Fix for Firewire and HPET IRQ conflict using DSDT

[DukeRaoul]

After a few days of hard work/research, I fixed my Firewire by changing the IRQ's that the HPET device uses in DSDT. Primary credit for this info goes to Laqk for defining the method to do this for USB and SATA conflicts with the HPET (HPET steals the other devices' IRQ's a lot).

Some folks have attempted to fix this issue by deleting AppleHPET.kext, but that isn't necessary with this fix.

 

Prerequisites: working DSDT and knowledge of editing it, plus use of IORegistryExplorer

 

Here is Laqk's guide to patching the HPET's IRQs in DSDT:

http://www.insanelymac.com/forum/index.php?showtopic=206313

 

That's what you do to fix your Firewire. Basically, you have to free up some IRQ's that the HPET is using so Firewire can have one.

First get IORegistryExplorer and look at your HPET device, and locate the Property called "IOInterruptSpecifiers" - this is what I believe are the IRQs for each device. Click the arrow to see the values under it. You will probably see either 2 or 4 sets of data values, which are the IRQs that HPET is using in OSX. Mine has 4 values, but my DSDT only specified 2 values with "IRQNoFlags". My DSDT specified 0 and 8, but in IORegistryExplorer HPET was using (hex values) 08, 14, 0b, and 0c which are IRQs 8, 20, 11, and 12 in decimal format as DSDT uses.

So DSDT is trying to get HPET to use IRQs 0 and 8, but 0 already got used by something else, so 8 was the first it got, then it went somehow to 20, then 11 and 12. The high value of 20 took over the spot for Firewire in my case.

 

Now to find free IRQs to substitute into DSDT....

Using IORegistryExplorer, search for your IRQs by entering "iointerruptspecifiers" into the Search bar up top (you may need to expand the search options with the little funny button to the right, just check all the boxes to search more areas). This should show all the areas (devices) in bold that have a Property "IOInterruptSpecifiers" so that you can see what IRQs are being used by OSX. This is a tedious process, but I opened Textedit and copied down each device name and the hex value for its IRQ. IOreg shows the hex values like this: <09 00 00 00 05 00 00 00> ... and I just looked at the first 2 numbers (09) to find the IRQs - comparing this to the IRQs defined in DSDT seemed to validate this, mostly. I honestly don't know what the other numbers after the first 2 are about. For now, just ignore them, and maybe somebody more knowledgeable will come along to enlighten me.

See the attached file below for my IRQ scratch-pad (RTF document, needs downloading to view properly). One problem I ran into was the IDE1 device appears to be using every IRQ from 0 to 16, plus 19 (13 hex). I chose to ignore that and take the risk of assigning some it had, only if no other device used it. My reasoning was to hope that it couldn't possibly use them all, and that it was some kind of placeholder thing.

Basically, from my listing of used IRQs, I found that 3, 5, 7, 10, 14, and 15 were free IRQs except for being "used" by that IDE1 device that I chose to ignore. In my DSDT, there were originally several other things claiming several IRQs at once, like LPT and ECP parallel ports. I deleted the entire sections related to PS2M, PS2K, LPT1, and ECP1 to free up the IRQs since I don't use those ports. Deleting other things in DSDT that claim IRQs will also help this process, but be sure that it's not something you need in there!

 

To fix up the HPET's IRQs in DSDT, I used Laqk's method to increase the "IRQNoFlags" entries from 2 to 4, and I tried to match them up with the values shown in IORegistryExplorer as closely as possible while remaining under IRQ #16 (iasl won't let you go over IRQ 15). DSDT was showing 0 and 8, and 8 was the first to be used by OSX for HPET, so I changed the first DSDT IRQNoFlags entry to 8 instead of 0. Then I went up from there to the next one, 0b hex / 11 decimal for DSDT, then for the next entry I used the next higher shown in IOreg, 0c hex / 12 dec. The other IRQ used by OSX was 20 (14 hex), but you can't go that high in DSDT, so I used the highest free IRQ of 15.

 

This is what I ended up with for my HPET entry in DSDT, after all of that procedure above:

 

 Device (HPET)
               {
                   Name (_HID, EisaId ("PNP0103"))
                   Name (ATT4, ResourceTemplate ()
                   {
                       IRQNoFlags ()
                           {8}
                       IRQNoFlags ()
                           {11}
                       IRQNoFlags ()
                           {12}
                       IRQNoFlags ()
                           {15}
                       Memory32Fixed (ReadWrite,
                           0xFED00000,         // Address Base
                           0x00000400,         // Address Length
                           )
                   })

 

 

After compiling the AML and rebooting, the Firewire is working. Same after sleep/wakeup, reboot, etc.

Looking into IORegistryExplorer now shows that Firewire is using IRQ 20 that was previously used by HPET. And the HPET is now using the 4 IRQs defined for it in DSDT.

It may be important to note that it didn't work the first time I tried changing the HPET IRQ values in DSDT - I first used the first "free" IRQs in order I found them (3, 5, 7, and 10). It worked when on the 2nd try I changed the IRQNoFlags 4 values to closely match what IORegistryExplorer had before. Originally 08, 14, 0b, 0c (hex) from IOreg -----> into 08, 0b, 0c, 0f after DSDT change to 08, 11, 12, 15.

 

HW specs relevant:

 

GA-EP43-UD3L motherboard

SD-LUC-4F-G firewire PCI card

 

Apologies if this guide is hard to read or understand - it's hard to explain!

 

IRQs_in_use.rtf

[hoyanf]

Nice find DukeRaol,

 

I'll give it a try on my P55-UD6.. Good job...

[smolniy]

I've spent quite a time trying your guide but unfortunately my attempts were fruitless. Neither combination of free IRQ's worked for me. I mean I didn't try them all but about 12 combinations were tested. Still no FireWire

[XLR]

Does it has anything to do with the famous error in kernel.log : "FireWire runtime power conservation disabled. (2)" ?

[pere]

Does it has anything to do with the famous error in kernel.log : "FireWire runtime power conservation disabled. (2)" ?

 

Nope, the firewire fix is this:

 

Locate Scope (_GPE), add this on the end.

Method (_L1A, 0, NotSerialized)  /* <-- Added for firewire  */
{
Notify (\_SB.PCI0.PCIB.FRWR, 0x00)
Notify (\_SB.PWRB, 0x02)
}

 

 

Locate your Firewire device (or create it with this code if it doesn´t exist)

		    Device (FRWR) /*Add all this code if you don´t have firewire device on DSDT*/
		    {
			    Name (_ADR, 0x00070000)
			    Name (_GPE, 0x1A)
			    Method (_DSM, 4, NotSerialized) /* Add from here if you already have a firewire device on dsdt*/
			    {
				    Store (Package (0x02)
					    {
						    "fwhub",
						    Buffer (0x04)
						    {
							    0x00, 0x00, 0x00, 0x00
						    }
					    }, Local0)
				    DTGP (Arg0, Arg1, Arg2, Arg3, RefOf (Local0))
				    Return (Local0)
			    }	 /* End of code if you just add to a existing firewire device */
		    }

[jvamos]

Hey all,

 

Having an issue with the GA-EP45T-DS3R as well. I think IRQs are to blame. I am not versed in machine language and edited my HPET IRQs but the firewire card seemed to still have issues. As well my ilok is giving me grief which I suspect is and IRQ conflict with my USB controller. The board is great for audio and I think if we were able to work it out it would still be a great boon to audiophiles out there. I tried the edit pere had suggested above but could not complile it due to errors where it said an object did not exist. I checked all my device names and they did seem to be present in other parts of the DSDT.  I am really not sure how to debug this issue. I am thinking about buying another PCI based USB card but it's a pain considering the board has everything I need in it. The iLok is the only authenticator that doesn't work as my eLicenser has no issues. I am willing to take the whole week to fix this issue. If you could lend a hand and understand machine language and the fairly dense principles of DSDT editing it would be greatly appreciated. 

[Gringo Vermelho]

You're being terribly non-specific about your compiling error and that makes it difficult to help you.

 

I don't like guessing but I'll make an exception: You must add the standard DTGP method to your DSDT if you want to use Pere's code, it refers to the DTGP method and will not work without it.

 

Are you using a Firewire PCI expansion card? DSDT only contains code for motherboard devices. While it's possible to do, adding code for external devices (such as an expansion card) is against the nature of DSDT and should only be done as a last resort.

Your motherboard manual should have a table that shows which IRQs are assigned to each PCI slot and with what on-board devices they are shared. Refer to this table to decide a better place to plug in your Firewire card, if possible. Also disabling any hardware in the BIOS that you're not using, such as serial- and parallel ports, will free up IRQs.

 

Sometimes it's enough to simply remove all hardcoded IRQs from DSDT. This will allow OS X to assign them at will. This is probably the easiest solution there is, if you're really having an IRQ resource problem. Either way, doing this can't hurt, so try this first. There's an old topic over on ProjectOSX that details this procedure, google "fix for slow SATA drives" or something like that to find it. Note the idea is not to take the code examples from there and paste them into your own DSDT; you need to find the equivalent code that's already in there and then make the changes yourself.

 

Don't plug the iLok into an USB expansion card, use a built-in USB port. Your motherboard has the ICH10 which means, AFAIK, that no USB DSDT edits are required, maybe for improved power management like sleep/wake but not for normal use. Also try to describe what the iLok problem actually is!

You really can't expect anyone to help you with what little information you've provided. Only someone with the exact same issue as you will have any idea what you're talking about.

[jvamos]

Thanks for replying. My apologies for being vague about the issue. Here is the situation as best as I can see it.

 

I am using a Gigabyte GA-EP45T-DS3R with a DSDT made for a GA-EP45T-UD3LR which is a similar board. It works with a vanilla install with all USB (save for the vague iLok issue), onboard NICs, Sleep/Wake, SATA working perfectly. Onboard Firewire is not working however.

 

I have an expansion card just to keep working with the system since firewire is integral to my setup for audio.

 

When I tried Pere's code I refreshed the tree and it seemed to be working as devices showed in the correct format but when compiling I received an error on line 217 of the DSDT

Notify (\_SB.PCI0.PCIB.FRWR, 0x00)

The error in DSDT editor is

Object does not exist (\_SB.PCI0.PCIB.FRWR)

I have not done the DTGP method so you are right about that. I was not aware of injecting that code and have found examples online now.

The iLok issue is odd as the iLok Client can see and update the licenser. But when launching Pro Tools it cannot be found. I am using the eLicenscer without any difficulties though for other DAW software. I have tried all the onboard USB and the issue remains no matter which port it is in.

 

I have disabled the serial ports in BIOS and still cannot get Firewire to cooperate.

 

I have looked throught the user manual but I can't find an IRQ table just some block diagrams and installation instructions.

 

I am removing all instances of IRQNoFlags and will see if that helps.

 

Is it better to use a live disk to extract a new dsdt?

 

Thanks again your help is really appreciated, I am so glad someone answered. Apologies if I left something out. I am fairly new to this side of pc's running OSx

[jvamos]

Removing the IRQs did nothing unfortunately. I think adding the onboard device will be necessary. I did extract the dsdt from aida64 but that didn't work either. I checked out that page on DSDT editing. One more question is the dsdt file case sensitive on booting?

[Gringo Vermelho]

no, you can leave it as dsdt.aml or DSDT.aml, doesn't make any difference. Unless you're (god forbid) using case sensitive HFS, but even then I think Chameleon doesn't care.

 

A great tool to monitor your changes in DSDT is IOJones (it's a replacement for IORegistryExplorer that comes with Apple developer tools). You can see the whole device tree as OS X sees it, assigned IRQs, what driver, if any, is loaded for which device etc etc, it's very helpful, give it a try. /EDIT I read your post again, it seems you're already using IORegistryExplorer..duh

 

Yes it's better to use a live Linux DVD (Linux Mint is good) to extract DSDT, that way you can be sure it's unaffected.

 

Never ever use someone elses DSDT. This may be, at least partially, what's causing your iLok and Firewire issues. Even though it's from another EP45 series board, DSDT contents change depending on BIOS version, amount of memory installed, PCI devices added, BIOS settings such as which CPU features were activated when the DSDT was extracted etc etc. Always extract and patch your own.

 

There is a huge topic in one of the DSDT sub-forums titled "DSDT fixes for Gigabyte boards". It deals with motherboards from the same generation as yours, I'm sure the solutions to most if not all of your issues can be found in that topic. But there's a lot to sift through.

[jvamos]

Ok, wow. Thank you!

[jvamos]

I have extracted a DSDT and applied the patch but I still can see no FRWR device in the newly patched and extracted DSDT. I used a live disk of mint for the extraction. I see all sorts of devices now that I don't think were there before like the TPM chip. Everything seems stable only I still see the

Firewire GUID 000000000000 is invalid!

in console and the onboard firewire is still not working. I thought my own extracted dsdt would be unstable but the patch from the site you listed worked! I am now wondering if I simply need to find a place to change the GUID and add that code into the DSDT to add a firewire device. I am looking into the DTGP method now...

[Gringo Vermelho]

We have a ton of posts about the Invalid GUID issue, unfortunately our own search is not very good, you can use google like this

 

Firewire GUID invalid site:www.insanelymac.com

 

That should get you going.

[jvamos]

I managed to patch the devices as described with the dtgp method but still to no avail.

 

No more GUID errors but no firewire neither. I can see it in linux but not in the resultant dsdt. I think I am just not editing the DSDT correctly. Like the placement of the hacked in edits is probably wrong. I haven't really found anything that sheds new light on the issue. I could try reverting back to another driver from leopard but I want sleep to work.

The only real change is that now when I go to system profiler console shows.

14-02-14 5:13:00 PM    System Profiler[261]    SPFWR ERROR: FireWire bus may be unstable. Other FireWire devices may be present.

Which really doesn't help me much. No sight of anyone fixing firewire with a DSDT edit on the boards that I can find that matches my situation. I really hoped that patching a clean dsdt would have worked.

Alas... untill next week.

 

Josh

[aicragleon]

Anyone know how to get firewire working on an EVGA SR-2? I get the unable to list firewire devices.  I have tried most methods on this page. I have also tried on both 10.8.5 and 10.9.2 with the same result. 

[themacmeister]

My HP XW6600 Workstation is missing HPET and AHCI (according to my Linux DSDT dump). I need to do some serious IRQ patching to get this working. I have edited AppleAHCIPort.kext to use SATA hardware device instead of AHCI, but this is not an optimal solution.

 

If I supply the DSDT and IOReg dump, could someone here make the edits for me pls? I am an absolute newb at DSDT editing. There are DSDT patches available HERE for the XW4600, which is VERY similar to mine.

[Gringo Vermelho]

This topic is about Firewire. Stick to the subject or start a new topic.

 

You can't put your SATA controller into AHCI mode by editing your DSDT, that's not possible.

 

If you're using Chameleon try the ForceHPET=y flag.