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,0x0`00000000) -> 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. After trying to boot up now, my log is void of any helpful 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.