All of lore.kernel.org
 help / color / mirror / Atom feed
From: John Byrne <john.l.byrne@hp.com>
To: Keir Fraser <Keir.Fraser@cl.cam.ac.uk>
Cc: xen-devel <xen-devel@lists.xensource.com>
Subject: Re: [PATCH] xen-unstable on HP dc7800 simply reboots
Date: Wed, 24 Oct 2007 19:13:44 -0700	[thread overview]
Message-ID: <471FFBD8.8080209@hp.com> (raw)
In-Reply-To: <471F6FA6.4080105@hp.com>

[-- Attachment #1: Type: text/plain, Size: 1999 bytes --]

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



[-- Attachment #2: dc7800.patch --]
[-- Type: text/x-patch, Size: 507 bytes --]

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

[-- Attachment #3: Type: text/plain, Size: 138 bytes --]

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

  reply	other threads:[~2007-10-25  2:13 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-10-23 16:49 xen-unstable on HP dc7800 simply reboots John Byrne
2007-10-23 18:07 ` Keir Fraser
2007-10-23 19:15   ` John Byrne
2007-10-23 23:03     ` John Byrne
2007-10-24  7:12       ` Keir Fraser
2007-10-24  8:03         ` Keir Fraser
2007-10-24 16:15           ` John Byrne
2007-10-25  2:13             ` John Byrne [this message]
2007-10-25  7:49               ` [PATCH] " Keir Fraser

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=471FFBD8.8080209@hp.com \
    --to=john.l.byrne@hp.com \
    --cc=Keir.Fraser@cl.cam.ac.uk \
    --cc=xen-devel@lists.xensource.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.