Ctrl-C does not work

Hello everyone,

Ctrl-C does on work on my serial console when I use the sample file
system from Hardhat 1.0 toolkit. It , however, works with the Hardhat
1.2 toolkit sample file system. I am using the same kernel to test both
the file systems. What could be different between these two file
systems?

Thank you,
Navin

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Navin,
Take a look at the /dev/console entry. In one it is a link to
/dev/ttyS0 in the other it isn't. At one point it should have
been the link. That is what makes it work. It was a feature
that is a disguised bug. It was fixed in HHL 2.0

Cal Erickson

Navin Boppuri wrote:

Hello everyone,

Ctrl-C does on work on my serial console when I use the sample file
system from Hardhat 1.0 toolkit. It , however, works with the Hardhat
1.2 toolkit sample file system. I am using the same kernel to test both
the file systems. What could be different between these two file
systems?

Thank you,
Navin

--
===========================================================================
Cal Erickson                 MontaVista Software Inc.
Linux Consultant             1237 E. Arques Ave.
Phone (408) 328-0304         Sunnyvale CA 94085
Fax   (408) 328-9204         web http://www.mvista.com
===========================================================================


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Navin Boppuri wrote:

Hello everyone,

Ctrl-C does on work on my serial console when I use the sample file
system from Hardhat 1.0 toolkit. It , however, works with the Hardhat
1.2 toolkit sample file system. I am using the same kernel to test both
the file systems. What could be different between these two file
systems?

Thank you,
Navin

Actually control-c should _NOT_ be working on Cross Dev Kit 1.0, or
1.2.  If it does work in one you are lucky.  There is a problem with the
way the serial consoles are started on CDK 1.0 and 1.2, it was left up
to the serial driver to turn on or off the control-c activation.

Under HHL 2.0, this problem has been resolved by using getty and login
to start a serial connection.  login has a patch that ensures that the
control-c stuff is enabled.

I would highly recommend that you move forward to HHL 2.0 if you can, it
has a lot of these minor annoyances fixed.

--Mark Hatle
MontaVista Software, Inc.

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Mark Hatle wrote:

.....  There is a problem with the
way the serial consoles are started on CDK 1.0 and 1.2, it was left up
to the serial driver to turn on or off the control-c activation.

It actually has to do with the way tty process groups are created and
signals are managed.  If you boot _any_ Linux kernel using something
like 'init=/bin/sh', ctl-C doesn't work because the process in slot 1
(normally init) is treated with special signal handling by the kernel.

.... login has a patch that ensures that the
control-c stuff is enabled.

Huh?  All you need to do is properly start up an interactive
session from init to get process group signal handling.  This is
just standard Linux userland stuff documented in a variety of places.



	-- Dan

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Dan Malek wrote:

Mark Hatle wrote:

quoted

.....  There is a problem with the
way the serial consoles are started on CDK 1.0 and 1.2, it was left up
to the serial driver to turn on or off the control-c activation.

It actually has to do with the way tty process groups are created and
signals are managed.  If you boot _any_ Linux kernel using something
like 'init=/bin/sh', ctl-C doesn't work because the process in slot 1
(normally init) is treated with special signal handling by the kernel.

Correct.  I should have been clearer before.

quoted

.... login has a patch that ensures that the
control-c stuff is enabled.

Huh?  All you need to do is properly start up an interactive
session from init to get process group signal handling.  This is
just standard Linux userland stuff documented in a variety of places.

Depends on the device, the problem that was solved was /dev/console may
not be /dev/ttyS0.  It can be a number of things, which can change from
the kernel boot parameters.  So /dev/console has to be used in a generic
interface.  The patch specifically enables TIOCSCTTY on the device, this
ensures that /dev/console will in fact work as a TTY (including ctrl-c
support).  The exception to this if if you set /dev/console to be
something other then a serial device, then TIOCSCTTY will fail, and
control-c will still probably not work.  :)

So the _ACTUAL_ problem is that /dev/console does not have TIOCSCTTY
enabled by default, where as _MOST_ serial drivers do have it enabled by
default.  (Again we found a couple a while back that did not work
properly, but I don't think they were on PPC...)

So the problem in HHL Cross Dev Kit 1.0 and 1.2 was the way that the
shell was being invoked from the init program, and the device that was
being used.  This is no longer an issue w/ HHL 2.0, unless you do
init=/bin/sh, but that is a different problem!  <grin>

--Mark

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/