Messages in this thread | | | From | "karl malbrain" <> | Subject | RE: 2.6.9: serial_core: uart_open | Date | Wed, 13 Jul 2005 10:53:19 -0700 |
| |
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/
| |