From owner-freebsd-acpi@FreeBSD.ORG Sun Nov 2 01:26:20 2014 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1F773DA for ; Sun, 2 Nov 2014 01:26:20 +0000 (UTC) Received: from spruce-goose-ao.twitter.com (spruce-goose-ao.twitter.com [199.59.150.84]) (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 F06C1FD5 for ; Sun, 2 Nov 2014 01:26:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=twitter.com; s=dkim-201406; t=1414890373; bh=qZ/o6cuVMruynjd/6ep/WEeXj+NWeDvvqzxmM3f8JGI=; h=Date:From:To:Subject:MIME-Version:Content-Type:List-Unsubscribe: Feedback-ID:Message-ID; b=dn7pv6+cJGucvuE3JjDYwjWGOwifg5RmolZ7V/1GHcT3ABqe9pBbA19mDPiWLrTRo 9FU48dN8eIWGNCLg6iOPZ0EOPchgVEq9vQHfuAZxCuNOvDzQC98WdXNre04sqFBFJE OJItkp+w1c5PBCiKz639r2l1YHCBVBcU90Dz+E+wf13/gKJQdjMIjuan+0yTsnVerg WqZ+A1OxPrPYmlKIvz7/SQ8els30GL9/OoeWKn3h3QUeIzOXdiuzST95/UZNWX/hrR aWSDgLqFfy+PB/oxXnjN3SpqwSP6VBRqWfCet763SohQAgUxJKVqA+DKvq2TavjyAA YRJgXuf+a6W1w== X-MSFBL: ZnJlZWJzZC1hY3BpQGZyZWVic2Qub3JnQHNtZjEtYmZuLTI0LXNyMS1FdmVyeXRo aW5nLjE4NEBFdmVyeXRoaW5nQGZyZWVic2QtYWNwaVxAZnJlZWJzZC5vcmdcQHVz YiMjMFxAMjQ0XEAwXEAwXEA4NzMwYWY5NzkyYTMwMjIzMTNhOWQwYWE1NDI4ZGZj ZjdkODViMjVk Date: Sun, 02 Nov 2014 01:06:13 +0000 From: "maitri (via Twitter)" To: freebsd-acpi@freebsd.org Subject: maitri sent you an invitation MIME-Version: 1.0 Feedback-ID: 0040162518f58f41d1f0:1a4b0c2a33e3b540c2f9f813ac6366b7f1:none:twitterESP Message-ID: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Nov 2014 01:26:20 -0000 maitri sent you an invitation Twitter helps you stay connected with what's happening right now and with the people and organizations you care about. Accept invitation https://twitter.com/i/1e55862a-ac0a-4c00-8576-59d0b66fdaf8 -- You can unsubscribe from receiving email notifications from Twitter at anytime. For general inquiries, please visit us at Twitter Support. Unsubscribe: https://twitter.com/i/o?t=1&cn=aW52aXRlX3NlbGZfc2VydmU%3D&iid=a5570ddfba8b41289316c9182162f6c0&uid=0&c=ZNV%2BN6G7N7iJhJ3n2T78ai5wuarSZRCecllQqPvg1K0%3D&nid=244+26 Need help? https://support.twitter.com From owner-freebsd-acpi@FreeBSD.ORG Fri Nov 7 19:08:58 2014 Return-Path: Delivered-To: freebsd-acpi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BAD0536B for ; Fri, 7 Nov 2014 19:08:58 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A284BE2B for ; Fri, 7 Nov 2014 19:08:58 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id sA7J8wro071442 for ; Fri, 7 Nov 2014 19:08:58 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-acpi@FreeBSD.org Subject: [Bug 194884] [acpi] Asus UX31E USB hangs during suspend, due to putting the USB controllers into D3 state Date: Fri, 07 Nov 2014 19:08:58 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.0-CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: adrian@freebsd.org X-Bugzilla-Status: Needs Triage X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-acpi@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: assigned_to Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Nov 2014 19:08:58 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194884 Adrian Chadd changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-bugs@FreeBSD.org |freebsd-acpi@FreeBSD.org -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-acpi@FreeBSD.ORG Fri Nov 7 21:27:56 2014 Return-Path: Delivered-To: freebsd-acpi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 745B2CE4 for ; Fri, 7 Nov 2014 21:27:56 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5AD6DE50 for ; Fri, 7 Nov 2014 21:27:56 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id sA7LRuPB090274 for ; Fri, 7 Nov 2014 21:27:56 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-acpi@FreeBSD.org Subject: [Bug 178253] Re: kern/162859: [acpi] ACPI battery/acline monitoring partialy working (switching) Date: Fri, 07 Nov 2014 21:27:55 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 1.0-CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: op@freebsd.org X-Bugzilla-Status: Issue Resolved X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-acpi@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: see_also Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Nov 2014 21:27:56 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=178253 Oliver Pinter changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.freebsd.org/bu | |gzilla/show_bug.cgi?id=1948 | |89 -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-acpi@FreeBSD.ORG Fri Nov 7 21:28:34 2014 Return-Path: Delivered-To: freebsd-acpi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DDAB2D6D for ; Fri, 7 Nov 2014 21:28:34 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C4A99E5E for ; Fri, 7 Nov 2014 21:28:34 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id sA7LSYt2090490 for ; Fri, 7 Nov 2014 21:28:34 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-acpi@FreeBSD.org Subject: [Bug 173408] [acpi] [regression] ACPI Regression: battery does not update often Date: Fri, 07 Nov 2014 21:28:34 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: unspecified X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: op@freebsd.org X-Bugzilla-Status: In Discussion X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-acpi@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: see_also Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Nov 2014 21:28:35 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=173408 Oliver Pinter changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.freebsd.org/bu | |gzilla/show_bug.cgi?id=1948 | |89 -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-acpi@FreeBSD.ORG Fri Nov 7 21:29:05 2014 Return-Path: Delivered-To: freebsd-acpi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E507EDF7 for ; Fri, 7 Nov 2014 21:29:05 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id CC715E75 for ; Fri, 7 Nov 2014 21:29:05 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id sA7LT5AG090727 for ; Fri, 7 Nov 2014 21:29:05 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-acpi@FreeBSD.org Subject: [Bug 162859] [acpi] ACPI battery/acline monitoring partialy working (switching) Date: Fri, 07 Nov 2014 21:29:05 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 9.0-PRERELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: op@freebsd.org X-Bugzilla-Status: In Discussion X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-acpi@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: see_also Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Nov 2014 21:29:06 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=162859 Oliver Pinter changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.freebsd.org/bu | |gzilla/show_bug.cgi?id=1948 | |89 -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-acpi@FreeBSD.ORG Sat Nov 8 12:42:30 2014 Return-Path: Delivered-To: freebsd-acpi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A93E8FAD for ; Sat, 8 Nov 2014 12:42:30 +0000 (UTC) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3ED13C0D for ; Sat, 8 Nov 2014 12:42:30 +0000 (UTC) Received: by mail-wi0-f173.google.com with SMTP id n3so6787838wiv.12 for ; Sat, 08 Nov 2014 04:42:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=U+/X29u4cPig6+ioxUMtv8bI5Rl40e7YVxBhqRPtH6M=; b=EyhXybvt/AB/gu7v9fv/+/TxYDy7IFvRNEsmpp7J1uhAyXsm2T43f4Ut4akKkgh0vJ yuQIRgrufg6dvZLfOyCN8KYPR/25hqdtJNzUk6S5z7/8PFCDJLVXX4oBS0aJsPz7f7kv 7MpNTkxOXidPmiXf+lx+20uDSB3KCV6MVU9o8vY9WcwClHLJN3oSy5DvgEUUGMqUO49Y sCA4J5iBuFv+Vh6h/wwiGf08YrP8bS4RIJ7FAb4EGSGA57SxD9Cs9dhUMGlTeIoLDmFs AdwJ8Qr+z+SmpoVJim2pxL2SF77GLZrpTsTVDaTvw9lkyuAO7laNQ+P0BwQYxisPHTCe pdwA== MIME-Version: 1.0 X-Received: by 10.181.13.208 with SMTP id fa16mr13578554wid.61.1415450548132; Sat, 08 Nov 2014 04:42:28 -0800 (PST) Received: by 10.194.221.132 with HTTP; Sat, 8 Nov 2014 04:42:28 -0800 (PST) Date: Sat, 8 Nov 2014 14:42:28 +0200 Message-ID: Subject: Fix issue with battery status update on HP Elitebook 8440p From: Juris Kaminskis To: freebsd-acpi@FreeBSD.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Nov 2014 12:42:30 -0000 Hi, My battery status updates only after reboot, is there a way I can get the fix for this? My system is 10.0-RELEASE-p11 with acpi_hp and acpi_wmi loaded and following dmesg: dmesg |grep acpi acpi0: on motherboard acpi0: Power Button (fixed) cpu0: on acpi0 cpu1: on acpi0 cpu2: on acpi0 cpu3: on acpi0 hpet0: iomem 0xfed00000-0xfed003ff on acpi0 atrtc0: port 0x70-0x77 irq 8 on acpi0 attimer0: port 0x40-0x43,0x50-0x53 irq 0 on acpi0 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 acpi_ec0: port 0x62,0x66 on acpi0 pcib0: port 0xcf8-0xcff on acpi0 acpi_wmi0: on acpi0 acpi_hp0: on acpi_wmi0 acpi_hp0: WMI device does not provide the HP BIOS GUID device_attach: acpi_hp0 attach returned 22 pcib5: on acpi0 battery0: on acpi0 battery1: on acpi0 acpi_acad0: on acpi0 acpi_button0: on acpi0 acpi_lid0: on acpi0 acpi_wmi1: on acpi0 acpi_hp1: on acpi_wmi1 acpi_hp1: HP event GUID detected, installing event handler acpi_hp1: HP CMI GUID detected acpi_tz0: on acpi0 acpi_tz1: on acpi0 acpi_tz2: on acpi0 acpi_tz3: on acpi0 acpi_tz4: on acpi0 acpi_tz5: on acpi0 acpi_tz6: on acpi0 acpi_tz7: on acpi0 acpi_tz8: on acpi0 acpi_tz9: on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 ppc1: port 0x378-0x37f,0x778-0x77a irq 5 on acpi0 and this is what I get from acpiconf -i0 Design capacity: 1551 mAh Last full capacity: 1551 mAh Technology: secondary (rechargeable) Design voltage: 10800 mV Capacity (warn): 350 mAh Capacity (low): 100 mAh Low/warn granularity: 100 mAh Warn/full granularity: 100 mAh Model number: Primary Serial number: 16138 2011/04/16 Type: LIon OEM info: Hewlett-Packard State: charging Remaining capacity: 0% Remaining time: unknown Present rate: 2334 mA (29378 mW) Present voltage: 12587 mV same problem described here: https://forums.freebsd.org/threads/acpiconf-i0-doesnt-update-hp-laptop-battery.30485/ My BIOS is to the latest update from HP. Is there a way I can contribute? thanks Juris From owner-freebsd-acpi@FreeBSD.ORG Sat Nov 8 17:25:16 2014 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id ABF1D682; Sat, 8 Nov 2014 17:25:16 +0000 (UTC) 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 1F56F7A4; Sat, 8 Nov 2014 17:25:15 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id sA8HP5li046557; Sun, 9 Nov 2014 04:25:05 +1100 (EST) (envelope-from smithi@nimnet.asn.au) Date: Sun, 9 Nov 2014 04:25:05 +1100 (EST) From: Ian Smith To: Adrian Chadd Subject: Re: [Bug 194884] [acpi] Asus UX31E USB hangs during suspend, due to putting the USB controllers into D3 state In-Reply-To: Message-ID: <20141109034218.X31139@sola.nimnet.asn.au> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: freebsd-acpi@freebsd.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Nov 2014 17:25:16 -0000 On Fri, 7 Nov 2014 19:08:58 +0000, bugzilla-noreply@freebsd.org wrote: > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194884 > > Adrian Chadd changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > Assignee|freebsd-bugs@FreeBSD.org |freebsd-acpi@FreeBSD.org Not loving bugzilla all that much. I'm going to reply here, after reformatting from cut'n'paste; do what thou wilt if anything's useful. > The laptop won't suspend with the USB drivers (ehci, xhci) loaded. Won't suspend, or won't resume? > Suspend bounce works fine - everything gets powered down fine, then > comes back up. > > Unloading the USB drivers fixes the problem, but that's hiding the > underlying causes - the trick is the transition of the USB ports into > D3. > The ACPI BIOS has this: > > Device (EHC1) > { > Name (_ADR, 0x001D0000) // _ADR: Address > OperationRegion (PWKE, PCI_Config, 0x62, 0x04) > Field (PWKE, DWordAcc, NoLock, Preserve) > { > , 1, > PWUC, 8 > } > > Method (_PSW, 1, NotSerialized) // _PSW: Power State Wake > { > If (Arg0) > { > Store (Ones, PWUC) /* \_SB_.PCI0.EHC1.PWUC */ > } > Else > { > Store (0x00, PWUC) /* \_SB_.PCI0.EHC1.PWUC */ > } > } > > Method (_S3D, 0, NotSerialized) // _S3D: S3 Device State > { > Return (0x02) > } > > Method (_S4D, 0, NotSerialized) // _S4D: S4 Device State > { > Return (0x02) > } > > .. so, we should be trying to put it into D2, not D3. I can't figure this. Methods _S3D and _S4D aren't apparently referenced or called anywhere else?, and there's nothing similar (I could spot) for EHC2. Are you assuming 0x02 here is the requested power state? How? If so, even if it wanted to leave some? power on during suspend, what good would that do in S4 (hibernate/STDisk) when the power is turned right off? - not that we support that, but W*s and maybe Linux do .. > But then: > > ehci0 pnpinfo vendor=0x8086 device=0x1c26 subvendor=0x1043 > subdevice=0x1427 class=0x0c0320 at slot=29 function=0 > handle=\_SB_.PCI0.EHC1 > > ehci0@pci0:0:29:0: class=0x0c0320 card=0x14271043 chip=0x1c268086 > rev=0x05 hdr=0x00 > vendor = 'Intel Corporation' > device = '6 Series/C200 Series Chipset Family USB Enhanced Host Controller' > class = serial bus > subclass = USB > cap 01[50] = powerspec 2 supports D0 D3 current D0 > cap 0a[58] = EHCI Debug Port at offset 0xa0 in map 0x14 > cap 13[98] = PCI Advanced Features: FLR TP > > .. we shouldn't be putting it into D2, because the device doesn't > support it. Right. Or at least, so we detect .. > However, we are actually transitioning it into D3. I don't have a > bootverbose output here, but just assume we are. [..] > The full files can be found at > http://people.freebsd.org/~adrian/asus_zenbook/ Actually a verbose boot - without the extra debugging - or with, if it's properly interleaved with ordinary verbose stuff - might be handy, even if it won't survive a suspend/resume, when it could be _really_ handy. > If I leave the driver loaded but I disable the suspend-to-d3 option, > things suspend/resume fine. > > If I set the unconfigured-devices-get-d3 option and unload the usb > modules, then the ehci controller ends up at d3 when I unload it. > Then if I suspend, the laptop hangs. Sorry, where are those options set? Is that what they're called? Probably not helpful, but have you considered changing the ASL? The only reason I can think of for leaving anything in D2 state is if that provides external power for phone charging and the like? My X200 has a BIOS option for that; pretty sure I turned it off. Does yours? cheers, Ian From owner-freebsd-acpi@FreeBSD.ORG Sat Nov 8 17:47:32 2014 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9C54691F for ; Sat, 8 Nov 2014 17:47:32 +0000 (UTC) Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 27CFB956 for ; Sat, 8 Nov 2014 17:47:32 +0000 (UTC) Received: by mail-wi0-f181.google.com with SMTP id n3so7158806wiv.8 for ; Sat, 08 Nov 2014 09:47:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=0lLoWNdAcqrEkzOCDgFLyDsJ2SqK8sk5mLTo00CY0Rw=; b=sJt9JJr5W6ehLCwqq1AdrpF/kmf+Yx2mg4jxI5fDRA1742BTYQIvRpMGJYtUhQUWMy 49AlKshW1UVA3ND7E0MDcHJdeCY1Oig/jO1RTnR2eAjVrk8/syYQbvdhNsv9nHjRUxS2 CEG4ancISW0RzYOKQifaAapKChwzUigBxy7Cr98q7GHjCFo6vSorrsttkxnk7muUPZ6r lX40eWjZzA/3tCbzFNfq5i5RWDT7mUt+TfX2wOVlc0cdOZ5z2IjovpbIrqzSklw5lnRI emlK1/HDn/WPdKwmvn99vuNr8Cg2mDjxja34Rl/reH9hDdgjgDvHQCU6QjQo52e8rWRe CMCQ== MIME-Version: 1.0 X-Received: by 10.180.92.169 with SMTP id cn9mr15878766wib.26.1415468849566; Sat, 08 Nov 2014 09:47:29 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.216.106.136 with HTTP; Sat, 8 Nov 2014 09:47:29 -0800 (PST) In-Reply-To: <20141109034218.X31139@sola.nimnet.asn.au> References: <20141109034218.X31139@sola.nimnet.asn.au> Date: Sat, 8 Nov 2014 09:47:29 -0800 X-Google-Sender-Auth: o5Pn-vEFmq6dOoUtF2xY0IQuszc Message-ID: Subject: Re: [Bug 194884] [acpi] Asus UX31E USB hangs during suspend, due to putting the USB controllers into D3 state From: Adrian Chadd To: Ian Smith Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-acpi@freebsd.org" X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Nov 2014 17:47:32 -0000 Hi, On 8 November 2014 09:25, Ian Smith wrote: > On Fri, 7 Nov 2014 19:08:58 +0000, bugzilla-noreply@freebsd.org wrote: > > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194884 > > > > Adrian Chadd changed: > > > > What |Removed |Added > > ---------------------------------------------------------------------------- > > Assignee|freebsd-bugs@FreeBSD.org |freebsd-acpi@FreeBSD.org > > Not loving bugzilla all that much. I'm going to reply here, after > reformatting from cut'n'paste; do what thou wilt if anything's useful. :( > > The laptop won't suspend with the USB drivers (ehci, xhci) loaded. > > Won't suspend, or won't resume? Won't suspend - it hangs before it powers everything off. > > Suspend bounce works fine - everything gets powered down fine, then > > comes back up. > > > > Unloading the USB drivers fixes the problem, but that's hiding the > > underlying causes - the trick is the transition of the USB ports into > > D3. > > > The ACPI BIOS has this: > > > > Device (EHC1) > > { > > Name (_ADR, 0x001D0000) // _ADR: Address > > OperationRegion (PWKE, PCI_Config, 0x62, 0x04) > > Field (PWKE, DWordAcc, NoLock, Preserve) > > { > > , 1, > > PWUC, 8 > > } > > > > Method (_PSW, 1, NotSerialized) // _PSW: Power State Wake > > { > > If (Arg0) > > { > > Store (Ones, PWUC) /* \_SB_.PCI0.EHC1.PWUC */ > > } > > Else > > { > > Store (0x00, PWUC) /* \_SB_.PCI0.EHC1.PWUC */ > > } > > } > > > > Method (_S3D, 0, NotSerialized) // _S3D: S3 Device State > > { > > Return (0x02) > > } > > > > Method (_S4D, 0, NotSerialized) // _S4D: S4 Device State > > { > > Return (0x02) > > } > > > > .. so, we should be trying to put it into D2, not D3. > > I can't figure this. Methods _S3D and _S4D aren't apparently referenced > or called anywhere else?, and there's nothing similar (I could spot) for > EHC2. Are you assuming 0x02 here is the requested power state? How? It's apparently in the spec and we do check for it - grep for _S%dD in sys/dev/acpica/ . > If so, even if it wanted to leave some? power on during suspend, what > good would that do in S4 (hibernate/STDisk) when the power is turned > right off? - not that we support that, but W*s and maybe Linux do .. I think it likely needs to be powered on during the transition to S3/S4, but then for S4 you can just yank the power. I doubt the USB controllers need to be on if the rest of th machine is powered off. > > But then: > > > > ehci0 pnpinfo vendor=0x8086 device=0x1c26 subvendor=0x1043 > > subdevice=0x1427 class=0x0c0320 at slot=29 function=0 > > handle=\_SB_.PCI0.EHC1 > > > > ehci0@pci0:0:29:0: class=0x0c0320 card=0x14271043 chip=0x1c268086 > > rev=0x05 hdr=0x00 > > vendor = 'Intel Corporation' > > device = '6 Series/C200 Series Chipset Family USB Enhanced Host Controller' > > class = serial bus > > subclass = USB > > cap 01[50] = powerspec 2 supports D0 D3 current D0 > > cap 0a[58] = EHCI Debug Port at offset 0xa0 in map 0x14 > > cap 13[98] = PCI Advanced Features: FLR TP > > > > .. we shouldn't be putting it into D2, because the device doesn't > > support it. > > Right. Or at least, so we detect .. Right, but we don't. If you check the .txt files, we are actually probing the bus itself to find the _SxD node, when apparently this ACPI table has it in the device. ie: acpi_device_pwr_for_sleep: \134_SB_.PCI0: dstate=3 acpi_device_pwr_for_sleep: \134_SB_.PCI0: now dstate=3 acpi_device_pwr_for_sleep: \134_SB_.PCI0: dstate=3 acpi_device_pwr_for_sleep: \134_SB_.PCI0: now dstate=3 acpi_device_pwr_for_sleep: \134_SB_.PCI0: dstate=3 acpi_device_pwr_for_sleep: \134_SB_.PCI0: now dstate=3 acpi_device_pwr_for_sleep: \134_SB_.PCI0.RP01: dstate=3 acpi_device_pwr_for_sleep: \134_SB_.PCI0.RP01: now dstate=3 acpi_device_pwr_for_sleep: \134_SB_.PCI0: dstate=3 acpi_device_pwr_for_sleep: \134_SB_.PCI0: now dstate=3 ath_hal_reg_write: reg=0x000000a0, val=0x00000000, pm=1 ath_hal_reg_write: reg=0x000000ac, val=0x00000000, pm=1 .. it's actually checking PCI0 all the time, including when it's trying to power down the atheros NIC. That's what's confusing about all of this. > > However, we are actually transitioning it into D3. I don't have a > > bootverbose output here, but just assume we are. > [..] > > The full files can be found at > > http://people.freebsd.org/~adrian/asus_zenbook/ > > Actually a verbose boot - without the extra debugging - or with, if it's > properly interleaved with ordinary verbose stuff - might be handy, even > if it won't survive a suspend/resume, when it could be _really_ handy. The verbose boot + suspend just says "going to D3" for all the devices. :-) > > If I leave the driver loaded but I disable the suspend-to-d3 option, > > things suspend/resume fine. > > > > If I set the unconfigured-devices-get-d3 option and unload the usb > > modules, then the ehci controller ends up at d3 when I unload it. > > Then if I suspend, the laptop hangs. > > Sorry, where are those options set? Is that what they're called? hw.pci.do_power_nodriver: 0 hw.pci.do_power_resume: 1 hw.pci.do_power_suspend: 1 > Probably not helpful, but have you considered changing the ASL? > > The only reason I can think of for leaving anything in D2 state is if > that provides external power for phone charging and the like? My X200 > has a BIOS option for that; pretty sure I turned it off. Does yours? Sure, but please keep in mind that it may also keep it in D2 state so some external device can wake the laptop up upon some event. And even if you don't /want/ that, the BIOS ACPI / SMI code may be expecting the device to actually be active and reachable when the transition to S3/S4 occurs. We can't really control that. -adrian