On 26/09/07 14:20 -0700, H. Peter Anvin wrote:
> Testing this patch now:
>
> >From 2efa33f81ef56e7700c09a3d8a881c96692149e5 Mon Sep 17 00:00:00 2001
> From: H. Peter Anvin <[EMAIL PROTECTED]>
> Date: Wed, 26 Sep 2007 14:11:43 -0700
> Subject: [PATCH] [x86 setup] Handle case of improperly
Jordan Crouse wrote:
>
> Hmm - the old code seems to fail to e801 when CF was set too:
>
> int $0x15 # make the call
> jc bail820 # fall to e801 if it fails
>
> cmpl$SMAP, %eax # check the
On 26/09/07 14:04 -0700, H. Peter Anvin wrote:
> Jordan Crouse wrote:
> > On 26/09/07 12:14 -0700, H. Peter Anvin wrote:
> >> Please try the following debug patch to let us know what is going on.
> >>
> >>-hpa
> >
> >> diff --git a/arch/i386/boot/memory.c b/arch/i386/boot/memory.c
> >> index
Jordan Crouse wrote:
> On 26/09/07 12:14 -0700, H. Peter Anvin wrote:
>> Please try the following debug patch to let us know what is going on.
>>
>> -hpa
>
>> diff --git a/arch/i386/boot/memory.c b/arch/i386/boot/memory.c
>> index 1a2e62d..a0ccf29 100644
>> --- a/arch/i386/boot/memory.c
>>
On 26/09/07 12:14 -0700, H. Peter Anvin wrote:
> Please try the following debug patch to let us know what is going on.
>
> -hpa
> diff --git a/arch/i386/boot/memory.c b/arch/i386/boot/memory.c
> index 1a2e62d..a0ccf29 100644
> --- a/arch/i386/boot/memory.c
> +++ b/arch/i386/boot/memory.c
>
Jordan Crouse wrote:
>
> Its the latter - max_pfn as read by find_max_pfn() in arch/i386/e820.c
> is being set to 9F (640k) in the broken case, this due to the
> the e820 map looking something like this:
>
> Address Size Type
> 0009FC00 1
> 0009FC00 0400 2
> 000E
Jordan Crouse wrote:
>
> As background, I'm using syslinux 3.36 as my loader here - I've used this
> exact same version for a very long time, so I don't blame it in the least.
> Something is getting confused in the early kernel, and whatever that
> something is, a still unknown change in a newer
On 26/09/07 07:10 -0700, H. Peter Anvin wrote:
> Joerg Pommnitz wrote:
> > Hello all,
> > this is what git bisect told me about the problem:
> >
> > [EMAIL PROTECTED]:~/linux-2.6$ git bisect good
> > 4fd06960f120e02e9abc802a09f9511c400042a5 is first bad commit
> > commit
> There is something very fishy.
>
> The only documentation you've given us so far is a screen shot which
> contained a message ("BIOS data check successful") which doesn't occur
> in the kernel.
>
> The loader string doesn't look all that familiar either; it looks like
> an extremely old
Joerg Pommnitz wrote:
> Hello all,
> this is what git bisect told me about the problem:
>
> [EMAIL PROTECTED]:~/linux-2.6$ git bisect good
> 4fd06960f120e02e9abc802a09f9511c400042a5 is first bad commit
> commit 4fd06960f120e02e9abc802a09f9511c400042a5
> Author: H. Peter Anvin <[EMAIL PROTECTED]>
Hello all,
this is what git bisect told me about the problem:
[EMAIL PROTECTED]:~/linux-2.6$ git bisect good
4fd06960f120e02e9abc802a09f9511c400042a5 is first bad commit
commit 4fd06960f120e02e9abc802a09f9511c400042a5
Author: H. Peter Anvin <[EMAIL PROTECTED]>
Date: Wed Jul 11 12:18:56 2007
Hello all,
this is what git bisect told me about the problem:
[EMAIL PROTECTED]:~/linux-2.6$ git bisect good
4fd06960f120e02e9abc802a09f9511c400042a5 is first bad commit
commit 4fd06960f120e02e9abc802a09f9511c400042a5
Author: H. Peter Anvin [EMAIL PROTECTED]
Date: Wed Jul 11 12:18:56 2007 -0700
Joerg Pommnitz wrote:
Hello all,
this is what git bisect told me about the problem:
[EMAIL PROTECTED]:~/linux-2.6$ git bisect good
4fd06960f120e02e9abc802a09f9511c400042a5 is first bad commit
commit 4fd06960f120e02e9abc802a09f9511c400042a5
Author: H. Peter Anvin [EMAIL PROTECTED]
Date:
There is something very fishy.
The only documentation you've given us so far is a screen shot which
contained a message (BIOS data check successful) which doesn't occur
in the kernel.
The loader string doesn't look all that familiar either; it looks like
an extremely old version
On 26/09/07 07:10 -0700, H. Peter Anvin wrote:
Joerg Pommnitz wrote:
Hello all,
this is what git bisect told me about the problem:
[EMAIL PROTECTED]:~/linux-2.6$ git bisect good
4fd06960f120e02e9abc802a09f9511c400042a5 is first bad commit
commit
Jordan Crouse wrote:
As background, I'm using syslinux 3.36 as my loader here - I've used this
exact same version for a very long time, so I don't blame it in the least.
Something is getting confused in the early kernel, and whatever that
something is, a still unknown change in a newer
Jordan Crouse wrote:
Its the latter - max_pfn as read by find_max_pfn() in arch/i386/e820.c
is being set to 9F (640k) in the broken case, this due to the
the e820 map looking something like this:
Address Size Type
0009FC00 1
0009FC00 0400 2
000E 2000 2
On 26/09/07 12:14 -0700, H. Peter Anvin wrote:
Please try the following debug patch to let us know what is going on.
-hpa
diff --git a/arch/i386/boot/memory.c b/arch/i386/boot/memory.c
index 1a2e62d..a0ccf29 100644
--- a/arch/i386/boot/memory.c
+++ b/arch/i386/boot/memory.c
@@
Jordan Crouse wrote:
On 26/09/07 12:14 -0700, H. Peter Anvin wrote:
Please try the following debug patch to let us know what is going on.
-hpa
diff --git a/arch/i386/boot/memory.c b/arch/i386/boot/memory.c
index 1a2e62d..a0ccf29 100644
--- a/arch/i386/boot/memory.c
+++
On 26/09/07 14:04 -0700, H. Peter Anvin wrote:
Jordan Crouse wrote:
On 26/09/07 12:14 -0700, H. Peter Anvin wrote:
Please try the following debug patch to let us know what is going on.
-hpa
diff --git a/arch/i386/boot/memory.c b/arch/i386/boot/memory.c
index 1a2e62d..a0ccf29
Jordan Crouse wrote:
Hmm - the old code seems to fail to e801 when CF was set too:
int $0x15 # make the call
jc bail820 # fall to e801 if it fails
cmpl$SMAP, %eax # check the return is
On 26/09/07 14:20 -0700, H. Peter Anvin wrote:
Testing this patch now:
From 2efa33f81ef56e7700c09a3d8a881c96692149e5 Mon Sep 17 00:00:00 2001
From: H. Peter Anvin [EMAIL PROTECTED]
Date: Wed, 26 Sep 2007 14:11:43 -0700
Subject: [PATCH] [x86 setup] Handle case of improperly terminated E820
22 matches
Mail list logo
