Fwd: Re: kern/122683: Accessing /dev/cuaa0 causes system to freeze

[Bruce Evans]

On Tue, 15 Apr 2008, Volker Werth wrote:

> does
> not have a serial port.  I ran an application from another machine which
> accessed /dev/cuad0.
> I can reproduce the problem with echo "asdf" > /dev/cuad0

Don't do that then :-).

This is a default misconfiguration.  /boot/device.hints is normally a
copy of /sys/i386/conf/GENERIC.hints, so it forces sio0 to exist by
specifying that sio0 is a console.  Bad things then happen if you
try to access sio0 when sio0 doesn't in fact exist.

> # dmesg
> sio0: configured irq 4 not in bitmap of probed irqs 0
> sio0: port may not be enabled
> sio0: irq maps: 0xeb9 0xeb9 0xeb9 0xeb9
> sio0: probe failed test(s): 0 1 2 4 6 7 9
> sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0
> sio0: type 8250 or not responding

This says that sio0 doesn't exist.  It only says indirectly that sio0 is
forced to exist (flags 0x10 and the missing "failed to probe" message say
this).

> ioapic0: routing intpin 4 (ISA IRQ 4) to vector 58
> sio1: configured irq 3 not in bitmap of probed irqs 0
> sio1: port may not be enabled
> sio1: irq maps: 0xeb9 0xeb9 0xeb9 0xeb9
> sio1: probe failed test(s): 0 1 2 4 6 7 9
> sio1 failed to probe at port 0x2f8-0x2ff irq 3 on isa0

This says that sio1 doesn't exist.  It only says indirectly that sio1 is
not forced to exist (the missing "flags 0" message and the present "failed
to probe" message say this).

The other messages give rather confusing details about the non-existence:
- "port may not be enabled" is poor wording for "port might not be enabled".
   This means that the port doesn't seem to exist, and its nonexistence might
   be due to disabling it in the BIOS.  It doesn't mean that neither you nor
   the probe is permitted to enable it.  This failure is not fatal, but should
   be (except for the force).
- "configured irq N not in bitmap..." means that the probe for the interrupt
   failed.  This error is not fatal, since sometimes it is just the
   interrupt probe that fails, and even if interrupts don't work then
   the port is supposed to be usable in polled mode (but I think polled
   mode is broken).  The interrupt probe has not been updated to understand
   anything except the ATPIC (via isa_irq_pending()), so it only works by
   magic on non-old systems with APICs (apparently irq4 on APIC is shadowed
   by irq4 on ATPIC, so the probe still works in most cases).
- "irq maps" gives information useful for debugging failures to probe for
   the interrupt.
- failure of any of the tests is fatal (except for the force).  Failures to
   probe the IRQ number (tests 3, 5 and 8) are not counted here, but tests 1,
   4, 6, 7 and 9 check for interrupts working internally to the device.  Only
   tests 0 and 2 are unrelated to interrupts.  Normally when the device
   doesn't exist, all tests fail and the message says
   "failed test(s): 0 1 2 4 6 7 9" as above since "0 1 2 4 6 7 9" is all
   tests except the 3 interrupt probe ones not counted here.

Bruce