All of lore.kernel.org
 help / color / mirror / Atom feed
From: "H. Peter Anvin" <hpa@zytor.com>
To: Jeremy Fitzhardinge <jeremy@goop.org>
Cc: Sean Young <sean@mess.org>, Rusty Russell <rusty@rustcorp.com.au>,
	linux-kernel@vger.kernel.org
Subject: Re: Regression: boot failure on AMD Elan TS-5500
Date: Mon, 30 Jun 2008 15:04:33 -0700	[thread overview]
Message-ID: <48695871.8000805@zytor.com> (raw)
In-Reply-To: <4869558A.9020907@goop.org>

Jeremy Fitzhardinge wrote:
>>
>> Looking at the beginning of startup_32, it seems ds is used before it 
>> is set:
>>
>> startup_32:
>>         cld
>>         /* test KEEP_SEGMENTS flag to see if the bootloader is asking
>>          * us to not reload segments */
>>         testb $(1<<6), BP_loadflags(%esi)
>>         jnz 1f
>>
>>         cli
>>         movl $(__BOOT_DS),%eax
>>         movl %eax,%ds
>>         movl %eax,%es
>>         movl %eax,%fs
>>         movl %eax,%gs
>>         movl %eax,%ss
>> 1:
>>
>> Since the testb instruction is a dereference, ds is implicitly used. If
>> I move the testb to after "movl %eax,%ds" it seems to work (not that it
>> would make any sense there, but just to prove the point).
>>
>> 1) Am I barking up the wrong tree?
>>
>> 2) If I'm right I have no idea what the correct solution is; it seems 
>> that
>>    a chicken & egg issue is introduced.
>>
>> Please advise. I am very new to all of this.
> 
> It's a bit odd that the boot loader neglected to set up ds properly, but 
> changing the testb line to
> 
>     testb $(1<<6), %cs:BP_loadflags(%esi)
> 
> should work.  (Or perhaps a %ss: override would be better?)
> 
> I'm assuming that the GDT setup isn't completely mad and that the 
> segments have the same base at least.
> 

This should have been set up by the *boot code* (specifically lines 
57-61 of arch/x86/boot/pmjump.S) since he's using a conventional boot 
loader (syslinux) so something is utterly fuggled up.  Using %cs: here 
should be safe, though (and *is* more conservative, after all, why 
otherwise bother reloading these segments at all?), but it still 
concerns me a great deal if this is broken in this way.  It's definitely 
better than %ss:.

In particular, I'm wondering if the Elan CPU has any strange ordering 
requirements with regards to the protected mode transition that we're 
not obeying.

It would be interesting to put in a heavyweight "brutally synchronizing" 
instruction like WBINVD at various places in arch/x86/boot/pmjump.S and 
see if it helps.

	-hpa

  reply	other threads:[~2008-06-30 22:08 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-06-16 12:11 Regression: boot failure on AMD Elan TS-5500 Sean Young
2008-06-16 13:27 ` Rusty Russell
2008-06-16 13:37   ` Jeremy Fitzhardinge
2008-06-16 16:19     ` Sean Young
2008-06-16 17:06       ` H. Peter Anvin
2008-06-16 17:58         ` Sean Young
2008-06-16 18:16           ` H. Peter Anvin
2008-06-16 17:06       ` H. Peter Anvin
2008-06-16 17:07       ` Jeremy Fitzhardinge
2008-06-30 21:43       ` Sean Young
2008-06-30 21:52         ` Jeremy Fitzhardinge
2008-06-30 22:04           ` H. Peter Anvin [this message]
2008-06-30 22:14             ` H. Peter Anvin
2008-06-30 22:36               ` Jeremy Fitzhardinge
2008-06-30 22:45                 ` H. Peter Anvin
2008-06-30 22:31             ` Sean Young
2008-06-30 22:34             ` Jeremy Fitzhardinge
2008-06-30 22:42               ` H. Peter Anvin
2008-07-01 19:59                 ` Sean Young
2008-07-01 20:20                   ` Sean Young
2008-07-01 20:24                     ` Jeremy Fitzhardinge
2008-07-01 20:25                     ` H. Peter Anvin
2008-07-15 22:23                     ` Sean Young
2008-07-15 22:30                       ` H. Peter Anvin
2008-07-01 20:22                   ` Jeremy Fitzhardinge
2008-07-01 20:23                   ` H. Peter Anvin
2008-07-01 20:29                     ` Jeremy Fitzhardinge
2008-07-01 20:39                       ` H. Peter Anvin
2008-07-06 13:21                       ` Pavel Machek
2008-06-30 22:09           ` Sean Young
2008-07-06  2:41             ` Eric W. Biederman
2008-07-06  3:07               ` H. Peter Anvin

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=48695871.8000805@zytor.com \
    --to=hpa@zytor.com \
    --cc=jeremy@goop.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rusty@rustcorp.com.au \
    --cc=sean@mess.org \
    /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.