From owner-freebsd-acpi@FreeBSD.ORG Sun Nov 2 01:26:20 2014
Return-Path: <owner-freebsd-acpi@FreeBSD.ORG>
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 <freebsd-acpi@freebsd.org>; 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 <freebsd-acpi@freebsd.org>; 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)" <notify@twitter.com>
To: freebsd-acpi@freebsd.org
Subject: maitri sent you an invitation
MIME-Version: 1.0
Feedback-ID: 0040162518f58f41d1f0:1a4b0c2a33e3b540c2f9f813ac6366b7f1:none:twitterESP
Message-ID: <BF.B8.37455.58385545@twitter.com>
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 <freebsd-acpi.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-acpi>,
<mailto:freebsd-acpi-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-acpi/>
List-Post: <mailto:freebsd-acpi@freebsd.org>
List-Help: <mailto:freebsd-acpi-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-acpi>,
<mailto:freebsd-acpi-request@freebsd.org?subject=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: <owner-freebsd-acpi@FreeBSD.ORG>
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 <freebsd-acpi@FreeBSD.org>; 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 <freebsd-acpi@FreeBSD.org>; 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 <freebsd-acpi@FreeBSD.org>; 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: <bug-194884-13733-T6mLK4Pufn@https.bugs.freebsd.org/bugzilla/>
In-Reply-To: <bug-194884-13733@https.bugs.freebsd.org/bugzilla/>
References: <bug-194884-13733@https.bugs.freebsd.org/bugzilla/>
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 <freebsd-acpi.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-acpi>,
<mailto:freebsd-acpi-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-acpi/>
List-Post: <mailto:freebsd-acpi@freebsd.org>
List-Help: <mailto:freebsd-acpi-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-acpi>,
<mailto:freebsd-acpi-request@freebsd.org?subject=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 <adrian@freebsd.org> 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: <owner-freebsd-acpi@FreeBSD.ORG>
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 <freebsd-acpi@FreeBSD.org>; 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 <freebsd-acpi@FreeBSD.org>; 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 <freebsd-acpi@FreeBSD.org>; 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: <bug-178253-13733-qhKNoZZCYW@https.bugs.freebsd.org/bugzilla/>
In-Reply-To: <bug-178253-13733@https.bugs.freebsd.org/bugzilla/>
References: <bug-178253-13733@https.bugs.freebsd.org/bugzilla/>
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 <freebsd-acpi.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-acpi>,
<mailto:freebsd-acpi-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-acpi/>
List-Post: <mailto:freebsd-acpi@freebsd.org>
List-Help: <mailto:freebsd-acpi-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-acpi>,
<mailto:freebsd-acpi-request@freebsd.org?subject=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 <op@freebsd.org> 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: <owner-freebsd-acpi@FreeBSD.ORG>
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 <freebsd-acpi@FreeBSD.org>; 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 <freebsd-acpi@FreeBSD.org>; 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 <freebsd-acpi@FreeBSD.org>; 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: <bug-173408-13733-jSB5ux94i5@https.bugs.freebsd.org/bugzilla/>
In-Reply-To: <bug-173408-13733@https.bugs.freebsd.org/bugzilla/>
References: <bug-173408-13733@https.bugs.freebsd.org/bugzilla/>
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 <freebsd-acpi.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-acpi>,
<mailto:freebsd-acpi-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-acpi/>
List-Post: <mailto:freebsd-acpi@freebsd.org>
List-Help: <mailto:freebsd-acpi-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-acpi>,
<mailto:freebsd-acpi-request@freebsd.org?subject=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 <op@freebsd.org> 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: <owner-freebsd-acpi@FreeBSD.ORG>
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 <freebsd-acpi@FreeBSD.org>; 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 <freebsd-acpi@FreeBSD.org>; 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 <freebsd-acpi@FreeBSD.org>; 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: <bug-162859-13733-I5q8GJEaDc@https.bugs.freebsd.org/bugzilla/>
In-Reply-To: <bug-162859-13733@https.bugs.freebsd.org/bugzilla/>
References: <bug-162859-13733@https.bugs.freebsd.org/bugzilla/>
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 <freebsd-acpi.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-acpi>,
<mailto:freebsd-acpi-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-acpi/>
List-Post: <mailto:freebsd-acpi@freebsd.org>
List-Help: <mailto:freebsd-acpi-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-acpi>,
<mailto:freebsd-acpi-request@freebsd.org?subject=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 <op@freebsd.org> 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: <owner-freebsd-acpi@FreeBSD.ORG>
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 <freebsd-acpi@FreeBSD.org>; 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 <freebsd-acpi@FreeBSD.org>; Sat, 8 Nov 2014 12:42:30 +0000 (UTC)
Received: by mail-wi0-f173.google.com with SMTP id n3so6787838wiv.12
for <freebsd-acpi@FreeBSD.org>; 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: <CAKJAkzvBiLXPgqviuU9rEX=FVtSh+ggRRDtD41P+0bp_QbXFBA@mail.gmail.com>
Subject: Fix issue with battery status update on HP Elitebook 8440p
From: Juris Kaminskis <juris.kaminskis@gmail.com>
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 <freebsd-acpi.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-acpi>,
<mailto:freebsd-acpi-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-acpi/>
List-Post: <mailto:freebsd-acpi@freebsd.org>
List-Help: <mailto:freebsd-acpi-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-acpi>,
<mailto:freebsd-acpi-request@freebsd.org?subject=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: <HPQOEM SLIC-MPC> on motherboard
acpi0: Power Button (fixed)
cpu0: <ACPI CPU> on acpi0
cpu1: <ACPI CPU> on acpi0
cpu2: <ACPI CPU> on acpi0
cpu3: <ACPI CPU> on acpi0
hpet0: <High Precision Event Timer> iomem 0xfed00000-0xfed003ff on acpi0
atrtc0: <AT realtime clock> port 0x70-0x77 irq 8 on acpi0
attimer0: <AT timer> port 0x40-0x43,0x50-0x53 irq 0 on acpi0
acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0
acpi_ec0: <Embedded Controller: GPE 0x16> port 0x62,0x66 on acpi0
pcib0: <ACPI Host-PCI bridge> port 0xcf8-0xcff on acpi0
acpi_wmi0: <ACPI-WMI mapping> on acpi0
acpi_hp0: <HP ACPI-WMI Mapping> on acpi_wmi0
acpi_hp0: WMI device does not provide the HP BIOS GUID
device_attach: acpi_hp0 attach returned 22
pcib5: <ACPI Host-PCI bridge> on acpi0
battery0: <ACPI Control Method Battery> on acpi0
battery1: <ACPI Control Method Battery> on acpi0
acpi_acad0: <AC Adapter> on acpi0
acpi_button0: <Sleep Button> on acpi0
acpi_lid0: <Control Method Lid Switch> on acpi0
acpi_wmi1: <ACPI-WMI mapping> on acpi0
acpi_hp1: <HP ACPI-WMI Mapping> on acpi_wmi1
acpi_hp1: HP event GUID detected, installing event handler
acpi_hp1: HP CMI GUID detected
acpi_tz0: <Thermal Zone> on acpi0
acpi_tz1: <Thermal Zone> on acpi0
acpi_tz2: <Thermal Zone> on acpi0
acpi_tz3: <Thermal Zone> on acpi0
acpi_tz4: <Thermal Zone> on acpi0
acpi_tz5: <Thermal Zone> on acpi0
acpi_tz6: <Thermal Zone> on acpi0
acpi_tz7: <Thermal Zone> on acpi0
acpi_tz8: <Thermal Zone> on acpi0
acpi_tz9: <Thermal Zone> on acpi0
atkbdc0: <Keyboard controller (i8042)> port 0x60,0x64 irq 1 on acpi0
ppc1: <Parallel port> 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: <owner-freebsd-acpi@FreeBSD.ORG>
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 <smithi@nimnet.asn.au>
To: Adrian Chadd <adrian@freebsd.org>
Subject: Re: [Bug 194884] [acpi] Asus UX31E USB hangs during suspend, due to
putting the USB controllers into D3 state
In-Reply-To: <bug-194884-13733-T6mLK4Pufn@https.bugs.freebsd.org/bugzilla/>
Message-ID: <20141109034218.X31139@sola.nimnet.asn.au>
References: <bug-194884-13733@https.bugs.freebsd.org/bugzilla/>
<bug-194884-13733-T6mLK4Pufn@https.bugs.freebsd.org/bugzilla/>
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 <freebsd-acpi.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-acpi>,
<mailto:freebsd-acpi-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-acpi/>
List-Post: <mailto:freebsd-acpi@freebsd.org>
List-Help: <mailto:freebsd-acpi-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-acpi>,
<mailto:freebsd-acpi-request@freebsd.org?subject=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 <adrian@freebsd.org> 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: <owner-freebsd-acpi@FreeBSD.ORG>
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 <freebsd-acpi@freebsd.org>; 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 <freebsd-acpi@freebsd.org>; Sat, 8 Nov 2014 17:47:32 +0000 (UTC)
Received: by mail-wi0-f181.google.com with SMTP id n3so7158806wiv.8
for <freebsd-acpi@freebsd.org>; 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: <bug-194884-13733@https.bugs.freebsd.org/bugzilla/>
<bug-194884-13733-T6mLK4Pufn@https.bugs.freebsd.org/bugzilla/>
<20141109034218.X31139@sola.nimnet.asn.au>
Date: Sat, 8 Nov 2014 09:47:29 -0800
X-Google-Sender-Auth: o5Pn-vEFmq6dOoUtF2xY0IQuszc
Message-ID: <CAJ-VmonuO6wL84kPXjApRR6pz2v3s1kfUogcq9n3cX_ztbdjgQ@mail.gmail.com>
Subject: Re: [Bug 194884] [acpi] Asus UX31E USB hangs during suspend, due to
putting the USB controllers into D3 state
From: Adrian Chadd <adrian@freebsd.org>
To: Ian Smith <smithi@nimnet.asn.au>
Content-Type: text/plain; charset=UTF-8
Cc: "freebsd-acpi@freebsd.org" <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 <freebsd-acpi.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-acpi>,
<mailto:freebsd-acpi-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-acpi/>
List-Post: <mailto:freebsd-acpi@freebsd.org>
List-Help: <mailto:freebsd-acpi-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-acpi>,
<mailto:freebsd-acpi-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sat, 08 Nov 2014 17:47:32 -0000
Hi,
On 8 November 2014 09:25, Ian Smith <smithi@nimnet.asn.au> 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 <adrian@freebsd.org> 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