High CPU load (D3100 Ubuntu 15.04)

[godrica]

Hi all...

I'm getting extremely high CPU load on my Dell XPS 13 machine running Ubuntu 15.04.

http://i61.tinypic.com/vo0m6t.png

Is this behaviour normal?
What are your experiences with CPU load and Display link manager?

[mlukaszek]

Hi,

This is not normal - can you create a coredump file from a running DisplayLink Manager (e.g. using gdb and its generate-core-file command)?

Thanks,
Michal

[vkorecky]

Hi,
I have the same problem on my Ubuntu 14.04

Ubuntu info:
Linux AcerV7 3.19.0-31-generic #36~14.04.1-Ubuntu SMP Thu Oct 8 10:21:08 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux

DisplayLink device:
HP 3005pr

lspci output:
00:00.0 Host bridge: Intel Corporation Haswell-ULT DRAM Controller (rev 09)
00:02.0 VGA compatible controller: Intel Corporation Haswell-ULT Integrated Graphics Controller (rev 09)
00:03.0 Audio device: Intel Corporation Haswell-ULT HD Audio Controller (rev 09)
00:14.0 USB controller: Intel Corporation Lynx Point-LP USB xHCI HC (rev 04)
00:16.0 Communication controller: Intel Corporation Lynx Point-LP HECI #0 (rev 04)
00:1b.0 Audio device: Intel Corporation Lynx Point-LP HD Audio Controller (rev 04)
00:1c.0 PCI bridge: Intel Corporation Lynx Point-LP PCI Express Root Port 1 (rev e4)
00:1c.2 PCI bridge: Intel Corporation Lynx Point-LP PCI Express Root Port 3 (rev e4)
00:1c.3 PCI bridge: Intel Corporation Lynx Point-LP PCI Express Root Port 4 (rev e4)
00:1c.4 PCI bridge: Intel Corporation Lynx Point-LP PCI Express Root Port 5 (rev e4)
00:1d.0 USB controller: Intel Corporation Lynx Point-LP USB EHCI #1 (rev 04)
00:1f.0 ISA bridge: Intel Corporation Lynx Point-LP LPC Controller (rev 04)
00:1f.2 SATA controller: Intel Corporation Lynx Point-LP SATA Controller 1 [AHCI mode] (rev 04)
00:1f.3 SMBus: Intel Corporation Lynx Point-LP SMBus Controller (rev 04)
01:00.0 3D controller: NVIDIA Corporation GK107M [GeForce GT 750M] (rev ff)
04:00.0 Network controller: Intel Corporation Wireless 7260 (rev 73)
05:00.0 Unassigned class [ff00]: Realtek Semiconductor Co., Ltd. Device 5287 (rev 01)
05:00.1 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 14)

lsusb output:
Bus 003 Device 002: ID 8087:8000 Intel Corp.
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 003: ID 17e9:430a DisplayLink HP Port Replicator (Composite Device)
Bus 002 Device 002: ID 0451:8040 Texas Instruments, Inc.
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 007: ID 04f3:0086 Elan Microelectronics Corp.
Bus 001 Device 005: ID 8087:07dc Intel Corp.
Bus 001 Device 003: ID 04f2:b3d6 Chicony Electronics Co., Ltd
Bus 001 Device 010: ID 04b4:0060 Cypress Semiconductor Corp.
Bus 001 Device 009: ID 1bcf:05cf Sunplus Innovation Technology Inc. Micro keyboard & mouse receiver
Bus 001 Device 008: ID 05e3:0608 Genesys Logic, Inc. USB-2.0 4-Port HUB
Bus 001 Device 006: ID 048d:1165 Integrated Technology Express, Inc. IT1165 Flash Controller
Bus 001 Device 004: ID 0424:2517 Standard Microsystems Corp. Hub
Bus 001 Device 002: ID 0451:8042 Texas Instruments, Inc. Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

[xenith]

Ok speculation time -

I had this issue at one point in my initial purchasing of this hardware which was when I wrote this:

http://displaylink.org/forum/showthread.php?p=78712#post78712

I had made the assumption that the CPU usage was otherwise normal (mine was a little lower but still _very_ high) for driving two screens.

For curious testing purposes I installed windows on a USB hard drive, booted that, and installed the proper displaylink drivers for windows 8.1 on that. Low and behold... It was capable of driving not two, but _3_ 1080p screens with zero lag over 1 USB3 port with relatively little CPU usage. This surprised me due to the poor performance I was seeing on Linux.

Point being, the hardware is capable. It's the failure of this company to produce Linux drivers that work as well that cause our pain and suffering.

Now, the reason that I'm writing this post -

Strangely, when I booted back into Fedora 22, I noticed that the lag wasn't present anymore (the screens no longer felt like they were clocked at 30Hz when they were previously) and the CPU usage was decreased dramatically.

I'm not sure whether or not I had a lingering kernel upgrade in between, but my speculation is that the windows drivers properly updated the firmware on the device itself, where the Linux drivers didn't. So, as a potential 'fix' attempt to find a windows computer that you can plug it into first.

Unfortunately, again, whether it's the latest kernel or the firmware that was upgraded on the device, I don't know. But there are a whole other host of issues that come from whatever upgrade happened, too. For some reason, unlike before, the devices fails ungracefully if X is ever restarted and gives the following error message until the computer is rebooted:

[ 453.842446] [drm:check_crtc_state [i915]] *ERROR* mismatch in ips_enabled (expected 1, found 0)
[ 453.842633] [drm:check_crtc_state [i915]] *ERROR* mismatch in ips_enabled (expected 1, found 0)

It's as if something isn't being released properly.

[geekygator]

I am having the same high CPU issue, Ubuntu 14.04, Dell XPS 13, D3100. CPU use hovers between 40% and 140% according to top.
I attempted to connect the device to a windows machine using the windows driver, but there was no improvement. Granted, I did not connect displays to the device when I connected it to Windows, nor reboot windows.

[trofim]

Same issue on ubuntu 15.10 with kernel 4.2.0-35-generic.

[mlukaszek]

Thanks for your reports.

Again, it would be useful if someone could attach a dump from DisplayLinkManager process so we can investigate - see my comment above.

Cheers,
Michal

[R.E.L]

Hi together,

I have an Ubuntu 14.04 trusty up to-date. An Year ago my DisplayLink was working with a lot of changes in the udev. Then I don't need the second display using DisplayLink. Now I have a need to use the second display. It now does not work.

So I investigate and found the new DisplayLink driver for Ubuntu and installed them. First it doesn't work because I had kernel 3.13.0-45. I Installed LTS wily kernel 4.2.0-35. After some display settings it works with a many crashes an always an poor performance. The mouse moves very slow and tipping an character takes seconds.

I take a deep look at it and found a solution:

sudo displaylink-installer uninstall

Remove my old DisplayLink udev entries

create a file /etc/modprobe.d/98_no_udl.conf with data: blacklist udl

reboot

run install

sudo ./displaylink-driver-1.0.335.run


Now the DisplayLink display and my primary display working without any problem.:)

Hope this helps You to regards Rainer

[cpo]

Same issue here. Please find the core dump from DisplayLinkManager. Uncompressed size is 2.4GB.

https://ferdi.naasa.net/oc/index.php/s/PX1lFi2sZFmNkqS

Additionally I'm getting logged off when I plug in the D3100 for the first time, I've two mouse cursors - one static and one which is flickering.

When the D3100 is attached during system startup, the secondary screen stays black and I've a couple of kernel stacktraces in the journal. Looks like these: https://github.com/DisplayLink/evdi/issues/28

[mlukaszek]

@cpo: Can you attach the output of the support tool, so we can know more details of your setup?

Edit: and it would also be great if you could attach an archive with all the libraries that DisplayLinkManager would link to at runtime (i.e. everything that you see mentioned in the output of ldd /usr/lib/displaylink/DisplayLinkManager), otherwise it would be hard to read anything from the dump without installing rawhide somewhere I guess.

Thanks
Michal

[cpo]

Please find the libs here. I added the usual output for ldd, dmesg, lspci -vvv.

https://ferdi.naasa.net/oc/index.php/s/RC2edn5EW3kzR0D

I don't know what kind of support tool you mean. If I search in google, I can find one for Windows. I've no windows, though.

[mlukaszek]

Sorry, I meant this http://support.displaylink.com/knowledgebase/articles/757047-how-can-i-report-ubuntu-issues-to-displaylink

Cheers,
Michal

[cpo]

The support tool zip:

https://ferdi.naasa.net/oc/index.php/s/d5YU6YecUxX5Q0B

Not sure if that makes sense - note that the D3100 is not attached at the moment (I'm not @home) and the DL service is disabled. If you need it to be attached, we'll have to wait until tomorrow.

[mlukaszek]

The logs of what was happening may be enough. Thanks.

Michal

[cpo]

Any news here? Any additional information I can provide?

[cpo]

Can you change the displaylink manager to log in clear text - or even better: provide the source for it. That I can look for the reason myself.

[Szymon]

Hi cpo,

Could you please provide a bit more information about the context when the problem occurs? Is it constantly eating your CPU or you observe it only in some circumstances, e.g. CPU load is significantly higher when resuming from machine suspend? Is there any specific app running? Maybe capturing a quick video on your phone would help?
I am asking as we would like to reproduce the problem internally.

Thanks,
Szymon

[sanette]

Hi

I have a brand new XPS 13 DE, just installed ubutu 16.04, kernel 4.4.0-24
so I can make some tests.

Indeed there is a problem with CPU. Here is my first test:

* install latest Displaylink driver 1.1.68
* test if it work with my dock D3100 + external HDMI monitor: YES!
* unplug the dock
* reboot (laptop alone, nothing is connected)
* in the terminal, "top" tells me DisplayLinkManager uses between 0% - 0.3%
so this is fine
* close the lid to suspend, re-open to wake up
* now DisplayLinkManager is steadily using 16%CPU !
(with nothing connected) So something is wrong here.

[sanette]

Here is the screenshot
(after resume, with nothing connected to the laptop)

[EDIT] sorry, the image has been shrunk, it's too small.; Anyway this is not important
It's just showing DisplayLinkManager at 16.9% CPU

[Sparxy]

I'm having the same problem. As soon as I plug in a single DisplayLink screen, the DisplayLinkManager CPU usage goes through the roof.

The CPU usage stays this high (around 80-100% of one logical core) as long as I keep using the screen(s).
See screenshot.

Ubuntu 16.04
kernel: 4.4.0-24-generic
DisplayLink 1.1.62

lspci:
00:00.0 Host bridge: Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor DRAM Controller (rev 06)
00:01.0 PCI bridge: Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor PCI Express x16 Controller (rev 06)
00:02.0 VGA compatible controller: Intel Corporation 4th Gen Core Processor Integrated Graphics Controller (rev 06)
00:03.0 Audio device: Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor HD Audio Controller (rev 06)
00:14.0 USB controller: Intel Corporation 8 Series/C220 Series Chipset Family USB xHCI (rev 04)
00:16.0 Communication controller: Intel Corporation 8 Series/C220 Series Chipset Family MEI Controller #1 (rev 04)
00:19.0 Ethernet controller: Intel Corporation Ethernet Connection I217-V (rev 04)
00:1a.0 USB controller: Intel Corporation 8 Series/C220 Series Chipset Family USB EHCI #2 (rev 04)
00:1b.0 Audio device: Intel Corporation 8 Series/C220 Series Chipset High Definition Audio Controller (rev 04)
00:1c.0 PCI bridge: Intel Corporation 8 Series/C220 Series Chipset Family PCI Express Root Port #1 (rev d4)
00:1c.6 PCI bridge: Intel Corporation 8 Series/C220 Series Chipset Family PCI Express Root Port #7 (rev d4)
00:1c.7 PCI bridge: Intel Corporation 8 Series/C220 Series Chipset Family PCI Express Root Port #8 (rev d4)
00:1d.0 USB controller: Intel Corporation 8 Series/C220 Series Chipset Family USB EHCI #1 (rev 04)
00:1f.0 ISA bridge: Intel Corporation HM87 Express LPC Controller (rev 04)
00:1f.2 SATA controller: Intel Corporation 8 Series/C220 Series Chipset Family 6-port SATA Controller 1 [AHCI mode] (rev 04)
00:1f.3 SMBus: Intel Corporation 8 Series/C220 Series Chipset Family SMBus Controller (rev 04)
01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Mars [Radeon HD 8730M] (rev ff)
01:00.1 Audio device: Advanced Micro Devices, Inc. [AMD/ATI] Cape Verde/Pitcairn HDMI Audio [Radeon HD 7700/7800 Series] (rev ff)
03:00.0 Network controller: Intel Corporation Wireless 7260 (rev 73)
04:00.0 Unassigned class [ff00]: Realtek Semiconductor Co., Ltd. RTS5227 PCI Express Card Reader (rev 01)

lsusb:
Bus 002 Device 002: ID 8087:8000 Intel Corp.
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 002: ID 8087:8008 Intel Corp.
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 004 Device 003: ID 17e9:ff0b DisplayLink
Bus 004 Device 002: ID 17e9:ff0b DisplayLink
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 003 Device 004: ID 05c8:0369 Cheng Uei Precision Industry Co., Ltd (Foxlink)
Bus 003 Device 003: ID 154b:005b PNY Flash Drive
Bus 003 Device 002: ID 046d:c52b Logitech, Inc. Unifying Receiver
Bus 003 Device 005: ID 8087:07dc Intel Corp.
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

Edit: Added zip with output of support tool and other info.

[mlukaszek]

Having DisplayLinkManager process using more CPU with no device connected (what sanette reported) is not normal and we'll be looking into that.

To give context for remaining reports so far: DisplayLinkManager does some heavy lifting to talk to devices and push pixels to all additional screens connected to docking stations - so it will always need some CPU resources to do that.

We use EVDI as a kernel mode DRM driver which receives all notifications from standard Linux subsystems, including those telling there is a change on the screen that needs to be displayed. DisplayLinkManager gets those updates from EVDI, and uses them to refresh screens connected to DisplayLink devices.

The CPU usage is proportional to how much data we need to work with. Generally speaking, the more extra screens, the higher CPU usage.

Unfortunately, some graphical environments (default Unity being a prime example) are working in such a way that the notifications we receive are about an entire screen changing, even if it's not exactly true.

For this reason, we can be forced to refresh all DisplayLink screens even if the update was just for the built-in laptop screen, and there was no real need to update contents of any other screen. We have seen much better behaviour in other desktop environments (e.g. Gnome 3 or KDE), where EVDI is given much more accurate information.

Having full screens needing to redraw will also make the process use more resources than updating a fraction of the screen. Unfortunately, this again comes back to the quality of screen update notifications we receive on Linux - even if the thing changing is tiny, if we're told that we should update the entire screen, we must do as we're instructed.

Having said all that...

We are currently looking at possibilities of reducing the CPU usage on Linux, but first would like understand what CPU usage (and overall performance) are people getting on different setups. Therefore, we'd need your help!

If you see something that you don't like please record a short video (smartphone quality is just fine) and share here. This will let us see how things work on your systems.

Some caveats:
Having Ubuntu's "Display Properties" window opened makes the CPU usage high - as the app is rendering an overlay with a display number on each screen - massively increasing the number of screen updates.

If using Unity desktop environment - for reasons explained above - even having a cursor blinking in console, or "top" window updating itself regularly on the internal screen will cause updates for all DisplayLink screens, too.

Regards,
Michal

[Sparxy]

Hi Michal,

I am using the XFCE desktop environment, which is rather lightweight so I'm not sure whether the amount of CPU usage I'm getting could be considered within normal range. This is why I'm checking in.
This also begs the question whether there's no way for DisplayLink to optimize the drivers to detect which parts of the screen changed more accurately, causing less need for constant screen updates?

Thank you for your help.

[cpo]

Sorry, I gave up on this stuff. I've some work to do currently. No time to experiment with various DisplayLink issues. Fact is that if you work, you'll have some applications open. Browsers with several tabs, multiple terminals, maybe an IDE (intellij in my case), a mail client, chat, etc. I've a 21:9 screen with 2560x1080 pixels on it.

It turned out that the current DisplayLink integration isn't made for my setup. It feels like a proof of concept. Maybe it's ok do simple presentations over it. I don't know why you need a video to understand what ~30fps means. Its just slow. And eats up CPU cycles. And the notebook battery.

Finding applications that may lead to high CPU load because they do things "different" isn't an argument if you need these applications.

That's valid at least for the USB3 connected D3100. I've the Dell USB-C connector, too. But I never got it running with the external screen because of kernel oupses when the HDMI cable is plugged and all screens black.

As a result, I'm running the Notebook without any external screens for three months now. Still having the hope that it will get usable some time.

[Sparxy]

I was able to greatly improve performance by disabling the default XFCE compositor. However, this causes the issue described in http://displaylink.org/forum/showthread.php?t=64586

[lloydwatkin]

Unfortunately, some graphical environments (default Unity being a prime example) are working in such a way that the notifications we receive are about an entire screen changing, even if it's not exactly true.

For this reason, we can be forced to refresh all DisplayLink screens even if the update was just for the built-in laptop screen, and there was no real need to update contents of any other screen. We have seen much better behaviour in other desktop environments (e.g. Gnome 3 or KDE), where EVDI is given much more accurate information.


I have installed Gnome 3.20 on Ubuntu 16.04 and am happy to report that CPU usage has dropped dramatically (it was at around 180%). I shall report on stability once I've used it a bit more. Previously my external monitors would freeze regularly with killing the main displaylink process and unplugging the dock the only way to turn them back on.

[asdfwadfawdf]

Having DisplayLinkManager process using more CPU with no device connected (what sanette reported) is not normal and we'll be looking into that.

To give context for remaining reports so far: DisplayLinkManager does some heavy lifting to talk to devices and push pixels to all additional screens connected to docking stations - so it will always need some CPU resources to do that.

We use EVDI as a kernel mode DRM driver which receives all notifications from standard Linux subsystems, including those telling there is a change on the screen that needs to be displayed. DisplayLinkManager gets those updates from EVDI, and uses them to refresh screens connected to DisplayLink devices.

The CPU usage is proportional to how much data we need to work with. Generally speaking, the more extra screens, the higher CPU usage.

Unfortunately, some graphical environments (default Unity being a prime example) are working in such a way that the notifications we receive are about an entire screen changing, even if it's not exactly true.

For this reason, we can be forced to refresh all DisplayLink screens even if the update was just for the built-in laptop screen, and there was no real need to update contents of any other screen. We have seen much better behaviour in other desktop environments (e.g. Gnome 3 or KDE), where EVDI is given much more accurate information.

Having full screens needing to redraw will also make the process use more resources than updating a fraction of the screen. Unfortunately, this again comes back to the quality of screen update notifications we receive on Linux - even if the thing changing is tiny, if we're told that we should update the entire screen, we must do as we're instructed.

Having said all that...

We are currently looking at possibilities of reducing the CPU usage on Linux, but first would like understand what CPU usage (and overall performance) are people getting on different setups. Therefore, we'd need your help!

If you see something that you don't like please record a short video (smartphone quality is just fine) and share here. This will let us see how things work on your systems.

Some caveats:
Having Ubuntu's "Display Properties" window opened makes the CPU usage high - as the app is rendering an overlay with a display number on each screen - massively increasing the number of screen updates.

If using Unity desktop environment - for reasons explained above - even having a cursor blinking in console, or "top" window updating itself regularly on the internal screen will cause updates for all DisplayLink screens, too.

Regards,
Michal

I opened Ubuntu bug 1613001 (https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/1613001)
Ubuntu 16.04 LTS, Intel HD Graphics 4000, 1 LVDS laptop display, 1 HDMI, 1 HDMI through DisplayLink USB 3.0.

root 19733 49.1 0.4 2167260 49476 ? Ssl 17:09 127:33 /usr/lib/displaylink/DisplayLinkManager

DisplayLinkManager uses significantly more CPU than everything else and mouse cursor flickers on all displays (LVDS and HDMI) but DisplayLink.

Any workaround so far?

[asdfwadfawdf]

I switched to gnome 3.18 by installing ubuntu-gnome-desktop, cpu utilization barely changed

root 3405 34.7 0.3 2138928 48668 ? Ssl 23:20 7:45 /usr/lib/displaylink/DisplayLinkManager


I don't think switching from Unity to Gnome made any difference. When I browse something like Google Earth on non-displaylink displays, DisplayLinkManager still causes CPU spike

[dcastellani]

Wanted to add my own experience.

On my desktop, running Antergos, basically Arch Linux, I am also experiencing extremely high CPU usage around DisplayLinkManager.

My setup is, three monitors, primary monitor is plugged directly into my desktop via DVI. Two monitors in portrait mode plugged into Dell D3100 via DVI to HDMI adapters. Displays are rotated via xrandr.

When moving just the mouse on the primary monitor, connected via DVI to the desktop GPU, DisplayLinkManager spikes to around 130%. My desktop is running an i7-2600k 4 cores, 8 threads.

This also occurs when moving windows/mouse on the actual monitors plugged into the display links.

[asdfwadfawdf]

And why is displaylinkmanager using 15% CPU when it is not even connected?

[trepseq]

Same problem here using HD3000 and Ubuntu 16.04 with unity. Will try out gnome to see if there is a difference.

[trepseq]

Using XFCE solves the problem. Seems that it's caused by compiz when using Unity.

[trepseq]

Running
metacity --replace
gets rid of the high CPU problem. But then you basically are not using Unity anymore.

So Ubuntu Unity ist NOT SUPPORTED by Displaylink. You can pick one of these:

a) Unity with permanent high CPU load
b) Different desktop than Unity
c) Different hardware

[trepseq]

https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/1616981

[jepster]

We have the high CPU usage and flickering mouse pointer on laptop screen issue also without metacity. Using Ubuntu 16.10. I have two 27" screens connected on the DELL 3100 docking station. The latest Ubuntu driver is installed.

Here is a link to the htop command's output from my laptop:
http://pix.toile-libre.org/upload/original/1477060200.png

Another issue is the very low frame rate. See the report from the glxgears program below.
http://pix.toile-libre.org/upload/original/1477062734.png

[Pandemie]

So is there any update on this? I have the same issues.

- Ubuntu 16.04.
- Dell D3100 Docking station
- Two 2560x1400 Displays connected
- Not using unity, but i3
- Using LightDM

[znd0]

I get an extremely high FPS reported from glxgears:
$ glxgears
Running synchronized to the vertical refresh. The framerate should be
approximately the same as the monitor refresh rate.
303 frames in 5.0 seconds = 60.553 FPS
1203 frames in 5.0 seconds = 240.384 FPS
8173 frames in 5.0 seconds = 1634.242 FPS
9915 frames in 5.0 seconds = 1982.991 FPS
8718 frames in 5.0 seconds = 1743.354 FPS
8002 frames in 5.0 seconds = 1600.181 FPS
8554 frames in 5.0 seconds = 1710.762 FPS


However, it LAGS :(

I'm running xfce...