Sorry not have positive things to report after six attempts to boot Big Sur 11.4 through latebloom. Verbose mode tells me latebloom seems to do what it's supposed to do (using delays of 100 and 270 ms, and a random additive delay of +/- 20 ms, but the boot process has ended up crashing several MINUTES later every time.
View attachment 1805572
Perhaps my Mac Pro 5,1 is not the best testing ground for latebloom. Before latebloom, I only got my Mac to boot one time out of roughly 30! It doesn't have any NVMe blades or SSD disks, just four regular hard disk drives (one of them moderately fast, at 7200 rpm). It also has a Titan-Ridge Thunderbolt 3 PCI card and an updated Wi-Fi/Bluetooth module. It has a 6-core X5765 processor running at 3.07 GHz.
Any suggestions?
More challenging systems are an important part of these tests; they'll help establish the limitations of this method, and possibly provide clues to a better solution.
Your picture appears to show a common hang point, but that photo doesn't show any signs of latebloom. Did you definitely see the words
_____[ !!! *** latebloom *** !!! ]: Hook placed successfully. Count = 0 prior to this? Latebloom doesn't actually prevent hangs, but because the delays typically have at least
some effect, it's unusual to see a hang exactly where it would have hung without latebloom. I suggest verifying that latebloom is definitely loaded and the hook is successfully set, because it looks like perhaps it's not. (As I noted in an earlier post, my own method involves recording the boot screen in slow motion on my iPhone, then scrolling through it slowly. Crude, but effective.)
PCI probing can happen for hot plug (Thunderbolt or ExpressCard or similar)?
I think that's a separate mechanism, but we should definitely test it. I'm away from my computer for most of today, so maybe someone else could try it? Set a fairly high
latebloom value, one that would produce an unmistakable delay, then try generating a hot plug event and see if it's far slower than usual. (Now that I think about it, I don't really have the hardware to test this myself...)
If the purpose of the hook is to delay PCI Bus Probe so it doesn't do stuff while something else is happening, then maybe this could be improved by making the delay last until whatever that something else is has completed. But you would have to find what that something else is. Is it a probe of some other device? I understand that you did try disabling all but one CPU but even a single CPU can do multiple threads - there's a scheduler that preempts one thread to continue work on another.
The hook is "dumb," in the sense that it knows nothing about what's going on in the PCI bus probe module. That's by design, because the MacOS register allocation and data structures change from dot-rev to dot-rev, and maintaining visibility into the module being hooked becomes extremely messy when supporting more than one very specific OS release. (I learned this the hard way when implementing my AVX emulator, which has related issues that I'm still ironing out.) When monkeying around with the internals like this, I like to stick with the KISS model unless absolutely necessary.
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?
My "best results seem to be in the 50-150ms range" statement was based on results from a small group of alpha testers; the whole point of this public beta is to figure out what (if anything) works on more than that handful of systems. The basic idea presented by
@tsialex is: the slower your CPU is, and/or the more PCI devices you have, the larger the
latebloom=N value probably needs to be. There isn't going to be a "one size fits all" value, every system will have its own optimal value based on the hardware/software configuration. Starting from a more conservative (higher) value should prevent some unnecessary pain when trying this on slow or heavily-PCI-populated systems.
I reserved two posts at the top of this thread for things like a FAQ and a results table - once folks have had a chance to tweak this, I want to create a table with system configurations and optimal/acceptable delay values, and we can see if there's any consistency. If we're lucky, we'll end up with a fairly clear-cut formula for calculating a starting
latebloom=N value given the CPU, memory, and PCI setup. If we're exceptionally lucky, I might be able to incorporate some of that logic into the kext itself so that it can calculate a reasonable default on the fly if no
latebloom=N value is present. (It never hurts to dream...)
forums.macrumors.com
