no VMs can be suspended in F12 x86_64

[karlkleinpaste]

With any recent F12 kernel (e.g. currently 2.6.31.12-174.2.3.fc12.x86_64), I am no longer able to suspend any VM. I have WinXP, Ubuntu, OpenSolaris, FreeBSD, and older Fedora guests, in both 32- and 64-bit flavors, and with various CPU options enabled (i.e. PAE/NX, IO APIC, nested paging). The log (attached) reports what appears to be normal suspend behavior ("changing state from SAVING to SUSPENDED"), followed 0.097sec later by changing from SUSPENDED to POWERING_OFF. It's not as though I personally had time in between to change my mind about what I wanted to see done with the VM.

[karlkleinpaste]

sample log of failure to suspend of WinXP VM in Fedora12 x86_64 host

[Frank Mehnert]

Can't see a problem in the logfile, the state transition looks correct. What is actual the problem? You are trying to suspend a VM, the VM is saved and there powered off. Isn't the VM marked as saved after that or what is the problem?

[karlkleinpaste]

The VM is momentarily (flashed on the screen) marked "Saved" and then immediately changes to "Aborted". On powering back up, it begins from a reboot -- there is no .sav file in Machines/WindowsXP/Snapshots/ containing the memory image. It is not an issue of lack of disc space to create the .sav; the filesystem has ~70G free.

[Frank Mehnert]

Aha, aborted means that it crashes when creating the saved state. You can help finding this bug by creating a ​core dump. Please contact me via private E-mail at frank _dot_ mehnert _at_ sun _dot_ com, I can tell you a server for uploading the core dump.

[Frank Mehnert]

Got your core dump. The crash is somewhere within an X11 function. Could you check if your F12 is up-to-date (seems not)?

[karlkleinpaste]

On the contrary, I'm somewhat fanatic about staying up to date, and yumex offers no new updates. If you'll tell me which packages are in question, I'll verify for you what package revisions are installed.

[karlkleinpaste]

So backtrace shows death in _XrmInternalStringToQuark, in /usr/lib64/libX11.so.6. That's from package libX11-1.3-1.fc12.x86_64. That's the original as distributed in F12, as seen at ​http://download.fedora.redhat.com/pub/fedora/linux/releases/12/Everything/x86_64/os/Packages/ and there are no newer versions at ​http://download.fedora.redhat.com/pub/fedora/linux/updates/12/x86_64/.

[karlkleinpaste]

New information... I noticed in the stack trace that it included use of /usr/lib64/nvidia/libGL.so.1. This package, xorg-x11-drv-nvidia-libs, was one which I installed not long ago in order that gnome-mplayer stop whining about its lack every time it begins playing a video. I never did understand why a package named for "nvidia" was needed on a machine (Lenovo T60p) with ATI display hardware.

When I move this one file out of the way, VBox can again save VMs. So it seems that there is a conflict between X11 and this library.

Regrets for the imprecise early report.

[Frank Mehnert]

Unfortunately the backtrace wasn't complete here although I installed a lot of missing debug packages. gdb complained that there are no debug symbols for nvidia but yum didn't find the debug symbols for nvidia. Where do your nvidia packages come from?

[karlkleinpaste]

​http://download1.rpmfusion.org/nonfree/fedora/updates/12/x86_64/repoview/xorg-x11-drv-nvidia-libs.html

gnome-mplayer needs libvdpau_nvidia, for no good reason I can identify. Renaming/removing this lib's libGL.so keeps VBox happy.

A pity that I didn't notice the time correlation between installing this package and VBox having trouble.

[Frank Mehnert]

Well, no I get a better backtrace but unfortunately nVidia didn't put debugging symbols for their libGL.so onto the server :-( What happens when you stop your VMs, are they aborted as well?

[karlkleinpaste]

With the bad libGL in place, saving aborts but just stopping via power-off ends normally, with the VM listed as "Powered off."

I've kept just the necessary libvdpau_nvidia for gnome-mplayer's sake, and moved the rest of it (/usr/lib64/nvidia) out of the way. Everything works now.

[Frank Mehnert]

Btw, #6250 applies to you as well (although not related to this problem).

[Frank Mehnert]

Still relevant?

[karlkleinpaste]

No, not relevant. I thought this would have been closed last March.

[Frank Mehnert]

Thanks.