Endless log spam _CGXGLDisplayContextForDisplayDevice: No matching context for device
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 Code:
5/12/14 10:39:21.472 PM WindowServer[295]: _CGXGLDisplayContextForDisplayDevice: No matching context for device (0x7fbae3402cd0) - disabling OpenGL Any suggestions on how to stop? I'm on 10.9.2 |
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. |
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. |
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. |
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 :-(. |
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.
|
Quote:
|
Quote:
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. |
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.
|
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 |
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/...93194-p-4.html |
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.
|
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... |
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... |
Would you care to comment, DisplayLink?
|
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 |
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).
|
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 |
Quote:
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): Quote:
|
Quote:
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 |
Quote:
|
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.
|
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/...nk-driver.html |
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 |
Disregard.
|
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! |
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. |
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. |
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 |
Quote:
James |
Quote:
Code:
? [= Sender WindowServer] [=S Message _CGXGLDisplayContextForDisplayDevice] ignore |
Quote:
? [= 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. |
Thank you BMT and others,
Will take your advice, hopefully won't find issues with this change. Cheers, Carlo |
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 |
Quote:
|
Quote:
|
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.
|
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?
|
Quote:
Kind regards, Carlo |
Quote:
Code:
No matching context for device (0x7fe957c26f90) - disabling OpenGL /System/Library/PrivateFrameworks/SkyLight.framework/Resources/WindowServer (/System/Library/PrivateFrameworks/SkyLight.framework/Versions/A/SkyLight) Subsystem: com.apple.SkyLight |
All times are GMT. The time now is 08:49 AM. |
Powered by vBulletin® Version 3.8.7
Copyright ©2000 - 2024, vBulletin Solutions, Inc.