View Single Post
Old 06-24-2018, 04:38 PM   #1
Borszczuk
Junior Member
 
Join Date: Jun 2018
Posts: 3
Lightbulb 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.

Last edited by Borszczuk; 06-26-2018 at 06:02 AM.
Borszczuk is offline   Reply With Quote