[lkml]   [2000]   [Feb]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: 2.3.39 ISA modem is not recognized
   From: <>
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

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

* 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 |
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
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:56    [W:0.052 / U:1.360 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site