Project OS X Forums > Dsdt Solution For Hpet Interrupt Conflicts With Usb, Sata

Full Version: Dsdt Solution For Hpet Interrupt Conflicts With Usb, Sata

Project OS X Forums > Snow Leopard Guides & Tutorials > DSDT Patching

laqk

Jan 10 2010, 03:21 AM

I found what I think is the ultimate solution for the various problems people have been having with the HPET device grabbing interrupts for exclusive use and interfering with various devices like USB and SATA.

In my particular case (I have an HP Pavilion DV5-1157ca notebook), this conflict prevented my two left side (EHCI) USB ports from working almost all the time, and sometimes also my two right (UHCI) USB ports as well. In each case, IORegistryExplorer revealed that the HPET, which always uses four interrupts, had randomly grabbed one or more interrupts that were normaly used by my EHCI/UHCI devices, and refused to share them, leaving my devices non-operational.

I've read various possible solutions from a number of threads about this, but none of them made sense to me. First, IORegistryExplorer clearly showed that HPET always used four interrupts, but only two vere specified in my DSDT. I've read that, for some, their DSDT doesn't even specify any interrupts at all. Furthermore, my HPET always took the first two interrupts as the one specified in the DSDT. It is the last two that were chosen at random and interfered with my USB ports.

So far the only thing that worked for me was to use Slice's IOPCIFamily kext. But I wanted a fully vanilla install so I needed another solution. I then said to myself that if the HPET wanted four interrupts, then I was going to give it four interrupts, but they would be of my choosing. Again using IORegistryExplorer, I looked for two interrupt values below 15 (because IASL complains when you try to use values greater than 15 in IRQ or IRQNoFlag statements) that were unused by any device. I then edited my HPET section in the DSDT from:

CODE

                Device (HPET)
                {
                    Name (_HID, EisaId ("PNP0103"))
                    Name (BUF0, ResourceTemplate ()
                    {
                        IRQNoFlags ()
                            {2}
                        IRQNoFlags ()
                            {8}
                        Memory32Fixed (ReadOnly,
                            0xFED00000,         // Address Base
                            0x00000400,         // Address Length
                            _Y10)
                    })
                    ...

To:

CODE

                Device (HPET)
                {
                    Name (_HID, EisaId ("PNP0103"))
                    Name (BUF0, ResourceTemplate ()
                    {
                        IRQNoFlags ()
                            {0}
                        IRQNoFlags ()
                            {8}
                        IRQNoFlags ()
                            {11}
                        IRQNoFlags ()
                            {15}
                        Memory32Fixed (ReadOnly,
                            0xFED00000,         // Address Base
                            0x00000400,         // Address Length
                            _Y10)
                    })
                    ...

I recompiled the DSDT, rebooted using the vanilla IOPCIFamily kext, and voila ! My system booted perfectly, no error message, HPET and all USB ports fully operational. IORegistryExplorer confirmed that HPET was effectively using the four interrupt numbers that I had explicitly specified in the DSDT.

Since then I've been able to boot into Snow Leopard with the vanilla IOPCIFamily kext with no trouble. I'm on Snow 64-bit, but since the solution is a DSDT patch, I assume it's going to work also for Snow 32-bit or Leopard. Slight modifications of this technique will probably allow anyone to solve their problems of IRQ conflict between the HPET and other devices.

I hope you find this information usefull.

NOTE: Not only does this solution allow you to use vanilla IOPCIFamily, but you MUST use vanilla kext ! After this modification, continuing to use Slice's IOPCIFamily caused my machine to kernel panic either during boot or a few seconds after GUI startup.

yeehaa

Jan 12 2010, 04:03 PM

wow! thanks man. that was nice! i tried to "look" at ioreg and figure out the available IRQs, but that didnt work out well. so took the shortcut and used your exact HPET as i have a similar HP notebook and voila! all's well and now i dont need the patched IOPCIfamily anymore. thanks a lot!

PS: would you mind uploading your "sound solution" and care to mention whether you are booting 32 or 64?

realityiswhere

Jan 13 2010, 12:10 PM

laqk, if you want to take the Quiz then I'll move this to the dedicated DSDT section.

(You wouldn't be able to post in your own thread otherwise heh).

Excellent work

apocolipse269

Jan 13 2010, 04:58 PM

Just as a note, the reason that IASL complains about interrupts over 15 is because 1-15 are reserved for the ACPI and other low level systems. If you'll note, the kernel itself handles interrupts 16 and over, and directs them as necessary. The kernel will classify any interrupts under 15 and under as Error vectors, and handle them appropriately (depending on whether in APIC or LAPIC, and on LAPIC which processor/core the interrupt occurred on, local apic, lapic is resident in each individual core, regular APIC is for all).

Slice

Jan 14 2010, 09:21 PM

Interrups are assinged by system dynamically so you can obtain a conflict later again.

laqk

Jan 16 2010, 07:25 PM

@yeehaa: You're welcome.

@realityiswhere: I took the quiz. Now what ?

@apocolipse269: Thanks for the info.

@Slice: That may be so, but so far I've observed that the system always seems to assign irqs above 0x10 for devices like USB and SATA, so assigning irqs below 0x10 to the HPET in the DSDT should prevent conflict. Of course there is no guaranty of this. Time will tell. However, until Apple get things right and write IOPCIFamily properly (maybe they will take inspiration from your work, who knows ?

), this solution seems to be the best one so far for those of us who want a fully vanilla install.

yeehaa

Jan 17 2010, 05:19 AM

QUOTE (laqk @ Jan 16 2010, 08:25 PM)

@realityiswhere: I took the quiz. Now what ?

now he will move your post to the DSDT forum where it should be!
OT: any info on that sound solution?

Slice

Jan 17 2010, 12:57 PM

My Interrupts

CODE

  +-o MacBook4,1  <class IOPlatformExpertDevice
    |   "IOInterruptSpecifiers" = (<0900000005000000>)
    | |   |   +-o FRWR@9  <class IOPCIDevice
    | |   |   | |   "IOInterruptSpecifiers" = (<1000000007000000>)
    | |   |   +-o CRD1@9,1  <class IOPCIDevice,
    | |   |   |     "IOInterruptSpecifiers" = (<1200000007000000>)
    | |   |   +-o pci1180,852@9,4  <class IOPCIDevice,
    | |   |   |     "IOInterruptSpecifiers" = (<1200000007000000>)
    | |   |   +-o pci1180,592@9,3  <class IOPCIDevice,
    | |   |   |     "IOInterruptSpecifiers" = (<1200000007000000>)
    | |   |   +-o pci1180,843@9,2  <class IOPCIDevice,
    | |   |         "IOInterruptSpecifiers" = (<1200000007000000>)
    | |   +-o USB1@1D  <class IOPCIDevice,
    | |   | |   "IOInterruptSpecifiers" = (<1400000007000000>)
    | |   +-o USB2@1D,1  <class IOPCIDevice,
    | |   | |   "IOInterruptSpecifiers" = (<1500000007000000>)
    | |   +-o USB3@1D,2  <class IOPCIDevice,
    | |   | |   "IOInterruptSpecifiers" = (<1600000007000000>)
    | |   +-o USB4@1A  <class IOPCIDevice,
    | |   | |   "IOInterruptSpecifiers" = (<1400000007000000>)
    | |   +-o USB5@1A,1  <class IOPCIDevice,
    | |   | |   "IOInterruptSpecifiers" = (<1500000007000000>)
    | |   +-o EHC2@1A,7  <class IOPCIDevice,
    | |   | |   "IOInterruptSpecifiers" = (<1600000007000000>)
    | |   +-o EHCI@1D,7  <class IOPCIDevice,
    | |   | |   "IOInterruptSpecifiers" = (<1400000007000000>)
    | |   +-o IDE0@1F,2  <class IOPCIDevice,
    | |   | |   "IOInterruptSpecifiers" = (<1100000007000000>, <0000000000000100>, <0100000000000100>, <0200000000000100>, <0300000000000100>)
    | |   +-o IDE1@1F,1  <class IOPCIDevice,
    | |   | |   "IOInterruptSpecifiers" = (<1000000007000000>)
    | |   |   +-o PRI@0  <class AppleIntelPIIXATAChannel,
    | |   |   | |   "IOInterruptSpecifiers" = (<0e00000000000000>)
    | |   |   +-o SEC0@1  <class AppleIntelPIIXATAChannel,
    | |   |         "IOInterruptSpecifiers" = (<0f00000000000000>)
    | |   +-o HDEF@1B  <class IOPCIDevice,
    | |   | |   "IOInterruptSpecifiers" = (<1500000007000000>,<0400000000000100>)
    | |   +-o SBUS@1F,3  <class IOPCIDevice,
    | |   |     "IOInterruptSpecifiers" = (<1100000007000000>)
    | |   +-o GFX0@2  <class IOPCIDevice,
    | |   | |   "IOInterruptSpecifiers" = (<1000000007000000>,<0500000000000100>)
    | |   +-o RP01@1C  <class IOPCIDevice,
    | |   | |   "IOInterruptSpecifiers" = (<1000000007000000>)
    | |   |   +-o GIGE@0  <class IOPCIDevice,
    | |   |     |   "IOInterruptSpecifiers" = (<1000000007000000>,<0700000000000100>)
    | |   +-o RP02@1C,1  <class IOPCIDevice,
    | |   | |   "IOInterruptSpecifiers" = (<1100000007000000>)
    | |   |   +-o ARPT@0  <class IOPCIDevice,
    | |   |     |   "IOInterruptSpecifiers" = (<1100000007000000>,<0800000000000100>)
    | |   +-o RP05@1C,4  <class IOPCIDevice,
    | |   | |   "IOInterruptSpecifiers" = (<1000000007000000>,<0600000000000100>)
    | +-o PS2M  <class IOACPIPlatformDevice,
    | | |   "IOInterruptSpecifiers" = (<0c00000000000000>)
    | | +-o ps2controller  <class AppleACPIPS2Nub,
    | |   |   "IOInterruptSpecifiers" = (<0100000000000000>,<0c00000000000000>)
    | +-o KBC  <class IOACPIPlatformDevice,
    | | |   "IOInterruptSpecifiers" = (<0100000000000000>)
    | | +-o ps2controller  <class AppleACPIPS2Nub,
    | |   |   "IOInterruptSpecifiers" = (<0100000000000000>,<0c00000000000000>)
    | +-o RTC  <class IOACPIPlatformDevice,
    | | |   "IOInterruptSpecifiers" = (<0400000000000000>)
    | +-o IPIC  <class IOACPIPlatformDevice,
    | |     "IOInterruptSpecifiers" = (<0200000000000000>)
    | +-o COPR  <class IOACPIPlatformDevice,
    | |     "IOInterruptSpecifiers" = (<0d00000000000000>)
    | +-o HPET  <class IOACPIPlatformDevice,
    | | |   "IOInterruptSpecifiers" = (<1700000000000000>,<0b00000000000000>)

All works fine.

realityiswhere

Jan 17 2010, 08:40 PM

topic moved to DSDT section

laqk

Jan 18 2010, 09:45 PM

@yehaa : I use Slice's version of VoodooHDA (Snow Leopard 64-bit version in the russian thread). You'll have to create a sound device section in your DSDT. I noticed that if I name this device AZAL, then AppleHDA no longer tries to drive it and I don't need to delete/disable this kext anymore.

@Slice: I notice that your HPET only uses two irqs. Is that an effect of your custom IOPCIFamily ? I was never able to make my HPET use less than four irqs, even with your custom kext.

@realityiswhere: Thanks.

Slice

Jan 19 2010, 07:12 AM

QUOTE (laqk @ Jan 19 2010, 01:45 AM)

Good trick!

QUOTE

@Slice: I notice that your HPET only uses two irqs. Is that an effect of your custom IOPCIFamily ? I was never able to make my HPET use less than four irqs, even with your custom kext.

No, HPET is not PCI device so it is not influenced by IOPCIFamily. My HPET uses only 2 IRQ because of my DSDT. It is enough for my. Native speedstep with AppleIntelCPUPowerManagement works fine. As well as USB, SATA, sleep/shutdown/restart.

CODE

                Device (HPET)
                {
                    Name (_HID, EisaId ("PNP0103"))
                    Name (ATT3, ResourceTemplate ()
                    {
                        Memory32Fixed (ReadWrite,
                            0xFED00000,         // Address Base
                            0x00000400,         // Address Length
                            )
                    })

                    Name (ATT4, ResourceTemplate ()
                    {
                    })
                    Method (_STA, 0, NotSerialized)
                    {
                        Return (0x0F)
                    }

                    Method (_CRS, 0, NotSerialized)
                    {
                        Return (ATT3)
                    }
                }

                    })

After official BIOS update (www.dell.com) I got new DSDT

CODE

                Device (HPET)
                {
                    Name (_HID, EisaId ("PNP0103"))
                    Name (_CID, EisaId ("PNP0C01"))   // compatible name
                    Name (BUF0, ResourceTemplate ()
                    {
                        Memory32Fixed (ReadOnly,
                            0xFED00000,         // Address Base
                            0x00000400,         // Address Length
                            )
                    })
                    Method (_STA, 0, NotSerialized)
                    {
                        If (LGreaterEqual (OSID (), 0x10))  // Windows XP and high
                        {
                            Return (0x0F)
                        }

                        Return (0x00)
                    }

                    Method (_CRS, 0, NotSerialized)
                    {
                        Return (BUF0)
                    }
                }

yeehaa

Jan 19 2010, 03:26 PM

QUOTE (laqk @ Jan 18 2010, 10:45 PM)

o crap! i tried that long back but used to get random IOHDAFamily KPs. havent tried it with the latest version of Voodoo tho'. n i miss the volume control! slice here will NOT add that feature to his VoodooHDA even tho i requested and linked to a post on insanely 100 times.

ok.. not 100...but still

thanks for the info.. n slice, thanks for the awesome voodoo

laqk

Jan 25 2010, 03:32 PM

QUOTE (Slice @ Jan 19 2010, 02:12 AM)

My HPET uses only 2 IRQ because of my DSDT.

Then you're a lucky man. My HPET ALWAYS uses four interrupts, not matter what I do to the DSDT. Different boards and BIOSes behave differently, obviously.

Since I couldn't do anything about this, that's when I had the idea of chosing (through the DSDT) which interrupts would be used by the HPET to avoid conflict with other devices.

Slice

Jan 26 2010, 01:38 PM

QUOTE (laqk @ Jan 19 2010, 12:45 AM)

In this case I have no sound device in System Profilier. But sound works fine.

laqk

Jan 26 2010, 04:42 PM

QUOTE (Slice @ Jan 26 2010, 08:38 AM)

In this case I have no sound device in System Profilier. But sound works fine.

Indeed, this is an unfortunate side effect. Sound device will appear in system profiler only if it's named HDEF in the DSDT.

But I'm willing to live with it.

drdaz

Apr 28 2010, 07:31 PM

QUOTE (laqk @ Jan 26 2010, 06:42 PM)

Indeed, this is an unfortunate side effect. Sound device will appear in system profiler only if it's named HDEF in the DSDT.

But I'm willing to live with it.

I reconifgured Disabler.kext to block AppleHDA. So if you want to change your sound device name back to HDEF and still use VoodooHDA without deleting AppleHDA, it should work. I've been using it for a few days without issue.

I'm running 32bit 10.6.3, so I don't know if this will work on 64bit.

EDIT: It works fine in 64 bit.

Click to view attachment

gushorty

Jun 24 2010, 05:30 PM

Perhaps a slightly off-topic question, but I notice that your HPET code has "_Y10" in it, while Slice's doesn't. What is the significance of this value/variable/reference/etc? I ask, because I see alot of code with these types of values, but none of my DSDT dumps ever have it.

Psamtek

Jul 9 2010, 08:24 PM

Thanks for the info. This also fixed the USB devices/bluetooth on my NC6400

pyildirim

Jul 22 2010, 09:02 PM

Because I decided to install Mac on my USB disk, this patch is necessary to boot my Mac. But, I always get
CODE
HPET: map device registers failed

and, of course, there is no HPET in my IOreg. I tried assigning 4 (as author suggested), 3 and 2 (even this enables USB) IRQs to HPET, but same message.

Assigning IRQs to 2, 8 and 0 also doesn't work. Btw. I checked my DSDT and it seems that there is no device occupying these IRQs (I removed them from TIMR/PIC/RTC).

Does anybody have a clue why HPET is not loading? How can I see which IRQ's are occupied inside Mac OS (because Windows says that HPET is taking no IRQs)?

Thank you in advance!

EDIT: Well, get Microsoft ASL compiler, then decompile your dump with MSASL, after that try to compile with IASL. It seems that IASL cannot decompile MSASLs code well (because later generates terrible code). After that, as MSASL generates even bad disassembly (for example, "pnop010b" is replaced with hex string, which is bad as HP is not using standard device names, but Cxxx and so on), after fixing errors with IASL decompile your new AML with IASL to get nice error-free DSDT. This also fixed many problems with my devices (including problem stated before).

It's like this:

CODE

// dsdt.aml is your original dump
asl /u dsdt.aml // decompile it with msasl
iasl -ta -vi dsdt.asl // compile with iasl, fix errors and so on
// now we have dsdt.aml which is aml generated by iasl
iasl -d dsdt.aml // decompile again
// now your dsdt.dsl contains nice code

MSASL [Only for windows] http://download.microsoft.com/download/2/c...iler-v4-0-0.msi

dejan_gs

Aug 26 2010, 10:39 AM

Greetings from Greece, this is my first post so....congratulations for your forum and also for this patch and sorry for my poor english.

Well, i want to use this patch but i cant find original (vanilla) IOPCIFamily.kext.
Can someone upload it?

****The reason that i am not satisfied with modified IOPCIFamily is that :

Many times i get Kernel Panics that seems to have to do with AppleACPIPlatform / IOPCIFamily.kext or dependencies. I use IOPCIFamily on System/Library/Extensions for enabling Web Cam and Left USB port. I tried to delete it from Extensions and see what happens but system crashed, not even boot on SL. My laptop is HP DV5 1130ev. Now of course i have recovered my working system with backup restore.

But random KPs remain.

http://img178.imageshack.us/i/p2308101110.jpg/
http://img834.imageshack.us/i/p2308102151.jpg/

Those are the 2 kexts i use.
http://www.mediafire.com/?yhj51zojm9vdky1

Slice

Aug 26 2010, 12:50 PM

You have KP with AppleACPIEC.kext. Are you sure it is compatible with your hardware?

Gringo Vermelho

Aug 26 2010, 02:53 PM

You can use Pacifist to extract IOPCIFamily.kext from an OS X installation DVD or combo update.

dejan_gs

Aug 27 2010, 08:48 PM

Thanks for the replies.

@Slice : to be honest, i have no idea if AppleACPIEC.kext is compatible with my hardware and if i can do anything about that for example patching it, edit some IDs and this stuff.. But i know this kext or IOPCIFamily gives me SOMETIMES Kernel Panic. Not always.

@Gringo Vermelho : i'll try that, thanks.

If someone has something else also in mind about fixing this bug, please let me know.
For now, when i'll find some time i'll use this thread's method and i will inform you if i 'll see some improvement.

dejan_gs

Sep 3 2010, 10:00 AM

Tried with Pacifist to find native kext from Combo Update (10.6.2 and 10.6.3) but no IOPCIFamily found !
Can someone upload the native kext for patching it ?

thx

edit : nevermind, found it !

This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please click here.