Date: Thu, 1 Dec 2005 19:31:46 -0600 From: Craig Boston <craig@tobuj.gank.org> To: John Baldwin <jhb@freebsd.org> Cc: freebsd-hackers@freebsd.org, imp@freebsd.org Subject: Re: Weird PCI interrupt delivery problem Message-ID: <20051202013146.GA15424@nowhere> In-Reply-To: <200512011342.19417.jhb@freebsd.org> References: <20051130020734.GA6577@nowhere> <200511301035.14284.jhb@freebsd.org> <20051130172303.GA57453@nowhere> <200512011342.19417.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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 tunable in > the loader. Something like: > > hw.pci9.1.INTA.irq=11 That does fix cbb0. With that line, the cardbus works in plain-old-PIC mode. I suspect that really old 16-bit PCMCIA cards with non-sharable interrupts wouldn't work, but does NEWCARD even support those anyway? > should do the trick to get your box working in the !ACPI and !APIC case at > least and you can see if it has the same issue with freezing up then. So far it seems to be working fine with !ACPI !APIC and that tunable. I'm pingflooding some "volunteers" on the wired and wireless LANs, and transferring 16MB/s from an external drive over firewire (cardbus fwohci). So far it's been running for about 30 minutes with a sustained interrupt rate of ~6000. That would be more than enough to kill it in the plain APIC (no ACPI) case. Still, this thing doesn't have apm so if I want any sort of power management I'll need to figure out why ACPI & APIC are broken. > 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. > That's cbb0 and it has no address assigned to BAR 0x10 (nor an IRQ). Unfortunately the BIOS is no help here either -- the only thing configurable is the boot order... > I'd still be interested to hear how the broken kernels fair if you > take cbb out and how the 8259 kernel does with the variable set to fix > cbb0's interrupt. All 3 (broken) combinations of ACPI and APIC behave exactly the same with cbb/pccard/cardbus removed from the kernel. :( > 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=10 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). 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. 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. 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... Craig
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20051202013146.GA15424>