Laqk Posted January 8, 2010 Share Posted January 8, 2010 Like many here I've been plagued by this dreaded error message that prevented some or all of my USB ports from working correctly. The problem was intermittent on Leopard, but now since I started using Snow, it happened in about 19 out of every 20 reboots. 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. 1 Link to comment Share on other sites More sharing options...
hchinasky Posted January 16, 2010 Share Posted January 16, 2010 I´ve been testing your patch for some days and it seems to work perfect in my laptop. All usb ports work well and shutdown and restart quickly. Thanks for share it. Link to comment Share on other sites More sharing options...
kidamnesiac Posted January 18, 2010 Share Posted January 18, 2010 so that what's called sharing knowledge... solved my plagued system too anyway my laptop is almost the same as yours so... hundreds thanks from here.. kidA Link to comment Share on other sites More sharing options...
camdenbloke Posted February 5, 2010 Share Posted February 5, 2010 I´ve been testing your patch for some days and it seems to work perfect in my laptop. All usb ports work well and shutdown and restart quickly. Thanks for share it. Many thanks from here too. Had exactly the same problem and been wrestling with DSDT editing for about 2 months now! Problem strangely seemed to get worse too, until until it was almost impossible to get a clean boot. Dell Inspiron 1720 here, but guess architecture is similar - C2D CPU, ICH chipset etc. Ironic that all the guides tell you to remove interrupt declarations from the DSDT, where as what it actually needs is a couple of extra ones added. Andy Link to comment Share on other sites More sharing options...
dejangs Posted April 27, 2010 Share Posted April 27, 2010 Can someone plz upload a working dsdt.aml for HP DV5 1130ev or similar model? Thanks a lot. Link to comment Share on other sites More sharing options...
miqlas Posted November 16, 2010 Share Posted November 16, 2010 Thanks, man! It works perfectly! Link to comment Share on other sites More sharing options...
DukeRaoul Posted November 20, 2010 Share Posted November 20, 2010 Laqk Thanks for posting this info - finding your guide with Google allowed me to fix my Firewire issue. Since you don't have Firewire mentioned here, I'm going to make a new topic to help people with similar Firewire issues like mine and link to your fix here. My main purpose is to make a more noob(ish)-friendly guide, explaining the ioregistryexplorer use to find the free IRQ's needed, etc. Many folks have postings on this board and the other Project site with their "Unable to list Firewire devices" woes, but they are just resorting to hacks like deleting AppleHPET.kext which is not good. Thanks again! Link to comment Share on other sites More sharing options...
DukeRaoul Posted November 20, 2010 Share Posted November 20, 2010 OK, I have created a guide based on this DSDT patch to the HPET IRQs to fix Firewire problems, with more about how to use IORegistryExplorer and manage the IRQs with DSDT. AFIK, all credit goes to Laqk for finding this fix, but if someone else posted elsewhere I couldn't find it. So thanks again, and I linked my post to this one. My post on Firewire - HPET - DSDT fix is here: http://www.insanelymac.com/forum/index.php?showtopic=237750 Link to comment Share on other sites More sharing options...
cristian arenas Posted August 5, 2011 Share Posted August 5, 2011 Well done; I worked in dsdt of my asus p5g41t-m, everything worked fine. But I probe your edits, its interesting. Thank for your post! Link to comment Share on other sites More sharing options...
liujianwei Posted June 18, 2015 Share Posted June 18, 2015 This is good,my USB random stop work,before this post I think it's hardware problem,now I use your patch and it works,I hope it fix this problem. No,your patch is not needed for me.In fact my USB device is bad,unplug problem solved. Link to comment Share on other sites More sharing options...
Recommended Posts