VirtualBox

Ticket #12748 (closed defect: fixed)

Opened 12 months ago

Last modified 11 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 12 months ago.
Screenshot1_kernelpanic_puppylinuxprecise571
vboxlog__kernelpanic_puppylinux-precise-571.rtf Download (56.2 KB) - added by longwuyuan 12 months ago.
vboxlogkernelpanic_puppylinux-precise-571
screenshot_virtualbox_kernelpanic_puppylinux-precise571.png Download (65.9 KB) - added by longwuyuan 12 months ago.
screenshot_virtualbox_kernelpanic_puppylinux-precise571
VBox.log Download (84.5 KB) - added by longwuyuan 12 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 12 months ago.
Latest kernel panic with work arround applied
twork-VBox.log Download (89.8 KB) - added by twork 12 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 12 months ago.
cvillepete-vbox.log before and after the workaround

Change History

comment:1 Changed 12 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 12 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 12 months ago by longwuyuan

Screenshot1_kernelpanic_puppylinuxprecise571

Changed 12 months ago by longwuyuan

vboxlogkernelpanic_puppylinux-precise-571

Changed 12 months ago by longwuyuan

screenshot_virtualbox_kernelpanic_puppylinux-precise571

comment:3 Changed 12 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 12 months ago by frank

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

comment:5 Changed 12 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 12 months ago by longwuyuan

reattached log file as is from the subdirectory of the ghost

comment:6 Changed 12 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 12 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 12 months ago by twork

Latest kernel panic with work arround applied

comment:8 in reply to: ↑ 7 ; follow-up: ↓ 9 Changed 12 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 12 months ago by twork (previous) (diff)

comment:9 in reply to: ↑ 8 ; follow-up: ↓ 16 Changed 12 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,0x000000000) -> GP(0)`

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

Version 0, edited 12 months ago by twork (next)

comment:10 Changed 12 months ago by twork

  • Status changed from closed to reopened
  • Resolution fixed deleted

comment:11 Changed 12 months ago by frank

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

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

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

comment:13 Changed 12 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 12 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 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?

Last edited 12 months ago by cvillepete (previous) (diff)

Changed 12 months ago by cvillepete

cvillepete-vbox.log before and after the workaround

comment:15 Changed 11 months ago by frank

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

comment:16 in reply to: ↑ 9 Changed 11 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 11 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