Date: Thu, 18 Aug 2016 22:12:15 +1000 (EST) From: Ian Smith <smithi@nimnet.asn.au> To: am_dxer@fastmail.fm Cc: Konstantin Belousov <kostikbel@gmail.com>, Adam Pribyl <pribyl@lowlevel.cz>, freebsd-acpi@freebsd.org Subject: Re: Problems with CPU throttling on HP 15-n066us laptop Message-ID: <20160818211938.R79687@sola.nimnet.asn.au> In-Reply-To: <1471514865.2276129.698913209.3B7A5306@webmail.messagingengine.com> References: <1471488612.2196853.698646081.0844D23B@webmail.messagingengine.com> <20160818074609.GV83214@kib.kiev.ua> <1471514865.2276129.698913209.3B7A5306@webmail.messagingengine.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 18 Aug 2016 06:07:45 -0400, am_dxer@fastmail.fm wrote: > On Thu, Aug 18, 2016, at 03:46 AM, Konstantin Belousov wrote: > > On Wed, Aug 17, 2016 at 10:50:12PM -0400, am_dxer@fastmail.fm wrote: > > > Hello, > > > I purchased a new laptop for FreeBSD and am having some problems with > > > CPU throttling. This laptop has an aMD a10-5745m processor. I cannot > > > start powerd and the frequency levels in dev.cpu are absent. I tried Just to clear up any confusion: Adam Pribyl noted that "throttling" is disabled in 10(+) but that refers only to "relative" cpufreq drivers, p4tcc and acpi_throttle, whereas your main problem appears to be that cpufreq(4) isn't attaching at all, so there's no a) control over and b) no ability to read, let alone set, cpu.0.freq. I don't know much about recent AMDs, but you mention Cool'n'Quiet, otherwise refered to in acpi(4) as: [ note: reading stable/9 manpage] powernow AMD PowerNow! and Cool'n'Quiet for K7 and K8 but again, these are subsidiary drivers to cpufreq(4). > > > with 11 and when that didn't work, I upgraded to Current. The laptop is > > > running very hot and the fans are often running at a high speed so I > > > think the cpu is running near full speed. This is the only issue I am > > > having in general use of the laptop. I will include the url for my asl > > > below as well as the output of dmesg after boot -v and sysctl hw.acpi. I > > > noticed messages like "acpi_ec0: EcCommand: no response to 0x84" near Yes, that stuck out. I don't know whether it might be related to this. > > > the bottom of the dmesg but honestly don't know enough about acpi to say > > > whether this could be causing the problem. I tried Googling the error > > > and found people who seemed to be having trouble with temperature > > > readings and battery status. For me, the battery status is working fine > > > when I check it via acpiconf although I did notice some unusual > > > temperature readings in the dmesg output. There are some other The only mentions are 3 of 'acpi_tz0: _CRT value is absurd, ignored (255.1C) I don't know where the '.1' comes from, but hw.scpi.thermal shows: hw.acpi.thermal.tz0._CRT: -1 hw.acpi.thermal.tz0._HOT: 100.1C hw.acpi.thermal.tz0._PSV: 96.1C hw.acpi.thermal.tz0.thermal_flags: 0 hw.acpi.thermal.tz0.passive_cooling: 1 hw.acpi.thermal.tz0.active: -1 hw.acpi.thermal.tz0.temperature: 46.1C -1 = 255, which is surely not a useful critical shutdown temperature, indeed your laptop would be a pool of molten plsstic, probably with a nasty Li-ion battery fire/explosion as a topping, long before then. FreeBSD doesn't actually use _HOT as far as I know, unsure about 11|12 !sysctl -d hw.acpi.thermal.tz0._HOT hw.acpi.thermal.tz0._HOT: too hot temp setpoint (suspend now) But I don't believe it works. Other(?) texts indiccte that should cause S4 (suspend to disk aka hibernation) but we don't support S4 at all, so if it does get too hot, you'll be relying on passive cooling cutting in at 96.1C (again, what's with this '.1'?) and I'm not sure if that can even happen without first using cpufreq? > > > temperature readings that appear in sysctl but I would have to study > > > them more during a work session to see if they remain reasonable. Thanks > > > in advance for any help. > > > > > > > > > asl url: http://pasted.co/5770b687 > > > > > > boot-v output: http://pasted.co/c8e9fb89 > > > > > > hw.acpi output: http://pasted.co/cc611266 > > > > It is more useful to show sysctl dev.cpu. I suspect your bios > > reports C-states in a way which we do not parse properly. Well it looks like C2 is being used 70-80% of the halt time, so I'm not sure that's so much of an issue, compared to cpufreq not attaching? I don't know if it would provide more info on a verbose boot, but you might try setting, in /boot/loader.conf: hw.acpi.verbose=1 debug.cpufreq.verbose=1 debug.hwpstate_verbose=1 # also an AMD thing i think? > > I am not aware of AMD-specific analog for the Intel' document 'Processor > > Vendor-Specific ACPI Interface Specification'. If somebody has a pointer > > to AMD version and wants to test, I am willing to code that. > I will include the output of dev.cpu below. One observation that I made > is that it seems that the Cool'n'Quiet driver is not attaching. I used > FreeBSD on a laptop with a newer apu once which was the amd a4-5000 from > the Kabini generation and the Cool'n'Quiet 2.0 driver attached on that > machine. I would be willing to perform any testing that you would find > helpful. Most likely cpufreq(4) also attached on that one too, and first? > output from dev.cpu: > dev.cpu.3.cx_method: C1/hlt C2/i > dev.cpu.3.cx_usage_counters: 2260 5108 > dev.cpu.3.cx_usage: 30.67% 69.32% last 2992us > dev.cpu.3.cx_lowest: C8 > dev.cpu.3.cx_supported: C1/1/0 C2/2/100 [..] > dev.cpu.2.cx_usage: 30.74% 69.25% last 1038us [..] > dev.cpu.1.cx_usage: 22.77% 77.22% last 568us [..] > dev.cpu.0.cx_method: C1/hlt C2/io > dev.cpu.0.cx_usage_counters: 1541 5804 > dev.cpu.0.cx_usage: 20.98% 79.01% last 2975us > dev.cpu.0.cx_lowest: C8 > dev.cpu.0.cx_supported: C1/1/0 C2/2/100 Just checking .. was the above taken when running on AC, or on battery? Just that your hw.acpi shows: hw.acpi.cpu.cx_lowest: C2 which is nowadays the (conservative?) default setting while on AC power: smithi@x200:/usr/head/src % grep cx etc/defaults/rc.conf performance_cx_lowest="C2" # Online CPU idle state economy_cx_lowest="Cmax" # Offline CPU idle state which sets hw.acpi.cpu.cx_lowest, which then controls the setting of the individual dev.cpu.X.cx_lowest, which above are shown as C8, ie Cmax ? Just a few thoughts .. cheers, Ian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20160818211938.R79687>