4 replies to this topic

[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.insanelym...howtopic=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
							)
					})

 Fixed_HPET_ioreg.jpg   70.73K   1066 downloads

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   23.41K   393 downloads

[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]

XLR, on 05 January 2012 - 03:30 PM, said:

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 */
				}