Thanks Ted,
I did all of your following suggestions, and increase udelay from 1000
to 10000.
tytso@mit.edu writes:
> 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:
> Experiment number #1. Comment out the entire block of code above.
> Experiment number #2. Put the above code back, and after it, add a
> udelay(1000) call. Try varying values of udelay()
> Experiment number #3. Remove the udelay() call, and comment out the
> first two serial_outp(info, UART_FCR, ...) calls.
But, unfortunately there are no differences observed. There are LSR
messages around the ppp connection and opening the TTY fails.
One thing that I'm going to try, is logging ALL of inb/outb
activity in the kernel regarding 0x2f8-0x3ff.
It is rather easy if I change the definition of inb/outb.
I wonder that some other part of the kernel (not serial.c) may give
bad influences to the modem, such as ISA PnP or others..
Because, the first few responses in the syslogs are significantly
different between 2.3.16 and 2.3.39, which suggests that the modem
states are different at the time of serial line initialization.
The other experiment is chasing the kernel version which cause the
change between 2.3.16 to 2.3.39. This may help to know what is the
cause of malfunction.
If I have some gain from the experiment, I'll report again.
-- Computer Systems Laboratory, Fujitsu Labs. kumon@flab.fujitsu.co.jp- 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:10 EST