Jump to content

DSDT - Vanilla Speedstep - Generic Scope (_PR)


  • Please log in to reply
1945 replies to this topic

#341
yeehaa

yeehaa

    InsanelyMac Protégé

  • Members
  • PipPip
  • 81 posts
  • Gender:Male
  • Location:FL, USA

My T60 has PSS and CST tables in the BIOS, so I don't have the error msgs in kernel.log. In this case, adding them to DSDT won't help.
The problem is that if I do not disable AppleIntelCPUPowermanagement.kext, it will mostly cause a KP within 5 minutes after the desktop show up. In some rare boots, it works just fine without KP, but you can not figure out the reason. This is all in 32 bit kernel.
With 64 bit kernel, AppleIntelCPUPowermanagement.kext won't cause KP at all. But another issue pop out, multiple instances of SoftwareUpdateCheck mysteriously keep launching by itself and eat a lot of CPU time which may eventually cause a KP.
I have to stick to NullCPUPowermanagemnet.kext which remove all the problems.


did u try the IRQ fixes? the one's posted by king over there at project?

#342
oldnapalm

oldnapalm

    InsanelyMac V.I.P.

  • Moderators
  • 6,838 posts
  • Gender:Male
  • Location:Brazil
Hey Master Chief, thanks for the great explanation.

I followed your steps and got very close results (4 values under PerformanceStateArray after adding _PSS for my CPU and Step2_0), except that after adding _CST from MacPro3,1 temperatures are still high (> 60º C idle). The main difference here is that my SSDT doesn't have PDC0 so I gave a shot in the dark and used 0x80000000.

Using NullCPUPowerManagement.kext and C1E enabled in BIOS I have decent temperatures (40-43º C idle) and CPU-i shows changes in frequency/multiplier/voltage, but only for cores 1 and 2, and between 2 states (my CPU has 4).

In Leopard SpeedStep works for all cores using Superhai's VoodooPowerMini.kext, waiting for 64 bit version.

#343
Brett Whinnen

Brett Whinnen

    InsanelyMac Geek

  • Members
  • PipPipPip
  • 146 posts
  • Gender:Male
  • Location:Bne, AU
Well I had some interesting findings this morning...

I've stripped all the SSDT related information out of my DSDT (also removed the DropSSDT=Y from com.apple.Boot.plist) as I wanted to start over again from the beginning...

Well lo and behold I have full speedstep enabled. CoolBook Controller lists the same states, the IORegistryExplorer reports the same 6 power states. I do get the "ACPI_SMC_PlatformPlugin::registerLPCDriver - WARNING - LPC device initialization failed: C-state power management not initialized" error still but I'll start on that again later...

Under ACPITables I can see my DSDT loaded as well as a separate SSDT.

I'm confused! The only difference between this DSDT and the old one that was used for us M1530 laptop owners is the HPET is actually closer to that of a real Mac and thus the AppleIntelCPUPowerManagement now loads fine.

This is my _PR scope now...
[codebox]
Scope (_PR)
{
Processor (CPU0, 0x00, 0x00001010, 0x06)
{
}

Processor (CPU1, 0x01, 0x00001010, 0x06)
{
}
}
[/codebox]

I no longer have the SSDT definition in there, no _PSS, nothing. So I'm now just throwing my hands up in the air thinking I did all that work to get PSTATES working when they would vanilla... So the issue must be with a mis-match in the number of CSTATES I have in my SSDT compared to what ACPI_SMC is expecting to see? Would that be a fair call?

Thanks again for looking...

Brett

#344
thestevo

thestevo

    InsanelyMac Chuck Norris

  • Members
  • PipPipPipPipPipPipPip
  • 550 posts
  • Gender:Male
  • Interests:A piano that's in tune and hardware that I don't have to write drivers for.
Well, the P-States provided by the system are wrong, as I explained in a PM. Not only is there not a proper entry for IDA, but it doesn't allow one to use the 600MHz P-State either.

#345
Brett Whinnen

Brett Whinnen

    InsanelyMac Geek

  • Members
  • PipPipPip
  • 146 posts
  • Gender:Male
  • Location:Bne, AU

Well, the P-States provided by the system are wrong, as I explained in a PM. Not only is there not a proper entry for IDA, but it doesn't allow one to use the 600MHz P-State either.


Was that to me? If so I don't have a PM from you outlining any issues with the system _PSS values, just one asking about getting _PSS values working ;)

Even searching Intel's site I didn't see a 600MHz pstate for the T9300, the lowest I saw was 800MHz...

But anyways any further info you have found is always good :)

#346
Master Chief

Master Chief

    Just Chief

  • Members
  • PipPipPipPipPipPipPipPip
  • 1,176 posts
  • Gender:Male

did u try the IRQ fixes? the one's posted by king over there at project?

I would like to call that a "workaround" and not a "fix". Why? Well, let's have a look at the RTC from a real MacPro3,1:
Device (RTC)				{					Name (_HID, EisaId ("PNP0B00"))					Name (BUF0, ResourceTemplate ()					{						IO (Decode16,							0x0070,			 // Range Minimum							0x0070,			 // Range Maximum							0x01,			   // Alignment							0x08,			   // Length							)					})					Name (BUF1, ResourceTemplate ()					{						IO (Decode16,							0x0070,			 // Range Minimum							0x0070,			 // Range Maximum							0x01,			   // Alignment							0x08,			   // Length							)						IRQNoFlags ()							{8}					})					Method (_CRS, 0, Serialized)					{						If (HPAE)						{							Return (BUF0)						}						Return (BUF1)					}				}

And here's TIMR from the same MacPro3,1:
Device (TIMR)				{					Name (_HID, EisaId ("PNP0100"))					Name (BUF0, ResourceTemplate ()					{						IO (Decode16,							0x0040,			 // Range Minimum							0x0040,			 // Range Maximum							0x01,			   // Alignment							0x04,			   // Length							)						IO (Decode16,							0x0050,			 // Range Minimum							0x0050,			 // Range Maximum							0x10,			   // Alignment							0x04,			   // Length							)					})					Name (BUF1, ResourceTemplate ()					{						IO (Decode16,							0x0040,			 // Range Minimum							0x0040,			 // Range Maximum							0x01,			   // Alignment							0x04,			   // Length							)						IO (Decode16,							0x0050,			 // Range Minimum							0x0050,			 // Range Maximum							0x10,			   // Alignment							0x04,			   // Length							)						IRQNoFlags ()							{0}					})					Method (_CRS, 0, Serialized)					{						If (HPAE)						{							Return (BUF0)						}						Return (BUF1)					}				}

Now note the if (HPAE) {} clause here, which is what makes it fly on a MacPro3,1 However, nobody ever explained, really, why you should remove the IRQ's. Is that because they simply never solved this piece of the puzzle, or am I missing something here?

It is still very early for me, but what was HPAE again? Let's start with that first. Thanks.

p.s. Here's a clue:
OperationRegion (RCRB, SystemMemory, 0xFED1C000, 0x4000)    Field (RCRB, DWordAcc, Lock, Preserve)    {                Offset (0x1000),                 Offset (0x3000),                 Offset (0x3404),         HPAS,   2,             ,   5,         HPAE,   1,                 Offset (0x3418),             ,   1,         PATD,   1,         SATD,   1,         SMBD,   1,         HDAD,   1,         A97D,   1,                 Offset (0x341A),         RP1D,   1,         RP2D,   1,         RP3D,   1,         RP4D,   1,         RP5D,   1,         RP6D,   1    }
And here's mine:
OperationRegion (RCRB, SystemMemory, 0xFED1F404, 0x04)
	Field (RCRB, AnyAcc, NoLock, Preserve)
	{
		HPAS,   2, 
			,   5, 
		HPAE,   1, 
				Offset (0x04)
	}
It's not that big because we don't need the references to the rest. BTW: Do any of these ring a bell? But don't tell me because I know what they are :D

And here's an example, in this case my HPET from my hack:
Device (HPET)                {                    Name (_HID, EisaId ("PNP0103"))                    Name (BUF0, ResourceTemplate ()                    {                        IRQNoFlags ()                            {0}                        IRQNoFlags ()                            {8}                        Memory32Fixed (ReadOnly,                            0xFED00000,         // Address Base                            0x00000400,         // Address Length                            _Y09)                    })                    Method (_STA, 0, NotSerialized)                    {                        If (LGreaterEqual (OSYS, 0x07D1))                        {                            If (HPAE)                            {                                Return (0x0F)                            }                        }                        Else                        {                            If (HPAE)                            {                                Return (0x0B)                            }                        }                        Return (Zero)                    }                    Method (_CRS, 0, NotSerialized)                    {                        if (HPAE)                        {                            CreateDWordField (CRS, \_SB.PCI0.LPCB.HPET._Y09._BAS, HPT0)                            Multiply (HPAS, 0x1000, Local0)                            Add (Local0, 0xFED00000, HPT0)                        }                        Return (BUF0)                    }                }
Making it look even more like a real MacPro3,1 – be it a little more optimized – but more importantly... no stutter for me :)

Hey Master Chief, thanks for the great explanation.

You're welcome.

I followed your steps and got very close results (4 values under PerformanceStateArray after adding _PSS for my CPU and Step2_0), except that after adding _CST from MacPro3,1 temperatures are still high (> 60º C idle). The main difference here is that my SSDT doesn't have PDC0 so I gave a shot in the dark and used 0x80000000.

ASUS uses TYPE instead of PDC0 and I think that was why FormelyKnownAs asked you to read the thread ;)

#347
THe KiNG

THe KiNG

    InsanelyMac Legend

  • Gurus
  • 707 posts
  • Gender:Male

I would like to call that a "workaround" and not a "fix". Why? Well, let's have a look at the RTC from a real MacPro3,1:

When you compare two x58 boards(what I did) you should use DSDT from MacPro4,1, and is not a workaround is a fix, Apple chose to not use IRQ's on RTC and TIMR and I explained why it cause trouble on our hacks.
Anyway those checks from MacPro3,1 does the same thing, returns _CRS w/o IRQ's when HPET has _STA 0x0F, so you can remove them to save space and code in your DSDT.

#348
Master Chief

Master Chief

    Just Chief

  • Members
  • PipPipPipPipPipPipPipPip
  • 1,176 posts
  • Gender:Male

When you compare two x58 boards(what I did) you should use DSDT from MacPro4,1, and is not a workaround is a fix, Apple chose to not use IRQ's on RTC and TIMR and I explained why it cause trouble on our hacks.
Anyway those checks from MacPro3,1 does the same thing, returns _CRS w/o IRQ's when HPET has _STA 0x0F, so you can remove them to save space and code in your DSDT.

Let me digg up a source file, from Apple, and get back to you a.s.a.p.

EDIT: I'll add it when I find it – I can't even remember where or when I've seen it (:

#349
oldnapalm

oldnapalm

    InsanelyMac V.I.P.

  • Moderators
  • 6,838 posts
  • Gender:Male
  • Location:Brazil

ASUS uses TYPE instead of PDC0 and I think that was why FormelyKnownAs asked you to read the thread ;)


Thank you.
Anyways, TYPE value is 0x80000000 here, so no changes at all.

#350
dong

dong

    InsanelyMac Sage

  • Retired Developers
  • 366 posts
  • Gender:Male

did u try the IRQ fixes? the one's posted by king over there at project?

[Update]
Well, it turned out the first reboot after IRQ modification happened to be the rare case where there is no KP. Following reboots result in KP just like before. Sadly it does not solve my KP problem.

I'm here to confirm that this works for me, no more KP.
Thanks THe King a lot for the tip.

My PSS contains 4 states, now the question is why the cpu frequency only changed between the highest and lowest although cpu-i shows 7 states here:
Posted Image

#351
Master Chief

Master Chief

    Just Chief

  • Members
  • PipPipPipPipPipPipPipPip
  • 1,176 posts
  • Gender:Male

Thank you.
Anyways, TYPE value is 0x80000000 here, so no changes at all.

Ah you've seen this Name (TYPE, 0x80000000) and expect it to stay like that. Newsflash ;) it will be initialized by OSPM but bits 5, 6 and 7 won't be set for the first CPU (that is also why you see checks for 0x20 in _CST).

My PSS contains 4 states, now the question is why the cpu frequency only changed between the highest and lowest although cpu-i shows 7 states here:
<snip />

Yeah, that can be misleading: CPU-i shows calculated values, not the values you've added. This data however can be pretty helpful in combination with the P-State Calculator.

Also, I'm afraid that I had bad news for you. You may have fixed the KP, but you apparently still only have two functional P-States. More work to be done so to speak.

#352
yeehaa

yeehaa

    InsanelyMac Protégé

  • Members
  • PipPip
  • 81 posts
  • Gender:Male
  • Location:FL, USA

I'm here to confirm that this works for me, no more KP. :thumbsup_anim:
Thanks THe King a lot for the tip.

My PSS contains 4 states, now the question is why the cpu frequency only changed between the highest and lowest although cpu-i shows 7 states here:


you can add all the pstates (and just the _PSS) to your dsdt and will get perfect switching between them. i had only three in my ssdt, but added 6 more to my dsdt and it is working alright

#353
oldnapalm

oldnapalm

    InsanelyMac V.I.P.

  • Moderators
  • 6,838 posts
  • Gender:Male
  • Location:Brazil

Ah you've seen this Name (TYPE, 0x80000000) and expect it to stay like that. Newsflash ;) it will be initialized by OSPM but bits 5, 6 and 7 won't be set for the first CPU (that is also why you see checks for 0x20 in _CST).


Thanks man, now I (finally) got it.
It's working just adding CST and setting SMproductname as "MacPro3,1" in smbios. I had the stuttering sound problem, but fixed removing IRQ from PIC and TMR (workaround, you name it).

One last question: my DSDT has OperationRegion (STBL, SystemMemory, 0x7FF8E0D0, 0x01D2) under Processor, so I woudn't need to add calculated PSS, right? But if I don't it looks like I have only 2 working P-states (2 values under PerformanceStateArray), and if I add calculated values (took from CPU-i running in Leopard with VoodooPower) I have 4. Does it mean PSS from SSDT are wrong?

Thank you FormerlyKnownAs for the topic, you were right, maybe if I had took the time to read the whole thread I wouldn't need to ask and create more pollution, sorry for that.

#354
Master Chief

Master Chief

    Just Chief

  • Members
  • PipPipPipPipPipPipPipPip
  • 1,176 posts
  • Gender:Male

Thanks man, now I (finally) got it.

No worries. We're all here to learn new stuff after all.

It's working just adding CST and setting SMproductname as "MacPro3,1" in smbios. I had the stuttering sound problem, but fixed removing IRQ from PIC and TMR.

Welcome to the club :P

One last question: my DSDT has OperationRegion (STBL, SystemMemory, 0x7FF8E0D0, 0x01D2) under Processor, so I woudn't need to add calculated PSS, right? But if I don't it looks like I have only 2 working P-states (2 values under PerformanceStateArray), and if I add calculated values (took from CPU-i running in Leopard with VoodooPower) I have 4. Does it mean PSS from SSDT are wrong?

That's up to you: you may want to add a customized _PSS object, one with four P-States in it, but you may skip this step when you're happy with two. Let's just say that the _PSS from your SSDT is a bit more "limited".

you can add all the pstates (and just the _PSS) to your dsdt and will get perfect switching between them. i had only three in my ssdt, but added 6 more to my dsdt and it is working alright

He wrote: "My PSS contains 4 states..." and thus he already has a _PSS object (right?) but it is hard to tell without having the actual DSDT at hand.

#355
dong

dong

    InsanelyMac Sage

  • Retired Developers
  • 366 posts
  • Gender:Male

He wrote: "My PSS contains 4 states..." and thus he already has a _PSS object (right?) but it is hard to tell without having the actual DSDT at hand.

I did not put the _PSS object into DSDT. It's in SSDT and I guess there is no need to move it to DSDT. The 4 states can be observed in IORegistry, with the values (corresponding to 2000, 1667, 1333 and 1000MHz) from SSDT. If it helps, here are the DSDT and related SSDTs:Attached File  DSDT_SSDT.zip   38.61KB   11 downloads
I modified my last post. The IRQ modification did not solve my KP problem. The first reboot happened to be a rare good case that system run well. Following reboots not work. Before KP, the console has lots of such messages (content in () varies):
9/30/09 1:34:10 PM	com.apple.launchd[1]	(com.apple.locationd) Throttling respawn: Will start in 1 seconds
9/30/09 1:34:10 PM	com.apple.launchd.peruser.501[146]	(com.apple.PreferenceSyncAgent) Throttling respawn: Will start in 2 seconds
9/30/09 1:34:10 PM	com.apple.launchd.peruser.501[146]	(com.apple.ReportCrash) Throttling respawn: Will start in 3 seconds


#356
yeehaa

yeehaa

    InsanelyMac Protégé

  • Members
  • PipPip
  • 81 posts
  • Gender:Male
  • Location:FL, USA

That's up to you: you may want to add a customized _PSS object, one with four P-States in it, but you may skip this step when you're happy with two. Let's just say that the _PSS from your SSDT is a bit more "limited".


He wrote: "My PSS contains 4 states..." and thus he already has a _PSS object (right?) but it is hard to tell without having the actual DSDT at hand.


yeah. but he had a complaint that they were not switchin properly and that he wanted all 7 of them. :)

#357
Brett Whinnen

Brett Whinnen

    InsanelyMac Geek

  • Members
  • PipPipPip
  • 146 posts
  • Gender:Male
  • Location:Bne, AU

So the issue must be with a mis-match in the number of CSTATES I have in my SSDT compared to what ACPI_SMC is expecting to see? Would that be a fair call?


Anybody got a comment on that? That the CSTATES are not loaded because ACPI_SMC_Plugin is looking for a certain number of CSTATES in the SSDT (based on a model number) and if it gets a mismatch it doesn't load them?

I've attached my SSDT1.dsl for reference. Which has my laptops available CSTATES. Is there an easy way to identify which of those relates to which CSTATE?

Attached File  SSDT1.dsl.zip   1.39KB   13 downloads

I'm currently running a MacBookPro5,1 as my model identifier, if I run a MacBookPro4,1 I get an issue with Pstates (as I only have 6 but it is expecting 9, still loads the 6 though), it still has the LPC based error for CSTATES but I do get a CState entry in the ACPI_SMC section of IOReg that says 'True'...

Thanks,

Brett

#358
Master Chief

Master Chief

    Just Chief

  • Members
  • PipPipPipPipPipPipPipPip
  • 1,176 posts
  • Gender:Male

Anybody got a comment on that? That the CSTATES are not loaded because ACPI_SMC_Plugin is looking for a certain number of CSTATES in the SSDT (based on a model number) and if it gets a mismatch it doesn't load them?

I would say no, but let me change mine to a MacBookPro[4/5],1 and see what happens B)

Edit: Right. No problem when I use "MacBookPro5,1" data, but with "MacBookPro4,1" data I get:

"WARNING - ACPI_SMC_CtrlLoop::initCPUCtrlLoop - no sub-config match for P5K PRO with 4 p-states, using default stepper instead"

Note: Never mind the "P5K PRO" here because I replaced "MacBookPro4,1" in the Info.plist with "P5K PRO" (that's the beauty of doing stuff like this).

And I also don't have a CSTinfo property. This is however easily to explain since under: CtrlLoopArray -> PLimitDict -> MacBookPro4,1 there's a property called: num-states which is set to 9 while there's no limit for:

MacBook5,1
MacBook5,2
MacBookPro5,1
MacBookPro5,2
MacBookPro5,3
MacBookPro5,4
MacBookPro5,5
MacPro3,1
Macmini3,1
iMac9,1

The others with limited P-States are:

MacBookAir1,1 (4, 6 or 6 P-States)
MacBookAir2,1 (2, 3 or 4 P-States)

This is also what THe KiNG addressed in post #261.

I've attached my SSDT1.dsl for reference. Which has my laptops available CSTATES. Is there an easy way to identify which of those relates to which CSTATE?

Yes. Let's pick one from your DSDT and I'll add some comments to it:
Return (Package (0x02){    0x01,  // Number of C-States    Package (0x04)    {        ResourceTemplate ()        {            Register (FFixedHW,             0x00,  // Bit Width            0x00,  // Bit Offset            0x0000000000000000,  // Address            ,)        },        0x01,  // C-State aka C1        0x9D,  //  Latency in microseconds (worse case) to change C-State.        0x03E8  // Average power consumption in milliwatt (per core).    }})
Make sure to (re)read post #46 and post #58 :)

#359
Brett Whinnen

Brett Whinnen

    InsanelyMac Geek

  • Members
  • PipPipPip
  • 146 posts
  • Gender:Male
  • Location:Bne, AU

I would say no, but let me change mine to a MacBookPro[4/5],1 and see what happens :rolleyes:

Edit: Right. No problem when I use "MacBookPro5,1" data, but with "MacBookPro4,1" data I get:

"WARNING - ACPI_SMC_CtrlLoop::initCPUCtrlLoop - no sub-config match for P5K PRO with 4 p-states, using default stepper instead"

Note: Never mind the "P5K PRO" here because I replaced "MacBookPro4,1" in the Info.plist with "P5K PRO" (that's the beauty of doing stuff like this).

And I also don't have a CSTinfo property. This is however easily to explain since under: CtrlLoopArray -> PLimitDict -> MacBookPro4,1 there's a property called: num-states which is set to 9 while there's no limit for:

MacBook5,1
MacBook5,2
MacBookPro5,1
MacBookPro5,2
MacBookPro5,3
MacBookPro5,4
MacBookPro5,5
MacPro3,1
Macmini3,1
iMac9,1

The others with limited P-States are:

MacBookAir1,1 (4, 6 or 6 P-States)
MacBookAir2,1 (2, 3 or 4 P-States)

This is also what TheKing addressed in post #261.


Yeah got that bit already :) I modified the entry for MacBookPro4,1 and set number of states to 6 (from 9) and got rid of the error above.

Yes. Let's pick one from your DSDT and I'll add some comments to it:

Return (Package (0x02){    0x01,  // Number of C-States    Package (0x04)    {        ResourceTemplate ()        {            Register (FFixedHW,             0x00,  // Bit Width            0x00,  // Bit Offset            0x0000000000000000,  // Address            ,)        },        0x01,  // C-State aka C1        0x9D,  //  Latency in microseconds (worse case) to change C-State.        0x03E8  // Average power consumption in milliwatt (per core).    }})
Make sure to (re)read post #46 and post #58 :P


Now that helps, re-reading those posts now I'm looking further into things, I'd forgotten about those posts, specially #58.

The question of the day is looking at a couple where 3 C-states are defined, the latency is 0x01 for both C1 and C2, that doesn't seem very long at all... So would some other value change (which are only CFGD or PDCx) that would then determine which of the multiple C-States would be used?

Does CFGD ever change from the value set in the SSDT table?

Thanks for having a look!

#360
Master Chief

Master Chief

    Just Chief

  • Members
  • PipPipPipPipPipPipPipPip
  • 1,176 posts
  • Gender:Male

...The question of the day is looking at a couple where 3 C-states are defined, the latency is 0x01 for both C1 and C2, that doesn't seem very long at all... So would some other value change (which are only CFGD or PDCx) that would then determine which of the multiple C-States would be used?

I can't help you with the first part of your question, but CFGD is more or less static (see below). And what I know about PDCx (or TYPE for ASUS boards) is that the value for the first CPU core is different – this to block it from entering higher C-States. You could verify this yourself, but it is a painstakingly slow process, trust me I've been there already. Anyway, it is bit 9 (0x0200) in your _CST that does this job:
If (And (CFGD, 0x0200))
The other bits/values can be found in the table in post #71

Does CFGD ever change from the value set in the SSDT table?

Not really. But the value depends on BIOS settings (where available). See also post #293 by keeza

Thanks for having a look!

You're welcome.





1 user(s) are reading this topic

0 members, 1 guests, 0 anonymous users

© 2014 InsanelyMac  |   News  |   Forum  |   Downloads  |   OSx86 Wiki  |   Mac Netbook  |   PHP hosting by CatN  |   Designed by Ed Gain  |   Logo by irfan  |   Privacy Policy