Date: Wed, 2 Jul 2008 00:22:55 +1000 (EST) From: Ian Smith <smithi@nimnet.asn.au> 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: <Pine.BSF.3.96.1080701225233.23993B-100000@gaia.nimnet.asn.au> In-Reply-To: <1214914799.1064.12.camel@RabbitsDen>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 1 Jul 2008, Alexandre "Sunny" Kovalenko wrote: > 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) <============================= > } > } And that's the only place it (and \_TZ.THM) notifies seem to occur. > 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. I should shutup till having a proper look at more recent sources :) but that may be the relative frequency control drivers, acpi_throttle0 on 6.3-S and p4tcc0 on 7-S and 8 as seen earlier in the dmesgs, returning throttled frequencies of 7/8 downto 1/8th of each, with any duplicates removed, to populate the available freq.levels I expect? So the fact that the levels topped out at 1200 rather than 2400 might indicate that at the time only the lower base frequency was available, whether by the BIOS intervening somehow, or by cpufreq 'freqing out' :) > 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. Only strange that it worked before for ages, up to 85C as David noted. Hopefully just a busted temperature sensor or something else fixable .. cheers, Ian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.96.1080701225233.23993B-100000>