<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html style="direction: ltr;">
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body style="direction: ltr;" bgcolor="#ffffff" text="#000000">
<p style="margin-bottom: 0cm; margin-top: 0pt;">Maxim Kovgan wrote:<br>
</p>
<blockquote cite="mid:0AD7D2FB-C99C-461F-AED1-BC89FD6D95F6@gmail.com"
type="cite">
<pre wrap="">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..."
</pre>
</blockquote>
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.<br>
<br>
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...<br>
<br>
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):<br>
<br>
<snip><br>
static int ptmx_open(struct inode *inode, struct file *filp)<br>
{<br>
struct tty_struct *tty;<br>
int retval;<br>
int index;<br>
<br>
nonseekable_open(inode, filp);<br>
<br>
/* find a device that is not in use. */<br>
printk(KERN_ALERT "34: pty_open to lock\n");<br>
tty_lock();<br>
printk(KERN_ALERT "35: pty_open locked\n");<br>
<snip><br>
<br>
OK, so I wrote "pty_code" where it should be "ptmx_open". But the
numbers are the real identifiers.<br>
<br>
And here's a small snippet from my /var/log/messages:<br>
<br>
Oct 29 16:14:34 ocho kernel: 02: pty_close to lock ffff880200f48800<br>
Oct 29 16:14:34 ocho kernel: 03: pty_close did lock ffff880200f48800<br>
Oct 29 16:14:58 ocho kernel: 34: pty_open to lock<br>
Oct 29 16:15:13 ocho kernel: 35: pty_open locked<br>
<br>
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?<br>
<br>
Or maybe, it has something to do with pty_close() looking like this
(the printks above omitted)?<br>
<br>
static void (struct tty_struct *tty, struct file *filp)<br>
{<br>
[ ... do the stuff, but no hassle with locks... ]<br>
tty_<font color="#ff0000"><b>un</b></font>lock();<br>
tty_vhangup(tty->link);<br>
tty_lock();<br>
}<br>
}<br>
<br>
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.<br>
<br>
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.<br>
<br>
Thanks to Guy again for that little tip.<br>
<br>
Eli<br>
<pre class="moz-signature" cols="72">--
Web: <a class="moz-txt-link-freetext" href="http://www.billauer.co.il">http://www.billauer.co.il</a>
</pre>
</body>
</html>