Bandes Posted November 12, 2009 Share Posted November 12, 2009 "i dont know if i should try the npss block for pss, cause 725 and 616 look strange for values, when there should be 0, 1.." No: It is the opposite. Your pss entrys are wrong! 0616 and 0725 in NPSS are right !!! 06 is multi 6* and 16 the VID for the volts . Your now listet 0036 and 0136 are complete wrong in pss. Use NPSS as PSS. hmm i was so confused about watching other ssdts, i was on a totally wrong path! i tried the npss settings, and p-state changing works now! cpu runs about 10 degree cooler! Thanx a lot! so, to the last hurdle: cst evaluation error is still present. those are the last 5 degrees to get it normal cool, and to make sleep work. so i have just read Master Chief's post about possible correct c-state values here http://www.insanelymac.com/forum/index.php...631&st=120# my PCT Address values are 0x880 and 0x882 if i am right i should use the values here in the cst method Method (_CST, 0, NotSerialized) { Return (Package (0x04) { 0x03, Package (0x04) {ResourceTemplate () {Register (FFixedHW, 0x00, 0x00, 0x000, ,)},0x01,0x01,0x3E8}, Package (0x04) {ResourceTemplate () {Register (FFixedHW, 0x08, 0x00, 0x414, ,)},0x02,0x01,0x1F4}, Package (0x04) {ResourceTemplate () {Register (FFixedHW, 0x08, 0x00, 0x415, ,)},0x03,0x55,0x0FA} // 0x03, // Package (0x04) {ResourceTemplate () {Register (FFixedHW, 0x00, 0x00, 0x000, ,)},0x01,0x01,0x3E8}, // Package (0x04) {ResourceTemplate () {Register (FFixedHW, 0x08, 0x00, 0x414, ,)},0x02,0x01,0x1F4}, // Package (0x04) {ResourceTemplate () {Register (FFixedHW, 0x08, 0x00, 0x416, ,)},0x03,0x96,0x064} }) } there are still two cst value blocks to choose from, i did try already both as they are, but none is working. my bet is on the values with the 0x000, 0x414, 0x415. (i was already wrong, so it might be the other three) but anyway these values dont work, so they need to be changed somehow. any suggestions ? -- just checking macpro 3.1 ssdt doesnt look good that method never returns 4 packages, only maximum 3. so one less c-states used probably. and there are if statements in the cst method with cfgd values. not mention odc and pdc methods. who knows what these do ? they might be needed for cst. Link to comment Share on other sites More sharing options...
Beerkex'd Posted November 13, 2009 Share Posted November 13, 2009 To everyone: If you are using any legacy/dummy HDA.kext, i.e. LegacyHDA.kext, with 1.7.9a4 AppleHDA.kext (10.6.2), please remove BuiltInHDA key from info.plist if having it. Also, don't need any LegacyHDAController.kext for Snow. Thanks for the tip. I guess this applies to AD2000B.kext as well? Since it's sort of kind of the same thing. I'll have a look later. d'animal, if you try this, please let me know (I can't right now from where I am). Link to comment Share on other sites More sharing options...
mitch_de Posted November 13, 2009 Share Posted November 13, 2009 [*]voodoomonitor shows my 9X voltage at 1.244 and my 6X voltage at 1.068 whereas voodoopstate shows 1.137 and 1.000 for those same multipliers, respectively. The values used by voodoopstate match my SSDT. Additionally the p-state tab in voodoomonitor shows yet another voltage for 6x (1.148) and the control column seems to have the wrong vid values I'd like to get this sorted out completely. Currently I think my SSDT tables are giving me working stepping but I'm not sure if the voltages are right. I could probably get to the bottom of this if the source for voodoomonitor was available. Is it?Thanks I believe that the speedstep tools which can show mVs show different mVolts because they do an different conversion (formula) getting mVolts from the acutal read(MSR) VID(that hex in PSS) . Any speedstep tool reads out VID and not mVolts (are not readable) and must convert that VID like 20hex to zzzz mVolts. CPU-X, which cant show mVolts only use thar hw.xyz kernel varibale to get MHz, not read MSR for MHZ. Also that gives sometimes different MHZ, if the speedstep tool didnt also update that kernel variable for MHz. CPU-X cant see MHZ changes in this case. The VID itself and "real mVolts" are same (i am 99% sure). If all Tools would show also VID beside mVolts, we would see that VIDs same, only mVolts (computed of of VID) maybe "virtually" different. MSR Tools, superhais & other voodoo, & .... may show different mVolts at same VID=same mVolts in real. So more an cosmetic problem. Link to comment Share on other sites More sharing options...
bcc9 Posted November 13, 2009 Share Posted November 13, 2009 I believe that the speedstep tools which can show mVs show different mVolts because they do an different conversion (formula) getting mVolts from the acutal read(MSR) VID(that hex in PSS) . Any speedstep tool reads out VID and not mVolts (are not readable) and must convert that VID like 20hex to zzzz mVolts. CPU-X, which cant show mVolts only use thar hw.xyz kernel varibale to get MHz, not read MSR for MHZ. Also that gives sometimes different MHZ, if the speedstep tool didnt also update that kernel variable for MHz. CPU-X cant see MHZ changes in this case.The VID itself and "real mVolts" are same (i am 99% sure). If all Tools would show also VID beside mVolts, we would see that VIDs same, only mVolts (computed of of VID) maybe "virtually" different. MSR Tools, superhais & other voodoo, & .... may show different mVolts at same VID=same mVolts in real. So more an cosmetic problem. I don't think you understood what I wrote. voodoomonitor is showing the wrong hex in the 'control' column, which includes the vid and which does not match up to the correct vid values as found in my SSDT and as reported correctly by my modified version of voodoopstate. voodoomonitor's voltage math is also not matching up between the p-state tab and the voltage tab; which is more than cosmetic. If it was simply a matter of voodoomonitor being off by a factor of X for all of its math then it would be cosmetic. @mojodojo: Source code please so that I can fix this? Link to comment Share on other sites More sharing options...
mitch_de Posted November 13, 2009 Share Posted November 13, 2009 Ladies & gentleman - get ready to rumble your dsdt compiling/disassembling New IASL + iASLme Tool (iasl is new, rest same) available - Nov 2009 Version OUT ! Source was out a few hours - mitch compiled again. You cant get it fasterSALES! 100% off http://www.insanelymac.com/forum/index.php?showtopic=189272 Link to comment Share on other sites More sharing options...
bcc9 Posted November 13, 2009 Share Posted November 13, 2009 voodoomonitor fix #1: I looked at the source to the older cpu-i and see that it's using the wrong equation for the voltage: inline UInt32 IntelGetVoltage(UInt8 vid) { return 700 + ((vid & 0x3F) << 4); } whereas for my 45nm cpu the voltage should be as in voodoopstate (which is in turn from voodoopower): inline UInt32 IntelGetCoreNewVoltage(UInt8 vid) { return (1425 + ((vid & 0x3F) * 25)) >> 1; } thus for vid=0x22, cpu-i and voodoomonitor report 1.244 whereas the right value is 1.137 this part *is* effectively cosmetic (but damn confusing). It's also just 1 of the several issues I mentioned... Link to comment Share on other sites More sharing options...
mitch_de Posted November 13, 2009 Share Posted November 13, 2009 Great ! Thanks for your found out the VID / mVolts difference reason in sources. Its really better to have fixed that, even "only" cosmetic. Can you share your changed source (or even better build) somewhere ? Link to comment Share on other sites More sharing options...
bcc9 Posted November 13, 2009 Share Posted November 13, 2009 Great ! Thanks for your found out the VID / mVolts difference reason in sources.Its really better to have fixed that, even "only" cosmetic. Can you share your changed source (or even better build) somewhere ? I don't have the source to voodoomonitor to fix it. That's why I started by asking for it. I don't understand how you guys are verifying that your p-state changes are working if none of the tools that test the results are in order. The problem that I reported as #3 above is particularly troubling. It seems like voodoomonitor gets "stuck" sometimes and stops updating. If I restart voodoomonitor it picks up the new values in this case. On my system I see the voltage change far less often than the multiplier and now I don't know if that's a voodoomonitor quirk or an actual issue with my system's intelcpupowermanagement. Link to comment Share on other sites More sharing options...
blackosx Posted November 13, 2009 Share Posted November 13, 2009 I have been looking though my kernel log and I have the following errors.... Nov 6 18:50:22 BlackSnow kernel[0]: IOHIDSystem::relativePointerEventGated: VBL too high (25014056), capping to 20000000 Nov 8 22:14:35 BlackSnow kernel[0]: IOHIDSystem::relativePointerEventGated: VBL too high (20229097), capping to 20000000 Nov 9 08:08:40 BlackSnow kernel[0]: IOHIDSystem::relativePointerEventGated: VBL too high (20960423), capping to 20000000 Nov 10 19:16:25 BlackSnow kernel[0]: IOHIDSystem::relativePointerEventGated: VBL too high (20019053), capping to 20000000 Nov 11 18:59:47 BlackSnow kernel[0]: IOHIDSystem::relativePointerEventGated: VBL too high (20655770), capping to 20000000 Nov 13 07:54:24 BlackSnow kernel[0]: IOHIDSystem::relativePointerEventGated: VBL too high (21134604), capping to 20000000 They only appear every now and then. Is this to do with SpeedStepping? Thanks I don't understand how you guys are verifying that your p-state changes are working if none of the tools that test the results are in order. The P-State values I entered in to my DSDT were taken from VoodooMonitor. So if it reports the wrong control values, then I must be using the wrong ones? Link to comment Share on other sites More sharing options...
bcc9 Posted November 13, 2009 Share Posted November 13, 2009 To everyone: If you are using any legacy/dummy HDA.kext, i.e. LegacyHDA.kext, with 1.7.9a4 AppleHDA.kext (10.6.2), please remove BuiltInHDA key from info.plist if having it. That advise is not generally true. If you have a system with nvidia HDMI audio plus another codec, then you need that section to avoid a bunch of sound assertion problems and panics. Basically any system with a nvidia mcp79 chipset such as the dell xps 1340, dell xps 14z. The P-State values I entered in to my DSDT were taken from VoodooMonitor. So if it reports the wrong control values, then I must be using the wrong ones?If you're converting the voltages reported by voodoomonitor back into vid values yourself and you have a 45nm intel cpu then yes. If you're using the control value column, then I'm not sure. Mine are screwy and don't match up with the other tabs. IOHIDSystem::relativePointerEventGated: VBL too high (21134604), capping to 20000000HID+pointer would be your mouse. Probably I/O overflow of some sort. Link to comment Share on other sites More sharing options...
blackosx Posted November 13, 2009 Share Posted November 13, 2009 If you're converting the voltages reported by voodoomonitor back into vid values yourself and you have a 45nm intel cpu then yes. If you're using the control value column, then I'm not sure. Mine are screwy and don't match up with the other tabs. My E7300 is an 45nm CPU. Yes I just copied the values from the control value column reported by VoodooMonitor in to my _PSS method (See attached image) So I believe it's correct. HID+pointer would be your mouse. Probably I/O overflow of some sort. Okay. Thanks Link to comment Share on other sites More sharing options...
bcc9 Posted November 13, 2009 Share Posted November 13, 2009 My E7300 is an 45nm CPU. Yes I just copied the values from the control value column reported by VoodooMonitor in to my _PSS method (See attached image) So I believe it's correct. Well I don't know, it's definitely wrong for my system. With voodoomonitor on the p-state tab, I see: 6x multiplier, 1.068v voltage (which would correspond to a vid of 0x17 and an actual voltage of 1.0000) on the p-state tab: 6x multiplier, 1.180 voltage, 0x61e control (ie a 0x1e vid which is not correct - does not match the SSDT) The 9x multiplier is consistent between those 2 voodoomonitor tabs however. My CPU has super-lfm modes which is probably breaking voodoomonitor's p-state tab completely. Screen shot if you want. Link to comment Share on other sites More sharing options...
blackosx Posted November 13, 2009 Share Posted November 13, 2009 Well I don't know, it's definitely wrong for my system. With voodoomonitor on the p-state tab, I see:6x multiplier, 1.068v voltage (which would correspond to a vid of 0x17 and an actual voltage of 1.0000) on the p-state tab: 6x multiplier, 1.180 voltage, 0x61e control (ie a 0x1e vid which is not correct - does not match the SSDT) The 9x multiplier is consistent between those 2 voodoomonitor tabs however. My CPU has super-lfm modes which is probably breaking voodoomonitor's p-state tab completely. Screen shot if you want. I don't know any more than what I have shown to you, so maybe one of the more knowledgeable people can help throw some light on your finding. Sorry bcc9. Link to comment Share on other sites More sharing options...
mcsmart Posted November 13, 2009 Share Posted November 13, 2009 Does this happen only if you have MSR Tools also running beside speedstep ?I belive that MSR Tool (plus it´s .kext) has some timing/communication problems (and/or interferences voodoopower) which does near freeze my system. I can run speedstep for days, but MSR tools beside not more than a few minutes, than only mouse is moving, rest freeze. OK, without MSR tools I haven't had this problem yet - I guess it was really caused by these tools. Danke @mitch_de Vanilla speedstep is now 100% working on my EP45-DS4 - I didn't even have to add any C-states! Regards, mcsmart Link to comment Share on other sites More sharing options...
leslieking Posted November 13, 2009 Share Posted November 13, 2009 Hi, I have obtained the DSDT and SSDT using ubuntu. I don't understand how can I merge the two files. Someone is able to do this for me? (at least, for cpu0ist). I have EP35-DS3L / Q6600. I would be grateful for any help! thanks! ssdt.zip Link to comment Share on other sites More sharing options...
bcc9 Posted November 13, 2009 Share Posted November 13, 2009 I don't know any more than what I have shown to you, so maybe one of the more knowledgeable people can help throw some light on your finding. Sorry bcc9.For the p-state tab, I believe I already have identified the problem and made a fix. As I posted in the voodoopstate thread, voodoopstate (and voodoopower) are using the wrong vid values for their computed p-state due to roundoff errors (as well as being thrown off by the super-lfm frequencies). See the voodoopstate thread for my fixed version. It looks like voodoomonitor is just replicating the problem in its p-state tab. Link to comment Share on other sites More sharing options...
voodoo1234 Posted November 13, 2009 Share Posted November 13, 2009 Hey Bandes! You got your dsdt file working with the speedstepping on q8200? Is it possible for you to put your dsdt file online so that i can compare yours to my dsdt file? Link to comment Share on other sites More sharing options...
Master Chief Posted November 13, 2009 Share Posted November 13, 2009 Ladies & gentleman - get ready to rumble your dsdt compiling/disassembling New IASL + iASLme Tool (iasl is new, rest same) available - Nov 2009 Version OUT ! Source was out a few hours - mitch compiled again. You cant get it fasterSALES! 100% off http://www.insanelymac.com/forum/index.php?showtopic=189272 Actually you can... I compiled it two days ago Thanks to Lin Ming for not closing the door Link to comment Share on other sites More sharing options...
ƃuıʞ ǝɥʇ Posted November 13, 2009 Share Posted November 13, 2009 Actually you can... I compiled it two days ago Thanks to Lin Ming for not closing the door Yours dosen't work: xyzs-macbook-pro:~ xyz$ /Users/xyz/Desktop/iasl -vo /Users/xyz/Desktop/M50SV_ASUS_SBUS.dsl dyld: unknown required load command 0x80000022 Trace/BPT trap Did you fixed the source? Link to comment Share on other sites More sharing options...
FKA Posted November 13, 2009 Author Share Posted November 13, 2009 Well I don't know, it's definitely wrong for my system. With voodoomonitor on the p-state tab, I see:6x multiplier, 1.068v voltage (which would correspond to a vid of 0x17 and an actual voltage of 1.0000) on the p-state tab: 6x multiplier, 1.180 voltage, 0x61e control (ie a 0x1e vid which is not correct - does not match the SSDT) Hi bcc9 Are you sure that the 6x @1.068v isn't C1? @ 6x my correct voltage should be 1.084v but most of the time it's bouncing around 1.116v when there is maybe 3 > 4% cpu load. It hits 1.084v for short periods with 1 > 2% load and drops to 1.052v with 0 >1% loading - which I assume is C1?! D. Ladies & gentleman - get ready to rumble your dsdt compiling/disassembling New IASL + iASLme Tool (iasl is new, rest same) available - Nov 2009 Version OUT ! Source was out a few hours - mitch compiled again. You cant get it faster SALES! 100% off http://www.insanelymac.com/forum/index.php?showtopic=189272 Nice one mitch - many thanks! Link to comment Share on other sites More sharing options...
leslieking Posted November 13, 2009 Share Posted November 13, 2009 FormerlyKnownAs, where did you get this code in your dsdt? : This page doesn't include your code: http://bit.ly/2zOtkX (as mentioned in first thread). Thanks! Method (_PPC, 0, NotSerialized) { Return (Zero) } Method (_PCT, 0, NotSerialized) { If (LEqual (And (CFGD, 0x00060000), 0x00020000)) { Return (Package (0x02) { ResourceTemplate () { Register (SystemIO, 0x10, // Bit Width 0x00, // Bit Offset 0x0000000000000199, // Address ,) }, ResourceTemplate () { Register (SystemIO, 0x10, // Bit Width 0x00, // Bit Offset 0x0000000000000198, // Address ,) } }) } If (LEqual (And (CFGD, 0x00060000), 0x00040000)) { Return (Package (0x02) { ResourceTemplate () { Register (FFixedHW, 0x00, // Bit Width 0x00, // Bit Offset 0x0000000000000000, // Address ,) }, ResourceTemplate () { Register (FFixedHW, 0x00, // Bit Width 0x00, // Bit Offset 0x0000000000000000, // Address ,) } }) } If (LOr (And (CFGD, 0x4000), And (CFGD, 0x00010000))) { Return (Package (0x02) { ResourceTemplate () { Register (FFixedHW, 0x00, // Bit Width 0x00, // Bit Offset 0x0000000000000000, // Address ,) }, ResourceTemplate () { Register (FFixedHW, 0x00, // Bit Width 0x00, // Bit Offset 0x0000000000000000, // Address ,) } }) } Return (Package (0x02) { ResourceTemplate () { Register (SystemIO, 0x10, // Bit Width 0x00, // Bit Offset 0x0000000000000199, // Address ,) }, ResourceTemplate () { Register (SystemIO, 0x10, // Bit Width 0x00, // Bit Offset 0x0000000000000198, // Address ,) } }) } Method (_PSS, 0, NotSerialized) { If (LEqual (And (CFGD, 0x00060000), 0x00020000)) { Return (SPSS) } If (LEqual (And (CFGD, 0x00060000), 0x00040000)) { Return (NPSS) } If (LOr (And (CFGD, 0x4000), And (CFGD, 0x00010000))) { Return (NPSS) } Return (SPSS) } Name (SPSS, Package (0x03) { Package (0x06) { 0x0C20, 0x000124F8, 0xA0, 0x0A, 0x0820, 0x0820 }, Package (0x06) { 0x0A9C, 0xFDE8, 0xA0, 0x0A, 0x071C, 0x071C }, Package (0x06) { 0x0918, 0xEA60, 0xA0, 0x0A, 0x061A, 0x061A } }) Name (NPSS, Package (0x03) { Package (0x06) { 0x0C20, 0x000124F8, 0x0A, 0x0A, 0x0820, 0x0820 }, Package (0x06) { 0x0A9C, 0xFDE8, 0x0A, 0x0A, 0x071C, 0x071C }, Package (0x06) { 0x0918, 0xEA60, 0x0A, 0x0A, 0x061A, 0x061A } }) } Scope (_PR.CPU1) { Method (_CST, 0, NotSerialized) { Return (^^CPU0._CST ()) } Method (_PPC, 0, NotSerialized) { Return (Zero) } Method (_PCT, 0, NotSerialized) { If (LEqual (And (CFGD, 0x00060000), 0x00020000)) { Return (Package (0x02) { ResourceTemplate () { Register (SystemIO, 0x10, // Bit Width 0x00, // Bit Offset 0x0000000000000199, // Address ,) }, ResourceTemplate () { Register (SystemIO, 0x10, // Bit Width 0x00, // Bit Offset 0x0000000000000198, // Address ,) } }) } If (LEqual (And (CFGD, 0x00060000), 0x00040000)) { Return (Package (0x02) { ResourceTemplate () { Register (FFixedHW, 0x00, // Bit Width 0x00, // Bit Offset 0x0000000000000000, // Address ,) }, ResourceTemplate () { Register (FFixedHW, 0x00, // Bit Width 0x00, // Bit Offset 0x0000000000000000, // Address ,) } }) } If (LOr (And (CFGD, 0x4000), And (CFGD, 0x00010000))) { Return (Package (0x02) { ResourceTemplate () { Register (FFixedHW, 0x00, // Bit Width 0x00, // Bit Offset 0x0000000000000000, // Address ,) }, ResourceTemplate () { Register (FFixedHW, 0x00, // Bit Width 0x00, // Bit Offset 0x0000000000000000, // Address ,) } }) } Return (Package (0x02) { ResourceTemplate () { Register (SystemIO, 0x10, // Bit Width 0x00, // Bit Offset 0x0000000000000199, // Address ,) }, ResourceTemplate () { Register (SystemIO, 0x10, // Bit Width 0x00, // Bit Offset 0x0000000000000198, // Address ,) } }) } Method (_PSS, 0, NotSerialized) { Return (^^CPU0._PSS ()) } } Scope (_PR.CPU2) { Method (_CST, 0, NotSerialized) { Return (^^CPU0._CST ()) } Method (_PPC, 0, NotSerialized) { Return (Zero) } Method (_PCT, 0, NotSerialized) { If (LEqual (And (CFGD, 0x00060000), 0x00020000)) { Return (Package (0x02) { ResourceTemplate () { Register (SystemIO, 0x10, // Bit Width 0x00, // Bit Offset 0x0000000000000199, // Address ,) }, ResourceTemplate () { Register (SystemIO, 0x10, // Bit Width 0x00, // Bit Offset 0x0000000000000198, // Address ,) } }) } If (LEqual (And (CFGD, 0x00060000), 0x00040000)) { Return (Package (0x02) { ResourceTemplate () { Register (FFixedHW, 0x00, // Bit Width 0x00, // Bit Offset 0x0000000000000000, // Address ,) }, ResourceTemplate () { Register (FFixedHW, 0x00, // Bit Width 0x00, // Bit Offset 0x0000000000000000, // Address ,) } }) } If (LOr (And (CFGD, 0x4000), And (CFGD, 0x00010000))) { Return (Package (0x02) { ResourceTemplate () { Register (FFixedHW, 0x00, // Bit Width 0x00, // Bit Offset 0x0000000000000000, // Address ,) }, ResourceTemplate () { Register (FFixedHW, 0x00, // Bit Width 0x00, // Bit Offset 0x0000000000000000, // Address ,) } }) } Return (Package (0x02) { ResourceTemplate () { Register (SystemIO, 0x10, // Bit Width 0x00, // Bit Offset 0x0000000000000199, // Address ,) }, ResourceTemplate () { Register (SystemIO, 0x10, // Bit Width 0x00, // Bit Offset 0x0000000000000198, // Address ,) } }) } Method (_PSS, 0, NotSerialized) { Return (^^CPU0._PSS ()) } } Scope (_PR.CPU3) { Method (_CST, 0, NotSerialized) { Return (^^CPU0._CST ()) } Method (_PPC, 0, NotSerialized) { Return (Zero) } Method (_PCT, 0, NotSerialized) { If (LEqual (And (CFGD, 0x00060000), 0x00020000)) { Return (Package (0x02) { ResourceTemplate () { Register (SystemIO, 0x10, // Bit Width 0x00, // Bit Offset 0x0000000000000199, // Address ,) }, ResourceTemplate () { Register (SystemIO, 0x10, // Bit Width 0x00, // Bit Offset 0x0000000000000198, // Address ,) } }) } If (LEqual (And (CFGD, 0x00060000), 0x00040000)) { Return (Package (0x02) { ResourceTemplate () { Register (FFixedHW, 0x00, // Bit Width 0x00, // Bit Offset 0x0000000000000000, // Address ,) }, ResourceTemplate () { Register (FFixedHW, 0x00, // Bit Width 0x00, // Bit Offset 0x0000000000000000, // Address ,) } }) } If (LOr (And (CFGD, 0x4000), And (CFGD, 0x00010000))) { Return (Package (0x02) { ResourceTemplate () { Register (FFixedHW, 0x00, // Bit Width 0x00, // Bit Offset 0x0000000000000000, // Address ,) }, ResourceTemplate () { Register (FFixedHW, 0x00, // Bit Width 0x00, // Bit Offset 0x0000000000000000, // Address ,) } }) } Return (Package (0x02) { ResourceTemplate () { Register (SystemIO, 0x10, // Bit Width 0x00, // Bit Offset 0x0000000000000199, // Address ,) }, ResourceTemplate () { Register (SystemIO, 0x10, // Bit Width 0x00, // Bit Offset 0x0000000000000198, // Address ,) } }) } Method (_PSS, 0, NotSerialized) { Return (^^CPU0._PSS ()) } } } Link to comment Share on other sites More sharing options...
Bandes Posted November 13, 2009 Share Posted November 13, 2009 Hey Bandes! You got your dsdt file working with the speedstepping on q8200? Is it possible for you to put your dsdt file online so that i can compare yours to my dsdt file? dsdt_sound_lpc_cpunew9.zip p-states work, c-states doesnt. i ve added some patches to the dsdt (rtc, hda for 888 sound, lpc, something about usb/ehci stuff) but i think there are some things more to improve. system seems to be unstable now with apple cpu management. i have random freezes sometimes. it was rock stable with disabler and bios-management. on random occurences, after bootup my ps2 keyboard is not working, and sometimes usb mouse neither. dont know why is this. looks like if i dont press any key at chameleon boot screen,sometimes it does not see a keyboard after that. Link to comment Share on other sites More sharing options...
FKA Posted November 13, 2009 Author Share Posted November 13, 2009 FormerlyKnownAs, where did you get this code in your dsdt? :This page doesn't include your code: http://bit.ly/2zOtkX (as mentioned in first thread). Thanks! Hi zoliky Firstly can you please post long bits of code as a text file rather than code box - this thread is long enough. To be honest I can't remember - it looks like my cpupm and ist parts of my SSDT. This is what I'm using at the mo' - a culmination of several ppl's work - mainly mm67 and Chiefs suggestions: Scope (_PR) { Processor (CPU0, 0x00, 0x00000410, 0x06) {} Processor (CPU1, 0x01, 0x00000410, 0x06) {} Processor (CPU2, 0x02, 0x00000410, 0x06) {} Processor (CPU3, 0x03, 0x00000410, 0x06) {} } Scope (_PR.CPU0) { Method (_PSS, 0, NotSerialized) { Return (Package (0x03) { Package (0x06) { Zero, Zero, 0x0A, 0x0A, 0x0820, Zero }, Package (0x06) { Zero, Zero, 0x0A, 0x0A, 0x071C, One }, Package (0x06) { Zero, Zero, 0x0A, 0x0A, 0x061A, 0x02 } }) } Method (_PSD, 0, NotSerialized) { Return (Package (0x05) { 0x05, Zero, Zero, 0xFC, 0x04 }) } Method (_CST, 0, NotSerialized) { Return (Package (0x02) { One, Package (0x04) { ResourceTemplate () { Register (FFixedHW, 0x01, // Bit Width 0x02, // Bit Offset 0x0000000000000000, // Address 0x01, // Access Size ) }, One, 0x9D, 0x03E8 } }) } } Scope (_PR.CPU1) { Method (_PSS, 0, NotSerialized) { Return (^^CPU0._PSS ()) } Method (_PSD, 0, NotSerialized) { Return (^^CPU0._PSD ()) } Method (_CST, 0, NotSerialized) { Return (Package (0x04) { 0x03, Package (0x04) { ResourceTemplate () { Register (FFixedHW, 0x01, // Bit Width 0x02, // Bit Offset 0x0000000000000000, // Address ,) }, One, Zero, 0x03E8 }, Package (0x04) { ResourceTemplate () { Register (FFixedHW, 0x08, // Bit Width 0x00, // Bit Offset 0x0000000000000414, // Address ,) }, 0x02, One, 0x01F4 }, Package (0x04) { ResourceTemplate () { Register (FFixedHW, 0x08, // Bit Width 0x00, // Bit Offset 0x0000000000000415, // Address ,) }, 0x03, 0x55, 0xFA } }) } } Scope (_PR.CPU2) { Method (_PSS, 0, NotSerialized) { Return (^^CPU0._PSS ()) } Method (_PSD, 0, NotSerialized) { Return (^^CPU0._PSD ()) } Method (_CST, 0, NotSerialized) { Return (^^CPU1._CST ()) } } Scope (_PR.CPU3) { Method (_PSS, 0, NotSerialized) { Return (^^CPU0._PSS ()) } Method (_PSD, 0, NotSerialized) { Return (^^CPU0._PSD ()) } Method (_CST, 0, NotSerialized) { Return (^^CPU1._CST ()) } } And yes Chief the _PSD method with 0xFC does seem to make the transitions more fluid! D. Link to comment Share on other sites More sharing options...
leslieking Posted November 13, 2009 Share Posted November 13, 2009 Thanks for your answer FormerlyKnownAs. I have attached my dsdt. I receive this error: dsdt.dsl 5746: Processor (CPU0, 0x00, 0x00000410, 0x06) {} Error 4056 - ^ Name already exists in scope (CPU0) ASL Input: dsdt.dsl - 5931 lines, 194179 bytes, 2483 keywords Compilation complete. 1 Errors, 1 Warnings, 0 Remarks, 60 Optimizations Someone check my dsdt please? I would like to add these p_states (Q6600 - 2.4Ghz - EP35-DS3L): I would be grateful for any help! dsdt.dsl.zip Link to comment Share on other sites More sharing options...
nvflash Posted November 13, 2009 Share Posted November 13, 2009 If we look with Reggie SE at IA32_MISC_ENABLE, will this let us know what C-States can be actively entered? Link to comment Share on other sites More sharing options...
Recommended Posts