Maxim Kovgan wrote:
1) I hope I didn't miss a sentence in one of the emails "I've searched the google
for 48 hours for similar problem..."
I always check Google first. Just to find out that it's adapting itself
to "common people". For example, looking for "pts", I get hits on the
word points. Looks like we're loosing Google too.
As for the arguments about TTYs blocking, I don't think that is relevant
during the open() call. Opening a TTY/PTY is doing nothing except
allocating memory and registering stuff, as far as I know. No reason it
should take any time. Unless...
Since there's a little kernel hacker hiding in me, I decided to put
printk's all over the pty.c file. I ended up with 37 of them, and here's
the interesting part (in the modified code):
<snip>
static int ptmx_open(struct inode *inode, struct file *filp)
{
struct tty_struct *tty;
int retval;
int index;
nonseekable_open(inode, filp);
/* find a device that is not in use. */
printk(KERN_ALERT "34: pty_open to lock\n");
tty_lock();
printk(KERN_ALERT "35: pty_open locked\n");
<snip>
OK, so I wrote "pty_code" where it should be "ptmx_open". But the
numbers are the real identifiers.
And here's a small snippet from my /var/log/messages:
Oct 29 16:14:34 ocho kernel: 02: pty_close to lock ffff880200f48800
Oct 29 16:14:34 ocho kernel: 03: pty_close did lock ffff880200f48800
Oct 29 16:14:58 ocho kernel: 34: pty_open to lock
Oct 29 16:15:13 ocho kernel: 35: pty_open locked
Hmmm... 15 seconds to acquire a lock. On other 34-35 pairs this took
no-time, of course. In case you wonder, tty_lock() and tty_unlock() gets
and releases the global mutex for all TTY related stuff. Introduced
somewhere between my old 2.6.35 and 2.6.36. Could it have something to
do with my problem?
Or maybe, it has something to do with pty_close() looking like this (the
printks above omitted)?
static void (struct tty_struct *tty, struct file *filp)
{
[ ... do the stuff, but no hassle with locks... ]
tty_*un*lock();
tty_vhangup(tty->link);
tty_lock();
}
}
Hmmm... Calling tty_unlock() first and then tty_lock(). And then return.
Maybe I missed something here, but this doesn't look good to me. I
didn't get it wrong. All other calls are lock(), then unlock(). Of course.
I've sent a little note to the relevant kernel maintainer about this. In
the meanwhile, I'll stick to my older kernel. Had enough with those oopses.
Thanks to Guy again for that little tip.
Eli
--
Web: http://www.billauer.co.il
_______________________________________________
Haifux mailing list
Haifux@haifux.org
http://hamakor.org.il/cgi-bin/mailman/listinfo/haifux
