You are not logged in.
After recent updates (hard to say exactly which, because I am using DisplayLink only at work), DisplayLink stopped working and is crashing X11 session after plugging in DL (or if laptop is started with plugged in DL cable)
[ 18.701] (II) Module glamoregl: vendor="X.Org Foundation"
[ 18.702] compiled for 1.18.4, module version = 1.0.0
[ 18.702] ABI class: X.Org ANSI C Emulation, version 0.4
[ 18.702] (II) glamor: OpenGL accelerated X.org driver based.
[ 18.703] (EE)
[ 18.703] (EE) Backtrace:
[ 18.703] (EE) 0: /usr/lib/xorg-server/Xorg (OsLookupColor+0x139) [0x59cd49]
[ 18.707] (EE) 1: /usr/lib/libc.so.6 (__restore_rt+0x0) [0x7f8c48ff40af]
[ 18.707] (EE) 2: /usr/lib/libgbm.so.1 (gbm_surface_has_free_buffers+0x1505) [0x7f8c3fb798f5]
[ 18.707] (EE) 3: /usr/lib/libgbm.so.1 (gbm_surface_has_free_buffers+0x1b98) [0x7f8c3fb7a628]
[ 18.707] (EE) 4: /usr/lib/libgbm.so.1 (gbm_surface_has_free_buffers+0x1498) [0x7f8c3fb79738]
[ 18.708] (EE) 5: /usr/lib/libgbm.so.1 (gbm_create_device+0x4c) [0x7f8c3fb76cbc]
[ 18.708] (EE) 6: /usr/lib/xorg/modules/libglamoregl.so (glamor_egl_init+0x81) [0x7f8c3fdb8151]
[ 18.708] (EE) 7: /usr/lib/xorg/modules/drivers/modesetting_drv.so (_init+0x3cc0) [0x7f8c3fff1af0]
[ 18.708] (EE) 8: /usr/lib/xorg-server/Xorg (xf86PlatformMatchDriver+0x706) [0x4972d6]
[ 18.708] (EE) 9: /usr/lib/xorg-server/Xorg (xf86PlatformDeviceCheckBusID+0x201) [0x49cae1]
[ 18.708] (EE) 10: /usr/lib/xorg-server/Xorg (config_fini+0xa17) [0x4991e7]
[ 18.708] (EE) 11: /usr/lib/xorg-server/Xorg (config_fini+0x13e8) [0x49a658]
[ 18.709] (EE) 12: /usr/lib/xorg-server/Xorg (WakeupHandler+0x6d) [0x43b2dd]
[ 18.709] (EE) 13: /usr/lib/xorg-server/Xorg (WaitForSomething+0x1e9) [0x5954f9]
[ 18.709] (EE) 14: /usr/lib/xorg-server/Xorg (SendErrorToClient+0x10e) [0x4365ee]
[ 18.710] (EE) 15: /usr/lib/xorg-server/Xorg (remove_fs_handlers+0x463) [0x43a7f3]
[ 18.710] (EE) 16: /usr/lib/libc.so.6 (__libc_start_main+0xf1) [0x7f8c48fe1291]
[ 18.710] (EE) 17: /usr/lib/xorg-server/Xorg (_start+0x29) [0x4246e9]
[ 18.711] (EE) 18: ? (?+0x29) [0x29]
[ 18.711] (EE)
[ 18.711] (EE) Segmentation fault at address 0xc
[ 18.711] (EE)
Fatal server error:
[ 18.711] (EE) Caught signal 11 (Segmentation fault). Server aborting
Last edited by riomus (2017-01-12 11:52:46)
Offline
By adding
Section "Device"
Identifier "Modesetting Graphics"
Driver "modesetting"
Option "AccelMethod" "none"
EndSection
to your xorg.conf (in particular the AccelMethod none line), you can disable glamoregl and start X without the segfault.
Unfortunately you will then find that your displaylink device still does not work, if your system is the same as mine.... still investigating. I get
18:25:22 bash@titanic ~$ xrandr --setprovideroutputsource 1 0
X Error of failed request: BadValue (integer parameter out of range for operation)
Major opcode of failed request: 140 (RANDR)
Minor opcode of failed request: 35 (RRSetProviderOutputSource)
Value in failed request: 0xcc
Serial number of failed request: 18
Current serial number in output stream: 19
and am stuck here.
Also unsure which update caused this. The same problem occurs on both the latest kernel and LTS, which I think the modesetting driver is part of, so I suspect it was an Xorg update.
Edit: Oops, I was overly optimistic . Actually what my fix lets me do is start X without the DisplayLink device plugged in (using just my laptop screen). If I plug in the DisplayLinux driver it attempts to load glamoregl anyway and crashes, and further it requires I reboot after unplugging the DisplayLink device otherwise it will still crash.
Last edited by andytoshi (2016-11-01 19:18:25)
Offline
Subscribed. I'm having this trouble as well and have found no scenario that leaves me with working X and DisplayLink.
I shuffled kernels, uninstalled the intel video driver (at least Chromium's tabs aren't being weird now), made sure `udl` is loading correctly... I don't think a evdi or displaylink package update snuck in.
Offline
By adding
Section "Device" Identifier "Modesetting Graphics" Driver "modesetting" Option "AccelMethod" "none" EndSection
to your xorg.conf (in particular the AccelMethod none line), you can disable glamoregl and start X without the segfault.
Unfortunately you will then find that your displaylink device still does not work, if your system is the same as mine.... still investigating. I get
18:25:22 bash@titanic ~$ xrandr --setprovideroutputsource 1 0 X Error of failed request: BadValue (integer parameter out of range for operation) Major opcode of failed request: 140 (RANDR) Minor opcode of failed request: 35 (RRSetProviderOutputSource) Value in failed request: 0xcc Serial number of failed request: 18 Current serial number in output stream: 19
and am stuck here.
Also unsure which update caused this. The same problem occurs on both the latest kernel and LTS, which I think the modesetting driver is part of, so I suspect it was an Xorg update.
Edit: Oops, I was overly optimistic . Actually what my fix lets me do is start X without the DisplayLink device plugged in (using just my laptop screen). If I plug in the DisplayLinux driver it attempts to load glamoregl anyway and crashes, and further it requires I reboot after unplugging the DisplayLink device otherwise it will still crash.
But it stopped working for you or newer worked? For me it stopped working couple days ago.
Offline
By adding
Section "Device" Identifier "Modesetting Graphics" Driver "modesetting" Option "AccelMethod" "none" EndSection
Because of bumblebee and usage of intel driver I am using
Option "AccelMethod" "uxa"
in order to be able to use display link hub, but still without the screen.
Offline
I can confirm, since i updated packages at 31. October, the displaylink manager is broken and kills the X server on plugin.
I've installed the following packages:
rw-r--r-- 1 root root 116644 Oct 31 10:07 dbus-glib-0.108-1-x86_64.pkg.tar.xz
-rw-r--r-- 1 root root 256528 Oct 31 10:04 gdl-3.22.0-1-x86_64.pkg.tar.xz
-rw-r--r-- 1 root root 3126556 Oct 31 14:02 gtk-sharp-2-2.12.42-1-x86_64.pkg.tar.xz
-rw-r--r-- 1 root root 95776 Oct 31 10:24 libproxy-0.4.13-1-x86_64.pkg.tar.xz
-rw-r--r-- 1 root root 152592 Oct 31 09:23 libthai-0.1.25-1-x86_64.pkg.tar.xz
-rw-r--r-- 1 root root 2465824 Oct 31 10:37 ttf-dejavu-2.37-1-any.pkg.tar.xz
Offline
I am also having this problem since the Oct. 31 update. I have tried using the default (sna) accel method and deprecating to DRI2, but neither provides additional xrandr outputs. At least these changes prevent the segmentation fault that was crashing Xorg as soon as the displaylink dock was attached before.
displaylink service is running normally and no issues installing the dkms evdi driver at upgrade.
Has anyone filed a bug report yet?
Offline
Has anyone filed a bug report yet?
I'd love to. Have we decided where that bug is?
Offline
But it stopped working for you or newer worked? For me it stopped working couple days ago.
Stopped working, unsure when because I don't always use my DisplayLink monitor (though Oct 31 sounds right), on both latest and LTS kernels, and has continued not to work across a couple kernel updates.
I'd love to. Have we decided where that bug is?
I think Xorg is the most likely culprit. Note that there are two issues here: the glamoregl segfault and the failure of "xrandr --setprovideroutputsource 1 0" when glamoregl is disabled.
I'll hold off on filing bugs since it sounds like you've volunteered to.
Last edited by andytoshi (2016-11-02 17:31:22)
Offline
Downgrading mesa to 12.0 works as a temporary fix for me, if anyone has been wondering where exactly the issue is located.
Offline
Confirmed - downgrading to mesa-12.0.3-3 and mesa-libgl-12.0.3-3 restored the displaylink function for my external monitor.
I filed a bug report:
https://bugs.archlinux.org/task/51653
Offline
You should also file a bug report upstream, and if possible try to bisect to find which commit introduced the problem.
R00KIE
Tm90aGluZyB0byBzZWUgaGVyZSwgbW92ZSBhbG9uZy4K
Offline
Downgrading mesa and mesa-libgl to 12.0.3 worked for me as well.
I submitted this report and sent a support request to DisplayLink. Hope something helpful comes of it.
Offline
This bug was killing me. Just once week not using displaylink then Xorg keep crashing before important presentation.
Offline
Downgrading mesa and mesa-libgl to 12.0.3 worked for me as well.
I submitted this report and sent a support request to DisplayLink. Hope something helpful comes of it.
Thank you!
FYI to run the patch Rob has suggested WARNING: this panics my kernel:
1. Download https://aur.archlinux.org/packages/libdrm-git/ to your AUR directory.
2. Change MAKEPKG source line
#branch=master
to
#commit=677cd97dc4a930af508388713f5016baf664ed1
Then do the usual makepkg / makepkg -i dance.
Last edited by andytoshi (2016-11-05 13:02:36)
Offline
Confirmed - downgrading to mesa-12.0.3-3 and mesa-libgl-12.0.3-3 restored the displaylink function for my external monitor.
I filed a bug report:
https://bugs.archlinux.org/task/51653
Hey, the bug report was closed by "Doug Newgard (Scimmia)"
Is it possible to reopen the report and explain to "Doug Newgard (Scimmia)" that displaylink.service is the systemd job for displaylink?
Offline
Is it possible to reopen the report and explain to "Doug Newgard (Scimmia)" that displaylink.service is the systemd job for displaylink?
I think Doug's crystal ball is broken otherwise he would have guessed what displaylink.service is and what it's supposed to do.
That file is not provided by anything in the official repositories, you have not specified what that file is supposed to do either here or in the bug report so that other people can try to reproduce the problem, no wonder the bug report was closed.
You will have to provide more information, specially information about any changes you have done to your system otherwise people will have an incomplete picture of the problem and just waste everyone's time, including yours, suggesting things that might not even be the cause of the problem.
R00KIE
Tm90aGluZyB0byBzZWUgaGVyZSwgbW92ZSBhbG9uZy4K
Offline
Today, after upgrading everything to latest version, I've entered the same problem.
Thanks for the workaround:
cd /var/cache/pacman/pkg;
yaourt -U mesa-12.0.3-3-x86_64.pkg.tar.xz mesa-libgl-12.0.3-3-x86_64.pkg.tar.xz
Has somebody else filed a bug for this?
Offline
I emailed Doug Newgard and asked to reopen the bug with a description that displaylink.service is the systemd service that provides a displaylink driver for xorg and linkked the Arch wiki page for Displaylink.
I asked what other information he needed if that was not sufficient.
Offline
@zekebsatx as this does not appear to be a packaging issue do you not expect that bug report on the arch bug tracker will simply be reclassfied from closed to upstream with a request that you work with upstream?
There appears to be only a single reporter working with upstream https://bugs.freedesktop.org/show_bug.cgi?id=98563 and the inital patch seems to reveal other issues that need more work upstream.
Perhaps if others affected by the issue tested the patch, performed bisects again after the patch is applied it would aid upstream.
Offline
@loqs - I was just following R00KIE and chico's advice to touch base again with the arch dev cho closed it. I never saw the notification that he had requested additional info.
It probably is an upstream issue.
Offline
Can anyone replicate andytoshi's finding in post #15 of the thread?
If so please capture the kernel panic also does changing versions of mesa / mesa-libgl from 12.0.3 to 13.0.0 or vice versa impact the panic?
Offline
I will try it, but this is a production machine, so I need detailed instructions on how to revert if I get a kernel panic.
Offline
If you are unhappy doing it then would advise against doing it.
Pacman#pacman_crashes_during_an_upgrade
Follow steps 1,2 then 5 where the package in step 5 would be libdrm.
Edit:
The above is worse case instructions and should work even if the kernel panic occurs during boot.
If the panic can be avoided by booting with machine not connected to the dock or by Change_default_target_to_boot_into to rescue.target then
# pacman -S libdrm
should be sufficient to replace libdrm-git with libdrm and restore the system to its pretest state.
Last edited by loqs (2016-11-08 23:16:00)
Offline
I emailed Doug Newgard and asked to reopen the bug with a description that displaylink.service is the systemd service that provides a displaylink driver for xorg and linkked the Arch wiki page for Displaylink.
I asked what other information he needed if that was not sufficient.
It was closed because it was complaining about displaylink.service, and I had no idea what that was (and nobody would explain). Your email at least explained that it's part of an AUR package. Since AUR packages are unsupported, it stays closed unless you can show that there's an issue with a repo package.
Last edited by Scimmia (2016-11-08 23:13:20)
Offline