[pre-release] macOS Sonoma

[miliuco]

@D3v1L

You're lucky. There is some difference between our systems that causes this different behavior. No matter how hard I tried, I could not remove that alert.

[PMheart]

From @dhinakg’s understanding, if RestrictEvents has been loaded from the very beginning, then the processes causing that alert badge will always be blocked. For @miliuco, it is very possible that you did not use RestrictEvents all the time (e.g., it was not loaded because of the lack of -beta flag), thus the corresponding processes were executed.

 

I put back the badge removal commands by @dhinakg on the master branch, but unfortunately it does not work on Sonoma.

Edited July 9, 2023 by PMheart

[PoMpIs]

2 minutes ago, miliuco said:

@D3v1L

You're lucky. There is some difference between our systems that causes this different behavior. No matter how hard I tried, I could not remove that alert.

 

The same thing happened to me in the raptor lake ..

 

simply starting without RestrictEvent once and without mapping the memory in OC, that appeared and never came out again..

 

On the other hand, in my super cool Ryzen 1600AF this error does not appear 😆.... it is the ultimate machine 🤪

 

 

[PMheart]

While I do not have to, I just want to remind that editing DataHub memory configuration to fix the MP7,1 memory tab issue is wrong.

[PoMpIs]

4 minutes ago, PMheart said:

While I do not have to, I just want to remind that editing DataHub memory configuration to fix the MP7,1 memory tab issue is wrong.

 

I tried once and no error appeared anymore... and so I didn't need RestrictEvents... but since it was in the 13600k... I lost the name of the CPU and I always put RestrictEvents back and remove the memory map in OC.. 

[iGPU]

8 hours ago, miliuco said:

 

The badge can't be removed in Sonoma, it's a very minor detail, just the text "1 alert" next to About This Mac when using MacPro7,1. Everything else seems to work fine.

 

Now I'm on beta 3. When beta 4 is out, I'll try MacPro7,1 and iMacPro1,1 with and without the 3 RestrictEvents patches to check which combination(s) offer(s) OTA update. I'll tell you the results. Thank you.

 

I get the same "1 alert" (see Spoiler) on all betas so far (1-3). I'm using MacPro7,1 and Sonoma beta 3 updated perfectly OTA, using RestrictEvents (v1.1.3) with boot-arg: revpatch=auto,sbvmm,asset

 

Spoiler

 

 

 

 

 

 

Edited July 10, 2023 by iGPU

[miliuco]

11 hours ago, PMheart said:

I just want to remind that editing DataHub memory configuration to fix the MP7,1 memory tab issue is wrong.

But is okey in PlatformInfo >> Generic >> Memory, right? Always thinking in RestrictEvents as the preferred method.

[miliuco]

@PMheart

 

Dear friend, you are right, adding -revbeta in boot args the "1 alert" badge has disappeared.
In addition to this, and I don't know if it can also influence, I had RestrictEvents quite low in the list of kexts and I have dropped it immediately after Lilu and VirtualSMC in case this also influences the early loading of the kext.
Summary: RestrictEvents 1.1.2 (not beta), no custom memory, -revbeta in boot args >> no badge.
Now I have to wait for Sonoma beta 4 to check what you were interested in about patches and OTA updates.
Thank you!!!

 

@iGPU

 

Edited July 10, 2023 by miliuco

[cankiulascmnfye]

40 minutes ago, miliuco said:

But is okey in PlatformInfo >> Generic >> Memory, right? Always thinking in RestrictEvents as the preferred method.

 

RE just suppresses/disables the warning, afaik

 

The Memory Settings are usually only required if something is reported wrong. I recently had that an issue on my Laptop where the RAM speed was reported incorrectly. So I added a chapter for the RAM section to my Repo: https://github.com/5T33Z0/OC-Little-Translated/blob/main/15_RAM/README.md

[miliuco]

@cankiulascmnfye

 

Good report. As always 🙂

[PMheart]

1 hour ago, miliuco said:

@PMheart

 

Dear friend, you are right, adding -revbeta in boot args the "1 alert" badge has disappeared.
In addition to this, and I don't know if it can also influence, I had RestrictEvents quite low in the list of kexts and I have dropped it immediately after Lilu and VirtualSMC in case this also influences the early loading of the kext.
Summary: RestrictEvents 1.1.2 (not beta), no custom memory, -revbeta in boot args >> no badge.
Now I have to wait for Sonoma beta 4 to check what you were interested in about patches and OTA updates.
Thank you!!!

 

@iGPU

 

REV 1.1.2 already has native macOS 14 loading support, and thus the -revbeta flag won’t do anything. Regarding the loading order, that’s interesting. Perhaps @iGPU can try the same thing.

1 hour ago, miliuco said:

But is okey in PlatformInfo >> Generic >> Memory, right? Always thinking in RestrictEvents as the preferred method.

Normally not. Since there is virtually no way to get the real MP7,1 memory configuration/distribution, the only possible workaround is blocking the processes emitting the error.

[cankiulascmnfye]

@miliuco Check this: https://github.com/acidanthera/RestrictEvents#removing-badges-this-works-until-macos-13

[D-an-W]

I don't have any alert badge but when using revpatch=sbvmm I do see the memory is reported differently in System Settings but ok I think in System Information...

 

With revpatch=sbvmm

 

Without revpatch=sbvmm

 

Edited July 10, 2023 by D-an-W

[cankiulascmnfye]

So a bought a used Intel AC-7260 Wifi/BT pcie half-mini card for Sonoma to replace my Broadcom 4360 IN my old Laptop. After changing the card Bluetooth was no lomger available on the system – neither in Windows nor macOS. So I put the old card back in and then Wifi and Bluetoth wouldn't work anymore. Really weird. 

 

I even reflashed the BIOS since this seems to be the only way to reset the BIOS. I think there's something wrong with the socket or the board. I've read reports though from other users with the same issue but I never found a working solution.

[miliuco]

@D-an-W

 

Both examples are using RestrictEvents, right?

I can't see the pics below With revpatch=sbvmm, they are not visible for any reason. Pics below Without revpatch=sbvmm are ok.

I guess that without revpatch=sbvmm RestrictEvents applies all patches as auto (memtab,pci,cpuname, without memtab and pci patches being applied on real Macs) so PCI-e tab disappears and memory tab matches real slots and memory. But with revpatch=sbvmm RestrictEvents applies only this specified patch, not applying memtab and pci so PCI-e tab exists and memory tab has ghost slots not matching your real configuration.

At least, you don't have the 1 alert badge.

 

Edited July 10, 2023 by miliuco

[D-an-W]

21 minutes ago, miliuco said:

@D-an-W

 

Both examples are using RestrictEvents, right?

I can't see the pics below With revpatch=sbvmm, they are not visible for any reason. Pics below Without revpatch=sbvmm are ok.

I guess that without revpatch=sbvmm RestrictEvents applies all patches as auto (memtab,pci,cpuname, without memtab and pci patches being applied on real Macs) so PCI-e tab disappears and memory tab matches real slots and memory. But with revpatch=sbvmm RestrictEvents applies only this specified patch, not applying memtab and pci so PCI-e tab exists and memory tab has ghost slots not matching your real configuration.

At least, you don't have the 1 alert badge.

 

 

Thanks for the info, not sure why the first two pictures don't show up for you sorry.

 

You are correct, both examples have the RestrictEvents.kext loaded yes.

[PMheart]

2 hours ago, miliuco said:

@D-an-W

 

Both examples are using RestrictEvents, right?

I can't see the pics below With revpatch=sbvmm, they are not visible for any reason. Pics below Without revpatch=sbvmm are ok.

I guess that without revpatch=sbvmm RestrictEvents applies all patches as auto (memtab,pci,cpuname, without memtab and pci patches being applied on real Macs) so PCI-e tab disappears and memory tab matches real slots and memory. But with revpatch=sbvmm RestrictEvents applies only this specified patch, not applying memtab and pci so PCI-e tab exists and memory tab has ghost slots not matching your real configuration.

At least, you don't have the 1 alert badge.

 

Correct.

[iGPU]

13 hours ago, PMheart said:

REV 1.1.2 already has native macOS 14 loading support, and thus the -revbeta flag won’t do anything. Regarding the loading order, that’s interesting. Perhaps @iGPU can try the same thing.

Normally not. Since there is virtually no way to get the real MP7,1 memory configuration/distribution, the only possible workaround is blocking the processes emitting the error.

 

I tried moving RestrictEvents from pos 15 to pos 3 (after Lilu and VirtualSMC) as well as using -revbeta.

 

No combination of the above got rid of the "1 alert" badge.

[PMheart]

8 hours ago, iGPU said:

 

I tried moving RestrictEvents from pos 15 to pos 3 (after Lilu and VirtualSMC) as well as using -revbeta.

 

No combination of the above got rid of the "1 alert" badge.

Thanks for letting me know. Now I have a weird experiment: Try disabling RestrictEvents (i.e., set OC Kext Add->Enabled to NO), and then boot once; then reset it to YES.

[miliuco]

@PMheart  @iGPU

 

I said that moving RE up in the kexts list the badge disappeared but I messed up and booted Ventura instead of Sonoma, so don't listen to that message from me 🙁
In Sonoma the 1 alert badge does not disappear in any way.
I have tried as @PMheart says. Deactivate RE >> reboot >> activate RE >> reboot >> the badge is still there. Having RE in the 3rd position (after Lilu and VirtualSMC).

Other than this, everything else seems to work ok.

[iGPU]

3 hours ago, PMheart said:

Thanks for letting me know. Now I have a weird experiment: Try disabling RestrictEvents (i.e., set OC Kext Add->Enabled to NO), and then boot once; then reset it to YES.

 

I followed your request after updating RestrictEvents to latest commit (1.1.3 - 9f45386; as well as updating OC to latest commit, 0.9.4 - de4b1d1).

 

Following the 2nd re-boot after re-enabling of RE, RE now seems not to be working as I get Memory Module Misconfiguration error box (Spoiler), despite RE properly loading (also in Spoilter). In addition, I've tried re-re-booting after moving it from its usual pos 15, to pos 3 (re-boot) and back to pos 15 (after re-boot), without any improvement. And the 1 alert badge is still present.

 

I need to head off to work soon, so later...

 

Spoiler

 

 

Edited July 11, 2023 by iGPU

[miliuco]

@iGPU

The memory misconfiguration warning goes out when booting with RE disabled, if you don’t close it you’ll see it again when rebooting with RE enabled. Maybe is this what has happened?

[iGPU]

3 hours ago, miliuco said:

@iGPU

The memory misconfiguration warning goes out when booting with RE disabled, if you don’t close it you’ll see it again when rebooting with RE enabled. Maybe is this what has happened?

 

No, this is not what happened. I did an initial disable of RE and re-enable using the very first version of RE 1.1.3: 954bd4e. 1 alert still present, so I then re-did the disable and re-enable using the latest commit of RE 9f45386. That's when the Memory error box popped up and has stayed up. (I even did a cold re-boot with same results.)

 

A few days ago, I re-enabled CustomMemory. I'll switch that off again and re-boot. If no help, then I'll revert to RE commit 954bd4e.

 

And to clarify, the RE boot-arg I'm using is "revpatch=auto,sbvmm,asset".

 

***

 

Back after re-running all tests with CustomMemory disabled. I got the same results with 1 alert still present.

 

I have to agree that one must close the Memory error box present from when RE was disabled before it will not re-appear after re-enabling RE. This behavior seems strange and not what I remember when fine tuning CustomMemory with RE for Big Sur and Ventura (accordingly, I did not re-try 1st ver of RE 1.1.3.) Maybe whatever is causing this error box to persist after re-boot is the same reason the 1 alert is present?

 

 

Edited July 11, 2023 by iGPU

[Anto65]

 

 

 

 

Spoiler

 

Edited July 11, 2023 by antuneddu

[Anto65]

Deleted
Wrong Link... Sorry 

Edited July 14, 2023 by antuneddu