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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



 

> -----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; [email protected]
> 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/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]
  Powered by Linux