From owner-freebsd-hackers@FreeBSD.ORG Fri Dec 2 13:25:17 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 87E7016A41F; Fri, 2 Dec 2005 13:25:17 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from speedfactory.net (mail6.speedfactory.net [66.23.216.219]) by mx1.FreeBSD.org (Postfix) with ESMTP id CF04743D5A; Fri, 2 Dec 2005 13:25:05 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (unverified [66.23.211.162]) by speedfactory.net (SurgeMail 3.5b3) with ESMTP id 3006823 for multiple; Fri, 02 Dec 2005 08:23:03 -0500 Received: from zion.baldwin.cx (zion.baldwin.cx [192.168.0.7]) (authenticated bits=0) by server.baldwin.cx (8.13.1/8.13.1) with ESMTP id jB2DOvod002243; Fri, 2 Dec 2005 08:24:59 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: Craig Boston Date: Fri, 2 Dec 2005 08:17:53 -0500 User-Agent: KMail/1.8.3 References: <20051130020734.GA6577@nowhere> <200512011342.19417.jhb@freebsd.org> <20051202013146.GA15424@nowhere> In-Reply-To: <20051202013146.GA15424@nowhere> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200512020817.55769.jhb@freebsd.org> X-Spam-Status: No, score=-2.8 required=4.2 tests=ALL_TRUSTED autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on server.baldwin.cx X-Server: High Performance Mail Server - http://surgemail.com r=1653887525 Cc: freebsd-hackers@freebsd.org, imp@freebsd.org Subject: Re: Weird PCI interrupt delivery problem X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Dec 2005 13:25:17 -0000 On Thursday 01 December 2005 08:31 pm, Craig Boston wrote: > On Thu, Dec 01, 2005 at 01:42:18PM -0500, John Baldwin wrote: > > Yeah, odd, no $PIR. You can get your cbb0 to work though using a tunab= le > > in the loader. Something like: > > > > hw.pci9.1.INTA.irq=3D11 > > That does fix cbb0. With that line, the cardbus works in plain-old-PIC > mode. Ok. > > For a test, you can try compiling cbb out of your kernel and seeing if > > the box works ok. > > No luck, still fails exactly the same in ACPI mode with cbb removed from > the kernel. Grrr. > > You could also try moving one of the links to IRQ 10 in the ACPI case > > via a tunable such as: > > > > hw.acpi.LNKA.irq=3D10 or some such (can't recall if that's the right > > name). > > Looks like it's hw.pci.link.LNKA.irq. However, there are a couple > problems: > > 1. The ASL for this machine expects to be notified of the interrupt > model via the _PIC method. It changes the _PRT depending on which model > is in use. For APIC, it doesn't use the PCI link objects at all and > just hardcodes all the vectors. For PIC, it uses the LNK objects (which > are constrained to IRQ 10 or 11). That's normal. > If I'm reading the code correctly, it appears that we call _PIC and set > the interrupt model to APIC, *if an MADT table exists*, regardless if > we're actually using the I/O APIC or not. This is what initially had me > thinking ACPI/PIC wasn't supported at all. If an MADT exists we do use the APIC and don't use ATPICs. That's normal. > 2. I "solved" the previous problem by modifying the ASL to assume PIC > mode, and then the tunables started working. It was only able to move > devices on the "near" side of the bridge (i.e. on pci0), but they did > work briefly on IRQ 10 before freezing just as before. You shouldn't have to do that. The ACPI standard clearly states that machi= nes=20 boot up in PIC mode by default and you only need to call _PIC to switch to= =20 either APIC or SAPIC (ia64) mode. Did you disable APIC before trying the=20 tunables BTW? > I think this is unrelated to my problem, however, as I get the same > behavior both with and without that modification (but it may be a bug > that needs to be fixed). > > Argh, this is driving me up the wall. I had a hunch that it was somehow > connected to level-triggered interrupts. That seems to not be the case, > as upon closer inspection the SCI interrupt (9) gets reprogrammed to > level/low. I can read the ACPI status all day long and the count for > IRQ 9 goes up and up without freezing... Interesting. How about IRQ 11 in non-APIC mode, is it programmed to=20 level/low? I've seen BIOSes that do very stupid things like have the link= =20 devices set to level/hi or edge/lo or even edge/hi. A verbose boot should= =20 tell you if any settings are changed though, and in the APIC case you shoul= d=20 see the initial defaults as well. =2D-=20 John Baldwin =A0<>< =A0http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" =A0=3D =A0http://www.FreeBSD.org