Jump to content

Snow Leopard Install Succesful! - Quick Q on turning off the system


Jaam
 Share

20 posts in this topic

Recommended Posts

So I manged to complete a SL install on an AMD system following this guide:

 

http://www.insanelymac.com/forum/index.php?showtopic=227592

 

System boots and runs smooth, the only problem is whenever I try to turn off the system:

 

Hit Shut Down > starts shutting down and then the screens go black.

I wait a couple of minutes but the tower does not turn off by itself. At this point I just hold the power button in the tower and turn it off. I wouldn't really mind doing this, but the problem is that every time I do that the bios resets. I have to enter bios and change the settings every time I want to boot.

 

Now, if I boot using the nawcom bootcd from the guide, the comp will show a "it's now safe to turn off the computer" type message when I hit Shut Down. The settings in the bios don't change and every thing is groovy.

 

I was wondering if there's anything I could do to have the system give me this message whenever I am turning off the system.

 

any suggestions will be greatly appreciated!

 

I can't post this on the actual topic as I don't have 10 posts yet :guitar:

Other than that.... big thanks to Mohamed Khairy for the guide! ;)

Link to comment
Share on other sites

Quick update:

I found out about NullCPUPowerManagement.kext and EvOreboot.kext while browsing around the internet. Just gave it a try but no result unfortunately. Same deal system shuts down but the tower is still powered on...

Link to comment
Share on other sites

Quick update:

I found out about NullCPUPowerManagement.kext and EvOreboot.kext while browsing around the internet. Just gave it a try but no result unfortunately. Same deal system shuts down but the tower is still powered on...

 

http://www.insanelymac.com/forum/index.php?showtopic=170115

It does sound like a power management issue, and I think that is called ACPI.

I looked at an older install guide (2009) and it said to disable ACPI 2.0 in Bios (and enable AHCI).

Your motherboard is listed as successful which is why I'm passing on this info, even though it sounds odd.

You didn't mention whether you could restart. Do you have a patched DSDT.aml for your motherboard?

Link to comment
Share on other sites

That is for a leopard install...

I do have it sat as AHCI but I don't remember seeing an ACPI 2.0 setting :/

I'll look more into it. Thank you!

 

When I first installed snow leopard, it came with the cmos reset bug, reminding of your report the "bios resets". The fix for cmos reset is: ElliottForceLegacyRTC.kext Do you have that in your /Extra/Extensions folder?

Whenever you install a new .kext one needs to rebuild the cache and repair permissions; Kext Helper b7 is good for that.

 

Maybe the guy who wrote the guide saw that option with a different motherboard that he tested as working.

 

/Library/Preferences/SystemConfiguration/com.
.Boot.plist

The content of this file state boot options such as:

 

  1. timeout (how much time to wait for user selection in boot prompt)
  2. Kernel (what kernel to use)
  3. Kernel flags (what kernel flags to use in each and every boot)
  4. Quiet boot (weather to display boot menu or not)
  5. Boot graphics (if to boot with apple spinning circle)

ACPI Flags are as on :

  • acpi=off = Don’t enable ACPI
     
  • acpi=ht = Use ACPI boot table parsing, but don’t enable ACPI interpreter
     
  • acpi=force = Force ACPI on (currently not needed)
     
  • acpi=strict = Disable out of spec ACPI workarounds.
     
  • acpi_sci = {edge,level,high,low} Set up ACPI SCI interrupt. EX:
     
  • acpi_sci = edgeacpi=noirq = Don’t route interrupts

It is easy to change things in the Bios back to how they were but sometimes not so easy to revert

in the OS. Use this as a last resort. Does your Bios read S3 now? That is standard for Hackintosh (acpi).

Link to comment
Share on other sites

I have some free time this afternoon so I'll take a look at what's in the boodcd, check the bios once more (not sure on the S3), and search ElliottForceLegacyRTC.kext. I also saw a post by Devout in the guide I followed with some steps that I'd like to try out. I'll post an update later tonight if I have time.

 

Thank you! :)

Link to comment
Share on other sites

Ok so I didn't post it before, but after I installed NullCPUPowerManagement.kext and EvOreboot.kext I couldnt get the comp to boot at all (using boodcd or trying to start as safe mode) so I had to format and reinstall again.

 

Checked the bios for ACPI and I found:

ACPI Suspend Type [s3(STR)]

No 2.0 though...

 

I did not have ElliottForceLegacyRTC.kext in the extensions folder. After I installed it the bios does not reset anymore!

Thank you soooooo much!!!!!!! :)

 

I got the boot.plist off the bootcd and I'm going to compare it to the on that I'm currently using see if I can get somewhere with that. I've never really played with boot.plist before so it might be a couple of days before I can post an update.

 

Thanks again!

Link to comment
Share on other sites

Ok so I didn't post it before, but after I installed NullCPUPowerManagement.kext and EvOreboot.kext I couldnt get the comp to boot at all (using boodcd or trying to start as safe mode) so I had to format and reinstall again.

 

Good! Do you still have the can't shut down issue? I've experienced not being able to reboot but I could shut down, so they are not quite the same thing. Anyway, if you do, there is more than one kext which functions like EvOreboot.kext, but still I think even if it does not fix the problem, it will still be perfectly safe. IOW, I think NullCPUPowerManagement.kext must have been the culprit. Did you enable HPET in Bios? Another kext is OHR,

OpenHaltRestart.kext ... repair permisssion rebuild the cache.

 

A patched DSDT.aml removes the need for ElliottForceLegacyRTC.kext with the simple edit:

Length should be changed to 0x02, its normally 0x04

The exact patched dsdt.aml file which matches your motherboard is an asset

post-689921-1301464140_thumb.png

Link to comment
Share on other sites

Sweet!

I don't have any experience with patching DSDTs but I'll look up how to do it, shouldn't take more than a couple of tries :)

 

I don't have the HPET Mode option in my bios but the rest is set up the same as in your picture.

 

and yes, I still have the issue with only the os shutting down but the tower staying powered on.

I got the boot.plist from the bootcd I used. Going to do some reading and compare it to the boot.plist I'm using see if there is something I can do.

 

any suggestions on that?

Link to comment
Share on other sites

Sweet!

I don't have any experience with patching DSDTs but I'll look up how to do it, shouldn't take more than a couple of tries ;)

 

I don't have the HPET Mode option in my bios but the rest is set up the same as in your picture.

 

and yes, I still have the issue with only the os shutting down but the tower staying powered on.

I got the boot.plist from the bootcd I used. Going to do some reading and compare it to the boot.plist I'm using see if there is something I can do.

 

any suggestions on that?

 

MaLd0n has a DSDT Auto-Patcher which creates a patched DSDT.aml for your system. The time to run it would have been after you reinstalled and before adding anything to distort the DSDT info. http://www.insanelymac.com/forum/index.php?showtopic=235523

"If you are using the Mac OS version of DSDT Auto-Patcher, do NOT use a DSDT replacement in Chameleon when you run the app, or it will be used as base for patching instead of the original one from BIOS. If you have a dsdt.aml in / or /Extra (or a specified file for DSDT key in com.apple.Boot.plist), remove it and reboot before running the Auto-Patcher."

A patched DSDT.aml has the Cmos reset fix and applies the function of NullCPUPowerManagement.kext by internal editing of the file.

 

I saw a picture of your mobo but (Revision 2, and that matters) which had HPET enabled, with a Note: This only works for Vista.

 

------------------------------------------------------

 

http://osx86.sojugarden.com/downloads/

EvOreboot.kext

 

Adds Restart and Shutdown functionality for most systems that are using NullCPUPowerManagement.kext.

 

NullCPUPowerManagement.kext

 

Disables AppleIntelCPUPowerManagement.kext – this extension is required until you have built a proper dsdt for your system. Without this or the dsdt your system will not boot (kernel panic). IMPORTANT NOTE: It is suggested that everyone use this kext for now even if your system runs fine without it. There is an unresolved issue with the way AppleIntelCPUPowerManagement.kext handles HPET on non-apple hardware that causes the CPU to run much hotter than normal.

 

------------------------------------------------------------------------

 

 

NullPowerCPUManagement.kext is frequently recommended to fix problems. The description above is the opposite of what happened to you. So that is the clue that I will follow since I don't have any predetermined idea of what to look for in boot.plist. Changing HPET in the Bios is recommended in the install guides that I've read, and I don't know what happens when you don't have it enabled; HPET is found in the Power section of the Bios. Did you have any problem downloading and installing MK's AfterSetup.zip and did you choose GPT tables?

Link to comment
Share on other sites

NullPowerCPUManagement.kext is frequently recommended to fix problems. The description above is the opposite of what happened to you. So that is the clue that I will follow since I don't have any predetermined idea of what to look for in boot.plist. Changing HPET in the Bios is recommended in the install guides that I've read, and I don't know what happens when you don't have it enabled; HPET is found in the Power section of the Bios.

 

I found this fix within a patched DSDT.aml which relates HPET and Appleintelcpupowermanagement.kext

and states that NullPowerCPUManagement.kext can be deleted, which you don't have around anymore.

I've reached the point where I'm suspicious but don't know if this causes your problem.

 

HPET FIX

 

"This fix allows us to load the driver Appleintelcpupowermanagement.kext,

and in that way have the option to use the native speedstep available in osx

 

"This is the HPET code from a Mac:

 

Device (HPET)

{ {

Name (_HID, EisaId ("PNP0103")) Name (_HID, EisaId ("PNP0103"))

Name (BUF0, ResourceTemplate () Name (BUF0, resource template ()

{ {

IRQNoFlags () IRQNoFlags ()

{0} {0}

IRQNoFlags () IRQNoFlags ()

{8} {8}

Memory32Fixed (ReadOnly, Memory32Fixed (read only,

0xFED00000, // Address Base 0xFED00000, / / ​​Address Base

0x00000400, // Address Length 0x00000400, / / ​​address length

_Y09) _Y09)

}) })

 

 

This is the HPET code from a PC:

 

Device (HPET) Device (HPET)

{ {

Name (_HID, EisaId ("PNP0103")) Name (_HID, EisaId ("PNP0103"))

Name (_CID, EisaId ("PNP0C01")) Name (_CID, EisaId ("PNP0C01"))

Name (BUF0, ResourceTemplate () Name (BUF0, resource template ()

{ {

Memory32Fixed (ReadOnly, Memory32Fixed (read only,

0xFED00000, // Address Base 0xFED00000, / / ​​Address Base

0x00000400, // Address Length 0x00000400, / / ​​address length

_Y0F) _Y0F)

}) })

 

We only have to add the "Irqnoflags" and that would fix it.

 

I think after you exhaust other possibilities, that you should obtain a

precisely generated DSDT.aml for your system and see what if anything,

improves. It's not easy learning how to patch a DSDT.aml file manually,

which is why I suggested the MaLd0n DSDT Auto-Patcher approach.

 

http://macmanx86.blogspot.com/2010/11/mini...yte-socket.html

"Gigabyte has not yet added Hackintosh logic to Device (HPET), so you will get kernel panics in AppleIntelCPUPowerManagement. The fix is easy; just change Method (_STA, 0, NotSerialized) to Return (0x0F) and to change Method (_CRS, 0, NotSerialized) to Return (ATT3)."

 

mulcyber: How easy the fix is perhaps a matter of perspective.

Link to comment
Share on other sites

Got it. I'll format and reinstall again... the installation goes pretty smooth so I don't mind doing it over.

I'll try the auto patcher and post the results during the weekend(got long shifts until friday >.< ).

 

and thanks for all the input!!!

Link to comment
Share on other sites

Mulcyber, you're barking up the wrong tree here.

 

He has an AMD system, he will be using a patched kernel that will automatically block AppleIntelCPUPowermanagement.kext from loading. This is necessary on systems that can't run the vanilla kernel. All patched kernels do it, since Voodoo 9.5.0.

 

Therefore it makes no difference what he does to his HPET device in his DSDT. AFAIK AppleHPET.kext does not load at all if AppleIntelCPUManagement.kext is not loaded.

 

NullCPUPowerManagement is a kernel extension that disables AppleIntelCPUManagement.kext.

This is not necessary on AMD systems, where AppleIntelCPUPowermanagement.kext is not loaded at all.

Therefore NullCPUPowerManagement.kext can't possibly have anything to do with the OPs issues.

Link to comment
Share on other sites

Mulcyber, you're barking up the wrong tree here.

 

He has an AMD system, he will be using a patched kernel that will automatically block AppleIntelCPUPowermanagement.kext from loading. This is necessary on systems that can't run the vanilla kernel. All patched kernels do it, since Voodoo 9.5.0.

 

Therefore it makes no difference what he does to his HPET device in his DSDT. AFAIK AppleHPET.kext does not load at all if AppleIntelCPUManagement.kext is not loaded.

 

NullCPUPowerManagement is a kernel extension that disables AppleIntelCPUManagement.kext.

This is not necessary on AMD systems, where AppleIntelCPUPowermanagement.kext is not loaded at all.

 

Therefore NullCPUPowerManagement.kext can't possibly have anything to do with the OPs issues.

 

Well, ok.

 

Jaam's first post on this topic: "Quick update:

I found out about NullCPUPowerManagement.kext and EvOreboot.kext while browsing around the internet. Just gave it a try but no result unfortunately. Same deal system shuts down but the tower is still powered on...

 

Jaam's second post:

Ok so I didn't post it before, but after I installed NullCPUPowerManagement.kext and EvOreboot.kext I couldnt get the comp to boot at all (using boodcd or trying to start as safe mode) so I had to format and reinstall again."

 

Mulcyber: So I diagnosed Null*.kext as the likely culprit, because more people report having to include it or remove it to get their systems to work. I suggested he try again with just Ev0*kext or OpenHaltRestart.kext, because even if it didn't work, I didn't think it would result in no boot, and then a "format and reinstall again". Besides fixing his shutdown problem, installing just Ev0*.kext, if it didn't work but there was no meltdown, it would establish Null*.kext as the meltdown culprit.

 

Gringo wrote: "Therefore NullCPUPowerManagement.kext can't possibly have anything to do with the OPs issues."

 

Then the obvious conclusion is that it was Ev0reboot.kext which made his system unable to boot in safe mode or by the bootcd, so that he had to format and reinstall again. Since it was working ok before then except for having to manually power down. I believe the information you provided about AMD is true, but I don't believe those facts support the conclusion you arrived at. I suppose though, that I could have missed a report about EvO*.kext creating a system reformat/reinstall disaster. Jaam didn't report any other adjustments which he actually might have tried, so without that, the cause has to be Null*.kext or Ev0*.kext. Doesn't it seem even with no AMD power management that NullCPUPowermanagement.kext caused a big problem?

 

I've been nagging Jaam to generate a patched DSDT.aml because it's possible there arises the serendipitous result of fixing his shutdown issue. I've strongly discouraged Jaam from making a DSDT.aml with manual editing; instead I twice recommended using MaLdon's Auto-Patcher. He doesn't even have a DSDT.aml to attempt a manual edit on.

 

Is generating a DSDT.aml bad advice? Does the Auto-Patcher not work on his mobo? The most likely result it seems to me that if his type of mobo isn't supported, then it just won't generate a DSDT.aml. And it won't matter what you hope to fix with it unless a destructive DSDT.aml is created.

 

First of all I wanted Jaam to try Ev0reboot.kext or similar. I think he was afraid to try it. My tree is that I want him to generate a DSDT.aml. And if that works, fine. If not, I want him to try Ev0reboot.kext or similar, the one by Master Chief. So talking about power kexts, was a means to an end, I wanted to motivate him to generate a DSDT.aml. It's true that I thought such a DSDT.aml might modify his HPET section (although maybe his mobo doesn't have one) but I don't see that it matters. The A-P will do what it does and maybe a fix will fall out of it. Having the DSDT.aml is an asset, in any event. I don't see anything with taking this step before trying Ev0*.kext or similar, since Jaam seemed to decline the idea of trying Ev0*.kext

 

Jaam said he would generate a DSDT.aml by starting over this weekend. If he is going to reinstall anyway, why not try Ev0reboot.kext or similar first and see if it fixes his shutdown problem, since the worst that can result is that he has to do his already planned reinstall? I appreciate the explanation about AMD and modified kernels and I read most of your posts.

 

MaLd0n

Dec 23 2010, 11:23 PM

 

QUOTE (diawollo @ Dec 23 2010, 07:30 PM) *

Thank you Maldon! can I ask what did you change?

 

MaLd0n replied,

"IRQs

REMOVE

 

AMD does not have much to do many patches do not work

is not intel and you do not enjoy the power management"

 

"We only have to add the "Irqnoflags" and that would fix it.

Perhaps that's just a coincidence.

 

I looked at the patched for AMD mobo dsdt.aml that MaLd0n made available and it says in part,

 

Device (HPET)

{

Name (_HID, EisaId ("PNP0103"))

Name (_UID, Zero)

Name (CRS, ResourceTemplate ()

{

IRQNoFlags ()

{0}

IRQNoFlags ()

{8}

Memory32Fixed (ReadWrite,

0x00000000, // Address Base

0x00000000, // Address Length

_Y09)

 

Maybe this doesn't fix Jaam's shutdown problem, but I tink it is a worthwhile measure, so the DSDT.aml is a good idea.

And then he still has the option of trying Ev0reboot.kext with repair and rebuild, though I think MaLd0n said to use RC5 for restart and DSDT for shutdown though I'm not sure whether he was referring to Intel, AMD, or both.

 

"delete EvOreboot - use chameleon RC5(restart) and DSDT(shutdown)

Nullcpupower - read it http://www.insanelymac.com/forum/index.php?showtopic=225766 "

 

This is the Gigabyte edit for the same section, in the patched DSDT.aml which differs a little,

 

Device (HPET)

{

Name (_HID, EisaId ("PNP0103"))

Name (ATT3, ResourceTemplate ()

{

IRQNoFlags ()

{0}

IRQNoFlags ()

{8}

Memory32Fixed (ReadWrite,

0xFED00000, // Address Base

0x00000400, // Address Length

)

})

Name (ATT4, ResourceTemplate ()

Link to comment
Share on other sites

Got it. I'll format and reinstall again... the installation goes pretty smooth so I don't mind doing it over.

I'll try the auto patcher and post the results during the weekend(got long shifts until friday >.< ).

 

and thanks for all the input!!!

 

Since this is a Quick Q, I thought that you might be running out of things to do, and I was amused by,

 

http://www.spassets.com/forums/linux.acpi....0HPET%20working

 

"I have an AMD SB460 southbridge (has HPET), but a BIOS with no HPET support."

Link to comment
Share on other sites

OK Update!

So I looked into the auto DSDT patcher and it did not have my mobo so I couldn't actually run it.

I guess the only way is to learn to manually patch the DSDT and compare it to other AMD DSDTs see what I can change.

 

On another note: I decided to try NullCPUPowerManagement.kext and EvOreboot.kext once more for the hell of it and the system actually runs fine. It still won't power off but I can turn it on no problem. So the reason with I couldn't turn it on last time might be different. I was thinking maybe the com.apple.boot.plist was the problem... I did open it to compare it to other com.apple.boot.plist but I don't remember making any actual changes.

 

I'll keep on using ElliottForceLegacyRTC.kext meanwhile. Bios doesn't reset anymore so that's a good start. I'll do some reading about DSDTs and post an update as soon as I try something out.

 

Thanks!

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share

×
×
  • Create New...