Hang in uart_block_til_ready()

Hang in uart_block_til_ready()

[Michael Hanselmann]

[-- Attachment #1: Type: text/plain, Size: 1583 bytes --]

Hello Russell

I've discovered a problem where I'm not sure wether it's an error in the
kernel or in the hardware.

The hardware I'm using for the serial console is a HP Lights-Out 100
Management. It provides a (virtual) serial port which then can be used
for remote administration over the network and is available as ttyS2 in
Linux. I'm using it for a serial console.

When doing open("/dev/ttyS2", O_RDWR) from userland, like it's done by
screen(1) and by my test program, the kernel "hangs" in the schedule()
call in the function uart_block_til_ready of serial_core.c.

The patch below fixes it, but I'm not sure wether it is the correct way,
nor if it might create other problems.

The problem was reproducable with 2.6.15.6, 2.6.16 and 2.6.16-git20 (all
vanilla). I've not been able to reproduce it on another box where the
serial console is on ttyS0 and done by a common 16550A-compatible chip.

Do you or somebody else have an idea what's going on here and how to fix
it correctly?

Thanks,
Michael

---
--- linux-2.6.16-hardened/drivers/serial/serial_core.c.orig	2006-04-02 15:07:43.000000000 +0200
+++ linux-2.6.16-hardened/drivers/serial/serial_core.c	2006-04-02 15:24:52.000000000 +0200
@@ -1456,6 +1456,10 @@ uart_block_til_ready(struct file *filp, 
 			break;
 		}
 
+		/* hansmi: fixes a hang on open("/dev/ttyS2", O_RDWR) for me */
+		if (uart_console(port) && (port->cons->flags & CON_ENABLED))
+			break;
+
 		/*
 		 * Set DTR to allow modem to know we're waiting.  Do
 		 * not set RTS here - we want to make sure we catch

[-- Attachment #2: Type: application/pgp-signature, Size: 191 bytes --]

Re: Hang in uart_block_til_ready()

[Russell King]

On Sun, Apr 02, 2006 at 03:51:38PM +0200, Michael Hanselmann wrote:
> I've discovered a problem where I'm not sure wether it's an error in the
> kernel or in the hardware.

It's neither - it's a bug in your test program.  If you want "callout"
semantics, open the port using O_NONBLOCK mode.

If you don't open the port using O_NONBLOCK then the port will wait for
the DCD line (or virtual DCD line) to be asserted by the hardware before
exiting uart_block_til_ready().  This is used for gettys on UARTs so
they don't display the login banner until someone connects to the port.

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

Re: Hang in uart_block_til_ready()

[Michael Hanselmann]

[-- Attachment #1: Type: text/plain, Size: 1204 bytes --]

Hello Russell

On Sun, Apr 02, 2006 at 03:38:27PM +0100, Russell King wrote:
> On Sun, Apr 02, 2006 at 03:51:38PM +0200, Michael Hanselmann wrote:
> > I've discovered a problem where I'm not sure wether it's an error in the
> > kernel or in the hardware.

> It's neither - it's a bug in your test program.  If you want "callout"
> semantics, open the port using O_NONBLOCK mode.

I've now patched screen(1) and it works, but one thing is amazing me.
The other computer I wrote about has the serial console on ttyS0 and
starting screen(1) on the serial console works. Here's the relevant
strace part:

screen-strace:open("/dev/ttyS0", O_RDWR|O_NONBLOCK) = 3
screen-strace.23801:open("/dev/ttyS0", O_RDWR) = 3

This doesn't work on the HP box with the serial console on ttyS2. After
adding O_NONBLOCK, it works. Here's the strace:

screen-strace:open("/dev/ttyS2", O_RDWR|O_NONBLOCK) = 3
screen-strace.31830:open("/dev/ttyS2", O_RDWR|O_NONBLOCK) = 3

Am I going correct that this is a bug in screen(1) and it only works on
the first box by some mysterious reason? Mabye some timing issue?

Thanks,
Michael

-- 
Gentoo Linux developer, http://hansmi.ch/, http://forkbomb.ch/

[-- Attachment #2: Type: application/pgp-signature, Size: 191 bytes --]

Re: Hang in uart_block_til_ready()

[Russell King]

On Sun, Apr 02, 2006 at 05:17:39PM +0200, Michael Hanselmann wrote:
> Hello Russell
> 
> On Sun, Apr 02, 2006 at 03:38:27PM +0100, Russell King wrote:
> > On Sun, Apr 02, 2006 at 03:51:38PM +0200, Michael Hanselmann wrote:
> > > I've discovered a problem where I'm not sure wether it's an error in the
> > > kernel or in the hardware.
> 
> > It's neither - it's a bug in your test program.  If you want "callout"
> > semantics, open the port using O_NONBLOCK mode.
> 
> I've now patched screen(1) and it works, but one thing is amazing me.
> The other computer I wrote about has the serial console on ttyS0 and
> starting screen(1) on the serial console works. Here's the relevant
> strace part:

Have you checked the state of the DCD line in both cases?  Look in
/proc/tty/driver/serial.

> Am I going correct that this is a bug in screen(1) and it only works on
> the first box by some mysterious reason? Mabye some timing issue?

Probably "works" on the first box because it happens to have DCD asserted
on the real serial port.

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

Re: Hang in uart_block_til_ready()

[Michael Hanselmann]

[-- Attachment #1: Type: text/plain, Size: 759 bytes --]

On Sun, Apr 02, 2006 at 04:23:50PM +0100, Russell King wrote:
> Have you checked the state of the DCD line in both cases?  Look in
> /proc/tty/driver/serial.

HP box:
2: uart:16550A port:000003E8 irq:4 tx:12888 rx:147 RTS|CTS|DTR|DSR

other box:
0: uart:16550A port:000003F8 irq:4 tx:18886 rx:299 RTS|CTS|DTR|DSR|CD

So, yes. The other box has CD set (unless CD is not DCD). It might be
that the serial cable used there does this, but I can't check it because
the box is several hundreds of kilometers away.

> Probably "works" on the first box because it happens to have DCD asserted
> on the real serial port.

Yes, that explains it.

Thanks for your help,
Michael

-- 
Gentoo Linux developer, http://hansmi.ch/, http://forkbomb.ch/

[-- Attachment #2: Type: application/pgp-signature, Size: 191 bytes --]