PDA

View Full Version : MacBook Pro / Air Graphics Engine Lockup



iMic
10th March 2013, 11:27 PM
I finished typing up and firing this email off to the Mac OS X team at Apple a few moments ago.


I have a MacBook Air (Mid 2012), 13-inch 1.8GHz with 8GB Memory and 512GB SSD, running OS X Mountain Lion 10.8.2. The system utilises the Intel HD Graphics 4000 graphics engine with 512MB of VRAM. There are no third party peripherals attached to the system.

I have noticed a major issue with the operating system that is not easily reproduced as it seems to occur at random, but the issue is very frequent. Some investigation suggests the issue is in software. A clean reinstall has not resolved the problem.

The system will periodically lock up entirely. I can still hear music playing, however I am unable to adjust the volume suggesting that keyboard input is not being received or is not being processed by the system. The cursor still moves without issue on the display, however all other visual elements are unresponsive.

I had iTunes, TextEdit and Safari open at the time. My very last action was switching to a new tab in Safari before the system locked up. At the exact moment of the lockup, this began appearing in the Console "All Messages" log:

10/03/13 11:21:18.000 PM kernel[0]: stampWait: Overflowed checking for stamp 0xea53b09 on MAIN ring: called from
10/03/13 11:21:18.000 PM kernel[0]: timestamp = 0xea53b01
10/03/13 11:21:18.000 PM kernel[0]: **** Debug info for *possible* hang in MAIN graphics engine ****
10/03/13 11:21:18.000 PM kernel[0]: ring head = 0x08a04198, wrap count = 69
10/03/13 11:21:18.000 PM kernel[0]: ring tail = 0x00004828
10/03/13 11:21:18.000 PM kernel[0]: ring control = 0x0000f001 enabled, auto report disabled, not waiting, semaphore not waiting, length = 0x010 4KB pages
10/03/13 11:21:18.000 PM kernel[0]: timestamps = 0xea53b01
10/03/13 11:21:18.000 PM kernel[0]: Semaphore register values:
10/03/13 11:21:18.000 PM kernel[0]: VRSYNC: (0x12044) = 0xea53b01
10/03/13 11:21:18.000 PM kernel[0]: BRSYNC: (0x22040) = 0x0
10/03/13 11:21:18.000 PM kernel[0]: RVSYNC: (0x 2040) = 0x0
10/03/13 11:21:18.000 PM kernel[0]: BVSYNC: (0x22044) = 0x0
10/03/13 11:21:18.000 PM kernel[0]: RBSYNC: (0x 2044) = 0x0
10/03/13 11:21:18.000 PM kernel[0]: VBSYNC: (0x12040) = 0x0
10/03/13 11:21:23.000 PM kernel[0]: stampWait: Overflowed checking for stamp 0xea53b0a on MAIN ring: called from
10/03/13 11:21:23.000 PM kernel[0]: timestamp = 0xea53b01

This block of diagnostic output would repeat over and over at intervals of exactly 5 seconds (11:21:18, then 11:21:23, then 11:21:28 and so on) until the system was hard powered off and restarted. On restart, I was prompted to reopen applications as the computer was restarted "because of a problem", however it did not provide any option to view or send the diagnostic output to Apple.

The issue is inconvenient, but mostly concerning as it seems to be common (a search for "Debug info for *possible* hang in MAIN graphics engine" seems to return many results) and the computer is otherwise passing diagnostic tests such as Apple Service Toolkit and Apple Service Diagnostic through authorised service channels. I don't believe the issue to be hardware related.

If I can provide further details, do feel free to contact me as I will be happy to assist in any way possible.

The issue is random, but it does occur frequently. The system will be functioning correctly with no abnormalities, temperatures are quite reasonable, CPU and memory utilisation is at 25% at best. Attempt to switch to another tab in Safari, or open an application, even create a new document and out of nowhere, the system freezes. Audio continues to play, but you can't adjust the volume as the system has stopped receiving keyboard input. The trackpad cursor still moves on the screen without issue, but that's all it can do - the user interface has stalled completely.

I do notice it only affects my MacBook Air (Intel HD 4000) and not my older MacBooks with nVidia GeForce 9400M and 320M chips, respectively. A quick search around seems to suggest it's a common issue, likely to be in software, although clean installs and new user accounts don't resolve the problem. The issue would appear to be in the Intel HD 3000 / 4000 graphics drivers in OS X Mountain Lion, although as we approach 10.8.3, the issue has yet to be resolved despite being first reported around the various boards in the middle of last year.

I've attached the full Console output for reference. Nothing occurs for several minutes immediately before the issue, and prior to that only some mdworker (Spotlight) and Time Machine messages regarding backups not starting (which is normal, the backup drive is not attached). The output is the full output from when I returned to the idle machine and began using it, not logging any console output, with the crash occurring at 11:21 PM, where the output begins.


10/03/13 11:21:18.000 PM kernel[0]: stampWait: Overflowed checking for stamp 0xea53b09 on MAIN ring: called from
10/03/13 11:21:18.000 PM kernel[0]: timestamp = 0xea53b01
10/03/13 11:21:18.000 PM kernel[0]: **** Debug info for *possible* hang in MAIN graphics engine ****
10/03/13 11:21:18.000 PM kernel[0]: ring head = 0x08a04198, wrap count = 69
10/03/13 11:21:18.000 PM kernel[0]: ring tail = 0x00004828
10/03/13 11:21:18.000 PM kernel[0]: ring control = 0x0000f001 enabled, auto report disabled, not waiting, semaphore not waiting, length = 0x010 4KB pages
10/03/13 11:21:18.000 PM kernel[0]: timestamps = 0xea53b01
10/03/13 11:21:18.000 PM kernel[0]: Semaphore register values:
10/03/13 11:21:18.000 PM kernel[0]: VRSYNC: (0x12044) = 0xea53b01
10/03/13 11:21:18.000 PM kernel[0]: BRSYNC: (0x22040) = 0x0
10/03/13 11:21:18.000 PM kernel[0]: RVSYNC: (0x 2040) = 0x0
10/03/13 11:21:18.000 PM kernel[0]: BVSYNC: (0x22044) = 0x0
10/03/13 11:21:18.000 PM kernel[0]: RBSYNC: (0x 2044) = 0x0
10/03/13 11:21:18.000 PM kernel[0]: VBSYNC: (0x12040) = 0x0
10/03/13 11:21:23.000 PM kernel[0]: stampWait: Overflowed checking for stamp 0xea53b0a on MAIN ring: called from
10/03/13 11:21:23.000 PM kernel[0]: timestamp = 0xea53b01
10/03/13 11:21:23.000 PM kernel[0]: **** Debug info for *possible* hang in MAIN graphics engine ****
10/03/13 11:21:23.000 PM kernel[0]: ring head = 0x08a04198, wrap count = 69
10/03/13 11:21:23.000 PM kernel[0]: ring tail = 0x000048a0
10/03/13 11:21:23.000 PM kernel[0]: ring control = 0x0000f001 enabled, auto report disabled, not waiting, semaphore not waiting, length = 0x010 4KB pages
10/03/13 11:21:23.000 PM kernel[0]: timestamps = 0xea53b01
10/03/13 11:21:23.000 PM kernel[0]: Semaphore register values:
10/03/13 11:21:23.000 PM kernel[0]: VRSYNC: (0x12044) = 0xea53b01
10/03/13 11:21:23.000 PM kernel[0]: BRSYNC: (0x22040) = 0x0
10/03/13 11:21:23.000 PM kernel[0]: RVSYNC: (0x 2040) = 0x0
10/03/13 11:21:23.000 PM kernel[0]: BVSYNC: (0x22044) = 0x0
10/03/13 11:21:23.000 PM kernel[0]: RBSYNC: (0x 2044) = 0x0
10/03/13 11:21:23.000 PM kernel[0]: VBSYNC: (0x12040) = 0x0
10/03/13 11:21:28.000 PM kernel[0]: stampWait: Overflowed checking for stamp 0xea53b0b on MAIN ring: called from
10/03/13 11:21:28.000 PM kernel[0]: timestamp = 0xea53b01
10/03/13 11:21:28.000 PM kernel[0]: **** Debug info for *possible* hang in MAIN graphics engine ****
10/03/13 11:21:28.000 PM kernel[0]: ring head = 0x08a04198, wrap count = 69
10/03/13 11:21:28.000 PM kernel[0]: ring tail = 0x00004918
10/03/13 11:21:28.000 PM kernel[0]: ring control = 0x0000f001 enabled, auto report disabled, not waiting, semaphore not waiting, length = 0x010 4KB pages
10/03/13 11:21:28.000 PM kernel[0]: timestamps = 0xea53b01
10/03/13 11:21:28.000 PM kernel[0]: Semaphore register values:
10/03/13 11:21:28.000 PM kernel[0]: VRSYNC: (0x12044) = 0xea53b01
10/03/13 11:21:28.000 PM kernel[0]: BRSYNC: (0x22040) = 0x0
10/03/13 11:21:28.000 PM kernel[0]: RVSYNC: (0x 2040) = 0x0
10/03/13 11:21:28.000 PM kernel[0]: BVSYNC: (0x22044) = 0x0
10/03/13 11:21:28.000 PM kernel[0]: RBSYNC: (0x 2044) = 0x0
10/03/13 11:21:28.000 PM kernel[0]: VBSYNC: (0x12040) = 0x0
10/03/13 11:21:33.000 PM kernel[0]: stampWait: Overflowed checking for stamp 0xea53b03 on MAIN ring: called from
10/03/13 11:21:33.000 PM kernel[0]: timestamp = 0xea53b01
10/03/13 11:21:33.000 PM kernel[0]: **** Debug info for *possible* hang in MAIN graphics engine ****
10/03/13 11:21:33.000 PM kernel[0]: ring head = 0x08a04198, wrap count = 69
10/03/13 11:21:33.000 PM kernel[0]: ring tail = 0x00005748
10/03/13 11:21:33.000 PM kernel[0]: ring control = 0x0000f001 enabled, auto report disabled, not waiting, semaphore not waiting, length = 0x010 4KB pages
10/03/13 11:21:33.000 PM kernel[0]: timestamps = 0xea53b01
10/03/13 11:21:33.000 PM kernel[0]: Semaphore register values:
10/03/13 11:21:33.000 PM kernel[0]: VRSYNC: (0x12044) = 0xea53b01
10/03/13 11:21:33.000 PM kernel[0]: BRSYNC: (0x22040) = 0x0
10/03/13 11:21:33.000 PM kernel[0]: RVSYNC: (0x 2040) = 0x0
10/03/13 11:21:33.000 PM kernel[0]: BVSYNC: (0x22044) = 0x0
10/03/13 11:21:33.000 PM kernel[0]: RBSYNC: (0x 2044) = 0x0
10/03/13 11:21:33.000 PM kernel[0]: VBSYNC: (0x12040) = 0x0

Anyone else here experienced this issue, or know anything about it and wish to shed some light on why it occurs?

Cheers,
Michael

bennyling
11th March 2013, 12:12 AM
Grats on 1000 posts :)

I daresay you've done much more than the average person would do to track down the issue, but if you've narrowed down the issue to being an OS-level fault I doubt there's much that can be done about the issue outside of Cupertino, I'm afraid.

iMic
11th March 2013, 11:32 PM
Cheers, I knew I was coming up on 1000 but I wasn't aware I had crossed that milestone. Time to get my drink on to celebrate.

I don't expect anyone but Apple to be able to address the fault, but it does have me curious as to its origin. It looks as if something is causing the graphics engine or driver to fall over, which of course halts the system video output. What's unusual is it doesn't seem to be consistent at all, it just occurs out of the blue, regardless of the combinations of applications currently running, system load, system temperature... it's quite bizarre.

I doubt Apple will respond but we'll see if anything happens with the new few OS updates.

Oldmacs
11th March 2013, 11:52 PM
I read somewhere that ivy bridge drivers for osx are not very good- explaining all the weird behaviour from my MacBook Pro!

iMic
16th May 2013, 11:51 PM
Some closure to this issue. The Logic Board was replaced back in early April and the issue hasn't reoccurred since, although it does coincide with the release of 10.8.3 - the board was replaced also for a potential thermal issue. To anyone else experiencing these issues, perform a software update first and see if this corrects your issue. If not, don't be afraid to exercise any warranty coverage in getting it resolved as it could be graphics hardware related.

The replacement board is not what I would call fantastic, it looked physically pretty shabby compared to the original, solder flux still present in a number of locations that I had to clean off. I would have returned it to Apple and asked for another, but for once the machine works, so I decided to stick with the component that would at least function correctly.