Date: Tue, 3 Jan 2012 17:12:36 -0500 From: John Baldwin <jhb@freebsd.org> To: kron <kron24@gmail.com> Cc: freebsd-acpi@freebsd.org, bug-followup@freebsd.org Subject: Re: kern/162578: 9.0-RC2's regression in power management on VIA Samuel 2 Message-ID: <201201031712.36866.jhb@freebsd.org> In-Reply-To: <4ECD6105.1050400@gmail.com> References: <4ECC9975.5090907@gmail.com> <4ECD6105.1050400@gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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?201201031712.36866.jhb>