Sign In
Create Account
36
Some KEXTs use the "device-id" of devices attached to the PCI bus to decide (i) whether to start and (ii) to tweak their behavior depending on the specific device.
This allows some but far from all KEXTs to be tricked into believing that you have hardware that is used by Apple and thus enjoying support from Apple's drivers.
In this tutorial, I will show how to get boards with USB from the Intel ICH9/-R chip (Intel P35 chipset) to sleep properly by leading the USB KEXTs into believing that it is actually an ICH10-R, which is used in the MacPro4,1. This fix requires Mac OS X 10.5.7.
Note: Automatic sleep after an idle period is not enabled by this fix. This problem is not necessarily even related to USB but might be caused by your DVD drive.
If your computer goes to sleep properly (i.e. all disks and fans completely switched off) but has trouble waking up, this fix may unfortunately not help.
If you have Mac OS X 10.5.5 or earlier, the fix won't change anything. Using it with Mac OS X 10.5.6 is not recommended.
If your computer has an ICH9/-R and can only sleep with slice's USB kexts, this fix should allow you to get sleep with the stock USB drivers from 10.5.7.
What the fix does is it lets the USB kext "recognize" the UHCI devices and enables the proper work-arounds for their quirks (see the "Errata" property of "AppleUSBUHCI" devices in IORegistryExplorer: if it is 0x0, the driver has probably not recognized the device).
To understand what is going on, you may want to install the USB Debug Kit from Apple. Using the supplied KEXTs, you will see at boot that the device is not supported and therefore power manangement is turned off. This results in the well-known behavior of the computer going to sleep only half-way and then requiring a hard reset to get back to life.
Thanks to CycloneFr and THe KiNG for beta testing!
Note: You are using this at your own risk. Tricking drivers into believing the hardware is something it isn't may seriously damage your computer.
The fix itself is quite simple for DSDT standards. However, I assume you are fairly experienced modding the DSDT. Otherwise, you should get your feet wet with some other tutorial.
Using the widely-used patch method "DTGP", we will add a property "device-id" to the UHCI devices in the DSDT. This property will be chosen to match that of the corresponding devices of the ICH10-R used in MacPro4,1.
Note: Do not set the model of your machine to MacPro4,1, as this will cause a kernel panic with 10.5.7. Just set it to MacPro3,1 or leave it at whatever you have used before.
Method DTGP
Ensure you have method DTGP defined somewhere in your DSDT.dsl. You might want to use the DSDT patcher to insert this method by applying one of its many fixes. This tutorial does not cover this. The end result is that you need to have the following code in the right place:
Method (DTGP, 5, NotSerialized)
{
If (LEqual (Arg0, Buffer (0x10)
{
/* 0000 */ 0xC6, 0xB7, 0xB5, 0xA0, 0x18, 0x13, 0x1C, 0x44,
/* 0008 */ 0xB0, 0xC9, 0xFE, 0x69, 0x5E, 0xAF, 0x94, 0x9B
}))
{
If (LEqual (Arg1, One))
{
If (LEqual (Arg2, Zero))
{
Store (Buffer (One)
{
0x03
}, Arg4)
Return (One)
}
If (LEqual (Arg2, One))
{
Return (One)
}
}
}
Store (Buffer (One)
{
0x00
}, Arg4)
Return (Zero)
}
Once you are done with this step and your DSDT.dsl still compiles without errors and warnings (or at least not more than before you touched it), you may proceed identifying the devices we will patch.Identifying Your UHCI Devices
The UHCI devices may be called anything. However, we can identify them based on their addresses, which are given by the line that begins with "Name (_ADR, 0x...). My second UHCI device, called "UHC2", begins like this:
Device (UHC2)
{
Name (_ADR, 0x001D0001)
...
From this value "0x001D0001", you may strip leading zeroes of every block of four figures and obtain "1D,1", which then corresponds to the addresses shown in IORegistryExplorer to the right of the "@" sign, such as "UHC2@1D,1". (IORegistryExplorer is part of XCode Tools, download from developer.apple.com). Limit the view by searching for "UHCI" and you should see something like this:
IORegistryExplorer_UHCI.png 149.3K
7916 downloadsThis way, you should be able to spot the six UHCI devices. Note that there may be more devices in the DSDT that look like UHCI devices (often there are seven), but only six are shown in IORegistryExplorer. Those are the ones we are going to patch.
The corresponding lines from "lspci" are:
00:1d.0 USB Controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #1 [8086:2934] (rev 03) 00:1d.1 USB Controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #2 [8086:2935] (rev 03) 00:1d.2 USB Controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #3 [8086:2936] (rev 03) 00:1a.0 USB Controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #4 [8086:2937] (rev 03) 00:1a.1 USB Controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #5 [8086:2938] (rev 03) 00:1a.2 USB Controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #6 [8086:2939] (rev 03)In the second pair of brackets, you can see the PCI vendor id (8086 for Intel) and the device-id (2934..2939).
For the ICH9/-R, devices UHCI 1...UHCI 6 have the following addresses and device IDs:
UHCI 1: 1D 2934 UHCI 2: 1D,1 2935 UHCI 3: 1D,2 2936 UHCI 4: 1A 2937 UHCI 5: 1A,1 2938 UHCI 6: 1A,2 2939Do not change the names of your devices as the DSDT won't compile anymore if you do.
Only proceed to patching if the addresses of all six UHCI devices match exactly.
Patching the "device-id" of the UHCI Devices
Now, we just add a call to the DTGP method by inserting a few lines of code into every single one of the 6 UHCI devices. The arguments we pass are "device-id", which is the property we want to patch, and then a four-byte buffer that contains the value to assign to the "device-id" property. These buffers are written "back-wards", i.e. the device-id for the UHC2 device of the ICH10-R, which is "3a35", is written as "0x35, 0x3A, 0x00, 0x00"
The code to add to the UHC2 device is:
Method (_DSM, 4, NotSerialized)
{
Store (Package (0x02)
{
"device-id",
Buffer (0x04)
{
0x35, 0x3A, 0x00, 0x00
}
}, Local0)
DTGP (Arg0, Arg1, Arg2, Arg3, RefOf (Local0))
Return (Local0)
}
The device-ids for the six UHCI devices on the ICH10-R are:UHCI 1: 1D 3a34 UHCI 2: 1D,1 3a35 UHCI 3: 1D,2 3a36 UHCI 4: 1A 3a37 UHCI 5: 1A,1 3a38 UHCI 6: 1A,2 3a39The end result of the UHCI devices should look as follows:
Device (UHC1)
{
Name (_ADR, 0x001D0000)
[...]
Method (_DSM, 4, NotSerialized)
{
Store (Package (0x02)
{
"device-id",
Buffer (0x04)
{
0x34, 0x3A, 0x00, 0x00
}
}, Local0)
DTGP (Arg0, Arg1, Arg2, Arg3, RefOf (Local0))
Return (Local0)
}
}
Device (UHC2)
{
Name (_ADR, 0x001D0001)
[...]
Method (_DSM, 4, NotSerialized)
{
Store (Package (0x02)
{
"device-id",
Buffer (0x04)
{
0x35, 0x3A, 0x00, 0x00
}
}, Local0)
DTGP (Arg0, Arg1, Arg2, Arg3, RefOf (Local0))
Return (Local0)
}
}
Device (UHC3)
{
Name (_ADR, 0x001D0002)
[...]
Method (_DSM, 4, NotSerialized)
{
Store (Package (0x02)
{
"device-id",
Buffer (0x04)
{
0x36, 0x3A, 0x00, 0x00
}
}, Local0)
DTGP (Arg0, Arg1, Arg2, Arg3, RefOf (Local0))
Return (Local0)
}
}
Device (UHC4)
{
Name (_ADR, 0x001A0000)
[...]
Method (_DSM, 4, NotSerialized)
{
Store (Package (0x02)
{
"device-id",
Buffer (0x04)
{
0x37, 0x3A, 0x00, 0x00
}
}, Local0)
DTGP (Arg0, Arg1, Arg2, Arg3, RefOf (Local0))
Return (Local0)
}
}
Device (UHC5)
{
Name (_ADR, 0x001A0001)
[...]
Method (_DSM, 4, NotSerialized)
{
Store (Package (0x02)
{
"device-id",
Buffer (0x04)
{
0x38, 0x3A, 0x00, 0x00
}
}, Local0)
DTGP (Arg0, Arg1, Arg2, Arg3, RefOf (Local0))
Return (Local0)
}
}
Device (UHC6)
{
Name (_ADR, 0x001A0002)
[...]
Method (_DSM, 4, NotSerialized)
{
Store (Package (0x02)
{
"device-id",
Buffer (0x04)
{
0x39, 0x3A, 0x00, 0x00
}
}, Local0)
DTGP (Arg0, Arg1, Arg2, Arg3, RefOf (Local0))
Return (Local0)
}
}
Have fun patching.Verifying the Reliability of Sleep
You need to be aware that if your machine has never slept before, you may encounter surprises when using sleep now that it works. In order to be able to attribute any issues you may experience to sleep, I strongly recommend a thorough burn-in procedure.
First, unplug all USB devices that you do not need, in particular any storage devices.
Then, in all the applications you typically use, open a few documents and leave them open.
Now put the machine to sleep at least a hundred times and wake it up afterwards.
This sounds like a big hassle, but if you have a second computer that is capable of doing all the work, it's not that bad. Using the PHP script below allows you to remotely sleep and wake up your machine any number of times without human intervention.
sleep_wake.php.zip 1.51K
1001 downloadsYou need to edit the variables "$target", "$hwaddr" and "$login". Run the script with one argument, e.g.
/path/to/sleep-wake.php 100will sleep and wake up your machine 100 times.
Note that for wake-up to work, UDP port 9 must be open. For sleep to work, SSH needs to be enabled and you need a public key installed on the target in order to allow automatic login. How to achieve this is outside the scope of this tutorial.
Do you know any other Intel chipset that supported by (10.5.7) vanilla kext? I have ICH7 chipset, maybe I can try this trick to get sleep working.
