Date: Fri, 2 Dec 2005 08:17:53 -0500 From: John Baldwin <jhb@freebsd.org> To: Craig Boston <craig@tobuj.gank.org> Cc: freebsd-hackers@freebsd.org, imp@freebsd.org Subject: Re: Weird PCI interrupt delivery problem Message-ID: <200512020817.55769.jhb@freebsd.org> In-Reply-To: <20051202013146.GA15424@nowhere> References: <20051130020734.GA6577@nowhere> <200512011342.19417.jhb@freebsd.org> <20051202013146.GA15424@nowhere>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <jhb@FreeBSD.org> =A0<>< =A0http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" =A0=3D =A0http://www.FreeBSD.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200512020817.55769.jhb>