immo Posted November 11, 2009 Author Share Posted November 11, 2009 On it's way via email (the IOATAFamily.kext that is). I'm going to start having a look back over the C-State errors now that there is a big change in the ACPI_SMC. I do know that even without any SSDT entries in my DSDT I still get speedstep working just fine. Haven't delved any further yet. Brett I need more time to experiment but I found something rather odd here. I made my own DSDT without SSDT tables and as you said, Speed Step works. However, according to CoolBook, the P-States aren't quite correct. The fastest step is 2.6GHz even though my CPU maxes at 2.4GHz. Unsurprisingly it does not step to the highest step. To try and correct this, I put back my old DSDT with the SSDT entries, and I got the same 2.6GHz highest step reported in CoolBook! I'm pretty sure that the CoolBook entries matched my SSDT power states before... Is it possible that the SSDT entries are now ignored in 10.6.2? I didn't have a lot of time to experiment so hopefully I didn't make a dumb-ass mistake. I'll experiment more when I get time. Link to comment Share on other sites More sharing options...
Brett Whinnen Posted November 11, 2009 Share Posted November 11, 2009 I need more time to experiment but I found something rather odd here. I made my own DSDT without SSDT tables and as you said, Speed Step works. However, according to CoolBook, the P-States aren't quite correct. The fastest step is 2.6GHz even though my CPU maxes at 2.4GHz. Unsurprisingly it does not step to the highest step. To try and correct this, I put back my old DSDT with the SSDT entries, and I got the same 2.6GHz highest step reported in CoolBook! I'm pretty sure that the CoolBook entries matched my SSDT power states before... Is it possible that the SSDT entries are now ignored in 10.6.2? I didn't have a lot of time to experiment so hopefully I didn't make a dumb-ass mistake. I'll experiment more when I get time. Mine has always referenced the highest power state as 2.6GHz even with 10.6.0 and 10.6.1. I didn't do as much testing under Leo so can't comment on that Link to comment Share on other sites More sharing options...
Chrysaor Posted November 11, 2009 Share Posted November 11, 2009 Use VoodooMonitor or MSR Tools to test speedstep, Coolbook isn't reliable. Link to comment Share on other sites More sharing options...
overshoot Posted November 11, 2009 Share Posted November 11, 2009 Mine has always referenced the highest power state as 2.6GHz even with 10.6.0 and 10.6.1. I didn't do as much testing under Leo so can't comment on that Hi All, I'm using Brett's DSDT for my XPS 1530 as he has the same CPU as mine but i can't get speedstep working correctly. My CPU frequency is stuck at 800 Mhz at first boot and never goes faster. If i put my hack to sleep it then get stuck at 1200Mhz. VoodooMonitor shows about 16 Pstates available... see screenshots please. I've removed dropssdt from my boot plist but no more speedstep. Also, sleep works sometimes and sometimes my hack reboots itself. I'm starting getting crazy trying to make speedstep works. If someone can help me... that would be very friendly. I'm also using Macbook pro4.1 for my smbios plist. Last thing is that i'm still using bios A09 but i can't install the new bios as i didn't have anymore windows on my laptop. I'm starting to think that this is the problem as i heard you were all using A12 bios, right? Thanks in advance. Josh. Link to comment Share on other sites More sharing options...
timmyj9 Posted November 12, 2009 Share Posted November 12, 2009 overshoot: locked at 800MHz means that your P-states don't match your platform change the number of p-states to 9 or larger in dsdt or use macbookpro5,1 got a new DSDT fix thanks to what masterchiefs been doing... changes involve adding MCDP method (replacement of DTGP - just kept both for now) adding FRWR device - (removes the firewire runtime power conservation error) and a link for this device in the GPE scope (_L19) also my previous DSDT on the other topic didn't have the PATA IOATA panic fix, so thats in there also for the FRWR fix - should work in M1530 i'm not sure about M1330 but i'd assume it'd be very similar may have to change the _ADR value i'm not sure - so yeah under scope _GPE added Method (_L19, 0, NotSerialized) { Notify (\_SB.PCI0.PCIB.FRWR, Zero) } and under the device with Name (_ADR, 0x001E0000) you can remove CRD0 aswell ( i've renamed a lot of my devices with the apple ones just to make things easier i'm not sure if this is one of the ones that i've changed or not) Device (FRWR) { Name (_ADR, 0x00090000) Name (_GPE, 0x19) Method (_DSM, 4, NotSerialized) { Store (Package (0x02) { "fwhub", Buffer (0x04) { 0x00, 0x00, 0x00, 0x00 } }, Local0) MCDP (Arg2, RefOf (Local0)) Return (Local0) } } and the MCDP method around the DTGP one Method (MCDP, 2, NotSerialized) { If (LEqual (Arg0, Zero)) { Store (Buffer (One) { 0x03 }, Arg1) } } hopefully this is of some use my decompiled DSDT is also attached for further reference is specific to my config (m1530, t9500 etc) but yeah take what you want from it DSDT.zip Link to comment Share on other sites More sharing options...
jkbuha Posted November 12, 2009 Share Posted November 12, 2009 Firewire DSDT fix works for me! If anyone needs the full DSDT please PM me (cannot attach files atm!) Cheers jkbuha Link to comment Share on other sites More sharing options...
timmyj9 Posted November 13, 2009 Share Posted November 13, 2009 it seems to me that our c-states issue is more related to the LPC device itself rather than _CST tables from what I can gather our error is what people normally get when they don't have AppleLPC.kext loaded, and therefore have to inject device IDs via DSDT. Plus we don't have any _CST evaluation failed messages etc.. But for us ICH8-M users AppleLPC.kext loads out of the box. Perhaps it is to do with how the ISAB/WSEC device is set out in our default DSDT, and therefore using the MacBookPro4,1 DSDT i've been trying to rewrite it to match the apple one but without much luck thus far.......it's also quite likely i'm completely wrong and if someone understands the DSDT better than I do, they probably have a better idea of it. I still haven't tried to implement the EC device which is another item under the LPC device on Apple DSDTs but perhaps that may also be worth attempting Just putting an idea out there. Does anyone know of anyone with working C-states on a hack laptop? Because all i've seen is desktop users doing it. Link to comment Share on other sites More sharing options...
immo Posted November 13, 2009 Author Share Posted November 13, 2009 Mine has always referenced the highest power state as 2.6GHz even with 10.6.0 and 10.6.1. I didn't do as much testing under Leo so can't comment on that So I did some digging and I figured out why CoolBook reports the 2.6. If you look at the PSS section and decode it, you find the first entry is 2401MHz with a multiplier of 13, and the second is 2400MHz with a multiplier of 12. With a bus speed of 200: 13 * 200 = 2600 12 * 200 = 2400 So CoolBook is simply calculating the frequency from the multiplier. The T8300 supports a maximum multiplier of 12, so why the heck that 2401 state is there is beyond me! I also tried VoodooMonitor as Chrysaor has suggested and it reports a total of 10 steps. I guess these are all the steps that the CPU can possibly use. It's definitely not hitting any steps that are not in the DSDT. Link to comment Share on other sites More sharing options...
jkbuha Posted November 13, 2009 Share Posted November 13, 2009 You can find someone who made CST work for laptops (esp Dell XPS) here: http://www.projectosx.com/forum/index.php?...ic=532&st=0 Let us know if you have any luck! Cheers jkbuha it seems to me that our c-states issue is more related to the LPC device itself rather than _CST tablesfrom what I can gather our error is what people normally get when they don't have AppleLPC.kext loaded, and therefore have to inject device IDs via DSDT. Plus we don't have any _CST evaluation failed messages etc.. But for us ICH8-M users AppleLPC.kext loads out of the box. Perhaps it is to do with how the ISAB/WSEC device is set out in our default DSDT, and therefore using the MacBookPro4,1 DSDT i've been trying to rewrite it to match the apple one but without much luck thus far.......it's also quite likely i'm completely wrong and if someone understands the DSDT better than I do, they probably have a better idea of it. I still haven't tried to implement the EC device which is another item under the LPC device on Apple DSDTs but perhaps that may also be worth attempting Just putting an idea out there. Does anyone know of anyone with working C-states on a hack laptop? Because all i've seen is desktop users doing it. Link to comment Share on other sites More sharing options...
Superhai Posted November 13, 2009 Share Posted November 13, 2009 So CoolBook is simply calculating the frequency from the multiplier. The T8300 supports a maximum multiplier of 12, so why the heck that 2401 state is there is beyond me! IDA Link to comment Share on other sites More sharing options...
immo Posted November 13, 2009 Author Share Posted November 13, 2009 small question if i replace the battery and the hd do i have to rebuild my dsdt files? Nope. IDA And all becomes clear Link to comment Share on other sites More sharing options...
jkbuha Posted November 14, 2009 Share Posted November 14, 2009 IDA Hello Superhai! Really good to see you here! Quick question - if 2401 enables IDA mode, how do you enable SLFM? Is the [600] entry enough? Also - have you had any luck so far with CST? And (last question promise!) any chance of us getting our hopes up for a shutdown/restart fix? Cheers jkbuha Link to comment Share on other sites More sharing options...
cyberbuddhah Posted November 14, 2009 Share Posted November 14, 2009 update oct 22 2009, 4pm sleep/speedstep work now! Thanks to all. guess i should post my findings as well. I used your dsdt running SL 10.6.2 now with, sleep/speedstep/shutdown/reboot WORK! Sound, touchpad scrolling double tap, clamshell, QE/CI open GL also work Even dual boot win7 Thank you. Essentially it's a mini macbook pro Enclosed my package if someone else needs it Link to comment Share on other sites More sharing options...
Claudio A. Posted November 14, 2009 Share Posted November 14, 2009 Thank you so much jkbuha, it worked!! RANDOM WORKING USB FIX in Device (TMR) section I REMOVED: IRQNoFlags () {2} I had to remove that just from TMR, but there are chances you have to remove something similar also in HPET or PIC sections... just try! I attach here my final DSDT, so everyone can use it. Configuration: - XPS 1330 - T7250 (2.0 ghz) - Nvidia 8400GS - Audio Sigmatel STAC9228 What works: - USB - Battery - Speedstep - Sleep - Audio (only from jacks and not from speakers, but I don't think it's dsdt related) What doesn't work: - C-States - Shutdown/restart What isn't perfect: - Audio problems waking up from the sleep - USB problem waking up from the sleep, I have to unplug and plug again devices like USB to Ethernet adapter. [EDIT: I changed a little the DSDT, previously I changed more than needed] DSDT_1330_T7250_8400GS.dsl.zip Hi! I've the exact same configuration but for an m1530, do you think that your DSDT will work? Link to comment Share on other sites More sharing options...
immo Posted November 14, 2009 Author Share Posted November 14, 2009 Hi! I've the exact same configuration but for an m1530, do you think that your DSDT will work? Don't use an M1330 DSDT on an M1530. Try Brett's: http://www.insanelymac.com/forum/index.php...t&p=1324780 It should work on any CPU. Link to comment Share on other sites More sharing options...
ab___73 Posted November 15, 2009 Share Posted November 15, 2009 it seems to me that our c-states issue is more related to the LPC device itself rather than _CST tablesfrom what I can gather our error is what people normally get when they don't have AppleLPC.kext loaded, and therefore have to inject device IDs via DSDT. Plus we don't have any _CST evaluation failed messages etc.. But for us ICH8-M users AppleLPC.kext loads out of the box. Perhaps it is to do with how the ISAB/WSEC device is set out in our default DSDT, and therefore using the MacBookPro4,1 DSDT i've been trying to rewrite it to match the apple one but without much luck thus far.......it's also quite likely i'm completely wrong and if someone understands the DSDT better than I do, they probably have a better idea of it. I still haven't tried to implement the EC device which is another item under the LPC device on Apple DSDTs but perhaps that may also be worth attempting Just putting an idea out there. Does anyone know of anyone with working C-states on a hack laptop? Because all i've seen is desktop users doing it. I think your on the right track. The error we are getting is not due to wrongly defined cstates or pstates in dsdt or ssdt tables, it's an error flag in the LPC device driver. I've managed to get pstates and cstates working with an Intel 945 chipset based laptop, ICH7M southbridge type. (HP 530). The LPC device loaded with this chipset and at least i was experiencing the _CST evaluation failed messages at the beginning. After a bit of tweaking the tables i managed to get them to load. Although this was a while back and I was using Leopard 10.5.5. I've no longer got this laptop so I cannot try the same hardware with SL 10.6.x. I've tried using the same methods that i used with this chipset on my M1530 laptop, but with no success. I've also managed to get CST and PSS loaded on my Gigabyte P45-DS4 Desktop using the Device ID hack within the LPCB device. (More evidence that it points to our LPC Device) I'm going to look at the IOPCIFamily kext to find out if this is reporting anything when the LPC device is loading. I'll report back any findings.... -- AB Link to comment Share on other sites More sharing options...
immo Posted November 15, 2009 Author Share Posted November 15, 2009 Just note the following about my DSDT;- NO SSDT entries, so if you use it make sure you don't have the DropSSDT=Y in Chameleon - has the HPET and TMR IRQ fixes for USB - has the IOATA fix for the CDROM - has the SBUS entries (thanks Julian) - has the extra USB entries to allow clean disconnects of USB devices during sleep - has the Nvidia 8600M GT 256 card entries - has the 'pretty text' additions for the Yukon NW controller I still get speedstep working with this, just using the default PSS states, I also run my laptop as a MBP5,1. Obviously no C-States. DSDT.dsl.zip Hi Brett. So as I mentioned earlier I made an M1330 DSDT.aml without the SSDT tables. Speed step works just as you said, but I've found that sleep is broken. Basically when I put it to sleep, it wakes up instantly. After putting the old one with the SSDT tables back and replacing the DropSSDT=y parameter, sleep starts working again... I applied all the same fixes except the "pretty text" one (not applicable to M1330). Is your sleep working? Immo Link to comment Share on other sites More sharing options...
jkbuha Posted November 15, 2009 Share Posted November 15, 2009 I think your on the right track.The error we are getting is not due to wrongly defined cstates or pstates in dsdt or ssdt tables, it's an error flag in the LPC device driver. I've managed to get pstates and cstates working with an Intel 945 chipset based laptop, ICH7M southbridge type. (HP 530). The LPC device loaded with this chipset and at least i was experiencing the _CST evaluation failed messages at the beginning. After a bit of tweaking the tables i managed to get them to load. Although this was a while back and I was using Leopard 10.5.5. I've no longer got this laptop so I cannot try the same hardware with SL 10.6.x. I've tried using the same methods that i used with this chipset on my M1530 laptop, but with no success. I've also managed to get CST and PSS loaded on my Gigabyte P45-DS4 Desktop using the Device ID hack within the LPCB device. (More evidence that it points to our LPC Device) I'm going to look at the IOPCIFamily kext to find out if this is reporting anything when the LPC device is loading. I'll report back any findings.... -- AB That's a really good point. So what if we change the deviceid to match the LPC id found in the MBP4,1 or the MP4,1 [ie the model that most closely resembles the T8300/T9300? Can anyone run an LSPCI on a proper mac and report the deviceid? Here's mine from a Dell XPS M1330 (ICH8 - 2815): 00:1f.0 ISA bridge [0601]: Intel Corporation 82801HEM (ICH8M) LPC Interface Controller [8086:2815] (rev 02) Then in order to change the deviceid to a more compatible id (eg: 3A18 below) insert the hack using DTGP method as shown below: Device (LPCB) { Name (_ADR, 0x001F0000) Method (_DSM, 4, NotSerialized) { Store (Package (0x02) { "device-id", Buffer (0x04) { 0x18, 0x3A, 0x00, 0x00 //hack the ID.. } }, Local0) DTGP (Arg0, Arg1, Arg2, Arg3, RefOf (Local0)) Return (Local0) } Maybe this could be the way towards finding the elusive CST on an XPS! Cheers jkbuha Link to comment Share on other sites More sharing options...
Brett Whinnen Posted November 15, 2009 Share Posted November 15, 2009 Hi Brett. So as I mentioned earlier I made an M1330 DSDT.aml without the SSDT tables. Speed step works just as you said, but I've found that sleep is broken. Basically when I put it to sleep, it wakes up instantly. After putting the old one with the SSDT tables back and replacing the DropSSDT=y parameter, sleep starts working again... I applied all the same fixes except the "pretty text" one (not applicable to M1330). Is your sleep working? Immo Sleep still works with both the wireless mouse update (run a magic mouse when using on a desktop surface) and 10.6.2. Might be interesting to see the difference in errors you get in the logs. Link to comment Share on other sites More sharing options...
overshoot Posted November 15, 2009 Share Posted November 15, 2009 Hi Brett. So as I mentioned earlier I made an M1330 DSDT.aml without the SSDT tables. Speed step works just as you said, but I've found that sleep is broken. Basically when I put it to sleep, it wakes up instantly. After putting the old one with the SSDT tables back and replacing the DropSSDT=y parameter, sleep starts working again... I applied all the same fixes except the "pretty text" one (not applicable to M1330). Is your sleep working? Immo Hi immo, I'm using Brett's DSDT on my XPS 1530 (apparently same config as its one) and i've also loosed sleep. My hack just restart itself. I've created a script to put my hack to sleep when the battery level is too low and, in this state, sleep works... strange... Josh. Link to comment Share on other sites More sharing options...
Brett Whinnen Posted November 15, 2009 Share Posted November 15, 2009 Hi immo, I'm using Brett's DSDT on my XPS 1530 (apparently same config as its one) and i've also loosed sleep. My hack just restart itself. I've created a script to put my hack to sleep when the battery level is too low and, in this state, sleep works... strange... Josh. How do you guys put your laptop to sleep? I just close the lid when I'm done. Link to comment Share on other sites More sharing options...
immo Posted November 16, 2009 Author Share Posted November 16, 2009 How do you guys put your laptop to sleep? I just close the lid when I'm done. Yes so do I. I actually figured it out though. I checked the console and found this: 09-11-15 11:54:48 PM kernel Wake reason = AZAL PBTN LID EHCI When I made that last DSDT, I didn't apply the HDEF patch. Reason being I didn't want to have to remove the AppleHDA.kext, and I heard by not applying the patch, AppleHDA will not load and conflict with VoodooHDA. Turns out that it is required for working sleep if you don't attach the SSDT tables, at least on my setup. But it works fine without the HDEF patch if the SSDT tables are included Did you apply the HDEF patch? Immo Link to comment Share on other sites More sharing options...
Brett Whinnen Posted November 16, 2009 Share Posted November 16, 2009 Yes so do I. I actually figured it out though. I checked the console and found this:09-11-15 11:54:48 PM kernel Wake reason = AZAL PBTN LID EHCI When I made that last DSDT, I didn't apply the HDEF patch. Reason being I didn't want to have to remove the AppleHDA.kext, and I heard by not applying the patch, AppleHDA will not load and conflict with VoodooHDA. Turns out that it is required for working sleep if you don't attach the SSDT tables, at least on my setup. But it works fine without the HDEF patch if the SSDT tables are included Did you apply the HDEF patch? Immo Yes I have the HDEF patch in place and have the AppleHDA kext removed. Link to comment Share on other sites More sharing options...
E-XD Posted November 16, 2009 Share Posted November 16, 2009 Hi Immo, thank you for doing and sharing this guide. I'm testing it right now, but I think you should correct this in Step One (Number 6): Step One: Dumping the ACPI Tables ... 6. Dump the tables and store them in ACPI-Tables.zip (thank you zhell) mkdir ACPI && dmesg | perl -we '$n=0; while (<>) { if (($t,$a,$l,$o) = (/^[^a-zA-Z]*ACPI: ([-._A-Z0-9]{4,4}) +([0-9A-F]{8,8}), ([0-9A-F]{4,4})+(?:\s*\(([^)]+))?/)) { $o && $o=~s/[^-._a-zA-Z0-9]+/-/g; ($cmd="acpidump -a $a -l $l > \"ACPI/${t}".($o?"_$o":"").".aml\""); print "Running command: \"$cmd\"\n"; system($cmd); ++$n; } } die("No match") unless $n;' && zip -r ACPI-Tables.zip ACPI ... If you run this command, it will bump many errors. In order to get flawless results you must first become root with command "sudo su" and then run the command from zhell (I supose). Hope it helps. If you already knew and posted it, my apologies. Link to comment Share on other sites More sharing options...
immo Posted November 16, 2009 Author Share Posted November 16, 2009 [/i]If you run this command, it will bump many errors. In order to get flawless results you must first become root with command "sudo su" and then run the command from zhell (I supose). Hope it helps. If you already knew and posted it, my apologies. Done. Thanks for pointing it out. Link to comment Share on other sites More sharing options...
Recommended Posts