Problem with graphics drm modules

[andyj]

Was freedesktop able to reproduce it, or are we not that far along yet?

[Juanito]

reproduced and elevated to high priority..

[Juanito]

A couple of patches have been produced, which seem to fix the problem for me.

@andyj - I sent you a pm with a link to test before I post a new xorg-server extension.

[andyj]

It works for me. I also checked resizing and multi-monitor switching, and they worked too.

[Juanito]

patched xorg-server posted to x86 and x86_64 repos

[andyj]

Now to make it more confusing. I've updated xorg-server, and now if the window is maximized when it boots I see the desktop for a little bit, then X aborts. If I add a sleep 10 before the startx command in .profile, or if the window size isn't maximized from boot (so that it remains vga=791 size), or if I boot to text then startx manually, it works OK. I can resize/maximize it once it is running without problems. This is on 64-bit, I haven't tried 32-bit yet.

Code: [Select]

[    27.202] (EE) Backtrace:
[    27.202] (EE) 0: /usr/local/lib/xorg/Xorg (xorg_backtrace+0x49) [0x51b183]
[    27.202] (EE) 1: /usr/local/lib/xorg/Xorg (0x400000+0x13bf19) [0x53bf19]
[    27.202] (EE) 2: /lib/libpthread.so.0 (0x7fc19bd28000+0x10030) [0x7fc19bd38030]
[    27.202] (EE) 3: /lib/libc.so.6 (gsignal+0xbb) [0x7fc19ae7885e]
[    27.202] (EE) 4: /lib/libc.so.6 (abort+0x139) [0x7fc19ae7999d]
[    27.202] (EE) 5: /lib/libc.so.6 (__assert_fail+0x0) [0x7fc19ae728fe]
[    27.202] (EE) 6: /lib/libc.so.6 (__assert_perror_fail+0x0) [0x7fc19ae72942]
[    27.202] (EE) 7: /usr/local/lib/xorg/Xorg (dixRegisterPrivateKey+0xc8) [0x4681f9]
[    27.202] (EE) 8: /usr/local/lib/xorg/modules/libglamoregl.so (glamor_init+0xba) [0x7fc1916b51ce]
[    27.202] (EE) 9: /usr/local/lib/xorg/modules/drivers/modesetting_drv.so (0x7fc1918d0000+0xe26c) [0x7fc1918de26c]
[    27.202] (EE) 10: /usr/local/lib/xorg/Xorg (AddGPUScreen+0x104) [0x431d55]
[    27.202] (EE) 11: /usr/local/lib/xorg/Xorg (0x400000+0x47c92) [0x447c92]
[    27.202] (EE) 12: /usr/local/lib/xorg/Xorg (0x400000+0x48527) [0x448527]
[    27.202] (EE) 13: /usr/local/lib/xorg/Xorg (0x400000+0x476b8) [0x4476b8]
[    27.202] (EE) 14: /usr/local/lib/xorg/Xorg (0x400000+0x4799d) [0x44799d]
[    27.202] (EE) 15: /usr/local/lib/xorg/Xorg (0x400000+0x13f916) [0x53f916]
[    27.202] (EE) 16: /usr/local/lib/xorg/Xorg (WaitForSomething+0xd8) [0x520200]
[    27.202] (EE) 17: /usr/local/lib/xorg/Xorg (0x400000+0x2d9d6) [0x42d9d6]
[    27.202] (EE) 18: /lib/libc.so.6 (__libc_start_main+0x15a) [0x7fc19ae6909d]
[    27.202] (EE) 19: /usr/local/lib/xorg/Xorg (_start+0x2a) [0x42defa]
[    27.202] (EE)
[    27.202] (EE)
Fatal server error:
[    27.202] (EE) Caught signal 6 (Aborted). Server aborting


[curaga]

Timing-sensitive bug, but why modesetting, I thought you're using vmware? It mentions assert, so please try to catch the assert message too.

[Juanito]

The X devs mentioned that the bug would also affect modesetting (perhaps not fatally) as well as xf86-video-vmware.

[andyj]

Recent versions of vmtools use KMS, or at least tries when it loads the plugins:

Code: [Select]

tc@box:~$ find /usr/local/lib/open-vm-tools/plugins
/usr/local/lib/open-vm-tools/plugins
/usr/local/lib/open-vm-tools/plugins/vmusr
/usr/local/lib/open-vm-tools/plugins/vmusr/libresolutionSet.so
/usr/local/lib/open-vm-tools/plugins/vmusr/libdndcp.so
/usr/local/lib/open-vm-tools/plugins/vmusr/libdesktopEvents.so
/usr/local/lib/open-vm-tools/plugins/vmsvc
/usr/local/lib/open-vm-tools/plugins/vmsvc/libvmbackup.so
/usr/local/lib/open-vm-tools/plugins/vmsvc/libtimeSync.so
/usr/local/lib/open-vm-tools/plugins/vmsvc/libresolutionKMS.so
/usr/local/lib/open-vm-tools/plugins/vmsvc/libpowerOps.so
/usr/local/lib/open-vm-tools/plugins/vmsvc/libguestInfo.so
/usr/local/lib/open-vm-tools/plugins/vmsvc/libgrabbitmqProxy.so
/usr/local/lib/open-vm-tools/plugins/vmsvc/libdeployPkgPlugin.so
/usr/local/lib/open-vm-tools/plugins/common
/usr/local/lib/open-vm-tools/plugins/common/libvix.so
/usr/local/lib/open-vm-tools/plugins/common/libhgfsServer.so

open-vm-tools-10.2.5/services/plugins/resolutionSet/resolutionCommon.c looks for Xorg vmware driver version info:
 

Code: [Select]

   g_debug("%s: Scanning for VMWare Xorg drivers.\n", __func__);               
   for(i = 0; i < numPaths; ++i) {                                             
       g_debug("%s: Looking for \"%s\".\n", __func__, paths[i]);               
       driver = fopen(paths[i], "r");                                         
       if (driver)                                                             
           break;                                                             
   }                                                                           
                                                                               
   if (!driver) {                                                             
       g_debug("%s: No driver found.\n",  __func__);                           
       return -1;                                                               
   }                                                                           
                                                                               
   g_debug("%s: Driver found. Looking for version info.\n", __func__);         
   curMatch = versionString;                                                   
   while (*curMatch) {                                                         
      if (feof(driver))                                                         
         goto outNotFound;                                                     
                                                                               
      curFileChar = fgetc(driver);                                             
      if (curFileChar == *curMatch) {                                         
         curMatch++;                                                           
         continue;                                                             
      } else if (curMatch != versionString) {                                 
         curMatch = versionString;                                             
         (void) ungetc(curFileChar, driver);                                   
      }                                                                       
   }                                                                           
                                                                               
   if (fscanf(driver, "%d.%d.%d", major, minor, level) != 3)                   
      goto outNotFound;                                                       
                                                                               
   fclose(driver);                                                             
   g_debug("%s: Version info found: %d.%d.%d\n", __func__, *major, *minor,     
           *level);                                                             
   return 0;                                                                   
                                                                               
 outNotFound:                                                                   
   fclose(driver);                                                             
   g_debug("%s: No version info found.\n", __func__);                         
   return -1;                                                                   

But I get this in /var/log/vmusr.tc.log. Would stripping cause this? Is there an unstripped version of vmware_drv.so I could try?

Code: [Select]

[Jul 09 12:44:24.450] [   debug] [resolutionCommon] resolutionXorgDriverVersion: Scanning for VMWare Xorg drivers.
[Jul 09 12:44:24.450] [   debug] [resolutionCommon] resolutionXorgDriverVersion: Looking for "/usr/local/lib/xorg/modules/drivers/vmware_drv.so".
[Jul 09 12:44:24.450] [   debug] [resolutionCommon] resolutionXorgDriverVersion: Driver found. Looking for version info.
[Jul 09 12:44:24.451] [   debug] [resolutionCommon] resolutionXorgDriverVersion: No version info found.
[Jul 09 12:44:24.451] [   debug] [resolutionCommon] resolutionCheckForKMS: ResolutionKMS disabled. (No configuration).

In any event I didn't see any other error message related info in Xorg.0.log. What I posted before is all there was. I did find this at the end of /var/log/vmusr.tc.log:

Code: [Select]

[Jul 09 12:25:25.061] [   debug] [vmusr] RpcIn: received 23 bytes, content:"Resolution_Set 1918 931"
[Jul 09 12:25:25.061] [   debug] [resolutionSet] Setting guest resolution to: 1176x885 (requested: 1918, 931)
[Jul 09 12:25:25.305] [   debug] [resolutionSet] XRRSetScreenConfig returned 0 (result: 1176x885)
[Jul 09 12:25:25.309] [   debug] [vmusr] RpcIn: sending 23 bytes
[Jul 09 12:25:28.532] [   debug] [desktopEvents] DEXIOErrorHandler
[Jul 09 12:25:28.532] [ message] [desktopEvents] Emitting tcs_de_xioerror due to X I/O error.

When it fails I see this in /var/log/Xorg.0.log:

Code: [Select]

[    21.903] (II) vmware: driver for VMware SVGA: vmware0405, vmware0710
[    21.903] (II) modesetting: Driver for Modesetting Kernel Drivers: kms
[    21.903] (II) VESA: driver for VESA chipsets: vesa
[    21.903] (--) using VT number 2

[    21.905] (WW) Falling back to old probe method for modesetting
[    21.905] (EE) open /dev/dri/card0: No such file or directory
[    21.905] (II) vmware(0): Creating default Display subsection in Screen section
        "Default Screen Section" for depth/fbbpp 24/32
[    23.513] (EE) vmware(0): Failed to open drm.
[    23.513] (WW) vmware(0): Disabling 3D support.
[    23.513] (WW) vmware(0): Disabling Render Acceleration.
[    23.513] (WW) vmware(0): Disabling RandR12+ support.

As opposed to when it works it looks like this:

Code: [Select]

[    46.937] (II) vmware: driver for VMware SVGA: vmware0405, vmware0710
[    46.937] (II) modesetting: Driver for Modesetting Kernel Drivers: kms
[    46.937] (II) VESA: driver for VESA chipsets: vesa
[    46.938] (--) using VT number 2

[    46.941] (WW) Falling back to old probe method for modesetting
[    46.941] (II) vmware(0): Creating default Display subsection in Screen section
        "Default Screen Section" for depth/fbbpp 24/32
[    46.941] (--) vmware(0): DRM driver version is 2.14.0
[    46.941] (==) vmware(0): Depth 24, (--) framebuffer bpp 32
[    46.941] (==) vmware(0): RGB weight 888
[    46.941] (==) vmware(0): Default visual is TrueColor
[    46.941] (--) vmware(0): Min width 1, Max Width 8192.
[    46.941] (--) vmware(0): Min height 1, Max Height 8192.

So we probably need to wait for udev? Is there a right way to do this, or do we just loop and sleep and wait for /dev/dri/card0 to exist or eventually give up?

[Juanito]

I started X multiple times in the vm with xf-86-input-vmmouse and xf86-video-vmware and vmware comes up as the driver used every time.

Maybe your hardware is faster than mine?

Maybe the problem is with open-vm-tools?

Xorg.0.log attached

[andyj]

From your log, either it takes 10 minutes for your system to boot or you ran startx manually 10 minutes after it booted. In graphical mode, speed can be a problem:

Code: [Select]

[    21.817]
X.Org X Server 1.20.0
X Protocol Version 11, Revision 0
...
[    21.905] (EE) open /dev/dri/card0: No such file or directory
...
[    23.513] (EE) vmware(0): Failed to open drm.
I updated startx with this in .profile:

Code: [Select]

TERMTYPE=`/usr/bin/tty`
[ ${TERMTYPE:5:3} == "tty" ] && (
[ ! -f /etc/sysconfig/Xserver ] ||
[ -f /etc/sysconfig/text ] ||
[ -e /tmp/.X11-unix/X0 ] ||
(
for waited in $(seq 10 -1 0); do
  [ -c /dev/dri/card0 ] && break
  echo "waiting for /dev/dri/card0 $waited"
  sleep 1
done
[ $waited -gt 0 ] && (sleep 1; startx)
)
)

Typically it waits 5 seconds. Adding the delay gets it working, although looping and waiting seems more like a fix than a solution:

Code: [Select]

[    28.764]
X.Org X Server 1.20.0
X Protocol Version 11, Revision 0
...
[    28.857] (--) vmware(0): DRM driver version is 2.14.0
I do think that requiring a non-stripped binary is a (design) problem, and the wrong way to get a version number. That's what functions are for. I verified this by adding /usr/lib64/xorg/modules/drivers as a search path in open-vm-tools. I copied a non-stripped version of vmware_drv.so from my host to enable KMS:

Code: [Select]

[Jul 10 12:51:00.735] [   debug] [resolutionCommon] resolutionXorgDriverVersion: Scanning for VMWare Xorg drivers.
[Jul 10 12:51:00.735] [   debug] [resolutionCommon] resolutionXorgDriverVersion: Looking for "/usr/lib64/xorg/modules/drivers/vmware_drv.so".
[Jul 10 12:51:00.735] [   debug] [resolutionCommon] resolutionXorgDriverVersion: Driver found. Looking for version info.
[Jul 10 12:51:00.737] [   debug] [resolutionCommon] resolutionXorgDriverVersion: Version info found: 13.3.0
[Jul 10 12:51:00.737] [   debug] [resolutionCommon] resolutionCheckForKMS: ResolutionKMS enabled based on Xorg driver version.
[Jul 10 12:51:00.737] [ message] [resolutionCommon] resolutionCheckForKMS: dlopen succeeded.
[Jul 10 12:51:00.856] [ message] [resolutionCommon] resolutionCheckForKMS: System support available for resolutionKMS.
[Jul 10 12:51:00.856] [ message] [resolutionSet] ResolutionToolkitInit: Backing off for resolutionKMS.

But then autofit doesn't work because the plugin manager doesn't like it so one more thing to chase:

Code: [Select]

:[Jul 10 12:51:00.856] [    info] [vmtoolsd] Plugin 'libresolutionSet.so' didn't provide deployment data, unloading.