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

[ebiederm@xmission.com (Eric W. Biederman)]

Linus Torvalds <torvalds@osdl.org> writes:

> 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. Maybe there is hardware out there that has a
> specialty interrupt controller that also uses extInt? 

I believe the definition of extInt is that it is an external
interrupt controller that sends interrupts like an 8259.

So it might be possible but it would be an extreme hardware.
And it would be an old hardware configuration because acpi
doesn't even allow you to setup that kind of thing.

> Secondly, why always just on IO-APIC 0? 

Good question the assumption was already in the code, but
it isn't hard to lift.

> This would make a lot more sense to do inside the
> loop-over-apics in enable_IO_APIC, no?

Probably.  It has to come before the call to clear_IO_APIC().
I was just be extra careful about that.

> 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?

The reason I generated the patch is because reading the acpi
tables is the default no one is even using the MP table anymore.
The acpi MADT table can't represent the notion of an a pin
in ExtInt mode.  Even in the MP table has the information is pretty
much advisory as the OS doesn't use it except on very old systems.

The practical question is which is the better route.  Save
off all of the entries in the apic and ioapic and restore
them on reboot, or simply save off which pin the i8259 is
talking through and restore one pin in ExtInt mode.  I like
the latter because we have enough information that we can
and if there is a weird system we can specify it with a command
line parameter.  But the save/restore approach may be more general,
and less prone to coder error.

Eric

-
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/