DisplayLink
Ryzen 4000 (mobile) lag and general unusability
- Are you using the latest driver? Using displaylink-rpm with displaylink version v5.4.34.0 and evdi version 1.7.2
- Linux distribution and its version Fedora 33, kernel 5.9.15-200.fc33.x86_64
- Desktop environment in use Gnome 3.38.2
I'm using a Dell D6000 dock with a ThinkPad T14s (Ryzen 7 4750u) and encountering severe lag and screen tearing as well as a lot of dmesg spam from evdi:
[ 272.075587] evdi evdi.0: cannot be used for peer-to-peer DMA as it is not a PCI device
[ 272.109276] evdi evdi.0: cannot be used for peer-to-peer DMA as it is not a PCI device
[ 272.143011] evdi evdi.0: cannot be used for peer-to-peer DMA as it is not a PCI device
[ 272.175520] evdi evdi.0: cannot be used for peer-to-peer DMA as it is not a PCI device
[ 272.197843] evdi evdi.0: cannot be used for peer-to-peer DMA as it is not a PCI device
Which I would suspect is the cause. I've been slowly following along with the status of DisplayLink on Wayland and on new AMD APUs and this is the closest I've managed to get to something usable, please let me know if I can provide any more detailed logs or information.
I have a Ryzen 4700U on an HP laptop running Arch, and I also see this dmesg spam error. My displays are usable, but there's a lot of screen tearing and some significant lag.
displaylink 5.3.1.34 evdi 1.7.2 Archlinux, kernel linux-zen 5.10.3 gnome 3.38.2
Based on the timestamps shown and my own recent unrelated experience[1] I suspect the poor performance you're observing may literally be the result of those log messages.
The example log output appears to be five messages in less than a fifth of a second. If that's constant that puts a lot of (sometimes) "invisible" load on the system.
As a workaround I suggest finding out if there's a configuration setting to suppress the messages or re-compiling with them removed.
[1] I had extremely poor, barely detectable stutter-y performance (consistently not-quite 60fps with frequent drops much lower) with an Nvidia Proprietary driver for a long period of time until one day I had reason to track the performance issue down to...the driver spamming the Xorg log with tens of messages a second with "connect"/"disconnect" notifications--apparently caused by some weird physical connector connection issue because when I accidentally slightly nudged the connector the messages immediately stopped!
Once I made the connection (excuse the pun) a web search revealed multiple other occurrences of similar situations.
So, I don't know how many people have been experiencing terrible performance with Nvidia cards on Linux due to someone apparently unfamiliar with the concept of "hysteresis". :) (Aside from the poor performance there was no visual indication of any connect/disconnect events so the connection detection was clearly more sensitive than needed.)
Anyway, just a drive-by comment in case it helps. :)
I am finding this also, I have tried evdi 1.7.0 and 1.7.2 and xanmod kernels (does not work with xanmod) and current ubuntu 5.8 kernel. on the gnome DE.
its not a very nice experience.
@follower apologies I didn't see your comment earlier.
I had htop open whilst testing and didn't see anything too odd, in addition, performance on the laptop display was absolutely fine.
The log spam is a single line every ~40ms which is definitely not enough to cause that kind of extreme lag.
More importantly, the log is stating that it's failing to use DMA. DMA is short for direct memory access and would allow, for example, the framebuffer to be sent over USB without having to 'manually' copy data through the CPU, instead using dedicated hardware.
Given the symptoms (sever latency issues and screen tearing) my suspicion would be that DMA is broken, and therefore it's having to use the much much slower method of copying data via the CPU.
So I have been struggling with this for a good bit now, I think this is related to some AMDGPU crashes I'm getting all the time that cause a kernel panic. At least, the DMA message tends to be the last message before a panic, and the full system crash only seems to happen when i have a monitor plugged into my USB dock. Running an external monitor through HDMI works fine.
Here's some logs:
journalctl -b -1 > journalctl.txt
journalctl.txt
journalctl -b -1 -k > journalctl-k.txt
journalctl-k.txt
My laptop does not have thunderbolt, but my dock is thunderbolt capable. Is it possible that the EVDI driver is attempting to access a thunderbolt port that isn't available or something odd like that? Pure speculation here, just thinking since thunderbolt would normally be connected through PCI, but this port is a USB 3.1...
Any info or thoughts would be welcome to help me to resolve this. Happy to provide logs and hardware info.
Doesn't work properly with AMD Ryzen 5 PRO 4650U as well. ;( On recent Arch Linux.
Seems now to happen on my Device too:
System:
DisplayLink 5.4 evdi 1.9.1.r4.gb0b3d13-1 Distro ArchLinux Kernel linux 5.11.13-arch1-1 Gnome 40.0.0
on a
Dell G5 15 SE 5500 Ryzen 9 4900H (with internal GPU) dGPU: Radeon RX5600M
Seems like with 5.11.12 it worked just fine, just not on 5.11.13
Same here:
DisplayLink 5.4 evdi 1.9.1.r4.gb0b3d13-1 Distro Manjaro 20.2 Kernel - tested on 5.9.16-1, 5.10.30-1, 5.11.14 Gnome 40.0.0, with Wayland Ryzen 4800H w/ Radeon graphics Using i-tec docking station w/ USB-C and 2 x monitors via DisplayPort
System is working OK only using Wayland, Xorg has unusable lag. Kernel 5.9.16 looks most stable. With the others I get occasional freeze and kernel panics while going in/out of Suspend. DisplayLinkManager process uses lots of CPU time - 7-15% when the screen is static (no windows etc. moving) and above 100% when you play a YouTube video for example. That is according to the top utility. I am not sure what's the norm there though for CPU usage. Those kernel messages sure seem like a problem.
@panayotd how is your experience with wayland? does it work smoothly with ryzen? Is it getting better?
Hi,
Yes, overall works OK-ish on my Tuxedo Pulse 14 laptop. CPU usage is high overall, but on 8-core CPU it is acceptable. When you compare it to non-displaylink experience e.g working on the laptop only, then there's a feeling of ms lag in response to mouse clicks, opening windows etc. But as I said OK-ish, nothing to do with the un-workable lag when using X.
My main problem at the moment is that once you connect the laptop to the DisplayLink dock it works, but if you try to disconnect it and continue on laptop only, or go to sleep, lock, shutdown, then something happens and everything blocks and you need to power cycle the machine. Very annoying. I am in a discussion with Tuxedo tech support to see what's the problem. I will update here if I have a solution.
@panayotd https://github.com/panayotd how is your experience with wayland? does it work smoothly with ryzen?
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/DisplayLink/evdi/issues/248#issuecomment-837834112, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAIKX3IRH3EU3BYU6E7Y7NLTNC4XRANCNFSM4VGDGB2Q.
@panayotd thanks for the effort and detailed report.
But to me this sounds it isn't yet ready for production. Hm... i feel really annoyed by this issue. Spending so much money and ending with a hacky non-performant system :cry:
Hello Guys, I have a display link dock and a 4000 series ryzen laptop (4800U).
with DisplayLink + Wayland + arch latest kernel 5.12 or its kernel 5.10, the following happens: Sleep/ crashes and screen does not come back up similar to how @panayotd described Normally kernel panics on every reboot forcing a hard shutdown.
I am fairly sure the panics are down to evdi + 4800 u combination.
Otherwise, it is working quite well on the arch.
Another thought I had is I actually connect my DisplayLink to my laptop as part of a USB type-c dock connection.
My Type-c Dock has the following connections (HDMI, TypeC PD, 3xUSB31, Ethernet, SD-Card) The connection is the following: Laptop -> Type C Dock. TypeC Dock: HDMI -> HDMI Display Ethernet -> Network Switch USB3.0 1 -> DisplayLink Dock (Lenovo ThinkPad DisplayLink DU9019D1 USB 3.0 Docking Station - With PSU) USB3.0 2-> Mouse, keyboard,webcam of a Hub. USB3.0 3 -> Backup hard drive. SD Card 0-> Empty TypeC PD -> Usb Type C Power supply 95W
My laptop also has a spare HDMI port I am not using. So I could upgrade this dock to one with the same features but an extra HDMI port. As I have read, the 4800U CPU supports up to 4 displays natively.
I do this setup because I find the ethernet on the Displaylink dock very buggy, so it is unused. And I get keyboard and mouse jitters via DisplayLink, so I connect them directly via the dock. If I were to remove the DisplayLink from my setup, I would only lose 1 display as I have a spare HDMI port available on the laptop. At this point, I am considering removing the DisplayLink entirely. A good USB type c Dock with dual HDMI + Ethernet + several USB ports should be a good replacement without relying on a broken evdi driver.
Perhaps I could also try connecting the display Link via a USB 3.0 port with this laptop, so it does not go through the dock? That might be helpful.
Overall, there are some problems with either of my proposed solution options. Firstly I sometimes use a Mac M1 Air for work. This laptop only has a type c USB port and no spare HDMI's (Hence my single type c port dock setup), so I would not have a spare HDMI port with that laptop. Secondly, due to the MacBook not having a usb3 connector, I would not be able to connect DisplayLink directly to the mac. Thirdly the mac m1 only supports 2 displays natively, so I would not use a type 3 Dual HDMI hub with it.
Overall, if the DisplayLink worked properly, I would be delighted with the setup and two laptops. Alas, it does not, I'm afraid :(
Hi @ameeno, connecting the DisplayLink dock would probably help in having less lag but would not solve the crash when you go to sleep and/or disconnect the dock from the laptop. I am using a fairly expensive i-tec dock, I also have a Dell D6000 dock - same thing. So I am 99.9% sure it is not the dock. I also think that the problem is the combination of kernel + evdi. I have also tried Ubuntu 20.04 with 5.8 kernel as it comes natively for my Tuxedo Pulse 14 laptop, effect is the same - it crashes. I see that there's a newer kernel in Manjaro - 5.13, I'll try with it and let you know if there's a positive development.
Anyone experiencing performance issues have a look at https://github.com/DisplayLink/evdi/pull/282#issuecomment-843626578
This fix fixes the problem on X11 and I hopefully should be merged to master
Hey @gdbd , thanks for sharing. I tried that on Manjaro, Gnome40, kernel 5.8. What I can say is - it is way better! Xorg is usable, no lag and most importantly it solves the crashing problem I have described above! It does however have some problems, for example if I close the lid of the laptop and leave only the two DisplayPort monitors it starts lagging again as before. Also if I open Firefox on one of the external monitors, Firefox only is very unresponsive. If I move it to the laptop monitor, which I have to leave working otherwise I have lag again, then it works there. So still some quirks but makes huge difference. Any idea about the issues still there? Thanks.
Hey @gdbd , thanks for sharing. I tried that on Manjaro, Gnome40, kernel 5.8. What I can say is - it is way better! Xorg is usable, no lag and most importantly it solves the crashing problem I have described above! It does however have some problems, for example if I close the lid of the laptop and leave only the two DisplayPort monitors it starts lagging again as before. Also if I open Firefox on one of the external monitors, Firefox only is very unresponsive. If I move it to the laptop monitor, which I have to leave working otherwise I have lag again, then it works there. So still some quirks but makes huge difference. Any idea about the issues still there? Thanks.
hey, yes this problems exists for me too, but now displaylink dock works even better and usable in some cases to work around i am connect primary display directly to notebook HDMI, secondary through displaylink. Now both displays works without lag and laptop display turned off
As an update, guys, I tried this patch with a custom evdi build (Number 2 on the repo fixes), and when I plugged my DisplayLink today while the laptop was on, the whole system halted and shut down with a kernel panic.
so it is not fully ideal yet. :(
I was hoping the patch would fix the bugs.
Hey @gdbd , thanks for sharing. I tried that on Manjaro, Gnome40, kernel 5.8. What I can say is - it is way better! Xorg is usable, no lag and most importantly it solves the crashing problem I have described above! It does however have some problems, for example if I close the lid of the laptop and leave only the two DisplayPort monitors it starts lagging again as before. Also if I open Firefox on one of the external monitors, Firefox only is very unresponsive. If I move it to the laptop monitor, which I have to leave working otherwise I have lag again, then it works there. So still some quirks but makes huge difference. Any idea about the issues still there? Thanks.
hey, yes this problems exists for me too, but now displaylink dock works even better and usable in some cases to work around i am connect primary display directly to notebook HDMI, secondary through displaylink. Now both displays works without lag and laptop display turned off
Aha, OK. I have two Displayport monitors so I have to connect them through Displalink dock. I now have a 3 monitor setup and things like Firefox, Skype, Discord and other apps that lag on the external monitors, to run on the laptop monitor. Not the most convenient thing in the world but somehow better than before :). Anyway if you do hear any update on that please share. Will do the same.
Hey @gdbd , thanks for sharing. I tried that on Manjaro, Gnome40, kernel 5.8. What I can say is - it is way better! Xorg is usable, no lag and most importantly it solves the crashing problem I have described above! It does however have some problems, for example if I close the lid of the laptop and leave only the two DisplayPort monitors it starts lagging again as before. Also if I open Firefox on one of the external monitors, Firefox only is very unresponsive. If I move it to the laptop monitor, which I have to leave working otherwise I have lag again, then it works there. So still some quirks but makes huge difference. Any idea about the issues still there? Thanks.
I still have crashing problem but I am on wayland with kernel 5.11.
is it worth going to kernel 5.8? the crashing problem is making me sad.
Hi, use the modified evdi driver above and Xorg. The patch does not work for Wayland. I think kernel switch would not be necessary.
On Tue, Jun 8, 2021, 02:03 AShah @.***> wrote:
Hey @gdbd https://github.com/gdbd , thanks for sharing. I tried that on Manjaro, Gnome40, kernel 5.8. What I can say is - it is way better! Xorg is usable, no lag and most importantly it solves the crashing problem I have described above! It does however have some problems, for example if I close the lid of the laptop and leave only the two DisplayPort monitors it starts lagging again as before. Also if I open Firefox on one of the external monitors, Firefox only is very unresponsive. If I move it to the laptop monitor, which I have to leave working otherwise I have lag again, then it works there. So still some quirks but makes huge difference. Any idea about the issues still there? Thanks.
I still have crashing problem but I am on wayland with kernel 5.11.
is it worth going to kernel 5.8? the crashing problem is making me sad.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/DisplayLink/evdi/issues/248#issuecomment-856316841, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAIKX3PMJVX4HBAZ3E6FFADTRVF3RANCNFSM4VGDGB2Q .
would that solve panics?
ALso my evdi.ko is a gz file but this script produced non gz file. is that a problem?
Yes it solved kernel panics for me. You should have a .gz file too.
On Tue, Jun 8, 2021, 12:04 AShah @.***> wrote:
would that solve panics?
ALso my evdi.ko is a gz file but this script produced non gz file. is that a problem?
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/DisplayLink/evdi/issues/248#issuecomment-856595897, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAIKX3JNGCCSBNBRZ2QFVQTTRXMLHANCNFSM4VGDGB2Q .
I can see the same problem on my Lenovo ThinkBook 16p G2 20YM000BGE . Using non DMA is a quite bad idea that my be the cause, that the system eats up CPU time.
8 month passed... many users frustrated... what do you think about that, displaylink?
I stopped using the display link and removed 1 monitor. I now use a laptop stand, 1 USB type c monitor and 1 HDMI. I have to switch between type c to HDMI adapter between mac and pc. In my desktop USB hub I have Rankie ethernet port, USB soundcard, keyboard mouse and backup hdd).
Life is so so much better without displaylink/evdi. I can switch between m1 mac, intel mac, linux laptop and windows laptop painlessly. the only negative is mac m1 only supports 1 additional display, but I can live with that not having to use displaylink laggy complexity.
8 month passed... many users frustrated... what do you think about that, displaylink?
I decided to buy a docking-station with a DisplayLinlk Chip because i was (the past!!) lucky with my 2 connected 4k Displays linked by a USB3 port. The performance was quite good. I I was using it with W10 and also with Linux.
The Linux implementation was comparable to the Windows one with one exception. There was one process running with a high CPU load. The Windows pendant was almost quite, there was permanent running process. So i think the bug should be inside evdi and may be very old.
Well display-link was purchased by Synaptics, and i fear that these dullies want to see their investment back, while DisplayLink trying to compete an already lost war against Intel and Thunderbold. But yes, they are doing wrong to forget their customer. Anyway evdi is on github. I will try to figure out, how the USB port is adresses, maybe there is also a bug/incompatebility inside the AMD czesanne USB connector inside the kernel.