From mboxrd@z Thu Jan 1 00:00:00 1970 From: John Byrne Subject: Re: [PATCH] xen-unstable on HP dc7800 simply reboots Date: Wed, 24 Oct 2007 19:13:44 -0700 Message-ID: <471FFBD8.8080209@hp.com> References: <471F6FA6.4080105@hp.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="------------050906040603020006080200" Return-path: In-Reply-To: <471F6FA6.4080105@hp.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Keir Fraser Cc: xen-devel List-Id: xen-devel@lists.xenproject.org This is a multi-part message in MIME format. --------------050906040603020006080200 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit John Byrne wrote: > Keir Fraser wrote: >> On 24/10/07 08:12, "Keir Fraser" 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 --------------050906040603020006080200 Content-Type: text/x-patch; name="dc7800.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="dc7800.patch" diff -r b28ae5f00553 xen/arch/x86/boot/trampoline.S --- a/xen/arch/x86/boot/trampoline.S Tue Oct 23 09:26:43 2007 +0100 +++ b/xen/arch/x86/boot/trampoline.S Wed Oct 24 16:58:23 2007 -0700 @@ -167,6 +167,8 @@ 1: mov $(BOOT_TRAMPOLINE>>4),%a /* Disable irqs before returning to protected mode. */ cli + /* At least 1 BIOS requires GDT to be reloaded. */ + lgdt bootsym(gdt_48) /* Enter protected mode, and flush insn queue. */ xor %ax,%ax --------------050906040603020006080200 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --------------050906040603020006080200--