While trying to put together a new kernel for my laptop (Dell I5150, as
in subject) I found that recent kernels just don't boot. Right after
grub loads the kernel, before the "Uncompressing Linux" message is
shown, it hangs. The BIOS appears to still be alive (ctrl-alt-del works,
keyboard lock LEDs respond). It seems to be caused by the new x86 setup
code.
My kernel is Linus' git as of a1c582d0720f2eff61043e90711767decf37b917.
I bisected and confirmed that 4fd06960f120e02e9abc802a09f9511c400042a5
triggers a non-functioning boot.
This system has Dell BIOS rev A38 and a P4 3.2 w/HT.
What should I do next to debug this problem?
Will Simoneau wrote:
> While trying to put together a new kernel for my laptop (Dell I5150, as
> in subject) I found that recent kernels just don't boot. Right after
> grub loads the kernel, before the "Uncompressing Linux" message is
> shown, it hangs. The BIOS appears to still be alive (ctrl-alt-del works,
> keyboard lock LEDs respond). It seems to be caused by the new x86 setup
> code.
>
> My kernel is Linus' git as of a1c582d0720f2eff61043e90711767decf37b917.
> I bisected and confirmed that 4fd06960f120e02e9abc802a09f9511c400042a5
> triggers a non-functioning boot.
>
> This system has Dell BIOS rev A38 and a P4 3.2 w/HT.
>
> What should I do next to debug this problem?
Can you put in some printf's in the code and see how far it gets?
-hpa
H. Peter Anvin wrote:
> Will Simoneau wrote:
>> While trying to put together a new kernel for my laptop (Dell I5150, as
>> in subject) I found that recent kernels just don't boot. Right after
>> grub loads the kernel, before the "Uncompressing Linux" message is
>> shown, it hangs. The BIOS appears to still be alive (ctrl-alt-del works,
>> keyboard lock LEDs respond). It seems to be caused by the new x86 setup
>> code.
>>
>> My kernel is Linus' git as of a1c582d0720f2eff61043e90711767decf37b917.
>> I bisected and confirmed that 4fd06960f120e02e9abc802a09f9511c400042a5
>> triggers a non-functioning boot.
>>
>> This system has Dell BIOS rev A38 and a P4 3.2 w/HT.
>>
>> What should I do next to debug this problem?
>
> Can you put in some printf's in the code and see how far it gets?
>
Specifically, the places to add printf's are to main() in main.c and
go_to_protected_mode() in pm.c.
-hpa
On 23:41 Thu 30 Aug , H. Peter Anvin wrote:
> H. Peter Anvin wrote:
>> Will Simoneau wrote:
>>> While trying to put together a new kernel for my laptop (Dell I5150, as
>>> in subject) I found that recent kernels just don't boot. Right after
>>> grub loads the kernel, before the "Uncompressing Linux" message is
>>> shown, it hangs. The BIOS appears to still be alive (ctrl-alt-del works,
>>> keyboard lock LEDs respond). It seems to be caused by the new x86 setup
>>> code.
>>>
>>> My kernel is Linus' git as of a1c582d0720f2eff61043e90711767decf37b917.
>>> I bisected and confirmed that 4fd06960f120e02e9abc802a09f9511c400042a5
>>> triggers a non-functioning boot.
>>>
>>> This system has Dell BIOS rev A38 and a P4 3.2 w/HT.
>>>
>>> What should I do next to debug this problem?
>> Can you put in some printf's in the code and see how far it gets?
>
> Specifically, the places to add printf's are to main() in main.c and
> go_to_protected_mode() in pm.c.
>
> -hpa
It dies in vesa_probe() right after calling int10 with ax=4f01 and
checking the return status, which was 0x004f (success). This happens on
the third iteration of the loop; the first two modes it finds are
framebuffer modes. This would be just after line 72 in video-vesa.c .
I have CONFIG_VIDEO_VESA=y and CONFIG_FB=y, but am not passing the
kernel options that would use vesafb as the console.
On 11:05 Fri 31 Aug , Will Simoneau wrote:
> On 23:41 Thu 30 Aug , H. Peter Anvin wrote:
> > H. Peter Anvin wrote:
> >> Will Simoneau wrote:
> >>> While trying to put together a new kernel for my laptop (Dell I5150, as
> >>> in subject) I found that recent kernels just don't boot. Right after
> >>> grub loads the kernel, before the "Uncompressing Linux" message is
> >>> shown, it hangs. The BIOS appears to still be alive (ctrl-alt-del works,
> >>> keyboard lock LEDs respond). It seems to be caused by the new x86 setup
> >>> code.
> >>>
> >>> My kernel is Linus' git as of a1c582d0720f2eff61043e90711767decf37b917.
> >>> I bisected and confirmed that 4fd06960f120e02e9abc802a09f9511c400042a5
> >>> triggers a non-functioning boot.
> >>>
> >>> This system has Dell BIOS rev A38 and a P4 3.2 w/HT.
> >>>
> >>> What should I do next to debug this problem?
> >> Can you put in some printf's in the code and see how far it gets?
> >
> > Specifically, the places to add printf's are to main() in main.c and
> > go_to_protected_mode() in pm.c.
> >
> > -hpa
>
> It dies in vesa_probe() right after calling int10 with ax=4f01 and
> checking the return status, which was 0x004f (success). This happens on
> the third iteration of the loop; the first two modes it finds are
> framebuffer modes. This would be just after line 72 in video-vesa.c .
>
> I have CONFIG_VIDEO_VESA=y and CONFIG_FB=y, but am not passing the
> kernel options that would use vesafb as the console.
Apparently some VESA BIOS implementations clobber our registers when called.
Tell gcc about it.
This makes my Dell Inspiron 5150 boot correctly instead of hanging.
Signed-off-by: Will Simoneau <[email protected]>
---
--- linux-2.6/arch/i386/boot/video-vesa.c.old 2007-08-31 11:51:40.478575122 -0400
+++ linux-2.6/arch/i386/boot/video-vesa.c 2007-08-31 11:51:10.980602450 -0400
@@ -39,9 +39,11 @@
vginfo.signature = VBE2_MAGIC;
- /* Optimistically assume a VESA BIOS is register-clean... */
ax = 0x4f00;
- asm("int $0x10" : "+a" (ax), "=m" (vginfo) : "D" (&vginfo));
+ asm("int $0x10"
+ : "+a" (ax), "=m" (vginfo)
+ : "D" (&vginfo)
+ : "ebx", "ecx", "edx", "esi");
if (ax != 0x004f ||
vginfo.signature != VESA_MAGIC ||
@@ -66,7 +68,8 @@
ax = 0x4f01;
asm("int $0x10"
: "+a" (ax), "=m" (vminfo)
- : "c" (mode), "D" (&vminfo));
+ : "c" (mode), "D" (&vminfo)
+ : "ebx", "edx", "esi");
if (ax != 0x004f)
continue;
Will Simoneau wrote:
>
> Apparently some VESA BIOS implementations clobber our registers when called.
> Tell gcc about it.
>
> This makes my Dell Inspiron 5150 boot correctly instead of hanging.
>
OK, we probably should use the INT10 macro, then, for these, too, as
well as change the other two int 0x10 callsites.
So much for optimism...
-hpa