From owner-freebsd-acpi@FreeBSD.ORG Wed Nov 23 21:09:34 2011 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 3DB40106566C; Wed, 23 Nov 2011 21:09:34 +0000 (UTC) (envelope-from kron24@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 41BBF8FC0C; Wed, 23 Nov 2011 21:09:32 +0000 (UTC) Received: by bkbzs8 with SMTP id zs8so2726926bkb.13 for ; Wed, 23 Nov 2011 13:09:32 -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:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=uGFNHUncyNn/59awsvsbaGNcgomWK+QQqmTDMLCf+VU=; b=rnZDMaKDa3/vr4UpyPOOWpzYmYi8VYS8PMsOSz23sNooWCo7x9vLepzwm+AEzbiG+J xzVnUbDxLemsLoDDP48znLVrCwxcFK19ykbkMOrMP1wavL39/3INF0Zw5zxxWMrxeibZ VrxzOFhyum+Cb2lE8UNr2ZG4jXUAEsbmWrFEA= Received: by 10.204.128.199 with SMTP id l7mr15275529bks.27.1322082572108; Wed, 23 Nov 2011 13:09:32 -0800 (PST) Received: from nbvk.local (uidzr185150.sattnet.cz. [212.96.185.150]) by mx.google.com with ESMTPS id l26sm23151909fad.17.2011.11.23.13.09.27 (version=SSLv3 cipher=OTHER); Wed, 23 Nov 2011 13:09:28 -0800 (PST) Message-ID: <4ECD6105.1050400@gmail.com> Date: Wed, 23 Nov 2011 22:09:25 +0100 From: kron User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:8.0) Gecko/20111109 Thunderbird/8.0 MIME-Version: 1.0 References: <4ECC9975.5090907@gmail.com> In-Reply-To: <4ECC9975.5090907@gmail.com> 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, 23 Nov 2011 21:09:34 -0000 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. Best regards Oli PS: My offer to do any tests on the affected HW still holds.