Weird PCI interrupt delivery problem (resolution, sort of)
scottl at samsco.org
Thu Jan 19 21:17:45 PST 2006
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 = 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.
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.
More information about the freebsd-hackers