kern/162578: 9.0-RC2's regression in power management on VIA Samuel 2

kron kron24 at gmail.com
Wed Nov 23 21:10:22 UTC 2011


The following reply was made to PR kern/162578; it has been noted by GNATS.

From: kron <kron24 at gmail.com>
To: Cc: bug-followup at FreeBSD.org, jhb at freebsd.org, jkim at freebsd.org, 
 freebsd-acpi at freebsd.org
Subject: Re: kern/162578: 9.0-RC2's regression in power management on VIA
 Samuel 2
Date: Wed, 23 Nov 2011 22:09:25 +0100

 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.
 
 Best regards
 Oli
 
 PS: My offer to do any tests on the affected HW still holds.


More information about the freebsd-bugs mailing list