Re: why is tty->pgrp set to -1 for console?

Re: why is tty->pgrp set to -1 for console?

[David Boutcher]

>  We had a problem that ctrl-c was not working on the console.

You need to be running something like mingetty on the console to have
signals (like ctrl-c) picked up.  If you start Linux with something like
"init=/bin/bash" then job control signals (like control C and control Z)
won't work.

Dave Boutcher
iSeries Linux guy


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

Re: why is tty->pgrp set to -1 for console?

[mod+linuxppc-dev]

>> We had a problem that ctrl-c was not working on the console.
>
>You need to be running something like mingetty on the console to
>have signals (like ctrl-c) picked up.  If you start Linux with
>something like "init=/bin/bash" then job control signals (like
>control C and control Z) won't work.


That doesn't sound correct.  When the system is in
single-user mode the console shell is a direct child
of init and is spawned without any kind of getty, yet
(at least in my case) the behavior of the shell is
indistinguishable from one spawned from mutiuser mode -
all signals (and job control, etc) are handled correctly.


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

Re: why is tty->pgrp set to -1 for console?

[Dan Malek]

David Boutcher wrote:


> You need to be running something like mingetty on the console to have
> signals (like ctrl-c) picked up.  If you start Linux with something like
> "init=/bin/bash" then job control signals (like control C and control Z)
> won't work.

One of the main reasons for this is the process in slot 1 (i.e. init)
has special signal handling in the kernel.  There are a variety of ways
to get a shell with job control running on the console.  Starting some
version of getty/mingetty as you mentioned is one, you can also fork a
shell and use stty to set signals, or anything to get a shell running
as process 2 or above.


	-- Dan


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

kernel hang when machine_restart called from isr

[gopi]

hi..

  linux: hardhat linux for powerpc(linux 2.2.14)

  We are calling machine_restart(which call m8xx_gorom) from an isr,
but the kernel hangs after coming to some stage on the restart.

If we call the same machine_restart from a simple ioctl, it works.

  Is there any limitation on the usage of machine_restart?  Does it
assume something which is not true when called from an ISR?

thanx
gopi


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

why is tty->pgrp set to -1 for console?

[gopi]

hi..

  We had a problem that ctrl-c was not working on the console.  I
figured out that, ctrl-c was getting recognized as the 'intr' signal,
but the function isig (in drivers/char/n_tty.c) sends a signal only if
the tty->pgrp > 0.

  I have put a print stmt in this function and checked that the value
  is 'tty->pgrp = ffffffff' (which is -1).

  What is the correct procedure to follow to get around this problem
and get ctrl-c working on console?

thanx
gopi

following is the output of stty -a on the console
---------------------------------------------------------------------
speed 9600 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^X; eof = ^D; eol = <undef>;
eol2 = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase =
^W;
lnext = ^V; flush = ^U; min = 1; time = 0;
-parenb -parodd cs8 hupcl -cstopb -cread clocal -crtscts
-ignbrk -brkint ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl ixon -ixoff
-iuclc ixany -imaxbel
opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
isig icanon -iexten echo -echoe -echok -echonl -noflsh -xcase -tostop echoprt
echoctl echoke
---------------------------------------------------------------------

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

Re: why is tty->pgrp set to -1 for console?

[Daniel Jacobowitz]

On Thu, Jan 31, 2002 at 08:58:58PM +0000, gopi@india.tejasnetworks.com wrote:
>
> hi..
>
>   We had a problem that ctrl-c was not working on the console.  I
> figured out that, ctrl-c was getting recognized as the 'intr' signal,
> but the function isig (in drivers/char/n_tty.c) sends a signal only if
> the tty->pgrp > 0.
>
>   I have put a print stmt in this function and checked that the value
>   is 'tty->pgrp = ffffffff' (which is -1).
>
>   What is the correct procedure to follow to get around this problem
> and get ctrl-c working on console?

You need to run a getty on the console in order for SIGINT to get sent
properly.  That should be all it takes.  If the pgrp hasn't been set
yet, the kernel doesn't know where to send them.

--
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

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

Re: why is tty->pgrp set to -1 for console?

[Scott Anderson]

gopi@india.tejasnetworks.com wrote:
>   What is the correct procedure to follow to get around this problem
> and get ctrl-c working on console?

It looks like everyone is taking a swing at this one, so I think I'll
join in.  First off, the easiest way I've found to track down why
ctrl-c doesn't work is to just run "ps -j".  For ctrl-c to work, you
need a controlling terminal (the TTY column) and a process group.  If
you have a '?' in the TTY column, ctrl-c won't work.  In the past I
have seen this happen because of this code in drivers/char/tty_io.c:
        if (device == SYSCONS_DEV) {
                struct console *c = console_drivers;
                while(c && !c->device)
                        c = c->next;
                if (!c)
                        return -ENODEV;
                device = c->device(c);
                filp->f_flags |= O_NONBLOCK; /* Don't let /dev/console block */
                noctty = 1;
        }
Note that O_NOCTTY (no controlling terminal) is forced on whenever
/dev/console is opened (noctty = 1).  Possible workarounds:
  1) Run getty on something other than /dev/console.  For example,
     if you console is on the first serial port, run getty on /dev/ttyS0.
     I believe this is the "correct" answer.
  2) You could also change getty to do a TIOCSCTTY ioctl explicitly after
     it has opened the terminal.
  3) You could remove the forcing of noctty on from tty_io.c

    Scott Anderson
    scott_anderson@mvista.com   MontaVista Software Inc.
    (408)328-9214               1237 East Arques Ave.
    http://www.mvista.com       Sunnyvale, CA  94085

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

Re: why is tty->pgrp set to -1 for console?

[gopi]

Thanx, both the options 1 and 3 are working (I didnt try 2).

With option 1, wouldn't we have the problem of some important kernel
messages(say oops) not coming on the terminal as they are put on
'console'.  Even though kmsg will have it, it is good if we can see
it on the console in case something goes wrong.

thanx
gopi
ps: ours is an embedded system


On Thu, 31 Jan 2002, Scott Anderson wrote:

> gopi@india.tejasnetworks.com wrote:
> >   What is the correct procedure to follow to get around this problem
> > and get ctrl-c working on console?
>
> It looks like everyone is taking a swing at this one, so I think I'll
> join in.  First off, the easiest way I've found to track down why
> ctrl-c doesn't work is to just run "ps -j".  For ctrl-c to work, you
> need a controlling terminal (the TTY column) and a process group.  If
> you have a '?' in the TTY column, ctrl-c won't work.  In the past I
> have seen this happen because of this code in drivers/char/tty_io.c:
>         if (device == SYSCONS_DEV) {
>                 struct console *c = console_drivers;
>                 while(c && !c->device)
>                         c = c->next;
>                 if (!c)
>                         return -ENODEV;
>                 device = c->device(c);
>                 filp->f_flags |= O_NONBLOCK; /* Don't let /dev/console block */
>                 noctty = 1;
>         }
> Note that O_NOCTTY (no controlling terminal) is forced on whenever
> /dev/console is opened (noctty = 1).  Possible workarounds:
>   1) Run getty on something other than /dev/console.  For example,
>      if you console is on the first serial port, run getty on /dev/ttyS0.
>      I believe this is the "correct" answer.
>   2) You could also change getty to do a TIOCSCTTY ioctl explicitly after
>      it has opened the terminal.
>   3) You could remove the forcing of noctty on from tty_io.c
>
>     Scott Anderson
>     scott_anderson@mvista.com   MontaVista Software Inc.
>     (408)328-9214               1237 East Arques Ave.
>     http://www.mvista.com       Sunnyvale, CA  94085
>


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