From owner-freebsd-acpi@freebsd.org Tue Sep 29 14:43:06 2015 Return-Path: Delivered-To: freebsd-acpi@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 14A73A0B88D for ; Tue, 29 Sep 2015 14:43:06 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [115.70.110.159]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 609A51D55; Tue, 29 Sep 2015 14:43:04 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id t8TEgvXT037167; Wed, 30 Sep 2015 00:42:57 +1000 (EST) (envelope-from smithi@nimnet.asn.au) Date: Wed, 30 Sep 2015 00:42:57 +1000 (EST) From: Ian Smith To: Arthur van der Peijl cc: Kevin Oberman , John Baldwin , "freebsd-acpi@freebsd.org" Subject: Re: ACPI problems op ASrock In-Reply-To: Message-ID: <20150930000154.E67283@sola.nimnet.asn.au> References: <49E6B533-4457-4583-82A2-9940C291AB51@gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Sep 2015 14:43:06 -0000 On Sat, 26 Sep 2015 10:17:20 +0200, Arthur van der Peijl wrote: > Thank you for assistance: powerd must clearly not be my focus: the > CPU stays high and thus cannot go into idle mode. > No need to change performance_cx_lowest as I just have a Pentium > G3220 running. > > [root@zfsguru /home/ssh]# cat /boot/loader.conf | grep hint. > hint.p4tcc.0.disabled="1" > hint.acpi_throttle.0.disabled="1" > > Tried to change lowest level on running system: > > [root@zfsguru /home/ssh]# sysctl dev.cpu.0.cx_lowest=C8 > dev.cpu.0.cx_lowest: C8 -> C8 You really need to set hw.acpi.cpu.cx_lowest=C8 instead; this is then propogated to dev.cpu.*.cx_lowest, updated when /etc/rc.d/power_profile runs on losing or regaining mains power. However, that won't help here. > We're already there. The document described some other setting which > could be read: > > [root@zfsguru /home/ssh]# sysctl dev.cpu | grep cx > dev.cpu.1.cx_usage: 100.00% last 5us > dev.cpu.1.cx_lowest: C8 > dev.cpu.1.cx_supported: C1/1/1 > dev.cpu.0.cx_usage: 100.00% 0.00% last 4us > dev.cpu.0.cx_lowest: C8 > dev.cpu.0.cx_supported: C1/1/1 C2/2/117 > > I don't inderstand this. 100% CPU is my main issue, created by > {acpi_task} in the kernal. However -> CPU1 supports different states > as CPU0? Or is this a summary of last states? I don't follow this either, and don't recall seeing different C-states available on different CPUs? If cpu1 has only C1, I can't see how cpu0 could ever use C2 - with its real win in terms of power consumption - as all CPUs are now set to the same C-state (and P-state) as far as I know. Is cpu1 a real CPU, or HTT? Perhaps show the CPU detection details from dmesg. powerd with standard parameters will always run at top speed with the CPU usage/idle figures you quoted; you could get it to run slower if you adjusted -i and -r settings, as an immediate workaround. But listen to John about debugging the ACPI tasks CPU usage issue .. cheers, Ian