From: Richard Weinberger <richard@nod.at>
To: Jiri Slaby <jslaby@suse.cz>
Cc: linux-kernel@vger.kernel.org, alan@lxorguk.ukuu.org.uk,
gregkh@linuxfoundation.org, Jiri Slaby <jirislaby@gmail.com>
Subject: Re: TTY: tty_port questions
Date: Sun, 11 Mar 2012 12:01:51 +0100 [thread overview]
Message-ID: <4F5C861F.2000507@nod.at> (raw)
In-Reply-To: <4F5BE1E6.9000201@nod.at>
[-- Attachment #1: Type: text/plain, Size: 1988 bytes --]
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
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
next prev parent reply other threads:[~2012-03-11 11:02 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-03-10 22:26 TTY: tty_port questions Richard Weinberger
2012-03-10 22:51 ` Jiri Slaby
2012-03-10 23:21 ` Richard Weinberger
2012-03-11 11:01 ` Richard Weinberger [this message]
2012-03-12 10:26 ` Richard Weinberger
2012-03-12 10:53 ` Alan Cox
2012-03-12 11:15 ` Richard Weinberger
2012-03-12 11:48 ` Alan Cox
2012-03-24 23:20 ` Al Viro
2012-03-25 14:51 ` Alan Cox
2012-03-25 15:14 ` Richard Weinberger
2012-03-25 17:20 ` Al Viro
2012-03-25 21:09 ` Alan Cox
2012-03-25 18:31 ` Al Viro
2012-03-25 21:06 ` Alan Cox
2012-03-25 22:33 ` Al Viro
2012-03-28 11:06 ` Alan Cox
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4F5C861F.2000507@nod.at \
--to=richard@nod.at \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=gregkh@linuxfoundation.org \
--cc=jirislaby@gmail.com \
--cc=jslaby@suse.cz \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.