ttyS0 not working any more, LSR safety check engaged

ttyS0 not working any more, LSR safety check engaged

[Marc Haber]

Hi,

since a few kernel versions (I unfortunately do not have logs going
back more than two months, 2.6.17.13), the serial port on my hp compaq
nc8000 is not working any more.

The Linux kernel logs "ttyS0: LSR safety check engaged!" whenever I
try to use the port. Googling for this error message suggests that the
port may either not be present or broken. I can confirm that both are
not the case: The port is present and works fine both on Windows and
with an older Knoppix version using a very old 2.6 kernel (I think
2.6.4).

Is it possible that a moderately recent update to the driver is
broken? What can I do to debug? What information do you need?

Greetings
Marc

-- 
-----------------------------------------------------------------------------
Marc Haber         | "I don't trust Computers. They | Mailadresse im Header
Mannheim, Germany  |  lose things."    Winona Ryder | Fon: *49 621 72739834
Nordisch by Nature |  How to make an American Quilt | Fax: *49 621 72739835

Re: ttyS0 not working any more, LSR safety check engaged

[Russell King]

On Sat, Nov 11, 2006 at 12:43:52PM +0100, Marc Haber wrote:
> since a few kernel versions (I unfortunately do not have logs going
> back more than two months, 2.6.17.13), the serial port on my hp compaq
> nc8000 is not working any more.
> 
> The Linux kernel logs "ttyS0: LSR safety check engaged!" whenever I
> try to use the port. Googling for this error message suggests that the
> port may either not be present or broken. I can confirm that both are
> not the case: The port is present and works fine both on Windows and
> with an older Knoppix version using a very old 2.6 kernel (I think
> 2.6.4).
> 
> Is it possible that a moderately recent update to the driver is
> broken? What can I do to debug? What information do you need?

It /does/ mean that the port went away, whether you like it or not.
The hardware was there when it was autoprobed, but when you came to
use it, it had gone.

In other words, something else in the system reconfigured something
which caused the hardware to become inaccessible at the IO address.

Maybe something to do with PNP?  Maybe ACPI?  Both of those I know
nothing about, but I suggest that if you have PNP enabled, you
build and use the 8250_pnp module, even if your port is detected
by the legacy detection methods in 8250.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 Serial core

Re: ttyS0 not working any more, LSR safety check engaged

[Marc Haber]

On Sat, Nov 11, 2006 at 11:50:16AM +0000, Russell King wrote:
> Maybe something to do with PNP?  Maybe ACPI?  Both of those I know
> nothing about, but I suggest that if you have PNP enabled, you
> build and use the 8250_pnp module, even if your port is detected
> by the legacy detection methods in 8250.

How do I configure that?

I have:
  ? ?<*> 8250/16550 and compatible serial support                         ? ?
  ? ?[*]   Console on 8250/16550 and compatible serial port               ? ?
  ? ?<*>   8250/16550 PCI device support                                  ? ?
  ? ?<*>   8250/16550 PNP device support                                  ? ?
  ? ?< >   8250/16550 PCMCIA device support                               ? ?
  ? ?(4)   Maximum number of 8250/16550 serial ports                      ? ?
  ? ?(4)   Number of 8250/16550 serial ports to register at runtime       ? ?
  ? ?[*]   Extended 8250/16550 serial driver options                      ? ?
  ? ?[ ]     Support more than 4 legacy serial ports (NEW)                ? ?
  ? ?[ ]     Support for sharing serial interrupts (NEW)                  ? ?
  ? ?[ ]     Autodetect IRQ on standard ports (unsafe) (NEW)              ? ?
  ? ?[ ]     Support RSA serial ports (NEW)                               

(drivers compiled in since I want to use the serial console without
initrd).

$ grep -i 'nov 11.*\(8250\|serial\|ttyS\|pnp\)' /var/log/syslog/syslog
Nov 11 09:27:41 scyw00225 kernel: pnp: PnP ACPI init
Nov 11 09:27:41 scyw00225 kernel: pnp: PnP ACPI: found 15 devices
Nov 11 09:27:41 scyw00225 kernel: PnPBIOS: Disabled by ACPI PNP
Nov 11 09:27:41 scyw00225 kernel: pnp: 00:0d: ioport range 0x4d0-0x4d1 has been reserved
Nov 11 09:27:41 scyw00225 kernel: pnp: 00:0d: ioport range 0x1000-0x107f could not be reserved
Nov 11 09:27:41 scyw00225 kernel: pnp: 00:0d: ioport range 0x1100-0x113f has been reserved
Nov 11 09:27:41 scyw00225 kernel: pnp: 00:0d: ioport range 0x1200-0x121f has been reserved
Nov 11 09:27:41 scyw00225 kernel: isapnp: Scanning for PnP cards...
Nov 11 09:27:41 scyw00225 kernel: isapnp: No Plug & Play device found
Nov 11 09:27:41 scyw00225 kernel: Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing disabled
Nov 11 09:27:41 scyw00225 kernel: serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
Nov 11 09:27:41 scyw00225 kernel: serial8250: ttyS2 at I/O 0x3e8 (irq = 4) is a 16550A
Nov 11 09:27:41 scyw00225 kernel: 00:02: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
Nov 11 09:27:41 scyw00225 kernel: PNP: PS/2 Controller [PNP0303:C192,PNP0f13:C193] at 0x60,0x64 irq 1,12
Nov 11 09:27:41 scyw00225 kernel: usb usb1: new device strings: Mfr=3, Product=2, SerialNumber=1
Nov 11 09:27:41 scyw00225 kernel: usb usb1: SerialNumber: 0000:00:1d.0
Nov 11 09:27:41 scyw00225 kernel: parport: PnPBIOS parport detected.
Nov 11 09:27:41 scyw00225 kernel: usb usb2: new device strings: Mfr=3, Product=2, SerialNumber=1
Nov 11 09:27:41 scyw00225 kernel: usb usb2: SerialNumber: 0000:00:1d.1
Nov 11 09:27:41 scyw00225 kernel: usb usb3: new device strings: Mfr=3, Product=2, SerialNumber=1
Nov 11 09:27:41 scyw00225 kernel: usb usb3: SerialNumber: 0000:00:1d.2
Nov 11 09:27:41 scyw00225 kernel: usb usb4: new device strings: Mfr=3, Product=2, SerialNumber=1
Nov 11 09:27:41 scyw00225 kernel: usb usb4: SerialNumber: 0000:00:1d.7
Nov 11 09:27:41 scyw00225 kernel: usb 3-1: new device strings: Mfr=1, Product=2, SerialNumber=0
Nov 11 09:27:41 scyw00225 kernel: ieee1394: sbp2: Driver forced to serialize I/O (serialize_io=1)
Nov 11 09:27:41 scyw00225 kernel: ieee1394: sbp2: Try serialize_io=0 for better performance
Nov 11 09:27:47 scyw00225 kernel: ttyS0: LSR safety check engaged!
Nov 11 09:27:48 scyw00225 kernel: ttyS2: LSR safety check engaged!


The port in question is ttyS0.

Greetings
Marc

-- 
-----------------------------------------------------------------------------
Marc Haber         | "I don't trust Computers. They | Mailadresse im Header
Mannheim, Germany  |  lose things."    Winona Ryder | Fon: *49 621 72739834
Nordisch by Nature |  How to make an American Quilt | Fax: *49 621 72739835

Re: ttyS0 not working any more, LSR safety check engaged

[Russell King]

On Sat, Nov 11, 2006 at 01:34:55PM +0100, Marc Haber wrote:
> On Sat, Nov 11, 2006 at 11:50:16AM +0000, Russell King wrote:
> > Maybe something to do with PNP?  Maybe ACPI?  Both of those I know
> > nothing about, but I suggest that if you have PNP enabled, you
> > build and use the 8250_pnp module, even if your port is detected
> > by the legacy detection methods in 8250.
> 
> How do I configure that?
> 
> I have:
>   ? ?<*> 8250/16550 and compatible serial support                         ? ?
>   ? ?[*]   Console on 8250/16550 and compatible serial port               ? ?
>   ? ?<*>   8250/16550 PCI device support                                  ? ?
>   ? ?<*>   8250/16550 PNP device support                                  ? ?

That's fine.

> $ grep -i 'nov 11.*\(8250\|serial\|ttyS\|pnp\)' /var/log/syslog/syslog
> pnp: PnP ACPI init
> pnp: PnP ACPI: found 15 devices
> PnPBIOS: Disabled by ACPI PNP
> pnp: 00:0d: ioport range 0x4d0-0x4d1 has been reserved
> pnp: 00:0d: ioport range 0x1000-0x107f could not be reserved
> pnp: 00:0d: ioport range 0x1100-0x113f has been reserved
> pnp: 00:0d: ioport range 0x1200-0x121f has been reserved
> isapnp: Scanning for PnP cards...
> isapnp: No Plug & Play device found
> Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing disabled
> serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A

ttyS0 detected via legacy ISA probes.

> serial8250: ttyS2 at I/O 0x3e8 (irq = 4) is a 16550A

ttyS2 detected via legacy ISA probes.

> 00:02: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A

ttyS0 detected via PNP device 00:02.

> ttyS0: LSR safety check engaged!
> ttyS2: LSR safety check engaged!

and then it mysteriously disappears on us.

It's certainly a mystery.  Suggest you git bisect to find the offending
change - I doubt it'll be serial/8250 itself.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 Serial core

Re: ttyS0 not working any more, LSR safety check engaged

[Andrew Morton]

On Sat, 11 Nov 2006 15:30:05 +0000
Russell King <rmk+lkml@arm.linux.org.uk> wrote:

> On Sat, Nov 11, 2006 at 01:34:55PM +0100, Marc Haber wrote:
> > On Sat, Nov 11, 2006 at 11:50:16AM +0000, Russell King wrote:
> > > Maybe something to do with PNP?  Maybe ACPI?  Both of those I know
> > > nothing about, but I suggest that if you have PNP enabled, you
> > > build and use the 8250_pnp module, even if your port is detected
> > > by the legacy detection methods in 8250.
> > 
> > How do I configure that?
> > 
> > I have:
> >   ? ?<*> 8250/16550 and compatible serial support                         ? ?
> >   ? ?[*]   Console on 8250/16550 and compatible serial port               ? ?
> >   ? ?<*>   8250/16550 PCI device support                                  ? ?
> >   ? ?<*>   8250/16550 PNP device support                                  ? ?
> 
> That's fine.
> 
> > $ grep -i 'nov 11.*\(8250\|serial\|ttyS\|pnp\)' /var/log/syslog/syslog
> > pnp: PnP ACPI init
> > pnp: PnP ACPI: found 15 devices
> > PnPBIOS: Disabled by ACPI PNP
> > pnp: 00:0d: ioport range 0x4d0-0x4d1 has been reserved
> > pnp: 00:0d: ioport range 0x1000-0x107f could not be reserved
> > pnp: 00:0d: ioport range 0x1100-0x113f has been reserved
> > pnp: 00:0d: ioport range 0x1200-0x121f has been reserved
> > isapnp: Scanning for PnP cards...
> > isapnp: No Plug & Play device found
> > Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing disabled
> > serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
> 
> ttyS0 detected via legacy ISA probes.
> 
> > serial8250: ttyS2 at I/O 0x3e8 (irq = 4) is a 16550A
> 
> ttyS2 detected via legacy ISA probes.
> 
> > 00:02: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
> 
> ttyS0 detected via PNP device 00:02.
> 
> > ttyS0: LSR safety check engaged!
> > ttyS2: LSR safety check engaged!
> 
> and then it mysteriously disappears on us.
> 
> It's certainly a mystery.  Suggest you git bisect to find the offending
> change - I doubt it'll be serial/8250 itself.

/proc/ioports and /proc/iomem might contain hints - can we see those please?

Re: ttyS0 not working any more, LSR safety check engaged

[Russell King]

On Sat, Nov 11, 2006 at 01:06:56PM -0800, Andrew Morton wrote:
> /proc/ioports and /proc/iomem might contain hints - can we see those please?

Only if someone is diddling with the resource system by using
insert_resource().  Serial keeps the port claimed as busy all the
time the port is registered with it.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 Serial core

Re: ttyS0 not working any more, LSR safety check engaged

[Marc Haber]

On Sat, Nov 11, 2006 at 01:06:56PM -0800, Andrew Morton wrote:
> /proc/ioports and /proc/iomem might contain hints - can we see those please?

Sure:
$ cat /proc/ioports
0000-001f : dma1
0020-0021 : pic1
0040-0043 : timer0
0050-0053 : timer1
0060-006f : keyboard
0070-0077 : rtc
0080-008f : dma page reg
00a0-00a1 : pic2
00c0-00df : dma2
00f0-00ff : fpu
0130-0137 : smsc-ircc2
01f0-01f7 : ide0
02f8-02ff : smsc-ircc2
0378-037a : parport0
03c0-03df : vga+
03e8-03ef : serial
03f6-03f6 : ide0
03f8-03ff : serial
04d0-04d1 : pnp 00:0d
0cf8-0cff : PCI conf1
1000-107f : 0000:00:1f.0
  1000-107f : motherboard
    1000-1003 : ACPI PM1a_EVT_BLK
    1004-1005 : ACPI PM1a_CNT_BLK
    1008-100b : ACPI PM_TMR
    1010-1015 : ACPI CPU throttle
    1020-1020 : ACPI PM2_CNT_BLK
    1028-102f : ACPI GPE0_BLK
1100-113f : 0000:00:1f.0
  1100-113f : motherboard
    1100-113f : pnp 00:0d
1200-121f : 0000:00:1f.3
  1200-121f : motherboard
    1200-121f : pnp 00:0d
      1200-121f : i801_smbus
2000-2fff : PCI Bus #01
  2000-20ff : 0000:01:00.0
3000-30ff : 0000:00:1f.5
  3000-30ff : Intel 82801DB-ICH4
3400-34ff : 0000:00:1f.6
  3400-34ff : Intel 82801DB-ICH4 Modem
3800-387f : 0000:00:1f.6
  3800-387f : Intel 82801DB-ICH4 Modem
3880-38bf : 0000:00:1f.5
  3880-38bf : Intel 82801DB-ICH4
38c0-38df : 0000:00:1d.0
  38c0-38df : uhci_hcd
38e0-38ff : 0000:00:1d.1
  38e0-38ff : uhci_hcd
3c00-3c1f : 0000:00:1d.2
  3c00-3c1f : uhci_hcd
3c20-3c2f : 0000:00:1f.1
  3c20-3c27 : ide0
  3c28-3c2f : ide1
4000-5fff : PCI Bus #02
  4000-40ff : PCI CardBus #03
  4400-44ff : PCI CardBus #03
  4800-48ff : PCI CardBus #05
  4c00-4cff : PCI CardBus #05
  5000-50ff : PCI CardBus #09
  5400-54ff : PCI CardBus #09
$ cat /proc/iomem
00000000-0009fbff : System RAM
0009fc00-0009ffff : reserved
000a0000-000bffff : Video RAM area
000c0000-000cffff : Video ROM
000f0000-000fffff : System ROM
00100000-3ffcffff : System RAM
  00100000-0037dada : Kernel code
  0037dadb-003fd087 : Kernel data
3ffd0000-3fff0bff : reserved
3fff0c00-3fffbfff : ACPI Non-volatile Storage
3fffc000-3fffffff : reserved
50000000-56ffffff : PCI Bus #02
  50000000-51ffffff : PCI CardBus #03
  52000000-53ffffff : PCI CardBus #05
  54000000-55ffffff : PCI CardBus #09
  56000000-5600ffff : 0000:02:0e.0
57000000-570003ff : 0000:00:1f.1
58000000-59ffffff : PCI CardBus #03
5a000000-5bffffff : PCI CardBus #05
5c000000-5dffffff : PCI CardBus #09
90000000-903fffff : PCI Bus #02
  90000000-9000ffff : 0000:02:0e.0
    90000000-9000ffff : tg3
  90080000-90083fff : 0000:02:0d.0
  90100000-90100fff : 0000:02:04.0
    90100000-90100fff : ipw2200
  90180000-90180fff : 0000:02:06.0
    90180000-90180fff : yenta_socket
  90200000-90200fff : 0000:02:06.1
    90200000-90200fff : yenta_socket
  90280000-90280fff : 0000:02:06.2
  90300000-90300fff : 0000:02:06.3
    90300000-90300fff : yenta_socket
  90380000-903807ff : 0000:02:0d.0
    90380000-903807ff : ohci1394
90400000-904fffff : PCI Bus #01
  90400000-9040ffff : 0000:01:00.0
  90420000-9043ffff : 0000:01:00.0
98000000-9fffffff : PCI Bus #01
  98000000-9fffffff : 0000:01:00.0
a0000000-a00003ff : 0000:00:1d.7
  a0000000-a00003ff : ehci_hcd
a0100000-a01001ff : 0000:00:1f.5
  a0100000-a01001ff : Intel 82801DB-ICH4
a0180000-a01800ff : 0000:00:1f.5
  a0180000-a01800ff : Intel 82801DB-ICH4
b0000000-bfffffff : 0000:00:00.0
$

I now suspect a user space issue, since the port is there and
functional when I boot with init=/bin/sh. I'll see what udev is doing
with my resources.

Greetings
Marc

-- 
-----------------------------------------------------------------------------
Marc Haber         | "I don't trust Computers. They | Mailadresse im Header
Mannheim, Germany  |  lose things."    Winona Ryder | Fon: *49 621 72739834
Nordisch by Nature |  How to make an American Quilt | Fax: *49 621 72739835

Re: ttyS0 not working any more, LSR safety check engaged

[Marc Haber]

On Sat, Nov 11, 2006 at 12:43:52PM +0100, Marc Haber wrote:
> since a few kernel versions (I unfortunately do not have logs going
> back more than two months, 2.6.17.13), the serial port on my hp compaq
> nc8000 is not working any more.
> 
> The Linux kernel logs "ttyS0: LSR safety check engaged!" whenever I
> try to use the port. Googling for this error message suggests that the
> port may either not be present or broken. I can confirm that both are
> not the case: The port is present and works fine both on Windows and
> with an older Knoppix version using a very old 2.6 kernel (I think
> 2.6.4).
> 
> Is it possible that a moderately recent update to the driver is
> broken?

The issue was udev loading smsc_ircc2. As soon as smsc_ircc2 is
loaded, the serial port shows the behavior listed above. Unloading the
module does not help, a reboot is needed.

I have now solved the issue locally by blacklisting smsc_ircc2 and
hope that I didn't break anything in this process.

Greetings
Marc

-- 
-----------------------------------------------------------------------------
Marc Haber         | "I don't trust Computers. They | Mailadresse im Header
Mannheim, Germany  |  lose things."    Winona Ryder | Fon: *49 621 72739834
Nordisch by Nature |  How to make an American Quilt | Fax: *49 621 72739835