@w1z, that's a carbon copy of what I usually see when the booting hangs.
Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
MP 1,1-5,1 Mac OS 11.3 has broken support for older Mac Pros
- Thread starter VitaminK
- WikiPost WikiPost
- Start date
- Sort by reaction score
- Status
- Status
The fast spinning GPU fan event you mention, does it happen to you only at startup and/or when waking up the system from sleep mode? To me it happens in the latter scenario and only when I put the computer to sleep myself manually. Otherwise, when it goes to sleep automatically, it never does that GPU fast fan spin event. As result, I never put it to sleep myself and just let it do it automatically to avoid the (scary) fast fan spin event.
I am only asking as I keep comparing your system to mine in the event that having the same wifi/bt and other potential similarities helps in finding a pattern. I will test upgrading to 11.3 on Saturday, can't get to it before then as this is my work computer.
I haven't seen this, but I do get "waiting on <dict ID="0"><key>IOProviderClass</key>..." or "still waiting for root device".
Last edited:
None during the 10 reboots I tested after 11.3 install. I did get a racing fan yesterday, while booting from Mojave to Big Sur. The racing fans happen very rarely in my system, at the beginning and they last 1-2 seconds. My system is always in Sleep, the racing condition occurs sometimes, only when I restart my Mac, never from sleep.
I am not invested in this (not running Catalina, Big Sur, or using OpenCore), but I do find it interesting that your screenshot shows no more messages past the 2 Intel Ethernet controllers.
On some Linux versions I could not use the Mac Pro Ethernet controllers unless they were physically connected on startup. Otherwise the hardware was not detected.
Looking at the System Diagram posted awhile back, Airport, Ethernet, and Firewire controllers are the only PCIe devices connected to the South Bridge.
On some Linux versions I could not use the Mac Pro Ethernet controllers unless they were physically connected on startup. Otherwise the hardware was not detected.
Looking at the System Diagram posted awhile back, Airport, Ethernet, and Firewire controllers are the only PCIe devices connected to the South Bridge.
I think you are describing something different here. Sometimes on wake, the fans will go full blast for a few seconds, then return to normal. This is not the fan bug I'm talking about. What I'm talking about is the fan bug where the PS and PCI fans spin higher than normal on cold boot (not reboot) and easily rev up when doing certain graphics tasks, even scrolling webpages. I suppose you don't have this then. Interesting.
I seem to always get:
Code:
Previous shutdown cause: 3The hang usually happens at this message:
Code:
rooting via boot-uuid from /chosen: XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX
Waiting on <dict ID="0"><key>I0ProviderClass</key><string ID="1">IOResources</string><key>IOResourceMatch</key><string ID="2">boot-uuid-media</string›</dict>
1080211 Controller::create I0Reporters 0xXXXXXXXXXXXXXXXX
Intel82574L::start - Built Apr 15 2021 01:18:37 -- running on device at b14 d0 f0
Intel82574L::start - Built Apr 15 2021 01:18:37 -- running on device at B15 30 f0After 1 minute, the letters on screen distort and the prohibitory symbol appears. But I've also notice that another message appears at this moment. It's distorted, but it says "still waiting for root device." The OpenCore manual mentions a similar issue, describing the ExitBootServicesDelay quirk. Unfortunately, the quirk has no effect in this case.
All of these are from the "IOFindBSDRoot" function posted earlier.
It is basically timing out due to some IO issue after 10 attempts at mounting something has failed. Needs checking what that "something " exactly is but initially looks like some disk/drive.
"Still waiting for root device" seems to be the key and seems to be targeted at Intel but all the stuff there seem to be filesystem related.
Will track stuff spinning off (there is something about needing "NetworkKexts" etc)
Might be worth flagging to the OpenCore guys as well.
EDIT: Enlightening to see that Apple appears to consider non-ARM to be not "XNU_TARGET_OS_OSX" and the if "XNU_TARGET_OS_OSX", it must also be ARM (at least in this bit).
Still in
.../iokit/bsddev/IOKitBSDInit.cpp, all in function kern_return_t IOFindBSDRoot( char * rootName, unsigned int rootNameSize, dev_t * root, u_int32_t * oflags ):
Code:
do {
if ((regEntry = IORegistryEntry::fromPath( "/chosen", gIODTPlane ))) {
di_root_ramfile(regEntry);
data = OSDynamicCast(OSData, regEntry->getProperty( "root-matching" ));
if (data) {
matching = OSDynamicCast(OSDictionary, OSUnserializeXML((char *)data->getBytesNoCopy()));
if (matching) {
continue;
}
}
data = (OSData *) regEntry->getProperty( "boot-uuid" );
if (data) {
uuidStr = (const char*)data->getBytesNoCopy();
OSString *uuidString = OSString::withCString( uuidStr );
// match the boot-args boot-uuid processing below
if (uuidString) {
IOLog("rooting via boot-uuid from /chosen: %s\n", uuidStr);
IOService::publishResource( "boot-uuid", uuidString );
uuidString->release();
matching = IOUUIDMatching();
mediaProperty = "boot-uuid-media";
regEntry->release();
continue;
} else {
uuidStr = NULL;
}
}
regEntry->release();
}
} while (false);rooting via boot-uuid from /chosen: xxx, that's the path your boot-loader is taking.A bit later, with no progress, we have:
Code:
if (true && matching) {
OSSerialize * s = OSSerialize::withCapacity( 5 );
if (matching->serialize( s )) {
IOLog( "Waiting on %s\n", s->text());
s->release();
}
}Waiting on <dict ID="0"><key>IOProviderClass</key><string ID="1">IOResources</string><key>IOResourceMatch</key><string ID="2">boot-uuid-media</string›</dict> message.And a bit further down, we have this:
Code:
do {
t.tv_sec = ROOTDEVICETIMEOUT;
t.tv_nsec = 0;
matching->retain();
service = IOService::waitForService( matching, &t );
if ((!service) || (mountAttempts == 10)) {
#if !XNU_TARGET_OS_OSX || !defined(__arm64__)
PE_display_icon( 0, "noroot");
IOLog( "Still waiting for root device\n" );
#endif
if (!debugInfoPrintedOnce) {
debugInfoPrintedOnce = true;
if (gIOKitDebug & kIOLogDTree) {
IOLog("\nDT plane:\n");
IOPrintPlane( gIODTPlane );
}
if (gIOKitDebug & kIOLogServiceTree) {
IOLog("\nService plane:\n");
IOPrintPlane( gIOServicePlane );
}
if (gIOKitDebug & kIOLogMemory) {
IOPrintMemory();
}
}
#if XNU_TARGET_OS_OSX && defined(__arm64__)
// The disk isn't found - have the user pick from recoveryOS+.
(void)IOSetRecoveryBoot(BSD_BOOTFAIL_MEDIA_MISSING, NULL, true);
#endif
}
} while (!service);Still waiting for root device message, as well as displaying the "noroot" icon (which I'm pretty sure is the "prohibited" symbol). Assuming a panic does not occur elsewhere, this will loop until a service matching the value of boot-uuid (whatever that is on your system) is found. ROOTDEVICETIMEOUT is defined as 60 (seconds) in the production kernel, 120 (seconds) in the debug kernel. mountAttempts is a static variable that gets incremented early in IOFindBSDRoot():
Code:
if (mountAttempts++) {
IOLog("mount(%d) failed\n", mountAttempts);
IOSleep( 5 * 1000 );
}mountAttempts only gets incremented once every time IOFindBSDRoot() is called.What's interesting here is that the loop should only exit if the matching service is found. If it's never found, it should iterate forever -
mountAttempts doesn't get incremented within that loop, and absent a panic elsewhere, you should see Still waiting for root device messages repeated every 60 seconds. The fact that you only see it once suggests to me that the problem is elsewhere.Waiting on <dict ID="0"><key>IOProviderClass</key><string ID="1">IOResources</string><key>IOResourceMatch</key><string ID="2">boot-uuid-media</string›</dict> and Still waiting for root device usually mean that the root filesystem cannot be recognized, for any number of reasons.You can override the IORegistry boot-uuid with two boot-args:
rd=uuid boot-uuid=224959f4-8eee-4190-a8c5-d8a992daa778 (of course, you'd substitute your own boot-device's UUID for the one I used here). That might be worth trying, just to see if the native boot-uuid is somehow getting garbled. (That said, I suspect the problem is elsewhere, and the boot-uuid handling is correct.)
An angle we haven't looked at.
I believe most 3,1 units might not have WIFI cards in place. Also note that the stock BT card in 3,1 causes BS to fail.
Could be similar issue affecting WIFI?
Wonder whether @nekton1 can confirm whether his 3,1 has a WIFI card.
Does 3,1 use the same ones? Needs checking.
Also, have those with more reliable experiences done anything to their WIFI setups .... upgraded or stock?
The
IO80211Controller::createIOReporters message comes from /System/Library/Extensions/IO80211Family.kext or /System/Library/Extensions/IO80211FamilyV2.kext (both contain that log message).The
Intel82574L message comes from /System/Library/Extensions/IONetworkingFamily.kext/Contents/PlugIns/Intel82574L.kext
on the hackintosh side 11.3 is a different story
www.tonymacx86.com
macOS 11.3 Update
Today Apple released macOS 11.3 Update, a major software update to macOS Big Sur. Update any supported system using the built-in Software Update functionality through the macOS System Preferences pane. What we know about the 11.3 Update so far... macOS Build 20E232 Updated audio, graphics...
Agree
C++:
// If the IOService we matched to is a subclass of IONetworkInterface,
// then make sure it has been registered with BSD and has a BSD name
// assigned.
if (service
&& service->metaCast( "IONetworkInterface" )
&& !IORegisterNetworkInterface( service )) {
// SUSPECT THE "IONetworkInterface" STUFF HERE FAILS AND "service" IS SET TO NULL
service = NULL;
}
if (service) {
// SOME STUFF SKIPPED IF "service" IS SET TO NULL ABOVE
} else {
// DO THINGS END UP HERE?
IOLog( "Wait for root failed\n" );
strlcpy( rootName, "en0", rootNameSize );
flags |= 1;
}Actually, I mentioned previously that the hang persists even with no WiFi card.
- Status