I run a 2.6.3 kernel on Intel S875WP1 mainboard. When I enable PnPBIOS
in kernel config, the kernel gets general protection fault 0 just after
telling it found PnP BIOS. No backtrace. Disabling PnPBIOS in kernel
works around the problem.
--
Meelis Roos ([email protected])
diff -urN linux-bk/arch/i386/mm/extable.c linux/arch/i386/mm/extable.c
--- linux-bk/arch/i386/mm/extable.c 2004-02-15 00:41:41.000000000 -0500
+++ linux/arch/i386/mm/extable.c 2004-03-04 08:42:12.169000128 -0500
@@ -12,7 +12,7 @@
const struct exception_table_entry *fixup;
#ifdef CONFIG_PNPBIOS
- if (unlikely((regs->xcs | 8) == 0x88)) /* 0x80 or 0x88 */
+ if (unlikely((regs->xcs & ~15) == (GDT_ENTRY_PNPBIOS_BASE << 3)))
{
extern u32 pnp_bios_fault_eip, pnp_bios_fault_esp;
extern u32 pnp_bios_is_utter_crap;
> Try this patch
Well, it gets a little further. No oops but a different hang:
Linux Plug and Play Support v0.97 (c) Adam Belay
PnPBIOS: Scanning system for PnP BIOS support...
PnPBIOS: Found PnP BIOS installation structure at 0xc00f3e90
PnPBIOS: PnP BIOS version 1.0, entry 0xf0000:0x44ba, dseg 0xf0000
PNPBIOS fault.. attempting recovery.
double fault, gdt at c0488100 [255 bytes]
double fault, tss at c0530800
eip = f7fa1ea6, esp = 00000028
eax = 00000028, ebx = f7fa1ea6, ecx = c048c5d4, edx = 00000086
esi = 00000000, edi = c010c958
--
Meelis Roos ([email protected]) http://www.cs.ut.ee/~mroos/
Meelis Roos wrote:
>>Try this patch
>
>
> Well, it gets a little further. No oops but a different hang:
>
> Linux Plug and Play Support v0.97 (c) Adam Belay
> PnPBIOS: Scanning system for PnP BIOS support...
> PnPBIOS: Found PnP BIOS installation structure at 0xc00f3e90
> PnPBIOS: PnP BIOS version 1.0, entry 0xf0000:0x44ba, dseg 0xf0000
> PNPBIOS fault.. attempting recovery.
> double fault, gdt at c0488100 [255 bytes]
> double fault, tss at c0530800
> eip = f7fa1ea6, esp = 00000028
Looks like the BIOS trashed the stack. I don't think there is anything
that can be done other than a BIOS update.
--
Brian Gerst
> > PNPBIOS fault.. attempting recovery.
> > double fault, gdt at c0488100 [255 bytes]
> > double fault, tss at c0530800
> > eip = f7fa1ea6, esp = 00000028
>
> Looks like the BIOS trashed the stack. I don't think there is anything
> that can be done other than a BIOS update.
This is the latest BIOS (P12) so I reported it to Intel.
--
Meelis Roos ([email protected])
diff -urN linux-bk/arch/i386/mm/extable.c linux/arch/i386/mm/extable.c
--- linux-bk/arch/i386/mm/extable.c 2004-02-15 00:41:41.000000000 -0500
+++ linux/arch/i386/mm/extable.c 2004-03-04 10:45:32.988904488 -0500
@@ -12,7 +12,7 @@
const struct exception_table_entry *fixup;
#ifdef CONFIG_PNPBIOS
- if (unlikely((regs->xcs | 8) == 0x88)) /* 0x80 or 0x88 */
+ if (unlikely((regs->xcs & ~15) == (GDT_ENTRY_PNPBIOS_BASE << 3)))
{
extern u32 pnp_bios_fault_eip, pnp_bios_fault_esp;
extern u32 pnp_bios_is_utter_crap;
@@ -21,7 +21,7 @@
__asm__ volatile(
"movl %0, %%esp\n\t"
"jmp *%1\n\t"
- : "=a" (pnp_bios_fault_esp), "=b" (pnp_bios_fault_eip));
+ : : "g" (pnp_bios_fault_esp), "g" (pnp_bios_fault_eip));
panic("do_trap: can't hit this");
}
#endif
On Thu, 4 Mar 2004, Brian Gerst wrote:
>
> This patch fixes two errors in fixup_exception() for PnP BIOS faults:
> - Check for the correct segments used for the BIOS
> - Fix asm constraints so that EIP and ESP are properly reloaded
I'm almost certain that you should NOT use "g" as a constraint, since that
allows the address to be on the stack frame, so when we compile without
frame pointers and the compiler uses a %esp-relative thing for the branch
address, that will totally screw up when we just re-loaded %esp inside the
asm.
Can you use "r" instead, and test that it all works for you, and send an
updated patch? Or just explain why I'm wrong.
Linus
Linus Torvalds wrote:
>
> On Thu, 4 Mar 2004, Brian Gerst wrote:
>
>>This patch fixes two errors in fixup_exception() for PnP BIOS faults:
>>- Check for the correct segments used for the BIOS
>>- Fix asm constraints so that EIP and ESP are properly reloaded
>
>
> I'm almost certain that you should NOT use "g" as a constraint, since that
> allows the address to be on the stack frame, so when we compile without
> frame pointers and the compiler uses a %esp-relative thing for the branch
> address, that will totally screw up when we just re-loaded %esp inside the
> asm.
>
> Can you use "r" instead, and test that it all works for you, and send an
> updated patch? Or just explain why I'm wrong.
>
> Linus
>
The inputs are global variables, with absolute addresses.
--
Brian Gerst