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

[Alexandre "Sunny" Kovalenko]

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.

-- 
Alexandre "Sunny" Kovalenko (Олександр Коваленко)