RE: [PATCH] i386 io_apic.c: Memorize at bootup where the i8259 is connected

["Andy Currid" <ACurrid@nvidia.com>]

> -----Original Message-----
> From: linux-kernel-owner@vger.kernel.org 
> [mailto:linux-kernel-owner@vger.kernel.org] 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 majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/