Messages in this thread | | | Date | Sun, 2 May 2004 01:24:48 +0200 | From | Petr Vandrovec <> | Subject | Re: strange delays on console logouts (tty != 1) |
| |
On Sat, May 01, 2004 at 02:46:17PM -0700, Chris Wedgwood wrote: > On Fri, Apr 30, 2004 at 09:53:51PM +0200, Jorge Bernal wrote: > > I'm not sure who is to blame here, it looks like some tty's get into a > state that either init or the getty doesn't like and don't want to > come unstuck easily (stty sane > /dev/tty<foo> sometimes helps). > > I need to get an init working as pid != 1 with debugging so I can > figure out what init thinks here. I've just been so short of time.
I do not think that it is init...
If I did analysis correct, problem is that:
(1) agetty (at least from util-linux 2.12 from current debian unstable) opens /dev/console and calls VT_OPENQRY to find first unopened VT. I have no idea why it does this, especially as it causes problems when more than one agetty is started simultaneously. I cannot believe that there is no better way how to detect whether tty is in use or not (as comment in the agetty suggests). Even spawning fuser /dev/ttyX looks less racy to me. This race between different agetty starting in parallel is reason why some gettys are missing after bootup. As they all use 10 sec timeout it takes some time until all my 24 gettys come up.
(2) tty hangup is scheduled for work_queue.
(3) when you have bad luck then scheduled hangup work runs AFTER newly created agetty calls VT_OPENQRY, and you get an error that ttyX is already in use...
When I just put /dev/ttyX instead of ttyX into /etc/inittab, problem disappears (as then VT_OPENQRY code in agetty is not triggered) and everything works as it should - except 'w', so I just disabled OPENQRY code in agetty instead as final solution.
I think that we should concentrate on how is it possible that init can spawn agetty and agetty can parse whole /var/run/utmp, open /dev/console and issue VT_OPENQRY before work scheduled before init was even notified is done. It looks to me like that someone schedules some job on the workqueue although that job apparently deserves its own kernel thread due to time it takes. Best regards, Petr Vandrovec - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |