[RFC] suggested fix for 83xx/85xx PowerPC UART break bug - Kernel

This is a discussion on [RFC] suggested fix for 83xx/85xx PowerPC UART break bug - Kernel ; This is something I'd tripped over earlier, and wanted to follow up on to get an acceptable fix in for everyone's benefit before it falls through the cracks again. There seems to be an issue with recent 83xx/85xx SOC UARTs, ...

+ Reply to Thread
Results 1 to 3 of 3

Thread: [RFC] suggested fix for 83xx/85xx PowerPC UART break bug

  1. [RFC] suggested fix for 83xx/85xx PowerPC UART break bug


    This is something I'd tripped over earlier, and wanted to follow up on
    to get an acceptable fix in for everyone's benefit before it falls through
    the cracks again.

    There seems to be an issue with recent 83xx/85xx SOC UARTs, in which a break
    triggers a short lived IRQ storm (hence killing any hope of using SysRQ).
    The only fix I found to work was to just ignore the bogus events that
    had the associated signature bit set.

    This fix is what I was using against earlier kernels, but I hate to add more
    board/arch specific ifdefs to files like 8250.c, so I'm wondering if
    anyone has any other suggestions before I simply end up cleaning up the
    boardlist (now ppc is dead) and respinning the patch much as it is now
    and resending.

    Thanks,
    Paul.

    -----------------

    Variation/update of version1 of the patch -- orig. discussion at:

    http://patchwork.ozlabs.org/linuxppc/patch?id=15986

    Update is: Don't use MPC8540 as a selector for the 8548 boards,
    since testing on a genuine (older) MPC8540ADS board shows that
    it doesn't have the issue. This will get coverage on the
    sbc8349, fsl_mpc8349_mitx, fsl_mpc832xe (and the similar 8323RDB)
    and the sbc8548 and the fsl_8548cds. (i.e all the boards where
    the problem has been demonstrated to exist so far.)

    Signed-off-by: Paul Gortmaker

    ---
    drivers/serial/8250.c | 17 +++++++++++++++++
    include/linux/serial_reg.h | 1 +
    2 files changed, 18 insertions(+)

    --- a/drivers/serial/8250.c
    +++ b/drivers/serial/8250.c
    @@ -1347,6 +1347,25 @@ serial8250_handle_port(struct uart_8250_

    status = serial_inp(up, UART_LSR);

    +#if defined(CONFIG_MPC834x) || defined(CONFIG_MPC85xx_CDS) || \
    + defined(CONFIG_SBC8548) || defined (CONFIG_PPC_MPC832x)
    + /*
    + * There appears to be a quirk in the implementation on some 8xxx
    + * where after a break is rec'd (UART_LSR_BI), the UART generates
    + * a short duration burst of bogus IRQ events with the signature
    + * of RFE set (along with "normal" bits set) in the LSR.
    + */
    +
    +#define RFE_8xxx_ERR_BITS ( UART_LSR_RFE | UART_LSR_TEMT | \
    + UART_LSR_THRE | UART_LSR_BI | \
    + UART_LSR_DR )
    +
    + if (status == RFE_8xxx_ERR_BITS) {
    + spin_unlock(&up->port.lock);
    + return;
    + }
    +#endif
    +
    DEBUG_INTR("status = %x...", status);

    if (status & UART_LSR_DR) {
    --- a/include/linux/serial_reg.h
    +++ b/include/linux/serial_reg.h
    @@ -109,6 +109,7 @@
    #define UART_MCR_DTR 0x01 /* DTR complement */

    #define UART_LSR 5 /* In: Line Status Register */
    +#define UART_LSR_RFE 0x80 /* Rx FIFO Error (BE, FE, or PE) */
    #define UART_LSR_TEMT 0x40 /* Transmitter empty */
    #define UART_LSR_THRE 0x20 /* Transmit-hold-register empty */
    #define UART_LSR_BI 0x10 /* Break interrupt indicator */

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

  2. Re: [RFC] suggested fix for 83xx/85xx PowerPC UART break bug


    On Jul 31, 2008, at 10:26 AM, Paul Gortmaker wrote:

    >
    > This is something I'd tripped over earlier, and wanted to follow up on
    > to get an acceptable fix in for everyone's benefit before it falls
    > through
    > the cracks again.
    >
    > There seems to be an issue with recent 83xx/85xx SOC UARTs, in which
    > a break
    > triggers a short lived IRQ storm (hence killing any hope of using
    > SysRQ).
    > The only fix I found to work was to just ignore the bogus events that
    > had the associated signature bit set.
    >
    > This fix is what I was using against earlier kernels, but I hate to
    > add more
    > board/arch specific ifdefs to files like 8250.c, so I'm wondering if
    > anyone has any other suggestions before I simply end up cleaning up
    > the
    > boardlist (now ppc is dead) and respinning the patch much as it is now
    > and resending.


    How did you test this or generate it? I was thinking about this the
    other day and figured we need to try and track this down with the HW
    guys. If we can generate a simple test I can try and run it through
    the various boards/parts we have and see which ones show the issue and
    which dont.

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

  3. Re: [RFC] suggested fix for 83xx/85xx PowerPC UART break bug

    On Thu, Jul 31, 2008 at 4:31 PM, Kumar Gala wrote:
    >
    > On Jul 31, 2008, at 10:26 AM, Paul Gortmaker wrote:
    >
    >>
    >> This is something I'd tripped over earlier, and wanted to follow up on
    >> to get an acceptable fix in for everyone's benefit before it falls through
    >> the cracks again.
    >>
    >> There seems to be an issue with recent 83xx/85xx SOC UARTs, in which a
    >> break
    >> triggers a short lived IRQ storm (hence killing any hope of using SysRQ).
    >> The only fix I found to work was to just ignore the bogus events that
    >> had the associated signature bit set.
    >>
    >> This fix is what I was using against earlier kernels, but I hate to add
    >> more
    >> board/arch specific ifdefs to files like 8250.c, so I'm wondering if
    >> anyone has any other suggestions before I simply end up cleaning up the
    >> boardlist (now ppc is dead) and respinning the patch much as it is now
    >> and resending.

    >
    > How did you test this or generate it? I was thinking about this the other
    > day and figured we need to try and track this down with the HW guys. If we
    > can generate a simple test I can try and run it through the various
    > boards/parts we have and see which ones show the issue and which dont.


    Actually, it is dead easy to reproduce. The obvious symptom is that you'll
    get a random complaint that SysRQ doesn't work. You send the break via
    whatever comm program you use, and 9 out of 10 times, you get the SysRQ
    help menu pop up immediately, before you've even entered another character.

    Once you dig a bit deeper, then you see that simply sending the break via
    the comm program (and nothing else) will result in roughly 300 to 2000 events
    as reported via "cat /proc/interrupts" on the UART in question.

    I've tested with at least 5 different boards, with minicom, ckermit and even
    with a commercial digiport in the path, and in all cases it came up the same.

    Paul.

    >
    > - k
    > --
    > To unsubscribe from this list: send the line "unsubscribe linux-serial" in
    > the body of a message to majordomo@vger.kernel.org
    > More majordomo info at http://vger.kernel.org/majordomo-info.html
    >

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

+ Reply to Thread