Re: Weird PCI interrupt delivery problem (resolution, sort of)

Scott Long <scottl@xxxxxxxxxx> · Thu, 19 Jan 2006 22:17:39 -0700

Craig Boston wrote:
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


This points to a bus coherency problem.  I wonder if your BIOS is
incorrectly setting the memory region of the apics as cachable.  You'll
want to bug Baldwin about this.
Scott
_______________________________________________
freebsd-hackers@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@xxxxxxxxxxx"

Re: Weird PCI interrupt delivery problem (resolution, sort of)

Relevant Pages