Date: Thu, 19 Jan 2006 22:17:39 -0700 From: Scott Long <scottl@samsco.org> To: Craig Boston <craig@tobuj.gank.org> Cc: freebsd-hackers@freebsd.org Subject: Re: Weird PCI interrupt delivery problem (resolution, sort of) Message-ID: <43D07273.6030804@samsco.org> In-Reply-To: <20060120014307.GA3118@nowhere> References: <20060120014307.GA3118@nowhere>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?43D07273.6030804>