tzel2 Posted January 19, 2010 Share Posted January 19, 2010 Thx for teh reply,yes, I did that, but there's no change. My firewire works without any code in DSDT, but I have the power conservation message. When I add the code I see it in IOREG, but it's not working. I'll attach my DSDT.dsl DSDT.dsl.zip So I suppose there's no solution for me yet. Link to comment Share on other sites More sharing options...
SMF Posted January 25, 2010 Share Posted January 25, 2010 I appologize for being slow but ... how do I figure out the address of my firewire from lspci? Mine shows - 05:06.0 FireWire (IEEE 1394) [0c00]: Texas Instruments TSB43AB23 IEEE-1394a-2000 Controller (PHY/Link) [104c:8024] Any pointer would be appreciated. Regards, SMF Link to comment Share on other sites More sharing options...
scrax Posted January 25, 2010 Share Posted January 25, 2010 [104c:8024] vendor id device id the blue one is what you need but reversed so: 0x24, 0x80 Link to comment Share on other sites More sharing options...
SMF Posted January 25, 2010 Share Posted January 25, 2010 scrax, Thanks, I've got that part. What I'm confused about is in red below. Device (FRWR) // Added device for Texas Instruments TSB43AB22/A IEEE-1394A Controller { Name (_ADR, 0x060A0000) // Reported by 'lspci' Regards, SMF Link to comment Share on other sites More sharing options...
LocusOfControl Posted January 25, 2010 Share Posted January 25, 2010 scrax, Thanks, I've got that part. What I'm confused about is in red below. Device (FRWR) // Added device for Texas Instruments TSB43AB22/A IEEE-1394A Controller { Name (_ADR, 0x060A0000) // Reported by 'lspci' Regards, SMF Ditto for me too 09:06.0 FireWire (IEEE 1394) [0c00]: Texas Instruments TSB43AB23 IEEE-1394a-2000 Controller (PHY/Link) [104c:8024] from ex58-ud5 ich10r generic code from first post didn't work so I assume the address is not 0x00070000 Link to comment Share on other sites More sharing options...
MacKonsti Posted January 25, 2010 Share Posted January 25, 2010 I appologize for being slow but ... how do I figure out the address of my firewire from lspci? Mine shows 05:06.0 FireWire (IEEE 1394) [0c00]: Texas Instruments TSB43AB23 IEEE-1394a-2000 Controller (PHY/Link) [104c:8024] Any pointer would be appreciated. Come on guys, it's simple! 05:06.0 = 0x05060000 09:06.0 = 0x09060000 It's always 8-digits! Link to comment Share on other sites More sharing options...
LocusOfControl Posted January 25, 2010 Share Posted January 25, 2010 Come on guys, it's simple!05:06.0 = 0x0506000009:06.0 = 0x09060000It's always 8-digits! Thanks MacKonsti, this address thing has had me confused for several weeks now I'm embarrassed to sayIt half worked withDevice (FRWR) { Name (_ADR, 0x09060000) Name (_GPE, 0x1A) Method (_DSM, 4, NotSerialized) { Store (Package (0x02) { "fwhub", Buffer (0x04) { 0x00, 0x00, 0x00, 0x00 } }, Local0) DTGP (Arg0, Arg1, Arg2, Arg3, RefOf (Local0)) Return (Local0) } } } I now getFireWire (OHCI) TI ID 8024 built-in now active, GUID 00dcaf5700001fd0; max speed s400.rather thanFireWire (OHCI) TI ID 8024 PCI now active, GUID 00dcaf5700001fd0; max speed s400.and no error message. My scanner isn't recognised until after sleep, so bit more tinkering to docheersSteve Link to comment Share on other sites More sharing options...
LocusOfControl Posted January 25, 2010 Share Posted January 25, 2010 Thanks MacKonsti, this address thing has had me confused for several weeks now I'm embarrassed to say It half worked with Device (FRWR) { Name (_ADR, 0x09060000) Name (_GPE, 0x1A) Method (_DSM, 4, NotSerialized) { Store (Package (0x02) { "fwhub", Buffer (0x04) { 0x00, 0x00, 0x00, 0x00 } }, Local0) DTGP (Arg0, Arg1, Arg2, Arg3, RefOf (Local0)) Return (Local0) } } } I now get FireWire (OHCI) TI ID 8024 built-in now active, GUID 00dcaf5700001fd0; max speed s400. rather than FireWire (OHCI) TI ID 8024 PCI now active, GUID 00dcaf5700001fd0; max speed s400. and no error message. My scanner isn't recognised until after sleep, so bit more tinkering to do cheers Steve I tried using callback in PCIB (_ADR, 0x001E0000) but didn't work for me apart from deleting 4 or 5 lines of code I only use firewire for my nikon scanner so not a big deal if my scanner isn't hot pluggable - maybe the scanner needs defining? (quite a lot of detail in there) Prior to sleep this is what ioreg looks like Then straight after sleep/wake turns green then black after powering scanner off then red strike through steve Link to comment Share on other sites More sharing options...
MacKonsti Posted January 25, 2010 Share Posted January 25, 2010 Thanks MacKonsti, this address thing has had me confused for several weeks now I'm embarrassed to say. It half worked with Device (FRWR) { Name (_ADR, 0x09060000) Name (_GPE, 0x1A) Method (_DSM, 4, NotSerialized) { Store (Package (0x02) { "fwhub", Buffer (0x04) { 0x00, 0x00, 0x00, 0x00 } }, Local0) DTGP (Arg0, Arg1, Arg2, Arg3, RefOf (Local0)) Return (Local0) } } } I now get FireWire (OHCI) TI ID 8024 built-in now active, GUID 00dcaf5700001fd0; max speed s400. rather than FireWire (OHCI) TI ID 8024 PCI now active, GUID 00dcaf5700001fd0; max speed s400. and no error message. My scanner isn't recognised until after sleep, so bit more tinkering to do. I also have the same message, funny that you brought it up; I thought I'd seen it change but didn't remember Guys, don't forget to insert the correct callback code in Name (_GPE, 0xXX). It has to be the (_GPE) call notification of the superset device that you've placed (FRWR) into... In my case, (FRWR) was made as a device inside (HUB0) device, so the callback in the firewire code points to the (_GPE) notification of the (HUB0) device, respectively... Study the (_GPE) code carefully, and if say there's an _L09 for you, then the code is Name (_GPE, 0x09) without the "L". This could solve the boot non-detection issues... Please use my code as posted in the previous page, and make sure you don't add or remove anything before reading carefully through the code... Link to comment Share on other sites More sharing options...
LocusOfControl Posted January 26, 2010 Share Posted January 26, 2010 I also have the same message, funny that you brought it up; I thought I'd seen it change but didn't remember Guys, don't forget to insert the correct callback code in Name (_GPE, 0xXX). It has to be the (_GPE) call notification of the superset device that you've placed (FRWR) into... In my case, (FRWR) was made as a device inside (HUB0) device, so the callback in the firewire code points to the (_GPE) notification of the (HUB0) device, respectively... Study the (_GPE) code carefully, and if say there's an _L09 for you, then the code is Name (_GPE, 0x09) without the "L". This could solve the boot non-detection issues... Please use my code as posted in the previous page, and make sure you don't add or remove anything before reading carefully through the code... Do you mean like, I've highlighted what I think are the relevant parts in red - didn't work for me Device (PCIB) { Name (_ADR, 0x001E0000) Method (_STA, 0, NotSerialized) { Return (0x0F) } Name (APIC, Package (0x0C) { Package (0x04) { 0xFFFF, Zero, Zero, 0x10 }, Package (0x04) { 0xFFFF, One, Zero, 0x11 }, Package (0x04) { 0xFFFF, 0x02, Zero, 0x12 }, Package (0x04) { 0xFFFF, 0x03, Zero, 0x13 }, Package (0x04) { 0x0001FFFF, Zero, Zero, 0x11 }, Package (0x04) { 0x0001FFFF, One, Zero, 0x12 }, Package (0x04) { 0x0001FFFF, 0x02, Zero, 0x13 }, Package (0x04) { 0x0001FFFF, 0x03, Zero, 0x10 }, Package (0x04) { 0x0006FFFF, Zero, Zero, 0x12 }, Package (0x04) { 0x0006FFFF, One, Zero, 0x12 }, Package (0x04) { 0x0006FFFF, 0x02, Zero, 0x12 }, Package (0x04) { 0x0006FFFF, 0x03, Zero, 0x12 } }) Method (_PRT, 0, NotSerialized) { Return (APIC) } [color="#FF0000"]Method (_PRW, 0, NotSerialized) { Return (Package (0x02) { 0x0B, 0x05 }) }[/color] Device (FRWR) { Name (_ADR, 0x09060000) [color="#FF0000"]Name (_GPE, 0x0B)[/color] Method (_DSM, 4, NotSerialized) { Store (Package (0x06) { "fwhub", Buffer (0x04) { 0x00, 0x00, 0x00, 0x00 }, "device-id", Buffer (0x04) { 0x24, 0x80, 0x00, 0x00 }, "name", Buffer (0x37) { "Texas Instruments TSB43AB23 IEEE-1394a-2000 Controller" } }, Local0) DTGP (Arg0, Arg1, Arg2, Arg3, RefOf (Local0)) Return (Local0) } } } calling Method (_L0B, 0, NotSerialized) { Notify (\[color="#FF0000"]_SB.PCI0.PCIB[/color], 0x02) } Link to comment Share on other sites More sharing options...
mikeetastic Posted January 26, 2010 Share Posted January 26, 2010 Do you mean like, I've highlighted what I think are the relevant parts in red - didn't work for me Device (PCIB) // changed from HUB0 { Name (_ADR, 0x001E0000) Method (_STA, 0, NotSerialized) { Return (0x0F) } Name (APIC, Package (0x0C) { Package (0x04) { 0xFFFF, Zero, Zero, 0x10 }, Package (0x04) { 0xFFFF, One, Zero, 0x11 }, Package (0x04) { 0xFFFF, 0x02, Zero, 0x12 }, Package (0x04) { 0xFFFF, 0x03, Zero, 0x13 }, Package (0x04) { 0x0001FFFF, Zero, Zero, 0x11 }, Package (0x04) { 0x0001FFFF, One, Zero, 0x12 }, Package (0x04) { 0x0001FFFF, 0x02, Zero, 0x13 }, Package (0x04) { 0x0001FFFF, 0x03, Zero, 0x10 }, Package (0x04) { 0x0006FFFF, Zero, Zero, 0x12 }, Package (0x04) { 0x0006FFFF, One, Zero, 0x12 }, Package (0x04) { 0x0006FFFF, 0x02, Zero, 0x12 }, Package (0x04) { 0x0006FFFF, 0x03, Zero, 0x12 } }) Method (_PRT, 0, NotSerialized) { Return (APIC) } [color="#FF0000"]Method (_PRW, 0, NotSerialized) { Return (Package (0x02) { 0x0B, 0x05 }) }[/color] Device (FRWR) { Name (_ADR, 0x09060000) [color="#FF0000"]Name (_GPE, 0x0B)[/color] Method (_DSM, 4, NotSerialized) { Store (Package (0x06) { "fwhub", Buffer (0x04) { 0x00, 0x00, 0x00, 0x00 }, "device-id", Buffer (0x04) { 0x24, 0x80, 0x00, 0x00 }, "name", Buffer (0x37) { "Texas Instruments TSB43AB23 IEEE-1394a-2000 Controller" } }, Local0) DTGP (Arg0, Arg1, Arg2, Arg3, RefOf (Local0)) Return (Local0) } } } calling Method (_L0B, 0, NotSerialized) { Notify (\[color="#FF0000"]_SB.PCI0.PCIB[/color], 0x02) } not working for me too, the error is gone but i cant plug and mount my mybook FW drive.. if i shutdown and plug it in before ON then it will be detected. am i doing something wrong? please check the code. lspci --nn is showing this 04:01.0 FireWire (IEEE 1394) so ADR is 0x04010000 [color="#0000FF"]Scope[/color] (_GPE) .............. Method (_L0B, 0, NotSerialized) { Notify (\_SB.PCI0.PCIB, 0x02) [color="#0000FF"]Device (PCIB)[/color] { Name (_ADR, 0x001E0000) .......................................... Method (_PRW, 0, NotSerialized) { Return (Package (0x02) { 0x0B, 0x05 }) } [color="#0000FF"]Device (FRWR)[/color] { Name (_ADR, 0x04010000) Name (_SUN, 0x2) // PCI slot 2 Name (_GPE, 0x0B) Method (_DSM, 4, NotSerialized) { Store (Package (0x06) { "device-id", Buffer (0x04) {0x23, 0x80, 0x00, 0x00}, "fwhub", Buffer (0x04) {0x00, 0x00, 0x00, 0x00}, "name", "Texas Instruments TSB43AB22 IEEE-1394 Controller" }, Local0) DTGP (Arg0, Arg1, Arg2, Arg3, RefOf (Local0)) Return (Local0) } } } Link to comment Share on other sites More sharing options...
scrax Posted January 26, 2010 Share Posted January 26, 2010 not working for me too, the error is gone but i cant plug and mount my mybook FW drive.. And after a sleep and wake? Can you see it? Link to comment Share on other sites More sharing options...
mikeetastic Posted January 26, 2010 Share Posted January 26, 2010 And after a sleep and wake? Can you see it? same! i even tried logging out and it wont just mount or even detected in disk utility. Link to comment Share on other sites More sharing options...
LocusOfControl Posted January 26, 2010 Share Posted January 26, 2010 same! i even tried logging out and it wont just mount or even detected in disk utility. On impulse I tried powering on scanner after boot and un-plugging from the mobo, then re-attaching it That didn't work I'm wondering if this is because the scanner is powered with its own complex internal mechanisms (unlike a HD)? But then again it used to work before sleep previously without DSDT There is another device in my DSDT called FWHD - is this related to firewire, if so should I keep or delete? Device (FWHD) { Name (_HID, EisaId ("INT0800")) Method (_CRS, 0, NotSerialized) { Name (FWH0, ResourceTemplate () { Memory32Fixed (ReadWrite, 0xFFB80000, // Address Base 0x00080000, // Address Length ) }) Return (FWH0) } } Link to comment Share on other sites More sharing options...
MacKonsti Posted January 26, 2010 Share Posted January 26, 2010 There is another device in my DSDT called FWHD - is this related to firewire, if so should I keep or delete? That's Firmware Hub device (FWH) or (FHWD) and you don't want to touch that, mate... I was tempted too, before I googled it... Guys, I honestly can't think of anything to say to help you solve this, except, like me, do many DSDT code tests and endless reboots... So to recap; on your mobo's the error disappears but your firewire scanner is not detected after you turn it on, correct? Or even firewire HDD? I have Texas Instruments device, perhaps Agere or others don't behave the same, due to Apple's drivers particularities? Link to comment Share on other sites More sharing options...
LocusOfControl Posted January 26, 2010 Share Posted January 26, 2010 That's Firmware Hub device (FWH) or (FHWD) and you don't want to touch that, mate... I was tempted too, before I googled it... Guys, I honestly can't think of anything to say to help you solve this, except, like me, do many DSDT code tests and endless reboots... So to recap; on your mobo's the error disappears but your firewire scanner is not detected after you turn it on, correct? Or even firewire HDD? I have Texas Instruments device, perhaps Agere or others don't behave the same, due to Apple's drivers particularities? No problem, thanks for your help. I think I see what the problem is even if I'm not sure how to fix it. I tried having the scanner on before I booted, there are no extra messages in the logs but doing this I can switch the scanner off and on without having to go through a wake sleep cycle. I assume that unless the powered scanner is on at the start then the original configuration conditions are somehow not set. This is slightly different from the tested scenario tested yesterday. Here the scanner isn't discovered till after wake but if I switch it off then I have to do another sleep wake cycle All in all I can live with this because I don't use it that often. So it is working, I just need to remember to power the scanner before I boot otherwise it is just a lump of metal stuck on the end of a firewire cable Edit: After sleeping and waking in this scenario the scanner is recognised but claims it is not ready or no film. This kind of implies that scanners are a bit more complex than HD's and need a few extra features set Link to comment Share on other sites More sharing options...
SMF Posted January 30, 2010 Share Posted January 30, 2010 The associated fix does remove the error for me on boot up ... however it appears to break sleep. When I apply the fix and then sleep (via the apple menu) the computer appears to sleep but the fans continue to spin. If I remove the fix and then sleep the computer completely sleeps with fans off, etc. Any ideas/thoughts? Regards, SMF Link to comment Share on other sites More sharing options...
ErmaC Posted January 30, 2010 Share Posted January 30, 2010 The associated fix does remove the error for me on boot up ... however it appears to break sleep. When I apply the fix and then sleep (via the apple menu) the computer appears to sleep but the fans continue to spin. If I remove the fix and then sleep the computer completely sleeps with fans off, etc. Any ideas/thoughts? Regards, SMF Nice... I have the same issue... (OHR or similar fix this but my goal is do this w/o kext) So i try and later I post my test result.. ( I try use old method in the first post of the page... unfix this fix ) Fabio EDIT Notthing... I think the problem is in the SS code not the Firewire Link to comment Share on other sites More sharing options...
MacKonsti Posted February 1, 2010 Share Posted February 1, 2010 Nice...I have the same issue... (OHR or similar fix this but my goal is do this w/o kext) So i try and later I post my test result.. ( I try use old method in the first post of the page... unfix this fix ) Fabio EDIT - Notthing... I think the problem is in the SS code not the Firewire Damn, guys, I also faced the same problem last night, and freaked out. I think that after sleeping/waking the PC for many times, when I turned the firewire HDD on it was not recognised, and slept (to do the detection trick) and it would not sleep--fans were running. I could not wake the thing up, had to reset it (front panel) and it rebooted a few times (got stuck at "Waiting for DSMOS") but then noticed (always on verbose boot -v) this message: 31/01/2010 1:00:37 a.m. FireWire (OHCI) TI ID 8023 built-in now active, GUID 00301b000048628f; max speed s100. Notice the S100 at the end. I eventually had to reset it a couple of times, remove power plug and wait a few seconds, remove all USB devices (external sticks, HDD and scanner) and booting up came to a normal status (including firewire HDDs). That was scary. I use a more-or-less improved DSDT and only EvOreBoot / FakeSMS / UIDplatform kexts. No SleepEnabler, nor OpenHaltRestart (due to Power Management done by the system). Any ideas, anyone? Am I missing a kext, all this time? Oh and iFabio, what do you mean by "SS code" problem? Link to comment Share on other sites More sharing options...
SMF Posted February 1, 2010 Share Posted February 1, 2010 MacKonsti, What I see in my logs is - "1/29/10 11:56:28 PM kernel System sleep prevented by FRWR". If I remove the fix I can sleep. I haven't been able to find something in the ACPI spec that would help me add code to force the FRWR to sleep - perhaps something in the PTS section of the DSDT. Regards, SMF Link to comment Share on other sites More sharing options...
ErmaC Posted February 1, 2010 Share Posted February 1, 2010 Oh and iFabio, what do you mean by "SS code" problem? SS= speedstep But now I can confirm that is not the SS code the trouble... in my case I also tried the DSDT without "SS" and the problem remains the same. I will focus to implement the sleep method disabling the Firewire device via BIOS. When I've also got the sleep I'll do the tests again on firewire. Fabio Sorry for my english. Link to comment Share on other sites More sharing options...
triptolemos Posted February 1, 2010 Share Posted February 1, 2010 Great work on the fixing guys. For me both solutions give the same problem hot plugging my Apogee Duet. For the rest they seem the same (sleep works with both, but i didn't try n times). Link to comment Share on other sites More sharing options...
asadev Posted February 4, 2010 Share Posted February 4, 2010 Just to add that i also cant sleep with the firewire fix, fans stay on. Without the fix sleep is perfect. Ive also only got an ipod with a firewire cable to test and that does not work before or after sleep, nor connected on a reboot. Regards Link to comment Share on other sites More sharing options...
scrax Posted February 4, 2010 Share Posted February 4, 2010 Just to add that i also cant sleep with the firewire fix, fans stay on. Without the fix sleep is perfect. Ive also only got an ipod with a firewire cable to test and that does not work before or after sleep, nor connected on a reboot. Regards For me the mod don't have any effect on sleep, still working good, but hotplug works only on certain device, not on portable HD, for example. Link to comment Share on other sites More sharing options...
MacKonsti Posted February 13, 2010 Share Posted February 13, 2010 Guys I think I may have found a solution here... While studying the DSDT structure of the other devices like USB etc. I found there's an entry for (_PRW) parameter that's missing from the firewire device. Now just because it ain't there doesn't mean it's not needed. So here's my newly modified code that seems to be working, that I urge you to copy/paste/try and come back with results. First of all, we need a new entry at the end of (_GPE) section, just for firewire (new method "_L1A"): Method (_L1A, 0, NotSerialized) { Notify (\_SB.PCI0.HUB0.FRWR, 0x00) Notify (\_SB.PWRB, 0x02) // Added notification for power button } Just make sure your device description is correct e.g. for me the superset device owning firewire is HUB0, for you could be PCIB etc. The value is on purporse 0x00 despite for USBs being 0x02 (well, you can try and experiment and tell us your findings). Now we need to add a new (_PRW) method in firewire device code, but be careful to keep the (_GPE) value we used before (will explain later): Device (FRWR) // Added device for Texas Instruments TSB43AB22/A IEEE-1394A Controller [104c:8023] { Name (_ADR, 0x060A0000) // [b]My firewire address reported by 'lspci -n'[/b] Name (_GPE, 0x0B) // [b]Callback to (_GPE) Method (_L0B) for device owning firewire (HUB0)[/b] Method (_DSM, 4, NotSerialized) { Store (Package (0x06) { "built-in", Buffer (0x01) { Zero }, "fwhub", Buffer (0x04) { 0x00, 0x00, 0x00, 0x00 }, "device-id", Buffer (0x04) { 0x23, 0x80, 0x00, 0x00 // [b]Board device ID is [8023] reported by 'lspci -n'[/b] } }, Local0) DTGP (Arg0, Arg1, Arg2, Arg3, RefOf (Local0)) Return (Local0) } [color="#0000FF"] Method (_PRW, 0, NotSerialized) { Return (Package (0x02) { 0x1A, // [b]Callback to new (_GPE) Method (_L1A)[/b] 0x05 }) }[/color] } For the 'conservation' error to disappear from bootlogs, we need to make sure the Name (_GPE, 0x0B) entry points to the callback of the superset device owning firewire, not firewire itself (_L1A). In my case, for HUB0 device, the callback in my code points to _L0B, search for yours (e.g. PCIB device?) and just put/leave that value. Don't point this one to the new method _L1A. The new (_PRW) method now should take care of any other calls for power management, just for the firewire itself, through our newly added method in (_GPE) section. Please try this, recompile your DSDT, reboot and let me/us know! I really hope this will help. For me, I can report that when I shut down the hackintosh, the firewire drives now shut also... But if someone with better DSDT knowledge thinks this is a screw up, please post now!!! :censored2: P.S. This code addition doesn't affect the system otherwise (e.g. speed-step etc.) Link to comment Share on other sites More sharing options...
Recommended Posts