Date: Thu, 19 Jan 2006 19:43:07 -0600 From: Craig Boston <craig@tobuj.gank.org> To: freebsd-hackers@freebsd.org Subject: Weird PCI interrupt delivery problem (resolution, sort of) Message-ID: <20060120014307.GA3118@nowhere>
next in thread | raw e-mail | index | archive | help
After trying everything I could think of to do to the I/O APIC code and
coming up empty, tonight I went back to the local APIC. I had
previously ruled it out since the lapic timer interrupt continued to
work fine even when the others stopped. However, adding some DELAY(1)
calls at key points caused it to work, much like adding WITNESS does.
I managed to get it down to a single change that makes APIC mode work on
this laptop:
--- local_apic.c.orig Thu Jan 19 18:32:37 2006
+++ local_apic.c Thu Jan 19 18:32:28 2006
@@ -599,4 +599,5 @@
lapic_eoi(void)
{
lapic->eoi = 0;
+ lapic->eoi = 0;
}
...and welcome to bizarro world. There's absolutely no reason I can
think of why that would change anything, other than buggy hardware.
I looked at what Linux was doing, and they're also using a single write
to EOI interrupts, so long as the X86_GOOD_APIC config option is enabled
(and it is for P5/MMX or newer). Otherwise it does an extra read before
writing to any APIC register. I don't know if linux works on this
hardware or not -- the live CD I tried wasn't compiled for APIC support.
At this point, since AFAIK nobody else has reported the same problem,
I'm content with a local workaround. It's just... wierd.
Craig
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060120014307.GA3118>