How/why would dev.cpu.0.freq_levels change??!?

Kevin Oberman oberman at es.net
Tue Jul 1 16:17:19 UTC 2008


> From: "Alexandre \"Sunny\" Kovalenko" <gaijin.k at gmail.com>
> Date: Tue, 01 Jul 2008 08:19:58 -0400
> Sender: owner-freebsd-acpi at freebsd.org
> 
> On Sun, 2008-06-29 at 17:45 -0700, David Wolfskill wrote:
> > On Sun, Jun 29, 2008 at 06:43:36PM -0400, Alexandre Sunny Kovalenko wrote:
> > > I am coming in late in the thread, so if I have misunderstood your
> > > problem, I do apologize.
> > 
> > Not at all; thank you for your suggestions!
> > 
> > > ...
> > > > * As you can see, this can lead to the "interesting" situation that the
> > > >   current CPU frequency is higher than the maximum "available."
> > > >From my (somewhat limited) understanding of the ACPI spec, BIOS can
> > > change _PSS object (one containing available clock frequencies) and
> > > issue notification to the OS to reevaluate said object. There is no
> > > requirement that BIOS change current CPU frequency while doing that.
> > 
> > OK; I confess ignorance on that score: I'm posting to -acpi because I
> > rather suspect that ACPI is (at least) profoundly implicated in what's
> > going on, if not responsible for it.
> > 
> > > You can try to dump your ASL and see if anything there messes up with
> > > _PSS and then issues Notify (xxx.CPU0, 0x80) on the same breath. Killing
> > > that piece of ASL dead should ensure constant CPU frequencies set. ???You
> > > can post your ASL someplace where I can get to it, I just could not
> > > promise that I'll understand it much better than you.
> > 
> > I ran
> > 
> > 	sudo acpidump -dt -o >laptop.i8200.dsdt >laptop.i8200.asl
> > 
> > and placed the results in www.catwhisker.org:~david/public_html/FreeBSD/,
> > so <http://www.catwhisker.org/~david/FreeBSD/laptop.i8200.asl> and
> > <http://www.catwhisker.org/~david/FreeBSD/laptop.i8200.dsdt> should
> > work.  I just tried it from my laptop (sick as it is), and the MD5
> > hashes matched.  They are:
> > 
> > g1-60(6.3-S)[6] md5 laptop.i8200.*
> > MD5 (laptop.i8200.asl) = 7c83c27ad30bbd0957f10a5a3ffc90e5
> > MD5 (laptop.i8200.dsdt) = c290ab9be7c97eb7ae98523a5f5a4ddc
> > g1-60(6.3-S)[7] 
> There is definitely some logic to figure out set of frequencies to
> return:
> 
>             Method (_PSS, 0, NotSerialized)
>             {
>                 SX10 ()
>                 SX30 (0x0B)
>                 SX11 ()
>                 Index (PSSX, 0x00, Local0)
>                 Store (SX42 (), Index (DerefOf (Local0), 0x00))
>                 Store (SX42 (), Index (DerefOf (Local0), 0x01))
>                 Store (SX42 (), Index (DerefOf (Local0), 0x02))
>                 Store (SX42 (), Index (DerefOf (Local0), 0x03))
>                 Store (SX40 (), Index (DerefOf (Local0), 0x04))
>                 Store (SX40 (), Index (DerefOf (Local0), 0x05))
>                 Index (PSSX, 0x01, Local1)
>                 Store (SX42 (), Index (DerefOf (Local1), 0x00))
>                 Store (SX42 (), Index (DerefOf (Local1), 0x01))
>                 Store (SX42 (), Index (DerefOf (Local1), 0x02))
>                 Store (SX42 (), Index (DerefOf (Local1), 0x03))
>                 Store (SX40 (), Index (DerefOf (Local1), 0x04))
>                 Store (SX40 (), Index (DerefOf (Local1), 0x05))
>                 SX12 ()
>                 Return (PSSX)
>             }
> 
> 
> and there is definitely a condition when OS is asked to reevaluate the
> list:
> 
>     Method (SMIE, 0, NotSerialized)
>     {
>         Store (SMI (0x96, 0x00), Local0)
>         If (And (Local0, 0x01))
>         {
>             Notify (\_TZ.THM, 0x80)
>         }
> 
>         If (And (Local0, 0x02))
>         {
>             Notify (\_SB.PCI0.AGP.VID, 0x80)
>         }
> 
>         If (And (Local0, 0x04))
>         {
>             Notify (\_SB.BAT0, 0x81)
>             Notify (\_SB.BAT1, 0x81)
>         }
> 
>         If (And (Local0, 0x08))
>         {
>             Notify (\_PR.CPU0, 0x80)   <=============================
>         }
>     }
> 
> What is somewhat puzzling, is that _PSS above seems to return two
> frequencies only, and your freq_levels output show more than that. Once
> you get it back from the repair shop, and, provided you still feel
> adventurous, we can try to sprinkle some prints around _PSS read and see
> what gives. Let me know if and when you are interested.
> 
> However, given what I am looking at, I am inclined to guess that a)
> there is the reason behind the _PSS change. b) the cpufreq driver you
> are using disagrees with it.

There are only two "real" frequencies on this CPU. Looks like a P4
without EST. In any case, the other "frequencies" are created by P4TCC
which performs the same function as throttling, but in a different
way. P4TCC works a bit better than throttling, but neither is a big
win. The Speedstep one is the big winner, here.

P4TCC will create 8 freq values for each "Real" frequency for a total of
16 frequencies. If the BIOS disabled the faster speed, there should only
be 8 available.
-- 
R. Kevin Oberman, Network Engineer
Energy Sciences Network (ESnet)
Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab)
E-mail: oberman at es.net			Phone: +1 510 486-8634
Key fingerprint:059B 2DDF 031C 9BA3 14A4  EADA 927D EBB3 987B 3751
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 224 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-acpi/attachments/20080701/52886ee6/attachment.pgp


More information about the freebsd-acpi mailing list