Bug 477842 - X fails to start in VMware VM
X fails to start in VMware VM
Status: CLOSED NEXTRELEASE
Product: Fedora
Classification: Fedora
Component: xorg-x11-drv-vmmouse (Show other bugs)
rawhide
All Linux
low Severity medium
: ---
: ---
Assigned To: Peter Hutterer
Fedora Extras Quality Assurance
: Patch
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-12-24 00:30 EST by Charlie Moschel
Modified: 2009-01-14 21:53 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-01-14 21:53:16 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Xorg.0.log -- autodetect, no xorg.conf file (75.31 KB, text/plain)
2008-12-24 00:38 EST, Charlie Moschel
no flags Details

  None (edit)
Description Charlie Moschel 2008-12-24 00:30:08 EST
Description of problem:
Current Rawhide now has ABI version 5 xorg video, but latest vmware_drv available is ABI version 4.  kdm & startx both hang with a black screen at startup.

Version-Release number of selected component (if applicable):

xorg-x11-drv-vmware-10.16.0-1.fc9.i386 (!)
xorg-x11-server-common-1.5.99.3-2.fc11.i386
xorg-x11-server-Xorg-1.5.99.3-2.fc11.i386


How reproducible:
Always 


Steps to Reproduce:
1. Update a vmware rawhide install to 22 or 23 Dec
2. Try to boot runlevel 5, or 3 then startx
3.
  
Actual results:
Hang at black screen

Expected results:
kdm starts up

Additional info:

(II) LoadModule: "vmware"
(II) Loading /usr/lib/xorg/modules/drivers//vmware_drv.so
(II) Module vmware: vendor="X.Org Foundation"
        compiled for 1.4.99.901, module version = 10.15.2
        Module class: X.Org Video Driver
        ABI class: X.Org Video Driver, version 4.0
(EE) module ABI major version (4) doesn't match the server's version (5)
(II) UnloadModule: "vmware"

For some reason, fallback to vesa does not work either: hangs in the same way, whether specified in xorg.conf or autodetected with no xorg.conf file.

Note, vesa fallback may be broken by mouse ABI version breakage I just noticed:

 LoadModule: "vmmouse"
(II) Loading /usr/lib/xorg/modules/input//vmmouse_drv.so
(II) Module vmmouse: vendor="X.Org Foundation"
        compiled for 1.5.99.3, module version = 12.6.2
        Module class: X.Org XInput Driver
        ABI class: X.Org XInput driver, version 4.0
(II) VMWARE(0): VMMOUSE module was loaded
(II) Loading sub module "mouse"
(II) LoadModule: "mouse"
(II) Loading /usr/lib/xorg/modules/input//mouse_drv.so
(II) Module mouse: vendor="X.Org Foundation"
        compiled for 1.4.99.901, module version = 1.3.0
        Module class: X.Org XInput Driver
        ABI class: X.Org XInput driver, version 2.0
(EE) module ABI major version (2) doesn't match the server's version (4)
(II) UnloadModule: "mouse"
(II) Unloading /usr/lib/xorg/modules/input//mouse_drv.so
(EE) Failed to load module "mouse" (module requirement mismatch, 0)
Comment 1 Charlie Moschel 2008-12-24 00:38:33 EST
Created attachment 327788 [details]
Xorg.0.log -- autodetect, no xorg.conf file

Logged x session, autodetected, no xorg.conf file.

vmware_drv is unloaded due to ABI mis-match, then VESA is loaded.

Vesa fallback appears to work (from the log), but the VM hangs with a black graphic screen: no pointer, no CTRL-ALT-F2, no numlock, etc.  VM is running though, I can ssh in.

Note the mouse breakage at the end of the log.
Comment 2 Charlie Moschel 2009-01-01 10:44:00 EST
OK, thanks for the quick vmware_drv.so update!  It fixes the screen driver ABI issue, but X is still hosed on this VM.  I see the screen size change, but it hangs with black screen & no pointer.  No X processes are left running.

mouse_drv.so ABI doesn't match as in above log (not sure why it's needed if vmmouse_drv.so is loaded ...).  'startx -- -ignoreABI' doesn't allow X to start.  

From an ssh session I see an interesting error (this doesn't appear in Xorg.0.log):

/usr/bin/X: symbol lookup error: /usr/lib/xorg/modules/input//vmmouse_drv.so: undefined symbol: xf86OSMouseInit

I will try to edit the bug title to be more accurate & refile against vmmouse_drv, but looks like both vmmouse_drv & mouse_drv need some love.
Comment 3 Charlie Moschel 2009-01-02 10:51:36 EST
Looks like this commit: 

http://cgit.freedesktop.org/xorg/driver/xf86-input-vmmouse/commit/?id=7cb41b467a161461627e6abf1ea979b7058d02f0
part of bumping vmmouse_drv to 12.6.3, would solve the "undefined symbol: xf86OSMouseInit" problem.

Not sure what what's needed for mouse_drv.so
Comment 4 Charlie Moschel 2009-01-07 01:00:47 EST
(In reply to comment #3)
> Looks like this commit: 
> 
> http://cgit.freedesktop.org/xorg/driver/xf86-input-vmmouse/commit/?id=7cb41b467a161461627e6abf1ea979b7058d02f0
> part of bumping vmmouse_drv to 12.6.3, would solve the "undefined symbol:
> xf86OSMouseInit" problem.

Well, rpm says vmmouse_drv 12.6.3 *is* installed, but the driver binary is still saying it's version 12.6.2.  I looked a little further, and the driver source in the SRPM has the 12.6.3 patch, including version bump in configure.ac, but version string is not bumped in src/vmmouse.c

[root@localhost ~]# rpm -qa | grep vmmouse
xorg-x11-drv-vmmouse-12.6.3-1.fc11.i386
[root@localhost ~]# rpm -V xorg-x11-drv-vmmouse
[root@localhost ~]# strings -a /usr/lib/xorg/modules/input/vmmouse_drv.so | grep version=
?version=12.6.2.0
[root@localhost ~]#

 LoadModule: "vmmouse"
(II) Loading /usr/lib/xorg/modules/input//vmmouse_drv.so
(II) Module vmmouse: vendor="X.Org Foundation"
        compiled for 1.5.99.3, module version = 12.6.2
        Module class: X.Org XInput Driver
        ABI class: X.Org XInput driver, version 4.0
(II) VMWARE(0): VMMOUSE module was loaded

(from vmmouse.c):
#define VMMOUSE_MAJOR_VERSION 12
#define VMMOUSE_MINOR_VERSION 6
#define VMMOUSE_PATCHLEVEL 2


Am I the only one who can't get X rawhide running in VMWare?
Comment 5 Peter Hutterer 2009-01-07 18:07:34 EST
did you update xorg-x11-drv-mouse too? vmmouse has a fallback where it just loads the plain mouse driver, so if it has an old driver there, that'd explain it.

what's the output of rpm -qa | grep xorg-x11-drv-mouse?
If you update the mouse driver, does it work then?

Could also be that something in the build didn't quite work and we have to run another one to fix this.
Comment 6 Charlie Moschel 2009-01-09 20:35:42 EST
(In reply to comment #5)
> did you update xorg-x11-drv-mouse too? 

Yes, it's up to date.

> what's the output of rpm -qa | grep xorg-x11-drv-mouse?

xorg-x11-drv-vmmouse-12.6.3-1.fc11.i386
(as per comment #4)

> If you update the mouse driver, does it work then?
> 
> Could also be that something in the build didn't quite work and we have to run
> another one to fix this.

Maybe.  I don't know if the 12.6.2 string in the binary means it really didn't get rebuild with the 12.6.3 changes, or if the 12.6.3 changes just missed a version string somewhere.
Comment 7 Peter Hutterer 2009-01-11 18:18:10 EST
> Maybe.  I don't know if the 12.6.2 string in the binary means it really didn't
> get rebuild with the 12.6.3 changes, or if the 12.6.3 changes just missed a
> version string somewhere.

The driver keeps separate defines from what configure.ac sets, and those defines didn't get updated with the last version bump. I just sent a patch to fix this to the maintainer, so that'll be gone soon.

I just updated xorg-x11-drv-mouse to 1.4.0, that should have fixed the ABI issue. Please try again with the update package.
Comment 8 Charlie Moschel 2009-01-14 21:43:12 EST
Thanks!  X runs again, pointer works & releases at window borders.

Up-to-date rawhide as of 14-Jan;  vmmouse_drv looks like it loads mouse_drv as a sub-module.  Both load OK.

AFAICT, this is OK to close, unless you want it open for the version string issue.

Note You need to log in before you can comment on or make changes to this bug.