From: <kumon@flab.fujitsu.co.jp>
Date: Sat, 29 Jan 2000 17:25:14 +0900
The log size is not so large, I attached syslog of both 2.3.16 and
2.3.39 with inb/outb printk in serial.c. Please be carefull that only
serial.c has been modified to produce syslog with printk(). The
following file contains two files, each containing the syslog listing
from the start of the booting to the the ppp invocation.
Actually, in 2.3.39, inbs from ttyS1 returns 0xff. But even in 2.3.16
there are some LSR warnings exist on /dev/ttyS0 (not a ttyS1).
Yeah, I see them in both 2.3.16 and 2.3.39 syslogs. Your Supra Fax
modem is definitely doing something weird. (But that's standard for PC
hardware....)
Jan 29 16:49:39 matx kernel: outb(0x2fa)<-01
Jan 29 16:49:39 matx kernel: outb(0x2fa)<-07
Jan 29 16:49:39 matx kernel: outb(0x2fa)<-00
Jan 29 16:49:39 matx kernel: inb(0x2fd)=ff
Jan 29 16:49:39 matx kernel: inb(0x2f8)=ff
Jan 29 16:49:39 matx kernel: inb(0x2fa)=ff
Jan 29 16:49:39 matx kernel: inb(0x2fe)=ff
Jan 29 16:49:39 matx kernel: inb(0x2fd)=ff
Jan 29 16:49:39 matx kernel: LSR safety check engaged!
My guess is that something --- and I'll guess that it was clearing the
FIFO's --- caused the board is going "insane" temporarily, so that all
reads to the port are returning 0xff. So, could you try a couple of
experiments, all of them relating to the following code in the serial
driver:
/*
* Clear the FIFO buffers and disable them
* (they will be reenabled in change_speed())
*/
if (uart_config[state->type].flags & UART_CLEAR_FIFO) {
serial_outp(info, UART_FCR, UART_FCR_ENABLE_FIFO);
serial_outp(info, UART_FCR, (UART_FCR_ENABLE_FIFO |
UART_FCR_CLEAR_RCVR |
UART_FCR_CLEAR_XMIT));
serial_outp(info, UART_FCR, 0);
}
Experiment number #1. Comment out the entire block of code above. Does
this make the problem go away? (i.e., does the LSR safety check message
go away?)
Experiment number #2. Put the above code back, and after it, add a
udelay(1000) call. Try varying values of udelay(), to see if it makes
the problem go away?
Experiment number #3. Remove the udelay() call, and comment out the
first two serial_outp(info, UART_FCR, ...) calls. Does that make the
problem go away?
The hardware is clearly doing something bogus, but if we can figure out
a way to work around the problem, that would be good.
- Ted
-
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/
This archive was generated by hypermail 2b29 : Mon Feb 07 2000 - 21:00:08 EST