I have a x86_64 system running inside a VMware virtual machine. It
works very well with 2.6.25; however, I have tried both 2.6.27 and
2.6.29, and both give me a panic immediately upon boot. I have to use
earlyprintk to get anything useful.
Output is pasted below. It's hand-typed from a screenshot, so
hopefully I didn't mistype anything. I can get the memory ranges if
need be. Hopefully someone knows of the solution/can fix the problem.
Thanks,
Jeff
console [earlyvga0] enabled
DMI present.
PANIC: early exception 0e rip 10:ffffffff80866edc error 0 cr2 ffffffffeff44003d
Pid: 0, comm: swapper Not tainted 2.6.29-gentoo-r5 #2
Call Trace:
early_idt_handler+0x5e/0x71
dmi_string_nosave+0x34/0x80
dmi_string_nosave+0x67/0x80
dmi_string+0xa/0x6e
dmi_save_ident+0x1b/0x2a
dmi_decode+0x72/0x492
_spin_unlock_irqrestore+0x14/0x17
__early_set_fixmap+0xa0/0xa7
dmi_table+0x4e/0x78
dmi_scan_machine+0x132/0x19f
setup_arch+0x34d/0x636
early_idt_handler+0x0/0x71
start_kernel+0x86/0x35e
x86_64_start_kernel+0xed/0xf6
RIP dmi_string_nosave+0x34/0x80
On 06/05/2009 11:39 PM, Jeff Mitchell wrote:
> Output is pasted below. It's hand-typed from a screenshot, so
> hopefully I didn't mistype anything.
Don't worry to append a link to the screenshot next time ;).
> console [earlyvga0] enabled
> DMI present.
> PANIC: early exception 0e rip 10:ffffffff80866edc error 0 cr2 ffffffffeff44003d
> Pid: 0, comm: swapper Not tainted 2.6.29-gentoo-r5 #2
> Call Trace:
> early_idt_handler+0x5e/0x71
> dmi_string_nosave+0x34/0x80
> dmi_string_nosave+0x67/0x80
> dmi_string+0xa/0x6e
> dmi_save_ident+0x1b/0x2a
> dmi_decode+0x72/0x492
> _spin_unlock_irqrestore+0x14/0x17
> __early_set_fixmap+0xa0/0xa7
> dmi_table+0x4e/0x78
> dmi_scan_machine+0x132/0x19f
> setup_arch+0x34d/0x636
> early_idt_handler+0x0/0x71
> start_kernel+0x86/0x35e
> x86_64_start_kernel+0xed/0xf6
> RIP dmi_string_nosave+0x34/0x80
Looks like dmi_string_nosave gets a mess. It tries to dereference
0xffffffffeff44003d. Could you investigate to which save_indent in
dmi_decode does the dmi_decode+0x72 correspond to?
Is this vanilla, i.e. what does -gentoo-r5 mean?
And also append a dmidecode output from a working kernel.
> Don't worry to append a link to the screenshot next time ;).
Done... http://tinypic.com/r/2vuwz1j/5
> Looks like dmi_string_nosave gets a mess. It tries to dereference
> 0xffffffffeff44003d. Could you investigate to which save_indent in
> dmi_decode does the dmi_decode+0x72 correspond to?
If you help me through it. That last sentence is pretty much
gibberish to me :-)
> Is this vanilla, i.e. what does -gentoo-r5 mean?
Gentoo patchset on top of vanilla. However, I have tried it with
vanilla 2.6.29.4 with the same exact results.
> And also append a dmidecode output from a working kernel.
Attached. I noticed in the output that the processor is claimed to be
GenuineIntel, although it's an AMD Opteron box (but via VMware).
Thanks!
--Jeff
On Sat, 6 Jun 2009 12:35:33 -0400
Jeff Mitchell <[email protected]> wrote:
> > Don't worry to append a link to the screenshot next time ;).
>
> Done... http://tinypic.com/r/2vuwz1j/5
>
> > Looks like dmi_string_nosave gets a mess. It tries to dereference
> > 0xffffffffeff44003d. Could you investigate to which save_indent in
> > dmi_decode does the dmi_decode+0x72 correspond to?
The dmi code isn't robust against corrupt BIOS DMI tables. I have a patch
pending for this if you want to try it out. I've no idea if that is the
trigger in your case but it may be.