RE: 2.6.9: serial_core: uart_open

["karl malbrain" <karl@petzent.com>]

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...".






-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/