> -----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/
