> -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of > Linus Torvalds > Sent: Friday, July 29, 2005 13:09 > To: Eric W. Biederman > Cc: Andrew Morton; linux-kernel@vger.kernel.org > 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 x86_64. > 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 > regardless, > 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. Andy -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/