Bug 189267 - [cpufreq] AMD Kabini (AM1/FM1Sb) Frequency Switching Causes Crash
Summary: [cpufreq] AMD Kabini (AM1/FM1Sb) Frequency Switching Causes Crash
Status: Closed FIXED
Alias: None
Product: Base System
Classification: Unclassified
Component: amd64 (show other bugs)
Version: 9.2-RELEASE
Hardware: Any Any
: Normal Affects Only Me
Assignee: freebsd-amd64 (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-05-02 23:00 UTC by Brodey Dover
Modified: 2015-03-06 18:13 UTC (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Brodey Dover 2014-05-02 23:00:00 UTC
Running powerd on FreeNAS system with C6 state enabled in BIOS causes
the system to crash shortly after start-up. Disabling the C6 state in
the BIOS resolves the system crashing but then one does not receive the
low power modes afforded by the platform. 

Disabling powerd, however, enabling CnQ and C6 state in the BIOS also
resolves the system crashing with the same effect; no low power modes.
I also note significant power usage from a system that should otherwise
be consuming less power than my Skt 939 90W TDP X2 3800+ with 4x DDR 1GB
modules. I noted that the GPU was also never down-clocked and would never
enter any low power modes.

I feel that this is a serious compatibility issue for hardware (that I
think was released when 9.2 was production).

Fix: 

N/A
How-To-Repeat: Run hardware on FreeBSD 9.2. (I haven't tried FreeBSD 10).
Comment 1 jeremias 2014-05-03 10:17:03 UTC
I have the same problem with an AMD Athlon 5350 on Asrock AM1H-ITX. I did
not verify the powerd solution yet. However, the experience is similar,
shortly after booting the system would reset. I tried FreeBSD 10 release
and stable, in both cases I activated powerd in the installation process
and had the described reboot issue.
I suspected a driver issue and switched to a FreeBSD 11 snapshot which
works perfectly. I guess the reason is that powerd is not enabled on these
snapshots.
Comment 2 Brodey Dover 2014-05-04 16:03:07 UTC
I also noticed that HPET isn't an eventtimer option in spite of it being
enabled in the BIOS.

[brodey@freenas] /# sysctl -a | grep eventtimer
kern.eventtimer.choice: LAPIC(400) i8254(100) RTC(0)
kern.eventtimer.et.LAPIC.flags: 15
kern.eventtimer.et.LAPIC.frequency: 50000961
kern.eventtimer.et.LAPIC.quality: 400
kern.eventtimer.et.i8254.flags: 1
kern.eventtimer.et.i8254.frequency: 1193182
kern.eventtimer.et.i8254.quality: 100
kern.eventtimer.et.RTC.flags: 17
kern.eventtimer.et.RTC.frequency: 32768
kern.eventtimer.et.RTC.quality: 0
kern.eventtimer.periodic: 0
kern.eventtimer.timer: LAPIC
kern.eventtimer.activetick: 1
kern.eventtimer.idletick: 0
kern.eventtimer.singlemul: 2

I also note that one core has a different supported state (maybe this is an
AMD implementation):

hw.acpi.cpu.cx_lowest: C1
dev.cpu.0.cx_supported: C1/1/0 C2/2/400
dev.cpu.0.cx_lowest: C1
dev.cpu.0.cx_usage: 100.00% 0.00% last 98us
dev.cpu.1.cx_supported: C1/1/0
dev.cpu.1.cx_lowest: C1
dev.cpu.1.cx_usage: 100.00% last 235us
dev.cpu.2.cx_supported: C1/1/0
dev.cpu.2.cx_lowest: C1
dev.cpu.2.cx_usage: 100.00% last 17us
dev.cpu.3.cx_supported: C1/1/0
dev.cpu.3.cx_lowest: C1
dev.cpu.3.cx_usage: 100.00% last 16us

Seeing C1 state supported and it's usage makes me wonder where my other
wattage is being used. I think the GPU isn't being switched down.


On Sat, May 3, 2014 at 5:17 AM, Jeremias Blendin <jeremias@blendin.org>wrote:

> I have the same problem with an AMD Athlon 5350 on Asrock AM1H-ITX. I did
> not verify the powerd solution yet. However, the experience is similar,
> shortly after booting the system would reset. I tried FreeBSD 10 release
> and stable, in both cases I activated powerd in the installation process
> and had the described reboot issue.
> I suspected a driver issue and switched to a FreeBSD 11 snapshot which
> works perfectly. I guess the reason is that powerd is not enabled on these
> snapshots.
>
Comment 3 kitsook 2014-06-14 10:23:23 UTC
I have the exact setup as jeremias (AMD 5350 and ASRock AM1H-ITX) and encountered the same problem. Disabling Core C6 in BIOS *or* turning off powerd in FreeBSD can avoid the reboot issue.

Also found that disabling CPU throttling can avoid the issue even with C6 enabled and powerd running.  I added this to /boot/loader.conf:

hint.acpi_throttle.0.disabled=1

Here is my /etc/rc.conf, with powerd enabled and lowest C-state set to max:

powerd_enable="YES"
powerd_flags="-a adaptive"

performance_cx_lowest="Cmax"
economy_cx_lowest="Cmax"


For reference, with C6 enabled in BIOS:

root@bart:~ # sysctl dev.cpu | grep cx
dev.cpu.0.cx_supported: C1/1/0 C2/2/400
dev.cpu.0.cx_lowest: C8
dev.cpu.0.cx_usage: 3.14% 96.85% last 3293us
dev.cpu.1.cx_supported: C1/1/0
dev.cpu.1.cx_lowest: C8
dev.cpu.1.cx_usage: 100.00% last 42697us
dev.cpu.2.cx_supported: C1/1/0
dev.cpu.2.cx_lowest: C8
dev.cpu.2.cx_usage: 100.00% last 3680us
dev.cpu.3.cx_supported: C1/1/0
dev.cpu.3.cx_lowest: C8
dev.cpu.3.cx_usage: 100.00% last 36us


However, with throttling disable, the reported lowest CPU freq is higher.

With throttling:

root@bart:~ # sysctl dev.cpu | grep freq
dev.cpu.0.freq: 100
dev.cpu.0.freq_levels: 2050/5021 1850/4590 1650/3675 1443/3215 1400/2937 1225/2569 1200/2266 1050/1982 1000/1880 875/1645 800/1527 700/1336 600/1145 500/954 400/763 300/572 200/381 100/190


Throttling disabled:

root@bart:~ # sysctl dev.cpu | grep freq
dev.cpu.0.freq: 800
dev.cpu.0.freq_levels: 2050/5021 1850/4590 1650/3675 1400/2937 1200/2266 1000/1880 800/1527


In summary, to get around the issue while maximizing power saving, my current config is:
- C6 enabled in BIOS
- powerd running
- CPU throttling disable hint.acpi_throttle.0.disabled=1
Comment 4 Allan Jude freebsd_committer freebsd_triage 2015-03-06 18:13:57 UTC
A change to disabled acpi_throttle by default was committed to -CURRENT in May of 2014 (10 months ago)

https://svnweb.freebsd.org/changeset/base/r265329

and was merged to stable/10 in January

https://svnweb.freebsd.org/changeset/base/r276986