Am 11.03.2012 00:21, schrieb Richard Weinberger:Am 10.03.2012 23:51, schrieb Jiri Slaby:On 03/10/2012 11:26 PM, Richard Weinberger wrote:Hi!
While moving UML's console driver to tty_port some strange things
happened. So, I have a few questions. :-)
The original driver did not implement tty_operations->hangup(). If
I implement it and call tty_port_hangup(), as Alan suggested, the
login fails on all TTYs except tty0. It fails because the opened
TTY returns EIO upon read()/write() after /bin/login called
vhangup().
The call chain is: vhangup() -> tty_vhangup_self() -> tty_vhangup()
-> __tty_hangup()
Within __tty_hangup() something happens that I don't fully
understand:
if (cons_filp) { if (tty->ops->close) for (n = 0; n< closecount;
n++) tty->ops->close(tty, cons_filp); } else if (tty->ops->hangup)
(tty->ops->hangup)(tty);
Login on tty0 works because cons_filp is not NULL and
tty->ops->close() is called. On the other hand login fails on every
other TTY because cons_filp remains NULL and the TTY hangs up.
Is there something missing in my hangup function?
If I omit tty_operations->hangup() and leave it, like the old
driver, NULL non-tty0 TTYs cannot be opened. (getty terminates
immediately because it cannot open any TTY.) open() retuns -EIO
because the TTY_CLOSING is set in tty->flags.
How can this be?
Hmm, it looks like some process is sitting on a TTY which was hung.
And the system offers this hung TTY to others on further opens. Could
you check that there is no process with open TTY after the vhangup?
"lsof | grep tty" does not show anything else than tty0. :-\
BTW: When I start the kernel with /bin/sh as init, opening and writing to any TTY works fine.
It looks like Fedora 16's userspace does something that makes the TTYs unhappy.
Thanks,
//richard