Bug 162578
| Summary: | 9.0-RC2's regression in power management on VIA Samuel 2 | ||
|---|---|---|---|
| Product: | Base System | Reporter: | Oli Kron <kron24> |
| Component: | kern | Assignee: | freebsd-bugs (Nobody) <bugs> |
| Status: | Closed FIXED | ||
| Severity: | Affects Only Me | ||
| Priority: | Normal | ||
| Version: | Unspecified | ||
| Hardware: | Any | ||
| OS: | Any | ||
I've noticed yet another difference between 8.2 and 9: dmesg on 8.2: acpi_throttle0: <ACPI CPU Throttling> on cpu0 dmesg on 9: acpi_throttle0: <ACPI CPU Throttling> on cpu0 acpi_throttle0: failed to attach P_CNT device_attach: acpi_throttle0 attach returned 6 Guessing it may relate to the power management issue. Oli I bisected this down to r216674. Moreover, "AMD Features=0x80000000<3DNow!>", which I highlighted in the original bugreport, was just a red herring. I'll try to attract some attention at users@ > I'll try to attract some attention at users@ Sorry, I meant -questions@ Hello, I'm bringing this to -acpi@ as suggested by jhb@. Some time ago while testing 9.0-RC2 I noticed that power management got broken (powerd doesn't start, Cx states disappeared) on a specific class of our minirouters. I created kern/162578, bisected the issue down to r216674 and I contacted the author - jhb@. John was kind to do a further analysis. Verbose boots before and after r216674 differ this way: -Calibrating TSC clock ... TSC clock: 532647138 Hz +Calibrating TSC clock ... TSC clock: 532648183 Hz -ACPI timer: 0/4 0/5 0/4 0/5 0/4 0/5 0/4 0/5 0/4 0/4 -> 0 -Timecounter "ACPI-safe" frequency 3579545 Hz quality 850 -acpi_timer0: <24-bit timer at 3.579545MHz> port 0x4008-0x400b on acpi0 +acpi_timer0: couldn't allocate resource (port 0x4008) -acpi_throttle0: P_CNT from P_BLK 0x4010 +acpi_throttle0: failed to attach P_CNT +device_attach: acpi_throttle0 attach returned 6 John's comment: > So this is the issue, and it seems what happens is that your > BIOS assigns the resources for this range to the pcib0 device > when we expect them to be assigned as a system resource (if > at all): > pcib0: <ACPI Host-PCI bridge> port > 0xcf8-0xcff,0x4000-0x407f,0x4080-0x40ff,0x5000-0x500f,0x6000-0x607f > on acpi0 > You could try hacking your ASL to not list the 0x4000-0x407f range > for now, but the real fix is probably to make resources attached > to Host-PCI bridge devices be treated as if they were system > resources and put into the ACPI system resource rman instead. > That requires a fair bit of work however. John also suggested to involve jkim@ and -acpi@. I'm going to experiment with ASL because it would be an acceptable solution to me and the real fix is way above my skills ATM. If anybody is interested in this I have a spare machine affected by this issue and I can do any test. Best regards Oli Kron > I'm going to experiment with ASL because it would be an acceptable
> solution to me and the real fix is way above my skills ATM.
As promised, I fiddled with ASL. I did found something which
resembled 0x4000-0x407f:
...
DefinitionBlock ("/tmp/acpidump.aml", "DSDT", 1, "VIA601", "AWRDACPI",
0x00001000)
{
....
Scope (\_SB)
{
...
Device (PCI0)
{
...
Method (_CRS, 0, NotSerialized)
{
...
Name (BUF0, ResourceTemplate ()
{
...
IO (Decode16,
0x4000, // Range Minimum
0x4000, // Range Maximum
0x01, // Alignment
0x80, // Length
)
...
I removed the IO block, compiled, installed the AML, rebooted
and voila - I have my power management back even with r216674.
Big thanks to jhb@ for guiding me.
As always, big thanks to all the good souls who write the
Handbook, too. It helped me with ASL and AML.
As
1. this hack is good enough for me, and
2. the real fix John suggested is above my skills
I think the PR can be closed.
Best regards
Oli
PS: My offer to do any tests on the affected HW still holds.
State Changed From-To: open->closed apparently a workaround has been committed, and submitter reports that PR may be closed. Can you try an updated HEAD and see if a stock ASL works? -- John Baldwin On 2012/01/03 23:12, John Baldwin wrote:
> Can you try an updated HEAD and see if a stock ASL works?
Just tested - the stock ASL fails as before:
...
acpi0: reservation of 0, a0000 (3) failed
acpi0: reservation of 100000, 1f6f0000 (3) failed
acpi_timer0: couldn't allocate resource (port 0x4008)
...
acpi_throttle0: <ACPI CPU Throttling> on cpu0
acpi_throttle0: failed to attach P_CNT
device_attach: acpi_throttle0 attach returned 6
...
Oli
|
I have a few machines (mostly routers) with VIA Samuel 2. FreeBSD 9.0-RC2 breaks power management on them. 8.2-RELEASE detects: CPU: VIA Samuel 2 (532.64-MHz 686-class CPU) Origin = "CentaurHauls" Id = 0x673 Family = 6 Model = 7 Stepping = 3 Features=0x803035<FPU,DE,TSC,MSR,MTRR,PGE,MMX> and sysctl dev.cpu.0 says: dev.cpu.0.%desc: ACPI CPU dev.cpu.0.%driver: cpu dev.cpu.0.%location: handle=\_PR_.CPU0 dev.cpu.0.%pnpinfo: _HID=none _UID=0 dev.cpu.0.%parent: acpi0 dev.cpu.0.freq: 532 dev.cpu.0.freq_levels: 532/-1 266/-1 dev.cpu.0.cx_supported: C1/0 C2/90 C3/900 dev.cpu.0.cx_lowest: C2 dev.cpu.0.cx_usage: 0.45% 99.54% 0.00% last 783us In 8.2 I can use dev.cpu.0.cx_lowest=C2 in /etc/sysctl.conf and powerd runs fine switching between 532 and 266 MHz. FreeBSD 9.0-RC2 detects: CPU: VIA Samuel 2 (532.65-MHz 686-class CPU) Origin = "CentaurHauls" Id = 0x673 Family = 6 Model = 7 Stepping = 3 Features=0x803035<FPU,DE,TSC,MSR,MTRR,PGE,MMX> AMD Features=0x80000000<3DNow!> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ the only difference and sysctl dev.cpu.0 is: dev.cpu.0.%desc: ACPI CPU dev.cpu.0.%driver: cpu dev.cpu.0.%location: handle=\_PR_.CPU0 dev.cpu.0.%pnpinfo: _HID=none _UID=0 dev.cpu.0.%parent: acpi0 dev.cpu.0.cx_supported: C1/0 dev.cpu.0.cx_lowest: C1 dev.cpu.0.cx_usage: 100.00% last 208us Of course, dev.cpu.0.cx_lowest=C2 is not available and powerd cannot start - "powerd -v" fails: powerd: lookup freq: No such file or directory How-To-Repeat: install 9.0-RC2 on VIA Samuel 2 and: 1. sysctl dev.cpu.0 to see available frequencies and Cx states 2. try start powerd