It will effect 3com modem cards, at least the Gateway branded telebit I have,
maybe others when they are at the COM4, ttyS3 position.
The SVGA server and SuperProbe both outl() into 0x42ec which hits
the ttyS3 sitting at 0x2e8-0x2ef.
In 2.3.28 this cripples the card causing an eventual overflow error, but
the machine survives.
In 2.3.29-33 the machine goes into an infinite loop in an interrupt handler.
In serial.c, in receive_chars(), near the top there is escape logic
to handle the case where the uart overruns the tty flip buffer...
In 2.3.28 we have...
if (tty->flip.count >= TTY_FLIPBUF_SIZE)
break;
In 2.3.29+ we have...
if (tty->flip.count >= TTY_FLIPBUF_SIZE)
goto ignore_char;
... which stays inside the enclosing loop.
After the card is clobbered the normal exit condition, uart line status
register data ready bit clears, will never occur. The UART_LSR remains
stuck at 0x61 and the input data sticks at 0x00.
By changing the logic back to the 'break' the machine survives, but
the serial device now continues to flop around in various error states
until closed.
Possible solutions would be...
1) get everyone on the planet to have a new X probing stategy
that knows the serial port is out there and leaves it alone. :-)
2) detect the clobbering in the driver, send an error to the user space
program using the serial device, and close the device.
3) reinitialize the uart after the clobbering and continue.
3 sounds complicated and will probably leave little windows where
characters could be dropped. That seems a poor choice.
I like 2, but don't know how to get the serial device into a defined
error state. I can detect the clobbering, but don't know what to do
next.
Ideas?
--
Jim Studt
The Federated Software Group, Inc.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/