Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 18 Aug 2016 09:14:20 -0400
From:      Anthony Jenkins <Scoobi_doo@yahoo.com>
To:        Ian Smith <smithi@nimnet.asn.au>, am_dxer@fastmail.fm
Cc:        freebsd-acpi@freebsd.org
Subject:   Re: Problems with CPU throttling on HP 15-n066us laptop
Message-ID:  <557a599e-a81b-c2bf-9b62-3a3f6cd9bb2e@yahoo.com>
In-Reply-To: <20160818211938.R79687@sola.nimnet.asn.au>
References:  <1471488612.2196853.698646081.0844D23B@webmail.messagingengine.com> <20160818074609.GV83214@kib.kiev.ua> <1471514865.2276129.698913209.3B7A5306@webmail.messagingengine.com> <20160818211938.R79687@sola.nimnet.asn.au>

next in thread | previous in thread | raw e-mail | index | archive | help
Try this patch, that's what I'm running.

diff --git a/sys/x86/cpufreq/hwpstate.c b/sys/x86/cpufreq/hwpstate.c
index d4c70b7..326d967 100644
--- a/sys/x86/cpufreq/hwpstate.c
+++ b/sys/x86/cpufreq/hwpstate.c
@@ -408,25 +408,27 @@ hwpstate_get_info_from_msr(device_t dev)
        hwpstate_set = sc->hwpstate_settings;
        for (i = 0; i < sc->cfnum; i++) {
                msr = rdmsr(MSR_AMD_10H_11H_CONFIG + i);
-               if ((msr & ((uint64_t)1 << 63)) != ((uint64_t)1 << 63)) {
+               if ((msr & ((uint64_t)1 << 63)) == 0) {
                        HWPSTATE_DEBUG(dev, "msr is not valid.\n");
                        return (ENXIO);
                }
                did = AMD_10H_11H_CUR_DID(msr);
                fid = AMD_10H_11H_CUR_FID(msr);
+               /* fid/did to frequency */
                switch(family) {
                case 0x11:
-                       /* fid/did to frequency */
-                       hwpstate_set[i].freq = 100 * (fid + 0x08) / (1
<< did);
+                       hwpstate_set[i].freq = (100 * (fid + 0x08)) >> did;
                        break;
                case 0x10:
-                       /* fid/did to frequency */
-                       hwpstate_set[i].freq = 100 * (fid + 0x10) / (1
<< did);
+               case 0x12:
+               case 0x14:
+               case 0x15:
+               case 0x16:
+                       hwpstate_set[i].freq = (100 * (fid + 0x10)) >> did;
                        break;
                default:
-                       HWPSTATE_DEBUG(dev, "get_info_from_msr: AMD
family %d CPU's are not implemented yet. sorry.\n", family);
+                       HWPSTATE_DEBUG(dev, "get_info_from_msr: AMD
family 0x%02x CPU's are not implemented yet. sorry.\n", family);
                        return (ENXIO);
-                       break;
                }
                hwpstate_set[i].pstate_id = i;
                /* There was volts calculation, but deleted it. */
diff --git a/sys/x86/cpufreq/powernow.c b/sys/x86/cpufreq/powernow.c
index cc62e87..355bde8 100644
--- a/sys/x86/cpufreq/powernow.c
+++ b/sys/x86/cpufreq/powernow.c
@@ -866,17 +866,22 @@ static void
 pn_identify(driver_t *driver, device_t parent)
 {
 
-       if ((amd_pminfo & AMDPM_FID) == 0 || (amd_pminfo & AMDPM_VID) == 0)
+       if ((amd_pminfo & AMDPM_FID) == 0 || (amd_pminfo & AMDPM_VID) ==
0) {
+               printf("powernow: pn_identify: amd_pminfo=0x%04x .\n",
amd_pminfo);
                return;
+       }
        switch (cpu_id & 0xf00) {
        case 0x600:
        case 0xf00:
                break;
        default:
+               printf("powernow: pn_identify: cpu_id=0x%04x.\n", cpu_id);
                return;
        }
-       if (device_find_child(parent, "powernow", -1) != NULL)
+       if (device_find_child(parent, "powernow", -1) != NULL) {
+               printf("powernow: pn_identify: No \"powernow\"device
found.\n");
                return;
+       }
        if (BUS_ADD_CHILD(parent, 10, "powernow", -1) == NULL)
                device_printf(parent, "powernow: add child failed\n");
 }
@@ -895,8 +900,10 @@ pn_probe(device_t dev)
        status = rdmsr(MSR_AMDK7_FIDVID_STATUS);

        pc = cpu_get_pcpu(dev);
-       if (pc == NULL)
+       if (pc == NULL) {
+               printf("powernow: cpu_get_pcpu() returned NULL.\n");
                return (ENODEV);
+       }

        cpu_est_clockrate(pc->pc_cpuid, &rate);

@@ -936,6 +943,7 @@ pn_probe(device_t dev)
                        device_set_desc(dev, "Cool`n'Quiet K8");
                break;
        default:
+               printf("powernow: cpuid 0x%04x & 0xf00 not matched.\n",
cpu_id);
                return (ENODEV);
        }



On 08/18/2016 08:12 AM, Ian Smith wrote:
> 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
> _______________________________________________
> freebsd-acpi@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-acpi
> To unsubscribe, send any mail to "freebsd-acpi-unsubscribe@freebsd.org"

-- 
Anthony Jenkins




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?557a599e-a81b-c2bf-9b62-3a3f6cd9bb2e>