Well it was much more complicated than this.
If anybody has similar issues (needing to troubleshoot loaded kexts) - i suggest getting an app called
This will tell you EXACTLY what is loaded, rather than just using the list from system report. System report didn't give me everything, and kext wizard found 4 or 5 that were loaded in non-safe boot that weren't in safe boot.
I'm currently testing if i can prevent the kernel panic right now, another 15 minutes to go with the redcine-x transcode. It always gives up around 4 minutes to go mark. (weird). When in safe boot it finishes properly.
Incidentally, make sure you set transcodes to 6 simultaneously and set your export preset to be 'use redline' (in option tab of each export preset) - you can do 6 at once and it'll use all your CPU cores and max it out (rather than only using about a 1/4 of your CPU and taking way longer for multiple clip transcodes)
It takes a LOT of troubleshooting. One of the kexts loaded that i didn't want loaded, was actually inside the PLUGIN folder inside a kext - i wanted the REST of the kext to load but not the plugin in side it, so you have to right click to 'show package contents' and find it thru there.
in 10 minutes i'll know whether this was a success. then i can slowly bring back kexts that i'm now sure are fine and leave out the naughty ones.
Well, it needed to go even deeper! I hope this helps someone.
So after making sure the same kexts were listed as loaded - like the list was EXACTLY the same, same number...it still wasn't working (the transcode in redcine-x)
Just remember this would apply to any replicatable fault where you get a kernel panic.
So what i did was reboot in safe mode and verbose mode - which logs the results of that to the system.log in /private/var/log
open this in console and look for what extensions safe boot is saying it's going to 'suppress the personalities' of.
I went thru, and did that. Now, some of what it wants to suppress is again, only inside the package in the plugins directory of that particular kext. so i just copied (made a backup) of the whole thing and then went in and only deleted the plugin it didn't want. I"m assuming other plugins ARE needed.
I missed a few, tested, failed, and did it again - had another 6 or so. Now my NORMAL boot looks the same as SAFE boot, and safe boot doesn't suppress any kexts. It has to do with the OSBundleRequired in the plist of important kexts, as per here:
OSBundleRequiredproperty informs the system that your kext must be available for loading during early boot. Kexts that don’t set this property can’t load during early boot. You can specify one of the following values for this property:
This kext is required to mount root, regardless of where root comes from—for example, platform drivers and families, PCI, or USB.
This kext is required to mount root on a remote volume—for example, the network family, Ethernet drivers, or NFS.
This kext is required to mount root on a local volume—for example, the storage family, disk drivers, or file systems.
This kext is required to provide character console support (single-user mode)—for example, keyboard drivers or the ADB family.
This kext is required even during safe-boot (unnecessary extensions disabled)—for example, mouse drivers or graphics drivers.
So testing again, see how I go.
Well, it didn't fix it, after all that.
So I'm back to my original question.
WHAT ELSE DOES SAFE BOOT DISABLE??? I have effectively replicated what Safe Boot does with all the extensions. Taken out all startup items from both account and system, launchagents, launchdaemons, all gone.
I just can't figure out what else safe boot does that is causing redcine-x to be happy again and export fine. Other than running fsck at startup. But that's not it.
Doesn't make sense to me.
If anybody who understands safe boot in detail reads this, PLEASE let me know what else I would have to disable or check to replicate safe boot. This way I can drill down to find the real cause and put everything else back in and only kill the nasty bit.
Nice stab in the dark but it's not that.
Good try tho.
It would do this off multiple hard drives booting.
The answer we were looking for is that Safe Boot also limits the amount of memory accessible. In my case, a bad DIMM was the problem, causing all of these problems. And of course, testing the memory was one of the first things I did - but Tech Tool Pro's memory test passed it all, it wasn't until I used "Rember" to test the Ram did it highlight the kernel panic when testing "All" ram.
Steer clear of Tech Tool! Useless.
Hope this helps someone else.
I just wish all those dumb articles on the internet talking about Safe Boot like we're all idiots actually went into some technical details about what it did - I had to figure this out for myself.
It is hard to help someone as technically competent as you.
But Apple's preferred way of testing hardware is called the apple hardware test.
It runs at boot time, so is not OS dependent, and can be run in a loop over night to catch memory problems, intermittent problems and the like.
How you get to it varies by model:
There are a few tricks here:
1. A negative on the AHT or on RAM testers does not indicate the lack of a problem.
2. You may want to loop the test and run it overnight. To do that, press Command +L
3. To stop the test, press Command+. The stop button generally doesn't work.
Regarding input managers, they are a little hard to get to. I found Cleanmymac very useful for finding the troublesome Chax input manager. For the record, you should never knowingly install an input manager, input method, or third-party kernel extension unless absolutely essential for your operation. I am also not positive Chax was causing my issue (fan running excessively due to high temp readings) because istat was controlling the fans without my realizing it. (default settings.) This is bad behavior for a monitoring application.
It's well known that even Apple Hardware Test can pass bad Ram.
The best thing to do if you suspect ram is to literally remove it. (if you don't have it soldered on the board) and test your known actions that cause the panic
Rember didn't require overnight testing - it failed within 30 seconds. Note it did NOT fail when testing smaller chunks of Ram. Meaning, that it accessed ALL of it straight away with a huge 32GB chunk of data straight into it.
This is why I was only getting panics on ram intensive tasks like Redcine-x.
I'm in the same situation right now, an iMac G5 that shows on-screen artifacts (HUGE ones) whan booted normally, but works as a charm in safe mode. I'll try kext wizard and/or your extensions-pruning procedure.
Thank you very much, I was starting to think I was missing some obvious information, so in a way it's nice to know that it's Apple's fault and not user stupidity