Re: kmemcheck: Caught 32-bit read from uninitialized memory (f6038ec0)

[Vegard Nossum]

On Mon, Sep 29, 2008 at 3:14 PM, Ingo Molnar <mingo@xxxxxxx> wrote:
>
> another crash is below - config attached.
>
>        Ingo
>
> ----------------->
> initcall 0xc08eabf0 returned 0 after 7 msecs
> calling  0xc08eae70 @ 1
> PnPBIOS: Scanning system for PnP BIOS support...
> PnPBIOS: Found PnP BIOS installation structure at 0xc00fc550
> PnPBIOS: PnP BIOS version 1.0, entry 0xf0000:0xc580, dseg 0xf0000
> BUG: unable to handle kernel paging request at 0000c6ef

Thanks, I can reproduce it. And that's very interesting. Look at the
faulting address and the line just above:

    PnP BIOS version 1.0, entry 0xf0000:0xc580

When I run it, I get something similar:

    PnPBIOS: PnP BIOS version 1.0, entry 0xf0000:0x67ba, dseg 0xf0000
    BUG: unable to handle kernel paging request at 000068ac

Enabling debug information also gives me the location of the crash. It
happens in kmemcheck's opcode decoder, when we dereference regs->eip.
Is it possible that PnPBIOS is executing some code which is located at
these weird addresses (like 16-bit code) and requires a different
segment register?

Maybe we should just check regs->flags to make sure that we are not in
VM86 mode or similar. Will experiment a bit with it. Thanks.


Vegard

-- 
"The animistic metaphor of the bug that maliciously sneaked in while
the programmer was not looking is intellectually dishonest as it
disguises that the error is the programmer's own creation."
	-- E. W. Dijkstra, EWD1036
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/