Hi Nicolas, Thanks for the report. On 02/09/2015 08:34 AM, Nicolas Schichan wrote: > On 09/10/2014 09:29 PM, Sebastian Andrzej Siewior wrote: >> The serial8250_do_startup() function unconditionally clears the >> interrupts and for that it reads from the RX-FIFO without checking if >> there is a byte in the FIFO or not. This works fine on OMAP4+ HW like >> AM335x or DRA7. >> OMAP3630 ES1.1 (which means probably all OMAP3 and earlier) does not like >> this: > > Hello, > > Sorry to wake up an old thread, but I'm affraid that this patch causes > problems on Marvell 88f6282 (Kirkwood). > > When a caracter is received on the UART while the kernel is printing > the boot messages, as soon as the kernel configures the UART for > receiving (after root filesystem mount), it gets stuck printing the > following message repeatedly: > > serial8250: too much work for irq29 > > Once stuck, the reception of another character allows the boot process > to finish. > > From what I can gather, when we hit that, the UART_IIR_NO_INT is 0 (so the > interrupt is raised), but the UART_LSR_DR bit is 0 as well so the UART_RX > register is never read to clear the interrupt. The "too much work" message means serial8250_handle_irq() is returning 0, ie., not handled. Which in turn means IIR indicates no interrupt is pending (UART_IIR_NO_INT == 1). Can you log the register values for LSR and IIR at both patch locations in serial8250_do_startup()? (I can get you a debug patch, if necessary. Let me know) Regards, Peter Hurley > We are using the second UART multiplexed on mpps 15 and 16. > > Reverting this particular patch fixes the issue. > > We are seing the problem on a 3.18 kernel. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
