Tiny Core Linux
Tiny Core Extensions => TCE Bugs => Topic started by: andyj on June 01, 2018, 05:51:14 PM
-
I just updated all the extensions in my TC 9 32-bit VM. Now when I startx I get:
[ 981.227] (EE) Backtrace:
[ 981.227] (EE) 0: /usr/local/lib/xorg/Xorg (xorg_backtrace+0x43) [0x815d427]
[ 981.227] (EE) 1: /usr/local/lib/xorg/Xorg (0x8048000+0x140afb) [0x8188afb]
[ 981.228] (EE) 2: linux-gate.so.1 (__kernel_rt_sigreturn+0x0) [0xb7f09b20]
[ 981.228] (EE) 3: /usr/local/lib/xorg/Xorg (xf86DPMSSet+0x59) [0x81778a7]
[ 981.228] (EE) 4: /usr/local/lib/xorg/modules/drivers/vmware_drv.so (0xb7790000+0x7d1b) [0xb7797d1b]
[ 981.228] (EE) 5: /usr/local/lib/xorg/modules/drivers/vmware_drv.so (0xb7790000+0x10226) [0xb77a0226]
[ 981.228] (EE) 6: /usr/local/lib/xorg/modules/drivers/vmware_drv.so (0xb7790000+0x7de9) [0xb7797de9]
[ 981.228] (EE) 7: /usr/local/lib/xorg/Xorg (0x8048000+0x145595) [0x818d595]
[ 981.228] (EE) 8: /usr/local/lib/xorg/Xorg (0x8048000+0xabb29) [0x80f3b29]
[ 981.228] (EE) 9: /usr/local/lib/xorg/Xorg (0x8048000+0x123d1e) [0x816bd1e]
[ 981.228] (EE) 10: /usr/local/lib/xorg/Xorg (0x8048000+0x2c8d0) [0x80748d0]
[ 981.228] (EE) 11: /lib/libc.so.6 (__libc_start_main+0x156) [0xb7a317c6]
[ 981.228] (EE) 12: /usr/local/lib/xorg/Xorg (0x8048000+0x2c9c1) [0x80749c1]
[ 981.228] (EE)
[ 981.228] (EE) Segmentation fault at address 0x4e4550b7
I took the open-vm-tools out of onboot.lst, but still no luck. Dropping the graphics-4.14.10-tinycore.tcz so the drm modules aren't loaded keeps it from crashing. When loading graphics-4.14.10-tinycore.tcz but not loading xf86-video-vmware.tcz Xorg doesn't crash but all I get is a black screen. Seems like there is something about vmwgfx and drm modules Xorg doesn't like.
-
xf86-video-vmware was updated in both the x86 and x86_64 repos due to the xorg-server update.
Do you have the same problem in a 64bit vm?
-
I ran tce-update and it updated Xorg and some xf86 drivers in my 64-bit VM. It was working before, but yes, it segfaults now. At least I knew to start sshd and connect before I ran startx to see what happened this time ;) The VM isn't locked up, just the console is useless now.
-
'seems there's been a fix - updated extensions posted
-
Anything updated besides xf86-video-vmware.tcz? It still segfaults.
-
The changelog for xf86-video-vmware suggests that the drm kernel modules may need refreshing as well.
-
I build a 4.14.47 kernel using the TC 4.14.10 config file and a modules initrd and they boot OK it seems:
Linux version 4.14.47-tinycore64 (tc@box) (gcc version 7.2.0 (GCC)) #1 SMP Mon Jun 4 14:04:20 UTC 2018
Command line: BOOT_IMAGE=/boot/vmlinuz64-9asj loglevel=3 vga=791 syslog noswap nozswap text tce=sda1/tce64 lang=en_US.UTF-8 udev.children-max=24 initrd=/boot/rootfs64-9-0.gz,/boot/modules64-9asj.gz
...
NX (Execute Disable) protection: active
SMBIOS 2.4 present.
DMI: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 05/19/2017
Hypervisor detected: VMware
vmware: TSC freq read from hypervisor : 4089.757 MHz
vmware: Host bus clock speed read from hypervisor : 66000000 Hz
vmware: using sched offset of 3074896016 ns
...
To make the modules extensions, I'm assuming that they're based on certain directories, and not specific files in the module tree? I don't suppose these could be posted in http://tinycorelinux.net/9.x/x86_64/release/src/kernel/ (http://tinycorelinux.net/9.x/x86_64/release/src/kernel/)? I could mine each *4.14*.list file, but that seems like it would require some guessing and so my not have the desired outcome.
-
https://github.com/tinycorelinux/sorter has the kernel module sorting script.
-
Thanks. With the new kernel version and modules:
tc@box:/var/log$ uname -a
Linux box 4.14.47-tinycore64 #1 SMP Mon Jun 4 14:04:20 UTC 2018 x86_64 GNU/Linux
tc@box:/var/log$ lsmod
Module Size Used by Not tainted
vmwgfx 184320 1
ttm 57344 1 vmwgfx
drm_kms_helper 90112 1 vmwgfx
drm 225280 4 vmwgfx,ttm,drm_kms_helper
intel_agp 16384 1
intel_gtt 16384 1 intel_agp
agpgart 28672 4 ttm,drm,intel_agp,intel_gtt
i2c_piix4 16384 0
cpufreq_powersave 12288 0
cpufreq_userspace 12288 0
cpufreq_conservative 12288 0
vmw_vsock_vmci_transport 20480 1
squashfs 28672 0
zstd_decompress 77824 1 squashfs
xxhash 12288 1 zstd_decompress
pcspkr 12288 0
xhci_pci 12288 0
vmxnet3 40960 0
xhci_hcd 81920 1 xhci_pci
vmw_vmci 40960 1 vmw_vsock_vmci_transport
loop 20480 0
ac 12288 0
It still segfaults:
tc@box:/var/log$ cat Xorg.0.log
[ 16713.348]
X.Org X Server 1.20.0
X Protocol Version 11, Revision 0
[ 16713.348] Build Operating System: Linux 4.14.10-tinycore64 x86_64
[ 16713.348] Current Operating System: Linux box 4.14.47-tinycore64 #1 SMP Mon Jun 4 14:04:20 UTC 2018 x86_64
[ 16713.348] Kernel command line: BOOT_IMAGE=/boot/vmlinuz64-9asj loglevel=3 vga=791 syslog noswap nozswap text tce=sda1/tce64 lang=en_US.UTF-8 udev.children-max=24 initrd=/boot/rootfs64-9-0.gz,/boot/modules64-9asj.gz
[ 16713.348] Build Date: 29 May 2018 01:41:32PM
...
[ 16713.746] (EE) Backtrace:
[ 16713.746] (EE) 0: /usr/local/lib/xorg/Xorg (xorg_backtrace+0x49) [0x51b05c]
[ 16713.746] (EE) 1: /usr/local/lib/xorg/Xorg (0x400000+0x13bdf2) [0x53bdf2]
[ 16713.746] (EE) 2: /lib/libpthread.so.0 (0x7f2f89b20000+0x10030) [0x7f2f89b30030]
[ 16713.746] (EE) 3: /usr/local/lib/xorg/Xorg (0x400000+0x12d4a2) [0x52d4a2]
[ 16713.746] (EE) 4: /usr/local/lib/xorg/Xorg (RROutputIsLeased+0x14) [0x4c5c4e]
[ 16713.746] (EE) 5: /usr/local/lib/xorg/Xorg (xf86DPMSSet+0x54) [0x4cd2f8]
[ 16713.746] (EE) 6: /usr/local/lib/xorg/modules/drivers/vmware_drv.so (0x7f2f86348000+0x9b98) [0x7f2f86351b98]
[ 16713.746] (EE) 7: /usr/local/lib/xorg/modules/drivers/vmware_drv.so (0x7f2f86348000+0x1189c) [0x7f2f8635989c]
[ 16713.746] (EE) 8: /usr/local/lib/xorg/modules/drivers/vmware_drv.so (0x7f2f86348000+0x9c2e) [0x7f2f86351c2e]
[ 16713.746] (EE) 9: /usr/local/lib/xorg/Xorg (0x400000+0xcdce1) [0x4cdce1]
[ 16713.746] (EE) 10: /usr/local/lib/xorg/Xorg (0x400000+0x108bfc) [0x508bfc]
[ 16713.746] (EE) 11: /usr/local/lib/xorg/Xorg (0x400000+0x85631) [0x485631]
[ 16713.746] (EE) 12: /usr/local/lib/xorg/Xorg (0x400000+0x2de01) [0x42de01]
[ 16713.746] (EE) 13: /lib/libc.so.6 (__libc_start_main+0x15a) [0x7f2f88c6109d]
[ 16713.746] (EE) 14: /usr/local/lib/xorg/Xorg (_start+0x2a) [0x42defa]
[ 16713.746] (EE)
[ 16713.746] (EE) Segmentation fault at address 0x1000000b1
[ 16713.746] (EE)
Fatal server error:
[ 16713.746] (EE) Caught signal 11 (Segmentation fault). Server aborting
So the kernel module is (probably?) not it.
-
From dmesg, the problem appears to be in hsetroot, provided by Xlibs.tcz:
hsetroot[9089]: segfault at e4 ip 00000000004024fd sp 00007ffea22fbdb0 error 4 in hsetroot[400000+4000]
Does this need to be updated too?
-
No, that happens with other buggy drivers too, and can't cause an X crash. hsetroot crashes if X has not fully started when it runs, even though X claims to have started.
-
See here:
http://forum.tinycorelinux.net/index.php/topic,20951.0.html
-
See here:
http://forum.tinycorelinux.net/index.php/topic,20951.0.html
I don't see how this is relevant. X was working, I ran tce-update, and now it's not. Nothing else changed.
-
Hi andyj
Here are a couple of ideas you can try. In the .xsession file, change this:
"$DESKTOP" 2>/tmp/wm_errors &to this:
"$DESKTOP" 2>/tmp/wm_errors
The other thing you could try is adding something like a 2 second delay prior to the .setbackground call.
-
I updated hsetroot in CorePure64 Xlibs - it says it fixes a seg fault when the display is not present, maybe that will help?
-
I updated hsetroot in CorePure64 Xlibs - it says it fixes a seg fault when the display is not present, maybe that will help?
The segfault for hsetroot in dmesg does look to be fixed, but X still segfaults. A step in the right direction anyway.
-
Xlibs also updated in the x86 repo
Did you submit a bug report for xf86-video-vmware?
-
I created the following VMs:
OpenSUSE Tumbleweed, xf86-video-vmware 13.3.0 and Xorg 1.19.6, works.
Fedora Rawhide xf86-video-vmware 13.2.1 with Xorg 1.20.0 works.
Debian Sid, xf86-video-vmware 13.3.0 and Xorg 1.20.0, works.
Slackware-current, xf86-video-vmware 13.3.0 and Xorg 1.20.0 works.
I'm not convinced that it's a problem in xf86-video-vmware. It seems more likely that there is some other compile / library mismatch in TC.
-
Hardware-wise I can only test the modesetting, intel and vesa modules. I've also tested with qemu and virtualbox and I cannot make x fail with any of them.
If I understand correctly, there's no free version of vmware with which to test?
-
"VMware Player" is the free (lite) version of VMware Workstation and is what I am using. ESXi is the free bare-metal hypervisor for servers.
-
so, using VMware Workstation 14.1.2 Player with CorePure64
Xorg-7.7 works
+ graphics-KERNEL works
+ Xorg-7.7-3d works
+ xf86-input-vmmouse xf86-video-vmware hangs
It looks like there's either a problem with a lack of suitable gallium driver or that vmmouse conflicts with evdev's choice of mouse and x sits there waiting for an input device - see attached
The above being said, I never looked at a vmware log, so maybe this is normal..
-
In settings, click on Display and enable 3D if you haven't already. Then in dmesg you should have this to tell you that the kernel DRM has initialized:
[drm] DX: yes.3D is detected.
[drm] Initialized vmwgfx 2.14.0 20170612 for 0000:00:0f.0 on minor 0DRM is working.
I've been booting into text mode, starting sshd, and connecting from a host konsole window so I can startx manually in the VM console and see the system after X hangs.
In /var/log/Xorg.0.log:
[ 54.792] (II) vmware(0): Initialized VMWARE_CTRL extension version 0.2
[ 54.804] (II) vmware(0): Gallium3D XA version: 2.3.0.
[ 54.804] (WW) Gallium3D XA version insufficient for dri3.
[ 54.804] (II) vmware(0): Path of drm device is "/dev/dri/card0".
[ 54.804] (II) vmware(0): [DRI2] Setup complete
[ 54.804] (II) vmware(0): [DRI2] DRI driver: vmwgfx
[ 54.804] (--) vmware(0): Render acceleration is enabled.
[ 54.804] (==) vmware(0): Rendercheck mode is disabled.
[ 54.804] (--) vmware(0): Direct rendering (DRI2 3D) is enabled.
[ 54.804] (--) vmware(0): Direct rendering (DRI3 3D) is disabled.
Sid and Tumbleweed have the same version of Gallium, and the logs look the same, so it's apparently not a serious problem. Rawhide also has Gallium 2.3.0, but it's not trying to load dri3 so it doesn't complain about Gallium.
Even when I don't load vmmouse it still segfaults, so I don't think that's it either.
You can create /etc/vmware-tools/tools.conf to turn on some debugging:
[logging]
log = true
# Enable VMware Tools service logging to a file.
vmtoolsd.level = debug
vmtoolsd.handler = file
vmtoolsd.data = /var/log/vmtoold.log
# Enable "vmsvc" service logging to a file.
vmsvc.level = debug
vmsvc.handler = file
vmsvc.data = /var/log/vmsvc.log
# Enable new "vmusr" service logging to a file.
vmusr.level = debug
vmusr.handler = file
vmusr.data = /var/log/vmusr.${USER}.log
# Enable the "vmvss" snapshot service logging to a file.
vmvss.level = debug
vmvss.handler = file
vmvss.data = /var/log/vmvss.log
# Enable VMwareResolutinSet logging to a file
vmresset.level = debug
vmresset.handler = file
vmresset.data = /var/log/vmresset.log
But so far I haven't found that it has anything that could give some direction.
-
I wasn't aware that 3d graphics needed to be switched on in vmware - yes, it seems to work, even with xf86-input-vmmouse, but without xf86-video-vmware.
As soon as xf86-video-vmware is added: [ 739.736] (EE) Backtrace:
[ 739.742] (EE) 0: /usr/local/lib/xorg/Xorg (xorg_backtrace+0x49) [0x51b05c]
[ 739.742] (EE) 1: /usr/local/lib/xorg/Xorg (0x400000+0x13bdf2) [0x53bdf2]
[ 739.742] (EE) 2: /lib/libpthread.so.0 (0x7f39b4fe8000+0x10030) [0x7f39b4ff8030]
[ 739.743] (EE) 3: /usr/local/lib/xorg/Xorg (0x400000+0x12d4a2) [0x52d4a2]
[ 739.743] (EE) 4: /usr/local/lib/xorg/Xorg (RROutputIsLeased+0x14) [0x4c5c4e]
[ 739.743] (EE) 5: /usr/local/lib/xorg/Xorg (xf86DPMSSet+0x54) [0x4cd2f8]
[ 739.743] (EE) 6: /usr/local/lib/xorg/modules/drivers/vmware_drv.so (0x7f39b1876000+0x9b98) [0x7f39b187fb98]
[ 739.743] (EE) 7: /usr/local/lib/xorg/modules/drivers/vmware_drv.so (0x7f39b1876000+0x1189c) [0x7f39b188789c]
[ 739.743] (EE) 8: /usr/local/lib/xorg/modules/drivers/vmware_drv.so (0x7f39b1876000+0x9c2e) [0x7f39b187fc2e]
[ 739.743] (EE) 9: /usr/local/lib/xorg/Xorg (0x400000+0xcdce1) [0x4cdce1]
[ 739.743] (EE) 10: /usr/local/lib/xorg/Xorg (0x400000+0x108bfc) [0x508bfc]
[ 739.743] (EE) 11: /usr/local/lib/xorg/Xorg (0x400000+0x85631) [0x485631]
[ 739.743] (EE) 12: /usr/local/lib/xorg/Xorg (0x400000+0x2de01) [0x42de01]
[ 739.743] (EE) 13: /lib/libc.so.6 (__libc_start_main+0x15a) [0x7f39b414509d]
[ 739.743] (EE) 14: /usr/local/lib/xorg/Xorg (_start+0x2a) [0x42defa]
[ 739.743] (EE)
[ 739.743] (EE) Segmentation fault at address 0x1000000b1
[ 739.743] (EE)
Fatal server error:
[ 739.743] (EE) Caught signal 11 (Segmentation fault). Server aborting
[ 739.743] (EE)
Now I guess the trick is to add gdb to the mix somehow, but it would seem to merit an xf86-video-vmware bug report...
-
Might be a bug, but my guess is the developers of X and all the other libraries are using a distro other than TC. I was unable to reproduce the problem in four other distros, i.e., it works as expected, so it might be a tough sell. Are we sure all the parts are compiled to the same ABI?
-
If you mean the new xorg-server abi, then only xf86-input* and xf86-video* need recompiling against it and Xorg.0.log gives an error for any drivers compiled against the wrong abi.
-
I managed to get something with gdb, but I'm not sure whether this is a problem with xorg-server or xf86-video-vmware...
0x000000000050fbfe in dixGetPrivate (privates=0x1b740d0,
key=0x8d2840 <rrPrivKeyRec>) at ../include/privates.h:136
No locals.
#1 0x000000000050fc46 in dixLookupPrivate (privates=0x1b740d0,
key=0x8d2840 <rrPrivKeyRec>) at ../include/privates.h:166
No locals.
#2 0x000000000050ffa0 in RROutputIsLeased (output=0x1b73720) at rrlease.c:124
screen = 0x1b73d00
scr_priv = 0x1b6eeb0
lease = 0x1b6f010
o = 3
#3 0x0000000000585de8 in xf86DPMSSet (scrn=0x1aee340, mode=3, flags=0)
at xf86Crtc.c:2967
output = 0x1af8bc0
config = 0x1aef650
i = 5
#4 0x00007f4b70b812cb in vmwgfx_disable_scanout (pScrn=0x1aee340)
at vmwgfx_crtc.c:115
i = 0
save_enabled = 0
crtc = 0x0
config = 0x1aef650
#5 0x00007f4b70b80f35 in drv_leave_vt (arg=0x1aee340) at vmwgfx_driver.c:1271
pScrn = 0x1aee340
ms = 0x1aeea60
#6 0x00007f4b70b81111 in drv_close_screen (pScreen=0x1aed440)
at vmwgfx_driver.c:1327
pScrn = 0x1aee340
ms = 0x1aeea60
#7 0x000000000052d93f in RRCloseScreen (pScreen=0x1aed440) at randr.c:108
pScrPriv = 0x1b6eeb0
j = -1
#8 0x0000000000580a44 in xf86CrtcCloseScreen (screen=0x1aed440)
at xf86Crtc.c:743
scrn = 0x1aee340
config = 0x1aef650
o = 0
c = 0
#9 0x00000000005d4a07 in DGACloseScreen (pScreen=0x1aed440) at xf86DGA.c:288
pScreenPriv = 0x1b761c0
#10 0x00000000005bcbd1 in CMapCloseScreen (pScreen=0x1aed440) at xf86cmap.c:250
No locals.
#11 0x0000000000551644 in XvCloseScreen (pScreen=0x1aed440) at xvmain.c:309
pxvs = 0x1b75bd0
#12 0x00000000005a7573 in xf86XVCloseScreen (pScreen=0x1aed440)
at xf86xv.c:1168
pScrn = 0x1aee340
pxvs = 0x1b75bd0
ScreenPriv = 0x1afbee0
pa = 0x1b85290
c = 2
#13 0x000000000046fdd6 in SyncCloseScreen (pScreen=0x1aed440) at misync.c:156
pScreenPriv = 0x1c47758
#14 0x000000000055e809 in CursorCloseScreen (pScreen=0x1aed440) at cursor.c:205
cs = 0x1c0ce80
ret = 32766
close_proc = 0x55e77d <CursorCloseScreen>
display_proc = 0x55e599 <CursorDisplayCursor>
#15 0x00000000004f226d in AnimCurCloseScreen (pScreen=0x1aed440)
at animcur.c:100
as = 0x1c47778
ret = 0
#16 0x0000000000559660 in compCloseScreen (pScreen=0x1aed440) at compinit.c:86
cs = 0x1b85020
ret = 0
#17 0x00000000004f4f04 in present_close_screen (screen=0x1aed440)
at present_screen.c:70
screen_priv = 0x1c0db60
#18 0x00007f4b72fe0e76 in glxCloseScreen (pScreen=0x1aed440)
at glxscreens.c:171
pGlxScreen = 0x1c0e030
#19 0x00000000006176a5 in dix_main (argc=3, argv=0x7ffe301caa28,
envp=0x7ffe301caa48) at main.c:325
i = 0
alwaysCheckForInput = {0, 1}
#20 0x000000000061e67a in main (argc=3, argv=0x7ffe301caa28,
envp=0x7ffe301caa48) at stubmain.c:34
No locals.
(EE)
(EE) Backtrace:
(EE) 0: /usr/local/lib/xorg/Xorg (xorg_backtrace+0xb0) [0x431177]
(EE) 1: /usr/local/lib/xorg/Xorg (0x400000+0x35f40) [0x435f40]
(EE) 2: /lib/libpthread.so.0 (0x7f4b742ff000+0x10030) [0x7f4b7430f030]
(EE) 3: /usr/local/lib/xorg/Xorg (0x400000+0x10fbfe) [0x50fbfe]
(EE) 4: /usr/local/lib/xorg/Xorg (0x400000+0x10fc46) [0x50fc46]
(EE) 5: /usr/local/lib/xorg/Xorg (RROutputIsLeased+0x35) [0x50ffa0]
(EE) 6: /usr/local/lib/xorg/Xorg (xf86DPMSSet+0x86) [0x585de8]
(EE) 7: /usr/local/lib/xorg/modules/drivers/vmware_drv.so (0x7f4b70b5e000+0x232cb) [0x7f4b70b812cb]
(EE) 8: /usr/local/lib/xorg/modules/drivers/vmware_drv.so (0x7f4b70b5e000+0x22f35) [0x7f4b70b80f35]
(EE) 9: /usr/local/lib/xorg/modules/drivers/vmware_drv.so (0x7f4b70b5e000+0x23111) [0x7f4b70b81111]
(EE) 10: /usr/local/lib/xorg/Xorg (0x400000+0x12d93f) [0x52d93f]
(EE) 11: /usr/local/lib/xorg/Xorg (0x400000+0x180a44) [0x580a44]
(EE) 12: /usr/local/lib/xorg/Xorg (0x400000+0x1d4a07) [0x5d4a07]
(EE) 13: /usr/local/lib/xorg/Xorg (0x400000+0x1bcbd1) [0x5bcbd1]
(EE) 14: /usr/local/lib/xorg/Xorg (0x400000+0x151644) [0x551644]
(EE) 15: /usr/local/lib/xorg/Xorg (0x400000+0x1a7573) [0x5a7573]
(EE) 16: /usr/local/lib/xorg/Xorg (0x400000+0x6fdd6) [0x46fdd6]
(EE) 17: /usr/local/lib/xorg/Xorg (0x400000+0x15e809) [0x55e809]
(EE) 18: /usr/local/lib/xorg/Xorg (0x400000+0xf226d) [0x4f226d]
(EE) 19: /usr/local/lib/xorg/Xorg (0x400000+0x159660) [0x559660]
(EE) 20: /usr/local/lib/xorg/Xorg (0x400000+0xf4f04) [0x4f4f04]
(EE) 21: /usr/local/lib/xorg/modules/extensions/libglx.so (0x7f4b72fcf000+0x11e76) [0x7f4b72fe0e76]
(EE) 22: /usr/local/lib/xorg/Xorg (0x400000+0x2176a5) [0x6176a5]
(EE) 23: /usr/local/lib/xorg/Xorg (0x400000+0x21e67a) [0x61e67a]
(EE) 24: /lib/libc.so.6 (__libc_start_main+0x15a) [0x7f4b7345c09d]
(EE) 25: /usr/local/lib/xorg/Xorg (_start+0x2a) [0x420c3a]
(EE)
(EE) Segmentation fault at address 0x1000000b1
(EE)
Fatal server error:
(EE) Caught signal 11 (Segmentation fault). Server aborting
-
I noticed that when I compared the old and new vmware_drv.so, libudev.so.0 is a new dependency. It seems to me that either it's trying to do something it wasn't doing before that is available on other distros but not TC, or it's doing something it was doing before but is doing it differently now. Or, the udev dependency shouldn't be there at all and a new configure option needs to be turned on or off when building? When I compare the ldd results to other distros I see other slight differences too, but nothing that jumps out for attention.
-
This looks similar:
https://bugs.freedesktop.org/show_bug.cgi?id=106772
-
Thanks for the suggestion, but it still segfaults after recompiling xorg-server with the patch
-
accepted as a bug by freedesktop and assigned
-
Was freedesktop able to reproduce it, or are we not that far along yet?
-
reproduced and elevated to high priority..
-
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.
-
It works for me. I also checked resizing and multi-monitor switching, and they worked too.
-
patched xorg-server posted to x86 and x86_64 repos
-
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.
[ 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
-
Timing-sensitive bug, but why modesetting, I thought you're using vmware? It mentions assert, so please try to catch the assert message too.
-
The X devs mentioned that the bug would also affect modesetting (perhaps not fatally) as well as xf86-video-vmware.
-
Recent versions of vmtools use KMS, or at least tries when it loads the plugins:
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:
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?
[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:
[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:
[ 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:
[ 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?
-
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
-
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:
[ 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:
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:
[ 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:
[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:
:[Jul 10 12:51:00.856] [ info] [vmtoolsd] Plugin 'libresolutionSet.so' didn't provide deployment data, unloading.