From owner-freebsd-bugs@FreeBSD.ORG Wed Jan 4 16:10:15 2012 Return-Path: Delivered-To: freebsd-bugs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 14782106566B for ; Wed, 4 Jan 2012 16:10:15 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id ECC698FC12 for ; Wed, 4 Jan 2012 16:10:14 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q04GAElQ007766 for ; Wed, 4 Jan 2012 16:10:14 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q04GAE8o007765; Wed, 4 Jan 2012 16:10:14 GMT (envelope-from gnats) Date: Wed, 4 Jan 2012 16:10:14 GMT Message-Id: <201201041610.q04GAE8o007765@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org From: kron Cc: Subject: Re: kern/162578: 9.0-RC2's regression in power management on VIA Samuel 2 X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: kron List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2012 16:10:15 -0000 The following reply was made to PR kern/162578; it has been noted by GNATS. From: kron To: John Baldwin 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 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@. >>> >>> 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? 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: on cpu0 acpi_throttle0: failed to attach P_CNT device_attach: acpi_throttle0 attach returned 6 ... Oli