bisk Posted January 29, 2018 Share Posted January 29, 2018 Aloha ! I am having the craziest problem which had been driving me nuts for over a week. Maybe a guru out there can shed some light on this one. OK, to explain ... I have installed Sierra 10.12.6 on an unsupported desktop system. Specifically, this is a series 4 (LGA775) motherboard with a Q9505 Core 2 Quad processor. This is not a new procedure to me as I have done several of these. Since it's defined as a MacPro3,1, /S/L/CS/PlatformSupport.plist was modified to allow booting and /S/L/E/NVDAStartup.kext was rolled back to the El Capitan version to allow use of an older (NVidia 9800GT) video card. At first, the system would boot and run just fine but soon afterwards, it would crash during boot up right after: "IOGraphics flags 0x43". This was not the typical KP within NVDAStartup.kext as there was no stack trace showing that the system was within this or any other kext during the panic. Instead, all that I got was a generic CPU fault showing no call stack at all. Suspecting the ElCap NVDAStartup, I replace the Sierra version and installed a Sierra-supported video card (GTS450) but was greeted with the exact same KP ! I managed to get this system to boot again by booting single user and rebuilding the kext cache manually. I went back to the ElCap version of NVDAStartup.kext and put back the 9800GT video card. Again the system booted and ran fine but the next time that I restarted the system, the same KP at boot time. Again, I booted standalone, manually rebuilt kext caches and again a perfect boot and run session. Suspecting something was going awry with the kextcache, I started keeping an eye on the prelinked kernel. When running in graphics mode, I decided to run: "kextcache -u /" and the OS did NOT rebuild anything so, at first, I was confused. But about 30 minutes later, I decided to check the prelinked kernel again and sure enough, it had gotten rebuilt automatically some time later. Tried rebooting, and got the KP. Booted standalone, manually rebuilt the prelinked kernel, rebooted up fine and then watched my perfectly good prelinked kernel be replaced automatically with a "poison" one some time later again ! From further testing I discovered that: If I rebuild the prelinked kernel by any method manually either by mounting this boot drive on another Mac or on the trouble system in standalone mode, this system will boot and run fine from the resulting prelinked kernel. However, if on this system in graphics mode, I either force a rebuild of the prelinked kernel manually or allow the system to rebuild it automatically, which it always eventually will, the resulting prelinked kernel will always cause a KP late in the boot cycle right in the graphics driver load phase. I should also mention that the "poison" prelinked kernels are always substantially larger than the good ones. Anyway, this is a system possessed and dead set on committing suicide over and over ! I have rebuilt the boot drive from scratch twice with the same result so please don't suggest that I do that one. I don't use any installation methods that "customize" kexts or any other aspects of the startup volume. I always begin with a completely vanilla startup volume and then make all of my customizations manually from there so I know exactly what I've got. Has anybody out there ever had this kind of demon and if so, how did you exorcise it ? I have attached a view of both an unsuccessful and a successful boot. Thanks in advance ! 1 Link to comment Share on other sites More sharing options...
MaLd0n Posted January 29, 2018 Share Posted January 29, 2018 u dont need modify nothing just use -no_compat_check flag and smbios macpro3,1 or iMac10,1(prefer iMac10,1) gt 9800 have total support in all system, just InjectNvidia CLOVER.zip after install send me tables RunMe.app.zip Link to comment Share on other sites More sharing options...
bisk Posted January 29, 2018 Author Share Posted January 29, 2018 Thanks for the super quick response, wow ! If by "InjectNVidia", u mean config.plist->Graphics->Inject->NVidia=Yes. I'm already doing that. I use MacPro3,1 instaed of iMac10,1 because MacPro3,1 opens up more USB ports. This way, I don't need to muck around with USBInjectAll.kext. Does -no_compat_check flag eliminate need to modify PlatformSupport.plist ? Does it also fix the Sierra NVDAStartup.kext problem with older NVidia cards and Sierra ? I'll give -no_compat_check a shot tomorrow and report back as instructed. Mahalo !!! 1 Link to comment Share on other sites More sharing options...
MaLd0n Posted January 29, 2018 Share Posted January 29, 2018 Yes, with -no_compat_check u dont need modify nothing use GT9800 and my folder above, the other we solve after install with DSDT Link to comment Share on other sites More sharing options...
bisk Posted January 31, 2018 Author Share Posted January 31, 2018 OK, I added the -no_compat_check and, sure enough, I am able to boot with stock Sierra /S/L/CS/PlatformSupport.plist and /S/L/E/NVDAStartup.kext. However, this system will still rebuild a prelinkedkernel that crashes upon reboot and right at the same place, immediately after: "IOGraphics flags 0x43". Here is the before and after prelinkedkernel. The smaller one is the original actually built on another system with the boot drive externally mounted. The second, larger one is what this system rebuilt while running with this boot drive. -rw-r--r-- 1 wheel 14750827 Jan 30 10:20 prelinkedkernel-rw-r--r-- 1 wheel 24052658 Jan 30 10:20 prelinkedkernel Strange how the timestamp did not change, huh ? I must stress that everything works on this system. Sleep, SpeedStep, Firewire, all USB ports, full graphics acceleration, native audio output, you name it. This is a Gigabyte P43T-ES3G mainboard. I believe that I have done all of the necessary DSDT mods but I am sure that there is always room for improvement. I also don't think that I really need very many of the usual Clover mods either but I will happily attach the results of your RunMe.app for inspection. I have never experienced a problem anything like this and I am not all that new to this scene. This is, in fact, my 122nd Hackintosh dating back to the Leopard days Thanks in advance ! Send me haxmax122.zip IORegistry.zip Link to comment Share on other sites More sharing options...
MaLd0n Posted January 31, 2018 Share Posted January 31, 2018 Ye, u have all essentials and good patches but the DSDT from ur bios? or u use from other user from other mobo? Link to comment Share on other sites More sharing options...
bisk Posted January 31, 2018 Author Share Posted January 31, 2018 Ye, u have all essentials and good patches but the DSDT from ur bios? or u use from other user from other mobo? Originally extracted from my own BIOS using F4 in Clover. Its an awesome build, just so confused. It runs El Capitan perfectly w/o the prelinkedkernel corruption thing. Link to comment Share on other sites More sharing options...
MaLd0n Posted January 31, 2018 Share Posted January 31, 2018 in u case, legacy, the best for install clover is it with rc scripts Link to comment Share on other sites More sharing options...
bisk Posted January 31, 2018 Author Share Posted January 31, 2018 in u case, legacy, the best for install clover is it 01.png 02.png with rc scripts OK, I'll reinstall clover with those options. Link to comment Share on other sites More sharing options...
bisk Posted January 31, 2018 Author Share Posted January 31, 2018 Alright, I did reinstall Clover with the customization options above but no difference. My problem does not involve finding the hard drive or getting this system to begin a boot cycle. My problem is that this system will create a prelinkedkernel that will NOT boot. I have 3 versions of the prelinkedkernel: #1 is 14MB and boots perfectly fine every time. It was created manually with "kextcache -i /" in single user mode. #2 is 19MB and KPs at the graphics kext loading stage. It was created manually with "kextcache -i /" after a successful boot into full graphics mode with preklinkedkernel #1. #3 is 24MB and KPs at the graphics kext loading stage. It was created automatically by the system when it decided that the prelinkedkernel needed to be rebuilt after a successful boot into full graphics mode with preklinkedkernel #1. They are too large to attach. WTH ? Really at a loss here. Has anyone ever experienced a problem like this ? Link to comment Share on other sites More sharing options...
Jief_Machak Posted June 27, 2020 Share Posted June 27, 2020 Have you ever found out ? Got the same problem today with Mojave ! Link to comment Share on other sites More sharing options...
Recommended Posts