From owner-freebsd-acpi@freebsd.org Sun Sep 27 07:07:57 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 11819A0ACE4 for ; Sun, 27 Sep 2015 07:07:57 +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 49057237; Sun, 27 Sep 2015 07:07:55 +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 t8R77oM1022196; Sun, 27 Sep 2015 17:07:51 +1000 (EST) (envelope-from smithi@nimnet.asn.au) Date: Sun, 27 Sep 2015 17:07:50 +1000 (EST) From: Ian Smith To: Colin Percival cc: Jung-uk Kim , John Baldwin , "freebsd-acpi@freebsd.org" , Dan Lukes Subject: Re: disabling sleep when shutting down In-Reply-To: <5606EA4A.3090705@freebsd.org> Message-ID: <20150927164605.U29510@sola.nimnet.asn.au> References: <55FA3848.7090802@freebsd.org> <55FB233D.2080000@FreeBSD.org> <55FB48E3.20401@freebsd.org> <55FC4F13.3090603@FreeBSD.org> <55FC57F9.3050702@yahoo.com> <55FE5D54.1030806@freebsd.org> <5601A863.5070406@FreeBSD.org> <560262BF.7090107@freebsd.org> <5602DE8D.3020102@FreeBSD.org> <560648A7.4030708@freebsd.org> <20150927024553.L29510@sola.nimnet.asn.au> <5606EA4A.3090705@freebsd.org> 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: Sun, 27 Sep 2015 07:07:57 -0000 On Sat, 26 Sep 2015 11:56:10 -0700, Colin Percival wrote: > On 09/26/15 10:59, Ian Smith wrote: > > On Sat, 26 Sep 2015 00:26:31 -0700, Colin Percival wrote: > > > Points without consensus: > > > * jkim thinks we should prevent suspend when we're dropping to single-user > > > mode; I'm not sure I see the point, but I don't think there's any harm in > > > doing that too. > > > > We should prevent suspending _during_ shutdown to SU, of course. Once > > happily in SU, is there any reason to disallow suspend? I've done it. > > I think the question here was about suspending during the shutdown to > single-user mode. This seemed a bit different to me since it's not a > "walk away from your laptop" sort of situation. But I've included it > (or rather, not *excluded* it) anyway. Sounds good. As all this shows, we can't assume what anyone might do :) > > > * Ian Smith would like to have suspend blocked for the last 5 minutes before > > > shutdown(8) signals init to shut the system down. I don't think anyone else > > > has expressed a desire for this, and some people have raised concerns about > > > blocking suspend for too long in case a system is running out of battery; so > > > I'm inclined to leave this out at this point. (It would be easy enough to > > > add the sysctl-frobbing to shutdown(8) if desired later.) > > > > Sorry, but that rather misrepresents my position; I was trying to deal > > specifically with the LID foot-shooting potential, in the case of user- > > initiated shutdown, so looking at possible mechanisms. Not to worry, I > > clearly didn't express myself clearly :^\ > > Ok, so you're satisfied with having the suspend-disabling triggered by > init (i.e., not happening until shutdown(8) reaches "now")? Sure, if you're satisfied that 'shutdown [..] now' - or hitting the power button as Dan mentioned - then quickly closing the lid will lose that race. As you say, with this mechanism in place, accessing it from shutdown(8) would be straightforward if deemed necessary. So, yes. > Should be trivial to MFC. Cool. Thanks, Ian From owner-freebsd-acpi@freebsd.org Sun Sep 27 08:04:39 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 07EC19CF181 for ; Sun, 27 Sep 2015 08:04:39 +0000 (UTC) (envelope-from bounces+73574-3fe6-freebsd-acpi=freebsd.org@sendgrid.net) Received: from o3.shared.sendgrid.net (o3.shared.sendgrid.net [208.117.48.85]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 42A8FE7B for ; Sun, 27 Sep 2015 08:04:37 +0000 (UTC) (envelope-from bounces+73574-3fe6-freebsd-acpi=freebsd.org@sendgrid.net) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sendgrid.info; h=subject:to:references:cc:from:mime-version:in-reply-to:content-type:content-transfer-encoding; s=smtpapi; bh=FAs8owfUCEhe/YfxxXQyTbgquJE=; b=oseFC0yqaHZVL2H0CJ A+YK643fdwM4M1brgjYekYMCLCf/Evq93CetILhbhtrw0z7uHTL6H4pG4iwUN4JX 3ehUUUGCX6IV6NNMXN+Xok1XJSnNV6OA0qPsMkS7dq752wfQSqKtqfQldQ/yagUV e3JgNFfD5I1SyL7XH9LcWAg6A= Received: by filter0691p1mdw1.sendgrid.net with SMTP id filter0691p1mdw1.20686.5607A30C18 2015-09-27 08:04:28.212624292 +0000 UTC Received: from mail.tarsnap.com (ec2-54-86-246-204.compute-1.amazonaws.com [54.86.246.204]) by ismtpd0001p1iad1.sendgrid.net (SG) with ESMTP id ntbbmh3pS1WFDN6weNT9rg for ; Sun, 27 Sep 2015 08:04:26.585 +0000 (UTC) Received: (qmail 40176 invoked from network); 27 Sep 2015 08:04:12 -0000 Received: from unknown (HELO clamshell.daemonology.net) (127.0.0.1) by ec2-107-20-205-189.compute-1.amazonaws.com with ESMTP; 27 Sep 2015 08:04:12 -0000 Received: (qmail 55085 invoked from network); 27 Sep 2015 08:04:06 -0000 Received: from unknown (HELO clamshell.daemonology.net) (127.0.0.1) by clamshell.daemonology.net with SMTP; 27 Sep 2015 08:04:06 -0000 Subject: Re: disabling sleep when shutting down To: Ian Smith References: <55FA3848.7090802@freebsd.org> <55FB233D.2080000@FreeBSD.org> <55FB48E3.20401@freebsd.org> <55FC4F13.3090603@FreeBSD.org> <55FC57F9.3050702@yahoo.com> <55FE5D54.1030806@freebsd.org> <5601A863.5070406@FreeBSD.org> <560262BF.7090107@freebsd.org> <5602DE8D.3020102@FreeBSD.org> <560648A7.4030708@freebsd.org> <20150927024553.L29510@sola.nimnet.asn.au> <5606EA4A.3090705@freebsd.org> <20150927164605.U29510@sola.nimnet.asn.au> Cc: Jung-uk Kim , John Baldwin , "freebsd-acpi@freebsd.org" , Dan Lukes From: Colin Percival Message-ID: <5607A2F6.60204@freebsd.org> Date: Sun, 27 Sep 2015 01:04:06 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <20150927164605.U29510@sola.nimnet.asn.au> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SG-EID: t2fXfoZHCw6vGsGKHqKxJ9qWwHSlQfPdDS+3+p6rOCuC391SmO4RrjfmTV15uQYsW5bGAbzcCJ2ZYS CGWT10KWYIksRBFWV8EyTWxkQ4SL08lIg3y+nnpM2iRypyFZ2e41YoxmECwbPs9y6Pkdt/4ls9HCy2 2lwc9xI552m9xX9JsIZPlcYhxM+u08E70p8g 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: Sun, 27 Sep 2015 08:04:39 -0000 On 09/27/15 00:07, Ian Smith wrote: > On Sat, 26 Sep 2015 11:56:10 -0700, Colin Percival wrote: > > Ok, so you're satisfied with having the suspend-disabling triggered by > > init (i.e., not happening until shutdown(8) reaches "now")? > > Sure, if you're satisfied that 'shutdown [..] now' - or hitting the > power button as Dan mentioned - then quickly closing the lid will lose > that race. As you say, with this mechanism in place, accessing it from > shutdown(8) would be straightforward if deemed necessary. So, yes. I'll check before committing, but I'd be very surprised if you could close the lid of a laptop in the window between hitting enter on 'shutdown -p now' and when init sets the sysctl. The code path is very direct... we should be talking a few ms at most. -- Colin Percival Security Officer Emeritus, FreeBSD | The power to serve Founder, Tarsnap | www.tarsnap.com | Online backups for the truly paranoid From owner-freebsd-acpi@freebsd.org Tue Sep 29 13:50:28 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 47C69A0BD52 for ; Tue, 29 Sep 2015 13:50:28 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 24F8914EC for ; Tue, 29 Sep 2015 13:50:28 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from ralph.baldwin.cx (c-73-231-226-104.hsd1.ca.comcast.net [73.231.226.104]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 1035CB95D; Tue, 29 Sep 2015 09:50:27 -0400 (EDT) From: John Baldwin To: freebsd-acpi@freebsd.org Cc: Arthur van der Peijl , Kevin Oberman Subject: Re: ACPI problems op ASrock Date: Mon, 28 Sep 2015 13:59:41 -0700 Message-ID: <8632725.d9CDSAQRzF@ralph.baldwin.cx> User-Agent: KMail/4.14.3 (FreeBSD/10.2-PRERELEASE; KDE/4.14.3; amd64; ; ) In-Reply-To: References: <49E6B533-4457-4583-82A2-9940C291AB51@gmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 29 Sep 2015 09:50:27 -0400 (EDT) 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 13:50:28 -0000 On Saturday, September 26, 2015 10:17:20 AM 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. Yes, I don't think tcc or throttling is related here. Your issue is that something is queueing tasks to the ACPI task queue threads (or a task is getting stuck in a busy loop). AFAIK there isn't really a great way currently to see which tasks are being queued to a taskqueue and how long they are running. It might be a nice thing to add some KTR traces for, to log how long tasks run on a given taskqueue thread (I added something a while back for callouts so they show up in schedgraph with the function pointer and you can then use a debugger to map that pointer to a symbol name). As an initial guess you might try identifying tasks that can be queued and adding some stat counters exported via sysctl for different functions. -- John Baldwin 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 From owner-freebsd-acpi@freebsd.org Tue Sep 29 16:49:47 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 E51E4A0ACB7 for ; Tue, 29 Sep 2015 16:49:47 +0000 (UTC) (envelope-from aavanderpeijl@gmail.com) Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 839F61C21; Tue, 29 Sep 2015 16:49:47 +0000 (UTC) (envelope-from aavanderpeijl@gmail.com) Received: by wicgb1 with SMTP id gb1so157937962wic.1; Tue, 29 Sep 2015 09:49:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=ibmKcj4llBlH1KxzZTyXz0C4DRwS9jTz7iIjMsYZXsw=; b=FCYM8uiRz77qWXgaPQxlXml/82NXtqlJcFH81utm4Dan0z1hl6pFs/j5Wsb77WhoQC 39EdFYT9jV+xy0p6AUG8Etw3XuUZWOd6wUmitsaA+rPo9TEBBIQshonsRQoG91ZdnXaP J2s27O5AEE48KtWK6iDSEXgBfBpk+T0EVU/1nBm9BfRzl1KTn3y2IFjRl35dW/y+UqTe qumH5WQiPFQOnkjBgG97yoVs+uO+Z566vwyXB85h+oxMYC6SZJDfcy0j9SiOK2bZSR+L JpfUesKf6nNl4p9Nee7wo6R2MdOg40LJ4+JR5It7GDKq8S9VGF5ewliweb479cDJhTTP k10Q== X-Received: by 10.180.88.168 with SMTP id bh8mr24565492wib.48.1443545385678; Tue, 29 Sep 2015 09:49:45 -0700 (PDT) Received: from macbookderpeijl.aerrow.local ([62.238.6.31]) by smtp.gmail.com with ESMTPSA id lh11sm24783449wic.18.2015.09.29.09.49.43 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 29 Sep 2015 09:49:44 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: ACPI problems op ASrock From: Arthur van der Peijl In-Reply-To: <20150930000154.E67283@sola.nimnet.asn.au> Date: Tue, 29 Sep 2015 18:49:42 +0200 Cc: Kevin Oberman , John Baldwin , "freebsd-acpi@freebsd.org" Message-Id: References: <49E6B533-4457-4583-82A2-9940C291AB51@gmail.com> <20150930000154.E67283@sola.nimnet.asn.au> To: Ian Smith X-Mailer: Apple Mail (2.1878.6) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.20 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 16:49:48 -0000 On 29 sep. 2015, at 16:42 Ian Smith wrote: > On Sat, 26 Sep 2015 10:17:20 +0200, Arthur van der Peijl wrote: > >> We're already there. The document described some other setting which=20= >> could be read: >>=20 >> [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 >>=20 >> I don't inderstand this. 100% CPU is my main issue, created by=20 >> {acpi_task} in the kernal. However -> CPU1 supports different states=20= >> as CPU0? Or is this a summary of last states? >=20 > I don't follow this either, and don't recall seeing different C-states=20= > available on different CPUs? If cpu1 has only C1, I can't see how = cpu0=20 > could ever use C2 - with its real win in terms of power consumption - = as=20 > all CPUs are now set to the same C-state (and P-state) as far as I = know. >=20 > Is cpu1 a real CPU, or HTT? Perhaps show the CPU detection details = from=20 > dmesg. powerd with standard parameters will always run at top speed=20= > with the CPU usage/idle figures you quoted; you could get it to run=20 > slower if you adjusted -i and -r settings, as an immediate workaround. >=20 Took CPU and ACPI related messages from dmesg: CPU: Intel(R) Pentium(R) CPU G3220 @ 3.00GHz (2993.38-MHz K8-class CPU) Origin=3D"GenuineIntel" Id=3D0x306c3 Family=3D0x6 Model=3D0x3c = Stepping=3D3 = Features=3D0xbfebfbff = Features2=3D0x4ddaebbf,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,MOVBE,POPCNT,TSCDLT,XSAVE,OSXSAVE,= RDRAND> AMD Features=3D0x2c100800 AMD Features2=3D0x21 Structured Extended = Features=3D0x2603 XSAVE Features=3D0x1 VT-x: PAT,HLT,MTF,PAUSE,EPT,UG,VPID TSC: P-state invariant, performance statistics ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 2 acpi0: on motherboard acpi0: Power Button (fixed) cpu0: on acpi0 cpu1: on acpi0 Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1808-0x180b on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: irq 16 at device 1.0 on pci0 pci1: on pcib1 pcib2: irq 16 at device 1.1 on pci0 pci2: on pcib2 pcib3: irq 16 at device 28.0 on pci0 pci3: on pcib3 pcib4: irq 18 at device 28.2 on pci0 pci4: on pcib4 pcib6: irq 19 at device 28.7 on pci0 pci6: on pcib6 pcib7: irq 19 at device 0.0 on pci6 pci7: on pcib7 acpi_button0: on acpi0 acpi_button1: on acpi0 acpi_tz0: on acpi0 acpi_tz1: on acpi0 coretemp0: on cpu0 coretemp1: on cpu1 > But listen to John about debugging the ACPI tasks CPU usage issue .. That's where I'm stuck as a junior FreeBSD user: @John; can you suggest = where to search for this? commands? Regards, Arthur van der Peijl From owner-freebsd-acpi@freebsd.org Thu Oct 1 10:54:09 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 6441AA0DF0A for ; Thu, 1 Oct 2015 10:54:09 +0000 (UTC) (envelope-from bounces+73574-3fe6-freebsd-acpi=freebsd.org@sendgrid.net) Received: from o1.l99.sendgrid.net (o1.l99.sendgrid.net [198.37.153.74]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 184BF1277 for ; Thu, 1 Oct 2015 10:54:08 +0000 (UTC) (envelope-from bounces+73574-3fe6-freebsd-acpi=freebsd.org@sendgrid.net) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sendgrid.info; h=subject:references:to:from:mime-version:in-reply-to:content-type:content-transfer-encoding; s=smtpapi; bh=IOwULHOIPSLZIM4JvRk4K6e/jN0=; b=MgGFlqZaQLd+JEVOee 3r7o6gFdt2fPPiov9+Nd2kopUeTLdck1VgD/5B9i+yUhYSGDV2+gw0Zn4zUxNAoo +XCFSA7IJxUpH6zCi9ZDBLNVF5n2TiUplktwA4JkpNugflk58CsAFDObbjtGwlLM JJvaPiQoz1kVnH4K0QNjtsG8s= Received: by filter0542p1mdw1.sendgrid.net with SMTP id filter0542p1mdw1.13720.560D10C99 2015-10-01 10:54:01.117797374 +0000 UTC Received: from localhost ([UNAVAILABLE]. [10.42.2.107]) by 10.42.243.102:2500 (trex/5.2.14); Thu, 01 Oct 2015 10:54:01 GMT Received: from mail.tarsnap.com (ec2-54-86-246-204.compute-1.amazonaws.com [54.86.246.204]) by ismtpd0001p1iad1.sendgrid.net (SG) with ESMTP id eX2RIFB9RrKyeNnYYl9Mhw for ; Thu, 01 Oct 2015 10:54:01.122 +0000 (UTC) Received: (qmail 58882 invoked from network); 1 Oct 2015 10:53:42 -0000 Received: from unknown (HELO clamshell.daemonology.net) (127.0.0.1) by ec2-107-20-205-189.compute-1.amazonaws.com with ESMTP; 1 Oct 2015 10:53:42 -0000 Received: (qmail 4193 invoked from network); 1 Oct 2015 10:53:43 -0000 Received: from unknown (HELO clamshell.daemonology.net) (127.0.0.1) by clamshell.daemonology.net with SMTP; 1 Oct 2015 10:53:43 -0000 Subject: Fwd: svn commit: r288446 - in head: sbin/init sys/dev/acpica sys/kern sys/sys References: <201510011052.t91AqR38036244@repo.freebsd.org> To: "freebsd-acpi@freebsd.org" From: Colin Percival X-Forwarded-Message-Id: <201510011052.t91AqR38036244@repo.freebsd.org> Message-ID: <560D10B7.2010501@freebsd.org> Date: Thu, 1 Oct 2015 03:53:43 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <201510011052.t91AqR38036244@repo.freebsd.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SG-EID: t2fXfoZHCw6vGsGKHqKxJ9qWwHSlQfPdDS+3+p6rOCvdO8A+qs/ctrlROD3dIw+jW84eAcq+CQMczQ 8rDyViOseewnuZxvslDlKHlnkikRUvmvdaoAcCb40ZD9bkglS1/+AagkXLVDZuLmG517KNhX3RtVUx OFOtIu1s5YjA2ZfsLpBj4nLMOSbnbmssSB9a 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: Thu, 01 Oct 2015 10:54:09 -0000 Thanks to everybody who helped with the design and discussion of this. -------- Forwarded Message -------- Subject: svn commit: r288446 - in head: sbin/init sys/dev/acpica sys/kern sys/sys Date: Thu, 1 Oct 2015 10:52:27 +0000 (UTC) From: Colin Percival To: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Author: cperciva Date: Thu Oct 1 10:52:26 2015 New Revision: 288446 URL: https://svnweb.freebsd.org/changeset/base/288446 Log: Disable suspend when we're shutting down. This solves the "tell FreeBSD to shut down; close laptop lid" scenario which otherwise tended to end with a laptop overheating or the battery dying. The implementation uses a new sysctl, kern.suspend_blocked; init(8) sets this while rc.suspend runs, and the ACPI sleep code ignores requests while the sysctl is set. Discussed on: freebsd-acpi (35 emails) MFC after: 1 week Modified: head/sbin/init/init.c head/sys/dev/acpica/acpi.c head/sys/kern/kern_shutdown.c head/sys/sys/systm.h Modified: head/sbin/init/init.c ============================================================================== --- head/sbin/init/init.c Thu Oct 1 10:43:40 2015 (r288445) +++ head/sbin/init/init.c Thu Oct 1 10:52:26 2015 (r288446) @@ -1487,6 +1487,15 @@ static state_func_t death(void) { session_t *sp; + int block, blocked; + size_t len; + + /* Temporarily block suspend. */ + len = sizeof(blocked); + block = 1; + if (sysctlbyname("kern.suspend_blocked", &blocked, &len, + &block, sizeof(block)) == -1) + blocked = 0; /* * Also revoke the TTY here. Because runshutdown() may reopen @@ -1503,6 +1512,11 @@ death(void) /* Try to run the rc.shutdown script within a period of time */ runshutdown(); + /* Unblock suspend if we blocked it. */ + if (!blocked) + sysctlbyname("kern.suspend_blocked", NULL, NULL, + &blocked, sizeof(blocked)); + return (state_func_t) death_single; } Modified: head/sys/dev/acpica/acpi.c ============================================================================== --- head/sys/dev/acpica/acpi.c Thu Oct 1 10:43:40 2015 (r288445) +++ head/sys/dev/acpica/acpi.c Thu Oct 1 10:52:26 2015 (r288446) @@ -2574,8 +2574,11 @@ acpi_ReqSleepState(struct acpi_softc *sc if (!acpi_sleep_states[state]) return (EOPNOTSUPP); - /* If a suspend request is already in progress, just return. */ - if (sc->acpi_next_sstate != 0) { + /* + * If a reboot/shutdown/suspend request is already in progress or + * suspend is blocked due to an upcoming shutdown, just return. + */ + if (rebooting || sc->acpi_next_sstate != 0 || suspend_blocked) { return (0); } Modified: head/sys/kern/kern_shutdown.c ============================================================================== --- head/sys/kern/kern_shutdown.c Thu Oct 1 10:43:40 2015 (r288445) +++ head/sys/kern/kern_shutdown.c Thu Oct 1 10:52:26 2015 (r288446) @@ -137,6 +137,10 @@ static int show_busybufs = 1; SYSCTL_INT(_kern_shutdown, OID_AUTO, show_busybufs, CTLFLAG_RW, &show_busybufs, 0, ""); +int suspend_blocked = 0; +SYSCTL_INT(_kern, OID_AUTO, suspend_blocked, CTLFLAG_RW, + &suspend_blocked, 0, "Block suspend due to a pending shutdown"); + /* * Variable panicstr contains argument to first call to panic; used as flag * to indicate that the kernel has already called panic. Modified: head/sys/sys/systm.h ============================================================================== --- head/sys/sys/systm.h Thu Oct 1 10:43:40 2015 (r288445) +++ head/sys/sys/systm.h Thu Oct 1 10:52:26 2015 (r288446) @@ -46,6 +46,7 @@ #include /* for people using printf mainly */ extern int cold; /* nonzero if we are doing a cold boot */ +extern int suspend_blocked; /* block suspend due to pending shutdown */ extern int rebooting; /* kern_reboot() has been called. */ extern const char *panicstr; /* panic message */ extern char version[]; /* system version */