Latest ElCap upgrade hanging 10.11.6 - "Stalling for detach"

My most recent time happened when my machine had been up for over 7 days, so it's not the 2^29 seconds thing someone mentioned. And I haven't noticed any particular application it's related to. When it happened this time, I'd just brought it out of display sleep in the morning. And when I looked in the log, the first "stalling for detach" message was several minutes before I woke it up, so it was essentially idle except for whatever automated stuff runs in the background.

Yup. Killing UserEventAgent definitely is the best bandaid we've got so far. Nice find. Now, if someone were able to create a script that could detect when UserEventAgent needs to be killed, and do that automatically.... 😝

Rather than look for a lock condition to kill this agent, perhaps just running a script that kills it off every six hours regardless of state would do as a band-aid until Apple fixes things. Of course, this might also end up being the Apple "fix" for the problem.

MBPro early 2013 10.11.6 Same problem. Chrome and Safari quits seem to help but then delays come back with a vengeance. I did the UserEventAgent kill thing and no delays yet. In Activity Monitor I noticed that it had 3200 ports in the memory tab. When it restarted it had 329.

I just installed the supplemental update, rebooted and logged in to find my entire homedir was wiped out. Everything is back to the El Capitan defaults.

I'll be spending the morning restoring from Time Machine, Backblaze and SuperDuper.

Be careful.

I'm still seeing the "deny mach-lookup" messages since reindexing:

Jan 19 14:25:37 Barry-Margolins-MacBook sandboxd[124] ([6747]): mdworker(6747) deny mach-lookup com.apple.bird.token (import fstype:hfs fsflag:480D000 flags:45E diag:0 isXCode:0 uti:com.apple.mail.emlx plugin:/Library/Spotlight/Mail.mdimporter - find suspect file using: sudo mdutil -t 18817824)

Most of the time when I run the command to find the suspect file it says "Unable to resolve path". But when I ran it for this one, it found a .emlx file in one of my IMAP folders, and I looked in the file to see what message it was. The message in question was received 40 minutes before the log message, and automatically moved into the folder by a filtering rule.

Interesting to note that in addition to the supplemental update released Jan 17, Apple also REISSUED a new Security Update 2016-003 (10.11.6) (full version) on Jan 17, replacing the initial one released on Dec 13, presumably with the supplemental fixes slipped in. Strangely though, they still have the original from Dec 13 posted on the Support site, along with the new one.

I have a Mac that I never applied Security Update 2016-003 (10.11.6) too (original or revised); I supposed it would be interesting to see if I update through the App Store now, which one gets installed, the original from Dec 13 or the reissue from Jan 17. I should be able to tell from the build number I end up with either 15G1212 or 1217

Well, there are several articles out now about the supplemental, and stating that in fact, those that had not installed Security Update 2016-003 (10.11.6) before, will get the new revised one through the App Store, and those that did already install it will get the Supplemental update, or if they choose they can also install the full, revised update. There's very little size difference between the supplemental and the revised full, which suggests there was alot more fixed than just the kernel problem.

If you're not sure which Security Update 2016-003 you have (Dec 13 or Jan 17), here's the hash:

Dec 13 release SHA1- 53770436F3DBEB60FE8B131412215C9EEE5108EE

Jan 17 release SHA1- C35481EF608A90B1FE7B69FC117F05D5565758B6

Installed supplemental udpdate on MacBook Air (mid-2013) on Jan 19.

Went through steps that would trigger symptoms since late December,

and the MBA shows no issues. Looks like it is solved, so far, so good :-)

I have the same issue as described in the referenced thread (with logs): Re: Stalling for detach from IntelAccelerator, nvAccelerator

I think the best you can do is submit a bug report with Apple:

https://bugreport.apple.com

Having the same issue. System is unresponsive for minutes at a time, and then accelerates through all the clicks, keyboard commands and window focus' that I performed during the unresponsive period. After 10-15 seconds, the system goes unresponsive again. Restarts fix things temporarily.

I have the same problem with a Mac Mini (Late 2012) 8GB RAM and an iMac (2016) 16GB RAM. In the first case the message is "stalling for detach from IntelAccelerator", in the second "stalling for detach from nvAccelerator".

The application typically running are: Mail, Safari (~15 tabs), Console, iterm2 (~ 15 windows), MacVim, Preview (~ 3 windows), Mathematica, LatexIt, Creative Cloud, Adobe Illustrator CC 2017, Dropbox, Newsbar.

The problem is more frequent when I start using again the computer after a period (>~ 1 hour) of inactivity.

No VirtualBox istalled.

Same problem with two separate machines: iMac Late 2012 32GB RAM, and MBP mid 2010, 8GB RAM, both running OS 10.11.6. After updating with the latest Apple security patch, both computers started to experience Window Manager hangs after being up for a day or two, and then woken up from either system sleep or display sleep. At that point there would be hanging when switching focus from one window to another, or working within individual apps like Mail and Safari (or any other - not application specific).

The "hanging" is a stall of the WM for 15 or 30 seconds, followed by normal function until the next stall a minute or two later when the user changes window focus. Reboot temporarily restores normal WM function for a few hours - maybe a day.

Console syslog message would generally include: "stalling for detach from nvAccelerator"

I have the same issue. I filed a bug. In my case, lots of Safari windows seemed to be the problem because killing Safari made things Ok, but re-starting Safari made the hangs start again,

FWIW I have spin dump files from some of the hangs, and the bottom of the WindowServer stack in each case says:

*10 ??? (kernel + 1657729) [0xffffff8000394b81]

*10 is_io_service_open_extended + 569 (kernel + 7192905) [0xffffff80008dc149]

*10 IOService::newUserClient(task*, void*, unsigned int, OSDictionary*, IOUserClient**) + 49 (kernel + 6889537) [0xffffff8000892041]

*10 IOGraphicsAccelerator2::newUserClient(task*, void*, unsigned int, IOUserClient**) + 461 (IOAcceleratorFamily2 + 146995) [0xffffff7f825a2e33]

*10 IOService::attach(IOService*) + 406 (kernel + 6850214) [0xffffff80008886a6]

*10 thread_block_reason + 175 (kernel + 974447) [0xffffff80002ede6f]

*10 ??? (kernel + 987996) [0xffffff80002f135c]

*10 machine_switch_context + 364 (kernel + 1864716) [0xffffff80003c740c]

It does look like an arbitration issue because of too many requests for accelerators, so presumably any case of lots of accelerator requests may trigger this. Unless the problem is previous requests not being freed?