PuppyLinux-Precise-v5.7.1 - Kernel Panic [FIXED in SVN]

[longwuyuan]

PuppyLinux-Precise version 5.7.1 VirtualBox Version = 4.3.8 r92456 Host OS = Mac OS version 10.7.2 Host HW = Macbook Pro 15" late 2011

Problem ===== PuppyLinux-v does not boot and throws kernel panic

Steps to reproduce ============

• Install Virtualbox

[Frank Mehnert]

Please attach 1) the VBox.log file of such a VM session and 2) a screen shot of the kernel panic.

[Frank Mehnert]

Also interesting: Did this VM work with an older version of VBox? If so, which was the last working VBox version?

[longwuyuan]

Screenshot1_kernelpanic_puppylinuxprecise571

[longwuyuan]

vboxlogkernelpanic_puppylinux-precise-571

[longwuyuan]

screenshot_virtualbox_kernelpanic_puppylinux-precise571

[longwuyuan]

• Screenshot attached

• Vbox.log attached in rtf format

• This was the first time I tried this combination of version 4.3.8 r92456 of VirtualBox & PuppyLinux-Precise5.7.1

• From #VirtualBox on Freenode, I was asked to try VirtualBox 4.3.6 and this problem was not seen on VirutalBox version 4.3.6

• Some references to PuppyLinux-Precise (but not version 5.7.1) not working on VirtualBox (MacOS & Windows as well) are mentioned here ​http://murga-linux.com/puppy/viewtopic.php?t=88429&start=15

• Just FYI, this problem does not occur on KVM

• I will be glad to provide any other info if required

Thanks,

[Frank Mehnert]

Sorry, could you just attach the VBox.log file untranslated (i.e. not in rtf)? Thank you!

[Klaus Espenlaub]

The key line in the log is

00:00:09.529364 IEM: wrmsr(0x391,0x0`2000000f) -> GP(0)

It means that this guest writes to a MSR which isn't allowed by VirtualBox (as it thinks it shouldn't be there/used)...

[longwuyuan]

reattached log file as is from the subdirectory of the ghost

[longwuyuan]

Is it possible to know if VirtualBox version 4.3.6 allows write to MSR. I am just uninstalling and reinstalling version 4.3.6 & version 4.3.8 without deleting host. Host launches on 4.3.6 but not on 4.3.8 so asked.

[bird]

Thanks for the report. We've tracked down the issue and (hopfully) fixed it. The next VirtualBox release will include the fix.

In the mean time, this should work around it:

VBoxManage setextradata <vm-name> VBoxInternal/CPUM/EnableHVP 1

[twork]

Latest kernel panic with work arround applied

[twork]

Replying to bird:

Workaround didn't work for me.

In case it's useful... I'm having the same or smilar issue. Host system is Gentoo amd64, VirtualBox worked fine before I updated to 4.3.8. Currently all of my guest VM's are also Gentoo, either 32 or 64.

After applying the "hopefully" fix:

VBoxManage setextradata <vm-name> VBoxInternal/CPUM/EnableHVP 1

...no joy.

My panic looks different from the one posted, though, so maybe I'm up against a different issue. Screenshot of my latest boot attempt just attached, VM name is "gentoo64-net-util Clone".

[twork]

Replying to twork:

Replying to bird:

Aha. Should have checked earlier: my VBox.log shows:

00:00:21.510087 IEM: wrmsr(0xc0000103,0x000000000) -> GP(0)`

...so it looks like I am indeed up against the same problem.

[Frank Mehnert]

twork, please attach the compile log file of such a VM session.

[burdi01]

It should be noted that for me the "EnableHVP 1" workaround works for Puppy precise-5.7.1.iso, Porteus-XFCE-v3.0-rc2-x86_64.iso as well as PartedMagic pmagic_2014_02_26.iso.

[twork]

Full VBox.log from twork's failed VM post-workaround, gentoo64 both host and VM

[twork]

One more update from my perspective: After more investigation it's pretty clear that I'm up against a different issue from the one addressed here. I'll start a different thread.

[cvillepete]

Replying to bird:

Thanks for the report. We've tracked down the issue and (hopfully) fixed it. The next VirtualBox release will include the fix.

In the mean time, this should work around it:

VBoxManage setextradata <vm-name> VBoxInternal/CPUM/EnableHVP 1

This isn't specific to PuppyLinux, is it? I'm trying to build an Arch Linux machine and am getting the exact same message:

02:30:55.287176 IEM: wrmsr(0x391,0x0`2000000f) -> GP(0)

The workaround seemed to have gotten rid of the wrmsr entry in the log and now I get the same "Kernel panic exitcode=0x0000000b" and "error 7 in libc-2.19.so" printed to the screen, but the log is void of any useful messages...basically goes from this:

00:00:03.338021 Guest Log: BIOS: Booting from Hard Disk...

...to this:

00:00:05.911131 AIOMgr: Host limits number of active IO requests to 16. Expect a performance impact.
00:00:16.629279 Changing the VM state from 'RUNNING' to 'SUSPENDING'.

I can attach my log if you wish. Is there another work-around for Arch or is this OS-independent?

[cvillepete]

cvillepete-vbox.log before and after the workaround

[Frank Mehnert]

cvillepete, please could you confirm that this build fixes your problems? Thank you!

[hoeferbe]

Replying to twork:

===

Aha. Should have checked earlier: my VBox.log shows:

00:00:21.510087 IEM: wrmsr(0xc0000103,0x0`00000000) -> GP(0)

...so it looks like I am indeed up against the same problem.

===

Same thing here. I was running 4.3.6 on a CentOS 5 server running kernel-2.6.18-371.6.1.el5.x86_64. My Fedora 19 guests (running kernel-3.13.6-100.fc19.x86_64) failed to start up as soon as I upgraded to VirtualBox-4.3-4.3.8_92456_el5-1.x86_64.

I see that same IEM log entry. The work-around in comment #7 did not help.

[Frank Mehnert]

Fix is part of VBox 4.3.10.