kern/162578: 9.0-RC2's regression in power management on VIA
Samuel 2
kron
kron24 at gmail.com
Wed Jan 4 16:10:15 UTC 2012
The following reply was made to PR kern/162578; it has been noted by GNATS.
From: kron <kron24 at gmail.com>
To: John Baldwin <jhb at freebsd.org>
Cc: freebsd-acpi at freebsd.org, bug-followup at freebsd.org
Subject: Re: kern/162578: 9.0-RC2's regression in power management on VIA
Samuel 2
Date: Wed, 04 Jan 2012 16:44:51 +0100
On 2012/01/03 23:12, John Baldwin wrote:
> On Wednesday, November 23, 2011 4:09:25 pm kron wrote:
>> On 2011/11/23 07:57, kron wrote:
>>> Hello,
>>>
>>> I'm bringing this to -acpi@ as suggested by jhb at .
>>>
>>> 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 at . 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 at .
>>>
>>> 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.
>
> 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
More information about the freebsd-bugs
mailing list