On Thu, 18 Aug 2016 06:07:45 -0400, am_d...@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_d...@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:

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
freebsd-acpi@freebsd.org mailing list
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"

Reply via email to