John Byrne wrote:
> Keir Fraser wrote:
>> On 24/10/07 08:12, "Keir Fraser" <Keir.Fraser@cl.cam.ac.uk> wrote:
>>
>>>> Littering the early boot code with putc() and comparing the code's
>>>> behavior on a machine that actually boots, I've found that the call to
>>>> get_memory_map from trampoline.S is the root of all evil. If that is
>>>> called, then the trampoline fails to make it back to protected mode 
>>>> from
>>>> real mode. I am still working to identify the specific problem.
>>> So if you remove that call, so Xen falls back to using the GRUB-supplied
>>> memory map, then Xen boots okay? Is tghat tru on current tip of 
>>> xen-unstable
>>> too?
>>
>> Thinking some more my guess is that any BIOS call is causing you to 
>> crash,
>> so removing just teh call to get_memory_map will be insufficient on 
>> tip --
>> you'll have to remove calls to set video mode and get edd information 
>> too.
>> Perhaps the IDT is either corrupted or not actually at address 0x0, like
>> it's supposed to be? What happens if you remove the 'lidt' instruction 
>> from
>> arch/x86/boot/trampoline.S?
> 
> Once I identified the problem revision, I went back to the tip to try to 
> debug it. (Sorry for any ambiguity.) Taking out get_memory_map is 
> sufficient;  get_edd and video don't seem to cause any problems. 
> Removing the lidt changes nothing. Adding a "ret" after the .Lmem88 in 
> mem.S confirms that the problem is in the e820 call. I'm currently 
> trying to see if the descriptor table is getting corrupted during the 
> BIOS calls.
> 

A lot of work to find a one-line fix. There is no sign of any corruption 
in the GDT, but you do need to reload the GDT before transitioning back 
to real mode. I am asking a BIOS person might require this, but, in the 
meantime, I cannot see how this patch will cause trouble on any other 
system and it seems to fix mine. I am just a little uncomfortable 
because I don't really understand why it is required.

Signed-off-by: john.l.byrne@hp.com