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_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:
>
> 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-unsubscr...@freebsd.org"
--
Anthony Jenkins
_______________________________________________
freebsd-acpi@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
