Re: 2.6.18-mm1

From: Aaron Durbin
Date: Wed Sep 27 2006 - 18:06:44 EST

On 9/27/06, Eric W. Biederman <ebiederm@xxxxxxxxxxxx> wrote:
Andi Kleen <ak@xxxxxxx> writes:

> On Wednesday 27 September 2006 09:39, Eric W. Biederman wrote:
>> Andi Kleen <ak@xxxxxxx> writes:
>> > On Wednesday 27 September 2006 04:04, Eric W. Biederman wrote:
>> >>
>> >> When I apply:
>> >> x86_64-mm-insert-ioapics-and-local-apic-into-resource-map
>> >>
>> >> My e1000 fails to initializes and complains about a bad eeprom checksum.
>> >> I haven't tracked this down to root cause yet and I am in the process of
>> > building
>> >> 2.6.18-mm1 with just that patch reverted to confirm that is the only cause.
>> >
>> > Is this with Linux BIOS?
>> Yes. Not that it matters in this case.
> Well Linus BIOS is known to play very fast-and-lose regarding supplying
> correct BIOS tables.

Agreed it does tend to push the envelop of what is allowed, and doesn't
try to work around OS bugs. Which does tend to expose things.

> Perhaps it conflicts with a broken e820 map?

No. Did you not get the other part of the discussion?

The reservation was wrong because those IOAPICs were on ordinary pci
devices. So the two reservations for the same resource conflicted,
so the pci allocator tried to move the pci device.

The problem is totally contained within the patch under discussion.

The role LinuxBIOS plays seems to be that it is atypical to enable
ioapics as ordinary pci devices.



I agree that clearing the IORESOURCE_BUSY flag would not alleviate
this problem. Could you please post the output of 'lspci -vvvvx' so
we could better understand the layout of your box? Perhaps I might
have to defer the registration of the resources until later. It seems
weird that the IO APIC are mapped in as PCI devices though.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at