shrieken213 Posted July 26, 2014 Share Posted July 26, 2014 Hey guys, I installed Yosemite on my computer using two USB drives: one dedicated to booting via Chameleon and one a vanilla installer for Yosemite created using createinstallmedia (I have a real Mac too). I installed Yosemite right over my Mavericks installation. I used the installer for version r2391 found here: http://www.insanelymac.com/forum/files/file/59-chameleon-22-svn/ After installing all my kexts, everything is working as they were before, but today the machine REFUSES to boot without maxmem=4096. Otherwise it gets a KP "Expected 0xdeadbeefdeadbeef but found 0xdeadbeef00000000" caused by kextd. The issue is that I have 16GB of RAM installed. I can't use a machine with 1/4th of the RAM that it used to have. What's worse, the KP does not show a backtrace to which kext caused the panic. Using a flurry of flags I managed to get a single backtrace to AppleHDA, which I rolled back to Mavericks for ALC892 support. Perhaps that's the issue? But that's unlikely, because most of the KPs happened right when the screen prints "Waiting for DSMOS." Another curious behavior that Chameleon 2.2 r2391 is that it cannot boot FROM a hard drive. That is, only USB boot disks work so far. If booting Chameleon r2391 from a hard drive the computer freezes during the pre-boot kernel loading (the wall of "read xx.kext [yy bytes]"). This means I have to keep my flash drive (in my case, this is also attached to my keychain ;- plugged into the computer if I want to boot into Yosemite... I'm running 4770K@4.3Ghz on a GA-Z87MX-D3H and GTX 770. Can anyone help me out here? Especially the maximum=4096 issue? > < *UPDATE* I tried the boot flag -force64 to force Yosemite into 64-bit mode (although by Apple's documentation everything after Snow Leopard should always boot into 64-bit...). So far the Hackintosh has booted successfully without the need of maxmem=4096, but we'll have to wait and see if it's a permanent fix. I also restored the AppleHDA provided by Yosemite. Maybe I'll just go to a DSDT edit instead of patched AppleHDA. Link to comment Share on other sites More sharing options...
shrieken213 Posted July 26, 2014 Author Share Posted July 26, 2014 Abandoned attempts to use AppleHDA and went with VoodooHDA. The KPs are back, even with -force64 and maxmem=4096 I'm at a loss for what is causing this. I even did a reinstall over the current Yosemite beta installation, which should have restored all the patched kexts to the original Yosemite kexts, yet I still get this error! I've also discovered that the USB kext included with Yosemite is highly unstable, freezing and crashing the system whenever I plug in a device. Link to comment Share on other sites More sharing options...
styrian Posted July 26, 2014 Share Posted July 26, 2014 @ shrieken213 Hello! It is for anybody, who wants to give you support, very hard to do this because of your unknown, used install method and SMbios personalitiy. Please put your hardware in your signature as told by the board rules and like many others have done it here. Have fun. Link to comment Share on other sites More sharing options...
jamiethemorris Posted July 26, 2014 Share Posted July 26, 2014 -force64 is only for amd kernels I believe and definitely serves no purpose under 10.8 and later. If you're getting kernel panics with voodoohda, make sure you have hdadisabler installed otherwise applehda will conflict with it and cause a kernel panic. Freezing and crashing with USB should be easily fixable, are you using genericusbxhci? Link to comment Share on other sites More sharing options...
sualpine Posted August 1, 2014 Share Posted August 1, 2014 I have the same exact issue. 4770k, GA-Z87MX-D3H, GTX 770, 16 GB of RAM. Chameleon 2391, using the iMac 14,2 SMBios. My current booting args are, "-v, npci=0x3000, UseKernelCache=No, maxmem=4096, PciRoot=1, GraphicsEnabler=No, kext-dev-mode=1". Would really like to boot with 16 gigs instead of 4. Link to comment Share on other sites More sharing options...
Pike R. Alpha Posted August 1, 2014 Share Posted August 1, 2014 This KP can be cause be a hardware or software failure. Try to boot with: "-no-zp" under 'Kernel Flags' in /L*/P*/SystemC*/com.apple.Boot.plist You can also remove/swap memory modules to see if any of them is causing this problem. 1 Link to comment Share on other sites More sharing options...
sualpine Posted August 2, 2014 Share Posted August 2, 2014 I know for sure this isn't a problem with my RAM. No issues running Windows / Linux on the same machine, as well as Mavericks. I will try the -no-zp option and report back, thank you. Link to comment Share on other sites More sharing options...
sualpine Posted August 2, 2014 Share Posted August 2, 2014 Issue persists. Link to comment Share on other sites More sharing options...
Pike R. Alpha Posted August 2, 2014 Share Posted August 2, 2014 What is the exact text you get? Is that: "a freed zone element has been modified: expected %p but found %p, bits changed %p, at offset %d of %d in zone: %s"? The %p/s/d are arguments and will be replaced with a value. Link to comment Share on other sites More sharing options...
sualpine Posted August 2, 2014 Share Posted August 2, 2014 I have also noticed that the latest Chameleon does not capture my full plist. It is not capturing UseKernelCache=No, GraphicsEnabler=No, etc. Link to comment Share on other sites More sharing options...
Pike R. Alpha Posted August 2, 2014 Share Posted August 2, 2014 Yeah that is the one. Adding "-no-zp" (without the quotes of course) should work, but probably not if Chameleon fails to read com.apple.Boot.plist properly. 1 Link to comment Share on other sites More sharing options...
styrian Posted August 2, 2014 Share Posted August 2, 2014 Hello! Why do you set npci=0x3000? Try to get rid of it. Have fun. Link to comment Share on other sites More sharing options...
sualpine Posted August 3, 2014 Share Posted August 3, 2014 I have confirmed that manually entering "-no-zp" works. Thank you very much! Could you please explain it's meaning/purpose, any possible ill effects, and any possible solution? Also, would like OP to confirm the resolution also. Thanks. Link to comment Share on other sites More sharing options...
Pike R. Alpha Posted August 3, 2014 Share Posted August 3, 2014 "-no-zp" means that zone poisoning is disabled (grep /var/log/system.log for: Zone poisoning disabled) And looking at the source code (XNU/osfmk/kern/zalloc.c) then we find this: -zp: enable poisoning for every alloc and free -no-zp: disable poisoning completely even for tiny zones zp-factor=XXXX: override how often to poison freed zone elements (default value=16). A zp_factor of 0 indicates zone poisoning is disabled -zleakoff (flag to disable zone leak monitor) zfactor=XXXX (override how often to sample the zone allocator) zleak-allocs=XXXX (override number of buckets in zallocations) zleak-traces=XXXX (override number of buckets in ztraces) -zinfop zalloc_debug -zc lets zlog log to debug zone corruption instead of leaks. zlog=<zone_to_log> zrecs=<num_records_in_log> The corrupted memory zone in that KP screenshot is "kalloc.64" (see zone_to_log and -zc) but we first need the debug kernel (no source code yet) before we can debug this with lldb's zprint. In short. Some process (code) is allocating memory, some time later it freed the allocated memory but then some (other) process writes to the freed memory. Which shouldn't happen of course. Uninitialised values in say bootstruct.h may be causing this, but again, there is no debug kernel yet so this is just an assumption. 2 Link to comment Share on other sites More sharing options...
justinreyesv Posted August 4, 2014 Share Posted August 4, 2014 Chimera is not working with current build of Yosemite as far as I know (something about changes in the kernel apparently), you have to use Clover for now (and for good hopefully) so you're gonna have to pin down getting it working in Mavericks. Quote from piker alpha: kernelcache "The above snippet also gave away that Apple is still using the same version/name/path for the kernel cache, but hold on. There is also a new property called Preferred Compression. Set to lzvn. Which is new. Overriding the previously used lzss compression method. But looking at the code, I think that you can either remove or rename lzvn to lzss and then kextcache will re-create a new kernelcache with lzss. Which is a must have for legacy boot loaders like Chameleon, Chimera and RevoBoot because without support for lzvn or renamed property value, this piece of code in drivers.c will error out with: “kernel compression is bad!“ Link to comment Share on other sites More sharing options...
MilanTristan Posted October 21, 2014 Share Posted October 21, 2014 Any negative impact of using boot flag -no zp?? Link to comment Share on other sites More sharing options...
Recommended Posts