Count on Apple to take something that works, and break it. We once had a reliable macOS, 4 or 5 years ago.
When if ever will we ever again have a macOS that doesn’t kernel panic on a regular basis?!
Meanwhile, engineering work is expended on backdoor spying infrastructure that is ideal for totalitarians all over the world. Which is why every privacy-oriented organization is in shock and awe at Apple’s poor judgment. Apple does not deserve any trust whatsoever in the realm of privacy—assume that everything you do is wide open. Because they won’t tell you when they decide to expand the scope of their spying.
My 2019 Mac Pro would not wake up this morning. It had crashed and shut itself off. Why and how it should do so when idle is beyond me.
A reader is having horrible kernel panic problems using Adobe Lightroom on his 2020 iMac 5K. Basically he cannot get work done.
A modern operating system should be able to run all year without a crash. But the emoji-happy managers at Apple cannot make macOS run for more than a week at a time, while embedding spyware into iOS and maybe soon macOS. This new problem might be related to the last Apple update?
Update 2021-09-05: it happened again, and it has also destroyed all file systems on one of my SSD backup drives (Disk Utility format). At this point I'll have to remove this drive and consider it suspect, but it has otherwise been operating normally.
panic(cpu 0 caller 0xffffff80161d51f7): "IOSCSIPeripheralDeviceType00::setPowerState(0xffffff95a5c646c0 : 0xffffff80185ae1cc, 3 -> 2)
timed out after 101093 ms"@/System/Volumes/Data/SWE/macOS/BuildRoots/d7e177bcf5/Library/
Caches/com.apple.xbs/Sources/xnu/xnu-7195.141.2/iokit/Kernel/IOServicePM.cpp:5382 Backtrace (CPU 0), Frame : Return Address 0xffffffa5fdd8bac0 : 0xffffff8015a8e04d 0xffffffa5fdd8bb10 : 0xffffff8015bd4e13 0xffffffa5fdd8bb50 : 0xffffff8015bc540a 0xffffffa5fdd8bba0 : 0xffffff8015a32a2f 0xffffffa5fdd8bbc0 : 0xffffff8015a8d86d 0xffffffa5fdd8bce0 : 0xffffff8015a8db63 0xffffffa5fdd8bd50 : 0xffffff801629dc0a 0xffffffa5fdd8bdc0 : 0xffffff80161d51f7 0xffffffa5fdd8be10 : 0xffffff80161d4b19 0xffffffa5fdd8be20 : 0xffffff80161edc5e 0xffffffa5fdd8be60 : 0xffffff80161d3898 0xffffffa5fdd8be80 : 0xffffff8015ad4605 0xffffffa5fdd8bef0 : 0xffffff8015ad5574 0xffffffa5fdd8bfa0 : 0xffffff8015a3213e Process name corresponding to current thread: kernel_task Mac OS version: 20G95 Kernel version: Darwin Kernel Version 20.6.0: Wed Jun 23 00:26:31 PDT 2021; root:xnu-7195.141.2~5/RELEASE_X86_64 Kernel UUID: FECBF22B-FBBE-36DE-9664-F12A7DD41D3D KernelCache slide: 0x0000000015800000 KernelCache base: 0xffffff8015a00000 Kernel slide: 0x0000000015810000 Kernel text base: 0xffffff8015a10000 __HIB text base: 0xffffff8015900000 System model name: MacPro7,1 (Mac-27AD2F918AE68F61) System shutdown begun: NO Hibernation exit count: 0 System uptime in nanoseconds: 137987168157671 Last Sleep: absolute base_tsc base_nano Uptime : 0x00007d7fa4244543 Sleep : 0x0000788963bf9866 0x000000017cb6b290 0x0000787772f75145 Wake : 0x00007889c6d0d783 0x000000017aa74e66 0x00007889aaf9abd8 last started kext at 62222130999907: @filesystems.exfat 1.4 (addr 0xffffff7fb1299000, size 53248) loaded kexts:
Joe M writes:
Lloyd, I believe this might be a similar problem I emailed you about on my iMac Pro on 5-11-21. The key is your panic string "IOSCSIPeripheralDeviceType00::setPowerState(0xffffff95a5c646c0 : 0xffffff80185ae1cc, 3 -> 2) timed out after 101093 ms
In my case the message was similar: ""PowerOff timed out in phase 'Notifying priority clients'. Total 30000 ms: vfs_unmountall: 1002 ms". I've had that many times, always during a commanded shutdown or commanded restart. I never use sleep/hibernate, so that's not involved in my case.
Maybe your case is triggered by sleep/wake, but with a similar mishandling of drive response resulting in a kernel panic. If we read the mS correctly yours was 101 sec and mine was 30 sec. If those are real numbers, a drive should respond faster than that but the OS should not panic.
I was told by OWC this is a known bug in MacOS if multiple OWC Thunderbolt drives are connected (with or without SoftRAID). In my case it wasn't new to Big Sur but also happened on Catalina. Apparently MacOS is issuing synchronous (not asynchronous) dismounts. Depending on response time of various RAID arrays, the cumulative response time exceeds some MacOS shutdown timeout and it panics.
For the shutdown case OWC tried to work around it in SoftRAID by issuing unmount commands during MacOS shutdown. That seemed to work for a while then a MacOS update broke it (sorry, don't remember the versions), and to my knowledge the problem still exists. I have eight different OWC arrays and it seems more common on some of them, especially the Thunderbay 4 Minis with four Samsung EVO 850/860 SSDs. Those pass all diagnostics and have never hung in operation, but the problem often happens during shutdown.
I think I've also seen it on the big Thunderbay 4s with mechanical drives. I've had it happen with only a single OWC Thunderbay drive connected, so it's not unique to daisy-chained or multi-array configurations. I don't think it's cable-specific. It happens when using short OWC or Apple Thunderbolt 2 cables (with Apple adapters) or Thunderbolt 3 cables with no adapters. No hubs or other interconnects are involved.
I've spent a huge amount of time troubleshooting it and sending logs to OWC. Finally I gave up and just quit using SoftRAID and I manually dismount and unplug all Thunderbolt drives before restarting or shutting down. Yes it's a hassle.
MPG: on my 2019 Mac Pro system, I have two 4-blade arrays. One is a PCIe SSD (internal), and another is an OWC Thunderblade (external, direct connect not daisy-chained).