The Seemingly Unsolvable Kernel Panic....

[matt shaw]

Hey everyone. Obviously I'm quite the noob, but I've been able to get everything running and functional in SL 6. I used tony's [url="http://www.insanelymac.com/forum/topic/279450-why-insanelymac-does-not-support-tonymacx86/"]#####[/url] to install SL with the retail DVD, but now I have tried to install Chameleon and I get a kernel panic on every boot. I've tried every kernel flag, but it keeps returning an error similar to "cpu 1: no HPET assigned to AppleIntelCPUPowerManagment". I've researched this extensively for the past 3-4 days, but can't get around it. I'm running SL on a Dell Inspiron 1545 with 3 gb of RAM. If you need more specs or an exact error message, please do tell.

[gyozadude]

Couple of things if you haven't already tried it: a) boot into BIOS and if you can find High Performance Event Timer, enable it. b ) otherwise, boot into the install media, start the utility shell, and cd /Volumes/[yourdisk]/System/Library/Extensions and mv AppleIntelCPUPowerManagement.kext to AppleIntelCPUPowerManagement.kext.off or .bak or your suffix of choice. cd .. and then touch ./

and reboot the system from the original hard drive. If the power mgmt module was causing the KP, it should stop now.

[matt shaw]

I can't find the High Performance event timer in my BIOS. By the install media, do you mean boot with [url="http://www.insanelymac.com/forum/topic/279450-why-insanelymac-does-not-support-tonymacx86/"]#####[/url]? If so, by the utility shell do you mean the command line that you can use at the bottom of Chameleon when it's booting from [url="http://www.insanelymac.com/forum/topic/279450-why-insanelymac-does-not-support-tonymacx86/"]#####[/url]?

[gyozadude]

No, I do NOT mean the [url="http://www.insanelymac.com/forum/topic/279450-why-insanelymac-does-not-support-tonymacx86/"]#####[/url] command line. I mean the UNIX shell command line after the OSX installer is up. By booting the install media, if you were able to boot with [url="http://www.insanelymac.com/forum/topic/279450-why-insanelymac-does-not-support-tonymacx86/"]#####[/url] and then boot into the OSX installer, you should see a utility menu on the top bar and find the command line shell. It's after you boot OSX installer. Presumably, you were able to boot to OSX in some form, format disk for Mac OS Extended/Journaled and then install, correct? If you can get there, and open up a "UNIX" terminal, then you're in good shape. You'll find your disk drive usually mounted already for you at /Volume/[name of disk] and that's how you can simply move the /Volume/[name of disk]/System/Library/Extensions/[name of kext].kext to .bak suffix.

[TedLucky]

IMNSHO I would not recommend to rename the driver. You could extract the SSDT through UBUNTU live USB or chameleon based P&C States

Edit Extra/com.apple.Boot.plist

		<key>EnableC4State</key>
<string>Yes</string>
<key>GenerateCStates</key>
<string>Yes</string>
<key>GeneratePStates</key>
<string>Yes</string>

[gyozadude]

Generating P/C states for CPU is one possibility IF the cpu PM is the culprit. OS X is UNIX under the covers. Moving a loadable module out of the way merely prevents the loading of the module and allows the boot to complete. You can move it back safely without issues unless you're not familiar w/ UNIX in which case, proceed with caution. In fact, most installers do this to prevent power management from kicking in during the install in order to make it more robust. But still, adding some directives to /Extra/com.apple.Boot.plist might work if that is specifically the problem.

[mulcyber]

Generating P/C states for CPU is one possibility IF the cpu PM is the culprit. OS X is UNIX under the covers. Moving a loadable module out of the way merely prevents the loading of the module and allows the boot to complete. You can move it back safely without issues unless you're not familiar w/ UNIX in which case, proceed with caution. In fact, most installers do this to prevent power management from kicking in during the install in order to make it more robust. But still, adding some directives to /Extra/com.apple.Boot.plist might work if that is specifically the problem.

 

I have a question about this. Suppose after matt renames a suspicious kext, he installs another kext, repairs permissions and rebuilds the cache. Now if the renamed suspicious kext is restored to its original filename: Don't the permissions have to be repaired and the cache rebuilt for that kext again? I agree that kexts should have the higher priority in troubleshooting.

 

I think advice about installing/altering kexts should always include a reminder about repairing and rebuilding to any new user since it's outside their experience. I had this happen to me, except that I put the kext I wanted to test in Trash. I tested something else. So when I restored the kext from Trash that I was testing to see how the system performed without it being used, it no longer worked, I had to reinstall it.

[neuk]

Have you checked your DSDT that the section, "Device HPET" must be present to pass/load the AppleIntelCPUPowerManagement.kext?

 

For example, my 945GCMX-S2 motherboard's DSDT has no "Device HPET" section and got kernel panic when loading AppleIntelCPUPowerManagement.kext. I've to manually insert the "Device HPET" section and the proper code into the DSDT.

[TedLucky]

You need to do it in 3 Steps (Snow Leo)

1. Copy

sudo -s
cp -r -v MyDriver.kext /System/Library/Extensions/

 

2. Repair Permission

chown -R root:wheel /System/Library/Extensions/MyDriver.kext
chmod -R 755 /System/Library/Extensions/MyDriver.kext

 

3. Clear Cache

rm -r -v /System/Library/Caches/com.apple.kernelcaches/*
rm -r -v /System/Library/Caches/com.apple.kext.caches/*

[gyozadude]

When moving files and directories around, the permissions and owner are usually preserved. Unless you feel the system is unstable and you want to copy before right, then cp -p will preserve permissions (and owner if you are root). And files are not necessarily set UID when in the root filesystem. They just need to be readable. If your default shell profile or .rc file sets umask 022, then be default, files are created readable by all and directories read/executable by all. I only started installed OSX about a month ago, and I thought it was strange that so many folks were having "permissions" issues with copying files. Then I realized that most folks on Mac OS X never use the shell much, or don't have the right RC settings in .cshrc or .profile. And plus they use graphical utilities which might also skip "hidden" files or what I would call "dot" files. I haven't run in permissioning issues yet, but then again, I'm coming in from UNIX where most of my time was spent on a console terminal which I think is faster at getting the job done if you know what you're doing. But graphical utilities can work too.

 

My recommendation for non-shell users is to get the system booted graphically into OS X, download some modern version of kext utility, and then simply drag a .kext bundle icon onto the kext utility icon and the utility will do almost everything, back up existing .kext directory in /S/L/E, copy the new .kext directory over, then set the perms and rebuild kext caches.

 

As for worrying about copying .kext directories, renaming them, and then reverting back, in most cases, if you've done it right on the command line, there is no change in permissions required. I rarely ever type "sudo" on anything. I run "su - root" or I have a C program that lets my userid su to root by just a few keystrokes. Then I'm fully root, and no longer need to sudo anything which is a pain in the rear.

 

You are right about the big fear - which is clobbering files in an existing directory. And that can happen if you're not careful. Which is why I never simply cp -v -r anything to a target directory. I check if the target exists and then mv that out first and then cp so as not to clobber. But to each his/her own. YMMV! Good luck!

 

I have a question about this. Suppose after matt renames a suspicious kext, he installs another kext, repairs permissions and rebuilds the cache. Now if the renamed suspicious kext is restored to its original filename: Don't the permissions have to be repaired and the cache rebuilt for that kext again? I agree that kexts should have the higher priority in troubleshooting.

 

I think advice about installing/altering kexts should always include a reminder about repairing and rebuilding to any new user since it's outside their experience. I had this happen to me, except that I put the kext I wanted to test in Trash. I tested something else. So when I restored the kext from Trash that I was testing to see how the system performed without it being used, it no longer worked, I had to reinstall it.