Description of problem: Version-Release number of selected component (if applicable): kernel-vserver-2.6.38.7-1.mga-1-1.mga1 VirtualBox 4.0.8, 4.0.10, mdv2010.1 x86_64 version obtained from virtualbox.org (w/ installed Extension Pack) How reproducible: Open the VirtualBox GUI, try to start existing VM or just try to open General Settings. Steps to Reproduce: 1. Get a mdv2010.2 installation 2. install VirtualBox, create a Windows-based VM 3, do a live update using urpmi from the command line, reboot. 4. See above (Installing the Extension Pack and recompiling the drivers via dkms does not seem to be a problem.) Background info: I used to work w/ kernel-vserver-2.6.38.4 compiled for mdv2010.2 (srpm obtained from cauldron) without any problems. After the live upgrade using urpmi, it is impossible to use VirtualBox--the application itself freezes and all other applications get slowed down by at least two orders of magnitude. According to htop, load average is >3 (no change after 8 hours). Apart from moving the mouse pointer (very jerky movements), there's not much you can do. Even after killing VirtualBox (for which you need hour-long patience!), the system stays unusable until reboot. This means that I am unable to use the existing VMs. (Since I actually use a number of VServers which are more important than the WindowsXP(32)/7(64)-VMs, using another kernel is not an option.) The problem might actually be related to the "usb/hardware detection stack"; there are two other situations where the system hangs for a short/medium/random(?) period of time which was not the case before the migration: -- connecting the mobile via USB in order to access the mounted filesystem freezes the system for a couple of seconds -- trying to view an image attached to an e-mail using thunderbird (which launches the external KDE viewer) once blocked the system for 5mins, once for >15mins (reboot). (This does not happen with "xv".) -- Could it be that the KDE application tries to scan all folders upon startup and even probes for USB devices?
I've just installed VirtualBox-4.0.10-72479-Linux_x86.run on my i586 system. The changelog is at http://www.virtualbox.org/wiki/Changelog I then installed the extpack, started an xp vm, and installed the guest additions. That's working ok here. For a 64 bit system get the VirtualBox-4.0.10-72479-Linux_amd64.run installation script.
CC: (none) => davidwhodgins
(In reply to comment #1) > I've just installed VirtualBox-4.0.10-72479-Linux_x86.run on my i586 system. > [...] > For a 64 bit system get the VirtualBox-4.0.10-72479-Linux_amd64.run > installation script. Using the ' generic' installer unfortunately doesn't solve the problem for me -- the system becomes unresponsive the moment you try to open General Settings or start a VM.
I finally managed to identify the culprit after browsing through lots of forums--it's the "nvidia" driver (which has been updated during the migration) AND the fact that I was using the Twinview mode. (OTOH, it's totally unrelated to the kernel, I tried several different ones.) As long as you do _not_ use Twinview mode, it also works with the "nvidia" driver; however, only the "nouveau" driver will allow me to use two TFTs in portrait mode and start both VirtualBox and Gwenview.
Source RPM: kernel-vserver-2.6.38.7-1.mga-1-1.mga1 => dkms-nvidia-current-*
Useful detail: I tried both the original nvidia driver which came with mga1 as well as v280.13 (cauldron srpm). The card in question is a "G73" (GeForce 7600 GS), the TFTs are two Iiyama AS4637 (shouldn't matter much).
Created attachment 723 [details] xorg.conf (used in conjunction w/ the "nvidia" driver, 2x1024x1280 screens in portrait mode)
Created attachment 724 [details] xorg.conf (used in conjunction w/ the "nouveau" driver, 2x1024x1280 screens in portrait mode)
Hi, as the nvidia drivers are proprietary software, there's little we can do about it. I guess the best is for you to continue testing with updated drivers, report the bug upstream, and keep us informed. Best regards.
Keywords: (none) => NEEDINFOCC: (none) => stormi
Hello what is the status of this bug ? (Virtualbox 4.0.14 is in updates)
(In reply to comment #8) > Hello what is the status of this bug ? (Virtualbox 4.0.14 is in updates) @ Markus is this bug still there with updated Virtualbox? Please reply this question above within two weeks from now, to avoid this bug being closed as OLD. Thank you.
CC: (none) => marja11
Since there are insufficient details provided in this report for us to investigate the issue further, and we have not received feedback to the information we have requested above, we will assume the problem was not reproducible, or has been fixed in one of the updates we have released for the reporter's distribution. Users who have experienced this problem are encouraged to upgrade to the latest update of their distribution, and if this issue turns out to still be reproducible in the latest update, please reopen this bug with additional information. Closing as OLD.
Status: NEW => RESOLVEDResolution: (none) => OLD