Date: Tue, 6 Jan 2004 11:13:35 -0800 (PST) From: Doug White <dwhite@gumbysoft.com> To: "M. Warner Losh" <imp@bsdimp.com> Cc: current@freebsd.org Subject: Re: IRQ routing debugging help Message-ID: <20040106111031.S95008@carver.gumbysoft.com> In-Reply-To: <20040105.201823.01024697.imp@bsdimp.com> References: <20040105181456.L85414@carver.gumbysoft.com> <20040105.201823.01024697.imp@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 5 Jan 2004, M. Warner Losh wrote: > : So whats the next step? > > Are you set for fresh goat entrails? How about Eye of Newt? :-) I've got the rubber gloves and bleach handy :) > The next step is to find the $PIR table. This will give you one set > of information. Here's a sample PIR table, the format may be a little > different than what I've presented here: How do you find this? This system doesn't appear to have one; it doesn't show up in boot -v with either SMP or UP kernels, with or without apic. > If an interrupt works under non-ACPI, then you can use something like > hw.acpi.pci.link.%d.%d.%d.irq to route it. First %d busno, then %d > slot and the last %d is pin. A is 0, B is 1, etc. If non-ACPI works, > then you you can power through things by doing something like > > hw.acpi.pci.link.2.12.0.irq=11 > hw.acpi.pci.link.2.15.0.irq=5 I guess I have a bad example. The affected component on this system, the keyboard, is an ISA interrupt. Comparing ACPI and non-ACPI boots, the main difference is in the final apic programming. In Non-ACPI, it looks like this: ioapic1: routing intpin 2 (IRQ 18) to cluster 0 ioapic1: routing intpin 8 (IRQ 24) to cluster 0 ioapic1: routing intpin 9 (IRQ 25) to cluster 0 ioapic0: routing intpin 1 (IRQ 1) to cluster 0 ioapic0: routing intpin 4 (IRQ 4) to cluster 0 ioapic0: routing intpin 6 (IRQ 6) to cluster 0 ioapic0: routing intpin 8 (IRQ 8) to cluster 0 ioapic0: routing intpin 11 (IRQ 11) to cluster 0 ioapic0: routing intpin 13 (IRQ 13) to cluster 0 ioapic0: routing intpin 14 (IRQ 14) to cluster 0 ioapic0: routing intpin 15 (IRQ 15) to cluster 0 In ACPI, the intpin 1 line is missing: ioapic1: routing intpin 2 (IRQ 18) to cluster 0 ioapic1: routing intpin 8 (IRQ 24) to cluster 0 ioapic1: routing intpin 9 (IRQ 25) to cluster 0 ioapic0: routing intpin 4 (IRQ 4) to cluster 0 ioapic0: routing intpin 6 (IRQ 6) to cluster 0 ioapic0: routing intpin 7 (IRQ 7) to cluster 0 ioapic0: routing intpin 8 (IRQ 8) to cluster 0 ioapic0: routing intpin 11 (IRQ 11) to cluster 0 ioapic0: routing intpin 13 (IRQ 13) to cluster 0 ioapic0: routing intpin 14 (IRQ 14) to cluster 0 ioapic0: routing intpin 15 (IRQ 15) to cluster 0 So there's something specifically funky with IRQ 1 in the ACPI case. I'll extract the DSDT and take a poke around. -- Doug White | FreeBSD: The Power to Serve dwhite@gumbysoft.com | www.FreeBSD.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040106111031.S95008>