Jump to content

Chameleon install: Can't boot without USB bootdisk, maxmem=4096?


16 posts in this topic

Recommended Posts

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

Abandoned attempts to use AppleHDA and went with VoodooHDA.

 

The KPs are back, even with -force64 and maxmem=4096 :P 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

@ 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

-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

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

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

"-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.

  • Like 2
Link to comment
Share on other sites

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

  • 2 months later...
 Share

×
×
  • Create New...