Date: Mon, 5 Dec 2005 19:51:29 -0600 From: Craig Boston <craig@tobuj.gank.org> To: freebsd-hackers@freebsd.org Subject: Re: Weird PCI interrupt delivery problem Message-ID: <20051206015129.GA34415@nowhere> In-Reply-To: <20051204004131.GA7596@nowhere> References: <20051130020734.GA6577@nowhere> <200512020817.55769.jhb@freebsd.org> <20051203005104.GA22567@nowhere> <200512031630.59476.jhb@freebsd.org> <20051204004131.GA7596@nowhere>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Dec 03, 2005 at 06:41:31PM -0600, Craig Boston wrote: > I'll keep hacking on it and follow up here if I figure anything out. Following up, I have made some interesting progress. With the ACPI timer disabled (debug.acpi.disabled=timer), the ACPI+APIC case now behaves the same as the plain APIC case. Each IRQ gets anywhere from 10,000-500,000 interrupts before it simply stops working. Switching the timecounter from ACPI-fast to something else after boot also improves the situation, but not as much as disabling the timer entirely. Up to about 50,000 but better than the <50 it would get otherwise. Switching the timecounter does not bring back any IRQs that have already "died". Disabling the timer does not change the +ACPI -APIC case, but I've been experimenting with that mode of operation and discovered it's not quite as it fist appeared. It's difficult to tell which device is producing interrupts since they all go to IRQ 11. I didn't notice before, but with +ACPI -APIC, the USB controller works fine (indefinitely). Also, I'm not 100% sure, but I don't think the devices on pci9 are producing _ANY_ interrupts at all. With the APIC enabled, rl0 sometimes lasts long enough to get a lease, but with it disabled it has yet to manage that. Also, the irq 11 count looks too low for multiple devices. I compared the entire PCI configuration space for the bridge with ACPI enabled and disabled and they were identical. The only thing that struck me as suspect is that the secondary status register for the bridge has the received master abort bit set, however that happens even when things are working so I'm not sure it's relevant. I get the same results after "fixing" the _PRT for bus 9. I tried both hardcoding the interrupts to 0xb and routing them via various link devices -- no luck. That's all really academic; I suspect ACPI+APIC is the only configuration that has a chance of actually working, and I'm halfway there... Craig
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20051206015129.GA34415>