Wow. After many many hours of testing... I finally found out why it stops. Or at least for my configuration. The problem is my DSDT. I can make it stop by removing a few lines, or by changing a few lines in my DSDT. How weird is that?
Apparently method _CRS under PCI0 is
extremely important for a good boot. If I make one wrong change and it is POOF! No boot.
Also I cannot boot without these lines in my DSDT:
Name (HPTB, 0xFED00000) // Used by several Apple kexts
Name (HPTC, 0xFED1F404) // AppleHPET.kext
Name (PEBS, 0xE0000000) // AppleProfileFamily.kext et all
And thus if you removed them... err. We seem to need them (now).
Note: The values for the three lines are probably different for you setup, or not required at all (maybe it's just my Sandy Bridge based setup).
p.s. I've let my hack boot/shutdown for 300 times and everything is still ok. Crazy stuff.
A few more observations:1.) I have 214 kexts in /System/Library/Extensions/
2.) I checked: /System/Library/Caches/com.apple.kext.caches/Directories/System/Library/Extensions/KextIdentifiers.plist.gz
and that tells me that I have 314 kexts.
3.) There are 313 kexts in Extensions.mkext (unpacked with mkextunpack).
4.) sudo kextcache -system-mkext outputs:
iPodDriver.kext is not valid; omitting from mkext.
JMicronATA.kext does not declare a kernel dependency; using com.apple.kernel.6.0.
BJUSBLoad.kext is missing dependencies (including anyway; dependencies may be available from elsewhere)
iPodDriver.kext is not valid; omitting from mkext.
Note: There are two lines for the exclusion of iPodDriver.kext – one for each arch.
5.) This shows me that my MKext is correct (includes all kexts).
6.) Then I replace my DSDT with a stripped copy and re-run kextcache again. And now I get a much smaller MKext (7.5MB) with 'only' 159 kexts in it.
This clearly shows us that the DSDT is very important when it comes to building caches, but I have yet to figure out what exactly it is that makes this difference.
Hello LionMost of you are probably wondering why this is so important. Well. Think Lion. Think about what error message people get when it fails to boot for them. Interesting isn't it?
We should setup a poll and ask people what (brand) motherboard they use, and what size their Extensions.mkext is when they boot into Snow Leopard. That should speak words. That will show you why group A can boot and group B never... or only sporadically.