From owner-freebsd-acpi@FreeBSD.ORG Tue Nov 22 21:03:47 2011 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from [127.0.0.1] (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by hub.freebsd.org (Postfix) with ESMTP id 67562106564A for ; Tue, 22 Nov 2011 21:03:47 +0000 (UTC) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: freebsd-acpi@freebsd.org Date: Tue, 22 Nov 2011 16:03:32 -0500 User-Agent: KMail/1.6.2 References: <4ECB73F4.4060703@gmail.com> <4ECBFD7A.3090407@gmail.com> <201111221505.50918.jhb@freebsd.org> In-Reply-To: <201111221505.50918.jhb@freebsd.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201111221603.34026.jkim@FreeBSD.org> Subject: Re: regression in power management since r216674 (kern/162578) 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, 22 Nov 2011 21:03:48 -0000 [Forwarding thread regarding kern/162578] On Tuesday 22 November 2011 03:05 pm, John Baldwin wrote: > [ Adding jkim@, could probably resend this thread to acpi@. ] > > On Tuesday, November 22, 2011 2:52:26 pm kron wrote: > > On 2011/11/22 14:58, John Baldwin wrote: > > > On Tuesday, November 22, 2011 5:05:40 am kron wrote: > > >> Hi John, > > >> > > >> I dare to write directly to you because this seems to be > > >> related to your commit r216674. > > >> > > >> I tried to open this on -stable a week ago ("9.0-RC2: > > >> regression in power management on VIA Samuel 2") but didn't > > >> attract an attention. In the meanwhile I created kern/162578 > > >> and after some bisecting came to a conclusion that my power > > >> management issue was caused by r216674. In summary: > > >> > > >> With r216673, sysctl shows: > > >> dev.cpu.0.%desc: ACPI CPU > > >> dev.cpu.0.%driver: cpu > > >> dev.cpu.0.%location: handle=\_PR_.CPU0 > > >> dev.cpu.0.%pnpinfo: _HID=none _UID=0 > > >> dev.cpu.0.%parent: acpi0 > > >> dev.cpu.0.freq: 532 > > >> *dev.cpu.0.freq_levels:* 532/-1 266/-1 > > >> *dev.cpu.0.cx_supported:* C1/0 C2/90 C3/900 > > >> dev.cpu.0.cx_lowest: C2 > > >> I can set dev.cpu.0.cx_lowest and run powerd, too. > > >> > > >> With r216674: > > >> dev.cpu.0.%desc: ACPI CPU > > >> dev.cpu.0.%driver: cpu > > >> dev.cpu.0.%location: handle=\_PR_.CPU0 > > >> dev.cpu.0.%pnpinfo: _HID=none _UID=0 > > >> dev.cpu.0.%parent: acpi0 > > >> dev.cpu.0.cx_supported: C1/0 > > >> dev.cpu.0.cx_lowest: C1 > > >> dev.cpu.0.cx_usage: 100.00% last 208us > > >> The C2 and C3 states and frequency levels are away and > > >> powerd fails to start: > > >> powerd: lookup freq: No such file or directory > > >> > > >> I tried to study acpi.c but it's a totally new area to me > > >> - I'm 15 years away from C and have zero experience with > > >> HW, kernels or so. I have a spare machine affected by this > > >> and I'm willing to work on this issue. I'm going to find > > >> some help at -users@ but before that, can you give me any > > >> advice or tip, please? > > > > > > Sure, perhaps acpi_cpu() is failing to attach. Can you get > > > verbose dmesg from before and after the change? > > > > Thank you very much! > > > > Both dmesgs attached. The difference between r216673 > > and r216674 is as follows: > > > > -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 > > 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.