Date: Wed, 16 Apr 2008 10:41:36 +1000 (EST) From: Bruce Evans <brde@optusnet.com.au> To: Volker Werth <vwe@freebsd.org> Cc: freebsd-bugs@freebsd.org Subject: Re: Fwd: Re: kern/122683: Accessing /dev/cuaa0 causes system to freeze Message-ID: <20080416100126.H43595@delplex.bde.org> In-Reply-To: <200804151900.m3FJ09g5062701@freefall.freebsd.org> References: <200804151900.m3FJ09g5062701@freefall.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080416100126.H43595>