From: vb on 24 Feb 2010 20:50 I saw this issue mentioned in the past (http://lkml.indiana.edu/hypermail/linux/kernel/0612.3/0756.html) but there has been no resolution. I also started experiencing this problem recently, it happens on a dual uart powerpc CPU when one of the ports is used by getty and its input is held in active state all the time, (apparently generating continuous UART breaks). It looks like getty gets tired of the junk it sees on the channel and shuts the port down. Soon after that I see this message reporting a dangling IRQ. I investigated a bit, what happens is that the second port (which was shut down on getty restart) asserts the IRQ, but the ISR (8250.c:serial8250_interrupt()) does not look at the second port's state, as the port is now unlinked from the list of active ports. The ISR reports the interrupt not handled. Now, why does the port assert the IRQ? This is because of the following code in serial_core.c:uart_close(): uart_shutdown(state); uart_flush_buffer(tty); tty_ldisc_flush(tty); uart_shutdown() disables ports interrupts and takes it out of the list, uart_flush_buffer() returns right away on a port which is down, uart_ldisc_flush() however doesn't mind. It goes like this: [ee0b1c70] [c01848bc] serial8250_start_tx+0x2c/0x268 [ee0b1ca0] [c017a8e4] uart_send_xchar+0xb4/0xd4 [ee0b1cd0] [c017ec04] uart_unthrottle+0x80/0x144 [ee0b1d10] [c01754d0] tty_unthrottle+0x64/0x80 [ee0b1d20] [c0173ca4] reset_buffer_flags+0xb4/0xe8 [ee0b1d40] [c0173cf0] n_tty_flush_buffer+0x18/0x88 [ee0b1d60] [c01777d8] tty_ldisc_flush+0x3c/0x60 [ee0b1d70] [c017d850] uart_close+0x1ec/0x2d0 [ee0b1da0] [c01712dc] tty_release_dev+0x168/0x4f4 [ee0b1e40] [c0171688] tty_release+0x20/0x3c [ee0b1e60] [c009c020] __fput+0x70/0x168 [ee0b1e80] [c0098884] filp_close+0x60/0x94 [ee0b1ea0] [c003d488] put_files_struct+0xf4/0x110 [ee0b1ec0] [c003f1a0] do_exit+0x560/0x5e8 [ee0b1f10] [c003f270] do_group_exit+0x48/0xac [ee0b1f30] [c003f2e8] sys_exit_group+0x14/0x28 [ee0b1f40] [c000f9a0] ret_from_syscall+0x0/0x3c where 8250.c:serial8250_start_tx() reenables transmit interrupt of the channel which was excluded from interrupt processing. what would be a proper fix here - should serial_core.c:uart_unthrottle() be modified not to attempt sending a character on the disabled tty? cheers, vadim -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Alan Cox on 25 Feb 2010 08:10 > what would be a proper fix here - should > serial_core.c:uart_unthrottle() be modified not to attempt sending a > character on the disabled tty? n_tty should not be calling the in the buffer flush handling when it is closed. Known bug. It needs to reset the flags but shouldn't be restarting I/O from that path. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|
Pages: 1 Prev: perf trace/scripting: add perf-trace-python Documentation Next: 2010 Award Promotion |