Date: Mon, 09 Sep 2002 16:44:07 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: Julian Elischer <julian@elischer.org> Cc: hackers@freebsd.org Subject: Re: what does this mean? Message-ID: <3D7D3247.4863F22@mindspring.com> References: <Pine.BSF.4.21.0209091558570.58958-100000@InterJet.elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Julian Elischer wrote: > ANother case of the "obscure beyond belief" > message: > > sio1: configured irq 3 not in bitmap of probed irqs 0 > > what on earth is this trying to tell me? > > WHAT bitmap? In sioprobe(), there is a bitmap assembled from the value of all bits in the 8259 list of current interrupt requests. This bitmap is created by triggering requests, taking a snapshot, and then clearing them, taking another snapshot, and then AND'ing the first snapshot with the bitwise NOT of the second snapshot. This basically guarantees that the interrupt in question was raised by the device being probed, instead of by some other device. During the sioprobe(), it does this, and then calls bus_get_resource(), which returns the IRQ the device is "supposed to" have, according to the bus space code. Then that number is used to shift the value "1" left that many times, and anded with the bitmap from before. If no bits are set, then the message is emitted. What this basically indicates is that you have a device which has probed as present, but which is not where it's supposed to be. A common cause of this, according to a recent discussion, is a non -current system with a PCMCIA card device, or an ACPI based device on -current, running on a laptop, most especially Sony Vaio laptops, which like to jam everything ISA onto IRQ 9. It's also a possible message, if you have a serial port disabled in the BIOS, but the hardware probe finds the hardware there, because the BIOS is merely advisory, and you have not disable "PnP OS" in the BIOS. See i386/isa/intr_machdep.c (for isa_irq_pending()) and isa/sio.c (for sioprobe()). I think the intent of this code is to ensure against conflicts in host assigned resources for things like Mach32 greaphics controllers, which are known to conflict with the I/O space for COM3, etc., but that's just my best guess from past experience with conflicted hardware. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3D7D3247.4863F22>