Re: Serial related oops



On Tue, Feb 20, 2007 at 01:29:09PM +0000, Frederik Deweerdt wrote:
(Sorry for the resend, I forgot to cc the list)
Hi Russell,

It seems that the following change in drivers/serial/8250.c

+
+ /*
+ * Do a quick test to see if we receive an
+ * interrupt when we enable the TX irq.
+ */
+ serial_outp(up, UART_IER, UART_IER_THRI);
+ lsr = serial_in(up, UART_LSR);
+ iir = serial_in(up, UART_IIR);
+ serial_outp(up, UART_IER, 0);
+
+ if (lsr & UART_LSR_TEMT && iir & UART_IIR_NO_INT) {
+ if (!(up->capabilities & UART_BUG_TXEN)) {
+ up->capabilities |= UART_BUG_TXEN;
+ pr_debug("ttyS%d - enabling bad tx status workarounds\n",
+ port->line);
+ }
+ } else {
+ up->capabilities &= ~UART_BUG_TXEN;
+ }
+

that was introduced in 2.6.12[1], is causing oopses on some hardware. In
particular Jose Goncalves reported[2] an oops in 2.6.16.38 reproducible

I don't see that. The oops your referring to is a NULL pointer
dereference. The only dereferences the above code does is via
'up' and 'port' both of which are provably always non-null here.

I was wondering:
- what is the goal of the test?

To detect UARTs which do not assert an interrupt when the transmit
interrupt is enabled, which then causes no data to ever be transmitted
without this work-around.

- could this be CONFIGed ?

No, it's only runtime because you can't tell which ports might be
affected, and you might have a mixture of ports which are affected
and those which aren't.

PS: CCing Andrew and Zang Roy-r61911 as they seemed to discuss this in
http://lkml.org/lkml/2006/6/13/21

I don't see any reference to this problem there.

--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of:
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/



Relevant Pages

  • Re: Serial related oops
    ... particular Jose Goncalves reportedan oops in 2.6.16.38 reproducible ... To detect UARTs which do not assert an interrupt when the transmit ... it's only runtime because you can't tell which ports might be ...
    (Linux-Kernel)
  • Re: em network issues
    ... >>> interrupt with usb, and yet so far he has been unsuccessful. ... on the em driver on FreeBSD? ... works wonders at exposing race conditions is the Smartbits bi-directional ... Smartbits with gigE ports isn't cheap, but I'd be surprised if Intel ...
    (freebsd-stable)
  • Re: em network issues
    ... interrupt with usb, and yet so far he has been unsuccessful. ... works wonders at exposing race conditions is the Smartbits bi-directional ... it will try to push 2.96 million packets/second through both ports ... Smartbits with gigE ports isn't cheap, but I'd be surprised if Intel ...
    (freebsd-stable)
  • Re: em network issues
    ... interrupt with usb, and yet so far he has been unsuccessful. ... works wonders at exposing race conditions is the Smartbits bi-directional ... Smartbits with gigE ports isn't cheap, but I'd be surprised if Intel ... wpaul@xxxxxxxxxxxxx | Wind River Systems ...
    (freebsd-stable)
  • Re: Cisco switches cable question
    ... Mike Gauthier wrote: ... A 2960 with 40 copper Gb ports, ... cables, but it just makes things more complicated. ... At no time is any pair used for both transmit AND receive. ...
    (comp.dcom.sys.cisco)