tsialex
Contributor
This is very problematic, the XNU sources have majority of the source code for the macOS kernel but not all.
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
khronokernel
macrumors 6502
The root cause, at least I believe, is bsd_init and other init code. Locks are now statically initialized so theoretically adding more delays during init should help out. As 11.3's kernel is up, can upload an 11.3 InstallAssistant for users to play with a custom kernel in a few hours
Not me. Agree 100% with tsialex. I'll either stick with 11.2.3 or sell my 12 core/64GB cMP and buy an M1 or M2 Mac mini; probably make a small profit.
If you are using a cMP + OpenCore + BigSur (i.e. a Hackintosh) and you don't understand when and when not to update you are probably best advised to sell you kit and get fully supported equipment.
ber404
macrumors member
Maybe my message is not well written because my mother tongue is not english .. I just want a way to hide the update.
Plus you should have a fully operational/tested backup of your current macOS + EFI on a spare drive in case anything goes wrong.
@khronokernel Yeah, I noticed those locks too while I was reviewing the changes from 11.2.3 to 11.3 here and noticed some other major changes in iokit/Kernel/IONVRAM.cpp, specifically around renaming of nvram partitions and deletion of many legacy macboot variables.
Looking at OpenCore's booting process:
Do you think changes to the nvram could be causing the issues we are seeing with the cMP? I am asking this because hackintoshes are generally booting normally as their nvram is created and adapted to recent code changes while the cMP is built-in meaning legacy.
Also, supported Apple hardware is still receiving EFI firmware updates which could include updates to nvram regions, partitions and working variables - @tsialex, can you confirm this? I noticed the variable "osenvironment" was dropped in the nvram yet it is still referenced in the kernel code - is this critical?
I'm thinking out loudly..
Looking at OpenCore's booting process:
Code:
System powers on and searches for boot devices
System locates BOOTx64.efi on your OpenCore USB under EFI/BOOT/
BOOTx64.efi is loaded which then chain-loads OpenCore.efi from EFI/OC/
NVRAM Properties are applied
EFI drivers are loaded from EFI/OC/Drivers
Graphics Output Protocol(GOP) is installed
ACPI Tables are loaded from EFI/OC/ACPI
SMBIOS Data is applied
OpenCore loads and shows you all possible boot options
You now boot your macOS installerDo you think changes to the nvram could be causing the issues we are seeing with the cMP? I am asking this because hackintoshes are generally booting normally as their nvram is created and adapted to recent code changes while the cMP is built-in meaning legacy.
Also, supported Apple hardware is still receiving EFI firmware updates which could include updates to nvram regions, partitions and working variables - @tsialex, can you confirm this? I noticed the variable "osenvironment" was dropped in the nvram yet it is still referenced in the kernel code - is this critical?
I'm thinking out loudly..
thatsmeonlyme
macrumors regular
Hi everybody,
I got 11.4 running on my 5.1 using OCLP via regular OTA updates. The installation was a patience trip. I did 3 cold starts to get the after boot setup working near the end.
1. statusbar loading very slow until stopping at about 10%
2. statusbar now loading quickly through the first 10% then progress to 30% (first cold start)
3. now quickly to the first 30% then fast moving to 60-70%
4. Loading to 60-70% but then no progress.
!! I never saw the text remaining x minutes !!
Did this 4 or 5 times with identic results. Removing USB didn´t any change.
Then I shut down and plugged out the power chord waiting at least 15 seconds before plugging in again.
Now starting the same procedere with primarly same result but the first time my gpu reacted as known before. (adjusting the monitor) After the following first cold reboot I got again the gpu but the time this appeared had changed. I did the next cold reboot. Gpu now started as before but now there was the text sequence ...remaining 10 minutes.
From there the machine booted without any problems.
The machine is working better than with Mojave. Not a single problem since installation. At weekend I´ll try reboots.
Now my question:
They did very much changing using RAM with the M1 generation of BigSur. Could our problem be related to the use of RAM and VRAM? Could it be graphics related? The timing, when the hardware is initiated?
I ask because for me it was conspicious to see this sequence of three, everytimes
I got 11.4 running on my 5.1 using OCLP via regular OTA updates. The installation was a patience trip. I did 3 cold starts to get the after boot setup working near the end.
1. statusbar loading very slow until stopping at about 10%
2. statusbar now loading quickly through the first 10% then progress to 30% (first cold start)
3. now quickly to the first 30% then fast moving to 60-70%
4. Loading to 60-70% but then no progress.
!! I never saw the text remaining x minutes !!
Did this 4 or 5 times with identic results. Removing USB didn´t any change.
Then I shut down and plugged out the power chord waiting at least 15 seconds before plugging in again.
Now starting the same procedere with primarly same result but the first time my gpu reacted as known before. (adjusting the monitor) After the following first cold reboot I got again the gpu but the time this appeared had changed. I did the next cold reboot. Gpu now started as before but now there was the text sequence ...remaining 10 minutes.
From there the machine booted without any problems.
The machine is working better than with Mojave. Not a single problem since installation. At weekend I´ll try reboots.
Now my question:
They did very much changing using RAM with the M1 generation of BigSur. Could our problem be related to the use of RAM and VRAM? Could it be graphics related? The timing, when the hardware is initiated?
I ask because for me it was conspicious to see this sequence of three, everytimes
Attachments
alphascorp
macrumors 6502
Hi all
I just remembered 2 things about my old cMP2,1 not supported by El Capitan, in order to be able to start it was necessary to replace the boot.efi file in 2 locations (/S/L/CoreServices/ and /usr/standalone/i386/).
But the most interesting was after the discovery of "Spectre" and "Meltdown" Apple had modified the Kernel after January 01, 2018 and after the installation of SU 2018-001 (and all those that followed) cMP2,1 entered a bootloop.
But since the Xeon X51xx CPUs of cMP1,1 and X53xx of cMP2,1 were not affected by "Specter" and "Metldown", I had created a tool which replaced the new Kernel with that of the last SU 2017. This cMP2,1 has worked like this for over a year without stability issue (I sold it 2 years ago but it still works like this almost every day).
About our issues of starting our cMP5.1 since 11.3 I therefore thought of the somewhat crazy idea of replacing the Kernel by the one from 11.2.3 (I imagine that some have probably had the same idea for a long time and have already tried that ...)
In order to be able to replace the Kernel I cannot mount in read/write the external disk containing 11.3.1 (partition disk6s5, shown in following screenshot), (I specify that I am running 11.2.3). I have tried a lot of commands through Terminal but haven't succeeded yet, would someone be kind enough to help me with this command?
I just remembered 2 things about my old cMP2,1 not supported by El Capitan, in order to be able to start it was necessary to replace the boot.efi file in 2 locations (/S/L/CoreServices/ and /usr/standalone/i386/).
But the most interesting was after the discovery of "Spectre" and "Meltdown" Apple had modified the Kernel after January 01, 2018 and after the installation of SU 2018-001 (and all those that followed) cMP2,1 entered a bootloop.
But since the Xeon X51xx CPUs of cMP1,1 and X53xx of cMP2,1 were not affected by "Specter" and "Metldown", I had created a tool which replaced the new Kernel with that of the last SU 2017. This cMP2,1 has worked like this for over a year without stability issue (I sold it 2 years ago but it still works like this almost every day).
About our issues of starting our cMP5.1 since 11.3 I therefore thought of the somewhat crazy idea of replacing the Kernel by the one from 11.2.3 (I imagine that some have probably had the same idea for a long time and have already tried that ...)
In order to be able to replace the Kernel I cannot mount in read/write the external disk containing 11.3.1 (partition disk6s5, shown in following screenshot), (I specify that I am running 11.2.3). I have tried a lot of commands through Terminal but haven't succeeded yet, would someone be kind enough to help me with this command?
Update on my 10.4 update. The first and second hang almost immediately after a whole day being turned off. The third restart worked fine, and kept running all day. Then, the machine, when left off for a while, would freeze. I have now wiped the HD and reverted back to 11.2.3. No more freezing.
So I did nothing different and my machine is just like everyone else. Sorry.
So I did nothing different and my machine is just like everyone else. Sorry.
paalb
macrumors 6502
A workaround way of doing that might be to make the other users standard users and not share the admin password.
Maybe switching OFF VMM flag in OpenCore?
See here: https://forums.macrumors.com/threads/opencore-on-the-mac-pro.2207814/?post=27914713#post-27914713
-> Familiarize yourself with the VMM flag
tsialex
Contributor
This is a lot more complex than you are thinking.
Apple can't just remove something/modify radically the EFI/NVRAM volume/BootLoader/BootBlock or binary compatibility stops. BigSur firmwares trigger down to Macs running Mojave and Catalina whenever Security Updates are released, so they can't radically change the EFI firmware or past macOS releases and other OS would have problems.
Apple can stop to use a NVRAM variable with an updated macOS release, but they can't remove it's functionality from the EFI.
Btw, binary compatibility is a complex problem and even subtle differences can bring trouble. One example with MacPro5,1 is bluetoothActiveControllerInfo variable that work differently between Mojave and Big Sur and the variable is modified when you boot one or the other, leading to variable multiplication inside the main NVRAM VSS store.
eVasilis
macrumors 6502
Oh, I know it’s a complex issue for sure and if I understood you correctly, changes to the NVRAM whether deprecated or new macboot variables can cause issues on unsupported/legacy hardware that cannot support such changes. Such changes can also include variables that have been deprecated in favor of new ones with expanded functionality which the cMP’s legacy EFI may not support.
It’s really very strange how some unsupported Apple hardware and hackintoshes are able to boot 11.3+
Ha anyone tried fully spoofing 7,1 with the cMP including NVRAM and VirtualSMC? If not, I have a Matt card installed and can test this but will need to buy a programmer first.
Appreciate your input.
khronokernel
macrumors 6502
Actually no, hackintoshes are also affected as I previously mentioned with ASentientBot's findings with their PC. Penryn hackintosh but still clears up the idea that it would affect any machine with many PCIe devices and a slower CPU.
Therefore can conclude it's not reliant on Apple firmware, however possible that MacPro4,1/5,1's firmware structure may exaggerate the issue compared to a MacPro3,1 and other Macs
tsialex
Contributor
Another even better example of binary compatibility problems is MP51.0087.B00 where the removal of the Intel microcodes from the EFI firmware to apply it at kernel time via a macOS service (ucupdate) led to Windows
Several unsupported Macs have the same problem as MacPro5,1, not just as much.
Seems that was a MacPro5,1 only problem because initially people using it tested more/with better tests and more people where looking, while the reports with other unsupported Macs were not as good or was even reproducible. Some blatant lies too.
The problem is PCIe related, not NVRAM or SMC related, maybe some quirk needed for something was deprecated and removed with 11.3 beta 3 leading to the race we now suffer.
I still have a hunch that this is someway related or exacerbated by the PCIe switch.
Edit: Windows UEFI, not EFI.
Last edited:
JohnD
macrumors regular
Were you the one who was going to sacrifice a machine by cutting backplane traces to the PCIe switch? I haven't take a look at the backplane to visually ID the switch, but if it's not a BGA chip, I'm not beyond de-soldering it, for science of course. Not crazy about the idea, but not dismissing it either. 🙂 I don't have a rework station, but can handle SMD. Thoughts?
tsialex
Contributor
I didn't want to sacrifice anything, backplanes here are insanely costly, just disable the main power feed to the PCIe switch. When I started to investigate the PCIe switch data sheet to find a feasible way to it I've found that it's more involved than I initially thought and it's needed to remove other passible components to really disable it.
I still think that is a interesting test and I'll probably do it when I have more time available and I'm slowly (COVID19 completely disrupted the supply chain and I can't even get decent flux or solder paste right now, btw things are getting worse again with the supply chain) getting everything needed.
khronokernel
macrumors 6502
For those who want to disable non-essential PCIe devices, you can apply botched properties to them so macOS won't recognize them. Similar to how we do it for iMac12,x with upgraded Metal GPUs, we hide the bad devices with garbage properties and so macOS threats them as generic devices and no kexts attach
An example of this would be to run gfxutil and grab PCI paths for devices you think are non-essential:
Code:
00:00.0 8086:4003 /PCI0@0/pci8086,4003@0 = PciRoot(0x0)/Pci(0x0,0x0)
00:01.0 8086:4021 /PCI0@0/NRP1@1 = PciRoot(0x0)/Pci(0x1,0x0)
00:05.0 8086:4025 /PCI0@0/NRP5@5 = PciRoot(0x0)/Pci(0x5,0x0)
00:09.0 8086:4029 /PCI0@0/P0P9@9 = PciRoot(0x0)/Pci(0x9,0x0)
00:0f.0 8086:402f /PCI0@0/pci8086,402f@F = PciRoot(0x0)/Pci(0xF,0x0)
00:10.0 8086:4030 /PCI0@0/PBIF@10 = PciRoot(0x0)/Pci(0x10,0x0)
00:10.1 8086:4030 /PCI0@0/AMAP@10,1 = PciRoot(0x0)/Pci(0x10,0x1)
00:10.2 8086:4030 /PCI0@0/pci8086,4030@10,2 = PciRoot(0x0)/Pci(0x10,0x2)
00:10.3 8086:4030 /PCI0@0/pci8086,4030@10,3 = PciRoot(0x0)/Pci(0x10,0x3)
00:10.4 8086:4030 /PCI0@0/pci8086,4030@10,4 = PciRoot(0x0)/Pci(0x10,0x4)
00:11.0 8086:4031 /PCI0@0/pci8086,4031@11 = PciRoot(0x0)/Pci(0x11,0x0)
02:00.0 1002:67df /PCI0@0/NRP5@5/GFX0@0 = PciRoot(0x0)/Pci(0x5,0x0)/Pci(0x0,0x0)
03:00.0 8086:3500 /PCI0@0/P0P9@9/P9P2@0 = PciRoot(0x0)/Pci(0x9,0x0)/Pci(0x0,0x0)
03:00.3 8086:350c /PCI0@0/P0P9@9/pci-bridge@0,3 = PciRoot(0x0)/Pci(0x9,0x0)/Pci(0x0,0x3)
00:15.0 8086:4035 /PCI0@0/pci8086,4035@15 = PciRoot(0x0)/Pci(0x15,0x0)
00:15.1 8086:4035 /PCI0@0/pci8086,4035@15,1 = PciRoot(0x0)/Pci(0x15,0x1)
00:16.0 8086:4036 /PCI0@0/pci8086,4036@16 = PciRoot(0x0)/Pci(0x16,0x0)
02:00.1 1002:aaf0 /PCI0@0/NRP5@5/HDAU@0,1 = PciRoot(0x0)/Pci(0x5,0x0)/Pci(0x0,0x1)
00:16.1 8086:4036 /PCI0@0/pci8086,4036@16,1 = PciRoot(0x0)/Pci(0x16,0x1)
00:1b.0 8086:269a /PCI0@0/HDEF@1B = PciRoot(0x0)/Pci(0x1B,0x0)
00:1c.0 8086:2690 /PCI0@0/pci-bridge@1C = PciRoot(0x0)/Pci(0x1C,0x0)
00:1c.1 8086:2692 /PCI0@0/pci-bridge@1C,1 = PciRoot(0x0)/Pci(0x1C,0x1)
00:1c.2 8086:2694 /PCI0@0/RP03@1C,2 = PciRoot(0x0)/Pci(0x1C,0x2)
04:00.0 8086:3510 /PCI0@0/P0P9@9/P9P2@0/P2P3@0 = PciRoot(0x0)/Pci(0x9,0x0)/Pci(0x0,0x0)/Pci(0x0,0x0)
04:01.0 8086:3514 /PCI0@0/P0P9@9/P9P2@0/P2P4@1 = PciRoot(0x0)/Pci(0x9,0x0)/Pci(0x0,0x0)/Pci(0x1,0x0)
00:1c.3 8086:2696 /PCI0@0/RP04@1C,3 = PciRoot(0x0)/Pci(0x1C,0x3)
04:02.0 8086:3518 /PCI0@0/P0P9@9/P9P2@0/P2P5@2 = PciRoot(0x0)/Pci(0x9,0x0)/Pci(0x0,0x0)/Pci(0x2,0x0)
00:1d.0 8086:2688 /PCI0@0/UHC1@1D = PciRoot(0x0)/Pci(0x1D,0x0)
00:1d.1 8086:2689 /PCI0@0/UHC2@1D,1 = PciRoot(0x0)/Pci(0x1D,0x1)
00:1d.2 8086:268a /PCI0@0/UHC3@1D,2 = PciRoot(0x0)/Pci(0x1D,0x2)
00:1d.3 8086:268b /PCI0@0/UHC4@1D,3 = PciRoot(0x0)/Pci(0x1D,0x3)
00:1d.7 8086:268c /PCI0@0/EHCI@1D,7 = PciRoot(0x0)/Pci(0x1D,0x7)
0b:00.0 104c:823e /PCI0@0/RP03@1C,2/FWBR@0 = PciRoot(0x0)/Pci(0x1C,0x2)/Pci(0x0,0x0)
07:00.0 8086:1096 /PCI0@0/P0P9@9/P9P2@0/P2P5@2/LAN0@0 = PciRoot(0x0)/Pci(0x9,0x0)/Pci(0x0,0x0)/Pci(0x2,0x0)/Pci(0x0,0x0)
05:00.0 14e4:43a0 /PCI0@0/P0P9@9/P9P2@0/P2P3@0/ARPT@0 = PciRoot(0x0)/Pci(0x9,0x0)/Pci(0x0,0x0)/Pci(0x0,0x0)/Pci(0x0,0x0)
07:00.1 8086:1096 /PCI0@0/P0P9@9/P9P2@0/P2P5@2/LAN1@0,1 = PciRoot(0x0)/Pci(0x9,0x0)/Pci(0x0,0x0)/Pci(0x2,0x0)/Pci(0x0,0x1)
0c:00.0 104c:823f /PCI0@0/RP03@1C,2/FWBR@0/FRWR@0 = PciRoot(0x0)/Pci(0x1C,0x2)/Pci(0x0,0x0)/Pci(0x0,0x0)
00:1e.0 8086:244e /PCI0@0/PCIB@1E = PciRoot(0x0)/Pci(0x1E,0x0)
00:1f.0 8086:2670 /PCI0@0/LPCB@1F = PciRoot(0x0)/Pci(0x1F,0x0)
00:1f.1 8086:269e /PCI0@0/PATA@1F,1 = PciRoot(0x0)/Pci(0x1F,0x1)
00:1f.2 8086:2681 /PCI0@0/SATA@1F,2 = PciRoot(0x0)/Pci(0x1F,0x2)
00:1f.3 8086:269b /PCI0@0/SBUS@1F,3 = PciRoot(0x0)/Pci(0x1F,0x3)From that, lets say I want to disable one of the USB 1.1 controllers(UHC4 for example) from having drivers attach. I would take this path, and add these properties to the config.plist with a simple plist editor like Xcode or ProperTree:
Code:
DeviceProperties
|---PciRoot(0x0)/Pci(0x1D,0x3)
|------| vendor-id | data | ffffffff
|------| device-id | data | ffffffff
|------| IOName | string | Garbage
|------| name | string | Garbage
|------| class-code | data | ffffffffNote: You may need to populate
DeviceProperties -> Delete and enable UEFI -> ProtocolOverrides -> DeviceProperties as well for scenarios where Apple has defined these values already. Mainly applicable for GPUs, generally other devices won't have device properties defined in the firmware. See OpenCore docs for more informationThis might work. Just have to find how to change the ignore to BS instead of Catalina.
How to Hide MacOS Catalina from Software Update on Mac
Want to stop MacOS Catalina showing up in Software Updates on a Mac? Don’t plan on updating to MacOS Catalina anytime soon? Still up in the air about whether or not to update to MacOS Catalin…
osxdaily.com
JohnD
macrumors regular
The --ignore switch is no longer an option if you're already running Big Sur. Open terminal and type "man softwareupdate" to see your options.This might work. Just have to find how to change the ignore to BS instead of Catalina.
How to Hide MacOS Catalina from Software Update on Mac
Want to stop MacOS Catalina showing up in Software Updates on a Mac? Don’t plan on updating to MacOS Catalina anytime soon? Still up in the air about whether or not to update to MacOS Catalin…
Yes, I agree, I have the OWC Accelerator S, add-in PCI 2.5" drive card SATA 6G and I also have an NVME drive using a PCI card, Lycom DS-120. I have had the same issues on both PCI card on macOS Big Sur v11.4, the latest. I tried all the solutions I read on this thread. FYI, I have 2 macPro 5, one with dual CPU slot and the other is a single CPU. One running Big Sur 11.4 and the other Big Sur 11.5 Beta. Graphics installed is MSI Radeon Armor with 8gB, 2 DP, 2 HDMI ports, and a Gigabyte Titan Thunderbolt 3 PCI card. Both have the same issues on this thread: Mac Pro booting is broken on NVME PCI card & the OWC SSD 6G drive on the DP ports on a Apple 30" Cinema Display. After a day with my head spinning, I tried using the HDMI port on a Dell monitor.... alas....the computer boots on the second try. The first time it boots was a little longer as if it was trying to enumerate the hardware devices connected on the system. I turn off the system after 2mins. and tried booting the second time. The system boots with no problem. I tested and restart the system about at least 10x. IT's a puzzling and a weird problem. I don't know if this is an issue on all cMP but at least it works on my system. I heard installing a Sonnet PCI USB 3.0 card creates problem. That's my next tests I have to perform. Good luck to everyone. Keep hacking!
Update:
After an hour or so on the PC; restarts...still broken! ARgggh!
Last edited:
I don't have any expertise to assist you all with your work but I just wanted to take a moment to thank you all for troubleshooting this for the rest of us.
I've had my MacPro since 2013 and it's been an awesome journey that started with firmware flashing (4,1 to 5,1), CPU upgrades (x2) and culminated in installing Opencore to get to Catalina/Big Sur.
Issues like this make me think an M series Mac is in the near future for me but I'd like to keep the old girl going for a bit longer. It's definitely the best Mac I've owned and I've had a few now. I'm gonna hang out for a few weeks to see if it persists and if so I'll likely go back down to Catalina to ensure I can get security updates for a while longer.
That being said, I've been subscribed to this thread for a few weeks now and excitedly check in nearly every day to see how you're all progressing. As I said in the opening, I have no IT expertise to assist you but just wanted to express that the work you are all doing is amazing!
I've had my MacPro since 2013 and it's been an awesome journey that started with firmware flashing (4,1 to 5,1), CPU upgrades (x2) and culminated in installing Opencore to get to Catalina/Big Sur.
Issues like this make me think an M series Mac is in the near future for me but I'd like to keep the old girl going for a bit longer. It's definitely the best Mac I've owned and I've had a few now. I'm gonna hang out for a few weeks to see if it persists and if so I'll likely go back down to Catalina to ensure I can get security updates for a while longer.
That being said, I've been subscribed to this thread for a few weeks now and excitedly check in nearly every day to see how you're all progressing. As I said in the opening, I have no IT expertise to assist you but just wanted to express that the work you are all doing is amazing!
- Status