DisplayLink Forum

DisplayLink Forum (https://displaylink.org/forum/index.php)
-   Linux and Open Source (https://displaylink.org/forum/forumdisplay.php?f=29)
-   -   Temporary workaround for high load with DisplayLink on Ubuntu 18.04 (https://displaylink.org/forum/showthread.php?t=66174)

Borszczuk 06-24-2018 04:38 PM

Temporary workaround for high load with DisplayLink on Ubuntu 18.04
 
Hi,

I am using Kubuntu 18.04, on Lenovo T520, with displaylink-driver-4.2.29.run installed and I have i-Tec's USB2HDTRIO device.

I was trying to figure out the possible culprit of significant load raise when I started to use DL and I managed to notice significant growth of my system logs. Investigating closer I noticed /var/log/syslog and /var/log/kern.log were simply flooded with repeated messages like that:

Code:

Jun 24 16:34:32 tuptak kernel: [89373.960339] released /dev/fb0 user=1 count=0
Jun 24 16:34:33 tuptak kernel: [89374.210590] open /dev/fb0 user=1 fb_info=000000009d548658 count=1
Jun 24 16:34:33 tuptak kernel: [89374.210624] released /dev/fb0 user=1 count=0
Jun 24 16:34:33 tuptak kernel: [89374.460808] open /dev/fb0 user=1 fb_info=000000009d548658 count=1
Jun 24 16:34:33 tuptak kernel: [89374.460817] released /dev/fb0 user=1 count=0
Jun 24 16:34:33 tuptak kernel: [89374.710933] open /dev/fb0 user=1 fb_info=000000009d548658 count=1
Jun 24 16:34:33 tuptak kernel: [89374.710943] released /dev/fb0 user=1 count=0
Jun 24 16:34:33 tuptak kernel: [89374.961124] open /dev/fb0 user=1 fb_info=000000009d548658 count=1
Jun 24 16:34:33 tuptak kernel: [89374.961149] released /dev/fb0 user=1 count=0
Jun 24 16:34:34 tuptak kernel: [89375.211308] open /dev/fb0 user=1 fb_info=000000009d548658 count=1
Jun 24 16:34:34 tuptak kernel: [89375.211318] released /dev/fb0 user=1 count=0
Jun 24 16:34:34 tuptak kernel: [89375.461447] open /dev/fb0 user=1 fb_info=000000009d548658 count=1
Jun 24 16:34:34 tuptak kernel: [89375.461455] released /dev/fb0 user=1 count=0
Jun 24 16:34:34 tuptak kernel: [89375.711584] open /dev/fb0 user=1 fb_info=000000009d548658 count=1
Jun 24 16:34:34 tuptak kernel: [89375.711593] released /dev/fb0 user=1 count=0
Jun 24 16:34:34 tuptak kernel: [89375.961712] open /dev/fb0 user=1 fb_info=000000009d548658 count=1
Jun 24 16:34:34 tuptak kernel: [89375.961729] released /dev/fb0 user=1 count=0
Jun 24 16:34:35 tuptak kernel: [89376.211843] open /dev/fb0 user=1 fb_info=000000009d548658 count=1
Jun 24 16:34:35 tuptak kernel: [89376.211853] released /dev/fb0 user=1 count=0
Jun 24 16:34:35 tuptak kernel: [89376.462012] open /dev/fb0 user=1 fb_info=000000009d548658 count=1
Jun 24 16:34:35 tuptak kernel: [89376.462033] released /dev/fb0 user=1 count=0
Jun 24 16:34:35 tuptak kernel: [89376.712201] open /dev/fb0 user=1 fb_info=000000009d548658 count=1
Jun 24 16:34:35 tuptak kernel: [89376.712212] released /dev/fb0 user=1 count=0
Jun 24 16:34:35 tuptak kernel: [89376.962346] open /dev/fb0 user=1 fb_info=000000009d548658 count=1

and even I am running SSD, it still had to significantly contribute to the load.
I saw many people posting complains about high load on their boxes when DisplayLink is in use also on this forum, but for some odd reasons I was unable to download their DLSupportTool's reports to check if this is the same story.

As lame workaround I simply decided to mute this flood by re-configuring system logger (which is rsyslog on my Kubuntu). So if you got the same on your flood on your machine, you can check my trick to see if that's going to help you. As root, edit `/etc/rsyslog.d/50-default.conf` and at the begining of that file you shall see:

Code:

#
# First some standard log files.  Log by facility.
#
auth,authpriv.*        /var/log/auth.log
*.*;auth,authpriv.none      -/var/log/syslog
#cron.*            /var/log/cron.log

Now you need to add the filter above the /var/log/syslog related entry, which is done my addding
Code:

:msg, contains, "/dev/fb0" ~
, so after the edit it needs to look like this:

Code:

#
# First some standard log files.  Log by facility.
#
auth,authpriv.*        /var/log/auth.log
:msg, contains, "/dev/fb0" ~
*.*;auth,authpriv.none      -/var/log/syslog
#cron.*            /var/log/cron.log

Note: this will filter out all log entries containing /dev/fb0 so if that's too agressive for you, you may want to play with it a bit (also see rsyslog docs for more filter types). Finally restart rsyslog

Code:

service restart rsyslog
and you should have lower load from now on. Let me know if that made your box more usable.

Drofe 06-27-2018 06:50 AM

Not working on Dell E7250
 
Hi,
the above fix does not work for me. As long as there is no graphics "action" on any screen the cpu usage is pretty low <10%. Both syslog and kern log are empty with regards to the entry above.

(I'm on a DELL Latitude E7250 laptop with SSD and i7 processor using Xubuntu with Xfce using latest 4.2.29 driver)


All times are GMT. The time now is 02:05 PM.

Powered by vBulletin® Version 3.8.7
Copyright ©2000 - 2024, vBulletin Solutions, Inc.