From owner-freebsd-acpi@FreeBSD.ORG Tue Jan 3 22:14:42 2012 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7F3751065670; Tue, 3 Jan 2012 22:14:42 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 3CA398FC1B; Tue, 3 Jan 2012 22:14:42 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [96.47.65.170]) by cyrus.watson.org (Postfix) with ESMTPSA id CCE8146B1A; Tue, 3 Jan 2012 17:14:41 -0500 (EST) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 62417B965; Tue, 3 Jan 2012 17:14:41 -0500 (EST) From: John Baldwin To: kron Date: Tue, 3 Jan 2012 17:12:36 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p8; KDE/4.5.5; amd64; ; ) References: <4ECC9975.5090907@gmail.com> <4ECD6105.1050400@gmail.com> In-Reply-To: <4ECD6105.1050400@gmail.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201201031712.36866.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 03 Jan 2012 17:14:41 -0500 (EST) 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 X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2012 22:14:42 -0000 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: 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