2.6.9: serial_core: uart_open

2.6.9: serial_core: uart_open

[karl malbrain]

The uart_open code loops waiting for CD to be asserted (whenever CLOCAL 
is not set).  The bottom of the loop contains the following code:

up(&state->sem);
schedule();
down(&state->sem);

if( signal_pending(current) )
   break;

When I issue an open("/dev/ttyS1", O_RDWR) from a terminal session on 
the console, the system seems to come to a stop in this loop until the 
process is killed.  I suspect that the scheduler is choosing this process
to run again because of an elevated console priority of some sort.
 
Is there a kernel mechanism to put a process to sleep until awakened by 
an event to replace this looping behaviour?
 
Thanks, karl malbrain, malbrain-at-yahoo-dot-com

RE: 2.6.9: serial_core: uart_open

[karl malbrain]

>On Tue, 12 Jul 2005, karl malbrain wrote:

>> The uart_open code loops waiting for CD to be asserted (whenever CLOCAL
>> is not set).  The bottom of the loop contains the following code:
>>
>> up(&state->sem);
>> schedule();
>> down(&state->sem);
>>
>> if( signal_pending(current) )
>>   break;
>>
>> When I issue an open("/dev/ttyS1", O_RDWR) from a terminal session on
>> the console, the system seems to come to a stop in this loop until the
>> process is killed.  I suspect that the scheduler is choosing this process
>> to run again because of an elevated console priority of some sort.
>>
>> Is there a kernel mechanism to put a process to sleep until awakened by
>> an event to replace this looping behaviour?
>>
>> Thanks, karl malbrain, malbrain-at-yahoo-dot-com
>>

>In the first place, you should perform an open(O_NDELAY), so the open
>returns immediately with anything that has potential "modem-control".
>Then you can set the device to blocking using fcntl(F_GETFL), F_SETFL.

>Also, the task that is waiting for the open() is sleeping. That's
>what schedule() does.

>Cheers,
>Dick Johnson

I'm looking for the POSIX behaviour of delaying the open until CD is
asserted by the modem.  If schedule() doesn't select another process to run,
no wonder the system is hung at this point, because the uart_open loop
doesn't break until CD is asserted by the modem.  This sounds like a serious
bug.

karl_m

RE: 2.6.9: serial_core: uart_open

[karl malbrain]

>On Tue, 12 Jul 2005, karl malbrain wrote:
>
>>> On Tue, 12 Jul 2005, karl malbrain wrote:
>>
>>>> The uart_open code loops waiting for CD to be asserted (whenever CLOCAL
>>>> is not set).  The bottom of the loop contains the following code:
>>>>
>>>> up(&state->sem);
>>>> schedule();
>>>> down(&state->sem);
>>>>
>>>> if( signal_pending(current) )
>>>>   break;
>>>>
>>>> When I issue an open("/dev/ttyS1", O_RDWR) from a terminal session on
>>>> the console, the system seems to come to a stop in this loop until the
>>>> process is killed.  I suspect that the scheduler is choosing this
process
>>>> to run again because of an elevated console priority of some sort.
>>>>
>>>> Is there a kernel mechanism to put a process to sleep until awakened by
>>>> an event to replace this looping behaviour?
>>>>
>>>> Thanks, karl malbrain, malbrain-at-yahoo-dot-com
>>>>
>>>
>>> In the first place, you should perform an open(O_NDELAY), so the open
>>> returns immediately with anything that has potential "modem-control".
>>> Then you can set the device to blocking using fcntl(F_GETFL), F_SETFL.
>>
>>> Also, the task that is waiting for the open() is sleeping. That's
>>> what schedule() does.
>>
>>> Cheers,
>>> Dick Johnson
>>
>> I'm looking for the POSIX behaviour of delaying the open until CD is
>> asserted by the modem.  If schedule() doesn't select another process to
run,

>schedule() gives the CPU to any runnable process. That's how it works.
>Most all drivers that are waiting for an event will give up the CPU
>by executing schedule(). That's how-come you can be doing something
>useful while file-I/O is occurring.

That looks like a problem.  If uart_open is just calling schedule() and if
the current process running in uart_open is being selected again, the system
is hung.

>> no wonder the system is hung at this point, because the uart_open loop
>> doesn't break until CD is asserted by the modem.  This sounds like a
serious
>> bug.

>You need to look at your code.

The code:
#include <fcntl.h>
#include <stdio.h>

int main (void)
{
int fd = open ("/dev/ttyS1");
printf("Opened\n");
}

>
> karl_m
>
>There is no bug although there may be a bug in your code.
>Just do `cat /dev/ttyS1` or whatever your device is. It will
>wait on the open if modem-control is enabled, and you can see
>from another terminal that nothing is spinning.

>$ ps laxw | grep cat
>
>0     0 11555  2791  17   0  3512  348 -      S    tty2       0:00 cat
/dev/ttyS0
>                                               |
>                                               |__ clearly sleeping
>
>0     0 11610 11556  16   0  3656  568 -      R    tty3       0:00 grep cat

Are you sure that CLOCAL is not set on /dev/ttyS0? and that the cat is not
sleeping on a read???  That's my original question: how can uart_open be
changed to put the process to sleep rather than looping like it does now.

>Cheers,
>Dick Johnson

karl m

Re: 2.6.9: serial_core: uart_open

[Russell King]

On Tue, Jul 12, 2005 at 11:36:51AM -0700, karl malbrain wrote:
> The uart_open code loops waiting for CD to be asserted (whenever CLOCAL 
> is not set).  The bottom of the loop contains the following code:
> 
> up(&state->sem);
> schedule();
> down(&state->sem);
> 
> if( signal_pending(current) )
>    break;

This does cause the process to sleep - in an interruptible wait.

Please give more details about the problem you're seeing.  Have you
tried getting a process listing from a different virtual console,
xterm or whatever you normally use?  What does that say?

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 Serial core

RE: 2.6.9: serial_core: uart_open

[karl malbrain]

-----Original Message-----
From: Russell King
Sent: Tuesday, July 12, 2005 2:04 PM
To: karl malbrain
Cc: linux-kernel@vger.kernel.org
Subject: Re: 2.6.9: serial_core: uart_open


On Tue, Jul 12, 2005 at 11:36:51AM -0700, karl malbrain wrote:
> The uart_open code loops waiting for CD to be asserted (whenever CLOCAL
> is not set).  The bottom of the loop contains the following code:
>
> up(&state->sem);
> schedule();
> down(&state->sem);
>
> if( signal_pending(current) )
>    break;

This does cause the process to sleep - in an interruptible wait.

Please give more details about the problem you're seeing.  Have you
tried getting a process listing from a different virtual console,
xterm or whatever you normally use?  What does that say?

--
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 Serial core

Sorry, but I cannot get anything else to run.  I can barely get XWindows to
kill the process.

What prevents schedule() from returning to the current process w/o any
delay?

Thanks, karl m

RE: 2.6.9: serial_core: uart_open

[karl malbrain]

Thanks for the suggestion of setting the modem termio to a copy of the xterm
console state.  Unfortunately, it doesn't help, the system still goes
out-to-lunch on the non-blocking open, and becomes nearly completely
unresponsive at the console and to telnet sessions.

Yesterday evening after testing via a telnet connection, the problem finally
cleared itself up and everything started to work as expected (even from the
console).  This morning, after a re-boot, the problem at the console
reoccurs.  Note that this test is being done through an xterm session.

I've also noticed that the boot sequence probes for modems on the serial
ports.  Is it possible that 8250.c is having a problem servicing an
interrupt from a character/state-change left over from this initialization?

Thanks, karl m

-----Original Message-----
From: Richard B. Johnson
Sent: Wednesday, July 13, 2005 6:04 AM
To: karl malbrain
Cc: Linux-Kernel@Vger. Kernel. Org
Subject: RE: 2.6.9: serial_core: uart_open



The attached code will set the UART to a sane state, then
clear the local flag, then open, waiting for modem control.
It clearly works, executing `ps` from another terminal will
clearly show that the task waiting for modem-control to open,
will be sleeping.

There is nothing wrong with kernel code that calls schedule().
That's how unix-machines work. When they are waiting for something
to happen, they execute schedule() which gives the CPU to other
runable tasks. The call to schedule() returns each time the
run queue is traversed. The driver code again checks for whatever
it was waiting for, then if it hasn't happened, the cycle repeats.
This is called "sleeping". That's what sleeping is. There are some
macros that do the same thing. They have names like "wait_for...".

Re: 2.6.9: serial_core: uart_open

[Russell King]

On Wed, Jul 13, 2005 at 10:53:19AM -0700, karl malbrain wrote:
> I've also noticed that the boot sequence probes for modems on the serial
> ports.  Is it possible that 8250.c is having a problem servicing an
> interrupt from a character/state-change left over from this initialization?

I did ask for a process listing a while back.  I don't want to
speculate on possible causes until we have some real information
from the system as to what's going on.

Please run up your test program and get the machine into the
problematic state.  Let it remain like that for about 2 minutes,
and then run via a telnet session or other window:

ps aux > /tmp/ps-forrmk.txt

and send me that file.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 Serial core

RE: 2.6.9: serial_core: uart_open

[karl malbrain]

> -----Original Message-----
> From: Russell King
> Sent: Thursday, July 14, 2005 1:27 AM
> To: karl malbrain
> Cc: Linux-Kernel@Vger. Kernel. Org
> Subject: Re: 2.6.9: serial_core: uart_open
>
>
> On Wed, Jul 13, 2005 at 10:53:19AM -0700, karl malbrain wrote:
> > I've also noticed that the boot sequence probes for modems on the serial
> > ports.  Is it possible that 8250.c is having a problem servicing an
> > interrupt from a character/state-change left over from this
> initialization?
>
> I did ask for a process listing a while back.  I don't want to
> speculate on possible causes until we have some real information
> from the system as to what's going on.
>
> Please run up your test program and get the machine into the
> problematic state.  Let it remain like that for about 2 minutes,
> and then run via a telnet session or other window:
>
> ps aux > /tmp/ps-forrmk.txt
>
> and send me that file.

I'd love to do a ps listing for you, but, except for the mouse, the system
is completely unresponsive after issuing the blocking open("/dev/ttyS1",
O_RDRW).

Telnet is dead; the console will respond to the mouse, but the only thing I
can do is close the xterm window and thereby kill the process. I can launch
a new xterm window from the menu using the mouse, but the new window is dead
and has no cursor nor bash prompt.

The clock on the display is being updated.  After several hours the system
reboots on its own.

I recall from my DOS days that 8250/16550 programming requires that the
specific IIR source be responded to, or the chip will immediately
turn-around with another interrupt.  It doesn't look like 8250.c is
organized to respond directly to the modem-status-change value in IIR which
requires reading MSR to reset.

I wish I could be of more assistance.  karl m

Re: 2.6.9: serial_core: uart_open

[Russell King]

On Thu, Jul 14, 2005 at 10:16:23AM -0700, karl malbrain wrote:
> I'd love to do a ps listing for you, but, except for the mouse, the system
> is completely unresponsive after issuing the blocking open("/dev/ttyS1",
> O_RDRW).
> 
> Telnet is dead; the console will respond to the mouse, but the only thing I
> can do is close the xterm window and thereby kill the process. I can launch
> a new xterm window from the menu using the mouse, but the new window is dead
> and has no cursor nor bash prompt.
> 
> The clock on the display is being updated.  After several hours the system
> reboots on its own.
> 
> I recall from my DOS days that 8250/16550 programming requires that the
> specific IIR source be responded to, or the chip will immediately
> turn-around with another interrupt.  It doesn't look like 8250.c is
> organized to respond directly to the modem-status-change value in IIR which
> requires reading MSR to reset.

Well, at this point interrupts are enabled, and _are_ handled.  The
only thing we use the IIR for is to answer the question "did this
device say it had an interrupt?"

If it did, we unconditionally read the MSR without fail.

So, I've no idea what so ever about what's going on here.  I don't
understand why your system is behaving the way it is.  Therefore,
I don't think we can progress this any further, sorry.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 Serial core

RE: 2.6.9: serial_core: uart_open

[karl malbrain]

> -----Original Message-----
> From: Russell King [mailto:rmk@arm.linux.org.uk]On Behalf Of Russell
> King
> Sent: Thursday, July 14, 2005 11:57 AM
> To: karl malbrain
> Cc: Linux-Kernel@Vger. Kernel. Org
> Subject: Re: 2.6.9: serial_core: uart_open
>
>
> On Thu, Jul 14, 2005 at 10:16:23AM -0700, karl malbrain wrote:
> > I'd love to do a ps listing for you, but, except for the mouse,
> the system
> > is completely unresponsive after issuing the blocking open("/dev/ttyS1",
> > O_RDRW).
> >
> > Telnet is dead; the console will respond to the mouse, but the
> only thing I
> > can do is close the xterm window and thereby kill the process.
> I can launch
> > a new xterm window from the menu using the mouse, but the new
> window is dead
> > and has no cursor nor bash prompt.
> >
> > The clock on the display is being updated.  After several hours
> the system
> > reboots on its own.
> >
> > I recall from my DOS days that 8250/16550 programming requires that the
> > specific IIR source be responded to, or the chip will immediately
> > turn-around with another interrupt.  It doesn't look like 8250.c is
> > organized to respond directly to the modem-status-change value
> in IIR which
> > requires reading MSR to reset.
>
> Well, at this point interrupts are enabled, and _are_ handled.  The
> only thing we use the IIR for is to answer the question "did this
> device say it had an interrupt?"
>
> If it did, we unconditionally read the MSR without fail.
>
> So, I've no idea what so ever about what's going on here.  I don't
> understand why your system is behaving the way it is.  Therefore,
> I don't think we can progress this any further, sorry.

There is some code inserted at the top of the main receive_chars loop in
8250.c that examines  tty->flip.count and returns without reading UART_RX
under the condition that tty->flip.count is not reset after a call to
tty->flip.work.func.  This would leave the chip RX IIR unserviced and
subject another interrupt request.  Is it possible that this is the cause of
the problem?

karl m

Thanks, karl m

RE: 2.6.9: serial_core: uart_open

[karl malbrain]

> -----Original Message-----
> From: Russell King
> Sent: Thursday, July 14, 2005 11:57 AM
> To: karl malbrain
> Cc: Linux-Kernel@Vger. Kernel. Org
> Subject: Re: 2.6.9: serial_core: uart_open
>
>
> On Thu, Jul 14, 2005 at 10:16:23AM -0700, karl malbrain wrote:
> > I'd love to do a ps listing for you, but, except for the mouse,
> the system
> > is completely unresponsive after issuing the blocking open("/dev/ttyS1",
> > O_RDRW).
> >
> > Telnet is dead; the console will respond to the mouse, but the
> only thing I
> > can do is close the xterm window and thereby kill the process.
> I can launch
> > a new xterm window from the menu using the mouse, but the new
> window is dead
> > and has no cursor nor bash prompt.
> >
> > The clock on the display is being updated.  After several hours
> the system
> > reboots on its own.
> >
> > I recall from my DOS days that 8250/16550 programming requires that the
> > specific IIR source be responded to, or the chip will immediately
> > turn-around with another interrupt.  It doesn't look like 8250.c is
> > organized to respond directly to the modem-status-change value
> in IIR which
> > requires reading MSR to reset.
>
> Well, at this point interrupts are enabled, and _are_ handled.  The
> only thing we use the IIR for is to answer the question "did this
> device say it had an interrupt?"
>
> If it did, we unconditionally read the MSR without fail.
>
> So, I've no idea what so ever about what's going on here.  I don't
> understand why your system is behaving the way it is.  Therefore,
> I don't think we can progress this any further, sorry.

AT LAST I HAVE SOME DATA!!!

The problem is that ALL SYSTEM CALLS to open "/dev/tty" are blocking!! even
with O_NDELAY set and even from completely disjoint sessions.  I discovered
this via issuing "strace sh".  That's why the new xterm windows froze.

The original process doing the open("/dev/ttyS1", O_RDWR) is listed in the
ps aux listing as status S+.

Hope this helps.... karl m

Re: 2.6.9: serial_core: uart_open

[Russell King]

On Thu, Jul 14, 2005 at 03:35:07PM -0700, karl malbrain wrote:
> AT LAST I HAVE SOME DATA!!!
> 
> The problem is that ALL SYSTEM CALLS to open "/dev/tty" are blocking!! even
> with O_NDELAY set and even from completely disjoint sessions.  I discovered
> this via issuing "strace sh".  That's why the new xterm windows froze.
> 
> The original process doing the open("/dev/ttyS1", O_RDWR) is listed in the
> ps aux listing as status S+.

Ok, 'S' means it's sleeping.

Can you enable Magic SYSRQ, and ensure that you have a large kernel
log buffer (the LOG_BUF_SHIFT configuration symbol).  Ensure that
/proc/sys/kernel/sysrq is 1, and re-run your test such that you have
something else waiting (eg, the strace sh).  Then hit Alt-SysRQ-T.

You can then read the kernel messages with dmesg - you may need the
-s argument to capture the entire kernel buffer.

This will tell us where all processes are sleeping.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 Serial core

RE: 2.6.9: serial_core: uart_open

[karl malbrain]

> -----Original Message-----
> From: Russell King
> Sent: Friday, July 15, 2005 12:29 AM
> To: karl malbrain
> Cc: Linux-Kernel@Vger. Kernel. Org
> Subject: Re: 2.6.9: serial_core: uart_open
>
>
> On Thu, Jul 14, 2005 at 03:35:07PM -0700, karl malbrain wrote:
> > AT LAST I HAVE SOME DATA!!!
> >
> > The problem is that ALL SYSTEM CALLS to open "/dev/tty" are
> blocking!! even
> > with O_NDELAY set and even from completely disjoint sessions.
> I discovered
> > this via issuing "strace sh".  That's why the new xterm windows froze.
> >
> > The original process doing the open("/dev/ttyS1", O_RDWR) is
> listed in the
> > ps aux listing as status S+.
>
> Ok, 'S' means it's sleeping.
>
> Can you enable Magic SYSRQ, and ensure that you have a large kernel
> log buffer (the LOG_BUF_SHIFT configuration symbol).  Ensure that
> /proc/sys/kernel/sysrq is 1, and re-run your test such that you have
> something else waiting (eg, the strace sh).  Then hit Alt-SysRQ-T.
>
> You can then read the kernel messages with dmesg - you may need the
> -s argument to capture the entire kernel buffer.
>
> This will tell us where all processes are sleeping.


 sh            D 00000006  3036  5341   5252                     (NOTLB)
d0408eb0 00000086 c01c14d7 00000006 d0408e94 000f4fa5 c0d38f81 000039a0
       df461240 df4613cc c035ff00 00000246 d0408ecc df461240 c0300e33
00000001
       df461240 c011c856 c035ff20 c035ff20 d0408000 00000001 c035abe0
d0408000
Call Trace:
 [<c01c14d7>] inode_has_perm+0x4c/0x54
 [<c0300e33>] __down+0x103/0x1fe
 [<c011c856>] default_wake_function+0x0/0xc
 [<c0301180>] __down_failed+0x8/0xc
 [<c021a4d0>] .text.lock.tty_io+0x87/0x10f
 [<c016d78c>] chrdev_open+0x325/0x3b9
 [<c016256f>] dentry_open+0xbd/0x180
 [<c01624ac>] filp_open+0x36/0x3c
 [<c01da502>] direct_strncpy_from_user+0x46/0x5d
 [<c0162970>] sys_open+0x31/0x7d
 [<c03036f3>] syscall_call+0x7/0xb

I believe that this is the sh process that's opening "/dev/tty"
karl m

RE: 2.6.9: serial_core: uart_open

[karl malbrain]

> -----Original Message-----
> From: Russell King
> Sent: Friday, July 15, 2005 12:29 AM
> To: karl malbrain
> Cc: Linux-Kernel@Vger. Kernel. Org
> Subject: Re: 2.6.9: serial_core: uart_open
>
>
> On Thu, Jul 14, 2005 at 03:35:07PM -0700, karl malbrain wrote:
> > AT LAST I HAVE SOME DATA!!!
> >
> > The problem is that ALL SYSTEM CALLS to open "/dev/tty" are
> blocking!! even
> > with O_NDELAY set and even from completely disjoint sessions.
> I discovered
> > this via issuing "strace sh".  That's why the new xterm windows froze.
> >
> > The original process doing the open("/dev/ttyS1", O_RDWR) is
> listed in the
> > ps aux listing as status S+.
>
> Ok, 'S' means it's sleeping.
>
> Can you enable Magic SYSRQ, and ensure that you have a large kernel
> log buffer (the LOG_BUF_SHIFT configuration symbol).  Ensure that
> /proc/sys/kernel/sysrq is 1, and re-run your test such that you have
> something else waiting (eg, the strace sh).  Then hit Alt-SysRQ-T.
>
> You can then read the kernel messages with dmesg - you may need the
> -s argument to capture the entire kernel buffer.
>
> This will tell us where all processes are sleeping.

Here is the dump of the original process that's waiting for the
open("/dev/ttyS1", O_RDWR) to return:

test5         S C023B673  3036  5399   5224                     (NOTLB)
d0fb6e88 00000086 d3462ea0 c023b673 04000000 001123f9 3949e4f7 00003b4e
       d204e170 d204e2fc dfee9658 dfd4ec60 c0422448 dfee9640 c02390c0
d1f22940
       00000000 d204e170 c011c856 00000000 00000000 c0236d4c 00000000
dfee9640
Call Trace:
 [<c023b673>] serial8250_interrupt+0x0/0x200
 [<c02390c0>] uart_block_til_ready+0x198/0x224
 [<c011c856>] default_wake_function+0x0/0xc
 [<c0236d4c>] uart_startup+0xb6/0x1d8
 [<c011c856>] default_wake_function+0x0/0xc
 [<c023980b>] uart_change_pm+0x1c/0x24
 [<c023938a>] uart_open+0xd1/0x105
 [<c0218226>] tty_open+0x18f/0x3b8
 [<c016d78c>] chrdev_open+0x325/0x3b9
 [<c016256f>] dentry_open+0xbd/0x180
 [<c01624ac>] filp_open+0x36/0x3c
 [<c0301e98>] __cond_resched+0x14/0x3b
 [<c01da4fa>] direct_strncpy_from_user+0x3e/0x5d
 [<c0162970>] sys_open+0x31/0x7d
 [<c03036f3>] syscall_call+0x7/0xb

Hope this helps, karl m

RE: 2.6.9: serial_core: uart_open

[karl malbrain]

> -----Original Message-----
> From: Richard B. Johnson
> Sent: Friday, July 15, 2005 8:53 AM
> To: karl malbrain
> Cc: Linux-Kernel@Vger. Kernel. Org
> Subject: RE: 2.6.9: serial_core: uart_open
>
>
> On Wed, 13 Jul 2005, karl malbrain wrote:
>
> > I've also noticed that the boot sequence probes for modems on the serial
> > ports.  Is it possible that 8250.c is having a problem servicing an
> > interrupt from a character/state-change left over from this
> initialization?
> >
>
> It doesn't care. Interrupts are edges in the 8250. If an interrupt
> is lost, it's just lost. The change of state gets lost or the character
> gets lost. This is rare, but cannot cause a hung system.

My spec for the NS16550D and my experience show that the specific interrupt
source identified in IIR must be serviced or the chip will initiate a new
interrupt sequence at its first opportunity.

When I wrote a 8250/16550 driver for DOS it was driven from IIR directly.
If you don't take this approach, then you must certify that each and every
path through the irq driver must service all possible interrupt sources.

karl m

Re: 2.6.9: serial_core: uart_open

[Russell King]

On Fri, Jul 15, 2005 at 09:02:48AM -0700, karl malbrain wrote:
> > -----Original Message-----
> > From: Russell King
> > Sent: Friday, July 15, 2005 12:29 AM
> > To: karl malbrain
> > Cc: Linux-Kernel@Vger. Kernel. Org
> > Subject: Re: 2.6.9: serial_core: uart_open
> >
> >
> > On Thu, Jul 14, 2005 at 03:35:07PM -0700, karl malbrain wrote:
> > > AT LAST I HAVE SOME DATA!!!
> > >
> > > The problem is that ALL SYSTEM CALLS to open "/dev/tty" are
> > blocking!! even
> > > with O_NDELAY set and even from completely disjoint sessions.
> > I discovered
> > > this via issuing "strace sh".  That's why the new xterm windows froze.
> > >
> > > The original process doing the open("/dev/ttyS1", O_RDWR) is
> > listed in the
> > > ps aux listing as status S+.
> >
> > Ok, 'S' means it's sleeping.
> >
> > Can you enable Magic SYSRQ, and ensure that you have a large kernel
> > log buffer (the LOG_BUF_SHIFT configuration symbol).  Ensure that
> > /proc/sys/kernel/sysrq is 1, and re-run your test such that you have
> > something else waiting (eg, the strace sh).  Then hit Alt-SysRQ-T.
> >
> > You can then read the kernel messages with dmesg - you may need the
> > -s argument to capture the entire kernel buffer.
> >
> > This will tell us where all processes are sleeping.
> 
> 
>  sh            D 00000006  3036  5341   5252                     (NOTLB)
> d0408eb0 00000086 c01c14d7 00000006 d0408e94 000f4fa5 c0d38f81 000039a0
>        df461240 df4613cc c035ff00 00000246 d0408ecc df461240 c0300e33
> 00000001
>        df461240 c011c856 c035ff20 c035ff20 d0408000 00000001 c035abe0
> d0408000
> Call Trace:
>  [<c01c14d7>] inode_has_perm+0x4c/0x54
>  [<c0300e33>] __down+0x103/0x1fe
>  [<c011c856>] default_wake_function+0x0/0xc
>  [<c0301180>] __down_failed+0x8/0xc
>  [<c021a4d0>] .text.lock.tty_io+0x87/0x10f
>  [<c016d78c>] chrdev_open+0x325/0x3b9

This seems to imply that there's a lock being taken in tty_open().  The
2.6.9 source contains no such thing.  Are you sure you're using an
unpatched 2.6.9 kernel?

>  [<c016256f>] dentry_open+0xbd/0x180
>  [<c01624ac>] filp_open+0x36/0x3c
>  [<c01da502>] direct_strncpy_from_user+0x46/0x5d
>  [<c0162970>] sys_open+0x31/0x7d
>  [<c03036f3>] syscall_call+0x7/0xb

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 Serial core

Re: 2.6.9: serial_core: uart_open

[karl malbrain]

----- Original Message ----- 
From: "Russell King" <rmk+lkml@arm.linux.org.uk>
To: "karl malbrain" <karl@petzent.com>
Cc: "Linux-Kernel@Vger. Kernel. Org" <linux-kernel@vger.kernel.org>
Sent: Friday, July 15, 2005 1:32 PM
Subject: Re: 2.6.9: serial_core: uart_open


> On Fri, Jul 15, 2005 at 09:02:48AM -0700, karl malbrain wrote:
> > > -----Original Message-----
> > > From: Russell King
> > > Sent: Friday, July 15, 2005 12:29 AM
> > > To: karl malbrain
> > > Cc: Linux-Kernel@Vger. Kernel. Org
> > > Subject: Re: 2.6.9: serial_core: uart_open
> > >
> > >
> > > On Thu, Jul 14, 2005 at 03:35:07PM -0700, karl malbrain wrote:
> > > > AT LAST I HAVE SOME DATA!!!
> > > >
> > > > The problem is that ALL SYSTEM CALLS to open "/dev/tty" are
> > > blocking!! even
> > > > with O_NDELAY set and even from completely disjoint sessions.
> > > I discovered
> > > > this via issuing "strace sh".  That's why the new xterm windows
froze.
> > > >
> > > > The original process doing the open("/dev/ttyS1", O_RDWR) is
> > > listed in the
> > > > ps aux listing as status S+.
> > >
> > > Ok, 'S' means it's sleeping.
> > >
> > > Can you enable Magic SYSRQ, and ensure that you have a large kernel
> > > log buffer (the LOG_BUF_SHIFT configuration symbol).  Ensure that
> > > /proc/sys/kernel/sysrq is 1, and re-run your test such that you have
> > > something else waiting (eg, the strace sh).  Then hit Alt-SysRQ-T.
> > >
> > > You can then read the kernel messages with dmesg - you may need the
> > > -s argument to capture the entire kernel buffer.
> > >
> > > This will tell us where all processes are sleeping.
> >
> >
> >  sh            D 00000006  3036  5341   5252                     (NOTLB)
> > d0408eb0 00000086 c01c14d7 00000006 d0408e94 000f4fa5 c0d38f81 000039a0
> >        df461240 df4613cc c035ff00 00000246 d0408ecc df461240 c0300e33
> > 00000001
> >        df461240 c011c856 c035ff20 c035ff20 d0408000 00000001 c035abe0
> > d0408000
> > Call Trace:
> >  [<c01c14d7>] inode_has_perm+0x4c/0x54
> >  [<c0300e33>] __down+0x103/0x1fe
> >  [<c011c856>] default_wake_function+0x0/0xc
> >  [<c0301180>] __down_failed+0x8/0xc
> >  [<c021a4d0>] .text.lock.tty_io+0x87/0x10f
> >  [<c016d78c>] chrdev_open+0x325/0x3b9
>
> This seems to imply that there's a lock being taken in tty_open().  The
> 2.6.9 source contains no such thing.  Are you sure you're using an
> unpatched 2.6.9 kernel?
>
> >  [<c016256f>] dentry_open+0xbd/0x180
> >  [<c01624ac>] filp_open+0x36/0x3c
> >  [<c01da502>] direct_strncpy_from_user+0x46/0x5d
> >  [<c0162970>] sys_open+0x31/0x7d
> >  [<c03036f3>] syscall_call+0x7/0xb
>

The system is red-hat 4.6.9-11EL.  There is a patch to tty_io but it doesn't
mention locking anything.  karl m