On Friday, 28 September 2007 02:12, H. Peter Anvin wrote:
> Jordan Crouse wrote:
> >
> > Worked, but that just raises more questions. Why didn't more x86 boxes
> > break or, alternatively, why did a new version of the BIOS fix the problem?
> > I guess we shouldn't look a gift horse in the
<[EMAIL PROTECTED]>
An: H. Peter Anvin <[EMAIL PROTECTED]>
CC: [EMAIL PROTECTED]; Joerg Pommnitz <[EMAIL PROTECTED]>; Chuck Ebbert <[EMAIL
PROTECTED]>; Linux Kernel Mailing List ; Andi
Kleen <[EMAIL PROTECTED]>
Gesendet: Freitag, den 28. September 2007, 01:15:52 Uhr
Bet
E820 brokenness
On 27/09/07 15:47 -0700, H. Peter Anvin wrote:
Jordan Crouse wrote:
Breaks on the Geode - original behavior.
I think that having boot_prams.e820_entries != 0 makes the kernel
assume the e820 data is correct.
Okay, now I'm utterly baffled how 2.6.22 ever worked
On Friday, 28 September 2007 02:12, H. Peter Anvin wrote:
Jordan Crouse wrote:
Worked, but that just raises more questions. Why didn't more x86 boxes
break or, alternatively, why did a new version of the BIOS fix the problem?
I guess we shouldn't look a gift horse in the mouth. Or
Jordan Crouse wrote:
>
> Worked, but that just raises more questions. Why didn't more x86 boxes
> break or, alternatively, why did a new version of the BIOS fix the problem?
> I guess we shouldn't look a gift horse in the mouth. Or something.
>
Why didn't more x86 boxes break... well, it's
On 27/09/07 16:36 -0700, H. Peter Anvin wrote:
> Jordan Crouse wrote:
> >>>
> >> Oh bugger, looks like this one might be genuinely my fault after all.
> >> The ID check in the new code is buggy.
> >>
> >> Can you please test this revised patch out (against current -git)?
> >
> >
> > That looks
Jordan Crouse wrote:
>>>
>> Oh bugger, looks like this one might be genuinely my fault after all.
>> The ID check in the new code is buggy.
>>
>> Can you please test this revised patch out (against current -git)?
>
>
> That looks the same as the previous patch you sent?
>
Sorry, this is the
On 27/09/07 16:27 -0700, H. Peter Anvin wrote:
> Jordan Crouse wrote:
> > On 27/09/07 15:47 -0700, H. Peter Anvin wrote:
> >> Jordan Crouse wrote:
> >>> Breaks on the Geode - original behavior.
> >>>
> >>> I think that having boot_prams.e820_entries != 0 makes the kernel
> >>> assume the e820 data
Jordan Crouse wrote:
> On 27/09/07 15:47 -0700, H. Peter Anvin wrote:
>> Jordan Crouse wrote:
>>> Breaks on the Geode - original behavior.
>>>
>>> I think that having boot_prams.e820_entries != 0 makes the kernel
>>> assume the e820 data is correct.
>>>
>> Okay, now I'm utterly baffled how 2.6.22
Jordan Crouse wrote:
>
> I copied in a 2.6.22 kernel to see that it really did work, and it did.
> But here's the crazy part - I did a dmesg, and it looks like it
> *is* using e820 data, and it looks complete (I see the entire map -
> including the ACPI and reserved blocks way up high).
>
> So
On 27/09/07 15:47 -0700, H. Peter Anvin wrote:
> Jordan Crouse wrote:
> >
> > Breaks on the Geode - original behavior.
> >
> > I think that having boot_prams.e820_entries != 0 makes the kernel
> > assume the e820 data is correct.
> >
>
> Okay, now I'm utterly baffled how 2.6.22 ever worked on
Jordan Crouse wrote:
>
> Breaks on the Geode - original behavior.
>
> I think that having boot_prams.e820_entries != 0 makes the kernel
> assume the e820 data is correct.
>
Okay, now I'm utterly baffled how 2.6.22 ever worked on this Geode,
because this, to the best of my reading, mimics the
On 27/09/07 15:17 -0700, H. Peter Anvin wrote:
> As luck would have it, it's not just an obscure Geode system which has a
> broken E820 implementation. Today I received a bug report about a Dell
> system (XPS M1330) with broken E820.
>
> Unfortunately, the workaround for the Geode breaks this
As luck would have it, it's not just an obscure Geode system which has a
broken E820 implementation. Today I received a bug report about a Dell
system (XPS M1330) with broken E820.
Unfortunately, the workaround for the Geode breaks this system, because
x86-64 doesn't fall back to the e801/88
As luck would have it, it's not just an obscure Geode system which has a
broken E820 implementation. Today I received a bug report about a Dell
system (XPS M1330) with broken E820.
Unfortunately, the workaround for the Geode breaks this system, because
x86-64 doesn't fall back to the e801/88
Jordan Crouse wrote:
I copied in a 2.6.22 kernel to see that it really did work, and it did.
But here's the crazy part - I did a dmesg, and it looks like it
*is* using e820 data, and it looks complete (I see the entire map -
including the ACPI and reserved blocks way up high).
So
On 27/09/07 15:47 -0700, H. Peter Anvin wrote:
Jordan Crouse wrote:
Breaks on the Geode - original behavior.
I think that having boot_prams.e820_entries != 0 makes the kernel
assume the e820 data is correct.
Okay, now I'm utterly baffled how 2.6.22 ever worked on this Geode,
Jordan Crouse wrote:
On 27/09/07 15:47 -0700, H. Peter Anvin wrote:
Jordan Crouse wrote:
Breaks on the Geode - original behavior.
I think that having boot_prams.e820_entries != 0 makes the kernel
assume the e820 data is correct.
Okay, now I'm utterly baffled how 2.6.22 ever worked on this
Jordan Crouse wrote:
Breaks on the Geode - original behavior.
I think that having boot_prams.e820_entries != 0 makes the kernel
assume the e820 data is correct.
Okay, now I'm utterly baffled how 2.6.22 ever worked on this Geode,
because this, to the best of my reading, mimics the 2.6.22
On 27/09/07 15:17 -0700, H. Peter Anvin wrote:
As luck would have it, it's not just an obscure Geode system which has a
broken E820 implementation. Today I received a bug report about a Dell
system (XPS M1330) with broken E820.
Unfortunately, the workaround for the Geode breaks this system,
On 27/09/07 16:27 -0700, H. Peter Anvin wrote:
Jordan Crouse wrote:
On 27/09/07 15:47 -0700, H. Peter Anvin wrote:
Jordan Crouse wrote:
Breaks on the Geode - original behavior.
I think that having boot_prams.e820_entries != 0 makes the kernel
assume the e820 data is correct.
Okay,
Jordan Crouse wrote:
Oh bugger, looks like this one might be genuinely my fault after all.
The ID check in the new code is buggy.
Can you please test this revised patch out (against current -git)?
That looks the same as the previous patch you sent?
Sorry, this is the right one...
On 27/09/07 16:36 -0700, H. Peter Anvin wrote:
Jordan Crouse wrote:
Oh bugger, looks like this one might be genuinely my fault after all.
The ID check in the new code is buggy.
Can you please test this revised patch out (against current -git)?
That looks the same as the previous
Jordan Crouse wrote:
Worked, but that just raises more questions. Why didn't more x86 boxes
break or, alternatively, why did a new version of the BIOS fix the problem?
I guess we shouldn't look a gift horse in the mouth. Or something.
Why didn't more x86 boxes break... well, it's pretty
24 matches
Mail list logo
