RE: 2.6.9 chrdev_open: serial_core: uart_open
Successful resolution!! The red-hat engineers monitoring their bugzilla list posted a fix for tty_io.c Friday that works. Thanks again for your help. karl m > -Original Message- > From: Russell King > Sent: Friday, July 15, 2005 2:54 PM > To: karl malbrain > Cc: [EMAIL PROTECTED] Kernel. Org > Subject: Re: 2.6.9 chrdev_open: serial_core: uart_open > > > On Fri, Jul 15, 2005 at 02:17:01PM -0700, karl malbrain wrote: > > > -Original Message- > > > From: Russell King > > > Sent: Friday, July 15, 2005 1:59 PM > > > To: karl malbrain > > > Cc: [EMAIL PROTECTED] Kernel. Org > > > Subject: Re: 2.6.9 chrdev_open: serial_core: uart_open > > > > > > > > > On Fri, Jul 15, 2005 at 01:52:15PM -0700, karl malbrain wrote: > > > > On my 2.6.9-11EL source it clearly shows the up(_sem) after > > > the call to > > > > uart_open. Init_dev never touches tty_sem. > > > > > > In which case, I have to say... > > > > > > Congratulations! You've found a bug with Red Hat's Enterprise Linux > > > kernel! Go straight to Red Hat's bugzilla! Do not collect 200$. Do > > > not pass go. > > > > > > Seriously though, this bug is not present in mainline kernels, so I > > > can't resolve this issue for you. Mainline kernels appear to work > > > properly. > > > > Could tty_io.c be all that changed by a small set of red-hat patches to > > 2.6.9? Why would they need to go in there to make so many > changes in the > > first place? Which 2.6 release changed tty_io.c's use of tty_sem so > > heavily? > > These are questions to ask of Red Hat, and can only be answered by > their representatives. > > Thanks anyway, and I'm sorry that this hasn't been resolved given > the amount of time put into it by both of us. > > -- > Russell King > Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/ > maintainer of: 2.6 Serial core - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: 2.6.9 chrdev_open: serial_core: uart_open
Successful resolution!! The red-hat engineers monitoring their bugzilla list posted a fix for tty_io.c Friday that works. Thanks again for your help. karl m -Original Message- From: Russell King Sent: Friday, July 15, 2005 2:54 PM To: karl malbrain Cc: [EMAIL PROTECTED] Kernel. Org Subject: Re: 2.6.9 chrdev_open: serial_core: uart_open On Fri, Jul 15, 2005 at 02:17:01PM -0700, karl malbrain wrote: -Original Message- From: Russell King Sent: Friday, July 15, 2005 1:59 PM To: karl malbrain Cc: [EMAIL PROTECTED] Kernel. Org Subject: Re: 2.6.9 chrdev_open: serial_core: uart_open On Fri, Jul 15, 2005 at 01:52:15PM -0700, karl malbrain wrote: On my 2.6.9-11EL source it clearly shows the up(tty_sem) after the call to uart_open. Init_dev never touches tty_sem. In which case, I have to say... Congratulations! You've found a bug with Red Hat's Enterprise Linux kernel! Go straight to Red Hat's bugzilla! Do not collect 200$. Do not pass go. Seriously though, this bug is not present in mainline kernels, so I can't resolve this issue for you. Mainline kernels appear to work properly. Could tty_io.c be all that changed by a small set of red-hat patches to 2.6.9? Why would they need to go in there to make so many changes in the first place? Which 2.6 release changed tty_io.c's use of tty_sem so heavily? These are questions to ask of Red Hat, and can only be answered by their representatives. Thanks anyway, and I'm sorry that this hasn't been resolved given the amount of time put into it by both of us. -- Russell King Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: 2.6 Serial core - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: 2.6.9 chrdev_open: serial_core: uart_open
> -Original Message- > From: Russell King > Sent: Friday, July 15, 2005 2:54 PM > To: karl malbrain > Cc: [EMAIL PROTECTED] Kernel. Org > Subject: Re: 2.6.9 chrdev_open: serial_core: uart_open > > > On Fri, Jul 15, 2005 at 02:17:01PM -0700, karl malbrain wrote: > > > -Original Message- > > > From: Russell King > > > Sent: Friday, July 15, 2005 1:59 PM > > > To: karl malbrain > > > Cc: [EMAIL PROTECTED] Kernel. Org > > > Subject: Re: 2.6.9 chrdev_open: serial_core: uart_open > > > > > > > > > On Fri, Jul 15, 2005 at 01:52:15PM -0700, karl malbrain wrote: > > > > On my 2.6.9-11EL source it clearly shows the up(_sem) after > > > the call to > > > > uart_open. Init_dev never touches tty_sem. > > > > > > In which case, I have to say... > > > > > > Congratulations! You've found a bug with Red Hat's Enterprise Linux > > > kernel! Go straight to Red Hat's bugzilla! Do not collect 200$. Do > > > not pass go. > > > > > > Seriously though, this bug is not present in mainline kernels, so I > > > can't resolve this issue for you. Mainline kernels appear to work > > > properly. > > > > Could tty_io.c be all that changed by a small set of red-hat patches to > > 2.6.9? Why would they need to go in there to make so many > changes in the > > first place? Which 2.6 release changed tty_io.c's use of tty_sem so > > heavily? > > These are questions to ask of Red Hat, and can only be answered by > their representatives. I've since answered part of my question. Red Hat pulled some code-changes from 2.6.10 tty_io.c with the somewhat cryptic comment "fix the trivial exploits caused by Rolands controlling tty changes (part 1)" and moved the tty_sem ops. Do you know if this would be Roland at Red Hat, or a Roland at lkml? Thanks, karl m - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: 2.6.9 chrdev_open: serial_core: uart_open
> -Original Message- > From: Russell King > Sent: Friday, July 15, 2005 1:59 PM > To: karl malbrain > Cc: [EMAIL PROTECTED] Kernel. Org > Subject: Re: 2.6.9 chrdev_open: serial_core: uart_open > > > On Fri, Jul 15, 2005 at 01:52:15PM -0700, karl malbrain wrote: > > On my 2.6.9-11EL source it clearly shows the up(_sem) after > the call to > > uart_open. Init_dev never touches tty_sem. > > In which case, I have to say... > > Congratulations! You've found a bug with Red Hat's Enterprise Linux > kernel! Go straight to Red Hat's bugzilla! Do not collect 200$. Do > not pass go. > > Seriously though, this bug is not present in mainline kernels, so I > can't resolve this issue for you. Mainline kernels appear to work > properly. Could tty_io.c be all that changed by a small set of red-hat patches to 2.6.9? Why would they need to go in there to make so many changes in the first place? Which 2.6 release changed tty_io.c's use of tty_sem so heavily? This conflict between main-line/redhat looks much worse than the unix sysV r4.0 divergence after 3.2. Ouch. Thanks for your help, though. karl m - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: 2.6.9 chrdev_open: serial_core: uart_open
> -Original Message- > From: Russell King > Sent: Friday, July 15, 2005 1:31 PM > To: karl malbrain > Cc: [EMAIL PROTECTED] Kernel. Org > Subject: Re: 2.6.9 chrdev_open: serial_core: uart_open > > > On Fri, Jul 15, 2005 at 01:11:33PM -0700, karl malbrain wrote: > > > -Original Message- > > > From: Russell King > > > Sent: Friday, July 15, 2005 12:23 AM > > > To: karl malbrain > > > Cc: [EMAIL PROTECTED] Kernel. Org > > > Subject: Re: 2.6.9 chrdev_open: serial_core: uart_open > > > > > > > > > On Thu, Jul 14, 2005 at 04:50:00PM -0700, karl malbrain wrote: > > > > chrdev_open issues a lock_kernel() before calling uart_open. > > > > > > > > It would appear that servicing the blocking open request > > > uart_open goes to > > > > sleep with the kernel locked. Would this shut down > subsequent access to > > > > opening "/dev/tty"??? > > > > > > No. lock_kernel() is automatically released when a process sleeps. > > > > Drilling down between the uart_open and chrdev_open into tty_open is a > > semaphore tty_sem that is being held during the sleep cycle in > uart_open. > > chrdev_open() calls tty_open(), which then calls init_dev(). init_dev() > takes tty_sem, does its stuff, and then releases tty_sem. A little > later on, tty_open() calls the uart driver's uart_open() function. > > So it does this with tty_sem unlocked. On my 2.6.9-11EL source it clearly shows the up(_sem) after the call to uart_open. Init_dev never touches tty_sem. karl m - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.9: serial_core: uart_open
- Original Message -
From: "Russell King" <[EMAIL PROTECTED]>
To: "karl malbrain" <[EMAIL PROTECTED]>
Cc: "[EMAIL PROTECTED] 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: [EMAIL PROTECTED] 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.
> >
> >
> > shD 0006 3036 5341 5252 (NOTLB)
> > d0408eb0 0086 c01c14d7 0006 d0408e94 000f4fa5 c0d38f81 39a0
> >df461240 df4613cc c035ff00 0246 d0408ecc df461240 c0300e33
> > 0001
> >df461240 c011c856 c035ff20 c035ff20 d0408000 0001 c035abe0
> > d0408000
> > Call Trace:
> > [] inode_has_perm+0x4c/0x54
> > [] __down+0x103/0x1fe
> > [] default_wake_function+0x0/0xc
> > [] __down_failed+0x8/0xc
> > [] .text.lock.tty_io+0x87/0x10f
> > [] 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?
>
> > [] dentry_open+0xbd/0x180
> > [] filp_open+0x36/0x3c
> > [] direct_strncpy_from_user+0x46/0x5d
> > [] sys_open+0x31/0x7d
> > [] 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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: 2.6.9 chrdev_open: serial_core: uart_open
> -Original Message- > From: Russell King > Sent: Friday, July 15, 2005 12:23 AM > To: karl malbrain > Cc: [EMAIL PROTECTED] Kernel. Org > Subject: Re: 2.6.9 chrdev_open: serial_core: uart_open > > > On Thu, Jul 14, 2005 at 04:50:00PM -0700, karl malbrain wrote: > > chrdev_open issues a lock_kernel() before calling uart_open. > > > > It would appear that servicing the blocking open request > uart_open goes to > > sleep with the kernel locked. Would this shut down subsequent access to > > opening "/dev/tty"??? > > No. lock_kernel() is automatically released when a process sleeps. Drilling down between the uart_open and chrdev_open into tty_open is a semaphore tty_sem that is being held during the sleep cycle in uart_open. This would appear to be the problem!! Is this a new semaphore in 2.6? How could this have ever worked with tty blocking mode? It would appear that tty_sem is going to have to be released before sleeping in uart_open. What a mess. N.b. I don't pretend to understand how uart_change_pm, uart_startup, and uart_block_til_ready could ALL be on the call stack. Uart_open calls them sequentially. Perhaps you might explain how this works? Thanks, karl m - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: 2.6.9: serial_core: uart_open
> -Original Message- > From: Richard B. Johnson > Sent: Friday, July 15, 2005 8:53 AM > To: karl malbrain > Cc: [EMAIL PROTECTED] 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: 2.6.9: serial_core: uart_open
> -Original Message-
> From: Russell King
> Sent: Friday, July 15, 2005 12:29 AM
> To: karl malbrain
> Cc: [EMAIL PROTECTED] 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 0086 d3462ea0 c023b673 0400 001123f9 3949e4f7 3b4e
d204e170 d204e2fc dfee9658 dfd4ec60 c0422448 dfee9640 c02390c0
d1f22940
d204e170 c011c856 c0236d4c
dfee9640
Call Trace:
[] serial8250_interrupt+0x0/0x200
[] uart_block_til_ready+0x198/0x224
[] default_wake_function+0x0/0xc
[] uart_startup+0xb6/0x1d8
[] default_wake_function+0x0/0xc
[] uart_change_pm+0x1c/0x24
[] uart_open+0xd1/0x105
[] tty_open+0x18f/0x3b8
[] chrdev_open+0x325/0x3b9
[] dentry_open+0xbd/0x180
[] filp_open+0x36/0x3c
[] __cond_resched+0x14/0x3b
[] direct_strncpy_from_user+0x3e/0x5d
[] sys_open+0x31/0x7d
[] syscall_call+0x7/0xb
Hope this helps, karl m
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: 2.6.9: serial_core: uart_open
> -Original Message-
> From: Russell King
> Sent: Friday, July 15, 2005 12:29 AM
> To: karl malbrain
> Cc: [EMAIL PROTECTED] 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.
shD 0006 3036 5341 5252 (NOTLB)
d0408eb0 0086 c01c14d7 0006 d0408e94 000f4fa5 c0d38f81 39a0
df461240 df4613cc c035ff00 0246 d0408ecc df461240 c0300e33
0001
df461240 c011c856 c035ff20 c035ff20 d0408000 0001 c035abe0
d0408000
Call Trace:
[] inode_has_perm+0x4c/0x54
[] __down+0x103/0x1fe
[] default_wake_function+0x0/0xc
[] __down_failed+0x8/0xc
[] .text.lock.tty_io+0x87/0x10f
[] chrdev_open+0x325/0x3b9
[] dentry_open+0xbd/0x180
[] filp_open+0x36/0x3c
[] direct_strncpy_from_user+0x46/0x5d
[] sys_open+0x31/0x7d
[] syscall_call+0x7/0xb
I believe that this is the sh process that's opening "/dev/tty"
karl m
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: 2.6.9: serial_core: uart_open
-Original Message- From: Russell King Sent: Friday, July 15, 2005 12:29 AM To: karl malbrain Cc: [EMAIL PROTECTED] 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. shD 0006 3036 5341 5252 (NOTLB) d0408eb0 0086 c01c14d7 0006 d0408e94 000f4fa5 c0d38f81 39a0 df461240 df4613cc c035ff00 0246 d0408ecc df461240 c0300e33 0001 df461240 c011c856 c035ff20 c035ff20 d0408000 0001 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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: 2.6.9: serial_core: uart_open
-Original Message-
From: Russell King
Sent: Friday, July 15, 2005 12:29 AM
To: karl malbrain
Cc: [EMAIL PROTECTED] 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 0086 d3462ea0 c023b673 0400 001123f9 3949e4f7 3b4e
d204e170 d204e2fc dfee9658 dfd4ec60 c0422448 dfee9640 c02390c0
d1f22940
d204e170 c011c856 c0236d4c
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
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: 2.6.9: serial_core: uart_open
-Original Message- From: Richard B. Johnson Sent: Friday, July 15, 2005 8:53 AM To: karl malbrain Cc: [EMAIL PROTECTED] 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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: 2.6.9 chrdev_open: serial_core: uart_open
-Original Message- From: Russell King Sent: Friday, July 15, 2005 12:23 AM To: karl malbrain Cc: [EMAIL PROTECTED] Kernel. Org Subject: Re: 2.6.9 chrdev_open: serial_core: uart_open On Thu, Jul 14, 2005 at 04:50:00PM -0700, karl malbrain wrote: chrdev_open issues a lock_kernel() before calling uart_open. It would appear that servicing the blocking open request uart_open goes to sleep with the kernel locked. Would this shut down subsequent access to opening /dev/tty??? No. lock_kernel() is automatically released when a process sleeps. Drilling down between the uart_open and chrdev_open into tty_open is a semaphore tty_sem that is being held during the sleep cycle in uart_open. This would appear to be the problem!! Is this a new semaphore in 2.6? How could this have ever worked with tty blocking mode? It would appear that tty_sem is going to have to be released before sleeping in uart_open. What a mess. N.b. I don't pretend to understand how uart_change_pm, uart_startup, and uart_block_til_ready could ALL be on the call stack. Uart_open calls them sequentially. Perhaps you might explain how this works? Thanks, karl m - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.9: serial_core: uart_open
- Original Message - From: Russell King [EMAIL PROTECTED] To: karl malbrain [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] 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: [EMAIL PROTECTED] 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. shD 0006 3036 5341 5252 (NOTLB) d0408eb0 0086 c01c14d7 0006 d0408e94 000f4fa5 c0d38f81 39a0 df461240 df4613cc c035ff00 0246 d0408ecc df461240 c0300e33 0001 df461240 c011c856 c035ff20 c035ff20 d0408000 0001 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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: 2.6.9 chrdev_open: serial_core: uart_open
-Original Message- From: Russell King Sent: Friday, July 15, 2005 1:31 PM To: karl malbrain Cc: [EMAIL PROTECTED] Kernel. Org Subject: Re: 2.6.9 chrdev_open: serial_core: uart_open On Fri, Jul 15, 2005 at 01:11:33PM -0700, karl malbrain wrote: -Original Message- From: Russell King Sent: Friday, July 15, 2005 12:23 AM To: karl malbrain Cc: [EMAIL PROTECTED] Kernel. Org Subject: Re: 2.6.9 chrdev_open: serial_core: uart_open On Thu, Jul 14, 2005 at 04:50:00PM -0700, karl malbrain wrote: chrdev_open issues a lock_kernel() before calling uart_open. It would appear that servicing the blocking open request uart_open goes to sleep with the kernel locked. Would this shut down subsequent access to opening /dev/tty??? No. lock_kernel() is automatically released when a process sleeps. Drilling down between the uart_open and chrdev_open into tty_open is a semaphore tty_sem that is being held during the sleep cycle in uart_open. chrdev_open() calls tty_open(), which then calls init_dev(). init_dev() takes tty_sem, does its stuff, and then releases tty_sem. A little later on, tty_open() calls the uart driver's uart_open() function. So it does this with tty_sem unlocked. On my 2.6.9-11EL source it clearly shows the up(tty_sem) after the call to uart_open. Init_dev never touches tty_sem. karl m - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: 2.6.9 chrdev_open: serial_core: uart_open
-Original Message- From: Russell King Sent: Friday, July 15, 2005 1:59 PM To: karl malbrain Cc: [EMAIL PROTECTED] Kernel. Org Subject: Re: 2.6.9 chrdev_open: serial_core: uart_open On Fri, Jul 15, 2005 at 01:52:15PM -0700, karl malbrain wrote: On my 2.6.9-11EL source it clearly shows the up(tty_sem) after the call to uart_open. Init_dev never touches tty_sem. In which case, I have to say... Congratulations! You've found a bug with Red Hat's Enterprise Linux kernel! Go straight to Red Hat's bugzilla! Do not collect 200$. Do not pass go. Seriously though, this bug is not present in mainline kernels, so I can't resolve this issue for you. Mainline kernels appear to work properly. Could tty_io.c be all that changed by a small set of red-hat patches to 2.6.9? Why would they need to go in there to make so many changes in the first place? Which 2.6 release changed tty_io.c's use of tty_sem so heavily? This conflict between main-line/redhat looks much worse than the unix sysV r4.0 divergence after 3.2. Ouch. Thanks for your help, though. karl m - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: 2.6.9 chrdev_open: serial_core: uart_open
-Original Message- From: Russell King Sent: Friday, July 15, 2005 2:54 PM To: karl malbrain Cc: [EMAIL PROTECTED] Kernel. Org Subject: Re: 2.6.9 chrdev_open: serial_core: uart_open On Fri, Jul 15, 2005 at 02:17:01PM -0700, karl malbrain wrote: -Original Message- From: Russell King Sent: Friday, July 15, 2005 1:59 PM To: karl malbrain Cc: [EMAIL PROTECTED] Kernel. Org Subject: Re: 2.6.9 chrdev_open: serial_core: uart_open On Fri, Jul 15, 2005 at 01:52:15PM -0700, karl malbrain wrote: On my 2.6.9-11EL source it clearly shows the up(tty_sem) after the call to uart_open. Init_dev never touches tty_sem. In which case, I have to say... Congratulations! You've found a bug with Red Hat's Enterprise Linux kernel! Go straight to Red Hat's bugzilla! Do not collect 200$. Do not pass go. Seriously though, this bug is not present in mainline kernels, so I can't resolve this issue for you. Mainline kernels appear to work properly. Could tty_io.c be all that changed by a small set of red-hat patches to 2.6.9? Why would they need to go in there to make so many changes in the first place? Which 2.6 release changed tty_io.c's use of tty_sem so heavily? These are questions to ask of Red Hat, and can only be answered by their representatives. I've since answered part of my question. Red Hat pulled some code-changes from 2.6.10 tty_io.c with the somewhat cryptic comment fix the trivial exploits caused by Rolands controlling tty changes (part 1) and moved the tty_sem ops. Do you know if this would be Roland at Red Hat, or a Roland at lkml? Thanks, karl m - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: 2.6.9 chrdev_open: serial_core: uart_open
chrdev_open issues a lock_kernel() before calling uart_open. It would appear that servicing the blocking open request uart_open goes to sleep with the kernel locked. Would this shut down subsequent access to opening "/dev/tty"??? karl m - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: 2.6.9: serial_core: uart_open
> -Original Message-
> From: Russell King
> Sent: Thursday, July 14, 2005 11:57 AM
> To: karl malbrain
> Cc: [EMAIL PROTECTED] 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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: 2.6.9: serial_core: uart_open
> -Original Message-
> From: Russell King [mailto:[EMAIL PROTECTED] Behalf Of Russell
> King
> Sent: Thursday, July 14, 2005 11:57 AM
> To: karl malbrain
> Cc: [EMAIL PROTECTED] 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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: 2.6.9: serial_core: uart_open
> -Original Message-
> From: Russell King
> Sent: Thursday, July 14, 2005 1:27 AM
> To: karl malbrain
> Cc: [EMAIL PROTECTED] 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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: 2.6.9: serial_core: uart_open
-Original Message- From: Russell King Sent: Thursday, July 14, 2005 1:27 AM To: karl malbrain Cc: [EMAIL PROTECTED] 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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: 2.6.9: serial_core: uart_open
-Original Message- From: Russell King Sent: Thursday, July 14, 2005 11:57 AM To: karl malbrain Cc: [EMAIL PROTECTED] 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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: 2.6.9 chrdev_open: serial_core: uart_open
chrdev_open issues a lock_kernel() before calling uart_open. It would appear that servicing the blocking open request uart_open goes to sleep with the kernel locked. Would this shut down subsequent access to opening /dev/tty??? karl m - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: 2.6.9: serial_core: uart_open
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: [EMAIL PROTECTED] 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...". - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: 2.6.9: serial_core: uart_open
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: [EMAIL PROTECTED] 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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: 2.6.9: serial_core: uart_open
-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(>sem); > schedule(); > down(>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 kernel2.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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: 2.6.9: serial_core: uart_open
>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(>sem);
>>>> schedule();
>>>> down(>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
#include
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 - Stty2 0:00 cat
/dev/ttyS0
> |
> |__ clearly sleeping
>
>0 0 11610 11556 16 0 3656 568 - Rtty3 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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: 2.6.9: serial_core: uart_open
>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(>sem);
>> schedule();
>> down(>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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
2.6.9: serial_core: uart_open
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(>sem);
schedule();
down(>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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: 2.6.9: serial_core: uart_open
-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 kernel2.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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.6.9: serial_core: uart_open
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: 2.6.9: serial_core: uart_open
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: 2.6.9: serial_core: uart_open
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 - Stty2 0:00 cat
/dev/ttyS0
|
|__ clearly sleeping
0 0 11610 11556 16 0 3656 568 - Rtty3 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
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
