MP 1,1-5,1 Mac OS 11.3 has broken support for older Mac Pros

[Dayo]

You probably missed that I did it with the previous build. I did it now too and it still panicked. Again after SMC reset I boot right away.

Sorry, must have missed it.

Presumably the following was tested?

1. /S/L/E/AppleSMC.kext (Alone)
2. /S/L/E/IOAHCIFamily.kext/Contents/PlugIns/IOAHCIBlockStorage.kext (Alone ... parent not updated)
3. 1 & 2 together (parent of 2 not updated)
4. 2 (Alone ... with parent updated)
5. 1 & 2 together (with parent of 2 updated)

 

[startergo]

Sorry, must have missed it.

Presumably the following was tested?

1. /S/L/E/AppleSMC.kext Alone
2. /S/L/E/IOAHCIFamily.kext/Contents/PlugIns/IOAHCIBlockStorage.kext Alone
3. 1 & 2 together
4. 1 alone with Parent
5. 2 Alone with Parent
6. 1 & 2 together with parent

It is not a kext issue. I am pretty sure now. It is a timing issue. And both 11.4b2.and b3 are performing better than the previous builds.

 

[Dayo]

It is a timing issue.

A race condition is a timing issue and the issue has always shown symptoms of this.
The challenge is determining what is responsible ... it could be in one kext or another in theory.

I suppose what you mean is that you think it is in the kernel core itself which is quite likely but probably much more difficult to pin point. Ideal scenario would have been that some change in some kext(s) was responsible and these could then be possibly swapped. That was maybe more of hope.

The occurrences are so random that the various observations are basically now largely meaningless. Would need stepping back to go over the basic situation of why Hacks and the cMP3,1 would work but not the cMP5,1 ... What is different?

I think this is the question that now needs looking at to get to being able to carry out meaningful tests.

 

[startergo]

A race condition is a timing issue and the issue has always shown symptoms of this.
The challenge is determining what is responsible ... it could be in one kext or another in theory.

I suppose what you mean is that you think it is in the kernel core itself which is quite likely but probably much more difficult to pin point. Ideal scenario would have been that some change in some kext(s) was responsible and these could then be possibly swapped. That was maybe more of hope.

The occurrences are so random that the various observations are basically now largely meaningless. Would need stepping back to go over the basic situation of why Hacks and the cMP3,1 would work but not the cMP5,1. What is different?

I think this is the question that now needs looking at to get to being able to carry out meaningful tests.

I think the SMC is different. That is the only unique component. This explains why resetting SMC fixes the boot. Something in the kernel messes up the SMC. This may need kernel debugging.

 

[JohnD]

I think the SMC is different. That is the only unique component. This explains why resetting SMC fixes the boot. Something in the kernel messes up the SMC. This may need kernel debugging.

Would VirtualSMC or FakeSMC help in that case?

 

[Macschrauber]

I have updated 11.3.1 to 11.4beta3 with "just" 1 freeze and could capture it (just the Apple AHCI Blade in):

 

[startergo]

Would VirtualSMC or FakeSMC help in that case?

I don't think there is an easy way to disable SMC. Virtual SMC simulates a missing one, but does not replace existing.

 

[Dayo]

Virtual SMC simulates a missing one, but does not replace existing.

Might still be worth a try. The notes say VirtualSMC replaces any hardware SMC it finds:

GitHub - acidanthera/VirtualSMC: SMC emulator layer

SMC emulator layer. Contribute to acidanthera/VirtualSMC development by creating an account on GitHub.

github.com

Also, @cdf raised the AppleSmcIo flag from OC earlier. Not sure if that has been tested.

 

[startergo]

Might still be worth a try. The notes say VirtualSMC replaces any hardware SMC it finds:

GitHub - acidanthera/VirtualSMC: SMC emulator layer

SMC emulator layer. Contribute to acidanthera/VirtualSMC development by creating an account on GitHub.

github.com

Also, @cdf raised the AppleSmcIo flag from OC earlier. Not sure if that has been tested.

I tested the flag.

 

[startergo]

Just tried VirtualSMC.kext:

sudo dmesg | grep -i "VirtualSMC"
Password:
[    4.360299]: Lilu       api: @ (DBG) got load request from VirtualSMC (124)
[    4.360306]: VirtualSMC      init: @ (DBG) VirtualSMC bootstrap DBG-124-2021-05-10
[    4.360346]: VirtualSMC      prov: @ (DBG) descriptor 0 was mapped
[    4.360414]: VirtualSMC      prov: @ (DBG) descriptor 1 was mapped
[    4.368848]: VirtualSMC     efend: @ authenticated restart support is unavailable (800000000000000E, 8)
[    4.368855]: VirtualSMC      init: @ (DBG) successfully created vsmc provider instance
[    4.369338]: VirtualSMC      vsmc: @ (DBG) found APP0001 compatible service SMC
[    4.369346]: VirtualSMC      vsmc: @ (DBG) found active smc device
[    4.369351]: VirtualSMC      vsmc: @ (DBG) found APP0001 compatible service SMC
[    4.369355]: VirtualSMC      vsmc: @ (DBG) ignoring self by class name
[    4.369359]: VirtualSMC      vsmc: @ (DBG) found 1 smc devices
[    4.369362]: VirtualSMC      vsmc: @ disabling itself due to multiple devices present
[   17.613813]: VirtualSMC      prov: @ (DBG) caught AppleSMC kext
[   31.326295]: Lilu   patcher: @ (DBG) last kext is 0xFFFFFF802189C000 and its name is as.vit9696.VirtualSMC

@vit9696 Is it disabling itself or replacing the original?

 

[startergo]

The notes say VirtualSMC replaces any hardware SMC it finds

(to disable SMC entirely you need to flash a dedicated firmware)

 

[Dayo]

to disable SMC entirely you need to flash a dedicated firmware

The wording is confusing and needs him to clarify. Using "entirely" implies it at least partially disables SMC but then, the word might just have been misused.

Is it disabling itself or replacing the original?

Logging seems to suggest it is disabling itself on finding an existing instance which is inconsistent with the notes.
Patcher line after this might indicate some changes are made though.

Anyway, presumably doesn't make any difference to the situation.

 

[JohnD]

OK, so doing some stupid SMC testing, I created a problem. Red LED clearly visible on the front, white power LED remains OFF, and all fans at 100%. Note to self, this was a bad idea. EDIT: Even when powered off, the red LED is still shining. Can't easily get inside this machine to see the LED's, but will if I have to. Oops?

 

[Macschrauber]

OK, so doing some stupid SMC testing, I created a problem. Red LED clearly visible on the front, white power LED remains OFF, and all fans at 100%. Note to self, this was a bad idea. EDIT: Even when powered off, the red LED is still shining. Can't easily get inside this machine to see the LED's, but will if I have to. Oops?

do an smc reset (plug off the machine for 10 seconds) and a 4 times nvram reset.

 

[JohnD]

do an smc reset (plug off the machine for 10 seconds) and a 4 times nvram reset.

That did the trick! Back to normal. Whew! I'm in way over my head, but hoping to try something 'outside the box' and get an interesting, useful result.

 

[JohnD]

Resetting SMC between shutdowns of 11.4b3 is a major fail - about 50% (every other boot) fails. This is with SATA SSD w/OC + Mojave, and PCIe SSD w/11.3.1 installed, booting 11.4b3 from an HDD in bay 4.

 

[startergo]

do an smc reset (plug off the machine for 10 seconds) and a 4 times nvram reset.

There is no need for NVRAM reset. SMC reset suffice. Either power cord has to be disconnected or power source (if surge protector is used) reset for 15-20 seconds after shutdown.

 

[Dayo]

What would be worth its weight in gold right now would be a cMP5,1 with the original Boot ROM or at least one that has never been updated with Mojave (preferably not even HiSierra). Even more valuable would be an unflashed cMP4,1.

Could then use RP and/or OC to provide APFS and see whether they behave like the cMP3,1 or the up to date cMP5,1 on this issue.

Would point to whether the issue is with the cMP5,1 firmware itself as I believe recent BS release came with some firmware updates which may be having implications (not sure if even a possible factor but would be good to rule out)

 

[JohnD]

What would be worth its weight in gold right now would be a cMP5,1 with the original Boot ROM or at least one that has never been updated with Mojave (preferably not even HiSierra). Even more valuable would be an unflashed cMP4,1.

Could then use RP and/or OC to provide APFS and see whether they behave like the cMP3,1 or the up to date cMP5,1 on this issue.

Would point to whether the issue is with the cMP5,1 firmware itself as I believe recent BS release came with some firmware updates which may be having implications (not sure if even a possible factor but would be good to rule out)

I asked earlier if downgrading firmware was possible or beneficial. Seems I still have a copy of a pre-High Sierra firmware (EDIT: Well, pre-0089 anyway) left behind in my EFI. Would this be of any help?

 

[Dayo]

explains why resetting SMC fixes the boot.

Resetting SMC between shutdowns of 11.4b3 is a major fail

Can roll that in with the other random outcomes. Apparently, the most likely reason the reset may have improved things was that the startup would have been slower which can improve the probability of success.

Still rolling the dice and does not actually fix the issue as such.

Would this be of any help?

Seems the best bet at this point is to sit on 11.2.3 until the Kernel source is released. OC team etc would be able to debug at that point.

The groping in the dark done so far was in the hope of stumbling on a lead but that has not come up with anything and the reasonable options are now basically exhausted. It is a game of patience now.

 

[Macschrauber]

before testing firmware images,

BACKUP YOUR CURRENT FIRMWARE!

it contains machine data like serial numbers of the Board, date of built and other sales / hardware data.

its a hell of a work to rebuild a firmware when losing them.


also dont forget if you downgrade a 4,1 it will need the xeon(s) downgraded again, too.

 

[Macschrauber]

There is no need for NVRAM reset. SMC reset suffice. Either power cord has to be disconnected or power source (if surge protector is used) reset for 15-20 seconds after shutdown.

I stated nvram reset to get away the current instance of OpenCore what causes the smc setting.

plus pulling the drive it contains.

 

[Dayo]

before testing firmware images, BACKUP YOUR CURRENT FIRMWARE!

Not worth the hassle. Only 50/50 chance of useful info to start with at best and then, any useful info then needs multiple blind tests to figure out. Best bet is to wait until the source is available for informed debugging (@Syncretic seems to have some other tools to look at things as they currently are but apart from that angle, just groping in the dark as said).

 

[Macschrauber]

Not worth the hassle. Only 50/50 chance of useful info to start with at best and then, any useful info then needs multiple blind tests to figure out. Best bet is to wait until the source is available for informed debugging (@Syncretic seems to have some other tools to look at things as they currently are but apart from that angle, just groping in the dark as said).

While, if its an smc hassle this kind of Firmware is not upgradeable and never got updated.

on the other hand 4.1 and 5.1 differ in smc firmware and do not differ in symptom.

just thinking loud, as well.

 

[Dayo]

Play with my new game, RaceConditionSim, to get a feel for how random things can be.
Condition is always the same. but the boot successes can vary wildly.

You can get the same number of successes or failures several times in a row but means nothing.
Anyway, my record is 66 "successful boots" before a "kernel panic".