Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 3 Jan 2012 22:20:10 GMT
From:      John Baldwin <jhb@freebsd.org>
To:        freebsd-bugs@FreeBSD.org
Subject:   Re: kern/162578: 9.0-RC2's regression in power management on VIA Samuel 2
Message-ID:  <201201032220.q03MKAMD086859@freefall.freebsd.org>

next in thread | raw e-mail | index | archive | help
The following reply was made to PR kern/162578; it has been noted by GNATS.

From: John Baldwin <jhb@freebsd.org>
To: kron <kron24@gmail.com>
Cc: bug-followup@freebsd.org,
 jkim@freebsd.org,
 freebsd-acpi@freebsd.org
Subject: Re: kern/162578: 9.0-RC2's regression in power management on VIA Samuel 2
Date: Tue, 3 Jan 2012 17:12:36 -0500

 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@.
 > >
 > > 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.
 > 
 > 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?
 
 -- 
 John Baldwin



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201201032220.q03MKAMD086859>