Date: Tue, 01 Jul 2008 09:17:18 -0700 From: "Kevin Oberman" <oberman@es.net> To: "Alexandre \"Sunny\" Kovalenko" <gaijin.k@gmail.com> Cc: freebsd-acpi@freebsd.org, David Wolfskill <david@catwhisker.org> Subject: Re: How/why would dev.cpu.0.freq_levels change??!? Message-ID: <20080701161718.CB0B745047@ptavv.es.net> In-Reply-To: Your message of "Tue, 01 Jul 2008 08:19:58 EDT." <1214914799.1064.12.camel@RabbitsDen>
next in thread | previous in thread | raw e-mail | index | archive | help
--==_Exmh_1214929038_54298P Content-Type: text/plain; charset=us-ascii Content-Disposition: inline > From: "Alexandre \"Sunny\" Kovalenko" <gaijin.k@gmail.com> > Date: Tue, 01 Jul 2008 08:19:58 -0400 > Sender: owner-freebsd-acpi@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@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 --==_Exmh_1214929038_54298P Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) Comment: Exmh version 2.5 06/03/2002 iD8DBQFIaliOkn3rs5h7N1ERAvLKAKChqTf5bfeQItIma1nBzCL7IwQRzgCfWffx sEf+sbtWufaXVsiFwlXKYHE= =ur1V -----END PGP SIGNATURE----- --==_Exmh_1214929038_54298P--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080701161718.CB0B745047>