Opened 11 years ago
Closed 11 years ago
#12748 closed defect (fixed)
PuppyLinux-Precise-v5.7.1 - Kernel Panic [FIXED in SVN]
Reported by: | longwuyuan | Owned by: | |
---|---|---|---|
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
Change History (24)
comment:1 by , 11 years ago
priority: | blocker → major |
---|
comment:2 by , 11 years ago
Also interesting: Did this VM work with an older version of VBox? If so, which was the last working VBox version?
by , 11 years ago
Attachment: | Screen Shot 2014-02-27 at 6.43.44 PM.png added |
---|
Screenshot1_kernelpanic_puppylinuxprecise571
by , 11 years ago
Attachment: | vboxlog__kernelpanic_puppylinux-precise-571.rtf added |
---|
vboxlogkernelpanic_puppylinux-precise-571
by , 11 years ago
Attachment: | screenshot_virtualbox_kernelpanic_puppylinux-precise571.png added |
---|
screenshot_virtualbox_kernelpanic_puppylinux-precise571
comment:3 by , 11 years ago
- 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,
comment:4 by , 11 years ago
Sorry, could you just attach the VBox.log file untranslated (i.e. not in rtf)? Thank you!
comment:5 by , 11 years ago
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)...
by , 11 years ago
reattached log file as is from the subdirectory of the ghost
comment:6 by , 11 years ago
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.
follow-ups: 8 14 comment:7 by , 11 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
Summary: | PuppyLinux-Precise-v5.7.1 - Kernel Panic → 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
by , 11 years ago
Attachment: | gentoo64-net-util Clone.png added |
---|
Latest kernel panic with work arround applied
follow-up: 9 comment:8 by , 11 years ago
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".
follow-up: 16 comment:9 by , 11 years ago
comment:10 by , 11 years ago
Resolution: | fixed |
---|---|
Status: | closed → reopened |
comment:12 by , 11 years ago
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.
by , 11 years ago
Attachment: | twork-VBox.log added |
---|
Full VBox.log from twork's failed VM post-workaround, gentoo64 both host and VM
comment:13 by , 11 years ago
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 by , 11 years ago
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?
comment:15 by , 11 years ago
cvillepete, please could you confirm that this build fixes your problems? Thank you!
comment:16 by , 11 years ago
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 by , 11 years ago
Resolution: | → fixed |
---|---|
Status: | reopened → closed |
Fix is part of VBox 4.3.10.
Please attach 1) the VBox.log file of such a VM session and 2) a screen shot of the kernel panic.