starting virtual machine in virtualbox-ose freezes system

Bug #347487 reported by Kristian Rink
34
This bug affects 7 people
Affects Status Importance Assigned to Milestone
virtualbox-ose (Ubuntu)
Confirmed
Medium
Unassigned

Bug Description

Installed a jaunty testbed system on my machine (Tecra A8 notebook, Core2 Duo CPU, 2GB RAM). Tried both Sun VirtualBox and virtualbox-ose off the package repository, with the same result: Starting virtualbox works well, vbox* modules also seem loaded. However as soon as I try starting a virtual machine (no matter whether a newly created one or an existing one restored from backup), the virtual machine window appears and then the whole system immediately locks up inasmuch as that the GUI doesn't respond anymore, no mouse/keyboard interactions are possible anymore, and switching to any vt using ctrl+alt+f<n> also doesn't work anymore. Couldn't so far get closer to this, unfortunately...

system:

Linux n428 2.6.28-11-generic #36-Ubuntu SMP Fri Mar 20 19:40:40 UTC 2009 i686 GNU/Linux

Revision history for this message
Kristian Rink (kawazu) wrote :
Revision history for this message
Kristian Rink (kawazu) wrote :
Revision history for this message
darthanubis (darthanubis) wrote :

Thank goodness it is not just me!

Linux core2duo 2.6.28-11-generic #38-Ubuntu SMP Fri Mar 27 10:01:17 UTC 2009 x86_64 GNU/Linux

Revision history for this message
Daniel Hahler (blueyed) wrote :

Marking confirmed, according to previous comment.

To some regard I can confirm it, too, but my system does not lockup: the Jaunty VM (alternate image) I'm starting hangs at "Booting from local disk..." (after chosing "Boot from first hard disk" with the .iso mounted - without .iso mounted it hangs at a black screen).
Another Jaunty image/VM (non-alternate) however boots/restores fine.

Also, a Hardy VM boots fine.

Changed in virtualbox-ose:
status: New → Confirmed
importance: Undecided → Medium
Revision history for this message
Kristian Rink (kawazu) wrote :

I am not sure whether this really is related to virtualbox or might be a kernel issue: In my environment, I managed to boot up any VM reliably after, in the VM configuration, disabling "VT-x/AMD-V" support (which is not really what one wants on a Core2 Duo that actually supports VT). However:

- Switching VT-x/AMD-V on and trying to boot the VM reliably ends up in a complete system lockup (frozen UI, SysRq keys not working anymore, machine not ping'able via LAN anymore).

- Switching off VT-x/AMD-V, the virtual machine comes up and seems to work as expected.

So, overally, this is a workaround to at least get VMs in virtualbox-ose running again.

- System: up-to-date jaunty build
- Kernel: Linux n428 2.6.28-11-generic #38-Ubuntu SMP Fri Mar 27 09:00:52 UTC 2009 i686 GNU/Linux

Revision history for this message
PearZoo (peter4) wrote :

I have the same problem on a Toshiba Qosmio with Core2 Duo T7600 processor. Any use of the VT-x (VirtualBox or KVM causes a complete system lockup).

If you install the KVM modules then the machine locks up during boot time.

These options work perfectly when I boot into the 8.10 Kernel.

Revision history for this message
PearZoo (peter4) wrote :

Here's my system info...

Revision history for this message
PearZoo (peter4) wrote :

and the pci stuff

Revision history for this message
PearZoo (peter4) wrote :

I've also tried the following:

Boot Live CD i386 - Install KVM and It Freezes as soon as the kvm_intel is loaded...
Boot Live CD 64 - Install KVM and It Freezes as soon as the kvm_intel is loaded...

All this works on 8.10 on my hardware

And when I run the same on an IBM Thinkpad T60 it works brilliantly...

Something about the Toshiba hardware and Jaunty that just don't agree when it comes to VT-x

Revision history for this message
PearZoo (peter4) wrote :

Okay found the problem!

It's the toshiba_acpi module, when loaded - all access to vt-x functionality will cause a system lock up.

Without it loaded, all works beautifully.

I will register this bug under toshiba_acpi

Revision history for this message
darthanubis (darthanubis) wrote : Re: [Bug 347487] Re: starting virtual machine in virtualbox-ose freezes system

On Fri, 2009-05-01 at 10:41 +0000, PearZoo wrote:
> Okay found the problem!
>
> It's the toshiba_acpi module, when loaded - all access to vt-x
> functionality will cause a system lock up.
>
> Without it loaded, all works beautifully.
>
> I will register this bug under toshiba_acpi
>
And what if your machine never loads or attempts to load this particular
module? Because I can see no such trace of this module loading.

Revision history for this message
PearZoo (peter4) wrote :

when i blacklist the toshiba_acpi module, and it doesn't load then all VT-x is fine

Revision history for this message
darthanubis (darthanubis) wrote :

On Fri, 2009-05-01 at 16:39 +0000, PearZoo wrote:
> when i blacklist the toshiba_acpi module, and it doesn't load then all
> VT-x is fine
>
Again, and for those of use who have not been loading toshiba_acpi
module all along is there a "fix" work around for us?

Revision history for this message
darthanubis (darthanubis) wrote :

I do not have nor have I ever had toshiba_acpi module load, and the issue of my PC locking up with VT enabled is STILL present. PearZoo is hasty in their conclusion me thinks? Can this bug get some attention please?

Revision history for this message
Don Zavitz (dzavitz) wrote :

running up to date karmic, on an amd x2 7750 cpu, 4gb ram

installed http://download.virtualbox.org/virtualbox/2.2.4/virtualbox-2.2_2.2.4-47978_Ubuntu_jaunty_amd64.deb freshly today

installed ubuntu 9.04 server fresh, and i am having 0 problems....

what hardware are you guys running?

Revision history for this message
Don Zavitz (dzavitz) wrote :

Linux cabo 2.6.30-8-generic #9-Ubuntu SMP Wed Jun 3 15:38:38 UTC 2009 x86_64 GNU/Linux

if your interested

Revision history for this message
darthanubis (darthanubis) wrote :

billybigrigger did NOT test this bug at all. Disregard his comments.

Revision history for this message
darthanubis (darthanubis) wrote :

I solved this for me. The cause, garbage BIOS (ver. P08)from XFX for my 680iLT. I had to use the BIOS for the board above mine (ver P33). Once I flashed to P33 BIOS for this board, ALL is well. P07 does not have the best Wolfdale support. P33 has the best support. I had no idea I had to use a BIOS that was NOT designed for my board in order to solve this issue for me.

Revision history for this message
Jason Straight (jason-jeetkunedomaster) wrote :

I have this problem with jaunty with an AMD processor. Without VT, everything is pretty stable, with VT the whole system locks up and usually kills the guest filesystem along with the lockup.

Revision history for this message
Kristian Rink (kawazu) wrote :

This problem still exists in lucid-prereleases with the virtualbox on my Tecra A8 (most up-to-date BIOS).

Revision history for this message
Kristian Rink (kawazu) wrote :

Looking at things, problem still persists, both using virtualbox-ose and the virtualbox.org builds in latest Lucid kernel. Anything to be done about that?

Revision history for this message
tankdriver (stoneraider-deactivatedaccount) wrote :

I have exactly the same Problem with my ASUS N90Sc Notebook as well, I found no way to do 64-bit virtualisation on Linux on this machine. I bet its a problem with the crap BIOS.
I contacted ASUS support, but they say they have no Linux support on this device.
I made already a BIOS update, because the original version was even more "crappier" (defraud 25% RAM, all OS)

Revision history for this message
PearZoo (peter4) wrote :

Try this:

What worked for me was to blacklist the Toshiba ACPI module by putting
this in the /etc/modprobe.d/blacklist.conf file

blacklist toshiba_acpi

You may not have a Toshiba nor use the toshiba-acpi, but perhaps the
equivalent acpi module cause the same issues? Try and find which acpi
modules you are using and then blacklist them. I'm no expert but that's
what worked for me.

Good luck

Mobile: +27 83 625 1856 Office: +27 11 234 6720 Fax: +27 86 521 7232
_This e-mail and any attachments may contain privileged and/or
confidential information. If you are not the intended recipient, you are
hereby notified that any dissemination, distribution or copying of the
information contained in this message is prohibited. If you have
received this message in error, please notify the sender by reply e-mail
and delete the message from your system. Any statements in this message
which do not relate to the business of Pear Zoo Marketing CC, are
neither given nor endorsed by Pear Zoo Marketing CC. Pear Zoo Marketing
CC is registered in South Africa - Company Reg No. 2005/030307/23 – Unit
7, Woodview Office Park, No 1 Humber Road, Woodmead, Johannesburg, South
Africa

On 06/07/10 13:33, Kristian Rink wrote:
> Looking at things, problem still persists, both using virtualbox-ose and
> the virtualbox.org builds in latest Lucid kernel. Anything to be done
> about that?
>
>

Revision history for this message
tankdriver (stoneraider-deactivatedaccount) wrote :

Thanks for your advice PearZoo, it did not help.
I found the equivalent module "asus_laptop" which handels the acpi-related stuff, and blacklisted it.
furthermore, I tried the boot option "acpi=off", both no success. (total freeze at VM start)

With the (host) boot options "noapic nolapic" I can (just one time) start the 64-bit guest VM , which immediately gets a kernel panic (error message). When I give it another try, total freeze.

Revision history for this message
Nathan Mccrina (nmccrina1) wrote :

Thought I'd weigh in because I guess this bug is still open even though the comments are from two years ago. Anyway, I am using the virtualbox package from Oracle and for the most part it works normally, I've had guests running for hours no problem. Every once in a while, though, I get the complete GUI freeze. Sometimes the guest has been running for a while, this last time it happened just as I was starting a guest. It's completely unpredictable.

uname -a
Linux FX6840 3.5.0-22-generic #34-Ubuntu SMP Tue Jan 8 21:47:00 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers