Mikael Pettersson wrote:
The machine in question is a ca 1993 vintage Siemens 486 with
a Quadtel S3 / Phoenix BIOS from 1994, booting via grub-0.95-13
from Fedora Core 4.
Signed-off-by: Mikael Pettersson <[email protected]>
---
arch/x86/boot/compressed/head_32.S | 5 +++++
1 files changed, 5 insertions(+)
--- linux-2.6.24-rc1-git13/arch/x86/boot/compressed/head_32.S.~1~ 2007-11-04 16:34:33.000000000 +0100
+++ linux-2.6.24-rc1-git13/arch/x86/boot/compressed/head_32.S 2007-11-04 16:44:15.000000000 +0100
@@ -33,6 +33,11 @@
.globl startup_32
startup_32:
+ /* workaround for BIOSen or boot loaders that don't reload %ds
+ after changing the GDT (insane but unfortunately true) */
+ movl %ds,%eax
+ movl %eax,%ds
+
cld
/* test KEEP_SEGMENTS flag to see if the bootloader is asking
* us to not reload segments */
Double bogus flag here.
It's not an issue of the BIOS or the boot loader (in your case, Grub)
unless you have a boot loader that does 32-bit entry (e.g. kexec or ELILO.)
Second, the "workaround" you have here effectively disables the meaning
of the KEEP_SEGMENTS flag, so it's unacceptable.
If one couldn't rely on %ds, then we could load the loadflags with a
%cs: override, but there is something much more bizarre going on here.
Since you're doing a normal 16-bit entry (unless your Grub is
configured/patched to do something extremely weird, not that that would
be anything out of the ordinary for Grub) the code that should have been
executed immediately before this point is this code from
arch/x86/boot/pm_jump.S:
protected_mode_jump:
xorl %ebx, %ebx # Flag to indicate this is a boot
movl %edx, %esi # Pointer to boot_params table
movl %eax, 2f # Patch ljmpl instruction
jmp 1f # Short jump to flush
instruction q.
1:
movw $__BOOT_DS, %cx
movl %cr0, %edx
orb $1, %dl # Protected mode (PE) bit
movl %edx, %cr0
movw %cx, %ds
movw %cx, %es
movw %cx, %fs
movw %cx, %gs
movw %cx, %ss
# Jump to the 32-bit entrypoint
.byte 0x66, 0xea # ljmpl opcode
2: .long 0 # offset
.word __BOOT_CS # segment
.size protected_mode_jump, .-protected_mode_jump
As you can see, all the segments should have been properly set up. I'm
somewhat wondering if you have found one lone CPU revision in the entire
x86 menagerie which doesn't properly serialize on mov to %cr0, which
would casue the mov to %ds immediately after to be misexecuted. If
that's the case, I believe I owe Eric Biederman a drink of choice.
Could you send me your /proc/cpuinfo?
Also, I would be very interested if you could try out this patch:
diff --git a/arch/x86/boot/pmjump.S b/arch/x86/boot/pmjump.S
index 2e55923..97cf407 100644
--- a/arch/x86/boot/pmjump.S
+++ b/arch/x86/boot/pmjump.S
@@ -30,7 +30,6 @@
protected_mode_jump:
xorl %ebx, %ebx # Flag to indicate this is a boot
movl %edx, %esi # Pointer to boot_params table
- movl %eax, 2f # Patch ljmpl instruction
jmp 1f # Short jump to flush instruction q.
1:
@@ -39,16 +38,17 @@ protected_mode_jump:
movl %cr0, %edx
orb $1, %dl # Protected mode (PE) bit
movl %edx, %cr0
+ ljmpw __BOOT_CS, 2f
- movw %cx, %ds
- movw %cx, %es
- movw %cx, %fs
- movw %cx, %gs
- movw %cx, %ss
+ .code32
+2:
+ movl %ecx, %ds
+ movl %ecx, %es
+ movl %ecx, %fs
+ movl %ecx, %gs
+ movl %ecx, %ss
# Jump to the 32-bit entrypoint
- .byte 0x66, 0xea # ljmpl opcode
-2: .long 0 # offset
- .word __BOOT_CS # segment
-
+ jmpl %eax
+
.size protected_mode_jump, .-protected_mode_jump
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
