Sign In
Create Account
2
Some members of this board much more knowledgeable than I am have traced the problem to an IRQ conflict between the HPET and the USB ports. A number of solutions have been offered, but the only one that worked for me was using an alternate IOPCIFamily.kext made by Slice. This worked perfectly fine, however I couldn't resolve myself to consider this as a permanent solution, simply because I want my hack to be has much "vanilla" as possible, therefore avoiding all the problems caused by system updates.
Let me point out that my machine is an HP Pavilion DV5-1157ca (which overall isn't too bad as a hackintosh), but the fix explained therein may also apply to other types of board, albeit with some adjustments.
A little investigating using IORegistryExplorer allowed me to figure out that my UHCI and EHCI ports that were most often disabled required use of IRQs 0x14 and 0x15. The HPET, however, requires four interrupts, even though only two are specified in the DSDT.
Device (HPET)
{
Name (_HID, EisaId ("PNP0103"))
Name (BUF0, ResourceTemplate ()
{
IRQNoFlags ()
{0}
IRQNoFlags ()
{8}
Memory32Fixed (ReadOnly,
0xFED00000, // Address Base
0x00000400, // Address Length
_Y10)
})
...
Note that even though the DSDT specifies interrupts 0 and 8, IORegistryExplorer shows that the HPET always seems to use interrupts 2 and 8. However, that didn't seem to conflict with other devices also using one of those two interrupts.However, in addition to these interrupts, the HPET always seemed to use two others. Sometimes these were 0x0B and 0x17, which didn't cause any problem with my USB ports.
The problem is that sometimes, the HPET was hijacking IRQ 0x14 or 0x15, sometimes both, and it seems to use these interrupts exclusively, therefore preventing USB ports normally using these same IRQs from working properly.
Many suggestions were offered to solve this problem. Some suggested changing the IRQ numbers defined in the HPET device section of the DSDT, some suggested removing them altogether, or altering or removing IRQ numbers in other device's sections. I tried all these fixes, to no avail.
Finally I realized that the problem came from the fact that the HPET device seemed to randomly choose values for the two IRQs that it requires in addition to the two specified in the DSDT. So I said to myself "Well, the HPET device wants four IRQs ? Fine, I'll give it four IRQs".
I started by changing the {0} code by {2}, since the HPET always seemed to use this interrupt anyway. Next, I added two more IRQNoFlags sections specifying the values 11 (0x0B) and 23 (0x17), the two values it was using on the rare occasions when everything worked fine. However, IASL gave me an error that the only acceptable values for IRQNoFlags were between 0 and 15. Fine. Hunting through IORegistryExplorer for an unused interrupt number between 0 and 15, I found out that values 0x0E and 0x0F were not used by any device.
So I decided on 0x0F and altered my DSDT in the following way:
Device (HPET)
{
Name (_HID, EisaId ("PNP0103"))
Name (BUF0, ResourceTemplate ()
{
IRQNoFlags ()
{2}
IRQNoFlags ()
{8}
IRQNoFlags ()
{11}
IRQNoFlags ()
{15}
Memory32Fixed (ReadOnly,
0xFED00000, // Address Base
0x00000400, // Address Length
_Y10)
})
...
I recompiled the DSDT, replaced it in my /Extra folder, replaced Slice's IOPCIFamily kext by the vanilla one, rebooted, and...Bingo ! No more "unable to get filterInterruptEventSource" errors, all the USB ports work perfectly. I rebooted several times to confirm that this was not a freak occurrence, and I can confirm that this fix permanently solves the IRQ conflict between the HPET device and USB ports. I can now use vanilla IOPCIFamily.kext on my machine and not worry about the next Snow Leopard update.
