Weird PCI interrupt delivery problem (resolution, sort of)

[Scott Long]

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