From owner-freebsd-acpi@FreeBSD.ORG Wed Jan 4 16:08:09 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 DFBB8106566B; Wed, 4 Jan 2012 16:08:08 +0000 (UTC) (envelope-from kron24@gmail.com) Received: from mail-ee0-f54.google.com (mail-ee0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id 275CF8FC12; Wed, 4 Jan 2012 16:08:07 +0000 (UTC) Received: by eekc50 with SMTP id c50so19946940eek.13 for ; Wed, 04 Jan 2012 08:08:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=ny3VyMctXvMfZVxp2y6zbNP/KHN9RFmSzgohqFuxvQI=; b=DlD1lHXL6gZ0O6FZm2GmSLguzLRHMQvIz68jFnHpB3I/wEaiWNcpLWt+KcX/a5YwPh zOawUySLrYZTCOagsIjm37I4YVqBFQj6uAiO1H/dV7ryx3Df7fO6FAjO0xpPuF1TGMPv NNgcC1wKvdDuF53ikHLfZ9/GJZukcU9XS1lbM= Received: by 10.14.39.72 with SMTP id c48mr23826395eeb.25.1325691896055; Wed, 04 Jan 2012 07:44:56 -0800 (PST) Received: from nbvk.local (uidzr185150.sattnet.cz. [212.96.185.150]) by mx.google.com with ESMTPS id 76sm221007682eeh.0.2012.01.04.07.44.52 (version=SSLv3 cipher=OTHER); Wed, 04 Jan 2012 07:44:54 -0800 (PST) Message-ID: <4F0473F3.7010904@gmail.com> Date: Wed, 04 Jan 2012 16:44:51 +0100 From: kron User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:9.0) Gecko/20111222 Thunderbird/9.0 MIME-Version: 1.0 To: John Baldwin References: <4ECC9975.5090907@gmail.com> <4ECD6105.1050400@gmail.com> <201201031712.36866.jhb@freebsd.org> In-Reply-To: <201201031712.36866.jhb@freebsd.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit 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: Wed, 04 Jan 2012 16:08:09 -0000 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