Jump to content

What is Speedstep and how do I patch it?


75 posts in this topic

Recommended Posts

Forgive the ignorance but I have a Speedstep-enabled mobo and haven't got a clue what this means,,,I know it has something to do with optimizing cpu speeds for best performance but even on Winbox I never found a controller or gui or anything to tell me what the heck this was all about!


Have read something on various hack forums abous S states and always assumed they had to do with these new 'i' sandybridge processors so never gave it a second look,,,until just now I discovered not only do I have it but also enabled in bios.


What do I need to do to use it... is there a way to patch the dsdt or patch a kext???

Link to comment
Share on other sites

Speed stepping (P-states) and sleep states (S-states) are only the tip of the iceberg.

Please study the following article before continuing here:



As you can see, the "S-states" that you're talking about are types of sleep states, all "sub-states" of G1. S3, or suspend-to-ram, is what happens when you click the sleep button in Windows, or OS X, if it's working properly. S4 is also known as hibernation, saving RAM contents to a file on your system drive and entering a low power state. Used more often on laptops than desktops.


Besides the "sleep" and "hibernate" buttons there is no "controller" or GUI for Windows, ACPI power state switching works automatically.

And when the right conditions are met, it also works automatically on OS X.


On a Hackintosh we used to have to make a lot of modifications to the SSDT and DSDT ACPI tables to get working CPU power management.

That changed in 2010: http://www.insanelym...howtopic=225766

Read the thread for more information, it is full of good stuff. Some of the info there is of course outdated by now. If in doubt, ask.


Quick and not very detailed checklist:

Make sure you are using a recent version of Chameleon. Chameleon is at 2.1 revision 2xxx now.

Before dumping your ACPI tables (not going to go into that, there are plenty of posts here that go into detail on this subject) enable ACPI 2.0, ACPI APIC and all advanced CPU features (except for CPUID Limit) in the BIOS.

add/set GeneratePStates and GenerateCStates to y in your /Extra/org/Chameleon.boot.plist as described

If you want you can dump your SSDT tables as well and have Chameleon load them. This way you can have the same (probably 4 on that CPU) P-states that you have in Windows. Name them as described and add DropSSDT=y to /Extra/org.Chameleon.boot.plist as well.

Use an /Extra/smbios.plist with complete and valid DMI data. You should probably use MacPro3,1 on that hardware. You can use champlist (google it) to generate one.


On your typical PC, the ACPI tables (such as DSDT and SSDT) are written to work with Windows and compiled with a compiler from Microsoft. While Macs use the same technology, Apple have their own way of implementing things, and therefore we sometimes have to make changes to the DSDT table to get power states like sleep (S3) and hibernate (S4) working correctly, like the USB wake signal code or something else. These things can be really hard to track down.

Thankfully a lot of work has been done in this area by some very intelligent people over the years, and so you can usually find code examples posted here and elsewhere that will work on your hardware - that is to say, if you can't find code examples specifically for your motherboard, ACPI table code from a same generation motherboard from the same manufacturer as yours will usually work with little to no editing.


Your HPET device code in DSDT must look something like this, or at least be functionally identical:



For native CPU power management to work correctly you must be running an unmodified Apple kernel.

AppleIntelCPUPowerManagement.kext, AppleHPET.kext and AppleLPC.kext must be loaded.

Kernel extensions such as disabler.kext and NullCPUPowerManagement.kext are made specifically to block AppleIntelCPUPowerManagement from loading, so you can't have either on your system.

Look in System Profiler/System Information or run Terminal.app and type kextstat -k to check which kernel extensions are loaded on your Hackintosh.

If you're getting error messages about C-states in kernel.log it means that AppleLPC.kext is not loaded, and you need to do this:



One way to check if native CPU power management is working is with IORegistryExplorer (part of Apple developer tools)


You can use hardware monitoring tools, such as these...


....to check CPU temperature on OS X, then compare temps with Windows, they should be roughly the same. If CPU temps are higher on OS X than on Windows under similar workload it's likely that CPU power management isn't working correctly.


You can also use Mark-i (discontinued, hopefully nobody minds me uploading it here):


See usage.txt included in the archive.

Screen Shot 2012-08-21 at 6.46.07 PM.png

  • Like 6
Link to comment
Share on other sites

Starting backwards... sorry... post got wiped when uploading the screen grab...




Clearly something is amiss (maybe as I reverted the system to a basic DSDT setup with kexts as I ran into an issue with the system clock and sleep no longer worked as expected after patching the dsdt)



More on that here: http://www.insanelymac.com/forum/index.php?showtopic=280756&st=120


I have chameleon wizard and kext wizard but no longer boot with Chameleon as Chameleon Wizard no longer connects to buildbot and there has been no fix for that or recent update.... instead I googled the latest Chimera and use it instead.


In Bios I have S3 states and speedstep enabled...

In org.chameleon.boot.plist both p-states and c-states are enabled..and when using the more patched version of the dsdt without kexts I used kernel cache option. Regardless of what I do though I have to have graphics enabler=yes enabled of I boot to a sleeping monitor...with or without nvenabler... but cannot see where I am going wrong...


I successfully patched the dsdt with EHCI and UHCI and was able to boot without the bus fix... (great!)... but alas the UHCI (2) code in DSDTSe.... seems to be a non-runner.... compile error 255 errors every time! tried adding in or subtracting an end bracket but no joy!


There are no such items listed in my dsdt either (suggesting I need to add them as opposed to edit them. Is this just a case of copy paste or do I need to edit this code somehow???)


Device (EHCI)

Device (UHCI)

Device (LPC)


and probably a few more...


My HPET code seems fine by default... copy code is pretty much exactly whats listed in the DSDT...



I use a 3.1 profile smbios as you correctly identified...


Think I had it in pretty good shape apart from the issue with the clock and sleep.... sleep closed off the monitor etc but not the cpu... fans keep on humming


Checked the console having 'woken' it and got this


Console message is as follows:

System sleep prevented by pci11c1,5811


Am baffled to say the least....


Will try to rebuild the dsdt from scatch and see how far I get with it.... and post back here then!

Link to comment
Share on other sites

The very first google search hit for 11c1,5811 is this: http://pci-ids.ucw.c...ad/PC/11c1/5811 - now that you have that information, improvise. I believe someone already suggested that you disable it in the BIOS, while not a solution it is a useful troubleshooting step.


You have no C-states and two P-states surely can't be correct for your CPU. It should have at least four like mine.


Like I said, try using Lavalys Everest Corporate Edition for Windows to dump your SSDT tables...

Everest_right_click.png Everest_ACPI_Dumper.png

...and have Chameleon load them. They must be placed in /Extra and named correctly and you need to add DropSSDT=y to your /Extra/org.chameleon.Boot.plist. For further details refer to my previous post and the topic I linked to.


There are no such items listed in my dsdt either (suggesting I need to add them as opposed to edit them. Is this just a case of copy paste or do I need to edit this code somehow???)


Device (EHCI)

Device (UHCI)

Device (LPC)


and probably a few more...


No, they are all there, just under different names. For example, ASUS uses the name USBE for EHCI. Gigabyte calls the LPC device PX40 and ASUS calls it SBRG. I have never seen a DSDT from an Intel board so I don't know which names they use.

If you can't identify a device by name or from looking at its code, use LSPCI to find it by address:

lspci V1.1.zip

Run the installer from the attached archive and reboot. Then run Terminal.app and type lspci -nn

You will see a list of all the devices on your motherboards PCI bus, along with address, vendor and device IDs for each device. For obvious reasons, this is extremely useful. If you look for 11c1:5811 that you asked about, you'll see that this is indeed your on-board Firewire controller.


Note that data shown by lspci has no bearing on actual functionality or whether any given device is 'recognized' by OS X. lspci is completely independent of the host OS, it merely scans the PCI bus and displays whatever it can match to its own internal list of known devices.

If you see any devices marked "unknown", you can enter update-pciids (answer y if asked about overwriting) to update that list. Then do lspci -nn again.


The following is just an example, you do not need to patch the LPC device code if AppleLPC.kext is already loaded on your system:

00:1f.0 ISA bridge [0601]: Intel Corporation 82801JIR (ICH10R) LPC Interface Controller [8086:3a16]

That's the LPC controller on Intel ICH10R, at 00:1F:0, as listed by lspci. Yours is probably located at the exact same address. Now use the search function in your DSDT editor to search for 0x001F0000 to find your LPC device code. You can do the same for other devices.


Note that I have already passed this very same information to you in my previous post, admittedly with a little less detail - but if you had bothered to follow the links I have given you, you would have known the above already.

If I get the idea that you aren't doing anything with the information I'm giving you, that means I'm wasting my time and I will stop trying to help you.

  • Like 1
Link to comment
Share on other sites

Part of the problem I think is that I don't understand the patch instructions...


USB native fix for example (i copied code from a supposedly 'fixed' dsdt which was obviously incorrect!)


Take this for example


USB native driver hack:
Locate your usb devices and add this code to each one, changing the values from device id with the one supplied under the code:[/size]

  Method (_DSM, 4, NotSerialized)[/size][size=3]
				Store (Package (0x0f)[/size][size=3]
						Buffer (0x04)[/size][size=3]
							0x34, 0x3A, 0x00, 0x00  //the values below[/size][size=3]
						"AAPL,clock-id",   // property needed for sleep support[/size][size=3]
						Buffer (One)[/size][size=3]
							0x0a  [/size][size=3]
							Buffer ()[/size][size=3]
						  "device_type",   //not sure it is useful[/size][size=3]
						  Buffer (0x05)[/size][size=3]

						"AAPL,current-in-sleep",  // to solve a problem with sleep when stick is inserted[/size][size=3]
						Buffer (0x01)[/size][size=3]
					}, Local0)[/size][size=3]
				DTGP (Arg0, Arg1, Arg2, Arg3, RefOf (Local0))[/size][size=3]
				Return (Local0)[/size][size=3]
USB1 - 0x2830[/size][size=3]
USB2 - 0x2831[/size][size=3]
USB3 - 0x2832[/size][size=3]
USB4 - 0x2834[/size][size=3]
USB5 - 0x2835[/size][size=3]
EHC1 - 0x2836[/size][size=3]
EHC2 - 0x283a[/size][size=3]
USB1 - 0x0aa5[/size][size=3]
USB2 - 0x0aa7[/size][size=3]
EHC1 - 0x0aa6[/size]
EHC2 - 0x0aa9


For starters my dsdt starts with USB0 and not USB1

second--- where exactly does 0x2830 go in the code?


totally confusing when you see this


						Buffer (0x04)[/size][size=3]
							0x34, 0x3A, 0x00, 0x00  //the values below[/size][size=3]
						"AAPL,clock-id",   // property needed for sleep support


huh??? Device ID's are 6 digit figures (0x0000) and only one of em.... not 4 x 4 digits... 0x00, 0x00x 0x00, 0x00

The UHCI (1) fix.....??? I suppose I just add the block device code to the end on the the USB devices...as a seperate device....


I have no Device (RTC)



Getting late here and been at this all day again... Will read your reply tomorrow and hopefully get a few more tips... Definitely reckon part of the problem I have is with the correct patching of the USB code... certainly what I had enabled me to dispose of USBBusFix¡yes but I think it also prevented sleep at the same time...


I reinstalled ML and forgot to mention I cannot boot at all with the standard IOPCIFamily.kext... hangs every time at [ PCI config....] Can only boot with Netkas's patched version of it! Tested sleep etc without dsdt and works as expected.... only when I patched the dsdt and added back un the USB code did I replicate the problem of the cpu not shutting off (leading me to think therefore that the USB fix is not correctly done...


Thanks for your help and as mentioned I'll look at things again tomorrow, hopefully with fresh eyes.


For now though I'm going to revert to the no- DSDT setup...


Ps... I did disable firewire in the Bios... but that made things worse... Instead of sleeping sleep sent the cpu into a reboot cycle!


PPS... Thanks again for your help... There's a minefield of information here. I'm gonna down the Everest program and run the SSDT dump and leave it at that for tonight!


Not sure why the c and p states don't show up though...

Link to comment
Share on other sites

It looks like you are meant to replace 0x34 0x3a with 0x28 0x30 for USB0, and so on. I'm not sure, besides some renaming to match what Apple uses, my USB devices are unpatched, they don't need any patching.


The UHCI (1) fix.....??? I suppose I just add the block device code to the end on the the USB devices...as a seperate device....

No, you're confused...read and compare...It's not a device, it's a "method" that goes inside each USB device. Device code say "device", methods say "method"....look under other devices, there are methods...this code must be added the same way as other methods you see inside a device.


But...you're grasping at straws here, you're trying to apply a patch without having the faintest idea what it does or whether you need it or not. You can easily make things worse. Throwing random code at a problem to see what sticks is not productive.


You need to be more specific when looking for information. If you can't be specific, you must improve your knowledge base.


What's the Southbridge on your motherboard? ICH9 or 10?

The USB controller is part of the Southbridge and some of the widespread fixes are for very specific issues with for example the ICH7.

The ICH10 and ICH10R normally don't need any patching. Then again, I have never seen a DSDT from an Intel board.


Post the output from LSPCI -nn and get me an unmodified DSDT from your motherboard. Extract it under Windows using Everest.

Make sure everything i mentioned up in post #2 is enabled in the BIOS prior to extraction. Then zip and attach it.

I ran into an issue with the system clock

Everybody does. The best and most reliable way to fix this is with the "RealTimeIsUniversal" registry edit on Windows that's described here on Prasys' blog: http://prasys.info/2...ith-osxwindows/

Your BIOS clock will be wrong from now on as it's now UTC, but NTP time syncing will work and the time will be correct in Windows and OS X, which is what matters.

I have no Device (RTC)

Yes you do, it just has a different name. Like RTC0 for example.

  • Like 1
Link to comment
Share on other sites



quite right I'm confused.....especially where no such device is listed and the instruction given is "change it with the following...."


Even to be able to get NVidia and on board audio patched I first need to be able to get rid of the USBBusFix altogether...in other words patch the dsdt effectively to support the functions that USBBustFix was compensating for... If I patch just the NVidia and audio parts I ket KP's on reboot Not sure how to explain it otherwise...


I'm attaching the error fixed but unpatched version of my dsdt which I have reverted to for now...


oh well...maybe not...seems attach file doesn't work...


heres the link to it on sendspace then...

Link to comment
Share on other sites

What can I say, file attaching apparently works fine...you had no trouble attaching that screenshot right?


Only certain file extensions are allowed, therefore, as I asked you to do before, zip and attach and it'll work.


I don't like those built-in patches, just look at it...it's called "USB hack". What does that mean? Do you know what it's supposed to fix?


What's wrong with using USBBusFix=y anyway? If it works for you, why can't you use it?


If you really want to fix it in DSDT instead, then find out what exactly USBBusFix=y does and start searching for a way to implement it in DSDT. That's much more specific than inserting a random piece of code called "USB Hack" and then hoping it'll work.


Don't inject your video card via DSDT, DSDT is for on-board devices. Use Chameleon GraphicsEnabler.

Link to comment
Share on other sites

...can only tell you that i zipped dsdt.aml and tried attaching it twice.... no luck so went with sendspcae... No problem with the screenshots though as you correctly mention.


Meanwhile on windows the only tables I can extract are as follow:












... nothing like ssdt or some of the others mentioned...


basically I'd like to have full graphic capability and sound without the need for enablers... I can get graphics now with just GraphicsEnabler=yes but have no idea if I am getting GPU support phys x and acceleration... dropped the nvenabler as it was problematic...

Link to comment
Share on other sites

Yeah, everybody does. The best and most reliable way to fix this is with the "RealTimeIsUniversal" registry edit on Windows that's described here on Prasys' blog: http://prasys.info/2...ith-osxwindows/

Your BIOS clock will be wrong from now on as it's now UTC, but NTP time syncing will work and the time will be correct in Windows and OS X, which is what matters.

Fixed that long ago.... that was always a case of just a standard differenct to GMT by something like 6 hours or so... what I ran into yesterdat was an hour and 40 minutes,,, on the next boot 2 hours and 12... totally random.... a real mess...


Off to bed here but if I could find a way (ANY way) of getting sleep to work properly I'd take it.


just went back into the test install and disabled firewire... with an unpatched dsdt and with USBBusFix=yes... clicked on sleep.. In this mode themachine does indeed seem to sleep.... but...no way of waking it...shook the mouse, clicked hit the power button... all I could do was hold down the power button and reboot!


WIth firewire on... you already know what's happening... cpu being prevented from sleeping by (apparently) firewire...


clearly USBBusfix fails when the machine is in sleep mode..


with what was obviously a poorly coded USB fix in the dsdt... with firewire disabled the machine went into reboot on wake...


with firewire enabled I could wake it but it never went to sleep properly in the first place... and again it seemed the firewire was the issue... so you can see from this the USBBusFix works... but not for sleep....(at least with firewire disabled on an un patched DSDT).


I'm guessing that if I can get the USB part of the dsdt correctly coded and the EHCI and UNCI fixed properly the battle would be half won at least!



Oddly enough I had a pretty messy install last week and got kp's etc and hangs on boot maybe 8 times out of 10... but when I was in the system it slept perfectly!!!


Now I have it booting 1st time, every time but cannot get it to sleep! Frustrating as hell! Really frustrating - it's the one thing keeping me from the perfect hack imo,,,


everything else works perfectly (need to customize my AppleHDA.kext though for surround and HDMI). remote with eHome Infrared Transceiver via mira and my remote from the iMac... Logitec Webcam... no issues at all... Shame theres no fix for the Audigy SE though! Not using wifi at the moment so have not tested airport..


But the sleep fix.... fix this and it also fixes MY sleep... damned fans run all night without it!

Link to comment
Share on other sites

I can probably help you but I need you to do what I asked for in post #6.

I have no problems attaching files, for example here's the same DSDT you uploaded to sendspace.
DSDT.aml.zip (no need to download, I didn't do anything to it)
No idea why you can't attach it.

You have no SSDT tables because the code that's usually in SSDT is located at the end of your DSDT inside the processor scope.


PhysX is Windows only, forget about that. To test for working Graphics Acceleration run an OpenGL benchmark or a game, look for water ripple effect when using dashboard, see if your menu bar is transparent etc.

For your Audigy card, try the OS X version of the kxproject driver. I don't know if there is a 64-bit version though, I haven't looked at it in a long long time.

Link to comment
Share on other sites

Tried the kxproject - thats why I mentioned it... Various models of Audigy 2 are supported but not SE! Killer!


phys-x as far as I know does work on Mac but I believe it's in a sort od beta stage. Look at ferals Batman - Arkham Asylum for example - phys.x game


On Mountain Lion there is no ripple effect in Dsahboard... when you go to add a widget though, if you hold down the opt key the available widgets wiggle...(not sure if thats the same thing...) In SL thoughI certainly have the ripple effect you mention.. The menu bar is transpatent though


I did something last night before going to sleep... Used the DSDT extracted from WIndows as opposed to Mac... The difference there is that the win extract shows 62 optimisations as opposed to 41... but what these are I have no idea. USB enablement was not one of them as I had to enable the fix


Sorry ..missed the request....


Here's the new DSDT with only 2 warnings fixed and no mods... (I'll post the

LSPCI later)


Once again I cannot attach a zip file - so here's the Sendspace Link


,,,and I'm not hallucinating... (tried attaching it 4 times...)



................. >>>>




Finally.... attached them using the advanced flash uploader...

Link to comment
Share on other sites

amls.zipIOReg.ziplspci report.zip


Other files you might find useful - IOReg report and amos, You're right the lspci program looks very useful. Haven't seen that information since I first tried to install a hack!!!!


Thanks again for your help with this... it's an itch I've been scratching for a few years at this stage....

Link to comment
Share on other sites

Dude you have NullCPUPowerMangement and Sleepenabler.kext installed. If you want native power management working you can't be using those. I already mentioned NullCPUPM in post #2, please pay attention.

Screen Shot 2012-08-23 at 11.09.13 PM.png

Screen Shot 2012-08-23 at 11.09.02 PM.png


Try this DSDT: [attachment removed]

Did some device renaming, removed fixed IRQs, Darwin OSVR, removed UAR1 code and fixed two compiling errors. There is still more to do.

Remove sleepenabler and NullCPUPM, reboot, zip and attach your /Extra/org.chameleon.Boot.plist and get me a new ioreg dump as well so I can track my changes and see what else might be needed.


I looked into PhysX. It appears that on OS X PhysX runs on solely the CPU, it does not use the GPU at all.

If you are able to play Batman Arkham Asylum (great game btw, finished it twice myself) on your Hackintosh with reasonable framerates (or any other game really) then hardware accelerated graphics are working.

The differences you're seeing in number of optimizations are due to different IASL versions used to compile the DSDT.


with firewire disabled the machine went into reboot on wake...

Patch AppleRTC.kext with this perl script:


Link to comment
Share on other sites

Thanks Man, You rock...! =)


Just checked the test environment... You're dead right about SleepEnabler.kext but I don't have NullCPU installed either on that partition or this one...


Will give the dsdt a shot and report back...


BTW do you know id Arkham City works in Wineskin or not? Haven't gotten round to looking at porting it yet! Thankfully a good many of My PC games port pretty well as long as .Net framework or VCredist isn't required... (another discussion for another day perhaps...)


Stand by...

Link to comment
Share on other sites

... As directed...


1) took out SleepEnabler.kext - NullCPU was most definitely not there...

2) ran the perl patch (something I tried previously) though had to change the directory as my AppleRTC.kext is in S/L/E not in E/E (simply done with drag and drop!)

3) replaced the dsdt.aml with your edited version



On reboot discovered the mouse wouldn't budge and no keyboard... rebooted with USBBusFix=yes and immediately updated org.chameleon,boot.plist with this...


tried sleep... much the same result though.


Monitor shuts off and even after 3 minutes the cpu still humming away so I 'woke' the monitor and took the IOReg snapshot as requested!


Here you go.... Admin’s Mac Pro.zip


Gotta have an early night here batteries need some serious recharging! Just hope I wont have as much trouble as I'm having with the hack on that score,,,, ;) Sleep!!! (Some people sleep to dream....while others dream about getting sleep working! Ironic, eh????)




PS. Not sure why your screenshot is showing NullCPU... even did a search for it with Alfred... nowhere to be found.... AppleIntelCPUPowerManagement diluted somehow??? Have not touched this kext since the fresh install.... experimented with a patched version of it prior to the fresh instal though...




Link to comment
Share on other sites

Place this new DSDT in extra and trash the other one I gave you. I tried to fix your Firewire this time.

(attachment removed)

There is more to do.


I need you to install bdmesg so we can see diagnostics messages from Chameleon.

Extract this to your desktop: bdmesg.zip

In Terminal, type cp ~/desktop/bdmesg /usr/bin


Now reboot.


Fire up Terminal and enter

bdmesg > ~/desktop/bdmesg.txt


kextstat -k > ~/desktop/kextstat.txt


Locate bdmesg.txt and kextstat.txt on your desktop.

I need to see an ioreg dump with the new DSDT loaded so I can track my changes - zip and attach kextstat, bdmesg and ioreg.


The screenshots I posted are from your ioreg and it is showing NullCPUPM because it is running on your system, simple as that.

You must locate it and delete it before we can continue, I will not be able to help you otherwise.

If you have a file named extensions.mkext in /Extra or /Extra/Extensions, zip and attach it here.


Re: your AppleRTC.kext - you should definitely not be using the same kext in /E/E and /S/L/E.

With UseKernelCache=y set, you should keep all your kernel extensions in /S/L/E.

/Extra/Extensions is only for use during installation and on first boot, post-installation.

Link to comment
Share on other sites



Have to say once again that I really appreciate your time, effort and help on these issues... these new tools, command line reports etc are beyond me... but I did crack open the kextstat report and you were quite right... Nullcpu was listed there... found the culprit too - MyHack.kext. (I know I used that tool building the initial base install for ML which I backed up and use for reinstalls... I thought I had removed it when I installed this time but apparently not... but gone now!!!


Just to clarify: I did use an E/E and S/L/E Setup without kext cache prior to cleaning up my install per rockinrons thread...No E/E now, conflicting kexts etc... and for that the system at least starts first time, every time now... Extra now only includes Dsdt.aml. smbios.plist, org.chameleon.Boot.plist and the Themes folder...


Here are the reports you requested... rebooted the system and tried sleep after removing the offending kext and rebuilding the cache... but still not sleeping at this stage... as obviously firewire is the main obstacle...



Link to comment
Share on other sites

Umm, I could't read too much past the first DSDT patching post, but why are you thinking USBBusFix=Yes a bad thing? When added to org.chameleon.Boot.plist you don't have to type it every time. Now my DSDT is edited for USB, but I still use Bus fix because it boosts all benchmark scores by almost 10%. I have confirmed the same behavior on every x58 system where I was able to convince the owner I'm not crazy and to try it. Only one core 2 duo owner I know has tried and it also worked for them. So I doubt it would hurt.

Link to comment
Share on other sites


I asked him the same question earlier. Anyway he has ICH10, which shouldn't need USBBusFix (Which he did add to his Boot.plist btw).

I'm trying to fix it in DSDT. Thanks for the info about the performance boost, I'll try it and let you know. (P45/Core 2 Duo).



The BIOS screenshots unfortunately don't show anything useful (to me at least). You can disable the serial port if you're not using it.

Please take photos of what's inside "Memory configuration" and "PCI Express configuration".


While taking a close look at your bdmesg output I found that you appear to have two /Extra folders:

Read HFS+ file: [hd(0,2)/Extra/Themes/Blackosx_Button/text_scroll_next.png] 795 bytes.
Read HFS+ file: [hd(0,2)/Extra/Themes/Blackosx_Button/font_console.png] 5562 bytes.
Read HFS+ file: [hd(0,2)/Extra/Themes/Blackosx_Button/font_small.png] 27435 bytes.
Read HFS+ file: [hd(1,3)/Library/Preferences/SystemConfiguration/com.apple.Boot.plist] 232 bytes.
Read HFS+ file: [hd(1,3)/Extra/org.chameleon.Boot.plist] 826 bytes.
Read HFS+ file: [hd(1,3)/Extra/dsdt.aml] 19741 bytes.

One on your system drive: hd(1,3) and one on another drive: hd(0,2)


Please use only one /Extra folder.


Try this: dsdt.aml.zip


Device renaming and IRQ removal

Corrected order of _ADR and _UID under PCI0

Removed all PS2 device and related code

Removed UAR1 code

Set Darwin OSVR (not 100% sure that I'm setting it in the right place though)

Added Method DTGP

Added Firewire device under P0P2

Added standard Intel HDEF device

Added SBUS device

Fixed compiling errors

First attempt at fixing USB


Boot with USBBusFix=n and let me know if it works without it. Try sleep.

What are you using for sound? btw If you have a HDAEnabler.kext you can delete it now.

Attach your smbios.plist.

As before, please attach an ioreg dump with the new DSDT loaded so I can check if I did something right :whistle:

Link to comment
Share on other sites

Hi Gringo...


First the issue of the 2 Extra folders... On occasion the bootloader has given me problems and I have to boot directly from another disc...ie. on chameleon if I chose snow leopard (not as my main partition) i could not boot.... If I chosos F10 and then that drive and it has a dsdt, extra folder etc and boot directly I can get in (in otherwords its a failsafe)


Will let you know how I get on ...


- Should I not have one Extra file for each installation of OS X...???




Think I mentioned it in this thread orrockinrons basic dsdt thread that basically I cannot boot without USBBusfix=yes. In one such scenario trying to get sleep working for example,,, I was unable to get back into the Desktop - even with USBBusFix=yes... However with a patched (and not even correctly patched) USB fix in the dsdt I was able to,,, Ultimately I would love to have this fixed in the DSDT as when running multiple versions of OS X (e.g. Lion, Snow Leopard and Mountain Lion) it saves a lot of hassle having to load it every time,,,

Link to comment
Share on other sites

Zipped up the Extra folders on my main ML drive and SL drive and deleted the folders...

unchecked USBBusFix

replaced dsdt.aml....



Mouse wouldn't budge and no response from keyboard (ie USB patch did not work....) rebooted again with USBBusFix=yes


NO AUDIO... No Output devices found... running on AppleHDA.kext... replaced this with Toleds's Sculpty Geese's Realtec 888 kext for DSDT enabled... same result...


I am able to get that much working here myself though. Had it working fine before... with the HDA addition to the Graphics Info in the DSDT... However I was not able to get graphics without GrahicsEnabler=yes...


For the time being I am running the non-DSDT HDAEnabler version on the Main Mountain Lion install... On the test install though sound is now NOT working with the new dsdt....

Admin’s Mac Pro.zip


Link to comment
Share on other sites

Okay...if you don't want to do it the right way lol...I've taken out the HDEF device so you can use your patched AppleHDA again.


HDEF device removed

All code for non-existant on-board graphics removed

New USB code and some other fixes (some are fixes for my fixes!) from Olarila (see post below)


Here's a new org.chameleon.Boot.plist and a complete MacPro3,1 smbios.plist (yours was missing stuff and had a misspelling causing one setting to not work)


With this org.chameleon.Boot.plist (npci=0x2000 kernel flag) and DSDT you should now be able to use an unpatched IOPCIFamily.kext - try it and let me know what happens. Hopefully you've kept a backup of the original.


I don't know if you're aware of this but USBBusfix=y actually applies three different fixes at once, two of them may not be necessary (from Chameleon boothelp.txt):


USBBusFix=Yes - Enable all USB fixes below:

EHCIacquire=Yes - Enable the EHCI fix (disabled by default)

UHCIreset=Yes - Enable the UHCI fix (disabled by default)

USBLegacyOff=Yes - Enable the USB Legacy fix (disabled by default)


Anyway, I've removed USBBusfix=y, it shouldn't be needed anymore with the device ID patches to USB in the attached DSDT.

EthernetBuiltIn=y was missing, added.

Forced C2 and C3, let's see if it works.

EnableHDMIAudio=y set. Nvidia HDMI audio should work unless you need to patch AppleHDA.kext for that.


As always, post an ioreg after applying the above.


About /Extra:

If you have all kernel extensions in /S/L/E on both your OS X installations, then you only need to keep /Extra on the drive/partition that has Chameleon installed on it. It's safe to remove the other one.

Link to comment
Share on other sites


  • Create New...