Latest ElCap upgrade hanging 10.11.6 - "Stalling for detach"

The files such as WindowServer_2017-01-05-090712_Seans-MacBook-Pro.userspace_watchdog_timeout should contain a stack trace which says where the WindowServer was stalled. This should actually be useful to confirm the bug. I would guess you'll see IOService::attach() close to the bottom which confirms the same cause other people including me are seeing.

I do strongly suspect it's the kernel update (possibly as well as some other update) because the kernel has changed since the original 10.11.6 and the "stalling for detach" message is only in the later source code. If you look at the source code for 10.12.1 (which I assume was back ported) the following two things in IOService::attach() strongly point to this bug:

1. There's new code which checks the accelerator child count (i.e. the number of threads using the accelerator device) and trigger the "stalling for detach" message if the count is >= 251. This code is new and strongly implies any case that triggers lots of accelerator users may trigger this bug:

count = provider->getChildCount(gIOServicePlane);

wait = (count > (kIOServiceBusyMax - 4));

if ( [...wait...] )

{

IOLog("stalling for detach from %s\n", provider->getName());

2. Later in the same function if this 251 child limit is reached, the stall involves an explicit wait for up to 15 seconds which seems to match the length of the desktop freeze:

clock_interval_to_deadline(15, kSecondScale, &deadline); // seems like 15 second delay unless woken up sooner

...

assert_wait_deadline((event_t)&provider->__provider, THREAD_UNINT, deadline);

It seems clear that the expectation is that normally the process should be woken up much sooner than 15 seconds by other accelerator users freeing their clients, but this is apparently not happening. Apple probably needs to look at why this code change was made and what is apparently going wrong with it ...

In the original 10.11.6 the attach proceeds without any "stalling for detach" or 15 second timeout which very strongly suggests that this change is to blame. It may or may not be non trivial to work out how to fix the bug, but this code definitely seems to be involved in the problem.

Bingo, here it is from a Windowserver watchdog timeout spindump.

Thanks for the analysis.

Report Version: 22

Hardware model: Macmini6,2

--------------------------------------------------

Timeline format: stacks are sorted chronologically

Use -i and -heavy to re-report with count sorting

--------------------------------------------------

Heaviest stack for the main thread of the target process:

10 start + 1 (libdyld.dylib + 13741) [0x7fff98c5a5ad]

10 ??? (WindowServer + 3966) [0x10b149f7e]

10 CGXServer + 7273 (CoreGraphics + 2334196) [0x7fff94c21df4]

10 CGXRunOneServicesPass + 1928 (CoreGraphics + 2326676) [0x7fff94c20094]

10 post_port_data + 234 (CoreGraphics + 2339805) [0x7fff94c233dd]

10 connectionHandler + 137 (CoreGraphics + 3825303) [0x7fff94d8de97]

10 CGXHandleMessage + 88 (CoreGraphics + 5042918) [0x7fff94eb72e6]

10 __connectionHandler_block_invoke + 86 (CoreGraphics + 3833427) [0x7fff94d8fe53]

10 _XHWCaptureWindowList + 1882 (CoreGraphics + 4382670) [0x7fff94e15fce]

10 CGXHWCaptureWindowList + 1559 (CoreGraphics + 4255378) [0x7fff94df6e92]

10 CGXConstructVirtualFramebufferFromDevice + 453 (CoreGraphics + 2298787) [0x7fff94c193a3]

10 IOAccelCreateSurface + 75 (IOKit + 68840) [0x7fff8fd46ce8]

10 IOServiceOpen + 45 (IOKit + 23646) [0x7fff8fd3bc5e]

10 io_service_open_extended + 128 (IOKit + 415735) [0x7fff8fd9b7f7]

10 mach_msg_trap + 10 (libsystem_kernel.dylib + 69490) [0x7fff985d0f72]

*10 hndl_mach_scall64 + 22 (kernel + 2008006) [0xffffff80003ea3c6]

*10 mach_call_munger64 + 410 (kernel + 1794650) [0xffffff80003b625a]

*10 mach_msg_overwrite_trap + 197 (kernel + 849637) [0xffffff80002cf6e5]

*10 ipc_kmsg_send + 184 (kernel + 784696) [0xffffff80002bf938]

*10 ipc_kobject_server + 259 (kernel + 901891) [0xffffff80002dc303]

*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) [0xffffff7f82994e33]

*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]

<IO policy important>

10 start + 1 (libdyld.dylib + 13741) [0x7fff98c5a5ad] 1-10

<thread QoS user initiated (requested user initiated), IO policy important>

10 _dispatch_mgr_thread + 52 (libdispatch.dylib + 32205) [0x7fff91cd5dcd] 1-10

<IO policy important>

10 thread_start + 13 (libsystem_pthread.dylib + 4945) [0x7fff9a8fa351] 1-10

Binary Images:

*0xffffff7f82971000 - 0xffffff7f829a8fff com.apple.iokit.IOAcceleratorFamily2 205.11 (205.11) <569DA297-BC38-35C0-B909-6E8686BE0928> /System/Library/Extensions/IOAcceleratorFamily2.kext/Contents/MacOS/IOAccelerat orFamily2

I have the same exact issue on 3 of my mac at home (Macbook Pro 15" Retina mid-2015, another 2012, and macmini 2011). All pausing randomly due to windowserver hanging. I find that odd that not more people are seeing this issue. The problem starts for me after 3-4 days of use sometime sooner. I do use VMware Fusion, Duet display, Lightroom, not sure if those are part of the trigger. My wife only uses safari and is able to see the issue usually after watching YouTube videos. Certainly seems graphic driver related. The spimdump does contain stack traces that can be useful in knowing where the pause is occurring. Apple should analyse those.

I think many will have this issue, not all will post on the forum. However, to really get the ball rolling, make sure to post a bug report to Apple: http://bugreport.apple.com

I was definitely helped by users on this topic to look at the spin dump and I have posted that as an attachment in my bug report to Apple.

Many have written before, don't think it is necessarily application related. Some of us have VM's running, some don't. Others blame Safari, where I have read of users that don't use Safari and only use FireFox.

Hard to pinpoint. I have a stand alone "hang" like Dec. 29th, had 3 occasions where the computer kept hanging on Jan. 3rd, since Jan. 3rd's last reboot it hasn't occurred for me anymore.

Most important of all, I have found no way of replication the issue deliberately. And not using the Mac any different than on the days it hung.

Let's hope Apple picks this one up quickly.

I have the same issue, and i thought upgrade to Sierra would fix it.

I have been staring at "about 29 minutes remaining" on install screen for about 49 minutes....

Now i see it ticking down, albeit slowly.

So it seems the bet is on "ugrade won't fix it"....

Your install may still finish fine. If so, does 10.12.2 fix the stalling or not? Alternatively, one can download 10.11.6 an install that version, because the faulty security update is not part of the 10.11.6 build.

me also suffering through,

kernel[0]: stalling for detach from nvAccelerator

again - System always on, happens every ~3-5 days or so.

I sent a bug report to apple first on 03.02.2017, they came back on me to verify the error by using sysdiagonstic if it happens again. Since the error just occured, i gave them the report. It seems, they are investigating it.

After it happens first, as others reporting, windows focus changes are triggering the error then, rendering the system unusable.

Same problem here, message is "1/10/17 7:09:27.000 AM kernel[0]: stalling for detach from AMDVerdeGraphicsAccelerator" and is repeated every 15-30 seconds. In my case quitting most (but not all) of my running applications made the problem go away, at least temporarily.

MacBook Pro (Retina, 15-inch, Mid 2015), OS X 10.11.6 (15G1212), Kernel Darwin 15.6.0

> they came back on me to verify the error by using sysdiagonstic [sic]

I'm not familiar with this; is it a Terminal command?

Put me in the "me too" category, same build, 15G1212, Safari is the fastest way to trigger the issue, I typically have > 15 tabs open in 2 or more windows (Safari).

I do have Virtual Box, although I don't believe that has anything to do with the issue, ssh is normal responsiveness, anything GUI is PAINFUL once it starts acting up, usually makes the machine virtually unusable within 2-4 hours after flair up.

iMac 21.5 Late 2012

CTO - 3.1 i7, 16GB Ram, GT 650M 512 MB

Chrde is onto something. I rebooted and had been problem-free.

roberts-iMac7:html robertlipe$ uptime

13:18 up 6 days, 15:53, 5 users, load averages: 3.05 3.17 2.83

console says I started getting them 1:20 ago.

I guess we're now Windows users and get to schedule reboot every N days. 😟

On Tue, Jan 10, 2017 at 4:42 AM, Apple Support Communities Updates <

2^29 milliseconds is 6.2 days (6 days, six hours) That's an odd size for a

timer to wrap. Problems at 2*30 and 2*31 are common as it's common to use

the top bit for sign. But if there's a 29 bit timer (perhaps it's an enum

packed into a word or something) that's overflowing/underflowing that would

be a smoking gun. Perhaps someone didn't handle a overflow/underflow

correctly. It's an unusual value - and probably not coincidence.

Had the same issue on late 2013 iMac 27", frozen system, even the screensaver was more stuttering then flurry.

As we use a netSUS update server for our company I could see Apple provided "Incompatible Kernel Extension Configuration Data" for several OS X versions with date 2017-01-04 and "Core suggestions Configuration Data" on 2017-01-10.

After deploying both today and a reboot the issue seems to be fixed by now.

Sorry I didnt perform this in the correct way -step by step to see which of both fixed it- maybe someone is able to check this ?

Regards

Dirk 😎

(1) Where are these files on OS X? How can I check if anything has been updated on my system? Can't find files with those names anywhere on my system.

(2) Why do you think the problem is fixed? Usually it takes a few days of uptime before the problem appears.