[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.022 / U:11.464 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site