Tiny Core Extensions > TCE Bugs
Problem with graphics drm modules
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: ---[ 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
--- End code ---
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: ---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
--- End code ---
open-vm-tools-10.2.5/services/plugins/resolutionSet/resolutionCommon.c looks for Xorg vmware driver version info:
--- Code: --- 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;
--- End code ---
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: ---[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).
--- End code ---
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: ---[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.
--- End code ---
When it fails I see this in /var/log/Xorg.0.log:
--- Code: ---[ 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.
--- End code ---
As opposed to when it works it looks like this:
--- Code: ---[ 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.
--- End code ---
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
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version