Re: Odd behavior in x86/pc booting process with minor modifications

[Bean]

On Jan 27, 2008 10:52 PM, Vesa Jääskeläinen <address@hidden> wrote:
> Hi,
>
> I was playing around with IDT and needed some code space in startup.S
> and in realmode.S. GRUB just hanged for some reason during the bootup
> when I just had query instruction for current IDT descriptor and some
> storage for it after GDT tables.
>
> I then reverted that code and added as many NOPs as that code would take
> there and it was still hanging... then I removed some NOPs and hang went
> away. I don't have good debugging capabilities other than qemu's log,
> but it would seem like when grub is decompressing itself there is minor
> code flow difference, though this could only be because binary is a bit
> different... so I am not sure about that theory... anyway if there are
> good ideas on how to debug this, or even better solutions to possible
> problem :). Any ideas are welcome.
>
> So how to reproduce this problem:
>
> 1. open kern/i386/pc/startup.S
> 2. find codestart
>
> // actual location is not so important
> 3. find first sti instruction
> 4. go 1 line backwards
>
> 5. add about 15 NOP's
>
> 6. recompile and make image
> 7. try it out, it should hang without displaying grub shell or menu.

This is actually caused by memory overlap. in grub-mkimage, it will
compress from offset 0x4A0 (GRUB_KERNEL_MACHINE_RAW_SIZE), which
corresponds to 0x6A0 of core.img. this is inside of lzo decompression
code which ends at 0x6A2 (you can verify this by adding a text string
at the end of lzo1x.S). it's a very delicate situation. when you add
more code, it push the lzo decompression code further back, making
more code inside compression zone, and it's bound to go wrong. The fix
is to increase the value of GRUB_KERNEL_MACHINE_RAW_SIZE.

-- 
Bean