Ausdauersportier - I was just asking because of this comment in post #1 - "This is an unsigned kext, so you'll almost certainly need SIP disabled to use it (I have not even tried looking at this)"
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 Latebloom - An experimental workaround for the 11.3+ race condition
- Thread starter Syncretic
- Start date
- Sort by reaction score
- Status
What is your point? The phrase from post #1 is self evident. "unsigned kext" says it all.
That's an intriguing notion, but I have a few reservations. I'd like to avoid an OpenCore dependency (even though most use-cases will involve OpenCore), which makes accessing other NVRAM volumes tricky for the user. I'd like to avoid cluttering up my code with C++, which is almost a requirement for using IOKit's NVRAM API. And by creating a dependency on the NVRAM kext, it's possible that latebloom would not get initialized until after the PCI bus had already been probed. MacOS treats boot-args specially, and has it all neatly packaged by the time kext initialization occurs, so it's simple to use. I agree that long-term, I'd want to minimize the use of boot-args; one possibility would be to combine the latebloom and lb_range variables into one, using a separator (e.g.
latebloom=100:20), and just doing away with lb_debug. For now, while we're all still experimenting, I don't see any harm in having multiple boot-args.The operative phrase there is "I have not even tried looking at this" - I know that direct kernel linking usually requires SIP to be off, I wasn't sure if OpenCore's kext injection changed that, and I didn't spend any time trying to figure it out. (I spend a lot of time developing kexts, so for simplicity, I normally run with SIP & AMFI disabled anyway. It saves a lot of time.) If one of our OpenCore experts would care to confirm that SIP does not need to be disabled when injecting latebloom via OpenCore, I'll happily update the first post.
EDIT: looks like I was typing while the answer was being posted:
(First post updated.)
Last edited:
Not yet.
I aware this kext / work around. And I planed to add this kext to my package later. But I can only do this after we believe that drive corruption most likely won't happen (with macOS 11.3 and newer after using this kext). Otherwise, many users may just accidentally fall into the trap.
If possible, please try
latebloom=100 and lb_range=1, this is what I planed to include in my package.This most likely will add 5-10s delay during boot. I think this is an acceptable number for most people.
latebloom=100 seems works well on cdf and startergo's cMP. According to post #1, using lb_range may also help to avoid deadlock. Therefore, let's include lb_range=1, just in case we can benefit from this function (even with very small number).
Here's my journey. My specs are in my signature and I used @h9826790's package of course.
I started with the default latebloom value and the install started perfectly fine. However, I was having issues upon boot with hanging. I changed latebloom=100. No dice. I changed it to 150, 175, 200, and finally 250. 250 worked for me. I just had two instances of boot hanging. So even now I will still have to play along with it. Moral of the story is that you have to play around with it. But I am pleased to say that it works. I'll be testing this daily.
Edit: Ended up setting a lb_range=20.
@Syncretic thank you and everyone for their hard work.
Last edited:
I'd go for a value much more conservative, I've tested 4 different MacPro5,1 and just one works with a latebloom value around 100. Go for something around 250 and then let the user fine tune it.
Another thing to consider, most people that had being testing the kext from the start have carefully chosen hardware configs and clean BootROMs, while the general people don't.
Last edited:
No joy. I tried to do an upgrade install from catalina and it hung continually. That is all for me.
Checking "log show --predicate 'sender == "latebloom"' --start $(date "+%Y-%m-%d") --debug" produces:
Log - Default: 0, Info: 0, Debug: 0, Error: 0, Fault: 0
Activity - Create: 0, Transition: 0, Actions: 0
Checking "log show --predicate 'sender == "latebloom"' --start $(date "+%Y-%m-%d") --debug" produces:
Log - Default: 0, Info: 0, Debug: 0, Error: 0, Fault: 0
Activity - Create: 0, Transition: 0, Actions: 0
Agreed. I have my quarterly Rom flash coming up. Wonder if it'll change anything.
What was your delay you used? As @tsialex mentioned, if you have an older Xeon Processor and based on your signature you do, you need to increase that value higher than the 100 you seem to have used.
I used 100 & 250. I am not certain if I have placed the boot-args in the wrong place (I feel it's ok but then again I can't be certain)
<key>7C436110-AB2A-4BBB-A880-FE41995C9F82</key>
<dict>
<key>boot-args</key>
<string>-lilubetaall -wegbeta agdpmod=pikera shikigva=80 unfairgva=1 mbasd=1 -wegtree -no_compat_check no32exec=0 latebloom=100 lb_range=20</string>
<key>csr-active-config</key>
Try some other values and set a range. If not, maybe wait until there is a more complete solution.
Do you have implemented the latebloom kext correctly? You always write about boot-args.
Code:
kextstat | grep latebloomshould return something
also
Code:
log show --predicate 'sender == "latebloom" AND composedMessage CONTAINS "Hook placed successfully"' --start $(date "+%Y-%m-%d") --debugadded an AppleScript to check for kextstat contains latebloom and the logfile with @startergo 2nd additions
Last edited:
kextstat | grep latebloom returns nothing and "log show --predicate 'sender == "latebloom" AND composedMessage CONTAINS "Hook placed successfully"' --start $(date "+%Y-%m-%d") --debug" returns:
Filtering the log data using "sender == "latebloom" AND composedMessage CONTAINS "Hook placed successfully""
Skipping info messages, pass --info to include.
Timestamp Thread Type Activity PID TTL
--------------------------------------------------------------------------------------------------------------------
Log - Default: 0, Info: 0, Debug: 0, Error: 0, Fault: 0
Activity - Create: 0, Transition: 0, Actions: 0
The section in config.plist with latebloom:
XML:
<key>Kernel</key>
<dict>
<key>Add</key>
<array>
<dict>
<key>Arch</key>
<string>x86_64</string>
<key>BundlePath</key>
<string>Lilu.kext</string>
<key>Comment</key>
<string>Do not touch this setting</string>
<key>Enabled</key>
<true/>
<key>ExecutablePath</key>
<string>Contents/MacOS/Lilu</string>
<key>MaxKernel</key>
<string></string>
<key>MinKernel</key>
<string>16.0.0</string>
<key>PlistPath</key>
<string>Contents/Info.plist</string>
</dict>
...............
<dict>
<key>Arch</key>
<string>x86_64</string>
<key>BundlePath</key>
<string>latebloom.kext</string>
<key>Comment</key>
<string>PCI delay for BS/Monterey</string>
<key>Enabled</key>
<true/>
<key>ExecutablePath</key>
<string>Contents/MacOS/latebloom</string>
<key>MaxKernel</key>
<string></string>
<key>MinKernel</key>
<string>18.7.0</string>
<key>PlistPath</key>
<string>Contents/Info.plist</string>
</dict>
</array>It is the last entry.
Yes of course. That was the first thing I did.
Attachments
Thanks for the report. So lb_range=20 still shows improvement after you set latebloom=250?
Yes. I've rebooted about 8 times so far after adding the range and have not gotten a boot hang yet. Fingers crossed.
IIRC the 3,1 seems to work fine on 11.3 and 11.4 but not Monterey, I've seen other users on here get higher than 11.2.3 on a 3,1 but not a 4,1 / 5,1.
To me, the first statement suggests a higher value will have a higher chance of success. But that doesn't rhyme with the second statement. Why would you start with 250?
- Status