From owner-freebsd-acpi@FreeBSD.ORG Sun Jun 30 14:22:21 2013 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 6D6D041E; Sun, 30 Jun 2013 14:22:21 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [115.70.110.159]) by mx1.freebsd.org (Postfix) with ESMTP id ABA821FE2; Sun, 30 Jun 2013 14:22:19 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id r5UEM9O2027295; Mon, 1 Jul 2013 00:22:10 +1000 (EST) (envelope-from smithi@nimnet.asn.au) Date: Mon, 1 Jul 2013 00:22:09 +1000 (EST) From: Ian Smith To: Adrian Chadd Subject: Re: USB ports on Lenovo T400 do not work after a suspend/resume In-Reply-To: Message-ID: <20130630233640.Y23789@sola.nimnet.asn.au> References: <20130621220013.X55167@sola.nimnet.asn.au> <20130626152833.M78748@sola.nimnet.asn.au> <20130626195154.GK88288@e-new.0x20.net> <20130627213331.W26984@sola.nimnet.asn.au> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: freebsd-acpi@freebsd.org, freebsd-stable@freebsd.org, freebsd-usb@freebsd.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Jun 2013 14:22:21 -0000 On Sat, 29 Jun 2013, Adrian Chadd wrote: > On 27 June 2013 04:58, Ian Smith wrote: > > We don't yet know if this is a bus, ACPI &/or USB issue. Home yet? :) > > Yup: > > http://people.freebsd.org/~adrian/usb/ > > dmesg.boot = dmesg at startup > > 1 - after powerup, usb device in > 2 - after acpiconf -s3 suspend/resume, w/ a USB device plugged in > 3 - after acpiconf -s3 suspend/resume, with a USB device removed > before suspend/resume After removing [numbers] (for WITNESS?), diff started making sense. The below is between the first and second suspend/resume cycles in dmesg-3.txt, encompassing the others. Nothing of note that I can see, if that usb hub-to-bus remapping is normal. As you said, 'CPU0: local APIC error 0x40' looks maybe sus. Maybe someone who knows might comment on that? Just checking: you've tried other USB devices apart from uftdi0? Out of ideas, and my depth, Ian ======= --- dm3.a 2013-06-30 21:49:48.000000000 +1000 +++ dm3.b 2013-06-30 21:50:30.000000000 +1000 @@ -1,23 +1,21 @@ -ugen3.2: at usbus3 -[] uftdi0: on usbus3 +ugen3.2: at usbus3 (disconnected) +[] uftdi0: at uhub4, port 2, addr 2 (disconnected) (ada0:ahcich0:0:0:0): spin-down [] acpi_lid0: wake_prep enabled for \134_SB_.LID_ (S3) [] acpi_button0: wake_prep enabled for \134_SB_.SLPB (S3) -[] uhub0: at usbus0, port 1, addr 1 (disconnected) -[] uhub1: at usbus1, port 1, addr 1 (disconnected) +[] uhub2: at usbus0, port 1, addr 1 (disconnected) +[] uhub0: at usbus1, port 1, addr 1 (disconnected) ugen1.2: at usbus1 (disconnected) ugen1.3: at usbus1 (disconnected) -[] ubt0: at uhub1, port 2, addr 3 (disconnected) -[] uhub2: at usbus2, port 1, addr 1 (disconnected) +[] ubt0: at uhub0, port 2, addr 3 (disconnected) +[] uhub1: at usbus2, port 1, addr 1 (disconnected) ugen2.2: at usbus2 (disconnected) pci0:0:28:0: Transition from D0 to D3 pci0:0:28:1: Transition from D0 to D3 pci0:0:28:3: Transition from D0 to D3 pci0:0:28:4: Transition from D0 to D3 -[] uhub3: at usbus3, port 1, addr 1 (disconnected) -ugen3.2: at usbus3 (disconnected) -[] uftdi0: at uhub3, port 2, addr 2 (disconnected) -[] uhub4: at usbus4, port 1, addr 1 (disconnected) +[] uhub4: at usbus3, port 1, addr 1 (disconnected) +[] uhub3: at usbus4, port 1, addr 1 (disconnected) [] uhub5: at usbus5, port 1, addr 1 (disconnected) pci0:21:0:0: Transition from D0 to D2 [] pci21: failed to set ACPI power state D2 on \134_SB_.PCI0.PCI1.CDBS: AE_BAD_PARAMETER @@ -73,12 +71,12 @@ kbdc: RESET_AUX ID:0000 [] battery0: battery initialization start [] ahcich0: AHCI reset: device ready after 100ms -[] uhub0: on usbus1 -[] uhub1: on usbus2 -[] uhub2: on usbus0 -[] uhub3: on usbus4 -[] uhub4: on usbus3 -[] uhub5: on usbus5 +[] uhub0: on usbus0 +[] uhub1: on usbus1 +[] uhub2: on usbus3 +[] uhub3: on usbus2 +[] uhub4: on usbus5 +[] uhub5: on usbus4 CPU0: local APIC error 0x40 [] battery0: battery initialization done, tried 1 times (ada0:ahcich0:0:0:0): resume @@ -92,15 +90,13 @@ intpin=a, irq=16 powerspec 2 supports D0 D3 current D0 [] cardbus0: at device 0.0 (no driver attached) -[] uhub0: 2 ports with 2 removable, self powered [] uhub1: 2 ports with 2 removable, self powered [] uhub2: 2 ports with 2 removable, self powered +[] uhub0: 2 ports with 2 removable, self powered [] uhub3: 2 ports with 2 removable, self powered -[] uhub5: 2 ports with 2 removable, self powered [] uhub4: 2 ports with 2 removable, self powered +[] uhub5: 2 ports with 2 removable, self powered ugen1.2: at usbus1 -ugen3.2: at usbus3 -[] uftdi0: on usbus3 ugen2.2: at usbus2 ugen1.3: at usbus1 [] ubt0: on usbus1 ======= From owner-freebsd-acpi@FreeBSD.ORG Sun Jun 30 22:02:58 2013 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id CA9D865A; Sun, 30 Jun 2013 22:02:58 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-qa0-x230.google.com (mail-qa0-x230.google.com [IPv6:2607:f8b0:400d:c00::230]) by mx1.freebsd.org (Postfix) with ESMTP id 69A6E1D8F; Sun, 30 Jun 2013 22:02:58 +0000 (UTC) Received: by mail-qa0-f48.google.com with SMTP id cm16so1683943qab.14 for ; Sun, 30 Jun 2013 15:02:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=RJdUV8rwkvE5t6AFUwjOG0lq8zpFGTnw8dKR53O6p6A=; b=fzSP5YaXZUPV4pkQM39gVBRdZfcyYrHZKDbStsrDO69o/EFb3P1QFpqwgRiZO2Zp1T +oH4J52Go+Y/Pij6qoa0xujhBcVFlAiTMEzI+lKEeXbEjrqqd+ErxYK5DzTxhOesW2x4 3H1UTH0Xeofxtqpj8XRy6t3abM5mHFcx1EOpsAqeOvWPCCJ/8cX6yfAdY/UXSJDW6jvn vM/XdJMw8OFQMXC5a988aFzYT5xzMRVBvaA/8AvYgx5RkM5kNsNrcJ2EKaMNQsJVavPg rW6lrr6XsElMPnW7Kos5ItM1M5JZMO6AErCaPSpfcjE+TrV/7bugoQBmjwFC5xtY+sUS 7gzQ== MIME-Version: 1.0 X-Received: by 10.229.160.9 with SMTP id l9mr6721504qcx.100.1372629777640; Sun, 30 Jun 2013 15:02:57 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.101.134 with HTTP; Sun, 30 Jun 2013 15:02:57 -0700 (PDT) In-Reply-To: <20130630233640.Y23789@sola.nimnet.asn.au> References: <20130621220013.X55167@sola.nimnet.asn.au> <20130626152833.M78748@sola.nimnet.asn.au> <20130626195154.GK88288@e-new.0x20.net> <20130627213331.W26984@sola.nimnet.asn.au> <20130630233640.Y23789@sola.nimnet.asn.au> Date: Sun, 30 Jun 2013 15:02:57 -0700 X-Google-Sender-Auth: zN3vNri3nT8fGv7WysGP1kwtPDQ Message-ID: Subject: Re: USB ports on Lenovo T400 do not work after a suspend/resume From: Adrian Chadd To: Ian Smith Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-acpi@freebsd.org, freebsd-stable@freebsd.org, freebsd-usb@freebsd.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Jun 2013 22:02:58 -0000 On 30 June 2013 07:22, Ian Smith wrote: > After removing [numbers] (for WITNESS?), diff started making sense. > The below is between the first and second suspend/resume cycles in > dmesg-3.txt, encompassing the others. Cool! > Nothing of note that I can see, if that usb hub-to-bus remapping is > normal. As you said, 'CPU0: local APIC error 0x40' looks maybe sus. > Maybe someone who knows might comment on that? > > Just checking: you've tried other USB devices apart from uftdi0? Yup, there's no 5v on the port. -adrian From owner-freebsd-acpi@FreeBSD.ORG Mon Jul 1 11:06:43 2013 Return-Path: Delivered-To: freebsd-acpi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 0EEA45DA for ; Mon, 1 Jul 2013 11:06:43 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id DC43B10CD for ; Mon, 1 Jul 2013 11:06:42 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r61B6gG2085689 for ; Mon, 1 Jul 2013 11:06:42 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r61B6gjf085687 for freebsd-acpi@FreeBSD.org; Mon, 1 Jul 2013 11:06:42 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 1 Jul 2013 11:06:42 GMT Message-Id: <201307011106.r61B6gjf085687@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-acpi@FreeBSD.org Subject: Current problem reports assigned to freebsd-acpi@FreeBSD.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jul 2013 11:06:43 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/174766 acpi [acpi] Random acpi panic o kern/174504 acpi [ACPI] Suspend/resume broken on Lenovo x220 o kern/171305 acpi [acpi] acpi_tz0: _CRT value is absurd, ignored (256.0C o kern/165381 acpi [cpufreq] powerd(8) eats CPUs for breakfast o kern/164329 acpi [acpi] hw.acpi.thermal.tz0.temperature shows strange v o kern/162859 acpi [acpi] ACPI battery/acline monitoring partialy working o kern/161715 acpi [acpi] Dell E6520 doesn't resume after ACPI suspend o kern/161713 acpi [acpi] Suspend on Dell E6520 o kern/160838 acpi [acpi] ACPI Battery Monitor Non-Functional o kern/160419 acpi [acpi_thermal] acpi_thermal kernel thread high CPU usa o kern/158689 acpi [acpi] value of sysctl hw.acpi.thermal.polling_rate ne o kern/154955 acpi [acpi] Keyboard or ACPI doesn't work on Lenovo S10-3 o kern/152098 acpi [acpi] Lenovo T61p does not resume o i386/146715 acpi [acpi] Suspend works, resume not on a HP Probook 4510s o kern/145306 acpi [acpi]: Can't change brightness on HP ProBook 4510s o i386/143798 acpi [acpi] shutdown problem with SiS K7S5A o kern/143420 acpi [acpi] ACPI issues with Toshiba o kern/142009 acpi [acpi] [panic] Panic in AcpiNsGetAttachedObject o kern/139088 acpi [acpi] ACPI Exception: AE_AML_INFINITE_LOOP error o amd64/138210 acpi [acpi] acer aspire 5536 ACPI problems (S3, brightness, o i386/136008 acpi [acpi] Dell Vostro 1310 will not shutdown (Requires us o kern/132602 acpi [acpi] ACPI Problem with Intel SS4200: System does not a i386/122887 acpi [panic] [atkbdc] 7.0-RELEASE on IBM HS20 panics immed s kern/112544 acpi [acpi] [patch] Add High Precision Event Timer Driver f o kern/91594 acpi [acpi] FreeBSD > 5.4 w/ACPI fails to detect Intel Pro/ o kern/73823 acpi [request] acpi / power-on by timer support 26 problems total. From owner-freebsd-acpi@FreeBSD.ORG Tue Jul 2 19:50:01 2013 Return-Path: Delivered-To: freebsd-acpi@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 8DEB0C48 for ; Tue, 2 Jul 2013 19:50:01 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 6516D11FF for ; Tue, 2 Jul 2013 19:50:01 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r62Jo16t099533 for ; Tue, 2 Jul 2013 19:50:01 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r62Jo1dD099532; Tue, 2 Jul 2013 19:50:01 GMT (envelope-from gnats) Date: Tue, 2 Jul 2013 19:50:01 GMT Message-Id: <201307021950.r62Jo1dD099532@freefall.freebsd.org> To: freebsd-acpi@FreeBSD.org Cc: From: John Baldwin Subject: Re: kern/91594: [acpi] FreeBSD > 5.4 w/ACPI fails to detect Intel Pro/1000 MT 4-port NIC in PCI slot 3 of DL380 G4 [regression] X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: John Baldwin List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2013 19:50:01 -0000 The following reply was made to PR kern/91594; it has been noted by GNATS. From: John Baldwin To: bug-followup@FreeBSD.org, bad@bsd.de Cc: Subject: Re: kern/91594: [acpi] FreeBSD > 5.4 w/ACPI fails to detect Intel Pro/1000 MT 4-port NIC in PCI slot 3 of DL380 G4 [regression] Date: Tue, 02 Jul 2013 12:49:13 -0700 This is a multi-part message in MIME format. --------------040100040502060400080805 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Please try this change: -- John Baldwin --------------040100040502060400080805 Content-Type: text/plain; charset=UTF-8; x-mac-type="0"; x-mac-creator="0"; name="pcib_acpi_present.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="pcib_acpi_present.patch" --- //depot/vendor/freebsd/src/sys/dev/acpica/acpi_pcib.c +++ //depot/projects/pci/sys/dev/acpica/acpi_pcib.c @@ -135,15 +135,6 @@ ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__); /* - * Don't attach if we're not really there. - * - * XXX: This isn't entirely correct since we may be a PCI bus - * on a hot-plug docking station, etc. - */ - if (!acpi_DeviceIsPresent(dev)) - return_VALUE(ENXIO); - - /* * Get the PCI interrupt routing table for this bus. If we can't * get it, this is not an error but may reduce functionality. There * are several valid bridges in the field that do not have a _PRT, so --- //depot/vendor/freebsd/src/sys/dev/acpica/acpi_pcib_acpi.c +++ //depot/projects/pci/sys/dev/acpica/acpi_pcib_acpi.c @@ -287,6 +292,12 @@ sc->ap_handle = acpi_get_handle(dev); /* + * Don't attach if we're not really there. + */ + if (!acpi_DeviceIsPresent(dev)) + return (ENXIO); + + /* * Get our segment number by evaluating _SEG. * It's OK for this to not exist. */ @@ -353,7 +364,7 @@ if (status != AE_NOT_FOUND) { device_printf(dev, "could not evaluate _BBN - %s\n", AcpiFormatException(status)); - return_VALUE (ENXIO); + return (ENXIO); } else { /* If it's not found, assume 0. */ sc->ap_bus = 0; --------------040100040502060400080805-- From owner-freebsd-acpi@FreeBSD.ORG Wed Jul 3 17:28:25 2013 Return-Path: Delivered-To: freebsd-acpi@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id B0E85F06; Wed, 3 Jul 2013 17:28:25 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 8CB8E1A2E; Wed, 3 Jul 2013 17:28:25 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r63HSPRB097699; Wed, 3 Jul 2013 17:28:25 GMT (envelope-from jhb@freefall.freebsd.org) Received: (from jhb@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r63HSPTD097698; Wed, 3 Jul 2013 17:28:25 GMT (envelope-from jhb) Date: Wed, 3 Jul 2013 17:28:25 GMT Message-Id: <201307031728.r63HSPTD097698@freefall.freebsd.org> To: bad@bsd.de, jhb@FreeBSD.org, freebsd-acpi@FreeBSD.org, jhb@FreeBSD.org From: jhb@FreeBSD.org Subject: Re: kern/91594: [acpi] FreeBSD > 5.4 w/ACPI fails to detect Intel Pro/1000 MT 4-port NIC in PCI slot 3 of DL380 G4 [regression] X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jul 2013 17:28:25 -0000 Synopsis: [acpi] FreeBSD > 5.4 w/ACPI fails to detect Intel Pro/1000 MT 4-port NIC in PCI slot 3 of DL380 G4 [regression] State-Changed-From-To: open->patched State-Changed-By: jhb State-Changed-When: Wed Jul 3 17:27:46 UTC 2013 State-Changed-Why: Fix committed to HEAD. Responsible-Changed-From-To: freebsd-acpi->jhb Responsible-Changed-By: jhb Responsible-Changed-When: Wed Jul 3 17:27:46 UTC 2013 Responsible-Changed-Why: Fix committed to HEAD. http://www.freebsd.org/cgi/query-pr.cgi?pr=91594 From owner-freebsd-acpi@FreeBSD.ORG Fri Jul 5 02:12:14 2013 Return-Path: Delivered-To: acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 8BA86530; Fri, 5 Jul 2013 02:12:14 +0000 (UTC) (envelope-from wblock@wonkity.com) Received: from wonkity.com (wonkity.com [67.158.26.137]) by mx1.freebsd.org (Postfix) with ESMTP id 1B26D19ED; Fri, 5 Jul 2013 02:12:13 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.7/8.14.7) with ESMTP id r652CDDO010414; Thu, 4 Jul 2013 20:12:13 -0600 (MDT) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.7/8.14.7/Submit) with ESMTP id r652CCFg010411; Thu, 4 Jul 2013 20:12:13 -0600 (MDT) (envelope-from wblock@wonkity.com) Date: Thu, 4 Jul 2013 20:12:12 -0600 (MDT) From: Warren Block To: acpi@freebsd.org Subject: Hyper mode for powerd Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="3512871622-242739370-1372990333=:10280" X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (wonkity.com [127.0.0.1]); Thu, 04 Jul 2013 20:12:13 -0600 (MDT) Cc: wblock@freebsd.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jul 2013 02:12:14 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --3512871622-242739370-1372990333=:10280 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Attached is a proposed patch for -head that adds a "hyper" mode to powerd. Instead of slewing like the adaptive modes, this mode drops all the way to the lowest frequency when the system is idle, and jumps all the way to the highest frequency when there is any load. Subjectively, it seems more responsive for desktop use than hiadaptive mode. That's hard to benchmark. Power usage is another question. This mode might use less power than the adaptive modes, but that's also difficult to benchmark. Comments welcome. --3512871622-242739370-1372990333=:10280 Content-Type: TEXT/PLAIN; charset=US-ASCII; name=powerd-hyper.diff Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename=powerd-hyper.diff SW5kZXg6IHVzci5zYmluL3Bvd2VyZC9wb3dlcmQuYw0KPT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PQ0KLS0tIHVzci5zYmluL3Bvd2VyZC9wb3dlcmQuYwkocmV2 aXNpb24gMjUyNzEzKQ0KKysrIHVzci5zYmluL3Bvd2VyZC9wb3dlcmQuYwko d29ya2luZyBjb3B5KQ0KQEAgLTYzLDYgKzYzLDcgQEANCiAJTU9ERV9NSU4s DQogCU1PREVfQURBUFRJVkUsDQogCU1PREVfSElBREFQVElWRSwNCisJTU9E RV9IWVBFUiwNCiAJTU9ERV9NQVgsDQogfSBtb2Rlc190Ow0KIA0KQEAgLTQx OSw2ICs0MjAsOCBAQA0KIAkJKm1vZGUgPSBNT0RFX0FEQVBUSVZFOw0KIAll bHNlIGlmIChzdHJjbXAoYXJnLCAiaGlhZGFwdGl2ZSIpID09IDAgfHwgc3Ry Y21wKGFyZywgImhhZHAiKSA9PSAwKQ0KIAkJKm1vZGUgPSBNT0RFX0hJQURB UFRJVkU7DQorCWVsc2UgaWYgKHN0cmNtcChhcmcsICJoeXBlciIpID09IDAg fHwgc3RyY21wKGFyZywgImh5cGUiKSA9PSAwKQ0KKwkJKm1vZGUgPSBNT0RF X0hZUEVSOw0KIAllbHNlDQogCQllcnJ4KDEsICJiYWQgb3B0aW9uOiAtJWMg JXMiLCAoY2hhciljaCwgb3B0YXJnKTsNCiB9DQpAQCAtNTkzLDExICs1OTYs MTEgQEANCiAJaWYgKGFjbGluZV9zdGF0dXMgPiBTUkNfVU5LTk9XTikNCiAJ CWVycngoMSwgImludmFsaWQgQUMgbGluZSBzdGF0dXMgJWQiLCBhY2xpbmVf c3RhdHVzKTsNCiAJaWYgKChhY2xpbmVfc3RhdHVzID09IFNSQ19BQyAmJg0K LQkgICAgKG1vZGVfYWMgPT0gTU9ERV9BREFQVElWRSB8fCBtb2RlX2FjID09 IE1PREVfSElBREFQVElWRSkpIHx8DQorCSAgICAobW9kZV9hYyA9PSBNT0RF X0FEQVBUSVZFIHx8IG1vZGVfYWMgPT0gTU9ERV9ISUFEQVBUSVZFIHx8IG1v ZGVfYWMgPT0gTU9ERV9IWVBFUikpIHx8DQogCSAgICAoYWNsaW5lX3N0YXR1 cyA9PSBTUkNfQkFUVEVSWSAmJg0KLQkgICAgKG1vZGVfYmF0dGVyeSA9PSBN T0RFX0FEQVBUSVZFIHx8IG1vZGVfYmF0dGVyeSA9PSBNT0RFX0hJQURBUFRJ VkUpKSB8fA0KKwkgICAgKG1vZGVfYmF0dGVyeSA9PSBNT0RFX0FEQVBUSVZF IHx8IG1vZGVfYmF0dGVyeSA9PSBNT0RFX0hJQURBUFRJVkUgfHwgbW9kZV9i YXR0ZXJ5ID09IE1PREVfSFlQRVIpKSB8fA0KIAkgICAgKGFjbGluZV9zdGF0 dXMgPT0gU1JDX1VOS05PV04gJiYNCi0JICAgIChtb2RlX25vbmUgPT0gTU9E RV9BREFQVElWRSB8fCBtb2RlX25vbmUgPT0gTU9ERV9ISUFEQVBUSVZFKSkp IHsNCisJICAgIChtb2RlX25vbmUgPT0gTU9ERV9BREFQVElWRSB8fCBtb2Rl X25vbmUgPT0gTU9ERV9ISUFEQVBUSVZFIHx8IG1vZGVfbm9uZSA9PSBNT0RF X0hZUEVSKSkpIHsNCiAJCS8qIFJlYWQgdGhlIGN1cnJlbnQgZnJlcXVlbmN5 LiAqLw0KIAkJbGVuID0gc2l6ZW9mKGN1cmZyZXEpOw0KIAkJaWYgKHN5c2N0 bChmcmVxX21pYiwgNCwgJmN1cmZyZXEsICZsZW4sIE5VTEwsIDApICE9IDAp IHsNCkBAIC03NjQsNiArNzY3LDQxIEBADQogCQkJCQlmcmVxID0gZnJlcXNb bnVtZnJlcXMgLSAxXTsNCiAJCQl9DQogCQl9DQorDQorCQlpZiAobW9kZSA9 PSBNT0RFX0hZUEVSKSB7DQorCQkJaWYgKGxvYWQgPiBjcHVfcnVubmluZ19t YXJrIC8gNCkgew0KKwkJCQlmcmVxID0gZnJlcXNbMF07DQorCQkJCWlmIChj dXJmcmVxICE9IGZyZXEpIHsNCisJCQkJCWlmICh2ZmxhZykgew0KKwkJCQkJ CXByaW50Zigibm93IG9wZXJhdGluZyBvbiAlcyBwb3dlcjsgIg0KKwkJCQkJ ICAgIAkiY2hhbmdpbmcgZnJlcXVlbmN5IHRvICVkIE1IelxuIiwNCisJCQkJ CSAgICAJbW9kZXNbYWNsaW5lX3N0YXR1c10sIGZyZXEpOw0KKwkJCQkJfQ0K KwkJCQkJaWRsZSA9IDA7DQorCQkJCQlpZiAoc2V0X2ZyZXEoZnJlcSkgIT0g MCkgew0KKwkJCQkJCXdhcm4oImVycm9yIHNldHRpbmcgQ1BVIGZyZXEgJWQi LA0KKwkJCQkgICAgCSAgICAJZnJlcSk7DQorCQkJCQkJY29udGludWU7DQor CQkJCQl9DQorCQkJCX0NCisJCQl9IGVsc2Ugew0KKwkJCQlmcmVxID0gZnJl cXNbbnVtZnJlcXMgLSAxXTsNCisJCQkJaWYgKGN1cmZyZXEgIT0gZnJlcSkg ew0KKwkJCQkJaWYgKHZmbGFnKSB7DQorCQkJCQkJcHJpbnRmKCJub3cgb3Bl cmF0aW5nIG9uICVzIHBvd2VyOyAiDQorCQkJCQkgICAgCSJjaGFuZ2luZyBm cmVxdWVuY3kgdG8gJWQgTUh6XG4iLA0KKwkJCQkJICAgIAltb2Rlc1thY2xp bmVfc3RhdHVzXSwgZnJlcSk7DQorCQkJCQl9DQorCQkJCQlpZGxlID0gMDsN CisJCQkJCWlmIChzZXRfZnJlcShmcmVxKSAhPSAwKSB7DQorCQkJCQkJd2Fy bigiZXJyb3Igc2V0dGluZyBDUFUgZnJlcSAlZCIsDQorCQkJCQkgICAgCWZy ZXEpOw0KKwkJCQkJCWNvbnRpbnVlOw0KKwkJCQkJfQ0KKwkJCQl9DQorCQkJ fQ0KKwkJfQ0KKw0KIAkJaWYgKHZmbGFnKSB7DQogCQkgICAgcHJpbnRmKCJs b2FkICUzZCUlLCBjdXJyZW50IGZyZXEgJTRkIE1IeiAoJTJkKSwgd2FudGVk IGZyZXEgJTRkIE1IelxuIiwNCiAJCQlsb2FkLCBjdXJmcmVxLCBpLCBmcmVx KTsNCkluZGV4OiB1c3Iuc2Jpbi9wb3dlcmQvcG93ZXJkLjgNCj09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT0NCi0tLSB1c3Iuc2Jpbi9wb3dlcmQvcG93ZXJkLjgJ KHJldmlzaW9uIDI1MjcwMSkNCisrKyB1c3Iuc2Jpbi9wb3dlcmQvcG93ZXJk LjgJKHdvcmtpbmcgY29weSkNCkBAIC03NCw2ICs3NCwxMyBAQA0KIHdpbGwg bWFpbnRhaW4gZnVsbCBmcmVxdWVuY3kgZm9yIGxvbmdlci4NCiBNYXkgYmUg YWJicmV2aWF0ZWQgYXMNCiAuQXIgaGFkcCAuDQorLkl0IEFyIGh5cGVyDQor SW1tZWRpYXRlbHkgZHJvcCB0byB0aGUgbG93ZXN0IGZyZXF1ZW5jeSB3aGVu IHRoZSBzeXN0ZW0gYXBwZWFycyB0byBiZQ0KK2lkbGUuDQorV2hlbiB0aGVy ZSBpcyBhbnkgbG9hZCBvbiB0aGUgc3lzdGVtLCBpbW1lZGlhdGVseSBqdW1w IHRvIHRoZSBoaWdoZXN0DQorZnJlcXVlbmN5Lg0KK01heSBiZSBhYmJyZXZp YXRlZCBhcw0KKy5BciBoeXBlIC4NCiAuRWwNCiAuUHANCiBUaGUgZGVmYXVs dCBtb2RlIGlzDQo= --3512871622-242739370-1372990333=:10280-- From owner-freebsd-acpi@FreeBSD.ORG Fri Jul 5 05:05:36 2013 Return-Path: Delivered-To: acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 12606371; Fri, 5 Jul 2013 05:05:36 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: from mail-oa0-x22b.google.com (mail-oa0-x22b.google.com [IPv6:2607:f8b0:4003:c02::22b]) by mx1.freebsd.org (Postfix) with ESMTP id C975210BE; Fri, 5 Jul 2013 05:05:35 +0000 (UTC) Received: by mail-oa0-f43.google.com with SMTP id i7so2807258oag.2 for ; Thu, 04 Jul 2013 22:05:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=Oiv4KGBAPIs/wCectPl9FDlel/a3VZc2ZUOwtyW9OSA=; b=OU5bnuTJC0lNyVuvPO602n7kf38xYwrdmb1QX1CqkSzImJmhaCZQhRWtkQGKb7aI+u JkGRaf3hFFJpZcUlZfuRDo58iyIiTqCK6lvZFDi5VDahsHogZ1pPduTUg+vxwKAILRZd CXNSVsaWZ1NabNsHT6D5FO6GaCydY2bMVinmX6UN5SiESrgLSCYc5ojfSd5baEKWna/o aav2KA+oobgsP2L2tLDAqPLBIIruRLepbgL1ShD7tCYIVGXn+DvRfZDR/iuA2jV1UO33 YzfqUr5kCzYDbkA9Ec0Hsbcxwr/9SBSjboUupXh9lfZJAFMqgHHLrgu+F4Pnp8dkqf2T NKRQ== MIME-Version: 1.0 X-Received: by 10.182.88.202 with SMTP id bi10mr9164521obb.91.1373000735403; Thu, 04 Jul 2013 22:05:35 -0700 (PDT) Sender: kob6558@gmail.com Received: by 10.76.112.212 with HTTP; Thu, 4 Jul 2013 22:05:35 -0700 (PDT) In-Reply-To: References: Date: Thu, 4 Jul 2013 22:05:35 -0700 X-Google-Sender-Auth: QV39Hd9l__BBjF0UcBBkfRMRTq4 Message-ID: Subject: Re: Hyper mode for powerd From: Kevin Oberman To: Warren Block Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: "freebsd-acpi@freebsd.org" , wblock@freebsd.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jul 2013 05:05:36 -0000 On Thu, Jul 4, 2013 at 7:12 PM, Warren Block wrote: > Attached is a proposed patch for -head that adds a "hyper" mode to powerd. > Instead of slewing like the adaptive modes, this mode drops all the way to > the lowest frequency when the system is idle, and jumps all the way to the > highest frequency when there is any load. > > Subjectively, it seems more responsive for desktop use than hiadaptive > mode. That's hard to benchmark. Power usage is another question. This > mode might use less power than the adaptive modes, but that's also > difficult to benchmark. > > Comments welcome. > > I have not looked at the patch yet, but it should really only use EST and not TC or throttling as many systems, when throttled and put into deep sleep modes (C3 or lower) will hang. Studies have shown (sorry, but since I retired I have lost the papers on the subject) that best power efficiency is when the system is operated at minimum performance when idle and maximum when not, so this is probably a good idea for most any non-mobile system and most mobile system applications. There are cases when you may be willing to pay a response price to keep the battery alive a little longer when performing ongoing activities that don't need large amounts of CPU like listening to music. As I have often pointed out, TCC and throttling were never intended for power management and I strongly recommend that they be disabled. OTOH, deep sleep states are huge winners and should be used to their maximum. EST is a smaller win, but can make a system seem sluggish, especially when added to TCC or throttling. -- R. Kevin Oberman, Network Engineer E-mail: rkoberman@gmail.com From owner-freebsd-acpi@FreeBSD.ORG Sat Jul 6 17:22:25 2013 Return-Path: Delivered-To: acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 9E7DC719; Sat, 6 Jul 2013 17:22:25 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [115.70.110.159]) by mx1.freebsd.org (Postfix) with ESMTP id 0FAD11D9A; Sat, 6 Jul 2013 17:22:24 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id r66HMM9q038361; Sun, 7 Jul 2013 03:22:22 +1000 (EST) (envelope-from smithi@nimnet.asn.au) Date: Sun, 7 Jul 2013 03:22:22 +1000 (EST) From: Ian Smith To: Warren Block Subject: Re: Hyper mode for powerd In-Reply-To: Message-ID: <20130707003651.Y26496@sola.nimnet.asn.au> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: acpi@freebsd.org, Kevin Oberman , wblock@freebsd.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Jul 2013 17:22:25 -0000 On Thu, 4 Jul 2013 30:12:12 -0600, Warren Block wrote: > Attached is a proposed patch for -head that adds a "hyper" mode to powerd. > Instead of slewing like the adaptive modes, this mode drops all the way to > the lowest frequency when the system is idle, and jumps all the way to the > highest frequency when there is any load. > > Subjectively, it seems more responsive for desktop use than hiadaptive mode. > That's hard to benchmark. Power usage is another question. This mode might > use less power than the adaptive modes, but that's also difficult to > benchmark. > > Comments welcome. I'll get to what Kevin talks about later, but want to address this in the context of how most modernish systems will run without deliberate tuning, that is with both absolute (eg est, powernow, acpi_perf) and relative (eg p4tcc, acpi_throttle) freq drivers enabled as shipped, see cpufreq(4) - though it may be somewhat out of date these days. Kevin is on the money, I believe, about the relative drivers; they add freqs of 7/8 down to 1/8 in 12.5% steps of a base absolute frequency, but offer little or no power savings over the base freq, keep the same CPU voltage and frequency, merely dropping between 1 and 7 out of every 8 cycles (to put it simply), by design to control excessive temperature. cpufreq merely treats these extra frequencies as equivalent in value to the primary, absolute levels, perhaps two to half a dozen from est / powernow, which shift both voltage and frequency, and there's nothing powerd can do to control - or even distinguish? - added relative freqs. We've often seen lately freq_levels ranging from say 2400 down to 75MHz, a range of 32:1, using the absolute levels plus all possible rates in between from the relative drivers. It's far from an exact science, most often I/O or network speed will be big factors, but it's perhaps fair to speculate that a process keeping a CPU (more likely CPUs) at 75MHz let's say 50% busy / 50% idle, is going to be something like only 1/32 as busy cranked up to 2400MHz - maybe less than 2% busy. Looking at your patch, 'scuse trimming and tab loss, + if (load > cpu_running_mark / 4) { + freq = freqs[0]; + if (curfreq != freq) { + if (vflag) { [..] + } + idle = 0; + if (set_freq(freq) != 0) { [..] + } + } + } else { + freq = freqs[numfreqs - 1]; + if (curfreq != freq) { + if (vflag) { [..] + } + idle = 0; + if (set_freq(freq) != 0) { [..] + } + } + } So even if cpu_running_mark were 100% (-r100), anything busier than 25% of our example 75MHz would shift to maximum freq immediately, where the load will likely plummet to just a few percent, way less than the 25% (at -r100) needed to keep it at that freq; ie it will most likely hunt. You don't appear to be taking any notice of the -i idle percentage here; perhaps that would be a more useful shift-down criterion? Even so, with a full house of frequencies, I can't see this being easy to tune as is. Show "sysctl -a | egrep 'freq|cx'" and we'll have something to chew on? And your powerd_flags setting? Of course anyone having a large number of freqs down to very slow could mitigate that by setting debug.cpufreq.lowest (or powerd's -m switch) to something more sensible, perhaps 300MHz or so, but even then it might be wise to chose an absolute rather than relative rate. If you disable p4tcc and throttling, you'll see how many absolute levels your CPU runs, and you may find using only those with hadp mode satisfies your needs? No argument this stuff is difficult to benchmark, even without the near infinite variety of possible workload scenarios, and apart from mav@'s power measurements with various things tuned or disabled, I've seen very little in the way of real data over the years. cheers, Ian