VirtualBox

Ticket #12748 (closed defect: fixed)

Opened 16 months ago

Last modified 15 months ago

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

Reported by: longwuyuan Owned by:
Priority: major Component: other
Version: VirtualBox 4.3.8 Keywords: kernel-panic
Cc: Guest type: Linux
Host type: Mac OS X

Description

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

Attachments

Screen Shot 2014-02-27 at 6.43.44 PM.png Download (65.9 KB) - added by longwuyuan 16 months ago.
Screenshot1_kernelpanic_puppylinuxprecise571
vboxlog__kernelpanic_puppylinux-precise-571.rtf Download (56.2 KB) - added by longwuyuan 16 months ago.
vboxlogkernelpanic_puppylinux-precise-571
screenshot_virtualbox_kernelpanic_puppylinux-precise571.png Download (65.9 KB) - added by longwuyuan 16 months ago.
screenshot_virtualbox_kernelpanic_puppylinux-precise571
VBox.log Download (84.5 KB) - added by longwuyuan 16 months ago.
reattached log file as is from the subdirectory of the ghost
gentoo64-net-util Clone.png Download (13.6 KB) - added by twork 16 months ago.
Latest kernel panic with work arround applied
twork-VBox.log Download (89.8 KB) - added by twork 16 months ago.
Full VBox.log from twork's failed VM post-workaround, gentoo64 both host and VM
VBox.2.log Download (87.8 KB) - added by cvillepete 16 months ago.
cvillepete-vbox.log before and after the workaround

Change History

comment:1 Changed 16 months ago by frank

  • Priority changed from blocker to major

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

comment:2 Changed 16 months ago by frank

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

Changed 16 months ago by longwuyuan

Screenshot1_kernelpanic_puppylinuxprecise571

Changed 16 months ago by longwuyuan

vboxlogkernelpanic_puppylinux-precise-571

Changed 16 months ago by longwuyuan

screenshot_virtualbox_kernelpanic_puppylinux-precise571

comment:3 Changed 16 months ago by 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
  • Just FYI, this problem does not occur on KVM
  • I will be glad to provide any other info if required

Thanks,

comment:4 Changed 16 months ago by frank

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

comment:5 Changed 16 months ago by klaus

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)...

Changed 16 months ago by longwuyuan

reattached log file as is from the subdirectory of the ghost

comment:6 Changed 16 months ago by 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.

comment:7 follow-ups: ↓ 8 ↓ 14 Changed 16 months ago by bird

  • Status changed from new to closed
  • Resolution set to fixed
  • Summary changed from PuppyLinux-Precise-v5.7.1 - Kernel Panic to PuppyLinux-Precise-v5.7.1 - Kernel Panic [FIXED in SVN]

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

Changed 16 months ago by twork

Latest kernel panic with work arround applied

comment:8 in reply to: ↑ 7 ; follow-up: ↓ 9 Changed 16 months ago by 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".

Last edited 16 months ago by twork (previous) (diff)

comment:9 in reply to: ↑ 8 ; follow-up: ↓ 16 Changed 16 months ago by 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.

Last edited 16 months ago by twork (previous) (diff)

comment:10 Changed 16 months ago by twork

  • Status changed from closed to reopened
  • Resolution fixed deleted

comment:11 Changed 16 months ago by frank

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

comment:12 Changed 16 months ago by 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.

Changed 16 months ago by twork

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

comment:13 Changed 16 months ago by 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.

comment:14 in reply to: ↑ 7 Changed 16 months ago by 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?

Version 0, edited 16 months ago by cvillepete (next)

Changed 16 months ago by cvillepete

cvillepete-vbox.log before and after the workaround

comment:15 Changed 16 months ago by frank

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

comment:16 in reply to: ↑ 9 Changed 15 months ago by 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.

comment:17 Changed 15 months ago by frank

  • Status changed from reopened to closed
  • Resolution set to fixed

Fix is part of VBox 4.3.10.

Note: See TracTickets for help on using tickets.

www.oracle.com
ContactPrivacy policyTerms of Use