Crashes always preceded by kernel[0]: zalloc did gc

[sman591]

I'm also using iStat Menus, and having the very strange kernel_task memory ballooning- last I had seen yesterday, it was at 6GB (not sure how much it got to by 1am). From last night:


The last time this happened the graph filled up (all the way to 16GB) completely before kernel panic.

Which bootloaders are we all using? Seems like that could possibly be related, as it seems that would directly relate to the kernel. I'm believe I'm using Chimera 2.1.1 r2248, according to

strings /boot

I'll try to figure out which applications I've installed

 

[ppohio]

I am on 2.1.2 r2248 - but I don't think that's the issue as I'm using the same bootloader to boot my clean partition which isn't experiencing the ballooning kernel_task issue.

 

[sman591]

I am on 2.1.2 r2248 - but I don't think that's the issue as I'm using the same bootloader to boot my clean partition which isn't experiencing the ballooning kernel_task issue.

Ah, touché. Can't be the bootloader then... unless it's the configuration? I'm not 100% sure what default org.chameleon.Boot.plist values are, but a few notable are

• Kernel=mach_kernel
• KernelFlags=darkwake=0
• UseKernelCache=Yes

Right off the bat, apps I have consistently running are CrashPlan, TeamViewer, AeroFS, Dropbox, and Mint.com, if those matter at all for the kernel ballooning.

 

[wonkywonky]

Sorry, didn't get notifications that new replies had been posted so I didn't check back here for a few days

All my three 24/7 running machines are now exhibiting the same behavior - my office workstation had KPed for the first time when I went in this morning. What's more, I forgot to keep an eye on kernel_task on my home machine and woke up to a dead machine this morning sigh.

Looking at my iStatServer charts, the rate at which wired memory increases seems to itself be increasing - that worries me a lot.

I just rolled FakeSMC back to v5.1.61 (from Multibeast v5.3.1). For the moment, I'm limiting my random trial and error efforts to kexts I *think* were changed about 30 days back.

I think I can also rule out the Paragon ExtFS and NTFS kexts I recently installed to test out on my home workstation.

The 3rd-party kext I have on all my machines that I would first suspect of being the culprit is Zevo (ZFS) v1.1.1, but it hasn't been updated since 2012-09-23 and hasn't given any trouble in the past.

ppohio, sman591: Are either of you running iStatServer as well?

 

[wonkywonky]

Ok, so I don't want to get too far ahead of myself, but it looks like FakeSMC v5.2.725 (or one of its plugins, not sure which) from MB v5.4.3 was the problem for me.

8 hours and counting, and all my machines are showing non-crazy wired memory behavior.

Rolling back to v5.1.61 from MB v5.3.1 seems to have done the trick for now - I'm going to try some other FakeSMC versions between v5.1.61 and v5.2.725 when I have time over the next few days and report back where things seem to have broken.

 

[ppohio]

Wonky, what's the best way to roll back FakeSMC? I am also running FakeSMC 5.2.725

It's weird that I have those installed on my "clean install" that isn't showing the crazy behavior, but I'd like to try rolling back too.

 

[wonkywonky]

I just installed it using MB v5.3.1 (I stored a copy) - grab it from the Downloads section.

I'm guessing there are some hardware configurations that aren't dealt with properly in the latest FakeSMC, and memory is leaking somewhere - for example, it identifies the core frequencies from my GTX650Ti but associates the wrong reading with the RAM voltage field (this field is correct on the older FakeSMC release).

 

[ppohio]

Hmmm - unfortunately that hasn't done it for me. Installed FakeSMC plugins from Multibeast 5.3.1 and my kernel_task is still increasing at a steady clip. Will have to see where we are later in the day but I am already above 1.57 Gb and my "stable"/blank installation never climbs above 1Gb. Will be interested to see if it works for SMan, I might have to actually remove the kexts and reinstall.

 

[wonkywonky]

Just to be sure nothing got left behind, can you delete FakeSMC from S/L/E and empty trash before you install from MB v5.3.1?

 

[ppohio]

Yup, I booted off my blank drive, deleted FakeSMC from the S/L/E on my main one, and reinstalled 5.1.61 to that drive and we're back in action. Will report back in a couple hours to see how we're doing.