Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Status
The first post of this thread is a WikiPost and can be edited by anyone with the appropiate permissions. Your edits will be public.
Status
Not open for further replies.
Perhaps the following observation is irrelevant, but, just in case, here goes: I may have missed it, but I haven't seen any reports of a supposedly successful series of boots using versions of Big Sur after 11.2.3 on a Mac Pro SERVER 5,1. I ask myself if the fact that you have the Server component installed is working wonders in your case.
Server models are identical to standard models in every way. They shipped with Apple RAID cards and 2x HDD's. My TEST machine is a server model. My machine behaves no differently than any other 5,1 Mac Pro, and my record number of successful, sequential reboots is 22x.
 
  • Like
Reactions: h9826790
More data: reinstalling my Mac's original RAM (the measly 6 GB at 1066 MHz) led to a successful boot of an otherwise practically unbootable machine, and removing all drives except the one with 11.3 gave a success rate of over 50%. I wonder what the common denominator could be. Power draw? SMC?
 
  • Like
Reactions: Bmju
More data: reinstalling my Mac's original RAM (the measly 6 GB at 1066 MHz) led to a successful boot of an otherwise practically unbootable machine, and removing all drives except the one with 11.3 gave a success rate of over 50%. I wonder what the common denominator could be. Power draw? SMC?
Interesting! RAM size affect the POST time, but that shouldn't be related. Because the OS not even started to load at that point.

However, changing RAM also change the NVRAM memory config. When booting macOS, it will read the memory config. This may be related to that racing condition.

Did you try if memory spoofing make any difference to the success rate of booting 11.3?
 
  • Like
Reactions: Bmju
changing RAM also change the NVRAM memory config. When booting macOS, it will read the memory config. This may be related to that racing condition.
Not exactly, except when you change from RDIMM to UDIMM or vice-versa, most times you have to reset the NVRAM to force the re-cache of the SPD and then you have the creation of new MemoryConfig variables. Remember the classic case of changing the Xeon to a Westmere and RAM still works at 1066MHz.

Edited to add vice-versa.
 
Last edited:
Did you try if memory spoofing make any difference to the success rate of booting 11.3?
XNU uses the memory map provided by EFI and not via the SMBIOS table, so unlikely that spoofing either more or less would be recognized by the kernel. Though depending on whether kexts themselves check the SMBIOS, perhaps it would make a difference?

Would be interesting to test I suppose, though for reference my 4GB MacBook7,1 still has the occasional erroring on 11.3+
 
More data: reinstalling my Mac's original RAM (the measly 6 GB at 1066 MHz) led to a successful boot of an otherwise practically unbootable machine, and removing all drives except the one with 11.3 gave a success rate of over 50%. I wonder what the common denominator could be. Power draw? SMC?
RDIMM to UDIMM?
 
Is the erroring a boot hang as well?
So for my iMac11,2, MacBook7,1 and MacPro3,1, they all experience the hang right after PCI Configuration Begins fairly frequently(1 every 10 boots). All machines have SATA SSDs and are basically stock (MacPro3,1 with BCM94360), they'll occasionally also panic on "Waiting for Root Device". For my iMac, I can no longer boot without verbose and other user on an iMac8,1 said they can rarely boot with Ethernet and Wifi kexts injected via OpenCore or on disk.

Machines have too many PCI devices to query and not finishing fast enough to create the boot hangs and/or errors

ASentientBot was also able to replicate this issue on a Penryn hackintosh as well so not specific to Apple firmware configuration
 
Not exactly, except when you change from RDIMM to UDIMM, most times you have to reset the NVRAM to force the re-cache of the SPD and then you have the creation of new MemoryConfig variables. Remember the classic case of changing the Xeon to a Westmere and RAM still works at 1066MHz.
I am not sure if it's always like that. Or just "sometimes" the memory config won't update itself.

When I upgraded from my original 1066MHz Apple UDIMM to my 3rd party 1333MHz RDIMM, I don't need to do the NVRAM reset. The new RAM work at 1333MHz straight away.
 
So for my iMac11,2, MacBook7,1 and MacPro3,1, they all experience the hang right after PCI Configuration Begins fairly frequently(1 every 10 boots). All machines have SATA SSDs and are basically stock (MacPro3,1 with BCM94360), they'll occasionally also panic on "Waiting for Root Device". For my iMac, I can no longer boot without verbose and other user on an iMac8,1 said they can rarely boot with Ethernet and Wifi kexts injected via OpenCore or on disk.

Machines have too many PCI devices to query and not finishing fast enough to create the boot hangs and/or errors

ASentientBot was also able to replicate this issue on a Penryn hackintosh as well so not specific to Apple firmware configuration
This is a very interesting report/data point. So, MP3,1 have a much better reliability for booting >11.3 successfully but it's not perfect. People in the past wrote that MP3,1 always work and this make us go to several goose chases trying to replicate it.
 
  • Like
Reactions: foliovision and cdf
I am not sure if it's always like that. Or just "sometimes" the memory config won't update itself.

When I upgraded from my original 1066MHz Apple UDIMM to my 3rd party 1333MHz RDIMM, I don't need to do the NVRAM reset. The new RAM work at 1333MHz straight away.
Yes and I probably could worded better my previous post, added a vice-versa to it, UDIMM to RDIMM also forces the re-initialisation of the memory controller and creation of new MemoryConfig variables.

My point is that sometimes changing the DIMM to a different one don't re-initialises the memory configuration stored on the NVRAM while for some RAM, just changing the DIMM slot order forces the re-initialisation.
 
  • Like
Reactions: h9826790
More data: reinstalling my Mac's original RAM (the measly 6 GB at 1066 MHz) led to a successful boot of an otherwise practically unbootable machine, and removing all drives except the one with 11.3 gave a success rate of over 50%. I wonder what the common denominator could be. Power draw? SMC?
My success rate is over 50% with 6x8GB (48GB) RDIMM's + 5x drives (HDD/SSD, SATA/PCIe). Micron MT36KSF1G72PZ-1G4M1HE PC3L-10600R for the record, in case that matters someday.
 
Not exactly, except when you change from RDIMM to UDIMM or vice-versa, most times you have to reset the NVRAM to force the re-cache of the SPD and then you have the creation of new MemoryConfig variables. Remember the classic case of changing the Xeon to a Westmere and RAM still works at 1066MHz.

Edited to add vice-versa.
Haha, reminds me of the first Mac Pro I upgraded from 8-core to 12-core and didn't reset NVRAM.
1622131448438.png
 
This is a very interesting report/data point. So, MP3,1 have a much better reliability for booting >11.3 successfully but it's not perfect. People in the past wrote that MP3,1 always work and this make us go to several goose chases trying to replicate it.
Yes, at first, EVERYONE with a 3,1 claimed 100% stability, and not just a few people. As time went on, we got one report, then another, then another that there were indeed issues on the 3,1 as well - just a much better success rate. Never did get to my 3,1 to unplug the stock BlueTooth module and confirm their findings, and no need to now.
 
  • Like
Reactions: tsialex
Server models are identical to standard models in every way.
Hardware, yes, but not the firmware.

The 4th store of the NVRAM volume has more settings on a Mac Pro Server model, personality server, and macOS installer uses it to configure several parameters, from power savings to ethernet fine tuning.

The thing is, any macOS release after Mojave still checks this?
 
I wonder if anyone has tested downloading and updating cMP disk on a supported mac and then putting it back in the cMP to see if the same issue happens.
 
I don't know how significant the following might be. I suspect it won't be very significant. Be that as it may, I've just updated my Parallels Big Sur 11.3.1 virtual machine (on my Mac Pro 5,1) to 11.4 and it was successful (something that did not happen when I tried to update 11.2.3 to 11.3.1). See attached screenshot. I probably failed to notice this before, but, quite correctly, Parallels says my virtual hardware is a Mac Pro 5,1 and it even recognizes its actual serial number! Since my physical Xeon processor is the one responsible for installing and running 11.4, I wonder why it would work reasonably well on a "virtual" Mac Pro 5,1 whereas the very same processor fails to run 11.3.x and 11.4 on my physical 5,1.
Screenshot 2021-05-27 at 20.59.34.png
 
whereas the very same processor fails to run 11.3.x and 11.4 on my physical 5,1.
How a virtual machine and real hardware act are vastly different even with kernel virtual machines (which parallels is not even that).

The devices present are vastly different(root bridges, chipset controllers, etc), the device trees are different (ACPI table formation) and the overall treatment of the device is different (XNU has dedicated code for Parallels and other VMs). In a sense, a VM is nothing like the host besides the few CPU features passed through like extended instruction sets
 
Boah … slightly Off-topic and not helpfull for finding a solution as I am technically not 1% capable as you girls and boys.
BUT: this is so frustrating having invested so much time, money, reading, writing, trying and caring to keep a 10 year old machine up to date and alive [yeah I know High Sierra was the best and stable macOS ever] and now out of the sudden a minor update of a macOS version which was running smoothly so far should be the gravedigger because some technicans at apple don't care about all this. I just don't understand why that should be: is it on purpose, has it to do with the ARM/M1 part of the software or is it just a loose end which unknowingly came to the surface?
Sorry if anyone feels disturbed by this post. I just needed to share this frustration … maybe someone out there can sympathize. Cheers.
 
Boah … slightly Off-topic and not helpfull for finding a solution as I am technically not 1% capable as you girls and boys.
BUT: this is so frustrating having invested so much time, money, reading, writing, trying and caring to keep a 10 year old machine up to date and alive [yeah I know High Sierra was the best and stable macOS ever] and now out of the sudden a minor update of a macOS version which was running smoothly so far should be the gravedigger because some technicans at apple don't care about all this. I just don't understand why that should be: is it on purpose, has it to do with the ARM/M1 part of the software or is it just a loose end which unknowingly came to the surface?
Sorry if anyone feels disturbed by this post. I just needed to share this frustration … maybe someone out there can sympathize. Cheers.
Being real here. Why Apple should care with a design from second half of 2008, declared obsolete by the manufacturer back in December 2018, today?

They don't test obsolete Macs with new macOS releases and actively remove any past quirks needed to run on it, this is not news.

Would be nice if they accept bug reports for obsolete hardware, unfortunately they don't.
 
As it has already been said, only if this new bootstrap code causes problems to newer machines might this issue be resolved.
 
Last edited:
As it has already been said, only if this new bootstrap code causes problems to newer machine might this issue be resolved.
Even more so, we still don't know the exact cause of the problem or what Apple changed to cause it.

If we knew, we could track a still supported Mac that also have it and trigger bug reports or even directly talk to developer contacts at Apple.
 
The good news is that Catalina works quite fine and so does the latest version of ms windows. I will be perfectly happy on Catalina for a couple more years. By then hopefully we’ll all be wanting some kind of silicon arm Mac to run OS X anyway.
 
Maybe the way to go is (if we find the kernel to be the root cause) to compile our own kernel from the source code with few changes.
 
Status
Not open for further replies.
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.