From: Steven Rostedt Try running the attached program on the machine that deadlocked (it is the one with the buggy uart). Without the patch, the serial_test will miss a wake up, and then be stuck in the sleeping TASK_INTERRUPTIBLE state (at least you can still kill it). With the patch, it runs fine. I ran the program with the following parameters: # ./serial_test /dev/ttyS0 115200 8 0 0 4 (Disclaimer: I did not write this serial_test. It was hacked up by my customer to show me that this bug exists). This may also be a bug with the vanilla kernel, since I don't see why it is not. I'll run more tests on the vanilla kernel, and if it too misses a wake up, I'll submit this to vanilla as well. Some 8250 uarts don't zero out the NO_INTERRUPT bit of the IIR register on transmit empty interrupts. If this happens, then the interrupt handler won't process any transmits that are waiting, and we can have processes stuck waiting to transmit over the serial. This patch has the interrupt process the transmits regardless if the interrupt handler didn't already handle the transmits, and the uart was previously (on setup) detected to be buggy. Signed-off-by: Steven Rostedt Signed-off-by: Ingo Molnar Cc: Russell King Signed-off-by: Andrew Morton --- drivers/serial/8250.c | 8 ++++++++ 1 files changed, 8 insertions(+) diff -puN drivers/serial/8250.c~fix-for-serial-uart-lockup drivers/serial/8250.c --- devel/drivers/serial/8250.c~fix-for-serial-uart-lockup 2006-05-11 15:18:10.000000000 -0700 +++ devel-akpm/drivers/serial/8250.c 2006-05-11 15:18:10.000000000 -0700 @@ -1366,6 +1366,14 @@ static irqreturn_t serial8250_interrupt( "irq%d\n", irq); break; } + /* + * If we have a buggy TX line, that doesn't + * notify us via iir that we need to transmit + * then force the call. + */ + if (!handled && (up->bugs & UART_BUG_TXEN)) + serial8250_handle_port(up, regs); + } while (l != end); spin_unlock(&i->lock); _