PDA

View Full Version : Endless log spam _CGXGLDisplayContextForDisplayDevice: No matching context for device


magillagorilla
05-13-2014, 04:41 AM
So I've just put in an Anker USB3 -> HDMI adapter, loaded the latest beta software and it works great.

However my console is now spammed *ENDLESSLY* with

5/12/14 10:39:21.472 PM WindowServer[295]: _CGXGLDisplayContextForDisplayDevice: No matching context for device (0x7fbae3402cd0) - disabling OpenGL
5/12/14 10:39:21.572 PM WindowServer[295]: _CGXGLDisplayContextForDisplayDevice: No matching context for device (0x7fbae3402cd0) - disabling OpenGL
5/12/14 10:39:21.680 PM WindowServer[295]: _CGXGLDisplayContextForDisplayDevice: No matching context for device (0x7fbae3402cd0) - disabling OpenGL
5/12/14 10:39:21.763 PM WindowServer[295]: _CGXGLDisplayContextForDisplayDevice: No matching context for device (0x7fbae3402cd0) - disabling OpenGL
5/12/14 10:39:21.872 PM WindowServer[295]: _CGXGLDisplayContextForDisplayDevice: No matching context for device (0x7fbae3402cd0) - disabling OpenGL
5/12/14 10:39:21.963 PM WindowServer[295]: _CGXGLDisplayContextForDisplayDevice: No matching context for device (0x7fbae3402cd0) - disabling OpenGL
5/12/14 10:39:22.022 PM WindowServer[295]: _CGXGLDisplayContextForDisplayDevice: No matching context for device (0x7fbae3402cd0) - disabling OpenGL
5/12/14 10:39:22.052 PM WindowServer[295]: _CGXGLDisplayContextForDisplayDevice: No matching context for device (0x7fbae3402cd0) - disabling OpenGL
5/12/14 10:39:22.164 PM WindowServer[295]: _CGXGLDisplayContextForDisplayDevice: No matching context for device (0x7fbae3402cd0) - disabling OpenGL
5/12/14 10:39:22.281 PM WindowServer[295]: _CGXGLDisplayContextForDisplayDevice: No matching context for device (0x7fbae3402cd0) - disabling OpenGL
5/12/14 10:39:22.363 PM WindowServer[295]: _CGXGLDisplayContextForDisplayDevice: No matching context for device (0x7fbae3402cd0) - disabling OpenGL
5/12/14 10:39:22.464 PM WindowServer[295]: _CGXGLDisplayContextForDisplayDevice: No matching context for device (0x7fbae3402cd0) - disabling OpenGL
5/12/14 10:39:22.564 PM WindowServer[295]: _CGXGLDisplayContextForDisplayDevice: No matching context for device (0x7fbae3402cd0) - disabling OpenGL
5/12/14 10:39:22.672 PM WindowServer[295]: _CGXGLDisplayContextForDisplayDevice: No matching context for device (0x7fbae3402cd0) - disabling OpenGL
5/12/14 10:39:22.752 PM WindowServer[295]: _CGXGLDisplayContextForDisplayDevice: No matching context for device (0x7fbae3402cd0) - disabling OpenGL
5/12/14 10:39:22.881 PM WindowServer[295]: _CGXGLDisplayContextForDisplayDevice: No matching context for device (0x7fbae3402cd0) - disabling OpenGL
5/12/14 10:39:22.964 PM WindowServer[295]: _CGXGLDisplayContextForDisplayDevice: No matching context for device (0x7fbae3402cd0) - disabling OpenGL
5/12/14 10:39:23.022 PM WindowServer[295]: _CGXGLDisplayContextForDisplayDevice: No matching context for device (0x7fbae3402cd0) - disabling OpenGL
5/12/14 10:39:23.064 PM WindowServer[295]: _CGXGLDisplayContextForDisplayDevice: No matching context for device (0x7fbae3402cd0) - disabling OpenGL


About 12 lines a second, it doesn't stop.

Any suggestions on how to stop?

I'm on 10.9.2

magillagorilla
05-13-2014, 12:52 PM
Well, I'm not sure what I did to fix this, but after several reboots and clearing nvpram, the log messages have stopped. (cmd-option-p-r during boot before grey screen)

Hope it stays that way.

MickM
05-15-2014, 03:13 PM
So what you have observed is THE primary reason I've been avoiding the 2.2 beta all this time. I have a solid state drive and the last thing I need is a dozen long lines PER SECOND and forever written to a log file. Someone previously said the log files are capped in size so it shouldn't be a problem - but that's beside the point. Yes they are capped in size, but they are still endlessly overwritten as the never ending stream of console output continues (and wearing out my SSD).

I tried your suggestion about zapping the PRAM and it did help! Now the console spew isn't continuous, but comes in big spurts whenever anything in the DisplayLink monitor happens (e.g. moving a window, scrolling in a window, Expose etc.). Fortunately moving the mouse around in the DisplayLink monitor doesn't trigger the console spew. It's a lot better now, but it definitely still needs fixing.

magillagorilla
05-15-2014, 03:39 PM
Oh man... I just went back in to check, since you said that and it's still happening. My ASL logs yesterday are about 2gb ARGH!!!

This is completely unacceptable. I assume you don't have this problem with an earlier release? I'm thinking about trying an older driver. I can't do this to my system.

MickM
05-15-2014, 03:55 PM
After I zapped the PRAM I installed the latest 2.2 beta and now I only get the spew when stuff happens in the DisplayLink window. There are actually several of the same error messages even when I do things in other non-DisplayLink displays, but at least now it's not continuously, relentlessly flooding the console - now it's just activity based. It's still bad and needs fixing, but it's much better. Who knows, it might all start up again like it did with you - if that happens then I'll be uninstalling 2.2 and going back to 2.1 again (with all of it's awful display jittering that 2.2 seems to have fixed).

The only reason I'm using a DisplayLink solution is because, even after all this time, a lightning hub that's even remotely affordable just doesn't exist :-(.

magillagorilla
05-15-2014, 04:14 PM
Well I just cleared my asl logs, and went to 2.1 drivers. So far no logspam. 2.1 drivers so far seem to work just as well as 2.2.

MickM
05-15-2014, 04:21 PM
Well I just cleared my asl logs, and went to 2.1 drivers. So far no logspam. 2.1 drivers so far seem to work just as well as 2.2.

Using 2.1, try going to www.icloud.com in Safari on your DisplayLink monitor and start doing stuff (scrolling, moving windows, selecting things). If you have iCloud Mail try that as well. You'll see a big difference between 2.1 and 2.1 ...

magillagorilla
05-15-2014, 05:09 PM
Using 2.1, try going to www.icloud.com in Safari on your DisplayLink monitor and start doing stuff (scrolling, moving windows, selecting things). If you have iCloud Mail try that as well. You'll see a big difference between 2.1 and 2.1 ...

Hmm.. Using Chrome and went to icloud. I don't have mail there, so I can't try that, but it hasn't caused any extra logging.. yet..

I was able to watch a video in VLClan (not fullscreen) on the displaylink monitor without issue.

I'll keep an eye on it if I see a uptake I'll try to correlate it with something.

MickM
05-15-2014, 05:54 PM
Doh! I wasn't very clear. You won't get any of this silly console logging in 2.1, but what you will see on your DisplayLink monitor when you use Safari to visit iCloud and iCloud Mail is all kinds of display artifact garbage as you try scrolling in windows etc.

MickM
05-15-2014, 08:34 PM
This is interesting. I just sent this email to the developer of CircusPonies Notebook. I'll post his reply if it's relevant.

G'Day Jayson,

So this probably has the makings of developers pointing fingers at each other...

I'm using a DisplayLink monitor (a dongle that has has a DVI output is connected to a USB port on my MacBook Pro and I effectively have another monitor). It obviously needs a driver, and that driver is having some teething problems.

If I put e.g. a Finder window in the DisplayLink monitor then nothing much happens. However, if I put a Notebook window in the DisplayLink monitor and bring that window to the front then I get this continuous steady stream of output appearing in the Console. This only happens if the Notebook window is in the DisplayLink monitor and it's the frontmost window - make any other window the frontmost window and the console output stops. It's almost like an active Notebook window is continuously broadcasting something that's upsetting DisplayLink and/or the WindowServer. A sample of the console output is shown below - any idea what might be causing this?

Regards,

Mick

2014.0515 3:57:09.138 PM WindowServer[97]: _CGXGLDisplayContextForDisplayDevice: No matching context for device (0x7fd694804690) - disabling OpenGL
2014.0515 3:57:09.704 PM WindowServer[97]: _CGXGLDisplayContextForDisplayDevice: No matching context for device (0x7fd694804690) - disabling OpenGL
2014.0515 3:57:10.264 PM WindowServer[97]: _CGXGLDisplayContextForDisplayDevice: No matching context for device (0x7fd694804690) - disabling OpenGL
2014.0515 3:57:10.821 PM WindowServer[97]: _CGXGLDisplayContextForDisplayDevice: No matching context for device (0x7fd694804690) - disabling OpenGL
2014.0515 3:57:11.381 PM WindowServer[97]: _CGXGLDisplayContextForDisplayDevice: No matching context for device (0x7fd694804690) - disabling OpenGL
2014.0515 3:57:11.948 PM WindowServer[97]: _CGXGLDisplayContextForDisplayDevice: No matching context for device (0x7fd694804690) - disabling OpenGL
2014.0515 3:57:12.497 PM WindowServer[97]: _CGXGLDisplayContextForDisplayDevice: No matching context for device (0x7fd694804690) - disabling OpenGL
2014.0515 3:57:13.064 PM WindowServer[97]: _CGXGLDisplayContextForDisplayDevice: No matching context for device (0x7fd694804690) - disabling OpenGL
2014.0515 3:57:13.620 PM WindowServer[97]: _CGXGLDisplayContextForDisplayDevice: No matching context for device (0x7fd694804690) - disabling OpenGL
2014.0515 3:57:14.181 PM WindowServer[97]: _CGXGLDisplayContextForDisplayDevice: No matching context for device (0x7fd694804690) - disabling OpenGL
2014.0515 3:57:14.737 PM WindowServer[97]: _CGXGLDisplayContextForDisplayDevice: No matching context for device (0x7fd694804690) - disabling OpenGL
2014.0515 3:57:15.303 PM WindowServer[97]: _CGXGLDisplayContextForDisplayDevice: No matching context for device (0x7fd694804690) - disabling OpenGL
2014.0515 3:57:15.864 PM WindowServer[97]: _CGXGLDisplayContextForDisplayDevice: No matching context for device (0x7fd694804690) - disabling OpenGL
2014.0515 3:57:16.421 PM WindowServer[97]: _CGXGLDisplayContextForDisplayDevice: No matching context for device (0x7fd694804690) - disabling OpenGL
2014.0515 3:57:16.981 PM WindowServer[97]: _CGXGLDisplayContextForDisplayDevice: No matching context for device (0x7fd694804690) - disabling OpenGL
2014.0515 3:57:17.548 PM WindowServer[97]: _CGXGLDisplayContextForDisplayDevice: No matching context for device (0x7fd694804690) - disabling OpenGL
2014.0515 3:57:17.787 PM WindowServer[97]: _CGXGLDisplayContextForDisplayDevice: No matching context for device (0x7fd694804690) - disabling OpenGL
2014.0515 3:57:18.065 PM WindowServer[97]: _CGXGLDisplayContextForDisplayDevice: No matching context for device (0x7fd694804690) - disabling OpenGL
2014.0515 3:57:18.096 PM WindowServer[97]: _CGXGLDisplayContextForDisplayDevice: No matching context for device (0x7fd694804690) - disabling OpenGL

MickM
05-15-2014, 09:54 PM
I got a reply from the Notebook developer, and he found something interesting that I hope gives a clue to the DisplayLink developers:

Hi Mick,

NoteBook does not use OpenGL directly. OS X might be invoking it on NoteBook's behalf, but for what reason I have no idea. I don't know much about OpenGL or DisplayLink.

I Googled _CGXGLDisplayContextForDisplayDevice to see if I could find any info to help you track it down. I ran across your post of this message, so you've read everything they had to say there. Here is the only other result that I thought might have some good info. It was talking about old drivers (kexts) of some sort. Search for _CGXGLDisplayContextForDisplayDevice to see the comment:

http://forums.macrumors.com/archive/index.php/t-1593194-p-4.html

MickM
05-16-2014, 06:15 PM
So while things are better after zapping the PRAM, I've decided the console logging is still just way too crazy with normal use, so it's back to 2.1 for me. I'll keep (im)patiently waiting for the next beta. I know DisplayLink are implicating at Apple, but version 2.1 didn't log anything like this vast amount of stuff to the console.

D43m0n
07-09-2014, 01:59 PM
Hmm, I'm on the 2.2 version of the driver (not the beta) on 10.9.4 and it's still spewing out these messages in Console.app. Two colleagues have exactly the same issue, one is on a MBA mid 2013, the other is on a 13" MBP (I believe 2012), my MBA is a mid 2012. We're all on 10.9.4.

I'll try zapping the PRAM. I've been waiting to use DisplayLink DL3xxx for more than a year since support was available and since then it's been a lot of issue's. This is another annoying one...

D43m0n
07-09-2014, 03:18 PM
After zapping PRAM and resetting SMC on 10.9.4 with version 2.2 of the driver (not the beta) the "09-07-14 16:16:55,953 WindowServer[96]: _CGXGLDisplayContextForDisplayDevice: No matching context for device (0x7fd9a2e10050) - disabling OpenGL"

message is continuously repeating itself. Zapping PRAM hasn't made a difference at all...

D43m0n
07-15-2014, 03:16 PM
Would you care to comment, DisplayLink?

Carlo
07-17-2014, 05:20 PM
Hi,

This is a known OS issue, triggered depending on the content being drawn on screen and depending on any SW on the system tracking the screen contents. I'm not aware of behavioural issues arising from these logs.

Apple has an internal bug for this, ID 14739701. If you want to raise its priority please open a new bug at bugreporter.apple.com.

Cheers,
Carlo

D43m0n
07-29-2014, 01:15 PM
I did raise a bug at Apple (17619820), they closed it as a duplicate of another issue (16585152). I can't see the details of other issues, only my own (I don't have a full developer account at Apple).

Carlo
08-15-2014, 09:40 AM
Hi D43m0n,

No one external to Apple, even developers, can see other people's issues. This means that once Apple has admitted an issue is theirs nobody has any way to check the status. Through BugReporter at least.

There was a developer petition some time ago to raise the priority of this issue with Apple but I guess it fell short of its objective.

I've been assured that Apple looks at all issues and the number of reports for the same issue affects its priority so let's do everything we can. Hope.

Cheers,
Carlo

BMT
09-17-2014, 04:57 PM
Hi,

This is a known OS issue, triggered depending on the content being drawn on screen and depending on any SW on the system tracking the screen contents. I'm not aware of behavioural issues arising from these logs.

Apple has an internal bug for this, ID 14739701. If you want to raise its priority please open a new bug at bugreporter.apple.com.

Cheers,
Carlo
If it's an OS issue, rather than a kext issue, how is it that older versions of the DisplayLink software (2.1 for example) did not have this issue? - That suggests that it's the result of a change made by DisplayLink not the OS.

This issue is actually more serious than you might think, because the OS is constantly writing to your hard drive which is going to do anything but improve it's longevity.

I've got into the habit of running the following in Terminal on every boot, just to stop the constant writing to the disk (which can really add up if you're using the Mac 8 hours+/day):
sudo launchctl unload /System/Library/LaunchDaemons/com.apple.syslogd.plist

That stops syslogd from running, which has the side effect of disabling the logging from any applications that rely on it - it's far from ideal, but better IMO than the alternative of the constant log spam.

Carlo
09-18-2014, 07:28 AM
If it's an OS issue, rather than a kext issue, how is it that older versions of the DisplayLink software (2.1 for example) did not have this issue? - That suggests that it's the result of a change made by DisplayLink not the OS.

In 2.2 we started using a new API for an important part of the driver. The previous API has been deprecated and its reliability was rapidly decaying with every new OS version.
The new API has benefits but has some issues as well, one of which is the log spamming in some situations. We have raised all issues with Apple.

I cannot share any more information on this I'm sorry

Cheers
Carlo

BMT
10-20-2014, 03:12 PM
In 2.2 we started using a new API for an important part of the driver. The previous API has been deprecated and its reliability was rapidly decaying with every new OS version.
The new API has benefits but has some issues as well, one of which is the log spamming in some situations. We have raised all issues with Apple.

I cannot share any more information on this I'm sorry

Cheers
Carlo
I see, that makes sense - thanks for the explanation.

tmendo
10-23-2014, 08:20 PM
Have should I write in the report for Apple? I want to file a bug report also but not sure what I should write to make it more accurate and less prone to be rejected.

jb8748
11-08-2014, 10:04 PM
I've made a configuration file for ASL to claim all these messages and then ignore them. Seems to be a reasonable solution until such time as a bug fix is available.

http://blog.jamesball.co.uk/2014/11/removing-displaylink-driver.html

Seemone
11-10-2014, 11:24 AM
A finer workaround would be to add

? [= Sender WindowServer] ignore

in the first line of asl.conf (in the etc directory) and then restart syslog by issuing

kill -hup <PID>

where PID is the syslog process pid

This will filter out only WindowServer messages instead of cutting all the syslog output

BMT
11-12-2014, 02:48 PM
Disregard.

mcousins
11-12-2014, 07:36 PM
I seem to have stopped the log spam by adding this to my asl.conf in /etc at the top of the file

? [= Sender WindowServer] ignore

And then performing the sudo kill -HUP [PID of process]

Not sure if that's OK, I tried the other way of creating a file under the asl folder and that did nothing for me.

Hope this helps, even if its just towards finding a better answer!

ehendrix
11-13-2014, 06:18 PM
I changed it a little bit to:

# WindowServer messages about display context (caused by DisplayLink driver)
? [= Sender WindowServer] [= Level Warning] [A= Message _CGXGLDisplayContextForDisplayDevice] claim only

Seems to be working and ensures that any other messages from WindowServer are still going in.

ehendrix
11-20-2014, 10:42 PM
No more messages since I've put this in. Interesting that with all the complaining about this within the forums that DisplayLink was never able to provide this as a solution.
Is it perfect? No.
Is it something Apple should fix? yes
Does the work-around work? Heck yes.
Could DisplayLink provide the work-around? Don't see why not.

Carlo
11-21-2014, 09:12 AM
Hi ehendrix,

Sorry for going quiet on this one. Yes we think this is a good workaround, we could apply it at install time.

We'd use
? [= Sender WindowServer] [=S Message_CGXGLDisplayContextForDisplayDevice] ignore

Unless anyone can spot any issue with the approach?

Cheers,
Carlo

jb8748
11-26-2014, 04:43 PM
I changed it a little bit to:

# WindowServer messages about display context (caused by DisplayLink driver)
? [= Sender WindowServer] [= Level Warning] [A= Message _CGXGLDisplayContextForDisplayDevice] claim only

Seems to be working and ensures that any other messages from WindowServer are still going in.

Thank you ehendrix. That does look like a better command - I'm no expert on the logging so I was finding things that worked. I've updated my blog post.

James

jb510
11-27-2014, 02:18 PM
Hi ehendrix,

Sorry for going quiet on this one. Yes we think this is a good workaround, we could apply it at install time.

We'd use
? [= Sender WindowServer] [=S Message_CGXGLDisplayContextForDisplayDevice] ignore

Unless anyone can spot any issue with the approach?

Cheers,
Carlo

Note that the above declaration is missing a space between Message and _CGX... should be
? [= Sender WindowServer] [=S Message _CGXGLDisplayContextForDisplayDevice] ignore

BMT
11-27-2014, 10:59 PM
Hi ehendrix,

Sorry for going quiet on this one. Yes we think this is a good workaround, we could apply it at install time.

We'd use
? [= Sender WindowServer] [=S Message_CGXGLDisplayContextForDisplayDevice] ignore

Unless anyone can spot any issue with the approach?

Cheers,
Carlo
Hi Carlo, the string you proposed is formatted incorrectly, it would need to be as follows instead else it won't work:
? [= Sender WindowServer] [S= Message _CGXGLDisplayContextForDisplayDevice] ignore

I've confirmed the above works as intended.

PS. Make sure to put the string at the top of asl.conf else it won't work! (Due to other rules taking priority over it and cancelling out the effect). I'm not sure if S= or =S (as you proposed) makes any difference, but I've only ever seen it as S= which is why I put it that way round.

Also, if you're thinking of doing this automatically you should make sure to check there's not already a string containing _CGXGLDisplayContextForDisplayDevice OR WindowServer in asl.conf, as people may have already added the same or a different string to stop it from happening already.

Edit: Looks like someone else beat me to it, I've been trying to post this for the past few days but kept getting forum errors each time I did. The 4th page of the topic wasn't even showing up until I posted my message! Weird.

Carlo
11-28-2014, 10:44 AM
Thank you BMT and others,

Will take your advice, hopefully won't find issues with this change.

Cheers,
Carlo

jb8748
11-28-2014, 11:01 AM
My view is that the DisplayLink installation should not edit the global asl.conf file in any way. I don't think it's the right approach for installers to alter system files when there are other alternatives.

You should use an ASL module, like I outlined in my blog post. My reasoning is:
1) asl.conf can be overwritten at anytime by a system update
2) it is clear who has requested that these stop entering the log - and this itself is logged when ASL starts
3) ASL will/should deal gracefully with cases where people have multiple 'claims' on the messages
4) Removing this (such as when uninstalling the drivers completely) becomes trivial as it's one file to delete. Removing an edit to asl.conf, which may have been subsequently edited, isn't going to be reliable.

Just my thoughts. Looking forward to this making it into the standard installation.

James

ehendrix
12-02-2014, 09:41 PM
Thank you ehendrix. That does look like a better command - I'm no expert on the logging so I was finding things that worked. I've updated my blog post.

James

As I see it, this was all team work. I would have never come to this if it weren't for your blog post and postings from others. :-)

BMT
12-10-2014, 12:37 PM
My view is that the DisplayLink installation should not edit the global asl.conf file in any way. I don't think it's the right approach for installers to alter system files when there are other alternatives.
While I would normally agree that it's bad to alter system files, the method you outlined in your blog post has never worked for me - editing asl.conf is the only method that has.

luckman212
07-21-2015, 06:30 PM
I thought that it was "fixed" but I noticed today these logspam messages continue to appear for me even as of v2.4 (Jul 3 2015) so I had to re-enable this patch.

dude123
05-11-2017, 03:49 PM
Sadly this has become a topic again under 10.12 Sierra. My syslogs get hit by 60.000 messages per second. And none of the above hints helps, also the asl-config coming with the displaylink 3.0 driver doesn't help. Anyone an idea about this?

Carlo
05-12-2017, 09:28 AM
Sadly this has become a topic again under 10.12 Sierra. My syslogs get hit by 60.000 messages per second. And none of the above hints helps, also the asl-config coming with the displaylink 3.0 driver doesn't help. Anyone an idea about this?

Can you please copy and paste the log message? It may be a new one.

Kind regards,
Carlo

dude123
05-12-2017, 12:18 PM
Can you please copy and paste the log message? It may be a new one.


Yes sure!

No matching context for device (0x7fe957c26f90) - disabling OpenGL

Sender:
/System/Library/PrivateFrameworks/SkyLight.framework/Resources/WindowServer
(/System/Library/PrivateFrameworks/SkyLight.framework/Versions/A/SkyLight)

Subsystem:
com.apple.SkyLight

silence
06-09-2017, 05:11 PM
Can you please copy and paste the log message? It may be a new one.

Kind regards,
Carlo

Can confirm this is an issue on Sierra 12.12.5. My log looks exactly like dude123's, and the existing fix no longer works.

steve_s
06-12-2017, 01:29 AM
Yes sure!

No matching context for device (0x7fe957c26f90) - disabling OpenGL

Sender:
/System/Library/PrivateFrameworks/SkyLight.framework/Resources/WindowServer
(/System/Library/PrivateFrameworks/SkyLight.framework/Versions/A/SkyLight)

Subsystem:
com.apple.SkyLight

I am getting the same behavior, running Sierra, with a different 0x... number:

No matching context for device (0x7ff8ca335340) - disabling OpenGL

wa2flq
06-13-2017, 01:28 PM
I seem to have stopped the log spam by adding this to my asl.conf in /etc at the top of the file

? [= Sender WindowServer] ignore

And then performing the sudo kill -HUP [PID of process]



I've tired this asl.conf. I can't seem to make it work in Sierra.
I have SIP (temporarily) turned off. Also tried this in /etc/asl/com.apple.windowserver and com.displaylink.windowserver. I can see that aslmanager is restarting after the HUP to syslog.

I still see tons of messages in the Console. Any thoughts as to what I am doing wrong?

duncanm
06-22-2017, 02:16 PM
As a temporary fix you can enter the following in your terminal:

sudo log config --process=[PID] --mode "level:off"

where [PID] is the ID of the process you see in the console.

You have to re-do it every time you re-start your mac which is a pain, but at least it saves all those writes to your disk

wa2flq
06-23-2017, 03:49 AM
That works, thanks.

dude123
07-27-2017, 09:52 PM
As a temporary fix you can enter the following in your terminal:

sudo log config --process=[PID] --mode "level:off"

where [PID] is the ID of the process you see in the console.

You have to re-do it every time you re-start your mac which is a pain, but at least it saves all those writes to your disk

Yes, can confirm, this is the first "solution" that works on Sierra.
MacOS 10.12.6 - DisplayLink 3.1

benwen
09-07-2017, 06:43 AM
As a temporary fix you can enter the following in your terminal:

sudo log config --process=[PID] --mode "level:off"

where [PID] is the ID of the process you see in the console.

You have to re-do it every time you re-start your mac which is a pain, but at least it saves all those writes to your disk

Thank you duncamn!

Here's a quick and dirty shell script to automate the finding of the PID

#!/bin/sh
pid=`ps -ax | awk '/SkyLight.framework/ && !/awk/ {print $1}'`
echo "Skylight.framework with OpenGL logorrhea PID found. Suppressing log for PID $pid"
sudo log config --process=$pid --mode "level:off"


Put that in a file 'quite-dlink' in your $PATH, chmod 0755 it and execute it in Terminal at startup.

paultzirides
09-11-2017, 01:47 PM
After installing the 4.0 beta, I'm no longer noticing any log spam. I ran the terminal command anyway, but observed no change in the amount or type of logs being generated by the system. Is anyone else seeing the same?

dude123
09-30-2017, 03:33 AM
Problem solved!!!

Update to 4.0 didn't make it better on macOS 10.12 - BUT after the system update to 10.13 combined with 4.0 - now finally the log spam is solved and on top of that also the hardware support for video etc is very much improved.

Well done!! Thank you a lot DisplayLink-Team!!!!

jormsby
10-24-2017, 06:43 PM
My new MacBook Pro running 10.12.6 and with DisplayLink 4.0.0 is filling up my Console with this error message.

I see where 10.13 might fix it but that is not an option on this work computer.

Any suggestions on how to get this to stop?

mattbehnken
12-23-2017, 06:54 PM
Problem solved!!!

Update to 4.0 didn't make it better on macOS 10.12 - BUT after the system update to 10.13 combined with 4.0 - now finally the log spam is solved and on top of that also the hardware support for video etc is very much improved.

Well done!! Thank you a lot DisplayLink-Team!!!!
My logs are filled with 3 per second. Since my log issue is slightly different than the OP I'll post it as an example. I'm not entirely sure it's DisplayLink, but I'm pretty sure.

MacOS High Sierra 10.13.2 - Display Link version 4.0 (sept. newest) with separate spaces checked (enabled)

I was able to suppress log until reboot using: sudo log config --pid=211 --mode "level:off"

Edit:

But you need to lookup the pid every boot, level:off

More Mac log suppression info

http://www.mackungfu.org/TurnoffrunawayloggingonmacOS

Speaking of log spam in High Sierra, I also get month 13 is out of bounds lol, but not as frequently as this:

default 19:04:19.044518 -0700 WindowServer No matching context for device (0x7f898cc3dcb0) - disabling acceleration.
default 19:04:19.044619 -0700 WindowServer No matching context for device (0x7f898cc3dcb0) - disabling acceleration.
default 19:04:19.044671 -0700 WindowServer No matching context for device (0x7f898cc3dcb0) - disabling acceleration.
default 19:04:19.044733 -0700 WindowServer No matching context for device (0x7f898cc3dcb0) - disabling acceleration.
default 19:04:19.044787 -0700 WindowServer No matching context for device (0x7f898cc3dcb0) - disabling acceleration.
default 19:04:19.060220 -0700 WindowServer No matching context for device (0x7f898cc3dcb0) - disabling acceleration.
default 19:04:19.060305 -0700 WindowServer No matching context for device (0x7f898cc3dcb0) - disabling acceleration.
default 19:04:19.060346 -0700 WindowServer No matching context for device (0x7f898cc3dcb0) - disabling acceleration.
default 19:04:19.060396 -0700 WindowServer No matching context for device (0x7f898cc3dcb0) - disabling acceleration.
default 19:04:19.060439 -0700 WindowServer No matching context for device (0x7f898cc3dcb0) - disabling acceleration.
default 19:04:19.153381 -0700 WindowServer No matching context for device (0x7f898cc3dcb0) - disabling acceleration.
default 19:04:19.153478 -0700 WindowServer No matching context for device (0x7f898cc3dcb0) - disabling acceleration.
default 19:04:19.153520 -0700 WindowServer No matching context for device (0x7f898cc3dcb0) - disabling acceleration.
default 19:04:19.153570 -0700 WindowServer No matching context for device (0x7f898cc3dcb0) - disabling acceleration.
default 19:04:19.153614 -0700 WindowServer No matching context for device (0x7f898cc3dcb0) - disabling acceleration.
default 19:04:19.163336 -0700 WindowServer No matching context for device (0x7f898cc3dcb0) - disabling acceleration.
default 19:04:19.163424 -0700 WindowServer No matching context for device (0x7f898cc3dcb0) - disabling acceleration.
default 19:04:19.169631 -0700 WindowServer No matching context for device (0x7f898cc3dcb0) - disabling acceleration.
default 19:04:19.169675 -0700 WindowServer No matching context for device (0x7f898cc3dcb0) - disabling acceleration.
default 19:04:19.169843 -0700 WindowServer No matching context for device (0x7f898cc3dcb0) - disabling acceleration.
default 19:04:19.224995 -0700 WindowServer No matching context for device (0x7f898cc3dcb0) - disabling acceleration.
default 19:04:19.225121 -0700 WindowServer No matching context for device (0x7f898cc3dcb0) - disabling acceleration.
default 19:04:19.225161 -0700 WindowServer No matching context for device (0x7f898cc3dcb0) - disabling acceleration.
default 19:04:19.225210 -0700 WindowServer No matching context for device (0x7f898cc3dcb0) - disabling acceleration.
default 19:04:19.225253 -0700 WindowServer No matching context for device (0x7f898cc3dcb0) - disabling acceleration.
default 19:04:19.421640 -0700 WindowServer No matching context for device (0x7f898cc3dcb0) - disabling acceleration.

skew4
02-07-2018, 02:11 AM
Problem solved!!!

Update to 4.0 didn't make it better on macOS 10.12 - BUT after the system update to 10.13 combined with 4.0 - now finally the log spam is solved and on top of that also the hardware support for video etc is very much improved.

Well done!! Thank you a lot DisplayLink-Team!!!!

Errr... I think you meant: Thank you Apple ! :-)

Some people have expressed concerned about wearing out disks. I don't know about that, however there's another massive difference that the super useful "log config level off" workaround just made: *responsiveness*. The short but still very painful lag between the moment I hit the keyboard and characters appears on the screen is finally gone.

For months and months until I found this message in the logs by chance (while looking for something else) I've been telling all my colleagues that DisplayLink was a technology really not for everyone because of a severe trade-off to make between screen real estate and responsiveness. Now I understand it was actually just that logging issue.

Has Apple any plan to backport the fix to Sierra?

Has DisplayLink updated their test plans to include responsiveness? (and also logging why not)

skew4
02-08-2018, 09:31 PM
My syslogs get hit by 60.000 messages per second.

Indeed:

# log show --last 6h --predicate 'messageType == error and processImagePath endswith "DisplayLinkManager"'

Timestamp Thread Type Activity PID
2018-02-08 09:34:12.277266 0xf609a Error 0x0 115 DisplayLinkManager: (CoreFoundation) Detected potentially harmful notification post rate of 60.0026 notifications per second

This message shows up even with the "level: off" workaround (but infrequently).

The fact that my monitors run at 60Hz is likely not a coincidence.