Tiny Core Linux

Tiny Core Extensions => TCE Bugs => Topic started by: andyj on June 01, 2018, 02:51:14 PM

Title: Problem with graphics drm modules
Post by: andyj on June 01, 2018, 02:51:14 PM
I just updated all the extensions in my TC 9 32-bit VM. Now when I startx I get:

Code: [Select]
[   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.
Title: Re: Problem with graphics drm modules
Post by: Juanito on June 01, 2018, 11:30:36 PM
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?
Title: Re: Problem with graphics drm modules
Post by: andyj on June 02, 2018, 05:57:21 AM
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.
Title: Re: Problem with graphics drm modules
Post by: Juanito on June 03, 2018, 01:50:37 AM
'seems there's been a fix - updated extensions posted
Title: Re: Problem with graphics drm modules
Post by: andyj on June 03, 2018, 07:41:51 PM
Anything updated besides xf86-video-vmware.tcz? It still segfaults.
Title: Re: Problem with graphics drm modules
Post by: andyj on June 04, 2018, 05:40:17 AM
The changelog for xf86-video-vmware suggests that the drm kernel modules may need refreshing as well.
Title: Re: Problem with graphics drm modules
Post by: andyj on June 04, 2018, 10:09:09 AM
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:
Code: [Select]
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.
Title: Re: Problem with graphics drm modules
Post by: curaga on June 04, 2018, 10:59:15 AM
https://github.com/tinycorelinux/sorter has the kernel module sorting script.
Title: Re: Problem with graphics drm modules
Post by: andyj on June 04, 2018, 12:58:14 PM
Thanks. With the new kernel version and modules:

Code: [Select]
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:

Code: [Select]
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.
Title: Re: Problem with graphics drm modules
Post by: andyj on June 10, 2018, 07:35:32 PM
From dmesg, the problem appears to be in hsetroot, provided by Xlibs.tcz:

Code: [Select]
hsetroot[9089]: segfault at e4 ip 00000000004024fd sp 00007ffea22fbdb0 error 4 in hsetroot[400000+4000]
Does this need to be updated too?
Title: Re: Problem with graphics drm modules
Post by: curaga on June 10, 2018, 11:49:35 PM
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.
Title: Re: Problem with graphics drm modules
Post by: thane on June 12, 2018, 05:24:05 PM
See here:

http://forum.tinycorelinux.net/index.php/topic,20951.0.html
Title: Re: Problem with graphics drm modules
Post by: andyj on June 13, 2018, 05:40:44 AM
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.
Title: Re: Problem with graphics drm modules
Post by: Rich on June 13, 2018, 05:58:19 AM
Hi andyj
Here are a couple of ideas you can try. In the  .xsession  file, change this:
Code: [Select]
"$DESKTOP" 2>/tmp/wm_errors &to this:
Code: [Select]
"$DESKTOP" 2>/tmp/wm_errors
The other thing you could try is adding something like a 2 second delay prior to the  .setbackground  call.
Title: Re: Problem with graphics drm modules
Post by: Juanito on June 13, 2018, 06:41:45 AM
I updated hsetroot in CorePure64 Xlibs - it says it fixes a seg fault when the display is not present, maybe that will help?
Title: Re: Problem with graphics drm modules
Post by: andyj on June 13, 2018, 08:19:11 PM
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.
Title: Re: Problem with graphics drm modules
Post by: Juanito on June 14, 2018, 01:38:24 AM
Xlibs also updated in the x86 repo

Did you submit a bug report for xf86-video-vmware?
Title: Re: Problem with graphics drm modules
Post by: andyj on June 14, 2018, 10:52:21 AM
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.
Title: Re: Problem with graphics drm modules
Post by: Juanito on June 14, 2018, 11:36:00 PM
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?


Title: Re: Problem with graphics drm modules
Post by: andyj on June 15, 2018, 05:31:30 AM
"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.
Title: Re: Problem with graphics drm modules
Post by: Juanito on June 15, 2018, 07:07:03 AM
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..
Title: Re: Problem with graphics drm modules
Post by: andyj on June 15, 2018, 01:54:54 PM
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:

Code: [Select]
[drm] DX: yes.3D is detected.

Code: [Select]
[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:
Code: [Select]
[    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:
Code: [Select]
[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.

Title: Re: Problem with graphics drm modules
Post by: Juanito on June 16, 2018, 04:43:39 AM
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:
Code: [Select]
[   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...
Title: Re: Problem with graphics drm modules
Post by: andyj on June 16, 2018, 07:59:54 AM
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?
Title: Re: Problem with graphics drm modules
Post by: Juanito on June 17, 2018, 03:41:47 AM
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.
Title: Re: Problem with graphics drm modules
Post by: Juanito on June 18, 2018, 02:52:25 AM
I managed to get something with gdb, but I'm not sure whether this is a problem with xorg-server or xf86-video-vmware...

Code: [Select]
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
Title: Re: Problem with graphics drm modules
Post by: andyj on June 18, 2018, 11:15:13 AM
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.
Title: Re: Problem with graphics drm modules
Post by: curaga on June 18, 2018, 12:44:07 PM
This looks similar:
https://bugs.freedesktop.org/show_bug.cgi?id=106772
Title: Re: Problem with graphics drm modules
Post by: Juanito on June 19, 2018, 01:34:08 AM
Thanks for the suggestion, but it still segfaults after recompiling xorg-server with the patch
Title: Re: Problem with graphics drm modules
Post by: Juanito on June 19, 2018, 03:51:34 AM
accepted as a bug by freedesktop and assigned
Title: Re: Problem with graphics drm modules
Post by: andyj on June 19, 2018, 06:02:18 AM
Was freedesktop able to reproduce it, or are we not that far along yet?
Title: Re: Problem with graphics drm modules
Post by: Juanito on June 22, 2018, 01:09:11 AM
reproduced and elevated to high priority..
Title: Re: Problem with graphics drm modules
Post by: Juanito on July 05, 2018, 06:15:12 AM
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.
Title: Re: Problem with graphics drm modules
Post by: andyj on July 07, 2018, 07:14:27 AM
It works for me. I also checked resizing and multi-monitor switching, and they worked too.
Title: Re: Problem with graphics drm modules
Post by: Juanito on July 08, 2018, 01:10:33 AM
patched xorg-server posted to x86 and x86_64 repos
Title: Re: Problem with graphics drm modules
Post by: andyj on July 08, 2018, 04:15:38 PM
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
Title: Re: Problem with graphics drm modules
Post by: curaga on July 09, 2018, 01:30:16 AM
Timing-sensitive bug, but why modesetting, I thought you're using vmware? It mentions assert, so please try to catch the assert message too.
Title: Re: Problem with graphics drm modules
Post by: Juanito on July 09, 2018, 01:41:38 AM
The X devs mentioned that the bug would also affect modesetting (perhaps not fatally) as well as xf86-video-vmware.
Title: Re: Problem with graphics drm modules
Post by: andyj on July 09, 2018, 06:19:04 AM
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?
Title: Re: Problem with graphics drm modules
Post by: Juanito on July 10, 2018, 01:14:23 AM
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
Title: Re: Problem with graphics drm modules
Post by: andyj on July 10, 2018, 06:50:05 AM
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.