WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] [PATCH] xen-unstable on HP dc7800 simply reboots

To: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH] xen-unstable on HP dc7800 simply reboots
From: John Byrne <john.l.byrne@xxxxxx>
Date: Wed, 24 Oct 2007 19:13:44 -0700
Cc: xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Wed, 24 Oct 2007 19:14:30 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <471F6FA6.4080105@xxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <C344BAE7.F684%Keir.Fraser@xxxxxxxxxxxx> <471F6FA6.4080105@xxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Thunderbird 2.0.0.6 (X11/20070728)
John Byrne wrote:
Keir Fraser wrote:
On 24/10/07 08:12, "Keir Fraser" <Keir.Fraser@xxxxxxxxxxxx> 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@xxxxxx


Attachment: dc7800.patch
Description: Text Data

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel