RE: [PATCH] i386 io_apic.c: Memorize at bootup where the i8259 is connected
From: Andy Currid
Date: Fri Jul 29 2005 - 16:13:31 EST
> -----Original Message-----
> From: linux-kernel-owner@xxxxxxxxxxxxxxx
> [mailto:linux-kernel-owner@xxxxxxxxxxxxxxx] On Behalf Of
> Linus Torvalds
> Sent: Friday, July 29, 2005 13:09
> To: Eric W. Biederman
> Cc: Andrew Morton; linux-kernel@xxxxxxxxxxxxxxx
> Subject: Re: [PATCH] i386 io_apic.c: Memorize at bootup where
> the i8259 is connected
> On Fri, 29 Jul 2005, Eric W. Biederman wrote:
> > Since the acpi MADT table does not provide the location
> where the i8259
> > is connected we have to look at the hardware to figure it out.
> I'm not really happy with this.
> First off, it kind of assumes that extINT is always the 8259.
> Maybe that's true, maybe it's not.
Since this code is the i386 architecture branch, I think it's safe to
assume that ExtINT always emanates from something that is 8259A
compatible. The Intel APIC / IOAPIC and MP specifications which govern
this architecture are quite specific on this point. The same is true for
> Maybe there is hardware out there that has a
> specialty interrupt controller that also uses extInt?
> Secondly, why always
> just on IO-APIC 0? This would make a lot more sense to do inside the
> loop-over-apics in enable_IO_APIC, no?
Agreed. Any IO-APIC is fair game for virtual wire routing.
> Especially since that one already calculates the number of
> entries, and
> does it a lot more nicely than you do.. (ie no shifting and
> masking with
> magic constants).
> Finally, the third issue I have is that _if_ the MP table is correct,
> we'll never know. Wouldn't it be better to query the MP table
> and see if it agrees with what we found, and if it doesn't,
> at least print
> a message so that it is easier to debug things if sh*t happens?
MP tables on IA32 / AMD64 systems are frequently wrong when it comes to
interrupt mappings. That's an indirect consequence of Microsoft
mandating ACPI since 2000: system vendors tend to test the hell out of
that configuration and nothing else.
But I think it's a good idea to cross check as Linus suggests, and
notify the user of any discrepancy. After all, the only *guaranteed* way
to get back into virtual wire mode on a platform is to do a reset; the
original MP spec didn't envisage supporting this mode of operation.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/