From owner-freebsd-current@FreeBSD.ORG Mon Jan 5 19:18:41 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B650E16A4CE for ; Mon, 5 Jan 2004 19:18:41 -0800 (PST) Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id A23A943D3F for ; Mon, 5 Jan 2004 19:18:38 -0800 (PST) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.10/8.12.9) with ESMTP id i063IcET044873; Mon, 5 Jan 2004 20:18:38 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Mon, 05 Jan 2004 20:18:23 -0700 (MST) Message-Id: <20040105.201823.01024697.imp@bsdimp.com> To: dwhite@gumbysoft.com From: "M. Warner Losh" In-Reply-To: <20040105181456.L85414@carver.gumbysoft.com> References: <20040105181456.L85414@carver.gumbysoft.com> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: current@freebsd.org Subject: Re: IRQ routing debugging help X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jan 2004 03:18:41 -0000 In message: <20040105181456.L85414@carver.gumbysoft.com> Doug White writes: : I have an IBM xSeries 335 system here that seems to be having interrupt : routing issues. With ACPI enabled the keyboard doesn't work. Without ACPI, : all is happy. : : I have a boot -v output captured from serial console. : : I'd like to learn how to look into these issues so poor jhb isn't stuck : doing this all the time. :) : : So whats the next step? Are you set for fresh goat entrails? How about Eye of Newt? :-) 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: $PIR table at 0x28126c20 version 1.0 PCI interrupt router at 0:15.8 vendor 0x8086 device 0x1234 PCI-only interrupts [ ] entry bus slot device 00: 00 00 31 INTB 61 [ 3 4 5 6 7 9 10 11 12 14 15] INTD 63 [ 3 4 5 6 7 9 10 11 12 14 15] 01: 02 00 03 INTA 61 [ 5 ] 02: 00 00 30 INTA 60 [ 3 4 5 6 7 9 10 11 12 14 15] INTB 61 [ 3 4 5 6 7 9 10 11 12 14 15] INTC 62 [ 3 4 5 6 7 9 10 11 12 14 15] INTD 63 [ 3 4 5 6 7 9 10 11 12 14 15] 03: 01 00 00 INTA 60 [ 3 4 5 6 7 9 10 11 12 14 15] 04: 02 00 06 INTA 63 [ 3 4 5 6 7 9 10 11 12 14 15] INTB 62 [ 3 4 5 6 7 9 10 11 12 14 15] 05: 08 00 00 INTA 63 [ 3 4 5 6 7 9 10 11 12 14 15] 06: 08 00 01 INTA 63 [ 3 4 5 6 7 9 10 11 12 14 15] 07: 02 00 15 INTA 63 [ 3 4 5 6 7 9 10 11 12 14 15] 08: 02 00 08 INTA 62 [ 3 4 5 6 7 9 10 11 12 14 15] 09: 02 00 12 INTA 62 [ 3 4 5 6 7 9 10 11 12 14 15] Link number ---------------^^ The link number is best thought of as 'wire number'. As you'd expect, all the INTx pins with the same link number are wire OR'd together. This means that if Entry #8's (pci2:8) INTA pin is wired to IRQ 10, then entry 9's INTA pin is also. Next, you'll need to find the ACPI table (I don't have one handy since bootverbose goes nuts with ata1 not finding anything, again and again). If you are lucky, they will match and be consistant. However, if they are consistant, you'll likely not be having problems. 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 Warner