[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <m1hcyto112.fsf@ebiederm.dsl.xmission.com>
Date: Wed, 27 Sep 2006 08:08:09 -0600
From: ebiederm@...ssion.com (Eric W. Biederman)
To: Andi Kleen <ak@...e.de>
Cc: Andrew Morton <akpm@...l.org>, linux-kernel@...r.kernel.org,
adurbin@...gle.com
Subject: Re: 2.6.18-mm1
Andi Kleen <ak@...e.de> writes:
> On Wednesday 27 September 2006 09:39, Eric W. Biederman wrote:
>> Andi Kleen <ak@...e.de> 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.
Eric
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists