From owner-freebsd-acpi@FreeBSD.ORG Mon Feb 24 11:06:44 2014 Return-Path: Delivered-To: freebsd-acpi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2D090A5E for ; Mon, 24 Feb 2014 11:06:44 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 001F01609 for ; Mon, 24 Feb 2014 11:06:43 +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 s1OB6h07027423 for ; Mon, 24 Feb 2014 11:06:43 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.8/8.14.8/Submit) id s1OB6h9W027420 for freebsd-acpi@FreeBSD.org; Mon, 24 Feb 2014 11:06:43 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 24 Feb 2014 11:06:43 GMT Message-Id: <201402241106.s1OB6h9W027420@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.17 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Feb 2014 11:06:44 -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/181665 acpi [acpi] System will not go into S3 state. o kern/180897 acpi [acpi] ACPI error with MB p8h67 v.1405 o kern/174766 acpi [acpi] Random acpi panic o kern/174504 acpi [ACPI] Suspend/resume broken on Lenovo x220 o kern/173408 acpi [acpi] [regression] ACPI Regression: battery does not 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/73823 acpi [request] acpi / power-on by timer support 28 problems total. From owner-freebsd-acpi@FreeBSD.ORG Mon Feb 24 17:13:22 2014 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4213A196 for ; Mon, 24 Feb 2014 17:13:22 +0000 (UTC) Received: from mail-ee0-x234.google.com (mail-ee0-x234.google.com [IPv6:2a00:1450:4013:c00::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C90951DFF for ; Mon, 24 Feb 2014 17:13:21 +0000 (UTC) Received: by mail-ee0-f52.google.com with SMTP id c41so2401395eek.11 for ; Mon, 24 Feb 2014 09:13:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:message-id:date :to:mime-version; bh=6ooc0g8seFPx3rTDgw4HTaXzWPEaazYjXjfWffUohIo=; b=oivyJEnSvMccq/UCJDVr3lbyjPjkrnfow9FKlstEfUT9ibizLI5tsWJjNgzOpFt162 NKjo9n5sQrmJDfx8vKQA6nvLOtgWS4mIozsnayMCWVz6g+OeM1kxIW0dIxmRzBEvDLqO LS7KTPKOsMYwF5XLfpJ9iIJEpmt9gpJ6TMgpdd7/tBibsH20pBtfwOc7mRChCsLHzJjG E8fDXDjtKesd35Axanq5a3wG4xf7JNLGUWJNru6jpYtsCDStK/ASqrxjEJmYiWBaI794 g9QhyL4b/KG15JKx+ZaK6KBCqtPm8F2GpUDvFG2dfXdGvIK4GRpIhzYKrvxIFgcZ4AXL fybQ== X-Received: by 10.15.26.8 with SMTP id m8mr25935052eeu.25.1393262000208; Mon, 24 Feb 2014 09:13:20 -0800 (PST) Received: from willis-imac.fritz.box (p5DE59E3E.dip0.t-ipconnect.de. [93.229.158.62]) by mx.google.com with ESMTPSA id m9sm65878258eeh.3.2014.02.24.09.13.18 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 24 Feb 2014 09:13:19 -0800 (PST) From: Willi Eggeling Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: Current state of "RTC wakeup" support Message-Id: Date: Mon, 24 Feb 2014 18:13:16 +0100 To: freebsd-acpi@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) X-Mailer: Apple Mail (2.1827) X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Feb 2014 17:13:22 -0000 Hi! According to the FreeBSD ACPI project page = (http://www.freebsd.org/projects/acpi/) RTC support is not realized yet. As the last update was in 2006 I just wanted to ask if there is any = change about RTC-triggered wakeup that has not been posted to the page. = Is there any?=20 All I need is to time system wakeup from S4/S5 on a HP ProLiant N40L.=20 Thanks and regards, Willi=20= From owner-freebsd-acpi@FreeBSD.ORG Tue Feb 25 08:00:37 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 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 85BBD558 for ; Tue, 25 Feb 2014 08:00:37 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 5917D186C; Tue, 25 Feb 2014 08:00:37 +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 s1P80bFD053444; Tue, 25 Feb 2014 08:00:37 GMT (envelope-from brueffer@freefall.freebsd.org) Received: (from brueffer@localhost) by freefall.freebsd.org (8.14.8/8.14.8/Submit) id s1P80bxX053443; Tue, 25 Feb 2014 09:00:37 +0100 (CET) (envelope-from brueffer) Date: Tue, 25 Feb 2014 09:00:37 +0100 (CET) Message-Id: <201402250800.s1P80bxX053443@freefall.freebsd.org> To: freebsd-acpi@FreeBSD.org, loox@e-shell.net, brueffer@FreeBSD.org, brueffer@FreeBSD.org From: brueffer@FreeBSD.org Subject: Re: bin/169779: [patch] powerd(8) doesn't honor the -n flag X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Feb 2014 08:00:37 -0000 Synopsis: [patch] powerd(8) doesn't honor the -n flag State-Changed-From-To: patched->closed State-Changed-By: brueffer State-Changed-When: Tue Feb 25 09:00:13 CET 2014 State-Changed-Why: Merge to stable branches done. http://www.freebsd.org/cgi/query-pr.cgi?pr=169779 From owner-freebsd-acpi@FreeBSD.ORG Tue Feb 25 08:39:46 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 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6D53425F for ; Tue, 25 Feb 2014 08:39:46 +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)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D89BD1C15 for ; Tue, 25 Feb 2014 08:39:45 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id s1P8daic030912; Tue, 25 Feb 2014 19:39:36 +1100 (EST) (envelope-from smithi@nimnet.asn.au) Date: Tue, 25 Feb 2014 19:39:36 +1100 (EST) From: Ian Smith To: Willi Eggeling Subject: Re: Current state of "RTC wakeup" support In-Reply-To: Message-ID: <20140225192128.S89549@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.17 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Feb 2014 08:39:46 -0000 On Mon, 24 Feb 2014 18:13:16 +0100, Willi Eggeling wrote: > Hi! > > According to the FreeBSD ACPI project page > (http://www.freebsd.org/projects/acpi/) RTC support is not realized > yet. As the last update was in 2006 I just wanted to ask if there is > any change about RTC-triggered wakeup that has not been posted to the > page. Is there any? > > All I need is to time system wakeup from S4/S5 on a HP ProLiant N40L. You're talking about http://www.freebsd.org/cgi/query-pr.cgi?pr=kern%2F73823&cat= which is now our oldest outstanding ACPI PR. I did some RTC programming in a past life - in Turbo Pascal no less - and this is not hard to do. I had a patch sort-of on the way when mav@ changed all the clocks and timers around, for 9.0 IIRC, and I got lost. Without delving too deeply into details, there's an alarm wake bit in the RTC that we gratuitously clear whenever we write to the RTC, both on initialisation and when updating CMOS time, also perhaps on init for other uses such as using the RTC interrupt as a low res timer or for profiling, maybe? ISTR that we mostly only needed to mask (ie not disturb) that wake interrupt bit once set and add a small userland utility to set, clear and enable/disable the wake timer bit and set the BCD time, the BIOS should do the rest. We don't support S4 on anything these days, AFAIK, but this could work both from S5 (power off) and S3 (suspend to RAM). cheers, Ian From owner-freebsd-acpi@FreeBSD.ORG Wed Feb 26 09:50:12 2014 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5204E21A for ; Wed, 26 Feb 2014 09:50:12 +0000 (UTC) Received: from dd16522.kasserver.com (dd16522.kasserver.com [85.13.137.124]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 0960F12A8 for ; Wed, 26 Feb 2014 09:50:11 +0000 (UTC) Received: from mx12.chaot.net (62.65.222.147.cable.starman.ee [62.65.222.147]) by dd16522.kasserver.com (Postfix) with ESMTPSA id 66CF1456086 for ; Wed, 26 Feb 2014 10:44:12 +0100 (CET) Received: from localhost (1003@localhost [local]); by mx12.chaot.net (OpenSMTPD) with ESMTPA id b1bd79f9; for ; Wed, 26 Feb 2014 11:44:11 +0200 (EET) Date: Wed, 26 Feb 2014 11:44:11 +0200 From: Johannes Meixner To: freebsd-acpi@freebsd.org Subject: hw.acpi.reset_video behavior when multiple VGA cards are prresent Message-ID: <20140226094411.GA9562@mx12.chaot.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ZGiS0Q5IWpPtfppv" Content-Disposition: inline User-Agent: Mutt/1.5.22 (2013-10-16) X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Feb 2014 09:50:12 -0000 --ZGiS0Q5IWpPtfppv Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, I've been trying to work out why my ASUS ZenBook can't work with S3 sleepst= ates. Resume works theoretically like a charm (I suspend with music playing; the = music stops and continues upon wakeup; I can reboot the system).=20 One thing that does not, however, is VGA resume. The screen will just stay blank.=20 So I looked into it a little and realized -- what's the expected behaviour = towards=20 video reset when multiple VGA cards are present (NVIDIA Optimus) with vgapc= i0=20 being the (unusable) NVIDIA board and vgapci1 the (usable with Xorg, vt(9),= KMS etc) Intel one? Best Johannes --=20 xmj@chaot.net http://xmj.me --ZGiS0Q5IWpPtfppv Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBAgAGBQJTDbdrAAoJEAy1bITjfmSMbwEP/23t5iZJVQcEDVmTDI++3j5P ukz9DhqvtHZGjeaSRuRnTBD8B/0RQGf8eEcyDYS5Eik92TCTBM6lgVs7WivYM5Tq Z2iU43uTpSmq0Zjos84yp/FdTRZTR19ODi6bpYBBQFmSSFRN1IxCNtscLVybpaNX U3agEqWZx3MZoTw43iPGKiPJLMeAVvR+xFeJ358TMu/ZrlNqguAl2wGs58O+3awD q1zR+LDZkuOuhKc53wWYM3Dk7/tW8sPir7/sbNLRvFL/nNg5EWL9jx9R4JWKJf9s x14MCQqkLd2D0u6gbH1eGToKWNDVSSDBos4iEUW5MQ/Q/0ssfurCmD/p6A9v+DPD l6IpHf/X7jXkFz2SIOsPUWcw7nQibwUO/O+wvuoQV4JJMa52i2gc+vOGFKePwB// 9+FXh7fFst4frZbVx9cXWTEvrPEGvxJ3l1+ypjtx3SvkdE8fwMu8JRJJ1KGwT0VP C3GxD80fW6sS+Vs9JrZXSk6PzI8M59TIS5SHqXMzssys243YkWY51jh56Nd2dYn+ EhsaZb9uayKdp4ze68jOkhVD/M75qIQPy4Q9K+T0nDQY8gUcp4MDOSDiV5X3EVyX GZ9kv4xCrmTYs06gGCX2+0PvE4xt2eFFverm1s0VlALHaPZUMy2FGCPDiF0wzyb3 ey7j90ILuo0CvRzXhlTP =bfwD -----END PGP SIGNATURE----- --ZGiS0Q5IWpPtfppv-- From owner-freebsd-acpi@FreeBSD.ORG Sun Mar 2 01:08:40 2014 Return-Path: Delivered-To: freebsd-acpi@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A0ABAEE4; Sun, 2 Mar 2014 01:08:40 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 756AD1575; Sun, 2 Mar 2014 01:08:40 +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 s2218eUE034766; Sun, 2 Mar 2014 01:08:40 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.8/8.14.8/Submit) id s2218eE5034765; Sun, 2 Mar 2014 01:08:40 GMT (envelope-from linimon) Date: Sun, 2 Mar 2014 01:08:40 GMT Message-Id: <201403020108.s2218eE5034765@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-acpi@FreeBSD.org From: linimon@FreeBSD.org Subject: Re: kern/187152: [i386] [acpi] resume from ACPI suspend (s3) sometimes results in all processes dying from sig 8 (SIGFPE) X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.17 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 Mar 2014 01:08:40 -0000 Synopsis: [i386] [acpi] resume from ACPI suspend (s3) sometimes results in all processes dying from sig 8 (SIGFPE) Responsible-Changed-From-To: freebsd-bugs->freebsd-acpi Responsible-Changed-By: linimon Responsible-Changed-When: Sun Mar 2 01:08:33 UTC 2014 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=187152 From owner-freebsd-acpi@FreeBSD.ORG Mon Mar 3 11:06:40 2014 Return-Path: Delivered-To: freebsd-acpi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B1BC7D9A for ; Mon, 3 Mar 2014 11:06:40 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 83F21930 for ; Mon, 3 Mar 2014 11:06:40 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.8/8.14.8) with ESMTP id s23B6ef3008405 for ; Mon, 3 Mar 2014 11:06:40 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.8/8.14.8/Submit) id s23B6eGj008403 for freebsd-acpi@FreeBSD.org; Mon, 3 Mar 2014 11:06:40 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 3 Mar 2014 11:06:40 GMT Message-Id: <201403031106.s23B6eGj008403@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.17 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Mar 2014 11:06:40 -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/187152 acpi [i386] [acpi] resume from ACPI suspend (s3) sometimes o kern/181665 acpi [acpi] System will not go into S3 state. o kern/180897 acpi [acpi] ACPI error with MB p8h67 v.1405 o kern/174766 acpi [acpi] Random acpi panic o kern/174504 acpi [ACPI] Suspend/resume broken on Lenovo x220 o kern/173408 acpi [acpi] [regression] ACPI Regression: battery does not 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/73823 acpi [request] acpi / power-on by timer support 29 problems total. From owner-freebsd-acpi@FreeBSD.ORG Mon Mar 3 15:24:19 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 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8A50A890; Mon, 3 Mar 2014 15:24:19 +0000 (UTC) Received: from mail-yk0-x231.google.com (mail-yk0-x231.google.com [IPv6:2607:f8b0:4002:c07::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 38FAD3CC; Mon, 3 Mar 2014 15:24:19 +0000 (UTC) Received: by mail-yk0-f177.google.com with SMTP id q200so10846497ykb.8 for ; Mon, 03 Mar 2014 07:24:18 -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=hVjhdREoTSz2DfjHdUHgF7Nh+Mhg/99iXGci2HMODzY=; b=Q5/ad1+aIzWkWXRZRBjsPfwcoaVpOf4rCm74fC/rQG2XPCfRkm8rikpSZLd2ypca3L hVDoDNvtq5f/Wjaqo+E2s1rW8VOKR4NGCrEtTuEoP74unZfJDpUjCdO7ohvZyfzg1nH3 DaU1YibFPPkQo0SeV7q3Xhv38pmR3Tt6wWasDpLKVqeY6rMV+iEiaSuxXIZtaV+xwzrx BMlo6WdO1Lv/Y7bwbDrBDmw8JTvQZBTj5em56GlqcrA6vFmpm6yq9uiPCO/fStYpfGh8 TVV0tdcwCuR1YZm6cVI0knKZdUyJZEasqmP6Rwr+qrU5aTFkpWQ1T9/bEuKX+o2jIrbn ekcA== MIME-Version: 1.0 X-Received: by 10.236.53.135 with SMTP id g7mr1669211yhc.106.1393860258450; Mon, 03 Mar 2014 07:24:18 -0800 (PST) Received: by 10.170.95.212 with HTTP; Mon, 3 Mar 2014 07:24:18 -0800 (PST) Date: Mon, 3 Mar 2014 16:24:18 +0100 Message-ID: Subject: Re: ACPI issues with PC engines APU beta board From: Idwer Vollering To: lab@gta.com, jhb@freebsd.org, "freebsd-acpi@freebsd.org?Subject=Re: ACPI issues with PC engines APU beta board&In-Reply-To=" Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Mar 2014 15:24:19 -0000 First: I'm not subscribed to freebsd-acpi. This beta board runs coreboot, which is GPL'ed software. This means that it is possible to submit a contribution that lets you boot FreeBSD 9.2 and 10. Working with PC Engines to come up with a solution is the right way. FWIW, I can boot FreeBSD 9.2 just fine on amd64 hardware (ASUS F2A85-M) that also starts with coreboot. Last wise words: http://www.coreboot.org/Git#Accessing_the_repository http://www.coreboot.org/Mailinglist HTH, Idwer From owner-freebsd-acpi@FreeBSD.ORG Mon Mar 3 15:48:44 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 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D7D6937C for ; Mon, 3 Mar 2014 15:48:44 +0000 (UTC) Received: from mailgate.gta.com (mailgate.gta.com [199.120.225.23]) by mx1.freebsd.org (Postfix) with ESMTP id 863997E7 for ; Mon, 3 Mar 2014 15:48:44 +0000 (UTC) Received: (qmail 7025 invoked by uid 1000); 3 Mar 2014 15:48:34 -0000 Date: Mon, 3 Mar 2014 10:48:34 -0500 From: Larry Baird To: Idwer Vollering Subject: Re: ACPI issues with PC engines APU beta board Message-ID: <20140303154834.GA5864@gta.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.22 (2013-10-16) Cc: freebsd-acpi@freebsd.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Mar 2014 15:48:44 -0000 > This beta board runs coreboot, which is GPL'ed software. This means that it > is possible to submit a contribution that lets you boot FreeBSD 9.2 and 10. > > Working with PC Engines to come up with a solution is the right way. > > FWIW, I can boot FreeBSD 9.2 just fine on amd64 hardware (ASUS F2A85-M) > that also starts with coreboot. FreeBSD has working on the issue from two directions. 1) John Baldwin has made software changes to FreeBSD head that work around the issue (http://svnweb.freebsd.org/base?view=revision&sortby=date&revision=261243). This issue was to be MFCed a few weeks back. I am sure that John will MFC it at some point. 2) I worked with Jung-uk Kim to develop BIOS patches to give to PC Engines to provide back to SAGE. I received an updated BIOS with this change the end of last week. Larry -- ------------------------------------------------------------------------ Larry Baird Global Technology Associates, Inc. 1992-2012 | http://www.gta.com Celebrating Twenty Years of Software Innovation | Orlando, FL Email: lab@gta.com | TEL 407-380-0220 From owner-freebsd-acpi@FreeBSD.ORG Mon Mar 3 23:50:01 2014 Return-Path: Delivered-To: freebsd-acpi@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7E8CE2A4 for ; Mon, 3 Mar 2014 23:50:01 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 527F4131 for ; Mon, 3 Mar 2014 23:50:01 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.8/8.14.8) with ESMTP id s23No1Wc051184 for ; Mon, 3 Mar 2014 23:50:01 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.8/8.14.8/Submit) id s23No0TT051132; Mon, 3 Mar 2014 23:50:00 GMT (envelope-from gnats) Date: Mon, 3 Mar 2014 23:50:00 GMT Message-Id: <201403032350.s23No0TT051132@freefall.freebsd.org> To: freebsd-acpi@FreeBSD.org Cc: From: Adrian Chadd Subject: Re: kern/187152 X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Adrian Chadd List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Mar 2014 23:50:01 -0000 The following reply was made to PR kern/187152; it has been noted by GNATS. From: Adrian Chadd To: "bug-followup@freebsd.org" , Adrian Chadd Cc: Subject: Re: kern/187152 Date: Mon, 3 Mar 2014 15:46:30 -0800 Hi, After resume, starting any processes would also result in SIGFPE. This time i was lucky enough to get to a non-X newcons login prompt, and login would spawn fine, but the shell(s) would die instantly with SIGFPE. -a From owner-freebsd-acpi@FreeBSD.ORG Mon Mar 10 11:06:41 2014 Return-Path: Delivered-To: freebsd-acpi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 12077FE3 for ; Mon, 10 Mar 2014 11:06:41 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D9E307FC for ; Mon, 10 Mar 2014 11:06:40 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.8/8.14.8) with ESMTP id s2AB6e39043105 for ; Mon, 10 Mar 2014 11:06:40 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.8/8.14.8/Submit) id s2AB6e0n043103 for freebsd-acpi@FreeBSD.org; Mon, 10 Mar 2014 11:06:40 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 10 Mar 2014 11:06:40 GMT Message-Id: <201403101106.s2AB6e0n043103@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.17 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Mar 2014 11:06:41 -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/187152 acpi [i386] [acpi] resume from ACPI suspend (s3) sometimes o kern/181665 acpi [acpi] System will not go into S3 state. o kern/180897 acpi [acpi] ACPI error with MB p8h67 v.1405 o kern/174766 acpi [acpi] Random acpi panic o kern/174504 acpi [ACPI] Suspend/resume broken on Lenovo x220 o kern/173408 acpi [acpi] [regression] ACPI Regression: battery does not 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/73823 acpi [request] acpi / power-on by timer support 29 problems total. From owner-freebsd-acpi@FreeBSD.ORG Mon Mar 10 19:49:27 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 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9C8A57E8 for ; Mon, 10 Mar 2014 19:49:27 +0000 (UTC) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [IPv6:2607:f3e0:0:1::12]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 1448C789 for ; Mon, 10 Mar 2014 19:49:27 +0000 (UTC) Received: from [IPv6:2607:f3e0:0:4:f025:8813:7603:7e4a] (saphire3.sentex.ca [IPv6:2607:f3e0:0:4:f025:8813:7603:7e4a]) by smarthost1.sentex.ca (8.14.7/8.14.7) with ESMTP id s2AJnQlP017958; Mon, 10 Mar 2014 15:49:26 -0400 (EDT) (envelope-from mike@sentex.net) Message-ID: <531E1742.2020906@sentex.net> Date: Mon, 10 Mar 2014 15:49:22 -0400 From: Mike Tancsa Organization: Sentex Communications User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Larry Baird , Idwer Vollering Subject: Re: ACPI issues with PC engines APU beta board References: <20140303154834.GA5864@gta.com> In-Reply-To: <20140303154834.GA5864@gta.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.74 Cc: freebsd-acpi@freebsd.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Mar 2014 19:49:27 -0000 On 3/3/2014 10:48 AM, Larry Baird wrote: >> This beta board runs coreboot, which is GPL'ed software. This means that it >> is possible to submit a contribution that lets you boot FreeBSD 9.2 and 10. >> >> Working with PC Engines to come up with a solution is the right way. >> >> FWIW, I can boot FreeBSD 9.2 just fine on amd64 hardware (ASUS F2A85-M) >> that also starts with coreboot. > FreeBSD has working on the issue from two directions. > > 1) John Baldwin has made software changes to FreeBSD > head that work around the issue (http://svnweb.freebsd.org/base?view=revision&sortby=date&revision=261243). This issue was to be MFCed a few weeks back. > I am sure that John will MFC it at some point. > > 2) I worked with Jung-uk Kim to develop BIOS patches to > give to PC Engines to provide back to SAGE. I received an updated BIOS > with this change the end of last week. Hi, I just got one of these boards to evaluate. I was trying to load the watchdog, but no luck. There seem to be a few other errors too amdsbwd0: ResetStatus0 = 0xf9 amdsbwd0: ResetStatus1 = 0x0b amdsbwd0: memory base address = 0xfec000f0 amdsbwd0: at iomem 0xfec000f0-0xfec000f3,0xfec000f4-0xfec000f7 on isa0 amdsbwd0: bus_alloc_resource for ctrl failed device_attach: amdsbwd0 attach returned 6 USB seems to have some issues as well device_attach: pcib4 attach returned 6 ohci0: at device 20.5 on pci0 ohci0: 0x1000 bytes of rid 0x10 res 3 failed (0, 0xffffffff). ohci0: Could not map memory device_attach: ohci0 attach returned 6 pcib4: at device 21.0 on pci0 pci4: on pcib4 ohci0: at device 22.0 on pci0 ohci0: 0x1000 bytes of rid 0x10 res 3 failed (0, 0xffffffff). ohci0: Could not map memory device_attach: ohci0 attach returned 6 ehci0: at device 22.2 on pci0 ehci0: 0x100 bytes of rid 0x10 res 3 failed (0, 0xffffffff). ehci0: Could not map memory device_attach: ehci0 attach returned 6 acpi_button0: on acpi0 pmtimer0 on isa0 not sure of the NIC errors are issues too ? re2: port 0x3000-0x30ff at device 0.0 on pci3 re2: 0x1000 bytes of rid 0x18 res 3 failed (0, 0xffffffff). re2: 0x4000 bytes of rid 0x20 res 3 failed (0, 0xffffffff). re2: could not allocate MSI-X PBA resource re2: Using 1 MSI message re2: ASPM disabled re2: Chip rev. 0x2c000000 re2: MAC rev. 0x00200000 miibus2: on re2 rgephy2: PHY 1 on miibus2 rgephy2: none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, 1000baseT-FDX-flow, 1000baseT-FDX-flow-master, auto, auto-flow re2: Ethernet address: 00:0d:b9:33:11:c6 Start bios (version ?-20131224_111227-ubuntubuilderx64) CPU Mhz=1000 10.0-STABLE FreeBSD 10.0-STABLE #2 r262153 i386 ---Mike -- ------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ From owner-freebsd-acpi@FreeBSD.ORG Mon Mar 10 20:03:21 2014 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EC320C54 for ; Mon, 10 Mar 2014 20:03:20 +0000 (UTC) Received: from mailgate.gta.com (mailgate.gta.com [199.120.225.23]) by mx1.freebsd.org (Postfix) with ESMTP id 9685191F for ; Mon, 10 Mar 2014 20:03:20 +0000 (UTC) Received: (qmail 69422 invoked by uid 1000); 10 Mar 2014 20:03:13 -0000 Date: Mon, 10 Mar 2014 16:03:13 -0400 From: Larry Baird To: Mike Tancsa Subject: Re: ACPI issues with PC engines APU beta board Message-ID: <20140310200313.GB67247@gta.com> References: <20140303154834.GA5864@gta.com> <531E1742.2020906@sentex.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <531E1742.2020906@sentex.net> User-Agent: Mutt/1.5.22 (2013-10-16) Cc: freebsd-acpi@freebsd.org, Idwer Vollering X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Mar 2014 20:03:21 -0000 On Mon, Mar 10, 2014 at 03:49:22PM -0400, Mike Tancsa wrote: > On 3/3/2014 10:48 AM, Larry Baird wrote: > >> This beta board runs coreboot, which is GPL'ed software. This means that it > >> is possible to submit a contribution that lets you boot FreeBSD 9.2 and 10. > >> > >> Working with PC Engines to come up with a solution is the right way. > >> > >> FWIW, I can boot FreeBSD 9.2 just fine on amd64 hardware (ASUS F2A85-M) > >> that also starts with coreboot. > > FreeBSD has working on the issue from two directions. > > > > 1) John Baldwin has made software changes to FreeBSD > > head that work around the issue (http://svnweb.freebsd.org/base?view=revision&sortby=date&revision=261243). This issue was to be MFCed a few weeks back. > > I am sure that John will MFC it at some point. > > > > 2) I worked with Jung-uk Kim to develop BIOS patches to > > give to PC Engines to provide back to SAGE. I received an updated BIOS > > with this change the end of last week. > > Hi, > I just got one of these boards to evaluate. I was trying to load the > watchdog, but no luck. There seem to be a few other errors too > > amdsbwd0: ResetStatus0 = 0xf9 > amdsbwd0: ResetStatus1 = 0x0b > amdsbwd0: memory base address = 0xfec000f0 > amdsbwd0: at iomem > 0xfec000f0-0xfec000f3,0xfec000f4-0xfec000f7 on isa0 > amdsbwd0: bus_alloc_resource for ctrl failed > device_attach: amdsbwd0 attach returned 6 > > USB seems to have some issues as well > > device_attach: pcib4 attach returned 6 > ohci0: at device 20.5 on pci0 > ohci0: 0x1000 bytes of rid 0x10 res 3 failed (0, 0xffffffff). > ohci0: Could not map memory > device_attach: ohci0 attach returned 6 > pcib4: at device 21.0 on pci0 > pci4: on pcib4 > ohci0: at device 22.0 on pci0 > ohci0: 0x1000 bytes of rid 0x10 res 3 failed (0, 0xffffffff). > ohci0: Could not map memory > device_attach: ohci0 attach returned 6 > ehci0: at device 22.2 on pci0 > ehci0: 0x100 bytes of rid 0x10 res 3 failed (0, 0xffffffff). > ehci0: Could not map memory > device_attach: ehci0 attach returned 6 > acpi_button0: on acpi0 > pmtimer0 on isa0 > > not sure of the NIC errors are issues too ? > > re2: port > 0x3000-0x30ff at device 0.0 on pci3 > re2: 0x1000 bytes of rid 0x18 res 3 failed (0, 0xffffffff). > re2: 0x4000 bytes of rid 0x20 res 3 failed (0, 0xffffffff). > re2: could not allocate MSI-X PBA resource > re2: Using 1 MSI message > re2: ASPM disabled > re2: Chip rev. 0x2c000000 > re2: MAC rev. 0x00200000 > miibus2: on re2 > rgephy2: PHY 1 on miibus2 > rgephy2: none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, > 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT, 1000baseT-master, > 1000baseT-FDX, 1000baseT-FDX-master, 1000baseT-FDX-flow, > 1000baseT-FDX-flow-master, auto, auto-flow > re2: Ethernet address: 00:0d:b9:33:11:c6 > > Start bios (version ?-20131224_111227-ubuntubuilderx64) > CPU Mhz=1000 > > 10.0-STABLE FreeBSD 10.0-STABLE #2 r262153 i386 You will need to either update the BIOS or patch FreeBSD 10. The patch associated with: http://svnweb.freebsd.org/base?view=revision&sortby=date&revision=261243 applies cleanly to FreeBSD 10. The latest BIOS from PC engines for the APU board is very noisy when it boots. Hopefully the code change will get MFCed now that the APU board is generally available: http://www.pcengines.ch/apu.htm Larry -- ------------------------------------------------------------------------ Larry Baird Global Technology Associates, Inc. 1992-2012 | http://www.gta.com Celebrating Twenty Years of Software Innovation | Orlando, FL Email: lab@gta.com | TEL 407-380-0220 From owner-freebsd-acpi@FreeBSD.ORG Mon Mar 10 20:34:29 2014 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 83C6E2B5; Mon, 10 Mar 2014 20:34:29 +0000 (UTC) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [IPv6:2607:f3e0:0:1::12]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 3042FBCC; Mon, 10 Mar 2014 20:34:29 +0000 (UTC) Received: from [IPv6:2607:f3e0:0:4:f025:8813:7603:7e4a] (saphire3.sentex.ca [IPv6:2607:f3e0:0:4:f025:8813:7603:7e4a]) by smarthost1.sentex.ca (8.14.7/8.14.7) with ESMTP id s2AKYSwJ023852; Mon, 10 Mar 2014 16:34:29 -0400 (EDT) (envelope-from mike@sentex.net) Message-ID: <531E21D0.8000409@sentex.net> Date: Mon, 10 Mar 2014 16:34:24 -0400 From: Mike Tancsa Organization: Sentex Communications User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Larry Baird Subject: Re: ACPI issues with PC engines APU beta board References: <20140303154834.GA5864@gta.com> <531E1742.2020906@sentex.net> <20140310200313.GB67247@gta.com> In-Reply-To: <20140310200313.GB67247@gta.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.74 Cc: freebsd-acpi@freebsd.org, Idwer Vollering X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Mar 2014 20:34:29 -0000 On 3/10/2014 4:03 PM, Larry Baird wrote: > On Mon, Mar 10, 2014 at 03:49:22PM -0400, Mike Tancsa wrote: >> On 3/3/2014 10:48 AM, Larry Baird wrote: >>>> This beta board runs coreboot, which is GPL'ed software. This means that it >>>> is possible to submit a contribution that lets you boot FreeBSD 9.2 and 10. >>>> >>>> Working with PC Engines to come up with a solution is the right way. >>>> >>>> FWIW, I can boot FreeBSD 9.2 just fine on amd64 hardware (ASUS F2A85-M) >>>> that also starts with coreboot. >>> FreeBSD has working on the issue from two directions. >>> >>> 1) John Baldwin has made software changes to FreeBSD >>> head that work around the issue (http://svnweb.freebsd.org/base?view=revision&sortby=date&revision=261243). This issue was to be MFCed a few weeks back. >>> I am sure that John will MFC it at some point. >>> >>> 2) I worked with Jung-uk Kim to develop BIOS patches to >>> give to PC Engines to provide back to SAGE. I received an updated BIOS >>> with this change the end of last week. >> >> Hi, >> I just got one of these boards to evaluate. I was trying to load the >> watchdog, but no luck. There seem to be a few other errors too >> >> amdsbwd0: ResetStatus0 = 0xf9 >> amdsbwd0: ResetStatus1 = 0x0b >> amdsbwd0: memory base address = 0xfec000f0 >> amdsbwd0: at iomem >> 0xfec000f0-0xfec000f3,0xfec000f4-0xfec000f7 on isa0 >> amdsbwd0: bus_alloc_resource for ctrl failed >> device_attach: amdsbwd0 attach returned 6 >> >> USB seems to have some issues as well >> >> device_attach: pcib4 attach returned 6 >> ohci0: at device 20.5 on pci0 >> ohci0: 0x1000 bytes of rid 0x10 res 3 failed (0, 0xffffffff). >> ohci0: Could not map memory >> device_attach: ohci0 attach returned 6 >> pcib4: at device 21.0 on pci0 >> pci4: on pcib4 >> ohci0: at device 22.0 on pci0 >> ohci0: 0x1000 bytes of rid 0x10 res 3 failed (0, 0xffffffff). >> ohci0: Could not map memory >> device_attach: ohci0 attach returned 6 >> ehci0: at device 22.2 on pci0 >> ehci0: 0x100 bytes of rid 0x10 res 3 failed (0, 0xffffffff). >> ehci0: Could not map memory >> device_attach: ehci0 attach returned 6 >> acpi_button0: on acpi0 >> pmtimer0 on isa0 >> >> not sure of the NIC errors are issues too ? >> >> re2: port >> 0x3000-0x30ff at device 0.0 on pci3 >> re2: 0x1000 bytes of rid 0x18 res 3 failed (0, 0xffffffff). >> re2: 0x4000 bytes of rid 0x20 res 3 failed (0, 0xffffffff). >> re2: could not allocate MSI-X PBA resource >> re2: Using 1 MSI message >> re2: ASPM disabled >> re2: Chip rev. 0x2c000000 >> re2: MAC rev. 0x00200000 >> miibus2: on re2 >> rgephy2: PHY 1 on miibus2 >> rgephy2: none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, >> 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT, 1000baseT-master, >> 1000baseT-FDX, 1000baseT-FDX-master, 1000baseT-FDX-flow, >> 1000baseT-FDX-flow-master, auto, auto-flow >> re2: Ethernet address: 00:0d:b9:33:11:c6 >> >> Start bios (version ?-20131224_111227-ubuntubuilderx64) >> CPU Mhz=1000 >> >> 10.0-STABLE FreeBSD 10.0-STABLE #2 r262153 i386 > You will need to either update the BIOS or patch FreeBSD 10. The > patch associated with: > http://svnweb.freebsd.org/base?view=revision&sortby=date&revision=261243 > applies cleanly to FreeBSD 10. The latest BIOS from PC engines for the APU > board is very noisy when it boots. Hopefully the code change will get MFCed > now that the APU board is generally available: > http://www.pcengines.ch/apu.htm Where can I find the latest BIOS ? Its not on the website Any reason why this has not been MFC'd ? Is there a downside to having it applied / running with it ? ---Mike > > Larry > > -- ------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ From owner-freebsd-acpi@FreeBSD.ORG Tue Mar 11 14:51:15 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 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 98DDA673 for ; Tue, 11 Mar 2014 14:51:15 +0000 (UTC) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [IPv6:2607:f3e0:0:1::12]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 408F1E60 for ; Tue, 11 Mar 2014 14:51:15 +0000 (UTC) Received: from [IPv6:2607:f3e0:0:4:f025:8813:7603:7e4a] (saphire3.sentex.ca [IPv6:2607:f3e0:0:4:f025:8813:7603:7e4a]) by smarthost1.sentex.ca (8.14.7/8.14.7) with ESMTP id s2BEpD2f021312 for ; Tue, 11 Mar 2014 10:51:13 -0400 (EDT) (envelope-from mike@sentex.net) Message-ID: <531F22DB.50404@sentex.net> Date: Tue, 11 Mar 2014 10:51:07 -0400 From: Mike Tancsa Organization: Sentex Communications User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: freebsd-acpi@freebsd.org Subject: Re: ACPI issues with PC engines APU beta board References: <20140303154834.GA5864@gta.com> <531E1742.2020906@sentex.net> <20140310200313.GB67247@gta.com> In-Reply-To: <20140310200313.GB67247@gta.com> Content-Type: multipart/mixed; boundary="------------000108060501000308080207" X-Scanned-By: MIMEDefang 2.74 X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Mar 2014 14:51:15 -0000 This is a multi-part message in MIME format. --------------000108060501000308080207 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 3/10/2014 4:03 PM, Larry Baird wrote: >> >> 10.0-STABLE FreeBSD 10.0-STABLE #2 r262153 i386 > You will need to either update the BIOS or patch FreeBSD 10. The > patch associated with: > http://svnweb.freebsd.org/base?view=revision&sortby=date&revision=261243 > applies cleanly to FreeBSD 10. The latest BIOS from PC engines for the APU > board is very noisy when it boots. Hopefully the code change will get MFCed > now that the APU board is generally available: > http://www.pcengines.ch/apu.htm > With the patch, all seems to work well so far. I updated to RELENG10 r262980M i386. I can now attach the watchdog, and it indeed works! Full dmesg of the pcengines APU attached for the archives. ---Mike -- ------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ --------------000108060501000308080207 Content-Type: text/plain; charset=windows-1252; name="apu.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="apu.txt" FreeBSD alix_2gen.sentex.ca 10.0-STABLE FreeBSD 10.0-STABLE #1 r262980M: Mon Mar 10 16:54:07 EDT 2014 mdtancsa@ich10.sentex.ca:/home/pxe10/usr/obj/home/pxe10/usr/src/sys/GENERIC i386 root@alix_2gen:/usr/home/mdtancsa # cat /var/run/dmesg.boot Copyright (c) 1992-2014 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 10.0-STABLE #1 r262980M: Mon Mar 10 16:54:07 EDT 2014 mdtancsa@ich10.sentex.ca:/home/pxe10/usr/obj/home/pxe10/usr/src/sys/GENERIC i386 FreeBSD clang version 3.3 (tags/RELEASE_33/final 183502) 20130610 CPU: AMD G-T40E Processor (1000.02-MHz 686-class CPU) Origin = "AuthenticAMD" Id = 0x500f20 Family = 0x14 Model = 0x2 Stepping = 0 Features=0x178bfbff Features2=0x802209 AMD Features=0x2e500800 AMD Features2=0x35ff TSC: P-state invariant, performance statistics real memory = 2114297856 (2016 MB) avail memory = 2052513792 (1957 MB) Event timer "LAPIC" quality 400 ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ioapic0 irqs 0-23 on motherboard kbd0 at kbdmux0 random: initialized module_register_init: MOD_LOAD (vesa, 0xc0f1f940, 0) error 19 acpi0: on motherboard acpi0: Power Button (fixed) cpu0: on acpi0 cpu1: on acpi0 atrtc0: port 0x70-0x71 irq 8 on acpi0 Event timer "RTC" frequency 32768 Hz quality 0 attimer0: port 0x40-0x43 irq 0 on acpi0 Timecounter "i8254" frequency 1193182 Hz quality 0 Event timer "i8254" frequency 1193182 Hz quality 100 Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 acpi_timer0: <32-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 950 Event timer "HPET" frequency 14318180 Hz quality 550 Event timer "HPET1" frequency 14318180 Hz quality 450 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: at device 4.0 on pci0 pci1: on pcib1 re0: port 0x1000-0x10ff mem 0xfe600000-0xfe600fff,0xfe500000-0xfe503fff at device 0.0 on pci1 re0: Using 1 MSI-X message re0: ASPM disabled re0: Chip rev. 0x2c000000 re0: MAC rev. 0x00200000 miibus0: on re0 rgephy0: PHY 1 on miibus0 rgephy0: none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, 1000baseT-FDX-flow, 1000baseT-FDX-flow-master, auto, auto-flow re0: Ethernet address: 00:0d:b9:33:11:c4 pcib2: at device 5.0 on pci0 pci2: on pcib2 re1: port 0x2000-0x20ff mem 0xfe800000-0xfe800fff,0xfe700000-0xfe703fff at device 0.0 on pci2 re1: Using 1 MSI-X message re1: ASPM disabled re1: Chip rev. 0x2c000000 re1: MAC rev. 0x00200000 miibus1: on re1 rgephy1: PHY 1 on miibus1 rgephy1: none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, 1000baseT-FDX-flow, 1000baseT-FDX-flow-master, auto, auto-flow re1: Ethernet address: 00:0d:b9:33:11:c5 pcib3: at device 6.0 on pci0 pci3: on pcib3 re2: port 0x3000-0x30ff mem 0xfea00000-0xfea00fff,0xfe900000-0xfe903fff at device 0.0 on pci3 re2: Using 1 MSI-X message re2: ASPM disabled re2: Chip rev. 0x2c000000 re2: MAC rev. 0x00200000 miibus2: on re2 rgephy2: PHY 1 on miibus2 rgephy2: none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, 1000baseT-FDX-flow, 1000baseT-FDX-flow-master, auto, auto-flow re2: Ethernet address: 00:0d:b9:33:11:c6 ahci0: port 0x4020-0x4027,0x4040-0x4043,0x4028-0x402f,0x4044-0x4047,0x4000-0x400f mem 0xfeb04000-0xfeb043ff at device 17.0 on pci0 ahci0: AHCI v1.20 with 4 6Gbps ports, Port Multiplier supported ahcich0: at channel 0 on ahci0 ahcich1: at channel 1 on ahci0 ahcich2: at channel 2 on ahci0 ahcich3: at channel 3 on ahci0 ohci0: mem 0xfeb00000-0xfeb00fff at device 18.0 on pci0 usbus0 on ohci0 ehci0: mem 0xfeb04400-0xfeb044ff at device 18.2 on pci0 usbus1: EHCI version 1.0 usbus1 on ehci0 ohci1: mem 0xfeb01000-0xfeb01fff at device 19.0 on pci0 usbus2 on ohci1 ehci1: mem 0xfeb04500-0xfeb045ff at device 19.2 on pci0 usbus3: EHCI version 1.0 usbus3 on ehci1 pci0: at device 20.0 (no driver attached) atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x4010-0x401f at device 20.1 on pci0 ata0: at channel 0 on atapci0 ata1: at channel 1 on atapci0 isab0: at device 20.3 on pci0 isa0: on isab0 pcib4: at device 20.4 on pci0 pcib4: failed to allocate initial memory window: 0-0xfffff pcib4: failed to allocate initial prefetch window: 0-0xfffff pci0: couldn't attach pci bus device_attach: pcib4 attach returned 6 ohci2: mem 0xfeb02000-0xfeb02fff at device 20.5 on pci0 usbus4 on ohci2 pcib4: at device 21.0 on pci0 pci4: on pcib4 ohci3: mem 0xfeb03000-0xfeb03fff at device 22.0 on pci0 usbus5 on ohci3 ehci2: mem 0xfeb04600-0xfeb046ff at device 22.2 on pci0 usbus6: EHCI version 1.0 usbus6 on ehci2 acpi_button0: on acpi0 pmtimer0 on isa0 orm0: at iomem 0xee800-0xeffff pnpid ORM0000 on isa0 ppc0: at port 0x378-0x37f irq 7 on isa0 ppc0: Generic chipset (EPP/NIBBLE) in COMPATIBLE mode ppbus0: on ppc0 lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 uart0: <16550 or compatible> at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 uart0: console (115200,n,8,1) uart1: <16550 or compatible> at port 0x2f8-0x2ff irq 3 on isa0 acpi_throttle0: on cpu0 Timecounters tick every 1.000 msec random: unblocking device. usbus0: 12Mbps Full Speed USB v1.0 usbus1: 480Mbps High Speed USB v2.0 usbus2: 12Mbps Full Speed USB v1.0 usbus3: 480Mbps High Speed USB v2.0 ugen0.1: at usbus0 uhub0: on usbus0 ugen1.1: at usbus1 uhub1: on usbus1 ugen2.1: at usbus2 uhub2: on usbus2 ugen3.1: at usbus3 uhub3: on usbus3 usbus4: 12Mbps Full Speed USB v1.0 usbus5: 12Mbps Full Speed USB v1.0 usbus6: 480Mbps High Speed USB v2.0 ugen4.1: at usbus4 uhub4: on usbus4 ugen5.1: at usbus5 uhub5: on usbus5 ugen6.1: at usbus6 uhub6: on usbus6 uhub4: 2 ports with 2 removable, self powered uhub0: 5 ports with 5 removable, self powered uhub2: 5 ports with 5 removable, self powered uhub5: 4 ports with 4 removable, self powered uhub6: 4 ports with 4 removable, self powered uhub1: 5 ports with 5 removable, self powered uhub3: 5 ports with 5 removable, self powered ugen6.2: at usbus6 umass0: on usbus6 umass0: SCSI over Bulk-Only; quirks = 0x4001 umass0:6:0:-1: Attached to scbus6 ugen0.2: at usbus0 ugen0.3: at usbus0 da0 at umass-sim0 bus 0 scbus6 target 0 lun 0 da0: Removable Direct Access SCSI-4 device da0: Serial Number 058F63666485 da0: 40.000MB/s transfers da0: Attempt to query device size failed: NOT READY, Medium not present da0: quirks=0x2 Netvsc initializing... SMP: AP CPU #1 Launched! Timecounter "TSC" frequency 1000021163 Hz quality 800 Trying to mount root from nfs: []... NFS ROOT: 10.255.255.1:/home/pxe10 umodem0: on usbus0 umodem0: data interface 1, has CM over data, has no break amdsbwd0: at iomem 0xfec000f0-0xfec000f3,0xfec000f4-0xfec000f7 on isa0 root@alix_2gen:/usr/home/mdtancsa # usbconfig ugen0.1: at usbus0, cfg=0 md=HOST spd=FULL (12Mbps) pwr=SAVE (0mA) ugen1.1: at usbus1, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE (0mA) ugen2.1: at usbus2, cfg=0 md=HOST spd=FULL (12Mbps) pwr=SAVE (0mA) ugen3.1: at usbus3, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE (0mA) ugen4.1: at usbus4, cfg=0 md=HOST spd=FULL (12Mbps) pwr=SAVE (0mA) ugen5.1: at usbus5, cfg=0 md=HOST spd=FULL (12Mbps) pwr=SAVE (0mA) ugen6.1: at usbus6, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE (0mA) ugen6.2: at usbus6, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON (100mA) ugen0.2: at usbus0, cfg=0 md=HOST spd=LOW (1.5Mbps) pwr=ON (2mA) ugen0.3: at usbus0, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON (100mA) root@alix_2gen:/usr/home/mdtancsa # usbconfig ugen0.1: at usbus0, cfg=0 md=HOST spd=FULL (12Mbps) pwr=SAVE (0mA) ugen1.1: at usbus1, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE (0mA) ugen2.1: at usbus2, cfg=0 md=HOST spd=FULL (12Mbps) pwr=SAVE (0mA) ugen3.1: at usbus3, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE (0mA) ugen4.1: at usbus4, cfg=0 md=HOST spd=FULL (12Mbps) pwr=SAVE (0mA) ugen5.1: at usbus5, cfg=0 md=HOST spd=FULL (12Mbps) pwr=SAVE (0mA) ugen6.1: at usbus6, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE (0mA) ugen6.2: at usbus6, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON (100mA) ugen0.2: at usbus0, cfg=0 md=HOST spd=LOW (1.5Mbps) pwr=ON (2mA) ugen0.3: at usbus0, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON (100mA) # pciconf -lvbc hostb0@pci0:0:0:0: class=0x060000 card=0x15101022 chip=0x15101022 rev=0x00 hdr=0x00 vendor = 'Advanced Micro Devices [AMD]' device = 'Family 14h Processor Root Complex' class = bridge subclass = HOST-PCI pcib1@pci0:0:4:0: class=0x060400 card=0x12341022 chip=0x15121022 rev=0x00 hdr=0x01 vendor = 'Advanced Micro Devices [AMD]' device = 'Family 14h Processor Root Port' class = bridge subclass = PCI-PCI cap 01[50] = powerspec 3 supports D0 D3 current D0 cap 10[58] = PCI-Express 2 root port slot max data 128(128) link x1(x1) speed 2.5(5.0) ASPM L0s/L1(L0s/L1) cap 05[a0] = MSI supports 1 message, 64 bit cap 0d[b0] = PCI Bridge card=0x12341022 cap 08[b8] = HT MSI fixed address window enabled at 0xfee00000 pcib2@pci0:0:5:0: class=0x060400 card=0x12341022 chip=0x15131022 rev=0x00 hdr=0x01 vendor = 'Advanced Micro Devices [AMD]' device = 'Family 14h Processor Root Port' class = bridge subclass = PCI-PCI cap 01[50] = powerspec 3 supports D0 D3 current D0 cap 10[58] = PCI-Express 2 root port slot max data 128(128) link x1(x1) speed 2.5(5.0) ASPM L0s/L1(L0s/L1) cap 05[a0] = MSI supports 1 message, 64 bit cap 0d[b0] = PCI Bridge card=0x12341022 cap 08[b8] = HT MSI fixed address window enabled at 0xfee00000 pcib3@pci0:0:6:0: class=0x060400 card=0x12341022 chip=0x15141022 rev=0x00 hdr=0x01 vendor = 'Advanced Micro Devices [AMD]' device = 'Family 14h Processor Root Port' class = bridge subclass = PCI-PCI cap 01[50] = powerspec 3 supports D0 D3 current D0 cap 10[58] = PCI-Express 2 root port slot max data 128(128) link x1(x1) speed 2.5(5.0) ASPM L0s/L1(L0s/L1) cap 05[a0] = MSI supports 1 message, 64 bit cap 0d[b0] = PCI Bridge card=0x12341022 cap 08[b8] = HT MSI fixed address window enabled at 0xfee00000 ahci0@pci0:0:17:0: class=0x010601 card=0x43911002 chip=0x43911002 rev=0x40 hdr=0x00 vendor = 'Advanced Micro Devices [AMD] nee ATI' device = 'SB7x0/SB8x0/SB9x0 SATA Controller [AHCI mode]' class = mass storage subclass = SATA bar [10] = type I/O Port, range 32, base 0x4020, size 8, enabled bar [14] = type I/O Port, range 32, base 0x4040, size 4, enabled bar [18] = type I/O Port, range 32, base 0x4028, size 8, enabled bar [1c] = type I/O Port, range 32, base 0x4044, size 4, enabled bar [20] = type I/O Port, range 32, base 0x4000, size 16, enabled bar [24] = type Memory, range 32, base 0xfeb04000, size 1024, enabled cap 12[70] = SATA Index-Data Pair cap 13[a4] = PCI Advanced Features: FLR TP ohci0@pci0:0:18:0: class=0x0c0310 card=0x43971002 chip=0x43971002 rev=0x00 hdr=0x00 vendor = 'Advanced Micro Devices [AMD] nee ATI' device = 'SB7x0/SB8x0/SB9x0 USB OHCI0 Controller' class = serial bus subclass = USB bar [10] = type Memory, range 32, base 0xfeb00000, size 4096, enabled ehci0@pci0:0:18:2: class=0x0c0320 card=0x43961002 chip=0x43961002 rev=0x00 hdr=0x00 vendor = 'Advanced Micro Devices [AMD] nee ATI' device = 'SB7x0/SB8x0/SB9x0 USB EHCI Controller' class = serial bus subclass = USB bar [10] = type Memory, range 32, base 0xfeb04400, size 256, enabled cap 01[c0] = powerspec 2 supports D0 D1 D2 D3 current D0 cap 0a[e4] = EHCI Debug Port at offset 0xe0 in map 0x14 ohci1@pci0:0:19:0: class=0x0c0310 card=0x43971002 chip=0x43971002 rev=0x00 hdr=0x00 vendor = 'Advanced Micro Devices [AMD] nee ATI' device = 'SB7x0/SB8x0/SB9x0 USB OHCI0 Controller' class = serial bus subclass = USB bar [10] = type Memory, range 32, base 0xfeb01000, size 4096, enabled ehci1@pci0:0:19:2: class=0x0c0320 card=0x43961002 chip=0x43961002 rev=0x00 hdr=0x00 vendor = 'Advanced Micro Devices [AMD] nee ATI' device = 'SB7x0/SB8x0/SB9x0 USB EHCI Controller' class = serial bus subclass = USB bar [10] = type Memory, range 32, base 0xfeb04500, size 256, enabled cap 01[c0] = powerspec 2 supports D0 D1 D2 D3 current D0 cap 0a[e4] = EHCI Debug Port at offset 0xe0 in map 0x14 none0@pci0:0:20:0: class=0x0c0500 card=0x15101022 chip=0x43851002 rev=0x42 hdr=0x00 vendor = 'Advanced Micro Devices [AMD] nee ATI' device = 'SBx00 SMBus Controller' class = serial bus subclass = SMBus atapci0@pci0:0:20:1: class=0x01018a card=0x439c1002 chip=0x439c1002 rev=0x40 hdr=0x00 vendor = 'Advanced Micro Devices [AMD] nee ATI' device = 'SB7x0/SB8x0/SB9x0 IDE Controller' class = mass storage subclass = ATA bar [20] = type I/O Port, range 32, base 0x4010, size 16, enabled isab0@pci0:0:20:3: class=0x060100 card=0x439d1002 chip=0x439d1002 rev=0x40 hdr=0x00 vendor = 'Advanced Micro Devices [AMD] nee ATI' device = 'SB7x0/SB8x0/SB9x0 LPC host controller' class = bridge subclass = PCI-ISA none1@pci0:0:20:4: class=0x060401 card=0x00000000 chip=0x43841002 rev=0x40 hdr=0x01 vendor = 'Advanced Micro Devices [AMD] nee ATI' device = 'SBx00 PCI to PCI Bridge' class = bridge subclass = PCI-PCI ohci2@pci0:0:20:5: class=0x0c0310 card=0x43991002 chip=0x43991002 rev=0x00 hdr=0x00 vendor = 'Advanced Micro Devices [AMD] nee ATI' device = 'SB7x0/SB8x0/SB9x0 USB OHCI2 Controller' class = serial bus subclass = USB bar [10] = type Memory, range 32, base 0xfeb02000, size 4096, enabled pcib4@pci0:0:21:0: class=0x060400 card=0x00001002 chip=0x43a01002 rev=0x00 hdr=0x01 vendor = 'Advanced Micro Devices [AMD] nee ATI' device = 'SB700/SB800/SB900 PCI to PCI bridge (PCIE port 0)' class = bridge subclass = PCI-PCI cap 01[50] = powerspec 3 supports D0 D1 D2 D3 current D0 cap 10[58] = PCI-Express 2 root port max data 128(128) link x16(x4) speed undef(2.5) ASPM disabled(L0s/L1) cap 05[a0] = MSI supports 1 message, 64 bit cap 0d[b0] = PCI Bridge card=0x00001002 cap 08[b8] = HT MSI fixed address window enabled at 0xfee00000 ohci3@pci0:0:22:0: class=0x0c0310 card=0x43971002 chip=0x43971002 rev=0x00 hdr=0x00 vendor = 'Advanced Micro Devices [AMD] nee ATI' device = 'SB7x0/SB8x0/SB9x0 USB OHCI0 Controller' class = serial bus subclass = USB bar [10] = type Memory, range 32, base 0xfeb03000, size 4096, enabled ehci2@pci0:0:22:2: class=0x0c0320 card=0x43961002 chip=0x43961002 rev=0x00 hdr=0x00 vendor = 'Advanced Micro Devices [AMD] nee ATI' device = 'SB7x0/SB8x0/SB9x0 USB EHCI Controller' class = serial bus subclass = USB bar [10] = type Memory, range 32, base 0xfeb04600, size 256, enabled cap 01[c0] = powerspec 2 supports D0 D1 D2 D3 current D0 cap 0a[e4] = EHCI Debug Port at offset 0xe0 in map 0x14 hostb1@pci0:0:24:0: class=0x060000 card=0x00000000 chip=0x17001022 rev=0x43 hdr=0x00 vendor = 'Advanced Micro Devices [AMD]' device = 'Family 12h/14h Processor Function 0' class = bridge subclass = HOST-PCI hostb2@pci0:0:24:1: class=0x060000 card=0x00000000 chip=0x17011022 rev=0x00 hdr=0x00 vendor = 'Advanced Micro Devices [AMD]' device = 'Family 12h/14h Processor Function 1' class = bridge subclass = HOST-PCI hostb3@pci0:0:24:2: class=0x060000 card=0x00000000 chip=0x17021022 rev=0x00 hdr=0x00 vendor = 'Advanced Micro Devices [AMD]' device = 'Family 12h/14h Processor Function 2' class = bridge subclass = HOST-PCI hostb4@pci0:0:24:3: class=0x060000 card=0x00000000 chip=0x17031022 rev=0x00 hdr=0x00 vendor = 'Advanced Micro Devices [AMD]' device = 'Family 12h/14h Processor Function 3' class = bridge subclass = HOST-PCI cap 0f[f0] = unknown hostb5@pci0:0:24:4: class=0x060000 card=0x00000000 chip=0x17041022 rev=0x00 hdr=0x00 vendor = 'Advanced Micro Devices [AMD]' device = 'Family 12h/14h Processor Function 4' class = bridge subclass = HOST-PCI hostb6@pci0:0:24:5: class=0x060000 card=0x00000000 chip=0x17181022 rev=0x00 hdr=0x00 vendor = 'Advanced Micro Devices [AMD]' device = 'Family 12h/14h Processor Function 6' class = bridge subclass = HOST-PCI hostb7@pci0:0:24:6: class=0x060000 card=0x00000000 chip=0x17161022 rev=0x00 hdr=0x00 vendor = 'Advanced Micro Devices [AMD]' device = 'Family 12h/14h Processor Function 5' class = bridge subclass = HOST-PCI hostb8@pci0:0:24:7: class=0x060000 card=0x00000000 chip=0x17191022 rev=0x00 hdr=0x00 vendor = 'Advanced Micro Devices [AMD]' device = 'Family 12h/14h Processor Function 7' class = bridge subclass = HOST-PCI re0@pci0:1:0:0: class=0x020000 card=0x012310ec chip=0x816810ec rev=0x06 hdr=0x00 vendor = 'Realtek Semiconductor Co., Ltd.' device = 'RTL8111/8168B PCI Express Gigabit Ethernet controller' class = network subclass = ethernet bar [10] = type I/O Port, range 32, base 0x1000, size 256, enabled bar [18] = type Memory, range 64, base 0xfe600000, size 4096, enabled bar [20] = type Prefetchable Memory, range 64, base 0xfe500000, size 16384, enabled cap 01[40] = powerspec 3 supports D0 D1 D2 D3 current D0 cap 05[50] = MSI supports 1 message, 64 bit cap 10[70] = PCI-Express 2 endpoint IRQ 1 max data 128(128) link x1(x1) speed 2.5(2.5) ASPM disabled(L0s/L1) cap 11[b0] = MSI-X supports 4 messages, enabled Table in map 0x20[0x0], PBA in map 0x20[0x800] cap 03[d0] = VPD re1@pci0:2:0:0: class=0x020000 card=0x012310ec chip=0x816810ec rev=0x06 hdr=0x00 vendor = 'Realtek Semiconductor Co., Ltd.' device = 'RTL8111/8168B PCI Express Gigabit Ethernet controller' class = network subclass = ethernet bar [10] = type I/O Port, range 32, base 0x2000, size 256, enabled bar [18] = type Memory, range 64, base 0xfe800000, size 4096, enabled bar [20] = type Prefetchable Memory, range 64, base 0xfe700000, size 16384, enabled cap 01[40] = powerspec 3 supports D0 D1 D2 D3 current D0 cap 05[50] = MSI supports 1 message, 64 bit cap 10[70] = PCI-Express 2 endpoint IRQ 1 max data 128(128) link x1(x1) speed 2.5(2.5) ASPM disabled(L0s/L1) cap 11[b0] = MSI-X supports 4 messages, enabled Table in map 0x20[0x0], PBA in map 0x20[0x800] cap 03[d0] = VPD re2@pci0:3:0:0: class=0x020000 card=0x012310ec chip=0x816810ec rev=0x06 hdr=0x00 vendor = 'Realtek Semiconductor Co., Ltd.' device = 'RTL8111/8168B PCI Express Gigabit Ethernet controller' class = network subclass = ethernet bar [10] = type I/O Port, range 32, base 0x3000, size 256, enabled bar [18] = type Memory, range 64, base 0xfea00000, size 4096, enabled bar [20] = type Prefetchable Memory, range 64, base 0xfe900000, size 16384, enabled cap 01[40] = powerspec 3 supports D0 D1 D2 D3 current D0 cap 05[50] = MSI supports 1 message, 64 bit cap 10[70] = PCI-Express 2 endpoint IRQ 1 max data 128(128) link x1(x1) speed 2.5(2.5) ASPM disabled(L0s/L1) cap 11[b0] = MSI-X supports 4 messages, enabled Table in map 0x20[0x0], PBA in map 0x20[0x800] cap 03[d0] = VPD --------------000108060501000308080207-- From owner-freebsd-acpi@FreeBSD.ORG Mon Mar 17 11:06:40 2014 Return-Path: Delivered-To: freebsd-acpi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C4831889 for ; Mon, 17 Mar 2014 11:06:40 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 96033285 for ; Mon, 17 Mar 2014 11:06:40 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.8/8.14.8) with ESMTP id s2HB6eEI011146 for ; Mon, 17 Mar 2014 11:06:40 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.8/8.14.8/Submit) id s2HB6erO011144 for freebsd-acpi@FreeBSD.org; Mon, 17 Mar 2014 11:06:40 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 17 Mar 2014 11:06:40 GMT Message-Id: <201403171106.s2HB6erO011144@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.17 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Mar 2014 11:06:40 -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/187152 acpi [i386] [acpi] resume from ACPI suspend (s3) sometimes o kern/181665 acpi [acpi] System will not go into S3 state. o kern/180897 acpi [acpi] ACPI error with MB p8h67 v.1405 o kern/174766 acpi [acpi] Random acpi panic o kern/174504 acpi [ACPI] Suspend/resume broken on Lenovo x220 o kern/173408 acpi [acpi] [regression] ACPI Regression: battery does not 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/73823 acpi [request] acpi / power-on by timer support 29 problems total. From owner-freebsd-acpi@FreeBSD.ORG Mon Mar 24 11:06:41 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 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B16F7F1C for ; Mon, 24 Mar 2014 11:06:41 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 837F2164 for ; Mon, 24 Mar 2014 11:06:41 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.8/8.14.8) with ESMTP id s2OB6ftD013773 for ; Mon, 24 Mar 2014 11:06:41 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.8/8.14.8/Submit) id s2OB6fdg013771 for freebsd-acpi@FreeBSD.org; Mon, 24 Mar 2014 11:06:41 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 24 Mar 2014 11:06:41 GMT Message-Id: <201403241106.s2OB6fdg013771@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.17 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Mar 2014 11:06:41 -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/187152 acpi [i386] [acpi] resume from ACPI suspend (s3) sometimes o kern/181665 acpi [acpi] System will not go into S3 state. o kern/180897 acpi [acpi] ACPI error with MB p8h67 v.1405 o kern/174766 acpi [acpi] Random acpi panic o kern/174504 acpi [ACPI] Suspend/resume broken on Lenovo x220 o kern/173408 acpi [acpi] [regression] ACPI Regression: battery does not 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/73823 acpi [request] acpi / power-on by timer support 29 problems total. From owner-freebsd-acpi@FreeBSD.ORG Mon Mar 31 11:06:40 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 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 214EF8F9 for ; Mon, 31 Mar 2014 11:06:40 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (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 E8D23B8B for ; Mon, 31 Mar 2014 11:06:39 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.8/8.14.8) with ESMTP id s2VB6d0e058598 for ; Mon, 31 Mar 2014 11:06:39 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.8/8.14.8/Submit) id s2VB6dTq058596 for freebsd-acpi@FreeBSD.org; Mon, 31 Mar 2014 11:06:39 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 31 Mar 2014 11:06:39 GMT Message-Id: <201403311106.s2VB6dTq058596@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.17 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Mar 2014 11:06:40 -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/187152 acpi [i386] [acpi] resume from ACPI suspend (s3) sometimes o kern/181665 acpi [acpi] System will not go into S3 state. o kern/180897 acpi [acpi] ACPI error with MB p8h67 v.1405 o kern/174766 acpi [acpi] Random acpi panic o kern/174504 acpi [ACPI] Suspend/resume broken on Lenovo x220 o kern/173408 acpi [acpi] [regression] ACPI Regression: battery does not 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/73823 acpi [request] acpi / power-on by timer support 29 problems total. From owner-freebsd-acpi@FreeBSD.ORG Mon Apr 7 11:06:39 2014 Return-Path: Delivered-To: freebsd-acpi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9BCA99D1 for ; Mon, 7 Apr 2014 11:06:39 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (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 670F0BE0 for ; Mon, 7 Apr 2014 11:06:39 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.8/8.14.8) with ESMTP id s37B6dl3070958 for ; Mon, 7 Apr 2014 11:06:39 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.8/8.14.8/Submit) id s37B6cbS070956 for freebsd-acpi@FreeBSD.org; Mon, 7 Apr 2014 11:06:38 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 7 Apr 2014 11:06:38 GMT Message-Id: <201404071106.s37B6cbS070956@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.17 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Apr 2014 11:06:39 -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/187152 acpi [i386] [acpi] resume from ACPI suspend (s3) sometimes o kern/181665 acpi [acpi] System will not go into S3 state. o kern/180897 acpi [acpi] ACPI error with MB p8h67 v.1405 o kern/174766 acpi [acpi] Random acpi panic o kern/174504 acpi [ACPI] Suspend/resume broken on Lenovo x220 o kern/173408 acpi [acpi] [regression] ACPI Regression: battery does not 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/73823 acpi [request] acpi / power-on by timer support 29 problems total. From owner-freebsd-acpi@FreeBSD.ORG Wed Apr 9 17:40:33 2014 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7E1981DE for ; Wed, 9 Apr 2014 17:40:33 +0000 (UTC) Received: from mail-ee0-x22f.google.com (mail-ee0-x22f.google.com [IPv6:2a00:1450:4013:c00::22f]) (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 1AE0F16E7 for ; Wed, 9 Apr 2014 17:40:32 +0000 (UTC) Received: by mail-ee0-f47.google.com with SMTP id b15so2161374eek.34 for ; Wed, 09 Apr 2014 10:40:31 -0700 (PDT) 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=aCpa0Gaf9DWX964QMv26rLHQZiWqFqjOkjMa2cDMhEc=; b=Zlbv5F0lbjWArBpGsvR/fq6UJQnRoERo67jHoJGs1WltP4oFGsbgqssX1g4LQX66du vQlmElJSGbD6l2PgUGPOe4RyT0YUGxssHY/QrbMU+IQyeEJmxq8PWQbVrtF82IlyqgP9 kcKYKUKVOy10z/uIrMv+KXgrA2Mgv7cSz6+LH98AG7jCDJS+HMTeji2G1nEHV/k42VQm krEdLabhVWtWkip/KWF9evWFKv/kzZV3E61rXtrYbvTbIkPCOan6VvnbZxW0nYLhbMoG byRKpPTvSmOX0qOfjCeo7xvGtCHXP5p0DuCkN35OjyqNnlB6W2pbMYxA3/Oe2UR0sRdM 6k2g== MIME-Version: 1.0 X-Received: by 10.14.220.130 with SMTP id o2mr13815052eep.42.1397065230565; Wed, 09 Apr 2014 10:40:30 -0700 (PDT) Received: by 10.14.213.194 with HTTP; Wed, 9 Apr 2014 10:40:30 -0700 (PDT) Date: Wed, 9 Apr 2014 10:40:30 -0700 Message-ID: Subject: C-States configuration From: hiren panchasara To: freebsd-acpi@freebsd.org Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Apr 2014 17:40:33 -0000 I am running -current on my T420 at r263906M debug.acpi.acpi_ca_version: 20130823 o/p of sysctl -a | grep acpi - http://bpaste.net/show/199806/ and I have following in my rc.conf: performance_cx_lowest="Cmax" economy_cx_lowest="Cmax" But I still get: % sysctl -a | grep cx_lowest hw.acpi.cpu.cx_lowest: C1 dev.cpu.0.cx_lowest: C1 dev.cpu.1.cx_lowest: C1 dev.cpu.2.cx_lowest: C1 dev.cpu.3.cx_lowest: C1 And I can do: # sysctl dev.cpu.0.cx_lowest=Cmax dev.cpu.0.cx_lowest: C1 -> C8 that tells me that Cmax is C8. % sysctl -d dev.cpu.0.cx_lowest dev.cpu.0.cx_lowest: lowest Cx sleep state to use I was expecting cx_lowest to be set to C8 because of rc.conf config I have. What am I missing here? cheers, Hiren From owner-freebsd-acpi@FreeBSD.ORG Wed Apr 9 18:07:49 2014 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 304F1364 for ; Wed, 9 Apr 2014 18:07:49 +0000 (UTC) Received: from mail-pd0-x231.google.com (mail-pd0-x231.google.com [IPv6:2607:f8b0:400e:c02::231]) (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 08FDD1A5F for ; Wed, 9 Apr 2014 18:07:49 +0000 (UTC) Received: by mail-pd0-f177.google.com with SMTP id y10so2750634pdj.36 for ; Wed, 09 Apr 2014 11:07:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=yXbqKuIzidX9Qp7dwfrhKVnuFMtK5LNh8i7YOHlwDc8=; b=ZJ+j/nvkIjxMyJZaaFLdEr8fJyyJUydbs2HqJQ6bJORW5Fu4tm3WzN6Uo0AIcFZiHY 5UVOppPLw4geb8/Szma70yO45ImcMnzNLcpIml1Rkny8/S3ny8YsPOI6xoOpYBA3EKo4 XkKLZVZTVd8uiDzY1Uz5JiTJryj6ywz0usUZrp5E85HKQYAZOQqTRul09tJP4QzCt/z5 +eWNZqKyixE8oUeWyB1vge4UwCBz0n1W14A0aMG7LAC+0kPau9OqzbeN7c84IBvAuSk6 mZeB5OHBBA+9uMtxL4h4jFuGL2JtpV7mqohRp37YrSzIdqaZGSLe2MJD7najz9MbtygA nizg== X-Received: by 10.68.136.41 with SMTP id px9mr14034808pbb.14.1397066868568; Wed, 09 Apr 2014 11:07:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.70.0.230 with HTTP; Wed, 9 Apr 2014 11:07:28 -0700 (PDT) In-Reply-To: References: From: Anton Sayetsky Date: Wed, 9 Apr 2014 21:07:28 +0300 Message-ID: Subject: Re: C-States configuration To: hiren panchasara Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-acpi@freebsd.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Apr 2014 18:07:49 -0000 2014-04-09 20:40 GMT+03:00 hiren panchasara : > I am running -current on my T420 at r263906M > > debug.acpi.acpi_ca_version: 20130823 > > o/p of sysctl -a | grep acpi - http://bpaste.net/show/199806/ > > and I have following in my rc.conf: > > performance_cx_lowest="Cmax" > economy_cx_lowest="Cmax" > > But I still get: > > % sysctl -a | grep cx_lowest > hw.acpi.cpu.cx_lowest: C1 > dev.cpu.0.cx_lowest: C1 > dev.cpu.1.cx_lowest: C1 > dev.cpu.2.cx_lowest: C1 > dev.cpu.3.cx_lowest: C1 > > And I can do: > # sysctl dev.cpu.0.cx_lowest=Cmax > dev.cpu.0.cx_lowest: C1 -> C8 > > that tells me that Cmax is C8. > > % sysctl -d dev.cpu.0.cx_lowest > dev.cpu.0.cx_lowest: lowest Cx sleep state to use > > I was expecting cx_lowest to be set to C8 because of rc.conf config I have. > > What am I missing here? > > cheers, > Hiren Try to set LOW instead of Cmax. From owner-freebsd-acpi@FreeBSD.ORG Wed Apr 9 18:22:20 2014 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A3560FD2 for ; Wed, 9 Apr 2014 18:22:20 +0000 (UTC) Received: from mail-ee0-x22a.google.com (mail-ee0-x22a.google.com [IPv6:2a00:1450:4013:c00::22a]) (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 3C5B41C69 for ; Wed, 9 Apr 2014 18:22:20 +0000 (UTC) Received: by mail-ee0-f42.google.com with SMTP id d17so2196681eek.29 for ; Wed, 09 Apr 2014 11:22:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=caTNs38Jihi4GvHZNGcfki7c1IEERFWPSBXHYpW4JDw=; b=ot30eI1k1xhwyk0G7uPI7xzVbG0F908EMpPEOVsNyx3KkYdIC1MiRQjNNMn3HRSv77 VUiwXsLkzVgzYvbI7+rmBOaVjfdqV9xLxy0t1NzBip0KzN+IPd4JEppwl4N+gDvIb9OZ XO77+ep9nwFCSc/T7t8UH0DtzlNe5nmUuLiJenbN8TBe2Q+nnxHsY5RTybPBkQybyrzn m2DECnDBlv4xIRYjdhxacgYA9QZVJIXeV3BpwFrnsHNeY5FAnIau2JO8nIvavI1vx4DL TQIahRiA4sUn32oyw1Akajrt9ZiY/T0lGggUcyiYOyvHlYvK5b3F7GAc4tKZYJ3vrtaf NhRw== MIME-Version: 1.0 X-Received: by 10.15.53.135 with SMTP id r7mr354169eew.102.1397067738332; Wed, 09 Apr 2014 11:22:18 -0700 (PDT) Received: by 10.14.213.194 with HTTP; Wed, 9 Apr 2014 11:22:18 -0700 (PDT) In-Reply-To: References: Date: Wed, 9 Apr 2014 11:22:18 -0700 Message-ID: Subject: Re: C-States configuration From: hiren panchasara To: Anton Sayetsky Content-Type: text/plain; charset=UTF-8 Cc: freebsd-acpi@freebsd.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Apr 2014 18:22:20 -0000 On Wed, Apr 9, 2014 at 11:07 AM, Anton Sayetsky wrote: > 2014-04-09 20:40 GMT+03:00 hiren panchasara : >> I am running -current on my T420 at r263906M >> >> debug.acpi.acpi_ca_version: 20130823 >> >> o/p of sysctl -a | grep acpi - http://bpaste.net/show/199806/ >> >> and I have following in my rc.conf: >> >> performance_cx_lowest="Cmax" >> economy_cx_lowest="Cmax" >> >> But I still get: >> >> % sysctl -a | grep cx_lowest >> hw.acpi.cpu.cx_lowest: C1 >> dev.cpu.0.cx_lowest: C1 >> dev.cpu.1.cx_lowest: C1 >> dev.cpu.2.cx_lowest: C1 >> dev.cpu.3.cx_lowest: C1 >> >> And I can do: >> # sysctl dev.cpu.0.cx_lowest=Cmax >> dev.cpu.0.cx_lowest: C1 -> C8 >> >> that tells me that Cmax is C8. >> >> % sysctl -d dev.cpu.0.cx_lowest >> dev.cpu.0.cx_lowest: lowest Cx sleep state to use >> >> I was expecting cx_lowest to be set to C8 because of rc.conf config I have. >> >> What am I missing here? >> >> cheers, >> Hiren > Try to set LOW instead of Cmax. I will try it again. Interestingly enough, on an amd machine, it worked as I expected with a bit more current version of -head but same version of acpica: debug.acpi.acpi_ca_version: 20130823 cpus came up with cx_lowest set to C8 with Cmax in rc.conf cheers, Hiren From owner-freebsd-acpi@FreeBSD.ORG Thu Apr 10 07:18:01 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 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BFC0F23F for ; Thu, 10 Apr 2014 07:18:01 +0000 (UTC) Received: from mail-pd0-x22e.google.com (mail-pd0-x22e.google.com [IPv6:2607:f8b0:400e:c02::22e]) (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 8A7571C62 for ; Thu, 10 Apr 2014 07:18:01 +0000 (UTC) Received: by mail-pd0-f174.google.com with SMTP id y13so3523877pdi.33 for ; Thu, 10 Apr 2014 00:18:01 -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:message-id:subject :from:to:cc:content-type; bh=dHW5LE5vBVC1MF3lLwYeRPeJYVZgOvdYL8WmtwfgdVc=; b=TD579+1Pe0JCauss44uccarQhGmn4hWcxjwQB2ILOPAZASHQsYiKMZyeKcyqhzGEDl ST4G9kQS1j2PNN5XDXTGA478314TNSJ3fuRKGkb2nsJVZyikwUubJ2vPE/LfwVs6bWaV 4SPAljO0Tb4HB1IgiXiCL99mlP8ew45GjV/oPky9IdCxqADHyNTesmUcysRn5Qu/ycR1 wSaKwLLHcPOtE9fOb8NfoPU8v4ItfaL7YFgHyzzrWHi8GaoiDdw236+sRGpQFJNuJO+J 4T42IwXf5CqyePtFwC/bk9ct43knyP+CENUmzeb+LIwKpOw8jj2kHOwFcEZEoDiVyic+ F85w== MIME-Version: 1.0 X-Received: by 10.67.1.106 with SMTP id bf10mr17586356pad.78.1397114281064; Thu, 10 Apr 2014 00:18:01 -0700 (PDT) Sender: kob6558@gmail.com Received: by 10.66.73.34 with HTTP; Thu, 10 Apr 2014 00:18:00 -0700 (PDT) In-Reply-To: References: Date: Thu, 10 Apr 2014 00:18:00 -0700 X-Google-Sender-Auth: OVy9TdutTUD6zdZS_93EvoCTFQo Message-ID: Subject: Re: C-States configuration From: Kevin Oberman To: hiren panchasara Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: "freebsd-acpi@freebsd.org" X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Apr 2014 07:18:01 -0000 On Wed, Apr 9, 2014 at 11:22 AM, hiren panchasara < hiren.panchasara@gmail.com> wrote: > On Wed, Apr 9, 2014 at 11:07 AM, Anton Sayetsky wrote: > > 2014-04-09 20:40 GMT+03:00 hiren panchasara >: > >> I am running -current on my T420 at r263906M > >> > >> debug.acpi.acpi_ca_version: 20130823 > >> > >> o/p of sysctl -a | grep acpi - http://bpaste.net/show/199806/ > >> > >> and I have following in my rc.conf: > >> > >> performance_cx_lowest="Cmax" > >> economy_cx_lowest="Cmax" > >> > >> But I still get: > >> > >> % sysctl -a | grep cx_lowest > >> hw.acpi.cpu.cx_lowest: C1 > >> dev.cpu.0.cx_lowest: C1 > >> dev.cpu.1.cx_lowest: C1 > >> dev.cpu.2.cx_lowest: C1 > >> dev.cpu.3.cx_lowest: C1 > >> > >> And I can do: > >> # sysctl dev.cpu.0.cx_lowest=Cmax > >> dev.cpu.0.cx_lowest: C1 -> C8 > >> > >> that tells me that Cmax is C8. > >> > >> % sysctl -d dev.cpu.0.cx_lowest > >> dev.cpu.0.cx_lowest: lowest Cx sleep state to use > >> > >> I was expecting cx_lowest to be set to C8 because of rc.conf config I > have. > >> > >> What am I missing here? > >> > >> cheers, > >> Hiren > > Try to set LOW instead of Cmax. > > I will try it again. > > Interestingly enough, on an amd machine, it worked as I expected with > a bit more current version of -head but same version of acpica: > debug.acpi.acpi_ca_version: 20130823 > > cpus came up with cx_lowest set to C8 with Cmax in rc.conf > > cheers, > Hiren > Setting Cx values is a bit confusing. Things may not mean what you think. CMax is always C8 because this is the largest possible value of a Cx state, not because C8 is actually available.The reason for this is that some systems have non-sequencial Cx states. That is the maximum value my be C5, but C2 may not be available. So the idea is to allow ANY C-state up to the maximum. LOWEST works well as long as no states are skipped. If they are, you are limited to the states before the skipped state. To see the actual available states, look at dev.cpu.0.cx_supported. The recommended value for best power savings is :Cmax. That will allow skipping over missing C-states. Also, the available states often differ between AC power and battery. On my T320: AC dev.cpu.0.cx_supported: C1/1/1 C2/3/104 Battery dev.cpu.0.cx_supported: C1/1/1 C2/2/80 C3/3/109 I am unsure why you are only seeing C1. -- R. Kevin Oberman, Network Engineer, Retired E-mail: rkoberman@gmail.com From owner-freebsd-acpi@FreeBSD.ORG Fri Apr 11 07:22:46 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 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 379F9922 for ; Fri, 11 Apr 2014 07:22:46 +0000 (UTC) Received: from mail-ee0-x231.google.com (mail-ee0-x231.google.com [IPv6:2a00:1450:4013:c00::231]) (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 C2EB1107E for ; Fri, 11 Apr 2014 07:22:45 +0000 (UTC) Received: by mail-ee0-f49.google.com with SMTP id c41so3721204eek.8 for ; Fri, 11 Apr 2014 00:22:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=WvW+WVYwQaxFVIlfiKKsIDX76W84+aj0FY4c+voJGZo=; b=gp8N220QwJPx1eQhGeJMn5wQ95O01XPqTLLvELj783GjJqvrROq/ZPaOdBrxiBF2P5 H9++z/VwnVERrE63DXhtTa414T1ps9T1z3gB4uw6fS2hQpr51RPIG57N5o3IzzzlkK80 gGxILZiVny+ISN5HCa+P59Pu8daAOUZB+QxmsO6f5n4DCQuAemIbZZ0jksRtMY54mtfP i9C9NHiQXq4PXJZATo7bbdAQ8b64U88Qhbz/KZ3YSNvaX0qYZ7XLhcWQXB3cvpph2E+n h58tu8+FfQmaaR53mxRmlq0kZTFxgTUGd+n1CrDrAwXVlaYlrLBYM10U3LJkcui5WuR9 9lww== MIME-Version: 1.0 X-Received: by 10.15.32.206 with SMTP id a54mr26694891eev.51.1397200963923; Fri, 11 Apr 2014 00:22:43 -0700 (PDT) Received: by 10.14.213.194 with HTTP; Fri, 11 Apr 2014 00:22:43 -0700 (PDT) In-Reply-To: References: Date: Fri, 11 Apr 2014 00:22:43 -0700 Message-ID: Subject: Re: C-States configuration From: hiren panchasara To: Kevin Oberman Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-acpi@freebsd.org" X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Apr 2014 07:22:46 -0000 On Thu, Apr 10, 2014 at 12:18 AM, Kevin Oberman wrote: > On Wed, Apr 9, 2014 at 11:22 AM, hiren panchasara > wrote: >> >> On Wed, Apr 9, 2014 at 11:07 AM, Anton Sayetsky wrote: >> > 2014-04-09 20:40 GMT+03:00 hiren panchasara >> > : >> >> I am running -current on my T420 at r263906M >> >> >> >> debug.acpi.acpi_ca_version: 20130823 >> >> >> >> o/p of sysctl -a | grep acpi - http://bpaste.net/show/199806/ >> >> >> >> and I have following in my rc.conf: >> >> >> >> performance_cx_lowest="Cmax" >> >> economy_cx_lowest="Cmax" >> >> >> >> But I still get: >> >> >> >> % sysctl -a | grep cx_lowest >> >> hw.acpi.cpu.cx_lowest: C1 >> >> dev.cpu.0.cx_lowest: C1 >> >> dev.cpu.1.cx_lowest: C1 >> >> dev.cpu.2.cx_lowest: C1 >> >> dev.cpu.3.cx_lowest: C1 >> >> >> >> And I can do: >> >> # sysctl dev.cpu.0.cx_lowest=Cmax >> >> dev.cpu.0.cx_lowest: C1 -> C8 >> >> >> >> that tells me that Cmax is C8. >> >> >> >> % sysctl -d dev.cpu.0.cx_lowest >> >> dev.cpu.0.cx_lowest: lowest Cx sleep state to use >> >> >> >> I was expecting cx_lowest to be set to C8 because of rc.conf config I >> >> have. >> >> >> >> What am I missing here? >> >> >> >> cheers, >> >> Hiren >> > Try to set LOW instead of Cmax. >> >> I will try it again. >> >> Interestingly enough, on an amd machine, it worked as I expected with >> a bit more current version of -head but same version of acpica: >> debug.acpi.acpi_ca_version: 20130823 >> >> cpus came up with cx_lowest set to C8 with Cmax in rc.conf >> >> cheers, >> Hiren > > > Setting Cx values is a bit confusing. Things may not mean what you think. > CMax is always C8 because this is the largest possible value of a Cx state, > not because C8 is actually available.The reason for this is that some > systems have non-sequencial Cx states. That is the maximum value my be C5, > but C2 may not be available. So the idea is to allow ANY C-state up to the > maximum. LOWEST works well as long as no states are skipped. If they are, > you are limited to the states before the skipped state. > > To see the actual available states, look at dev.cpu.0.cx_supported. > > The recommended value for best power savings is :Cmax. That will allow > skipping over missing C-states. Also, the available states often differ > between AC power and battery. On my T320: > AC dev.cpu.0.cx_supported: C1/1/1 C2/3/104 > Battery dev.cpu.0.cx_supported: C1/1/1 C2/2/80 C3/3/109 AC: hw.acpi.cpu.cx_lowest: C8 dev.cpu.0.cx_supported: C1/1/1 C2/3/104 dev.cpu.0.cx_lowest: C8 dev.cpu.0.cx_usage: 8.23% 91.76% last 38us Battery: hw.acpi.cpu.cx_lowest: C8 dev.cpu.0.cx_supported: C1/1/1 C2/2/80 C3/3/109 dev.cpu.0.cx_lowest: C8 dev.cpu.0.cx_usage: 12.35% 3.22% 84.42% last 3088us So, pretty similar on my T420 with following in rc.conf performance_cx_lowest="Cmax" economy_cx_lowest="Cmax" How do I know what C-state cpu0 is in, at any point in time? Or thats not how things work? cheers, Hiren From owner-freebsd-acpi@FreeBSD.ORG Fri Apr 11 08:31:13 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 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id ACBAD762 for ; Fri, 11 Apr 2014 08:31:13 +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 186F3179C for ; Fri, 11 Apr 2014 08:31:12 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id s3B8V880001091; Fri, 11 Apr 2014 18:31:08 +1000 (EST) (envelope-from smithi@nimnet.asn.au) Date: Fri, 11 Apr 2014 18:31:08 +1000 (EST) From: Ian Smith To: hiren panchasara Subject: Re: C-States configuration In-Reply-To: Message-ID: <20140411180645.I66326@sola.nimnet.asn.au> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: Kevin Oberman , "freebsd-acpi@freebsd.org" X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Apr 2014 08:31:13 -0000 On Fri, 11 Apr 2014 00:22:43 -0700, hiren panchasara wrote: > On Thu, Apr 10, 2014 at 12:18 AM, Kevin Oberman wrote: > > On Wed, Apr 9, 2014 at 11:22 AM, hiren panchasara > > wrote: > >> > >> On Wed, Apr 9, 2014 at 11:07 AM, Anton Sayetsky wrote: > >> > 2014-04-09 20:40 GMT+03:00 hiren panchasara > >> > : > >> >> I am running -current on my T420 at r263906M > >> >> > >> >> debug.acpi.acpi_ca_version: 20130823 > >> >> > >> >> o/p of sysctl -a | grep acpi - http://bpaste.net/show/199806/ > >> >> > >> >> and I have following in my rc.conf: > >> >> > >> >> performance_cx_lowest="Cmax" > >> >> economy_cx_lowest="Cmax" > >> >> > >> >> But I still get: > >> >> > >> >> % sysctl -a | grep cx_lowest > >> >> hw.acpi.cpu.cx_lowest: C1 > >> >> dev.cpu.0.cx_lowest: C1 > >> >> dev.cpu.1.cx_lowest: C1 > >> >> dev.cpu.2.cx_lowest: C1 > >> >> dev.cpu.3.cx_lowest: C1 > >> >> > >> >> And I can do: > >> >> # sysctl dev.cpu.0.cx_lowest=Cmax > >> >> dev.cpu.0.cx_lowest: C1 -> C8 > >> >> > >> >> that tells me that Cmax is C8. > >> >> > >> >> % sysctl -d dev.cpu.0.cx_lowest > >> >> dev.cpu.0.cx_lowest: lowest Cx sleep state to use > >> >> > >> >> I was expecting cx_lowest to be set to C8 because of rc.conf config I > >> >> have. > >> >> > >> >> What am I missing here? > >> >> > >> >> cheers, > >> >> Hiren > >> > Try to set LOW instead of Cmax. > >> > >> I will try it again. > >> > >> Interestingly enough, on an amd machine, it worked as I expected with > >> a bit more current version of -head but same version of acpica: > >> debug.acpi.acpi_ca_version: 20130823 > >> > >> cpus came up with cx_lowest set to C8 with Cmax in rc.conf > >> > >> cheers, > >> Hiren > > > > > > Setting Cx values is a bit confusing. Things may not mean what you think. > > CMax is always C8 because this is the largest possible value of a Cx state, > > not because C8 is actually available.The reason for this is that some > > systems have non-sequencial Cx states. That is the maximum value my be C5, > > but C2 may not be available. So the idea is to allow ANY C-state up to the > > maximum. LOWEST works well as long as no states are skipped. If they are, > > you are limited to the states before the skipped state. > > > > To see the actual available states, look at dev.cpu.0.cx_supported. > > > > The recommended value for best power savings is :Cmax. That will allow > > skipping over missing C-states. Also, the available states often differ > > between AC power and battery. On my T320: > > AC dev.cpu.0.cx_supported: C1/1/1 C2/3/104 > > Battery dev.cpu.0.cx_supported: C1/1/1 C2/2/80 C3/3/109 > > AC: > hw.acpi.cpu.cx_lowest: C8 > dev.cpu.0.cx_supported: C1/1/1 C2/3/104 > dev.cpu.0.cx_lowest: C8 > dev.cpu.0.cx_usage: 8.23% 91.76% last 38us > > Battery: > hw.acpi.cpu.cx_lowest: C8 > dev.cpu.0.cx_supported: C1/1/1 C2/2/80 C3/3/109 > dev.cpu.0.cx_lowest: C8 > dev.cpu.0.cx_usage: 12.35% 3.22% 84.42% last 3088us > > So, pretty similar on my T420 with following in rc.conf > performance_cx_lowest="Cmax" > economy_cx_lowest="Cmax" > > How do I know what C-state cpu0 is in, at any point in time? Or thats > not how things work? smithi@x200:~ % x200stat Fri Apr 11 18:24:19 EST 2014 dev.cpu.0.freq: 200 0.00% 2.47% 97.51% last 520us 0.01% 2.22% 97.75% last 817us dev.acpi_ibm.0.fan_speed: 3391 dev.acpi_ibm.0.fan_level: 0 dev.acpi_ibm.0.thermal: 40 44 -1 41 36 -1 35 -1 hw.acpi.thermal.tz0.temperature: 40.0C hw.acpi.thermal.tz1.temperature: 36.0C State: high Remaining capacity: 96% Remaining time: unknown Present rate: 0 mW Present voltage: 12329 mV I'm not sure that 'at any point in time' could be very meaningful. The above shows sysctl -n dev.cpu.0.cx_usage & sysctl -n dev.cpu.1.cx_usage at one time - or rather at the two relativelty close times that each of those sysctls was retrieved, both covering less than 1ms. Heisenberg's Uncertainty Principle would most likely apply to any closer examination, but you could chase down where the statistics are accumulated, somewhere in cpufreq IIRC. cheers, Ian From owner-freebsd-acpi@FreeBSD.ORG Fri Apr 11 19:12:44 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 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AFB97EA8; Fri, 11 Apr 2014 19:12:44 +0000 (UTC) Received: from mail.ignoranthack.me (ujvl.x.rootbsd.net [199.102.79.106]) (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 887771285; Fri, 11 Apr 2014 19:12:44 +0000 (UTC) Received: from [10.73.160.242] (nat-dip7.cfw-a-gci.corp.yahoo.com [209.131.62.116]) (using SSLv3 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: sbruno@ignoranthack.me) by mail.ignoranthack.me (Postfix) with ESMTPSA id EE48B1929A9; Fri, 11 Apr 2014 19:12:42 +0000 (UTC) Subject: Re: IPMI is broken on Intel S1200RP Board From: Sean Bruno To: Vladimir Laskov In-Reply-To: References: <1397156847.1088.11.camel@powernoodle.corp.yahoo.com> <1397232539.1434.6.camel@powernoodle.corp.yahoo.com> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-5ATc6oB1mGJBQaFyjVCK" Date: Fri, 11 Apr 2014 12:12:41 -0700 Message-ID: <1397243561.1434.74.camel@powernoodle.corp.yahoo.com> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Cc: freebsd-acpi X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: sbruno@freebsd.org List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Apr 2014 19:12:44 -0000 --=-5ATc6oB1mGJBQaFyjVCK Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, 2014-04-11 at 22:42 +0400, Vladimir Laskov wrote: >=20 >=20 > links > https://bitbucket.org/weec/docs/downloads/dmesg_verbose_boot.log > https://bitbucket.org/weec/docs/downloads/intel_s1200rp.dsdt >=20 >=20 Wanted to xpost this over to freebsd-acpi too. Since it looks to me that the IPMI driver isn't getting invoked, I assume that its because of a variance in ACPI parsing of the relevant IPMI section. sean >=20 > On Fri, Apr 11, 2014 at 8:08 PM, Sean Bruno > wrote: > On Fri, 2014-04-11 at 07:47 +0400, venom wrote: > > ppc1: cannot reserve I/O port range > > pcib0: allocated type 4 (0x60-0x60) for rid 0 of atkbdc0 > > pcib0: allocated type 4 (0x64-0x64) for rid 1 of atkbdc0 > > atkbdc0: AT keyboard controller not found > > pcib0: allocated type 4 (0x3f0-0x3f5) for rid 0 of fdc0 > > pcib0: allocated type 4 (0x3f7-0x3f7) for rid 1 of fdc0 > > ppc0: cannot reserve I/O port range > > pci0: driver added > > found-> vendor=3D0x8086, dev=3D0x8c22, revid=3D0x05 > > domain=3D0, bus=3D0, slot=3D31, func=3D3 > > class=3D0c-05-00, hdrtype=3D0x00, mfdev=3D0 > > cmdreg=3D0x0143, statreg=3D0x0280, cachelnsz=3D0 (dwords) > > lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 = ns) > > intpin=3Dc, irq=3D18 > > pci0:0:31:3: reprobing on driver added > > found-> vendor=3D0x8086, dev=3D0x8c24, revid=3D0x05 > > domain=3D0, bus=3D0, slot=3D31, func=3D6 > > class=3D11-80-00, hdrtype=3D0x00, mfdev=3D0 > > cmdreg=3D0x0006, statreg=3D0x0010, cachelnsz=3D0 (dwords) > > lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 = ns) > > intpin=3Dc, irq=3D18 > > powerspec 3 supports D0 D3 current D0 > > MSI supports 1 message > > pci0:0:31:6: reprobing on driver added > > pci1: driver added > > pci2: driver added > > pci0: driver added > > found-> vendor=3D0x8086, dev=3D0x8c22, revid=3D0x05 > > domain=3D0, bus=3D0, slot=3D31, func=3D3 > > class=3D0c-05-00, hdrtype=3D0x00, mfdev=3D0 > > cmdreg=3D0x0143, statreg=3D0x0280, cachelnsz=3D0 (dwords) > > lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 = ns) > > intpin=3Dc, irq=3D18 > > pci0:0:31:3: reprobing on driver added > > found-> vendor=3D0x8086, dev=3D0x8c24, revid=3D0x05 > > domain=3D0, bus=3D0, slot=3D31, func=3D6 > > class=3D11-80-00, hdrtype=3D0x00, mfdev=3D0 > > cmdreg=3D0x0006, statreg=3D0x0010, cachelnsz=3D0 (dwords) > > lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 = ns) > > intpin=3Dc, irq=3D18 > > powerspec 3 supports D0 D3 current D0 > > MSI supports 1 message > > pci0:0:31:6: reprobing on driver added > > pci1: driver added > > pci2: driver added > > > =20 > =20 > =20 > I don't see an attach here, so I assume that something is > "new" in the > acpi tables on this board. Can you dump the ACPI table > somewhere > "acpidump -dt > intel_s1200rp.dsdt" and post it somewhere we > can look at > it? > =20 > freebsd.org mailing lists will strip attachments in most > cases, so a > pastebin or other link would be best. > =20 > sean > =20 >=20 >=20 --=-5ATc6oB1mGJBQaFyjVCK Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAABAgAGBQJTSD6pAAoJEBkJRdwI6BaHT+cH/3OHljDlIC8a5bskisdpkJAT WoF5pLf8vL9cN5ifapbiKkLhoQJzg2biYnsj7LegI0/s1esRiHCgvvUbOVQ/Kn7t /7UioyW0hbQQKN1mpUEwRpAcg5ZTHvYI93VhebzQF0O65/WUqeNyp0etfS5HzCZG sFjjuQGNICMZZUkBxP4915Ac1yUwTRdAIeTRcYs1z5iy94h4GJMSywEnDxDxXLUF JSOEXwCwbFJ3UEZXVw16L8YaFh3WZjrTZsSQhTA5+H2zCLxKWmtuVgiASan40NdY GI4KkTmo5sNM7rRiqNxgljDs2PzeVl4ino9MZDgmA106XB/giOwYXrgN4CuDHqQ= =+8+F -----END PGP SIGNATURE----- --=-5ATc6oB1mGJBQaFyjVCK-- From owner-freebsd-acpi@FreeBSD.ORG Fri Apr 11 19:16:24 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 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B28A2F34 for ; Fri, 11 Apr 2014 19:16:24 +0000 (UTC) Received: from mail-pd0-x233.google.com (mail-pd0-x233.google.com [IPv6:2607:f8b0:400e:c02::233]) (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 821E312B3 for ; Fri, 11 Apr 2014 19:16:24 +0000 (UTC) Received: by mail-pd0-f179.google.com with SMTP id w10so5683959pde.10 for ; Fri, 11 Apr 2014 12:16:24 -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:message-id:subject :from:to:cc:content-type; bh=3IE0SFcdSjvFVEyA4howrVjdKcOSLsygGWNWU6e2p4I=; b=sxCkHc3lt4gjZ00mxz6DXTpE59S8yt3Z7ajVs7lalQaJXHzfklbnMrLqbr6LPkvYX+ lX8T9AE926hKRhtq6qIlmn3oYj9ruzAm4eHiBx5aNEatCN6ud61aPRGnhJTVfOtM40hM +eyYU0L/fJbh74KcR9KSLXO7EnU06XE4iI1DHkpeEggH+2H5nlQjU8zChIiLnQmFjJF/ p+OH/jLYtNe3xpe9EHiClIG+TJ2JBur81YoR6TxDom20TrObr2qFqDNuwy3UFvKt2MTo D1yHLKNgfu5M8Auhc1o72gHfC9wRxbmMNDUNToVz8AMwyH1j7UkPL+lzIhxXYZE/Y0Bh PLiw== MIME-Version: 1.0 X-Received: by 10.66.227.193 with SMTP id sc1mr29522756pac.102.1397243784032; Fri, 11 Apr 2014 12:16:24 -0700 (PDT) Sender: kob6558@gmail.com Received: by 10.66.73.34 with HTTP; Fri, 11 Apr 2014 12:16:23 -0700 (PDT) In-Reply-To: <20140411180645.I66326@sola.nimnet.asn.au> References: <20140411180645.I66326@sola.nimnet.asn.au> Date: Fri, 11 Apr 2014 12:16:23 -0700 X-Google-Sender-Auth: dcGHAcKK6oCfizxxWeiffDLdLRg Message-ID: Subject: Re: C-States configuration From: Kevin Oberman To: Ian Smith Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: "freebsd-acpi@freebsd.org" X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Apr 2014 19:16:24 -0000 On Fri, Apr 11, 2014 at 1:31 AM, Ian Smith wrote: > On Fri, 11 Apr 2014 00:22:43 -0700, hiren panchasara wrote: > > On Thu, Apr 10, 2014 at 12:18 AM, Kevin Oberman > wrote: > > > On Wed, Apr 9, 2014 at 11:22 AM, hiren panchasara > > > wrote: > > >> > > >> On Wed, Apr 9, 2014 at 11:07 AM, Anton Sayetsky > wrote: > > >> > 2014-04-09 20:40 GMT+03:00 hiren panchasara > > >> > : > > >> >> I am running -current on my T420 at r263906M > > >> >> > > >> >> debug.acpi.acpi_ca_version: 20130823 > > >> >> > > >> >> o/p of sysctl -a | grep acpi - http://bpaste.net/show/199806/ > > >> >> > > >> >> and I have following in my rc.conf: > > >> >> > > >> >> performance_cx_lowest="Cmax" > > >> >> economy_cx_lowest="Cmax" > > >> >> > > >> >> But I still get: > > >> >> > > >> >> % sysctl -a | grep cx_lowest > > >> >> hw.acpi.cpu.cx_lowest: C1 > > >> >> dev.cpu.0.cx_lowest: C1 > > >> >> dev.cpu.1.cx_lowest: C1 > > >> >> dev.cpu.2.cx_lowest: C1 > > >> >> dev.cpu.3.cx_lowest: C1 > > >> >> > > >> >> And I can do: > > >> >> # sysctl dev.cpu.0.cx_lowest=Cmax > > >> >> dev.cpu.0.cx_lowest: C1 -> C8 > > >> >> > > >> >> that tells me that Cmax is C8. > > >> >> > > >> >> % sysctl -d dev.cpu.0.cx_lowest > > >> >> dev.cpu.0.cx_lowest: lowest Cx sleep state to use > > >> >> > > >> >> I was expecting cx_lowest to be set to C8 because of rc.conf > config I > > >> >> have. > > >> >> > > >> >> What am I missing here? > > >> >> > > >> >> cheers, > > >> >> Hiren > > >> > Try to set LOW instead of Cmax. > > >> > > >> I will try it again. > > >> > > >> Interestingly enough, on an amd machine, it worked as I expected with > > >> a bit more current version of -head but same version of acpica: > > >> debug.acpi.acpi_ca_version: 20130823 > > >> > > >> cpus came up with cx_lowest set to C8 with Cmax in rc.conf > > >> > > >> cheers, > > >> Hiren > > > > > > > > > Setting Cx values is a bit confusing. Things may not mean what you > think. > > > CMax is always C8 because this is the largest possible value of a Cx > state, > > > not because C8 is actually available.The reason for this is that some > > > systems have non-sequencial Cx states. That is the maximum value my > be C5, > > > but C2 may not be available. So the idea is to allow ANY C-state up > to the > > > maximum. LOWEST works well as long as no states are skipped. If they > are, > > > you are limited to the states before the skipped state. > > > > > > To see the actual available states, look at dev.cpu.0.cx_supported. > > > > > > The recommended value for best power savings is :Cmax. That will allow > > > skipping over missing C-states. Also, the available states often > differ > > > between AC power and battery. On my T320: > > > AC dev.cpu.0.cx_supported: C1/1/1 C2/3/104 > > > Battery dev.cpu.0.cx_supported: C1/1/1 C2/2/80 C3/3/109 > > > > AC: > > hw.acpi.cpu.cx_lowest: C8 > > dev.cpu.0.cx_supported: C1/1/1 C2/3/104 > > dev.cpu.0.cx_lowest: C8 > > dev.cpu.0.cx_usage: 8.23% 91.76% last 38us > > > > Battery: > > hw.acpi.cpu.cx_lowest: C8 > > dev.cpu.0.cx_supported: C1/1/1 C2/2/80 C3/3/109 > > dev.cpu.0.cx_lowest: C8 > > dev.cpu.0.cx_usage: 12.35% 3.22% 84.42% last 3088us > > > > So, pretty similar on my T420 with following in rc.conf > > performance_cx_lowest="Cmax" > > economy_cx_lowest="Cmax" > > > > How do I know what C-state cpu0 is in, at any point in time? Or thats > > not how things work? > > smithi@x200:~ % x200stat > Fri Apr 11 18:24:19 EST 2014 dev.cpu.0.freq: 200 > 0.00% 2.47% 97.51% last 520us > 0.01% 2.22% 97.75% last 817us > dev.acpi_ibm.0.fan_speed: 3391 > dev.acpi_ibm.0.fan_level: 0 > dev.acpi_ibm.0.thermal: 40 44 -1 41 36 -1 35 -1 > hw.acpi.thermal.tz0.temperature: 40.0C > hw.acpi.thermal.tz1.temperature: 36.0C > State: high > Remaining capacity: 96% > Remaining time: unknown > Present rate: 0 mW > Present voltage: 12329 mV > > I'm not sure that 'at any point in time' could be very meaningful. The > above shows sysctl -n dev.cpu.0.cx_usage & sysctl -n dev.cpu.1.cx_usage > at one time - or rather at the two relativelty close times that each of > those sysctls was retrieved, both covering less than 1ms. Heisenberg's > Uncertainty Principle would most likely apply to any closer examination, > but you could chase down where the statistics are accumulated, somewhere > in cpufreq IIRC. > Since hte state changes very quickly and quite often, I agree with Ian. Don't know hat I can quite attribute it ti Heisengerg, but I can agree that trying ot look at it will distort the results, probably significantly. the fact that it is reported over times of less than 10 ms makes it clear that this changes a LOT. Adrian Chadd posted a patch to count the changes. Here is what I see after 10 seconds while quiescent: > sysctl dev.cpu.0 | grep usage dev.cpu.0.cx_usage: 8.43% 2.51% 89.05% last 1761us dev.cpu.0.cx_usage_counters: 121 36 1277 And while compiling wxgtk (i.e. the CPUs are all at near 100%): sysctl dev.cpu.0 | grep usage dev.cpu.0.cx_usage: 100.00% 0.00% 0.00% last 117us dev.cpu.0.cx_usage_counters: 7 0 0 As you can see, the CPU is only occasionally halted while the compile is going on and never long enough to get past C1. When "idle" it is spending almost 90% of it's time is deep sleep (C3) and there are far more times when the CPU is halted, 1433 vs. 7. -- R. Kevin Oberman, Network Engineer, Retired E-mail: rkoberman@gmail.com From owner-freebsd-acpi@FreeBSD.ORG Mon Apr 14 11:06:40 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 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D9986E6A for ; Mon, 14 Apr 2014 11:06:40 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (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 A5691164C for ; Mon, 14 Apr 2014 11:06:40 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.8/8.14.8) with ESMTP id s3EB6e5k025776 for ; Mon, 14 Apr 2014 11:06:40 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.8/8.14.8/Submit) id s3EB6euB025774 for freebsd-acpi@FreeBSD.org; Mon, 14 Apr 2014 11:06:40 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 14 Apr 2014 11:06:40 GMT Message-Id: <201404141106.s3EB6euB025774@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.17 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Apr 2014 11:06:40 -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/187152 acpi [i386] [acpi] resume from ACPI suspend (s3) sometimes o kern/181665 acpi [acpi] System will not go into S3 state. o kern/180897 acpi [acpi] ACPI error with MB p8h67 v.1405 o kern/174766 acpi [acpi] Random acpi panic o kern/174504 acpi [ACPI] Suspend/resume broken on Lenovo x220 o kern/173408 acpi [acpi] [regression] ACPI Regression: battery does not 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/73823 acpi [request] acpi / power-on by timer support 29 problems total. From owner-freebsd-acpi@FreeBSD.ORG Thu Apr 17 04:26:50 2014 Return-Path: Delivered-To: freebsd-acpi@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E2F6334B; Thu, 17 Apr 2014 04:26:50 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (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 B7D121084; Thu, 17 Apr 2014 04:26:50 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.8/8.14.8) with ESMTP id s3H4QoVQ060927; Thu, 17 Apr 2014 04:26:50 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.8/8.14.8/Submit) id s3H4QoaU060926; Thu, 17 Apr 2014 04:26:50 GMT (envelope-from linimon) Date: Thu, 17 Apr 2014 04:26:50 GMT Message-Id: <201404170426.s3H4QoaU060926@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-acpi@FreeBSD.org From: linimon@FreeBSD.org Subject: Re: kern/173414: [acpi] ACPI battery time incorrect X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Apr 2014 04:26:51 -0000 Old Synopsis: ACPI battery time incorrect New Synopsis: [acpi] ACPI battery time incorrect Responsible-Changed-From-To: freebsd-bugs->freebsd-acpi Responsible-Changed-By: linimon Responsible-Changed-When: Thu Apr 17 04:26:23 UTC 2014 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=173414 From owner-freebsd-acpi@FreeBSD.ORG Thu Apr 17 05:20:01 2014 Return-Path: Delivered-To: freebsd-acpi@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3B8D2C0F for ; Thu, 17 Apr 2014 05:20:01 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (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 1A6E7147A for ; Thu, 17 Apr 2014 05:20:01 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.8/8.14.8) with ESMTP id s3H5K0NG079944 for ; Thu, 17 Apr 2014 05:20:00 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.8/8.14.8/Submit) id s3H5K02i079943; Thu, 17 Apr 2014 05:20:00 GMT (envelope-from gnats) Date: Thu, 17 Apr 2014 05:20:00 GMT Message-Id: <201404170520.s3H5K02i079943@freefall.freebsd.org> To: freebsd-acpi@FreeBSD.org Cc: From: Kevin Oberman Subject: Re: kern/173414: [acpi] ACPI battery time incorrect X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Kevin Oberman List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Apr 2014 05:20:01 -0000 The following reply was made to PR kern/173414; it has been noted by GNATS. From: Kevin Oberman To: bug-followup@FreeBSD.org, jb.1234abcd@gmail.com Cc: Subject: Re: kern/173414: [acpi] ACPI battery time incorrect Date: Wed, 16 Apr 2014 22:11:16 -0700 --047d7b10cf8b0fcbe604f736106a Content-Type: text/plain; charset=UTF-8 Im most systems, ACPI does not return the battery lifetime when on AC power. The actual remaining time is calculated by the EC BIOS and is calculated mostly be taking the discharge rate in mW and the current capacity in mWh. As far as I know, no OS attempts to calculate the time. It is simply read from the the EC via ACPI. When plugged in to AC, the discharge rate is 0, making the calculation undefined (division by zero). Even the remaining battery time reported by ACPI is, at best, a very rough guess as discharge rate can vary dramatically depending on system load. On FreeBSD you can see detailed information on batteries with the acpiconf(8) command. "acpiconf -i N" where 'N' is the battery number; 0 if only one battery is present. My system on battery: esign capacity: 50540 mWh Last full capacity: 46660 mWh Technology: secondary (rechargeable) Design voltage: 10800 mV Capacity (warn): 2333 mWh Capacity (low): 200 mWh Low/warn granularity: 1 mWh Warn/full granularity: 1 mWh Model number: 42T4795 Serial number: 2654 Type: LION OEM info: SONY State: discharging Remaining capacity: 96% Remaining time: 2:12 Present rate: 20460 mW Present voltage: 11652 mV And after plugging in to AC: Design capacity: 50540 mWh Last full capacity: 46660 mWh Technology: secondary (rechargeable) Design voltage: 10800 mV Capacity (warn): 2333 mWh Capacity (low): 200 mWh Low/warn granularity: 1 mWh Warn/full granularity: 1 mWh Model number: 42T4795 Serial number: 2654 Type: LION OEM info: SONY State: high Remaining capacity: 96% Remaining time: unknown Present rate: 0 mW Present voltage: 11648 mV Looking at the raw sysctl when on battery shows hw.acpi.battery.time: -1. This is normal. I don't see that ACPI -- R. Kevin Oberman, Network Engineer, Retired E-mail: rkoberman@gmail.com --047d7b10cf8b0fcbe604f736106a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Im most systems, ACPI does not return = the battery lifetime when on AC power. The actual remaining time is calcula= ted by the EC BIOS and is calculated mostly be taking the discharge rate in= mW and the current capacity in mWh. As far as I know, no OS attempts to ca= lculate the time. It is simply read from the the EC via ACPI. When plugged = in to AC, the discharge rate is 0, making the calculation undefined (divisi= on by zero). Even the remaining battery time reported by ACPI is, at best, = a very rough guess as discharge rate can vary dramatically depending on sys= tem load.

On FreeBSD you can see detailed information on batteries with the= acpiconf(8) command. "acpiconf -i N" where 'N' is the ba= ttery number; 0 if only one battery is present.
My system on batte= ry:
esign capacity:=C2=A0=C2=A0=C2=A0 50540 mWh
Last full capacity:=C2=A0=C2= =A0=C2=A0 46660 mWh
Technology:=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 sec= ondary (rechargeable)
Design voltage:=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2= =A0 10800 mV
Capacity (warn):=C2=A0=C2=A0=C2=A0 2333 mWh
Capacity (lo= w):=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 200 mWh
Low/warn granularity:= =C2=A0=C2=A0=C2=A0 1 mWh
Warn/full granularity:=C2=A0=C2=A0=C2=A0 1 mWh
Model number:=C2=A0=C2=A0= =C2=A0 =C2=A0=C2=A0=C2=A0 42T4795
Serial number:=C2=A0=C2=A0=C2=A0 =C2= =A0=C2=A0=C2=A0 =C2=A02654
Type:=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 = =C2=A0=C2=A0=C2=A0 LION
OEM info:=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 S= ONY
State:=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 disch= arging
Remaining capacity:=C2=A0=C2=A0=C2=A0 96%
Remaining time:=C2= =A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 2:12
Present rate:=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 20460 mW
Present volt= age:=C2=A0=C2=A0=C2=A0 11652 mV

And after plugging in to AC:Design capacity:=C2=A0=C2=A0=C2=A0 50540 mWh
Last full capacity:=C2=A0= =C2=A0=C2=A0 46660 mWh
Technology:=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 = secondary (rechargeable)
Design voltage:=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 10800 mV
Capacity (= warn):=C2=A0=C2=A0=C2=A0 2333 mWh
Capacity (low):=C2=A0=C2=A0=C2=A0 =C2= =A0=C2=A0=C2=A0 200 mWh
Low/warn granularity:=C2=A0=C2=A0=C2=A0 1 mWhWarn/full granularity:=C2=A0=C2=A0=C2=A0 1 mWh
Model number:=C2=A0=C2= =A0=C2=A0 =C2=A0=C2=A0=C2=A0 42T4795
Serial number:=C2=A0=C2=A0=C2=A0 = =C2=A0=C2=A0=C2=A0 =C2=A02654
Type:=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 LION
OEM i= nfo:=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 SONY
State:=C2=A0=C2=A0=C2=A0 = =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 high
Remaining capacity:=C2=A0=C2= =A0=C2=A0 96%
Remaining time:=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 unkno= wn
Present rate:=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 0 mW
Present vo= ltage:=C2=A0=C2=A0=C2=A0 11648 mV

Looking at the raw sysctl wh= en on battery shows hw.acpi.battery.time: -1. This is normal. I don't s= ee that ACPI
--
R. Kevin Oberman, Network = Engineer, Retired
E-mail: rkoberman@gmail.com
--047d7b10cf8b0fcbe604f736106a-- From owner-freebsd-acpi@FreeBSD.ORG Sat Apr 19 21:15:04 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 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 653198DA for ; Sat, 19 Apr 2014 21:15:04 +0000 (UTC) Received: from mail-we0-x236.google.com (mail-we0-x236.google.com [IPv6:2a00:1450:400c:c03::236]) (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 A38E21094 for ; Sat, 19 Apr 2014 21:15:03 +0000 (UTC) Received: by mail-we0-f182.google.com with SMTP id p61so2635688wes.13 for ; Sat, 19 Apr 2014 14:15:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=gwRQSwdHPQvUzDMIMxy9u6kyHRZmsrFz0XdN15EJD/c=; b=ZAWqy0lBDUY1k2gmUKfBRzPegyoxeU3vjMkGHMe8PaXbB3qVM9ojJLVutyMzSyv5Xu PjA9kouGp/tFxfaZ76xeJLdjHjdNsIkZnIpdXkBTwD+GgorL9LlWXgqe4ftpVrUm9DLL k2VwpAFGgvuW7JTlPgCTpu4pZ/vyDhxosheTeOL2T9N1GTZeI2MfYffkT08ilsBW5mxJ QcKcAa288MvwGGnV1LU08Nl7irXQYCWDhXq5MEQWp4gJ0ryXq/MwC3gY6050DCjrb9fz 7NJe2PvcU+4Fh2iH/2hHyt20JqJdT6OZFSVIKWZDzx5eQQ4Cp0S6VV59FrG3g8pC3p13 rWRA== MIME-Version: 1.0 X-Received: by 10.194.92.7 with SMTP id ci7mr22230464wjb.7.1397942100687; Sat, 19 Apr 2014 14:15:00 -0700 (PDT) Sender: mcjgrice@gmail.com Received: by 10.216.234.72 with HTTP; Sat, 19 Apr 2014 14:15:00 -0700 (PDT) Date: Sat, 19 Apr 2014 22:15:00 +0100 X-Google-Sender-Auth: 8yA2Pf6w4PnM66qDCVig5zm7ocQ Message-ID: Subject: ACPI bug submission From: Matt Grice To: freebsd-acpi@FreeBSD.org Content-Type: multipart/mixed; boundary=089e01494602541e4b04f76bc2d9 X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Apr 2014 21:15:04 -0000 --089e01494602541e4b04f76bc2d9 Content-Type: text/plain; charset=ISO-8859-1 Hi all, First of all, let me apologise if I have sent this report to you in error. I am using the latest version of PC-BSD 10 which I believe uses a "vanilla kernel" (excuse the linuxism) from FreeBSD. Symptoms: Lid close does not initiate sleep, battery is not recognised and does not charge. My hardware is an Acer Extensa 5630EZ. I hope the rest of the information you might find interesting is in the output of dmesg after a verbose boot, which is attached. The output of acpidump -dt can be found here: http://pastebin.com/vpPN86qR Kind regards Matt Grice --089e01494602541e4b04f76bc2d9 Content-Type: text/plain; charset=UTF-8; name="dmesg-v.txt" Content-Disposition: attachment; filename="dmesg-v.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: f_hu7eckmg0 VGFibGUgJ0ZBQ1AnIGF0IDB4N2JiZTQwMDAKVGFibGUgJ0hQRVQnIGF0IDB4N2JiZmVkMjMKVGFi bGUgJ01DRkcnIGF0IDB4N2JiZmVkNWIKVGFibGUgJ1NMSUMnIGF0IDB4N2JiZmVkOTcKVGFibGUg J0FTRiEnIGF0IDB4N2JiZmVmMGQKVGFibGUgJ0FQSUMnIGF0IDB4N2JiZmVmNzAKQVBJQzogRm91 bmQgdGFibGUgYXQgMHg3YmJmZWY3MApBUElDOiBVc2luZyB0aGUgTUFEVCBlbnVtZXJhdG9yLgpN QURUOiBGb3VuZCBDUFUgQVBJQyBJRCAwIEFDUEkgSUQgMDogZW5hYmxlZApTTVA6IEFkZGVkIENQ VSAwIChBUCkKTUFEVDogRm91bmQgQ1BVIEFQSUMgSUQgMSBBQ1BJIElEIDE6IGVuYWJsZWQKU01Q OiBBZGRlZCBDUFUgMSAoQVApCkNvcHlyaWdodCAoYykgMTk5Mi0yMDE0IFRoZSBGcmVlQlNEIFBy b2plY3QuCkNvcHlyaWdodCAoYykgMTk3OSwgMTk4MCwgMTk4MywgMTk4NiwgMTk4OCwgMTk4OSwg MTk5MSwgMTk5MiwgMTk5MywgMTk5NAoJVGhlIFJlZ2VudHMgb2YgdGhlIFVuaXZlcnNpdHkgb2Yg Q2FsaWZvcm5pYS4gQWxsIHJpZ2h0cyByZXNlcnZlZC4KRnJlZUJTRCBpcyBhIHJlZ2lzdGVyZWQg dHJhZGVtYXJrIG9mIFRoZSBGcmVlQlNEIEZvdW5kYXRpb24uCkZyZWVCU0QgMTAuMC1SRUxFQVNF LXA5ICMwOiBUdWUgQXByICA4IDIxOjA4OjQyIFVUQyAyMDE0CiAgICByb290QGFtZDY0LWJ1aWxk ZXIucGNic2Qub3JnOi91c3Ivb2JqL3Vzci9zcmMvc3lzL0dFTkVSSUMgYW1kNjQKRnJlZUJTRCBj bGFuZyB2ZXJzaW9uIDMuMyAodGFncy9SRUxFQVNFXzMzL2ZpbmFsIDE4MzUwMikgMjAxMzA2MTAK UHJlbG9hZGVkIGVsZjY0IGtlcm5lbCAia2VybmVsIiBhdCAweGZmZmZmZmZmODFjMGUzYjEuClBy ZWxvYWRlZCAvYm9vdC96ZnMvenBvb2wuY2FjaGUgIi9ib290L3pmcy96cG9vbC5jYWNoZSIgYXQg MHhmZmZmZmZmZjgxYzBlNmM5LgpQcmVsb2FkZWQgZWxmIG9iaiBtb2R1bGUgInZib3hkcnYua28i IGF0IDB4ZmZmZmZmZmY4MWMwZTcyOS4KUHJlbG9hZGVkIGVsZiBvYmogbW9kdWxlICJvcGVuc29s YXJpcy5rbyIgYXQgMHhmZmZmZmZmZjgxYzBlY2M5LgpQcmVsb2FkZWQgZWxmIG9iaiBtb2R1bGUg Inpmcy5rbyIgYXQgMHhmZmZmZmZmZjgxYzBmMmU5LgpQcmVsb2FkZWQgZWxmIG9iaiBtb2R1bGUg InRtcGZzLmtvIiBhdCAweGZmZmZmZmZmODFjMGZhMDEuClByZWxvYWRlZCBlbGYgb2JqIG1vZHVs ZSAibGludXgua28iIGF0IDB4ZmZmZmZmZmY4MWMxMDBhMS4KUHJlbG9hZGVkIGVsZiBvYmogbW9k dWxlICJjcnlwdG8ua28iIGF0IDB4ZmZmZmZmZmY4MWMxMGEwMS4KUHJlbG9hZGVkIGVsZiBvYmog bW9kdWxlICJnZW9tX2pvdXJuYWwua28iIGF0IDB4ZmZmZmZmZmY4MWMxMTI2MS4KUHJlbG9hZGVk IGVsZiBvYmogbW9kdWxlICJnZW9tX21pcnJvci5rbyIgYXQgMHhmZmZmZmZmZjgxYzExOTQxLgpQ cmVsb2FkZWQgZWxmIG9iaiBtb2R1bGUgImdlb21fZWxpLmtvIiBhdCAweGZmZmZmZmZmODFjMTIw MjEuClByZWxvYWRlZCBlbGYgb2JqIG1vZHVsZSAiYWVzbmkua28iIGF0IDB4ZmZmZmZmZmY4MWMx MjZjMS4KUHJlbG9hZGVkIGVsZiBvYmogbW9kdWxlICJ1bXMua28iIGF0IDB4ZmZmZmZmZmY4MWMx MmRhMS4KQ2FsaWJyYXRpbmcgVFNDIGNsb2NrIC4uLiBUU0MgY2xvY2s6IDE5OTUwNDQzNTAgSHoK Q1BVOiBQZW50aXVtKFIpIER1YWwtQ29yZSBDUFUgICAgICAgVDQyMDAgIEAgMi4wMEdIeiAoMTk5 NS4wNC1NSHogSzgtY2xhc3MgQ1BVKQogIE9yaWdpbiA9ICJHZW51aW5lSW50ZWwiICBJZCA9IDB4 MTA2N2EgIEZhbWlseSA9IDB4NiAgTW9kZWwgPSAweDE3ICBTdGVwcGluZyA9IDEwCiAgRmVhdHVy ZXM9MHhiZmViZmJmZjxGUFUsVk1FLERFLFBTRSxUU0MsTVNSLFBBRSxNQ0UsQ1g4LEFQSUMsU0VQ LE1UUlIsUEdFLE1DQSxDTU9WLFBBVCxQU0UzNixDTEZMVVNILERUUyxBQ1BJLE1NWCxGWFNSLFNT RSxTU0UyLFNTLEhUVCxUTSxQQkU+CiAgRmVhdHVyZXMyPTB4YzAwZTM5ZDxTU0UzLERURVM2NCxN T04sRFNfQ1BMLEVTVCxUTTIsU1NTRTMsQ1gxNix4VFBSLFBEQ00sWFNBVkUsT1NYU0FWRT4KICBB TUQgRmVhdHVyZXM9MHgyMDEwMDgwMDxTWVNDQUxMLE5YLExNPgogIEFNRCBGZWF0dXJlczI9MHgx PExBSEY+CiAgVFNDOiBQLXN0YXRlIGludmFyaWFudCwgcGVyZm9ybWFuY2Ugc3RhdGlzdGljcwpy ZWFsIG1lbW9yeSAgPSAyMDc2MDU3NjAwICgxOTc5IE1CKQpQaHlzaWNhbCBtZW1vcnkgY2h1bmso cyk6CjB4MDAwMDAwMDAwMDAxMDAwMCAtIDB4MDAwMDAwMDAwMDA5OWZmZiwgNTY1MjQ4IGJ5dGVz ICgxMzggcGFnZXMpCjB4MDAwMDAwMDAwMDEwMDAwMCAtIDB4MDAwMDAwMDAwMDFmZmZmZiwgMTA0 ODU3NiBieXRlcyAoMjU2IHBhZ2VzKQoweDAwMDAwMDAwMDFjNDEwMDAgLSAweDAwMDAwMDAwNzgz ZmJmZmYsIDE5ODc4MTc0NzIgYnl0ZXMgKDQ4NTMwNyBwYWdlcykKMHgwMDAwMDAwMDdiNmE3MDAw IC0gMHgwMDAwMDAwMDdiN2JiZmZmLCAxMTM0NTkyIGJ5dGVzICgyNzcgcGFnZXMpCjB4MDAwMDAw MDA3YjgwZjAwMCAtIDB4MDAwMDAwMDA3YjkwN2ZmZiwgMTAxOTkwNCBieXRlcyAoMjQ5IHBhZ2Vz KQoweDAwMDAwMDAwN2JiMGYwMDAgLSAweDAwMDAwMDAwN2JiMThmZmYsIDQwOTYwIGJ5dGVzICgx MCBwYWdlcykKMHgwMDAwMDAwMDdiYjFmMDAwIC0gMHgwMDAwMDAwMDdiYjYzZmZmLCAyODI2MjQg Ynl0ZXMgKDY5IHBhZ2VzKQoweDAwMDAwMDAwN2JiOWYwMDAgLSAweDAwMDAwMDAwN2JiYzlmZmYs IDE3NjEyOCBieXRlcyAoNDMgcGFnZXMpCmF2YWlsIG1lbW9yeSA9IDE5NzU4NDg5NjAgKDE4ODQg TUIpCkV2ZW50IHRpbWVyICJMQVBJQyIgcXVhbGl0eSA0MDAKQUNQSSBBUElDIFRhYmxlOiA8UFRM VEQgIAkgQVBJQyAgPgpJTlRSOiBBZGRpbmcgbG9jYWwgQVBJQyAxIGFzIGEgdGFyZ2V0CkZyZWVC U0QvU01QOiBNdWx0aXByb2Nlc3NvciBTeXN0ZW0gRGV0ZWN0ZWQ6IDIgQ1BVcwpGcmVlQlNEL1NN UDogMSBwYWNrYWdlKHMpIHggMiBjb3JlKHMpCiBjcHUwIChCU1ApOiBBUElDIElEOiAgMAogY3B1 MSAoQVApOiBBUElDIElEOiAgMQpBUElDOiBDUFUgMCBoYXMgQUNQSSBJRCAwCkFQSUM6IENQVSAx IGhhcyBBQ1BJIElEIDEKeDg2YmlvczogIElWVCAweDAwMDAwMC0weDAwMDRmZiBhdCAweGZmZmZm ODAwMDAwMDAwMDAKeDg2YmlvczogU1NFRyAweDA5ODAwMC0weDA5OGZmZiBhdCAweGZmZmZmZTAw NzZmZjUwMDAKeDg2YmlvczogRUJEQSAweDA5ZDAwMC0weDA5ZmZmZiBhdCAweGZmZmZmODAwMDAw OWQwMDAKeDg2YmlvczogIFJPTSAweDBhMDAwMC0weDBmZWZmZiBhdCAweGZmZmZmODAwMDAwYTAw MDAKWEVOOiBDUFUgMCBoYXMgVkNQVSBJRCAwClhFTjogQ1BVIDEgaGFzIFZDUFUgSUQgMQpVTEU6 IHNldHVwIGNwdSAwClVMRTogc2V0dXAgY3B1IDEKQUNQSTogUlNEUCAweGY2YjkwIDAwMDI0ICh2 MDIgUFRMVEQgKQpBQ1BJOiBYU0RUIDB4N2JiZjQyYzMgMDAwNkMgKHYwMSBBQ1JTWVMgQUNSUFJE Q1QgMDYwNDAwMDAgSU5OQSAwMDAwMDAwMCkKQUNQSTogRkFDUCAweDdiYmU0MDAwIDAwMEY0ICh2 MDMgSU5URUwgIENSRVNUTE5FIDA2MDQwMDAwIEFMQU4gMDAwMDAwMDEpCkFDUEk6IERTRFQgMHg3 YmJlNTAwMCAwQTY5OCAodjAyIEludGVsICBDQU5USUdBICAwNjA0MDAwMCBNU0ZUIDAzMDAwMDAw KQpBQ1BJOiBGQUNTIDB4N2JiOWVmYzAgMDAwNDAKQUNQSTogSFBFVCAweDdiYmZlZDIzIDAwMDM4 ICh2MDEgSU5URUwgIENSRVNUTE5FIDA2MDQwMDAwIExPSFIgMDAwMDAwNUEpCkFDUEk6IE1DRkcg MHg3YmJmZWQ1YiAwMDAzQyAodjAxIElOVEVMICBDUkVTVExORSAwNjA0MDAwMCBMT0hSIDAwMDAw MDVBKQpBQ1BJOiBTTElDIDB4N2JiZmVkOTcgMDAxNzYgKHYwMSBBQ1JTWVMgQUNSUFJEQ1QgMDYw NDAwMDAgQU5OSSAwMDAwMDAwMSkKQUNQSTogQVNGISAweDdiYmZlZjBkIDAwMDYzICh2MzIgT0VN SUQgIE9FTVRCTCAgIDA2MDQwMDAwIFBUTCAgMDAwMDAwMDEpCkFDUEk6IEFQSUMgMHg3YmJmZWY3 MCAwMDA2OCAodjAxIFBUTFREICA/IEFQSUMgICAwNjA0MDAwMCAgTFRQIDAwMDAwMDAwKQpBQ1BJ OiBCT09UIDB4N2JiZmVmZDggMDAwMjggKHYwMSBQVExURCAgJFNCRlRCTCQgMDYwNDAwMDAgIExU UCAwMDAwMDAwMSkKQUNQSTogU1NEVCAweDdiYmY0MzY3IDAwMUJDICh2MDEgQnJ0UmVmICBERDAx QlJUIDAwMDAxMDAwIElOVEwgMjAwNTA2MjQpCkFDUEk6IFNTRFQgMHg3YmJlMzAwMCAwMDY1NSAo djAxICBQbVJlZiAgICBDcHVQbSAwMDAwMzAwMCBJTlRMIDIwMDUwNjI0KQpNQURUOiBGb3VuZCBJ TyBBUElDIElEIDIsIEludGVycnVwdCAwIGF0IDB4ZmVjMDAwMDAKaW9hcGljMDogUm91dGluZyBl eHRlcm5hbCA4MjU5QSdzIC0+IGludHBpbiAwCmxhcGljMDogUm91dGluZyBOTUkgLT4gTElOVDEK bGFwaWMwOiBMSU5UMSB0cmlnZ2VyOiBlZGdlCmxhcGljMDogTElOVDEgcG9sYXJpdHk6IGhpZ2gK bGFwaWMxOiBSb3V0aW5nIE5NSSAtPiBMSU5UMQpsYXBpYzE6IExJTlQxIHRyaWdnZXI6IGVkZ2UK bGFwaWMxOiBMSU5UMSBwb2xhcml0eTogaGlnaApNQURUOiBJbnRlcnJ1cHQgb3ZlcnJpZGU6IHNv dXJjZSAwLCBpcnEgMgppb2FwaWMwOiBSb3V0aW5nIElSUSAwIC0+IGludHBpbiAyCk1BRFQ6IElu dGVycnVwdCBvdmVycmlkZTogc291cmNlIDksIGlycSA5CmlvYXBpYzA6IGludHBpbiA5IHRyaWdn ZXI6IGxldmVsCmlvYXBpYzAgPFZlcnNpb24gMi4wPiBpcnFzIDAtMjMgb24gbW90aGVyYm9hcmQK Y3B1MCBCU1A6CiAgICAgSUQ6IDB4MDAwMDAwMDAgICBWRVI6IDB4MDAwNTAwMTQgTERSOiAweDAw MDAwMDAwIERGUjogMHhmZmZmZmZmZgogIGxpbnQwOiAweDAwMDEwNzAwIGxpbnQxOiAweDAwMDAw NDAwIFRQUjogMHgwMDAwMDAwMCBTVlI6IDB4MDAwMDAxZmYKICB0aW1lcjogMHgwMDAxMDBlZiB0 aGVybTogMHgwMDAxMDAwMCBlcnI6IDB4MDAwMDAwZjAgcG1jOiAweDAwMDEwNDAwCnNuZF91bml0 X2luaXQoKSB1PTB4MDBmZjgwMDAgWzUxMl0gZD0weDAwMDA3YzAwIFszMl0gYz0weDAwMDAwM2Zm IFsxMDI0XQpmZWVkZXJfcmVnaXN0ZXI6IHNuZF91bml0PS0xIHNuZF9tYXhhdXRvdmNoYW5zPTE2 IGxhdGVuY3k9NSBmZWVkZXJfcmF0ZV9taW49MSBmZWVkZXJfcmF0ZV9tYXg9MjAxNjAwMCBmZWVk ZXJfcmF0ZV9yb3VuZD0yNQp3bGFuOiA8ODAyLjExIExpbmsgTGF5ZXI+CkhhcmR3YXJlLCBJbnRl bCBJdnlCcmlkZ2UrIFJORzogUkRSQU5EIGlzIG5vdCBwcmVzZW50CkhhcmR3YXJlLCBWSUEgTmVo ZW1pYWggUGFkbG9jayBSTkc6IFZJQSBQYWRsb2NrIFJORyBub3QgcHJlc2VudApuZnNsb2NrOiBw c2V1ZG8tZGV2aWNlClZFU0E6IElOVCAweDEwIHZlY3RvciAweGMwMDA6MHgwMDE0ClZFU0E6IGlu Zm9ybWF0aW9uIGJsb2NrCjAwMDAgICA1NiA0NSA1MyA0MSAwMCAwMyAwMCAwMSAwMCA5OSAwMSAw MCAwMCAwMCA0MCAwMAowMDEwICAgMDAgOTkgZmYgMDMgMDAgMDEgMzMgMDEgMDAgOTkgNDUgMDEg MDAgOTkgNjkgMDEKMDAyMCAgIDAwIDk5IDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAw IDAwIDAwIDAwCjAwMzAgICAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAw MCAwMCAwMAowMDQwICAgNjAgMDEgNjEgMDEgNjIgMDEgNjMgMDEgNjQgMDEgNjUgMDEgNjYgMDEg NjcgMDEKMDA1MCAgIDY4IDAxIDY5IDAxIDZhIDAxIDZiIDAxIDZjIDAxIDZkIDAxIDZlIDAxIDZm IDAxCjAwNjAgICA3MCAwMSA3MSAwMSAzYyAwMSA0ZCAwMSA1YyAwMSAzYSAwMSA0YiAwMSA1YSAw MQowMDcwICAgMDcgMDEgMWEgMDEgMWIgMDEgMDUgMDEgMTcgMDEgMTggMDEgMTIgMDEgMTQgMDEK MDA4MCAgIDE1IDAxIDAxIDAxIDAzIDAxIDExIDAxIGZmIGZmIDAwIDAwIDAwIDAwIDAwIDAwCjAw OTAgICAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMAowMGEw ICAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAKMDBiMCAg IDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwCjAwYzAgICAw MCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMAowMGQwICAgMDAg MDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAKMDBlMCAgIDAwIDAw IDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwCjAwZjAgICAwMCAwMCAw MCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMAowMTAwICAgNDkgNmUgNzQg NjUgNmMgMjggNzIgMjkgNDMgNjEgNmUgNzQgNjkgNjcgNjEgMjAKMDExMCAgIDQ3IDcyIDYxIDcw IDY4IDY5IDYzIDczIDIwIDQzIDY4IDY5IDcwIDIwIDQxIDYzCjAxMjAgICA2MyA2NSA2YyA2NSA3 MiA2MSA3NCA2NSA2NCAyMCA1NiA0NyA0MSAyMCA0MiA0OQowMTMwICAgNGYgNTMgMDAgNDkgNmUg NzQgNjUgNmMgMjAgNDMgNmYgNzIgNzAgNmYgNzIgNjEKMDE0MCAgIDc0IDY5IDZmIDZlIDAwIDQ5 IDZlIDc0IDY1IDZjIDI4IDcyIDI5IDQzIDYxIDZlCjAxNTAgICA3NCA2OSA2NyA2MSAyMCA0NyA3 MiA2MSA3MCA2OCA2OSA2MyA3MyAyMCA0MyA2ZgowMTYwICAgNmUgNzQgNzIgNmYgNmMgNmMgNjUg NzIgMDAgNDggNjEgNzIgNjQgNzcgNjEgNzIKMDE3MCAgIDY1IDIwIDU2IDY1IDcyIDczIDY5IDZm IDZlIDIwIDMwIDJlIDMwIDAwIDAwIDAwCjAxODAgICAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAw MCAwMCAwMCAwMCAwMCAwMCAwMCAwMAowMTkwICAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAg MDAgMDAgMDAgMDAgMDAgMDAgMDAKMDFhMCAgIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAw IDAwIDAwIDAwIDAwIDAwIDAwCjAxYjAgICAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAw MCAwMCAwMCAwMCAwMCAwMAowMWMwICAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAg MDAgMDAgMDAgMDAgMDAKMDFkMCAgIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAw IDAwIDAwIDAwIDAwCjAxZTAgICAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAw MCAwMCAwMCAwMAowMWYwICAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAg MDAgMDAgMDAKVkVTQTogMTIgbW9kZShzKSBmb3VuZApWRVNBOiB2My4wLCA2NTQ3MmsgbWVtb3J5 LCBmbGFnczoweDEsIG1vZGUgdGFibGU6MHhmZmZmZmUwMDc3N2RlMDQwICg5OTAwMDA0MCkKVkVT QTogSW50ZWwocilDYW50aWdhIEdyYXBoaWNzIENoaXAgQWNjZWxlcmF0ZWQgVkdBIEJJT1MKVkVT QTogSW50ZWwgQ29ycG9yYXRpb24gSW50ZWwocilDYW50aWdhIEdyYXBoaWNzIENvbnRyb2xsZXIg SGFyZHdhcmUgVmVyc2lvbiAwLjAKaW86IDxJL08+ClZNQlVTOiBsb2FkCmtiZDogbmV3IGFycmF5 IHNpemUgNAprYmQxIGF0IGtiZG11eDAKbWVtOiA8bWVtb3J5PgpudWxsOiA8bnVsbCBkZXZpY2Us IHplcm8gZGV2aWNlPgpjcnlwdG86IDxjcnlwdG8gY29yZT4KRmFsbGluZyBiYWNrIHRvIDxTb2Z0 d2FyZSwgWWFycm93PiByYW5kb20gYWRhcHRvcgpyYW5kb206IDxTb2Z0d2FyZSwgWWFycm93PiBp bml0aWFsaXplZApocHRucjogUjc1MC9EQzcyODAgY29udHJvbGxlciBkcml2ZXIgdjEuMApocHQy N3h4OiBSb2NrZXRSQUlEIDI3eHggY29udHJvbGxlciBkcml2ZXIgdjEuMQpocHRycjogUm9ja2V0 UkFJRCAxN3h4LzJ4eHggU0FUQSBjb250cm9sbGVyIGRyaXZlciB2MS4yCmNyeXB0b3NvZnQwOiA8 c29mdHdhcmUgY3J5cHRvPiBvbiBtb3RoZXJib2FyZApjcnlwdG86IGFzc2lnbiBjcnlwdG9zb2Z0 MCBkcml2ZXIgaWQgMCwgZmxhZ3MgMTAwNjYzMjk2CmNyeXB0bzogY3J5cHRvc29mdDAgcmVnaXN0 ZXJzIGFsZyAxIGZsYWdzIDAgbWF4b3BsZW4gMApjcnlwdG86IGNyeXB0b3NvZnQwIHJlZ2lzdGVy cyBhbGcgMiBmbGFncyAwIG1heG9wbGVuIDAKY3J5cHRvOiBjcnlwdG9zb2Z0MCByZWdpc3RlcnMg YWxnIDMgZmxhZ3MgMCBtYXhvcGxlbiAwCmNyeXB0bzogY3J5cHRvc29mdDAgcmVnaXN0ZXJzIGFs ZyA0IGZsYWdzIDAgbWF4b3BsZW4gMApjcnlwdG86IGNyeXB0b3NvZnQwIHJlZ2lzdGVycyBhbGcg NSBmbGFncyAwIG1heG9wbGVuIDAKY3J5cHRvOiBjcnlwdG9zb2Z0MCByZWdpc3RlcnMgYWxnIDE2 IGZsYWdzIDAgbWF4b3BsZW4gMApjcnlwdG86IGNyeXB0b3NvZnQwIHJlZ2lzdGVycyBhbGcgNiBm bGFncyAwIG1heG9wbGVuIDAKY3J5cHRvOiBjcnlwdG9zb2Z0MCByZWdpc3RlcnMgYWxnIDcgZmxh Z3MgMCBtYXhvcGxlbiAwCmNyeXB0bzogY3J5cHRvc29mdDAgcmVnaXN0ZXJzIGFsZyAxOCBmbGFn cyAwIG1heG9wbGVuIDAKY3J5cHRvOiBjcnlwdG9zb2Z0MCByZWdpc3RlcnMgYWxnIDE5IGZsYWdz IDAgbWF4b3BsZW4gMApjcnlwdG86IGNyeXB0b3NvZnQwIHJlZ2lzdGVycyBhbGcgMjAgZmxhZ3Mg MCBtYXhvcGxlbiAwCmNyeXB0bzogY3J5cHRvc29mdDAgcmVnaXN0ZXJzIGFsZyA4IGZsYWdzIDAg bWF4b3BsZW4gMApjcnlwdG86IGNyeXB0b3NvZnQwIHJlZ2lzdGVycyBhbGcgMTUgZmxhZ3MgMCBt YXhvcGxlbiAwCmNyeXB0bzogY3J5cHRvc29mdDAgcmVnaXN0ZXJzIGFsZyA5IGZsYWdzIDAgbWF4 b3BsZW4gMApjcnlwdG86IGNyeXB0b3NvZnQwIHJlZ2lzdGVycyBhbGcgMTAgZmxhZ3MgMCBtYXhv cGxlbiAwCmNyeXB0bzogY3J5cHRvc29mdDAgcmVnaXN0ZXJzIGFsZyAxMyBmbGFncyAwIG1heG9w bGVuIDAKY3J5cHRvOiBjcnlwdG9zb2Z0MCByZWdpc3RlcnMgYWxnIDE0IGZsYWdzIDAgbWF4b3Bs ZW4gMApjcnlwdG86IGNyeXB0b3NvZnQwIHJlZ2lzdGVycyBhbGcgMTEgZmxhZ3MgMCBtYXhvcGxl biAwCmNyeXB0bzogY3J5cHRvc29mdDAgcmVnaXN0ZXJzIGFsZyAyMiBmbGFncyAwIG1heG9wbGVu IDAKY3J5cHRvOiBjcnlwdG9zb2Z0MCByZWdpc3RlcnMgYWxnIDIxIGZsYWdzIDAgbWF4b3BsZW4g MApjcnlwdG86IGNyeXB0b3NvZnQwIHJlZ2lzdGVycyBhbGcgMTcgZmxhZ3MgMCBtYXhvcGxlbiAw CmFlc25pMDogTm8gQUVTTkkgc3VwcG9ydC4KYWNwaTA6IDxBQ1JTWVMgQUNSUFJEQ1Q+IG9uIG1v dGhlcmJvYXJkCkFDUEk6IEFsbCBBQ1BJIFRhYmxlcyBzdWNjZXNzZnVsbHkgYWNxdWlyZWQKUENJ ZTogTWVtb3J5IE1hcHBlZCBjb25maWd1cmF0aW9uIGJhc2UgQCAweGUwMDAwMDAwCmlvYXBpYzA6 IHJvdXRpbmcgaW50cGluIDkgKElTQSBJUlEgOSkgdG8gbGFwaWMgMCB2ZWN0b3IgNDgKYWNwaTA6 IFBvd2VyIEJ1dHRvbiAoZml4ZWQpCmhwZXQwOiA8SGlnaCBQcmVjaXNpb24gRXZlbnQgVGltZXI+ IGlvbWVtIDB4ZmVkMDAwMDAtMHhmZWQwMDNmZiBvbiBhY3BpMApocGV0MDogdmVuZG9yIDB4ODA4 NiwgcmV2IDB4MSwgMTQzMTgxODBIeiA2NGJpdCwgNCB0aW1lcnMsIGxlZ2FjeSByb3V0ZQpocGV0 MDogIHQwOiBpcnFzIDB4MDBmMDAwMDAgKDApLCA2NGJpdCwgcGVyaW9kaWMKaHBldDA6ICB0MTog aXJxcyAweDAwZjAwMDAwICgwKQpocGV0MDogIHQyOiBpcnFzIDB4MDBmMDA4MDAgKDApCmhwZXQw OiAgdDM6IGlycXMgMHgwMGYwMTAwMCAoMCkKVGltZWNvdW50ZXIgIkhQRVQiIGZyZXF1ZW5jeSAx NDMxODE4MCBIeiBxdWFsaXR5IDk1MAppb2FwaWMwOiByb3V0aW5nIGludHBpbiAyMCAoUENJIElS USAyMCkgdG8gbGFwaWMgMCB2ZWN0b3IgNDkKRXZlbnQgdGltZXIgIkhQRVQiIGZyZXF1ZW5jeSAx NDMxODE4MCBIeiBxdWFsaXR5IDQ1MApFdmVudCB0aW1lciAiSFBFVDEiIGZyZXF1ZW5jeSAxNDMx ODE4MCBIeiBxdWFsaXR5IDQ0MApFdmVudCB0aW1lciAiSFBFVDIiIGZyZXF1ZW5jeSAxNDMxODE4 MCBIeiBxdWFsaXR5IDQ0MApFdmVudCB0aW1lciAiSFBFVDMiIGZyZXF1ZW5jeSAxNDMxODE4MCBI eiBxdWFsaXR5IDQ0MApjcHUwOiBQcm9jZXNzb3IgXDEzNF9QUl8uQ1BVMCAoQUNQSSBJRCAwKSAt PiBBUElDIElEIDAKY3B1MDogPEFDUEkgQ1BVPiBvbiBhY3BpMApBQ1BJOiBTU0RUIDB4N2JiMWFj YTAgMDAyMjMgKHYwMSAgUG1SZWYgIENwdTBJc3QgMDAwMDMwMDAgSU5UTCAyMDA1MDYyNCkKQUNQ STogRHluYW1pYyBPRU0gVGFibGUgTG9hZDoKQUNQSTogU1NEVCAwIDAwMjIzICh2MDEgIFBtUmVm ICBDcHUwSXN0IDAwMDAzMDAwIElOVEwgMjAwNTA2MjQpCkFDUEk6IFNTRFQgMHg3YmIxOTYyMCAw MDU0OSAodjAxICBQbVJlZiAgQ3B1MENzdCAwMDAwMzAwMSBJTlRMIDIwMDUwNjI0KQpBQ1BJOiBE eW5hbWljIE9FTSBUYWJsZSBMb2FkOgpBQ1BJOiBTU0RUIDAgMDA1NDkgKHYwMSAgUG1SZWYgIENw dTBDc3QgMDAwMDMwMDEgSU5UTCAyMDA1MDYyNCkKY3B1MTogUHJvY2Vzc29yIFwxMzRfUFJfLkNQ VTEgKEFDUEkgSUQgMSkgLT4gQVBJQyBJRCAxCmNwdTE6IDxBQ1BJIENQVT4gb24gYWNwaTAKQUNQ STogU1NEVCAweDdiYjFhYTIwIDAwMUNGICh2MDEgIFBtUmVmICAgIEFwSXN0IDAwMDAzMDAwIElO VEwgMjAwNTA2MjQpCkFDUEk6IER5bmFtaWMgT0VNIFRhYmxlIExvYWQ6CkFDUEk6IFNTRFQgMCAw MDFDRiAodjAxICBQbVJlZiAgICBBcElzdCAwMDAwMzAwMCBJTlRMIDIwMDUwNjI0KQpBQ1BJOiBT U0RUIDB4N2JiMWFmMjAgMDAwOEQgKHYwMSAgUG1SZWYgICAgQXBDc3QgMDAwMDMwMDAgSU5UTCAy MDA1MDYyNCkKQUNQSTogRHluYW1pYyBPRU0gVGFibGUgTG9hZDoKQUNQSTogU1NEVCAwIDAwMDhE ICh2MDEgIFBtUmVmICAgIEFwQ3N0IDAwMDAzMDAwIElOVEwgMjAwNTA2MjQpCkFDUEk6IFByb2Nl c3NvciBcMTM0X1BSXy5DUFUyIChBQ1BJIElEIDIpIGlnbm9yZWQKQUNQSTogUHJvY2Vzc29yIFwx MzRfUFJfLkNQVTMgKEFDUEkgSUQgMykgaWdub3JlZAphdHJ0YzA6IDxBVCByZWFsdGltZSBjbG9j az4gcG9ydCAweDcwLTB4NzcgaXJxIDggb24gYWNwaTAKYXRydGMwOiBXYXJuaW5nOiBDb3VsZG4n dCBtYXAgSS9PLgphdHJ0YzA6IHJlZ2lzdGVyZWQgYXMgYSB0aW1lLW9mLWRheSBjbG9jayAocmVz b2x1dGlvbiAxMDAwMDAwdXMsIGFkanVzdG1lbnQgMC41MDAwMDAwMDBzKQppb2FwaWMwOiByb3V0 aW5nIGludHBpbiA4IChJU0EgSVJRIDgpIHRvIGxhcGljIDAgdmVjdG9yIDUwCkV2ZW50IHRpbWVy ICJSVEMiIGZyZXF1ZW5jeSAzMjc2OCBIeiBxdWFsaXR5IDAKYXR0aW1lcjA6IDxBVCB0aW1lcj4g cG9ydCAweDQwLTB4NDMsMHg1MC0weDUzIGlycSAwIG9uIGFjcGkwClRpbWVjb3VudGVyICJpODI1 NCIgZnJlcXVlbmN5IDExOTMxODIgSHogcXVhbGl0eSAwCmlvYXBpYzA6IHJvdXRpbmcgaW50cGlu IDIgKElTQSBJUlEgMCkgdG8gbGFwaWMgMCB2ZWN0b3IgNTEKRXZlbnQgdGltZXIgImk4MjU0IiBm cmVxdWVuY3kgMTE5MzE4MiBIeiBxdWFsaXR5IDEwMApBQ1BJIHRpbWVyOiAxLzAgMS8wIDEvMCAx LzAgMS8wIDEvMCAxLzAgMS8wIDEvMCAxLzAgLT4gMTAKVGltZWNvdW50ZXIgIkFDUEktZmFzdCIg ZnJlcXVlbmN5IDM1Nzk1NDUgSHogcXVhbGl0eSA5MDAKYWNwaV90aW1lcjA6IDwyNC1iaXQgdGlt ZXIgYXQgMy41Nzk1NDVNSHo+IHBvcnQgMHg0MDgtMHg0MGIgb24gYWNwaTAKYWNwaV9lYzA6IDxF bWJlZGRlZCBDb250cm9sbGVyOiBHUEUgMHgxNz4gcG9ydCAweDYyLDB4NjYgb24gYWNwaTAKcGNp X2xpbmswOiAgICAgICAgSW5kZXggIElSUSAgUnRkICBSZWYgIElSUXMKICBJbml0aWFsIFByb2Jl ICAgICAgIDAgICAxMSAgIE4gICAgIDAgIDEwIDExCiAgVmFsaWRhdGlvbiAgICAgICAgICAwICAg MTEgICBOICAgICAwICAxMCAxMQogIEFmdGVyIERpc2FibGUgICAgICAgMCAgMjU1ICAgTiAgICAg MCAgMTAgMTEKcGNpX2xpbmsxOiAgICAgICAgSW5kZXggIElSUSAgUnRkICBSZWYgIElSUXMKICBJ bml0aWFsIFByb2JlICAgICAgIDAgICAxMSAgIE4gICAgIDAgIDEwIDExCiAgVmFsaWRhdGlvbiAg ICAgICAgICAwICAgMTEgICBOICAgICAwICAxMCAxMQogIEFmdGVyIERpc2FibGUgICAgICAgMCAg MjU1ICAgTiAgICAgMCAgMTAgMTEKcGNpX2xpbmsyOiAgICAgICAgSW5kZXggIElSUSAgUnRkICBS ZWYgIElSUXMKICBJbml0aWFsIFByb2JlICAgICAgIDAgICAxMCAgIE4gICAgIDAgIDEwIDExCiAg VmFsaWRhdGlvbiAgICAgICAgICAwICAgMTAgICBOICAgICAwICAxMCAxMQogIEFmdGVyIERpc2Fi bGUgICAgICAgMCAgMjU1ICAgTiAgICAgMCAgMTAgMTEKcGNpX2xpbmszOiAgICAgICAgSW5kZXgg IElSUSAgUnRkICBSZWYgIElSUXMKICBJbml0aWFsIFByb2JlICAgICAgIDAgICAxMCAgIE4gICAg IDAgIDEwIDExCiAgVmFsaWRhdGlvbiAgICAgICAgICAwICAgMTAgICBOICAgICAwICAxMCAxMQog IEFmdGVyIERpc2FibGUgICAgICAgMCAgMjU1ICAgTiAgICAgMCAgMTAgMTEKcGNpX2xpbms0OiAg ICAgICAgSW5kZXggIElSUSAgUnRkICBSZWYgIElSUXMKICBJbml0aWFsIFByb2JlICAgICAgIDAg ICAxMSAgIE4gICAgIDAgIDEwIDExCiAgVmFsaWRhdGlvbiAgICAgICAgICAwICAgMTEgICBOICAg ICAwICAxMCAxMQogIEFmdGVyIERpc2FibGUgICAgICAgMCAgMjU1ICAgTiAgICAgMCAgMTAgMTEK cGNpX2xpbms1OiAgICAgICAgSW5kZXggIElSUSAgUnRkICBSZWYgIElSUXMKICBJbml0aWFsIFBy b2JlICAgICAgIDAgICAxMCAgIE4gICAgIDAgIDEwIDExCiAgVmFsaWRhdGlvbiAgICAgICAgICAw ICAgMTAgICBOICAgICAwICAxMCAxMQogIEFmdGVyIERpc2FibGUgICAgICAgMCAgMjU1ICAgTiAg ICAgMCAgMTAgMTEKcGNpX2xpbms2OiAgICAgICAgSW5kZXggIElSUSAgUnRkICBSZWYgIElSUXMK ICBJbml0aWFsIFByb2JlICAgICAgIDAgICAxMSAgIE4gICAgIDAgIDEwIDExCiAgVmFsaWRhdGlv biAgICAgICAgICAwICAgMTEgICBOICAgICAwICAxMCAxMQogIEFmdGVyIERpc2FibGUgICAgICAg MCAgMjU1ICAgTiAgICAgMCAgMTAgMTEKcGNpX2xpbms3OiAgICAgICAgSW5kZXggIElSUSAgUnRk ICBSZWYgIElSUXMKICBJbml0aWFsIFByb2JlICAgICAgIDAgICAxMCAgIE4gICAgIDAgIDEwIDEx CiAgVmFsaWRhdGlvbiAgICAgICAgICAwICAgMTAgICBOICAgICAwICAxMCAxMQogIEFmdGVyIERp c2FibGUgICAgICAgMCAgMjU1ICAgTiAgICAgMCAgMTAgMTEKcGNpYjA6IDxBQ1BJIEhvc3QtUENJ IGJyaWRnZT4gcG9ydCAweGNmOC0weGNmZiBvbiBhY3BpMApwY2liMDogZGVjb2RpbmcgNCByYW5n ZSAwLTB4Y2Y3CnBjaWIwOiBkZWNvZGluZyA0IHJhbmdlIDB4ZDAwLTB4ZmZmZgpwY2liMDogZGVj b2RpbmcgMyByYW5nZSAweGEwMDAwLTB4YmZmZmYKcGNpYjA6IGRlY29kaW5nIDMgcmFuZ2UgMHhk NDAwMC0weGQ3ZmZmCnBjaWIwOiBkZWNvZGluZyAzIHJhbmdlIDB4ZDgwMDAtMHhkYmZmZgpwY2li MDogZGVjb2RpbmcgMyByYW5nZSAweGRjMDAwLTB4ZGZmZmYKcGNpYjA6IGRlY29kaW5nIDMgcmFu Z2UgMHhlMDAwMC0weGUzZmZmCnBjaWIwOiBkZWNvZGluZyAzIHJhbmdlIDB4ODAwMDAwMDAtMHhk ZmZmZmZmZgpwY2liMDogZGVjb2RpbmcgMyByYW5nZSAweGYwMDAwMDAwLTB4ZmViZmZmZmYKcGNp MDogPEFDUEkgUENJIGJ1cz4gb24gcGNpYjAKcGNpMDogZG9tYWluPTAsIHBoeXNpY2FsIGJ1cz0w CmZvdW5kLT4JdmVuZG9yPTB4ODA4NiwgZGV2PTB4MmE0MCwgcmV2aWQ9MHgwNwoJZG9tYWluPTAs IGJ1cz0wLCBzbG90PTAsIGZ1bmM9MAoJY2xhc3M9MDYtMDAtMDAsIGhkcnR5cGU9MHgwMCwgbWZk ZXY9MAoJY21kcmVnPTB4MDEwNiwgc3RhdHJlZz0weDIwOTAsIGNhY2hlbG5zej0wIChkd29yZHMp CglsYXR0aW1lcj0weDAwICgwIG5zKSwgbWluZ250PTB4MDAgKDAgbnMpLCBtYXhsYXQ9MHgwMCAo MCBucykKZm91bmQtPgl2ZW5kb3I9MHg4MDg2LCBkZXY9MHgyYTQyLCByZXZpZD0weDA3Cglkb21h aW49MCwgYnVzPTAsIHNsb3Q9MiwgZnVuYz0wCgljbGFzcz0wMy0wMC0wMCwgaGRydHlwZT0weDAw LCBtZmRldj0xCgljbWRyZWc9MHgwMDA3LCBzdGF0cmVnPTB4MDA5MCwgY2FjaGVsbnN6PTAgKGR3 b3JkcykKCWxhdHRpbWVyPTB4MDAgKDAgbnMpLCBtaW5nbnQ9MHgwMCAoMCBucyksIG1heGxhdD0w eDAwICgwIG5zKQoJaW50cGluPWEsIGlycT0xMQoJcG93ZXJzcGVjIDMgIHN1cHBvcnRzIEQwIEQz ICBjdXJyZW50IEQwCglNU0kgc3VwcG9ydHMgMSBtZXNzYWdlCgltYXBbMTBdOiB0eXBlIE1lbW9y eSwgcmFuZ2UgNjQsIGJhc2UgMHhmNDAwMDAwMCwgc2l6ZSAyMiwgZW5hYmxlZApwY2liMDogYWxs b2NhdGVkIHR5cGUgMyAoMHhmNDAwMDAwMC0weGY0M2ZmZmZmKSBmb3IgcmlkIDEwIG9mIHBjaTA6 MDoyOjAKCW1hcFsxOF06IHR5cGUgUHJlZmV0Y2hhYmxlIE1lbW9yeSwgcmFuZ2UgNjQsIGJhc2Ug MHhkMDAwMDAwMCwgc2l6ZSAyOCwgZW5hYmxlZApwY2liMDogYWxsb2NhdGVkIHR5cGUgMyAoMHhk MDAwMDAwMC0weGRmZmZmZmZmKSBmb3IgcmlkIDE4IG9mIHBjaTA6MDoyOjAKCW1hcFsyMF06IHR5 cGUgSS9PIFBvcnQsIHJhbmdlIDMyLCBiYXNlIDB4MTgwMCwgc2l6ZSAgMywgZW5hYmxlZApwY2li MDogYWxsb2NhdGVkIHR5cGUgNCAoMHgxODAwLTB4MTgwNykgZm9yIHJpZCAyMCBvZiBwY2kwOjA6 MjowCnBjaWIwOiBtYXRjaGVkIGVudHJ5IGZvciAwLjIuSU5UQQpwY2liMDogc2xvdCAyIElOVEEg aGFyZHdpcmVkIHRvIElSUSAxNgpmb3VuZC0+CXZlbmRvcj0weDgwODYsIGRldj0weDJhNDMsIHJl dmlkPTB4MDcKCWRvbWFpbj0wLCBidXM9MCwgc2xvdD0yLCBmdW5jPTEKCWNsYXNzPTAzLTgwLTAw LCBoZHJ0eXBlPTB4MDAsIG1mZGV2PTEKCWNtZHJlZz0weDAwMDcsIHN0YXRyZWc9MHgwMDkwLCBj YWNoZWxuc3o9MCAoZHdvcmRzKQoJbGF0dGltZXI9MHgwMCAoMCBucyksIG1pbmdudD0weDAwICgw IG5zKSwgbWF4bGF0PTB4MDAgKDAgbnMpCglwb3dlcnNwZWMgMyAgc3VwcG9ydHMgRDAgRDMgIGN1 cnJlbnQgRDAKCW1hcFsxMF06IHR5cGUgTWVtb3J5LCByYW5nZSA2NCwgYmFzZSAweGY0NDAwMDAw LCBzaXplIDIwLCBlbmFibGVkCnBjaWIwOiBhbGxvY2F0ZWQgdHlwZSAzICgweGY0NDAwMDAwLTB4 ZjQ0ZmZmZmYpIGZvciByaWQgMTAgb2YgcGNpMDowOjI6MQpmb3VuZC0+CXZlbmRvcj0weDgwODYs IGRldj0weDI5MzcsIHJldmlkPTB4MDMKCWRvbWFpbj0wLCBidXM9MCwgc2xvdD0yNiwgZnVuYz0w CgljbGFzcz0wYy0wMy0wMCwgaGRydHlwZT0weDAwLCBtZmRldj0xCgljbWRyZWc9MHgwMDA1LCBz dGF0cmVnPTB4MDI5MCwgY2FjaGVsbnN6PTAgKGR3b3JkcykKCWxhdHRpbWVyPTB4MDAgKDAgbnMp LCBtaW5nbnQ9MHgwMCAoMCBucyksIG1heGxhdD0weDAwICgwIG5zKQoJaW50cGluPWEsIGlycT0x MQoJbWFwWzIwXTogdHlwZSBJL08gUG9ydCwgcmFuZ2UgMzIsIGJhc2UgMHgxODIwLCBzaXplICA1 LCBlbmFibGVkCnBjaWIwOiBhbGxvY2F0ZWQgdHlwZSA0ICgweDE4MjAtMHgxODNmKSBmb3Igcmlk IDIwIG9mIHBjaTA6MDoyNjowCnBjaWIwOiBtYXRjaGVkIGVudHJ5IGZvciAwLjI2LklOVEEKcGNp YjA6IHNsb3QgMjYgSU5UQSBoYXJkd2lyZWQgdG8gSVJRIDIwCmZvdW5kLT4JdmVuZG9yPTB4ODA4 NiwgZGV2PTB4MjkzOCwgcmV2aWQ9MHgwMwoJZG9tYWluPTAsIGJ1cz0wLCBzbG90PTI2LCBmdW5j PTEKCWNsYXNzPTBjLTAzLTAwLCBoZHJ0eXBlPTB4MDAsIG1mZGV2PTAKCWNtZHJlZz0weDAwMDUs IHN0YXRyZWc9MHgwMjkwLCBjYWNoZWxuc3o9MCAoZHdvcmRzKQoJbGF0dGltZXI9MHgwMCAoMCBu cyksIG1pbmdudD0weDAwICgwIG5zKSwgbWF4bGF0PTB4MDAgKDAgbnMpCglpbnRwaW49YiwgaXJx PTExCgltYXBbMjBdOiB0eXBlIEkvTyBQb3J0LCByYW5nZSAzMiwgYmFzZSAweDE4NDAsIHNpemUg IDUsIGVuYWJsZWQKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDQgKDB4MTg0MC0weDE4NWYpIGZvciBy aWQgMjAgb2YgcGNpMDowOjI2OjEKcGNpYjA6IG1hdGNoZWQgZW50cnkgZm9yIDAuMjYuSU5UQgpw Y2liMDogc2xvdCAyNiBJTlRCIGhhcmR3aXJlZCB0byBJUlEgMjAKZm91bmQtPgl2ZW5kb3I9MHg4 MDg2LCBkZXY9MHgyOTM5LCByZXZpZD0weDAzCglkb21haW49MCwgYnVzPTAsIHNsb3Q9MjYsIGZ1 bmM9MgoJY2xhc3M9MGMtMDMtMDAsIGhkcnR5cGU9MHgwMCwgbWZkZXY9MAoJY21kcmVnPTB4MDAw NSwgc3RhdHJlZz0weDAyOTAsIGNhY2hlbG5zej0wIChkd29yZHMpCglsYXR0aW1lcj0weDAwICgw IG5zKSwgbWluZ250PTB4MDAgKDAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBucykKCWludHBpbj1jLCBp cnE9MTEKCW1hcFsyMF06IHR5cGUgSS9PIFBvcnQsIHJhbmdlIDMyLCBiYXNlIDB4MTg2MCwgc2l6 ZSAgNSwgZW5hYmxlZApwY2liMDogYWxsb2NhdGVkIHR5cGUgNCAoMHgxODYwLTB4MTg3ZikgZm9y IHJpZCAyMCBvZiBwY2kwOjA6MjY6MgpwY2liMDogbWF0Y2hlZCBlbnRyeSBmb3IgMC4yNi5JTlRD CnBjaWIwOiBzbG90IDI2IElOVEMgaGFyZHdpcmVkIHRvIElSUSAyMApmb3VuZC0+CXZlbmRvcj0w eDgwODYsIGRldj0weDI5M2MsIHJldmlkPTB4MDMKCWRvbWFpbj0wLCBidXM9MCwgc2xvdD0yNiwg ZnVuYz03CgljbGFzcz0wYy0wMy0yMCwgaGRydHlwZT0weDAwLCBtZmRldj0wCgljbWRyZWc9MHgw MTA2LCBzdGF0cmVnPTB4MDI5MCwgY2FjaGVsbnN6PTAgKGR3b3JkcykKCWxhdHRpbWVyPTB4MDAg KDAgbnMpLCBtaW5nbnQ9MHgwMCAoMCBucyksIG1heGxhdD0weDAwICgwIG5zKQoJaW50cGluPWMs IGlycT0xMQoJcG93ZXJzcGVjIDIgIHN1cHBvcnRzIEQwIEQzICBjdXJyZW50IEQwCgltYXBbMTBd OiB0eXBlIE1lbW9yeSwgcmFuZ2UgMzIsIGJhc2UgMHhmNGEwNDgwMCwgc2l6ZSAxMCwgZW5hYmxl ZApwY2liMDogYWxsb2NhdGVkIHR5cGUgMyAoMHhmNGEwNDgwMC0weGY0YTA0YmZmKSBmb3Igcmlk IDEwIG9mIHBjaTA6MDoyNjo3CnBjaWIwOiBtYXRjaGVkIGVudHJ5IGZvciAwLjI2LklOVEMKcGNp YjA6IHNsb3QgMjYgSU5UQyBoYXJkd2lyZWQgdG8gSVJRIDIwCmZvdW5kLT4JdmVuZG9yPTB4ODA4 NiwgZGV2PTB4MjkzZSwgcmV2aWQ9MHgwMwoJZG9tYWluPTAsIGJ1cz0wLCBzbG90PTI3LCBmdW5j PTAKCWNsYXNzPTA0LTAzLTAwLCBoZHJ0eXBlPTB4MDAsIG1mZGV2PTAKCWNtZHJlZz0weDAxMDYs IHN0YXRyZWc9MHgwMDEwLCBjYWNoZWxuc3o9MTYgKGR3b3JkcykKCWxhdHRpbWVyPTB4MDAgKDAg bnMpLCBtaW5nbnQ9MHgwMCAoMCBucyksIG1heGxhdD0weDAwICgwIG5zKQoJaW50cGluPWEsIGly cT0xMAoJcG93ZXJzcGVjIDIgIHN1cHBvcnRzIEQwIEQzICBjdXJyZW50IEQwCglNU0kgc3VwcG9y dHMgMSBtZXNzYWdlLCA2NCBiaXQKCW1hcFsxMF06IHR5cGUgTWVtb3J5LCByYW5nZSA2NCwgYmFz ZSAweGY0ODAwMDAwLCBzaXplIDE0LCBlbmFibGVkCnBjaWIwOiBhbGxvY2F0ZWQgdHlwZSAzICgw eGY0ODAwMDAwLTB4ZjQ4MDNmZmYpIGZvciByaWQgMTAgb2YgcGNpMDowOjI3OjAKcGNpYjA6IG1h dGNoZWQgZW50cnkgZm9yIDAuMjcuSU5UQQpwY2liMDogc2xvdCAyNyBJTlRBIGhhcmR3aXJlZCB0 byBJUlEgMjEKZm91bmQtPgl2ZW5kb3I9MHg4MDg2LCBkZXY9MHgyOTQwLCByZXZpZD0weDAzCglk b21haW49MCwgYnVzPTAsIHNsb3Q9MjgsIGZ1bmM9MAoJY2xhc3M9MDYtMDQtMDAsIGhkcnR5cGU9 MHgwMSwgbWZkZXY9MQoJY21kcmVnPTB4MDEwNywgc3RhdHJlZz0weDAwMTAsIGNhY2hlbG5zej0x NiAoZHdvcmRzKQoJbGF0dGltZXI9MHgwMCAoMCBucyksIG1pbmdudD0weDA0ICgxMDAwIG5zKSwg bWF4bGF0PTB4MDAgKDAgbnMpCglpbnRwaW49YSwgaXJxPTExCglwb3dlcnNwZWMgMiAgc3VwcG9y dHMgRDAgRDMgIGN1cnJlbnQgRDAKCU1TSSBzdXBwb3J0cyAxIG1lc3NhZ2UKcGNpYjA6IG1hdGNo ZWQgZW50cnkgZm9yIDAuMjguSU5UQQpwY2liMDogc2xvdCAyOCBJTlRBIGhhcmR3aXJlZCB0byBJ UlEgMTYKZm91bmQtPgl2ZW5kb3I9MHg4MDg2LCBkZXY9MHgyOTQyLCByZXZpZD0weDAzCglkb21h aW49MCwgYnVzPTAsIHNsb3Q9MjgsIGZ1bmM9MQoJY2xhc3M9MDYtMDQtMDAsIGhkcnR5cGU9MHgw MSwgbWZkZXY9MQoJY21kcmVnPTB4MDEwNywgc3RhdHJlZz0weDAwMTAsIGNhY2hlbG5zej0xNiAo ZHdvcmRzKQoJbGF0dGltZXI9MHgwMCAoMCBucyksIG1pbmdudD0weDA0ICgxMDAwIG5zKSwgbWF4 bGF0PTB4MDAgKDAgbnMpCglpbnRwaW49YiwgaXJxPTExCglwb3dlcnNwZWMgMiAgc3VwcG9ydHMg RDAgRDMgIGN1cnJlbnQgRDAKCU1TSSBzdXBwb3J0cyAxIG1lc3NhZ2UKcGNpYjA6IG1hdGNoZWQg ZW50cnkgZm9yIDAuMjguSU5UQgpwY2liMDogc2xvdCAyOCBJTlRCIGhhcmR3aXJlZCB0byBJUlEg MTcKZm91bmQtPgl2ZW5kb3I9MHg4MDg2LCBkZXY9MHgyOTQ4LCByZXZpZD0weDAzCglkb21haW49 MCwgYnVzPTAsIHNsb3Q9MjgsIGZ1bmM9NAoJY2xhc3M9MDYtMDQtMDAsIGhkcnR5cGU9MHgwMSwg bWZkZXY9MQoJY21kcmVnPTB4MDEwNywgc3RhdHJlZz0weDAwMTAsIGNhY2hlbG5zej0xNiAoZHdv cmRzKQoJbGF0dGltZXI9MHgwMCAoMCBucyksIG1pbmdudD0weDA0ICgxMDAwIG5zKSwgbWF4bGF0 PTB4MDAgKDAgbnMpCglpbnRwaW49YSwgaXJxPTExCglwb3dlcnNwZWMgMiAgc3VwcG9ydHMgRDAg RDMgIGN1cnJlbnQgRDAKCU1TSSBzdXBwb3J0cyAxIG1lc3NhZ2UKcGNpYjA6IG1hdGNoZWQgZW50 cnkgZm9yIDAuMjguSU5UQQpwY2liMDogc2xvdCAyOCBJTlRBIGhhcmR3aXJlZCB0byBJUlEgMTYK Zm91bmQtPgl2ZW5kb3I9MHg4MDg2LCBkZXY9MHgyOTM0LCByZXZpZD0weDAzCglkb21haW49MCwg YnVzPTAsIHNsb3Q9MjksIGZ1bmM9MAoJY2xhc3M9MGMtMDMtMDAsIGhkcnR5cGU9MHgwMCwgbWZk ZXY9MQoJY21kcmVnPTB4MDAwNSwgc3RhdHJlZz0weDAyOTAsIGNhY2hlbG5zej0wIChkd29yZHMp CglsYXR0aW1lcj0weDAwICgwIG5zKSwgbWluZ250PTB4MDAgKDAgbnMpLCBtYXhsYXQ9MHgwMCAo MCBucykKCWludHBpbj1hLCBpcnE9MTAKCW1hcFsyMF06IHR5cGUgSS9PIFBvcnQsIHJhbmdlIDMy LCBiYXNlIDB4MTg4MCwgc2l6ZSAgNSwgZW5hYmxlZApwY2liMDogYWxsb2NhdGVkIHR5cGUgNCAo MHgxODgwLTB4MTg5ZikgZm9yIHJpZCAyMCBvZiBwY2kwOjA6Mjk6MApwY2liMDogbWF0Y2hlZCBl bnRyeSBmb3IgMC4yOS5JTlRBCnBjaWIwOiBzbG90IDI5IElOVEEgaGFyZHdpcmVkIHRvIElSUSAy Mwpmb3VuZC0+CXZlbmRvcj0weDgwODYsIGRldj0weDI5MzUsIHJldmlkPTB4MDMKCWRvbWFpbj0w LCBidXM9MCwgc2xvdD0yOSwgZnVuYz0xCgljbGFzcz0wYy0wMy0wMCwgaGRydHlwZT0weDAwLCBt ZmRldj0wCgljbWRyZWc9MHgwMDA1LCBzdGF0cmVnPTB4MDI5MCwgY2FjaGVsbnN6PTAgKGR3b3Jk cykKCWxhdHRpbWVyPTB4MDAgKDAgbnMpLCBtaW5nbnQ9MHgwMCAoMCBucyksIG1heGxhdD0weDAw ICgwIG5zKQoJaW50cGluPWIsIGlycT0xMQoJbWFwWzIwXTogdHlwZSBJL08gUG9ydCwgcmFuZ2Ug MzIsIGJhc2UgMHgxOGEwLCBzaXplICA1LCBlbmFibGVkCnBjaWIwOiBhbGxvY2F0ZWQgdHlwZSA0 ICgweDE4YTAtMHgxOGJmKSBmb3IgcmlkIDIwIG9mIHBjaTA6MDoyOToxCnBjaWIwOiBtYXRjaGVk IGVudHJ5IGZvciAwLjI5LklOVEIKcGNpYjA6IHNsb3QgMjkgSU5UQiBoYXJkd2lyZWQgdG8gSVJR IDE3CmZvdW5kLT4JdmVuZG9yPTB4ODA4NiwgZGV2PTB4MjkzNiwgcmV2aWQ9MHgwMwoJZG9tYWlu PTAsIGJ1cz0wLCBzbG90PTI5LCBmdW5jPTIKCWNsYXNzPTBjLTAzLTAwLCBoZHJ0eXBlPTB4MDAs IG1mZGV2PTAKCWNtZHJlZz0weDAwMDUsIHN0YXRyZWc9MHgwMjkwLCBjYWNoZWxuc3o9MCAoZHdv cmRzKQoJbGF0dGltZXI9MHgwMCAoMCBucyksIG1pbmdudD0weDAwICgwIG5zKSwgbWF4bGF0PTB4 MDAgKDAgbnMpCglpbnRwaW49YywgaXJxPTEwCgltYXBbMjBdOiB0eXBlIEkvTyBQb3J0LCByYW5n ZSAzMiwgYmFzZSAweDE4YzAsIHNpemUgIDUsIGVuYWJsZWQKcGNpYjA6IGFsbG9jYXRlZCB0eXBl IDQgKDB4MThjMC0weDE4ZGYpIGZvciByaWQgMjAgb2YgcGNpMDowOjI5OjIKcGNpYjA6IG1hdGNo ZWQgZW50cnkgZm9yIDAuMjkuSU5UQwpwY2liMDogc2xvdCAyOSBJTlRDIGhhcmR3aXJlZCB0byBJ UlEgMTgKZm91bmQtPgl2ZW5kb3I9MHg4MDg2LCBkZXY9MHgyOTNhLCByZXZpZD0weDAzCglkb21h aW49MCwgYnVzPTAsIHNsb3Q9MjksIGZ1bmM9NwoJY2xhc3M9MGMtMDMtMjAsIGhkcnR5cGU9MHgw MCwgbWZkZXY9MAoJY21kcmVnPTB4MDEwNiwgc3RhdHJlZz0weDAyOTAsIGNhY2hlbG5zej0wIChk d29yZHMpCglsYXR0aW1lcj0weDAwICgwIG5zKSwgbWluZ250PTB4MDAgKDAgbnMpLCBtYXhsYXQ9 MHgwMCAoMCBucykKCWludHBpbj1hLCBpcnE9MTAKCXBvd2Vyc3BlYyAyICBzdXBwb3J0cyBEMCBE MyAgY3VycmVudCBEMAoJbWFwWzEwXTogdHlwZSBNZW1vcnksIHJhbmdlIDMyLCBiYXNlIDB4ZjRh MDRjMDAsIHNpemUgMTAsIGVuYWJsZWQKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4ZjRhMDRj MDAtMHhmNGEwNGZmZikgZm9yIHJpZCAxMCBvZiBwY2kwOjA6Mjk6NwpwY2liMDogbWF0Y2hlZCBl bnRyeSBmb3IgMC4yOS5JTlRBCnBjaWIwOiBzbG90IDI5IElOVEEgaGFyZHdpcmVkIHRvIElSUSAy Mwpmb3VuZC0+CXZlbmRvcj0weDgwODYsIGRldj0weDI0NDgsIHJldmlkPTB4OTMKCWRvbWFpbj0w LCBidXM9MCwgc2xvdD0zMCwgZnVuYz0wCgljbGFzcz0wNi0wNC0wMSwgaGRydHlwZT0weDAxLCBt ZmRldj0wCgljbWRyZWc9MHgwMTA3LCBzdGF0cmVnPTB4MDAxMCwgY2FjaGVsbnN6PTAgKGR3b3Jk cykKCWxhdHRpbWVyPTB4MDAgKDAgbnMpLCBtaW5nbnQ9MHgwNCAoMTAwMCBucyksIG1heGxhdD0w eDAwICgwIG5zKQpmb3VuZC0+CXZlbmRvcj0weDgwODYsIGRldj0weDI5MTksIHJldmlkPTB4MDMK CWRvbWFpbj0wLCBidXM9MCwgc2xvdD0zMSwgZnVuYz0wCgljbGFzcz0wNi0wMS0wMCwgaGRydHlw ZT0weDAwLCBtZmRldj0xCgljbWRyZWc9MHgwMDA3LCBzdGF0cmVnPTB4MDIxMCwgY2FjaGVsbnN6 PTAgKGR3b3JkcykKCWxhdHRpbWVyPTB4MDAgKDAgbnMpLCBtaW5nbnQ9MHgwMCAoMCBucyksIG1h eGxhdD0weDAwICgwIG5zKQpmb3VuZC0+CXZlbmRvcj0weDgwODYsIGRldj0weDI5MjksIHJldmlk PTB4MDMKCWRvbWFpbj0wLCBidXM9MCwgc2xvdD0zMSwgZnVuYz0yCgljbGFzcz0wMS0wNi0wMSwg aGRydHlwZT0weDAwLCBtZmRldj0wCgljbWRyZWc9MHgwMDA3LCBzdGF0cmVnPTB4MDJiMCwgY2Fj aGVsbnN6PTAgKGR3b3JkcykKCWxhdHRpbWVyPTB4MDAgKDAgbnMpLCBtaW5nbnQ9MHgwMCAoMCBu cyksIG1heGxhdD0weDAwICgwIG5zKQoJaW50cGluPWIsIGlycT0xMAoJcG93ZXJzcGVjIDMgIHN1 cHBvcnRzIEQwIEQzICBjdXJyZW50IEQwCglNU0kgc3VwcG9ydHMgMTYgbWVzc2FnZXMKCW1hcFsx MF06IHR5cGUgSS9PIFBvcnQsIHJhbmdlIDMyLCBiYXNlIDB4MTgxOCwgc2l6ZSAgMywgZW5hYmxl ZApwY2liMDogYWxsb2NhdGVkIHR5cGUgNCAoMHgxODE4LTB4MTgxZikgZm9yIHJpZCAxMCBvZiBw Y2kwOjA6MzE6MgoJbWFwWzE0XTogdHlwZSBJL08gUG9ydCwgcmFuZ2UgMzIsIGJhc2UgMHgxODBj LCBzaXplICAyLCBlbmFibGVkCnBjaWIwOiBhbGxvY2F0ZWQgdHlwZSA0ICgweDE4MGMtMHgxODBm KSBmb3IgcmlkIDE0IG9mIHBjaTA6MDozMToyCgltYXBbMThdOiB0eXBlIEkvTyBQb3J0LCByYW5n ZSAzMiwgYmFzZSAweDE4MTAsIHNpemUgIDMsIGVuYWJsZWQKcGNpYjA6IGFsbG9jYXRlZCB0eXBl IDQgKDB4MTgxMC0weDE4MTcpIGZvciByaWQgMTggb2YgcGNpMDowOjMxOjIKCW1hcFsxY106IHR5 cGUgSS9PIFBvcnQsIHJhbmdlIDMyLCBiYXNlIDB4MTgwOCwgc2l6ZSAgMiwgZW5hYmxlZApwY2li MDogYWxsb2NhdGVkIHR5cGUgNCAoMHgxODA4LTB4MTgwYikgZm9yIHJpZCAxYyBvZiBwY2kwOjA6 MzE6MgoJbWFwWzIwXTogdHlwZSBJL08gUG9ydCwgcmFuZ2UgMzIsIGJhc2UgMHgxOGUwLCBzaXpl ICA1LCBlbmFibGVkCnBjaWIwOiBhbGxvY2F0ZWQgdHlwZSA0ICgweDE4ZTAtMHgxOGZmKSBmb3Ig cmlkIDIwIG9mIHBjaTA6MDozMToyCgltYXBbMjRdOiB0eXBlIE1lbW9yeSwgcmFuZ2UgMzIsIGJh c2UgMHhmNGEwNDAwMCwgc2l6ZSAxMSwgZW5hYmxlZApwY2liMDogYWxsb2NhdGVkIHR5cGUgMyAo MHhmNGEwNDAwMC0weGY0YTA0N2ZmKSBmb3IgcmlkIDI0IG9mIHBjaTA6MDozMToyCnBjaWIwOiBt YXRjaGVkIGVudHJ5IGZvciAwLjMxLklOVEIKcGNpYjA6IHNsb3QgMzEgSU5UQiBoYXJkd2lyZWQg dG8gSVJRIDE5CmZvdW5kLT4JdmVuZG9yPTB4ODA4NiwgZGV2PTB4MjkzMCwgcmV2aWQ9MHgwMwoJ ZG9tYWluPTAsIGJ1cz0wLCBzbG90PTMxLCBmdW5jPTMKCWNsYXNzPTBjLTA1LTAwLCBoZHJ0eXBl PTB4MDAsIG1mZGV2PTAKCWNtZHJlZz0weDAxMDMsIHN0YXRyZWc9MHgwMjgwLCBjYWNoZWxuc3o9 MCAoZHdvcmRzKQoJbGF0dGltZXI9MHgwMCAoMCBucyksIG1pbmdudD0weDAwICgwIG5zKSwgbWF4 bGF0PTB4MDAgKDAgbnMpCglpbnRwaW49YywgaXJxPTEwCgltYXBbMTBdOiB0eXBlIE1lbW9yeSwg cmFuZ2UgNjQsIGJhc2UgMCwgc2l6ZSAgOCwgZW5hYmxlZAoJbWFwWzIwXTogdHlwZSBJL08gUG9y dCwgcmFuZ2UgMzIsIGJhc2UgMHgxYzAwLCBzaXplICA1LCBlbmFibGVkCnBjaWIwOiBhbGxvY2F0 ZWQgdHlwZSA0ICgweDFjMDAtMHgxYzFmKSBmb3IgcmlkIDIwIG9mIHBjaTA6MDozMTozCnBjaWIw OiBtYXRjaGVkIGVudHJ5IGZvciAwLjMxLklOVEMKcGNpYjA6IHNsb3QgMzEgSU5UQyBoYXJkd2ly ZWQgdG8gSVJRIDE5CnZnYXBjaTA6IDxWR0EtY29tcGF0aWJsZSBkaXNwbGF5PiBwb3J0IDB4MTgw MC0weDE4MDcgbWVtIDB4ZjQwMDAwMDAtMHhmNDNmZmZmZiwweGQwMDAwMDAwLTB4ZGZmZmZmZmYg aXJxIDE2IGF0IGRldmljZSAyLjAgb24gcGNpMAphZ3AwOiA8SW50ZWwgR000NSBTVkdBIGNvbnRy b2xsZXI+IG9uIHZnYXBjaTAKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4ODAwMDAwMDAtMHg4 MDAwMGZmZikgZm9yIHJpZCA2NCBvZiBhZ3AwCmFncDA6IEFsbG9jYXRlZCBmbHVzaCBwYWdlIHBo eXMgMHg4MDAwMDAwMCB2aXJ0IDB4ZmZmZmY4MDA4MDAwMDAwMAphZ3AwOiBhcGVydHVyZSBzaXpl IGlzIDI1Nk0sIGRldGVjdGVkIDY1NTMyayBzdG9sZW4gbWVtb3J5CmFncDA6IEFHUF9JOTY1X1BH VEJMX0NUTDI6IDAwMDAwMDAwCmFncDA6IEFHUF9JODU1X0dDQzE6IDB4NzAKYWdwMDogQUdQX0k5 NjVfTVNBQzogMHgwMAphZ3AwOiBNYXBwYWJsZSBHVFQgZW50cmllczogNjU1MzYKYWdwMDogVG90 YWwgR1RUIGVudHJpZXM6IDUyNDI4OAp2Z2FwY2kwOiBCb290IHZpZGVvIGRldmljZQp2Z2FwY2kx OiA8VkdBLWNvbXBhdGlibGUgZGlzcGxheT4gbWVtIDB4ZjQ0MDAwMDAtMHhmNDRmZmZmZiBhdCBk ZXZpY2UgMi4xIG9uIHBjaTAKdWhjaTA6IDxJbnRlbCA4MjgwMUkgKElDSDkpIFVTQiBjb250cm9s bGVyPiBwb3J0IDB4MTgyMC0weDE4M2YgaXJxIDIwIGF0IGRldmljZSAyNi4wIG9uIHBjaTAKdXNi dXMwIG9uIHVoY2kwCnVoY2kwOiB1c2JwZjogQXR0YWNoZWQKdWhjaTE6IDxJbnRlbCA4MjgwMUkg KElDSDkpIFVTQiBjb250cm9sbGVyPiBwb3J0IDB4MTg0MC0weDE4NWYgaXJxIDIwIGF0IGRldmlj ZSAyNi4xIG9uIHBjaTAKdXNidXMxIG9uIHVoY2kxCnVoY2kxOiB1c2JwZjogQXR0YWNoZWQKdWhj aTI6IDxJbnRlbCA4MjgwMUkgKElDSDkpIFVTQiBjb250cm9sbGVyPiBwb3J0IDB4MTg2MC0weDE4 N2YgaXJxIDIwIGF0IGRldmljZSAyNi4yIG9uIHBjaTAKdXNidXMyIG9uIHVoY2kyCnVoY2kyOiB1 c2JwZjogQXR0YWNoZWQKZWhjaTA6IDxJbnRlbCA4MjgwMUkgKElDSDkpIFVTQiAyLjAgY29udHJv bGxlcj4gbWVtIDB4ZjRhMDQ4MDAtMHhmNGEwNGJmZiBpcnEgMjAgYXQgZGV2aWNlIDI2Ljcgb24g cGNpMAp1c2J1czM6IEVIQ0kgdmVyc2lvbiAxLjAKdXNidXMzIG9uIGVoY2kwCmVoY2kwOiB1c2Jw ZjogQXR0YWNoZWQKaGRhYzA6IDxJbnRlbCA4MjgwMUkgSERBIENvbnRyb2xsZXI+IG1lbSAweGY0 ODAwMDAwLTB4ZjQ4MDNmZmYgaXJxIDIxIGF0IGRldmljZSAyNy4wIG9uIHBjaTAKaGRhYzA6IFBD SSBjYXJkIHZlbmRvcjogMHgxMDI1LCBkZXZpY2U6IDB4MDEzYwpoZGFjMDogSERBIERyaXZlciBS ZXZpc2lvbjogMjAxMjAxMjZfMDAwMgpoZGFjMDogQ29uZmlnIG9wdGlvbnM6IG9uPTB4MDAwMDAw MDAgb2ZmPTB4MDAwMDAwMDAKaGRhYzA6IGF0dGVtcHRpbmcgdG8gYWxsb2NhdGUgMSBNU0kgdmVj dG9ycyAoMSBzdXBwb3J0ZWQpCm1zaTogcm91dGluZyBNU0kgSVJRIDI1NiB0byBsb2NhbCBBUElD IDAgdmVjdG9yIDUyCmhkYWMwOiB1c2luZyBJUlEgMjU2IGZvciBNU0kKaGRhYzA6IENhcHM6IE9T UyA0LCBJU1MgNCwgQlNTIDAsIE5TRE8gMSwgNjRiaXQsIENPUkIgMjU2LCBSSVJCIDI1NgpwY2li MTogPEFDUEkgUENJLVBDSSBicmlkZ2U+IGlycSAxNiBhdCBkZXZpY2UgMjguMCBvbiBwY2kwCnBj aWIwOiBhbGxvY2F0ZWQgdHlwZSAzICgweGY0NTAwMDAwLTB4ZjQ1ZmZmZmYpIGZvciByaWQgMjAg b2YgcGNpYjEKcGNpYjE6ICAgZG9tYWluICAgICAgICAgICAgMApwY2liMTogICBzZWNvbmRhcnkg YnVzICAgICAyCnBjaWIxOiAgIHN1Ym9yZGluYXRlIGJ1cyAgIDIKcGNpYjE6ICAgbWVtb3J5IGRl Y29kZSAgICAgMHhmNDUwMDAwMC0weGY0NWZmZmZmCnBjaWIxOiAgIHNwZWNpYWwgZGVjb2RlICAg IElTQQpwY2kyOiA8QUNQSSBQQ0kgYnVzPiBvbiBwY2liMQpwY2kyOiBkb21haW49MCwgcGh5c2lj YWwgYnVzPTIKZm91bmQtPgl2ZW5kb3I9MHgxNGU0LCBkZXY9MHgxNjg0LCByZXZpZD0weDEwCglk b21haW49MCwgYnVzPTIsIHNsb3Q9MCwgZnVuYz0wCgljbGFzcz0wMi0wMC0wMCwgaGRydHlwZT0w eDAwLCBtZmRldj0wCgljbWRyZWc9MHgwMTA2LCBzdGF0cmVnPTB4MDAxMCwgY2FjaGVsbnN6PTE2 IChkd29yZHMpCglsYXR0aW1lcj0weDAwICgwIG5zKSwgbWluZ250PTB4MDAgKDAgbnMpLCBtYXhs YXQ9MHgwMCAoMCBucykKCWludHBpbj1hLCBpcnE9MTEKCXBvd2Vyc3BlYyAzICBzdXBwb3J0cyBE MCBEMyAgY3VycmVudCBEMAoJTVNJIHN1cHBvcnRzIDEgbWVzc2FnZSwgNjQgYml0CgltYXBbMTBd OiB0eXBlIE1lbW9yeSwgcmFuZ2UgNjQsIGJhc2UgMHhmNDUwMDAwMCwgc2l6ZSAxNiwgZW5hYmxl ZApwY2liMTogYWxsb2NhdGVkIG1lbW9yeSByYW5nZSAoMHhmNDUwMDAwMC0weGY0NTBmZmZmKSBm b3IgcmlkIDEwIG9mIHBjaTA6MjowOjAKcGNpYjE6IG1hdGNoZWQgZW50cnkgZm9yIDIuMC5JTlRB CnBjaWIxOiBzbG90IDAgSU5UQSBoYXJkd2lyZWQgdG8gSVJRIDE2CmJnZTA6IDxCcm9hZGNvbSBO ZXRYdHJlbWUgRmFzdCBFdGhlcm5ldCBDb250cm9sbGVyLCBBU0lDIHJldi4gMHg1Nzg0MTAwPiBt ZW0gMHhmNDUwMDAwMC0weGY0NTBmZmZmIGlycSAxNiBhdCBkZXZpY2UgMC4wIG9uIHBjaTIKYmdl MDogYXR0ZW1wdGluZyB0byBhbGxvY2F0ZSAxIE1TSSB2ZWN0b3JzICgxIHN1cHBvcnRlZCkKbXNp OiByb3V0aW5nIE1TSSBJUlEgMjU3IHRvIGxvY2FsIEFQSUMgMCB2ZWN0b3IgNTMKYmdlMDogdXNp bmcgSVJRIDI1NyBmb3IgTVNJCmJnZTA6IENISVAgSUQgMHgwNTc4NDEwMDsgQVNJQyBSRVYgMHg1 Nzg0OyBDSElQIFJFViAweDU3ODQxOyBQQ0ktRQpiZ2UwOiBEaXNhYmxpbmcgZmFzdGJvb3QKbWlp YnVzMDogPE1JSSBidXM+IG9uIGJnZTAKYnJncGh5MDogPEJDTTU3ODQgMTAvMTAwLzEwMDBiYXNl VCBQSFk+IFBIWSAxIG9uIG1paWJ1czAKYnJncGh5MDogT1VJIDB4MDAwYWY3LCBtb2RlbCAweDAw M2EsIHJldi4gNApicmdwaHkwOiAgMTBiYXNlVCwgMTBiYXNlVC1GRFgsIDEwMGJhc2VUWCwgMTAw YmFzZVRYLUZEWCwgMTAwMGJhc2VULCAxMDAwYmFzZVQtbWFzdGVyLCAxMDAwYmFzZVQtRkRYLCAx MDAwYmFzZVQtRkRYLW1hc3RlciwgYXV0bywgYXV0by1mbG93CmJnZTA6IGJwZiBhdHRhY2hlZApi Z2UwOiBFdGhlcm5ldCBhZGRyZXNzOiAwMDoxZDo3MjpmYjo5YTo3YgpwY2liMjogPEFDUEkgUENJ LVBDSSBicmlkZ2U+IGlycSAxNyBhdCBkZXZpY2UgMjguMSBvbiBwY2kwCnBjaWIwOiBhbGxvY2F0 ZWQgdHlwZSAzICgweGY0NjAwMDAwLTB4ZjQ2ZmZmZmYpIGZvciByaWQgMjAgb2YgcGNpYjIKcGNp YjI6ICAgZG9tYWluICAgICAgICAgICAgMApwY2liMjogICBzZWNvbmRhcnkgYnVzICAgICAzCnBj aWIyOiAgIHN1Ym9yZGluYXRlIGJ1cyAgIDMKcGNpYjI6ICAgbWVtb3J5IGRlY29kZSAgICAgMHhm NDYwMDAwMC0weGY0NmZmZmZmCnBjaWIyOiAgIHNwZWNpYWwgZGVjb2RlICAgIElTQQpwY2kzOiA8 QUNQSSBQQ0kgYnVzPiBvbiBwY2liMgpwY2kzOiBkb21haW49MCwgcGh5c2ljYWwgYnVzPTMKZm91 bmQtPgl2ZW5kb3I9MHgxNjhjLCBkZXY9MHgwMDJhLCByZXZpZD0weDAxCglkb21haW49MCwgYnVz PTMsIHNsb3Q9MCwgZnVuYz0wCgljbGFzcz0wMi04MC0wMCwgaGRydHlwZT0weDAwLCBtZmRldj0w CgljbWRyZWc9MHgwMTA3LCBzdGF0cmVnPTB4MDAxMCwgY2FjaGVsbnN6PTE2IChkd29yZHMpCgls YXR0aW1lcj0weDAwICgwIG5zKSwgbWluZ250PTB4MDAgKDAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBu cykKCWludHBpbj1hLCBpcnE9MTEKCXBvd2Vyc3BlYyAyICBzdXBwb3J0cyBEMCBEMSBEMyAgY3Vy cmVudCBEMAoJTVNJIHN1cHBvcnRzIDEgbWVzc2FnZQoJTVNJLVggc3VwcG9ydHMgMSBtZXNzYWdl IGluIG1hcCAweDEwCgltYXBbMTBdOiB0eXBlIE1lbW9yeSwgcmFuZ2UgNjQsIGJhc2UgMHhmNDYw MDAwMCwgc2l6ZSAxNiwgZW5hYmxlZApwY2liMjogYWxsb2NhdGVkIG1lbW9yeSByYW5nZSAoMHhm NDYwMDAwMC0weGY0NjBmZmZmKSBmb3IgcmlkIDEwIG9mIHBjaTA6MzowOjAKcGNpYjI6IG1hdGNo ZWQgZW50cnkgZm9yIDMuMC5JTlRBCnBjaWIyOiBzbG90IDAgSU5UQSBoYXJkd2lyZWQgdG8gSVJR IDE3CmF0aDA6IDxBdGhlcm9zIDkyODA+IG1lbSAweGY0NjAwMDAwLTB4ZjQ2MGZmZmYgaXJxIDE3 IGF0IGRldmljZSAwLjAgb24gcGNpMwppb2FwaWMwOiByb3V0aW5nIGludHBpbiAxNyAoUENJIElS USAxNykgdG8gbGFwaWMgMCB2ZWN0b3IgNTQKYXRoMDogW0hUXSBlbmFibGluZyBIVCBtb2Rlcwph dGgwOiBbSFRdIDEgc3RyZWFtIFNUQkMgcmVjZWl2ZSBlbmFibGVkCmF0aDA6IFtIVF0gMiBSWCBz dHJlYW1zOyAxIFRYIHN0cmVhbXMKYXRoMDogMTFiIHJhdGVzOiAxTWJwcyAyTWJwcyA1LjVNYnBz IDExTWJwcwphdGgwOiAxMWcgcmF0ZXM6IDFNYnBzIDJNYnBzIDUuNU1icHMgMTFNYnBzIDZNYnBz IDlNYnBzIDEyTWJwcyAxOE1icHMgMjRNYnBzIDM2TWJwcyA0OE1icHMgNTRNYnBzCmF0aDA6IDFU MlIKYXRoMDogMTFuZyBNQ1MgMjBNSHoKYXRoMDogTUNTIDAtNzogNi41TWJwcyAtIDY1TWJwcwph dGgwOiAxMW5nIE1DUyA0ME1IejoKYXRoMDogTUNTIDAtNzogMTMuNU1icHMgLSAxMzVNYnBzCmF0 aDA6IDExbmcgTUNTIDQwTUh6IFNHSToKYXRoMDogTUNTIDAtNzogMTVNYnBzIC0gMTUwTWJwcwph dGgwOiBBUjkyODAgbWFjIDEyOC4yIFJGNTEzMyBwaHkgMTMuMAphdGgwOiAyR0h6IHJhZGlvOiAw eDAwMDA7IDVHSHogcmFkaW86IDB4MDBjMAphdGgwOiBVc2UgaHcgcXVldWUgMSBmb3IgV01FX0FD X0JFIHRyYWZmaWMKYXRoMDogVXNlIGh3IHF1ZXVlIDAgZm9yIFdNRV9BQ19CSyB0cmFmZmljCmF0 aDA6IFVzZSBodyBxdWV1ZSAyIGZvciBXTUVfQUNfVkkgdHJhZmZpYwphdGgwOiBVc2UgaHcgcXVl dWUgMyBmb3IgV01FX0FDX1ZPIHRyYWZmaWMKYXRoMDogVXNlIGh3IHF1ZXVlIDggZm9yIENBQiB0 cmFmZmljCmF0aDA6IFVzZSBodyBxdWV1ZSA5IGZvciBiZWFjb25zCmF0aDA6IHVzaW5nIG11bHRp Y2FzdCBrZXkgc2VhcmNoCnBjaWIzOiA8QUNQSSBQQ0ktUENJIGJyaWRnZT4gaXJxIDE2IGF0IGRl dmljZSAyOC40IG9uIHBjaTAKcGNpYjM6IGFsbG9jYXRpbmcgbm9uLUlTQSByYW5nZSAweDIwMDAt MHgyMGZmCnBjaWIwOiBhbGxvY2F0ZWQgdHlwZSA0ICgweDIwMDAtMHgyMGZmKSBmb3IgcmlkIDFj IG9mIHBjaWIzCnBjaWIzOiBhbGxvY2F0aW5nIG5vbi1JU0EgcmFuZ2UgMHgyNDAwLTB4MjRmZgpw Y2liMDogYWxsb2NhdGVkIHR5cGUgNCAoMHgyNDAwLTB4MjRmZikgZm9yIHJpZCAxYyBvZiBwY2li MwpwY2liMzogYWxsb2NhdGluZyBub24tSVNBIHJhbmdlIDB4MjgwMC0weDI4ZmYKcGNpYjA6IGFs bG9jYXRlZCB0eXBlIDQgKDB4MjgwMC0weDI4ZmYpIGZvciByaWQgMWMgb2YgcGNpYjMKcGNpYjM6 IGFsbG9jYXRpbmcgbm9uLUlTQSByYW5nZSAweDJjMDAtMHgyY2ZmCnBjaWIwOiBhbGxvY2F0ZWQg dHlwZSA0ICgweDJjMDAtMHgyY2ZmKSBmb3IgcmlkIDFjIG9mIHBjaWIzCnBjaWIwOiBhbGxvY2F0 ZWQgdHlwZSAzICgweGYyMDAwMDAwLTB4ZjNmZmZmZmYpIGZvciByaWQgMjAgb2YgcGNpYjMKcGNp YjA6IGFsbG9jYXRlZCB0eXBlIDMgKDB4ZjAwMDAwMDAtMHhmMWZmZmZmZikgZm9yIHJpZCAyNCBv ZiBwY2liMwpwY2liMzogICBkb21haW4gICAgICAgICAgICAwCnBjaWIzOiAgIHNlY29uZGFyeSBi dXMgICAgIDQKcGNpYjM6ICAgc3Vib3JkaW5hdGUgYnVzICAgNgpwY2liMzogICBJL08gZGVjb2Rl ICAgICAgICAweDIwMDAtMHgyZmZmCnBjaWIzOiAgIG1lbW9yeSBkZWNvZGUgICAgIDB4ZjIwMDAw MDAtMHhmM2ZmZmZmZgpwY2liMzogICBwcmVmZXRjaGVkIGRlY29kZSAweGYwMDAwMDAwLTB4ZjFm ZmZmZmYKcGNpYjM6ICAgc3BlY2lhbCBkZWNvZGUgICAgSVNBCnBjaTQ6IDxBQ1BJIFBDSSBidXM+ IG9uIHBjaWIzCnBjaTQ6IGRvbWFpbj0wLCBwaHlzaWNhbCBidXM9NAp1aGNpMzogPEludGVsIDgy ODAxSSAoSUNIOSkgVVNCIGNvbnRyb2xsZXI+IHBvcnQgMHgxODgwLTB4MTg5ZiBpcnEgMjMgYXQg ZGV2aWNlIDI5LjAgb24gcGNpMAppb2FwaWMwOiByb3V0aW5nIGludHBpbiAyMyAoUENJIElSUSAy MykgdG8gbGFwaWMgMCB2ZWN0b3IgNTUKdXNidXM0IG9uIHVoY2kzCnVoY2kzOiB1c2JwZjogQXR0 YWNoZWQKdWhjaTQ6IDxJbnRlbCA4MjgwMUkgKElDSDkpIFVTQiBjb250cm9sbGVyPiBwb3J0IDB4 MThhMC0weDE4YmYgaXJxIDE3IGF0IGRldmljZSAyOS4xIG9uIHBjaTAKdXNidXM1IG9uIHVoY2k0 CnVoY2k0OiB1c2JwZjogQXR0YWNoZWQKdWhjaTU6IDxJbnRlbCA4MjgwMUkgKElDSDkpIFVTQiBj b250cm9sbGVyPiBwb3J0IDB4MThjMC0weDE4ZGYgaXJxIDE4IGF0IGRldmljZSAyOS4yIG9uIHBj aTAKaW9hcGljMDogcm91dGluZyBpbnRwaW4gMTggKFBDSSBJUlEgMTgpIHRvIGxhcGljIDAgdmVj dG9yIDU2CnVzYnVzNiBvbiB1aGNpNQp1aGNpNTogdXNicGY6IEF0dGFjaGVkCmVoY2kxOiA8SW50 ZWwgODI4MDFJIChJQ0g5KSBVU0IgMi4wIGNvbnRyb2xsZXI+IG1lbSAweGY0YTA0YzAwLTB4ZjRh MDRmZmYgaXJxIDIzIGF0IGRldmljZSAyOS43IG9uIHBjaTAKdXNidXM3OiBFSENJIHZlcnNpb24g MS4wCnVzYnVzNyBvbiBlaGNpMQplaGNpMTogdXNicGY6IEF0dGFjaGVkCnBjaWI0OiA8QUNQSSBQ Q0ktUENJIGJyaWRnZT4gYXQgZGV2aWNlIDMwLjAgb24gcGNpMApwY2liMDogYWxsb2NhdGVkIHR5 cGUgMyAoMHhmNDcwMDAwMC0weGY0N2ZmZmZmKSBmb3IgcmlkIDIwIG9mIHBjaWI0CnBjaWI0OiAg IGRvbWFpbiAgICAgICAgICAgIDAKcGNpYjQ6ICAgc2Vjb25kYXJ5IGJ1cyAgICAgMTMKcGNpYjQ6 ICAgc3Vib3JkaW5hdGUgYnVzICAgMTQKcGNpYjQ6ICAgbWVtb3J5IGRlY29kZSAgICAgMHhmNDcw MDAwMC0weGY0N2ZmZmZmCnBjaWI0OiAgIHNwZWNpYWwgZGVjb2RlICAgIElTQSwgc3VidHJhY3Rp dmUKcGNpMTM6IDxBQ1BJIFBDSSBidXM+IG9uIHBjaWI0CnBjaTEzOiBkb21haW49MCwgcGh5c2lj YWwgYnVzPTEzCmZvdW5kLT4JdmVuZG9yPTB4MTIxNywgZGV2PTB4NzEzNSwgcmV2aWQ9MHgwMQoJ ZG9tYWluPTAsIGJ1cz0xMywgc2xvdD02LCBmdW5jPTAKCWNsYXNzPTA2LTA3LTAwLCBoZHJ0eXBl PTB4MDIsIG1mZGV2PTEKCWNtZHJlZz0weDAxMDcsIHN0YXRyZWc9MHgwNDEwLCBjYWNoZWxuc3o9 MCAoZHdvcmRzKQoJbGF0dGltZXI9MHg1MSAoMjQzMCBucyksIG1pbmdudD0weGM0ICg0OTAwMCBu cyksIG1heGxhdD0weDAwICgwIG5zKQoJaW50cGluPWEsIGlycT0xMQoJcG93ZXJzcGVjIDIgIHN1 cHBvcnRzIEQwIEQxIEQyIEQzICBjdXJyZW50IEQwCgltYXBbMTBdOiB0eXBlIE1lbW9yeSwgcmFu Z2UgMzIsIGJhc2UgMHhmNDcwMDAwMCwgc2l6ZSAxMiwgZW5hYmxlZApwY2liNDogYWxsb2NhdGVk IG1lbW9yeSByYW5nZSAoMHhmNDcwMDAwMC0weGY0NzAwZmZmKSBmb3IgcmlkIDEwIG9mIHBjaTA6 MTM6NjowCnBjaWI0OiBtYXRjaGVkIGVudHJ5IGZvciAxMy42LklOVEEKcGNpYjQ6IHNsb3QgNiBJ TlRBIGhhcmR3aXJlZCB0byBJUlEgMjIKY2JiMDogPFBDSS1DYXJkQnVzIEJyaWRnZT4gbWVtIDB4 ZjQ3MDAwMDAtMHhmNDcwMGZmZiBpcnEgMjIgYXQgZGV2aWNlIDYuMCBvbiBwY2kxMwpjYXJkYnVz MDogPENhcmRCdXMgYnVzPiBvbiBjYmIwCnBjY2FyZDA6IDwxNi1iaXQgUENDYXJkIGJ1cz4gb24g Y2JiMAppb2FwaWMwOiByb3V0aW5nIGludHBpbiAyMiAoUENJIElSUSAyMikgdG8gbGFwaWMgMCB2 ZWN0b3IgNTcKY2JiMDogUENJIENvbmZpZ3VyYXRpb24gc3BhY2U6CiAgMHgwMDogMHg3MTM1MTIx NyAweDA0MTAwMTA3IDB4MDYwNzAwMDEgMHgwMDgyNTEwMCAKICAweDEwOiAweGY0NzAwMDAwIDB4 MDIwMDAwYTAgMHgyMDBlMGUwZCAweGZmZmZmMDAwIAogIDB4MjA6IDB4MDAwMDAwMDAgMHhmZmZm ZjAwMCAweDAwMDAwMDAwIDB4MDAwMGZmZmQgCiAgMHgzMDogMHgwMDAwMDAwMSAweDAwMDBmZmZk IDB4MDAwMDAwMDEgMHgwNDQ0MDExNiAKICAweDQwOiAweDAxM2MxMDI1IDB4MDAwMDAwMDEgMHgw MDAwMDAwMCAweDAwMDAwMDAwIAogIDB4NTA6IDB4MDAwMDAwMDAgMHgwMDAwMDAwMCAweDAwMDAw MDAwIDB4MDAwMDAwMDAgCiAgMHg2MDogMHgwMDAwMDAwMCAweDAwMDAwMDAwIDB4MDAwMDAwMDAg MHgwMDAwMDAwMCAKICAweDcwOiAweDAwMDAwMDAwIDB4MDAwMDAwMDAgMHgwMDAwMDAwMCAweDAw MDAwMDAwIAogIDB4ODA6IDB4MDAwMDAwMDAgMHgwMDAwMDAwMCAweDAwMDAwMDAwIDB4MDAwMDAw MDAgCiAgMHg5MDogMHgwMDI1MjQwNiAweDAwMDAwMDAwIDB4MDAwMDAwMDAgMHgwMDAwMDAwMCAK ICAweGEwOiAweGZlMDIwMDAxIDB4MDBjMDQwMDAgMHgwMDAwMDAwMCAweDAwMDAwMDAwIAogIDB4 YjA6IDB4MDAwMDAwMDAgMHgwMDAwMDAwMCAweDAwMDAwMDAwIDB4MDAwMDAwMDAgCiAgMHhjMDog MHgwMDAwMDAwMCAweDAwMDAwMDAwIDB4MDAwMDAwMDAgMHgwMDAwMDAwMCAKICAweGQwOiAweDA5 MDA0MTAwIDB4ODA4MjBiZWEgMHgwMDAwMDAwMCAweDAwNDAwMTE4IAogIDB4ZTA6IDB4MDA4MjIw MDYgMHgwMDA3NDBlNyAweDBhNjAwMDAwIDB4MDEwMjAwMDcgCiAgMHhmMDogMHgwMDAwMDAwMCAw eDAwMDAwMDAwIDB4MDAwMDAwMDAgMHgwMDAwMDAwMCAKaXNhYjA6IDxQQ0ktSVNBIGJyaWRnZT4g YXQgZGV2aWNlIDMxLjAgb24gcGNpMAppc2EwOiA8SVNBIGJ1cz4gb24gaXNhYjAKYWhjaTA6IDxJ bnRlbCBJQ0g5TSBBSENJIFNBVEEgY29udHJvbGxlcj4gcG9ydCAweDE4MTgtMHgxODFmLDB4MTgw Yy0weDE4MGYsMHgxODEwLTB4MTgxNywweDE4MDgtMHgxODBiLDB4MThlMC0weDE4ZmYgbWVtIDB4 ZjRhMDQwMDAtMHhmNGEwNDdmZiBpcnEgMTkgYXQgZGV2aWNlIDMxLjIgb24gcGNpMAphaGNpMDog YXR0ZW1wdGluZyB0byBhbGxvY2F0ZSAxIE1TSSB2ZWN0b3JzICgxNiBzdXBwb3J0ZWQpCm1zaTog cm91dGluZyBNU0kgSVJRIDI1OCB0byBsb2NhbCBBUElDIDAgdmVjdG9yIDU4CmFoY2kwOiB1c2lu ZyBJUlEgMjU4IGZvciBNU0kKYWhjaTA6IEFIQ0kgdjEuMjAgd2l0aCA0IDNHYnBzIHBvcnRzLCBQ b3J0IE11bHRpcGxpZXIgbm90IHN1cHBvcnRlZAphaGNpMDogQ2FwczogNjRiaXQgTkNRIFNOVEYg U1MgQUxQIEFMIENMTyAzR2JwcyBQTUQgU1NDIFBTQyAzMmNtZCBDQ0MgRU0gZVNBVEEgNHBvcnRz CmFoY2kwOiBDYXBzMjoKYWhjaWNoMDogPEFIQ0kgY2hhbm5lbD4gYXQgY2hhbm5lbCAwIG9uIGFo Y2kwCmFoY2ljaDA6IENhcHM6CmFoY2ljaDE6IDxBSENJIGNoYW5uZWw+IGF0IGNoYW5uZWwgMSBv biBhaGNpMAphaGNpY2gxOiBDYXBzOgphaGNpY2gyOiBub3QgcHJvYmVkIChkaXNhYmxlZCkKYWhj aWNoMzogbm90IHByb2JlZCAoZGlzYWJsZWQpCmFoY2ljaDQ6IDxBSENJIGNoYW5uZWw+IGF0IGNo YW5uZWwgNCBvbiBhaGNpMAphaGNpY2g0OiBDYXBzOiBIUENQIEVTUAphaGNpY2g1OiA8QUhDSSBj aGFubmVsPiBhdCBjaGFubmVsIDUgb24gYWhjaTAKYWhjaWNoNTogQ2FwczoKYWhjaWVtMDogPEFI Q0kgZW5jbG9zdXJlIG1hbmFnZW1lbnQgYnJpZGdlPiBvbiBhaGNpMAphaGNpZW0wOiBDYXBzOiBB TEhEIFhNVCBTTUIgTEVECnBjaTA6IDxzZXJpYWwgYnVzLCBTTUJ1cz4gYXQgZGV2aWNlIDMxLjMg KG5vIGRyaXZlciBhdHRhY2hlZCkKYWNwaV9saWQwOiA8Q29udHJvbCBNZXRob2QgTGlkIFN3aXRj aD4gb24gYWNwaTAKYWNwaV9idXR0b24wOiA8U2xlZXAgQnV0dG9uPiBvbiBhY3BpMAphY3BpX3R6 MDogPFRoZXJtYWwgWm9uZT4gb24gYWNwaTAKYWNwaV90ejE6IDxUaGVybWFsIFpvbmU+IG9uIGFj cGkwCmF0a2JkYzA6IDxLZXlib2FyZCBjb250cm9sbGVyIChpODA0Mik+IHBvcnQgMHg2MCwweDY0 IGlycSAxIG9uIGFjcGkwCmF0a2JkMDogPEFUIEtleWJvYXJkPiBpcnEgMSBvbiBhdGtiZGMwCmF0 a2JkOiB0aGUgY3VycmVudCBrYmQgY29udHJvbGxlciBjb21tYW5kIGJ5dGUgMDA0NwphdGtiZDog a2V5Ym9hcmQgSUQgMHg0MWFiICgyKQprYmQwIGF0IGF0a2JkMAprYmQwOiBhdGtiZDAsIEFUIDEw MS8xMDIgKDIpLCBjb25maWc6MHgwLCBmbGFnczoweDNkMDAwMAppb2FwaWMwOiByb3V0aW5nIGlu dHBpbiAxIChJU0EgSVJRIDEpIHRvIGxhcGljIDAgdmVjdG9yIDU5CmF0a2JkMDogW0dJQU5ULUxP Q0tFRF0KcHNtMDogdW5hYmxlIHRvIGFsbG9jYXRlIElSUQpwc21jcG5wMDogPFBTLzIgbW91c2Ug cG9ydD4gaXJxIDEyIG9uIGFjcGkwCnBzbTA6IGN1cnJlbnQgY29tbWFuZCBieXRlOjAwNDcKcHNt MDogPFBTLzIgTW91c2U+IGlycSAxMiBvbiBhdGtiZGMwCmlvYXBpYzA6IHJvdXRpbmcgaW50cGlu IDEyIChJU0EgSVJRIDEyKSB0byBsYXBpYyAwIHZlY3RvciA2MApwc20wOiBbR0lBTlQtTE9DS0VE XQpwc20wOiBtb2RlbCBHbGlkZVBvaW50LCBkZXZpY2UgSUQgMC0wMCwgMiBidXR0b25zCnBzbTA6 IGNvbmZpZzowMDAwNDAwMCwgZmxhZ3M6MDAwMDAwMDgsIHBhY2tldCBzaXplOjMKcHNtMDogc3lu Y21hc2s6YzAsIHN5bmNiaXRzOjAwCmJhdHRlcnkwOiA8QUNQSSBDb250cm9sIE1ldGhvZCBCYXR0 ZXJ5PiBvbiBhY3BpMAphY3BpX2FjYWQwOiA8QUMgQWRhcHRlcj4gb24gYWNwaTAKQUNQSTogRW5h YmxlZCA0IEdQRXMgaW4gYmxvY2sgMDAgdG8gM0YKYWNwaTA6IHdha2V1cCBjb2RlIHZhIDB4ZmZm ZmZlMDA5Mjk3ODAwMCBwYSAweDk0MDAwCmV4X2lzYV9pZGVudGlmeSgpCmFoY19pc2FfaWRlbnRp ZnkgMDogaW9wb3J0IDB4YzAwIGFsbG9jIGZhaWxlZAphaGNfaXNhX2lkZW50aWZ5IDE6IGlvcG9y dCAweDFjMDAgYWxsb2MgZmFpbGVkCmFoY19pc2FfaWRlbnRpZnkgMjogaW9wb3J0IDB4MmMwMCBh bGxvYyBmYWlsZWQKYWhjX2lzYV9pZGVudGlmeSAzOiBpb3BvcnQgMHgzYzAwIGFsbG9jIGZhaWxl ZAphaGNfaXNhX2lkZW50aWZ5IDQ6IGlvcG9ydCAweDRjMDAgYWxsb2MgZmFpbGVkCmFoY19pc2Ff aWRlbnRpZnkgNTogaW9wb3J0IDB4NWMwMCBhbGxvYyBmYWlsZWQKYWhjX2lzYV9pZGVudGlmeSA2 OiBpb3BvcnQgMHg2YzAwIGFsbG9jIGZhaWxlZAphaGNfaXNhX2lkZW50aWZ5IDc6IGlvcG9ydCAw eDdjMDAgYWxsb2MgZmFpbGVkCmFoY19pc2FfaWRlbnRpZnkgODogaW9wb3J0IDB4OGMwMCBhbGxv YyBmYWlsZWQKYWhjX2lzYV9pZGVudGlmeSA5OiBpb3BvcnQgMHg5YzAwIGFsbG9jIGZhaWxlZAph aGNfaXNhX2lkZW50aWZ5IDEwOiBpb3BvcnQgMHhhYzAwIGFsbG9jIGZhaWxlZAphaGNfaXNhX2lk ZW50aWZ5IDExOiBpb3BvcnQgMHhiYzAwIGFsbG9jIGZhaWxlZAphaGNfaXNhX2lkZW50aWZ5IDEy OiBpb3BvcnQgMHhjYzAwIGFsbG9jIGZhaWxlZAphaGNfaXNhX2lkZW50aWZ5IDEzOiBpb3BvcnQg MHhkYzAwIGFsbG9jIGZhaWxlZAphaGNfaXNhX2lkZW50aWZ5IDE0OiBpb3BvcnQgMHhlYzAwIGFs bG9jIGZhaWxlZApwY2liMDogYWxsb2NhdGVkIHR5cGUgMyAoMHhhMDAwMC0weGEwN2ZmKSBmb3Ig cmlkIDAgb2Ygb3JtMApwY2liMDogYWxsb2NhdGVkIHR5cGUgMyAoMHhhMDgwMC0weGEwZmZmKSBm b3IgcmlkIDAgb2Ygb3JtMApwY2liMDogYWxsb2NhdGVkIHR5cGUgMyAoMHhhMTAwMC0weGExN2Zm KSBmb3IgcmlkIDAgb2Ygb3JtMApwY2liMDogYWxsb2NhdGVkIHR5cGUgMyAoMHhhMTgwMC0weGEx ZmZmKSBmb3IgcmlkIDAgb2Ygb3JtMApwY2liMDogYWxsb2NhdGVkIHR5cGUgMyAoMHhhMjAwMC0w eGEyN2ZmKSBmb3IgcmlkIDAgb2Ygb3JtMApwY2liMDogYWxsb2NhdGVkIHR5cGUgMyAoMHhhMjgw MC0weGEyZmZmKSBmb3IgcmlkIDAgb2Ygb3JtMApwY2liMDogYWxsb2NhdGVkIHR5cGUgMyAoMHhh MzAwMC0weGEzN2ZmKSBmb3IgcmlkIDAgb2Ygb3JtMApwY2liMDogYWxsb2NhdGVkIHR5cGUgMyAo MHhhMzgwMC0weGEzZmZmKSBmb3IgcmlkIDAgb2Ygb3JtMApwY2liMDogYWxsb2NhdGVkIHR5cGUg MyAoMHhhNDAwMC0weGE0N2ZmKSBmb3IgcmlkIDAgb2Ygb3JtMApwY2liMDogYWxsb2NhdGVkIHR5 cGUgMyAoMHhhNDgwMC0weGE0ZmZmKSBmb3IgcmlkIDAgb2Ygb3JtMApwY2liMDogYWxsb2NhdGVk IHR5cGUgMyAoMHhhNTAwMC0weGE1N2ZmKSBmb3IgcmlkIDAgb2Ygb3JtMApwY2liMDogYWxsb2Nh dGVkIHR5cGUgMyAoMHhhNTgwMC0weGE1ZmZmKSBmb3IgcmlkIDAgb2Ygb3JtMApwY2liMDogYWxs b2NhdGVkIHR5cGUgMyAoMHhhNjAwMC0weGE2N2ZmKSBmb3IgcmlkIDAgb2Ygb3JtMApwY2liMDog YWxsb2NhdGVkIHR5cGUgMyAoMHhhNjgwMC0weGE2ZmZmKSBmb3IgcmlkIDAgb2Ygb3JtMApwY2li MDogYWxsb2NhdGVkIHR5cGUgMyAoMHhhNzAwMC0weGE3N2ZmKSBmb3IgcmlkIDAgb2Ygb3JtMApw Y2liMDogYWxsb2NhdGVkIHR5cGUgMyAoMHhhNzgwMC0weGE3ZmZmKSBmb3IgcmlkIDAgb2Ygb3Jt MApwY2liMDogYWxsb2NhdGVkIHR5cGUgMyAoMHhhODAwMC0weGE4N2ZmKSBmb3IgcmlkIDAgb2Yg b3JtMApwY2liMDogYWxsb2NhdGVkIHR5cGUgMyAoMHhhODgwMC0weGE4ZmZmKSBmb3IgcmlkIDAg b2Ygb3JtMApwY2liMDogYWxsb2NhdGVkIHR5cGUgMyAoMHhhOTAwMC0weGE5N2ZmKSBmb3Igcmlk IDAgb2Ygb3JtMApwY2liMDogYWxsb2NhdGVkIHR5cGUgMyAoMHhhOTgwMC0weGE5ZmZmKSBmb3Ig cmlkIDAgb2Ygb3JtMApwY2liMDogYWxsb2NhdGVkIHR5cGUgMyAoMHhhYTAwMC0weGFhN2ZmKSBm b3IgcmlkIDAgb2Ygb3JtMApwY2liMDogYWxsb2NhdGVkIHR5cGUgMyAoMHhhYTgwMC0weGFhZmZm KSBmb3IgcmlkIDAgb2Ygb3JtMApwY2liMDogYWxsb2NhdGVkIHR5cGUgMyAoMHhhYjAwMC0weGFi N2ZmKSBmb3IgcmlkIDAgb2Ygb3JtMApwY2liMDogYWxsb2NhdGVkIHR5cGUgMyAoMHhhYjgwMC0w eGFiZmZmKSBmb3IgcmlkIDAgb2Ygb3JtMApwY2liMDogYWxsb2NhdGVkIHR5cGUgMyAoMHhhYzAw MC0weGFjN2ZmKSBmb3IgcmlkIDAgb2Ygb3JtMApwY2liMDogYWxsb2NhdGVkIHR5cGUgMyAoMHhh YzgwMC0weGFjZmZmKSBmb3IgcmlkIDAgb2Ygb3JtMApwY2liMDogYWxsb2NhdGVkIHR5cGUgMyAo MHhhZDAwMC0weGFkN2ZmKSBmb3IgcmlkIDAgb2Ygb3JtMApwY2liMDogYWxsb2NhdGVkIHR5cGUg MyAoMHhhZDgwMC0weGFkZmZmKSBmb3IgcmlkIDAgb2Ygb3JtMApwY2liMDogYWxsb2NhdGVkIHR5 cGUgMyAoMHhhZTAwMC0weGFlN2ZmKSBmb3IgcmlkIDAgb2Ygb3JtMApwY2liMDogYWxsb2NhdGVk IHR5cGUgMyAoMHhhZTgwMC0weGFlZmZmKSBmb3IgcmlkIDAgb2Ygb3JtMApwY2liMDogYWxsb2Nh dGVkIHR5cGUgMyAoMHhhZjAwMC0weGFmN2ZmKSBmb3IgcmlkIDAgb2Ygb3JtMApwY2liMDogYWxs b2NhdGVkIHR5cGUgMyAoMHhhZjgwMC0weGFmZmZmKSBmb3IgcmlkIDAgb2Ygb3JtMApwY2liMDog YWxsb2NhdGVkIHR5cGUgMyAoMHhiMDAwMC0weGIwN2ZmKSBmb3IgcmlkIDAgb2Ygb3JtMApwY2li MDogYWxsb2NhdGVkIHR5cGUgMyAoMHhiMDgwMC0weGIwZmZmKSBmb3IgcmlkIDAgb2Ygb3JtMApw Y2liMDogYWxsb2NhdGVkIHR5cGUgMyAoMHhiMTAwMC0weGIxN2ZmKSBmb3IgcmlkIDAgb2Ygb3Jt MApwY2liMDogYWxsb2NhdGVkIHR5cGUgMyAoMHhiMTgwMC0weGIxZmZmKSBmb3IgcmlkIDAgb2Yg b3JtMApwY2liMDogYWxsb2NhdGVkIHR5cGUgMyAoMHhiMjAwMC0weGIyN2ZmKSBmb3IgcmlkIDAg b2Ygb3JtMApwY2liMDogYWxsb2NhdGVkIHR5cGUgMyAoMHhiMjgwMC0weGIyZmZmKSBmb3Igcmlk IDAgb2Ygb3JtMApwY2liMDogYWxsb2NhdGVkIHR5cGUgMyAoMHhiMzAwMC0weGIzN2ZmKSBmb3Ig cmlkIDAgb2Ygb3JtMApwY2liMDogYWxsb2NhdGVkIHR5cGUgMyAoMHhiMzgwMC0weGIzZmZmKSBm b3IgcmlkIDAgb2Ygb3JtMApwY2liMDogYWxsb2NhdGVkIHR5cGUgMyAoMHhiNDAwMC0weGI0N2Zm KSBmb3IgcmlkIDAgb2Ygb3JtMApwY2liMDogYWxsb2NhdGVkIHR5cGUgMyAoMHhiNDgwMC0weGI0 ZmZmKSBmb3IgcmlkIDAgb2Ygb3JtMApwY2liMDogYWxsb2NhdGVkIHR5cGUgMyAoMHhiNTAwMC0w eGI1N2ZmKSBmb3IgcmlkIDAgb2Ygb3JtMApwY2liMDogYWxsb2NhdGVkIHR5cGUgMyAoMHhiNTgw MC0weGI1ZmZmKSBmb3IgcmlkIDAgb2Ygb3JtMApwY2liMDogYWxsb2NhdGVkIHR5cGUgMyAoMHhi NjAwMC0weGI2N2ZmKSBmb3IgcmlkIDAgb2Ygb3JtMApwY2liMDogYWxsb2NhdGVkIHR5cGUgMyAo MHhiNjgwMC0weGI2ZmZmKSBmb3IgcmlkIDAgb2Ygb3JtMApwY2liMDogYWxsb2NhdGVkIHR5cGUg MyAoMHhiNzAwMC0weGI3N2ZmKSBmb3IgcmlkIDAgb2Ygb3JtMApwY2liMDogYWxsb2NhdGVkIHR5 cGUgMyAoMHhiNzgwMC0weGI3ZmZmKSBmb3IgcmlkIDAgb2Ygb3JtMApwY2liMDogYWxsb2NhdGVk IHR5cGUgMyAoMHhiODAwMC0weGI4N2ZmKSBmb3IgcmlkIDAgb2Ygb3JtMApwY2liMDogYWxsb2Nh dGVkIHR5cGUgMyAoMHhiODgwMC0weGI4ZmZmKSBmb3IgcmlkIDAgb2Ygb3JtMApwY2liMDogYWxs b2NhdGVkIHR5cGUgMyAoMHhiOTAwMC0weGI5N2ZmKSBmb3IgcmlkIDAgb2Ygb3JtMApwY2liMDog YWxsb2NhdGVkIHR5cGUgMyAoMHhiOTgwMC0weGI5ZmZmKSBmb3IgcmlkIDAgb2Ygb3JtMApwY2li MDogYWxsb2NhdGVkIHR5cGUgMyAoMHhiYTAwMC0weGJhN2ZmKSBmb3IgcmlkIDAgb2Ygb3JtMApw Y2liMDogYWxsb2NhdGVkIHR5cGUgMyAoMHhiYTgwMC0weGJhZmZmKSBmb3IgcmlkIDAgb2Ygb3Jt MApwY2liMDogYWxsb2NhdGVkIHR5cGUgMyAoMHhiYjAwMC0weGJiN2ZmKSBmb3IgcmlkIDAgb2Yg b3JtMApwY2liMDogYWxsb2NhdGVkIHR5cGUgMyAoMHhiYjgwMC0weGJiZmZmKSBmb3IgcmlkIDAg b2Ygb3JtMApwY2liMDogYWxsb2NhdGVkIHR5cGUgMyAoMHhiYzAwMC0weGJjN2ZmKSBmb3Igcmlk IDAgb2Ygb3JtMApwY2liMDogYWxsb2NhdGVkIHR5cGUgMyAoMHhiYzgwMC0weGJjZmZmKSBmb3Ig cmlkIDAgb2Ygb3JtMApwY2liMDogYWxsb2NhdGVkIHR5cGUgMyAoMHhiZDAwMC0weGJkN2ZmKSBm b3IgcmlkIDAgb2Ygb3JtMApwY2liMDogYWxsb2NhdGVkIHR5cGUgMyAoMHhiZDgwMC0weGJkZmZm KSBmb3IgcmlkIDAgb2Ygb3JtMApwY2liMDogYWxsb2NhdGVkIHR5cGUgMyAoMHhiZTAwMC0weGJl N2ZmKSBmb3IgcmlkIDAgb2Ygb3JtMApwY2liMDogYWxsb2NhdGVkIHR5cGUgMyAoMHhiZTgwMC0w eGJlZmZmKSBmb3IgcmlkIDAgb2Ygb3JtMApwY2liMDogYWxsb2NhdGVkIHR5cGUgMyAoMHhiZjAw MC0weGJmN2ZmKSBmb3IgcmlkIDAgb2Ygb3JtMApwY2liMDogYWxsb2NhdGVkIHR5cGUgMyAoMHhi ZjgwMC0weGJmZmZmKSBmb3IgcmlkIDAgb2Ygb3JtMApwY2liMDogYWxsb2NhdGVkIHR5cGUgMyAo MHhkNDAwMC0weGQ0N2ZmKSBmb3IgcmlkIDIgb2Ygb3JtMApwY2liMDogYWxsb2NhdGVkIHR5cGUg MyAoMHhkNDgwMC0weGQ0ZmZmKSBmb3IgcmlkIDIgb2Ygb3JtMApwY2liMDogYWxsb2NhdGVkIHR5 cGUgMyAoMHhkNTAwMC0weGQ1N2ZmKSBmb3IgcmlkIDIgb2Ygb3JtMApwY2liMDogYWxsb2NhdGVk IHR5cGUgMyAoMHhkNTgwMC0weGQ1ZmZmKSBmb3IgcmlkIDIgb2Ygb3JtMApwY2liMDogYWxsb2Nh dGVkIHR5cGUgMyAoMHhkNjAwMC0weGQ2N2ZmKSBmb3IgcmlkIDIgb2Ygb3JtMApwY2liMDogYWxs b2NhdGVkIHR5cGUgMyAoMHhkNjgwMC0weGQ2ZmZmKSBmb3IgcmlkIDIgb2Ygb3JtMApwY2liMDog YWxsb2NhdGVkIHR5cGUgMyAoMHhkNzAwMC0weGQ3N2ZmKSBmb3IgcmlkIDIgb2Ygb3JtMApwY2li MDogYWxsb2NhdGVkIHR5cGUgMyAoMHhkNzgwMC0weGQ3ZmZmKSBmb3IgcmlkIDIgb2Ygb3JtMApw Y2liMDogYWxsb2NhdGVkIHR5cGUgMyAoMHhkODAwMC0weGQ4N2ZmKSBmb3IgcmlkIDIgb2Ygb3Jt MApwY2liMDogYWxsb2NhdGVkIHR5cGUgMyAoMHhkODgwMC0weGQ4ZmZmKSBmb3IgcmlkIDIgb2Yg b3JtMApwY2liMDogYWxsb2NhdGVkIHR5cGUgMyAoMHhkOTAwMC0weGQ5N2ZmKSBmb3IgcmlkIDIg b2Ygb3JtMApwY2liMDogYWxsb2NhdGVkIHR5cGUgMyAoMHhkOTgwMC0weGQ5ZmZmKSBmb3Igcmlk IDIgb2Ygb3JtMApwY2liMDogYWxsb2NhdGVkIHR5cGUgMyAoMHhkYTAwMC0weGRhN2ZmKSBmb3Ig cmlkIDIgb2Ygb3JtMApwY2liMDogYWxsb2NhdGVkIHR5cGUgMyAoMHhkYTgwMC0weGRhZmZmKSBm b3IgcmlkIDIgb2Ygb3JtMApwY2liMDogYWxsb2NhdGVkIHR5cGUgMyAoMHhkYjAwMC0weGRiN2Zm KSBmb3IgcmlkIDIgb2Ygb3JtMApwY2liMDogYWxsb2NhdGVkIHR5cGUgMyAoMHhkYjgwMC0weGRi ZmZmKSBmb3IgcmlkIDIgb2Ygb3JtMApwY2liMDogYWxsb2NhdGVkIHR5cGUgMyAoMHhkYzAwMC0w eGRjN2ZmKSBmb3IgcmlkIDIgb2Ygb3JtMApwY2liMDogYWxsb2NhdGVkIHR5cGUgMyAoMHhkYzgw MC0weGRjZmZmKSBmb3IgcmlkIDIgb2Ygb3JtMApwY2liMDogYWxsb2NhdGVkIHR5cGUgMyAoMHhk ZDAwMC0weGRkN2ZmKSBmb3IgcmlkIDIgb2Ygb3JtMApwY2liMDogYWxsb2NhdGVkIHR5cGUgMyAo MHhkZDgwMC0weGRkZmZmKSBmb3IgcmlkIDIgb2Ygb3JtMApwY2liMDogYWxsb2NhdGVkIHR5cGUg MyAoMHhkZTAwMC0weGRlN2ZmKSBmb3IgcmlkIDIgb2Ygb3JtMApwY2liMDogYWxsb2NhdGVkIHR5 cGUgMyAoMHhkZTgwMC0weGRlZmZmKSBmb3IgcmlkIDIgb2Ygb3JtMApwY2liMDogYWxsb2NhdGVk IHR5cGUgMyAoMHhkZjAwMC0weGRmN2ZmKSBmb3IgcmlkIDIgb2Ygb3JtMApwY2liMDogYWxsb2Nh dGVkIHR5cGUgMyAoMHhkZjgwMC0weGRmZmZmKSBmb3IgcmlkIDIgb2Ygb3JtMApwY2liMDogYWxs b2NhdGVkIHR5cGUgMyAoMHhlMDAwMC0weGUwN2ZmKSBmb3IgcmlkIDIgb2Ygb3JtMApwY2liMDog YWxsb2NhdGVkIHR5cGUgMyAoMHhlMDgwMC0weGUwZmZmKSBmb3IgcmlkIDIgb2Ygb3JtMApwY2li MDogYWxsb2NhdGVkIHR5cGUgMyAoMHhlMTAwMC0weGUxN2ZmKSBmb3IgcmlkIDIgb2Ygb3JtMApw Y2liMDogYWxsb2NhdGVkIHR5cGUgMyAoMHhlMTgwMC0weGUxZmZmKSBmb3IgcmlkIDIgb2Ygb3Jt MApwY2liMDogYWxsb2NhdGVkIHR5cGUgMyAoMHhlMjAwMC0weGUyN2ZmKSBmb3IgcmlkIDIgb2Yg b3JtMApwY2liMDogYWxsb2NhdGVkIHR5cGUgMyAoMHhlMjgwMC0weGUyZmZmKSBmb3IgcmlkIDIg b2Ygb3JtMApwY2liMDogYWxsb2NhdGVkIHR5cGUgMyAoMHhlMzAwMC0weGUzN2ZmKSBmb3Igcmlk IDIgb2Ygb3JtMApwY2liMDogYWxsb2NhdGVkIHR5cGUgMyAoMHhlMzgwMC0weGUzZmZmKSBmb3Ig cmlkIDIgb2Ygb3JtMAppc2FfcHJvYmVfY2hpbGRyZW46IGRpc2FibGluZyBQblAgZGV2aWNlcwph dGtiZGM6IGF0a2JkYzAgYWxyZWFkeSBleGlzdHM7IHNraXBwaW5nIGl0CmF0cnRjOiBhdHJ0YzAg YWxyZWFkeSBleGlzdHM7IHNraXBwaW5nIGl0CmF0dGltZXI6IGF0dGltZXIwIGFscmVhZHkgZXhp c3RzOyBza2lwcGluZyBpdApzYzogc2MwIGFscmVhZHkgZXhpc3RzOyBza2lwcGluZyBpdAppc2Ff cHJvYmVfY2hpbGRyZW46IHByb2Jpbmcgbm9uLVBuUCBkZXZpY2VzCm9ybTA6IDxJU0EgT3B0aW9u IFJPTXM+IGF0IGlvbWVtIDB4YzAwMDAtMHhjZjdmZiwweGNmODAwLTB4ZDA3ZmYgb24gaXNhMApz YzA6IDxTeXN0ZW0gY29uc29sZT4gYXQgZmxhZ3MgMHgxMDAgb24gaXNhMApzYzA6IFZHQSA8MTYg dmlydHVhbCBjb25zb2xlcywgZmxhZ3M9MHgzMDA+CnNjMDogZmIwLCBrYmQxLCB0ZXJtaW5hbCBl bXVsYXRvcjogc2N0ZWtlbiAodGVrZW4gdGVybWluYWwpCnZnYTA6IDxHZW5lcmljIElTQSBWR0E+ IGF0IHBvcnQgMHgzYzAtMHgzZGYgaW9tZW0gMHhhMDAwMC0weGJmZmZmIG9uIGlzYTAKcGNpYjA6 IGFsbG9jYXRlZCB0eXBlIDQgKDB4M2MwLTB4M2RmKSBmb3IgcmlkIDAgb2YgdmdhMApwY2liMDog YWxsb2NhdGVkIHR5cGUgMyAoMHhhMDAwMC0weGJmZmZmKSBmb3IgcmlkIDAgb2YgdmdhMApwY2li MDogYWxsb2NhdGVkIHR5cGUgNCAoMHgzZjAtMHgzZjUpIGZvciByaWQgMCBvZiBmZGMwCnBjaWIw OiBhbGxvY2F0ZWQgdHlwZSA0ICgweDNmNy0weDNmNykgZm9yIHJpZCAxIG9mIGZkYzAKZmRjMCBm YWlsZWQgdG8gcHJvYmUgYXQgcG9ydCAweDNmMC0weDNmNSwweDNmNyBpcnEgNiBkcnEgMiBvbiBp c2EwCnBwYzA6IGNhbm5vdCByZXNlcnZlIEkvTyBwb3J0IHJhbmdlCnBwYzAgZmFpbGVkIHRvIHBy b2JlIGF0IGlycSA3IG9uIGlzYTAKcGNpYjA6IGFsbG9jYXRlZCB0eXBlIDQgKDB4M2Y4LTB4M2Zm KSBmb3IgcmlkIDAgb2YgdWFydDAKdWFydDAgZmFpbGVkIHRvIHByb2JlIGF0IHBvcnQgMHgzZjgt MHgzZmYgaXJxIDQgb24gaXNhMApwY2liMDogYWxsb2NhdGVkIHR5cGUgNCAoMHgyZjgtMHgyZmYp IGZvciByaWQgMCBvZiB1YXJ0MQp1YXJ0MSBmYWlsZWQgdG8gcHJvYmUgYXQgcG9ydCAweDJmOC0w eDJmZiBpcnEgMyBvbiBpc2EwCndid2QwIGZhaWxlZCB0byBwcm9iZSBvbiBpc2EwCmlzYV9wcm9i ZV9jaGlsZHJlbjogcHJvYmluZyBQblAgZGV2aWNlcwplc3QwOiA8RW5oYW5jZWQgU3BlZWRTdGVw IEZyZXF1ZW5jeSBDb250cm9sPiBvbiBjcHUwCnA0dGNjMDogPENQVSBGcmVxdWVuY3kgVGhlcm1h bCBDb250cm9sPiBvbiBjcHUwCmVzdDE6IDxFbmhhbmNlZCBTcGVlZFN0ZXAgRnJlcXVlbmN5IENv bnRyb2w+IG9uIGNwdTEKcDR0Y2MxOiA8Q1BVIEZyZXF1ZW5jeSBUaGVybWFsIENvbnRyb2w+IG9u IGNwdTEKRGV2aWNlIGNvbmZpZ3VyYXRpb24gZmluaXNoZWQuCnByb2NmcyByZWdpc3RlcmVkClpG UyBOT1RJQ0U6IFByZWZldGNoIGlzIGRpc2FibGVkIGJ5IGRlZmF1bHQgaWYgbGVzcyB0aGFuIDRH QiBvZiBSQU0gaXMgcHJlc2VudDsKICAgICAgICAgICAgdG8gZW5hYmxlLCBhZGQgInZmcy56ZnMu cHJlZmV0Y2hfZGlzYWJsZT0wIiB0byAvYm9vdC9sb2FkZXIuY29uZi4KWkZTIGZpbGVzeXN0ZW0g dmVyc2lvbjogNQpaRlMgc3RvcmFnZSBwb29sIHZlcnNpb246IGZlYXR1cmVzIHN1cHBvcnQgKDUw MDApClRpbWVjb3VudGVycyB0aWNrIGV2ZXJ5IDEuMDAwIG1zZWMKdmxhbjogaW5pdGlhbGl6ZWQs IHVzaW5nIGhhc2ggdGFibGVzIHdpdGggY2hhaW5pbmcKdmJveGRydjogZkFzeW5jPTAgb2ZmTWlu PTB4MTM2IG9mZk1heD0weDIyNgpMaW51eCBFTEYgZXhlYyBoYW5kbGVyIGluc3RhbGxlZAp0Y3Bf aW5pdDogbmV0LmluZXQudGNwLnRjYmhhc2hzaXplIGF1dG8gdHVuZWQgdG8gMTYzODQKbG8wOiBi cGYgYXR0YWNoZWQKaHB0bnI6IG5vIGNvbnRyb2xsZXIgZGV0ZWN0ZWQuCmhwdDI3eHg6IG5vIGNv bnRyb2xsZXIgZGV0ZWN0ZWQuCmhwdHJyOiBubyBjb250cm9sbGVyIGRldGVjdGVkLgpoZGFjYzA6 IDxSZWFsdGVrIEFMQzI2OCBIREEgQ09ERUM+IGF0IGNhZCAwIG9uIGhkYWMwCmhkYWEwOiA8UmVh bHRlayBBTEMyNjggQXVkaW8gRnVuY3Rpb24gR3JvdXA+IGF0IG5pZCAxIG9uIGhkYWNjMApoZGFh MDogU3Vic3lzdGVtIElEOiAweDEwMjUwMTNjCmhkYWEwOiBOdW1HUElPPTQgTnVtR1BPPTAgTnVt R1BJPTAgR1BJV2FrZT0wIEdQSVVuc29sPTEKaGRhYTA6ICBHUElPMDogZGlzYWJsZWQKaGRhYTA6 ICBHUElPMTogZGlzYWJsZWQKaGRhYTA6ICBHUElPMjogZGlzYWJsZWQKaGRhYTA6ICBHUElPMzog ZGlzYWJsZWQKaGRhYTA6IE9yaWdpbmFsIHBpbnMgY29uZmlndXJhdGlvbjoKaGRhYTA6IG5pZCAg IDB4ICAgIGFzIHNlcSBkZXZpY2UgICAgICAgY29ubiAgamFjayAgICBsb2MgICAgICAgIGNvbG9y ICAgbWlzYwpoZGFhMDogMTggNDExMTExZjAgMTUgMCAgU3BlYWtlciAgICAgICBOb25lICAxLzgg ICAgIFJlYXIgICAgICAgQmxhY2sgICAxCmhkYWEwOiAxOSA0MTExMTFmMCAxNSAwICBTcGVha2Vy ICAgICAgIE5vbmUgIDEvOCAgICAgUmVhciAgICAgICBCbGFjayAgIDEKaGRhYTA6IDIwIDk5MTMw MTEwIDEgIDAgIFNwZWFrZXIgICAgICAgRml4ZWQgQVRBUEkgICBPbmJvYXJkICAgIFVua25vd24g MQpoZGFhMDogMjEgMDIyMTQwMWYgMSAgMTUgSGVhZHBob25lcyAgICBKYWNrICAxLzggICAgIEZy b250ICAgICAgR3JlZW4gICAwCmhkYWEwOiAyMiA0MTExMTFmMCAxNSAwICBTcGVha2VyICAgICAg IE5vbmUgIDEvOCAgICAgUmVhciAgICAgICBCbGFjayAgIDEKaGRhYTA6IDI0IDAyYTE5ODJlIDIg IDE0IE1pYyAgICAgICAgICAgSmFjayAgMS84ICAgICBGcm9udCAgICAgIFBpbmsgICAgOApoZGFh MDogMjUgOTlhMzA5MzAgMyAgMCAgTWljICAgICAgICAgICBGaXhlZCBBVEFQSSAgIE9uYm9hcmQg ICAgVW5rbm93biA5CmhkYWEwOiAyNiAwMjgxMzAyMCAyICAwICBMaW5lLWluICAgICAgIEphY2sg IDEvOCAgICAgRnJvbnQgICAgICBCbHVlICAgIDAKaGRhYTA6IDI4IDQxMTExMWYwIDE1IDAgIFNw ZWFrZXIgICAgICAgTm9uZSAgMS84ICAgICBSZWFyICAgICAgIEJsYWNrICAgMQpoZGFhMDogMjkg NDAxNjg1MmQgMiAgMTMgU3BlYWtlciAgICAgICBOb25lICBEaWdpdGFsIDB4MDAgICAgICAgUHVy cGxlICA1CmhkYWEwOiAzMCA0MTExMTFmMCAxNSAwICBTcGVha2VyICAgICAgIE5vbmUgIDEvOCAg ICAgUmVhciAgICAgICBCbGFjayAgIDEKaGRhYTA6IFBhdGNoaW5nIHdpZGdldCBjYXBzIG5pZD0y OSAweDAwNDAwMDAwIC0+IDB4MDA3MDAwMDAKaGRhYTA6IFBhdGNoZWQgcGlucyBjb25maWd1cmF0 aW9uOgpoZGFhMDogbmlkICAgMHggICAgYXMgc2VxIGRldmljZSAgICAgICBjb25uICBqYWNrICAg IGxvYyAgICAgICAgY29sb3IgICBtaXNjCmhkYWEwOiAxOCA0MTExMTFmMCAxNSAwICBTcGVha2Vy ICAgICAgIE5vbmUgIDEvOCAgICAgUmVhciAgICAgICBCbGFjayAgIDEgRElTQQpoZGFhMDogMTkg NDExMTExZjAgMTUgMCAgU3BlYWtlciAgICAgICBOb25lICAxLzggICAgIFJlYXIgICAgICAgQmxh Y2sgICAxIERJU0EKaGRhYTA6IDIwIDk5MTMwMTEwIDEgIDAgIFNwZWFrZXIgICAgICAgRml4ZWQg QVRBUEkgICBPbmJvYXJkICAgIFVua25vd24gMQpoZGFhMDogMjEgMDIyMTQwMWYgMSAgMTUgSGVh ZHBob25lcyAgICBKYWNrICAxLzggICAgIEZyb250ICAgICAgR3JlZW4gICAwCmhkYWEwOiAyMiA0 MTExMTFmMCAxNSAwICBTcGVha2VyICAgICAgIE5vbmUgIDEvOCAgICAgUmVhciAgICAgICBCbGFj ayAgIDEgRElTQQpoZGFhMDogMjQgMDJhMTk4MmUgMiAgMTQgTWljICAgICAgICAgICBKYWNrICAx LzggICAgIEZyb250ICAgICAgUGluayAgICA4CmhkYWEwOiAyNSA5OWEzMDkzMCAzICAwICBNaWMg ICAgICAgICAgIEZpeGVkIEFUQVBJICAgT25ib2FyZCAgICBVbmtub3duIDkKaGRhYTA6IDI2IDAy ODEzMDIwIDIgIDAgIExpbmUtaW4gICAgICAgSmFjayAgMS84ICAgICBGcm9udCAgICAgIEJsdWUg ICAgMApoZGFhMDogMjggNDExMTExZjAgMTUgMCAgU3BlYWtlciAgICAgICBOb25lICAxLzggICAg IFJlYXIgICAgICAgQmxhY2sgICAxIERJU0EKaGRhYTA6IDMwIDQxMTExMWYwIDE1IDAgIFNwZWFr ZXIgICAgICAgTm9uZSAgMS84ICAgICBSZWFyICAgICAgIEJsYWNrICAgMSBESVNBCmhkYWEwOiAz IGFzc29jaWF0aW9ucyBmb3VuZDoKaGRhYTA6IEFzc29jaWF0aW9uIDAgKDEpIG91dDoKaGRhYTA6 ICBQaW4gbmlkPTIwIHNlcT0wCmhkYWEwOiAgUGluIG5pZD0yMSBzZXE9MTUKaGRhYTA6IEFzc29j aWF0aW9uIDEgKDIpIGluOgpoZGFhMDogIFBpbiBuaWQ9MjYgc2VxPTAKaGRhYTA6ICBQaW4gbmlk PTI0IHNlcT0xNApoZGFhMDogQXNzb2NpYXRpb24gMiAoMykgaW46CmhkYWEwOiAgUGluIG5pZD0y NSBzZXE9MApoZGFhMDogVHJhY2luZyBhc3NvY2lhdGlvbiAwICgxKQpoZGFhMDogIFBpbiAyMCB0 cmFjZWQgdG8gREFDIDIKaGRhYTA6ICBQaW4gMjEgdHJhY2VkIHRvIERBQyAyIGFuZCBocHJlZGly IDAKaGRhYTA6IEFzc29jaWF0aW9uIDAgKDEpIHRyYWNlIHN1Y2NlZWRlZApoZGFhMDogVHJhY2lu ZyBhc3NvY2lhdGlvbiAxICgyKQpoZGFhMDogIFBpbiAyNiB0cmFjZWQgdG8gQURDIDcKaGRhYTA6 ICBQaW4gMjQgdHJhY2VkIHRvIEFEQyA3CmhkYWEwOiBBc3NvY2lhdGlvbiAxICgyKSB0cmFjZSBz dWNjZWVkZWQKaGRhYTA6IFRyYWNpbmcgYXNzb2NpYXRpb24gMiAoMykKaGRhYTA6ICBQaW4gMjUg dHJhY2VkIHRvIEFEQyA4CmhkYWEwOiBBc3NvY2lhdGlvbiAyICgzKSB0cmFjZSBzdWNjZWVkZWQK aGRhYTA6IExvb2tpbmcgZm9yIGFkZGl0aW9uYWwgREFDIGZvciBhc3NvY2lhdGlvbiAwICgxKQpo ZGFhMDogTG9va2luZyBmb3IgYWRkaXRpb25hbCBBREMgZm9yIGFzc29jaWF0aW9uIDEgKDIpCmhk YWEwOiBMb29raW5nIGZvciBhZGRpdGlvbmFsIEFEQyBmb3IgYXNzb2NpYXRpb24gMiAoMykKaGRh YTA6IFRyYWNpbmcgaW5wdXQgbW9uaXRvcgpoZGFhMDogVHJhY2luZyBvdGhlciBpbnB1dCBtb25p dG9ycwpoZGFhMDogIFRyYWNpbmcgbmlkIDI0IHRvIG91dApoZGFhMDogIFRyYWNpbmcgbmlkIDI1 IHRvIG91dApoZGFhMDogIFRyYWNpbmcgbmlkIDI2IHRvIG91dApoZGFhMDogVHJhY2luZyBiZWVw ZXIKaGRhYTA6ICBuaWQgMjkgdHJhY2VkIHRvIG91dApoZGFhMDogR1BJTyBjb21taXQKaGRhYTA6 ICBHUElPMDogb3V0cHV0IHN0YXRlPTEKaGRhYTA6ICBHUElPMTogZGlzYWJsZWQKaGRhYTA6ICBH UElPMjogZGlzYWJsZWQKaGRhYTA6ICBHUElPMzogZGlzYWJsZWQKaGRhYTA6IEhlYWRwaG9uZXMg cmVkaXJlY3Rpb24gZm9yIGFzc29jaWF0aW9uIDAgbmlkPTIxIHVzaW5nIHVuc29saWNpdGVkIHJl c3BvbnNlcy4KaGRhYTA6IFJlZGlyZWN0IG91dHB1dCB0bzogbWFpbgpoZGFhMDogRkcgY29uZmln L3F1aXJrczogZm9yY2VzdGVyZW8gaXZyZWY1MCBpdnJlZjgwIGl2cmVmMTAwIGl2cmVmCnBjbTA6 IDxSZWFsdGVrIEFMQzI2OCAoQW5hbG9nIDIuMCtIUC8yLjApPiBhdCBuaWQgMjAsMjEgYW5kIDI2 LDI0IG9uIGhkYWEwCnBjbTA6IFBsYXliYWNrOgpwY20wOiAgICAgIFN0cmVhbSBjYXA6IDB4MDAw MDAwMDEgUENNCnBjbTA6ICAgICAgICAgUENNIGNhcDogMHgwMDBlMDU2MCAxNiAyMCAyNCBiaXRz LCA0NCA0OCA5NiAxOTIgS0h6CnBjbTA6ICAgICAgICAgICAgIERBQzogMgpwY20wOiAKcGNtMDog ICAgIG5pZD0yMCBbcGluOiBTcGVha2VyIChGaXhlZCldCnBjbTA6ICAgICAgICsgPC0gbmlkPTE1 IFthdWRpbyBtaXhlcl0gW3NyYzogcGNtLCBzcGVha2VyXQpwY20wOiAgICAgICAgICAgICAgKyA8 LSBuaWQ9MiBbYXVkaW8gb3V0cHV0XSBbc3JjOiBwY21dCnBjbTA6ICAgICAgICAgICAgICArIDwt IG5pZD0yOSBbYmVlcCB3aWRnZXRdIFtzcmM6IHNwZWFrZXJdCnBjbTA6IApwY20wOiAgICAgbmlk PTIxIFtwaW46IEhlYWRwaG9uZXMgKEdyZWVuIEphY2spXQpwY20wOiAgICAgICArIDwtIG5pZD0x NiBbYXVkaW8gbWl4ZXJdIFtzcmM6IHBjbSwgc3BlYWtlcl0KcGNtMDogICAgICAgICAgICAgICsg PC0gbmlkPTI5IFtiZWVwIHdpZGdldF0gW3NyYzogc3BlYWtlcl0KcGNtMDogICAgICAgICAgICAg ICsgPC0gbmlkPTIgW2F1ZGlvIG91dHB1dF0gW3NyYzogcGNtXQpwY20wOiAKcGNtMDogUmVjb3Jk OgpwY20wOiAgICAgIFN0cmVhbSBjYXA6IDB4MDAwMDAwMDEgUENNCnBjbTA6ICAgICAgICAgUENN IGNhcDogMHgwMDBlMDE2MCAxNiAyMCAyNCBiaXRzLCA0NCA0OCA5NiBLSHoKcGNtMDogICAgICAg ICAgICAgQURDOiA3CnBjbTA6IApwY20wOiAgICAgbmlkPTcgW2F1ZGlvIGlucHV0XQpwY20wOiAg ICAgICArIDwtIG5pZD0zNiBbYXVkaW8gc2VsZWN0b3JdIFtzcmM6IGxpbmUsIG1pY10KcGNtMDog ICAgICAgICAgICAgICsgPC0gbmlkPTI0IFtwaW46IE1pYyAoUGluayBKYWNrKV0gW3NyYzogbWlj XQpwY20wOiAgICAgICAgICAgICAgKyA8LSBuaWQ9MjYgW3BpbjogTGluZS1pbiAoQmx1ZSBKYWNr KV0gW3NyYzogbGluZV0KcGNtMDogCnBjbTA6IE1hc3RlciBWb2x1bWUgKE9TUzogdm9sKTogLTY0 LzBkQgpwY20wOiAgICArLSBjdGwgIDEgKG5pZCAgIDIgb3V0KTogICAgLTY0LzBkQiAoNjUgc3Rl cHMpCnBjbTA6ICAgICstIGN0bCAgNCAobmlkICAxNSBpbiAgIDApOiBtdXRlCnBjbTA6ICAgICst IGN0bCAgNSAobmlkICAxNSBpbiAgIDEpOiBtdXRlCnBjbTA6ICAgICstIGN0bCAgNyAobmlkICAx NiBpbiAgIDEpOiBtdXRlCnBjbTA6ICAgICstIGN0bCAgOCAobmlkICAxNiBpbiAgIDIpOiBtdXRl CnBjbTA6ICAgICstIGN0bCAgOSAobmlkICAyMCBpbiApOiAgICBtdXRlCnBjbTA6ICAgICstIGN0 bCAxMCAobmlkICAyMSBpbiApOiAgICBtdXRlCnBjbTA6IApwY20wOiBQQ00gVm9sdW1lIChPU1M6 IHBjbSk6IC02NC8wZEIKcGNtMDogICAgKy0gY3RsICAxIChuaWQgICAyIG91dCk6ICAgIC02NC8w ZEIgKDY1IHN0ZXBzKQpwY20wOiAgICArLSBjdGwgIDQgKG5pZCAgMTUgaW4gICAwKTogbXV0ZQpw Y20wOiAgICArLSBjdGwgIDggKG5pZCAgMTYgaW4gICAyKTogbXV0ZQpwY20wOiAKcGNtMDogTWlj cm9waG9uZSBWb2x1bWUgKE9TUzogbWljKTogMC80MGRCCnBjbTA6ICAgICstIGN0bCAxMyAobmlk ICAyNCBvdXQpOiAgICAwLzQwZEIgKDMgc3RlcHMpCnBjbTA6ICAgICstIGN0bCAxOCAobmlkICAz NiBvdXQpOiAgICAtMTUvMzFkQiAoMzIgc3RlcHMpICsgbXV0ZQpwY20wOiAKcGNtMDogTGluZS1p biBWb2x1bWUgKE9TUzogbGluZSk6IDAvNDBkQgpwY20wOiAgICArLSBjdGwgMTYgKG5pZCAgMjYg b3V0KTogICAgMC80MGRCICgzIHN0ZXBzKQpwY20wOiAgICArLSBjdGwgMTggKG5pZCAgMzYgb3V0 KTogICAgLTE1LzMxZEIgKDMyIHN0ZXBzKSArIG11dGUKcGNtMDogCnBjbTA6IFNwZWFrZXIvQmVl cCBWb2x1bWUgKE9TUzogc3BlYWtlcik6IDAvMGRCCnBjbTA6ICAgICstIGN0bCAgNSAobmlkICAx NSBpbiAgIDEpOiBtdXRlCnBjbTA6ICAgICstIGN0bCAgNyAobmlkICAxNiBpbiAgIDEpOiBtdXRl CnBjbTA6IApwY20wOiBSZWNvcmRpbmcgTGV2ZWwgKE9TUzogcmVjKTogLTE1LzMxZEIKcGNtMDog ICAgKy0gY3RsIDEzIChuaWQgIDI0IG91dCk6ICAgIDAvNDBkQiAoMyBzdGVwcykKcGNtMDogICAg Ky0gY3RsIDE2IChuaWQgIDI2IG91dCk6ICAgIDAvNDBkQiAoMyBzdGVwcykKcGNtMDogICAgKy0g Y3RsIDE4IChuaWQgIDM2IG91dCk6ICAgIC0xNS8zMWRCICgzMiBzdGVwcykgKyBtdXRlCnBjbTA6 IApwY20wOiBJbnB1dCBNb25pdG9yaW5nIExldmVsIChPU1M6IGlnYWluKTogMC8wZEIKcGNtMDog ICAgKy0gY3RsICA1IChuaWQgIDE1IGluICAgMSk6IG11dGUKcGNtMDogICAgKy0gY3RsICA3IChu aWQgIDE2IGluICAgMSk6IG11dGUKcGNtMDogCnBjbTA6IE1peGVyICJ2b2wiOgpwY20wOiBNaXhl ciAicGNtIjoKcGNtMDogTWl4ZXIgInNwZWFrZXIiOgpwY20wOiBNaXhlciAibGluZSI6CnBjbTA6 IE1peGVyICJtaWMiOgpwY20wOiBNaXhlciAicmVjIjoKcGNtMDogTWl4ZXIgImlnYWluIjoKcGNt MDogTWl4ZXIgIm9nYWluIjoKcGNtMDogUGxheWJhY2sgY2hhbm5lbCBzZXQgaXM6IEZyb250IExl ZnQsIEZyb250IFJpZ2h0LCAKcGNtMDogUGxheWJhY2sgY2hhbm5lbCBtYXRyaXggaXM6IDIuMCAo dW5rbm93bikKcGNtMDogUmVjb3JkaW5nIGNoYW5uZWwgc2V0IGlzOiBGcm9udCBMZWZ0LCBGcm9u dCBSaWdodCwgCnBjbTA6IFJlY29yZGluZyBjaGFubmVsIG1hdHJpeCBpczogMi4wIChkaXNjb25u ZWN0ZWQpCnBjbTE6IDxSZWFsdGVrIEFMQzI2OCAoT25ib2FyZCBBbmFsb2cgTWljKT4gYXQgbmlk IDI1IG9uIGhkYWEwCnBjbTE6IFJlY29yZDoKcGNtMTogICAgICBTdHJlYW0gY2FwOiAweDAwMDAw MDAxIFBDTQpwY20xOiAgICAgICAgIFBDTSBjYXA6IDB4MDAwZTAxNjAgMTYgMjAgMjQgYml0cywg NDQgNDggOTYgS0h6CnBjbTE6ICAgICAgICAgICAgIEFEQzogOApwY20xOiAKcGNtMTogICAgIG5p ZD04IFthdWRpbyBpbnB1dF0KcGNtMTogICAgICAgKyA8LSBuaWQ9MzUgW2F1ZGlvIHNlbGVjdG9y XSBbc3JjOiBtb25pdG9yXQpwY20xOiAgICAgICAgICAgICAgKyA8LSBuaWQ9MjUgW3BpbjogTWlj IChGaXhlZCldIFtzcmM6IG1vbml0b3JdCnBjbTE6IApwY20xOiBNaWNyb3Bob25lMiBWb2x1bWUg KE9TUzogbW9uaXRvcik6IDAvNDBkQgpwY20xOiAgICArLSBjdGwgMTQgKG5pZCAgMjUgb3V0KTog ICAgMC80MGRCICgzIHN0ZXBzKQpwY20xOiAgICArLSBjdGwgMTcgKG5pZCAgMzUgb3V0KTogICAg LTE1LzMxZEIgKDMyIHN0ZXBzKSArIG11dGUKcGNtMTogCnBjbTE6IFJlY29yZGluZyBMZXZlbCAo T1NTOiByZWMpOiAtMTUvMzFkQgpwY20xOiAgICArLSBjdGwgMTQgKG5pZCAgMjUgb3V0KTogICAg MC80MGRCICgzIHN0ZXBzKQpwY20xOiAgICArLSBjdGwgMTcgKG5pZCAgMzUgb3V0KTogICAgLTE1 LzMxZEIgKDMyIHN0ZXBzKSArIG11dGUKcGNtMTogCnBjbTE6IE1peGVyICJyZWMiOgpwY20xOiBN aXhlciAibW9uaXRvciI6CnBjbTE6IEF1dG9tYXRpY2FsbHkgc2V0IHJlYyBzb3VyY2UgdG86IG1v bml0b3IKcGNtMTogUmVjb3JkaW5nIGNoYW5uZWwgc2V0IGlzOiBGcm9udCBMZWZ0LCBGcm9udCBS aWdodCwgCnBjbTE6IFJlY29yZGluZyBjaGFubmVsIG1hdHJpeCBpczogMi4wICh1bmtub3duKQpo ZGFjYzE6IDxJbnRlbCBDYW50aWdhIEhEQSBDT0RFQz4gYXQgY2FkIDMgb24gaGRhYzAKaGRhYTE6 IDxJbnRlbCBDYW50aWdhIEF1ZGlvIEZ1bmN0aW9uIEdyb3VwPiBhdCBuaWQgMSBvbiBoZGFjYzEK aGRhYTE6IFN1YnN5c3RlbSBJRDogMHg4MDg2MDEwMQpoZGFhMTogTnVtR1BJTz0wIE51bUdQTz0w IE51bUdQST0wIEdQSVdha2U9MCBHUElVbnNvbD0wCmhkYWExOiBPcmlnaW5hbCBwaW5zIGNvbmZp Z3VyYXRpb246CmhkYWExOiBuaWQgICAweCAgICBhcyBzZXEgZGV2aWNlICAgICAgIGNvbm4gIGph Y2sgICAgbG9jICAgICAgICBjb2xvciAgIG1pc2MKaGRhYTE6ICAzIDE4NTYwMDEwIDEgIDAgIERp Z2l0YWwtb3V0ICAgSmFjayAgRGlnaXRhbCAweDE4ICAgICAgIFVua25vd24gMApoZGFhMTogUGF0 Y2hlZCBwaW5zIGNvbmZpZ3VyYXRpb246CmhkYWExOiBuaWQgICAweCAgICBhcyBzZXEgZGV2aWNl ICAgICAgIGNvbm4gIGphY2sgICAgbG9jICAgICAgICBjb2xvciAgIG1pc2MKaGRhYTE6ICAzIDE4 NTYwMDEwIDEgIDAgIERpZ2l0YWwtb3V0ICAgSmFjayAgRGlnaXRhbCAweDE4ICAgICAgIFVua25v d24gMApoZGFhMTogMSBhc3NvY2lhdGlvbnMgZm91bmQ6CmhkYWExOiBBc3NvY2lhdGlvbiAwICgx KSBvdXQ6CmhkYWExOiAgUGluIG5pZD0zIHNlcT0wCmhkYWExOiBUcmFjaW5nIGFzc29jaWF0aW9u IDAgKDEpCmhkYWExOiAgUGluIDMgdHJhY2VkIHRvIERBQyAyCmhkYWExOiBBc3NvY2lhdGlvbiAw ICgxKSB0cmFjZSBzdWNjZWVkZWQKaGRhYTE6IExvb2tpbmcgZm9yIGFkZGl0aW9uYWwgREFDIGZv ciBhc3NvY2lhdGlvbiAwICgxKQpoZGFhMTogVHJhY2luZyBpbnB1dCBtb25pdG9yCmhkYWExOiBU cmFjaW5nIG90aGVyIGlucHV0IG1vbml0b3JzCmhkYWExOiBUcmFjaW5nIGJlZXBlcgpoZGFhMTog RkcgY29uZmlnL3F1aXJrczogZm9yY2VzdGVyZW8gaXZyZWY1MCBpdnJlZjgwIGl2cmVmMTAwIGl2 cmVmCnBjbTI6IDxJbnRlbCBDYW50aWdhIChIRE1JIDhjaCk+IGF0IG5pZCAzIG9uIGhkYWExCnBj bTI6IFBsYXliYWNrOgpwY20yOiAgICAgIFN0cmVhbSBjYXA6IDB4MDAwMDAwMDUgQUMzIFBDTQpw Y20yOiAgICAgICAgIFBDTSBjYXA6IDB4MDAxZTA3ZjAgMTYgMjAgMjQgMzIgYml0cywgMzIgNDQg NDggODggOTYgMTc2IDE5MiBLSHoKcGNtMjogICAgICAgICAgICAgREFDOiAyCnBjbTI6IApwY20y OiAgICAgbmlkPTMgW3BpbjogRGlnaXRhbC1vdXQgKEphY2spXQpwY20yOiAgICAgICArIDwtIG5p ZD0yIFthdWRpbyBvdXRwdXRdIFtzcmM6IHBjbV0KcGNtMjogCnBjbTI6IE1hc3RlciBWb2x1bWUg KE9TUzogdm9sKTogMC8wZEIKcGNtMjogICAgKy0gY3RsICAxIChuaWQgICAzIGluICk6ICAgIG11 dGUKcGNtMjogCnBjbTI6IFBDTSBWb2x1bWUgKE9TUzogcGNtKTogMC8wZEIKcGNtMjogICAgKy0g Y3RsICAxIChuaWQgICAzIGluICk6ICAgIG11dGUKcGNtMjogCnBjbTI6IE1peGVyICJ2b2wiOgpw Y20yOiBNaXhlciAicGNtIjoKcGNtMjogU29mdCBQQ00gbWl4ZXIgRU5BQkxFRApwY20yOiBQbGF5 YmFjayBjaGFubmVsIG1hdHJpeCBpczogdW5rbm93biwgYXNzdW1pbmcgNy4xIChkaXNjb25uZWN0 ZWQpCnJhbmRvbTogdW5ibG9ja2luZyBkZXZpY2UuCnVzYnVzMDogMTJNYnBzIEZ1bGwgU3BlZWQg VVNCIHYxLjAKdXNidXMxOiAxMk1icHMgRnVsbCBTcGVlZCBVU0IgdjEuMAp1c2J1czI6IDEyTWJw cyBGdWxsIFNwZWVkIFVTQiB2MS4wCnVzYnVzMzogNDgwTWJwcyBIaWdoIFNwZWVkIFVTQiB2Mi4w CnVzYnVzNDogMTJNYnBzIEZ1bGwgU3BlZWQgVVNCIHYxLjAKdXNidXM1OiAxMk1icHMgRnVsbCBT cGVlZCBVU0IgdjEuMAp1c2J1czY6IDEyTWJwcyBGdWxsIFNwZWVkIFVTQiB2MS4wCnVzYnVzNzog NDgwTWJwcyBIaWdoIFNwZWVkIFVTQiB2Mi4wCmFoY2ljaDA6IEFIQ0kgcmVzZXQuLi4KYWhjaWNo MDogU0FUQSBjb25uZWN0IHRpbWU9MTAwdXMgc3RhdHVzPTAwMDAwMTIzCmFoY2ljaDA6IEFIQ0kg cmVzZXQ6IGRldmljZSBmb3VuZAphaGNpY2gxOiBBSENJIHJlc2V0Li4uCmFoY2ljaDE6IFNBVEEg Y29ubmVjdCB0aW1lPTkwMHVzIHN0YXR1cz0wMDAwMDExMwphaGNpY2gxOiBBSENJIHJlc2V0OiBk ZXZpY2UgZm91bmQKYWhjaWNoMTogQUhDSSByZXNldDogZGV2aWNlIHJlYWR5IGFmdGVyIDFtcwph aGNpY2g0OiBBSENJIHJlc2V0Li4uCnVnZW4yLjE6IDxJbnRlbD4gYXQgdXNidXMyCnVodWIwOiA8 SW50ZWwgVUhDSSByb290IEhVQiwgY2xhc3MgOS8wLCByZXYgMS4wMC8xLjAwLCBhZGRyIDE+IG9u IHVzYnVzMgp1Z2VuMS4xOiA8SW50ZWw+IGF0IHVzYnVzMQp1aHViMTogPEludGVsIFVIQ0kgcm9v dCBIVUIsIGNsYXNzIDkvMCwgcmV2IDEuMDAvMS4wMCwgYWRkciAxPiBvbiB1c2J1czEKdWdlbjAu MTogPEludGVsPiBhdCB1c2J1czAKdWh1YjI6IDxJbnRlbCBVSENJIHJvb3QgSFVCLCBjbGFzcyA5 LzAsIHJldiAxLjAwLzEuMDAsIGFkZHIgMT4gb24gdXNidXMwCnVnZW41LjE6IDxJbnRlbD4gYXQg dXNidXM1CnVodWIzOiA8SW50ZWwgVUhDSSByb290IEhVQiwgY2xhc3MgOS8wLCByZXYgMS4wMC8x LjAwLCBhZGRyIDE+IG9uIHVzYnVzNQp1Z2VuNC4xOiA8SW50ZWw+IGF0IHVzYnVzNAp1aHViNDog PEludGVsIFVIQ0kgcm9vdCBIVUIsIGNsYXNzIDkvMCwgcmV2IDEuMDAvMS4wMCwgYWRkciAxPiBv biB1c2J1czQKdWdlbjMuMTogPEludGVsPiBhdCB1c2J1czMKdWh1YjU6IDxJbnRlbCBFSENJIHJv b3QgSFVCLCBjbGFzcyA5LzAsIHJldiAyLjAwLzEuMDAsIGFkZHIgMT4gb24gdXNidXMzCnVnZW43 LjE6IDxJbnRlbD4gYXQgdXNidXM3CnVodWI2OiA8SW50ZWwgRUhDSSByb290IEhVQiwgY2xhc3Mg OS8wLCByZXYgMi4wMC8xLjAwLCBhZGRyIDE+IG9uIHVzYnVzNwp1Z2VuNi4xOiA8SW50ZWw+IGF0 IHVzYnVzNgp1aHViNzogPEludGVsIFVIQ0kgcm9vdCBIVUIsIGNsYXNzIDkvMCwgcmV2IDEuMDAv MS4wMCwgYWRkciAxPiBvbiB1c2J1czYKYWhjaWNoNDogU0FUQSBjb25uZWN0IHRpbWVvdXQgdGlt ZT0xMDAwMHVzIHN0YXR1cz0wMDAwMDAwMAphaGNpY2g0OiBBSENJIHJlc2V0OiBkZXZpY2Ugbm90 IGZvdW5kCmFoY2ljaDU6IEFIQ0kgcmVzZXQuLi4KYWhjaWNoNTogU0FUQSBvZmZsaW5lIHN0YXR1 cz0wMDAwMDAwNAphaGNpY2g1OiBBSENJIHJlc2V0OiBkZXZpY2Ugbm90IGZvdW5kCmJhdHRlcnkw OiBiYXR0ZXJ5IGluaXRpYWxpemF0aW9uIHN0YXJ0CmFjcGlfYWNhZDA6IGFjbGluZSBpbml0aWFs aXphdGlvbiBzdGFydApiYXR0ZXJ5MDogY3JpdGljYWxseSBsb3cgY2hhcmdlIQphY3BpX2FjYWQw OiBPbiBMaW5lCmFjcGlfYWNhZDA6IGFjbGluZSBpbml0aWFsaXphdGlvbiBkb25lLCB0cmllZCAx IHRpbWVzCmFoY2ljaDA6IEFIQ0kgcmVzZXQ6IGRldmljZSByZWFkeSBhZnRlciAxMDBtcwpwYXNz MCBhdCBhaGNpY2gwIGJ1cyAwIHNjYnVzMCB0YXJnZXQgMCBsdW4gMApwYXNzMDogPEhHU1QgSFRT NzIxMDEwQTlFNjMwIEpCME9BM0IwPiBBVEEtOCBTQVRBIDMueCBkZXZpY2UKcGFzczA6IFNlcmlh bCBOdW1iZXIgSkc0MDAwNlBHUko1TUMKcGFzczA6IDMwMC4wMDBNQi9zIHRyYW5zZmVycyAoU0FU QSAyLngsIFVETUE2LCBQSU8gODE5MmJ5dGVzKQpwYXNzMDogQ29tbWFuZCBRdWV1ZWluZyBlbmFi bGVkCnBhc3MxIGF0IGFoY2ljaDEgYnVzIDAgc2NidXMxIHRhcmdldCAwIGx1biAwCnBhc3MxOiA8 VFNTVGNvcnAgQ0REVkRXIFRTLUw2MzNBIEFDMDA+IFJlbW92YWJsZSBDRC1ST00gU0NTSS0wIGRl dmljZSAKcGFzczE6IDE1MC4wMDBNQi9zIHRyYW5zZmVycyAoU0FUQSAxLngsIFVETUE1LCBBVEFQ SSAxMmJ5dGVzLCBQSU8gODE5MmJ5dGVzKQpwYXNzMiBhdCBhaGNpZW0wIGJ1cyAwIHNjYnVzNCB0 YXJnZXQgMCBsdW4gMApwYXNzMjogPEFIQ0kgU0dQSU8gRW5jbG9zdXJlIDEuMDAgMDAwMT4gU0VN QiBTLUUtUyAyLjAwIGRldmljZQphZGEwIGF0IGFoY2ljaDAgYnVzIDAgc2NidXMwIHRhcmdldCAw IGx1biAwCmFkYTA6IDxIR1NUIEhUUzcyMTAxMEE5RTYzMCBKQjBPQTNCMD4gQVRBLTggU0FUQSAz LnggZGV2aWNlCmFkYTA6IFNlcmlhbCBOdW1iZXIgSkc0MDAwNlBHUko1TUMKR0VPTTogbmV3IGRp c2sgYWRhMAphZGEwOiAzMDAuMDAwTUIvcyB0cmFuc2ZlcnMgKFNBVEEgMi54LCBVRE1BNiwgUElP IDgxOTJieXRlcykKYWRhMDogQ29tbWFuZCBRdWV1ZWluZyBlbmFibGVkCmFkYTA6IDk1Mzg2OU1C ICgxOTUzNTI1MTY4IDUxMiBieXRlIHNlY3RvcnM6IDE2SCA2M1MvVCAxNjM4M0MpCmFkYTA6IFBy ZXZpb3VzbHkgd2FzIGtub3duIGFzIGFkNApzZXMwIGF0IGFoY2llbTAgYnVzIDAgc2NidXM0IHRh cmdldCAwIGx1biAwCnNlczA6IDxBSENJIFNHUElPIEVuY2xvc3VyZSAxLjAwIDAwMDE+IFNFTUIg Uy1FLVMgMi4wMCBkZXZpY2UKc2VzMDogU0VNQiBTRVMgRGV2aWNlCnNlczA6IEdlbmVyYXRpb24g Q29kZSAweDAgaGFzIDEgU3ViRW5jbG9zdXJlcwpzZXMwOiAgU3ViRW5jbG9zdXJlIElEIDAsIDEg VHlwZXMgV2l0aCB0aGlzIElELCBEZXNjcmlwdG9yIExlbmd0aCAzNiwgb2Zmc2V0IDgKc2VzMDog V1dOOiAwCnNlczA6ICBUeXBlIERlc2NbMF06IFR5cGUgMHgxNywgTWF4RWx0IDYsIEluIFN1YmVu YyAwLCBUZXh0IExlbmd0aCAwOiAKY2QwIGF0IGFoY2ljaDEgYnVzIDAgc2NidXMxIHRhcmdldCAw IGx1biAwCmNkMDogPFRTU1Rjb3JwIENERFZEVyBUUy1MNjMzQSBBQzAwPiBSZW1vdmFibGUgQ0Qt Uk9NIFNDU0ktMCBkZXZpY2UgCmNkMDogMTUwLjAwME1CL3MgdHJhbnNmZXJzIChTQVRBIDEueCwg VURNQTUsIEFUQVBJIDEyYnl0ZXMsIFBJTyA4MTkyYnl0ZXMpCmNkMDogQXR0ZW1wdCB0byBxdWVy eSBkZXZpY2Ugc2l6ZSBmYWlsZWQ6IE5PVCBSRUFEWSwgTWVkaXVtIG5vdCBwcmVzZW50IC0gdHJh eSBjbG9zZWQKYmF0dGVyeTA6IGJhdHRlcnkgaW5pdGlhbGl6YXRpb24gZG9uZSwgdHJpZWQgMSB0 aW1lcwpOZXR2c2MgaW5pdGlhbGl6aW5nLi4uIFNNUDogQVAgQ1BVICMxIExhdW5jaGVkIQpjcHUx IEFQOgogICAgIElEOiAweDAxMDAwMDAwICAgVkVSOiAweDAwMDUwMDE0IExEUjogMHgwMDAwMDAw MCBERlI6IDB4ZmZmZmZmZmYKICBsaW50MDogMHgwMDAxMDcwMCBsaW50MTogMHgwMDAwMDQwMCBU UFI6IDB4MDAwMDAwMDAgU1ZSOiAweDAwMDAwMWZmCiAgdGltZXI6IDB4MDAwMTAwZWYgdGhlcm06 IDB4MDAwMTAwMDAgZXJyOiAweDAwMDAwMGYwIHBtYzogMHgwMDAxMDQwMAppb2FwaWMwOiByb3V0 aW5nIGludHBpbiAxIChJU0EgSVJRIDEpIHRvIGxhcGljIDEgdmVjdG9yIDQ4CmlvYXBpYzA6IHJv dXRpbmcgaW50cGluIDEyIChJU0EgSVJRIDEyKSB0byBsYXBpYyAxIHZlY3RvciA0OQppb2FwaWMw OiByb3V0aW5nIGludHBpbiAxOCAoUENJIElSUSAxOCkgdG8gbGFwaWMgMSB2ZWN0b3IgNTAKaW9h cGljMDogcm91dGluZyBpbnRwaW4gMjMgKFBDSSBJUlEgMjMpIHRvIGxhcGljIDEgdmVjdG9yIDUx Cm1zaTogQXNzaWduaW5nIE1TSSBJUlEgMjU3IHRvIGxvY2FsIEFQSUMgMSB2ZWN0b3IgNTIKVFND IHRpbWVjb3VudGVyIGRpc2FibGVkOiBDMyBlbmFibGVkLgpUaW1lY291bnRlciAiVFNDIiBmcmVx dWVuY3kgMTk5NTA0NDM1MCBIeiBxdWFsaXR5IC0xMDAwCkdFT01fUEFSVDogcGFydGl0aW9uIDEg aXMgbm90IGFsaWduZWQgb24gNDA5NiBieXRlcwpHRU9NOiBuZXcgZGlzayBjZDAKR0VPTV9QQVJU OiBwYXJ0aXRpb24gMSBpcyBub3QgYWxpZ25lZCBvbiA0MDk2IGJ5dGVzCnVodWIwOiAyIHBvcnRz IHdpdGggMiByZW1vdmFibGUsIHNlbGYgcG93ZXJlZAp1aHViMzogMiBwb3J0cyB3aXRoIDIgcmVt b3ZhYmxlLCBzZWxmIHBvd2VyZWQKdWh1Yjc6IDIgcG9ydHMgd2l0aCAyIHJlbW92YWJsZSwgc2Vs ZiBwb3dlcmVkCnVodWI0OiAyIHBvcnRzIHdpdGggMiByZW1vdmFibGUsIHNlbGYgcG93ZXJlZAp1 aHViMjogMiBwb3J0cyB3aXRoIDIgcmVtb3ZhYmxlLCBzZWxmIHBvd2VyZWQKdWh1YjE6IDIgcG9y dHMgd2l0aCAyIHJlbW92YWJsZSwgc2VsZiBwb3dlcmVkClJvb3QgbW91bnQgd2FpdGluZyBmb3I6 IHVzYnVzNyB1c2J1czMKUm9vdCBtb3VudCB3YWl0aW5nIGZvcjogdXNidXM3IHVzYnVzMwpSb290 IG1vdW50IHdhaXRpbmcgZm9yOiB1c2J1czcgdXNidXMzCnVodWI2OiA2IHBvcnRzIHdpdGggNiBy ZW1vdmFibGUsIHNlbGYgcG93ZXJlZAp1aHViNTogNiBwb3J0cyB3aXRoIDYgcmVtb3ZhYmxlLCBz ZWxmIHBvd2VyZWQKVHJ5aW5nIHRvIG1vdW50IHJvb3QgZnJvbSB6ZnM6dGFuay9ST09UL2RlZmF1 bHQgW10uLi4Kc3RhcnRfaW5pdDogdHJ5aW5nIC9zYmluL2luaXQKbGlucHJvY2ZzIHJlZ2lzdGVy ZWQKcGNpMDogZHJpdmVyIGFkZGVkCmZvdW5kLT4JdmVuZG9yPTB4ODA4NiwgZGV2PTB4MjkzMCwg cmV2aWQ9MHgwMwoJZG9tYWluPTAsIGJ1cz0wLCBzbG90PTMxLCBmdW5jPTMKCWNsYXNzPTBjLTA1 LTAwLCBoZHJ0eXBlPTB4MDAsIG1mZGV2PTAKCWNtZHJlZz0weDAxMDMsIHN0YXRyZWc9MHgwMjgw LCBjYWNoZWxuc3o9MCAoZHdvcmRzKQoJbGF0dGltZXI9MHgwMCAoMCBucyksIG1pbmdudD0weDAw ICgwIG5zKSwgbWF4bGF0PTB4MDAgKDAgbnMpCglpbnRwaW49YywgaXJxPTE5CnBjaTA6MDozMToz OiByZXByb2Jpbmcgb24gZHJpdmVyIGFkZGVkCnBjaTI6IGRyaXZlciBhZGRlZApwY2kzOiBkcml2 ZXIgYWRkZWQKcGNpNDogZHJpdmVyIGFkZGVkCnBjaTEzOiBkcml2ZXIgYWRkZWQKcGNpMDogZHJp dmVyIGFkZGVkCmZvdW5kLT4JdmVuZG9yPTB4ODA4NiwgZGV2PTB4MjkzMCwgcmV2aWQ9MHgwMwoJ ZG9tYWluPTAsIGJ1cz0wLCBzbG90PTMxLCBmdW5jPTMKCWNsYXNzPTBjLTA1LTAwLCBoZHJ0eXBl PTB4MDAsIG1mZGV2PTAKCWNtZHJlZz0weDAxMDMsIHN0YXRyZWc9MHgwMjgwLCBjYWNoZWxuc3o9 MCAoZHdvcmRzKQoJbGF0dGltZXI9MHgwMCAoMCBucyksIG1pbmdudD0weDAwICgwIG5zKSwgbWF4 bGF0PTB4MDAgKDAgbnMpCglpbnRwaW49YywgaXJxPTE5CnBjaTA6MDozMTozOiByZXByb2Jpbmcg b24gZHJpdmVyIGFkZGVkCnBjaTI6IGRyaXZlciBhZGRlZApwY2kzOiBkcml2ZXIgYWRkZWQKcGNp NDogZHJpdmVyIGFkZGVkCnBjaTEzOiBkcml2ZXIgYWRkZWQKZmlybXdhcmU6ICdydW5mdycgdmVy c2lvbiAxOiA4MTkyIGJ5dGVzIGxvYWRlZCBhdCAweGZmZmZmZmZmODFlN2IwYTgKQ3VzZTRCU0Qg djAuMS4zMCBAIC9kZXYvY3VzZQpwZWZzOiBBRVNOSSBoYXJkd2FyZSBhY2NlbGVyYXRpb24gZGlz YWJsZWQKbGluc3lzZnMgcmVnaXN0ZXJlZApmaXJtd2FyZTogJ2l3bjQ5NjVmdycgdmVyc2lvbiAw OiAxODc5NzIgYnl0ZXMgbG9hZGVkIGF0IDB4ZmZmZmZmZmY4MWYwZDBiOApmaXJtd2FyZTogJ2l3 bjEwMDBmdycgdmVyc2lvbiAwOiAzMzc1MjAgYnl0ZXMgbG9hZGVkIGF0IDB4ZmZmZmZmZmY4MWYz YzBiOApmaXJtd2FyZTogJ2l3bjUwMDBmdycgdmVyc2lvbiAwOiAzNDA2OTYgYnl0ZXMgbG9hZGVk IGF0IDB4ZmZmZmZmZmY4MWY4ZjBiOApmaXJtd2FyZTogJ2l3bjUxNTBmdycgdmVyc2lvbiAwOiAz Mzc0MDAgYnl0ZXMgbG9hZGVkIGF0IDB4ZmZmZmZmZmY4MWZlMzBiOApmaXJtd2FyZTogJ2l3bjYw MDBmdycgdmVyc2lvbiAwOiA0NTQ2MDggYnl0ZXMgbG9hZGVkIGF0IDB4ZmZmZmZmZmY4MjAzNjBi OApmaXJtd2FyZTogJ2l3bjYwMDBnMmFmdycgdmVyc2lvbiAwOiA2NzcyOTYgYnl0ZXMgbG9hZGVk IGF0IDB4ZmZmZmZmZmY4MjBhNjBjMApmaXJtd2FyZTogJ2l3bjYwMDBnMmJmdycgdmVyc2lvbiAw OiA0NjA5MTIgYnl0ZXMgbG9hZGVkIGF0IDB4ZmZmZmZmZmY4MjE0YzBjMApmaXJtd2FyZTogJ2l3 bjYwNTBmdycgdmVyc2lvbiAwOiA0Njk3ODAgYnl0ZXMgbG9hZGVkIGF0IDB4ZmZmZmZmZmY4MjFi ZDBiOAphY3BpX3ZpZGVvMDogPEFDUEkgdmlkZW8gZXh0ZW5zaW9uPiBvbiB2Z2FwY2kwCmZvdW5k IFZHQSBDUlQgb3IgVkVTQSBDb21wYXRpYmxlIEFuYWxvZyBNb25pdG9yKDEwMCksIGlkeCMwLCBw b3J0IzAsIGRldGVjdGFibGUgYnkgQklPUywgaGVhZCAjMApmb3VuZCBJbnRlcm5hbC9JbnRlZ3Jh dGVkIERpZ2l0YWwgRmxhdCBQYW5lbCg0MTApLCBpZHgjMCwgcG9ydCMxLCBkZXRlY3RhYmxlIGJ5 IEJJT1MsIGhlYWQgIzAKZnVzZS1mcmVlYnNkOiB2ZXJzaW9uIDAuNC40LCBGVVNFIEFCSSA3LjgK YmdlMDogRGlzYWJsaW5nIGZhc3Rib290CmJnZTA6IERpc2FibGluZyBmYXN0Ym9vdAp3bGFuMDog YnBmIGF0dGFjaGVkCndsYW4wOiBicGYgYXR0YWNoZWQKd2xhbjA6IEV0aGVybmV0IGFkZHJlc3M6 IDBjOjYwOjc2OjQyOjM3OjdiCmlwZncyICgraXB2NikgaW5pdGlhbGl6ZWQsIGRpdmVydCBsb2Fk YWJsZSwgbmF0IGxvYWRhYmxlLCBkZWZhdWx0IHRvIGRlbnksIGxvZ2dpbmcgZGlzYWJsZWQKV0FS TklORzogYXR0ZW1wdCB0byBkb21haW5fYWRkKGJsdWV0b290aCkgYWZ0ZXIgZG9tYWluZmluYWxp emUoKQppbmZvOiBbZHJtXSBJbml0aWFsaXplZCBkcm0gMS4xLjAgMjAwNjA4MTAKZHJtbjA6IDxN b2JpbGUgSW50ZWzCriBHTTQ1IEV4cHJlc3MgQ2hpcHNldD4gb24gdmdhcGNpMAp2Z2FwY2kwOiBh dHRlbXB0aW5nIHRvIGFsbG9jYXRlIDEgTVNJIHZlY3RvcnMgKDEgc3VwcG9ydGVkKQptc2k6IHJv dXRpbmcgTVNJIElSUSAyNTkgdG8gbG9jYWwgQVBJQyAxIHZlY3RvciA1Mwp2Z2FwY2kwOiB1c2lu ZyBJUlEgMjU5IGZvciBNU0kKaW5mbzogW2RybV0gTVNJIGVuYWJsZWQgMSBtZXNzYWdlKHMpCmlu Zm86IFtkcm1dIEFHUCBhdCAweGQwMDAwMDAwIDI1Nk1CCmlpY2J1czA6IDxQaGlsaXBzIEkyQyBi dXM+IG9uIGlpY2JiMCBhZGRyIDB4ZmYKaWljMDogPEkyQyBnZW5lcmljIEkvTz4gb24gaWljYnVz MAppaWMxOiA8STJDIGdlbmVyaWMgSS9PPiBvbiBpaWNidXMxCmlpY2J1czI6IDxQaGlsaXBzIEky QyBidXM+IG9uIGlpY2JiMSBhZGRyIDB4ZmYKaWljMjogPEkyQyBnZW5lcmljIEkvTz4gb24gaWlj YnVzMgppaWMzOiA8STJDIGdlbmVyaWMgSS9PPiBvbiBpaWNidXMzCmlpY2J1czQ6IDxQaGlsaXBz IEkyQyBidXM+IG9uIGlpY2JiMiBhZGRyIDB4ZmYKaWljNDogPEkyQyBnZW5lcmljIEkvTz4gb24g aWljYnVzNAppaWM1OiA8STJDIGdlbmVyaWMgSS9PPiBvbiBpaWNidXM1CmlpY2J1czY6IDxQaGls aXBzIEkyQyBidXM+IG9uIGlpY2JiMyBhZGRyIDB4ZmYKaWljNjogPEkyQyBnZW5lcmljIEkvTz4g b24gaWljYnVzNgppaWM3OiA8STJDIGdlbmVyaWMgSS9PPiBvbiBpaWNidXM3CmlpY2J1czg6IDxQ aGlsaXBzIEkyQyBidXM+IG9uIGlpY2JiNCBhZGRyIDB4ZmYKaWljODogPEkyQyBnZW5lcmljIEkv Tz4gb24gaWljYnVzOAppaWM5OiA8STJDIGdlbmVyaWMgSS9PPiBvbiBpaWNidXM5CmlpY2J1czEw OiA8UGhpbGlwcyBJMkMgYnVzPiBvbiBpaWNiYjUgYWRkciAweGZmCmlpYzEwOiA8STJDIGdlbmVy aWMgSS9PPiBvbiBpaWNidXMxMAppaWMxMTogPEkyQyBnZW5lcmljIEkvTz4gb24gaWljYnVzMTEK aWljYnVzMTI6IDxQaGlsaXBzIEkyQyBidXM+IG9uIGlpY2JiNiBhZGRyIDB4ZmYKaWljMTI6IDxJ MkMgZ2VuZXJpYyBJL08+IG9uIGlpY2J1czEyCmlpYzEzOiA8STJDIGdlbmVyaWMgSS9PPiBvbiBp aWNidXMxMwppaWNidXMxNDogPFBoaWxpcHMgSTJDIGJ1cz4gb24gaWljYmI3IGFkZHIgMHhmZgpp aWMxNDogPEkyQyBnZW5lcmljIEkvTz4gb24gaWljYnVzMTQKaWljMTU6IDxJMkMgZ2VuZXJpYyBJ L08+IG9uIGlpY2J1czE1CmluZm86IFtkcm1dIFN1cHBvcnRzIHZibGFuayB0aW1lc3RhbXAgY2Fj aGluZyBSZXYgMSAoMTAuMTAuMjAxMCkuCmluZm86IFtkcm1dIERyaXZlciBzdXBwb3J0cyBwcmVj aXNlIHZibGFuayB0aW1lc3RhbXAgcXVlcnkuCmRybW4wOiB0YWtpbmcgb3ZlciB0aGUgZmljdGl0 aW91cyByYW5nZSAweGQwMDAwMDAwLTB4ZTAwMDAwMDAKaW5mbzogW2RybV0gSW5pdGlhbGl6ZWQg aTkxNSAxLjYuMCAyMDA4MDczMApzY3NpX2NkLmM6OmlvY3RsIGNtZD04MDA0NjY3ZSBlcnJvcj0y NQpzY3NpX2NkLmM6OmlvY3RsIGNtZD04MDA0NjY3ZSBlcnJvcj0yNQpzY3NpX2NkLmM6OmlvY3Rs IGNtZD04MDA0NjY3ZSBlcnJvcj0yNQpzY3NpX2NkLmM6OmlvY3RsIGNtZD04MDA0NjY3ZSBlcnJv cj0yNQo= --089e01494602541e4b04f76bc2d9-- From owner-freebsd-acpi@FreeBSD.ORG Sat Apr 19 23:13:53 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 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3638EB91 for ; Sat, 19 Apr 2014 23:13:53 +0000 (UTC) Received: from mail-pd0-x22b.google.com (mail-pd0-x22b.google.com [IPv6:2607:f8b0:400e:c02::22b]) (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 09BDA1C0A for ; Sat, 19 Apr 2014 23:13:53 +0000 (UTC) Received: by mail-pd0-f171.google.com with SMTP id r10so2508068pdi.2 for ; Sat, 19 Apr 2014 16:13:52 -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:message-id:subject :from:to:cc:content-type; bh=G+PMkk4t7q6o+AL12fcpgDre0iV0PXwtFMtJwaII/RE=; b=U2n5fWTeHJ6EtmlJRqIlyilGZa/GUnoGwWuigfPvkjH5Rp3NrS3ic44Yizl2Y4JTQx 0mT9fJH8vSiPzW5aJ7zroO7MAq6BXSPeZQMEx1deC6qp1Jg3YfcGJ/3+vwlWt1yerVOG 6qVGrkL5SEQfYGe0yoKL/PX6f1UcB8LzsTG93/dLKJh0eXxawOEvs/e2R1LcdonrQDoo loStyfDrK4JZx3STnUuQSqFra6uqHFBrBWhym2Y8k22IPmT/mVkvZeE5CiCb/J5feDOy AHOLah0N7DpK1f3e/599L/B17qOtSZZlntdCEdYsWwp5DwjhjpZ40P6dtySed/BvAa2D EzQg== MIME-Version: 1.0 X-Received: by 10.69.0.198 with SMTP id ba6mr29987818pbd.16.1397949232589; Sat, 19 Apr 2014 16:13:52 -0700 (PDT) Sender: kob6558@gmail.com Received: by 10.66.73.34 with HTTP; Sat, 19 Apr 2014 16:13:52 -0700 (PDT) In-Reply-To: References: Date: Sat, 19 Apr 2014 16:13:52 -0700 X-Google-Sender-Auth: _oKu6aUUUwGjgp6YdbbhKlxfGko Message-ID: Subject: Re: ACPI bug submission From: Kevin Oberman To: Matt Grice Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: "freebsd-acpi@freebsd.org" X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Apr 2014 23:13:53 -0000 On Sat, Apr 19, 2014 at 2:15 PM, Matt Grice wrote: > Hi all, > > First of all, let me apologise if I have sent this report to you in > error. I am using the latest version of PC-BSD 10 which I believe uses > a "vanilla kernel" (excuse the linuxism) from FreeBSD. > > Symptoms: Lid close does not initiate sleep, battery is not recognised > and does not charge. > > > My hardware is an Acer Extensa 5630EZ. I hope the rest of the > information you might find interesting is in the output of dmesg after > a verbose boot, which is attached. > > The output of acpidump -dt can be found here: > > http://pastebin.com/vpPN86qR > > Kind regards > > Matt Grice > Could you provide the output of: sysctl hw.acpi acpiconf -i 0 -- R. Kevin Oberman, Network Engineer, Retired E-mail: rkoberman@gmail.com From owner-freebsd-acpi@FreeBSD.ORG Sun Apr 20 02:30:25 2014 Return-Path: Delivered-To: freebsd-acpi@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1027E99B; Sun, 20 Apr 2014 02:30:25 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (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 D7EF51AE8; Sun, 20 Apr 2014 02:30:24 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.8/8.14.8) with ESMTP id s3K2UOeX002022; Sun, 20 Apr 2014 02:30:24 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.8/8.14.8/Submit) id s3K2UOnO002021; Sun, 20 Apr 2014 02:30:24 GMT (envelope-from linimon) Date: Sun, 20 Apr 2014 02:30:24 GMT Message-Id: <201404200230.s3K2UOnO002021@freefall.freebsd.org> To: syuu@freebsd.org, linimon@FreeBSD.org, freebsd-amd64@FreeBSD.org, freebsd-acpi@FreeBSD.org From: linimon@FreeBSD.org Subject: Re: kern/187965: [acpi] [patch] Intel Baytrail-M NUC panics because of buggy ACPI table X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Apr 2014 02:30:25 -0000 Old Synopsis: Intel Baytrail-M NUC panics because of buggy ACPI table New Synopsis: [acpi] [patch] Intel Baytrail-M NUC panics because of buggy ACPI table State-Changed-From-To: open->open State-Changed-By: linimon State-Changed-When: Sun Apr 20 01:48:45 UTC 2014 State-Changed-Why: reclassify. Responsible-Changed-From-To: freebsd-amd64->freebsd-acpi Responsible-Changed-By: linimon Responsible-Changed-When: Sun Apr 20 01:48:45 UTC 2014 Responsible-Changed-Why: http://www.freebsd.org/cgi/query-pr.cgi?pr=187965 From owner-freebsd-acpi@FreeBSD.ORG Mon Apr 21 09:45:39 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 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 22229C7 for ; Mon, 21 Apr 2014 09:45:39 +0000 (UTC) Received: from mail.0x20.net (mail.0x20.net [IPv6:2001:aa8:fffb:1::3]) (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 CE9DB12D4 for ; Mon, 21 Apr 2014 09:45:38 +0000 (UTC) Received: from e-new.0x20.net (mail.0x20.net [IPv6:2001:aa8:fffb:1::3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.0x20.net (Postfix) with ESMTPS id B15CA6A6020; Mon, 21 Apr 2014 11:45:35 +0200 (CEST) Received: from e-new.0x20.net (localhost [127.0.0.1]) by e-new.0x20.net (8.14.7/8.14.7) with ESMTP id s3L9jZxB097006; Mon, 21 Apr 2014 11:45:35 +0200 (CEST) (envelope-from lars@e-new.0x20.net) Received: (from lars@localhost) by e-new.0x20.net (8.14.7/8.14.7/Submit) id s3L9jZas095785; Mon, 21 Apr 2014 11:45:35 +0200 (CEST) (envelope-from lars) Date: Mon, 21 Apr 2014 11:45:35 +0200 From: Lars Engels To: Matt Grice Subject: Re: ACPI bug submission Message-ID: <20140421094534.GA35980@e-new.0x20.net> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="mP3DRpeJDSE+ciuQ" Content-Disposition: inline In-Reply-To: X-Editor: VIM - Vi IMproved 7.4 X-Operation-System: FreeBSD 8.4-RELEASE-p4 User-Agent: Mutt/1.5.23 (2014-03-12) Cc: freebsd-acpi@FreeBSD.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Apr 2014 09:45:39 -0000 --mP3DRpeJDSE+ciuQ Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Apr 19, 2014 at 10:15:00PM +0100, Matt Grice wrote: > Hi all, >=20 > First of all, let me apologise if I have sent this report to you in > error. I am using the latest version of PC-BSD 10 which I believe uses > a "vanilla kernel" (excuse the linuxism) from FreeBSD. >=20 > Symptoms: Lid close does not initiate sleep, battery is not recognised > and does not charge. To suspend the notebook when the lid is closed, add this to /etc/sysctl.conf: hw.acpi.lid_switch_state=3DS3 --mP3DRpeJDSE+ciuQ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iKYEARECAGYFAlNU6L5fFIAAAAAALgAoaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl bnBncC5maWZ0aGhvcnNlbWFuLm5ldDE3RkMwOEUxNUUwOUJEMjE0ODlFMjA1MDI5 Q0U3NURBQzBGNzY5RjgACgkQKc512sD3afhqOgCglMI2T8Avat5bWVc2Om054m0E C9sAn1konnO/CFiliCq0QANgh/+XToaG =9Oip -----END PGP SIGNATURE----- --mP3DRpeJDSE+ciuQ-- From owner-freebsd-acpi@FreeBSD.ORG Mon Apr 21 11:06:42 2014 Return-Path: Delivered-To: freebsd-acpi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 922A0F2A for ; Mon, 21 Apr 2014 11:06:42 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (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 66E1C194C for ; Mon, 21 Apr 2014 11:06:42 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.8/8.14.8) with ESMTP id s3LB6g3N085621 for ; Mon, 21 Apr 2014 11:06:42 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.8/8.14.8/Submit) id s3LB6fvY085619 for freebsd-acpi@FreeBSD.org; Mon, 21 Apr 2014 11:06:41 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 21 Apr 2014 11:06:41 GMT Message-Id: <201404211106.s3LB6fvY085619@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.17 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Apr 2014 11:06:42 -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/187965 acpi [acpi] [patch] Intel Baytrail-M NUC panics because of o kern/187152 acpi [i386] [acpi] resume from ACPI suspend (s3) sometimes o kern/181665 acpi [acpi] System will not go into S3 state. o kern/180897 acpi [acpi] ACPI error with MB p8h67 v.1405 o kern/174766 acpi [acpi] Random acpi panic o kern/174504 acpi [ACPI] Suspend/resume broken on Lenovo x220 o kern/173414 acpi [acpi] ACPI battery time incorrect o kern/173408 acpi [acpi] [regression] ACPI Regression: battery does not 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/73823 acpi [request] acpi / power-on by timer support 31 problems total. From owner-freebsd-acpi@FreeBSD.ORG Mon Apr 21 14:38:37 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 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 270AC6D8 for ; Mon, 21 Apr 2014 14:38:37 +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 985D01CE7 for ; Mon, 21 Apr 2014 14:38:35 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id s3LEcK8P010524; Tue, 22 Apr 2014 00:38:20 +1000 (EST) (envelope-from smithi@nimnet.asn.au) Date: Tue, 22 Apr 2014 00:38:20 +1000 (EST) From: Ian Smith To: Matt Grice Subject: Re: ACPI bug submission In-Reply-To: Message-ID: <20140422001708.Q9458@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.17 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Apr 2014 14:38:37 -0000 On Sat, 19 Apr 2014 22:15:00 +0100, Matt Grice wrote: > Hi all, > > First of all, let me apologise if I have sent this report to you in > error. I am using the latest version of PC-BSD 10 which I believe uses > a "vanilla kernel" (excuse the linuxism) from FreeBSD. > > Symptoms: Lid close does not initiate sleep, battery is not recognised > and does not charge. > > > My hardware is an Acer Extensa 5630EZ. I hope the rest of the > information you might find interesting is in the output of dmesg after > a verbose boot, which is attached. > > The output of acpidump -dt can be found here: > > http://pastebin.com/vpPN86qR What Lars said about 'hw.acpi.lid_switch_state=S3' .. assuming suspend & resume work properly normally (via 'acpiconf -s3' or your sleep button) But regarding your battery, from your dmesg it IS being recognised: battery0: on acpi0 acpi_acad0: on acpi0 [..] battery0: battery initialization start acpi_acad0: acline initialization start battery0: critically low charge! acpi_acad0: On Line [..] battery0: battery initialization done, tried 1 times .. but is reporting critically low state on startup. Which is either a dead battery, or a broken charging circuit. Usually that has nothing to do with the OS; if you have it plugged in when not running, it should fully charge, or at least charge past the critically low state fairly quickly - and even when running on AC power. So as Kevin asked, 'sysctl hw.acpi' and 'acpiconf -i0' could be helpful. cheers, Ian From owner-freebsd-acpi@FreeBSD.ORG Mon Apr 21 16:05:39 2014 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AB9E3C62 for ; Mon, 21 Apr 2014 16:05:39 +0000 (UTC) Received: from mail.atarian.co.uk (rev3.cooljo.in [185.10.200.198]) by mx1.freebsd.org (Postfix) with ESMTP id 3B5AE172E for ; Mon, 21 Apr 2014 16:05:37 +0000 (UTC) Received: from [192.168.0.128] (cpc24-cove12-2-0-cust184.3-1.cable.virginm.net [81.106.120.185]) by mail.atarian.co.uk (Postfix) with ESMTPSA id 2EC5C1001DF for ; Mon, 21 Apr 2014 16:05:19 +0000 (UTC) Date: Mon, 21 Apr 2014 17:05:33 +0100 Subject: Fwd: Re: ACPI bug submission Message-ID: Importance: normal From: Matt Grice To: "freebsd-acpi@freebsd.org" MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Apr 2014 16:05:39 -0000 U29ycnksIFBFQktBQyBlcnJvciwgaXQgYXBwZWFycyBJJ3ZlIGJlZW4gcmVwbHlpbmcgb2ZmLWxp c3QuCgpQbGVhc2UgZmluZCBiZWxvdyBteSByZXNwb25zZS4gSXQgYXBwZWFycyB0aGF0IHRoZSBs YXRlc3QgcHJvYmxlbSBpcyBzb21ldGhpbmcgdG8gZG8gd2l0aCBYIGFzIGl0IGNyYXNoZXMgb3V0 IHdoZW4gdHJ5aW5nIHRvIHJldHVybiB0byB0aGUgY29uc29sZSB3aGVuIHByZXNzaW5nIEN0cmwt QWx0LUYxIHRvby4KClRoYW5rcwoKTWF0dCBHcmljZQoKPGRpdj4tLS0tLS0tLSBPcmlnaW5hbCBt ZXNzYWdlIC0tLS0tLS0tPC9kaXY+PGRpdj5Gcm9tOiBNYXR0IEdyaWNlIDxtYXR0QGF0YXJpYW4u Y28udWs+IDwvZGl2PjxkaXY+RGF0ZToyMS8wNC8yMDE0ICAxNDo1MSAgKEdNVCswMDowMCkgPC9k aXY+PGRpdj5UbzogS2V2aW4gT2Jlcm1hbiA8cmtvYmVybWFuQGdtYWlsLmNvbT4gPC9kaXY+PGRp dj5TdWJqZWN0OiBSZTogQUNQSSBidWcgc3VibWlzc2lvbiA8L2Rpdj48ZGl2Pgo8L2Rpdj5UaGFu a3MgZm9yIHRoZSBoZWxwIEtldmluLCBJJ20gcXVpdGUgbmV3IHRvIEZyZWVCU0QuIEkgbm90aWNl ZCB0aGUgc3lzY3RsIGZvciBsaWRfc3dpdGNoIHdhc24ndCBzZXQsIGJ1dCBJIGp1c3QgdGhvdWdo dCBpdCB3YXMgZm9yIGluZm9ybWF0aW9uIG9ubHkuIG1hbiA4IHN5c2N0bCBpcyBteSBmcmllbmQu CgpTbGVlcCBub3cgd29ya3MsIGl0IGp1c3Qgd29uJ3Qgd2FrZSB1cC4gSSd2ZSBkZWJ1Z2dlZCB0 aGlzIGtpbmQgb2YgdGhpbmcgYmVmb3JlIHdpdGggTGludXggc28gSSdsbCBwbG91Z2ggb24gZnJv bSBoZXJlLCBJIGV4cGVjdCBJJ2xsIGp1c3QgaGF2ZSB0byB3b3JrIG91dCB3aGljaCBzeXN0ZW1z IGFyZSBzaHV0IGRvd24gYXQgc2xlZXAgYW5kIHdoaWNoIG9uZXMgYXJlIHJlc3RhcnRlZCBhZnRl cndhcmRzLiBJJ3ZlIGhhZCBpc3N1ZXMgd2l0aCBzb3VuZCBtb2R1bGVzIGRvaW5nIHRoaXMga2lu ZCBvZiB0aGluZyBpbiB0aGUgcGFzdC4gSSB0aGluayBhIHNlcmlhbCBjb25zb2xlIG1pZ2h0IGJl IGluIG9yZGVyLgoKVGhlIGJhdHRlcnkgdGhpbmcgaXMgcmVhbGx5IG9kZCBhcyBpdCdzIGEgdmly dHVhbGx5IG5ldyBiYXR0ZXJ5LCBhbmQgSSB3YXNuJ3QgYXdhcmUgdGhlcmUgd2VyZSBpc3N1ZXMg YmVmb3JlIHRoZSBpbnN0YWxsLiBIb3dldmVyLCB0aGUgdGhpbmcgd29uJ3QgY2hhcmdlIHdoZW4g aXQncyBzd2l0Y2hlZCBvZmYsIHdoaWNoIHNjcmVhbXMgSEFSRFdBUkUhIEl0J3MgcHJvYmFibHkg b25lIG9mIHRob3NlIGJsYWNrIHN3YW4gc2l0dWF0aW9ucy4KClRoYW5rcyBhZ2FpbiBmb3IgdGFr aW5nIHRoZSB0aW1lIG91dCB0byBoZWxwLiBJdCdzIHJlYWxseSBhcHByZWNpYXRlZC4KCgpNYXR0 IEdyaWNlCgoKCk9uIDIwLzA0LzIwMTQgMTY6MTIsIEtldmluIE9iZXJtYW4gd3JvdGU6Ck9uIFN1 biwgQXByIDIwLCAyMDE0IGF0IDI6MzkgQU0sIE1hdHQgR3JpY2UgPG1hdHRAYXRhcmlhbi5jby51 az4gd3JvdGU6CkNvdWxkIHlvdSBwcm92aWRlIHRoZSBvdXRwdXQgb2Y6CnN5c2N0bCBody5hY3Bp Cgpbcm9vdEBSYXB0b3JdIC91c3IvcG9ydHMvY29tbXMvd3NwciMgc3lzY3RsIGh3LmFjcGkKaHcu YWNwaS5zdXBwb3J0ZWRfc2xlZXBfc3RhdGU6IFMzIFM0IFM1ClMzIGlzIHN1c3BlbmQgdG8gUkFN LCBTNCBpcyBzdXNwZW5kIHRvIGRpc2ssIGFuZCBTNSBpcyBzaHV0ZG93bgpody5hY3BpLnBvd2Vy X2J1dHRvbl9zdGF0ZTogUzUKUG93ZXIgYnV0dG9uIHdpbGwgZG8gYSBzeXN0ZW0gc2h1dGZvd24g YW5kIHBvd2VyIG9mZiAKaHcuYWNwaS5zbGVlcF9idXR0b25fc3RhdGU6IFMzClNsZWVwIGJ1dHRv biB3aWxsIHN1c3BlbmQgdG8gUkFNLiBMaXR0bGUgcG93ZXIgdXNlIGFuZCBzdXBwb3J0ZWQgYnkg QklPUyB3aXRoIG1pbmltYWwgT1Mgc3VwcG9ydC4gV29ya3Mgb24gRnJlZUJTRApody5hY3BpLmxp ZF9zd2l0Y2hfc3RhdGU6IE5PTkUKQ2xvc2luZyB0aGUgbGlkIGRvZXMgbm90aGluZyBpbiBCSU9T LiBEaXNwbGF5IGJhY2tsaWdodCBteSB0dXJuIG9mZiwgYnV0IHRoYXQncyBpdC4gCmh3LmFjcGku c3RhbmRieV9zdGF0ZTogTk9ORQpJZiB0aGUgcG93ZXIgbWFuYWdlbWVudCBzeXN0ZW0gd2FudHMg dG8gZ28gdG8gYSBzdGFuZGJ5IG1vZGUsIG5vdGhpbmcgaGFwcGVucy4gCmh3LmFjcGkuc3VzcGVu ZF9zdGF0ZTogUzMKSWYgYSBzdXNwZW5kIGlzIHJlcXVlc3RlZCBieSB0aGUgT1MsIHN1c3BlbmQg dG8gUkFNIGlzIHVzZWQgCmh3LmFjcGkuc2xlZXBfZGVsYXk6IDEKRGVsYXkgMSBzZWNvbmQgZm9y IE9TIHRvIGRvIHByZXBhcmF0aW9uIGZvciBzdXNwZW5kIHRvIFJBTSAKaHcuYWNwaS5zNGJpb3M6 IDAKQklPUyBkb2VzIG5vdCBzdXBwb3J0IHN1c3BlbmQgdG8gZGlzay4gT1Mgc3VwcG9ydCBpcyBy ZXF1aXJlZC4gRnJlZUJTRCBkb2VzIG5vdCBoYXZlIHRoaXMgc3VwcG9ydC4KaHcuYWNwaS52ZXJi b3NlOiAxCmh3LmFjcGkuZGlzYWJsZV9vbl9yZWJvb3Q6IDAKaHcuYWNwaS5oYW5kbGVfcmVib290 OiAwCmh3LmFjcGkucmVzZXRfdmlkZW86IDAKaHcuYWNwaS5jcHUuY3hfbG93ZXN0OiBDMQpQb3dl ciBzYXZpbmcgQ3ggc3RhdGVzIGFyZSBOT1QgZW5hYmxlZC4gCmh3LmFjcGkudGhlcm1hbC5taW5f cnVudGltZTogMApody5hY3BpLnRoZXJtYWwucG9sbGluZ19yYXRlOiAxMApBQ1BJIHdpbGwgdXBk YXRlIHRlbXBlcmF0dXJlIGluZm9ybWF0aW9uIGV2ZXJ5IDEwIHNlY29uZHMgCmh3LmFjcGkudGhl cm1hbC51c2VyX292ZXJyaWRlOiAwCmh3LmFjcGkudGhlcm1hbC50ejAudGVtcGVyYXR1cmU6IDM5 LjBDClRoZXJtYWwgem9uZSAwIGlzIDM5Qy4gVGhpcyBpcyB1c3VhbGx5IHRoZSBDUFUuIDM5QyBp cyBWRVJZIGNvb2wuIEhvcGVmdWxseSBpdCBpIGFjY3VyYXRlLgpody5hY3BpLnRoZXJtYWwudHow LmFjdGl2ZTogLTEKQUNQSSBpcyBOT1QgdGhyb3R0bGluZyB0aGUgQ1BVIHRvIGNvbnRyb2wgdGVt cGVyYXR1cmUgCmh3LmFjcGkudGhlcm1hbC50ejAucGFzc2l2ZV9jb29saW5nOiAwCkFDUEkgaXMg bm90IGluY3JlYXNpbmcgc3lzdGVtIGNvb2xpbmcgY2FwYWJpbGl0eSAodXN1YWxseSB0aGUgZmFu KSB0byByZWR1Y2UgdGVtcGVyYXR1cmUuIE5PVEU6IFRoaXMgZG9lcyBub3QgbWVhbiBub24tQUNQ SSBjb250cm9scyBhcmUgbm90IHVzZWQhCmh3LmFjcGkudGhlcm1hbC50ejAudGhlcm1hbF9mbGFn czogMApody5hY3BpLnRoZXJtYWwudHowLl9QU1Y6IDk1LjBDCkF0IDk1QywgdHVybiB0aGUgY29v bGluZyAoZmFucykgdG8gbWF4aW11bS4KaHcuYWNwaS50aGVybWFsLnR6MC5fSE9UOiAtMQpody5h Y3BpLnRoZXJtYWwudHowLl9DUlQ6IDk4LjBDCkF0IDk4QywgdGhyb3R0bGV0aGUgQ1BVIHRvIHJl ZHVjZSB0ZW1wZXJhdHVyZSAKaHcuYWNwaS50aGVybWFsLnR6MC5fQUN4OiAtMSAtMSAtMSAtMSAt MSAtMSAtMSAtMSAtMSAtMQpody5hY3BpLnRoZXJtYWwudHowLl9UQzE6IDAKaHcuYWNwaS50aGVy bWFsLnR6MC5fVEMyOiA1MApody5hY3BpLnRoZXJtYWwudHowLl9UU1A6IDAKaHcuYWNwaS50aGVy bWFsLnR6MS50ZW1wZXJhdHVyZTogMzkuMEMKT2RkIHRoYXQgdHowIGFuZCB0ejEgYXJlIGJvdGgg MzlDLiBTZWVtcyB1bmxpa2VseS4gTWF5IGJlIGRpZmZlcmVudCBDUFUgc2Vuc29yIG9yIHNvbWV0 aGluZyBlbHNlLgpody5hY3BpLnRoZXJtYWwudHoxLmFjdGl2ZTogLTEKaHcuYWNwaS50aGVybWFs LnR6MS5wYXNzaXZlX2Nvb2xpbmc6IDAKaHcuYWNwaS50aGVybWFsLnR6MS50aGVybWFsX2ZsYWdz OiAwCmh3LmFjcGkudGhlcm1hbC50ejEuX1BTVjogLTEKaHcuYWNwaS50aGVybWFsLnR6MS5fSE9U OiAtMQpody5hY3BpLnRoZXJtYWwudHoxLl9DUlQ6IDk4LjBDCkF0IDk4QywgcG93ZXIgZG93biAo aWYgc3VwcG9ydGVkKS4gVGhpcyBpcyBkaWZmZXJlbnQgZnJvbSB0aGUgaGFyZHdhcmUgc2h1dGRv d24gb24gc2V2ZXJlIG92ZXJ0ZW1wIHRoYXQgc2ltcGx5IGtpbGxzIHBvd2VyLgpody5hY3BpLnRo ZXJtYWwudHoxLl9BQ3g6IC0xIC0xIC0xIC0xIC0xIC0xIC0xIC0xIC0xIC0xCmh3LmFjcGkudGhl cm1hbC50ejEuX1RDMTogLTEKaHcuYWNwaS50aGVybWFsLnR6MS5fVEMyOiAtMQpody5hY3BpLnRo ZXJtYWwudHoxLl9UU1A6IC0xCmh3LmFjcGkuYmF0dGVyeS5saWZlOiAwCmh3LmFjcGkuYmF0dGVy eS50aW1lOiAtMQpody5hY3BpLmJhdHRlcnkuc3RhdGU6IDQKaHcuYWNwaS5iYXR0ZXJ5LnVuaXRz OiAxCmh3LmFjcGkuYmF0dGVyeS5pbmZvX2V4cGlyZTogNQpody5hY3BpLmFjbGluZTogMQpody5h Y3BpLnZpZGVvLmNydDAuYWN0aXZlOiAwCmh3LmFjcGkudmlkZW8ubGNkMC5hY3RpdmU6IDEKaHcu YWNwaS52aWRlby5sY2QwLmJyaWdodG5lc3M6IDEwMApody5hY3BpLnZpZGVvLmxjZDAuZnVsbHBv d2VyOiAxMDAKaHcuYWNwaS52aWRlby5sY2QwLmVjb25vbXk6IDYwCmh3LmFjcGkudmlkZW8ubGNk MC5sZXZlbHM6IDEwMCA2MCAxMCAyMCAzMCA0MCA1MCA2MCA3MCA4MCA5MCAxMDAKIApJZiB5b3Ug d2FudCB0aGUgc3lzdGVtIHRvIHN1c3BlbmQgd2hlbiB0aGUgbGlkIGNsb3NlcywgInN5c2N0bCBo dy5hY3BpLmxpZF9zd2l0Y2hfc3RhdGU9UzMiLgoKCgoKYWNwaWNvbmYgLWkgMAoKW3Jvb3RAUmFw dG9yXSAvdXNyL3BvcnRzL2NvbW1zL3dzcHIjIGFjcGljb25mIC1pIG8KRGVzaWduIGNhcGFjaXR5 OiAgICAgICA0NDAwIG1BaApMYXN0IGZ1bGwgY2FwYWNpdHk6ICAgICAzNzU3IG1BaApCYXR0ZXJ5 IGlzIGdldHRpbmcgb2xkIGFuZCBvbmx5IHdpbGwgY2hhcmdlIHRvIDg1JSBvZiBpdCdzIGRlc2ln biBjYXBhY2l0eS4gClRlY2hub2xvZ3k6ICAgICAgICAgICAgIHNlY29uZGFyeSAocmVjaGFyZ2Vh YmxlKQpEZXNpZ24gdm9sdGFnZTogICAgICAgICAxMTEwMCBtVgpDYXBhY2l0eSAod2Fybik6ICAg ICAgICAxODUgbUFoCkNhcGFjaXR5IChsb3cpOiAgICAgICAgIDEyOSBtQWgKTG93L3dhcm4gZ3Jh bnVsYXJpdHk6ICAgNTYgbUFoCldhcm4vZnVsbCBncmFudWxhcml0eTogIDM1NzIgbUFoCk1vZGVs IG51bWJlcjogR1JBUEUzMgpTZXJpYWwgbnVtYmVyOiAyNwpUeXBlOiBMSU9OCk9FTSBpbmZvOiAg ICAgICAgICAgICAgIFNBTllPClN0YXRlOiAgICAgICAgICAgICAgICAgIGNyaXRpY2FsCllvdXIg YmF0dGVyeSBpcyBkeWluZyEgClJlbWFpbmluZyBjYXBhY2l0eTogICAgIDAlCk9LLiBJdCdzIGRl YWQuIApSZW1haW5pbmcgdGltZTogICAgICAgICB1bmtub3duClByZXNlbnQgcmF0ZTogICAgICAg ICAgIDAgbUEgKDAgbVcpCkl0J3Mgbm90IGRpc2NoYXJnaW5nLiAKUHJlc2VudCB2b2x0YWdlOiAg ICAgICAgNzg3MCBtVgpJdCBpcyBhdCA3Ljkgdm9sdHMgd2hpY2ggaXMgdG9vIGxvdyB0byBydW4g dGhlIHN5c3RlbS4gCgpTaW5jZSB0aGUgc3lzdGVtIGFwcGVhcnMgdG8gYmUgb24gQUMgcG93ZXIs IGJ1dCB0aGUgYmF0dGVyeSBpcyBub3QgY2hhcmdpbmcsIHNvbWV0aGluZyBpcyB3cm9uZyBoZXJl LiBJIGhhdmUgbm8gaWRlYSB3aGF0LgoKCkl0IGFwcGVhcnMgdGhhdCBlaXRoZXIgdGhlIGNoYXJn aW5nIHN5c3RlbSBvciB0aGUgYmF0dGVyeSBoYXMgZmFpbGVkLk5laXRoZXIgaW52b2x2ZWQgdGhl IE9TLCBidXQgaW5kaWNhdGVzIGEgaGFyZHdhcmUgaXNzdWUgd2l0aCB0aGUgZGV2aWNlLgoKVGhl cmUgYXJlIHNldmVyYWwgQUNQSSB2YXJpYWJsZXMgSSBkb24ndCByZWNvZ25pemUgb3IgYW0gc2lt cGx5IG5vdCBmYW1pbGlhciB3aXRoLCBidXQgdGhpcyB3aWxsIGdpdmUgeW91IHNvbWUgICAgICAg ICAgICAgICBpZGVhIHdoYXQgbWFueSBvZiB0aGUgaW1wb3J0YW50IG9uZXMgYXJlLiBSZW1lbWJl ciB0aGF0IEFDUEkgaXMgZmlybXdhcmUgYW5kIG1heSBoYXZlIGVycm9ycyB0aGF0IHJlc3VsdCBp biBpdHMgbHlpbmcgdG8gdGhlIE9TLiBJIGRvbid0IHRydXN0IHNvbWUgb2Ygd2hhdCBJIHNlZSwg ZXNwZWNpYWxseSB0aGUgdGVtcGVyYXR1cmUuIE1vc3QgbGFwdG9wcyBpZGxlIGF0IGJldHdlZW4g ICAgICAgICAgICAgICA1MCBhbmQgNjBDLiBTZWVpbmcgdHdvIHpvbmVzIGF0IDM5QyBpcyB2ZXJ5 IG9kZC4KLS0gClIuIEtldmluIE9iZXJtYW4sIE5ldHdvcmsgRW5naW5lZXIsIFJldGlyZWQKRS1t YWlsOiBya29iZXJtYW5AZ21haWwuY29tCgo= From owner-freebsd-acpi@FreeBSD.ORG Mon Apr 21 18:29:25 2014 Return-Path: Delivered-To: freebsd-acpi@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5EB29EAF; Mon, 21 Apr 2014 18:29:25 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (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 2E84B16F8; Mon, 21 Apr 2014 18:29:25 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.8/8.14.8) with ESMTP id s3LITPvJ031264; Mon, 21 Apr 2014 18:29:25 GMT (envelope-from jhb@freefall.freebsd.org) Received: (from jhb@localhost) by freefall.freebsd.org (8.14.8/8.14.8/Submit) id s3LITOku031263; Mon, 21 Apr 2014 18:29:24 GMT (envelope-from jhb) Date: Mon, 21 Apr 2014 18:29:24 GMT Message-Id: <201404211829.s3LITOku031263@freefall.freebsd.org> To: syuu@freebsd.org, jhb@FreeBSD.org, freebsd-acpi@FreeBSD.org, takawata@FreeBSD.org From: jhb@FreeBSD.org Subject: Re: kern/187965: [acpi] [patch] Intel Baytrail-M NUC panics because of buggy ACPI table X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Apr 2014 18:29:25 -0000 Synopsis: [acpi] [patch] Intel Baytrail-M NUC panics because of buggy ACPI table State-Changed-From-To: open->patched State-Changed-By: jhb State-Changed-When: Mon Apr 21 18:28:02 UTC 2014 State-Changed-Why: This was fixed in HEAD in r263795 and r263859. Responsible-Changed-From-To: freebsd-acpi->takawata Responsible-Changed-By: jhb Responsible-Changed-When: Mon Apr 21 18:28:02 UTC 2014 Responsible-Changed-Why: This was fixed in HEAD in r263795 and r263859. http://www.freebsd.org/cgi/query-pr.cgi?pr=187965 From owner-freebsd-acpi@FreeBSD.ORG Mon Apr 21 19:07:52 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 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 031587B2 for ; Mon, 21 Apr 2014 19:07:52 +0000 (UTC) Received: from mail-pa0-x230.google.com (mail-pa0-x230.google.com [IPv6:2607:f8b0:400e:c03::230]) (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 CA90C1A8C for ; Mon, 21 Apr 2014 19:07:51 +0000 (UTC) Received: by mail-pa0-f48.google.com with SMTP id hz1so4022510pad.21 for ; Mon, 21 Apr 2014 12:07:51 -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:message-id:subject :from:to:cc:content-type; bh=Uj9vSyyu/vtG3SnYSyUxwrlHhct4llHfFMPWFtiofy4=; b=Zq2ZhuySRUvnVFdR8xycCaJpPSSGmVB3K976NQZ4QAT2QSPxdDC9tnlz/f/41Xpqch 43jXJ3ix5h5gJ9AGVQds16/clmoO5I7IMCtagDoEKSEW+my8jd1r+H3sYXLD6TOS880R vW6A97LgJb3oWYNYS+MORcWQj671LnaKLn5tYt1SfkjlLB4bL6VLQ351JRq/BvHZ21MC zOk7gpgSY1yWuKryKirkz0rQTYyTPo5eYW50tuuvnOHMt5NrXESEaEnxsZEP9Amnqadj dTjZmf+tFGHPzmx+2RVKC/cZV5Cgg1+8l1QBsZ4jZeSgQdP3IddzPdH7FSxMw1btiMot ve0Q== MIME-Version: 1.0 X-Received: by 10.66.251.233 with SMTP id zn9mr40087462pac.67.1398107271450; Mon, 21 Apr 2014 12:07:51 -0700 (PDT) Sender: kob6558@gmail.com Received: by 10.66.73.34 with HTTP; Mon, 21 Apr 2014 12:07:51 -0700 (PDT) In-Reply-To: References: Date: Mon, 21 Apr 2014 12:07:51 -0700 X-Google-Sender-Auth: 2Gwq7VLps6Lt6yx2vp2N1TK2rxc Message-ID: Subject: Re: Re: ACPI bug submission From: Kevin Oberman To: Matt Grice Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: "freebsd-acpi@freebsd.org" X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Apr 2014 19:07:52 -0000 On Mon, Apr 21, 2014 at 9:05 AM, Matt Grice wrote: > Sorry, PEBKAC error, it appears I've been replying off-list. > > Please find below my response. It appears that the latest problem is > something to do with X as it crashes out when trying to return to the > console when pressing Ctrl-Alt-F1 too. > > Thanks > > Matt Grice > >
-------- Original message --------
From: Matt Grice < > matt@atarian.co.uk>
Date:21/04/2014 14:51 (GMT+00:00) >
To: Kevin Oberman
Subject: > Re: ACPI bug submission
>
Thanks for the help Kevin, I'm quite new to FreeBSD. I noticed the > sysctl for lid_switch wasn't set, but I just thought it was for information > only. man 8 sysctl is my friend. > > Sleep now works, it just won't wake up. I've debugged this kind of thing > before with Linux so I'll plough on from here, I expect I'll just have to > work out which systems are shut down at sleep and which ones are restarted > afterwards. I've had issues with sound modules doing this kind of thing in > the past. I think a serial console might be in order. > > The battery thing is really odd as it's a virtually new battery, and I > wasn't aware there were issues before the install. However, the thing won't > charge when it's switched off, which screams HARDWARE! It's probably one of > those black swan situations. > > Thanks again for taking the time out to help. It's really appreciated. > > > Matt Grice > > > > On 20/04/2014 16:12, Kevin Oberman wrote: > On Sun, Apr 20, 2014 at 2:39 AM, Matt Grice wrote: > Could you provide the output of: > sysctl hw.acpi > > [root@Raptor] /usr/ports/comms/wspr# sysctl hw.acpi > hw.acpi.supported_sleep_state: S3 S4 S5 > S3 is suspend to RAM, S4 is suspend to disk, and S5 is shutdown > hw.acpi.power_button_state: S5 > Power button will do a system shutfown and power off > hw.acpi.sleep_button_state: S3 > Sleep button will suspend to RAM. Little power use and supported by BIOS > with minimal OS support. Works on FreeBSD > hw.acpi.lid_switch_state: NONE > Closing the lid does nothing in BIOS. Display backlight my turn off, but > that's it. > hw.acpi.standby_state: NONE > If the power management system wants to go to a standby mode, nothing > happens. > hw.acpi.suspend_state: S3 > If a suspend is requested by the OS, suspend to RAM is used > hw.acpi.sleep_delay: 1 > Delay 1 second for OS to do preparation for suspend to RAM > hw.acpi.s4bios: 0 > BIOS does not support suspend to disk. OS support is required. FreeBSD > does not have this support. > hw.acpi.verbose: 1 > hw.acpi.disable_on_reboot: 0 > hw.acpi.handle_reboot: 0 > hw.acpi.reset_video: 0 > hw.acpi.cpu.cx_lowest: C1 > Power saving Cx states are NOT enabled. > hw.acpi.thermal.min_runtime: 0 > hw.acpi.thermal.polling_rate: 10 > ACPI will update temperature information every 10 seconds > hw.acpi.thermal.user_override: 0 > hw.acpi.thermal.tz0.temperature: 39.0C > Thermal zone 0 is 39C. This is usually the CPU. 39C is VERY cool. > Hopefully it i accurate. > hw.acpi.thermal.tz0.active: -1 > ACPI is NOT throttling the CPU to control temperature > hw.acpi.thermal.tz0.passive_cooling: 0 > ACPI is not increasing system cooling capability (usually the fan) to > reduce temperature. NOTE: This does not mean non-ACPI controls are not used! > hw.acpi.thermal.tz0.thermal_flags: 0 > hw.acpi.thermal.tz0._PSV: 95.0C > At 95C, turn the cooling (fans) to maximum. > hw.acpi.thermal.tz0._HOT: -1 > hw.acpi.thermal.tz0._CRT: 98.0C > At 98C, throttlethe CPU to reduce temperature > hw.acpi.thermal.tz0._ACx: -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 > hw.acpi.thermal.tz0._TC1: 0 > hw.acpi.thermal.tz0._TC2: 50 > hw.acpi.thermal.tz0._TSP: 0 > hw.acpi.thermal.tz1.temperature: 39.0C > Odd that tz0 and tz1 are both 39C. Seems unlikely. May be different CPU > sensor or something else. > hw.acpi.thermal.tz1.active: -1 > hw.acpi.thermal.tz1.passive_cooling: 0 > hw.acpi.thermal.tz1.thermal_flags: 0 > hw.acpi.thermal.tz1._PSV: -1 > hw.acpi.thermal.tz1._HOT: -1 > hw.acpi.thermal.tz1._CRT: 98.0C > At 98C, power down (if supported). This is different from the hardware > shutdown on severe overtemp that simply kills power. > hw.acpi.thermal.tz1._ACx: -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 > hw.acpi.thermal.tz1._TC1: -1 > hw.acpi.thermal.tz1._TC2: -1 > hw.acpi.thermal.tz1._TSP: -1 > hw.acpi.battery.life: 0 > hw.acpi.battery.time: -1 > hw.acpi.battery.state: 4 > hw.acpi.battery.units: 1 > hw.acpi.battery.info_expire: 5 > hw.acpi.acline: 1 > hw.acpi.video.crt0.active: 0 > hw.acpi.video.lcd0.active: 1 > hw.acpi.video.lcd0.brightness: 100 > hw.acpi.video.lcd0.fullpower: 100 > hw.acpi.video.lcd0.economy: 60 > hw.acpi.video.lcd0.levels: 100 60 10 20 30 40 50 60 70 80 90 100 > > If you want the system to suspend when the lid closes, "sysctl > hw.acpi.lid_switch_state=S3". > > > > > acpiconf -i 0 > > [root@Raptor] /usr/ports/comms/wspr# acpiconf -i o > Design capacity: 4400 mAh > Last full capacity: 3757 mAh > Battery is getting old and only will charge to 85% of it's design capacity. > Technology: secondary (rechargeable) > Design voltage: 11100 mV > Capacity (warn): 185 mAh > Capacity (low): 129 mAh > Low/warn granularity: 56 mAh > Warn/full granularity: 3572 mAh > Model number: GRAPE32 > Serial number: 27 > Type: LION > OEM info: SANYO > State: critical > Your battery is dying! > Remaining capacity: 0% > OK. It's dead. > Remaining time: unknown > Present rate: 0 mA (0 mW) > It's not discharging. > Present voltage: 7870 mV > It is at 7.9 volts which is too low to run the system. > > Since the system appears to be on AC power, but the battery is not > charging, something is wrong here. I have no idea what. > > > It appears that either the charging system or the battery has > failed.Neither involved the OS, but indicates a hardware issue with the > device. > > There are several ACPI variables I don't recognize or am simply not > familiar with, but this will give you some idea what many of > the important ones are. Remember that ACPI is firmware and may have errors > that result in its lying to the OS. I don't trust some of what I see, > especially the temperature. Most laptops idle at between 50 > and 60C. Seeing two zones at 39C is very odd. > -- > R. Kevin Oberman, Network Engineer, Retired > E-mail: rkoberman@gmail.com > Are you running with Intel or Radeon graphics? Are you using DRM2 and KMS? If so, syscons is broken with KMS, so once you switch to X, there is no visual console available outside of X. The keyboard will still work, but the screen will be blank. If you either use the VT kernel configuration or add: nodevice sc nodevice vga device vt device vt_vga to your current configuration and re-build the kernel, you should get your display back, though the splash screen is not yet working for vt(4). You will also see a few unrecognized ioctls as not all syscons features are in vt(4) at this time. -- R. Kevin Oberman, Network Engineer, Retired E-mail: rkoberman@gmail.com From owner-freebsd-acpi@FreeBSD.ORG Tue Apr 22 08:51:48 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 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 536A03AE for ; Tue, 22 Apr 2014 08:51:48 +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 5AD861829 for ; Tue, 22 Apr 2014 08:51:46 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id s3M8pRAX048737; Tue, 22 Apr 2014 18:51:27 +1000 (EST) (envelope-from smithi@nimnet.asn.au) Date: Tue, 22 Apr 2014 18:51:27 +1000 (EST) From: Ian Smith To: Kevin Oberman Subject: Re: Re: ACPI bug submission In-Reply-To: Message-ID: <20140422172604.C9458@sola.nimnet.asn.au> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: "freebsd-acpi@freebsd.org" , Matt Grice X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Apr 2014 08:51:48 -0000 On Mon, 21 Apr 2014 12:07:51 -0700, Kevin Oberman wrote: > On Mon, Apr 21, 2014 at 9:05 AM, Matt Grice wrote: > > > Sorry, PEBKAC error, it appears I've been replying off-list. Ah, I would have left it to Kevin had I known. However this raises a couple of interesting points .. cutting mercilessly .. > > hw.acpi.cpu.cx_lowest: C1 > > Power saving Cx states are NOT enabled. Which makes the cool temperatures you noted, Kevin, more amazing. Matt, you might try adding to /etc/rc.conf: performance_cx_lowest=C3 economy_cx_lowest=C3 > > hw.acpi.thermal.tz0.temperature: 39.0C > > Thermal zone 0 is 39C. This is usually the CPU. 39C is VERY cool. Yes it is, but see below .. > > Hopefully it i accurate. > > hw.acpi.thermal.tz0.active: -1 > > ACPI is NOT throttling the CPU to control temperature > > hw.acpi.thermal.tz0.passive_cooling: 0 > > ACPI is not increasing system cooling capability (usually the fan) to > > reduce temperature. NOTE: This does not mean non-ACPI controls are not used! Actually, active cooling is the fan/s, and passive cooling is CPU speed reduction and/or cycle throttling. > > hw.acpi.thermal.tz0.thermal_flags: 0 > > hw.acpi.thermal.tz0._PSV: 95.0C > > At 95C, turn the cooling (fans) to maximum. It's the passive (throttling) temperature that kicks in at 95C > > hw.acpi.thermal.tz0._HOT: -1 > > hw.acpi.thermal.tz0._CRT: 98.0C > > At 98C, throttlethe CPU to reduce temperature And that's the critical temperature that should cause shutdown. > > hw.acpi.thermal.tz0._ACx: -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 > > hw.acpi.thermal.tz0._TC1: 0 > > hw.acpi.thermal.tz0._TC2: 50 > > hw.acpi.thermal.tz0._TSP: 0 > > hw.acpi.thermal.tz1.temperature: 39.0C > > Odd that tz0 and tz1 are both 39C. Seems unlikely. May be different CPU > > sensor or something else. But see below .. > > hw.acpi.thermal.tz1.active: -1 > > hw.acpi.thermal.tz1.passive_cooling: 0 > > hw.acpi.thermal.tz1.thermal_flags: 0 > > hw.acpi.thermal.tz1._PSV: -1 > > hw.acpi.thermal.tz1._HOT: -1 > > hw.acpi.thermal.tz1._CRT: 98.0C > > At 98C, power down (if supported). This is different from the hardware > > shutdown on severe overtemp that simply kills power. Right. This zone just has _CRT, also 98C, no active or passive cooling. [..] > > acpiconf -i 0 > > > > [root@Raptor] /usr/ports/comms/wspr# acpiconf -i o > > Design capacity: 4400 mAh > > Last full capacity: 3757 mAh > > Battery is getting old and only will charge to 85% of it's design capacity. It would be nice if it worked even that well, but .. > > Technology: secondary (rechargeable) > > Design voltage: 11100 mV > > Capacity (warn): 185 mAh > > Capacity (low): 129 mAh > > Low/warn granularity: 56 mAh > > Warn/full granularity: 3572 mAh > > Model number: GRAPE32 > > Serial number: 27 > > Type: LION > > OEM info: SANYO > > State: critical > > Your battery is dying! > > Remaining capacity: 0% > > OK. It's dead. Or just isn't getting charged (though leaving it fully discharged for long will kill it in the end anyway). One of my Thinkpad T23s has a broken charging circuit, not unknown on that model; it runs on AC but a) won't charge any battery and b) dies on loss of AC power, even with a charged battery .. perhaps similar to what's happened to this one? > > Remaining time: unknown > > Present rate: 0 mA (0 mW) > > It's not discharging. On AC power, present rate usually shows the charging rate until fully charged, so it's clearly not charging at all. > > Present voltage: 7870 mV > > It is at 7.9 volts which is too low to run the system. > > > > Since the system appears to be on AC power, but the battery is not > > charging, something is wrong here. I have no idea what. > > It appears that either the charging system or the battery has > > failed.Neither involved the OS, but indicates a hardware issue with the > > device. We concur. Matt, you could maybe try this battery in another laptop if you have access to one, or an external charger, ie the battery may still be at least partially ok and only the charge circuit is broken (bummer!) or OTOH the battery may be so stuffed that the charge circuit refuses to try to charge it, but isn't broken as such - so a new battery may help. > > There are several ACPI variables I don't recognize or am simply not > > familiar with, but this will give you some idea what many of > > the important ones are. Remember that ACPI is firmware and may have errors > > that result in its lying to the OS. I don't trust some of what I see, > > especially the temperature. Most laptops idle at between 50 > > and 60C. Seeing two zones at 39C is very odd. I'd have agreed with this before ~10 weeks ago, when my son bought me a Thinkpad X200 from an auction site out of the blue - without battery or charger, and with a dodgy serial number. I took the punt - thanks to encouragement by Lars - and bought it a new one of each, and it's a very sweet little machine. 2.4GHz Core 2 Duo which also runs extraordinarily cool. Right now, idling, ambient temp. 26C after a warm autumn day: smithi@x200:~ % x200stat Tue Apr 22 18:03:22 EST 2014 dev.cpu.0.freq: 200 0.00% 0.49% 99.50% last 617us 0.00% 0.45% 99.54% last 524us dev.acpi_ibm.0.fan_speed: 3393 dev.acpi_ibm.0.fan_level: 0 dev.acpi_ibm.0.thermal: 38 41 -1 38 32 -1 30 -1 hw.acpi.thermal.tz0.temperature: 38.0C hw.acpi.thermal.tz1.temperature: 34.0C State: high Remaining capacity: 97% Remaining time: unknown Present rate: 0 mW Present voltage: 12448 mV And now after about 6 minutes running dd if=/dev/random of=/dev/null on each core, I can only manage to drive it up to: Tue Apr 22 18:11:28 EST 2014 dev.cpu.0.freq: 2401 0.00% 0.50% 99.49% last 7us 0.01% 0.56% 99.42% last 2us dev.acpi_ibm.0.fan_speed: 3376 dev.acpi_ibm.0.fan_level: 0 dev.acpi_ibm.0.thermal: 64 41 -1 57 32 -1 30 -1 hw.acpi.thermal.tz0.temperature: 64.0C hw.acpi.thermal.tz1.temperature: 65.0C State: high Remaining capacity: 97% Remaining time: unknown Present rate: 0 mW Present voltage: 12448 mV smithi@x200:~ % 10000+0 records in 10000+0 records out 10485760000 bytes transferred in 328.271913 secs (31942300 bytes/sec) 10000+0 records in 10000+0 records out 10485760000 bytes transferred in 328.040868 secs (31964798 bytes/sec) I recall seeing it get to almost 70C on one 33C day, but that's it. And fortunately it does switch from X to VTs and back without issue on 9.2, so it must have "old-enough" graphics, for which I'm thankful. cheers, Ian From owner-freebsd-acpi@FreeBSD.ORG Fri Apr 25 15:47:59 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 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E408597C for ; Fri, 25 Apr 2014 15:47:59 +0000 (UTC) Received: from mail.stratum16.com (incognito.stratum16.com [216.223.229.163]) (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 C517E13C1 for ; Fri, 25 Apr 2014 15:47:59 +0000 (UTC) Received: from [192.168.1.77] (unknown [67.22.186.126]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: sspence@stratum16.com) by mail.stratum16.com (Postfix) with ESMTPSA id 19F201E30EC for ; Fri, 25 Apr 2014 09:47:58 -0600 (MDT) Message-ID: <535A83AE.3040703@stratum16.com> Date: Fri, 25 Apr 2014 09:47:58 -0600 From: Steven Spence User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: freebsd-acpi@freebsd.org Subject: kern/186051: [vmware] [panic] FreeBSD 8.4+, 9.x+, 10.0 guest panic with VMWare Server on boot References: <201404212000.s3LK01cT059791@freefall.freebsd.org> <5355DE8A.8030801@mittelstaedt.us> In-Reply-To: <5355DE8A.8030801@mittelstaedt.us> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Apr 2014 15:48:00 -0000 Hello, I had opened a bug report at: http://www.freebsd.org/cgi/query-pr.cgi?pr=186051 and it was suggested that I inquire here as to whether there were any suggestions on the issue. I can try to answer any further questions if necessary. Thanks, Steven From owner-freebsd-acpi@FreeBSD.ORG Mon Apr 28 11:06:42 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 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DF2B53C5 for ; Mon, 28 Apr 2014 11:06:42 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (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 B1F401A94 for ; Mon, 28 Apr 2014 11:06:42 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.8/8.14.8) with ESMTP id s3SB6gNB086034 for ; Mon, 28 Apr 2014 11:06:42 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.8/8.14.8/Submit) id s3SB6gwh086031 for freebsd-acpi@FreeBSD.org; Mon, 28 Apr 2014 11:06:42 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 28 Apr 2014 11:06:42 GMT Message-Id: <201404281106.s3SB6gwh086031@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.17 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Apr 2014 11:06:42 -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/187152 acpi [i386] [acpi] [suspend/resume] resume from ACPI suspen o kern/181665 acpi [acpi] System will not go into S3 state. o kern/180897 acpi [acpi] ACPI error with MB p8h67 v.1405 o kern/174766 acpi [acpi] Random acpi panic o kern/174504 acpi [acpi] [suspend/resume] Suspend/resume broken on Lenov o kern/173414 acpi [acpi] ACPI battery time incorrect o kern/173408 acpi [acpi] [regression] ACPI Regression: battery does not 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] [suspend/resume] Dell E6520 doesn't resume afte o kern/161713 acpi [acpi] [suspend/resume] Suspend on Dell E6520 doesn't 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] [suspend/resume] Lenovo T61p does not resume o i386/146715 acpi [acpi] [suspend/resume] Suspend works, resume not on a 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/73823 acpi [request] acpi / power-on by timer support 30 problems total. From owner-freebsd-acpi@FreeBSD.ORG Thu May 1 21:03:51 2014 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1A0F36FA for ; Thu, 1 May 2014 21:03:51 +0000 (UTC) Received: from mail.atelo.org (atelo.org [192.95.27.91]) (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 B38001C19 for ; Thu, 1 May 2014 21:03:50 +0000 (UTC) Received: from localhost (ovo.atelo.org [192.168.1.7]); by mail.atelo.org (OpenSMTPD) with ESMTP id 24fb32ff; for ; Thu, 1 May 2014 20:57:00 +0000 (UTC) Date: Thu, 1 May 2014 13:57:06 -0700 From: =?utf-8?B?WMSrY8Oy?= To: freebsd-acpi@freebsd.org Subject: Emitting keyboard events Message-ID: <20140501205706.GA6007@coyotlan.Tlalpan> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 May 2014 21:03:51 -0000 Dear freebsd-acpi, Being a systemd refugee, I am trying to setup FreeBSD on several machines here. As a first question, I cannot find any driver to handle the hotkeys on a 2011 Sony VPCZ2. sys/dev/acpi_support/acpi_sony.c only contains backlight support for old laptops. Is anyone aware of such a driver? In any case, I started playing a bit with ACPI in a module, and have been able to register a handler for the hotkeys, and decode the associated events. Unfortunately, I have no idead of what I could do with them. At some point, I would like Xorg to receive keyboard events, such as XF86MonBrightnessUp, but I lack the knowledge on how to emit that from kernel space. Thank you for your help! Best, -- XÄ«cò From owner-freebsd-acpi@FreeBSD.ORG Thu May 1 22:56:44 2014 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D09E13EA for ; Thu, 1 May 2014 22:56:44 +0000 (UTC) Received: from nm27-vm1.bullet.mail.bf1.yahoo.com (nm27-vm1.bullet.mail.bf1.yahoo.com [98.139.213.148]) (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 5D90B1751 for ; Thu, 1 May 2014 22:56:44 +0000 (UTC) Received: from [98.139.215.142] by nm27.bullet.mail.bf1.yahoo.com with NNFMP; 01 May 2014 22:56:37 -0000 Received: from [98.139.211.206] by tm13.bullet.mail.bf1.yahoo.com with NNFMP; 01 May 2014 22:56:37 -0000 Received: from [127.0.0.1] by smtp215.mail.bf1.yahoo.com with NNFMP; 01 May 2014 22:56:37 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1398984997; bh=fZ9sQ8nJQta+7OmfqrNb84BY70wR+wN4fuIsQlxiYUY=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=aus2mmGJOhtFEHea15VgwLvB0yyk4ZqCLXYtsAvACuJBmhh6VQHi4pwK4YJSdlRgdZZyaFqe5dAvN5NWDIqOPpdapUlnpDmsJQ2Y/XhmAOWtEb6CZxY1fPFRdvNCZto7ItyhMUp+f0dd83Fqd670uoR52ttPUwmxCmeuFdKOhAM= X-Yahoo-Newman-Id: 37492.19838.bm@smtp215.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: LQg_mgoVM1lEG47XWMN7fySM3FCnSZoVkSi75mZ0C5edbfl bwsMvkl0lLhdeeQtYbNHcjEodyKN8jIEB87ef0u8MHoHOYWeeASy644hWTl4 8fLzcLux8rP.E8aD2RpCSUhOIHiFRWjZKGKWoBs1PZtrcC_Cd8itOREvH6tg Z.L9RZDvh2BIxZ1TbMTrW2p2KbO3t6Ok883jC_C2K2_VUVX5X4swA7hY.FJf bpAkrfrUQLDAkOIxiS7p5g6i5vs6y.zlrTJkcyQ.yjSzsfYfKRMjSr5HVoPo lu8YPwJ1mPPF_Vn6N1c4jRndQqMDSpGGqqXPrKTCn.B.06Mqhby2fA4YoN3Y TREuiz120rGtplEcSqwV.VvnBdBJ8mCr98m48ca1rNCEBrTifTSdvSE3dQ7l jPNROla9H0RggtjLuoHk025ebiHyBmNwuGT_KpGwJDBFX2HLsfm0Tys_ie6r yAhlsdLNCybQxcdfpjgs.kFeWa42eb_qzqZwK5dCYmeaYarzzOzxcaTVl1Yy GXhqEGsonH5cnuEFL8ATw3Q-- X-Yahoo-SMTP: 9sPoSQ2swBBlERuQ.0vs8XLc_MeClW0- X-Rocket-Received: from [10.0.0.192] (Scoobi_doo@74.7.140.50 with plain [98.138.105.21]) by smtp215.mail.bf1.yahoo.com with SMTP; 01 May 2014 15:56:37 -0700 PDT Message-ID: <5362D123.9040505@yahoo.com> Date: Thu, 01 May 2014 18:56:35 -0400 From: Anthony Jenkins User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: =?UTF-8?B?WMSrY8Oy?= , freebsd-acpi@freebsd.org Subject: Re: Emitting keyboard events References: <20140501205706.GA6007@coyotlan.Tlalpan> In-Reply-To: <20140501205706.GA6007@coyotlan.Tlalpan> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 May 2014 22:56:44 -0000 On 05/01/2014 16:57, XÄ«cò wrote: > Dear freebsd-acpi, > > Being a systemd refugee, I am trying to setup FreeBSD on several > machines here. As a first question, I cannot find any driver to handle > the hotkeys on a 2011 Sony VPCZ2. sys/dev/acpi_support/acpi_sony.c only > contains backlight support for old laptops. Is anyone aware of such a > driver? > > In any case, I started playing a bit with ACPI in a module, and have > been able to register a handler for the hotkeys, and decode the > associated events. Unfortunately, I have no idead of what I could do > with them. At some point, I would like Xorg to receive keyboard events, > such as XF86MonBrightnessUp, but I lack the knowledge on how to emit > that from kernel space. No idea how hard this would be, or if it's the right way to go, but I'm picturing an ACPI keyboard driver that consumes keyboard events from ACPI and can attach to the keyboard multiplexer device kbdmux(4). Your ACPI mods for your machine would inject events into it (if it's loaded). That'd be modular and pretty self-contained and could be extended to support other machines. -- Anthony Jenkins > Thank you for your help! > > Best, > > -- > XÄ«cò > _______________________________________________ > freebsd-acpi@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-acpi > To unsubscribe, send any mail to "freebsd-acpi-unsubscribe@freebsd.org" From owner-freebsd-acpi@FreeBSD.ORG Sun May 4 08:27:39 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 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AC14FA86; Sun, 4 May 2014 08:27:39 +0000 (UTC) Received: from mail-qc0-x230.google.com (mail-qc0-x230.google.com [IPv6:2607:f8b0:400d:c01::230]) (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 5EC6C1C57; Sun, 4 May 2014 08:27:39 +0000 (UTC) Received: by mail-qc0-f176.google.com with SMTP id x13so6629258qcv.35 for ; Sun, 04 May 2014 01:27:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=SJOaulOTSv4UQdCH9/3BW8n8h7iEu4lgIdbH75efsY0=; b=TfQweivZppTF1+TdnafZrV4EIxav+d/SWv+UGP8ziU2u+WVl4tXmNfuE1uIOa5RPVN iEbxJNf6JEmlhqfpEkbnSA/EfYnuvvFdrr0n0iP13Q24X0/2p55eXAIhVByk1T/AE4O2 VkTTEQ87vV1Njty5/42Gake4Yt+fnmR/dMKbG2tQGk3dHedWFiI37dHLb1rVe2muEqrA TDK6xPQF9M3wVW0ScKgVO0TwObweBOpCgdxAF2Y8q/SQXKAbFjPhFSauNoX0TYoUB762 iyXxfcWRrdsQ6aBLnOITo6CL50Nv467O1z+5xPLZfVT0oNUdniav8H0TXyDOhLULGan6 PCRg== MIME-Version: 1.0 X-Received: by 10.140.96.51 with SMTP id j48mr33463775qge.24.1399192058524; Sun, 04 May 2014 01:27:38 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.191.201 with HTTP; Sun, 4 May 2014 01:27:38 -0700 (PDT) Date: Sun, 4 May 2014 01:27:38 -0700 X-Google-Sender-Auth: u8h749eWk6MBEQcd3bo2SBVr0wM Message-ID: Subject: proposal: set default lid state to S3, performance/economy Cx states to Cmax From: Adrian Chadd To: Kevin Oberman , "freebsd-arch@freebsd.org" , "freebsd-acpi@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 May 2014 08:27:39 -0000 Hi, I'd like to propose flipping a few things: * Flipping the default lid state to S3. I think ACPI suspend/resume seems to work well enough these days and I've not met anyone lately who expects the default from their laptop to be "stay awake with the lid shut." * Save chip bugs that we should add workarounds for, we should be OK to enter lower sleep states when idling. Flipping this may expose some further crazy driver, platform or timer bugs, but they again likely should be fixed. what do people think? -a Index: etc/defaults/rc.conf =================================================================== --- etc/defaults/rc.conf (revision 265255) +++ etc/defaults/rc.conf (working copy) @@ -642,9 +642,9 @@ devfs_set_rulesets="" # A list of /mount/dev=ruleset_name settings to # apply (must be mounted already, i.e. fstab(5)) devfs_load_rulesets="YES" # Enable to always load the default rulesets -performance_cx_lowest="HIGH" # Online CPU idle state +performance_cx_lowest="Cmax" # Online CPU idle state performance_cpu_freq="NONE" # Online CPU frequency -economy_cx_lowest="HIGH" # Offline CPU idle state +economy_cx_lowest="Cmax" # Offline CPU idle state economy_cpu_freq="NONE" # Offline CPU frequency virecover_enable="YES" # Perform housekeeping for the vi(1) editor ugidfw_enable="NO" # Load mac_bsdextended(4) rules on boot Index: sys/dev/acpica/acpi.c =================================================================== --- sys/dev/acpica/acpi.c (revision 265255) +++ sys/dev/acpica/acpi.c (working copy) @@ -620,11 +620,12 @@ /* * Dispatch the default sleep state to devices. The lid switch is set - * to UNKNOWN by default to avoid surprising users. + * to S3 to mirror what everything else iBook and later does. */ sc->acpi_power_button_sx = acpi_sleep_states[ACPI_STATE_S5] ? ACPI_STATE_S5 : ACPI_STATE_UNKNOWN; - sc->acpi_lid_switch_sx = ACPI_STATE_UNKNOWN; + sc->acpi_lid_switch_sx = acpi_sleep_states[ACPI_STATE_S3] ? + ACPI_STATE_S3 : ACPI_STATE_UNKNOWN; sc->acpi_standby_sx = acpi_sleep_states[ACPI_STATE_S1] ? ACPI_STATE_S1 : ACPI_STATE_UNKNOWN; sc->acpi_suspend_sx = acpi_sleep_states[ACPI_STATE_S3] ? From owner-freebsd-acpi@FreeBSD.ORG Sun May 4 15:55:57 2014 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4E915AE8; Sun, 4 May 2014 15:55:57 +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 B671411C4; Sun, 4 May 2014 15:55:56 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id s44Ftk9m064089; Mon, 5 May 2014 01:55:46 +1000 (EST) (envelope-from smithi@nimnet.asn.au) Date: Mon, 5 May 2014 01:55:46 +1000 (EST) From: Ian Smith To: Adrian Chadd Subject: Re: proposal: set default lid state to S3, performance/economy Cx states to Cmax In-Reply-To: Message-ID: <20140505011654.O11699@sola.nimnet.asn.au> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: Kevin Oberman , "freebsd-acpi@freebsd.org" , "freebsd-arch@freebsd.org" X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 May 2014 15:55:57 -0000 On Sun, 4 May 2014 01:27:38 -0700, Adrian Chadd wrote: > Hi, > > I'd like to propose flipping a few things: > > * Flipping the default lid state to S3. I think ACPI suspend/resume > seems to work well enough these days and I've not met anyone lately > who expects the default from their laptop to be "stay awake with the > lid shut." Meet me; sitting here right now with the X200 lid closed, backlight off, idling but 'working' via ssh. Laptops running as (mostly) headless servers would normally run with lid down - been doing this for years, keeps the cockroaches out, mostly :) Anyway, this would be a very poor default on any machine that didn't resume completely well every time. 'Seems to work well enough' on a still fairly limited range of laptops, I gather. I've yet to get this X200 (on stable/9) to suspend without losing USB - after the _second_ suspend, unlike yours - and besides it's not a big deal to set it to S3 when desired. Maybe an rc.conf knob like 'suspend_on_lid="YES"' ono rather than requiring sysctl.conf setting? > * Save chip bugs that we should add workarounds for, we should be OK > to enter lower sleep states when idling. Flipping this may expose some > further crazy driver, platform or timer bugs, but they again likely > should be fixed. This seems likely less controversial, and should suit most, probably. An Nate Lawson said often many years ago, we really need some sort of profile mechanism to describe as a package different ACPI and power settings for different brands / models / usage cases, plugins if you like; then 'resumes_reliably' could condition stuff. But I digress .. 2c, and not assuming myself to be any sort of 'average user', Ian > what do people think? > > > -a > > > Index: etc/defaults/rc.conf > =================================================================== > --- etc/defaults/rc.conf (revision 265255) > +++ etc/defaults/rc.conf (working copy) > @@ -642,9 +642,9 @@ > devfs_set_rulesets="" # A list of /mount/dev=ruleset_name settings to > # apply (must be mounted already, i.e. fstab(5)) > devfs_load_rulesets="YES" # Enable to always load the default rulesets > -performance_cx_lowest="HIGH" # Online CPU idle state > +performance_cx_lowest="Cmax" # Online CPU idle state > performance_cpu_freq="NONE" # Online CPU frequency > -economy_cx_lowest="HIGH" # Offline CPU idle state > +economy_cx_lowest="Cmax" # Offline CPU idle state > economy_cpu_freq="NONE" # Offline CPU frequency > virecover_enable="YES" # Perform housekeeping for the vi(1) editor > ugidfw_enable="NO" # Load mac_bsdextended(4) rules on boot > Index: sys/dev/acpica/acpi.c > =================================================================== > --- sys/dev/acpica/acpi.c (revision 265255) > +++ sys/dev/acpica/acpi.c (working copy) > @@ -620,11 +620,12 @@ > > /* > * Dispatch the default sleep state to devices. The lid switch is set > - * to UNKNOWN by default to avoid surprising users. > + * to S3 to mirror what everything else iBook and later does. > */ > sc->acpi_power_button_sx = acpi_sleep_states[ACPI_STATE_S5] ? > ACPI_STATE_S5 : ACPI_STATE_UNKNOWN; > - sc->acpi_lid_switch_sx = ACPI_STATE_UNKNOWN; > + sc->acpi_lid_switch_sx = acpi_sleep_states[ACPI_STATE_S3] ? > + ACPI_STATE_S3 : ACPI_STATE_UNKNOWN; > sc->acpi_standby_sx = acpi_sleep_states[ACPI_STATE_S1] ? > ACPI_STATE_S1 : ACPI_STATE_UNKNOWN; > sc->acpi_suspend_sx = acpi_sleep_states[ACPI_STATE_S3] ? > _______________________________________________ > freebsd-acpi@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-acpi > To unsubscribe, send any mail to "freebsd-acpi-unsubscribe@freebsd.org" > From owner-freebsd-acpi@FreeBSD.ORG Sun May 4 17:36:08 2014 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8E667E5F; Sun, 4 May 2014 17:36:08 +0000 (UTC) Received: from felyko.com (felyko.com [IPv6:2607:f2f8:a528::3:1337:ca7]) by mx1.freebsd.org (Postfix) with ESMTP id 727DC1DBE; Sun, 4 May 2014 17:36:08 +0000 (UTC) Received: from [IPv6:2601:9:8280:426:bc6f:4b2:eb90:358c] (unknown [IPv6:2601:9:8280:426:bc6f:4b2:eb90:358c]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by felyko.com (Postfix) with ESMTPSA id 9BAB739827; Sun, 4 May 2014 10:36:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=felyko.com; s=mail; t=1399224967; bh=50NS81vUSCzx6I37i5p+nnHnhNaQUeX53nEr1PxBZ8o=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=jt2cyyrL2UggOxI6aRiGGB2pQNzTCgFH4iWamCdwuJfZiHlbhBdGTDnx2bIlxv9Je V6HwLlLqiq9cfnDHKr98pkAS5sZhyeNpTnUTxs339vijkF8IDx3P5zKBB8HU3HLyGE KUW7WbexxhYKdSogNXasBpQhJZzwb5+GBskaFJOE= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: proposal: set default lid state to S3, performance/economy Cx states to Cmax From: Rui Paulo In-Reply-To: Date: Sun, 4 May 2014 10:36:06 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Adrian Chadd X-Mailer: Apple Mail (2.1874) Cc: Kevin Oberman , "freebsd-acpi@freebsd.org" , "freebsd-arch@freebsd.org" X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 May 2014 17:36:08 -0000 On May 4, 2014, at 1:27, Adrian Chadd wrote: > * Flipping the default lid state to S3. I think ACPI suspend/resume > seems to work well enough these days and I've not met anyone lately > who expects the default from their laptop to be "stay awake with the > lid shut." The sysctl is really just a hack. We should have a much better = mechanism for integrating our ACPI with the X11 desktop environments. = GNOME/KDE/Mate don't understand our sysctl and get confused easily.=20 You can turn it on by default, but I'm sure ACPI suspend/resume is not = working well enough like you say. How many laptops have you tested? = For completeness, how many desktops? =20 There are bunch of ports kernel modules that will crash your system if = you suspend. VirtualBox is one of them. > * Save chip bugs that we should add workarounds for, we should be OK > to enter lower sleep states when idling. Flipping this may expose some > further crazy driver, platform or timer bugs, but they again likely > should be fixed. They are still not fixed. Some of these problems are not in FreeBSD = though and I don't expect us to be able to work around them. We should = try to identify systems where C3 has surprising effects and blacklist = them. -- Rui Paulo From owner-freebsd-acpi@FreeBSD.ORG Sun May 4 20:00:53 2014 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C470115A; Sun, 4 May 2014 20:00:53 +0000 (UTC) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 8629F1967; Sun, 4 May 2014 20:00:53 +0000 (UTC) Received: from critter.freebsd.dk (unknown [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id 33BAA15B2; Sun, 4 May 2014 20:00:46 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.8/8.14.8) with ESMTP id s44K0iME002224; Sun, 4 May 2014 20:00:45 GMT (envelope-from phk@phk.freebsd.dk) To: Ian Smith Subject: Re: proposal: set default lid state to S3, performance/economy Cx states to Cmax In-reply-to: <20140505011654.O11699@sola.nimnet.asn.au> From: "Poul-Henning Kamp" References: <20140505011654.O11699@sola.nimnet.asn.au> Content-Type: text/plain; charset=ISO-8859-1 Date: Sun, 04 May 2014 20:00:44 +0000 Message-ID: <2223.1399233644@critter.freebsd.dk> Cc: Kevin Oberman , "freebsd-acpi@freebsd.org" , "freebsd-arch@freebsd.org" X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 May 2014 20:00:53 -0000 In message <20140505011654.O11699@sola.nimnet.asn.au>, Ian Smith writes: >On Sun, 4 May 2014 01:27:38 -0700, Adrian Chadd wrote: >'Seems to work well enough' on a still fairly limited range of laptops, >I gather. I'd say. I havn't seen suspend/resume work for ages on my T4xx laptops and as far as I recall it never worked on this T430s at all. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-acpi@FreeBSD.ORG Sun May 4 20:51:21 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 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E8A60DD9; Sun, 4 May 2014 20:51:21 +0000 (UTC) Received: from mail-qa0-x230.google.com (mail-qa0-x230.google.com [IPv6:2607:f8b0:400d:c00::230]) (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 9737B1D2C; Sun, 4 May 2014 20:51:21 +0000 (UTC) Received: by mail-qa0-f48.google.com with SMTP id i13so1648875qae.35 for ; Sun, 04 May 2014 13:51:20 -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:message-id:subject :from:to:cc:content-type; bh=ofv7A+WQRti4Aj+Iqf5bgsjGskdBWIQvLkUsAnxnq+E=; b=xrHaN60NDzdd7s/eQVzLKEzHm4vHEYXrC4u3375NS2icF6SikjJePe3HSHVOctEDVO prrQqQpV8psTFFzjBqPx4yk0rE0ocfWH60rttm2nJWR0V6nqf/af+qy/UQqhnMOSVRRj CFMMVzJOr3E+qklq5aBSprtb2kHcSEgNBUt0/ZM/0i5VAIxjdkX2t6xZRFwKqrSsWAiZ Gjbvj6apcDFjvQUFgOsHv7DpsjZx15kXb+W1p13T2KiSO34nsqf+tPeqWwgt3OD519u7 lLZFfiPBYDRtWJs5Y+nv4ApMT0j5uxz9vKzyalgZQpU9sqp+rrkyhqIDvxHktHyY1cfx md/Q== MIME-Version: 1.0 X-Received: by 10.140.109.70 with SMTP id k64mr37307699qgf.92.1399236680704; Sun, 04 May 2014 13:51:20 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.191.201 with HTTP; Sun, 4 May 2014 13:51:20 -0700 (PDT) In-Reply-To: <2223.1399233644@critter.freebsd.dk> References: <20140505011654.O11699@sola.nimnet.asn.au> <2223.1399233644@critter.freebsd.dk> Date: Sun, 4 May 2014 13:51:20 -0700 X-Google-Sender-Auth: pTQvF9ec-uJIPoOdX7WCkgV2oJ0 Message-ID: Subject: Re: proposal: set default lid state to S3, performance/economy Cx states to Cmax From: Adrian Chadd To: Poul-Henning Kamp Content-Type: text/plain; charset=UTF-8 Cc: Kevin Oberman , "freebsd-acpi@freebsd.org" , Ian Smith , "freebsd-arch@freebsd.org" X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 May 2014 20:51:22 -0000 On 4 May 2014 13:00, Poul-Henning Kamp wrote: > In message <20140505011654.O11699@sola.nimnet.asn.au>, Ian Smith writes: >>On Sun, 4 May 2014 01:27:38 -0700, Adrian Chadd wrote: > >>'Seems to work well enough' on a still fairly limited range of laptops, >>I gather. > > I'd say. > > I havn't seen suspend/resume work for ages on my T4xx laptops and > as far as I recall it never worked on this T430s at all. I've tested it (-HEAD) on: * T43 * T60 * T60p * T400 * T500 * T420 * X220 I'm actively using the T60, T400 and X220 right now. I'd like to see it working on more laptops and I've worked with various people in the past to try and fix whichever resume issues I find. I'm happy leaving this as-is but at some point something has to be bitten and the bugs in the drivers / ACPI stuff need to be fixed. :) -a From owner-freebsd-acpi@FreeBSD.ORG Sun May 4 22:59:26 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 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F0771B5A; Sun, 4 May 2014 22:59:26 +0000 (UTC) Received: from wonkity.com (wonkity.com [67.158.26.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "wonkity.com", Issuer "wonkity.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 8234B1AE4; Sun, 4 May 2014 22:59:26 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.8/8.14.8) with ESMTP id s44MxMgI009250 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 4 May 2014 16:59:22 -0600 (MDT) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.8/8.14.8/Submit) with ESMTP id s44MxLbp009247; Sun, 4 May 2014 16:59:22 -0600 (MDT) (envelope-from wblock@wonkity.com) Date: Sun, 4 May 2014 16:59:21 -0600 (MDT) From: Warren Block To: Rui Paulo Subject: Re: proposal: set default lid state to S3, performance/economy Cx states to Cmax In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (wonkity.com [127.0.0.1]); Sun, 04 May 2014 16:59:22 -0600 (MDT) Cc: Kevin Oberman , "freebsd-acpi@freebsd.org" , "freebsd-arch@freebsd.org" X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 May 2014 22:59:27 -0000 On Sun, 4 May 2014, Rui Paulo wrote: > On May 4, 2014, at 1:27, Adrian Chadd wrote: > >> * Flipping the default lid state to S3. I think ACPI suspend/resume >> seems to work well enough these days and I've not met anyone lately >> who expects the default from their laptop to be "stay awake with the >> lid shut." > > The sysctl is really just a hack. We should have a much better mechanism for integrating our ACPI with the X11 desktop environments. GNOME/KDE/Mate don't understand our sysctl and get confused easily. > > You can turn it on by default, but I'm sure ACPI suspend/resume is not working well enough like you say. How many laptops have you tested? For completeness, how many desktops? Suspend works for me. It's the resume part, on Dell and Acer systems at least, that does not work at all. > There are bunch of ports kernel modules that will crash your system if you suspend. VirtualBox is one of them. > >> * Save chip bugs that we should add workarounds for, we should be OK >> to enter lower sleep states when idling. Flipping this may expose some >> further crazy driver, platform or timer bugs, but they again likely >> should be fixed. > > They are still not fixed. Some of these problems are not in FreeBSD though and I don't expect us to be able to work around them. We should try to identify systems where C3 has surprising effects and blacklist them. If there were an easy-to-run test, many would be happy to report results. From owner-freebsd-acpi@FreeBSD.ORG Mon May 5 00:25:51 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 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 961BC8BB; Mon, 5 May 2014 00:25:51 +0000 (UTC) Received: from mail-qg0-x229.google.com (mail-qg0-x229.google.com [IPv6:2607:f8b0:400d:c04::229]) (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 447EE1272; Mon, 5 May 2014 00:25:51 +0000 (UTC) Received: by mail-qg0-f41.google.com with SMTP id j5so60365qga.0 for ; Sun, 04 May 2014 17:25:50 -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:message-id:subject :from:to:cc:content-type; bh=irv2gEMJA82oBZO0fa6zl5ndmiu60OV+43+t46tO1zM=; b=oHWEkhXuG5Qz5ji/QwNo5pS+DvT5giIwwejWAwewLLPPsq8VBmv1F5bmoqoKLVyYGl HC5r5TKeNaKgGVJChhJIV+GsShhjrP5Evx8r4YzXawGrn/4gN0gdoNllYuJrwuJkUqaD Qkq7aIsf5Db1zK2R6QzionmVENGFohnbGre1XPPRKUk/3GOMg96jDI1jbG6G3CA/9p3c A8Nu/m1bvcKzwIqzbXfBRYpGPfNMBIPdXirOzfBdlgALQ+93V5vEzLSZ6McS4dGyvNdo sg/AImeqOXS9wJawdcw7YIBlLN8g+njcSovrg95gEcheEKC/fE1Sl2E4LuRpuRI5vbs0 X0Gg== MIME-Version: 1.0 X-Received: by 10.229.198.2 with SMTP id em2mr85033qcb.21.1399249550404; Sun, 04 May 2014 17:25:50 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.191.201 with HTTP; Sun, 4 May 2014 17:25:50 -0700 (PDT) In-Reply-To: References: Date: Sun, 4 May 2014 17:25:50 -0700 X-Google-Sender-Auth: 0PpzMHdxqj9hlUqdClQ-a1l-rJQ Message-ID: Subject: Re: proposal: set default lid state to S3, performance/economy Cx states to Cmax From: Adrian Chadd To: Warren Block Content-Type: text/plain; charset=UTF-8 Cc: Kevin Oberman , "freebsd-acpi@freebsd.org" , Rui Paulo , "freebsd-arch@freebsd.org" X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2014 00:25:51 -0000 [snip] The easy-to-run test is "sysctl dev.cpu.0.cx_lowest=Cmax" and then use stuff. The problem is that we're not getting anywhere near enough exposure to this kind of stuff because we don't have it on by default and we don't have an active QA group with ridiculous amounts of hardware. So, I'd like to flip it on and then start blacklisting devices that actively don't work in halt states above C1. We're never going to cross this bridge fully if we leave things at C1 out of fear. I'm only suggesting we do this on -HEAD. If it's too scary then we can always flip the default back to C1 for 11.0-RELEASE. -a From owner-freebsd-acpi@FreeBSD.ORG Mon May 5 00:53:24 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 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7791EB11; Mon, 5 May 2014 00:53:24 +0000 (UTC) Received: from wonkity.com (wonkity.com [67.158.26.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "wonkity.com", Issuer "wonkity.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 23688149F; Mon, 5 May 2014 00:53:23 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.8/8.14.8) with ESMTP id s450rLG0009836 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 4 May 2014 18:53:21 -0600 (MDT) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.8/8.14.8/Submit) with ESMTP id s450rLNq009833; Sun, 4 May 2014 18:53:21 -0600 (MDT) (envelope-from wblock@wonkity.com) Date: Sun, 4 May 2014 18:53:21 -0600 (MDT) From: Warren Block To: Adrian Chadd Subject: Re: proposal: set default lid state to S3, performance/economy Cx states to Cmax In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (wonkity.com [127.0.0.1]); Sun, 04 May 2014 18:53:21 -0600 (MDT) Cc: Kevin Oberman , "freebsd-acpi@freebsd.org" , Rui Paulo , "freebsd-arch@freebsd.org" X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2014 00:53:24 -0000 On Sun, 4 May 2014, Adrian Chadd wrote: > [snip] > > The easy-to-run test is "sysctl dev.cpu.0.cx_lowest=Cmax" and then use stuff. It's that "use stuff" step that would preferably be automated. Is the failure mode a lockup, or could a program detect problems? The idea is to get lots of feedback, fast. > The problem is that we're not getting anywhere near enough exposure to > this kind of stuff because we don't have it on by default and we don't > have an active QA group with ridiculous amounts of hardware. > > So, I'd like to flip it on and then start blacklisting devices that > actively don't work in halt states above C1. We're never going to > cross this bridge fully if we leave things at C1 out of fear. > > I'm only suggesting we do this on -HEAD. If it's too scary then we can > always flip the default back to C1 for 11.0-RELEASE. Seems reasonable to me. From owner-freebsd-acpi@FreeBSD.ORG Mon May 5 01:07: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 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F1366F66; Mon, 5 May 2014 01:07:34 +0000 (UTC) Received: from mail-qa0-x229.google.com (mail-qa0-x229.google.com [IPv6:2607:f8b0:400d:c00::229]) (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 9EC6B15A2; Mon, 5 May 2014 01:07:34 +0000 (UTC) Received: by mail-qa0-f41.google.com with SMTP id dc16so4844912qab.28 for ; Sun, 04 May 2014 18:07:33 -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:message-id:subject :from:to:cc:content-type; bh=C/RiJASl00e/cggkv6Iocpw27MfRAq7Xeem0vxC7+Oo=; b=v02bDV7KTQBIyS1gZ0vBCZCAUknQuz+icZWhX1i0lncUhst41mJN4bj17NKLwFTZIF yxD9SYBAvQOR9XpDP+UeN3sP1pf6RYDyDBuiipr0glAXklM/BiTHFVktpqAY6kAffsaI xdksE8JQQpNVxRA6hwl535c8ZxLHI1A85jl45ZPo/8rRQr6/GUCvCJIZxk8DIBaR209F lIZxWYlZe0JFDNMSqudh66ipGP/jhaE8fdmfsdNUs2ajRM8lSbqbidgN6wHqFc8/GWV0 u7Ir8cOy0WXhXlaqlt7P+rkPxCChvGzpKF0IsZ0tMUlnEc+bIdZqknQMwFMQpfd0jXox /rwg== MIME-Version: 1.0 X-Received: by 10.224.38.138 with SMTP id b10mr467403qae.98.1399252053166; Sun, 04 May 2014 18:07:33 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.191.201 with HTTP; Sun, 4 May 2014 18:07:33 -0700 (PDT) In-Reply-To: References: Date: Sun, 4 May 2014 18:07:33 -0700 X-Google-Sender-Auth: bYHhbVFb43FcK3XkSBMH78nm_KI Message-ID: Subject: Re: proposal: set default lid state to S3, performance/economy Cx states to Cmax From: Adrian Chadd To: Warren Block Content-Type: text/plain; charset=UTF-8 Cc: Kevin Oberman , "freebsd-acpi@freebsd.org" , Rui Paulo , "freebsd-arch@freebsd.org" X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2014 01:07:35 -0000 On 4 May 2014 17:53, Warren Block wrote: > On Sun, 4 May 2014, Adrian Chadd wrote: > >> [snip] >> >> The easy-to-run test is "sysctl dev.cpu.0.cx_lowest=Cmax" and then use >> stuff. > > > It's that "use stuff" step that would preferably be automated. Is the > failure mode a lockup, or could a program detect problems? The idea is to > get lots of feedback, fast. The lack of a general test suite is a bigger problem. :-) -a From owner-freebsd-acpi@FreeBSD.ORG Mon May 5 05:18:15 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 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1C973A28; Mon, 5 May 2014 05:18:15 +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 7F6D21FB4; Mon, 5 May 2014 05:18:13 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id s455I3ir092634; Mon, 5 May 2014 15:18:03 +1000 (EST) (envelope-from smithi@nimnet.asn.au) Date: Mon, 5 May 2014 15:18:03 +1000 (EST) From: Ian Smith To: Adrian Chadd Subject: Re: proposal: set default lid state to S3, performance/economy Cx states to Cmax In-Reply-To: Message-ID: <20140505135809.Y11699@sola.nimnet.asn.au> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: Kevin Oberman , "freebsd-acpi@freebsd.org" , Rui Paulo , "freebsd-arch@freebsd.org" X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2014 05:18:15 -0000 On Sun, 4 May 2014 17:25:50 -0700, Adrian Chadd wrote: > [snip] > > The easy-to-run test is "sysctl dev.cpu.0.cx_lowest=Cmax" and then use stuff. This doesn't work, on stable/9 at least, in that it only sets cpu.0 .. you need to set sysctl hw.acpi.cpu.cx_lowest - which rather surprised me, although that's what /etc/rc.d/power_profile has always set. I guess it's only cpu.0.freq that still sets all CPUs in sync. Further, rather than -economy_cx_lowest="HIGH" # Offline CPU idle state +economy_cx_lowest="Cmax" # Offline CPU idle state you could use "LOW" which already sets it to "Cmax", though on 8.2: lowest_value="`(sysctl -n dev.cpu.0.cx_supported | \ awk '{ print "C" split($0, a) }' -) 2> /dev/null`" I'm not sure what the point of setting cx_lowest to C8 is on a machine where lowest cx_supported is C3, but it seems to do no harm on mine. Where does C8 come from anyway? Is that the lowest on any known hardware, or the lowest the ACPI spec supports? root@x200:~ # sysctl -a | grep cx hw.acpi.cpu.cx_lowest: C3 dev.cpu.0.cx_supported: C1/1/1 C2/2/1 C3/3/57 dev.cpu.0.cx_lowest: C3 dev.cpu.0.cx_usage: 0.00% 0.79% 99.20% last 35us dev.cpu.1.cx_supported: C1/1/1 C2/2/1 C3/3/57 dev.cpu.1.cx_lowest: C3 dev.cpu.1.cx_usage: 0.08% 1.59% 98.32% last 62us root@x200:~ # sysctl dev.cpu.0.cx_lowest=Cmax dev.cpu.0.cx_lowest: C3 -> C8 root@x200:~ # sysctl -a | grep cx hw.acpi.cpu.cx_lowest: C3 dev.cpu.0.cx_supported: C1/1/1 C2/2/1 C3/3/57 dev.cpu.0.cx_lowest: C8 <<<< dev.cpu.0.cx_usage: 0.00% 5.66% 94.33% last 73us dev.cpu.1.cx_supported: C1/1/1 C2/2/1 C3/3/57 dev.cpu.1.cx_lowest: C3 <<<< dev.cpu.1.cx_usage: 0.07% 1.91% 98.01% last 2us root@x200:~ # sysctl dev.cpu.1.cx_lowest=C2 dev.cpu.1.cx_lowest: C3 -> C2 root@x200:~ # sysctl -a | grep cx hw.acpi.cpu.cx_lowest: C3 <<<< dev.cpu.0.cx_supported: C1/1/1 C2/2/1 C3/3/57 dev.cpu.0.cx_lowest: C8 <<<< dev.cpu.0.cx_usage: 0.00% 0.19% 99.80% last 474us dev.cpu.1.cx_supported: C1/1/1 C2/2/1 C3/3/57 dev.cpu.1.cx_lowest: C2 <<<< dev.cpu.1.cx_usage: 3.47% 96.52% 0.00% last 1us root@x200:~ # sysctl hw.acpi.cpu.cx_lowest=Cmax hw.acpi.cpu.cx_lowest: C3 -> C8 root@x200:~ # sysctl -a | grep cx hw.acpi.cpu.cx_lowest: C8 dev.cpu.0.cx_supported: C1/1/1 C2/2/1 C3/3/57 dev.cpu.0.cx_lowest: C8 dev.cpu.0.cx_usage: 0.00% 3.05% 96.94% last 351us dev.cpu.1.cx_supported: C1/1/1 C2/2/1 C3/3/57 dev.cpu.1.cx_lowest: C8 dev.cpu.1.cx_usage: 0.00% 7.05% 92.94% last 2us I've long run with C3 in AC power mode without issue, but don't know if that's true for all machines; all yours and mine are Thinkpads! > The problem is that we're not getting anywhere near enough exposure to > this kind of stuff because we don't have it on by default and we don't > have an active QA group with ridiculous amounts of hardware. > > So, I'd like to flip it on and then start blacklisting devices that > actively don't work in halt states above C1. We're never going to > cross this bridge fully if we leave things at C1 out of fear. > > I'm only suggesting we do this on -HEAD. If it's too scary then we can > always flip the default back to C1 for 11.0-RELEASE. Yeah, I think this likely uncontroversial - unlike lid state S3 - and I don't recall hearing about machines that fail below C1 if lower states are shown as available. As you say, this might shake these out. But where would you put such a blacklist? Someting like USB quirks? cheers, Ian From owner-freebsd-acpi@FreeBSD.ORG Mon May 5 05:22:14 2014 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2B855C15; Mon, 5 May 2014 05:22:14 +0000 (UTC) Received: from mail-qa0-x230.google.com (mail-qa0-x230.google.com [IPv6:2607:f8b0:400d:c00::230]) (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 C8C731FD9; Mon, 5 May 2014 05:22:13 +0000 (UTC) Received: by mail-qa0-f48.google.com with SMTP id i13so1903473qae.7 for ; Sun, 04 May 2014 22:22:13 -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:message-id:subject :from:to:cc:content-type; bh=RSwHUOUUlZI4ZpFAxg8ANDO8ZVVxL/FluJ6ckofBbX4=; b=HoT/CJb/EOS9URlzkA2qpJDpLQSgfS9I5RrR5khv0TOAUhr/9kJWaJKhQowBJ/Np4Z TfTiIGRDHxKCUHxK/zXUytXlgZmmRViraOqKx7IENias3tKPVqire8VEJcN+hMUga396 p06JNTh5jFAIGkgb5UbDnMHXAWb5WPY2glWuMCq9rJtE9749iCcAE2q3MTmFGj4OMVNs Ee/OtQR/STu7h8KrC8Yiwc+2hQGggTNUpUSXbBCX4mhYFqQrStUHnmsLApbtcimNCXAf JUja8GGIpQAU8Atx8EqVS1JREHpK2Ln5tQpMfYONATF4Oj86JrTRnSBfDep15xJKWSfl IU5Q== MIME-Version: 1.0 X-Received: by 10.224.47.130 with SMTP id n2mr42105697qaf.26.1399267332980; Sun, 04 May 2014 22:22:12 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.191.201 with HTTP; Sun, 4 May 2014 22:22:12 -0700 (PDT) In-Reply-To: <20140505135809.Y11699@sola.nimnet.asn.au> References: <20140505135809.Y11699@sola.nimnet.asn.au> Date: Sun, 4 May 2014 22:22:12 -0700 X-Google-Sender-Auth: u-RXGYRcF7mwBWtF_rrFP10VxR4 Message-ID: Subject: Re: proposal: set default lid state to S3, performance/economy Cx states to Cmax From: Adrian Chadd To: Ian Smith Content-Type: text/plain; charset=UTF-8 Cc: Kevin Oberman , "freebsd-acpi@freebsd.org" , Rui Paulo , "freebsd-arch@freebsd.org" X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2014 05:22:14 -0000 On 4 May 2014 22:18, Ian Smith wrote: > On Sun, 4 May 2014 17:25:50 -0700, Adrian Chadd wrote: > > [snip] > > > > The easy-to-run test is "sysctl dev.cpu.0.cx_lowest=Cmax" and then use stuff. > > This doesn't work, on stable/9 at least, in that it only sets cpu.0 .. > you need to set sysctl hw.acpi.cpu.cx_lowest - which rather surprised > me, although that's what /etc/rc.d/power_profile has always set. I > guess it's only cpu.0.freq that still sets all CPUs in sync. Yeah. Sorry, my mistake. One should just do the rc.conf change and reboot. > Further, rather than > -economy_cx_lowest="HIGH" # Offline CPU idle state > +economy_cx_lowest="Cmax" # Offline CPU idle state > you could use "LOW" which already sets it to "Cmax", though on 8.2: > lowest_value="`(sysctl -n dev.cpu.0.cx_supported | \ > awk '{ print "C" split($0, a) }' -) 2> /dev/null`" > > I'm not sure what the point of setting cx_lowest to C8 is on a machine > where lowest cx_supported is C3, but it seems to do no harm on mine. Well, it's just convenient to set it to that. It's the same as Cmax. > Where does C8 come from anyway? Is that the lowest on any known > hardware, or the lowest the ACPI spec supports? Not sure. It's what's chosen when you use Cmax. :-) > root@x200:~ # sysctl -a | grep cx > hw.acpi.cpu.cx_lowest: C3 > dev.cpu.0.cx_supported: C1/1/1 C2/2/1 C3/3/57 > dev.cpu.0.cx_lowest: C3 > dev.cpu.0.cx_usage: 0.00% 0.79% 99.20% last 35us > dev.cpu.1.cx_supported: C1/1/1 C2/2/1 C3/3/57 > dev.cpu.1.cx_lowest: C3 > dev.cpu.1.cx_usage: 0.08% 1.59% 98.32% last 62us > > root@x200:~ # sysctl dev.cpu.0.cx_lowest=Cmax > dev.cpu.0.cx_lowest: C3 -> C8 > root@x200:~ # sysctl -a | grep cx > hw.acpi.cpu.cx_lowest: C3 > dev.cpu.0.cx_supported: C1/1/1 C2/2/1 C3/3/57 > dev.cpu.0.cx_lowest: C8 <<<< > dev.cpu.0.cx_usage: 0.00% 5.66% 94.33% last 73us > dev.cpu.1.cx_supported: C1/1/1 C2/2/1 C3/3/57 > dev.cpu.1.cx_lowest: C3 <<<< > dev.cpu.1.cx_usage: 0.07% 1.91% 98.01% last 2us > > root@x200:~ # sysctl dev.cpu.1.cx_lowest=C2 > dev.cpu.1.cx_lowest: C3 -> C2 > root@x200:~ # sysctl -a | grep cx > hw.acpi.cpu.cx_lowest: C3 <<<< > dev.cpu.0.cx_supported: C1/1/1 C2/2/1 C3/3/57 > dev.cpu.0.cx_lowest: C8 <<<< > dev.cpu.0.cx_usage: 0.00% 0.19% 99.80% last 474us > dev.cpu.1.cx_supported: C1/1/1 C2/2/1 C3/3/57 > dev.cpu.1.cx_lowest: C2 <<<< > dev.cpu.1.cx_usage: 3.47% 96.52% 0.00% last 1us > > root@x200:~ # sysctl hw.acpi.cpu.cx_lowest=Cmax > hw.acpi.cpu.cx_lowest: C3 -> C8 > root@x200:~ # sysctl -a | grep cx > hw.acpi.cpu.cx_lowest: C8 > dev.cpu.0.cx_supported: C1/1/1 C2/2/1 C3/3/57 > dev.cpu.0.cx_lowest: C8 > dev.cpu.0.cx_usage: 0.00% 3.05% 96.94% last 351us > dev.cpu.1.cx_supported: C1/1/1 C2/2/1 C3/3/57 > dev.cpu.1.cx_lowest: C8 > dev.cpu.1.cx_usage: 0.00% 7.05% 92.94% last 2us > > I've long run with C3 in AC power mode without issue, but don't know if > that's true for all machines; all yours and mine are Thinkpads! I've only had problems on an older Atom. That I'll bring with me to bsdcan to finally show mav. Linux has had the same problem with this particular Atom and timekeeping. ;( > > The problem is that we're not getting anywhere near enough exposure to > > this kind of stuff because we don't have it on by default and we don't > > have an active QA group with ridiculous amounts of hardware. > > > > So, I'd like to flip it on and then start blacklisting devices that > > actively don't work in halt states above C1. We're never going to > > cross this bridge fully if we leave things at C1 out of fear. > > > > I'm only suggesting we do this on -HEAD. If it's too scary then we can > > always flip the default back to C1 for 11.0-RELEASE. > > Yeah, I think this likely uncontroversial - unlike lid state S3 - and I > don't recall hearing about machines that fail below C1 if lower states > are shown as available. As you say, this might shake these out. > > But where would you put such a blacklist? Someting like USB quirks? I'm not sure yet. Maybe make it userland and as part of the rc / power scripts. That way Cmax gets turned into C1. -a From owner-freebsd-acpi@FreeBSD.ORG Mon May 5 05:45:13 2014 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 06FBFE6D; Mon, 5 May 2014 05:45:13 +0000 (UTC) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id BEADA1164; Mon, 5 May 2014 05:45:12 +0000 (UTC) Received: from critter.freebsd.dk (unknown [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id D715715AF; Mon, 5 May 2014 05:45:10 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.8/8.14.8) with ESMTP id s455jAbt022968; Mon, 5 May 2014 05:45:10 GMT (envelope-from phk@phk.freebsd.dk) To: Adrian Chadd Subject: Re: proposal: set default lid state to S3, performance/economy Cx states to Cmax In-reply-to: From: "Poul-Henning Kamp" References: <20140505011654.O11699@sola.nimnet.asn.au> <2223.1399233644@critter.freebsd.dk> Content-Type: text/plain; charset=ISO-8859-1 Date: Mon, 05 May 2014 05:45:10 +0000 Message-ID: <22967.1399268710@critter.freebsd.dk> Cc: Kevin Oberman , "freebsd-acpi@freebsd.org" , Ian Smith , "freebsd-arch@freebsd.org" X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2014 05:45:13 -0000 In message , Adrian Chadd writes: >> I havn't seen suspend/resume work for ages on my T4xx laptops and >> as far as I recall it never worked on this T430s at all. > >I've tested it (-HEAD) on: > >* T43 >* T60 >* T60p >* T400 >* T500 >* T420 >* X220 I'm building head as we speak, I'll test once it's done. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-acpi@FreeBSD.ORG Mon May 5 06:17:12 2014 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DBD9D16A; Mon, 5 May 2014 06:17:12 +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 2E444135F; Mon, 5 May 2014 06:17:11 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id s456H87B094601; Mon, 5 May 2014 16:17:08 +1000 (EST) (envelope-from smithi@nimnet.asn.au) Date: Mon, 5 May 2014 16:17:08 +1000 (EST) From: Ian Smith To: Adrian Chadd Subject: Re: proposal: set default lid state to S3, performance/economy Cx states to Cmax In-Reply-To: Message-ID: <20140505153421.W11699@sola.nimnet.asn.au> References: <20140505011654.O11699@sola.nimnet.asn.au> <2223.1399233644@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: Kevin Oberman , Poul-Henning Kamp , "freebsd-acpi@freebsd.org" , "freebsd-arch@freebsd.org" X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2014 06:17:13 -0000 On Sun, 4 May 2014 13:51:20 -0700, Adrian Chadd wrote: > On 4 May 2014 13:00, Poul-Henning Kamp wrote: > > I havn't seen suspend/resume work for ages on my T4xx laptops and > > as far as I recall it never worked on this T430s at all. > > I've tested it (-HEAD) on: > > * T43 > * T60 > * T60p > * T400 > * T500 > * T420 > * X220 > > I'm actively using the T60, T400 and X220 right now. So, is the USB not working after $n resumes on T4xx and T2xx (at least) now fixed in HEAD? If so, it would be REALLY good to MFC whatever fixed it to 10 and hopefully to 9 before 9.3. I need to do more tests on stable/9; it didn't work with the offered workarounds on 9.2-RELEASE (leaving VESA out of kernel leaves me with no screen on resume in console mode, setting sysctl dev.[ue]hci.*.wake=1 fails to even start to resume) though if that works on 10 I'd give it a go, despite Darren Pilgrim's dvd1_to_memstick script failing to have pkg use any of the local DVD packages, which is why I went back to 9.2 I know you only like working on HEAD, but unless there's API/ABI reasons preventing MFC, it would be great to have 9.3 work in this respect .. my X200 is not useful for purpose if it won't suspend/resume 100% reliably, with USB, and I don't want to run 11 on it, it's needed for developing non-FreeBSD stuff (in freepascal, if that's not a dirty word here :) and for that it needs to be rock solid while travelling from place to place. > I'd like to see it working on more laptops and I've worked with > various people in the past to try and fix whichever resume issues I > find. Indeed; last I heard was last July with unsolved USB issues on your T400, and the mysterious but related 'CPU0: local APIC error 0x40' > I'm happy leaving this as-is but at some point something has to be > bitten and the bugs in the drivers / ACPI stuff need to be fixed. :) It's a bit disconcerting if fixes only ever make it into HEAD, for me. cheers, Ian (someone please sing out if I shouldn't be crossposting to -arch) From owner-freebsd-acpi@FreeBSD.ORG Mon May 5 06:25:23 2014 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3F947264; Mon, 5 May 2014 06:25:23 +0000 (UTC) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id F40DA13F0; Mon, 5 May 2014 06:25:22 +0000 (UTC) Received: from critter.freebsd.dk (unknown [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id CC23915AF; Mon, 5 May 2014 06:25:21 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.8/8.14.8) with ESMTP id s456PL1G085790; Mon, 5 May 2014 06:25:21 GMT (envelope-from phk@phk.freebsd.dk) To: Ian Smith Subject: Re: proposal: set default lid state to S3, performance/economy Cx states to Cmax In-reply-to: <20140505153421.W11699@sola.nimnet.asn.au> From: "Poul-Henning Kamp" References: <20140505011654.O11699@sola.nimnet.asn.au> <2223.1399233644@critter.freebsd.dk> <20140505153421.W11699@sola.nimnet.asn.au> Content-Type: text/plain; charset=ISO-8859-1 Date: Mon, 05 May 2014 06:25:21 +0000 Message-ID: <85787.1399271121@critter.freebsd.dk> Cc: Kevin Oberman , "freebsd-acpi@freebsd.org" , "freebsd-arch@freebsd.org" X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2014 06:25:23 -0000 In message <20140505153421.W11699@sola.nimnet.asn.au>, Ian Smith writes: >I need to do more tests on stable/9; it didn't work with the offered >workarounds on 9.2-RELEASE (leaving VESA out of kernel leaves me with no >screen on resume in console mode, setting sysctl dev.[ue]hci.*.wake=1 Do we have a canonical page with all the various workarounds one should attempt in order to get suspend/resume to work ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-acpi@FreeBSD.ORG Mon May 5 07:00:44 2014 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 57C2C51D; Mon, 5 May 2014 07:00:44 +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 BD8F3167E; Mon, 5 May 2014 07:00:43 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id s4570cAh096109; Mon, 5 May 2014 17:00:39 +1000 (EST) (envelope-from smithi@nimnet.asn.au) Date: Mon, 5 May 2014 17:00:38 +1000 (EST) From: Ian Smith To: Poul-Henning Kamp Subject: Re: proposal: set default lid state to S3, performance/economy Cx states to Cmax In-Reply-To: <85787.1399271121@critter.freebsd.dk> Message-ID: <20140505163316.R11699@sola.nimnet.asn.au> References: <20140505011654.O11699@sola.nimnet.asn.au> <2223.1399233644@critter.freebsd.dk> <20140505153421.W11699@sola.nimnet.asn.au> <85787.1399271121@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: Kevin Oberman , "freebsd-acpi@freebsd.org" , "freebsd-arch@freebsd.org" X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2014 07:00:44 -0000 On Mon, 5 May 2014 06:25:21 +0000, Poul-Henning Kamp wrote: > In message <20140505153421.W11699@sola.nimnet.asn.au>, Ian Smith writes: > > >I need to do more tests on stable/9; it didn't work with the offered > >workarounds on 9.2-RELEASE (leaving VESA out of kernel leaves me with no > >screen on resume in console mode, setting sysctl dev.[ue]hci.*.wake=1 > > Do we have a canonical page with all the various workarounds one should > attempt in order to get suspend/resume to work ? Bits scattered all over the place. For the above there's: http://unethicalblogger.com/2013/12/03/scratchiest-neckbeard-freebsd-x200.html which refers to te tail of this thread in -usb (and -stable) http://lists.freebsd.org/pipermail/freebsd-usb/2013-July/thread.html#12242 which began with Adrian's post in http://lists.freebsd.org/pipermail/freebsd-usb/2013-June/thread.html Then there's the wiki page: https://wiki.freebsd.org/SuspendResume which leads to some more bits, lots more scattered through -acpi and -laptop over the time. There used to be lots of useful per-laptop snippets in the FLCL (freebsd laptop compatibility list) which sadly disappeared last year, but I just googled up an archive of it at http://archive.today/CVo46 latest from mid-2013. Ah sorry, spoke too soon, individual pages redirect to eg: http://laptop.bsdgroup.de/freebsd/index.html?action=list_laptop_mf&mfid=1 which is still down :( Ian From owner-freebsd-acpi@FreeBSD.ORG Mon May 5 09:16:55 2014 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 06BAFC91; Mon, 5 May 2014 09:16:55 +0000 (UTC) Received: from smtprelay05.ispgateway.de (smtprelay05.ispgateway.de [80.67.31.94]) (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 B3E7A1308; Mon, 5 May 2014 09:16:54 +0000 (UTC) Received: from [78.35.164.35] (helo=fabiankeil.de) by smtprelay05.ispgateway.de with esmtpsa (SSLv3:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1WhEeX-0004tS-0W; Mon, 05 May 2014 10:53:37 +0200 Date: Mon, 5 May 2014 10:53:45 +0200 From: Fabian Keil To: "freebsd-acpi@freebsd.org" Subject: Re: proposal: set default lid state to S3, performance/economy Cx states to Cmax Message-ID: <20140505105345.099e4503@fabiankeil.de> In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; boundary="Sig_/gPHa/TvqAC+pMJ9jm174mKD"; protocol="application/pgp-signature" X-Df-Sender: Nzc1MDY3 Cc: "freebsd-arch@freebsd.org" X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2014 09:16:55 -0000 --Sig_/gPHa/TvqAC+pMJ9jm174mKD Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Warren Block wrote: > On Sun, 4 May 2014, Adrian Chadd wrote: > > The easy-to-run test is "sysctl dev.cpu.0.cx_lowest=3DCmax" and then us= e stuff. >=20 > It's that "use stuff" step that would preferably be automated. Is the=20 > failure mode a lockup, or could a program detect problems? The idea=20 > is to get lots of feedback, fast. One possible failure mode is that timers tick unreliably which can be detected automatically (in some cases), for example by using the DTrace script timestamp-test.d: http://www.fabiankeil.de/gehacktes/dtrace-timestamp-tests/ It should also be possible to let the kernel do this itself and log an error message and maybe optionally disable Cx states that cause problems: sysctl dev.cpu.0.cx_lowest=3DCmax-as-long-as-it-appears-to-be-working Fabian --Sig_/gPHa/TvqAC+pMJ9jm174mKD Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iEYEARECAAYFAlNnUZoACgkQBYqIVf93VJ3mbACfR/oMz44RrrpDrxX5dsJDQSxt cccAoMmC0JQIeUVcSqTgfZIwGheO7RoN =Qn19 -----END PGP SIGNATURE----- --Sig_/gPHa/TvqAC+pMJ9jm174mKD-- From owner-freebsd-acpi@FreeBSD.ORG Mon May 5 09:54:23 2014 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 04FFC6E8; Mon, 5 May 2014 09:54:23 +0000 (UTC) Received: from mail.0x20.net (mail.0x20.net [217.69.76.211]) (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 B2C7916BE; Mon, 5 May 2014 09:54:22 +0000 (UTC) Received: from e-new.0x20.net (mail.0x20.net [IPv6:2001:aa8:fffb:1::3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.0x20.net (Postfix) with ESMTPS id AE5F06A600D; Mon, 5 May 2014 11:54:18 +0200 (CEST) Received: from e-new.0x20.net (localhost [127.0.0.1]) by e-new.0x20.net (8.14.7/8.14.7) with ESMTP id s459sIYu068431; Mon, 5 May 2014 11:54:18 +0200 (CEST) (envelope-from lars@e-new.0x20.net) Received: (from lars@localhost) by e-new.0x20.net (8.14.7/8.14.7/Submit) id s459sGWd067448; Mon, 5 May 2014 11:54:16 +0200 (CEST) (envelope-from lars) Date: Mon, 5 May 2014 11:54:16 +0200 From: Lars Engels To: Ian Smith Subject: Re: proposal: set default lid state to S3, performance/economy Cx states to Cmax Message-ID: <20140505095416.GF1451@e-new.0x20.net> References: <20140505011654.O11699@sola.nimnet.asn.au> <2223.1399233644@critter.freebsd.dk> <20140505153421.W11699@sola.nimnet.asn.au> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: <20140505153421.W11699@sola.nimnet.asn.au> X-Editor: VIM - Vi IMproved 7.4 X-Operation-System: FreeBSD 8.4-RELEASE-p4 User-Agent: Mutt/1.5.23 (2014-03-12) Cc: Kevin Oberman , "freebsd-arch@freebsd.org" , Poul-Henning Kamp , "freebsd-acpi@freebsd.org" X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2014 09:54:23 -0000 On Mon, May 05, 2014 at 04:17:08PM +1000, Ian Smith wrote: > On Sun, 4 May 2014 13:51:20 -0700, Adrian Chadd wrote: > > On 4 May 2014 13:00, Poul-Henning Kamp wrote: >=20 > > > I havn't seen suspend/resume work for ages on my T4xx laptops and > > > as far as I recall it never worked on this T430s at all. > >=20 > > I've tested it (-HEAD) on: > >=20 > > * T43 > > * T60 > > * T60p > > * T400 > > * T500 > > * T420 > > * X220 > >=20 > > I'm actively using the T60, T400 and X220 right now. I can also confirm that suspend/resume works out of the box on my X200 and= =20 on several T61 I used with 10.0-RELEASE, even without newcons the T61 woke up. > I know you only like working on HEAD, but unless there's API/ABI reasons= =20 > preventing MFC, it would be great to have 9.3 work in this respect .. my= =20 > X200 is not useful for purpose if it won't suspend/resume 100% reliably,= =20 > with USB, and I don't want to run 11 on it, it's needed for developing=20 > non-FreeBSD stuff (in freepascal, if that's not a dirty word here :) and= =20 > for that it needs to be rock solid while travelling from place to place. Tyler Croy got it working on his X200 which did not work for me: http://unethicalblogger.com/2013/12/03/scratchiest-neckbeard-freebsd-x200.h= tml I worked around around this with an el cheapo USB 3.0 PCI-Express card which fits nicely into the card slot and works after every resume. From owner-freebsd-acpi@FreeBSD.ORG Mon May 5 11:06:40 2014 Return-Path: Delivered-To: freebsd-acpi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 07FC3CDC for ; Mon, 5 May 2014 11:06:40 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (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 CEB701CDE for ; Mon, 5 May 2014 11:06:39 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.8/8.14.8) with ESMTP id s45B6d8C083022 for ; Mon, 5 May 2014 11:06:39 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.8/8.14.8/Submit) id s45B6dqV083020 for freebsd-acpi@FreeBSD.org; Mon, 5 May 2014 11:06:39 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 5 May 2014 11:06:39 GMT Message-Id: <201405051106.s45B6dqV083020@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.18 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2014 11:06:40 -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/187152 acpi [i386] [acpi] [suspend/resume] resume from ACPI suspen o kern/181665 acpi [acpi] System will not go into S3 state. o kern/180897 acpi [acpi] ACPI error with MB p8h67 v.1405 o kern/174766 acpi [acpi] Random acpi panic o kern/174504 acpi [acpi] [suspend/resume] Suspend/resume broken on Lenov o kern/173414 acpi [acpi] ACPI battery time incorrect o kern/173408 acpi [acpi] [regression] ACPI Regression: battery does not 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] [suspend/resume] Dell E6520 doesn't resume afte o kern/161713 acpi [acpi] [suspend/resume] Suspend on Dell E6520 doesn't 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] [suspend/resume] Lenovo T61p does not resume o i386/146715 acpi [acpi] [suspend/resume] Suspend works, resume not on a 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/73823 acpi [request] acpi / power-on by timer support 30 problems total. From owner-freebsd-acpi@FreeBSD.ORG Mon May 5 15:05:50 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 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 59C87B3A; Mon, 5 May 2014 15:05:50 +0000 (UTC) Received: from mail.ignoranthack.me (ujvl.x.rootbsd.net [199.102.79.106]) (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 362441733; Mon, 5 May 2014 15:05:49 +0000 (UTC) Received: from [192.168.10.7] (unknown [207.198.106.18]) (using SSLv3 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: sbruno@ignoranthack.me) by mail.ignoranthack.me (Postfix) with ESMTPSA id DD90C1928E4; Mon, 5 May 2014 15:05:47 +0000 (UTC) Subject: Re: proposal: set default lid state to S3, performance/economy Cx states to Cmax From: Sean Bruno Reply-To: sbruno@freebsd.org To: Adrian Chadd In-Reply-To: References: <20140505011654.O11699@sola.nimnet.asn.au> <2223.1399233644@critter.freebsd.dk> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-YJiqTCg6/ewMxLrtZFB7" Date: Mon, 05 May 2014 08:05:46 -0700 Message-ID: <1399302346.10130.1.camel@powernoodle.corp.yahoo.com> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Cc: "freebsd-acpi@freebsd.org" X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2014 15:05:50 -0000 --=-YJiqTCg6/ewMxLrtZFB7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sun, 2014-05-04 at 13:51 -0700, Adrian Chadd wrote: > I've tested it (-HEAD) on: >=20 > * T43 > * T60 > * T60p > * T400 > * T500 > * T420 > * X220 >=20 > I'm actively using the T60, T400 and X220 right now. >=20 >=20 T520, just works. Has for a while. I suspect disabling firewire and the eSATA port helps quite a bit. sean -arch for this. --=-YJiqTCg6/ewMxLrtZFB7 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAABAgAGBQJTZ6jCAAoJEBkJRdwI6BaHMcUH/3YIWbeLgvSfJ2NXO/GwUEWt JLuGQnZBsaAcO+Y023CuwQBoiELK/oLaBhmKaBwWd3wRdnMK9XnTVgwfe+oE+5Hq EjYEaLjXTAFS5ScSeIFE4EWnkaGO2hxk6gRAFw1FuIOQRv+DRmXpTZq3v0AlRmt/ YjOdUw/QIx3vxvoBMZO4pDd5chmH6z1o5s+RFa10jbvhSAdWi7tfVxFNGaIwTSRo uuKyScp7uf0V36o5jTD9iY8Er2kDwiiNgxpozFoQOjeFwCX2+qcC1pFcwbFB38Pb 0mlfJA+zRdVQHeU4zYgXFwWVLggcuoKwcyD1T1D01i+m65crUSUtMLdvvgksDXs= =IoWe -----END PGP SIGNATURE----- --=-YJiqTCg6/ewMxLrtZFB7-- From owner-freebsd-acpi@FreeBSD.ORG Mon May 5 16:26:09 2014 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6D1C33BE; Mon, 5 May 2014 16:26:09 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 44EF610F; Mon, 5 May 2014 16:26:09 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id A27A7B917; Mon, 5 May 2014 12:26:07 -0400 (EDT) From: John Baldwin To: freebsd-acpi@freebsd.org Subject: Re: proposal: set default lid state to S3, performance/economy Cx states to Cmax Date: Mon, 5 May 2014 11:09:39 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20140415; KDE/4.5.5; amd64; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201405051109.39345.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 05 May 2014 12:26:07 -0400 (EDT) Cc: Kevin Oberman , "freebsd-arch@freebsd.org" X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2014 16:26:09 -0000 On Sunday, May 04, 2014 4:27:38 am Adrian Chadd wrote: > Hi, > > I'd like to propose flipping a few things: > > * Flipping the default lid state to S3. I think ACPI suspend/resume > seems to work well enough these days and I've not met anyone lately > who expects the default from their laptop to be "stay awake with the > lid shut." > * Save chip bugs that we should add workarounds for, we should be OK > to enter lower sleep states when idling. Flipping this may expose some > further crazy driver, platform or timer bugs, but they again likely > should be fixed. > > what do people think? I think the lid switch thing is premature. Even on my X220 I use a devd hook to enable it only when i915drm is loaded as resume doesn't work until that is done. I think the Cmax thing OTOH is probably more appropriate. We have several things place that should "mostly" DTRT for picking the correct timers to use. The one case I know of recently were some somewhat older systems where the HPET wasn't reliable, but the system chose to use HPET instead of LAPIC becuase the LAPIC was known to stop during C1E, etc. In this case the user just stuck with plain old C1 and forced the LAPIC timer which worked fine. However, it is hard to identify those cases. On modern systems I would expect the LAPIC to work just fine, so this problem will become less and less important as time goes on. -- John Baldwin From owner-freebsd-acpi@FreeBSD.ORG Mon May 5 16:55:31 2014 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 34C3B679; Mon, 5 May 2014 16:55:31 +0000 (UTC) Received: from mail-qa0-x22d.google.com (mail-qa0-x22d.google.com [IPv6:2607:f8b0:400d:c00::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 C794C3B7; Mon, 5 May 2014 16:55:30 +0000 (UTC) Received: by mail-qa0-f45.google.com with SMTP id hw13so6991671qab.4 for ; Mon, 05 May 2014 09:55:29 -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:message-id:subject :from:to:cc:content-type; bh=hJqYB5/TfZWf3v/eNWmemNQi5qdUZ01FyQLgHFnBJO4=; b=CLBbcxaVE4bMmTD/V+4f6ObYjtXVyMsrPW4HCUmFnGY14v/X7DCzzNn59SvVbvlevP HPIl2A+caO1lCJ5jLYIsnIXUcQJewc5TC2GbNJpJGDgfSDP6dZLvCBnsHWkOlx+pV+lD 1q4NPPzEQRa3xZhvjEISUegvSg7hW0saLIrGWGGqQhppgGiqoLNKkhy9zxDE8GTz3qG/ GTv5yns/mc7u6VxERepnwg70NDhIH3KKVnEeO4LrftJqgUQAwa4oY8BesQhD4hJ9khGM wAA7urNZCKCOw7hA2peJnbpxjH8R8WTF5Y+WYutMH46icLuuo1XzcxiaFRixV9AxDOu5 pMhg== MIME-Version: 1.0 X-Received: by 10.140.22.209 with SMTP id 75mr43396501qgn.4.1399308929590; Mon, 05 May 2014 09:55:29 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.191.201 with HTTP; Mon, 5 May 2014 09:55:29 -0700 (PDT) In-Reply-To: <201405051109.39345.jhb@freebsd.org> References: <201405051109.39345.jhb@freebsd.org> Date: Mon, 5 May 2014 09:55:29 -0700 X-Google-Sender-Auth: qVhb-qF-sZLD18ukIF6f5h4v3NQ Message-ID: Subject: Re: proposal: set default lid state to S3, performance/economy Cx states to Cmax From: Adrian Chadd To: John Baldwin Content-Type: text/plain; charset=UTF-8 Cc: Kevin Oberman , "freebsd-acpi@freebsd.org" , "freebsd-arch@freebsd.org" X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2014 16:55:31 -0000 On 5 May 2014 08:09, John Baldwin wrote: > On Sunday, May 04, 2014 4:27:38 am Adrian Chadd wrote: >> Hi, >> >> I'd like to propose flipping a few things: >> >> * Flipping the default lid state to S3. I think ACPI suspend/resume >> seems to work well enough these days and I've not met anyone lately >> who expects the default from their laptop to be "stay awake with the >> lid shut." >> * Save chip bugs that we should add workarounds for, we should be OK >> to enter lower sleep states when idling. Flipping this may expose some >> further crazy driver, platform or timer bugs, but they again likely >> should be fixed. >> >> what do people think? > > I think the lid switch thing is premature. Even on my X220 I use a devd > hook to enable it only when i915drm is loaded as resume doesn't work until > that is done. > > I think the Cmax thing OTOH is probably more appropriate. We have several > things place that should "mostly" DTRT for picking the correct timers to > use. The one case I know of recently were some somewhat older systems where > the HPET wasn't reliable, but the system chose to use HPET instead of LAPIC > becuase the LAPIC was known to stop during C1E, etc. In this case the user > just stuck with plain old C1 and forced the LAPIC timer which worked fine. > However, it is hard to identify those cases. On modern systems I would > expect the LAPIC to work just fine, so this problem will become less and > less important as time goes on. right. I'd rather we start finding more of these sooner rather than later. :-) -a From owner-freebsd-acpi@FreeBSD.ORG Mon May 5 17:37:09 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 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 31403245; Mon, 5 May 2014 17:37:09 +0000 (UTC) Received: from mail-qa0-x230.google.com (mail-qa0-x230.google.com [IPv6:2607:f8b0:400d:c00::230]) (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 DA4F895F; Mon, 5 May 2014 17:37:08 +0000 (UTC) Received: by mail-qa0-f48.google.com with SMTP id i13so2712659qae.35 for ; Mon, 05 May 2014 10:37:08 -0700 (PDT) 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=ZGk7i0ex0bN2aE1VvyvjFYjjUs26+n25SuIS0VPhcHQ=; b=ulkxq62xxg3QJY6BIPo1qbvf+kF36VvZpBgAuxDqoH09Tll7UaC6dfbU2NqBBJ+1rt GKwYytJy96kb5l0V6XiA4XE6JBF3p5pPl5ac1ctSPayn9csraCjAy3E+klp4WzKBDUQm 97M8y3rZPi+VdYzRb+4wnL4D4oUcGHpriSx5o/6q0qv6x9TptXZMqBiUdQzo5vclVFNW AjjqWD5rgUwWl/0oBqc2uy49AIcgw/yoJv37/D37/HT7psRopnbvfWnuNpZR1PzeHm03 sFX3iG6u01mR+i2WSGfRXCFRD8Ij3661RxDi/5tTercKkMnsrMSBk0RrcZfCPGWYUL40 QYEg== MIME-Version: 1.0 X-Received: by 10.140.22.209 with SMTP id 75mr43735355qgn.4.1399311428017; Mon, 05 May 2014 10:37:08 -0700 (PDT) Received: by 10.224.191.201 with HTTP; Mon, 5 May 2014 10:37:07 -0700 (PDT) Date: Mon, 5 May 2014 10:37:07 -0700 Message-ID: Subject: suspend issues with latest -HEAD, ahci failing to complete something? From: Adrian Chadd To: "freebsd-acpi@freebsd.org" , Alexander Motin Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2014 17:37:09 -0000 Hiya, (I know, I just emailed out asking about setting S3 for the default lid suspend state, however I just updated to the very latest head and things went a little backwards.) Suspend no longer works for me: May 5 10:33:10 lucy-11i386 acpi: suspend at 20140505 10:33:10 May 5 10:33:47 lucy-11i386 kernel: ahcich0: Timeout on slot 19 port 0 May 5 10:33:47 lucy-11i386 kernel: ahcich0: is 00000000 cs fff80fff ss fff80fff rs fff80fff tfd d0 serr 00000000 cmd 0000d317 May 5 10:33:47 lucy-11i386 kernel: (ada0:ahcich0:0:0:0): WRITE_FPDMA_QUEUED. ACB: 61 08 e0 b0 fa 40 42 00 00 00 00 00 May 5 10:33:47 lucy-11i386 kernel: (ada0:ahcich0:0:0:0): CAM status: Command timeout May 5 10:33:47 lucy-11i386 kernel: (ada0:ahcich0:0:0:0): Retrying command May 5 10:33:13 lucy-11i386 acpi: resumed at 20140505 10:33:13 May 5 10:33:59 lucy-11i386 acpi: suspend at 20140505 10:33:59 May 5 10:34:37 lucy-11i386 kernel: ahcich0: Timeout on slot 9 port 0 May 5 10:34:37 lucy-11i386 kernel: ahcich0: is 00000000 cs ffffff83 ss ffffff83 rs ffffff83 tfd d0 serr 00000000 cmd 0000c717 May 5 10:34:37 lucy-11i386 kernel: (ada0:ahcich0:0:0:0): WRITE_FPDMA_QUEUED. ACB: 61 08 18 5c f7 40 42 00 00 00 00 00 May 5 10:34:37 lucy-11i386 kernel: (ada0:ahcich0:0:0:0): CAM status: Command timeout May 5 10:34:37 lucy-11i386 kernel: (ada0:ahcich0:0:0:0): Retrying command May 5 10:34:03 lucy-11i386 acpi: resumed at 20140505 10:34:03 What has recently changed that'd possibly break ahci's ability to correctly suspend? Thanks, -adrian From owner-freebsd-acpi@FreeBSD.ORG Mon May 5 19:51:32 2014 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0DEEF956 for ; Mon, 5 May 2014 19:51:32 +0000 (UTC) Received: from mail-ee0-x235.google.com (mail-ee0-x235.google.com [IPv6:2a00:1450:4013:c00::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 979C15FBF for ; Mon, 5 May 2014 19:51:31 +0000 (UTC) Received: by mail-ee0-f53.google.com with SMTP id c13so16932eek.12 for ; Mon, 05 May 2014 12:51:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=EjVi0+xPT524IJNBhmwEohRNWDjqi7XbxfbG5SLhy4U=; b=fPs2HB9DWhYqzNaxcwzPDkO1HIoYKmPzoAIU4X+opWIjC7J+wkdnvIq2AqH39zMUam Akzs/ZoMglUAaobMJs+ukEyBI4EbOsw9FKH76TTGlL7fkLGSe8Vvlu7ww+OC1wETV/p0 QxNYt7QgQ4ipmllbztmq4J9gUviShtJ6qyNXmjSrwF8Js5WaySKCb9iytkqYqOY33D3e ROTC4uTKkQhQbk7mkrq+iT+xF8OgIuOQKKR81QhCKZqHxGep9F13zw6/T/mOzhjOH3IW SeqZN11bCCG0mAHzk5BPURpvqME8GsqVzzfVN4n+rNrO7DkbkNUkYIZ13zvdW4BOloaG 5M4g== X-Received: by 10.15.45.130 with SMTP id b2mr34533862eew.28.1399319489917; Mon, 05 May 2014 12:51:29 -0700 (PDT) Received: from mavbook.mavhome.dp.ua ([134.249.139.101]) by mx.google.com with ESMTPSA id a42sm32217834ees.10.2014.05.05.12.51.28 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 05 May 2014 12:51:29 -0700 (PDT) Sender: Alexander Motin Message-ID: <5367EBBE.2020602@FreeBSD.org> Date: Mon, 05 May 2014 22:51:26 +0300 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Adrian Chadd , "freebsd-acpi@freebsd.org" Subject: Re: suspend issues with latest -HEAD, ahci failing to complete something? References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2014 19:51:32 -0000 On 05.05.2014 20:37, Adrian Chadd wrote: > (I know, I just emailed out asking about setting S3 for the default > lid suspend state, however I just updated to the very latest head and > things went a little backwards.) > > Suspend no longer works for me: > > May 5 10:33:10 lucy-11i386 acpi: suspend at 20140505 10:33:10 > May 5 10:33:47 lucy-11i386 kernel: ahcich0: Timeout on slot 19 port 0 > May 5 10:33:47 lucy-11i386 kernel: ahcich0: is 00000000 cs fff80fff > ss fff80fff rs fff80fff tfd d0 serr 00000000 cmd 0000d317 > May 5 10:33:47 lucy-11i386 kernel: (ada0:ahcich0:0:0:0): > WRITE_FPDMA_QUEUED. ACB: 61 08 e0 b0 fa 40 42 00 00 00 00 00 > May 5 10:33:47 lucy-11i386 kernel: (ada0:ahcich0:0:0:0): CAM status: > Command timeout > May 5 10:33:47 lucy-11i386 kernel: (ada0:ahcich0:0:0:0): Retrying command > May 5 10:33:13 lucy-11i386 acpi: resumed at 20140505 10:33:13 > > May 5 10:33:59 lucy-11i386 acpi: suspend at 20140505 10:33:59 > May 5 10:34:37 lucy-11i386 kernel: ahcich0: Timeout on slot 9 port 0 > May 5 10:34:37 lucy-11i386 kernel: ahcich0: is 00000000 cs ffffff83 > ss ffffff83 rs ffffff83 tfd d0 serr 00000000 cmd 0000c717 > May 5 10:34:37 lucy-11i386 kernel: (ada0:ahcich0:0:0:0): > WRITE_FPDMA_QUEUED. ACB: 61 08 18 5c f7 40 42 00 00 00 00 00 > May 5 10:34:37 lucy-11i386 kernel: (ada0:ahcich0:0:0:0): CAM status: > Command timeout > May 5 10:34:37 lucy-11i386 kernel: (ada0:ahcich0:0:0:0): Retrying command > May 5 10:34:03 lucy-11i386 acpi: resumed at 20140505 10:34:03 > > What has recently changed that'd possibly break ahci's ability to > correctly suspend? When I tested it last time (awhile ago), it was working for me. ahci_ch_suspend() should block all I/O on the channel and wait until all active commands complete. On resume channel should be reinitialized, device reset and only then I/Os should be released. Do you see those timeouts on suspend or resume? Do you have kern.cam.ada.spindown_suspend enabled? Can you try to disable it? -- Alexander Motin From owner-freebsd-acpi@FreeBSD.ORG Mon May 5 19:55: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 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 954E0B11; Mon, 5 May 2014 19:55:32 +0000 (UTC) Received: from mail-qa0-x230.google.com (mail-qa0-x230.google.com [IPv6:2607:f8b0:400d:c00::230]) (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 47FBCBB; Mon, 5 May 2014 19:55:32 +0000 (UTC) Received: by mail-qa0-f48.google.com with SMTP id i13so2901811qae.35 for ; Mon, 05 May 2014 12:55:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Z5IY+HlZ3PmTBaYceXcE/qNUIOQUkZ4jK/APrJNbIJM=; b=KvCF9hrE1Pe96dXvIkUy63hJcQwqTEFVIvIMNbXCoRVZCLyEnxDlisV30g4+BQeWZA G2AHo8D6Od8z1aTwItAvPdM55Gu3zOy6fhnVW7NJMTs+Kh+L7RucK0bmtr48B+e5VagC HD6gdtlg7Q6EOfxc1OwgLiaalAidKPdJoIWGxBfCqUq5oWRxjGuAP+AGOSkAFfM6z0vK oK6ZTPCwcDA9dnemwYYGzc655NcIB9WNnPDPxPKSB3aUW2UDdpiauK+WB3ukHiW+RA1f USWx2HpWXjunbirLWy/3akeATZSVIu8YVlVJpxvXHN7UIlE+r4tMLSwNocm3UZlerqbZ f/IQ== MIME-Version: 1.0 X-Received: by 10.140.22.209 with SMTP id 75mr44839242qgn.4.1399319731448; Mon, 05 May 2014 12:55:31 -0700 (PDT) Received: by 10.224.191.201 with HTTP; Mon, 5 May 2014 12:55:31 -0700 (PDT) In-Reply-To: <5367EBBE.2020602@FreeBSD.org> References: <5367EBBE.2020602@FreeBSD.org> Date: Mon, 5 May 2014 12:55:31 -0700 Message-ID: Subject: Re: suspend issues with latest -HEAD, ahci failing to complete something? From: Adrian Chadd To: Alexander Motin Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-acpi@freebsd.org" X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2014 19:55:32 -0000 Hi, Would you mind testing the latest -HEAD out? It worked a couple weeks ago with my last rebuild on this particular laptop. -a On 5 May 2014 12:51, Alexander Motin wrote: > On 05.05.2014 20:37, Adrian Chadd wrote: >> >> (I know, I just emailed out asking about setting S3 for the default >> lid suspend state, however I just updated to the very latest head and >> things went a little backwards.) >> >> Suspend no longer works for me: >> >> May 5 10:33:10 lucy-11i386 acpi: suspend at 20140505 10:33:10 >> May 5 10:33:47 lucy-11i386 kernel: ahcich0: Timeout on slot 19 port 0 >> May 5 10:33:47 lucy-11i386 kernel: ahcich0: is 00000000 cs fff80fff >> ss fff80fff rs fff80fff tfd d0 serr 00000000 cmd 0000d317 >> May 5 10:33:47 lucy-11i386 kernel: (ada0:ahcich0:0:0:0): >> WRITE_FPDMA_QUEUED. ACB: 61 08 e0 b0 fa 40 42 00 00 00 00 00 >> May 5 10:33:47 lucy-11i386 kernel: (ada0:ahcich0:0:0:0): CAM status: >> Command timeout >> May 5 10:33:47 lucy-11i386 kernel: (ada0:ahcich0:0:0:0): Retrying command >> May 5 10:33:13 lucy-11i386 acpi: resumed at 20140505 10:33:13 >> >> May 5 10:33:59 lucy-11i386 acpi: suspend at 20140505 10:33:59 >> May 5 10:34:37 lucy-11i386 kernel: ahcich0: Timeout on slot 9 port 0 >> May 5 10:34:37 lucy-11i386 kernel: ahcich0: is 00000000 cs ffffff83 >> ss ffffff83 rs ffffff83 tfd d0 serr 00000000 cmd 0000c717 >> May 5 10:34:37 lucy-11i386 kernel: (ada0:ahcich0:0:0:0): >> WRITE_FPDMA_QUEUED. ACB: 61 08 18 5c f7 40 42 00 00 00 00 00 >> May 5 10:34:37 lucy-11i386 kernel: (ada0:ahcich0:0:0:0): CAM status: >> Command timeout >> May 5 10:34:37 lucy-11i386 kernel: (ada0:ahcich0:0:0:0): Retrying command >> May 5 10:34:03 lucy-11i386 acpi: resumed at 20140505 10:34:03 >> >> What has recently changed that'd possibly break ahci's ability to >> correctly suspend? > > > When I tested it last time (awhile ago), it was working for me. > ahci_ch_suspend() should block all I/O on the channel and wait until all > active commands complete. On resume channel should be reinitialized, device > reset and only then I/Os should be released. Do you see those timeouts on > suspend or resume? > > Do you have kern.cam.ada.spindown_suspend enabled? Can you try to disable > it? > > -- > Alexander Motin From owner-freebsd-acpi@FreeBSD.ORG Mon May 5 21:26:07 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 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A5830581; Mon, 5 May 2014 21:26:07 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7AFE08A3; Mon, 5 May 2014 21:26:07 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 6EAA2B968; Mon, 5 May 2014 17:26:05 -0400 (EDT) From: John Baldwin To: Adrian Chadd Subject: Re: proposal: set default lid state to S3, performance/economy Cx states to Cmax Date: Mon, 5 May 2014 16:57:49 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20140415; KDE/4.5.5; amd64; ; ) References: <201405051109.39345.jhb@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201405051657.49992.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 05 May 2014 17:26:05 -0400 (EDT) Cc: Kevin Oberman , "freebsd-acpi@freebsd.org" , "freebsd-arch@freebsd.org" X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2014 21:26:07 -0000 On Monday, May 05, 2014 12:55:29 pm Adrian Chadd wrote: > On 5 May 2014 08:09, John Baldwin wrote: > > On Sunday, May 04, 2014 4:27:38 am Adrian Chadd wrote: > >> Hi, > >> > >> I'd like to propose flipping a few things: > >> > >> * Flipping the default lid state to S3. I think ACPI suspend/resume > >> seems to work well enough these days and I've not met anyone lately > >> who expects the default from their laptop to be "stay awake with the > >> lid shut." > >> * Save chip bugs that we should add workarounds for, we should be OK > >> to enter lower sleep states when idling. Flipping this may expose some > >> further crazy driver, platform or timer bugs, but they again likely > >> should be fixed. > >> > >> what do people think? > > > > I think the lid switch thing is premature. Even on my X220 I use a devd > > hook to enable it only when i915drm is loaded as resume doesn't work until > > that is done. > > > > I think the Cmax thing OTOH is probably more appropriate. We have several > > things place that should "mostly" DTRT for picking the correct timers to > > use. The one case I know of recently were some somewhat older systems where > > the HPET wasn't reliable, but the system chose to use HPET instead of LAPIC > > becuase the LAPIC was known to stop during C1E, etc. In this case the user > > just stuck with plain old C1 and forced the LAPIC timer which worked fine. > > However, it is hard to identify those cases. On modern systems I would > > expect the LAPIC to work just fine, so this problem will become less and > > less important as time goes on. > > right. I'd rather we start finding more of these sooner rather than later. :-) The user in question found this on 9-stable with the existing defaults as the HPET was just plain broken on their system and that was unrelated to Cx states. (Rather, Cx states were only involved because worries about them are why the system chose to use HPET. Had Cx states been enabled by default, they would have had to disable those as well in addition to forcing LAPIC instead of HPET.) -- John Baldwin From owner-freebsd-acpi@FreeBSD.ORG Tue May 6 18:08:36 2014 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EBCFE3BA; Tue, 6 May 2014 18:08:36 +0000 (UTC) Received: from mail-qc0-x236.google.com (mail-qc0-x236.google.com [IPv6:2607:f8b0:400d:c01::236]) (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 89CCE85; Tue, 6 May 2014 18:08:36 +0000 (UTC) Received: by mail-qc0-f182.google.com with SMTP id e16so7198524qcx.41 for ; Tue, 06 May 2014 11:08: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:message-id:subject :from:to:cc:content-type; bh=Ty3zJIZSWYLoxXq1SY1j4Sx2I0t57arOSXQn+vIOM4E=; b=GI1ifn8V0eqj/RHv0UxfJ4TjwONiO9kc2X7N+Y21iZ0zu/h4O2WPe3lbJQKu/pxag6 Deu35B2kDv+iAGJYqswxSsEP0tHocPC85PeNNjjob6+yBCAeCSM+vApJUhQZnvpd1e9n pa5mvmN+YrdK9zuqNKFFCgOOfVWbQllz10nFZlbdZI1Koc3N3mkfs28IV6ELl8paAoX/ UxUwJ1ivvJJZCpj5oXVhv09kNl7V1gcO1BEDYiF95jthO21cTl6STphOb9o3FZ9tXm31 BKdIJhyLCLOcf19QZeAjo1dxAjdkWUtKD6PWkcF+OrLKYxMw8sxdzSqG8q9zdUY+r4PU /Uhg== MIME-Version: 1.0 X-Received: by 10.224.47.130 with SMTP id n2mr58210442qaf.26.1399399715673; Tue, 06 May 2014 11:08:35 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.191.201 with HTTP; Tue, 6 May 2014 11:08:35 -0700 (PDT) In-Reply-To: <201405051657.49992.jhb@freebsd.org> References: <201405051109.39345.jhb@freebsd.org> <201405051657.49992.jhb@freebsd.org> Date: Tue, 6 May 2014 11:08:35 -0700 X-Google-Sender-Auth: gbhK2GqiysVLFEWdIbvq4S9Skxg Message-ID: Subject: Re: proposal: set default lid state to S3, performance/economy Cx states to Cmax From: Adrian Chadd To: John Baldwin Content-Type: text/plain; charset=UTF-8 Cc: Kevin Oberman , "freebsd-acpi@freebsd.org" , "freebsd-arch@freebsd.org" X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 May 2014 18:08:37 -0000 On 5 May 2014 13:57, John Baldwin wrote: > The user in question found this on 9-stable with the existing defaults as the > HPET was just plain broken on their system and that was unrelated to Cx states. > (Rather, Cx states were only involved because worries about them are why the > system chose to use HPET. Had Cx states been enabled by default, they would > have had to disable those as well in addition to forcing LAPIC instead of > HPET.) Hm. Sounds uncomfortable. How does Windows run on systems like this? Do the windows drivers just disable HPET and use LAPIC or worse for timing, and just ignore anything lower than C1? I'm going to flip the switch to enable Cmax on defaults/rc.conf on -HEAD today. -a From owner-freebsd-acpi@FreeBSD.ORG Tue May 6 20:56:37 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 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4C6DAF93; Tue, 6 May 2014 20:56:37 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2408927D; Tue, 6 May 2014 20:56:37 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 6E0DCB941; Tue, 6 May 2014 16:56:35 -0400 (EDT) From: John Baldwin To: freebsd-acpi@freebsd.org Subject: Re: suspend issues with latest -HEAD, ahci failing to complete something? Date: Tue, 6 May 2014 15:40:20 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20140415; KDE/4.5.5; amd64; ; ) References: <5367EBBE.2020602@FreeBSD.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201405061540.20265.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 06 May 2014 16:56:35 -0400 (EDT) Cc: Adrian Chadd , Alexander Motin X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 May 2014 20:56:37 -0000 On Monday, May 05, 2014 3:55:31 pm Adrian Chadd wrote: > Hi, > > Would you mind testing the latest -HEAD out? It worked a couple weeks > ago with my last rebuild on this particular laptop. My x220 resumes just fine with yesterday's HEAD from S3. Uses ahci: ahci0: port 0x50a8-0x50af,0x50bc-0x50bf,0x50a0-0x50a7,0x50b8-0x50bb,0x5060-0x507f mem 0xd2528000-0xd25287ff irq 19 at device 31.2 on pci0 ahci0: AHCI v1.30 with 6 6Gbps ports, Port Multiplier not supported ahcich0: at channel 0 on ahci0 ahcich1: at channel 1 on ahci0 ahcich4: at channel 4 on ahci0 ahciem0: on ahci0 ... ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 ada0: ATA-8 SATA 2.x device ada0: Serial Number W0Q06E4A ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada0: Command Queueing enabled ada0: 305245MB (625142448 512 byte sectors: 1H 63S/T 16383C) ada0: quirks=0x1<4K> ada0: Previously was known as ad4 ses0 at ahciem0 bus 0 scbus3 target 0 lun 0 ses0: SEMB S-E-S 2.00 device ses0: SEMB SES Device -- John Baldwin From owner-freebsd-acpi@FreeBSD.ORG Tue May 6 20:56:41 2014 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 820AEFE4; Tue, 6 May 2014 20:56:41 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 57CBA286; Tue, 6 May 2014 20:56:41 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 437B6B9CB; Tue, 6 May 2014 16:56:40 -0400 (EDT) From: John Baldwin To: Adrian Chadd Subject: Re: proposal: set default lid state to S3, performance/economy Cx states to Cmax Date: Tue, 6 May 2014 16:37:29 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20140415; KDE/4.5.5; amd64; ; ) References: <201405051657.49992.jhb@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201405061637.30037.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 06 May 2014 16:56:40 -0400 (EDT) Cc: Kevin Oberman , "freebsd-acpi@freebsd.org" , "freebsd-arch@freebsd.org" X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 May 2014 20:56:41 -0000 On Tuesday, May 06, 2014 2:08:35 pm Adrian Chadd wrote: > On 5 May 2014 13:57, John Baldwin wrote: > > > The user in question found this on 9-stable with the existing defaults as the > > HPET was just plain broken on their system and that was unrelated to Cx states. > > (Rather, Cx states were only involved because worries about them are why the > > system chose to use HPET. Had Cx states been enabled by default, they would > > have had to disable those as well in addition to forcing LAPIC instead of > > HPET.) > > Hm. Sounds uncomfortable. How does Windows run on systems like this? > Do the windows drivers just disable HPET and use LAPIC or worse for > timing, and just ignore anything lower than C1? I have no idea. Maybe they use the RTC. :-/ Maybe the HPET on these systems works if you use it "sparingly". I believe OS X might have only used the HPET to provide the "missing" LAPIC wakeups when entering Cx for example. (Our current eventtimer system wants to always use whichever timer it picks, not switch off between them.) -- John Baldwin From owner-freebsd-acpi@FreeBSD.ORG Tue May 6 22:15:51 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 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C9A79D3; Tue, 6 May 2014 22:15:51 +0000 (UTC) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) (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 9C33EB99; Tue, 6 May 2014 22:15:50 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1WhneP-000KW2-7n; Tue, 06 May 2014 22:15:49 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id s46MFkFj026622; Tue, 6 May 2014 16:15:46 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+8kRswA9DWBxTt4D8kCWJI Subject: Re: proposal: set default lid state to S3, performance/economy Cx states to Cmax From: Ian Lepore To: John Baldwin In-Reply-To: <201405061637.30037.jhb@freebsd.org> References: <201405051657.49992.jhb@freebsd.org> <201405061637.30037.jhb@freebsd.org> Content-Type: text/plain; charset="us-ascii" Date: Tue, 06 May 2014 16:15:46 -0600 Message-ID: <1399414546.22079.286.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: Kevin Oberman , "freebsd-acpi@freebsd.org" , "freebsd-arch@freebsd.org" X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 May 2014 22:15:51 -0000 On Tue, 2014-05-06 at 16:37 -0400, John Baldwin wrote: > On Tuesday, May 06, 2014 2:08:35 pm Adrian Chadd wrote: > > On 5 May 2014 13:57, John Baldwin wrote: > > > > > The user in question found this on 9-stable with the existing defaults as the > > > HPET was just plain broken on their system and that was unrelated to Cx states. > > > (Rather, Cx states were only involved because worries about them are why the > > > system chose to use HPET. Had Cx states been enabled by default, they would > > > have had to disable those as well in addition to forcing LAPIC instead of > > > HPET.) > > > > Hm. Sounds uncomfortable. How does Windows run on systems like this? > > Do the windows drivers just disable HPET and use LAPIC or worse for > > timing, and just ignore anything lower than C1? > > I have no idea. Maybe they use the RTC. :-/ Maybe the HPET on these systems > works if you use it "sparingly". I believe OS X might have only used the HPET > to provide the "missing" LAPIC wakeups when entering Cx for example. (Our current > eventtimer system wants to always use whichever timer it picks, not switch off > between them.) > The eventtimer code is happy to switch between timers on the fly, but iirc the only interface to that feature is sysctl. I found it fairly easy to add an in-kernel API for changing the frequency of the current timer on the fly. I think it would be just as easy to add a kernel call to change timers as well. -- Ian From owner-freebsd-acpi@FreeBSD.ORG Tue May 6 23:12:30 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 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 095349EC for ; Tue, 6 May 2014 23:12:30 +0000 (UTC) Received: from mail-qa0-x236.google.com (mail-qa0-x236.google.com [IPv6:2607:f8b0:400d:c00::236]) (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 BF2DAFE9 for ; Tue, 6 May 2014 23:12:29 +0000 (UTC) Received: by mail-qa0-f54.google.com with SMTP id j15so190879qaq.41 for ; Tue, 06 May 2014 16:12:29 -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:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=sAWWZ3/J7fjrH0im09o6C5bTQQ7Vx3kc4H4emr3Hxcw=; b=AUvGl7EFQOvxu657LYGJMpkxK2PfIySbHfrFxBobV8Hoe9n/827nttVzf6YZpaVhOH u8CR9SRsSaXlGJxyqqP/DZWaKu0qjjsVyoaHeyBTT8vFCK666xEflCV3rdfvoAk+JRui amjyoOl2dSDYL1bY4eT4Mr4MVycmK9tir5q6vTPrx6JSKoAt4i7Y0yhiUhJ3XZoMf9X+ jnpu+RpC+a1xWiULjuyx0evRdXbx44g19y9Uo+o93BxqwWOWj1q+GetDyg5psovOujT/ NR4xLIsWvn4DbHc1ojfBiRUJBNdvt1CCs0sxl0XFsdtuBrecvM5Lf1k5zpGeYra/Iu/c 3m3g== MIME-Version: 1.0 X-Received: by 10.229.17.69 with SMTP id r5mr58396233qca.7.1399417948937; Tue, 06 May 2014 16:12:28 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.191.201 with HTTP; Tue, 6 May 2014 16:12:28 -0700 (PDT) In-Reply-To: <20140501205706.GA6007@coyotlan.Tlalpan> References: <20140501205706.GA6007@coyotlan.Tlalpan> Date: Tue, 6 May 2014 16:12:28 -0700 X-Google-Sender-Auth: pGmO6MRGSwsd7XAKIPBBv-1f3gA Message-ID: Subject: Re: Emitting keyboard events From: Adrian Chadd To: =?UTF-8?B?WMSrY8Oy?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "freebsd-acpi@freebsd.org" X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 May 2014 23:12:30 -0000 Just to follow up - I'd love to know how the hell to do this too. acpi_ibm needs some updating. :( -a On 1 May 2014 13:57, X=C4=ABc=C3=B2 wrote: > Dear freebsd-acpi, > > Being a systemd refugee, I am trying to setup FreeBSD on several > machines here. As a first question, I cannot find any driver to handle > the hotkeys on a 2011 Sony VPCZ2. sys/dev/acpi_support/acpi_sony.c only > contains backlight support for old laptops. Is anyone aware of such a > driver? > > In any case, I started playing a bit with ACPI in a module, and have > been able to register a handler for the hotkeys, and decode the > associated events. Unfortunately, I have no idead of what I could do > with them. At some point, I would like Xorg to receive keyboard events, > such as XF86MonBrightnessUp, but I lack the knowledge on how to emit > that from kernel space. > > Thank you for your help! > > Best, > > -- > X=C4=ABc=C3=B2 > _______________________________________________ > freebsd-acpi@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-acpi > To unsubscribe, send any mail to "freebsd-acpi-unsubscribe@freebsd.org" From owner-freebsd-acpi@FreeBSD.ORG Wed May 7 13:51:21 2014 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 255822D8; Wed, 7 May 2014 13:51:21 +0000 (UTC) Received: from mail.0x20.net (mail.0x20.net [IPv6:2001:aa8:fffb:1::3]) (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 D7E58B5A; Wed, 7 May 2014 13:51:20 +0000 (UTC) Received: from e-new.0x20.net (mail.0x20.net [IPv6:2001:aa8:fffb:1::3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.0x20.net (Postfix) with ESMTPS id 4DECF6A600D; Wed, 7 May 2014 15:51:18 +0200 (CEST) Received: from e-new.0x20.net (localhost [127.0.0.1]) by e-new.0x20.net (8.14.7/8.14.7) with ESMTP id s47DpI7n094353; Wed, 7 May 2014 15:51:18 +0200 (CEST) (envelope-from lars@e-new.0x20.net) Received: (from lars@localhost) by e-new.0x20.net (8.14.7/8.14.7/Submit) id s47DpHZk093622; Wed, 7 May 2014 15:51:17 +0200 (CEST) (envelope-from lars) Date: Wed, 7 May 2014 15:51:17 +0200 From: Lars Engels To: Adrian Chadd Subject: Re: Emitting keyboard events Message-ID: <20140507135117.GL1451@e-new.0x20.net> References: <20140501205706.GA6007@coyotlan.Tlalpan> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: X-Editor: VIM - Vi IMproved 7.4 X-Operation-System: FreeBSD 8.4-RELEASE-p4 User-Agent: Mutt/1.5.23 (2014-03-12) Cc: rpaulo@freebsd.org, "freebsd-acpi@freebsd.org" X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 May 2014 13:51:21 -0000 On Tue, May 06, 2014 at 04:12:28PM -0700, Adrian Chadd wrote: > Just to follow up - I'd love to know how the hell to do this too. > acpi_ibm needs some updating. :( >=20 >=20 > -a >=20 >=20 > On 1 May 2014 13:57, X=C4=ABc=C3=B2 wrote: > > Dear freebsd-acpi, > > > > Being a systemd refugee, I am trying to setup FreeBSD on several > > machines here. As a first question, I cannot find any driver to handle > > the hotkeys on a 2011 Sony VPCZ2. sys/dev/acpi_support/acpi_sony.c only > > contains backlight support for old laptops. Is anyone aware of such a > > driver? > > > > In any case, I started playing a bit with ACPI in a module, and have > > been able to register a handler for the hotkeys, and decode the > > associated events. Unfortunately, I have no idead of what I could do > > with them. At some point, I would like Xorg to receive keyboard events, > > such as XF86MonBrightnessUp, but I lack the knowledge on how to emit > > that from kernel space. > > > > Thank you for your help! > > > > Best, > > IIRC Rui (CC'ed) did some work on implementing new ACPI key events in acpi_asus for the first EeePC. From owner-freebsd-acpi@FreeBSD.ORG Wed May 7 15:49:15 2014 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6A95A960; Wed, 7 May 2014 15:49:15 +0000 (UTC) Received: from mail.atelo.org (atelo.org [192.95.27.91]) (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 03BD3985; Wed, 7 May 2014 15:49:14 +0000 (UTC) Received: from coyotlan.Tlalpan (ovo.atelo.org [192.168.1.7]); by mail.atelo.org (OpenSMTPD) with ESMTP id 9485b100; Wed, 7 May 2014 15:48:35 +0000 (UTC) Received: from localhost (1001@localhost [local]); by localhost (OpenSMTPD) with ESMTPA id 9d2e5814; Wed, 7 May 2014 08:48:55 -0700 (PDT) Date: Wed, 7 May 2014 08:46:07 -0700 From: =?utf-8?B?WMSrY8Oy?= To: Lars Engels Subject: Re: Emitting keyboard events Message-ID: <20140507154607.GA1826@coyotlan.Tlalpan> References: <20140501205706.GA6007@coyotlan.Tlalpan> <20140507135117.GL1451@e-new.0x20.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140507135117.GL1451@e-new.0x20.net> User-Agent: Mutt/1.5.23 (2014-03-12) Cc: rpaulo@freebsd.org, "freebsd-acpi@freebsd.org" X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 May 2014 15:49:15 -0000 On Wed, May 07, 2014 at 03:51:17PM +0200, Lars Engels wrote: > IIRC Rui (CC'ed) did some work on implementing new ACPI key events in > acpi_asus for the first EeePC. Looking around the acpi drivers, some hard-encode actions associated to the events (like brightness control), some emit messages for devd (like sound control for the asus), and most mix the two options. Emitting devd events is both easy and highly user configurable. But it still does not solve the problem of reinjecting the special keys as generic keyboard events, for instance to let the user configure them through xorg. Writing a virtual keyboard in each acpi driver seems a lot of duplication, and maybe too heavy. IMHO acpi drivers should just emit information to be caught by devd. Maybe with a single format, so that a shared other component can listen to them and reinject them as generic keyboard events. From owner-freebsd-acpi@FreeBSD.ORG Wed May 7 15:52:31 2014 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3953AA4A; Wed, 7 May 2014 15:52:31 +0000 (UTC) Received: from mail-qc0-x230.google.com (mail-qc0-x230.google.com [IPv6:2607:f8b0:400d:c01::230]) (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 DCE3BA2D; Wed, 7 May 2014 15:52:30 +0000 (UTC) Received: by mail-qc0-f176.google.com with SMTP id r5so1332118qcx.35 for ; Wed, 07 May 2014 08:52:30 -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:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=7Tixe5xQrJ1sEYKNQxq2IVMEDnEvxOhEpkFOpddj9ww=; b=tfULHnGCtK3lFk34JesfOKVwbJLvhY6GOqHtwaYUYoLInh3MQslidfybI+AUlCjQqY T+1tOEyPHyUhQGzl71lYRKYQ5maEp+vwZdADUTgR4mEk4Y4SmojQmyrtS13ujEdl3Do6 Tf5PdadqUIg01Pab6GzOzC3PMZJKeNkRHeeIS5lNPyNlzyRYTu8jacS0e+KsfdecOXfz OfqvuY+k7EiG7jjyofRrnwaQ57yDU45s8DrZROcQbjnhmCuOAX1zaXX0NKVmRM/HGWsX 6dB8Dntk/8nxFYWy6NZv/xzydpE2Rd63+f/mgfbHeuakF0+behhp7bzaNnq8BfL4Fjku yDAA== MIME-Version: 1.0 X-Received: by 10.224.16.199 with SMTP id p7mr30875727qaa.76.1399477950061; Wed, 07 May 2014 08:52:30 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.191.201 with HTTP; Wed, 7 May 2014 08:52:30 -0700 (PDT) In-Reply-To: <20140507154607.GA1826@coyotlan.Tlalpan> References: <20140501205706.GA6007@coyotlan.Tlalpan> <20140507135117.GL1451@e-new.0x20.net> <20140507154607.GA1826@coyotlan.Tlalpan> Date: Wed, 7 May 2014 08:52:30 -0700 X-Google-Sender-Auth: 1X_ki_D5tAWjNAFTGC5_NwlrZRU Message-ID: Subject: Re: Emitting keyboard events From: Adrian Chadd To: =?UTF-8?B?WMSrY8Oy?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "freebsd-acpi@freebsd.org" , Rui Paulo X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 May 2014 15:52:31 -0000 On 7 May 2014 08:46, X=C4=ABc=C3=B2 wrote: > On Wed, May 07, 2014 at 03:51:17PM +0200, Lars Engels wrote: >> IIRC Rui (CC'ed) did some work on implementing new ACPI key events in >> acpi_asus for the first EeePC. > > Looking around the acpi drivers, some hard-encode actions associated to > the events (like brightness control), some emit messages for devd (like > sound control for the asus), and most mix the two options. > > Emitting devd events is both easy and highly user configurable. But it > still does not solve the problem of reinjecting the special keys as > generic keyboard events, for instance to let the user configure them > through xorg. Writing a virtual keyboard in each acpi driver seems a lot > of duplication, and maybe too heavy. IMHO acpi drivers should just emit > information to be caught by devd. Maybe with a single format, so that a > shared other component can listen to them and reinject them as generic > keyboard events. Indeed. Hack it up, send through patches. :) -a From owner-freebsd-acpi@FreeBSD.ORG Wed May 7 18:34:41 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 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3E540EB0; Wed, 7 May 2014 18:34:41 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 14388C9E; Wed, 7 May 2014 18:34:41 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id EE815B964; Wed, 7 May 2014 14:34:39 -0400 (EDT) From: John Baldwin To: Ian Lepore Subject: Re: proposal: set default lid state to S3, performance/economy Cx states to Cmax Date: Wed, 7 May 2014 12:26:34 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20140415; KDE/4.5.5; amd64; ; ) References: <201405061637.30037.jhb@freebsd.org> <1399414546.22079.286.camel@revolution.hippie.lan> In-Reply-To: <1399414546.22079.286.camel@revolution.hippie.lan> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201405071226.34487.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 07 May 2014 14:34:40 -0400 (EDT) Cc: Kevin Oberman , "freebsd-acpi@freebsd.org" , "freebsd-arch@freebsd.org" X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 May 2014 18:34:41 -0000 On Tuesday, May 06, 2014 6:15:46 pm Ian Lepore wrote: > On Tue, 2014-05-06 at 16:37 -0400, John Baldwin wrote: > > On Tuesday, May 06, 2014 2:08:35 pm Adrian Chadd wrote: > > > On 5 May 2014 13:57, John Baldwin wrote: > > > > > > > The user in question found this on 9-stable with the existing defaults as the > > > > HPET was just plain broken on their system and that was unrelated to Cx states. > > > > (Rather, Cx states were only involved because worries about them are why the > > > > system chose to use HPET. Had Cx states been enabled by default, they would > > > > have had to disable those as well in addition to forcing LAPIC instead of > > > > HPET.) > > > > > > Hm. Sounds uncomfortable. How does Windows run on systems like this? > > > Do the windows drivers just disable HPET and use LAPIC or worse for > > > timing, and just ignore anything lower than C1? > > > > I have no idea. Maybe they use the RTC. :-/ Maybe the HPET on these systems > > works if you use it "sparingly". I believe OS X might have only used the HPET > > to provide the "missing" LAPIC wakeups when entering Cx for example. (Our current > > eventtimer system wants to always use whichever timer it picks, not switch off > > between them.) > > > > The eventtimer code is happy to switch between timers on the fly, but > iirc the only interface to that feature is sysctl. I found it fairly > easy to add an in-kernel API for changing the frequency of the current > timer on the fly. I think it would be just as easy to add a kernel > call to change timers as well. Ah. Well, if it's only a small slice of time where machines need this, I'd be fine with those machines just having to disable C1E and forcing use of LAPIC rather than adding a lot of goop to do LAPIC + HPET and then hoping the HPET works well enough. -- John Baldwin From owner-freebsd-acpi@FreeBSD.ORG Fri May 9 09:55:32 2014 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0D643FD9; Fri, 9 May 2014 09:55:32 +0000 (UTC) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id C346DFF8; Fri, 9 May 2014 09:55:31 +0000 (UTC) Received: from critter.freebsd.dk (unknown [192.168.60.3]) by phk.freebsd.dk (Postfix) with ESMTP id 12B911598; Fri, 9 May 2014 09:55:30 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.8/8.14.8) with ESMTP id s499tSen007682; Fri, 9 May 2014 09:55:29 GMT (envelope-from phk@phk.freebsd.dk) To: Ian Smith Subject: Re: proposal: set default lid state to S3, performance/economy Cx states to Cmax In-reply-to: <20140505163316.R11699@sola.nimnet.asn.au> From: "Poul-Henning Kamp" References: <20140505011654.O11699@sola.nimnet.asn.au> <2223.1399233644@critter.freebsd.dk> <20140505153421.W11699@sola.nimnet.asn.au> <85787.1399271121@critter.freebsd.dk> <20140505163316.R11699@sola.nimnet.asn.au> Content-Type: text/plain; charset=ISO-8859-1 Date: Fri, 09 May 2014 09:55:28 +0000 Message-ID: <7681.1399629328@critter.freebsd.dk> Cc: Kevin Oberman , "freebsd-acpi@freebsd.org" , "freebsd-arch@freebsd.org" X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 May 2014 09:55:32 -0000 In message <20140505163316.R11699@sola.nimnet.asn.au>, Ian Smith writes: >On Mon, 5 May 2014 06:25:21 +0000, Poul-Henning Kamp wrote: > > In message <20140505153421.W11699@sola.nimnet.asn.au>, Ian Smith writes: > > > > Do we have a canonical page with all the various workarounds one should > > attempt in order to get suspend/resume to work ? > >Bits scattered all over the place. For the above there's: So based on various scattered hints, I tried booting the VT kernel, r265336, on my Thinkpad T430s and that seems to fix both Suspend/Resume and also console switching. Much appreciated! I'll keep an eye on any peripheral bogons as I used it now. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-acpi@FreeBSD.ORG Fri May 9 10:26:01 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 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AD55F44B; Fri, 9 May 2014 10:26:01 +0000 (UTC) Received: from mail-qa0-x22a.google.com (mail-qa0-x22a.google.com [IPv6:2607:f8b0:400d:c00::22a]) (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 59E482AA; Fri, 9 May 2014 10:26:01 +0000 (UTC) Received: by mail-qa0-f42.google.com with SMTP id j5so3898004qaq.29 for ; Fri, 09 May 2014 03:26:00 -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:message-id:subject :from:to:cc:content-type; bh=FNgIjzGxDKoqUBGyu+Z5GgpzaLrUONVlf0qh3gLiAOU=; b=s6A2jRD1Gd/16Ae3aUHqI6v1nCnu4EApZ2jegi1kv1S373+LYfv216r6LHQjxYLf99 khP8fQ5cg5lUMmNKZm5SJYEzh2BJt29QjSMMw/gyhpjhaD8ysG5YOaGtiPKYHM04iTmw xCReEfK96zWULQth1XnZOP6e3B6pIuFpPKbKttauJzXgXLDlyeBzYr1fpjgkZMhQiZsL cpVsXyjQWZggjicz+13uz9nMgvowlBI0HBDR1JSD/lsPKY5vP1hHOXzsw7AG0VC0uoQZ yVMG0iEbohC91zRgiXOB6Gj66guBLVvksIpk4nDDGJ1qpvIgDrj2GUvHW3KLKkdcCF+O PjZQ== MIME-Version: 1.0 X-Received: by 10.224.47.130 with SMTP id n2mr13007698qaf.26.1399631160040; Fri, 09 May 2014 03:26:00 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.191.201 with HTTP; Fri, 9 May 2014 03:25:59 -0700 (PDT) In-Reply-To: <7681.1399629328@critter.freebsd.dk> References: <20140505011654.O11699@sola.nimnet.asn.au> <2223.1399233644@critter.freebsd.dk> <20140505153421.W11699@sola.nimnet.asn.au> <85787.1399271121@critter.freebsd.dk> <20140505163316.R11699@sola.nimnet.asn.au> <7681.1399629328@critter.freebsd.dk> Date: Fri, 9 May 2014 03:25:59 -0700 X-Google-Sender-Auth: eiZxUpZlvPRLsB0N6qRpye8sFh4 Message-ID: Subject: Re: proposal: set default lid state to S3, performance/economy Cx states to Cmax From: Adrian Chadd To: Poul-Henning Kamp Content-Type: text/plain; charset=UTF-8 Cc: Kevin Oberman , "freebsd-acpi@freebsd.org" , Ian Smith , "freebsd-arch@freebsd.org" X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 May 2014 10:26:01 -0000 Hi! On 9 May 2014 02:55, Poul-Henning Kamp wrote: > In message <20140505163316.R11699@sola.nimnet.asn.au>, Ian Smith writes: >>On Mon, 5 May 2014 06:25:21 +0000, Poul-Henning Kamp wrote: >> > In message <20140505153421.W11699@sola.nimnet.asn.au>, Ian Smith writes: >> > >> > Do we have a canonical page with all the various workarounds one should >> > attempt in order to get suspend/resume to work ? >> >>Bits scattered all over the place. For the above there's: > > So based on various scattered hints, I tried booting the VT kernel, > r265336, on my Thinkpad T430s and that seems to fix both Suspend/Resume > and also console switching. > > Much appreciated! > > I'll keep an eye on any peripheral bogons as I used it now. Woo! Would you mind populating http://wiki.freebsd.org/Laptops with your details? Thanks! -a From owner-freebsd-acpi@FreeBSD.ORG Fri May 9 20:12:29 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 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 89EEAA2D; Fri, 9 May 2014 20:12:29 +0000 (UTC) Received: from mail-pa0-x22e.google.com (mail-pa0-x22e.google.com [IPv6:2607:f8b0:400e:c03::22e]) (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 4E793E9F; Fri, 9 May 2014 20:12:29 +0000 (UTC) Received: by mail-pa0-f46.google.com with SMTP id kq14so658345pab.19 for ; Fri, 09 May 2014 13:12:29 -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:message-id:subject :from:to:cc:content-type; bh=dLioNfn9FiVlEvybSPFIB3tkoFEK0Cb2/x+2/OcG0KY=; b=bSF7pBEaJKVTdAyXSiA6XL6qVZRoTI7QAGvjBlYfzTt+8rrAkqcg6iTiHqHrEcF0su Q6wcfVx7lPuBV6DACxK2mJp8KKv7uuvgcUNaT1NkWI699ypyuOYTuO0cVi2pIGKmnEgc GR+JwIBJlZZThaxsIwxBPi4Ce6IwQna9tJgSpzFrp9XsjO/Ss1/ihZB97S+ko5YjNEot Z219UHgWeBirSnYHrrTeULHVBVFEsXuTELTRV4SrLMFXoTUPmu8H/PinUuADOv1EcVFd A/TQjf6cnD601EKbMYm71IMKcYwSuaeEW5t4oiarwsw/S5nmD5ZTC8/NQAVPOPKY2T+v tkeg== MIME-Version: 1.0 X-Received: by 10.67.8.102 with SMTP id dj6mr24209393pad.10.1399666348963; Fri, 09 May 2014 13:12:28 -0700 (PDT) Sender: kob6558@gmail.com Received: by 10.66.73.34 with HTTP; Fri, 9 May 2014 13:12:28 -0700 (PDT) In-Reply-To: References: <20140505011654.O11699@sola.nimnet.asn.au> <2223.1399233644@critter.freebsd.dk> <20140505153421.W11699@sola.nimnet.asn.au> <85787.1399271121@critter.freebsd.dk> <20140505163316.R11699@sola.nimnet.asn.au> <7681.1399629328@critter.freebsd.dk> Date: Fri, 9 May 2014 13:12:28 -0700 X-Google-Sender-Auth: L9x_f_czLEgBkIM9ioseXVAWcpY Message-ID: Subject: Re: proposal: set default lid state to S3, performance/economy Cx states to Cmax From: Kevin Oberman To: Adrian Chadd Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18 Cc: Poul-Henning Kamp , "freebsd-arch@freebsd.org" , Ian Smith , "freebsd-acpi@freebsd.org" X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 May 2014 20:12:29 -0000 On Fri, May 9, 2014 at 3:25 AM, Adrian Chadd wrote: > Hi! > > On 9 May 2014 02:55, Poul-Henning Kamp wrote: > > In message <20140505163316.R11699@sola.nimnet.asn.au>, Ian Smith writes: > >>On Mon, 5 May 2014 06:25:21 +0000, Poul-Henning Kamp wrote: > >> > In message <20140505153421.W11699@sola.nimnet.asn.au>, Ian Smith > writes: > >> > > >> > Do we have a canonical page with all the various workarounds one > should > >> > attempt in order to get suspend/resume to work ? > >> > >>Bits scattered all over the place. For the above there's: > > > > So based on various scattered hints, I tried booting the VT kernel, > > r265336, on my Thinkpad T430s and that seems to fix both Suspend/Resume > > and also console switching. > > > > Much appreciated! > > > > I'll keep an eye on any peripheral bogons as I used it now. > > Woo! > > Would you mind populating http://wiki.freebsd.org/Laptops with your > details? > > Thanks! > > > -a > Excellent! This alone will save batteries and also lower the carbon footprint of FreeBSD servers! Just to clarify the various settings of *_cx_lowest in rc.conf, HIGH is obvious. At one time, LOW was also obvious, but then some vendors started shipping BIOS that "skipped" some C-states in different power conditions. E.g. C1, C2 and C3 when on Battery, but only C1 and C3 when on AC. This scenario was common on Sandybridge systems (like my T320). Skipping a state broke "LOW" as it only saw C1 when on AC. Thus, Cmax appeared. Cmax is simply C8. It is just easier ot remember then C8. The code was re-written to ignore "missing" C-states and try all possible C-states until C8 was reached. Why "LOW" was not just changed to deal with this I don't understand, but Cmax (or C8) is recommended to gain the maximum power savings from C-states. On AC power: dev.cpu.0.cx_supported: C1/1/1 C2/3/104 dev.cpu.0.cx_lowest: C8 dev.cpu.0.cx_usage: 8.86% 91.13% last 2685us On battery: dev.cpu.0.cx_supported: C1/1/1 C2/2/80 C3/3/109 dev.cpu.0.cx_lowest: C8 dev.cpu.0.cx_usage: 3.09% 0.74% 96.15% last 728us Note the supported list on AC? C2/3/104 The first part, "C2", is what the OS labels that second state. The next part, "3", is the ACPI number of this state. On AC, this system has no C-state 2, so FreeBSD call the ACPI state 3 "C2". Oh, the last number is the number of clock cycles required to get into/out of that state. so in my case, when on battery, my CPU goes ot C2 after being halted for 80 clock cycles and C3 after 109. I hope this makes sense to everyone. I'm not really sure that it does to me! -- R. Kevin Oberman, Network Engineer, Retired E-mail: rkoberman@gmail.com From owner-freebsd-acpi@FreeBSD.ORG Fri May 9 20:36:03 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 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B612B38D; Fri, 9 May 2014 20:36:03 +0000 (UTC) Received: from mail-qc0-x230.google.com (mail-qc0-x230.google.com [IPv6:2607:f8b0:400d:c01::230]) (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 5A703CA; Fri, 9 May 2014 20:36:03 +0000 (UTC) Received: by mail-qc0-f176.google.com with SMTP id r5so5242998qcx.35 for ; Fri, 09 May 2014 13:36:02 -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:message-id:subject :from:to:cc:content-type; bh=nj3nn7zXA86NwjVh1fr7cUxbCzjDb/XQbOKNBgghR6o=; b=k8+mt1lNssLHLK9PMYYHSnBpbwdjQdF3RWJ3SAPvp/BWiadPsEUww3OTOVf5z3hKgp znqgnb/dV16VtxKDCnHNP6zi7rNQplPJqJ4OSQzyWt9B/mHfAxXg8djsRgEOwZ5Bv0w6 NuMdEGlbNeY2ptnthTEJJqH/4q+ZvaQymHILE3oZ99vGsUIX8dBFqnSI4nKZcv2k8MK2 kaOFgOvHHrvb7CpCsM95RbUoG9PWrxGWhNs031T9gUBIZnDO/AW2cKb62CGMA4Vlotkp vOCdudFlBsYwLnXZ7vcH70lb9PkB4hFB1T+vk6X0eR3H4a7gDnHtAI6GrcFtMJqIvjOc KB3Q== MIME-Version: 1.0 X-Received: by 10.224.16.199 with SMTP id p7mr18507242qaa.76.1399667762540; Fri, 09 May 2014 13:36:02 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.191.201 with HTTP; Fri, 9 May 2014 13:36:02 -0700 (PDT) In-Reply-To: References: <20140505011654.O11699@sola.nimnet.asn.au> <2223.1399233644@critter.freebsd.dk> <20140505153421.W11699@sola.nimnet.asn.au> <85787.1399271121@critter.freebsd.dk> <20140505163316.R11699@sola.nimnet.asn.au> <7681.1399629328@critter.freebsd.dk> Date: Fri, 9 May 2014 13:36:02 -0700 X-Google-Sender-Auth: buWpk3LJagVjuFoJaUfq78cAcNg Message-ID: Subject: Re: proposal: set default lid state to S3, performance/economy Cx states to Cmax From: Adrian Chadd To: Kevin Oberman Content-Type: text/plain; charset=UTF-8 Cc: Poul-Henning Kamp , "freebsd-arch@freebsd.org" , Ian Smith , "freebsd-acpi@freebsd.org" X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 May 2014 20:36:03 -0000 cool! next; # pkg install intel-pcm # kldload cpuctl # pcm.x 1 See what it reports. -a On 9 May 2014 13:12, Kevin Oberman wrote: > On Fri, May 9, 2014 at 3:25 AM, Adrian Chadd wrote: >> >> Hi! >> >> On 9 May 2014 02:55, Poul-Henning Kamp wrote: >> > In message <20140505163316.R11699@sola.nimnet.asn.au>, Ian Smith writes: >> >>On Mon, 5 May 2014 06:25:21 +0000, Poul-Henning Kamp wrote: >> >> > In message <20140505153421.W11699@sola.nimnet.asn.au>, Ian Smith >> >> > writes: >> >> > >> >> > Do we have a canonical page with all the various workarounds one >> >> > should >> >> > attempt in order to get suspend/resume to work ? >> >> >> >>Bits scattered all over the place. For the above there's: >> > >> > So based on various scattered hints, I tried booting the VT kernel, >> > r265336, on my Thinkpad T430s and that seems to fix both Suspend/Resume >> > and also console switching. >> > >> > Much appreciated! >> > >> > I'll keep an eye on any peripheral bogons as I used it now. >> >> Woo! >> >> Would you mind populating http://wiki.freebsd.org/Laptops with your >> details? >> >> Thanks! >> >> >> -a > > > Excellent! This alone will save batteries and also lower the carbon > footprint of FreeBSD servers! > > Just to clarify the various settings of *_cx_lowest in rc.conf, HIGH is > obvious. At one time, LOW was also obvious, but then some vendors started > shipping BIOS that "skipped" some C-states in different power conditions. > E.g. C1, C2 and C3 when on Battery, but only C1 and C3 when on AC. This > scenario was common on Sandybridge systems (like my T320). Skipping a state > broke "LOW" as it only saw C1 when on AC. Thus, Cmax appeared. Cmax is > simply C8. It is just easier ot remember then C8. The code was re-written to > ignore "missing" C-states and try all possible C-states until C8 was > reached. > > Why "LOW" was not just changed to deal with this I don't understand, but > Cmax (or C8) is recommended to gain the maximum power savings from > C-states. > > On AC power: > dev.cpu.0.cx_supported: C1/1/1 C2/3/104 > dev.cpu.0.cx_lowest: C8 > dev.cpu.0.cx_usage: 8.86% 91.13% last 2685us > > On battery: > dev.cpu.0.cx_supported: C1/1/1 C2/2/80 C3/3/109 > dev.cpu.0.cx_lowest: C8 > dev.cpu.0.cx_usage: 3.09% 0.74% 96.15% last 728us > > Note the supported list on AC? > C2/3/104 The first part, "C2", is what the OS labels that second state. The > next part, "3", is the ACPI number of this state. On AC, this system has no > C-state 2, so FreeBSD call the ACPI state 3 "C2". Oh, the last number is the > number of clock cycles required to get into/out of that state. so in my > case, when on battery, my CPU goes ot C2 after being halted for 80 clock > cycles and C3 after 109. I hope this makes sense to everyone. I'm not really > sure that it does to me! > -- > R. Kevin Oberman, Network Engineer, Retired > E-mail: rkoberman@gmail.com From owner-freebsd-acpi@FreeBSD.ORG Fri May 9 21:33:03 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 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 21FE99E3; Fri, 9 May 2014 21:33:03 +0000 (UTC) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id D4AE28E2; Fri, 9 May 2014 21:33:02 +0000 (UTC) Received: from critter.freebsd.dk (unknown [192.168.60.3]) by phk.freebsd.dk (Postfix) with ESMTP id CCC961598; Fri, 9 May 2014 21:33:01 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.8/8.14.8) with ESMTP id s49LX0gi010409; Fri, 9 May 2014 21:33:00 GMT (envelope-from phk@phk.freebsd.dk) To: Adrian Chadd Subject: Re: proposal: set default lid state to S3, performance/economy Cx states to Cmax In-reply-to: From: "Poul-Henning Kamp" References: <20140505011654.O11699@sola.nimnet.asn.au> <2223.1399233644@critter.freebsd.dk> <20140505153421.W11699@sola.nimnet.asn.au> <85787.1399271121@critter.freebsd.dk> <20140505163316.R11699@sola.nimnet.asn.au> <7681.1399629328@critter.freebsd.dk> Content-Type: text/plain; charset=ISO-8859-1 Date: Fri, 09 May 2014 21:33:00 +0000 Message-ID: <10408.1399671180@critter.freebsd.dk> Cc: Kevin Oberman , "freebsd-acpi@freebsd.org" , Ian Smith , "freebsd-arch@freebsd.org" X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 May 2014 21:33:03 -0000 In message , Adrian Chadd write s: >cool! > >next; > ># pkg install intel-pcm ># kldload cpuctl ># pcm.x 1 > >See what it reports. Lots of numbers. Am I looking for anything in particular ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-acpi@FreeBSD.ORG Mon May 12 00:40:32 2014 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9C49B389; Mon, 12 May 2014 00:40:32 +0000 (UTC) Received: from mail-pa0-x22d.google.com (mail-pa0-x22d.google.com [IPv6:2607:f8b0:400e:c03::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 60C4024E2; Mon, 12 May 2014 00:40:32 +0000 (UTC) Received: by mail-pa0-f45.google.com with SMTP id ey11so7156822pad.4 for ; Sun, 11 May 2014 17:40:32 -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:message-id:subject :from:to:cc:content-type; bh=+Npo4i30kggNiHPQeEnMEUqZ08kj5ole2IZ/Htzgkis=; b=MfsXQsa2tBwvXJol3Dmjor2+PEJoY4M8YJvCYEG2hph1tBJ/+T//2215Pu93Suk40U wiFu0qECBRQrlM7NAMMEPwZaCqvF/1yRnv8qCQcwBGZ/1LujrXuqBcX56guPKkD44enu fEEid0xIlBgHJl4BajOjinuHSH6YbCWq09QaAfa4Yg+XNHkctLLLH6CaFqZmwgQwLJUj 1kX4WLoNgMjLRqgcdWpqNPoUnII1dunxF3Nib/ja6mnIxxsAItnA7gMrFLic1VjJNH7D GmG0GEgoKhztlRS4AxDIB5G9x/fU4jfjjlF1ZQL87fEBWZyFO/GyeQ4XQRaV1B3dmEQ4 AD4A== MIME-Version: 1.0 X-Received: by 10.66.244.176 with SMTP id xh16mr48869974pac.20.1399855232033; Sun, 11 May 2014 17:40:32 -0700 (PDT) Sender: kob6558@gmail.com Received: by 10.66.73.34 with HTTP; Sun, 11 May 2014 17:40:31 -0700 (PDT) In-Reply-To: References: <20140505011654.O11699@sola.nimnet.asn.au> <2223.1399233644@critter.freebsd.dk> <20140505153421.W11699@sola.nimnet.asn.au> <85787.1399271121@critter.freebsd.dk> <20140505163316.R11699@sola.nimnet.asn.au> <7681.1399629328@critter.freebsd.dk> Date: Sun, 11 May 2014 17:40:31 -0700 X-Google-Sender-Auth: 68Ocn8Ty8f-Am-VFC51U3IjUL-c Message-ID: Subject: Re: proposal: set default lid state to S3, performance/economy Cx states to Cmax From: Kevin Oberman To: Adrian Chadd Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18 Cc: Poul-Henning Kamp , "freebsd-arch@freebsd.org" , Ian Smith , "freebsd-acpi@freebsd.org" X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 May 2014 00:40:32 -0000 On Fri, May 9, 2014 at 1:36 PM, Adrian Chadd wrote: > cool! > > next; > > # pkg install intel-pcm > # kldload cpuctl > # pcm.x 1 > > See what it reports. > OK. Any documentation on what this is supposed to tell me? Some of it makes perfect sense and some baffles me. I see C-states of C1 and C6 when on AC and C1, C3, and C7 when on battery (and, of course, C0). FREQ vs. AFREQ look interesting, but I'm not sure I really understand the implications. The last few lines, from " PHYSICAL CORE IPC", are particularly mysterious to me. I can understand the words, but I think that they carry more significance than is obvious, at least to me. I'm not a hardware guy. -- R. Kevin Oberman, Network Engineer, Retired E-mail: rkoberman@gmail.com From owner-freebsd-acpi@FreeBSD.ORG Mon May 12 11:06:39 2014 Return-Path: Delivered-To: freebsd-acpi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F2DD7A4E for ; Mon, 12 May 2014 11:06:39 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (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 C5DF326B2 for ; Mon, 12 May 2014 11:06:39 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.8/8.14.8) with ESMTP id s4CB6dIT067714 for ; Mon, 12 May 2014 11:06:39 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.8/8.14.8/Submit) id s4CB6dFN067710 for freebsd-acpi@FreeBSD.org; Mon, 12 May 2014 11:06:39 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 12 May 2014 11:06:39 GMT Message-Id: <201405121106.s4CB6dFN067710@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.18 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 May 2014 11:06:40 -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/187152 acpi [i386] [acpi] [suspend/resume] resume from ACPI suspen o kern/181665 acpi [acpi] System will not go into S3 state. o kern/180897 acpi [acpi] ACPI error with MB p8h67 v.1405 o kern/174766 acpi [acpi] Random acpi panic o kern/174504 acpi [acpi] [suspend/resume] Suspend/resume broken on Lenov o kern/173414 acpi [acpi] ACPI battery time incorrect o kern/173408 acpi [acpi] [regression] ACPI Regression: battery does not 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] [suspend/resume] Dell E6520 doesn't resume afte o kern/161713 acpi [acpi] [suspend/resume] Suspend on Dell E6520 doesn't 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] [suspend/resume] Lenovo T61p does not resume o i386/146715 acpi [acpi] [suspend/resume] Suspend works, resume not on a 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/73823 acpi [request] acpi / power-on by timer support 30 problems total. From owner-freebsd-acpi@FreeBSD.ORG Mon May 12 15:14:09 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 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CDDC379F; Mon, 12 May 2014 15:14:09 +0000 (UTC) Received: from mail-qg0-x231.google.com (mail-qg0-x231.google.com [IPv6:2607:f8b0:400d:c04::231]) (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 752392FE3; Mon, 12 May 2014 15:14:09 +0000 (UTC) Received: by mail-qg0-f49.google.com with SMTP id a108so7720160qge.22 for ; Mon, 12 May 2014 08:14:08 -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:message-id:subject :from:to:cc:content-type; bh=QIbCHbp0C1SqcWEd87wHH/HoozajtJh31AZaVbEZnzw=; b=zc2PoDOZ/e6WyPpkzJRw3k139d6DP6ugKZhGCQqlQaohFpSsd96cPnVnxwDOu0Z92D Vqh5Ech6pcCKdOXXHvOVww58+hdvpA87QEEMig10G86N7m9zx59++1mxaGOC8h8IDz9t 6MiAJniH3fZhokbs+6ukgDdRByptfBlw8A+Aa6f2rw3DgdKuG6j1BcJ53QBq4yWnZ0e/ eJp9AOF6fmu4E+UbET2qtA+YFgl5MlipmN19Dvj8S2C7gR2WpBGKInGQ6dc1eWG3AcU6 wLPoRfYmFLwur5dZeFK0LsJ4R29zmRfIZ6Tm0r4L9LgS2nwY+qSqyOcM84LNfNPpMgx2 Sszw== MIME-Version: 1.0 X-Received: by 10.224.38.138 with SMTP id b10mr12191463qae.98.1399907648569; Mon, 12 May 2014 08:14:08 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.191.201 with HTTP; Mon, 12 May 2014 08:14:08 -0700 (PDT) In-Reply-To: References: <20140505011654.O11699@sola.nimnet.asn.au> <2223.1399233644@critter.freebsd.dk> <20140505153421.W11699@sola.nimnet.asn.au> <85787.1399271121@critter.freebsd.dk> <20140505163316.R11699@sola.nimnet.asn.au> <7681.1399629328@critter.freebsd.dk> Date: Mon, 12 May 2014 08:14:08 -0700 X-Google-Sender-Auth: pPW8a4SXPe8A-EAwASqWOsbjHUU Message-ID: Subject: Re: proposal: set default lid state to S3, performance/economy Cx states to Cmax From: Adrian Chadd To: Kevin Oberman Content-Type: text/plain; charset=UTF-8 Cc: Poul-Henning Kamp , "freebsd-arch@freebsd.org" , Ian Smith , "freebsd-acpi@freebsd.org" X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 May 2014 15:14:10 -0000 The documentation is uhm, what's on intel's (growing) blog post and responses: https://software.intel.com/en-us/articles/intel-performance-counter-monitor-a-better-way-to-measure-cpu-utilization Yes, we can / should add clearer documentation. I had to also go hunting in the source to figure some of it out. FREQ/AFREQ is just the current clock cycle counters / clock reference counter (TSC). Ie, a freq or afreq of 1.0 means the clock cycle counters == TSC counter. FREQ takes the sleep state into account (ie, only counts _running_ cycles.) AFREQ doesn't. So FREQ gives you a good indication of the running duty cycle versus the ideal maximum, and AFREQ tells you what frequency the core is running at versus the reference frequency. An AFREQ of < 1.0 means that the chip is underclocking that core. An AFREQ of > 1.0 means turboboost is on and it's overclocking that core. -a On 11 May 2014 17:40, Kevin Oberman wrote: > On Fri, May 9, 2014 at 1:36 PM, Adrian Chadd wrote: >> >> cool! >> >> next; >> >> # pkg install intel-pcm >> # kldload cpuctl >> # pcm.x 1 >> >> See what it reports. > > > OK. Any documentation on what this is supposed to tell me? Some of it makes > perfect sense and some baffles me. > > I see C-states of C1 and C6 when on AC and C1, C3, and C7 when on battery > (and, of course, C0). FREQ vs. AFREQ look interesting, but I'm not sure I > really understand the implications. The last few lines, from " PHYSICAL CORE > IPC", are particularly mysterious to me. I can understand the words, but I > think that they carry more significance than is obvious, at least to me. I'm > not a hardware guy. > -- > R. Kevin Oberman, Network Engineer, Retired > E-mail: rkoberman@gmail.com From owner-freebsd-acpi@FreeBSD.ORG Mon May 19 11:06:41 2014 Return-Path: Delivered-To: freebsd-acpi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 40BF42B5 for ; Mon, 19 May 2014 11:06:41 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (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 13EB52D9F for ; Mon, 19 May 2014 11:06:41 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.8/8.14.8) with ESMTP id s4JB6e9u079919 for ; Mon, 19 May 2014 11:06:40 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.8/8.14.8/Submit) id s4JB6eM8079917 for freebsd-acpi@FreeBSD.org; Mon, 19 May 2014 11:06:40 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 19 May 2014 11:06:40 GMT Message-Id: <201405191106.s4JB6eM8079917@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.18 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 May 2014 11:06:41 -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/187152 acpi [i386] [acpi] [suspend/resume] resume from ACPI suspen o kern/181665 acpi [acpi] System will not go into S3 state. o kern/180897 acpi [acpi] ACPI error with MB p8h67 v.1405 o kern/174766 acpi [acpi] Random acpi panic o kern/174504 acpi [acpi] [suspend/resume] Suspend/resume broken on Lenov o kern/173414 acpi [acpi] ACPI battery time incorrect o kern/173408 acpi [acpi] [regression] ACPI Regression: battery does not 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] [suspend/resume] Dell E6520 doesn't resume afte o kern/161713 acpi [acpi] [suspend/resume] Suspend on Dell E6520 doesn't 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] [suspend/resume] Lenovo T61p does not resume o i386/146715 acpi [acpi] [suspend/resume] Suspend works, resume not on a 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/73823 acpi [request] acpi / power-on by timer support 30 problems total. From owner-freebsd-acpi@FreeBSD.ORG Wed May 21 19:53:37 2014 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6AE722CE for ; Wed, 21 May 2014 19:53:37 +0000 (UTC) Received: from mail.ignoranthack.me (ignoranthack.me [199.102.79.106]) (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 4CEB529E5 for ; Wed, 21 May 2014 19:53:37 +0000 (UTC) Received: from [10.12.72.220] (unknown [69.164.56.1]) (using SSLv3 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: sbruno@ignoranthack.me) by mail.ignoranthack.me (Postfix) with ESMTPSA id 679D9194138 for ; Wed, 21 May 2014 19:53:36 +0000 (UTC) Subject: device.hints -> hint.acpi_throttle.0.disabled="1 From: Sean Bruno Reply-To: sbruno@freebsd.org To: "freebsd-acpi@freebsd.org" Content-Type: text/plain; charset="us-ascii" Date: Wed, 21 May 2014 12:53:35 -0700 Message-ID: <1400702015.1848.20.camel@bruno> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 May 2014 19:53:37 -0000 I found sys/dev/acpica/acpi_throttle.c today. Should I have this removed from a standard laptop configuration? I would think I would want the system to throttle itself when appropriate. Is this an older way of doing something like C-states or have I missed something? sean From owner-freebsd-acpi@FreeBSD.ORG Wed May 21 20:09:16 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 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 77E31B6B; Wed, 21 May 2014 20:09:16 +0000 (UTC) Received: from mail-qg0-x22e.google.com (mail-qg0-x22e.google.com [IPv6:2607:f8b0:400d:c04::22e]) (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 2A8842B2E; Wed, 21 May 2014 20:09:16 +0000 (UTC) Received: by mail-qg0-f46.google.com with SMTP id q108so3992514qgd.5 for ; Wed, 21 May 2014 13:09:15 -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:message-id:subject :from:to:cc:content-type; bh=2njEFgwV265HSWrXbO18wTueUI+d+dhnbRyFyOXYpmE=; b=VUrtbWKFRZADN92t+dRlA5kIWNaGxM+oNTmZeSfriN0N7k5QlWIEdbpEKjP2IMRJl2 xtbl+Dkdp7Qoo5FpBBhrA3u8I9OzVEmwf9TgrVv90/Y09gL3QJfVeLRHWJFLx72CgmMz Yx98iu1KJYmnGgFuzpQi0LDGfiL/6dYfXxh+FeL9PI4ANZrPpGh8zlBF9b9bKkPEkTPO n5IaLR9LEgvG+zGXjQHjmOKyVQ9mBx71i3BrSkS6lwdBGBZcdmTlqQuQjGnCxcVcWtoW PuDmFKJSS7zOI1buGMOhE2CdOIRzE9C6jslVi+gv7/khmVrQ2lqf3DJsRnLAi4ZJGT4w OhmA== MIME-Version: 1.0 X-Received: by 10.140.96.51 with SMTP id j48mr70582938qge.24.1400702955214; Wed, 21 May 2014 13:09:15 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.191.201 with HTTP; Wed, 21 May 2014 13:09:15 -0700 (PDT) In-Reply-To: <1400702015.1848.20.camel@bruno> References: <1400702015.1848.20.camel@bruno> Date: Wed, 21 May 2014 13:09:15 -0700 X-Google-Sender-Auth: X5-LC9Dx8AFoCUOVIivr1UW7NoE Message-ID: Subject: Re: device.hints -> hint.acpi_throttle.0.disabled="1 From: Adrian Chadd To: Sean Bruno Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-acpi@freebsd.org" X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 May 2014 20:09:16 -0000 TL;DR - yes. That's why it was made as disabled by default now in hints. -a On 21 May 2014 12:53, Sean Bruno wrote: > I found sys/dev/acpica/acpi_throttle.c today. Should I have this > removed from a standard laptop configuration? I would think I would > want the system to throttle itself when appropriate. Is this an older > way of doing something like C-states or have I missed something? > > sean > > _______________________________________________ > freebsd-acpi@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-acpi > To unsubscribe, send any mail to "freebsd-acpi-unsubscribe@freebsd.org" From owner-freebsd-acpi@FreeBSD.ORG Fri May 23 16:15:01 2014 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1756E536 for ; Fri, 23 May 2014 16:15:01 +0000 (UTC) Received: from mail.ignoranthack.me (ignoranthack.me [199.102.79.106]) (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 ED90D2D24 for ; Fri, 23 May 2014 16:15:00 +0000 (UTC) Received: from [10.12.72.76] (unknown [69.164.56.1]) (using SSLv3 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: sbruno@ignoranthack.me) by mail.ignoranthack.me (Postfix) with ESMTPSA id 90E83194139 for ; Fri, 23 May 2014 16:14:58 +0000 (UTC) Subject: Investigating failed suspend/resume T61 From: Sean Bruno Reply-To: sbruno@freebsd.org To: "freebsd-acpi@freebsd.org" Content-Type: text/plain; charset="us-ascii" Date: Fri, 23 May 2014 09:14:58 -0700 Message-ID: <1400861698.1126.0.camel@bruno> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 May 2014 16:15:01 -0000 Trying to figure out the failures on suspend resume for the T61 I have. I see a little acpi error at host startup, but I don't think its related. However, I'm not sure what it means. sean ------ FreeBSD 11.0-CURRENT #1 r265820: Sat May 10 15:13:37 PDT 2014 sbruno@bruno:/usr/obj/usr/src/sys/BRUNO amd64 FreeBSD clang version 3.4 (tags/RELEASE_34/final 197956) 20140216 VT: running with driver "vga". CPU: Intel(R) Core(TM)2 Duo CPU T7300 @ 2.00GHz (1995.04-MHz K8-class CPU) Origin="GenuineIntel" Id=0x6fa Family=0x6 Model=0xf Stepping=10 Features=0xbfebfbff Features2=0xe3bd AMD Features=0x20100800 AMD Features2=0x1 TSC: P-state invariant, performance statistics real memory = 2147483648 (2048 MB) avail memory = 2007138304 (1914 MB) Event timer "LAPIC" quality 400 ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ACPI BIOS Warning (bug): 32/64X length mismatch in FADT/Gpe1Block: 0/32 (20130823/tbfadt-601) ACPI BIOS Warning (bug): Optional FADT field Gpe1Block has zero address or length: 0x000000000000102C/0x0 (20130823/tbfadt-630) From owner-freebsd-acpi@FreeBSD.ORG Mon May 26 11:06:41 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 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D2CDBD62 for ; Mon, 26 May 2014 11:06:41 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (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 A508824CD for ; Mon, 26 May 2014 11:06:41 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.8/8.14.8) with ESMTP id s4QB6f6f031925 for ; Mon, 26 May 2014 11:06:41 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.8/8.14.8/Submit) id s4QB6f19031923 for freebsd-acpi@FreeBSD.org; Mon, 26 May 2014 11:06:41 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 26 May 2014 11:06:41 GMT Message-Id: <201405261106.s4QB6f19031923@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.18 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 May 2014 11:06:41 -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/187152 acpi [i386] [acpi] [suspend/resume] resume from ACPI suspen o kern/181665 acpi [acpi] System will not go into S3 state. o kern/180897 acpi [acpi] ACPI error with MB p8h67 v.1405 o kern/174766 acpi [acpi] Random acpi panic o kern/174504 acpi [acpi] [suspend/resume] Suspend/resume broken on Lenov o kern/173414 acpi [acpi] ACPI battery time incorrect o kern/173408 acpi [acpi] [regression] ACPI Regression: battery does not 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] [suspend/resume] Dell E6520 doesn't resume afte o kern/161713 acpi [acpi] [suspend/resume] Suspend on Dell E6520 doesn't 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] [suspend/resume] Lenovo T61p does not resume o i386/146715 acpi [acpi] [suspend/resume] Suspend works, resume not on a 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/73823 acpi [request] acpi / power-on by timer support 30 problems total. From owner-freebsd-acpi@FreeBSD.ORG Tue May 27 17:17:28 2014 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8F671A77; Tue, 27 May 2014 17:17:28 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6B01C2084; Tue, 27 May 2014 17:17:28 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id C4231B97D; Tue, 27 May 2014 13:17:26 -0400 (EDT) From: John Baldwin To: freebsd-acpi@freebsd.org, sbruno@freebsd.org Subject: Re: Investigating failed suspend/resume T61 Date: Tue, 27 May 2014 11:32:55 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20140415; KDE/4.5.5; amd64; ; ) References: <1400861698.1126.0.camel@bruno> In-Reply-To: <1400861698.1126.0.camel@bruno> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201405271132.55387.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 27 May 2014 13:17:26 -0400 (EDT) X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 May 2014 17:17:28 -0000 On Friday, May 23, 2014 12:14:58 pm Sean Bruno wrote: > Trying to figure out the failures on suspend resume for the T61 I have. > I see a little acpi error at host startup, but I don't think its > related. However, I'm not sure what it means. > > sean > > ------ > > FreeBSD 11.0-CURRENT #1 r265820: Sat May 10 15:13:37 PDT 2014 > sbruno@bruno:/usr/obj/usr/src/sys/BRUNO amd64 > FreeBSD clang version 3.4 (tags/RELEASE_34/final 197956) 20140216 > VT: running with driver "vga". > CPU: Intel(R) Core(TM)2 Duo CPU T7300 @ 2.00GHz (1995.04-MHz > K8-class CPU) > Origin="GenuineIntel" Id=0x6fa Family=0x6 Model=0xf Stepping=10 > > Features=0xbfebfbff > > Features2=0xe3bd > AMD Features=0x20100800 > AMD Features2=0x1 > TSC: P-state invariant, performance statistics > real memory = 2147483648 (2048 MB) > avail memory = 2007138304 (1914 MB) > Event timer "LAPIC" quality 400 > ACPI APIC Table: > FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs > FreeBSD/SMP: 1 package(s) x 2 core(s) > cpu0 (BSP): APIC ID: 0 > cpu1 (AP): APIC ID: 1 > ACPI BIOS Warning (bug): 32/64X length mismatch in FADT/Gpe1Block: 0/32 > (20130823/tbfadt-601) > ACPI BIOS Warning (bug): Optional FADT field Gpe1Block has zero address > or length: 0x000000000000102C/0x0 (20130823/tbfadt-630) It might be related as Gpe1Block describes a register set that IIRC is used to enter sleep states. Can you put your acpidump -t somewhere? (No need for -d as this is in the FADT, not the DSDT.) -- John Baldwin From owner-freebsd-acpi@FreeBSD.ORG Tue May 27 17:39:51 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 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B8E47FCB; Tue, 27 May 2014 17:39:51 +0000 (UTC) Received: from mail.ignoranthack.me (ignoranthack.me [199.102.79.106]) (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 996202284; Tue, 27 May 2014 17:39:50 +0000 (UTC) Received: from [192.168.200.103] (c-50-131-4-11.hsd1.ca.comcast.net [50.131.4.11]) (using SSLv3 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: sbruno@ignoranthack.me) by mail.ignoranthack.me (Postfix) with ESMTPSA id 65C24194139; Tue, 27 May 2014 17:39:49 +0000 (UTC) Subject: Re: Investigating failed suspend/resume T61 From: Sean Bruno Reply-To: sbruno@freebsd.org To: John Baldwin In-Reply-To: <201405271132.55387.jhb@freebsd.org> References: <1400861698.1126.0.camel@bruno> <201405271132.55387.jhb@freebsd.org> Content-Type: text/plain; charset="us-ascii" Date: Tue, 27 May 2014 10:39:48 -0700 Message-ID: <1401212388.1128.2.camel@bruno> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: "freebsd-acpi@freebsd.org" X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 May 2014 17:39:51 -0000 On Tue, 2014-05-27 at 11:32 -0400, John Baldwin wrote: > On Friday, May 23, 2014 12:14:58 pm Sean Bruno wrote: > > Trying to figure out the failures on suspend resume for the T61 I have. > > I see a little acpi error at host startup, but I don't think its > > related. However, I'm not sure what it means. > > > > sean > > > > ------ > > > > FreeBSD 11.0-CURRENT #1 r265820: Sat May 10 15:13:37 PDT 2014 > > sbruno@bruno:/usr/obj/usr/src/sys/BRUNO amd64 > > FreeBSD clang version 3.4 (tags/RELEASE_34/final 197956) 20140216 > > VT: running with driver "vga". > > CPU: Intel(R) Core(TM)2 Duo CPU T7300 @ 2.00GHz (1995.04-MHz > > K8-class CPU) > > Origin="GenuineIntel" Id=0x6fa Family=0x6 Model=0xf Stepping=10 > > > > Features=0xbfebfbff > > > > Features2=0xe3bd > > AMD Features=0x20100800 > > AMD Features2=0x1 > > TSC: P-state invariant, performance statistics > > real memory = 2147483648 (2048 MB) > > avail memory = 2007138304 (1914 MB) > > Event timer "LAPIC" quality 400 > > ACPI APIC Table: > > FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs > > FreeBSD/SMP: 1 package(s) x 2 core(s) > > cpu0 (BSP): APIC ID: 0 > > cpu1 (AP): APIC ID: 1 > > ACPI BIOS Warning (bug): 32/64X length mismatch in FADT/Gpe1Block: 0/32 > > (20130823/tbfadt-601) > > ACPI BIOS Warning (bug): Optional FADT field Gpe1Block has zero address > > or length: 0x000000000000102C/0x0 (20130823/tbfadt-630) > > It might be related as Gpe1Block describes a register set that IIRC is used > to enter sleep states. Can you put your acpidump -t somewhere? (No need > for -d as this is in the FADT, not the DSDT.) > Here --> http://people.freebsd.org/~sbruno/T61_acpidump.txt sean From owner-freebsd-acpi@FreeBSD.ORG Tue May 27 20:19:51 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 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8623E4D0; Tue, 27 May 2014 20:19:51 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5FCFC2188; Tue, 27 May 2014 20:19:51 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 5A3B9B924; Tue, 27 May 2014 16:19:50 -0400 (EDT) From: John Baldwin To: sbruno@freebsd.org Subject: Re: Investigating failed suspend/resume T61 Date: Tue, 27 May 2014 16:14:30 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20140415; KDE/4.5.5; amd64; ; ) References: <1400861698.1126.0.camel@bruno> <201405271132.55387.jhb@freebsd.org> <1401212388.1128.2.camel@bruno> In-Reply-To: <1401212388.1128.2.camel@bruno> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201405271614.30168.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 27 May 2014 16:19:50 -0400 (EDT) Cc: "freebsd-acpi@freebsd.org" X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 May 2014 20:19:51 -0000 On Tuesday, May 27, 2014 1:39:48 pm Sean Bruno wrote: > On Tue, 2014-05-27 at 11:32 -0400, John Baldwin wrote: > > On Friday, May 23, 2014 12:14:58 pm Sean Bruno wrote: > > > Trying to figure out the failures on suspend resume for the T61 I have. > > > I see a little acpi error at host startup, but I don't think its > > > related. However, I'm not sure what it means. > > > > > > sean > > > > > > ------ > > > > > > FreeBSD 11.0-CURRENT #1 r265820: Sat May 10 15:13:37 PDT 2014 > > > sbruno@bruno:/usr/obj/usr/src/sys/BRUNO amd64 > > > FreeBSD clang version 3.4 (tags/RELEASE_34/final 197956) 20140216 > > > VT: running with driver "vga". > > > CPU: Intel(R) Core(TM)2 Duo CPU T7300 @ 2.00GHz (1995.04-MHz > > > K8-class CPU) > > > Origin="GenuineIntel" Id=0x6fa Family=0x6 Model=0xf Stepping=10 > > > > > > Features=0xbfebfbff > > > > > > Features2=0xe3bd > > > AMD Features=0x20100800 > > > AMD Features2=0x1 > > > TSC: P-state invariant, performance statistics > > > real memory = 2147483648 (2048 MB) > > > avail memory = 2007138304 (1914 MB) > > > Event timer "LAPIC" quality 400 > > > ACPI APIC Table: > > > FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs > > > FreeBSD/SMP: 1 package(s) x 2 core(s) > > > cpu0 (BSP): APIC ID: 0 > > > cpu1 (AP): APIC ID: 1 > > > ACPI BIOS Warning (bug): 32/64X length mismatch in FADT/Gpe1Block: 0/32 > > > (20130823/tbfadt-601) > > > ACPI BIOS Warning (bug): Optional FADT field Gpe1Block has zero address > > > or length: 0x000000000000102C/0x0 (20130823/tbfadt-630) > > > > It might be related as Gpe1Block describes a register set that IIRC is used > > to enter sleep states. Can you put your acpidump -t somewhere? (No need > > for -d as this is in the FADT, not the DSDT.) > > > > > Here --> http://people.freebsd.org/~sbruno/T61_acpidump.txt Ah, so the warning is due to the fact that the 'FACP' table has 'X_GPE1_BLOCK' but no 'GPE1_BLOCK'. (Note how it has both 'GPE0_BLOCK' and 'X_GPE0_BLOCK' which say the same thing.) Try this workaround to quiet the warning. I've no idea if it will help at all with suspend/resume. Index: sys/contrib/dev/acpica/components/tables/tbfadt.c =================================================================== --- tbfadt.c (revision 266442) +++ tbfadt.c (working copy) @@ -601,6 +601,10 @@ AcpiTbValidateFadt ( ACPI_BIOS_WARNING ((AE_INFO, "32/64X length mismatch in FADT/%s: %u/%u", Name, ACPI_MUL_8 (Length), Address64->BitWidth)); + if (Length == 0) + { + Length = ACPI_DIV_8 (Address64->BitWidth); + } } if (FadtInfoTable[i].Type & ACPI_FADT_REQUIRED) -- John Baldwin From owner-freebsd-acpi@FreeBSD.ORG Wed May 28 11:08:42 2014 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A4C05865; Wed, 28 May 2014 11:08:42 +0000 (UTC) Received: from mail.ignoranthack.me (ignoranthack.me [199.102.79.106]) (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 70234291C; Wed, 28 May 2014 11:08:42 +0000 (UTC) Received: from [192.168.200.103] (c-50-131-4-11.hsd1.ca.comcast.net [50.131.4.11]) (using SSLv3 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: sbruno@ignoranthack.me) by mail.ignoranthack.me (Postfix) with ESMTPSA id 42496194139; Wed, 28 May 2014 11:08:40 +0000 (UTC) Subject: Re: Investigating failed suspend/resume T61 From: Sean Bruno Reply-To: sbruno@freebsd.org To: John Baldwin In-Reply-To: <201405271614.30168.jhb@freebsd.org> References: <1400861698.1126.0.camel@bruno> <201405271132.55387.jhb@freebsd.org> <1401212388.1128.2.camel@bruno> <201405271614.30168.jhb@freebsd.org> Content-Type: text/plain; charset="us-ascii" Date: Wed, 28 May 2014 04:08:36 -0700 Message-ID: <1401275319.2355.0.camel@bruno> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: "freebsd-acpi@freebsd.org" X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 May 2014 11:08:42 -0000 On Tue, 2014-05-27 at 16:14 -0400, John Baldwin wrote: > On Tuesday, May 27, 2014 1:39:48 pm Sean Bruno wrote: > > On Tue, 2014-05-27 at 11:32 -0400, John Baldwin wrote: > > > On Friday, May 23, 2014 12:14:58 pm Sean Bruno wrote: > > > > Trying to figure out the failures on suspend resume for the T61 I have. > > > > I see a little acpi error at host startup, but I don't think its > > > > related. However, I'm not sure what it means. > > > > > > > > sean > > > > > > > > ------ > > > > > > > > FreeBSD 11.0-CURRENT #1 r265820: Sat May 10 15:13:37 PDT 2014 > > > > sbruno@bruno:/usr/obj/usr/src/sys/BRUNO amd64 > > > > FreeBSD clang version 3.4 (tags/RELEASE_34/final 197956) 20140216 > > > > VT: running with driver "vga". > > > > CPU: Intel(R) Core(TM)2 Duo CPU T7300 @ 2.00GHz (1995.04-MHz > > > > K8-class CPU) > > > > Origin="GenuineIntel" Id=0x6fa Family=0x6 Model=0xf Stepping=10 > > > > > > > > Features=0xbfebfbff > > > > > > > > Features2=0xe3bd > > > > AMD Features=0x20100800 > > > > AMD Features2=0x1 > > > > TSC: P-state invariant, performance statistics > > > > real memory = 2147483648 (2048 MB) > > > > avail memory = 2007138304 (1914 MB) > > > > Event timer "LAPIC" quality 400 > > > > ACPI APIC Table: > > > > FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs > > > > FreeBSD/SMP: 1 package(s) x 2 core(s) > > > > cpu0 (BSP): APIC ID: 0 > > > > cpu1 (AP): APIC ID: 1 > > > > ACPI BIOS Warning (bug): 32/64X length mismatch in FADT/Gpe1Block: 0/32 > > > > (20130823/tbfadt-601) > > > > ACPI BIOS Warning (bug): Optional FADT field Gpe1Block has zero address > > > > or length: 0x000000000000102C/0x0 (20130823/tbfadt-630) > > > > > > It might be related as Gpe1Block describes a register set that IIRC is used > > > to enter sleep states. Can you put your acpidump -t somewhere? (No need > > > for -d as this is in the FADT, not the DSDT.) > > > > > > > > > Here --> http://people.freebsd.org/~sbruno/T61_acpidump.txt > > Ah, so the warning is due to the fact that the 'FACP' table has 'X_GPE1_BLOCK' > but no 'GPE1_BLOCK'. (Note how it has both 'GPE0_BLOCK' and 'X_GPE0_BLOCK' > which say the same thing.) Try this workaround to quiet the warning. I've > no idea if it will help at all with suspend/resume. > > Index: sys/contrib/dev/acpica/components/tables/tbfadt.c > =================================================================== > --- tbfadt.c (revision 266442) > +++ tbfadt.c (working copy) > @@ -601,6 +601,10 @@ AcpiTbValidateFadt ( > ACPI_BIOS_WARNING ((AE_INFO, > "32/64X length mismatch in FADT/%s: %u/%u", > Name, ACPI_MUL_8 (Length), Address64->BitWidth)); > + if (Length == 0) > + { > + Length = ACPI_DIV_8 (Address64->BitWidth); > + } > } > > if (FadtInfoTable[i].Type & ACPI_FADT_REQUIRED) > > One warning went away, one remains, not sure if its meaningful or not. ACPI BIOS Warning (bug): 32/64X length mismatch in FADT/Gpe1Block: 0/32 (20130823/tbfadt-601) sean From owner-freebsd-acpi@FreeBSD.ORG Wed May 28 15:59:12 2014 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 498AAE5F; Wed, 28 May 2014 15:59:12 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1F0B025D9; Wed, 28 May 2014 15:59:12 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 12F4AB94C; Wed, 28 May 2014 11:59:11 -0400 (EDT) From: John Baldwin To: sbruno@freebsd.org Subject: Re: Investigating failed suspend/resume T61 Date: Wed, 28 May 2014 10:54:53 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20140415; KDE/4.5.5; amd64; ; ) References: <1400861698.1126.0.camel@bruno> <201405271614.30168.jhb@freebsd.org> <1401275319.2355.0.camel@bruno> In-Reply-To: <1401275319.2355.0.camel@bruno> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201405281054.53558.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 28 May 2014 11:59:11 -0400 (EDT) Cc: "freebsd-acpi@freebsd.org" X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 May 2014 15:59:12 -0000 On Wednesday, May 28, 2014 7:08:36 am Sean Bruno wrote: > On Tue, 2014-05-27 at 16:14 -0400, John Baldwin wrote: > > On Tuesday, May 27, 2014 1:39:48 pm Sean Bruno wrote: > > > On Tue, 2014-05-27 at 11:32 -0400, John Baldwin wrote: > > > > On Friday, May 23, 2014 12:14:58 pm Sean Bruno wrote: > > > > > Trying to figure out the failures on suspend resume for the T61 I have. > > > > > I see a little acpi error at host startup, but I don't think its > > > > > related. However, I'm not sure what it means. > > > > > > > > > > sean > > > > > > > > > > ------ > > > > > > > > > > FreeBSD 11.0-CURRENT #1 r265820: Sat May 10 15:13:37 PDT 2014 > > > > > sbruno@bruno:/usr/obj/usr/src/sys/BRUNO amd64 > > > > > FreeBSD clang version 3.4 (tags/RELEASE_34/final 197956) 20140216 > > > > > VT: running with driver "vga". > > > > > CPU: Intel(R) Core(TM)2 Duo CPU T7300 @ 2.00GHz (1995.04-MHz > > > > > K8-class CPU) > > > > > Origin="GenuineIntel" Id=0x6fa Family=0x6 Model=0xf Stepping=10 > > > > > > > > > > Features=0xbfebfbff > > > > > > > > > > Features2=0xe3bd > > > > > AMD Features=0x20100800 > > > > > AMD Features2=0x1 > > > > > TSC: P-state invariant, performance statistics > > > > > real memory = 2147483648 (2048 MB) > > > > > avail memory = 2007138304 (1914 MB) > > > > > Event timer "LAPIC" quality 400 > > > > > ACPI APIC Table: > > > > > FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs > > > > > FreeBSD/SMP: 1 package(s) x 2 core(s) > > > > > cpu0 (BSP): APIC ID: 0 > > > > > cpu1 (AP): APIC ID: 1 > > > > > ACPI BIOS Warning (bug): 32/64X length mismatch in FADT/Gpe1Block: 0/32 > > > > > (20130823/tbfadt-601) > > > > > ACPI BIOS Warning (bug): Optional FADT field Gpe1Block has zero address > > > > > or length: 0x000000000000102C/0x0 (20130823/tbfadt-630) > > > > > > > > It might be related as Gpe1Block describes a register set that IIRC is used > > > > to enter sleep states. Can you put your acpidump -t somewhere? (No need > > > > for -d as this is in the FADT, not the DSDT.) > > > > > > > > > > > > > Here --> http://people.freebsd.org/~sbruno/T61_acpidump.txt > > > > Ah, so the warning is due to the fact that the 'FACP' table has 'X_GPE1_BLOCK' > > but no 'GPE1_BLOCK'. (Note how it has both 'GPE0_BLOCK' and 'X_GPE0_BLOCK' > > which say the same thing.) Try this workaround to quiet the warning. I've > > no idea if it will help at all with suspend/resume. > > > > Index: sys/contrib/dev/acpica/components/tables/tbfadt.c > > =================================================================== > > --- tbfadt.c (revision 266442) > > +++ tbfadt.c (working copy) > > @@ -601,6 +601,10 @@ AcpiTbValidateFadt ( > > ACPI_BIOS_WARNING ((AE_INFO, > > "32/64X length mismatch in FADT/%s: %u/%u", > > Name, ACPI_MUL_8 (Length), Address64->BitWidth)); > > + if (Length == 0) > > + { > > + Length = ACPI_DIV_8 (Address64->BitWidth); > > + } > > } > > > > if (FadtInfoTable[i].Type & ACPI_FADT_REQUIRED) > > > > > > One warning went away, one remains, not sure if its meaningful or not. > > ACPI BIOS Warning (bug): 32/64X length mismatch in FADT/Gpe1Block: 0/32 > (20130823/tbfadt-601) Yes, I didn't remove that warning, I just fixed it to use the 64-bit length when the 32-bit length was zero when that warning fires. Does this seem to have made any difference with anything on the laptop? (E.g. it might possibly affect hotkeys, etc.) -- John Baldwin From owner-freebsd-acpi@FreeBSD.ORG Wed May 28 16:10:59 2014 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 17A975F5; Wed, 28 May 2014 16:10:59 +0000 (UTC) Received: from mail.ignoranthack.me (ignoranthack.me [199.102.79.106]) (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 D77D02805; Wed, 28 May 2014 16:10:58 +0000 (UTC) Received: from [192.168.200.103] (c-50-131-4-11.hsd1.ca.comcast.net [50.131.4.11]) (using SSLv3 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: sbruno@ignoranthack.me) by mail.ignoranthack.me (Postfix) with ESMTPSA id 96DDD194139; Wed, 28 May 2014 16:10:56 +0000 (UTC) Subject: Re: Investigating failed suspend/resume T61 From: Sean Bruno Reply-To: sbruno@freebsd.org To: John Baldwin In-Reply-To: <201405281054.53558.jhb@freebsd.org> References: <1400861698.1126.0.camel@bruno> <201405271614.30168.jhb@freebsd.org> <1401275319.2355.0.camel@bruno> <201405281054.53558.jhb@freebsd.org> Content-Type: text/plain; charset="us-ascii" Date: Wed, 28 May 2014 09:10:55 -0700 Message-ID: <1401293455.1050.1.camel@bruno> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: "freebsd-acpi@freebsd.org" X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 May 2014 16:10:59 -0000 On Wed, 2014-05-28 at 10:54 -0400, John Baldwin wrote: > On Wednesday, May 28, 2014 7:08:36 am Sean Bruno wrote: > > On Tue, 2014-05-27 at 16:14 -0400, John Baldwin wrote: > > > On Tuesday, May 27, 2014 1:39:48 pm Sean Bruno wrote: > > > > On Tue, 2014-05-27 at 11:32 -0400, John Baldwin wrote: > > > > > On Friday, May 23, 2014 12:14:58 pm Sean Bruno wrote: > > > > > > Trying to figure out the failures on suspend resume for the T61 I have. > > > > > > I see a little acpi error at host startup, but I don't think its > > > > > > related. However, I'm not sure what it means. > > > > > > > > > > > > sean > > > > > > > > > > > > ------ > > > > > > > > > > > > FreeBSD 11.0-CURRENT #1 r265820: Sat May 10 15:13:37 PDT 2014 > > > > > > sbruno@bruno:/usr/obj/usr/src/sys/BRUNO amd64 > > > > > > FreeBSD clang version 3.4 (tags/RELEASE_34/final 197956) 20140216 > > > > > > VT: running with driver "vga". > > > > > > CPU: Intel(R) Core(TM)2 Duo CPU T7300 @ 2.00GHz (1995.04-MHz > > > > > > K8-class CPU) > > > > > > Origin="GenuineIntel" Id=0x6fa Family=0x6 Model=0xf Stepping=10 > > > > > > > > > > > > Features=0xbfebfbff > > > > > > > > > > > > Features2=0xe3bd > > > > > > AMD Features=0x20100800 > > > > > > AMD Features2=0x1 > > > > > > TSC: P-state invariant, performance statistics > > > > > > real memory = 2147483648 (2048 MB) > > > > > > avail memory = 2007138304 (1914 MB) > > > > > > Event timer "LAPIC" quality 400 > > > > > > ACPI APIC Table: > > > > > > FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs > > > > > > FreeBSD/SMP: 1 package(s) x 2 core(s) > > > > > > cpu0 (BSP): APIC ID: 0 > > > > > > cpu1 (AP): APIC ID: 1 > > > > > > ACPI BIOS Warning (bug): 32/64X length mismatch in FADT/Gpe1Block: 0/32 > > > > > > (20130823/tbfadt-601) > > > > > > ACPI BIOS Warning (bug): Optional FADT field Gpe1Block has zero address > > > > > > or length: 0x000000000000102C/0x0 (20130823/tbfadt-630) > > > > > > > > > > It might be related as Gpe1Block describes a register set that IIRC is used > > > > > to enter sleep states. Can you put your acpidump -t somewhere? (No need > > > > > for -d as this is in the FADT, not the DSDT.) > > > > > > > > > > > > > > > > > Here --> http://people.freebsd.org/~sbruno/T61_acpidump.txt > > > > > > Ah, so the warning is due to the fact that the 'FACP' table has 'X_GPE1_BLOCK' > > > but no 'GPE1_BLOCK'. (Note how it has both 'GPE0_BLOCK' and 'X_GPE0_BLOCK' > > > which say the same thing.) Try this workaround to quiet the warning. I've > > > no idea if it will help at all with suspend/resume. > > > > > > Index: sys/contrib/dev/acpica/components/tables/tbfadt.c > > > =================================================================== > > > --- tbfadt.c (revision 266442) > > > +++ tbfadt.c (working copy) > > > @@ -601,6 +601,10 @@ AcpiTbValidateFadt ( > > > ACPI_BIOS_WARNING ((AE_INFO, > > > "32/64X length mismatch in FADT/%s: %u/%u", > > > Name, ACPI_MUL_8 (Length), Address64->BitWidth)); > > > + if (Length == 0) > > > + { > > > + Length = ACPI_DIV_8 (Address64->BitWidth); > > > + } > > > } > > > > > > if (FadtInfoTable[i].Type & ACPI_FADT_REQUIRED) > > > > > > > > > > One warning went away, one remains, not sure if its meaningful or not. > > > > ACPI BIOS Warning (bug): 32/64X length mismatch in FADT/Gpe1Block: 0/32 > > (20130823/tbfadt-601) > > Yes, I didn't remove that warning, I just fixed it to use the 64-bit length > when the 32-bit length was zero when that warning fires. Does this seem to > have made any difference with anything on the laptop? (E.g. it might possibly > affect hotkeys, etc.) > Believe it or not, but I just suspend/resumed on the thing, TWICE. Once from the xfce menu -> suspend and once from Fn->moonsymbolsuspendsleepthing on the F4 key. Good grief. Thanks John. sean From owner-freebsd-acpi@FreeBSD.ORG Wed May 28 16:20:45 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 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9E80E816; Wed, 28 May 2014 16:20:45 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5C5E02885; Wed, 28 May 2014 16:20:45 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 7470BB917; Wed, 28 May 2014 12:20:44 -0400 (EDT) From: John Baldwin To: sbruno@freebsd.org Subject: Re: Investigating failed suspend/resume T61 Date: Wed, 28 May 2014 12:20:24 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20140415; KDE/4.5.5; amd64; ; ) References: <1400861698.1126.0.camel@bruno> <201405281054.53558.jhb@freebsd.org> <1401293455.1050.1.camel@bruno> In-Reply-To: <1401293455.1050.1.camel@bruno> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201405281220.24778.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 28 May 2014 12:20:44 -0400 (EDT) Cc: "freebsd-acpi@freebsd.org" X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 May 2014 16:20:45 -0000 On Wednesday, May 28, 2014 12:10:55 pm Sean Bruno wrote: > On Wed, 2014-05-28 at 10:54 -0400, John Baldwin wrote: > > On Wednesday, May 28, 2014 7:08:36 am Sean Bruno wrote: > > > On Tue, 2014-05-27 at 16:14 -0400, John Baldwin wrote: > > > > On Tuesday, May 27, 2014 1:39:48 pm Sean Bruno wrote: > > > > > On Tue, 2014-05-27 at 11:32 -0400, John Baldwin wrote: > > > > > > On Friday, May 23, 2014 12:14:58 pm Sean Bruno wrote: > > > > > > > Trying to figure out the failures on suspend resume for the T61 I have. > > > > > > > I see a little acpi error at host startup, but I don't think its > > > > > > > related. However, I'm not sure what it means. > > > > > > > > > > > > > > sean > > > > > > > > > > > > > > ------ > > > > > > > > > > > > > > FreeBSD 11.0-CURRENT #1 r265820: Sat May 10 15:13:37 PDT 2014 > > > > > > > sbruno@bruno:/usr/obj/usr/src/sys/BRUNO amd64 > > > > > > > FreeBSD clang version 3.4 (tags/RELEASE_34/final 197956) 20140216 > > > > > > > VT: running with driver "vga". > > > > > > > CPU: Intel(R) Core(TM)2 Duo CPU T7300 @ 2.00GHz (1995.04-MHz > > > > > > > K8-class CPU) > > > > > > > Origin="GenuineIntel" Id=0x6fa Family=0x6 Model=0xf Stepping=10 > > > > > > > > > > > > > > Features=0xbfebfbff > > > > > > > > > > > > > > Features2=0xe3bd > > > > > > > AMD Features=0x20100800 > > > > > > > AMD Features2=0x1 > > > > > > > TSC: P-state invariant, performance statistics > > > > > > > real memory = 2147483648 (2048 MB) > > > > > > > avail memory = 2007138304 (1914 MB) > > > > > > > Event timer "LAPIC" quality 400 > > > > > > > ACPI APIC Table: > > > > > > > FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs > > > > > > > FreeBSD/SMP: 1 package(s) x 2 core(s) > > > > > > > cpu0 (BSP): APIC ID: 0 > > > > > > > cpu1 (AP): APIC ID: 1 > > > > > > > ACPI BIOS Warning (bug): 32/64X length mismatch in FADT/Gpe1Block: 0/32 > > > > > > > (20130823/tbfadt-601) > > > > > > > ACPI BIOS Warning (bug): Optional FADT field Gpe1Block has zero address > > > > > > > or length: 0x000000000000102C/0x0 (20130823/tbfadt-630) > > > > > > > > > > > > It might be related as Gpe1Block describes a register set that IIRC is used > > > > > > to enter sleep states. Can you put your acpidump -t somewhere? (No need > > > > > > for -d as this is in the FADT, not the DSDT.) > > > > > > > > > > > > > > > > > > > > > Here --> http://people.freebsd.org/~sbruno/T61_acpidump.txt > > > > > > > > Ah, so the warning is due to the fact that the 'FACP' table has 'X_GPE1_BLOCK' > > > > but no 'GPE1_BLOCK'. (Note how it has both 'GPE0_BLOCK' and 'X_GPE0_BLOCK' > > > > which say the same thing.) Try this workaround to quiet the warning. I've > > > > no idea if it will help at all with suspend/resume. > > > > > > > > Index: sys/contrib/dev/acpica/components/tables/tbfadt.c > > > > =================================================================== > > > > --- tbfadt.c (revision 266442) > > > > +++ tbfadt.c (working copy) > > > > @@ -601,6 +601,10 @@ AcpiTbValidateFadt ( > > > > ACPI_BIOS_WARNING ((AE_INFO, > > > > "32/64X length mismatch in FADT/%s: %u/%u", > > > > Name, ACPI_MUL_8 (Length), Address64->BitWidth)); > > > > + if (Length == 0) > > > > + { > > > > + Length = ACPI_DIV_8 (Address64->BitWidth); > > > > + } > > > > } > > > > > > > > if (FadtInfoTable[i].Type & ACPI_FADT_REQUIRED) > > > > > > > > > > > > > > One warning went away, one remains, not sure if its meaningful or not. > > > > > > ACPI BIOS Warning (bug): 32/64X length mismatch in FADT/Gpe1Block: 0/32 > > > (20130823/tbfadt-601) > > > > Yes, I didn't remove that warning, I just fixed it to use the 64-bit length > > when the 32-bit length was zero when that warning fires. Does this seem to > > have made any difference with anything on the laptop? (E.g. it might possibly > > affect hotkeys, etc.) > > > > > Believe it or not, but I just suspend/resumed on the thing, TWICE. Once > from the xfce menu -> suspend and once from > Fn->moonsymbolsuspendsleepthing on the F4 key. > > Good grief. Thanks John. Humm. I wonder if we can get the Intel guys to accept the patch upstream? -- John Baldwin From owner-freebsd-acpi@FreeBSD.ORG Wed May 28 16:44:45 2014 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from hammer.pct.niksun.com (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by hub.freebsd.org (Postfix) with ESMTP id E9740E88; Wed, 28 May 2014 16:44:44 +0000 (UTC) Message-ID: <5386127C.3060005@FreeBSD.org> Date: Wed, 28 May 2014 12:44:44 -0400 From: Jung-uk Kim User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: John Baldwin , sbruno@freebsd.org Subject: Re: Investigating failed suspend/resume T61 References: <1400861698.1126.0.camel@bruno> <201405281054.53558.jhb@freebsd.org> <1401293455.1050.1.camel@bruno> <201405281220.24778.jhb@freebsd.org> In-Reply-To: <201405281220.24778.jhb@freebsd.org> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "freebsd-acpi@freebsd.org" X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 May 2014 16:44:45 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2014-05-28 12:20:24 -0400, John Baldwin wrote: > On Wednesday, May 28, 2014 12:10:55 pm Sean Bruno wrote: >> On Wed, 2014-05-28 at 10:54 -0400, John Baldwin wrote: >>> On Wednesday, May 28, 2014 7:08:36 am Sean Bruno wrote: >>>> On Tue, 2014-05-27 at 16:14 -0400, John Baldwin wrote: >>>>> On Tuesday, May 27, 2014 1:39:48 pm Sean Bruno wrote: >>>>>> On Tue, 2014-05-27 at 11:32 -0400, John Baldwin wrote: >>>>>>> On Friday, May 23, 2014 12:14:58 pm Sean Bruno wrote: >>>>>>>> Trying to figure out the failures on suspend resume >>>>>>>> for the T61 I have. I see a little acpi error at host >>>>>>>> startup, but I don't think its related. However, I'm >>>>>>>> not sure what it means. >>>>>>>> >>>>>>>> sean >>>>>>>> >>>>>>>> ------ >>>>>>>> >>>>>>>> FreeBSD 11.0-CURRENT #1 r265820: Sat May 10 15:13:37 >>>>>>>> PDT 2014 sbruno@bruno:/usr/obj/usr/src/sys/BRUNO >>>>>>>> amd64 FreeBSD clang version 3.4 >>>>>>>> (tags/RELEASE_34/final 197956) 20140216 VT: running >>>>>>>> with driver "vga". CPU: Intel(R) Core(TM)2 Duo CPU >>>>>>>> T7300 @ 2.00GHz (1995.04-MHz K8-class CPU) >>>>>>>> Origin="GenuineIntel" Id=0x6fa Family=0x6 >>>>>>>> Model=0xf Stepping=10 >>>>>>>> >>>>>>>> Features=0xbfebfbff >>>>>>>> >>>>>>>> >>>>>>>> Features2=0xe3bd >>>>>>>> AMD Features=0x20100800 AMD >>>>>>>> Features2=0x1 TSC: P-state invariant, >>>>>>>> performance statistics real memory = 2147483648 >>>>>>>> (2048 MB) avail memory = 2007138304 (1914 MB) Event >>>>>>>> timer "LAPIC" quality 400 ACPI APIC Table: >>>>>>> TP-7L > FreeBSD/SMP: Multiprocessor System >>>>>>>> Detected: 2 CPUs FreeBSD/SMP: 1 package(s) x 2 >>>>>>>> core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: >>>>>>>> 1 ACPI BIOS Warning (bug): 32/64X length mismatch in >>>>>>>> FADT/Gpe1Block: 0/32 (20130823/tbfadt-601) ACPI BIOS >>>>>>>> Warning (bug): Optional FADT field Gpe1Block has zero >>>>>>>> address or length: 0x000000000000102C/0x0 >>>>>>>> (20130823/tbfadt-630) >>>>>>> >>>>>>> It might be related as Gpe1Block describes a register >>>>>>> set that IIRC is used to enter sleep states. Can you >>>>>>> put your acpidump -t somewhere? (No need for -d as >>>>>>> this is in the FADT, not the DSDT.) >>>>>>> >>>>>> >>>>>> >>>>>> Here --> >>>>>> http://people.freebsd.org/~sbruno/T61_acpidump.txt >>>>> >>>>> Ah, so the warning is due to the fact that the 'FACP' table >>>>> has 'X_GPE1_BLOCK' but no 'GPE1_BLOCK'. (Note how it has >>>>> both 'GPE0_BLOCK' and 'X_GPE0_BLOCK' which say the same >>>>> thing.) Try this workaround to quiet the warning. I've no >>>>> idea if it will help at all with suspend/resume. >>>>> >>>>> Index: sys/contrib/dev/acpica/components/tables/tbfadt.c >>>>> =================================================================== >>>>> >>>>> - --- tbfadt.c (revision 266442) >>>>> +++ tbfadt.c (working copy) @@ -601,6 +601,10 @@ >>>>> AcpiTbValidateFadt ( ACPI_BIOS_WARNING ((AE_INFO, "32/64X >>>>> length mismatch in FADT/%s: %u/%u", Name, ACPI_MUL_8 >>>>> (Length), Address64->BitWidth)); + if (Length == 0) + >>>>> { + Length = ACPI_DIV_8 (Address64->BitWidth); + } } >>>>> >>>>> if (FadtInfoTable[i].Type & ACPI_FADT_REQUIRED) >>>>> >>>>> >>>> >>>> One warning went away, one remains, not sure if its >>>> meaningful or not. >>>> >>>> ACPI BIOS Warning (bug): 32/64X length mismatch in >>>> FADT/Gpe1Block: 0/32 (20130823/tbfadt-601) >>> >>> Yes, I didn't remove that warning, I just fixed it to use the >>> 64-bit length when the 32-bit length was zero when that warning >>> fires. Does this seem to have made any difference with >>> anything on the laptop? (E.g. it might possibly affect >>> hotkeys, etc.) >>> >> >> >> Believe it or not, but I just suspend/resumed on the thing, >> TWICE. Once from the xfce menu -> suspend and once from >> Fn->moonsymbolsuspendsleepthing on the F4 key. >> >> Good grief. Thanks John. > > Humm. I wonder if we can get the Intel guys to accept the patch > upstream? Yes, ACPICA guys are very open to patches. Actually there are several ways to report bugs and/or submit patches. Bug reports: https://bugs.acpica.org Developer ML: https://lists.acpica.org/mailman/listinfo/devel Source repository: https://github.com/acpica/acpica However, I'm afraid the following commit may have nullified your patch. https://github.com/acpica/acpica/commit/8149df49 Jung-uk Kim -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQEcBAEBAgAGBQJThhJ8AAoJEHyflib82/FGrPsH/iohXslK+ZSWBWXpHmlE5ONQ bpRjFbAvfeKwSn33YaVgk/1g06/+UhPcpErEwLF0yp9/CC54v40/LXJUKs2DTYRV 5A2gK02xTJ9vJCQiqJXanZhdFBfITPf9eKAM2idIfgCwGlvKH/Vw3DFZbdVHDphJ ma4nWYFWureASD3QvRoZ4xjmjWZoY0jfw/h+xRk49Ja5/bzFTu9Mx0AbkVTtg/50 jta4pzbaiv6Sv3lsTvYU+VTc9vOyLqnPl6JSeavM8Bit3AThb8e8Atg7ZLxb6WGb YAdei45YvsplGTTl+vjzOWFpXdxNATv2yjwBNzudG1+rjiCEayd+96CyMURH+tk= =ylP0 -----END PGP SIGNATURE----- From owner-freebsd-acpi@FreeBSD.ORG Wed May 28 17:50:17 2014 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0A3477AD; Wed, 28 May 2014 17:50:17 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B59CE2159; Wed, 28 May 2014 17:50:16 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 3B39BB939; Wed, 28 May 2014 13:50:15 -0400 (EDT) From: John Baldwin To: "Jung-uk Kim" Subject: Re: Investigating failed suspend/resume T61 Date: Wed, 28 May 2014 13:44:46 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20140415; KDE/4.5.5; amd64; ; ) References: <1400861698.1126.0.camel@bruno> <201405281220.24778.jhb@freebsd.org> <5386127C.3060005@FreeBSD.org> In-Reply-To: <5386127C.3060005@FreeBSD.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201405281344.46430.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 28 May 2014 13:50:15 -0400 (EDT) Cc: "freebsd-acpi@freebsd.org" X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 May 2014 17:50:17 -0000 On Wednesday, May 28, 2014 12:44:44 pm Jung-uk Kim wrote: > On 2014-05-28 12:20:24 -0400, John Baldwin wrote: > > On Wednesday, May 28, 2014 12:10:55 pm Sean Bruno wrote: > >> On Wed, 2014-05-28 at 10:54 -0400, John Baldwin wrote: > >>> On Wednesday, May 28, 2014 7:08:36 am Sean Bruno wrote: > >>>> On Tue, 2014-05-27 at 16:14 -0400, John Baldwin wrote: > >>>>> On Tuesday, May 27, 2014 1:39:48 pm Sean Bruno wrote: > >>>>>> On Tue, 2014-05-27 at 11:32 -0400, John Baldwin wrote: > >>>>>>> On Friday, May 23, 2014 12:14:58 pm Sean Bruno wrote: > >>>>>>>> Trying to figure out the failures on suspend resume > >>>>>>>> for the T61 I have. I see a little acpi error at host > >>>>>>>> startup, but I don't think its related. However, I'm > >>>>>>>> not sure what it means. > >>>>>>>> > >>>>>>>> sean > >>>>>>>> > >>>>>>>> ------ > >>>>>>>> > >>>>>>>> FreeBSD 11.0-CURRENT #1 r265820: Sat May 10 15:13:37 > >>>>>>>> PDT 2014 sbruno@bruno:/usr/obj/usr/src/sys/BRUNO > >>>>>>>> amd64 FreeBSD clang version 3.4 > >>>>>>>> (tags/RELEASE_34/final 197956) 20140216 VT: running > >>>>>>>> with driver "vga". CPU: Intel(R) Core(TM)2 Duo CPU > >>>>>>>> T7300 @ 2.00GHz (1995.04-MHz K8-class CPU) > >>>>>>>> Origin="GenuineIntel" Id=0x6fa Family=0x6 > >>>>>>>> Model=0xf Stepping=10 > >>>>>>>> > >>>>>>>> Features=0xbfebfbff > >>>>>>>> > >>>>>>>> > >>>>>>>> > Features2=0xe3bd > >>>>>>>> AMD Features=0x20100800 AMD > >>>>>>>> Features2=0x1 TSC: P-state invariant, > >>>>>>>> performance statistics real memory = 2147483648 > >>>>>>>> (2048 MB) avail memory = 2007138304 (1914 MB) Event > >>>>>>>> timer "LAPIC" quality 400 ACPI APIC Table: >>>>>>>> TP-7L > FreeBSD/SMP: Multiprocessor System > >>>>>>>> Detected: 2 CPUs FreeBSD/SMP: 1 package(s) x 2 > >>>>>>>> core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: > >>>>>>>> 1 ACPI BIOS Warning (bug): 32/64X length mismatch in > >>>>>>>> FADT/Gpe1Block: 0/32 (20130823/tbfadt-601) ACPI BIOS > >>>>>>>> Warning (bug): Optional FADT field Gpe1Block has zero > >>>>>>>> address or length: 0x000000000000102C/0x0 > >>>>>>>> (20130823/tbfadt-630) > >>>>>>> > >>>>>>> It might be related as Gpe1Block describes a register > >>>>>>> set that IIRC is used to enter sleep states. Can you > >>>>>>> put your acpidump -t somewhere? (No need for -d as > >>>>>>> this is in the FADT, not the DSDT.) > >>>>>>> > >>>>>> > >>>>>> > >>>>>> Here --> > >>>>>> http://people.freebsd.org/~sbruno/T61_acpidump.txt > >>>>> > >>>>> Ah, so the warning is due to the fact that the 'FACP' table > >>>>> has 'X_GPE1_BLOCK' but no 'GPE1_BLOCK'. (Note how it has > >>>>> both 'GPE0_BLOCK' and 'X_GPE0_BLOCK' which say the same > >>>>> thing.) Try this workaround to quiet the warning. I've no > >>>>> idea if it will help at all with suspend/resume. > >>>>> > >>>>> Index: sys/contrib/dev/acpica/components/tables/tbfadt.c > >>>>> =================================================================== > >>>>> > >>>>> > --- tbfadt.c (revision 266442) > >>>>> +++ tbfadt.c (working copy) @@ -601,6 +601,10 @@ > >>>>> AcpiTbValidateFadt ( ACPI_BIOS_WARNING ((AE_INFO, "32/64X > >>>>> length mismatch in FADT/%s: %u/%u", Name, ACPI_MUL_8 > >>>>> (Length), Address64->BitWidth)); + if (Length == 0) + > >>>>> { + Length = ACPI_DIV_8 (Address64->BitWidth); + } } > >>>>> > >>>>> if (FadtInfoTable[i].Type & ACPI_FADT_REQUIRED) > >>>>> > >>>>> > >>>> > >>>> One warning went away, one remains, not sure if its > >>>> meaningful or not. > >>>> > >>>> ACPI BIOS Warning (bug): 32/64X length mismatch in > >>>> FADT/Gpe1Block: 0/32 (20130823/tbfadt-601) > >>> > >>> Yes, I didn't remove that warning, I just fixed it to use the > >>> 64-bit length when the 32-bit length was zero when that warning > >>> fires. Does this seem to have made any difference with > >>> anything on the laptop? (E.g. it might possibly affect > >>> hotkeys, etc.) > >>> > >> > >> > >> Believe it or not, but I just suspend/resumed on the thing, > >> TWICE. Once from the xfce menu -> suspend and once from > >> Fn->moonsymbolsuspendsleepthing on the F4 key. > >> > >> Good grief. Thanks John. > > > > Humm. I wonder if we can get the Intel guys to accept the patch > > upstream? > > Yes, ACPICA guys are very open to patches. Actually there are several > ways to report bugs and/or submit patches. > > Bug reports: > https://bugs.acpica.org > > Developer ML: > https://lists.acpica.org/mailman/listinfo/devel > > Source repository: > https://github.com/acpica/acpica > > However, I'm afraid the following commit may have nullified your patch. > > https://github.com/acpica/acpica/commit/8149df49 It looks to only be adjusting the preference for the Address portion. It still uses the length field from FADT and doesn't use the length from the GAS. -- John Baldwin From owner-freebsd-acpi@FreeBSD.ORG Wed May 28 18:16:04 2014 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from hammer.pct.niksun.com (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by hub.freebsd.org (Postfix) with ESMTP id 64AF0E75; Wed, 28 May 2014 18:16:04 +0000 (UTC) Message-ID: <538627E3.7080308@FreeBSD.org> Date: Wed, 28 May 2014 14:16:03 -0400 From: Jung-uk Kim User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: John Baldwin Subject: Re: Investigating failed suspend/resume T61 References: <1400861698.1126.0.camel@bruno> <201405281220.24778.jhb@freebsd.org> <5386127C.3060005@FreeBSD.org> <201405281344.46430.jhb@freebsd.org> In-Reply-To: <201405281344.46430.jhb@freebsd.org> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "freebsd-acpi@freebsd.org" X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 May 2014 18:16:04 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2014-05-28 13:44:46 -0400, John Baldwin wrote: > On Wednesday, May 28, 2014 12:44:44 pm Jung-uk Kim wrote: >> On 2014-05-28 12:20:24 -0400, John Baldwin wrote: >>> On Wednesday, May 28, 2014 12:10:55 pm Sean Bruno wrote: >>>> On Wed, 2014-05-28 at 10:54 -0400, John Baldwin wrote: >>>>> On Wednesday, May 28, 2014 7:08:36 am Sean Bruno wrote: >>>>>> On Tue, 2014-05-27 at 16:14 -0400, John Baldwin wrote: >>>>>>> On Tuesday, May 27, 2014 1:39:48 pm Sean Bruno wrote: >>>>>>>> On Tue, 2014-05-27 at 11:32 -0400, John Baldwin >>>>>>>> wrote: >>>>>>>>> On Friday, May 23, 2014 12:14:58 pm Sean Bruno >>>>>>>>> wrote: >>>>>>>>>> Trying to figure out the failures on suspend >>>>>>>>>> resume for the T61 I have. I see a little acpi >>>>>>>>>> error at host startup, but I don't think its >>>>>>>>>> related. However, I'm not sure what it means. >>>>>>>>>> >>>>>>>>>> sean >>>>>>>>>> >>>>>>>>>> ------ >>>>>>>>>> >>>>>>>>>> FreeBSD 11.0-CURRENT #1 r265820: Sat May 10 >>>>>>>>>> 15:13:37 PDT 2014 >>>>>>>>>> sbruno@bruno:/usr/obj/usr/src/sys/BRUNO amd64 >>>>>>>>>> FreeBSD clang version 3.4 (tags/RELEASE_34/final >>>>>>>>>> 197956) 20140216 VT: running with driver "vga". >>>>>>>>>> CPU: Intel(R) Core(TM)2 Duo CPU T7300 @ 2.00GHz >>>>>>>>>> (1995.04-MHz K8-class CPU) Origin="GenuineIntel" >>>>>>>>>> Id=0x6fa Family=0x6 Model=0xf Stepping=10 >>>>>>>>>> >>>>>>>>>> > Features=0xbfebfbff >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >> > Features2=0xe3bd >>>>>>>>>> AMD Features=0x20100800 AMD >>>>>>>>>> Features2=0x1 TSC: P-state invariant, >>>>>>>>>> performance statistics real memory = 2147483648 >>>>>>>>>> (2048 MB) avail memory = 2007138304 (1914 MB) >>>>>>>>>> Event timer "LAPIC" quality 400 ACPI APIC Table: >>>>>>>>>> FreeBSD/SMP: Multiprocessor >>>>>>>>>> System Detected: 2 CPUs FreeBSD/SMP: 1 package(s) >>>>>>>>>> x 2 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): >>>>>>>>>> APIC ID: 1 ACPI BIOS Warning (bug): 32/64X length >>>>>>>>>> mismatch in FADT/Gpe1Block: 0/32 >>>>>>>>>> (20130823/tbfadt-601) ACPI BIOS Warning (bug): >>>>>>>>>> Optional FADT field Gpe1Block has zero address or >>>>>>>>>> length: 0x000000000000102C/0x0 >>>>>>>>>> (20130823/tbfadt-630) >>>>>>>>> >>>>>>>>> It might be related as Gpe1Block describes a >>>>>>>>> register set that IIRC is used to enter sleep >>>>>>>>> states. Can you put your acpidump -t somewhere? >>>>>>>>> (No need for -d as this is in the FADT, not the >>>>>>>>> DSDT.) >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Here --> >>>>>>>> http://people.freebsd.org/~sbruno/T61_acpidump.txt >>>>>>> >>>>>>> Ah, so the warning is due to the fact that the 'FACP' >>>>>>> table has 'X_GPE1_BLOCK' but no 'GPE1_BLOCK'. (Note >>>>>>> how it has both 'GPE0_BLOCK' and 'X_GPE0_BLOCK' which >>>>>>> say the same thing.) Try this workaround to quiet the >>>>>>> warning. I've no idea if it will help at all with >>>>>>> suspend/resume. >>>>>>> >>>>>>> Index: >>>>>>> sys/contrib/dev/acpica/components/tables/tbfadt.c >>>>>>> =================================================================== >>>>>>> >>>>>>> >> >>>>>>> - --- tbfadt.c (revision 266442) >>>>>>> +++ tbfadt.c (working copy) @@ -601,6 +601,10 @@ >>>>>>> AcpiTbValidateFadt ( ACPI_BIOS_WARNING ((AE_INFO, >>>>>>> "32/64X length mismatch in FADT/%s: %u/%u", Name, >>>>>>> ACPI_MUL_8 (Length), Address64->BitWidth)); + if >>>>>>> (Length == 0) + { + Length = ACPI_DIV_8 >>>>>>> (Address64->BitWidth); + } } >>>>>>> >>>>>>> if (FadtInfoTable[i].Type & ACPI_FADT_REQUIRED) >>>>>>> >>>>>>> >>>>>> >>>>>> One warning went away, one remains, not sure if its >>>>>> meaningful or not. >>>>>> >>>>>> ACPI BIOS Warning (bug): 32/64X length mismatch in >>>>>> FADT/Gpe1Block: 0/32 (20130823/tbfadt-601) >>>>> >>>>> Yes, I didn't remove that warning, I just fixed it to use >>>>> the 64-bit length when the 32-bit length was zero when that >>>>> warning fires. Does this seem to have made any difference >>>>> with anything on the laptop? (E.g. it might possibly >>>>> affect hotkeys, etc.) >>>>> >>>> >>>> >>>> Believe it or not, but I just suspend/resumed on the thing, >>>> TWICE. Once from the xfce menu -> suspend and once from >>>> Fn->moonsymbolsuspendsleepthing on the F4 key. >>>> >>>> Good grief. Thanks John. >>> >>> Humm. I wonder if we can get the Intel guys to accept the >>> patch upstream? >> >> Yes, ACPICA guys are very open to patches. Actually there are >> several ways to report bugs and/or submit patches. >> >> Bug reports: https://bugs.acpica.org >> >> Developer ML: https://lists.acpica.org/mailman/listinfo/devel >> >> Source repository: https://github.com/acpica/acpica >> >> However, I'm afraid the following commit may have nullified your >> patch. >> >> https://github.com/acpica/acpica/commit/8149df49 > > It looks to only be adjusting the preference for the Address > portion. It still uses the length field from FADT and doesn't use > the length from the GAS. Okay. BTW, I just read your patch carefully but I failed to understand how shutting up a warning can fix any problem at all. Did you mean to patch internal table? Jung-uk Kim -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQEcBAEBAgAGBQJThifjAAoJEHyflib82/FGNsEIAI2/4zlCl4J448VDzRPlzp7i jsHVt9KB7NUNin3Wie20PwxHxLhWcxd4LsMXUuC5vQUO7d8i06AMImsJ4O56u1ZO muGu/tuH9RfmH7xBeJ/9Lu7FOSUhEPd4qIQwl0hD1P5OTmigdJDQ9W0Xw4l87VuH EuHWM0DiXywAvZTKgPdc4REZHzO2PnVco7qm/HpJqcxksrmOMbWuPjlimnR4KSQT JFf6Gp3+xtFgP3Mpcqfyn3Xi8hO8DEkVBOQVkAh9u3Rki1AZuBjPwkWop0ykTjT7 KL5UAv7Tx/4W04tbqzsE3lmvCdU5EcNjhSlFEmKA5oyOoNdyf7NNAz3fmMMkU2I= =OrGY -----END PGP SIGNATURE----- From owner-freebsd-acpi@FreeBSD.ORG Wed May 28 19:56:50 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 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1FD357AE; Wed, 28 May 2014 19:56:50 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E80822F66; Wed, 28 May 2014 19:56:49 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 7A2ACB95D; Wed, 28 May 2014 15:56:48 -0400 (EDT) From: John Baldwin To: "Jung-uk Kim" Subject: Re: Investigating failed suspend/resume T61 Date: Wed, 28 May 2014 15:56:37 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20140415; KDE/4.5.5; amd64; ; ) References: <1400861698.1126.0.camel@bruno> <201405281344.46430.jhb@freebsd.org> <538627E3.7080308@FreeBSD.org> In-Reply-To: <538627E3.7080308@FreeBSD.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201405281556.37651.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 28 May 2014 15:56:48 -0400 (EDT) Cc: "freebsd-acpi@freebsd.org" X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 May 2014 19:56:50 -0000 On Wednesday, May 28, 2014 2:16:03 pm Jung-uk Kim wrote: > On 2014-05-28 13:44:46 -0400, John Baldwin wrote: > > On Wednesday, May 28, 2014 12:44:44 pm Jung-uk Kim wrote: > >> On 2014-05-28 12:20:24 -0400, John Baldwin wrote: > >>> On Wednesday, May 28, 2014 12:10:55 pm Sean Bruno wrote: > >>>> On Wed, 2014-05-28 at 10:54 -0400, John Baldwin wrote: > >>>>> On Wednesday, May 28, 2014 7:08:36 am Sean Bruno wrote: > >>>>>> On Tue, 2014-05-27 at 16:14 -0400, John Baldwin wrote: > >>>>>>> On Tuesday, May 27, 2014 1:39:48 pm Sean Bruno wrote: > >>>>>>>> On Tue, 2014-05-27 at 11:32 -0400, John Baldwin > >>>>>>>> wrote: > >>>>>>>>> On Friday, May 23, 2014 12:14:58 pm Sean Bruno > >>>>>>>>> wrote: > >>>>>>>>>> Trying to figure out the failures on suspend > >>>>>>>>>> resume for the T61 I have. I see a little acpi > >>>>>>>>>> error at host startup, but I don't think its > >>>>>>>>>> related. However, I'm not sure what it means. > >>>>>>>>>> > >>>>>>>>>> sean > >>>>>>>>>> > >>>>>>>>>> ------ > >>>>>>>>>> > >>>>>>>>>> FreeBSD 11.0-CURRENT #1 r265820: Sat May 10 > >>>>>>>>>> 15:13:37 PDT 2014 > >>>>>>>>>> sbruno@bruno:/usr/obj/usr/src/sys/BRUNO amd64 > >>>>>>>>>> FreeBSD clang version 3.4 (tags/RELEASE_34/final > >>>>>>>>>> 197956) 20140216 VT: running with driver "vga". > >>>>>>>>>> CPU: Intel(R) Core(TM)2 Duo CPU T7300 @ 2.00GHz > >>>>>>>>>> (1995.04-MHz K8-class CPU) Origin="GenuineIntel" > >>>>>>>>>> Id=0x6fa Family=0x6 Model=0xf Stepping=10 > >>>>>>>>>> > >>>>>>>>>> > > Features=0xbfebfbff > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >> > > > Features2=0xe3bd > >>>>>>>>>> AMD Features=0x20100800 AMD > >>>>>>>>>> Features2=0x1 TSC: P-state invariant, > >>>>>>>>>> performance statistics real memory = 2147483648 > >>>>>>>>>> (2048 MB) avail memory = 2007138304 (1914 MB) > >>>>>>>>>> Event timer "LAPIC" quality 400 ACPI APIC Table: > >>>>>>>>>> FreeBSD/SMP: Multiprocessor > >>>>>>>>>> System Detected: 2 CPUs FreeBSD/SMP: 1 package(s) > >>>>>>>>>> x 2 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): > >>>>>>>>>> APIC ID: 1 ACPI BIOS Warning (bug): 32/64X length > >>>>>>>>>> mismatch in FADT/Gpe1Block: 0/32 > >>>>>>>>>> (20130823/tbfadt-601) ACPI BIOS Warning (bug): > >>>>>>>>>> Optional FADT field Gpe1Block has zero address or > >>>>>>>>>> length: 0x000000000000102C/0x0 > >>>>>>>>>> (20130823/tbfadt-630) > >>>>>>>>> > >>>>>>>>> It might be related as Gpe1Block describes a > >>>>>>>>> register set that IIRC is used to enter sleep > >>>>>>>>> states. Can you put your acpidump -t somewhere? > >>>>>>>>> (No need for -d as this is in the FADT, not the > >>>>>>>>> DSDT.) > >>>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> Here --> > >>>>>>>> http://people.freebsd.org/~sbruno/T61_acpidump.txt > >>>>>>> > >>>>>>> Ah, so the warning is due to the fact that the 'FACP' > >>>>>>> table has 'X_GPE1_BLOCK' but no 'GPE1_BLOCK'. (Note > >>>>>>> how it has both 'GPE0_BLOCK' and 'X_GPE0_BLOCK' which > >>>>>>> say the same thing.) Try this workaround to quiet the > >>>>>>> warning. I've no idea if it will help at all with > >>>>>>> suspend/resume. > >>>>>>> > >>>>>>> Index: > >>>>>>> sys/contrib/dev/acpica/components/tables/tbfadt.c > >>>>>>> =================================================================== > >>>>>>> > >>>>>>> > >> > >>>>>>> > --- tbfadt.c (revision 266442) > >>>>>>> +++ tbfadt.c (working copy) @@ -601,6 +601,10 @@ > >>>>>>> AcpiTbValidateFadt ( ACPI_BIOS_WARNING ((AE_INFO, > >>>>>>> "32/64X length mismatch in FADT/%s: %u/%u", Name, > >>>>>>> ACPI_MUL_8 (Length), Address64->BitWidth)); + if > >>>>>>> (Length == 0) + { + Length = ACPI_DIV_8 > >>>>>>> (Address64->BitWidth); + } } > >>>>>>> > >>>>>>> if (FadtInfoTable[i].Type & ACPI_FADT_REQUIRED) > >>>>>>> > >>>>>>> > >>>>>> > >>>>>> One warning went away, one remains, not sure if its > >>>>>> meaningful or not. > >>>>>> > >>>>>> ACPI BIOS Warning (bug): 32/64X length mismatch in > >>>>>> FADT/Gpe1Block: 0/32 (20130823/tbfadt-601) > >>>>> > >>>>> Yes, I didn't remove that warning, I just fixed it to use > >>>>> the 64-bit length when the 32-bit length was zero when that > >>>>> warning fires. Does this seem to have made any difference > >>>>> with anything on the laptop? (E.g. it might possibly > >>>>> affect hotkeys, etc.) > >>>>> > >>>> > >>>> > >>>> Believe it or not, but I just suspend/resumed on the thing, > >>>> TWICE. Once from the xfce menu -> suspend and once from > >>>> Fn->moonsymbolsuspendsleepthing on the F4 key. > >>>> > >>>> Good grief. Thanks John. > >>> > >>> Humm. I wonder if we can get the Intel guys to accept the > >>> patch upstream? > >> > >> Yes, ACPICA guys are very open to patches. Actually there are > >> several ways to report bugs and/or submit patches. > >> > >> Bug reports: https://bugs.acpica.org > >> > >> Developer ML: https://lists.acpica.org/mailman/listinfo/devel > >> > >> Source repository: https://github.com/acpica/acpica > >> > >> However, I'm afraid the following commit may have nullified your > >> patch. > >> > >> https://github.com/acpica/acpica/commit/8149df49 > > > > It looks to only be adjusting the preference for the Address > > portion. It still uses the length field from FADT and doesn't use > > the length from the GAS. > > Okay. > > BTW, I just read your patch carefully but I failed to understand how > shutting up a warning can fix any problem at all. Did you mean to > patch internal table? It shuts up the second warning. The first warning is still legit (there is a length mismatch), but it handles the special case of the 32-bit length being zero by using the 64-bit length. Once a valid length is set, the second warning goes away (and GPE1 works which apparently fixes resume for Sean). -- John Baldwin From owner-freebsd-acpi@FreeBSD.ORG Wed May 28 20:06:55 2014 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from hammer.pct.niksun.com (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by hub.freebsd.org (Postfix) with ESMTP id D6966D6C; Wed, 28 May 2014 20:06:54 +0000 (UTC) Message-ID: <538641DE.5030309@FreeBSD.org> Date: Wed, 28 May 2014 16:06:54 -0400 From: Jung-uk Kim User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: John Baldwin Subject: Re: Investigating failed suspend/resume T61 References: <1400861698.1126.0.camel@bruno> <201405281344.46430.jhb@freebsd.org> <538627E3.7080308@FreeBSD.org> <201405281556.37651.jhb@freebsd.org> In-Reply-To: <201405281556.37651.jhb@freebsd.org> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "freebsd-acpi@freebsd.org" X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 May 2014 20:06:55 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2014-05-28 15:56:37 -0400, John Baldwin wrote: > On Wednesday, May 28, 2014 2:16:03 pm Jung-uk Kim wrote: >> On 2014-05-28 13:44:46 -0400, John Baldwin wrote: >>> On Wednesday, May 28, 2014 12:44:44 pm Jung-uk Kim wrote: >>>> On 2014-05-28 12:20:24 -0400, John Baldwin wrote: >>>>> On Wednesday, May 28, 2014 12:10:55 pm Sean Bruno wrote: >>>>>> On Wed, 2014-05-28 at 10:54 -0400, John Baldwin wrote: >>>>>>> On Wednesday, May 28, 2014 7:08:36 am Sean Bruno >>>>>>> wrote: >>>>>>>> On Tue, 2014-05-27 at 16:14 -0400, John Baldwin >>>>>>>> wrote: >>>>>>>>> On Tuesday, May 27, 2014 1:39:48 pm Sean Bruno >>>>>>>>> wrote: >>>>>>>>>> On Tue, 2014-05-27 at 11:32 -0400, John Baldwin >>>>>>>>>> wrote: >>>>>>>>>>> On Friday, May 23, 2014 12:14:58 pm Sean Bruno >>>>>>>>>>> wrote: >>>>>>>>>>>> Trying to figure out the failures on suspend >>>>>>>>>>>> resume for the T61 I have. I see a little >>>>>>>>>>>> acpi error at host startup, but I don't think >>>>>>>>>>>> its related. However, I'm not sure what it >>>>>>>>>>>> means. >>>>>>>>>>>> >>>>>>>>>>>> sean >>>>>>>>>>>> >>>>>>>>>>>> ------ >>>>>>>>>>>> >>>>>>>>>>>> FreeBSD 11.0-CURRENT #1 r265820: Sat May 10 >>>>>>>>>>>> 15:13:37 PDT 2014 >>>>>>>>>>>> sbruno@bruno:/usr/obj/usr/src/sys/BRUNO >>>>>>>>>>>> amd64 FreeBSD clang version 3.4 >>>>>>>>>>>> (tags/RELEASE_34/final 197956) 20140216 VT: >>>>>>>>>>>> running with driver "vga". CPU: Intel(R) >>>>>>>>>>>> Core(TM)2 Duo CPU T7300 @ 2.00GHz >>>>>>>>>>>> (1995.04-MHz K8-class CPU) >>>>>>>>>>>> Origin="GenuineIntel" Id=0x6fa Family=0x6 >>>>>>>>>>>> Model=0xf Stepping=10 >>>>>>>>>>>> >>>>>>>>>>>> >>> > Features=0xbfebfbff >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>> >>> >> > Features2=0xe3bd >>>>>>>>>>>> AMD Features=0x20100800 AMD >>>>>>>>>>>> Features2=0x1 TSC: P-state invariant, >>>>>>>>>>>> performance statistics real memory = >>>>>>>>>>>> 2147483648 (2048 MB) avail memory = >>>>>>>>>>>> 2007138304 (1914 MB) Event timer "LAPIC" >>>>>>>>>>>> quality 400 ACPI APIC Table: >>>>>>>>>>> > FreeBSD/SMP: Multiprocessor System >>>>>>>>>>>> Detected: 2 CPUs FreeBSD/SMP: 1 package(s) x >>>>>>>>>>>> 2 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): >>>>>>>>>>>> APIC ID: 1 ACPI BIOS Warning (bug): 32/64X >>>>>>>>>>>> length mismatch in FADT/Gpe1Block: 0/32 >>>>>>>>>>>> (20130823/tbfadt-601) ACPI BIOS Warning >>>>>>>>>>>> (bug): Optional FADT field Gpe1Block has zero >>>>>>>>>>>> address or length: 0x000000000000102C/0x0 >>>>>>>>>>>> (20130823/tbfadt-630) >>>>>>>>>>> >>>>>>>>>>> It might be related as Gpe1Block describes a >>>>>>>>>>> register set that IIRC is used to enter sleep >>>>>>>>>>> states. Can you put your acpidump -t >>>>>>>>>>> somewhere? (No need for -d as this is in the >>>>>>>>>>> FADT, not the DSDT.) >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Here --> >>>>>>>>>> http://people.freebsd.org/~sbruno/T61_acpidump.txt >>>>>>>>> >>>>>>>>> >>>>>>>>>> Ah, so the warning is due to the fact that the 'FACP' >>>>>>>>> table has 'X_GPE1_BLOCK' but no 'GPE1_BLOCK'. >>>>>>>>> (Note how it has both 'GPE0_BLOCK' and >>>>>>>>> 'X_GPE0_BLOCK' which say the same thing.) Try this >>>>>>>>> workaround to quiet the warning. I've no idea if >>>>>>>>> it will help at all with suspend/resume. >>>>>>>>> >>>>>>>>> Index: >>>>>>>>> sys/contrib/dev/acpica/components/tables/tbfadt.c >>>>>>>>> =================================================================== >>>>>>>>> >>>>>>>>> >>>> >>>>>>>>> >> >>>>>>>>> - --- tbfadt.c (revision 266442) >>>>>>>>> +++ tbfadt.c (working copy) @@ -601,6 +601,10 @@ >>>>>>>>> AcpiTbValidateFadt ( ACPI_BIOS_WARNING ((AE_INFO, >>>>>>>>> "32/64X length mismatch in FADT/%s: %u/%u", Name, >>>>>>>>> ACPI_MUL_8 (Length), Address64->BitWidth)); + >>>>>>>>> if (Length == 0) + { + Length = ACPI_DIV_8 >>>>>>>>> (Address64->BitWidth); + } } >>>>>>>>> >>>>>>>>> if (FadtInfoTable[i].Type & ACPI_FADT_REQUIRED) >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> One warning went away, one remains, not sure if its >>>>>>>> meaningful or not. >>>>>>>> >>>>>>>> ACPI BIOS Warning (bug): 32/64X length mismatch in >>>>>>>> FADT/Gpe1Block: 0/32 (20130823/tbfadt-601) >>>>>>> >>>>>>> Yes, I didn't remove that warning, I just fixed it to >>>>>>> use the 64-bit length when the 32-bit length was zero >>>>>>> when that warning fires. Does this seem to have made >>>>>>> any difference with anything on the laptop? (E.g. it >>>>>>> might possibly affect hotkeys, etc.) >>>>>>> >>>>>> >>>>>> >>>>>> Believe it or not, but I just suspend/resumed on the >>>>>> thing, TWICE. Once from the xfce menu -> suspend and >>>>>> once from Fn->moonsymbolsuspendsleepthing on the F4 key. >>>>>> >>>>>> Good grief. Thanks John. >>>>> >>>>> Humm. I wonder if we can get the Intel guys to accept the >>>>> patch upstream? >>>> >>>> Yes, ACPICA guys are very open to patches. Actually there >>>> are several ways to report bugs and/or submit patches. >>>> >>>> Bug reports: https://bugs.acpica.org >>>> >>>> Developer ML: >>>> https://lists.acpica.org/mailman/listinfo/devel >>>> >>>> Source repository: https://github.com/acpica/acpica >>>> >>>> However, I'm afraid the following commit may have nullified >>>> your patch. >>>> >>>> https://github.com/acpica/acpica/commit/8149df49 >>> >>> It looks to only be adjusting the preference for the Address >>> portion. It still uses the length field from FADT and doesn't >>> use the length from the GAS. >> >> Okay. >> >> BTW, I just read your patch carefully but I failed to understand >> how shutting up a warning can fix any problem at all. Did you >> mean to patch internal table? > > It shuts up the second warning. The first warning is still legit > (there is a length mismatch), but it handles the special case of > the 32-bit length being zero by using the 64-bit length. Once a > valid length is set, the second warning goes away Yes, I know that. > (and GPE1 works which apparently fixes resume for Sean). It is really puzzling because your patch does not change anything functionally but shutting up the warning message. :-( Jung-uk Kim -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQEcBAEBAgAGBQJThkHeAAoJEHyflib82/FGC+YH/1rlo23HKXhrZVqGeP8zKsP/ OQj7rcF3sX0bvCymX/iq/I0IXLlAiZna/FRo+vq4RaL0gRHEefPdhg5z/K0UGd7l 00B3tgUhQglp0SooHCl+I97+9otHRCgSrlhQ1RCmIrMxlb+057Qn92GV6fGFpFTO f/NMrUp3SGmp/wI44B5KHryitoGJYvFEPkTA1uL2UkHzCqL313uOBIU2jtGPtqo4 cbCgiSPkfovbjM1qKBsyD2htme0k7Zqc734nFfT+ZxJEw5y2V6HUNCSnfmR520jk BRLGBsNJ1Xh3sIcE3QgEAueFnutYKsyOgOzbJp6Kjo8FXHHgaUcd5lSBtqo5pf4= =dTxX -----END PGP SIGNATURE----- From owner-freebsd-acpi@FreeBSD.ORG Wed May 28 21:30:01 2014 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 74D98481; Wed, 28 May 2014 21:30:01 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 48B2B276F; Wed, 28 May 2014 21:30:01 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 86437B939; Wed, 28 May 2014 17:29:59 -0400 (EDT) From: John Baldwin To: "Jung-uk Kim" Subject: Re: Investigating failed suspend/resume T61 Date: Wed, 28 May 2014 17:29:35 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20140415; KDE/4.5.5; amd64; ; ) References: <1400861698.1126.0.camel@bruno> <201405281556.37651.jhb@freebsd.org> <538641DE.5030309@FreeBSD.org> In-Reply-To: <538641DE.5030309@FreeBSD.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201405281729.35703.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 28 May 2014 17:29:59 -0400 (EDT) Cc: "freebsd-acpi@freebsd.org" X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 May 2014 21:30:01 -0000 On Wednesday, May 28, 2014 4:06:54 pm Jung-uk Kim wrote: > On 2014-05-28 15:56:37 -0400, John Baldwin wrote: > > On Wednesday, May 28, 2014 2:16:03 pm Jung-uk Kim wrote: > >> On 2014-05-28 13:44:46 -0400, John Baldwin wrote: > >>> On Wednesday, May 28, 2014 12:44:44 pm Jung-uk Kim wrote: > >>>> On 2014-05-28 12:20:24 -0400, John Baldwin wrote: > >>>>> On Wednesday, May 28, 2014 12:10:55 pm Sean Bruno wrote: > >>>>>> On Wed, 2014-05-28 at 10:54 -0400, John Baldwin wrote: > >>>>>>> On Wednesday, May 28, 2014 7:08:36 am Sean Bruno > >>>>>>> wrote: > >>>>>>>> On Tue, 2014-05-27 at 16:14 -0400, John Baldwin > >>>>>>>> wrote: > >>>>>>>>> On Tuesday, May 27, 2014 1:39:48 pm Sean Bruno > >>>>>>>>> wrote: > >>>>>>>>>> On Tue, 2014-05-27 at 11:32 -0400, John Baldwin > >>>>>>>>>> wrote: > >>>>>>>>>>> On Friday, May 23, 2014 12:14:58 pm Sean Bruno > >>>>>>>>>>> wrote: > >>>>>>>>>>>> Trying to figure out the failures on suspend > >>>>>>>>>>>> resume for the T61 I have. I see a little > >>>>>>>>>>>> acpi error at host startup, but I don't think > >>>>>>>>>>>> its related. However, I'm not sure what it > >>>>>>>>>>>> means. > >>>>>>>>>>>> > >>>>>>>>>>>> sean > >>>>>>>>>>>> > >>>>>>>>>>>> ------ > >>>>>>>>>>>> > >>>>>>>>>>>> FreeBSD 11.0-CURRENT #1 r265820: Sat May 10 > >>>>>>>>>>>> 15:13:37 PDT 2014 > >>>>>>>>>>>> sbruno@bruno:/usr/obj/usr/src/sys/BRUNO > >>>>>>>>>>>> amd64 FreeBSD clang version 3.4 > >>>>>>>>>>>> (tags/RELEASE_34/final 197956) 20140216 VT: > >>>>>>>>>>>> running with driver "vga". CPU: Intel(R) > >>>>>>>>>>>> Core(TM)2 Duo CPU T7300 @ 2.00GHz > >>>>>>>>>>>> (1995.04-MHz K8-class CPU) > >>>>>>>>>>>> Origin="GenuineIntel" Id=0x6fa Family=0x6 > >>>>>>>>>>>> Model=0xf Stepping=10 > >>>>>>>>>>>> > >>>>>>>>>>>> > >>> > > Features=0xbfebfbff > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>> > >>> > >> > > > Features2=0xe3bd > >>>>>>>>>>>> AMD Features=0x20100800 AMD > >>>>>>>>>>>> Features2=0x1 TSC: P-state invariant, > >>>>>>>>>>>> performance statistics real memory = > >>>>>>>>>>>> 2147483648 (2048 MB) avail memory = > >>>>>>>>>>>> 2007138304 (1914 MB) Event timer "LAPIC" > >>>>>>>>>>>> quality 400 ACPI APIC Table: >>>>>>>>>>>> > FreeBSD/SMP: Multiprocessor System > >>>>>>>>>>>> Detected: 2 CPUs FreeBSD/SMP: 1 package(s) x > >>>>>>>>>>>> 2 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): > >>>>>>>>>>>> APIC ID: 1 ACPI BIOS Warning (bug): 32/64X > >>>>>>>>>>>> length mismatch in FADT/Gpe1Block: 0/32 > >>>>>>>>>>>> (20130823/tbfadt-601) ACPI BIOS Warning > >>>>>>>>>>>> (bug): Optional FADT field Gpe1Block has zero > >>>>>>>>>>>> address or length: 0x000000000000102C/0x0 > >>>>>>>>>>>> (20130823/tbfadt-630) > >>>>>>>>>>> > >>>>>>>>>>> It might be related as Gpe1Block describes a > >>>>>>>>>>> register set that IIRC is used to enter sleep > >>>>>>>>>>> states. Can you put your acpidump -t > >>>>>>>>>>> somewhere? (No need for -d as this is in the > >>>>>>>>>>> FADT, not the DSDT.) > >>>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> Here --> > >>>>>>>>>> http://people.freebsd.org/~sbruno/T61_acpidump.txt > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>> > Ah, so the warning is due to the fact that the 'FACP' > >>>>>>>>> table has 'X_GPE1_BLOCK' but no 'GPE1_BLOCK'. > >>>>>>>>> (Note how it has both 'GPE0_BLOCK' and > >>>>>>>>> 'X_GPE0_BLOCK' which say the same thing.) Try this > >>>>>>>>> workaround to quiet the warning. I've no idea if > >>>>>>>>> it will help at all with suspend/resume. > >>>>>>>>> > >>>>>>>>> Index: > >>>>>>>>> sys/contrib/dev/acpica/components/tables/tbfadt.c > >>>>>>>>> =================================================================== > >>>>>>>>> > >>>>>>>>> > >>>> > >>>>>>>>> > >> > >>>>>>>>> > --- tbfadt.c (revision 266442) > >>>>>>>>> +++ tbfadt.c (working copy) @@ -601,6 +601,10 @@ > >>>>>>>>> AcpiTbValidateFadt ( ACPI_BIOS_WARNING ((AE_INFO, > >>>>>>>>> "32/64X length mismatch in FADT/%s: %u/%u", Name, > >>>>>>>>> ACPI_MUL_8 (Length), Address64->BitWidth)); + > >>>>>>>>> if (Length == 0) + { + Length = ACPI_DIV_8 > >>>>>>>>> (Address64->BitWidth); + } } > >>>>>>>>> > >>>>>>>>> if (FadtInfoTable[i].Type & ACPI_FADT_REQUIRED) > >>>>>>>>> > >>>>>>>>> > >>>>>>>> > >>>>>>>> One warning went away, one remains, not sure if its > >>>>>>>> meaningful or not. > >>>>>>>> > >>>>>>>> ACPI BIOS Warning (bug): 32/64X length mismatch in > >>>>>>>> FADT/Gpe1Block: 0/32 (20130823/tbfadt-601) > >>>>>>> > >>>>>>> Yes, I didn't remove that warning, I just fixed it to > >>>>>>> use the 64-bit length when the 32-bit length was zero > >>>>>>> when that warning fires. Does this seem to have made > >>>>>>> any difference with anything on the laptop? (E.g. it > >>>>>>> might possibly affect hotkeys, etc.) > >>>>>>> > >>>>>> > >>>>>> > >>>>>> Believe it or not, but I just suspend/resumed on the > >>>>>> thing, TWICE. Once from the xfce menu -> suspend and > >>>>>> once from Fn->moonsymbolsuspendsleepthing on the F4 key. > >>>>>> > >>>>>> Good grief. Thanks John. > >>>>> > >>>>> Humm. I wonder if we can get the Intel guys to accept the > >>>>> patch upstream? > >>>> > >>>> Yes, ACPICA guys are very open to patches. Actually there > >>>> are several ways to report bugs and/or submit patches. > >>>> > >>>> Bug reports: https://bugs.acpica.org > >>>> > >>>> Developer ML: > >>>> https://lists.acpica.org/mailman/listinfo/devel > >>>> > >>>> Source repository: https://github.com/acpica/acpica > >>>> > >>>> However, I'm afraid the following commit may have nullified > >>>> your patch. > >>>> > >>>> https://github.com/acpica/acpica/commit/8149df49 > >>> > >>> It looks to only be adjusting the preference for the Address > >>> portion. It still uses the length field from FADT and doesn't > >>> use the length from the GAS. > >> > >> Okay. > >> > >> BTW, I just read your patch carefully but I failed to understand > >> how shutting up a warning can fix any problem at all. Did you > >> mean to patch internal table? > > > > It shuts up the second warning. The first warning is still legit > > (there is a length mismatch), but it handles the special case of > > the 32-bit length being zero by using the 64-bit length. Once a > > valid length is set, the second warning goes away > > Yes, I know that. > > > (and GPE1 works which apparently fixes resume for Sean). > > It is really puzzling because your patch does not change anything > functionally but shutting up the warning message. :-( Err, I think it enables GPE1 as otherwise ACPICA assumes GPE1 has a length of zero (and is thus invalid)? Perhaps _PTS wants to frob something that uses GPE1 that this fixes? -- John Baldwin From owner-freebsd-acpi@FreeBSD.ORG Wed May 28 22:14:35 2014 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from hammer.pct.niksun.com (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by hub.freebsd.org (Postfix) with ESMTP id CFD9C18A; Wed, 28 May 2014 22:14:34 +0000 (UTC) Message-ID: <53865FCA.6080407@FreeBSD.org> Date: Wed, 28 May 2014 18:14:34 -0400 From: Jung-uk Kim User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: John Baldwin Subject: Re: Investigating failed suspend/resume T61 References: <1400861698.1126.0.camel@bruno> <201405281556.37651.jhb@freebsd.org> <538641DE.5030309@FreeBSD.org> <201405281729.35703.jhb@freebsd.org> In-Reply-To: <201405281729.35703.jhb@freebsd.org> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "freebsd-acpi@freebsd.org" X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 May 2014 22:14:35 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2014-05-28 17:29:35 -0400, John Baldwin wrote: > Err, I think it enables GPE1 as otherwise ACPICA assumes GPE1 has a > length of zero (and is thus invalid)? Perhaps _PTS wants to frob > something that uses GPE1 that this fixes? static void AcpiTbValidateFadt ( void) { ... UINT8 Length; ... for (i = 0; i < ACPI_FADT_INFO_ENTRIES; i++) { ... Length = *ACPI_ADD_PTR (UINT8, &AcpiGbl_FADT, FadtInfoTable[i].Length); ... Note the Length is read from the internal FADT and it is NOT a pointer. ... if (Address64->Address && (ACPI_MUL_8 (Length) <= ACPI_UINT8_MAX) && (Address64->BitWidth != ACPI_MUL_8 (Length))) { ACPI_BIOS_WARNING ((AE_INFO, "32/64X length mismatch in FADT/%s: %u/%u", Name, ACPI_MUL_8 (Length), Address64->BitWidth)); + if (Length == 0) + { + Length = ACPI_DIV_8 (Address64->BitWidth); + } } ... } } AFAICT, it does change anything in AcpiGbl_FADT. If you really wanted to "patch" it, you had to do something like this: + if (Length == 0) + { + Length = ACPI_DIV_8 (Address64->BitWidth); + *ACPI_ADD_PTR (UINT8, + &AcpiGbl_FADT, FadtInfoTable[i].Length) = Length; + } However, it had to be done from AcpiEvGpeInitialize() in sys/contrib/dev/acpica/components/events/evgpeinit.c, IMHO. ACPI_STATUS AcpiEvGpeInitialize ( void) { ... if (AcpiGbl_FADT.Gpe1BlockLength && ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ HERE!!! AcpiGbl_FADT.XGpe1Block.Address) { ... What did I miss? Jung-uk Kim -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQEcBAEBAgAGBQJThl/KAAoJEHyflib82/FGessH+gOcPzgbg8/kPbpkHl6y6n1n 1vMgky6TB1v5ul48YEtnHQybK0pFm/9UVaxOnJFEAKmDzVyr739xFnveht3g1otQ LLM0vDh6dLNV2qlmLSVNQQm3Fsvu0NdF737dsSNyksi6vvKAjb7o45nn1UmkQmv/ lqNjSEaSuW8dLR9xuvvQvUUFgxGyGM3UuAk7tHOF7PQo/EwRvbkc2W0cOfRLPXqP Se+B/8kggxSoV+yj/kHdoYm5wb/dsVfudkh7grKtm/C2iH/PqAhnYDLWEfbSZbpz Vy3C+r4/uz4I3CaV7Txz13plbYqIJ1oo3sdUxUdLH+SfbaY16+adHJZFfagVyOU= =n4SF -----END PGP SIGNATURE----- From owner-freebsd-acpi@FreeBSD.ORG Wed May 28 22:22:47 2014 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from hammer.pct.niksun.com (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by hub.freebsd.org (Postfix) with ESMTP id AF948491; Wed, 28 May 2014 22:22:47 +0000 (UTC) Message-ID: <538661B7.1020203@FreeBSD.org> Date: Wed, 28 May 2014 18:22:47 -0400 From: Jung-uk Kim User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: John Baldwin Subject: Re: Investigating failed suspend/resume T61 References: <1400861698.1126.0.camel@bruno> <201405281556.37651.jhb@freebsd.org> <538641DE.5030309@FreeBSD.org> <201405281729.35703.jhb@freebsd.org> <53865FCA.6080407@FreeBSD.org> In-Reply-To: <53865FCA.6080407@FreeBSD.org> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "freebsd-acpi@freebsd.org" X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 May 2014 22:22:48 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2014-05-28 18:14:34 -0400, Jung-uk Kim wrote: > On 2014-05-28 17:29:35 -0400, John Baldwin wrote: >> Err, I think it enables GPE1 as otherwise ACPICA assumes GPE1 has >> a length of zero (and is thus invalid)? Perhaps _PTS wants to >> frob something that uses GPE1 that this fixes? > > static void AcpiTbValidateFadt ( void) { ... UINT8 > Length; ... for (i = 0; i < ACPI_FADT_INFO_ENTRIES; i++) { ... > Length = *ACPI_ADD_PTR (UINT8, &AcpiGbl_FADT, > FadtInfoTable[i].Length); ... > > Note the Length is read from the internal FADT and it is NOT a > pointer. > > ... if (Address64->Address && (ACPI_MUL_8 (Length) <= > ACPI_UINT8_MAX) && (Address64->BitWidth != ACPI_MUL_8 (Length))) { > ACPI_BIOS_WARNING ((AE_INFO, "32/64X length mismatch in FADT/%s: > %u/%u", Name, ACPI_MUL_8 (Length), Address64->BitWidth)); + if > (Length == 0) + { + Length = ACPI_DIV_8 > (Address64->BitWidth); + } } ... } } > > AFAICT, it does change anything in AcpiGbl_FADT. ... ^ not Sorry for the typo. Jung-uk Kim -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQEcBAEBAgAGBQJThmG3AAoJEHyflib82/FGlGEIAIZBOaLiQSpFT8ziuK8vPP7s WwI69o7tYzso16pbBjtaCV7eSD2uku+inSqNigmnp+FwvZGr4wxTOQSYMLSht9kw CkiEjZ2wN4xA5rTCfvZzHlUgnVk4M9DAXjILiZ5W6+aURo5xRwkFNjVVQXPh2JXn /JwmP7yJrRyVcm3KGKTR1c3rqoBzps3RP9RSz7I2bPZwzRfBTTTgiuuAjDy3LdUf ozz6zGkknTGg/tPSATZULPWrzhfVWjfzwsTO3MbzQwynXtjVa0nmAO0Ug0iBiB0g 9ls1TdH/JSwaMMG3/8QlIkMp95jD5aTtpT2x1I78iWbptEX5N4pJ7uQctsFn09o= =j9xm -----END PGP SIGNATURE----- From owner-freebsd-acpi@FreeBSD.ORG Wed May 28 22:43:59 2014 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from hammer.pct.niksun.com (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by hub.freebsd.org (Postfix) with ESMTP id 35FCD87D; Wed, 28 May 2014 22:43:59 +0000 (UTC) Message-ID: <538666AE.4030501@FreeBSD.org> Date: Wed, 28 May 2014 18:43:58 -0400 From: Jung-uk Kim User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: John Baldwin Subject: Re: Investigating failed suspend/resume T61 References: <1400861698.1126.0.camel@bruno> <201405281556.37651.jhb@freebsd.org> <538641DE.5030309@FreeBSD.org> <201405281729.35703.jhb@freebsd.org> In-Reply-To: <201405281729.35703.jhb@freebsd.org> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "freebsd-acpi@freebsd.org" X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 May 2014 22:43:59 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2014-05-28 17:29:35 -0400, John Baldwin wrote: > Err, I think it enables GPE1 as otherwise ACPICA assumes GPE1 has a > length of zero (and is thus invalid)? BTW, ACPI 5.0a (page 121) says: "This is an optional field; if this register block is not supported, this field contains zero." Therefore, we must assume X_GPE1_BLK it is NOT supported. Jung-uk Kim -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQEcBAEBAgAGBQJThmauAAoJEHyflib82/FG0rUIAJdLFd+Bd5KXF5nzSX9maVS2 71h9iM5oJE6WjLdMAt7nD2p1seiicVYkxm+jLU08EegkV9QH3506wt8KOXxtvIMG XNuLzTB7cukqYoMXfsrA2ojis4YDGADhAwuT6UpsJq8iblwiA4Ec9pvfli4l/RwU UObGkQIbKJ1BLspFHFClbXrqBqCp5Ou6s8Aga0AsqR4BIqgpnrtV+LQEmPIiUCRh W3PLu+/VHmBvTaU7YhUhmsN0BDC1CXhGwi6w614uHWB9GBym7xIuFjjREMoLPX2D cL9gidZBj0TAtPj2oe/geYRb3Ta47Migo/FAkkpp5hqd9/xrr9CImK9f37yzqzU= =Yxlz -----END PGP SIGNATURE----- From owner-freebsd-acpi@FreeBSD.ORG Wed May 28 23:40:11 2014 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from hammer.pct.niksun.com (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by hub.freebsd.org (Postfix) with ESMTP id 223E0500; Wed, 28 May 2014 23:40:11 +0000 (UTC) Message-ID: <538673DA.5030105@FreeBSD.org> Date: Wed, 28 May 2014 19:40:10 -0400 From: Jung-uk Kim User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: John Baldwin Subject: Re: Investigating failed suspend/resume T61 References: <1400861698.1126.0.camel@bruno> <201405281556.37651.jhb@freebsd.org> <538641DE.5030309@FreeBSD.org> <201405281729.35703.jhb@freebsd.org> <53865FCA.6080407@FreeBSD.org> In-Reply-To: <53865FCA.6080407@FreeBSD.org> X-Enigmail-Version: 1.6 Content-Type: multipart/mixed; boundary="------------040405030706020903010103" Cc: "freebsd-acpi@freebsd.org" X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 May 2014 23:40:11 -0000 This is a multi-part message in MIME format. --------------040405030706020903010103 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2014-05-28 18:14:34 -0400, Jung-uk Kim wrote: > However, it had to be done from AcpiEvGpeInitialize() in > sys/contrib/dev/acpica/components/events/evgpeinit.c, IMHO. > > ACPI_STATUS AcpiEvGpeInitialize ( void) { ... if > (AcpiGbl_FADT.Gpe1BlockLength && ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > HERE!!! AcpiGbl_FADT.XGpe1Block.Address) { ... Please see the attached patch (not tested). Probably, this is what you really meant to test. Jung-uk Kim -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQEcBAEBAgAGBQJThnPaAAoJEHyflib82/FGKbcIAIfNGtaEDNhEuGUTTr7wSgCE DIAIt/QdTeICyOiR8t9r8SrOKrnrloPohKTqtujhkliiAN7bKbjodeN3+/50H7a9 Ura6075gCtds/6Im/hOiFMyclWBA88HR+lUpct3RJD9Ag70qcfEQloIiVI1pkm2U X1YRRgS0liUbG4NKoZuAl2xPxyO+DS+jC7FKO/Ti4Bl4buM+R/lO0fvAj6ZZoRQ4 JnLGsOPMrmPLDfug6dZSCruG8rcetrh+0PYVn3En4ecZ8rzsY+IW5qR+57+8rcXX Jh9JsWyS0eYiGP62yOKzdj+9GSH85MJJC0fvtOgYe42eA8UU3bf8GAD5Vynl+gU= =4thP -----END PGP SIGNATURE----- --------------040405030706020903010103 Content-Type: text/x-patch; name="gpe.diff" Content-Transfer-Encoding: 8bit Content-Disposition: attachment; filename="gpe.diff" Index: sys/contrib/dev/acpica/components/events/evgpeinit.c =================================================================== --- sys/contrib/dev/acpica/components/events/evgpeinit.c (리비전 266821) +++ sys/contrib/dev/acpica/components/events/evgpeinit.c (ìž‘ì—… 사본) @@ -128,12 +128,19 @@ AcpiEvGpeInitialize ( * If EITHER the register length OR the block address are zero, then that * particular block is not supported. */ - if (AcpiGbl_FADT.Gpe0BlockLength && - AcpiGbl_FADT.XGpe0Block.Address) + if ((AcpiGbl_FADT.Gpe0Block && AcpiGbl_FADT.Gpe0BlockLength) || + (AcpiGbl_FADT.XGpe0Block.Address && AcpiGbl_FADT.XGpe0Block.BitWidth)) { /* GPE block 0 exists (has both length and address > 0) */ - RegisterCount0 = (UINT16) (AcpiGbl_FADT.Gpe0BlockLength / 2); + if (AcpiGbl_FADT.XGpe0Block.Address && AcpiGbl_FADT.XGpe0Block.BitWidth) + { + RegisterCount0 = ACPI_DIV_8 (AcpiGbl_FADT.XGpe0Block.BitWidth) / 2; + } + else + { + RegisterCount0 = AcpiGbl_FADT.Gpe0BlockLength / 2; + } GpeNumberMax = (RegisterCount0 * ACPI_GPE_REGISTER_WIDTH) - 1; /* Install GPE Block 0 */ @@ -149,12 +156,19 @@ AcpiEvGpeInitialize ( } } - if (AcpiGbl_FADT.Gpe1BlockLength && - AcpiGbl_FADT.XGpe1Block.Address) + if ((AcpiGbl_FADT.Gpe1Block && AcpiGbl_FADT.Gpe1BlockLength) || + (AcpiGbl_FADT.XGpe1Block.Address && AcpiGbl_FADT.XGpe1Block.BitWidth)) { /* GPE block 1 exists (has both length and address > 0) */ - RegisterCount1 = (UINT16) (AcpiGbl_FADT.Gpe1BlockLength / 2); + if (AcpiGbl_FADT.XGpe1Block.Address && AcpiGbl_FADT.XGpe1Block.BitWidth) + { + RegisterCount1 = ACPI_DIV_8 (AcpiGbl_FADT.XGpe1Block.BitWidth) / 2; + } + else + { + RegisterCount1 = AcpiGbl_FADT.Gpe1BlockLength / 2; + } /* Check for GPE0/GPE1 overlap (if both banks exist) */ --------------040405030706020903010103-- From owner-freebsd-acpi@FreeBSD.ORG Thu May 29 13:16:49 2014 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3A9E0F29; Thu, 29 May 2014 13:16:49 +0000 (UTC) Received: from mail.ignoranthack.me (ignoranthack.me [199.102.79.106]) (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 19BE52884; Thu, 29 May 2014 13:16:48 +0000 (UTC) Received: from [192.168.200.105] (c-50-131-4-11.hsd1.ca.comcast.net [50.131.4.11]) (using SSLv3 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: sbruno@ignoranthack.me) by mail.ignoranthack.me (Postfix) with ESMTPSA id 212E8194139; Thu, 29 May 2014 13:16:42 +0000 (UTC) Subject: Re: Investigating failed suspend/resume T61 From: Sean Bruno Reply-To: sbruno@freebsd.org To: Jung-uk Kim In-Reply-To: <538666AE.4030501@FreeBSD.org> References: <1400861698.1126.0.camel@bruno> <201405281556.37651.jhb@freebsd.org> <538641DE.5030309@FreeBSD.org> <201405281729.35703.jhb@freebsd.org> <538666AE.4030501@FreeBSD.org> Content-Type: text/plain; charset="us-ascii" Date: Thu, 29 May 2014 06:16:41 -0700 Message-ID: <1401369401.1100.1.camel@bruno> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: "freebsd-acpi@freebsd.org" X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 May 2014 13:16:49 -0000 On Wed, 2014-05-28 at 18:43 -0400, Jung-uk Kim wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 2014-05-28 17:29:35 -0400, John Baldwin wrote: > > Err, I think it enables GPE1 as otherwise ACPICA assumes GPE1 has a > > length of zero (and is thus invalid)? > > BTW, ACPI 5.0a (page 121) says: > > "This is an optional field; if this register block is not supported, > this field contains zero." > > Therefore, we must assume X_GPE1_BLK it is NOT supported. > > Jung-uk Kim So, reverting John's changes and applying yours seems to do new things while not quieting the old error messages. Perhaps this is significant? real memory = 2147483648 (2048 MB) avail memory = 2007089152 (1914 MB) Event timer "LAPIC" quality 400 ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ACPI BIOS Warning (bug): 32/64X length mismatch in FADT/Gpe1Block: 0/32 (20130823/tbfadt-601) ACPI BIOS Warning (bug): Optional FADT field Gpe1Block has zero address or length: 0x000000000000102C/0x0 (20130823/tbfadt-630) ioapic0: Changing APIC ID to 1 ioapic0 irqs 0-23 on motherboard random: initialized kbd1 at kbdmux0 acpi0: on motherboard CPU0: local APIC error 0x40 ACPI Error: GPE0 block (GPE 0 to 31) overlaps the GPE1 block (GPE 0 to 15) - Ignoring GPE1 (20130823/evgpeinit-178) acpi_ec0: port 0x62,0x66 on acpi0 acpi0: Power Button (fixed) acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, 7df00000 (3) failed From owner-freebsd-acpi@FreeBSD.ORG Thu May 29 13:51:09 2014 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 69484312; Thu, 29 May 2014 13:51:09 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 42C6C2BD0; Thu, 29 May 2014 13:51:09 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 4D8C9B9CE; Thu, 29 May 2014 09:51:08 -0400 (EDT) From: John Baldwin To: sbruno@freebsd.org Subject: Re: Investigating failed suspend/resume T61 Date: Thu, 29 May 2014 09:30:00 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20140415; KDE/4.5.5; amd64; ; ) References: <1400861698.1126.0.camel@bruno> <538666AE.4030501@FreeBSD.org> <1401369401.1100.1.camel@bruno> In-Reply-To: <1401369401.1100.1.camel@bruno> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201405290930.00425.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Thu, 29 May 2014 09:51:08 -0400 (EDT) Cc: "freebsd-acpi@freebsd.org" X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 May 2014 13:51:09 -0000 On Thursday, May 29, 2014 9:16:41 am Sean Bruno wrote: > On Wed, 2014-05-28 at 18:43 -0400, Jung-uk Kim wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > On 2014-05-28 17:29:35 -0400, John Baldwin wrote: > > > Err, I think it enables GPE1 as otherwise ACPICA assumes GPE1 has a > > > length of zero (and is thus invalid)? > > > > BTW, ACPI 5.0a (page 121) says: > > > > "This is an optional field; if this register block is not supported, > > this field contains zero." > > > > Therefore, we must assume X_GPE1_BLK it is NOT supported. > > > > Jung-uk Kim > > So, reverting John's changes and applying yours seems to do new things > while not quieting the old error messages. Perhaps this is significant? > > real memory = 2147483648 (2048 MB) > avail memory = 2007089152 (1914 MB) > Event timer "LAPIC" quality 400 > ACPI APIC Table: > FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs > FreeBSD/SMP: 1 package(s) x 2 core(s) > cpu0 (BSP): APIC ID: 0 > cpu1 (AP): APIC ID: 1 > ACPI BIOS Warning (bug): 32/64X length mismatch in FADT/Gpe1Block: 0/32 > (20130823/tbfadt-601) > ACPI BIOS Warning (bug): Optional FADT field Gpe1Block has zero address > or length: 0x000000000000102C/0x0 (20130823/tbfadt-630) > ioapic0: Changing APIC ID to 1 > ioapic0 irqs 0-23 on motherboard > random: initialized > kbd1 at kbdmux0 > acpi0: on motherboard > CPU0: local APIC error 0x40 > ACPI Error: GPE0 block (GPE 0 to 31) overlaps the GPE1 block (GPE 0 to > 15) - Ignoring GPE1 (20130823/evgpeinit-178) Actually, I think all these patches are changing nothing, and this actually points out that I misread your FADT at the first. GPE1 should actually be ignored since it does in fact overlap. Can you just try reverting all your changes and seeing if suspend/resume works? -- John Baldwin From owner-freebsd-acpi@FreeBSD.ORG Thu May 29 13:51:08 2014 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 36D8230F; Thu, 29 May 2014 13:51:08 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 10B482BCE; Thu, 29 May 2014 13:51:08 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 0E18AB9CC; Thu, 29 May 2014 09:51:07 -0400 (EDT) From: John Baldwin To: "Jung-uk Kim" Subject: Re: Investigating failed suspend/resume T61 Date: Thu, 29 May 2014 09:25:22 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20140415; KDE/4.5.5; amd64; ; ) References: <1400861698.1126.0.camel@bruno> <201405281729.35703.jhb@freebsd.org> <53865FCA.6080407@FreeBSD.org> In-Reply-To: <53865FCA.6080407@FreeBSD.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201405290925.22969.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Thu, 29 May 2014 09:51:07 -0400 (EDT) Cc: "freebsd-acpi@freebsd.org" X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 May 2014 13:51:08 -0000 On Wednesday, May 28, 2014 6:14:34 pm Jung-uk Kim wrote: > On 2014-05-28 17:29:35 -0400, John Baldwin wrote: > > Err, I think it enables GPE1 as otherwise ACPICA assumes GPE1 has a > > length of zero (and is thus invalid)? Perhaps _PTS wants to frob > > something that uses GPE1 that this fixes? > > static void > AcpiTbValidateFadt ( > void) > { > ... > UINT8 Length; > ... > for (i = 0; i < ACPI_FADT_INFO_ENTRIES; i++) > { > ... > Length = *ACPI_ADD_PTR (UINT8, > &AcpiGbl_FADT, FadtInfoTable[i].Length); > ... > > Note the Length is read from the internal FADT and it is NOT a pointer. > > ... > if (Address64->Address && > (ACPI_MUL_8 (Length) <= ACPI_UINT8_MAX) && > (Address64->BitWidth != ACPI_MUL_8 (Length))) > { > ACPI_BIOS_WARNING ((AE_INFO, > "32/64X length mismatch in FADT/%s: %u/%u", > Name, ACPI_MUL_8 (Length), Address64->BitWidth)); > + if (Length == 0) > + { > + Length = ACPI_DIV_8 (Address64->BitWidth); > + } > } > ... > } > } > > AFAICT, it does change anything in AcpiGbl_FADT. If you really wanted > to "patch" it, you had to do something like this: > > + if (Length == 0) > + { > + Length = ACPI_DIV_8 (Address64->BitWidth); > + *ACPI_ADD_PTR (UINT8, > + &AcpiGbl_FADT, FadtInfoTable[i].Length) = Length; > + } > > However, it had to be done from AcpiEvGpeInitialize() in > sys/contrib/dev/acpica/components/events/evgpeinit.c, IMHO. > > ACPI_STATUS > AcpiEvGpeInitialize ( > void) > { > ... > if (AcpiGbl_FADT.Gpe1BlockLength && > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > HERE!!! > AcpiGbl_FADT.XGpe1Block.Address) > { > ... > > What did I miss? Nothing, I've no idea how this could possibly have affected suspend/resume on Sean's laptop then. Maybe it was just a coincidence. -- John Baldwin From owner-freebsd-acpi@FreeBSD.ORG Wed Jun 4 06:46:14 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 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9A766837; Wed, 4 Jun 2014 06:46:14 +0000 (UTC) Received: from mail-we0-x230.google.com (mail-we0-x230.google.com [IPv6:2a00:1450:400c:c03::230]) (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 0B52F2C1A; Wed, 4 Jun 2014 06:46:13 +0000 (UTC) Received: by mail-we0-f176.google.com with SMTP id q59so7719651wes.7 for ; Tue, 03 Jun 2014 23:46:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=Bo+Vy3ocUgRWZFA6lFJbBj7FWUbNkXFeomSMjYcDGsE=; b=QpBD883KOAewizwNgDA69RkWDfyIyyenDLmNN1Q8XSdp1cmwt60Dtu30Nys3zBt5mZ KNqbA/r9Xj09aODGbh92k91DbpoGZ2NeQ4MkxVRWU1xuUROIaTowf7JmQrRm2OQ3asTk G11sIV/IMuG8ibdDSaEJWPBbIwfJNKvObXT0Y0cmEgR8qIF2a0ciCgVxjimHuZkK1zRm xRMi1DB5TqadinlennNK9o3onu9k3lRfVuI5FOsxJfZ4j/Ef9J6UDoKLMcPijhy7JJEU ARtBFwNkBN3vTjNFAgOK2P0aqe5YgLdn0d7L8CZfMCZ6ef7drRJ62bKKjUx4uOmUjRUa k+/Q== X-Received: by 10.180.7.137 with SMTP id j9mr2018955wia.7.1401864372294; Tue, 03 Jun 2014 23:46:12 -0700 (PDT) Received: from [192.168.1.53] (LNantes-156-74-19-50.w82-127.abo.wanadoo.fr. [82.127.90.50]) by mx.google.com with ESMTPSA id nb8sm46511686wic.18.2014.06.03.23.46.11 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 03 Jun 2014 23:46:11 -0700 (PDT) Message-ID: <538EC0B3.6050506@gmail.com> Date: Wed, 04 Jun 2014 08:46:11 +0200 From: David Demelier User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: freebsd-acpi@freebsd.org, mav@freebsd.org Subject: Re: proposal: set default lid state to S3, performance/economy Cx states to Cmax References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jun 2014 06:46:14 -0000 Le 04/05/2014 10:27, Adrian Chadd a écrit : > Hi, > > I'd like to propose flipping a few things: > > * Flipping the default lid state to S3. I think ACPI suspend/resume > seems to work well enough these days and I've not met anyone lately > who expects the default from their laptop to be "stay awake with the > lid shut." > * Save chip bugs that we should add workarounds for, we should be OK > to enter lower sleep states when idling. Flipping this may expose some > further crazy driver, platform or timer bugs, but they again likely > should be fixed. > > what do people think? > > > -a > > > Index: etc/defaults/rc.conf > =================================================================== > --- etc/defaults/rc.conf (revision 265255) > +++ etc/defaults/rc.conf (working copy) > @@ -642,9 +642,9 @@ > devfs_set_rulesets="" # A list of /mount/dev=ruleset_name settings to > # apply (must be mounted already, i.e. fstab(5)) > devfs_load_rulesets="YES" # Enable to always load the default rulesets > -performance_cx_lowest="HIGH" # Online CPU idle state > +performance_cx_lowest="Cmax" # Online CPU idle state > performance_cpu_freq="NONE" # Online CPU frequency > -economy_cx_lowest="HIGH" # Offline CPU idle state > +economy_cx_lowest="Cmax" # Offline CPU idle state > economy_cpu_freq="NONE" # Offline CPU frequency > virecover_enable="YES" # Perform housekeeping for the vi(1) editor > ugidfw_enable="NO" # Load mac_bsdextended(4) rules on boot > Index: sys/dev/acpica/acpi.c > =================================================================== > --- sys/dev/acpica/acpi.c (revision 265255) > +++ sys/dev/acpica/acpi.c (working copy) > @@ -620,11 +620,12 @@ > > /* > * Dispatch the default sleep state to devices. The lid switch is set > - * to UNKNOWN by default to avoid surprising users. > + * to S3 to mirror what everything else iBook and later does. > */ > sc->acpi_power_button_sx = acpi_sleep_states[ACPI_STATE_S5] ? > ACPI_STATE_S5 : ACPI_STATE_UNKNOWN; > - sc->acpi_lid_switch_sx = ACPI_STATE_UNKNOWN; > + sc->acpi_lid_switch_sx = acpi_sleep_states[ACPI_STATE_S3] ? > + ACPI_STATE_S3 : ACPI_STATE_UNKNOWN; > sc->acpi_standby_sx = acpi_sleep_states[ACPI_STATE_S1] ? > ACPI_STATE_S1 : ACPI_STATE_UNKNOWN; > sc->acpi_suspend_sx = acpi_sleep_states[ACPI_STATE_S3] ? > _______________________________________________ > freebsd-acpi@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-acpi > To unsubscribe, send any mail to "freebsd-acpi-unsubscribe@freebsd.org" For me, I still have problems with suspend / resume (the sound does not work after resume), I didn't try with new KMS / vt but I'm afraid. I'm not sure if it's already a good idea at that time :(. Regards, David. From owner-freebsd-acpi@FreeBSD.ORG Wed Jun 4 12:56:01 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 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5E0CB862 for ; Wed, 4 Jun 2014 12:56:01 +0000 (UTC) Received: from nm16-vm6.access.bullet.mail.gq1.yahoo.com (nm16-vm6.access.bullet.mail.gq1.yahoo.com [216.39.63.164]) (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 2BB742F0D for ; Wed, 4 Jun 2014 12:56:00 +0000 (UTC) Received: from [216.39.60.169] by nm16.access.bullet.mail.gq1.yahoo.com with NNFMP; 04 Jun 2014 12:53:11 -0000 Received: from [98.138.104.96] by tm5.access.bullet.mail.gq1.yahoo.com with NNFMP; 04 Jun 2014 12:53:11 -0000 Received: from [127.0.0.1] by smtp116.sbc.mail.ne1.yahoo.com with NNFMP; 04 Jun 2014 12:53:11 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1401886391; bh=vlO11brFSNjkpO+f8G5n57I4nDnwPUNeammxcvAY9cc=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:Content-Type:Content-Transfer-Encoding; b=iki8fjfIfFlSEAunYEcXz7jGggVLYEFjBXD843uNrzc6NuusNUK++sai3yPeKdbMp8Fn92AHBNP/DHNm6/uXMQPWNu9zIir7NSwtAbiK/msNvsjxczFu8hJVCe99PQ1FqjlbxdBUgmx5DgT5SLImmYTeOWyaST+J8BaIbzSqNBA= X-Yahoo-Newman-Id: 258755.26459.bm@smtp116.sbc.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: Gxaz1MYVM1kC9jcRwiVGXpPs6uYGrfCt_QwwEmtMA_WDURp BwDX9sKMPGRj16og34DN1XmWwljkyWLAsnIFfr4CwH9fU1KSXwKtF9hIusWE Km.N49I5ggzdg6DmpeeymBshYaSjrMOtZ1QF8glKi35cMlRQuhGzEM7cGTkj hlUNZZfoETmbcT2uTU_uZwNP0IEe7dvlgW32JrNFzwPqJ5spE8QBZp7zZS5z b4d1LjhQeleum8p6s4t.Kxe5IWZ1lKC5N7JdBCUR5PaqRTmVmE.AsSxsYnx. xAwm0Rkrgyl3V_8.BIhUYWQDE3ubniUIlVpznDfLIn4bs6_hnbOJAWpR_d6p MgeUp7L3vMM3YDMqWtXCgdzYTx9uuvWsKiil.Yc5jIhgjQXOMLOe_1DNxjpX 52Aud7F5MXIKIXFHj50QV.hLazO.EG3w9hqZogs34keeYPMR.tslyQyzME26 Yu72lC0TMjMwyZIoK4XjaHqekz7d6Gx8HoDOijSS_ZxWrJwlxCKENnGvhGkh OH2orF6IbAyVkpRfYEZeu_qMQ_5Af96rAJC6ZTIYOcGIPGdfYY_lbXVHCi8O h.0oc9eI8UQ-- X-Yahoo-SMTP: OKD1keCswBBTAmAF1s00hLyKW3wE3YfSK0Eazl6b4VZG4LTqJxg- X-Rocket-Received: from [10.82.223.159] (Anthony.B.Jenkins@64.102.254.33 with plain [98.138.84.52]) by smtp116.sbc.mail.ne1.yahoo.com with SMTP; 04 Jun 2014 12:53:11 +0000 UTC Message-ID: <538F16B5.8040208@att.net> Date: Wed, 04 Jun 2014 08:53:09 -0400 From: Anthony Jenkins User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: freebsd-acpi@freebsd.org Subject: [PATCH] Naive implementation of AcpiExCmosSpaceHandler() Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jun 2014 12:56:01 -0000 Here's a naive implementation of AcpiExCmosSpaceHandler(), it simply uses I/O ports 0x70 and 0x71 to read/write CMOS registers using AcpiHwWritePort()/AcpiHwReadPort() calls. I'm new(ish) to the ACPICA subsystem and I'm probably not going about this the right way - I think I should implement an actual CMOS RTC device which handles the three PNP IDs that represent those hardware devices, but this was good enough for what I was trying to do. This fixes my HP Envy 6z-1100 laptop's suspend/resume (except video fails to resume, but I believe that's due to backlight handling from my research). Before, initiating a suspend (zzz(8)) caused the laptop to seemingly suspend and immediately resume. Now trying to track down the backlight issue. I implemented a missing _BQC method which returns a single value from the _BCL listj; I think Linux does some kind of vendor backlight control method if this method is missing. Suggestions welcome. Anthony Jenkins Index: sys/contrib/dev/acpica/components/events/evhandler.c =================================================================== --- sys/contrib/dev/acpica/components/events/evhandler.c (revision 266756) +++ sys/contrib/dev/acpica/components/events/evhandler.c (working copy) @@ -70,6 +70,7 @@ ACPI_ADR_SPACE_SYSTEM_MEMORY, ACPI_ADR_SPACE_SYSTEM_IO, ACPI_ADR_SPACE_PCI_CONFIG, + ACPI_ADR_SPACE_CMOS, ACPI_ADR_SPACE_DATA_TABLE }; @@ -379,9 +380,12 @@ */ if ((Node->Type != ACPI_TYPE_DEVICE) && (Node->Type != ACPI_TYPE_PROCESSOR) && + (Node->Type != ACPI_TYPE_REGION) && (Node->Type != ACPI_TYPE_THERMAL) && (Node != AcpiGbl_RootNode)) { + ACPI_DEBUG_PRINT ((ACPI_DB_OPREGION, + "Device %p not a DEVICE, PROCESSOR, REGION, THERMAL type or root node.\n", Node)); Status = AE_BAD_PARAMETER; goto UnlockAndExit; } Index: sys/contrib/dev/acpica/components/executer/exregion.c =================================================================== --- sys/contrib/dev/acpica/components/executer/exregion.c (revision 266756) +++ sys/contrib/dev/acpica/components/executer/exregion.c (working copy) @@ -449,7 +449,21 @@ return_ACPI_STATUS (Status); } +static UINT8 AcpiExCmosRead(ACPI_PHYSICAL_ADDRESS Address) +{ + UINT32 Value32; + AcpiHwWritePort((ACPI_IO_ADDRESS) 0x70, (UINT32) Address, 8); + AcpiHwReadPort ((ACPI_IO_ADDRESS) 0x71, &Value32, 8); + return Value32 & 0xFF; +} + +static void AcpiExCmosWrite(ACPI_PHYSICAL_ADDRESS Address, UINT8 Value) +{ + AcpiHwWritePort((ACPI_IO_ADDRESS) 0x70, (UINT32) Address, 8); + AcpiHwWritePort((ACPI_IO_ADDRESS) 0x71, (UINT32) Value, 8); +} + /******************************************************************************* * * FUNCTION: AcpiExCmosSpaceHandler @@ -473,7 +487,7 @@ UINT32 Function, ACPI_PHYSICAL_ADDRESS Address, UINT32 BitWidth, - UINT64 *Value, + UINT64 *Value64, void *HandlerContext, void *RegionContext) { @@ -482,7 +496,23 @@ ACPI_FUNCTION_TRACE (ExCmosSpaceHandler); + if (Address < 0x80 && + (Function == ACPI_READ || Function == ACPI_WRITE) && + BitWidth <= 64) + { + UINT32 i; + UINT8 *Value = (UINT8 *)Value64; + for (i = 0; i < (BitWidth + 7) / 8; ++i, ++Address, ++Value) { + if (Function == ACPI_READ) { + *Value = AcpiExCmosRead(Address); + } else { + AcpiExCmosWrite(Address, *Value); + } + } + } else { + Status = AE_BAD_PARAMETER; + } return_ACPI_STATUS (Status); } Index: sys/contrib/dev/acpica/include/acconfig.h =================================================================== --- sys/contrib/dev/acpica/include/acconfig.h (revision 266756) +++ sys/contrib/dev/acpica/include/acconfig.h (working copy) @@ -194,7 +194,7 @@ /* Maximum SpaceIds for Operation Regions */ #define ACPI_MAX_ADDRESS_SPACE 255 -#define ACPI_NUM_DEFAULT_SPACES 4 +#define ACPI_NUM_DEFAULT_SPACES 5 /* Array sizes. Used for range checking also */ From owner-freebsd-acpi@FreeBSD.ORG Wed Jun 4 16:07:07 2014 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 70D48D67; Wed, 4 Jun 2014 16:07:07 +0000 (UTC) Received: from mail.ignoranthack.me (ignoranthack.me [199.102.79.106]) (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 506BF227D; Wed, 4 Jun 2014 16:07:07 +0000 (UTC) Received: from [192.168.200.104] (c-50-131-4-11.hsd1.ca.comcast.net [50.131.4.11]) (using SSLv3 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: sbruno@ignoranthack.me) by mail.ignoranthack.me (Postfix) with ESMTPSA id 29F4319294A; Wed, 4 Jun 2014 16:07:06 +0000 (UTC) Subject: Re: Investigating failed suspend/resume T61 From: Sean Bruno Reply-To: sbruno@freebsd.org To: John Baldwin In-Reply-To: <201405290930.00425.jhb@freebsd.org> References: <1400861698.1126.0.camel@bruno> <538666AE.4030501@FreeBSD.org> <1401369401.1100.1.camel@bruno> <201405290930.00425.jhb@freebsd.org> Content-Type: text/plain; charset="us-ascii" Date: Wed, 04 Jun 2014 09:07:05 -0700 Message-ID: <1401898025.1123.17.camel@bruno> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: "freebsd-acpi@freebsd.org" X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jun 2014 16:07:07 -0000 On Thu, 2014-05-29 at 09:30 -0400, John Baldwin wrote: > On Thursday, May 29, 2014 9:16:41 am Sean Bruno wrote: > > On Wed, 2014-05-28 at 18:43 -0400, Jung-uk Kim wrote: > > > -----BEGIN PGP SIGNED MESSAGE----- > > > Hash: SHA1 > > > > > > On 2014-05-28 17:29:35 -0400, John Baldwin wrote: > > > > Err, I think it enables GPE1 as otherwise ACPICA assumes GPE1 has a > > > > length of zero (and is thus invalid)? > > > > > > BTW, ACPI 5.0a (page 121) says: > > > > > > "This is an optional field; if this register block is not supported, > > > this field contains zero." > > > > > > Therefore, we must assume X_GPE1_BLK it is NOT supported. > > > > > > Jung-uk Kim > > > > So, reverting John's changes and applying yours seems to do new things > > while not quieting the old error messages. Perhaps this is significant? > > > > real memory = 2147483648 (2048 MB) > > avail memory = 2007089152 (1914 MB) > > Event timer "LAPIC" quality 400 > > ACPI APIC Table: > > FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs > > FreeBSD/SMP: 1 package(s) x 2 core(s) > > cpu0 (BSP): APIC ID: 0 > > cpu1 (AP): APIC ID: 1 > > ACPI BIOS Warning (bug): 32/64X length mismatch in FADT/Gpe1Block: 0/32 > > (20130823/tbfadt-601) > > ACPI BIOS Warning (bug): Optional FADT field Gpe1Block has zero address > > or length: 0x000000000000102C/0x0 (20130823/tbfadt-630) > > ioapic0: Changing APIC ID to 1 > > ioapic0 irqs 0-23 on motherboard > > random: initialized > > kbd1 at kbdmux0 > > acpi0: on motherboard > > CPU0: local APIC error 0x40 > > ACPI Error: GPE0 block (GPE 0 to 31) overlaps the GPE1 block (GPE 0 to > > 15) - Ignoring GPE1 (20130823/evgpeinit-178) > > Actually, I think all these patches are changing nothing, and this actually > points out that I misread your FADT at the first. GPE1 should actually be > ignored since it does in fact overlap. Can you just try reverting all your > changes and seeing if suspend/resume works? > Boy oh boy ... talk about a waste of time. trasz@ and I have the same laptop and I just confirmed with him that the patch does nothing useful (as both of you suggested). The *ACTUAL* problem seems to be related to disabling devices in the Thinkpad BIOS. Disabling devices seems to cause the resume to not work correctly, but whatever. So none of these patches are actually needed. sean From owner-freebsd-acpi@FreeBSD.ORG Wed Jun 4 16:35: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 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 83932781; Wed, 4 Jun 2014 16:35:34 +0000 (UTC) Received: from mail-qg0-x231.google.com (mail-qg0-x231.google.com [IPv6:2607:f8b0:400d:c04::231]) (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 24276256E; Wed, 4 Jun 2014 16:35:34 +0000 (UTC) Received: by mail-qg0-f49.google.com with SMTP id a108so15701164qge.22 for ; Wed, 04 Jun 2014 09:35:33 -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:message-id:subject :from:to:cc:content-type; bh=6uuqJjYhpMM9JVmAMuilwjH5P/D3DQf5o+wvLQ3JWv8=; b=yg6ReKD56NoUUcaGqyyra7JLY59FdttLca8ZgSRZKxTEmWaNwvVUqmB+GtGqA1X83Y nIKK7K55kO9vVN94rVV5N34nP27JYBJNTKqtddr/YPDtRIPTeoDX7PNs5AEP36pSrim4 zSTLWV3vaeMq7UlBRDj0dAmJ+QBVAeGPmFVzyUBwW4wtLIpryoX+zOQ+q1qn8gexI96Y o9Tpx0ByPDeatDwyHlTGZXDoD8h1ASHQACYwUtfe0HRPx1N2KTsbf+gEycWdl6d+f+Lm fYi7O/7+O+KrZ+WBiICKO19kH+wQDjckOqWLSE12W6GD5a+2/YDT8MTNQmqddJk3PW/h +2nQ== MIME-Version: 1.0 X-Received: by 10.224.37.10 with SMTP id v10mr7923881qad.98.1401899733222; Wed, 04 Jun 2014 09:35:33 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.43.134 with HTTP; Wed, 4 Jun 2014 09:35:33 -0700 (PDT) In-Reply-To: <1401898025.1123.17.camel@bruno> References: <1400861698.1126.0.camel@bruno> <538666AE.4030501@FreeBSD.org> <1401369401.1100.1.camel@bruno> <201405290930.00425.jhb@freebsd.org> <1401898025.1123.17.camel@bruno> Date: Wed, 4 Jun 2014 09:35:33 -0700 X-Google-Sender-Auth: rcdIJDvK8ZX9_cQ-FTV0x03OuQw Message-ID: Subject: Re: Investigating failed suspend/resume T61 From: Adrian Chadd To: Sean Bruno Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-acpi@freebsd.org" X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jun 2014 16:35:34 -0000 Which devices? -a On 4 June 2014 09:07, Sean Bruno wrote: > On Thu, 2014-05-29 at 09:30 -0400, John Baldwin wrote: >> On Thursday, May 29, 2014 9:16:41 am Sean Bruno wrote: >> > On Wed, 2014-05-28 at 18:43 -0400, Jung-uk Kim wrote: >> > > -----BEGIN PGP SIGNED MESSAGE----- >> > > Hash: SHA1 >> > > >> > > On 2014-05-28 17:29:35 -0400, John Baldwin wrote: >> > > > Err, I think it enables GPE1 as otherwise ACPICA assumes GPE1 has a >> > > > length of zero (and is thus invalid)? >> > > >> > > BTW, ACPI 5.0a (page 121) says: >> > > >> > > "This is an optional field; if this register block is not supported, >> > > this field contains zero." >> > > >> > > Therefore, we must assume X_GPE1_BLK it is NOT supported. >> > > >> > > Jung-uk Kim >> > >> > So, reverting John's changes and applying yours seems to do new things >> > while not quieting the old error messages. Perhaps this is significant? >> > >> > real memory = 2147483648 (2048 MB) >> > avail memory = 2007089152 (1914 MB) >> > Event timer "LAPIC" quality 400 >> > ACPI APIC Table: >> > FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs >> > FreeBSD/SMP: 1 package(s) x 2 core(s) >> > cpu0 (BSP): APIC ID: 0 >> > cpu1 (AP): APIC ID: 1 >> > ACPI BIOS Warning (bug): 32/64X length mismatch in FADT/Gpe1Block: 0/32 >> > (20130823/tbfadt-601) >> > ACPI BIOS Warning (bug): Optional FADT field Gpe1Block has zero address >> > or length: 0x000000000000102C/0x0 (20130823/tbfadt-630) >> > ioapic0: Changing APIC ID to 1 >> > ioapic0 irqs 0-23 on motherboard >> > random: initialized >> > kbd1 at kbdmux0 >> > acpi0: on motherboard >> > CPU0: local APIC error 0x40 >> > ACPI Error: GPE0 block (GPE 0 to 31) overlaps the GPE1 block (GPE 0 to >> > 15) - Ignoring GPE1 (20130823/evgpeinit-178) >> >> Actually, I think all these patches are changing nothing, and this actually >> points out that I misread your FADT at the first. GPE1 should actually be >> ignored since it does in fact overlap. Can you just try reverting all your >> changes and seeing if suspend/resume works? >> > > > Boy oh boy ... talk about a waste of time. > > trasz@ and I have the same laptop and I just confirmed with him that the > patch does nothing useful (as both of you suggested). The *ACTUAL* > problem seems to be related to disabling devices in the Thinkpad BIOS. > > Disabling devices seems to cause the resume to not work correctly, but > whatever. So none of these patches are actually needed. > > sean > > _______________________________________________ > freebsd-acpi@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-acpi > To unsubscribe, send any mail to "freebsd-acpi-unsubscribe@freebsd.org" From owner-freebsd-acpi@FreeBSD.ORG Wed Jun 4 17:15: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 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E0879393; Wed, 4 Jun 2014 17:15:31 +0000 (UTC) Received: from mail.ignoranthack.me (ignoranthack.me [199.102.79.106]) (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 ACE0C2942; Wed, 4 Jun 2014 17:15:31 +0000 (UTC) Received: from [192.168.200.104] (c-50-131-4-11.hsd1.ca.comcast.net [50.131.4.11]) (using SSLv3 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: sbruno@ignoranthack.me) by mail.ignoranthack.me (Postfix) with ESMTPSA id 712F119294A; Wed, 4 Jun 2014 17:15:30 +0000 (UTC) Subject: Re: Investigating failed suspend/resume T61 From: Sean Bruno Reply-To: sbruno@freebsd.org To: Adrian Chadd In-Reply-To: References: <1400861698.1126.0.camel@bruno> <538666AE.4030501@FreeBSD.org> <1401369401.1100.1.camel@bruno> <201405290930.00425.jhb@freebsd.org> <1401898025.1123.17.camel@bruno> Content-Type: text/plain; charset="us-ascii" Date: Wed, 04 Jun 2014 10:15:28 -0700 Message-ID: <1401902128.1123.26.camel@bruno> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: "freebsd-acpi@freebsd.org" X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jun 2014 17:15:32 -0000 On Wed, 2014-06-04 at 09:35 -0700, Adrian Chadd wrote: > Which devices? > > > -a > > On 4 June 2014 09:07, Sean Bruno wrote: > > On Thu, 2014-05-29 at 09:30 -0400, John Baldwin wrote: > >> On Thursday, May 29, 2014 9:16:41 am Sean Bruno wrote: > >> > On Wed, 2014-05-28 at 18:43 -0400, Jung-uk Kim wrote: > >> > > -----BEGIN PGP SIGNED MESSAGE----- > >> > > Hash: SHA1 > >> > > > >> > > On 2014-05-28 17:29:35 -0400, John Baldwin wrote: > >> > > > Err, I think it enables GPE1 as otherwise ACPICA assumes GPE1 has a > >> > > > length of zero (and is thus invalid)? > >> > > > >> > > BTW, ACPI 5.0a (page 121) says: > >> > > > >> > > "This is an optional field; if this register block is not supported, > >> > > this field contains zero." > >> > > > >> > > Therefore, we must assume X_GPE1_BLK it is NOT supported. > >> > > > >> > > Jung-uk Kim > >> > > >> > So, reverting John's changes and applying yours seems to do new things > >> > while not quieting the old error messages. Perhaps this is significant? > >> > > >> > real memory = 2147483648 (2048 MB) > >> > avail memory = 2007089152 (1914 MB) > >> > Event timer "LAPIC" quality 400 > >> > ACPI APIC Table: > >> > FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs > >> > FreeBSD/SMP: 1 package(s) x 2 core(s) > >> > cpu0 (BSP): APIC ID: 0 > >> > cpu1 (AP): APIC ID: 1 > >> > ACPI BIOS Warning (bug): 32/64X length mismatch in FADT/Gpe1Block: 0/32 > >> > (20130823/tbfadt-601) > >> > ACPI BIOS Warning (bug): Optional FADT field Gpe1Block has zero address > >> > or length: 0x000000000000102C/0x0 (20130823/tbfadt-630) > >> > ioapic0: Changing APIC ID to 1 > >> > ioapic0 irqs 0-23 on motherboard > >> > random: initialized > >> > kbd1 at kbdmux0 > >> > acpi0: on motherboard > >> > CPU0: local APIC error 0x40 > >> > ACPI Error: GPE0 block (GPE 0 to 31) overlaps the GPE1 block (GPE 0 to > >> > 15) - Ignoring GPE1 (20130823/evgpeinit-178) > >> > >> Actually, I think all these patches are changing nothing, and this actually > >> points out that I misread your FADT at the first. GPE1 should actually be > >> ignored since it does in fact overlap. Can you just try reverting all your > >> changes and seeing if suspend/resume works? > >> > > > > > > Boy oh boy ... talk about a waste of time. > > > > trasz@ and I have the same laptop and I just confirmed with him that the > > patch does nothing useful (as both of you suggested). The *ACTUAL* > > problem seems to be related to disabling devices in the Thinkpad BIOS. > > > > Disabling devices seems to cause the resume to not work correctly, but > > whatever. So none of these patches are actually needed. > > > > sean > > It looks like the on board modem is a bit touchy. sean hdacc1: at cad 1 on hdac0 unknown: at nid 2 on hdacc1 (no driver attached) From owner-freebsd-acpi@FreeBSD.ORG Wed Jun 4 17:17:18 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 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7669C56A; Wed, 4 Jun 2014 17:17:18 +0000 (UTC) Received: from mail-wg0-x230.google.com (mail-wg0-x230.google.com [IPv6:2a00:1450:400c:c00::230]) (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 A1CA9296C; Wed, 4 Jun 2014 17:17:17 +0000 (UTC) Received: by mail-wg0-f48.google.com with SMTP id k14so8866461wgh.7 for ; Wed, 04 Jun 2014 10:17:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=sf6wvfLs5VqsHthBu86XLFpeVf43epnpK8EPv7JfghY=; b=yE9XBrgtmyxcNqN9B4eqYyG3lrcsW4CC/iGKUyfi/Gnrm7pBftij9MjNilqz4yhGN9 O/d8ZqHh49qw5wYSb0rupptOnC9gJ/imJMqh22BchKSKMs9OlRYT7T0RmlWnQUF1UUjd B0kJB5CgmtnW1EiQrxJM9cKIpH2X9wTuv+BFx8aNSZMmr0THELf/RE334ORJxKtkfEq1 O5U7+uuZNes8LmYVOyb63fl9RLUT4jCdeQDh6BXlWm3UbUPKyzH55IH/AVJRdZhYuEQb jWGEWCqpXkbflMukHqFrk0RiAkuQlg6Mt1ty0hogGVy/TvQXwlQzJ2HIIJIxd8sTh5V8 YXsw== X-Received: by 10.14.209.3 with SMTP id r3mr3003865eeo.27.1401902235982; Wed, 04 Jun 2014 10:17:15 -0700 (PDT) Received: from brick.home (adhm124.neoplus.adsl.tpnet.pl. [79.184.168.124]) by mx.google.com with ESMTPSA id e44sm7243977eeg.24.2014.06.04.10.17.14 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 04 Jun 2014 10:17:14 -0700 (PDT) Sender: =?UTF-8?Q?Edward_Tomasz_Napiera=C5=82a?= Date: Wed, 4 Jun 2014 19:17:14 +0200 From: Edward Tomasz =?utf-8?Q?Napiera=C5=82a?= To: Sean Bruno Subject: Re: Investigating failed suspend/resume T61 Message-ID: <20140604171714.GA931@brick.home> References: <1400861698.1126.0.camel@bruno> <538666AE.4030501@FreeBSD.org> <1401369401.1100.1.camel@bruno> <201405290930.00425.jhb@freebsd.org> <1401898025.1123.17.camel@bruno> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1401898025.1123.17.camel@bruno> User-Agent: Mutt/1.5.23 (2014-03-12) Cc: "freebsd-acpi@freebsd.org" X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jun 2014 17:17:18 -0000 On 0604T0907, Sean Bruno wrote: > On Thu, 2014-05-29 at 09:30 -0400, John Baldwin wrote: > > On Thursday, May 29, 2014 9:16:41 am Sean Bruno wrote: > > > On Wed, 2014-05-28 at 18:43 -0400, Jung-uk Kim wrote: > > > > -----BEGIN PGP SIGNED MESSAGE----- > > > > Hash: SHA1 > > > > > > > > On 2014-05-28 17:29:35 -0400, John Baldwin wrote: > > > > > Err, I think it enables GPE1 as otherwise ACPICA assumes GPE1 has a > > > > > length of zero (and is thus invalid)? > > > > > > > > BTW, ACPI 5.0a (page 121) says: > > > > > > > > "This is an optional field; if this register block is not supported, > > > > this field contains zero." > > > > > > > > Therefore, we must assume X_GPE1_BLK it is NOT supported. > > > > > > > > Jung-uk Kim > > > > > > So, reverting John's changes and applying yours seems to do new things > > > while not quieting the old error messages. Perhaps this is significant? > > > > > > real memory = 2147483648 (2048 MB) > > > avail memory = 2007089152 (1914 MB) > > > Event timer "LAPIC" quality 400 > > > ACPI APIC Table: > > > FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs > > > FreeBSD/SMP: 1 package(s) x 2 core(s) > > > cpu0 (BSP): APIC ID: 0 > > > cpu1 (AP): APIC ID: 1 > > > ACPI BIOS Warning (bug): 32/64X length mismatch in FADT/Gpe1Block: 0/32 > > > (20130823/tbfadt-601) > > > ACPI BIOS Warning (bug): Optional FADT field Gpe1Block has zero address > > > or length: 0x000000000000102C/0x0 (20130823/tbfadt-630) > > > ioapic0: Changing APIC ID to 1 > > > ioapic0 irqs 0-23 on motherboard > > > random: initialized > > > kbd1 at kbdmux0 > > > acpi0: on motherboard > > > CPU0: local APIC error 0x40 > > > ACPI Error: GPE0 block (GPE 0 to 31) overlaps the GPE1 block (GPE 0 to > > > 15) - Ignoring GPE1 (20130823/evgpeinit-178) > > > > Actually, I think all these patches are changing nothing, and this actually > > points out that I misread your FADT at the first. GPE1 should actually be > > ignored since it does in fact overlap. Can you just try reverting all your > > changes and seeing if suspend/resume works? > > > > > Boy oh boy ... talk about a waste of time. > > trasz@ and I have the same laptop and I just confirmed with him that the > patch does nothing useful (as both of you suggested). The *ACTUAL* > problem seems to be related to disabling devices in the Thinkpad BIOS. Yup. The culprit seems to be the "Security -> IO Port Access -> Modem" BIOS control: setting it to disabled breaks resume; the AcpiEnterSleepState() never returns. With that option set to enabled, the suspend/resume works seems to work flawlessly on T61 with Intel graphics, with VT kernel and i915kms.ko, on 11-CURRENT/amd64 from a few days ago, without any patches or special sysctl/tunables. The following messages are still displayed at boot, but seem harmless: ACPI BIOS Warning (bug): 32/64X length mismatch in FADT/Gpe1Block: 0/32 (20130823/tbfadt-601) ACPI BIOS Warning (bug): Optional FADT field Gpe1Block has zero address or length: 0x000000000000102C/0x0 (20130823/tbfadt-630) [..] acpi0: on motherboard acpi0: failed to install _OSI("Windows 2006"): AE_ALREADY_EXISTS CPU0: local APIC error 0x40 acpi_ec0: port 0x62,0x66 on acpi0 acpi0: Power Button (fixed) acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, 7df00000 (3) failed From owner-freebsd-acpi@FreeBSD.ORG Wed Jun 4 18:24:33 2014 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1A3CCE4; Wed, 4 Jun 2014 18:24:33 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E3442211C; Wed, 4 Jun 2014 18:24:32 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 1024FB939; Wed, 4 Jun 2014 14:24:31 -0400 (EDT) From: John Baldwin To: Edward Tomasz =?utf-8?q?Napiera=C5=82a?= Subject: Re: Investigating failed suspend/resume T61 Date: Wed, 4 Jun 2014 13:30:54 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20140415; KDE/4.5.5; amd64; ; ) References: <1400861698.1126.0.camel@bruno> <1401898025.1123.17.camel@bruno> <20140604171714.GA931@brick.home> In-Reply-To: <20140604171714.GA931@brick.home> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <201406041330.54793.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 04 Jun 2014 14:24:31 -0400 (EDT) Cc: Sean Bruno , "freebsd-acpi@freebsd.org" X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jun 2014 18:24:33 -0000 On Wednesday, June 04, 2014 1:17:14 pm Edward Tomasz Napiera=C5=82a wrote: > On 0604T0907, Sean Bruno wrote: > > On Thu, 2014-05-29 at 09:30 -0400, John Baldwin wrote: > > > On Thursday, May 29, 2014 9:16:41 am Sean Bruno wrote: > > > > On Wed, 2014-05-28 at 18:43 -0400, Jung-uk Kim wrote: > > > > > -----BEGIN PGP SIGNED MESSAGE----- > > > > > Hash: SHA1 > > > > >=20 > > > > > On 2014-05-28 17:29:35 -0400, John Baldwin wrote: > > > > > > Err, I think it enables GPE1 as otherwise ACPICA assumes GPE1 h= as a > > > > > > length of zero (and is thus invalid)? > > > > >=20 > > > > > BTW, ACPI 5.0a (page 121) says: > > > > >=20 > > > > > "This is an optional field; if this register block is not support= ed, > > > > > this field contains zero." > > > > >=20 > > > > > Therefore, we must assume X_GPE1_BLK it is NOT supported. > > > > >=20 > > > > > Jung-uk Kim > > > >=20 > > > > So, reverting John's changes and applying yours seems to do new thi= ngs > > > > while not quieting the old error messages. Perhaps this is signifi= cant? > > > >=20 > > > > real memory =3D 2147483648 (2048 MB) > > > > avail memory =3D 2007089152 (1914 MB) > > > > Event timer "LAPIC" quality 400 > > > > ACPI APIC Table: > > > > FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs > > > > FreeBSD/SMP: 1 package(s) x 2 core(s) > > > > cpu0 (BSP): APIC ID: 0 > > > > cpu1 (AP): APIC ID: 1 > > > > ACPI BIOS Warning (bug): 32/64X length mismatch in FADT/Gpe1Block: = 0/32 > > > > (20130823/tbfadt-601) > > > > ACPI BIOS Warning (bug): Optional FADT field Gpe1Block has zero add= ress > > > > or length: 0x000000000000102C/0x0 (20130823/tbfadt-630) > > > > ioapic0: Changing APIC ID to 1 > > > > ioapic0 irqs 0-23 on motherboard > > > > random: initialized > > > > kbd1 at kbdmux0 > > > > acpi0: on motherboard > > > > CPU0: local APIC error 0x40 > > > > ACPI Error: GPE0 block (GPE 0 to 31) overlaps the GPE1 block (GPE 0= to > > > > 15) - Ignoring GPE1 (20130823/evgpeinit-178) > > >=20 > > > Actually, I think all these patches are changing nothing, and this ac= tually > > > points out that I misread your FADT at the first. GPE1 should actual= ly be > > > ignored since it does in fact overlap. Can you just try reverting al= l your > > > changes and seeing if suspend/resume works? > > >=20 > >=20 > >=20 > > Boy oh boy ... talk about a waste of time. > >=20 > > trasz@ and I have the same laptop and I just confirmed with him that the > > patch does nothing useful (as both of you suggested). The *ACTUAL* > > problem seems to be related to disabling devices in the Thinkpad BIOS. >=20 >=20 > Yup. The culprit seems to be the "Security -> IO Port Access -> Modem" > BIOS control: setting it to disabled breaks resume; the AcpiEnterSleepSta= te() > never returns. >=20 > With that option set to enabled, the suspend/resume works seems to work > flawlessly on T61 with Intel graphics, with VT kernel and i915kms.ko, > on 11-CURRENT/amd64 from a few days ago, without any patches or special > sysctl/tunables.=20 Well, document it on the wiki at least. =2D-=20 John Baldwin From owner-freebsd-acpi@FreeBSD.ORG Wed Jun 4 19:46:30 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 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 50AACC6C; Wed, 4 Jun 2014 19:46:30 +0000 (UTC) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) (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 911D128D3; Wed, 4 Jun 2014 19:46:29 +0000 (UTC) Received: by mail-wi0-f169.google.com with SMTP id hi2so8512169wib.2 for ; Wed, 04 Jun 2014 12:46:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=7CDWZ1vvhy9EJ/0RLEw1MQ/iI694u9Y9i5g2gUZ/Cuo=; b=JPiqNqB1ObnM86ESJeAE2EJgWa1G9AMYfwQdD6cUgbxe9xOmtA3/FgWIStjd+wfskU AXCt9/bRE36mcW6cXE7Te3PYepDqqKnzFI53/JTiX75WeG1tGxKULKy/cxuurADem4XO Ejg7uO5xWxToHGA2ifAzwVO+JuSAcD7iPgjWobBkVrcncfa/SR0B7cr57ed9Mtupy90c Cc9/BsZ0noWJo4WTNYtXCjNFL9flCqIn1F/PTm1XgkjERhuqgzud79royFN64t5H2qS7 oG+7yyU9jpjZ49Laq7JSirKK6Sh9s1Sa5tKPtxhZ1SC/fsTESW8q3cfjPJ1jQbCXHo3U 0X3g== X-Received: by 10.15.21.200 with SMTP id d48mr3327769eeu.25.1401911187764; Wed, 04 Jun 2014 12:46:27 -0700 (PDT) Received: from strashydlo.home (adde29.neoplus.adsl.tpnet.pl. [79.184.56.29]) by mx.google.com with ESMTPSA id f3sm8205739eep.40.2014.06.04.12.46.26 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 04 Jun 2014 12:46:27 -0700 (PDT) Sender: =?UTF-8?Q?Edward_Tomasz_Napiera=C5=82a?= Subject: Re: Investigating failed suspend/resume T61 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-2 From: =?iso-8859-2?Q?Edward_Tomasz_Napiera=B3a?= In-Reply-To: <201406041330.54793.jhb@freebsd.org> Date: Wed, 4 Jun 2014 21:46:24 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1400861698.1126.0.camel@bruno> <1401898025.1123.17.camel@bruno> <20140604171714.GA931@brick.home> <201406041330.54793.jhb@freebsd.org> To: John Baldwin X-Mailer: Apple Mail (2.1283) Cc: Sean Bruno , "freebsd-acpi@freebsd.org" X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jun 2014 19:46:30 -0000 Wiadomo=B6=E6 napisana przez John Baldwin w dniu 4 cze 2014, o godz. = 19:30: > On Wednesday, June 04, 2014 1:17:14 pm Edward Tomasz Napiera=B3a = wrote: >> On 0604T0907, Sean Bruno wrote: >>> On Thu, 2014-05-29 at 09:30 -0400, John Baldwin wrote: >>>> On Thursday, May 29, 2014 9:16:41 am Sean Bruno wrote: >>>>> On Wed, 2014-05-28 at 18:43 -0400, Jung-uk Kim wrote: >>>>>> -----BEGIN PGP SIGNED MESSAGE----- >>>>>> Hash: SHA1 >>>>>>=20 >>>>>> On 2014-05-28 17:29:35 -0400, John Baldwin wrote: >>>>>>> Err, I think it enables GPE1 as otherwise ACPICA assumes GPE1 = has a >>>>>>> length of zero (and is thus invalid)? >>>>>>=20 >>>>>> BTW, ACPI 5.0a (page 121) says: >>>>>>=20 >>>>>> "This is an optional field; if this register block is not = supported, >>>>>> this field contains zero." >>>>>>=20 >>>>>> Therefore, we must assume X_GPE1_BLK it is NOT supported. >>>>>>=20 >>>>>> Jung-uk Kim >>>>>=20 >>>>> So, reverting John's changes and applying yours seems to do new = things >>>>> while not quieting the old error messages. Perhaps this is = significant? >>>>>=20 >>>>> real memory =3D 2147483648 (2048 MB) >>>>> avail memory =3D 2007089152 (1914 MB) >>>>> Event timer "LAPIC" quality 400 >>>>> ACPI APIC Table: >>>>> FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs >>>>> FreeBSD/SMP: 1 package(s) x 2 core(s) >>>>> cpu0 (BSP): APIC ID: 0 >>>>> cpu1 (AP): APIC ID: 1 >>>>> ACPI BIOS Warning (bug): 32/64X length mismatch in FADT/Gpe1Block: = 0/32 >>>>> (20130823/tbfadt-601) >>>>> ACPI BIOS Warning (bug): Optional FADT field Gpe1Block has zero = address >>>>> or length: 0x000000000000102C/0x0 (20130823/tbfadt-630) >>>>> ioapic0: Changing APIC ID to 1 >>>>> ioapic0 irqs 0-23 on motherboard >>>>> random: initialized >>>>> kbd1 at kbdmux0 >>>>> acpi0: on motherboard >>>>> CPU0: local APIC error 0x40 >>>>> ACPI Error: GPE0 block (GPE 0 to 31) overlaps the GPE1 block (GPE = 0 to >>>>> 15) - Ignoring GPE1 (20130823/evgpeinit-178) >>>>=20 >>>> Actually, I think all these patches are changing nothing, and this = actually >>>> points out that I misread your FADT at the first. GPE1 should = actually be >>>> ignored since it does in fact overlap. Can you just try reverting = all your >>>> changes and seeing if suspend/resume works? >>>>=20 >>>=20 >>>=20 >>> Boy oh boy ... talk about a waste of time. >>>=20 >>> trasz@ and I have the same laptop and I just confirmed with him that = the >>> patch does nothing useful (as both of you suggested). The *ACTUAL* >>> problem seems to be related to disabling devices in the Thinkpad = BIOS. >>=20 >>=20 >> Yup. The culprit seems to be the "Security -> IO Port Access -> = Modem" >> BIOS control: setting it to disabled breaks resume; the = AcpiEnterSleepState() >> never returns. >>=20 >> With that option set to enabled, the suspend/resume works seems to = work >> flawlessly on T61 with Intel graphics, with VT kernel and i915kms.ko, >> on 11-CURRENT/amd64 from a few days ago, without any patches or = special >> sysctl/tunables.=20 >=20 > Well, document it on the wiki at least. Thanks for suggestion; done. From owner-freebsd-acpi@FreeBSD.ORG Wed Jun 4 22:32:41 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 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 85E1AB20; Wed, 4 Jun 2014 22:32:41 +0000 (UTC) Received: from mail-qa0-x229.google.com (mail-qa0-x229.google.com [IPv6:2607:f8b0:400d:c00::229]) (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 23FEE2C26; Wed, 4 Jun 2014 22:32:41 +0000 (UTC) Received: by mail-qa0-f41.google.com with SMTP id dc16so240351qab.28 for ; Wed, 04 Jun 2014 15:32:40 -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:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=5mnd7/ZdxQtFkoi4MUsHxr0Vwdrv8Tnh44rDElLYGv8=; b=gET9ZPdi4ay3kxCEtnSUHrkuIG5XddpeEgAoj79497AlvFy2JPxfg/k6FVm0Ef5r93 WnKZOQVWiFengoCkEijDnM992CyehmHkm5EOVSvjblFYtRcVdgd0w0KuHfn2P5wR11cm EafawKQwsF2fW7Q+vfL1OUiF5C9rtIq9eD+vr1fwtTSE2Ljlzn/PCto5df6xAXjYHxYi AN8ucvOcXO1RqfjDCuWfKxZRn8XAiqTAHgNCrMs/wOXJQao/qOk4EtVWVY0jqjonVEXd kUdJk+8BZOGiujF86P0mgjcEPm33+Rl7TmiGgt0QiN5EJmWWWkn7/PkmME9qCfZuh90m sOkw== MIME-Version: 1.0 X-Received: by 10.224.135.66 with SMTP id m2mr11796197qat.55.1401921160245; Wed, 04 Jun 2014 15:32:40 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.43.134 with HTTP; Wed, 4 Jun 2014 15:32:40 -0700 (PDT) In-Reply-To: References: <1400861698.1126.0.camel@bruno> <1401898025.1123.17.camel@bruno> <20140604171714.GA931@brick.home> <201406041330.54793.jhb@freebsd.org> Date: Wed, 4 Jun 2014 15:32:40 -0700 X-Google-Sender-Auth: tn_S-ddmAh5E3q9nBUSZgTES8ZA Message-ID: Subject: Re: Investigating failed suspend/resume T61 From: Adrian Chadd To: =?UTF-8?Q?Edward_Tomasz_Napiera=C5=82a?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Sean Bruno , "freebsd-acpi@freebsd.org" X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jun 2014 22:32:41 -0000 Hi, Please also document why it is/isn't working. It's only documented as "suspend/resume doesn't work" :) -a On 4 June 2014 12:46, Edward Tomasz Napiera=C5=82a wrot= e: > Wiadomo=C5=9B=C4=87 napisana przez John Baldwin w dniu 4 cze 2014, o godz= . 19:30: > >> On Wednesday, June 04, 2014 1:17:14 pm Edward Tomasz Napiera=C5=82a wrot= e: >>> On 0604T0907, Sean Bruno wrote: >>>> On Thu, 2014-05-29 at 09:30 -0400, John Baldwin wrote: >>>>> On Thursday, May 29, 2014 9:16:41 am Sean Bruno wrote: >>>>>> On Wed, 2014-05-28 at 18:43 -0400, Jung-uk Kim wrote: >>>>>>> -----BEGIN PGP SIGNED MESSAGE----- >>>>>>> Hash: SHA1 >>>>>>> >>>>>>> On 2014-05-28 17:29:35 -0400, John Baldwin wrote: >>>>>>>> Err, I think it enables GPE1 as otherwise ACPICA assumes GPE1 has = a >>>>>>>> length of zero (and is thus invalid)? >>>>>>> >>>>>>> BTW, ACPI 5.0a (page 121) says: >>>>>>> >>>>>>> "This is an optional field; if this register block is not supported= , >>>>>>> this field contains zero." >>>>>>> >>>>>>> Therefore, we must assume X_GPE1_BLK it is NOT supported. >>>>>>> >>>>>>> Jung-uk Kim >>>>>> >>>>>> So, reverting John's changes and applying yours seems to do new thin= gs >>>>>> while not quieting the old error messages. Perhaps this is signific= ant? >>>>>> >>>>>> real memory =3D 2147483648 (2048 MB) >>>>>> avail memory =3D 2007089152 (1914 MB) >>>>>> Event timer "LAPIC" quality 400 >>>>>> ACPI APIC Table: >>>>>> FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs >>>>>> FreeBSD/SMP: 1 package(s) x 2 core(s) >>>>>> cpu0 (BSP): APIC ID: 0 >>>>>> cpu1 (AP): APIC ID: 1 >>>>>> ACPI BIOS Warning (bug): 32/64X length mismatch in FADT/Gpe1Block: 0= /32 >>>>>> (20130823/tbfadt-601) >>>>>> ACPI BIOS Warning (bug): Optional FADT field Gpe1Block has zero addr= ess >>>>>> or length: 0x000000000000102C/0x0 (20130823/tbfadt-630) >>>>>> ioapic0: Changing APIC ID to 1 >>>>>> ioapic0 irqs 0-23 on motherboard >>>>>> random: initialized >>>>>> kbd1 at kbdmux0 >>>>>> acpi0: on motherboard >>>>>> CPU0: local APIC error 0x40 >>>>>> ACPI Error: GPE0 block (GPE 0 to 31) overlaps the GPE1 block (GPE 0 = to >>>>>> 15) - Ignoring GPE1 (20130823/evgpeinit-178) >>>>> >>>>> Actually, I think all these patches are changing nothing, and this ac= tually >>>>> points out that I misread your FADT at the first. GPE1 should actual= ly be >>>>> ignored since it does in fact overlap. Can you just try reverting al= l your >>>>> changes and seeing if suspend/resume works? >>>>> >>>> >>>> >>>> Boy oh boy ... talk about a waste of time. >>>> >>>> trasz@ and I have the same laptop and I just confirmed with him that t= he >>>> patch does nothing useful (as both of you suggested). The *ACTUAL* >>>> problem seems to be related to disabling devices in the Thinkpad BIOS. >>> >>> >>> Yup. The culprit seems to be the "Security -> IO Port Access -> Modem" >>> BIOS control: setting it to disabled breaks resume; the AcpiEnterSleepS= tate() >>> never returns. >>> >>> With that option set to enabled, the suspend/resume works seems to work >>> flawlessly on T61 with Intel graphics, with VT kernel and i915kms.ko, >>> on 11-CURRENT/amd64 from a few days ago, without any patches or special >>> sysctl/tunables. >> >> Well, document it on the wiki at least. > > Thanks for suggestion; done. > > _______________________________________________ > freebsd-acpi@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-acpi > To unsubscribe, send any mail to "freebsd-acpi-unsubscribe@freebsd.org" From owner-freebsd-acpi@FreeBSD.ORG Thu Jun 5 14:51:03 2014 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1FBBF522; Thu, 5 Jun 2014 14:51:03 +0000 (UTC) Received: from mail.ignoranthack.me (ignoranthack.me [199.102.79.106]) (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 A641A25F1; Thu, 5 Jun 2014 14:51:00 +0000 (UTC) Received: from [192.168.200.103] (c-50-131-4-11.hsd1.ca.comcast.net [50.131.4.11]) (using SSLv3 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: sbruno@ignoranthack.me) by mail.ignoranthack.me (Postfix) with ESMTPSA id F2B8B19294A; Thu, 5 Jun 2014 14:50:58 +0000 (UTC) Subject: Re: Investigating failed suspend/resume T61 From: Sean Bruno Reply-To: sbruno@freebsd.org To: Adrian Chadd In-Reply-To: References: <1400861698.1126.0.camel@bruno> <1401898025.1123.17.camel@bruno> <20140604171714.GA931@brick.home> <201406041330.54793.jhb@freebsd.org> Content-Type: text/plain; charset="us-ascii" Date: Thu, 05 Jun 2014 07:50:59 -0700 Message-ID: <1401979859.1123.29.camel@bruno> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: "freebsd-acpi@freebsd.org" , Edward Tomasz =?iso-8859-2?Q?Napiera=B3a?= X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jun 2014 14:51:03 -0000 On Wed, 2014-06-04 at 15:32 -0700, Adrian Chadd wrote: > Hi, > > Please also document why it is/isn't working. It's only documented as > "suspend/resume doesn't work" :) > > > -a Well there's this that trasz updated to indicate that it works: https://wiki.freebsd.org/SuspendResume I just updated this to indicate the same information: https://wiki.freebsd.org/Laptops/Thinkpad_T61 sean From owner-freebsd-acpi@FreeBSD.ORG Fri Jun 6 01:52:03 2014 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 31A3B9F2; Fri, 6 Jun 2014 01:52:03 +0000 (UTC) Received: from mail-qa0-x22e.google.com (mail-qa0-x22e.google.com [IPv6:2607:f8b0:400d:c00::22e]) (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 C2C682375; Fri, 6 Jun 2014 01:52:02 +0000 (UTC) Received: by mail-qa0-f46.google.com with SMTP id w8so2615737qac.19 for ; Thu, 05 Jun 2014 18:52:01 -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:message-id:subject :from:to:cc:content-type; bh=75XY8MYLsi6QHxqaLlc2k61BMPAG3qlAOTkXZpu0Jks=; b=CqwmKKX0nggcgUBjrcQ81zflOgPj6Kj7Y2g+DAikF+MA6Is4tYcUy93RZs8VpGTDOe h3QFCPAh65xrK+M0T6kEJbpZAHifX4v9vRUZMUVpbkvZzCXIJug1g/HtUtm/h4brgr/A vjUrPkbffNAiMDscTgM/WK5nR/uhZIbpSMfT0yllhK0oNv0xbGCOu5woSpLUZqpgU3wc tz7fnBtjztDE5IHpFv5EfNabECtJSthi9Y9WIx+5+eeNvbLNljgNsNWhj2K7cMTYUkuW qcyAXq+K6TbQ7UHGNmBM/iRuQC9hPvq/IJLPcoZlwfAknJDmOiJTND/HGmZmX32DRT8i FEFg== MIME-Version: 1.0 X-Received: by 10.140.35.212 with SMTP id n78mr2331375qgn.87.1402019521877; Thu, 05 Jun 2014 18:52:01 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.43.134 with HTTP; Thu, 5 Jun 2014 18:52:01 -0700 (PDT) In-Reply-To: <1401979859.1123.29.camel@bruno> References: <1400861698.1126.0.camel@bruno> <1401898025.1123.17.camel@bruno> <20140604171714.GA931@brick.home> <201406041330.54793.jhb@freebsd.org> <1401979859.1123.29.camel@bruno> Date: Thu, 5 Jun 2014 21:52:01 -0400 X-Google-Sender-Auth: A5UPlbKCEQjy8QK-DkJAYFsLBus Message-ID: Subject: Re: Investigating failed suspend/resume T61 From: Adrian Chadd To: Sean Bruno Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-acpi@freebsd.org" , =?UTF-8?Q?Edward_Tomasz_Napiera=C5=82a?= X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jun 2014 01:52:03 -0000 ok so when you disable the modem, does it still think there's a modem there? Is it still trying to power the device off via ACPI even though it's not probed? -a On 5 June 2014 10:50, Sean Bruno wrote: > On Wed, 2014-06-04 at 15:32 -0700, Adrian Chadd wrote: >> Hi, >> >> Please also document why it is/isn't working. It's only documented as >> "suspend/resume doesn't work" :) >> >> >> -a > > > Well there's this that trasz updated to indicate that it works: > https://wiki.freebsd.org/SuspendResume > > I just updated this to indicate the same information: > https://wiki.freebsd.org/Laptops/Thinkpad_T61 > > sean > From owner-freebsd-acpi@FreeBSD.ORG Fri Jun 6 07:57:43 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 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6AC9B381; Fri, 6 Jun 2014 07:57:43 +0000 (UTC) Received: from mail-wg0-x22f.google.com (mail-wg0-x22f.google.com [IPv6:2a00:1450:400c:c00::22f]) (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 A17BA219F; Fri, 6 Jun 2014 07:57:42 +0000 (UTC) Received: by mail-wg0-f47.google.com with SMTP id k14so1414017wgh.18 for ; Fri, 06 Jun 2014 00:57:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=v8JcM2yzCdxrL/2eykZEvR74NAikOywYiF0ScsGahwg=; b=pjQZouOrWNpa06K0xhDTP1YYmaMpS2osZPgooBEpCeT2NiANPlytnKzTONohMxcDUU oh8fA9+6hJawJAl4r6I/uUlB2ZOqxn6BmQuFVaDcckGfrvwznwgn1wVWGVODBjaiTpit Scubpy5sdxM/9Jjp6k9k8wJr+G2wcjZ+IWAnJVqRJIdj2NjrKYtRx1r1AWjbrlvPlW9R LSxhkkFFSv2quvvntEEaKItPQve/PopKeAK352Mrc8zweVaWqSQjPDjbDLt72TJJaGAS vwptPuABkWyR19IQo8lmC4rWJ3RDadujnMcH0EcrvMOoxGYG6Y1HT+/82sysPcmdUn89 KyOw== X-Received: by 10.14.211.66 with SMTP id v42mr538717eeo.1.1402041460817; Fri, 06 Jun 2014 00:57:40 -0700 (PDT) Received: from brick.home (acta155.neoplus.adsl.tpnet.pl. [83.11.54.155]) by mx.google.com with ESMTPSA id q49sm21097233eeo.23.2014.06.06.00.57.39 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 06 Jun 2014 00:57:40 -0700 (PDT) Sender: =?UTF-8?Q?Edward_Tomasz_Napiera=C5=82a?= Date: Fri, 6 Jun 2014 09:57:37 +0200 From: Edward Tomasz =?utf-8?Q?Napiera=C5=82a?= To: Adrian Chadd Subject: Re: Investigating failed suspend/resume T61 Message-ID: <20140606075737.GA826@brick.home> References: <1400861698.1126.0.camel@bruno> <1401898025.1123.17.camel@bruno> <20140604171714.GA931@brick.home> <201406041330.54793.jhb@freebsd.org> <1401979859.1123.29.camel@bruno> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Cc: "freebsd-acpi@freebsd.org" X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jun 2014 07:57:43 -0000 The difference in dmesg with (-) and without (+) the modem looks like this: --- dmesg.modem 2014-06-06 09:46:02.000000000 +0200 +++ dmesg.bez 2014-06-06 09:52:45.000000000 +0200 @@ -48,7 +48,7 @@ Event timer "HPET1" frequency 14318180 H Event timer "HPET2" frequency 14318180 Hz quality 440 atrtc0: port 0x70-0x71 irq 8 on acpi0 Event timer "RTC" frequency 32768 Hz quality 0 -Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 +Timecounter "ACPI-safe" frequency 3579545 Hz quality 850 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 acpi_lid0: on acpi0 acpi_button0: on acpi0 @@ -157,12 +157,13 @@ est0: on cpu1 est1: on cpu1 Timecounters tick every 1.000 msec +hdac0: Command timeout on address 1 +hdac0: Command timeout on address 1 +hdac0: CODEC is not responding! hdacc0: at cad 0 on hdac0 hdaa0: at nid 1 on hdacc0 pcm0: at nid 18,17 and 28,20,21 on hdaa0 pcm1: at nid 27 on hdaa0 -hdacc1: at cad 1 on hdac0 -unknown: at nid 2 on hdacc1 (no driver attached) random: unblocking device. usbus0: 12Mbps Full Speed USB v1.0 usbus1: 12Mbps Full Speed USB v1.0 Note that with modem disabled, it's not suspend that fails - it's the resuming. On 0605T2152, Adrian Chadd wrote: > ok so when you disable the modem, does it still think there's a modem > there? Is it still trying to power the device off via ACPI even though > it's not probed? > > > -a > > > On 5 June 2014 10:50, Sean Bruno wrote: > > On Wed, 2014-06-04 at 15:32 -0700, Adrian Chadd wrote: > >> Hi, > >> > >> Please also document why it is/isn't working. It's only documented as > >> "suspend/resume doesn't work" :) > >> > >> > >> -a > > > > > > Well there's this that trasz updated to indicate that it works: > > https://wiki.freebsd.org/SuspendResume > > > > I just updated this to indicate the same information: > > https://wiki.freebsd.org/Laptops/Thinkpad_T61 > > > > sean > > From owner-freebsd-acpi@FreeBSD.ORG Fri Jun 6 23:33:15 2014 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 02D9EBCD for ; Fri, 6 Jun 2014 23:33:15 +0000 (UTC) Received: from mail-qg0-x232.google.com (mail-qg0-x232.google.com [IPv6:2607:f8b0:400d:c04::232]) (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 B83192C60 for ; Fri, 6 Jun 2014 23:33:14 +0000 (UTC) Received: by mail-qg0-f50.google.com with SMTP id z60so5900277qgd.9 for ; Fri, 06 Jun 2014 16:33:13 -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:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=W2yQDVLk8r15oCTsW+pNLLcSIjI+uqmsyWqn9eGnsEU=; b=YrH0KTGa/IdaI0ubW4BoKInLzU1B81FRUBljXeWI/WZ9W+PGSUuEsZxmIBDn9PtfY/ XHl7RIc/hfKYs9JnsmJpFUvxWKKO7ENgvG5yHeLQp0eXT4lhyc3Z/rlIAYOsL68fgiHh DbJsl3jgQ8W1Rb4+HzrC3Mzfobng1zAXXB2qVlAbLxT+26Pw9zc91lVo+tfHiYd7laqO 3a4F47a5IGGYVDIX734uaP2qbQuy4j+1a+BrHsCSj0eAFRaR+YhfACjtx5B7goZL6Qyc ffoa9NEY3WmqeHrvWKaUOWMZXyebh6yZIzzk972X3iAX4GX0q/h64gb91p6oHb/PlSi7 ysug== MIME-Version: 1.0 X-Received: by 10.140.91.5 with SMTP id y5mr13066380qgd.12.1402097593807; Fri, 06 Jun 2014 16:33:13 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.43.134 with HTTP; Fri, 6 Jun 2014 16:33:13 -0700 (PDT) In-Reply-To: <538F16B5.8040208@att.net> References: <538F16B5.8040208@att.net> Date: Fri, 6 Jun 2014 16:33:13 -0700 X-Google-Sender-Auth: u_g1hWLwOdwp5D1hqTLAfSecNf0 Message-ID: Subject: Re: [PATCH] Naive implementation of AcpiExCmosSpaceHandler() From: Adrian Chadd To: Anthony Jenkins Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "freebsd-acpi@freebsd.org" X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jun 2014 23:33:15 -0000 Hi! Would you mind throwing this into a bugzilla report? https://bugs.freebsd.org/bugzilla/ That way it won't get lost? Let me know what number it is and I'll chase it down and get it into -HEAD. Thanks! -a On 4 June 2014 05:53, Anthony Jenkins wrote: > Here's a naive implementation of AcpiExCmosSpaceHandler(), it simply uses= I/O ports 0x70 and 0x71 to read/write CMOS registers using AcpiHwWritePort= ()/AcpiHwReadPort() calls. I'm new(ish) to the ACPICA subsystem and I'm pr= obably not going about this the right way - I think I should implement an a= ctual CMOS RTC device which handles the three PNP IDs that represent those = hardware devices, but this was good enough for what I was trying to do. > > This fixes my HP Envy 6z-1100 laptop's suspend/resume (except video fails= to resume, but I believe that's due to backlight handling from my research= ). Before, initiating a suspend (zzz(8)) caused the laptop to seemingly su= spend and immediately resume. > > Now trying to track down the backlight issue. I implemented a missing _BQ= C method which returns a single value from the _BCL listj; I think Linux do= es some kind of vendor backlight control method if this method is missing. > > Suggestions welcome. > Anthony Jenkins > > Index: sys/contrib/dev/acpica/components/events/evhandler.c > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- sys/contrib/dev/acpica/components/events/evhandler.c (revision 266= 756) > +++ sys/contrib/dev/acpica/components/events/evhandler.c (working copy= ) > @@ -70,6 +70,7 @@ > ACPI_ADR_SPACE_SYSTEM_MEMORY, > ACPI_ADR_SPACE_SYSTEM_IO, > ACPI_ADR_SPACE_PCI_CONFIG, > + ACPI_ADR_SPACE_CMOS, > ACPI_ADR_SPACE_DATA_TABLE > }; > > @@ -379,9 +380,12 @@ > */ > if ((Node->Type !=3D ACPI_TYPE_DEVICE) && > (Node->Type !=3D ACPI_TYPE_PROCESSOR) && > + (Node->Type !=3D ACPI_TYPE_REGION) && > (Node->Type !=3D ACPI_TYPE_THERMAL) && > (Node !=3D AcpiGbl_RootNode)) > { > + ACPI_DEBUG_PRINT ((ACPI_DB_OPREGION, > + "Device %p not a DEVICE, PROCESSOR, REGION, THERMAL type or = root node.\n", Node)); > Status =3D AE_BAD_PARAMETER; > goto UnlockAndExit; > } > Index: sys/contrib/dev/acpica/components/executer/exregion.c > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- sys/contrib/dev/acpica/components/executer/exregion.c (revision 26= 6756) > +++ sys/contrib/dev/acpica/components/executer/exregion.c (working cop= y) > @@ -449,7 +449,21 @@ > return_ACPI_STATUS (Status); > } > > +static UINT8 AcpiExCmosRead(ACPI_PHYSICAL_ADDRESS Address) > +{ > + UINT32 Value32; > > + AcpiHwWritePort((ACPI_IO_ADDRESS) 0x70, (UINT32) Address, 8); > + AcpiHwReadPort ((ACPI_IO_ADDRESS) 0x71, &Value32, 8); > + return Value32 & 0xFF; > +} > + > +static void AcpiExCmosWrite(ACPI_PHYSICAL_ADDRESS Address, UINT8 Value) > +{ > + AcpiHwWritePort((ACPI_IO_ADDRESS) 0x70, (UINT32) Address, 8); > + AcpiHwWritePort((ACPI_IO_ADDRESS) 0x71, (UINT32) Value, 8); > +} > + > /***********************************************************************= ******** > * > * FUNCTION: AcpiExCmosSpaceHandler > @@ -473,7 +487,7 @@ > UINT32 Function, > ACPI_PHYSICAL_ADDRESS Address, > UINT32 BitWidth, > - UINT64 *Value, > + UINT64 *Value64, > void *HandlerContext, > void *RegionContext) > { > @@ -482,7 +496,23 @@ > > ACPI_FUNCTION_TRACE (ExCmosSpaceHandler); > > + if (Address < 0x80 && > + (Function =3D=3D ACPI_READ || Function =3D=3D ACPI_WRITE) && > + BitWidth <=3D 64) > + { > + UINT32 i; > + UINT8 *Value =3D (UINT8 *)Value64; > > + for (i =3D 0; i < (BitWidth + 7) / 8; ++i, ++Address, ++Value) { > + if (Function =3D=3D ACPI_READ) { > + *Value =3D AcpiExCmosRead(Address); > + } else { > + AcpiExCmosWrite(Address, *Value); > + } > + } > + } else { > + Status =3D AE_BAD_PARAMETER; > + } > return_ACPI_STATUS (Status); > } > > Index: sys/contrib/dev/acpica/include/acconfig.h > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- sys/contrib/dev/acpica/include/acconfig.h (revision 266756) > +++ sys/contrib/dev/acpica/include/acconfig.h (working copy) > @@ -194,7 +194,7 @@ > /* Maximum SpaceIds for Operation Regions */ > > #define ACPI_MAX_ADDRESS_SPACE 255 > -#define ACPI_NUM_DEFAULT_SPACES 4 > +#define ACPI_NUM_DEFAULT_SPACES 5 > > /* Array sizes. Used for range checking also */ > > > > _______________________________________________ > freebsd-acpi@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-acpi > To unsubscribe, send any mail to "freebsd-acpi-unsubscribe@freebsd.org" From owner-freebsd-acpi@FreeBSD.ORG Sat Jun 7 00:05:38 2014 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from hammer.pct.niksun.com (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by hub.freebsd.org (Postfix) with ESMTP id D3CE451A; Sat, 7 Jun 2014 00:05:37 +0000 (UTC) Message-ID: <53925751.4060007@FreeBSD.org> Date: Fri, 06 Jun 2014 20:05:37 -0400 From: Jung-uk Kim User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Adrian Chadd , Anthony Jenkins Subject: Re: [PATCH] Naive implementation of AcpiExCmosSpaceHandler() References: <538F16B5.8040208@att.net> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "freebsd-acpi@freebsd.org" X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Jun 2014 00:05:38 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2014-06-06 19:33:13 -0400, Adrian Chadd wrote: > Hi! > > Would you mind throwing this into a bugzilla report? > > https://bugs.freebsd.org/bugzilla/ > > That way it won't get lost? > > Let me know what number it is and I'll chase it down and get it > into -HEAD. ... Actually, it is a patch for upstream to review. https://bugs.acpica.org https://lists.acpica.org/mailman/listinfo https://github.com/acpica/acpica Jung-uk Kim -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBAgAGBQJTkldRAAoJEHyflib82/FGnoEH/A2t0nFfkIHSEPICxvuQKucB D1sG3oQjn4tScyL7Izy4mhGLev7b0zw0u8g1GbAkva8lrr/NSUOgBS5aS/o+LMLE 6gddnOGlpq5BZCBsddpSpKqSIahQarzDHlqhd4mhF9dox+D4XsZ8IfiVIteEjXyc K/UscdtBHc2SKLRWpbBzm3eS2SRB0R6fRoUkPcZ1MW6y0Np95zUwsa/Ok8vemwyP /X5u33Q2OdTSwlhQBE7hR3iszEebpvS0+cBUKcM6PFV8RZLlZXMOxdkTyx6o+nxq 5rHsoCZWOn9/yLYxs0NetoLZrm00/nq2LcMTBAE1qJZWfXxKmZ1BSAp7SKZ8zes= =ZRDm -----END PGP SIGNATURE----- From owner-freebsd-acpi@FreeBSD.ORG Sat Jun 7 00:49:59 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 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id ADF0F109; Sat, 7 Jun 2014 00:49:59 +0000 (UTC) Received: from mail-qg0-x231.google.com (mail-qg0-x231.google.com [IPv6:2607:f8b0:400d:c04::231]) (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 5EE9C22EA; Sat, 7 Jun 2014 00:49:59 +0000 (UTC) Received: by mail-qg0-f49.google.com with SMTP id a108so5825129qge.22 for ; Fri, 06 Jun 2014 17:49:58 -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:message-id:subject :from:to:cc:content-type; bh=rNpJ8xxEGWBdeUgN7t1D1t15Ku8WBpb76Dybx1WlbYs=; b=GoIfZpdezejfsnlqsyj8k9dc7dDO6rQTok8D6uKFJRAHrRaNbETZ9s1jSUBlt5mg9F naBrBQGxgtoT5OrxTWdfloVF76JfUc/lUkiwlSR4VYlqYhxQyrVzNoBFpIIfaWxx428u pqfVATXGXJv+yi7HAON1p5RVHphjmrTxjVPONALmRfmt9ocPsHkOgWZ4AlcgsPgpu9mw F8yomLLhlZfA4/HuZje4szKhLANQI0umDeaJadMAZD1hU3IWhPebM4ZJEOguzxMldxns 6jKXTJNIQ4e9FW3AcLW/alO7xSiQYq1nfp9kqfeRnhdCUDEwJRHE38G7b4ZGQ5hywS5h hxDw== MIME-Version: 1.0 X-Received: by 10.224.37.10 with SMTP id v10mr13882235qad.98.1402102198503; Fri, 06 Jun 2014 17:49:58 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.43.134 with HTTP; Fri, 6 Jun 2014 17:49:58 -0700 (PDT) In-Reply-To: <53925751.4060007@FreeBSD.org> References: <538F16B5.8040208@att.net> <53925751.4060007@FreeBSD.org> Date: Fri, 6 Jun 2014 17:49:58 -0700 X-Google-Sender-Auth: wSFXbL3w_mgRwqI6JUoIelCWFU4 Message-ID: Subject: Re: [PATCH] Naive implementation of AcpiExCmosSpaceHandler() From: Adrian Chadd To: Jung-uk Kim Content-Type: text/plain; charset=UTF-8 Cc: Anthony Jenkins , "freebsd-acpi@freebsd.org" X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Jun 2014 00:49:59 -0000 ah! you're zetalog? -a On 6 June 2014 17:05, Jung-uk Kim wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 2014-06-06 19:33:13 -0400, Adrian Chadd wrote: >> Hi! >> >> Would you mind throwing this into a bugzilla report? >> >> https://bugs.freebsd.org/bugzilla/ >> >> That way it won't get lost? >> >> Let me know what number it is and I'll chase it down and get it >> into -HEAD. > ... > Actually, it is a patch for upstream to review. > > https://bugs.acpica.org > https://lists.acpica.org/mailman/listinfo > https://github.com/acpica/acpica > > Jung-uk Kim > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2 > > iQEcBAEBAgAGBQJTkldRAAoJEHyflib82/FGnoEH/A2t0nFfkIHSEPICxvuQKucB > D1sG3oQjn4tScyL7Izy4mhGLev7b0zw0u8g1GbAkva8lrr/NSUOgBS5aS/o+LMLE > 6gddnOGlpq5BZCBsddpSpKqSIahQarzDHlqhd4mhF9dox+D4XsZ8IfiVIteEjXyc > K/UscdtBHc2SKLRWpbBzm3eS2SRB0R6fRoUkPcZ1MW6y0Np95zUwsa/Ok8vemwyP > /X5u33Q2OdTSwlhQBE7hR3iszEebpvS0+cBUKcM6PFV8RZLlZXMOxdkTyx6o+nxq > 5rHsoCZWOn9/yLYxs0NetoLZrm00/nq2LcMTBAE1qJZWfXxKmZ1BSAp7SKZ8zes= > =ZRDm > -----END PGP SIGNATURE----- From owner-freebsd-acpi@FreeBSD.ORG Sat Jun 7 03:39:24 2014 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 639DB1E9 for ; Sat, 7 Jun 2014 03:39:24 +0000 (UTC) Received: from nm1-vm4.access.bullet.mail.gq1.yahoo.com (nm1-vm4.access.bullet.mail.gq1.yahoo.com [216.39.63.89]) (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 0F85F2323 for ; Sat, 7 Jun 2014 03:39:24 +0000 (UTC) Received: from [216.39.60.174] by nm1.access.bullet.mail.gq1.yahoo.com with NNFMP; 07 Jun 2014 03:33:47 -0000 Received: from [98.138.226.243] by tm10.access.bullet.mail.gq1.yahoo.com with NNFMP; 07 Jun 2014 03:33:47 -0000 Received: from [127.0.0.1] by smtp114.sbc.mail.ne1.yahoo.com with NNFMP; 07 Jun 2014 03:33:47 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1402112027; bh=0G4aVqKn2cLS/xPI6i9If97U3RXx3DlVDLqe0D0LtzU=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=D3JSy+iCqgcEeNWQvZX2I6Ip5T4WxrLtvg6VCRfJufErSNSNtMZgJ8V4ovEFwwAaLLnvJ57MT0CjUrFEdBmK3UCsYxgJTQA0aOuqeZu7YQ87nzOshxksL9b4EBeCeUV5RCGDTmTRSHf45ht6tffFJMSJsBQHSGAWROCmXVmgr38= X-Yahoo-Newman-Id: 265637.40292.bm@smtp114.sbc.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: LNtWvW4VM1krxwLnooyeZTO3lSHKWrZaxe_bahbgO_RyTqh XHqnvKUB1DNBeYqwZdCDCi.MuBsFaFvgUOhpkO3uKSi1Zdl4MfERJqq5JrGK AidRrxlGnVwX_e5ayVmaY8UnIfNihgCQjvHYpa_8MKoyLhpxYjZVZdqmpWeh 28CiEXEaoANh8p3mj9dPl4n848TscO3jAMaSSsF2wcRVNR8p_DdKIcsm3ktq PsqxBZYPlkEgtcT_LhfAbmRnZYy9Dpv6PCskTPncKX0zquYdZp_4zUYLuUb5 rVoFSA5yLWF_DfFTYDH6qOpGnZe_H1hYnY6AtiSF7B5pbT36lIYC1TdeXzYU b.EjWBwrNPkU66NLQK29y57YFBJ1B_f_Oey17zDkhXFvsdVLznnrVnPFdOEQ c8bqmwR18gyRXrE93z5MG.lhg84CxtAKXMdYwhOyIvcL2Bn4edCNI9Pnlxak fiXnG60APiquGvhV.omUHTb9_prUYf3yEmSxweCS9ApKv0ue4QEgHD5sEDIK ZgyUyZfp7s4DZjQrxfl6xif9PLUWB.f.d9SSsz9G5KRUM2UjF1NYUVH24ONm qLBssXxgjjkCiOVSjnLuXnubAICvFnmUIqa_y5vLgGcxQn8trbZcnrgiyHq9 p6bRCiPARihzAG_wi2.Iccp1QOJo5egm8Uj8.yq9CpCxWtLru_AaT.fQT1UL j7cUq84TmJyioPciS99DqnjdFXVrrmwev5ifxgC0ABh08kfw- X-Yahoo-SMTP: OKD1keCswBBTAmAF1s00hLyKW3wE3YfSK0Eazl6b4VZG4LTqJxg- X-Rocket-Received: from [192.168.1.134] (Anthony.B.Jenkins@99.62.101.19 with plain [98.138.84.52]) by smtp114.sbc.mail.ne1.yahoo.com with SMTP; 07 Jun 2014 03:33:47 +0000 UTC Message-ID: <53928819.8090402@att.net> Date: Fri, 06 Jun 2014 23:33:45 -0400 From: Anthony Jenkins User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Jung-uk Kim , Adrian Chadd Subject: Re: [PATCH] Naive implementation of AcpiExCmosSpaceHandler() References: <538F16B5.8040208@att.net> <53925751.4060007@FreeBSD.org> In-Reply-To: <53925751.4060007@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "freebsd-acpi@freebsd.org" X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Jun 2014 03:39:24 -0000 On 06/06/2014 20:05, Jung-uk Kim wrote: > On 2014-06-06 19:33:13 -0400, Adrian Chadd wrote: > > Hi! > > > Would you mind throwing this into a bugzilla report? > > > https://bugs.freebsd.org/bugzilla/ > > > That way it won't get lost? > > > Let me know what number it is and I'll chase it down and get it > > into -HEAD. > ... > Actually, it is a patch for upstream to review. > > https://bugs.acpica.org > https://lists.acpica.org/mailman/listinfo > https://github.com/acpica/acpica I just got the acpica git repo & applied my changes there to submit; I'll post the patch to the mailing list tonight or tomorrow. That list doesn't see a lot of traffic, looking at the archives... Anthony > > Jung-uk Kim > From owner-freebsd-acpi@FreeBSD.ORG Sat Jun 7 14:30:24 2014 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B9BC1769 for ; Sat, 7 Jun 2014 14:30:24 +0000 (UTC) Received: from nm22-vm6.access.bullet.mail.bf1.yahoo.com (nm22-vm6.access.bullet.mail.bf1.yahoo.com [216.109.115.149]) (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 72A6C2218 for ; Sat, 7 Jun 2014 14:30:24 +0000 (UTC) Received: from [66.196.81.163] by nm22.access.bullet.mail.bf1.yahoo.com with NNFMP; 07 Jun 2014 14:28:12 -0000 Received: from [98.138.226.241] by tm9.access.bullet.mail.bf1.yahoo.com with NNFMP; 07 Jun 2014 14:28:12 -0000 Received: from [127.0.0.1] by smtp112.sbc.mail.ne1.yahoo.com with NNFMP; 07 Jun 2014 14:28:12 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1402151292; bh=Ts0InNUrbp0VnQzsyTUiKx46ayCGWGGp65Yyweaq69M=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:Content-Type:Content-Transfer-Encoding; b=VJDEJYP3MEnxCBkQhbC71HGVxkY0GWLAnwlUpGiOyYbiNRxoKmx8T9OuGsisoSzANpoxsqjdoSlB5dfMxO7FoXNTBFioPHVHffWh/o7iNvTpbxzPxcWOgoMsY1zNc3AnmwalCFgKXI/iiyZ1KiQV9frPFjUo3QxSwJaldaM1vaw= X-Yahoo-Newman-Id: 611060.31744.bm@smtp112.sbc.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: Q1OruKgVM1kLQaOBsuwWPr4420IHtcALSpbRgYYi1ldoRys AbzaW_OrMxPmt7HN6mllmRG0MAeEEABN_7LxRVidtxhd3IJPrD5H2iXPyZUg mpl81pSjkj47XSrmW8umzKeIIrz33.k_VCYB46Rz5JzzcDyBY_cJszZ3zswb bfNaix_v5fQIIWLV..ID3edDrk8D2XUIvAW670s8sXWKkDN9pkhl8J4pfrts qYN.cElmy1Y4OMkBAYEDKXq3t0zbMynVbKgiSwjSD_hm._oF73mAjHgq8ynf bjyxiMbreH0MwE68IdEwo3svcJOb6B0yD5fu65E.NEAf3yFFsLDB.LvIpIfM xNOUNzLsq8NWDZWHPdwpTWk1P9PAtRbHScd_uKB5fTrSyk3U.AqpZLefT.sA QKv6LWatdF1tNzHYEYNhtRI7dC0TpILRZmVwexegf1T95kyAdvDqUBmwKrDW ZkRo7bFeg4myWAQQl0aY5WGrdAN4VMCGLz_sbEZS7hX81jYNr8ZQxsJnW2ak papPVR2oXJYB9zjjWOCbX38.rDCfItrlvqkA.J8KZy0Gkfw-- X-Yahoo-SMTP: OKD1keCswBBTAmAF1s00hLyKW3wE3YfSK0Eazl6b4VZG4LTqJxg- X-Rocket-Received: from [192.168.1.134] (Anthony.B.Jenkins@99.62.101.19 with plain [98.138.84.52]) by smtp112.sbc.mail.ne1.yahoo.com with SMTP; 07 Jun 2014 07:28:12 -0700 PDT Message-ID: <5393217B.2010101@att.net> Date: Sat, 07 Jun 2014 10:28:11 -0400 From: Anthony Jenkins User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: "devel@acpica.org" Subject: [PATCH] Naive implementation of AcpiExCmosSpaceHandler() Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "freebsd-acpi@freebsd.org" X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Jun 2014 14:30:24 -0000 I'm testing on FreeBSD 11.0-CURRENT #18 r266756M on an HP Envy Sleekbook 6z-1100 (AMD A-10). This is a naive implementation of AcpiExCmosSpaceHandler(), it simply uses I/O ports 0x70 and 0x71 to read/write CMOS registers using AcpiHwWritePort()/AcpiHwReadPort() calls. I'm new(ish) to the ACPICA subsystem and I'm probably not going about this the right way - I think I should implement an actual FreeBSD CMOS RTC device which handles the three PNP IDs that represent those hardware devices, but this was good enough for what I was trying to do. This fixes my HP Envy 6z-1100 laptop's suspend/resume (except video fails to resume, but I believe that's due to backlight handling from my research). Before, initiating a suspend (zzz(8)) caused the laptop to suspend and immediately resume. Now trying to track down the backlight issue. I implemented a missing _BQC method which returns a single value from the _BCL listj; I think Linux does some kind of vendor backlight control method if this method is missing. Suggestions on the patch or backlight issue welcome. Anthony Jenkins diff --git a/source/components/events/evhandler.c b/source/components/events/evhandler.c index d17411e..4f341ca 100644 --- a/source/components/events/evhandler.c +++ b/source/components/events/evhandler.c @@ -142,6 +142,7 @@ UINT8 AcpiGbl_DefaultAddressSpaces[ACPI_NUM_DEFAULT_SPACES] = ACPI_ADR_SPACE_SYSTEM_MEMORY, ACPI_ADR_SPACE_SYSTEM_IO, ACPI_ADR_SPACE_PCI_CONFIG, + ACPI_ADR_SPACE_CMOS, ACPI_ADR_SPACE_DATA_TABLE }; @@ -451,9 +452,12 @@ AcpiEvInstallSpaceHandler ( */ if ((Node->Type != ACPI_TYPE_DEVICE) && (Node->Type != ACPI_TYPE_PROCESSOR) && + (Node->Type != ACPI_TYPE_REGION) && (Node->Type != ACPI_TYPE_THERMAL) && (Node != AcpiGbl_RootNode)) { + ACPI_DEBUG_PRINT ((ACPI_DB_OPREGION, + "Device %p not a DEVICE, PROCESSOR, REGION, THERMAL type or root node.\n", Node)); Status = AE_BAD_PARAMETER; goto UnlockAndExit; } diff --git a/source/components/executer/exregion.c b/source/components/executer/exregion.c index ea10a01..bfdd721 100644 --- a/source/components/executer/exregion.c +++ b/source/components/executer/exregion.c @@ -521,6 +521,20 @@ AcpiExPciConfigSpaceHandler ( return_ACPI_STATUS (Status); } +static UINT8 AcpiExCmosRead(ACPI_PHYSICAL_ADDRESS Address) +{ + UINT32 Value32; + + AcpiHwWritePort((ACPI_IO_ADDRESS) 0x70, (UINT32) Address, 8); + AcpiHwReadPort ((ACPI_IO_ADDRESS) 0x71, &Value32, 8); + return Value32 & 0xFF; +} + +static void AcpiExCmosWrite(ACPI_PHYSICAL_ADDRESS Address, UINT8 Value) +{ + AcpiHwWritePort((ACPI_IO_ADDRESS) 0x70, (UINT32) Address, 8); + AcpiHwWritePort((ACPI_IO_ADDRESS) 0x71, (UINT32) Value, 8); +} /******************************************************************************* * @@ -545,7 +559,7 @@ AcpiExCmosSpaceHandler ( UINT32 Function, ACPI_PHYSICAL_ADDRESS Address, UINT32 BitWidth, - UINT64 *Value, + UINT64 *Value64, void *HandlerContext, void *RegionContext) { @@ -554,7 +568,23 @@ AcpiExCmosSpaceHandler ( ACPI_FUNCTION_TRACE (ExCmosSpaceHandler); - + if (Address < 0x80 && + (Function == ACPI_READ || Function == ACPI_WRITE) && + BitWidth <= 64) + { + UINT32 i; + UINT8 *Value = (UINT8 *)Value64; + + for (i = 0; i < (BitWidth + 7) / 8; ++i, ++Address, ++Value) { + if (Function == ACPI_READ) { + *Value = AcpiExCmosRead(Address); + } else { + AcpiExCmosWrite(Address, *Value); + } + } + } else { + Status = AE_BAD_PARAMETER; + } return_ACPI_STATUS (Status); } diff --git a/source/include/acconfig.h b/source/include/acconfig.h index 6b34484..7fe2eac 100644 --- a/source/include/acconfig.h +++ b/source/include/acconfig.h @@ -270,7 +270,7 @@ /* Maximum SpaceIds for Operation Regions */ #define ACPI_MAX_ADDRESS_SPACE 255 -#define ACPI_NUM_DEFAULT_SPACES 4 +#define ACPI_NUM_DEFAULT_SPACES 5 /* Array sizes. Used for range checking also */ From owner-freebsd-acpi@FreeBSD.ORG Sat Jun 7 16:21:09 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 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 96442E96; Sat, 7 Jun 2014 16:21:09 +0000 (UTC) Received: from mail-qg0-x234.google.com (mail-qg0-x234.google.com [IPv6:2607:f8b0:400d:c04::234]) (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 31E8D2B9D; Sat, 7 Jun 2014 16:21:09 +0000 (UTC) Received: by mail-qg0-f52.google.com with SMTP id a108so6809813qge.39 for ; Sat, 07 Jun 2014 09:21:08 -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:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=trsiioCEAomf13fmoDCpyLn53x/VzmSzT4w9Cw+8Xmg=; b=TKCogI3vG42EZfSOQwaUoDSYavI7Fs4knAUDt6zHul3eENC5e3OwkEnPcDpAkM0RGX cnM/0asf2P17jAt71RP9Y4JBsilNx7rCBJ89xHoiKYgDumQ+W0GKkiOD0cRRGysKzjAJ eJ2Qyw5mfH4LGYBCAutaDzF85ydgTvCZlrimg1nzPqfwpwKQYfNPtXkG1p/d8ibyDpBm zcBAFBy+3Gi7Q2ZgpON0hFspN8eGEV00SHIeVrT2dMax8fQtA29NuDSMZYpEDaLE95jh W9zyWdVv7vKaatWVoXH1CZjYpkBkYspjLOdXJok2SXqOz610TxHLIpSQcL3GJn4DhYqT 4/jg== MIME-Version: 1.0 X-Received: by 10.140.22.209 with SMTP id 75mr18183566qgn.4.1402158068293; Sat, 07 Jun 2014 09:21:08 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.43.134 with HTTP; Sat, 7 Jun 2014 09:21:08 -0700 (PDT) In-Reply-To: <20140606075737.GA826@brick.home> References: <1400861698.1126.0.camel@bruno> <1401898025.1123.17.camel@bruno> <20140604171714.GA931@brick.home> <201406041330.54793.jhb@freebsd.org> <1401979859.1123.29.camel@bruno> <20140606075737.GA826@brick.home> Date: Sat, 7 Jun 2014 12:21:08 -0400 X-Google-Sender-Auth: 5R0cKfUuJ-TtzywrzVgAEUgiDZE Message-ID: Subject: Re: Investigating failed suspend/resume T61 From: Adrian Chadd To: =?UTF-8?Q?Edward_Tomasz_Napiera=C5=82a?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "freebsd-acpi@freebsd.org" X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Jun 2014 16:21:09 -0000 That's odd. Is it still trying to resume hdac0 ? -a On 6 June 2014 03:57, Edward Tomasz Napiera=C5=82a wrot= e: > The difference in dmesg with (-) and without (+) the modem looks like thi= s: > > --- dmesg.modem 2014-06-06 09:46:02.000000000 +0200 > +++ dmesg.bez 2014-06-06 09:52:45.000000000 +0200 > @@ -48,7 +48,7 @@ Event timer "HPET1" frequency 14318180 H > Event timer "HPET2" frequency 14318180 Hz quality 440 > atrtc0: port 0x70-0x71 irq 8 on acpi0 > Event timer "RTC" frequency 32768 Hz quality 0 > -Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 > +Timecounter "ACPI-safe" frequency 3579545 Hz quality 850 > acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 > acpi_lid0: on acpi0 > acpi_button0: on acpi0 > @@ -157,12 +157,13 @@ est0: coretemp1: on cpu1 > est1: on cpu1 > Timecounters tick every 1.000 msec > +hdac0: Command timeout on address 1 > +hdac0: Command timeout on address 1 > +hdac0: CODEC is not responding! > hdacc0: at cad 0 on hdac0 > hdaa0: at nid 1 on hdacc0 > pcm0: at nid 18,17 and 28,20= ,21 on hdaa0 > pcm1: at nid 27 on hdaa0 > -hdacc1: at cad 1 on hdac0 > -unknown: at nid 2 on = hdacc1 (no driver attached) > random: unblocking device. > usbus0: 12Mbps Full Speed USB v1.0 > usbus1: 12Mbps Full Speed USB v1.0 > > Note that with modem disabled, it's not suspend that fails - it's the > resuming. > > On 0605T2152, Adrian Chadd wrote: >> ok so when you disable the modem, does it still think there's a modem >> there? Is it still trying to power the device off via ACPI even though >> it's not probed? >> >> >> -a >> >> >> On 5 June 2014 10:50, Sean Bruno wrote: >> > On Wed, 2014-06-04 at 15:32 -0700, Adrian Chadd wrote: >> >> Hi, >> >> >> >> Please also document why it is/isn't working. It's only documented as >> >> "suspend/resume doesn't work" :) >> >> >> >> >> >> -a >> > >> > >> > Well there's this that trasz updated to indicate that it works: >> > https://wiki.freebsd.org/SuspendResume >> > >> > I just updated this to indicate the same information: >> > https://wiki.freebsd.org/Laptops/Thinkpad_T61 >> > >> > sean >> > From owner-freebsd-acpi@FreeBSD.ORG Sat Jun 7 16:37:14 2014 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 18EA54D9; Sat, 7 Jun 2014 16:37:14 +0000 (UTC) Received: from mail-we0-x22c.google.com (mail-we0-x22c.google.com [IPv6:2a00:1450:400c:c03::22c]) (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 54EF02C9F; Sat, 7 Jun 2014 16:37:13 +0000 (UTC) Received: by mail-we0-f172.google.com with SMTP id k48so4189660wev.31 for ; Sat, 07 Jun 2014 09:37:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=cPLCcc/B/+rw3u+8HxoPYeTUMavxQXWbtXBbDRssc4o=; b=I1jvJw0LS01wfotFR9d6prqR3fsEqfrzB/uMq4piT3IS6l0L0gGY9I+lTld2YT9fDT ph0sWVhNQ8eOHm89r+g3bC7GDZt3rktb0+GPOwWbhRO4FeI2u4p47I7f9k4t7rwqlcN5 JU4Zpvx4HoGgEuALyd9n8di3LYRT1SH3mfV0SvRMneyyp785QPnLRPokMoCOqIKPvJZG lRpiop/oXdNaloMKJn0op1bxXns6himwJGX3Bz+L4aDqv91ETYz1lgs6q0P02HL794+y wfnFWRGCBF3GcbRr+Jw+mTzzmHK1pAdoZssM5pN6o2+AS331rjzJc5fHE4ZBv+5Ejm/X KzbQ== X-Received: by 10.14.216.135 with SMTP id g7mr24552eep.55.1402159031576; Sat, 07 Jun 2014 09:37:11 -0700 (PDT) Received: from brick.home (aedr225.neoplus.adsl.tpnet.pl. [79.186.95.225]) by mx.google.com with ESMTPSA id cj41sm31430252eeb.34.2014.06.07.09.37.10 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 07 Jun 2014 09:37:11 -0700 (PDT) Sender: =?UTF-8?Q?Edward_Tomasz_Napiera=C5=82a?= Date: Sat, 7 Jun 2014 18:37:08 +0200 From: Edward Tomasz =?utf-8?Q?Napiera=C5=82a?= To: Adrian Chadd Subject: Re: Investigating failed suspend/resume T61 Message-ID: <20140607163708.GB23405@brick.home> References: <1400861698.1126.0.camel@bruno> <1401898025.1123.17.camel@bruno> <20140604171714.GA931@brick.home> <201406041330.54793.jhb@freebsd.org> <1401979859.1123.29.camel@bruno> <20140606075737.GA826@brick.home> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Cc: "freebsd-acpi@freebsd.org" X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Jun 2014 16:37:14 -0000 With modem enabled? I don't know; I don't see anything related to hdac0 during resume. With modem disabled resuming is completely broken - it fails _very_ early, by failing to return from acpi_machdep_sleep() iirc. On 0607T1221, Adrian Chadd wrote: > That's odd. Is it still trying to resume hdac0 ? > > > -a > > > On 6 June 2014 03:57, Edward Tomasz NapieraÅ‚a wrote: > > The difference in dmesg with (-) and without (+) the modem looks like this: > > > > --- dmesg.modem 2014-06-06 09:46:02.000000000 +0200 > > +++ dmesg.bez 2014-06-06 09:52:45.000000000 +0200 > > @@ -48,7 +48,7 @@ Event timer "HPET1" frequency 14318180 H > > Event timer "HPET2" frequency 14318180 Hz quality 440 > > atrtc0: port 0x70-0x71 irq 8 on acpi0 > > Event timer "RTC" frequency 32768 Hz quality 0 > > -Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 > > +Timecounter "ACPI-safe" frequency 3579545 Hz quality 850 > > acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 > > acpi_lid0: on acpi0 > > acpi_button0: on acpi0 > > @@ -157,12 +157,13 @@ est0: > coretemp1: on cpu1 > > est1: on cpu1 > > Timecounters tick every 1.000 msec > > +hdac0: Command timeout on address 1 > > +hdac0: Command timeout on address 1 > > +hdac0: CODEC is not responding! > > hdacc0: at cad 0 on hdac0 > > hdaa0: at nid 1 on hdacc0 > > pcm0: at nid 18,17 and 28,20,21 on hdaa0 > > pcm1: at nid 27 on hdaa0 > > -hdacc1: at cad 1 on hdac0 > > -unknown: at nid 2 on hdacc1 (no driver attached) > > random: unblocking device. > > usbus0: 12Mbps Full Speed USB v1.0 > > usbus1: 12Mbps Full Speed USB v1.0 > > > > Note that with modem disabled, it's not suspend that fails - it's the > > resuming. > > > > On 0605T2152, Adrian Chadd wrote: > >> ok so when you disable the modem, does it still think there's a modem > >> there? Is it still trying to power the device off via ACPI even though > >> it's not probed? > >> > >> > >> -a > >> > >> > >> On 5 June 2014 10:50, Sean Bruno wrote: > >> > On Wed, 2014-06-04 at 15:32 -0700, Adrian Chadd wrote: > >> >> Hi, > >> >> > >> >> Please also document why it is/isn't working. It's only documented as > >> >> "suspend/resume doesn't work" :) > >> >> > >> >> > >> >> -a > >> > > >> > > >> > Well there's this that trasz updated to indicate that it works: > >> > https://wiki.freebsd.org/SuspendResume > >> > > >> > I just updated this to indicate the same information: > >> > https://wiki.freebsd.org/Laptops/Thinkpad_T61 > >> > > >> > sean > >> > From owner-freebsd-acpi@FreeBSD.ORG Tue Jun 10 14:55:02 2014 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EAED5AAC for ; Tue, 10 Jun 2014 14:55:02 +0000 (UTC) Received: from marnier.ucs.louisiana.edu (ucs.louisiana.edu [130.70.132.233]) by mx1.freebsd.org (Postfix) with ESMTP id A03962EE3 for ; Tue, 10 Jun 2014 14:55:01 +0000 (UTC) Received: from zimbra-mta01.ucs.louisiana.edu (zimbra-mta01.ucs.louisiana.edu [130.70.132.57]) by marnier.ucs.louisiana.edu (8.14.1/8.14.1/ull-ucs-mx-host_1.9a) with ESMTP id s5AEsoSB013135 for ; Tue, 10 Jun 2014 09:54:55 -0500 (CDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra-mta01.ucs.louisiana.edu (Postfix) with ESMTP id 7B65423CC04 for ; Tue, 10 Jun 2014 09:54:50 -0500 (CDT) X-Virus-Scanned: amavisd-new at zimbra-mta01.ucs.louisiana.edu Received: from zimbra-mta01.ucs.louisiana.edu ([127.0.0.1]) by localhost (zimbra-mta01.ucs.louisiana.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TGq5No2rlIRB for ; Tue, 10 Jun 2014 09:54:50 -0500 (CDT) Received: from [130.70.83.68] (canpc36.cacs.louisiana.edu [130.70.83.68]) by zimbra-mta01.ucs.louisiana.edu (Postfix) with ESMTPSA id 3C13623CC9C for ; Tue, 10 Jun 2014 09:54:50 -0500 (CDT) Message-ID: <1402412054.2426.13.camel@canpc36.cacs.louisiana.edu> Subject: Missing: hw.acpi.thermal.tz%d._HOT From: Eric Neblock To: freebsd-acpi@freebsd.org Date: Tue, 10 Jun 2014 09:54:14 -0500 Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-Lg9sUsF/gZyYzH9RyPPc" X-Mailer: Evolution 3.10.2 Mime-Version: 1.0 X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jun 2014 14:55:03 -0000 --=-Lg9sUsF/gZyYzH9RyPPc Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello all, I'm trying to figure out what is the _HOT temperature on my particular processor. I'm running FreeBSD 10 GENERIC on a Sunfire X2200. The processor is an Dual Core AMD Opteron 2218. In the GENERIC kernel, acpi is built in; so, kldload acpi fails. I've also loaded the amdtemp module at boot time to figure out what the current temp of the processor is. With all of that, when performing `sysctl -a` I never seem to be able to pull up the _HOT value.=20 Are there any suggestions on how to be able to view it? Thanks, Eric --=-Lg9sUsF/gZyYzH9RyPPc Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEABECAAYFAlOXHEAACgkQbOB8sc0AlGU9dACfWdoQS75PBpTcMh2R07Sn/M43 A2cAoLxvLkifRzK91pOn7bdYHMq7Gc2D =QN16 -----END PGP SIGNATURE----- --=-Lg9sUsF/gZyYzH9RyPPc-- From owner-freebsd-acpi@FreeBSD.ORG Tue Jun 10 15:33:37 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 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8AF818F1 for ; Tue, 10 Jun 2014 15:33:37 +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 4136A2307 for ; Tue, 10 Jun 2014 15:33:35 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id s5AFXM2X022543; Wed, 11 Jun 2014 01:33:23 +1000 (EST) (envelope-from smithi@nimnet.asn.au) Date: Wed, 11 Jun 2014 01:33:22 +1000 (EST) From: Ian Smith To: Eric Neblock Subject: Re: Missing: hw.acpi.thermal.tz%d._HOT In-Reply-To: <1402412054.2426.13.camel@canpc36.cacs.louisiana.edu> Message-ID: <20140611011810.V10629@sola.nimnet.asn.au> References: <1402412054.2426.13.camel@canpc36.cacs.louisiana.edu> 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 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jun 2014 15:33:37 -0000 On Tue, 10 Jun 2014 09:54:14 -0500, Eric Neblock wrote: > Hello all, > I'm trying to figure out what is the _HOT temperature on my particular > processor. I'm running FreeBSD 10 GENERIC on a Sunfire X2200. > > The processor is an Dual Core AMD Opteron 2218. > > In the GENERIC kernel, acpi is built in; so, kldload acpi fails. I've > also loaded the amdtemp module at boot time to figure out what the > current temp of the processor is. > > With all of that, when performing `sysctl -a` I never seem to be able to > pull up the _HOT value. > > Are there any suggestions on how to be able to view it? Many thermal zones seen, including some CPUs, don't specify any _HOT value, just _PSV and _CRT, which should trigger passive cooling (eg clock slowing or throttling) and emergency shutdown, respectively. What says 'sysctl hw.acpi.thermal' ? cheers, Ian From owner-freebsd-acpi@FreeBSD.ORG Tue Jun 10 15:40:26 2014 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2F260AB4 for ; Tue, 10 Jun 2014 15:40:26 +0000 (UTC) Received: from marnier.ucs.louisiana.edu (ucs.louisiana.edu [130.70.132.233]) by mx1.freebsd.org (Postfix) with ESMTP id BD65E2350 for ; Tue, 10 Jun 2014 15:40:25 +0000 (UTC) Received: from zimbra-mta01.ucs.louisiana.edu (zimbra-mta01.ucs.louisiana.edu [130.70.132.57]) by marnier.ucs.louisiana.edu (8.14.1/8.14.1/ull-ucs-mx-host_1.9a) with ESMTP id s5AFeJDX018061; Tue, 10 Jun 2014 10:40:24 -0500 (CDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra-mta01.ucs.louisiana.edu (Postfix) with ESMTP id 6564323CCE2; Tue, 10 Jun 2014 10:40:19 -0500 (CDT) X-Virus-Scanned: amavisd-new at zimbra-mta01.ucs.louisiana.edu Received: from zimbra-mta01.ucs.louisiana.edu ([127.0.0.1]) by localhost (zimbra-mta01.ucs.louisiana.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QDHlSdplVa3l; Tue, 10 Jun 2014 10:40:19 -0500 (CDT) Received: from [130.70.83.68] (canpc36.cacs.louisiana.edu [130.70.83.68]) by zimbra-mta01.ucs.louisiana.edu (Postfix) with ESMTPSA id 1D40B23CCCB; Tue, 10 Jun 2014 10:40:19 -0500 (CDT) Message-ID: <1402414819.17836.2.camel@canpc36.cacs.louisiana.edu> Subject: Re: Missing: hw.acpi.thermal.tz%d._HOT From: Eric Neblock To: Ian Smith Date: Tue, 10 Jun 2014 10:40:19 -0500 In-Reply-To: <20140611011810.V10629@sola.nimnet.asn.au> References: <1402412054.2426.13.camel@canpc36.cacs.louisiana.edu> <20140611011810.V10629@sola.nimnet.asn.au> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-zFtQvV1VnZKRacW/oLNH" X-Mailer: Evolution 3.10.2 Mime-Version: 1.0 Cc: freebsd-acpi@freebsd.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jun 2014 15:40:26 -0000 --=-zFtQvV1VnZKRacW/oLNH Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, 2014-06-11 at 01:33 +1000, Ian Smith wrote: > On Tue, 10 Jun 2014 09:54:14 -0500, Eric Neblock wrote: > > Hello all, > > I'm trying to figure out what is the _HOT temperature on my particul= ar > > processor. I'm running FreeBSD 10 GENERIC on a Sunfire X2200. > >=20 > > The processor is an Dual Core AMD Opteron 2218. > >=20 > > In the GENERIC kernel, acpi is built in; so, kldload acpi fails. I've > > also loaded the amdtemp module at boot time to figure out what the > > current temp of the processor is. > >=20 > > With all of that, when performing `sysctl -a` I never seem to be able = to > > pull up the _HOT value.=20 > >=20 > > Are there any suggestions on how to be able to view it? >=20 > Many thermal zones seen, including some CPUs, don't specify any _HOT=20 > value, just _PSV and _CRT, which should trigger passive cooling (eg=20 > clock slowing or throttling) and emergency shutdown, respectively. >=20 > What says 'sysctl hw.acpi.thermal' ? >=20 > cheers, Ian The result is as follows: sysctl: Unknown oid 'hw.acpi.thermal' : No such file or directory Eric --=-zFtQvV1VnZKRacW/oLNH Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEABECAAYFAlOXJukACgkQbOB8sc0AlGWAhQCgi5sxqUZtz0vSxtbdgW9VvdtI rGEAnA08qbyJp3Y+XuUKf47gwzAAbf+2 =3awX -----END PGP SIGNATURE----- --=-zFtQvV1VnZKRacW/oLNH-- From owner-freebsd-acpi@FreeBSD.ORG Tue Jun 10 16:19:42 2014 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 715693A2 for ; Tue, 10 Jun 2014 16:19:42 +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 47B252727 for ; Tue, 10 Jun 2014 16:19:40 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id s5AGJX1V024129; Wed, 11 Jun 2014 02:19:34 +1000 (EST) (envelope-from smithi@nimnet.asn.au) Date: Wed, 11 Jun 2014 02:19:33 +1000 (EST) From: Ian Smith To: Eric Neblock Subject: Re: Missing: hw.acpi.thermal.tz%d._HOT In-Reply-To: <1402414819.17836.2.camel@canpc36.cacs.louisiana.edu> Message-ID: <20140611020626.X10629@sola.nimnet.asn.au> References: <1402412054.2426.13.camel@canpc36.cacs.louisiana.edu> <20140611011810.V10629@sola.nimnet.asn.au> <1402414819.17836.2.camel@canpc36.cacs.louisiana.edu> 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 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jun 2014 16:19:42 -0000 On Tue, 10 Jun 2014 10:40:19 -0500, Eric Neblock wrote: > On Wed, 2014-06-11 at 01:33 +1000, Ian Smith wrote: > > On Tue, 10 Jun 2014 09:54:14 -0500, Eric Neblock wrote: > > > Hello all, > > > I'm trying to figure out what is the _HOT temperature on my particular > > > processor. I'm running FreeBSD 10 GENERIC on a Sunfire X2200. > > > > > > The processor is an Dual Core AMD Opteron 2218. > > > > > > In the GENERIC kernel, acpi is built in; so, kldload acpi fails. I've > > > also loaded the amdtemp module at boot time to figure out what the > > > current temp of the processor is. > > > > > > With all of that, when performing `sysctl -a` I never seem to be able to > > > pull up the _HOT value. > > > > > > Are there any suggestions on how to be able to view it? > > > > Many thermal zones seen, including some CPUs, don't specify any _HOT > > value, just _PSV and _CRT, which should trigger passive cooling (eg > > clock slowing or throttling) and emergency shutdown, respectively. > > > > What says 'sysctl hw.acpi.thermal' ? > > > > cheers, Ian > > The result is as follows: > > sysctl: Unknown oid 'hw.acpi.thermal' : No such file or directory > > Eric Sorry Eric, I know nothing about the Suns, and should have noticed. Suggest showing 'sysctl hw.acpi' and waiting for someone with a clue. cheers, Ian From owner-freebsd-acpi@FreeBSD.ORG Wed Jun 11 01:41:17 2014 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A82F062C for ; Wed, 11 Jun 2014 01:41:17 +0000 (UTC) Received: from alogt.com (alogt.com [69.36.191.58]) (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 828A228C1 for ; Wed, 11 Jun 2014 01:41:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=alogt.com; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:References:In-Reply-To:Message-ID:Subject:Cc:To:From:Date; bh=iy1i8/PHmWx1dfpoHcEcqL5A59ZFL8hsLKZ6+uhdAzI=; b=YaLOoA7mblPtKSDUnT/GFenWAc+T56ZOY6KgdPmxk5dQhyx3aOV54vsFXSUNvbttW5oCuMQV7H28mZV+1KipJ7f5zTqKJ195akY/7mSQtEB5tD/iAt0rmdoaitAltr4aaSsWhHlkRtX2rux+NSPiEMn/q2/rXLP5um6k7DMoxsI=; Received: from [39.192.15.163] (port=29070 helo=X220.alogt.com) by sl-508-2.slc.westdc.net with esmtpsa (SSLv3:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WuXXK-001Qdl-2y; Tue, 10 Jun 2014 19:41:10 -0600 Date: Wed, 11 Jun 2014 09:41:04 +0800 From: Erich Dollansky To: Eric Neblock Subject: Re: Missing: hw.acpi.thermal.tz%d._HOT Message-ID: <20140611094104.5e6aadb0@X220.alogt.com> In-Reply-To: <1402412054.2426.13.camel@canpc36.cacs.louisiana.edu> References: <1402412054.2426.13.camel@canpc36.cacs.louisiana.edu> X-Mailer: Claws Mail 3.9.3 (GTK+ 2.24.22; amd64-portbld-freebsd10.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - sl-508-2.slc.westdc.net X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - alogt.com X-Get-Message-Sender-Via: sl-508-2.slc.westdc.net: authenticated_id: erichsfreebsdlist@alogt.com X-Source: X-Source-Args: X-Source-Dir: Cc: freebsd-acpi@freebsd.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jun 2014 01:41:17 -0000 Hi, I have had to use k8temp from ports on my old AMD machine. Erich On Tue, 10 Jun 2014 09:54:14 -0500 Eric Neblock wrote: > Hello all, > I'm trying to figure out what is the _HOT temperature on my > particular processor. I'm running FreeBSD 10 GENERIC on a Sunfire > X2200. > > The processor is an Dual Core AMD Opteron 2218. > > In the GENERIC kernel, acpi is built in; so, kldload acpi fails. I've > also loaded the amdtemp module at boot time to figure out what the > current temp of the processor is. > > With all of that, when performing `sysctl -a` I never seem to be able > to pull up the _HOT value. > > Are there any suggestions on how to be able to view it? > > Thanks, > Eric From owner-freebsd-acpi@FreeBSD.ORG Wed Jun 11 13:57:56 2014 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 316C44EE for ; Wed, 11 Jun 2014 13:57:56 +0000 (UTC) Received: from marnier.ucs.louisiana.edu (ucs.louisiana.edu [130.70.132.233]) by mx1.freebsd.org (Postfix) with ESMTP id BF2D02A92 for ; Wed, 11 Jun 2014 13:57:54 +0000 (UTC) Received: from zimbra-mta01.ucs.louisiana.edu (zimbra-mta01.ucs.louisiana.edu [130.70.132.57]) by marnier.ucs.louisiana.edu (8.14.1/8.14.1/ull-ucs-mx-host_1.9a) with ESMTP id s5BDvl6R002640; Wed, 11 Jun 2014 08:57:52 -0500 (CDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra-mta01.ucs.louisiana.edu (Postfix) with ESMTP id 3FB8F23CCA7; Wed, 11 Jun 2014 08:57:47 -0500 (CDT) X-Virus-Scanned: amavisd-new at zimbra-mta01.ucs.louisiana.edu Received: from zimbra-mta01.ucs.louisiana.edu ([127.0.0.1]) by localhost (zimbra-mta01.ucs.louisiana.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oQ-kyKysp3D9; Wed, 11 Jun 2014 08:57:46 -0500 (CDT) Received: from [130.70.83.68] (canpc36.cacs.louisiana.edu [130.70.83.68]) by zimbra-mta01.ucs.louisiana.edu (Postfix) with ESMTPSA id A079623CC99; Wed, 11 Jun 2014 08:57:44 -0500 (CDT) Message-ID: <1402495058.17836.5.camel@canpc36.cacs.louisiana.edu> Subject: Re: Missing: hw.acpi.thermal.tz%d._HOT From: Eric Neblock To: Erich Dollansky Date: Wed, 11 Jun 2014 08:57:38 -0500 In-Reply-To: <20140611094104.5e6aadb0@X220.alogt.com> References: <1402412054.2426.13.camel@canpc36.cacs.louisiana.edu> <20140611094104.5e6aadb0@X220.alogt.com> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-MqgJDa5i2gNUS7YytHCq" X-Mailer: Evolution 3.10.2 Mime-Version: 1.0 Cc: freebsd-acpi@freebsd.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jun 2014 13:57:56 -0000 --=-MqgJDa5i2gNUS7YytHCq Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, 2014-06-11 at 09:41 +0800, Erich Dollansky wrote: > Hi, >=20 > I have had to use k8temp from ports on my old AMD machine. >=20 > Erich Unfortunately, this doesn't appear to show anything more than what amdtemp(4) shows.=20 Thanks though, Eric > On Tue, 10 Jun 2014 09:54:14 -0500 > Eric Neblock wrote: >=20 > > Hello all, > > I'm trying to figure out what is the _HOT temperature on my > > particular processor. I'm running FreeBSD 10 GENERIC on a Sunfire > > X2200. > >=20 > > The processor is an Dual Core AMD Opteron 2218. > >=20 > > In the GENERIC kernel, acpi is built in; so, kldload acpi fails. I've > > also loaded the amdtemp module at boot time to figure out what the > > current temp of the processor is. > >=20 > > With all of that, when performing `sysctl -a` I never seem to be able > > to pull up the _HOT value.=20 > >=20 > > Are there any suggestions on how to be able to view it? > >=20 > > Thanks, > > Eric >=20 --=-MqgJDa5i2gNUS7YytHCq Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEABECAAYFAlOYYGAACgkQbOB8sc0AlGWtywCeN0DP5Eb3gcCAdF9b2zKQLNTx F5MAnR6IoPutBRxswuRPgDr1EvrmEPPR =wlAd -----END PGP SIGNATURE----- --=-MqgJDa5i2gNUS7YytHCq-- From owner-freebsd-acpi@FreeBSD.ORG Thu Jun 12 21:28:35 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 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EBB93FC2 for ; Thu, 12 Jun 2014 21:28:34 +0000 (UTC) Received: from mail-qc0-x231.google.com (mail-qc0-x231.google.com [IPv6:2607:f8b0:400d:c01::231]) (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 ACD552A8E for ; Thu, 12 Jun 2014 21:28:34 +0000 (UTC) Received: by mail-qc0-f177.google.com with SMTP id i17so2932274qcy.8 for ; Thu, 12 Jun 2014 14:28:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=VV+PL+ChtBQaofO4kr9mZgfjseHtCM+oO0nRe0w6LEw=; b=Yg8YQx6TNiYaGrOU8fHTYs59rSj9fYd/TGf0bPMu/XyrVHl/N+p3/22Cj5OQj36P2c jVJMJgfEH2w+CPHR6uDlvfiKihVq214e4KhAIYdWYBlV+OsLJiU74fykAN2OAj5Kbc/n TQsDb0Wdq8ATSujzY9W4Os6vnAQ7i5bTfqZEz47h9LXfEK5h2Y/fu4Us46HK1Y9pts7+ CPC23Edh5Wj1hGvyxTybikXr6T4ntBVfen9hdROJ2LpCX0KUJftCeK6OEfrxEKoJJ2xO ye0t3dwRKBx1uXKbhgO/Uvz4poh7eJG0dyG8K8wkZ0Luqsv0YFm4UlQcXWdtAW9E+/eU PpYQ== MIME-Version: 1.0 X-Received: by 10.140.25.166 with SMTP id 35mr35233585qgt.103.1402608513528; Thu, 12 Jun 2014 14:28:33 -0700 (PDT) Received: by 10.96.73.39 with HTTP; Thu, 12 Jun 2014 14:28:33 -0700 (PDT) In-Reply-To: <1402414819.17836.2.camel@canpc36.cacs.louisiana.edu> References: <1402412054.2426.13.camel@canpc36.cacs.louisiana.edu> <20140611011810.V10629@sola.nimnet.asn.au> <1402414819.17836.2.camel@canpc36.cacs.louisiana.edu> Date: Thu, 12 Jun 2014 14:28:33 -0700 Message-ID: Subject: Re: Missing: hw.acpi.thermal.tz%d._HOT From: hiren panchasara To: Eric Neblock Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-acpi@freebsd.org" , Ian Smith X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 21:28:35 -0000 On Tue, Jun 10, 2014 at 8:40 AM, Eric Neblock wrote: > On Wed, 2014-06-11 at 01:33 +1000, Ian Smith wrote: >> On Tue, 10 Jun 2014 09:54:14 -0500, Eric Neblock wrote: >> > Hello all, >> > I'm trying to figure out what is the _HOT temperature on my particular >> > processor. I'm running FreeBSD 10 GENERIC on a Sunfire X2200. >> > >> > The processor is an Dual Core AMD Opteron 2218. >> > >> > In the GENERIC kernel, acpi is built in; so, kldload acpi fails. I've >> > also loaded the amdtemp module at boot time to figure out what the >> > current temp of the processor is. >> > >> > With all of that, when performing `sysctl -a` I never seem to be able to >> > pull up the _HOT value. >> > >> > Are there any suggestions on how to be able to view it? >> >> Many thermal zones seen, including some CPUs, don't specify any _HOT >> value, just _PSV and _CRT, which should trigger passive cooling (eg >> clock slowing or throttling) and emergency shutdown, respectively. >> >> What says 'sysctl hw.acpi.thermal' ? >> >> cheers, Ian > > The result is as follows: > > sysctl: Unknown oid 'hw.acpi.thermal' : No such file or directory Similar thing here at home desktop running -CURRENT: CPU: AMD FX(tm)-8350 Eight-Core Processor (4000.24-MHz K8-class CPU) Origin="AuthenticAMD" Id=0x600f20 Family=0x15 Model=0x2 Stepping=0 acpi0: <7596MS A7596100> on motherboard Other related bits: # sysctl hw.acpi hw.acpi.supported_sleep_state: S3 S4 S5 hw.acpi.power_button_state: S5 hw.acpi.sleep_button_state: S3 hw.acpi.lid_switch_state: NONE hw.acpi.standby_state: NONE hw.acpi.suspend_state: S3 hw.acpi.sleep_delay: 1 hw.acpi.s4bios: 0 hw.acpi.verbose: 0 hw.acpi.disable_on_reboot: 0 hw.acpi.handle_reboot: 0 hw.acpi.reset_video: 0 hw.acpi.cpu.cx_lowest: C8 # # sysctl dev.amdtemp dev.amdtemp.0.%desc: AMD CPU On-Die Thermal Sensors dev.amdtemp.0.%driver: amdtemp dev.amdtemp.0.%parent: hostb4 dev.amdtemp.0.sensor_offset: 0 dev.amdtemp.0.core0.sensor0: 15.3C # sysctl -a dev.cpu | grep temp dev.cpu.0.temperature: 15.2C dev.cpu.1.temperature: 15.2C dev.cpu.2.temperature: 15.2C dev.cpu.3.temperature: 15.2C dev.cpu.4.temperature: 15.2C dev.cpu.5.temperature: 15.2C dev.cpu.6.temperature: 15.2C dev.cpu.7.temperature: 15.2C I am not sure how this ^ relates to what acpi reports under thermal. Cheers, Hiren From owner-freebsd-acpi@FreeBSD.ORG Fri Jun 13 16:22:12 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 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 55A15226 for ; Fri, 13 Jun 2014 16:22:12 +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 BC9942CB9 for ; Fri, 13 Jun 2014 16:22:11 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id s5DGM1t7074891; Sat, 14 Jun 2014 02:22:01 +1000 (EST) (envelope-from smithi@nimnet.asn.au) Date: Sat, 14 Jun 2014 02:22:00 +1000 (EST) From: Ian Smith To: hiren panchasara Subject: Re: Missing: hw.acpi.thermal.tz%d._HOT In-Reply-To: Message-ID: <20140614013631.J10629@sola.nimnet.asn.au> References: <1402412054.2426.13.camel@canpc36.cacs.louisiana.edu> <20140611011810.V10629@sola.nimnet.asn.au> <1402414819.17836.2.camel@canpc36.cacs.louisiana.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: "freebsd-acpi@freebsd.org" , Eric Neblock X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jun 2014 16:22:12 -0000 On Thu, 12 Jun 2014 14:28:33 -0700, hiren panchasara wrote: > On Tue, Jun 10, 2014 at 8:40 AM, Eric Neblock wrote: > > On Wed, 2014-06-11 at 01:33 +1000, Ian Smith wrote: > >> On Tue, 10 Jun 2014 09:54:14 -0500, Eric Neblock wrote: > >> > Hello all, > >> > I'm trying to figure out what is the _HOT temperature on my particular > >> > processor. I'm running FreeBSD 10 GENERIC on a Sunfire X2200. > >> > > >> > The processor is an Dual Core AMD Opteron 2218. > >> > > >> > In the GENERIC kernel, acpi is built in; so, kldload acpi fails. I've > >> > also loaded the amdtemp module at boot time to figure out what the > >> > current temp of the processor is. > >> > > >> > With all of that, when performing `sysctl -a` I never seem to be able to > >> > pull up the _HOT value. > >> > > >> > Are there any suggestions on how to be able to view it? > >> > >> Many thermal zones seen, including some CPUs, don't specify any _HOT > >> value, just _PSV and _CRT, which should trigger passive cooling (eg > >> clock slowing or throttling) and emergency shutdown, respectively. > >> > >> What says 'sysctl hw.acpi.thermal' ? > >> > >> cheers, Ian > > > > The result is as follows: > > > > sysctl: Unknown oid 'hw.acpi.thermal' : No such file or directory > > Similar thing here at home desktop running -CURRENT: > > CPU: AMD FX(tm)-8350 Eight-Core Processor (4000.24-MHz K8-class CPU) > Origin="AuthenticAMD" Id=0x600f20 Family=0x15 Model=0x2 Stepping=0 > > acpi0: <7596MS A7596100> on motherboard > > Other related bits: > > # sysctl hw.acpi > hw.acpi.supported_sleep_state: S3 S4 S5 > hw.acpi.power_button_state: S5 > hw.acpi.sleep_button_state: S3 > hw.acpi.lid_switch_state: NONE > hw.acpi.standby_state: NONE > hw.acpi.suspend_state: S3 > hw.acpi.sleep_delay: 1 > hw.acpi.s4bios: 0 > hw.acpi.verbose: 0 > hw.acpi.disable_on_reboot: 0 > hw.acpi.handle_reboot: 0 > hw.acpi.reset_video: 0 > hw.acpi.cpu.cx_lowest: C8 > # > > # sysctl dev.amdtemp > dev.amdtemp.0.%desc: AMD CPU On-Die Thermal Sensors > dev.amdtemp.0.%driver: amdtemp > dev.amdtemp.0.%parent: hostb4 > dev.amdtemp.0.sensor_offset: 0 > dev.amdtemp.0.core0.sensor0: 15.3C > > # sysctl -a dev.cpu | grep temp > dev.cpu.0.temperature: 15.2C > dev.cpu.1.temperature: 15.2C > dev.cpu.2.temperature: 15.2C > dev.cpu.3.temperature: 15.2C > dev.cpu.4.temperature: 15.2C > dev.cpu.5.temperature: 15.2C > dev.cpu.6.temperature: 15.2C > dev.cpu.7.temperature: 15.2C > > I am not sure how this ^ relates to what acpi reports under thermal. Well first, unless you've just turned it on, it's idling and lives in a refrigerator or coldroom, those temperatures are at best a third of the minimum I'd expect to see reported .. and they wouldn't all be the same. And neither of these are reporting hw.acpi.thermal .. is it because the BIOS / ACPI doesn't present thermal zone information? Or there aren't suitable drivers to interpret it? I've no idea, but does seem curious. Any output from? # acpidump -dt | egrep -i 'TZ|thermal' If so, you might want to put your full ASL up somewhere. Note: I'm not at all qualified to interpret it, just that I'd expect there to be some; eg on a Lenovo X200 (Core2 Duo): root@x200:~ # acpidump -dt | egrep -i 'TZ|thermal' Notify (\_TZ.THM0, 0x80) Notify (\_TZ.THM1, 0x80) Notify (\_TZ.THM0, 0x80) Notify (\_TZ.THM1, 0x80) "AdaptiveThermalManagementAC" "AdaptiveThermalManagementBattery" Notify (\_TZ.THM0, 0x80) Notify (\_TZ.THM1, 0x80) Notify (\_TZ.THM1, 0x80) Notify (\_TZ.THM0, 0x81) Scope (\_TZ) ThermalZone (THM0) ThermalZone (THM1) Return (\_TZ.THM0._TMP ()) Notify (\_TZ.THM0, 0x80) cheers, Ian From owner-freebsd-acpi@FreeBSD.ORG Fri Jun 13 17:08:59 2014 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 841D7C69 for ; Fri, 13 Jun 2014 17:08:59 +0000 (UTC) Received: from mail-qc0-x22a.google.com (mail-qc0-x22a.google.com [IPv6:2607:f8b0:400d:c01::22a]) (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 36519214B for ; Fri, 13 Jun 2014 17:08:59 +0000 (UTC) Received: by mail-qc0-f170.google.com with SMTP id l6so4452512qcy.15 for ; Fri, 13 Jun 2014 10:08:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=lL1Zgnn4zAEkjhFY2jVNx03faQq3uO86YweX0jLHeUM=; b=YL92F/tmP0/I1+DR8inZMRAOd2eSIwqd8mT/QNtKdN0D37PRXljoZkNJwz41DnkmNg ZXmdHcH9FcoVbJrSwHBwMnMFe1DofV4pXRO46sd68l/jGhaiPoiCjUIynWu3/scy01T9 REYI/97VEyuLojp0FoWbC2ar+2liYHRCHMaix5kplldx3qZHanZmK0N7aLS3AH5yPLzm K4OOOLbsIOVh5ngKkyQybFD6/nK85yYy0NYQvZkSB4ik4hsOZcx6Ctbd04/DQNBD4yXc a7sbrxzorNWWiaB8akjPPiP6LhIzzFeicoHyPjOvZHRjq+UkdQ067qSHdUtNVVNG9HWk 7U9g== MIME-Version: 1.0 X-Received: by 10.224.7.6 with SMTP id b6mr5729190qab.45.1402679337936; Fri, 13 Jun 2014 10:08:57 -0700 (PDT) Received: by 10.96.73.39 with HTTP; Fri, 13 Jun 2014 10:08:57 -0700 (PDT) In-Reply-To: <20140614013631.J10629@sola.nimnet.asn.au> References: <1402412054.2426.13.camel@canpc36.cacs.louisiana.edu> <20140611011810.V10629@sola.nimnet.asn.au> <1402414819.17836.2.camel@canpc36.cacs.louisiana.edu> <20140614013631.J10629@sola.nimnet.asn.au> Date: Fri, 13 Jun 2014 10:08:57 -0700 Message-ID: Subject: Re: Missing: hw.acpi.thermal.tz%d._HOT From: hiren panchasara To: Ian Smith Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18 Cc: "freebsd-acpi@freebsd.org" , Eric Neblock X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jun 2014 17:08:59 -0000 On Fri, Jun 13, 2014 at 9:22 AM, Ian Smith wrote: > On Thu, 12 Jun 2014 14:28:33 -0700, hiren panchasara wrote: > > On Tue, Jun 10, 2014 at 8:40 AM, Eric Neblock wrote: > > > On Wed, 2014-06-11 at 01:33 +1000, Ian Smith wrote: > > >> On Tue, 10 Jun 2014 09:54:14 -0500, Eric Neblock wrote: > > >> > Hello all, > > >> > I'm trying to figure out what is the _HOT temperature on my particular > > >> > processor. I'm running FreeBSD 10 GENERIC on a Sunfire X2200. > > >> > > > >> > The processor is an Dual Core AMD Opteron 2218. > > >> > > > >> > In the GENERIC kernel, acpi is built in; so, kldload acpi fails. I've > > >> > also loaded the amdtemp module at boot time to figure out what the > > >> > current temp of the processor is. > > >> > > > >> > With all of that, when performing `sysctl -a` I never seem to be able to > > >> > pull up the _HOT value. > > >> > > > >> > Are there any suggestions on how to be able to view it? > > >> > > >> Many thermal zones seen, including some CPUs, don't specify any _HOT > > >> value, just _PSV and _CRT, which should trigger passive cooling (eg > > >> clock slowing or throttling) and emergency shutdown, respectively. > > >> > > >> What says 'sysctl hw.acpi.thermal' ? > > >> > > >> cheers, Ian > > > > > > The result is as follows: > > > > > > sysctl: Unknown oid 'hw.acpi.thermal' : No such file or directory > > > > Similar thing here at home desktop running -CURRENT: > > > > CPU: AMD FX(tm)-8350 Eight-Core Processor (4000.24-MHz K8-class CPU) > > Origin="AuthenticAMD" Id=0x600f20 Family=0x15 Model=0x2 Stepping=0 > > > > acpi0: <7596MS A7596100> on motherboard > > > > Other related bits: > > > > # sysctl hw.acpi > > hw.acpi.supported_sleep_state: S3 S4 S5 > > hw.acpi.power_button_state: S5 > > hw.acpi.sleep_button_state: S3 > > hw.acpi.lid_switch_state: NONE > > hw.acpi.standby_state: NONE > > hw.acpi.suspend_state: S3 > > hw.acpi.sleep_delay: 1 > > hw.acpi.s4bios: 0 > > hw.acpi.verbose: 0 > > hw.acpi.disable_on_reboot: 0 > > hw.acpi.handle_reboot: 0 > > hw.acpi.reset_video: 0 > > hw.acpi.cpu.cx_lowest: C8 > > # > > > > # sysctl dev.amdtemp > > dev.amdtemp.0.%desc: AMD CPU On-Die Thermal Sensors > > dev.amdtemp.0.%driver: amdtemp > > dev.amdtemp.0.%parent: hostb4 > > dev.amdtemp.0.sensor_offset: 0 > > dev.amdtemp.0.core0.sensor0: 15.3C > > > > # sysctl -a dev.cpu | grep temp > > dev.cpu.0.temperature: 15.2C > > dev.cpu.1.temperature: 15.2C > > dev.cpu.2.temperature: 15.2C > > dev.cpu.3.temperature: 15.2C > > dev.cpu.4.temperature: 15.2C > > dev.cpu.5.temperature: 15.2C > > dev.cpu.6.temperature: 15.2C > > dev.cpu.7.temperature: 15.2C > > > > I am not sure how this ^ relates to what acpi reports under thermal. > > Well first, unless you've just turned it on, it's idling and lives in a > refrigerator or coldroom, those temperatures are at best a third of the > minimum I'd expect to see reported .. and they wouldn't all be the same. Oh wait. It gets better :-) # uptime 9:42AM up 10 days, 9:04, 1 user, load averages: 0.37, 0.29, 0.24 # sysctl -a dev.cpu | grep temp dev.cpu.0.temperature: 13.6C dev.cpu.1.temperature: 13.6C dev.cpu.2.temperature: 13.6C dev.cpu.3.temperature: 13.6C dev.cpu.4.temperature: 13.6C dev.cpu.5.temperature: 13.6C dev.cpu.6.temperature: 13.6C dev.cpu.7.temperature: 13.6C # I am not sure how correct these numbers are but I've enabled AMD's Cool'n'Quiet thingi in BIOS. # sysctl dev.cpu | grep cx_lowest dev.cpu.0.cx_lowest: C8 dev.cpu.1.cx_lowest: C8 dev.cpu.2.cx_lowest: C8 dev.cpu.3.cx_lowest: C8 dev.cpu.4.cx_lowest: C8 dev.cpu.5.cx_lowest: C8 dev.cpu.6.cx_lowest: C8 dev.cpu.7.cx_lowest: C8 # >From top: last pid: 53106; load averages: 0.13, 0.18, 0.19 up 10+09:27:27 10:06:21 88 processes: 1 running, 87 sleeping CPU: 0.3% user, 0.1% nice, 0.3% system, 0.0% interrupt, 99.2% idle Mem: 58M Active, 1006M Inact, 14G Wired, 12M Cache, 590M Free ARC: 8753M Total, 1834M MFU, 4757M MRU, 272K Anon, 210M Header, 1952M Other Swap: 16G Total, 16G Free > > And neither of these are reporting hw.acpi.thermal .. is it because the > BIOS / ACPI doesn't present thermal zone information? I'd believe so. > Or there aren't > suitable drivers to interpret it? I've no idea, but does seem curious. > > Any output from? > # acpidump -dt | egrep -i 'TZ|thermal' nothing. # acpidump -dt | egrep -i 'TZ|thermal' acpidump: RSDT entry 3 (sig OEMB) is corrupt Now this ^^ error might also suggest something is wrong. > > If so, you might want to put your full ASL up somewhere. # acpidump -dt | gzip -c9 > amd_fx8350.asl.gz amd_fx8350.asl.gz is attached. By the time I collected everything, # sysctl dev.cpu | grep temp dev.cpu.0.temperature: 14.0C dev.cpu.1.temperature: 14.0C dev.cpu.2.temperature: 14.0C dev.cpu.3.temperature: 14.0C dev.cpu.4.temperature: 14.0C dev.cpu.5.temperature: 14.0C dev.cpu.6.temperature: 14.0C dev.cpu.7.temperature: 14.0C Cheers, Hiren From owner-freebsd-acpi@FreeBSD.ORG Fri Jun 13 23:51:27 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 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E43985BD for ; Fri, 13 Jun 2014 23:51:26 +0000 (UTC) Received: from mail-qa0-x22c.google.com (mail-qa0-x22c.google.com [IPv6:2607:f8b0:400d:c00::22c]) (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 A3966233D for ; Fri, 13 Jun 2014 23:51:26 +0000 (UTC) Received: by mail-qa0-f44.google.com with SMTP id hw13so3365745qab.17 for ; Fri, 13 Jun 2014 16:51:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Ub3sRstWrkUoerWmvlnbwEhLpFAGoJspB7b7JEV5m9Y=; b=GRWPi5HQY85A2EQa/bAk38v3xsdFHeHGqZBr5saFTVagMHz1/t0PMwyHx6/dlte/Ws H03xFJQ585eBV/GN6LgY9cyFvKAJknOydsbbX7P6Peeu31XYtqz3Y8WlVJNX2va4i9Gu RcARvxO3OMBUHnu5PR9IU+HHEe/IWPXianqxTeYTHlSm6Y7UNPGmSbaGoyQpO1NYdIAk vdA9k4Ti6YmtRBzIXWdQmj9iJ72P/TFjR82Z2i+H0Gy/69qgwX5P5YIHdZjqq9yk/i48 0FEgFRQnTCDphnEyvdljegYhxR5pO/154qQ8wRpwbfoL2vg0S5+KUK+9C9EvU/0Gx1/G INJw== MIME-Version: 1.0 X-Received: by 10.140.35.212 with SMTP id n78mr7537229qgn.87.1402703485808; Fri, 13 Jun 2014 16:51:25 -0700 (PDT) Received: by 10.96.73.39 with HTTP; Fri, 13 Jun 2014 16:51:25 -0700 (PDT) In-Reply-To: References: <1402412054.2426.13.camel@canpc36.cacs.louisiana.edu> <20140611011810.V10629@sola.nimnet.asn.au> <1402414819.17836.2.camel@canpc36.cacs.louisiana.edu> <20140614013631.J10629@sola.nimnet.asn.au> Date: Fri, 13 Jun 2014 16:51:25 -0700 Message-ID: Subject: Re: Missing: hw.acpi.thermal.tz%d._HOT From: hiren panchasara To: Ian Smith Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-acpi@freebsd.org" , Eric Neblock X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jun 2014 23:51:27 -0000 On Fri, Jun 13, 2014 at 10:08 AM, hiren panchasara wrote: > On Fri, Jun 13, 2014 at 9:22 AM, Ian Smith wrote: >> On Thu, 12 Jun 2014 14:28:33 -0700, hiren panchasara wrote: >> > >> > # sysctl dev.amdtemp >> > dev.amdtemp.0.%desc: AMD CPU On-Die Thermal Sensors >> > dev.amdtemp.0.%driver: amdtemp >> > dev.amdtemp.0.%parent: hostb4 >> > dev.amdtemp.0.sensor_offset: 0 >> > dev.amdtemp.0.core0.sensor0: 15.3C >> > >> > # sysctl -a dev.cpu | grep temp >> > dev.cpu.0.temperature: 15.2C >> > dev.cpu.1.temperature: 15.2C >> > dev.cpu.2.temperature: 15.2C >> > dev.cpu.3.temperature: 15.2C >> > dev.cpu.4.temperature: 15.2C >> > dev.cpu.5.temperature: 15.2C >> > dev.cpu.6.temperature: 15.2C >> > dev.cpu.7.temperature: 15.2C >> > >> > I am not sure how this ^ relates to what acpi reports under thermal. >> >> Well first, unless you've just turned it on, it's idling and lives in a >> refrigerator or coldroom, those temperatures are at best a third of the >> minimum I'd expect to see reported .. and they wouldn't all be the same. > > Oh wait. It gets better :-) > > # uptime > 9:42AM up 10 days, 9:04, 1 user, load averages: 0.37, 0.29, 0.24 > # sysctl -a dev.cpu | grep temp > dev.cpu.0.temperature: 13.6C > dev.cpu.1.temperature: 13.6C > dev.cpu.2.temperature: 13.6C > dev.cpu.3.temperature: 13.6C > dev.cpu.4.temperature: 13.6C > dev.cpu.5.temperature: 13.6C > dev.cpu.6.temperature: 13.6C > dev.cpu.7.temperature: 13.6C > # > > I am not sure how correct these numbers are but I've enabled AMD's > Cool'n'Quiet thingi in BIOS. > > # sysctl dev.cpu | grep cx_lowest > dev.cpu.0.cx_lowest: C8 > dev.cpu.1.cx_lowest: C8 > dev.cpu.2.cx_lowest: C8 > dev.cpu.3.cx_lowest: C8 > dev.cpu.4.cx_lowest: C8 > dev.cpu.5.cx_lowest: C8 > dev.cpu.6.cx_lowest: C8 > dev.cpu.7.cx_lowest: C8 > # > > # sysctl dev.cpu | grep temp > dev.cpu.0.temperature: 14.0C > dev.cpu.1.temperature: 14.0C > dev.cpu.2.temperature: 14.0C > dev.cpu.3.temperature: 14.0C > dev.cpu.4.temperature: 14.0C > dev.cpu.5.temperature: 14.0C > dev.cpu.6.temperature: 14.0C > dev.cpu.7.temperature: 14.0C Just for curious minds: Afternoon and evenings bring direct sunlight to where the machine is. And I guess that is showing? probably? # sysctl dev.cpu | grep temp dev.cpu.0.temperature: 16.8C dev.cpu.1.temperature: 16.8C dev.cpu.2.temperature: 16.8C dev.cpu.3.temperature: 16.8C dev.cpu.4.temperature: 16.8C dev.cpu.5.temperature: 16.8C dev.cpu.6.temperature: 16.8C dev.cpu.7.temperature: 16.8C cheers, Hiren From owner-freebsd-acpi@FreeBSD.ORG Sat Jun 14 00:54:30 2014 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F3838A36 for ; Sat, 14 Jun 2014 00:54:29 +0000 (UTC) Received: from nm22-vm8.bullet.mail.gq1.yahoo.com (nm22-vm8.bullet.mail.gq1.yahoo.com [98.136.217.71]) (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 B8D472885 for ; Sat, 14 Jun 2014 00:54:29 +0000 (UTC) Received: from [98.137.12.190] by nm22.bullet.mail.gq1.yahoo.com with NNFMP; 14 Jun 2014 00:54:28 -0000 Received: from [98.136.164.67] by tm11.bullet.mail.gq1.yahoo.com with NNFMP; 14 Jun 2014 00:54:28 -0000 Received: from [127.0.0.1] by smtp229.mail.gq1.yahoo.com with NNFMP; 14 Jun 2014 00:54:28 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sbcglobal.net; s=s1024; t=1402707268; bh=ASFQnql+luQwU/x5kRmxp+5K3vTlR+t5k7BIeJz8Cgk=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:Message-ID:Disposition-Notification-To:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:X-Enigmail-Version:Content-Type:Content-Transfer-Encoding; b=O58g+WFqhqMpN8SHNKCH11CIGvLxDRNX3ImQfoCGUk0g6PZpWHw4cK1YyH8CdJvMUpdJrLIxD8XzhDEz8C2QLfJrVOrPvZNDCCao1tmpKD+HYYnkTG+rUEELSKKGncNjgJRBP7ov0PbNoP5fdpyhmmr6jQVfm6/J9K3yRqP3qfs= X-Yahoo-Newman-Id: 567628.73258.bm@smtp229.mail.gq1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: H3_G8vEVM1mqYFKe997q7IJIwoxG8.9JjL0CioQyfAYCiRN chWR_1IP1uumwe.I4o98hqbFm0VV78kYabzv.j0fNIgnkEOePDcuz7yHJ1vE t_Q84EoMxZ08SEsfdy1fW_mEIZC7h1qaGu.mVwY1aXF6.38Up8VvAjD9Xx92 YFpa2HnlF_cCbP0wLMQUud14xB66aDPpjrZaj9zvSD6I_Im01fB5phU.7R7g YVewh8nue40EOU8LFkaZZ3Q4eHERTaMqf5nbb_LeQIBh.oo.k1PPBGgxP1wY h3__ba1ZKzXeFgxPsJi5ucj50Utbu8OaA3hqsiCjQzxbfHlN7jEYVGkOkv9R TWOXRSPvkIRE13mYD6z_cvp6qtCH3XUKE0LVUjHgxE1ailEeD8zmWVd4cUAY W6tHBePWzv3M3bDZDfn3fmb.0JUjOKen4qpYF3uYLbkYQlIlFSQn0.kKg.aP u3dHgTX5l44_DnZc8H4S1devGto_3OPjSn_KRV3mRlrFcouRt4rC1LbWnT3d gAoFD.FomaKsv_4R9tgczakXNsjld4WgOqyFXIOCZksXKyZerUXYRK2LQiIH Vmmn7qPrrjARPdV9XeC8zrYPV76roK4GkZ3mykd2SBCPDuL_k3qycjPq9Cx2 6Qh3NSuT2qDgX_BDsen5ZbhUOv6IDbe5av8Md_SeezUSnVko- X-Yahoo-SMTP: UGQWZEGswBBuSsLptuxsMWrCLMz_zXgELJxrKh3KoeMV X-Rocket-Received: from laptop.sailorcire.homelinux.com (c_eric@68.226.244.67 with plain [63.250.193.228]) by smtp229.mail.gq1.yahoo.com with SMTP; 14 Jun 2014 00:54:28 +0000 UTC Message-ID: <539B9D98.8030808@sbcglobal.net> Date: Fri, 13 Jun 2014 19:55:52 -0500 From: Eric Neblock User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: hiren panchasara , Ian Smith Subject: Re: Missing: hw.acpi.thermal.tz%d._HOT References: <1402412054.2426.13.camel@canpc36.cacs.louisiana.edu> <20140611011810.V10629@sola.nimnet.asn.au> <1402414819.17836.2.camel@canpc36.cacs.louisiana.edu> <20140614013631.J10629@sola.nimnet.asn.au> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "freebsd-acpi@freebsd.org" , Eric Neblock X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jun 2014 00:54:30 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 06/13/2014 06:51 PM, hiren panchasara wrote: > On Fri, Jun 13, 2014 at 10:08 AM, hiren panchasara > wrote: >> On Fri, Jun 13, 2014 at 9:22 AM, Ian Smith >> wrote: >>> On Thu, 12 Jun 2014 14:28:33 -0700, hiren panchasara wrote: > >>>> >>>> # sysctl dev.amdtemp dev.amdtemp.0.%desc: AMD CPU On-Die >>>> Thermal Sensors dev.amdtemp.0.%driver: amdtemp >>>> dev.amdtemp.0.%parent: hostb4 dev.amdtemp.0.sensor_offset: 0 >>>> dev.amdtemp.0.core0.sensor0: 15.3C >>>> >>>> # sysctl -a dev.cpu | grep temp dev.cpu.0.temperature: 15.2C >>>> dev.cpu.1.temperature: 15.2C dev.cpu.2.temperature: 15.2C >>>> dev.cpu.3.temperature: 15.2C dev.cpu.4.temperature: 15.2C >>>> dev.cpu.5.temperature: 15.2C dev.cpu.6.temperature: 15.2C >>>> dev.cpu.7.temperature: 15.2C >>>> >>>> I am not sure how this ^ relates to what acpi reports under >>>> thermal. >>> >>> Well first, unless you've just turned it on, it's idling and >>> lives in a refrigerator or coldroom, those temperatures are at >>> best a third of the minimum I'd expect to see reported .. and >>> they wouldn't all be the same. >> >> Oh wait. It gets better :-) >> >> # uptime 9:42AM up 10 days, 9:04, 1 user, load averages: 0.37, >> 0.29, 0.24 # sysctl -a dev.cpu | grep temp dev.cpu.0.temperature: >> 13.6C dev.cpu.1.temperature: 13.6C dev.cpu.2.temperature: 13.6C >> dev.cpu.3.temperature: 13.6C dev.cpu.4.temperature: 13.6C >> dev.cpu.5.temperature: 13.6C dev.cpu.6.temperature: 13.6C >> dev.cpu.7.temperature: 13.6C # >> >> I am not sure how correct these numbers are but I've enabled >> AMD's Cool'n'Quiet thingi in BIOS. >> >> # sysctl dev.cpu | grep cx_lowest dev.cpu.0.cx_lowest: C8 >> dev.cpu.1.cx_lowest: C8 dev.cpu.2.cx_lowest: C8 >> dev.cpu.3.cx_lowest: C8 dev.cpu.4.cx_lowest: C8 >> dev.cpu.5.cx_lowest: C8 dev.cpu.6.cx_lowest: C8 >> dev.cpu.7.cx_lowest: C8 # > > >> >> # sysctl dev.cpu | grep temp dev.cpu.0.temperature: 14.0C >> dev.cpu.1.temperature: 14.0C dev.cpu.2.temperature: 14.0C >> dev.cpu.3.temperature: 14.0C dev.cpu.4.temperature: 14.0C >> dev.cpu.5.temperature: 14.0C dev.cpu.6.temperature: 14.0C >> dev.cpu.7.temperature: 14.0C > > Just for curious minds: > > Afternoon and evenings bring direct sunlight to where the machine > is. And I guess that is showing? probably? # sysctl dev.cpu | grep > temp dev.cpu.0.temperature: 16.8C dev.cpu.1.temperature: 16.8C > dev.cpu.2.temperature: 16.8C dev.cpu.3.temperature: 16.8C > dev.cpu.4.temperature: 16.8C dev.cpu.5.temperature: 16.8C > dev.cpu.6.temperature: 16.8C dev.cpu.7.temperature: 16.8C > > cheers, Hiren > What are you using as a cooling setup? I am flabbergasted as I'm working the scheduler to try and keep my temps under 55C. Eric -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTm52YAAoJEKnJ+4MkCuMTxYMIANQp2SjR8vEV2uU7pSeon+aB cVQxijNVZjdHQIY8SKNRF3uVA5wGBwlF5qXBMbxK2sYLGOWkCxAkPZDTJWBlgpyv 0fZgD3KYv7BRYivlzcX/ZYTDTuVZ1WoslO7rH1ogJ/dslVYZeP/0Vyb1abscGSYk WlB80gB5AsyrP+NcUemWmqD0sytxJTVaKfXOJpkBnNNeDnYVxQgxL6MLYs+9g5g8 Q1JZE4yTtz+9ZqxXPjAp35JDfNkXKNyTtYlJzzH4os+Jh1ZC2QSbDkHhnGAV0PAk H/rHecqj0lAqBmYK1mDyxMBSihLRxr6PwtDimw6SDMGc73Mk73V0QEhRwkUvbD8= =ZKga -----END PGP SIGNATURE----- From owner-freebsd-acpi@FreeBSD.ORG Sat Jun 14 06:06:41 2014 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DD943DDC; Sat, 14 Jun 2014 06:06:41 +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 48A992055; Sat, 14 Jun 2014 06:06:40 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id s5E66aca004393; Sat, 14 Jun 2014 16:06:36 +1000 (EST) (envelope-from smithi@nimnet.asn.au) Date: Sat, 14 Jun 2014 16:06:36 +1000 (EST) From: Ian Smith To: hiren panchasara Subject: Re: Missing: hw.acpi.thermal.tz%d._HOT In-Reply-To: Message-ID: <20140614152711.W609@sola.nimnet.asn.au> References: <1402412054.2426.13.camel@canpc36.cacs.louisiana.edu> <20140611011810.V10629@sola.nimnet.asn.au> <1402414819.17836.2.camel@canpc36.cacs.louisiana.edu> <20140614013631.J10629@sola.nimnet.asn.au> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: "freebsd-acpi@freebsd.org" , Eric Neblock X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jun 2014 06:06:41 -0000 On Fri, 13 Jun 2014 10:08:57 -0700, hiren panchasara wrote: > On Fri, Jun 13, 2014 at 9:22 AM, Ian Smith wrote: > > On Thu, 12 Jun 2014 14:28:33 -0700, hiren panchasara wrote: > > > On Tue, Jun 10, 2014 at 8:40 AM, Eric Neblock wrote: > > > > On Wed, 2014-06-11 at 01:33 +1000, Ian Smith wrote: > > > >> On Tue, 10 Jun 2014 09:54:14 -0500, Eric Neblock wrote: > > > >> > Hello all, > > > >> > I'm trying to figure out what is the _HOT temperature on my particular > > > >> > processor. I'm running FreeBSD 10 GENERIC on a Sunfire X2200. > > > >> > > > > >> > The processor is an Dual Core AMD Opteron 2218. > > > >> > > > > >> > In the GENERIC kernel, acpi is built in; so, kldload acpi fails. I've > > > >> > also loaded the amdtemp module at boot time to figure out what the > > > >> > current temp of the processor is. [..] > > > > sysctl: Unknown oid 'hw.acpi.thermal' : No such file or directory > > > > > > Similar thing here at home desktop running -CURRENT: > > > > > > CPU: AMD FX(tm)-8350 Eight-Core Processor (4000.24-MHz K8-class CPU) > > > Origin="AuthenticAMD" Id=0x600f20 Family=0x15 Model=0x2 Stepping=0 So looking at /sys/dev/amdtemp/amdtemp.c .. here on stable/9 from a few weeks ago, whic appears to be an MFC of this one on head: http://svnweb.freebsd.org/base/head/sys/dev/amdtemp/amdtemp.c?view=log "Driver for the AMD CPU on-die thermal sensors for Family 0Fh/10h/11h procs." with support added recently also for the 0x16h family, but no mention of 0x15 .. going by Eric's report, his would appear suoported. Looking at amdtemp_gettemp() there, I suspect the 0x15 family uses yet another number or placement of register bits; your ~13C to 15C range of temps shown seems much more likely to be in the ~52C to 60C range .. cc'ing jkim@, although others have messed with amdtemp more recently. > > > acpi0: <7596MS A7596100> on motherboard > > > # sysctl dev.amdtemp > > > dev.amdtemp.0.%desc: AMD CPU On-Die Thermal Sensors > > > dev.amdtemp.0.%driver: amdtemp > > > dev.amdtemp.0.%parent: hostb4 > > > dev.amdtemp.0.sensor_offset: 0 > > > dev.amdtemp.0.core0.sensor0: 15.3C > > > > > > # sysctl -a dev.cpu | grep temp > > > dev.cpu.0.temperature: 15.2C [..] > > > dev.cpu.7.temperature: 15.2C > > > > > > I am not sure how this ^ relates to what acpi reports under thermal. I assume dev.amdtemp.0.core0.sensor0 is the source for all of those. > I am not sure how correct these numbers are but I've enabled AMD's > Cool'n'Quiet thingi in BIOS. Looks like you need to ask someone to add support for family 0x15. As for Eric, with no _TZ support, I don't know how you'd handle overtemps. > > And neither of these are reporting hw.acpi.thermal .. is it because the > > BIOS / ACPI doesn't present thermal zone information? > I'd believe so. > > > Or there aren't > > suitable drivers to interpret it? I've no idea, but does seem curious. > > > > Any output from? > > # acpidump -dt | egrep -i 'TZ|thermal' > nothing. > > # acpidump -dt | egrep -i 'TZ|thermal' > acpidump: RSDT entry 3 (sig OEMB) is corrupt > > Now this ^^ error might also suggest something is wrong. Don't know, but probably not related to the sensor temperatures. > > If so, you might want to put your full ASL up somewhere. > # acpidump -dt | gzip -c9 > amd_fx8350.asl.gz > > amd_fx8350.asl.gz is attached. It's no use to me and the list swallowed it; you'd need to put it up at an URL somewhere .. but as it has no Thermal Zone section it can't help with this issue anyway. > By the time I collected everything, > > # sysctl dev.cpu | grep temp > dev.cpu.0.temperature: 14.0C > dev.cpu.1.temperature: 14.0C > dev.cpu.2.temperature: 14.0C > dev.cpu.3.temperature: 14.0C > dev.cpu.4.temperature: 14.0C > dev.cpu.5.temperature: 14.0C > dev.cpu.6.temperature: 14.0C > dev.cpu.7.temperature: 14.0C 56C most likely, unless there's also an offset. I'm out of clues .. cheers, Ian From owner-freebsd-acpi@FreeBSD.ORG Sat Jun 14 07:22:31 2014 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 52ED1AA2; Sat, 14 Jun 2014 07:22:31 +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 996CA25BA; Sat, 14 Jun 2014 07:22:30 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id s5E7MQ2x006896; Sat, 14 Jun 2014 17:22:26 +1000 (EST) (envelope-from smithi@nimnet.asn.au) Date: Sat, 14 Jun 2014 17:22:26 +1000 (EST) From: Ian Smith To: hiren panchasara Subject: Re: Missing: hw.acpi.thermal.tz%d._HOT In-Reply-To: <20140614152711.W609@sola.nimnet.asn.au> Message-ID: <20140614170907.E609@sola.nimnet.asn.au> References: <1402412054.2426.13.camel@canpc36.cacs.louisiana.edu> <20140611011810.V10629@sola.nimnet.asn.au> <1402414819.17836.2.camel@canpc36.cacs.louisiana.edu> <20140614013631.J10629@sola.nimnet.asn.au> <20140614152711.W609@sola.nimnet.asn.au> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: "freebsd-acpi@freebsd.org" , Eric Neblock X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jun 2014 07:22:31 -0000 On Sat, 14 Jun 2014 16:06:36 +1000, Ian Smith wrote: > On Fri, 13 Jun 2014 10:08:57 -0700, hiren panchasara wrote: > > On Fri, Jun 13, 2014 at 9:22 AM, Ian Smith wrote: > > > On Thu, 12 Jun 2014 14:28:33 -0700, hiren panchasara wrote: > > > > On Tue, Jun 10, 2014 at 8:40 AM, Eric Neblock wrote: > > > > > On Wed, 2014-06-11 at 01:33 +1000, Ian Smith wrote: > > > > >> On Tue, 10 Jun 2014 09:54:14 -0500, Eric Neblock wrote: > > > > >> > Hello all, > > > > >> > I'm trying to figure out what is the _HOT temperature on my particular > > > > >> > processor. I'm running FreeBSD 10 GENERIC on a Sunfire X2200. > > > > >> > > > > > >> > The processor is an Dual Core AMD Opteron 2218. > > > > >> > > > > > >> > In the GENERIC kernel, acpi is built in; so, kldload acpi fails. I've > > > > >> > also loaded the amdtemp module at boot time to figure out what the > > > > >> > current temp of the processor is. > [..] > > > > > sysctl: Unknown oid 'hw.acpi.thermal' : No such file or directory > > > > > > > > Similar thing here at home desktop running -CURRENT: > > > > > > > > CPU: AMD FX(tm)-8350 Eight-Core Processor (4000.24-MHz K8-class CPU) > > > > Origin="AuthenticAMD" Id=0x600f20 Family=0x15 Model=0x2 Stepping=0 > > So looking at /sys/dev/amdtemp/amdtemp.c .. here on stable/9 from a few > weeks ago, whic appears to be an MFC of this one on head: > http://svnweb.freebsd.org/base/head/sys/dev/amdtemp/amdtemp.c?view=log > > "Driver for the AMD CPU on-die thermal sensors for Family 0Fh/10h/11h > procs." with support added recently also for the 0x16h family, but no > mention of 0x15 .. going by Eric's report, his would appear suoported. Sorry .. I didn't look closely enough at all. The version on head does appear to support the 0x15 family as well, and quite a bit of the code has been reworked and augmented. #define DEVICEID_AMD_MISC15 0x1603 > Looking at amdtemp_gettemp() there, I suspect the 0x15 family uses yet > another number or placement of register bits; your ~13C to 15C range of > temps shown seems much more likely to be in the ~52C to 60C range .. That's changed too .. but none of this explains why yours is reporting (apparently) one quarter of the real temperature. Out of my depth .. cheers, Ian From owner-freebsd-acpi@FreeBSD.ORG Sat Jun 14 18:07:42 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 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C5155C19 for ; Sat, 14 Jun 2014 18:07:42 +0000 (UTC) Received: from mail.ignoranthack.me (ignoranthack.me [199.102.79.106]) (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 9FAC522F2 for ; Sat, 14 Jun 2014 18:07:41 +0000 (UTC) Received: from [192.168.200.105] (c-50-131-4-11.hsd1.ca.comcast.net [50.131.4.11]) (using SSLv3 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: sbruno@ignoranthack.me) by mail.ignoranthack.me (Postfix) with ESMTPSA id 1F47B1936DE; Sat, 14 Jun 2014 18:07:40 +0000 (UTC) Subject: Re: Missing: hw.acpi.thermal.tz%d._HOT From: Sean Bruno Reply-To: sbruno@freebsd.org To: hiren panchasara In-Reply-To: References: <1402412054.2426.13.camel@canpc36.cacs.louisiana.edu> <20140611011810.V10629@sola.nimnet.asn.au> <1402414819.17836.2.camel@canpc36.cacs.louisiana.edu> <20140614013631.J10629@sola.nimnet.asn.au> Content-Type: text/plain; charset="us-ascii" Date: Sat, 14 Jun 2014 11:07:41 -0700 Message-ID: <1402769262.1120.5.camel@bruno> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: "freebsd-acpi@freebsd.org" , Ian Smith , Eric Neblock X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jun 2014 18:07:42 -0000 > > Just for curious minds: > > Afternoon and evenings bring direct sunlight to where the machine is. > And I guess that is showing? probably? > # sysctl dev.cpu | grep temp > dev.cpu.0.temperature: 16.8C > dev.cpu.1.temperature: 16.8C > dev.cpu.2.temperature: 16.8C > dev.cpu.3.temperature: 16.8C > dev.cpu.4.temperature: 16.8C > dev.cpu.5.temperature: 16.8C > dev.cpu.6.temperature: 16.8C > dev.cpu.7.temperature: 16.8C I have an FX-8150 based system similar, but a bit older that this one: Base Board Information Manufacturer: ASUSTeK Computer INC. Product Name: M5A88-M Processor Information Socket Designation: AM3R2 Type: Central Processor Family: FX Manufacturer: AMD ID: 12 0F 60 00 FF FB 8B 17 Version: AMD FX(tm)-8150 Eight-Core Processor At idle, the machine reports pretty low temps: dev.amdtemp.0.%desc: AMD CPU On-Die Thermal Sensors dev.amdtemp.0.%driver: amdtemp dev.amdtemp.0.%parent: hostb4 dev.amdtemp.0.sensor_offset: 0 dev.amdtemp.0.core0.sensor0: 16.2C But when doing builds with all the cpus firing: dev.amdtemp.0.core0.sensor0: 49.5C ... dev.amdtemp.0.core0.sensor0: 52.3C ... dev.cpu.0.temperature: 53.0C Seems legit to me. sean From owner-freebsd-acpi@FreeBSD.ORG Sun Jun 15 04:44:08 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 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9A420564; Sun, 15 Jun 2014 04:44:08 +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 DB3492F94; Sun, 15 Jun 2014 04:44:07 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id s5F4hu84051146; Sun, 15 Jun 2014 14:43:56 +1000 (EST) (envelope-from smithi@nimnet.asn.au) Date: Sun, 15 Jun 2014 14:43:56 +1000 (EST) From: Ian Smith To: sbruno@freebsd.org Subject: Re: Missing: hw.acpi.thermal.tz%d._HOT In-Reply-To: <1402769262.1120.5.camel@bruno> Message-ID: <20140615133533.A609@sola.nimnet.asn.au> References: <1402412054.2426.13.camel@canpc36.cacs.louisiana.edu> <20140611011810.V10629@sola.nimnet.asn.au> <1402414819.17836.2.camel@canpc36.cacs.louisiana.edu> <20140614013631.J10629@sola.nimnet.asn.au> <1402769262.1120.5.camel@bruno> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: "freebsd-acpi@freebsd.org" , Eric Neblock X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Jun 2014 04:44:08 -0000 On Sat, 14 Jun 2014 11:07:41 -0700, Sean Bruno wrote: > > Just for curious minds: > > > > Afternoon and evenings bring direct sunlight to where the machine is. > > And I guess that is showing? probably? > > # sysctl dev.cpu | grep temp > > dev.cpu.0.temperature: 16.8C > > dev.cpu.1.temperature: 16.8C > > dev.cpu.2.temperature: 16.8C > > dev.cpu.3.temperature: 16.8C > > dev.cpu.4.temperature: 16.8C > > dev.cpu.5.temperature: 16.8C > > dev.cpu.6.temperature: 16.8C > > dev.cpu.7.temperature: 16.8C > > > I have an FX-8150 based system similar, but a bit older that this one: > Base Board Information > Manufacturer: ASUSTeK Computer INC. > Product Name: M5A88-M > > Processor Information > Socket Designation: AM3R2 > Type: Central Processor > Family: FX > Manufacturer: AMD > ID: 12 0F 60 00 FF FB 8B 17 > Version: AMD FX(tm)-8150 Eight-Core Processor Which family, model, stepping is that? > At idle, the machine reports pretty low temps: > dev.amdtemp.0.%desc: AMD CPU On-Die Thermal Sensors > dev.amdtemp.0.%driver: amdtemp > dev.amdtemp.0.%parent: hostb4 > dev.amdtemp.0.sensor_offset: 0 > dev.amdtemp.0.core0.sensor0: 16.2C Is it water-cooled? Roughly, what's the ambient temperature where it lives? Short of forced water cooling, with the watertank feeling cool to the touch, I can't see how any electronic equipment can run anything like that cool. If you touch the heatsink, is it cooler than ambient? > But when doing builds with all the cpus firing: > dev.amdtemp.0.core0.sensor0: 49.5C > ... > dev.amdtemp.0.core0.sensor0: 52.3C > ... > dev.cpu.0.temperature: 53.0C > > > Seems legit to me. I don't think so. Maybe becaus we use Centigrade here. 16C is ~62F, I'd have a wooly jumper on. 50C ~= 120F, we get days that hot outback. There's mention in amdtemp.c of some models having a -28C offset: #define AMDTEMP_FLAG_ALT_OFFSET 0x04 /* CurTmp starts at -28C. */ and later: 535 mask = (sc->sc_flags & AMDTEMP_FLAG_CT_10BIT) != 0 ? 0x3ff : 0x3fc; 536 offset = (sc->sc_flags & AMDTEMP_FLAG_ALT_OFFSET) != 0 ? 28 : 49; 537 temp = pci_read_config(dev, AMDTEMP_THERMTP_STAT, 4); 538 temp = ((temp >> 14) & mask) * 5 / 2; 539 temp += AMDTEMP_ZERO_C_TO_K + (sc->sc_offset - offset) * 10; I'm not claiming to follow that through the masking, shift and factor, and it's returned in Kelvin anyway, but there's clearly a 21 $something difference in offset for some models, and see the XXX comments there. 16C + 21C = 37C, which is believable at idle. 53C + 21C = 74C, which is quite believable for 8 busy cores, assuming a good h/s & fan. You can leave your finger, for a good while anyway, on a heatsink at 53C. 74C will burn you quite quickly; here anyway, most home hot water systems are set to deliver between 60 and 70C, which will scald before long. Touch test? cheers, Ian From owner-freebsd-acpi@FreeBSD.ORG Mon Jun 16 14:36:43 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 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 73EB61D9; Mon, 16 Jun 2014 14:36:43 +0000 (UTC) Received: from mail-ob0-x22a.google.com (mail-ob0-x22a.google.com [IPv6:2607:f8b0:4003:c01::22a]) (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 35F482793; Mon, 16 Jun 2014 14:36:43 +0000 (UTC) Received: by mail-ob0-f170.google.com with SMTP id uz6so5840564obc.29 for ; Mon, 16 Jun 2014 07:36:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=oWx26RFOrgpanoD1eGlBA5sIlLZqdex3yXQkS+eGATY=; b=fbAb/P983BySOTuKqWcsyl1quUWC7BZOBKybbcI2KPdTLOyEXr9qdWwUgjknfRTrKQ BXJh3SPYViCEXLkK+yLWI+9W+amY2NTRLxfcGAUoKK73500q5hDVls+ZODlteXcXLDQs WMi9iGUrwxPPEhhbhJWPqMfgGDfdDdto27ZahG0BA6RjZETjbZQBw4XGvJG4netOoY6u UUIHY9JHZ54g3Vc6aBwEyZLbMnmQMmL+jrKhtDZAHaVMmeW6Xyfo3xDhhA42d48EzDrC a7iPclNDAMJZsNPxARt+qWlR+kZksCLapwMVtmJxOFLKbxdKsGq977yFPya/p016aeuJ gTgg== MIME-Version: 1.0 X-Received: by 10.182.44.233 with SMTP id h9mr2829681obm.68.1402929402497; Mon, 16 Jun 2014 07:36:42 -0700 (PDT) Sender: tomek.cedro@gmail.com Received: by 10.202.75.207 with HTTP; Mon, 16 Jun 2014 07:36:42 -0700 (PDT) Date: Mon, 16 Jun 2014 16:36:42 +0200 X-Google-Sender-Auth: J2ao6J-YJnAqLBlLvQvrwYsR-AE Message-ID: Subject: sysctl hw.acpi.acline From: CeDeROM To: freebsd-hackers@freebsd.org, freebsd-acpi@freebsd.org Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jun 2014 14:36:43 -0000 Hello world :-) One application that I am porting needs to know the power supply information from the system. I thought using SYSCTL + ACPI would be the simplest and elegant way. But, I found out that information on the power supply is only available on the laptop machines, while on the desktop machines it does not apply. According to the "man acpi", the "hw.acpi.acline" oid tells the AC line state, so I guess desktop should always tell 1, but there is no such oid on my desktop.. Is this a bug or feature? :-) How can I tell the power source on my FreeBSD (i.e. AC, Battery, UPS)? man acpi: ... hw.acpi.acline AC line state (1 means online, 0 means on battery power). root@hexagon:~ # sysctl hw.acpi.acline sysctl: unknown oid 'hw.acpi.acline': No such file or directory root@hexagon:~ # uname -a FreeBSD hexagon 10.0-RELEASE-p3 FreeBSD 10.0-RELEASE-p3 #0: Tue May 13 18:31:10 UTC 2014 root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 Any hints appreciated! :-) Tomek -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info From owner-freebsd-acpi@FreeBSD.ORG Mon Jun 16 15:39:57 2014 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 41001506; Mon, 16 Jun 2014 15:39:57 +0000 (UTC) Received: from mail-ob0-x236.google.com (mail-ob0-x236.google.com [IPv6:2607:f8b0:4003:c01::236]) (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 ED5072DE1; Mon, 16 Jun 2014 15:39:56 +0000 (UTC) Received: by mail-ob0-f182.google.com with SMTP id nu7so6002004obb.27 for ; Mon, 16 Jun 2014 08:39:56 -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:message-id:subject :from:to:content-type; bh=XgsvPi/BI34L5+5dsZ/5VLAuGAeH/xoPOfEvPs02goA=; b=nQPVDh/Uob+PuPH4Y3cKiQh50sBmpF/E5sHpyyQA1EaabJzMTMcvqrNeRYba+QyMrC DxcyqrJwxcIU2+ANjYRe9HlOpB6Ug7u7cNT16zgWJcqLUZy7zBHe2QHUTc3OTpSRVG8g CYGUuvpV8wu2CophTL+hKruDjyaxBa9+kTv5TCkJbtBrvuJYvPcALX76wNjoDU3nG6dM Y2EuoY46UUeqgqm7lWZ6HVVjy554jlzqCPAn48vlm8aFYClwkG9UliFrDo33YD7ljWFX rUbeIX7d98THreT+V2Yfk7Z4sD7oHs3H+GL85x4oAqt0zcCsSym3/580Yq3pQ3GBej4U z66A== MIME-Version: 1.0 X-Received: by 10.60.56.98 with SMTP id z2mr3581166oep.62.1402933196291; Mon, 16 Jun 2014 08:39:56 -0700 (PDT) Sender: tomek.cedro@gmail.com Received: by 10.202.75.207 with HTTP; Mon, 16 Jun 2014 08:39:56 -0700 (PDT) In-Reply-To: <20140616153254.GE1187@albert.catwhisker.org> References: <20140616153254.GE1187@albert.catwhisker.org> Date: Mon, 16 Jun 2014 17:39:56 +0200 X-Google-Sender-Auth: 4J8eNZjrY6Hf0VIgztB6oag9fP8 Message-ID: Subject: Re: sysctl hw.acpi.acline From: CeDeROM To: David Wolfskill , freebsd-hackers@freebsd.org, freebsd-acpi@freebsd.org Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jun 2014 15:39:57 -0000 On Mon, Jun 16, 2014 at 5:32 PM, David Wolfskill wrote: > On Mon, Jun 16, 2014 at 04:36:42PM +0200, CeDeROM wrote: >> ... >> How can I tell the power source on my FreeBSD (i.e. AC, Battery, UPS)? >> >> man acpi: >> ... >> hw.acpi.acline >> AC line state (1 means online, 0 means on battery power). >> .... > > From the perspective of the running system, you should not be able to > tell (merely from the state of the power supply, at least) whether power > is being supplied by UPS or "house wiring". > > You can make that distinction by querying the state of a UPS, if one is > connected (and set up to provide power to the system in question). I am porting from Linux code that use "/sys/class/power_supply/type" and can tell "Mains", "UPS", or "Battery". It would be nice if FreeBSD had something similar :-) >From ACPI manual it seems that "hw.acpi.acline" shoud do the job, but this OID is not available on desktops.. and this is not noted anywhere that "hw.acpi.acline" is only available on a laptops.. so I am not sure if my code should depend on this OID and if this is a bug? Thanks! :-) Tomek -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info From owner-freebsd-acpi@FreeBSD.ORG Mon Jun 16 19:07:47 2014 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 291A54B5 for ; Mon, 16 Jun 2014 19:07:47 +0000 (UTC) Received: from marnier.ucs.louisiana.edu (ucs.louisiana.edu [130.70.132.233]) by mx1.freebsd.org (Postfix) with ESMTP id D2B1023A4 for ; Mon, 16 Jun 2014 19:07:45 +0000 (UTC) Received: from zimbra-mta01.ucs.louisiana.edu (zimbra-mta01.ucs.louisiana.edu [130.70.132.57]) by marnier.ucs.louisiana.edu (8.14.1/8.14.1/ull-ucs-mx-host_1.9a) with ESMTP id s5GJ7WI6000369; Mon, 16 Jun 2014 14:07:37 -0500 (CDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra-mta01.ucs.louisiana.edu (Postfix) with ESMTP id A512023CC76; Mon, 16 Jun 2014 14:07:32 -0500 (CDT) X-Virus-Scanned: amavisd-new at zimbra-mta01.ucs.louisiana.edu Received: from zimbra-mta01.ucs.louisiana.edu ([127.0.0.1]) by localhost (zimbra-mta01.ucs.louisiana.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XDXxXOS8ilDt; Mon, 16 Jun 2014 14:07:32 -0500 (CDT) Received: from [130.70.78.85] (cacswifi085.cacs.louisiana.edu [130.70.78.85]) by zimbra-mta01.ucs.louisiana.edu (Postfix) with ESMTPSA id 1BC2423CC38; Mon, 16 Jun 2014 14:07:32 -0500 (CDT) Message-ID: <539F4063.3070107@louisiana.edu> Date: Mon, 16 Jun 2014 14:07:15 -0500 From: Eric Neblock User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Ian Smith , hiren panchasara Subject: Re: Missing: hw.acpi.thermal.tz%d._HOT References: <1402412054.2426.13.camel@canpc36.cacs.louisiana.edu> <20140611011810.V10629@sola.nimnet.asn.au> <1402414819.17836.2.camel@canpc36.cacs.louisiana.edu> <20140614013631.J10629@sola.nimnet.asn.au> In-Reply-To: <20140614013631.J10629@sola.nimnet.asn.au> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.18 Cc: "freebsd-acpi@freebsd.org" X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jun 2014 19:07:47 -0000 On 06/13/2014 11:22 AM, Ian Smith wrote: > On Thu, 12 Jun 2014 14:28:33 -0700, hiren panchasara wrote: > > On Tue, Jun 10, 2014 at 8:40 AM, Eric Neblock wrote: > > > On Wed, 2014-06-11 at 01:33 +1000, Ian Smith wrote: > > >> On Tue, 10 Jun 2014 09:54:14 -0500, Eric Neblock wrote: > > >> > Hello all, > > >> > I'm trying to figure out what is the _HOT temperature on my particular > > >> > processor. I'm running FreeBSD 10 GENERIC on a Sunfire X2200. > > >> > > > >> > The processor is an Dual Core AMD Opteron 2218. > > >> > > > >> > In the GENERIC kernel, acpi is built in; so, kldload acpi fails. I've > > >> > also loaded the amdtemp module at boot time to figure out what the > > >> > current temp of the processor is. > > >> > > > >> > With all of that, when performing `sysctl -a` I never seem to be able to > > >> > pull up the _HOT value. > > >> > > > >> > Are there any suggestions on how to be able to view it? > > >> > > >> Many thermal zones seen, including some CPUs, don't specify any _HOT > > >> value, just _PSV and _CRT, which should trigger passive cooling (eg > > >> clock slowing or throttling) and emergency shutdown, respectively. > > >> > > >> What says 'sysctl hw.acpi.thermal' ? > > >> > > >> cheers, Ian > > > > > > The result is as follows: > > > > > > sysctl: Unknown oid 'hw.acpi.thermal' : No such file or directory > > > > Similar thing here at home desktop running -CURRENT: > > > > CPU: AMD FX(tm)-8350 Eight-Core Processor (4000.24-MHz K8-class CPU) > > Origin="AuthenticAMD" Id=0x600f20 Family=0x15 Model=0x2 Stepping=0 > > > > acpi0: <7596MS A7596100> on motherboard > > > > Other related bits: > > > > # sysctl hw.acpi > > hw.acpi.supported_sleep_state: S3 S4 S5 > > hw.acpi.power_button_state: S5 > > hw.acpi.sleep_button_state: S3 > > hw.acpi.lid_switch_state: NONE > > hw.acpi.standby_state: NONE > > hw.acpi.suspend_state: S3 > > hw.acpi.sleep_delay: 1 > > hw.acpi.s4bios: 0 > > hw.acpi.verbose: 0 > > hw.acpi.disable_on_reboot: 0 > > hw.acpi.handle_reboot: 0 > > hw.acpi.reset_video: 0 > > hw.acpi.cpu.cx_lowest: C8 > > # > > > > # sysctl dev.amdtemp > > dev.amdtemp.0.%desc: AMD CPU On-Die Thermal Sensors > > dev.amdtemp.0.%driver: amdtemp > > dev.amdtemp.0.%parent: hostb4 > > dev.amdtemp.0.sensor_offset: 0 > > dev.amdtemp.0.core0.sensor0: 15.3C > > > > # sysctl -a dev.cpu | grep temp > > dev.cpu.0.temperature: 15.2C > > dev.cpu.1.temperature: 15.2C > > dev.cpu.2.temperature: 15.2C > > dev.cpu.3.temperature: 15.2C > > dev.cpu.4.temperature: 15.2C > > dev.cpu.5.temperature: 15.2C > > dev.cpu.6.temperature: 15.2C > > dev.cpu.7.temperature: 15.2C > > > > I am not sure how this ^ relates to what acpi reports under thermal. > > Well first, unless you've just turned it on, it's idling and lives in a > refrigerator or coldroom, those temperatures are at best a third of the > minimum I'd expect to see reported .. and they wouldn't all be the same. > > And neither of these are reporting hw.acpi.thermal .. is it because the > BIOS / ACPI doesn't present thermal zone information? Or there aren't > suitable drivers to interpret it? I've no idea, but does seem curious. > > Any output from? > # acpidump -dt | egrep -i 'TZ|thermal' I also got the same results as Hiren. I'll attach my results as well. Eric > If so, you might want to put your full ASL up somewhere. Note: I'm not > at all qualified to interpret it, just that I'd expect there to be some; > eg on a Lenovo X200 (Core2 Duo): > root@x200:~ # acpidump -dt | egrep -i 'TZ|thermal' > Notify (\_TZ.THM0, 0x80) > Notify (\_TZ.THM1, 0x80) > Notify (\_TZ.THM0, 0x80) > Notify (\_TZ.THM1, 0x80) > "AdaptiveThermalManagementAC" > "AdaptiveThermalManagementBattery" > Notify (\_TZ.THM0, 0x80) > Notify (\_TZ.THM1, 0x80) > Notify (\_TZ.THM1, 0x80) > Notify (\_TZ.THM0, 0x81) > Scope (\_TZ) > ThermalZone (THM0) > ThermalZone (THM1) > Return (\_TZ.THM0._TMP ()) > Notify (\_TZ.THM0, 0x80) > > cheers, Ian > From owner-freebsd-acpi@FreeBSD.ORG Mon Jun 16 21:43:58 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 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4D7041F9; Mon, 16 Jun 2014 21:43:58 +0000 (UTC) Received: from mail-ob0-x22e.google.com (mail-ob0-x22e.google.com [IPv6:2607:f8b0:4003:c01::22e]) (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 0D4D4217D; Mon, 16 Jun 2014 21:43:57 +0000 (UTC) Received: by mail-ob0-f174.google.com with SMTP id va2so6484912obc.33 for ; Mon, 16 Jun 2014 14:43: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:message-id:subject :from:to:content-type; bh=ehMrkDXWV6gL+WcEO4ZYvx6E9B46bV5I0V4+8bfjXMY=; b=NPbJ8DobHiXQyDbuC3fOVL82sBhwzDpRNpDD04s5xQC96lq4XButwmER60IysINjhS jpE2QijHRaSjxrN3N9ElKprbjg2HUWbB4KyjOXEZ+2cU3Eq/b59sACEqH8QgdY7hfSGD zwiT5LzWfoeJBYncCN5MmiSLfV63oRbrhKc+ABJuHb0iClPP0eEHilF6S982mEQ/po5Y qS3GLbN9c1elx8UAKkVuuEOPS4FLUSAZcf73sgqooy+gScXshkPM+GpURSXnpAyn9tRl kIdAoIHni4LRAZnK1jItPc8dXHHJo3A92GsHdVSBUNJvt9ZrPzRWCaJUDk6d3tAa62kK RNqA== MIME-Version: 1.0 X-Received: by 10.60.70.200 with SMTP id o8mr10627599oeu.55.1402955037387; Mon, 16 Jun 2014 14:43:57 -0700 (PDT) Sender: tomek.cedro@gmail.com Received: by 10.202.75.207 with HTTP; Mon, 16 Jun 2014 14:43:57 -0700 (PDT) In-Reply-To: <539F56E9.8070809@muc.de> References: <539F56E9.8070809@muc.de> Date: Mon, 16 Jun 2014 23:43:57 +0200 X-Google-Sender-Auth: LPzl5D_npZMQzU9VoHprxdIqY68 Message-ID: Subject: Re: sysctl hw.acpi.acline From: CeDeROM To: Armin Gruner , freebsd-hackers@freebsd.org, freebsd-acpi@freebsd.org Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jun 2014 21:43:58 -0000 On Mon, Jun 16, 2014 at 10:43 PM, Armin Gruner wrote: > it's actually "hw.acpi.battery.state" > (the man page is indeed stale) > The value of hw.acpi.battery.state > 0 means: on AC power > 1 means: on battery > 2 means: charging Hey Armin :-) The same situation here on a desktop I get: root@hexagon:~ # sysctl hw.acpi.battery.state sysctl: unknown oid 'hw.acpi.battery.state': No such file or directory root@hexagon:~ # uname -a FreeBSD hexagon 10.0-RELEASE-p3 FreeBSD 10.0-RELEASE-p3 #0: Tue May 13 18:31:10 UTC 2014 root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 Tanks! :-) Tomek -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info From owner-freebsd-acpi@FreeBSD.ORG Mon Jun 16 22:16:40 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 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 26358991 for ; Mon, 16 Jun 2014 22:16:40 +0000 (UTC) Received: from nm13.access.bullet.mail.bf1.yahoo.com (nm13.access.bullet.mail.bf1.yahoo.com [216.109.114.36]) (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 A4932243E for ; Mon, 16 Jun 2014 22:16:39 +0000 (UTC) Received: from [66.196.81.164] by nm13.access.bullet.mail.bf1.yahoo.com with NNFMP; 16 Jun 2014 22:10:10 -0000 Received: from [98.138.226.244] by tm10.access.bullet.mail.bf1.yahoo.com with NNFMP; 16 Jun 2014 22:10:10 -0000 Received: from [127.0.0.1] by smtp115.sbc.mail.ne1.yahoo.com with NNFMP; 16 Jun 2014 22:10:10 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1402956610; bh=t5Zi3B/lh/booZzBRP2Fzyk/ARFQBtUTnnM276IFi5Y=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=XVk57plZpJDGakUynvwOYECgBpqDewNMVAiMHnal7PIQo3UVSD6qeMt0ybc2EfjZF69x9t1C6ldfiSKp7IaFUZhOsLcCKTfUsavdZWB2/L4SNiPyptcW9KB83ICcgq6OnfV/f2OGgtjCc3XLZhdCY1UrH/9kvwtuRVklAIB0Ihw= X-Yahoo-Newman-Id: 217920.74373.bm@smtp115.sbc.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: y7WElrUVM1kJx19oxi4sCwYcAcKLhvQwj.aezwpm1m2D7DZ Yd0u6NZv4V4xGqFb6yH24X2boWd00Cc7b01iJRpvAh8jnEObvGdX8ogtJ6uz O3bb5zlpGyJ_zT2wAayKVoAW_T0HJ9Kwo0DPjvCE.7Fruss7Ra8ZrxrNwieK LbsgAnYcvG8xLo2Klr5a4rDB7OVqC.WTBgX4xxFgYOMjjH3cHwoCSIXRhgjr 3kTiuGRFjjYtaQFGaFoW.NeZpBV.pQPBSlYCzNCbhJ_PiomyqdmcyYhvq6eG k7bwws7VtA7jVtT03DijNmm1vw.wASpJKFnhJA9AvO5HhX53DY1UBt1cGjIt 68LckRzum_u18ETVpVFIVKx11c4g9qtnuBua5Tcxli6Xb.WtJrPPiRVZyYCA uQN8fH6Ul4SHylIwc7nY9yhzmHfFWh5vmhhGD1AZKsPgrWvkXZ0LQzmGbAsf FanPm3Bu8E24G4l6K2ClhUNMB6tOumOZNWtanVU0j9moD7AvSmBHh2hWjhsq kGkdvNTDZhxbycTkK.DMdUWZ41_g52AfYloGwuegg8C4n7g-- X-Yahoo-SMTP: OKD1keCswBBTAmAF1s00hLyKW3wE3YfSK0Eazl6b4VZG4LTqJxg- X-Rocket-Received: from [64.100.76.53] (Anthony.B.Jenkins@64.100.76.53 with plain [98.138.84.52]) by smtp115.sbc.mail.ne1.yahoo.com with SMTP; 16 Jun 2014 22:10:10 +0000 UTC Message-ID: <539F6B3F.2000308@att.net> Date: Mon, 16 Jun 2014 18:10:07 -0400 From: Anthony Jenkins User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: CeDeROM , Armin Gruner , freebsd-hackers@freebsd.org, freebsd-acpi@freebsd.org Subject: Re: sysctl hw.acpi.acline References: <539F56E9.8070809@muc.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jun 2014 22:16:40 -0000 On 06/16/2014 17:43, CeDeROM wrote: > On Mon, Jun 16, 2014 at 10:43 PM, Armin Gruner wrote: >> it's actually "hw.acpi.battery.state" >> (the man page is indeed stale) >> The value of hw.acpi.battery.state >> 0 means: on AC power >> 1 means: on battery >> 2 means: charging > Hey Armin :-) The same situation here on a desktop I get: > > root@hexagon:~ # sysctl hw.acpi.battery.state > sysctl: unknown oid 'hw.acpi.battery.state': No such file or directory > root@hexagon:~ # uname -a > FreeBSD hexagon 10.0-RELEASE-p3 FreeBSD 10.0-RELEASE-p3 #0: Tue May 13 > 18:31:10 UTC 2014 > root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 > > Tanks! :-) > Tomek > The absence of hw.acpi.battery and child oids probably implies there is no battery and the system may be assumed to be on line (A/C) power. Anthony From owner-freebsd-acpi@FreeBSD.ORG Mon Jun 16 22:25:06 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 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2FFE5DE6; Mon, 16 Jun 2014 22:25:06 +0000 (UTC) Received: from mail-oa0-x22b.google.com (mail-oa0-x22b.google.com [IPv6:2607:f8b0:4003:c02::22b]) (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 DC4292504; Mon, 16 Jun 2014 22:25:05 +0000 (UTC) Received: by mail-oa0-f43.google.com with SMTP id o6so6699572oag.30 for ; Mon, 16 Jun 2014 15:25:05 -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:message-id:subject :from:to:cc:content-type; bh=Ofme2RQEBblKh7KAvCJZLjD1DvIdFEZOVwCCenh4ajk=; b=rxli+mvdXziu4HBDHzm3dNcx8B1UatPBH7sMwOG05jdmq6YCb1kqf20xq6WQd4Kw+K IyKVZlxu/ksOIXU5LdKrnbTBR2x23bcx0iHPbzyUupbfWotbKpfw7ioh4Mno7IKkdG1w QZwhp5Cc1eYNfPknBgv66tBGlajM0IHG/nbnYbk3oX5kFDCDwrI96zK8hg2oSQgV2MoE 0yVZwHgJxX0DTM29lXPs5Hk4WJ8d0h5j4mXgqvMBZCd4a1FFt83cNRqI7CJ+Sr2SnMh7 P5YqywtkpHf131E/zEEzE6vv9zuUjLQol4RVo5SJk9WHN7dZ6p+yU59xVIsb008TaHN5 j8jg== MIME-Version: 1.0 X-Received: by 10.182.230.227 with SMTP id tb3mr11018448obc.55.1402957505216; Mon, 16 Jun 2014 15:25:05 -0700 (PDT) Sender: tomek.cedro@gmail.com Received: by 10.202.75.207 with HTTP; Mon, 16 Jun 2014 15:25:05 -0700 (PDT) In-Reply-To: <539F6B3F.2000308@att.net> References: <539F56E9.8070809@muc.de> <539F6B3F.2000308@att.net> Date: Tue, 17 Jun 2014 00:25:05 +0200 X-Google-Sender-Auth: WCbQhT7ij1OD3hTtyj2kHwS_5lI Message-ID: Subject: Re: sysctl hw.acpi.acline From: CeDeROM To: Anthony Jenkins Content-Type: text/plain; charset=UTF-8 Cc: freebsd-hackers@freebsd.org, freebsd-acpi@freebsd.org, Armin Gruner X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jun 2014 22:25:06 -0000 On Tue, Jun 17, 2014 at 12:10 AM, Anthony Jenkins wrote: > The absence of hw.acpi.battery and child oids probably implies there is no battery and the system may be assumed to be on line (A/C) power. Hello Anthony! I would prefer to have that information clearly defined in the manual :-) I guessed that this is a quick fix to first check the OID existence, but if manual tells there is such OID it should be there, even if there is no battery, huh? This is why I consider this to be a bug :-) -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info From owner-freebsd-acpi@FreeBSD.ORG Tue Jun 17 00:29:08 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 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CDA4B754; Tue, 17 Jun 2014 00:29:08 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "funkthat.com", Issuer "funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 8E4A92EF7; Tue, 17 Jun 2014 00:29:08 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id s5H0T5GV005086 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 16 Jun 2014 17:29:06 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s5H0T5VP005085; Mon, 16 Jun 2014 17:29:05 -0700 (PDT) (envelope-from jmg) Date: Mon, 16 Jun 2014 17:29:05 -0700 From: John-Mark Gurney To: CeDeROM Subject: Re: sysctl hw.acpi.acline Message-ID: <20140617002905.GW31367@funkthat.com> Mail-Followup-To: CeDeROM , Anthony Jenkins , freebsd-hackers@freebsd.org, freebsd-acpi@freebsd.org, Armin Gruner References: <539F56E9.8070809@muc.de> <539F6B3F.2000308@att.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Mon, 16 Jun 2014 17:29:06 -0700 (PDT) Cc: Anthony Jenkins , freebsd-hackers@freebsd.org, freebsd-acpi@freebsd.org, Armin Gruner X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jun 2014 00:29:08 -0000 CeDeROM wrote this message on Tue, Jun 17, 2014 at 00:25 +0200: > On Tue, Jun 17, 2014 at 12:10 AM, Anthony Jenkins > wrote: > > The absence of hw.acpi.battery and child oids probably implies there is no battery and the system may be assumed to be on line (A/C) power. > > Hello Anthony! I would prefer to have that information clearly defined > in the manual :-) I guessed that this is a quick fix to first check Which manual? > the OID existence, but if manual tells there is such OID it should be > there, even if there is no battery, huh? This is why I consider this > to be a bug :-) ACPI have tons of optional stuff that isn't required to be present, and apparently acline is one of them. Also, acline is only useful if there are multiple power sources, what if you have a desktop machine always running off a battery, if we defaulted acline=1, then you'd complain that the status is wrong... :) -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-acpi@FreeBSD.ORG Tue Jun 17 06:12:46 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 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 79012574; Tue, 17 Jun 2014 06:12:46 +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 E63682895; Tue, 17 Jun 2014 06:12:44 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id s5H6CeMe054143; Tue, 17 Jun 2014 16:12:40 +1000 (EST) (envelope-from smithi@nimnet.asn.au) Date: Tue, 17 Jun 2014 16:12:40 +1000 (EST) From: Ian Smith To: CeDeROM Subject: Re: sysctl hw.acpi.acline In-Reply-To: Message-ID: <20140617153436.G609@sola.nimnet.asn.au> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: freebsd-hackers@freebsd.org, freebsd-acpi@freebsd.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jun 2014 06:12:46 -0000 On Mon, 16 Jun 2014 16:36:42 +0200, CeDeROM wrote: > One application that I am porting needs to know the power supply > information from the system. I thought using SYSCTL + ACPI would be > the simplest and elegant way. But, I found out that information on the > power supply is only available on the laptop machines, while on the > desktop machines it does not apply. According to the "man acpi", the > "hw.acpi.acline" oid tells the AC line state, so I guess desktop > should always tell 1, but there is no such oid on my desktop.. > > Is this a bug or feature? :-) Definitely a feature. The absence of this OID is a sure way to tell if the machine you're talking to - which may be remote, so you may not know how it's being powered - is or is not (capable of) running on battery. > How can I tell the power source on my FreeBSD (i.e. AC, Battery, UPS)? > > man acpi: > ... > hw.acpi.acline > AC line state (1 means online, 0 means on battery power). > > root@hexagon:~ # sysctl hw.acpi.acline > sysctl: unknown oid 'hw.acpi.acline': No such file or directory So this is an AC powered machine. And it is, most certainly, ON. Perhaps what you need to do is fit one of these to your machine: DED (pronounced "dead") (dark emitting diode) A variation of LED technology used exclusively by the CIA for clandestine equipment. Also popular as power-off indicators. http://www.rane.com/par-d.html You could also add a DDR (dark dependant resistor) circuit to ring a bell whenever the DED is emitting, just to be sure it really is OFF. You should probably avoid using the new super-dark DEDs or you may find your room plunged into impenetrable darkness whenever power goes off. Seriously for a moment: if you do have a UPS you'll need to interrogate the UPS software - which varies for different brands of UPS so can't be integrated with the BIOS/ACPI - for its state, as David mentioned. cheers, Ian From owner-freebsd-acpi@FreeBSD.ORG Tue Jun 17 06:18:48 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 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4ADA160C; Tue, 17 Jun 2014 06:18:48 +0000 (UTC) Received: from mail-oa0-x22a.google.com (mail-oa0-x22a.google.com [IPv6:2607:f8b0:4003:c02::22a]) (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 07C5828BB; Tue, 17 Jun 2014 06:18:47 +0000 (UTC) Received: by mail-oa0-f42.google.com with SMTP id eb12so7492979oac.1 for ; Mon, 16 Jun 2014 23:18:47 -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:message-id:subject :from:to:content-type; bh=L8vzFcyDtgr0v7LmyDT/OvJoVfcHKp6NPymQN6WiQ0o=; b=YB0iy/1KQMkvUG5jYsZzgXsF+EKTmoUCZ2fVhWTVGtBm+IbPwDfc6RRvP8+rfIjD3g kKrJzBJjd6PGczpG767q9YXIBfOdOwod096KE2BJ/KqRKC21kV98iYNJkoEehgJ9j5dJ sPAfeRbheMmY0Y6QrFWFgSroEZd88DOwFQaW0/IX3UeG6YdKUwxyentJakYX5PpGY2zD mPMjOnhbIJ5gU5MzFvPzsCMA+juw7Z8nvdm88epbsRrAAwatJZGn91oo773JyeZx6HsZ WMu8jcIWqXu7ZjRvxZ0olZ0ViUudKrlP8nngOPCC/yVJ8DhzV75qIBOMpmz3x77qwQf1 EGlg== MIME-Version: 1.0 X-Received: by 10.60.65.136 with SMTP id x8mr24682263oes.30.1402985927259; Mon, 16 Jun 2014 23:18:47 -0700 (PDT) Sender: tomek.cedro@gmail.com Received: by 10.202.75.207 with HTTP; Mon, 16 Jun 2014 23:18:47 -0700 (PDT) In-Reply-To: <20140617002905.GW31367@funkthat.com> References: <539F56E9.8070809@muc.de> <539F6B3F.2000308@att.net> <20140617002905.GW31367@funkthat.com> Date: Tue, 17 Jun 2014 08:18:47 +0200 X-Google-Sender-Auth: caOaO78el1i6Sl9_09F6OM-9Bac Message-ID: Subject: Re: sysctl hw.acpi.acline From: CeDeROM To: Anthony Jenkins , freebsd-hackers@freebsd.org, freebsd-acpi@freebsd.org, Armin Gruner Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jun 2014 06:18:48 -0000 On Tue, Jun 17, 2014 at 2:29 AM, John-Mark Gurney wrote: > CeDeROM wrote this message on Tue, Jun 17, 2014 at 00:25 +0200: >> On Tue, Jun 17, 2014 at 12:10 AM, Anthony Jenkins >> wrote: >> > The absence of hw.acpi.battery and child oids probably implies there is no battery and the system may be assumed to be on line (A/C) power. >> >> Hello Anthony! I would prefer to have that information clearly defined >> in the manual :-) I guessed that this is a quick fix to first check > > Which manual? man acpi > ACPI have tons of optional stuff that isn't required to be present, > and apparently acline is one of them. Also, acline is only useful > if there are multiple power sources, what if you have a desktop > machine always running off a battery, if we defaulted acline=1, then > you'd complain that the status is wrong... :) There is no information in the ACPI Manual that the OID's are optional and may not exist in some cases. This is exactly the problem, an undefined and undocumented situation. Maybe its just worth putting a note :-) " hw.acpi.acline AC line state (1 means online, 0 means on battery power). " I expect code based on this oid to work on both desktop and laptop with no additional guessing. For me this manual information means that acline oid is always available, and will show 1 in case of desktop where no battery (maybe no UPS as well) is available. There is no information that this oid is optional. For desktop/server a battery power would mean UPS, right, so then I would also expect to see the battery charge status information.. but I understand this would be more complicated than in a laptop thus may not be implemented. Still, I would always expect power source type OID to tell me what is the power source, even if there can be only one. Best regards :-) Tomek -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info From owner-freebsd-acpi@FreeBSD.ORG Tue Jun 17 13:55:01 2014 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D167A10F for ; Tue, 17 Jun 2014 13:55:01 +0000 (UTC) Received: from mail.metricspace.net (207-172-209-89.c3-0.arl-ubr1.sbo-arl.ma.static.cable.rcn.com [207.172.209.89]) by mx1.freebsd.org (Postfix) with ESMTP id AA6382233 for ; Tue, 17 Jun 2014 13:55:01 +0000 (UTC) Received: from [172.16.1.182] (unknown [172.16.1.182]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) (Authenticated sender: eric) by mail.metricspace.net (Postfix) with ESMTPSA id E39332424D for ; Tue, 17 Jun 2014 13:54:59 +0000 (UTC) Message-ID: <53A048B1.1080108@metricspace.net> Date: Tue, 17 Jun 2014 09:54:57 -0400 From: Eric McCorkle User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: freebsd-acpi@freebsd.org Subject: ACPI error messages on Lenovo W540 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jun 2014 13:55:01 -0000 Hello, I'm trying to set up on a lenovo W540 mobile workstation I recently purchased. Things work well for the most part (including suspend/resume), however there's some error messages that I suspect are at the root of why the nvidia Xorg driver doesn't work, and possibly also at the root of why USB 3.0 won't work either. At suspend/resume, the following error messages show up: pci0: failed to set ACPI power state D2 on \134_SB_.PCI0.PEG_: AE_BAD_PARAMETER pci0: failed to set ACPI power state D2 on \134_SB_.PCI0.EXP1: AE_BAD_PARAMETER pci0: failed to set ACPI power state D2 on \134_SB_.PCI0.EXP2: AE_BAD_PARAMETER pci0: failed to set ACPI power state D2 on \134_SB_.PCI0.EXP3: AE_BAD_PARAMETER pci0: failed to set ACPI power state D2 on \134_SB_.PCI0.EXP5: AE_BAD_PARAMETER I suspect these might have something to do with the USB 3.0 system not working, though I don't have experience with either the ACPI or USB subsystems. Also, the nvidia Xorg driver fails to work, and causes a similar error message: ACPI Warning: \134_SB_.PCI0.PEG_.VID_._DSM: Argument #4 type mismatch - Found [Buffer], APCI requires [Package] (20130823/nsarguments-97) (the same message gets repeated about 10 times) Again, I don't have any experience with ACPI, but this looks to me like a vendor-specific quirk. Any advice on how to go about fixing/working around this? Thanks, Eric From owner-freebsd-acpi@FreeBSD.ORG Tue Jun 17 14:16:14 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 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 671806F1 for ; Tue, 17 Jun 2014 14:16:14 +0000 (UTC) Received: from mail.turbocat.net (mail.turbocat.net [IPv6:2a01:4f8:d16:4514::2]) (using TLSv1.1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2AA6F2442 for ; Tue, 17 Jun 2014 14:16:14 +0000 (UTC) Received: from laptop015.home.selasky.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id EF9C01FE045; Tue, 17 Jun 2014 16:16:12 +0200 (CEST) Message-ID: <53A04DC0.8080703@selasky.org> Date: Tue, 17 Jun 2014 16:16:32 +0200 From: Hans Petter Selasky User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Eric McCorkle , freebsd-acpi@freebsd.org Subject: Re: ACPI error messages on Lenovo W540 References: <53A048B1.1080108@metricspace.net> In-Reply-To: <53A048B1.1080108@metricspace.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jun 2014 14:16:14 -0000 On 06/17/14 15:54, Eric McCorkle wrote: > I suspect these might have something to do with the USB 3.0 system not > working, though I don't have experience with either the ACPI or USB > subsystems. Regarding USB 3.0, does "pciconf -lv" list xhci? --HPS From owner-freebsd-acpi@FreeBSD.ORG Tue Jun 17 18:06:23 2014 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C0DF8686 for ; Tue, 17 Jun 2014 18:06:23 +0000 (UTC) Received: from mail.metricspace.net (mail.metricspace.net [IPv6:2001:470:1f11:617::103]) by mx1.freebsd.org (Postfix) with ESMTP id 964AB2AE8 for ; Tue, 17 Jun 2014 18:06:23 +0000 (UTC) Received: from [10.2.158.112] (mobile-198-228-199-009.mycingular.net [198.228.199.9]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) (Authenticated sender: eric) by mail.metricspace.net (Postfix) with ESMTPSA id 108C82498B; Tue, 17 Jun 2014 18:06:22 +0000 (UTC) References: <53A048B1.1080108@metricspace.net> <53A04DC0.8080703@selasky.org> Mime-Version: 1.0 (1.0) In-Reply-To: <53A04DC0.8080703@selasky.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <94CC8439-62DA-4D55-BA4E-1B225BCA1DF8@metricspace.net> X-Mailer: iPhone Mail (11B511) From: Eric McCorkle Subject: Re: ACPI error messages on Lenovo W540 Date: Tue, 17 Jun 2014 14:06:15 -0400 To: Hans Petter Selasky Cc: "freebsd-acpi@freebsd.org" X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jun 2014 18:06:23 -0000 Yes it does. The messages may not be related at all; it's just a suspicion.= I am more certain, however, that there's an issue preventing the nvidia driv= er from working. > On Jun 17, 2014, at 10:16 AM, Hans Petter Selasky wrote:= >=20 >> On 06/17/14 15:54, Eric McCorkle wrote: >> I suspect these might have something to do with the USB 3.0 system not >> working, though I don't have experience with either the ACPI or USB >> subsystems. >=20 > Regarding USB 3.0, does "pciconf -lv" list xhci? >=20 > --HPS From owner-freebsd-acpi@FreeBSD.ORG Wed Jun 18 06:40:05 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 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 63696CF8; Wed, 18 Jun 2014 06:40:05 +0000 (UTC) Received: from locore.org (ns01.locore.org [218.45.21.227]) (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 E5D7E2C47; Wed, 18 Jun 2014 06:40:03 +0000 (UTC) Received: from localhost (celeron.v4.locore.org [192.168.0.10]) by locore.org (8.14.5/8.14.5/iwasaki) with ESMTP/inet id s5I6SQex044291; Wed, 18 Jun 2014 15:28:26 +0900 (JST) (envelope-from iwasaki@freebsd.org) Date: Wed, 18 Jun 2014 15:28:26 +0900 (JST) Message-Id: <20140618.152826.81987615.iwasaki@freebsd.org> To: cederom@tlen.pl Subject: Re: sysctl hw.acpi.acline From: Mitsuru IWASAKI In-Reply-To: References: <20140617002905.GW31367@funkthat.com> X-Mailer: Mew version 3.3 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Anthony.B.Jenkins@att.net, freebsd-hackers@freebsd.org, freebsd-acpi@freebsd.org, ag@muc.de X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jun 2014 06:40:05 -0000 Hi, > > ACPI have tons of optional stuff that isn't required to be present, > > and apparently acline is one of them. Also, acline is only useful > > if there are multiple power sources, what if you have a desktop > > machine always running off a battery, if we defaulted acline=1, then > > you'd complain that the status is wrong... :) > > There is no information in the ACPI Manual that the OID's are optional > and may not exist in some cases. This is exactly the problem, an > undefined and undocumented situation. Maybe its just worth putting a > note :-) > > " > hw.acpi.acline > AC line state (1 means online, 0 means on battery power). > " OK, how about adding the following line? ---- Note that this OID exists only if there is a ACPI Device ID "ACPI0003" in ACPI Namespace of the system. ---- > I expect code based on this oid to work on both desktop and laptop > with no additional guessing. For me this manual information means that > acline oid is always available, and will show 1 in case of desktop > where no battery (maybe no UPS as well) is available. There is no > information that this oid is optional. For desktop/server a battery > power would mean UPS, right, so then I would also expect to see the > battery charge status information.. but I understand this would be > more complicated than in a laptop thus may not be implemented. Still, > I would always expect power source type OID to tell me what is the > power source, even if there can be only one. Unfortunately, UPS is not covered by ACPI specification. I think that new OID would be needed in generic place (not under hw.acpi) in order to get the state of power sources. In that case, hw.acpi.battery should be moved to new place too. Thanks From owner-freebsd-acpi@FreeBSD.ORG Wed Jun 18 07:17:51 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 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AC043E6A; Wed, 18 Jun 2014 07:17:51 +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 07C1A2FCD; Wed, 18 Jun 2014 07:17:50 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id s5I7HeI6006287; Wed, 18 Jun 2014 17:17:40 +1000 (EST) (envelope-from smithi@nimnet.asn.au) Date: Wed, 18 Jun 2014 17:17:40 +1000 (EST) From: Ian Smith To: Eric McCorkle Subject: Re: ACPI error messages on Lenovo W540 In-Reply-To: <53A048B1.1080108@metricspace.net> Message-ID: <20140618163410.C609@sola.nimnet.asn.au> References: <53A048B1.1080108@metricspace.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: freebsd-acpi@freebsd.org, freebsd-mobile@freebsd.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jun 2014 07:17:51 -0000 On Tue, 17 Jun 2014 09:54:57 -0400, Eric McCorkle wrote: > I'm trying to set up on a lenovo W540 mobile workstation I recently > purchased. Things work well for the most part (including suspend/resume), > however there's some error messages that I suspect are at the root of why the > nvidia Xorg driver doesn't work, and possibly also at the root of why USB 3.0 > won't work either. > > At suspend/resume, the following error messages show up: > > pci0: failed to set ACPI power state D2 on \134_SB_.PCI0.PEG_: > AE_BAD_PARAMETER > pci0: failed to set ACPI power state D2 on \134_SB_.PCI0.EXP1: > AE_BAD_PARAMETER > pci0: failed to set ACPI power state D2 on \134_SB_.PCI0.EXP2: > AE_BAD_PARAMETER > pci0: failed to set ACPI power state D2 on \134_SB_.PCI0.EXP3: > AE_BAD_PARAMETER > pci0: failed to set ACPI power state D2 on \134_SB_.PCI0.EXP5: > AE_BAD_PARAMETER > > I suspect these might have something to do with the USB 3.0 system not > working, though I don't have experience with either the ACPI or USB > subsystems. > > Also, the nvidia Xorg driver fails to work, and causes a similar error > message: > > ACPI Warning: \134_SB_.PCI0.PEG_.VID_._DSM: Argument #4 type mismatch - > Found [Buffer], APCI requires [Package] (20130823/nsarguments-97) > (the same message gets repeated about 10 times) > > Again, I don't have any experience with ACPI, but this looks to me like a > vendor-specific quirk. > > Any advice on how to go about fixing/working around this? Hi Eric, I refer you to freebsd-mobile@ archives for May re these 'failed to set ACPI power state D2' messages, in thread 'Thinkpad T410: resume broken'. I'm also cross-posting this back there. These appear on the suspend path on (AFAICT) all modern Lenovos; X2xx, T4xx and T5xx at least, though I get similar messages for the Cardbus bridges on my old T23s. The EXPn messages at least do appear to be harmless though they keep causing your sort of concern, and it would be good in the long run to find out why attempts are being made to set state D2 on devices that (should indicate that they) don't support it. John Baldwin (cc'd) explains in that thread that the EXPn devices are "probably PCI-PCI bridges that represent the downstream ports of your PCI-e root complex)" though I can't say I understand what that means .. with verbose boot messages you may also see that these are initialised back into D0 state twice, unlike the other devices. The PEG_ message seems to appear on the more recent ones with integrated graphics. I don't know if that message represents a problem or not, though the later warnings re \134_SB_.PCI0.PEG_.VID_._DSM seem ominous. It would be good to know if your USB3 issues are connected to the more generic issue all these Lenovos appear to have of USB failing entirely, only on the external ports, after - depending on model - one or two suspend/resume cycles. There's not even any 5V on these ports, whether or not the BIOS has been set to provide 5V on these ports in suspend or power-off states. Does that also happen on yours? cheers, Ian From owner-freebsd-acpi@FreeBSD.ORG Wed Jun 18 09:51:39 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 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 65BA5F37; Wed, 18 Jun 2014 09:51:39 +0000 (UTC) Received: from mail-oa0-x229.google.com (mail-oa0-x229.google.com [IPv6:2607:f8b0:4003:c02::229]) (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 165522D4F; Wed, 18 Jun 2014 09:51:39 +0000 (UTC) Received: by mail-oa0-f41.google.com with SMTP id l6so1283198oag.28 for ; Wed, 18 Jun 2014 02:51:38 -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:message-id:subject :from:to:cc:content-type; bh=c5FR/pv5FZvHHO02+aZeLhJdKqkep7LRuUaC3bTCcJQ=; b=Z2ilYijD+pFzOYcfiZj7R4JJzcXjXNgjspf5DFY6PGlw2Ps8obcSNaNAbnk3/tm9BH mRxxZ3nzs/V8MMm8B9npQUS+tne2aZq3zoHHCuEGp89tcBcQXk4FhWfsmAnD3OU08450 iUnTT35L6oJNYjjrJhLgZ8YxtYwX8iqVFQwyP4uNai8/KX02AYW4wChMImXO/Lhcie99 SQ3tVQn7kdFfWHVGWcoS40S8MmB1hKv0ae9g6kIC4isCM9OIVJnTSaL7kBQLaxKSMOqW +oWMd3u8JynSwVVEQtkB7gbVn8KRomdmOpbWyTpNiMPGPSS95vFItJFgJTpomBKTXD3q 7oYQ== MIME-Version: 1.0 X-Received: by 10.60.73.39 with SMTP id i7mr755460oev.51.1403085098327; Wed, 18 Jun 2014 02:51:38 -0700 (PDT) Sender: tomek.cedro@gmail.com Received: by 10.202.75.207 with HTTP; Wed, 18 Jun 2014 02:51:38 -0700 (PDT) In-Reply-To: <20140618.152826.81987615.iwasaki@freebsd.org> References: <20140617002905.GW31367@funkthat.com> <20140618.152826.81987615.iwasaki@freebsd.org> Date: Wed, 18 Jun 2014 11:51:38 +0200 X-Google-Sender-Auth: KhjdIgN-vSpYllSt0v9GkkAzZYk Message-ID: Subject: Re: sysctl hw.acpi.acline From: CeDeROM To: Mitsuru IWASAKI Content-Type: text/plain; charset=UTF-8 Cc: Anthony Jenkins , freebsd-hackers@freebsd.org, freebsd-acpi@freebsd.org, Armin Gruner X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jun 2014 09:51:39 -0000 On Wed, Jun 18, 2014 at 8:28 AM, Mitsuru IWASAKI wrote: >> There is no information in the ACPI Manual that the OID's are optional >> and may not exist in some cases. This is exactly the problem, an >> undefined and undocumented situation. Maybe its just worth putting a >> note :-) > > OK, how about adding the following line? > ---- > Note that this OID exists only if there is a ACPI Device ID "ACPI0003" in ACPI Namespace of the system. > ---- Hello Mitsuru! :-) I wanted to ask the list and make sure, in general, if OID can be optional/missing depending on the hardware capabilities. It looks like things are like that - some other OID are missing as well depending on the hardware. I think one general remark could be put into acpi and sysctl manual pages, something like: "Note that some OID will be available only if given hardware supports them, on a different hardware these will be missing which means that feature is not supported." > Unfortunately, UPS is not covered by ACPI specification. I think that > new OID would be needed in generic place (not under hw.acpi) in order > to get the state of power sources. > In that case, hw.acpi.battery should be moved to new place too. I thought acline would be such place - it is even specified in the manual (unlike battery) :-) Now I know assumption must be made that is acline oid is not available then we have a dekstop. But I dont really like assumptions, thats why I prefered to ask first :-) Thank you! :-) Tomek -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info From owner-freebsd-acpi@FreeBSD.ORG Sat Jun 21 02:27:24 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 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AF026E5C; Sat, 21 Jun 2014 02:27:24 +0000 (UTC) Received: from mail.metricspace.net (207-172-209-89.c3-0.arl-ubr1.sbo-arl.ma.static.cable.rcn.com [207.172.209.89]) by mx1.freebsd.org (Postfix) with ESMTP id 811D52379; Sat, 21 Jun 2014 02:27:23 +0000 (UTC) Received: from [172.16.1.182] (unknown [172.16.1.182]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) (Authenticated sender: eric) by mail.metricspace.net (Postfix) with ESMTPSA id 9810B25B10; Sat, 21 Jun 2014 02:27:17 +0000 (UTC) Message-ID: <53A4ED85.2050904@metricspace.net> Date: Fri, 20 Jun 2014 22:27:17 -0400 From: Eric McCorkle User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Ian Smith Subject: Re: ACPI error messages on Lenovo W540 References: <53A048B1.1080108@metricspace.net> <20140618163410.C609@sola.nimnet.asn.au> In-Reply-To: <20140618163410.C609@sola.nimnet.asn.au> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@freebsd.org, freebsd-mobile@freebsd.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Jun 2014 02:27:24 -0000 On 06/18/2014 03:17, Ian Smith wrote: > On Tue, 17 Jun 2014 09:54:57 -0400, Eric McCorkle wrote: > > > I'm trying to set up on a lenovo W540 mobile workstation I recently > > purchased. Things work well for the most part (including suspend/resume), > > however there's some error messages that I suspect are at the root of why the > > nvidia Xorg driver doesn't work, and possibly also at the root of why USB 3.0 > > won't work either. > > > > At suspend/resume, the following error messages show up: > > > > pci0: failed to set ACPI power state D2 on \134_SB_.PCI0.PEG_: > > AE_BAD_PARAMETER > > pci0: failed to set ACPI power state D2 on \134_SB_.PCI0.EXP1: > > AE_BAD_PARAMETER > > pci0: failed to set ACPI power state D2 on \134_SB_.PCI0.EXP2: > > AE_BAD_PARAMETER > > pci0: failed to set ACPI power state D2 on \134_SB_.PCI0.EXP3: > > AE_BAD_PARAMETER > > pci0: failed to set ACPI power state D2 on \134_SB_.PCI0.EXP5: > > AE_BAD_PARAMETER > > > > I suspect these might have something to do with the USB 3.0 system not > > working, though I don't have experience with either the ACPI or USB > > subsystems. > > > > Also, the nvidia Xorg driver fails to work, and causes a similar error > > message: > > > > ACPI Warning: \134_SB_.PCI0.PEG_.VID_._DSM: Argument #4 type mismatch - > > Found [Buffer], APCI requires [Package] (20130823/nsarguments-97) > > (the same message gets repeated about 10 times) > > > > Again, I don't have any experience with ACPI, but this looks to me like a > > vendor-specific quirk. > > > > Any advice on how to go about fixing/working around this? > > Hi Eric, > > I refer you to freebsd-mobile@ archives for May re these 'failed to set > ACPI power state D2' messages, in thread 'Thinkpad T410: resume broken'. > I'm also cross-posting this back there. I ran across those also. > These appear on the suspend path on (AFAICT) all modern Lenovos; X2xx, > T4xx and T5xx at least, though I get similar messages for the Cardbus > bridges on my old T23s. The EXPn messages at least do appear to be > harmless though they keep causing your sort of concern, and it would be > good in the long run to find out why attempts are being made to set > state D2 on devices that (should indicate that they) don't support it. > > John Baldwin (cc'd) explains in that thread that the EXPn devices are > "probably PCI-PCI bridges that represent the downstream ports of your > PCI-e root complex)" though I can't say I understand what that means .. > with verbose boot messages you may also see that these are initialised > back into D0 state twice, unlike the other devices. Whatever they do, the messages suggest that it might just be what amounts to a type error in the ACPI code (apologies for any inaccuracies; I have only cursory knowledge of ACPI, but I know there's some kind of interpreted language in there somewhere). Again, sorry for lack of knowledge, but does FreeBSD have any sort of functionality for working around these sort of vendor quirks? > > The PEG_ message seems to appear on the more recent ones with integrated > graphics. I don't know if that message represents a problem or not, > though the later warnings re \134_SB_.PCI0.PEG_.VID_._DSM seem ominous. Some poking around on google seems to show other lenovos (the T440p) having similar problems with the nvidia drivers. I suppose a worthwhile experiment might be to remove ACPI from the kernel and see if the driver works successfully. If the driver issues persist, I'm not sure what to do other than contact nvidia directly. If it does work, however, that suggests digging into the ACPI stuff on the lenovo as a possible way forward. I'd be willing to try, and again, the messages suggest it's a relatively simple programming error somewhere in the Lenovo ACPI stuff. > It would be good to know if your USB3 issues are connected to the more > generic issue all these Lenovos appear to have of USB failing entirely, > only on the external ports, after - depending on model - one or two > suspend/resume cycles. There's not even any 5V on these ports, whether > or not the BIOS has been set to provide 5V on these ports in suspend or > power-off states. Does that also happen on yours? The apparent connection to the USB issues seems likely to be a red herring at this point. The messages show up near some USB error messages, but that seems to just be "luck". I found some other threads about USB 3.0 issues, but in general, USB seems to work. There were serious issues when I first installed, but after an update and a kernel compile, they went away. I can mount a thumb drive and my phone starts charging if I plug it in. There's still an error message, but honestly, I'm more interested in getting the nvidia driver working at this point. From owner-freebsd-acpi@FreeBSD.ORG Sat Jun 21 14:54:59 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 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 803D3F2D; Sat, 21 Jun 2014 14:54:59 +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 97CA7295C; Sat, 21 Jun 2014 14:54:58 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id s5LEsmY2072724; Sun, 22 Jun 2014 00:54:49 +1000 (EST) (envelope-from smithi@nimnet.asn.au) Date: Sun, 22 Jun 2014 00:54:48 +1000 (EST) From: Ian Smith To: Eric McCorkle Subject: Re: ACPI error messages on Lenovo W540 In-Reply-To: <53A4ED85.2050904@metricspace.net> Message-ID: <20140622000435.R609@sola.nimnet.asn.au> References: <53A048B1.1080108@metricspace.net> <20140618163410.C609@sola.nimnet.asn.au> <53A4ED85.2050904@metricspace.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: freebsd-acpi@freebsd.org, freebsd-mobile@freebsd.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Jun 2014 14:54:59 -0000 On Fri, 20 Jun 2014 22:27:17 -0400, Eric McCorkle wrote: > On 06/18/2014 03:17, Ian Smith wrote: > > On Tue, 17 Jun 2014 09:54:57 -0400, Eric McCorkle wrote: > > > > > I'm trying to set up on a lenovo W540 mobile workstation I recently > > > purchased. Things work well for the most part (including > > suspend/resume), > > > however there's some error messages that I suspect are at the root of > > why the > > > nvidia Xorg driver doesn't work, and possibly also at the root of why > > USB 3.0 > > > won't work either. > > > > > > At suspend/resume, the following error messages show up: > > > > > > pci0: failed to set ACPI power state D2 on \134_SB_.PCI0.PEG_: > > > AE_BAD_PARAMETER > > > pci0: failed to set ACPI power state D2 on \134_SB_.PCI0.EXP1: > > > AE_BAD_PARAMETER > > > pci0: failed to set ACPI power state D2 on \134_SB_.PCI0.EXP2: > > > AE_BAD_PARAMETER > > > pci0: failed to set ACPI power state D2 on \134_SB_.PCI0.EXP3: > > > AE_BAD_PARAMETER > > > pci0: failed to set ACPI power state D2 on \134_SB_.PCI0.EXP5: > > > AE_BAD_PARAMETER > > > > > > I suspect these might have something to do with the USB 3.0 system not > > > working, though I don't have experience with either the ACPI or USB > > > subsystems. > > > > > > Also, the nvidia Xorg driver fails to work, and causes a similar error > > > message: > > > > > > ACPI Warning: \134_SB_.PCI0.PEG_.VID_._DSM: Argument #4 type mismatch - > > > Found [Buffer], APCI requires [Package] (20130823/nsarguments-97) > > > (the same message gets repeated about 10 times) > > > > > > Again, I don't have any experience with ACPI, but this looks to me like > > a > > > vendor-specific quirk. > > > > > > Any advice on how to go about fixing/working around this? > > > > Hi Eric, > > > > I refer you to freebsd-mobile@ archives for May re these 'failed to set > > ACPI power state D2' messages, in thread 'Thinkpad T410: resume broken'. > > I'm also cross-posting this back there. > > I ran across those also. > > > These appear on the suspend path on (AFAICT) all modern Lenovos; X2xx, > > T4xx and T5xx at least, though I get similar messages for the Cardbus > > bridges on my old T23s. The EXPn messages at least do appear to be > > harmless though they keep causing your sort of concern, and it would be > > good in the long run to find out why attempts are being made to set > > state D2 on devices that (should indicate that they) don't support it. > > > > John Baldwin (cc'd) explains in that thread that the EXPn devices are > > "probably PCI-PCI bridges that represent the downstream ports of your > > PCI-e root complex)" though I can't say I understand what that means .. > > with verbose boot messages you may also see that these are initialised > > back into D0 state twice, unlike the other devices. > > Whatever they do, the messages suggest that it might just be what amounts to > a type error in the ACPI code (apologies for any inaccuracies; I have only > cursory knowledge of ACPI, but I know there's some kind of interpreted > language in there somewhere). It's more a virtual machine than an interpreter, in the sense that Java isn't interpreted but runs precompiled bytecode, but yes, there could be a problem in the AML, derived from the source ASL .. see acpidump(8). I am (it seems) fortunate that my X200 has pre-KMS i915 graphics that work fine including suspend/resume from X or (old) console, so I can't speculate about nvidea Xorg issues. > Again, sorry for lack of knowledge, but does FreeBSD have any sort of > functionality for working around these sort of vendor quirks? If you could clearly identify the/a problem in the ASL, someone might be inspired to help fix it, though ASL-savvy people are thin on the ground; ACPI code is a non-trivial learning curve, for this old codger anyway :) > > The PEG_ message seems to appear on the more recent ones with integrated > > graphics. I don't know if that message represents a problem or not, > > though the later warnings re \134_SB_.PCI0.PEG_.VID_._DSM seem ominous. > > Some poking around on google seems to show other lenovos (the T440p) having > similar problems with the nvidia drivers. > > I suppose a worthwhile experiment might be to remove ACPI from the kernel and > see if the driver works successfully. If the driver issues persist, I'm not > sure what to do other than contact nvidia directly. You can boot without ACPI from the loader prompt already, but I'm not sure anything modern will run at all without it. I don't go there, but expect that the Xorg list might have more eyes on video driver problems. > If it does work, however, that suggests digging into the ACPI stuff on the > lenovo as a possible way forward. I'd be willing to try, and again, the > messages suggest it's a relatively simple programming error somewhere in the > Lenovo ACPI stuff. Well, disassemble your ACPI according to acpidump(8) to start hunting. The old ACPI debugging page in the Handbook has been merged into the (imho) less well-named section '12.13. Power and Resource Management', http://www.freebsd.org/doc/handbook/acpi-overview.html which may help. > > It would be good to know if your USB3 issues are connected to the more > > generic issue all these Lenovos appear to have of USB failing entirely, > > only on the external ports, after - depending on model - one or two > > suspend/resume cycles. There's not even any 5V on these ports, whether > > or not the BIOS has been set to provide 5V on these ports in suspend or > > power-off states. Does that also happen on yours? > > The apparent connection to the USB issues seems likely to be a red herring at > this point. The messages show up near some USB error messages, but that > seems to just be "luck". Mmm, and the ACPI PEG_ messages may not really be the main issue at all. > I found some other threads about USB 3.0 issues, but in general, USB seems to > work. There were serious issues when I first installed, but after an update > and a kernel compile, they went away. I can mount a thumb drive and my phone > starts charging if I plug it in. There's still an error message, but > honestly, I'm more interested in getting the nvidia driver working at this > point. Fair enough, but if you can suspend and resume more than once and still have working USB ports, that may be the first recent Lenovo that can .. cheers, Ian From owner-freebsd-acpi@FreeBSD.ORG Mon Jun 23 02:00:49 2014 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id ACD3695; Mon, 23 Jun 2014 02:00:49 +0000 (UTC) Received: from mail-in-16.arcor-online.net (mail-in-16.arcor-online.net [151.189.21.56]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mx.arcor.de", Issuer "Thawte SSL CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6BC2B2E46; Mon, 23 Jun 2014 02:00:49 +0000 (UTC) Received: from mail-in-03-z2.arcor-online.net (mail-in-03-z2.arcor-online.net [151.189.8.15]) by mx.arcor.de (Postfix) with ESMTP id 89DA98461; Mon, 23 Jun 2014 03:27:10 +0200 (CEST) Received: from mail-in-01.arcor-online.net (mail-in-01.arcor-online.net [151.189.21.41]) by mail-in-03-z2.arcor-online.net (Postfix) with ESMTP id 82478562A06; Mon, 23 Jun 2014 03:27:10 +0200 (CEST) Received: from Dell-oben.fritz.box (dyndsl-037-138-110-208.ewe-ip-backbone.de [37.138.110.208]) (Authenticated sender: hilko.meyer@arcor.de) by mail-in-01.arcor-online.net (Postfix) with ESMTPA id 6B6255AC25; Mon, 23 Jun 2014 03:27:10 +0200 (CEST) X-DKIM: Sendmail DKIM Filter v2.8.2 mail-in-01.arcor-online.net 6B6255AC25 From: Hilko Meyer To: freebsd-stable@freebsd.org Subject: powerd stopped working after update from 8.4 to 9.2 Date: Mon, 23 Jun 2014 03:27:08 +0200 Message-ID: X-Mailer: Forte Agent 1.93/32.576 English (American) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-acpi@freebsd.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jun 2014 02:00:49 -0000 Hi, powerd doesn't work anymore after the update from 8.4 to 9.2. The system has an old (more than 10 years) mainboard with Via KT133 chipset. I made a verbose boot with both, 8.4 and 9.2: 8.4: http://pastebin.com/iiZXRXgK 9.2: http://pastebin.com/sHcd3MHv The relevant part of the diff seem to be these parts: viapropm0: SMBus I/O base at 0x5000 viapropm0: SMBus I/O base at 0x5000 viapropm0: port 0x5000-0x500f at device 7.4 on pci0 -viapropm0: SMBus revision code 0x40 -smbus0: on viapropm0 -smb0: on smbus0 +viapropm0: could not allocate bus space +device_attach: viapropm0 attach returned 6 [=E2=80=A6] acpi_throttle0: on cpu0 -acpi_throttle0: P_CNT from P_BLK 0x4010 +acpi_throttle0: failed to attach P_CNT +device_attach: acpi_throttle0 attach returned 6 Any ideas what I can do? regards, Hilko PS: Maybe acpi related so I cced acpi@ From owner-freebsd-acpi@FreeBSD.ORG Mon Jun 23 15:52:12 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 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 976D98DD for ; Mon, 23 Jun 2014 15:52:12 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 71659263D for ; Mon, 23 Jun 2014 15:52:12 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 7F397B95D; Mon, 23 Jun 2014 11:52:10 -0400 (EDT) From: John Baldwin To: freebsd-acpi@freebsd.org Subject: Re: ACPI error messages on Lenovo W540 Date: Mon, 23 Jun 2014 09:53:16 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20140415; KDE/4.5.5; amd64; ; ) References: <53A048B1.1080108@metricspace.net> In-Reply-To: <53A048B1.1080108@metricspace.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201406230953.16496.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 23 Jun 2014 11:52:10 -0400 (EDT) X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jun 2014 15:52:12 -0000 On Tuesday, June 17, 2014 9:54:57 am Eric McCorkle wrote: > Hello, > > I'm trying to set up on a lenovo W540 mobile workstation I recently > purchased. Things work well for the most part (including > suspend/resume), however there's some error messages that I suspect are > at the root of why the nvidia Xorg driver doesn't work, and possibly > also at the root of why USB 3.0 won't work either. > > At suspend/resume, the following error messages show up: > > pci0: failed to set ACPI power state D2 on \134_SB_.PCI0.PEG_: > AE_BAD_PARAMETER > pci0: failed to set ACPI power state D2 on \134_SB_.PCI0.EXP1: > AE_BAD_PARAMETER > pci0: failed to set ACPI power state D2 on \134_SB_.PCI0.EXP2: > AE_BAD_PARAMETER > pci0: failed to set ACPI power state D2 on \134_SB_.PCI0.EXP3: > AE_BAD_PARAMETER > pci0: failed to set ACPI power state D2 on \134_SB_.PCI0.EXP5: > AE_BAD_PARAMETER I think these are harmless and you can ignore them. Probably these devices only support D0 (on) and D3 (off) and not D2 (low power). > I suspect these might have something to do with the USB 3.0 system not > working, though I don't have experience with either the ACPI or USB > subsystems. Does it not work in general, or does it not work after resume? > Also, the nvidia Xorg driver fails to work, and causes a similar error > message: > > ACPI Warning: \134_SB_.PCI0.PEG_.VID_._DSM: Argument #4 type mismatch - > Found [Buffer], APCI requires [Package] (20130823/nsarguments-97) > (the same message gets repeated about 10 times) That is a very different error, but it might explain nvidia driver problems. The ACPI spec explains how _DSM works (there's an example method in section 9 of the 5.0 spec which you can get from acpi.info). In this case the warning is complaining that the return type is incorrect. Of course, the spec says that this function should return a Buffer, but ACPICA seems to think it should return a Package. It would be good to track down which specific arguments were passed to _DSM and then examine the acpidump to see which path that would take. -- John Baldwin From owner-freebsd-acpi@FreeBSD.ORG Mon Jun 23 21:13:28 2014 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E0402B35; Mon, 23 Jun 2014 21:13:28 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id BABF3250E; Mon, 23 Jun 2014 21:13:28 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id AF032B972; Mon, 23 Jun 2014 17:13:27 -0400 (EDT) From: John Baldwin To: freebsd-stable@freebsd.org Subject: Re: powerd stopped working after update from 8.4 to 9.2 Date: Mon, 23 Jun 2014 16:09:53 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20140415; KDE/4.5.5; amd64; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <201406231609.53123.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 23 Jun 2014 17:13:27 -0400 (EDT) Cc: Hilko Meyer , freebsd-acpi@freebsd.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jun 2014 21:13:29 -0000 On Sunday, June 22, 2014 9:27:08 pm Hilko Meyer wrote: > Hi, >=20 > powerd doesn't work anymore after the update from 8.4 to 9.2. The system > has an old (more than 10 years) mainboard with Via KT133 chipset. >=20 > I made a verbose boot with both, 8.4 and 9.2: > 8.4: http://pastebin.com/iiZXRXgK > 9.2: http://pastebin.com/sHcd3MHv > The relevant part of the diff seem to be these parts: >=20 > viapropm0: SMBus I/O base at 0x5000 > viapropm0: SMBus I/O base at 0x5000 > viapropm0: port 0x5000-0x500f at > device 7.4 on pci0 > -viapropm0: SMBus revision code 0x40 > -smbus0: on viapropm0 > -smb0: on smbus0 > +viapropm0: could not allocate bus space > +device_attach: viapropm0 attach returned 6 > [=E2=80=A6] > acpi_throttle0: on cpu0 > -acpi_throttle0: P_CNT from P_BLK 0x4010 > +acpi_throttle0: failed to attach P_CNT > +device_attach: acpi_throttle0 attach returned 6 >=20 > Any ideas what I can do? acpi_timer0 also failed to probe due to a resource issue. Can you get the= =20 output of 'devinfo -rv' and 'devinfo -u' from the both kernels? =2D-=20 John Baldwin From owner-freebsd-acpi@FreeBSD.ORG Mon Jun 23 22:42:32 2014 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3FE27C25; Mon, 23 Jun 2014 22:42:32 +0000 (UTC) Received: from mail.metricspace.net (mail.metricspace.net [IPv6:2001:470:1f11:617::103]) by mx1.freebsd.org (Postfix) with ESMTP id 145162D92; Mon, 23 Jun 2014 22:42:32 +0000 (UTC) Received: from [172.16.1.182] (unknown [172.16.1.182]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) (Authenticated sender: eric) by mail.metricspace.net (Postfix) with ESMTPSA id E710E25077; Mon, 23 Jun 2014 22:42:30 +0000 (UTC) Message-ID: <53A8AD54.8040908@metricspace.net> Date: Mon, 23 Jun 2014 18:42:28 -0400 From: Eric McCorkle User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: John Baldwin , freebsd-acpi@freebsd.org Subject: Re: ACPI error messages on Lenovo W540 References: <53A048B1.1080108@metricspace.net> <201406230953.16496.jhb@freebsd.org> In-Reply-To: <201406230953.16496.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jun 2014 22:42:32 -0000 On 06/23/2014 09:53, John Baldwin wrote: > On Tuesday, June 17, 2014 9:54:57 am Eric McCorkle wrote: >> Hello, >> >> I'm trying to set up on a lenovo W540 mobile workstation I recently >> purchased. Things work well for the most part (including >> suspend/resume), however there's some error messages that I suspect are >> at the root of why the nvidia Xorg driver doesn't work, and possibly >> also at the root of why USB 3.0 won't work either. >> >> At suspend/resume, the following error messages show up: >> >> pci0: failed to set ACPI power state D2 on \134_SB_.PCI0.PEG_: >> AE_BAD_PARAMETER >> pci0: failed to set ACPI power state D2 on \134_SB_.PCI0.EXP1: >> AE_BAD_PARAMETER >> pci0: failed to set ACPI power state D2 on \134_SB_.PCI0.EXP2: >> AE_BAD_PARAMETER >> pci0: failed to set ACPI power state D2 on \134_SB_.PCI0.EXP3: >> AE_BAD_PARAMETER >> pci0: failed to set ACPI power state D2 on \134_SB_.PCI0.EXP5: >> AE_BAD_PARAMETER > > I think these are harmless and you can ignore them. Probably these devices > only support D0 (on) and D3 (off) and not D2 (low power). That makes sense. It'd be nice if we could quiet the messages, but that wouldn't even be a second-order concern for me at this point. > >> I suspect these might have something to do with the USB 3.0 system not >> working, though I don't have experience with either the ACPI or USB >> subsystems. > > Does it not work in general, or does it not work after resume? Actually, USB seems to be working quite well. It even detects an already plugged-in mouse during the ith resume. The sign of trouble are some messages that show up during resume: usb_alloc_device: device init 2 failed (USB_ERR_IOERROR, ignored) ugen0.2: at usbus2 (disconnected) uhub_reattach_port: could not allocate new device There had been some timeout messages, which googling seemed to implicate was a USB 3.0 issue with lenovos, but those seem to have disappeared (I did do a kernel update). Maybe I should test USB 3.0-specific features to see if they are working. Unfortunately, I'm not that familiar with the gritty details of USB. Any ideas for how to do that? > >> Also, the nvidia Xorg driver fails to work, and causes a similar error >> message: >> >> ACPI Warning: \134_SB_.PCI0.PEG_.VID_._DSM: Argument #4 type mismatch - >> Found [Buffer], APCI requires [Package] (20130823/nsarguments-97) >> (the same message gets repeated about 10 times) > > That is a very different error, but it might explain nvidia driver problems. > The ACPI spec explains how _DSM works (there's an example method in section 9 > of the 5.0 spec which you can get from acpi.info). In this case the warning > is complaining that the return type is incorrect. Of course, the spec says > that this function should return a Buffer, but ACPICA seems to think it should > return a Package. It would be good to track down which specific arguments > were passed to _DSM and then examine the acpidump to see which path that would > take. I looked at acpidump, and I was able to find the definition of _DSM. Is there a way to get better ACPI debugging info out of the kernel (aside from adding debug messages directly)? From owner-freebsd-acpi@FreeBSD.ORG Mon Jun 23 23:12:27 2014 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 476F5672; Mon, 23 Jun 2014 23:12:27 +0000 (UTC) Received: from mail-in-16.arcor-online.net (mail-in-16.arcor-online.net [151.189.21.56]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mx.arcor.de", Issuer "Thawte SSL CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 03CDA20F9; Mon, 23 Jun 2014 23:12:26 +0000 (UTC) Received: from mail-in-13-z2.arcor-online.net (mail-in-13-z2.arcor-online.net [151.189.8.30]) by mx.arcor.de (Postfix) with ESMTP id 15F2F82C9; Tue, 24 Jun 2014 01:12:24 +0200 (CEST) Received: from mail-in-18.arcor-online.net (mail-in-18.arcor-online.net [151.189.21.58]) by mail-in-13-z2.arcor-online.net (Postfix) with ESMTP id 11DE714A5E7; Tue, 24 Jun 2014 01:12:24 +0200 (CEST) X-Greylist: Passed host: 31.150.165.247 X-DKIM: Sendmail DKIM Filter v2.8.2 mail-in-18.arcor-online.net CFE623DC31C X-Greylist: Passed host: 31.150.165.247 X-Greylist: Passed host: 31.150.165.247 Received: from Dell-oben.fritz.box (dyndsl-031-150-165-247.ewe-ip-backbone.de [31.150.165.247]) (Authenticated sender: hilko.meyer@arcor.de) by mail-in-18.arcor-online.net (Postfix) with ESMTPA id CFE623DC31C; Tue, 24 Jun 2014 01:12:23 +0200 (CEST) From: Hilko Meyer To: John Baldwin Subject: Re: powerd stopped working after update from 8.4 to 9.2 Date: Tue, 24 Jun 2014 01:12:23 +0200 Message-ID: <1mchq919q3su1ji3sgaamjugv2jdu5bbgs@mail.arcor.de> References: <201406231609.53123.jhb@freebsd.org> In-Reply-To: <201406231609.53123.jhb@freebsd.org> X-Mailer: Forte Agent 1.93/32.576 English (American) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-acpi@freebsd.org, freebsd-stable@freebsd.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jun 2014 23:12:27 -0000 John Baldwin wrote: >On Sunday, June 22, 2014 9:27:08 pm Hilko Meyer wrote: >> Hi, >>=20 >> powerd doesn't work anymore after the update from 8.4 to 9.2. The = system >> has an old (more than 10 years) mainboard with Via KT133 chipset. >>=20 >> I made a verbose boot with both, 8.4 and 9.2: >> 8.4: http://pastebin.com/iiZXRXgK >> 9.2: http://pastebin.com/sHcd3MHv >> The relevant part of the diff seem to be these parts: >>=20 >> viapropm0: SMBus I/O base at 0x5000 >> viapropm0: SMBus I/O base at 0x5000 >> viapropm0: port 0x5000-0x500f = at >> device 7.4 on pci0 >> -viapropm0: SMBus revision code 0x40 >> -smbus0: on viapropm0 >> -smb0: on smbus0 >> +viapropm0: could not allocate bus space >> +device_attach: viapropm0 attach returned 6 >> [=E2=80=A6] >> acpi_throttle0: on cpu0 >> -acpi_throttle0: P_CNT from P_BLK 0x4010 >> +acpi_throttle0: failed to attach P_CNT >> +device_attach: acpi_throttle0 attach returned 6 >>=20 >> Any ideas what I can do? > >acpi_timer0 also failed to probe due to a resource issue. Can you get = the=20 >output of 'devinfo -rv' and 'devinfo -u' from the both kernels? Yes, no problem. devinfo -rv: 8.4: http://pastebin.com/6xm1tBrU 9.2: http://pastebin.com/whXk32Ab devinfo -u: 8.4: http://pastebin.com/47U7HZb3 9.2: http://pastebin.com/U85HTw0C thanks for your help, Hilko From owner-freebsd-acpi@FreeBSD.ORG Tue Jun 24 14:27:30 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 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 08437907 for ; Tue, 24 Jun 2014 14:27:30 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C9D312FB0 for ; Tue, 24 Jun 2014 14:27:29 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id D44A6B94A; Tue, 24 Jun 2014 10:27:28 -0400 (EDT) From: John Baldwin To: Eric McCorkle Subject: Re: ACPI error messages on Lenovo W540 Date: Tue, 24 Jun 2014 10:00:35 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20140415; KDE/4.5.5; amd64; ; ) References: <53A048B1.1080108@metricspace.net> <201406230953.16496.jhb@freebsd.org> <53A8AD54.8040908@metricspace.net> In-Reply-To: <53A8AD54.8040908@metricspace.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201406241000.35812.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 24 Jun 2014 10:27:28 -0400 (EDT) Cc: freebsd-acpi@freebsd.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jun 2014 14:27:30 -0000 On Monday, June 23, 2014 6:42:28 pm Eric McCorkle wrote: > On 06/23/2014 09:53, John Baldwin wrote: > > On Tuesday, June 17, 2014 9:54:57 am Eric McCorkle wrote: > >> I suspect these might have something to do with the USB 3.0 system not > >> working, though I don't have experience with either the ACPI or USB > >> subsystems. > > > > Does it not work in general, or does it not work after resume? > > Actually, USB seems to be working quite well. It even detects an > already plugged-in mouse during the ith resume. > > The sign of trouble are some messages that show up during resume: > > usb_alloc_device: device init 2 failed (USB_ERR_IOERROR, ignored) > ugen0.2: at usbus2 (disconnected) > uhub_reattach_port: could not allocate new device > > There had been some timeout messages, which googling seemed to implicate > was a USB 3.0 issue with lenovos, but those seem to have disappeared (I > did do a kernel update). > > Maybe I should test USB 3.0-specific features to see if they are > working. Unfortunately, I'm not that familiar with the gritty details > of USB. Any ideas for how to do that? There was a recent fix to acpi_pwrres.c that fixed USB issues on resume for several ThinkPads because the kernel wasn't properly turning certain things back on during resume, so if your problems were only with resume, then there's a good chance they should now be fixed (and it sounds like they did after you updated). > > > >> Also, the nvidia Xorg driver fails to work, and causes a similar error > >> message: > >> > >> ACPI Warning: \134_SB_.PCI0.PEG_.VID_._DSM: Argument #4 type mismatch - > >> Found [Buffer], APCI requires [Package] (20130823/nsarguments-97) > >> (the same message gets repeated about 10 times) > > > > That is a very different error, but it might explain nvidia driver problems. > > The ACPI spec explains how _DSM works (there's an example method in section 9 > > of the 5.0 spec which you can get from acpi.info). In this case the warning > > is complaining that the return type is incorrect. Of course, the spec says > > that this function should return a Buffer, but ACPICA seems to think it should > > return a Package. It would be good to track down which specific arguments > > were passed to _DSM and then examine the acpidump to see which path that would > > take. > > I looked at acpidump, and I was able to find the definition of _DSM. Is > there a way to get better ACPI debugging info out of the kernel (aside > from adding debug messages directly)? Probably not in this case, though just looking at the source of the _DSM method might be a start. However, re-reading this warning (and checking the source), the problem is not in the _DSM method, but in some code calling the _DSM method. Are there any calls to _DSM in your acpidump? Ah, the nvidia driver calls _DSM and it has the bug. In its nvidia_acpi.c file it uses a Buffer instead of a Package for the fourth argument to _DSM. OTOH, the warning doesn't prevent the method from running, so the warning may be harmless. You can try contacting the nvidia folks to tell them about the warning and point out the bug in their _DSM wrapper in nvidia_acpi.c to see what they say. -- John Baldwin From owner-freebsd-acpi@FreeBSD.ORG Tue Jun 24 14:27:31 2014 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0E1579BB; Tue, 24 Jun 2014 14:27:31 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D54D12FB1; Tue, 24 Jun 2014 14:27:30 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id DAFD6B97B; Tue, 24 Jun 2014 10:27:29 -0400 (EDT) From: John Baldwin To: Hilko Meyer Subject: Re: powerd stopped working after update from 8.4 to 9.2 Date: Tue, 24 Jun 2014 10:26:52 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20140415; KDE/4.5.5; amd64; ; ) References: <201406231609.53123.jhb@freebsd.org> <1mchq919q3su1ji3sgaamjugv2jdu5bbgs@mail.arcor.de> In-Reply-To: <1mchq919q3su1ji3sgaamjugv2jdu5bbgs@mail.arcor.de> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <201406241026.52678.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 24 Jun 2014 10:27:29 -0400 (EDT) Cc: freebsd-acpi@freebsd.org, freebsd-stable@freebsd.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jun 2014 14:27:31 -0000 On Monday, June 23, 2014 7:12:23 pm Hilko Meyer wrote: > John Baldwin wrote: > >On Sunday, June 22, 2014 9:27:08 pm Hilko Meyer wrote: > >> Hi, > >>=20 > >> powerd doesn't work anymore after the update from 8.4 to 9.2. The syst= em > >> has an old (more than 10 years) mainboard with Via KT133 chipset. > >>=20 > >> I made a verbose boot with both, 8.4 and 9.2: > >> 8.4: http://pastebin.com/iiZXRXgK > >> 9.2: http://pastebin.com/sHcd3MHv > >> The relevant part of the diff seem to be these parts: > >>=20 > >> viapropm0: SMBus I/O base at 0x5000 > >> viapropm0: SMBus I/O base at 0x5000 > >> viapropm0: port 0x5000-0x500f at > >> device 7.4 on pci0 > >> -viapropm0: SMBus revision code 0x40 > >> -smbus0: on viapropm0 > >> -smb0: on smbus0 > >> +viapropm0: could not allocate bus space > >> +device_attach: viapropm0 attach returned 6 > >> [=E2=80=A6] > >> acpi_throttle0: on cpu0 > >> -acpi_throttle0: P_CNT from P_BLK 0x4010 > >> +acpi_throttle0: failed to attach P_CNT > >> +device_attach: acpi_throttle0 attach returned 6 > >>=20 > >> Any ideas what I can do? > > > >acpi_timer0 also failed to probe due to a resource issue. Can you get th= e=20 > >output of 'devinfo -rv' and 'devinfo -u' from the both kernels? >=20 > Yes, no problem. > devinfo -rv: > 8.4: http://pastebin.com/6xm1tBrU > 9.2: http://pastebin.com/whXk32Ab >=20 > devinfo -u: > 8.4: http://pastebin.com/47U7HZb3 > 9.2: http://pastebin.com/U85HTw0C >=20 > thanks for your help, > Hilko Can you provide your acpidump? This box seems confusing. =2D-=20 John Baldwin From owner-freebsd-acpi@FreeBSD.ORG Tue Jun 24 17:41:27 2014 Return-Path: Delivered-To: freebsd-acpi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B8DEBBE6 for ; Tue, 24 Jun 2014 17:41:27 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (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 9FBBF256C for ; Tue, 24 Jun 2014 17:41:27 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.8/8.14.8) with ESMTP id s5OHfRpc017048 for ; Tue, 24 Jun 2014 18:41:27 +0100 (BST) (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-acpi@FreeBSD.org Subject: [Bug 169862] [acpi] Prevent system sleep once shutdown has been initiated Date: Tue, 24 Jun 2014 17:41:27 +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: jkim@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: 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 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jun 2014 17:41:27 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=169862 Jung-uk Kim changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|jkim@FreeBSD.org |freebsd-acpi@FreeBSD.org --- Comment #2 from Jung-uk Kim --- Apparently, I don't have time for this. Sorry. -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-acpi@FreeBSD.ORG Tue Jun 24 17:46:21 2014 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4533FDF2; Tue, 24 Jun 2014 17:46:21 +0000 (UTC) Received: from kirk.hochpass.uni-hannover.de (kirk.hochpass.uni-hannover.de [130.75.81.215]) (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 731C625B9; Tue, 24 Jun 2014 17:46:20 +0000 (UTC) Received: from SOLO.hochpass.uni-hannover.de (solo.hochpass.uni-hannover.de [130.75.81.216]) by kirk.hochpass.uni-hannover.de (8.14.7/8.14.7) with SMTP id s5OHafCt016481; Tue, 24 Jun 2014 19:36:41 +0200 (CEST) (envelope-from hilko.meyer@gmx.de) From: Hilko Meyer To: John Baldwin Subject: Re: powerd stopped working after update from 8.4 to 9.2 Date: Tue, 24 Jun 2014 19:36:41 +0200 Message-ID: <6hcjq9540905oeibsjnf8ogee7sqfcdoej@4ax.com> References: <201406231609.53123.jhb@freebsd.org> <1mchq919q3su1ji3sgaamjugv2jdu5bbgs@mail.arcor.de> <201406241026.52678.jhb@freebsd.org> In-Reply-To: <201406241026.52678.jhb@freebsd.org> X-Mailer: Forte Agent 1.93/32.576 English (American) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--=_9pdjq9po3g121o3fdnah564pc90cdk0bhu.MFSBCHJLHS" Cc: freebsd-acpi@freebsd.org, freebsd-stable@freebsd.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jun 2014 17:46:21 -0000 ----=_9pdjq9po3g121o3fdnah564pc90cdk0bhu.MFSBCHJLHS Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit On Tue, 24 Jun 2014 10:26:52 -0400, you wrote: >On Monday, June 23, 2014 7:12:23 pm Hilko Meyer wrote: >> John Baldwin wrote: >> >On Sunday, June 22, 2014 9:27:08 pm Hilko Meyer wrote: >> >> >> >> powerd doesn't work anymore after the update from 8.4 to 9.2. The system >> >> has an old (more than 10 years) mainboard with Via KT133 chipset. >> >> >> >> I made a verbose boot with both, 8.4 and 9.2: >> >> 8.4: http://pastebin.com/iiZXRXgK >> >> 9.2: http://pastebin.com/sHcd3MHv >> >> The relevant part of the diff seem to be these parts: >> >> >> >> viapropm0: SMBus I/O base at 0x5000 >> >> viapropm0: SMBus I/O base at 0x5000 >> >> viapropm0: port 0x5000-0x500f at >> >> device 7.4 on pci0 >> >> -viapropm0: SMBus revision code 0x40 >> >> -smbus0: on viapropm0 >> >> -smb0: on smbus0 >> >> +viapropm0: could not allocate bus space >> >> +device_attach: viapropm0 attach returned 6 >> >> […] >> >> acpi_throttle0: on cpu0 >> >> -acpi_throttle0: P_CNT from P_BLK 0x4010 >> >> +acpi_throttle0: failed to attach P_CNT >> >> +device_attach: acpi_throttle0 attach returned 6 >> >> >> >> Any ideas what I can do? >> > >> >acpi_timer0 also failed to probe due to a resource issue. Can you get the >> >output of 'devinfo -rv' and 'devinfo -u' from the both kernels? >> >> Yes, no problem. >> devinfo -rv: >> 8.4: http://pastebin.com/6xm1tBrU >> 9.2: http://pastebin.com/whXk32Ab >> >> devinfo -u: >> 8.4: http://pastebin.com/47U7HZb3 >> 9.2: http://pastebin.com/U85HTw0C >> >> thanks for your help, >> Hilko > >Can you provide your acpidump? This box seems confusing. Well, its quite old. An Epox 8kta3 from around 2002. I was not sure which output you need so I attached acpidump -d and acpidump -dt. regards, Hilko ----=_9pdjq9po3g121o3fdnah564pc90cdk0bhu.MFSBCHJLHS Content-Type: application/octet-stream; name=acpidump-d.gz Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=acpidump-d.gz H4sICB+1qVMCA2FjcGlkdW1wLWQA7T1pc9rItt/zK1T5FG4xjloSIN9vQouHFzAE4Thza6pcBMs2 NTb4Ac5NXir//fUigZC6Wy212Gy5ajyxejtbn3P6nF4+/uud8i+lM1sFj4plDzqKPX96ns+C2Uqx FpOH6SqYrF4WAapk9bqKM12Ol8vg6dtjsFC+B4vldD5TNBUAtaG1/tA1VM+eP/9cTO8fVsqHSQ0W qqryB64TDmPPF8/zxXgFm6Lq6L9Ntz+V+Z3ycfX0/HE8eZ7evjw9nzWH366/XdeV0Uug/M8LHM5Q wPm/NePfQEXdGrAD1EcfjjmdjR+V0RhCp/wZjG+Dxb9RCfrxp/ezMcJECX/eO74zeh8Vd4PZ/epB 2fyoPyDcqma7TeUDAMa5UYuqDoPvU4x2rCpQ/gV/FF3749t0pawwAB++gFpdmc2VpoG/Po3hAMuX Z4j7KurLfggm/yxfnmJ9tVtRYd/tKR0nBtP7Lx2reW68j1cgyIbV3lvXQwdxcavKFsAEL4CY8sFQ z5trtBDfp4ir0ZDve763IdC6+EvIdIQ16kq1IYGarVZL00zU2cd375zgbjqbIv62H+eTf5QP77cZ On56fF8PGVBXQH2NWD2GQT0Gau3dr3eYiZP5MyTs3zeDYQ1/IJ/Rz2AxnwTL5XxBis/swZWKuwBR RwbsCv+7WVN+/cYNf7/D/7scP+FefVg+GE/+Gd/DP2FFIznIf4LFvK7k+JOMUtseBWSMgr7F+sn+ kzqKkT2Ktt1Pxp/UURq7HKX/HBA1MQzukch9+Ntx2xd1xf+5XAVPnT7iphlymbTwpsHj7bpe++cq sCaTunI570I5hKAugmWw+B4koXTaF5ApimLGpSI1uvt11IsG7wVP88XPULQ8z9QxGEDdAoM0uJ4v boWgGPZ7GArQjNFk2PMpH/s9jVZTo9XUaTXTH62e20MfdY1PhK493OaAajiEB9o28riiMAtgdcKC GEjwm5bNlr/90ZW/DZKh6lSxIDWFYbq48UcC4193hp+T42sWbXxSU3h8WHsogn+vY6fG96j445rC 4/v2AA2fMf7FoN9ODm/YRDK2hicVxak/UFUspTGJgN8A5ZtG+aZTvhmUbw3KtyblW4vyzaR8O09/ AxQ8AAUPQMEDUPAAFDwABQ9AwQNQ8AAUPAAFD42Ch0bBQ6PgoVHw0Ch4aBQ8NAoeGgUPjYKHRsFD p+Dx9Sv+lnYL+r7Xjc+lXrB6mENp9kdDKOQakuOVHyym48fp/wW3qSl8p3zowhru/75Az/SDD+v0 4Sdrca9C5zD2J6jVautWm/bE4YR+6wzbV3VTJwQSq+7b21TXxPOBM2z8GGtEUGpfeZAC7Ze7O+jP fQjrQJ+IUg/w6/mrOfSo8ZiwIuyWVgRwEdgUXT9MkX+cBG4bayeYLIIntA5JVaQQ1gkWwR1CvzO7 DX5EKIYNITmS5Vt9oR+Ca9Sgtj3Yr1T1iCfIyduu+5vGoah6fxaqOZYyHY7s3rYybdGMK6kmrErt XucyaVztnmOljAumTjgGaUSqCY8U/fTv7pbBCsusV4uN6v95JWJSL4YWzdUy1NCsq9uOVlhfAkqg xqH0uhdqkl7pNm1rCzPYKBuzzqXXZ/mQBs1nIQ2EMfvUdjpJ5QaF5Tr5beAjD2H7W2eINJ2ixF1y p+O7yXo+ZGJKWaYwbbvuYFuSm4CCH6km7pKAtoBLYvcvR0mXhOKQkGris+hylJIK+A1Qvmmpb6Nh NyUda1My+DTE62CuKQkVKqZAUiOGZVAmoalEY1GKGtCyItAoRchZohYRxY5H09L6+2IRjFdr06AR SWaasf4iBJ6MB/+5rTg3gHqeFw6qb1ehD6ynBqbP9qRF0ZOKe+tPa3a7htezefCq7jHAm6ytUV2F EGgiPzGkEhL5981g5GeLJGIpERFII5UpltFoaJldY7lGUT9qgylBrBZGbR3R2eLe4NoGEfvQv2sp eYxqoBVEukbeTkCyRozw+bGNE7cRERdQZZAU1dGCjT14cmTAHBnjfWENCd5OXUH/rlGraBH1aD5a f7HhPeku3VGIAVlq01CM5tCGdhG2QpMoQSE0To1ViQ1EYq4hxMjinASg0L/FCd+oJQOQm2l3bX0S tgSQN15yUmWIbBwe4hZwVTaEYnr3Ewf62meD62E77opunN0Qi3V01u8kIY4QvOn5Fyz80sMn1EdS xGJ0XvfvIw6K9k/ljp5WJqzpk10PLw9S9TLxohH1YuAyqdpFUQxVEOvL+fyZS8MuimGI9xYXEbuj nl35bTUtJ7RhTIlhBCWxnQr1Bt+nkwDNkWGbORhe/d782YGqz50uxx0I7vvB5UC1Vft9QuNsJG9k 8dDhLyMhLm2BZWQEfM/tFYAdMGG3h35+2OOxhGGwnL8sJsEoeHp+hK6O8iGtZNM9EBjQIkjXvOmP AC1sg/Ht9WK6CurU2usMlocyOvX1t48fURAE+u1LpT1eBvy2aBlJb0uygMzWN3+poFYqFsZhsNDK xcI8DBZ6uVjYh8HCKBULVWJeALU4Fmp5WMDVn3cILI6GD9YxYABkMFAlJKlRoiS5rhQWoDQ+/E5/ snFMwEHZ4SgUhk0p9nCggT9DVvkMTa2zm7YF7bNl93oS3YCwm2HPAnLddN1L2I3vy3SjbaDR5LqJ oJHpRt9Ao8t1E0Ej042xgcaQ6yaCRqabRtgN2sxAWTm/fFstxpMVXPDg/QNx1UFvkQiEkE0PZJ0k 6DKGyyckyCwBwtUepnerbnC3igaBsJn0QAVjYUafKsm+8QaN/H1T58/W6p64VXTRTgQk6ITVChNW Y82FNGG1YoTVRAirFSOslkFYOyKsXpCwemHC6qxpnSasXoywughh9WKE1TMIu3G/6EqHQtwo0YC1 B93ERYvk7fxy5iIZRQlyr5ItVU+uksO6ljMMo2WUUkgaJxmRoG+WsYajugJBu7Hns7vpfXoL25ow YQwjaxkepUDX8RcyREZWK1tmScA2yljRqU4LjVIwtlIYm2VjbJWDsVYGxpdtNAO2MU4mrhO4kCaC GPxiOp6b3HSjVaPkrl3LcVh57XQfzXNaH8Ov/YF4H6ZJ68O6ME1WH7DsPM2FBM1Li7p5NaFhDhgg Qx5a+2V5+fL0DWUQo46gaC1fnoJFXelNZxAsvC6Cf4x/bP4YzJdOMJnfZi5W61vf4ELnYjGevTyO 4QLrZ96mw/HsPkBATZ9enriNPY/VePwjszFl5BEEevmIp2IogbweAKWHjHVdvc5YYnf6aAcSojRo cmlte2ZxgnEaZxMM1BPf0HL2cXo/QyljXkOT0rBQHAIJMiJUJMGDxfz2ZRJK8EZ8U7KruLPVdBFg TI9SkG2vdUhBpolFtiDXldHP58BfwVEmp8cvR4JfundQxaPrhRRPNr9ElZAhI+y8xrtTQqZalhIS J5IpQyTzpIl0xDPfADLCe9iZT/aJHXDmN2RmfuMgMx+8BaFuqECCLwcWas89rFA3ZYS6eeLm7IiF uiljQb3DCvW519qNUON8C0ll0pgWYxCNf/Z48hCg894onlA0Dy28IkqnocWX9mp7m4M5uZcaOZ9K UlUt1YMI98L0LoY0Opzxmjhqy3DUqTh6dBylbNIQ17Cud0COhnt88nL05i90NjcvV/PuvsBJhSj/ 3Ty7wQfhRvm3XyT7wXn0UZ/WDz7CuUmhR2k0+qCbpHuckKguq3teCo2W7BrgLNXmYgfNzgp2U26B yI5tY1RNIobMCoyiDYW7l58sTvu0OMDK+4MfiMDfPl74NRH47eOFXxeB3zkg/OclyH/7eOEHxy4/ 5yXI/xHLj37s+tMqQf7t44UfHLv8WCXI/xHLj37s+rNdgvw7xws/OHb5aZcg/0csP/qx60/7xPW/ feL63z5x/W+fuP53Tlz/Oyeu/50T1/9Opf8r/V/p/0r/V/q/0v8nqP/dE49/uieu/90T1//uict/ 68TzX60Tz3+1Tjz/1Trx/Bc4cfkHJy7/4MTlH+xd/rc3UNQS13CS08dfRmZT7IDg5mSx2lJV2k06 6ftth+6X1AlT6pla9BPddosbSZ+Shb1csk7JZkM+wC8gbEOOLqbFF++lN7pQTwSzYUudDEZcOBuI vLogNgCW1M7QyjoAO+i07ew6Q4dOyLSQiZLXb7cYR49NkykYpJG0YKyBWh/+NaiHf6Of5FXT8R/3 ym8nr53OGOu8Jly3obLqel1yKToLru6AX04ZC7DH6uDXPQzmWPzyK5BRrvHL07CaDRas7kC3efxw L/nllLGatXzH7CPFiq6XLKRYKbeCrHe7XW8/Y6TlMEDnHNMjshORf4EEmwigEBH0V0SEjuMWkwTA AmDoXngsK7q+CwBWYr37kU0r6lWyWi2vDdp6XANBXSvRiCTM55em2UzaFK+Z4WxQ+5A2MV9cdA+D oO8RMayNx1ZlGBbe3x7yjUCBjnnm5lvqHZBsjmH1+si4qy57pPQDJbmEg8yLUaeXeBrPFqVfhl/P R0L90eJ5UOqPtsEt9lRusaqbBp00tBVKCdhofHh0wC1uNrjFllkcFzM/LqrGpy0fF1U94uL90tHI kFF+sSZVDHbKw+J0bBbQFHxojHP+1Gtyi9FrY7xTyvzOgYSWaZzazNwvqny2Zc0tSULtF9Wd6rws RbBXM7lblajuFxftSFVsEVPVkJptx2zJ9mqqVL41OUalJr6IH/Wc2OOSyPhtPxkZ/aRPTpKWROgH nb6aqw0kitOz8rUx8TggVxsbj5OrDbrcw/7z0hMJ7HsXWnKtTZ6u01R2YB83cjLemS4SwFWZAVzf H4x4AW6/xy8fZLQfZLRPwwpUNqzkzUmW/vHtdmbwklcO+3e5/ff442cFw2F7bv+DDPwGkvgNMvAb SOI3iPATD0hcYPFI38Ybr4E6zaiR1YefOYqfOYqfOUrb9lk1olAnVB+q6DTm31ecCmdeoDfqs6Nj YtEm2JnygcxdwlUiG2S2Ezki0opkssaKS/EB9hHAuiTAW+9bIkVdy6pKsEKCJ1AVIYokUKQq7vVK oFdMRCSTAlUxAL4IAJgdSEqzq2I9gsSVUxUJQGZPF6GECKByEYmRK1KVyJ1Ar6FAigAQSa0rUpWI uUCveNLjWZBnEkT6wBl+UfOKvJheSOgGT1Q3ZLsVGx3hkbviEzqCyARbL7DD49nEApLEAocmFkio T1+CWALki9kdUNDugL3bHeJzEm+J+FzESyX+GfEC/ZOzO7643fHF7Y4vbnd8cbvji9sdX9zu+CXb HV/c7vjidscXtzu+uN3xxe2OL253/Ldsd7SEjqjsDodYekJ97tjuREhhnBpwvNz5+lDON/EntVWU FgT99dsdqd8W/u16bELQH5M+ZlAZTyeR4BbavxHGnGJvcMPfvb7j5mmoRQ2vYMv8IzaQCP5p5R8R NrxiNsRPZ2+egQ4JwnjyaGsfzywaRQ8nbep99VzOgfqjrfIwTFVl48TQUAh6tHcoL4CoHdpOA01t UUkNAXeCRXDXh911ZrfBj/TfZMcJpKJVg9SEsGq1rP2d6IctT2zFhH6YG2yyEQppadS4tX5lgp6X MHouwmQTh0+gTCLtBkltr0gyZguOM0MFjbqOAvLsYUrbwRXSqjdeTR44JAKIND33M6YTVEC90TCD VBvTUOM/ABchTjYuCTPtvLbulwsHqsaj47u9UUWYIoQaKHEkTA1TgBoYWLYNnc8m0KTN8LNRkRmM rBr+PyMHGTlzrDpcBwwudlsSDlh/FixZaTxaNSBQjZ7go1XLelqTnZKLVDreVKv8Kn0/JnvNX6LA q/kFvsmlmLC0q7VNhzyVjau0st+dbAlwPaqYKWy7VhpHTUMgSkNQe1s+I0a9cRivsXn8XmMWeV6J 3yiHJsdzzAu6sZ79jUzg2aoxclaQkYsW22yDx18mGic05RvVlGdN+cbbmPKNVz/lgeCUNwpMeb6b ylkw+GE6r9gJq2Pztolvx86kbVdj5mgyFaFALBBtFhXK04VVmVmgsgMTJEgqCprOB41tf1BwdWPF itIxy/XHU7DXdclyo/QoygEsYnsTdxDSiHxGRsplva1Oz0o078yGRqcxw0XLmn/l2BuiN7P4mWEA IlD5Oevd2MFmTr6L8f7ozH1jR2iKz4BWsRlQmhpGAoYAitJQKPxRV1AIDFFm6yMJKtRkHFec4+oG yyXkCdaQ0UDr2Ug+Zw2VTxpwl+y4joiXJmVvjL3YG/Am7Y1f2Zs3a2/8t2Fv/DLsjR+zN/5x2RtA szdgB/YG0O0NKN/eAF4MvGR7g5HMshRY3HoXLrGDuZISsW0sajmpCSA4CwS2PUWJTPbO1vzkAa+Q PNS9okI3ZX0ZWXah+5EMgZOKg2s7dY+fwdqzWMI9fpZ9hocs7xq/axvku35PgOTWldMpRPKG0I1X 6KZTwe7/7Dh1xZ0uxx1IyPeDy4Fqq977GvP6r6uOk3nzlT+yil+khGczuTuRXMzDm3jx7XUxr6v4 hUt4W8p+blzCvrD8FtibAb5lqiC1CVfbV14bvUNM3jAeBU/Pj3gTSe6EzvAz5EPwPXisK9ZkNf0e dOf/rSv+w3iB3jzOsL6grteNeqPerLfqQK0DUAdaHRh10GBYS/5uFoRUrtD0jdPxS5Jb1avj+z/z jW+fDCdv/uLtQcZd5+JZajMuwWP77ub1E8mts5vO5agOgWyDXP2RXf2wmSYQrudt601XNGo5tBnL pD9M71bD6f3Damsbs8FvhXUgFJm4GgQF1SBlHUu6ahWPD6wfoY51Z/K3kW8RpBvcrfCWrcRmNuPw a3w+mXMsK2h4Ar4IlpF5jDajsydSsrLBmz4ZucL8CtlHChEUVIgpHbDesw9yqY7N9Ztc1bFhIaq0 JeWcTaKR04LgEVpjxFSOqBZZI83r/vph+hgwglgF9Mhssgiegtl61nOkqxC4vJVythFOMExc1yKW ke6jNiwrL+alt3fspWs79tLRgUtC6MpL34eXbr1GL93av5dO5NbDSSPaEdfde+nWfrx0c9deupXw 0ttrL91ce+kWyNVfZGqtfXvpCW1W+duVv70rf9vK429bhf1t63j8bauYv22J+NtWAX/bqvzt0vzt LHO6cZ1RzY3rTDe9Yq6zvWPXWd+L61wFuPflOtuv0XW2D+U6k7X1YVxnez+u8/muXWc74Trba9f5 fO062yBXf5HVtA/jOlcB7srhPlKH287jcNuFHW77eBxuu5jDbYs43HYBh9uuHO6SHW62EZYMcJfn pTs79tKNXW9DcSovfZ9euvMavXTnANtQnFgGzDmEl+7sx0u3du2lOwkv3Vl76dbaS3dArv4iU+vs fRuKU3nplZd+xF66k8dLdwp76c7xeOlOMS/dEfHSnQJeulN56eVtQ8kwwpJeOuo+tg3FyemlR+K9 sW7QnHWyLH+a2Egh+aOhjXrqw4nyvjedLObLOUTpejq7nf93Cf14miGmKkH23Q/8MZTL0XuJyxPQ QVXf6+7tRgQt33hCyy3/L38osdzSiu36D2tgp1HE4WMwuI+Oy0zmtwFo1rnHctCVfPGfjx+V4Xh2 Hyi96Wz69PJUsPH4R1ZjUE98g42tx+n9DCkY3queKqVhN5jdrx7YFz1KEknTJIjEbrxDIrn7J5Jh SBCJ3XiHRLL3T6SmjCQ1DyBJqnYAIjVkiNQ4AJHa+ydSS2a6tQ4w3dQDTLdzIEEkduMdEknfP5Es GZ1kvRHr5sr4Se7b8JMMR4JInMbHbt1+C50iHnSK77GCP5zlxN4WC5rMJNDUt+G9WDJEsk6bSMPP l3PvcXy/5L0K9kv7XXAKpW/hzDGHtF3OIQiZ8sGePz2PV9Nv08fp6id6jHvZGy9XwaKujBbj2fIu WJi8dNkv47ek6Kkyoqe+kcW8KUMk8xBEAgdwnGVWF+dvZHVhy0iSfQBJ0tT9uTujXvHoKTgOd8eQ 4a9xCEtu7NmSq0Ut+XBU3BluH4d0tGSkoyUhHcapSIdZVDr8wafiysM8DvFoyoSemocIPYH9GQe7 P5DJrRnHwGBPZv57p+1si81/oOdVAKn77vxBp19X/J9wGfWE/oUipJ5Ku4wh3NdBGgheV0fJvl86 X/H1dJRrBB0L7YBNXl2XwADfTRjCQjojzQpDtCbN3d0yWKFst6vSLjm0h8SjNOllgFOmccp0TpnB KWtwypqcshanzOSUnXPKLE5Zm1Nmc8ocTpnLKfPYZQ6Hfw6Hfw6Hfw6Hfw6Hfw6Hfw6Hfw6Hf46Z OXuiTTTupXeRf+vM5jnC+CbTLyOzeeZe6nZNaOSvEiP/J1jM8w8dGUXPsdXCRrFF93rK2b2f2Iya RHCg2/iiYJn9+eqO9wohieIZq5CDRBtm3Qu+eXoamyKgil0Nn9zPq2ZuNOVvMkWyysMpQWJvz1tr NyTV+fvveDQqazOuCK0S9Dr0q80FQC79wYb0lx0dtODNT+G5mZiXrie0+TZqYDMP67E4sftjH14p xz6E1jTh6kIvvK7J7iBjbRN2YBZa34SNm/nXOOx1TgHitWSJ15IjHpAhHiideEILRSy9TbZyKiO5 xko8UtakSb2KpqHQ3A+ds8GeIhC6TARCl4lAmEVDTM29J2mKz0ip2XjwOFyOMA1j5pWS0s5O9W+v UnZzNAid8el3+3mPBqEzVP0/O7xm1/PFbaIZwAeRPqs5RwMG7831nbpHYk9i2FnXoCASZzhc9FNB +cD2bCGvDnFO4EhV6qxQM/usUATL1oE+YR+TcfLPm85u/YBQpz3FB84+i5yTL+doF9SlW0e7Cj3f GkGQiA943c5QEGfy8tyrwNmxJGdrf0GNMchOVvZaRiBEdWUNi2/AaqjgkC+hVEEsrloVeQ/vTQex WlUQqwpiFQ9iHSqG5F2BA8SQTNkwiHnAGJJZLAxy8xfr6p/kYgzWtDN0gVHgppXYYoSwfWPjkOFe 37TSPrvpdS7hKgX+Lqs/6yvqz/paRn/2+iaYz1LLoVYu15yn3De2EqtyWy2ystBEx8AmVfcE1lKx MYSWUpKrF7bApCqyJIFnD8JOEp7ZFegMRS/RALn5srmqgyVr6zAgFNk9hgH91XixcoLnYHYLVZY3 u5wPFtNKb+9Ab5cSvjbyPAN8CN5qsrzV3ixv9WPnre7Kzlu3mrfHOm9leau51bwVCcfMbmOcpa7U XnniQj2Xd7lzhvLbp5mBcE87A9F6axkItIQoNRqfdaPc3qLx2o6j8VoVjS8hGu/mjsbrpkw03ix+ r2tqPmSEuxORkfXtmKcVJfcOHCXfkF2QfnI0FAMqDy3zZR2yaSpE152jocqi8Xu/yaqcuTS1VqVS 8qVStL2nUt5m2ObmL54KSaRS3ILLQPFUhZZIVWjrVIVTKJXC7y9/KoXdn1tSKsWsUimvIZWiHU0q RatSKVUqpUqlVCHZKpVSzdsqlVKlUqpUilwqpVWlUg6QSjHfXCpFKzuVYh5DKqUzTJ7XyJNKAa/0 7g0J7eXmUgNZ6Q7Gi6BmbqzxuHbywV2QL8kCXveRh5zgOfJR5KIJuAxAi+QCdxbQjosw7MgNDzvV Sk46bgk4cgrYCjOLhGL2gTVtq2D8KwrGe6LBeKDuNxiP7PY62O3JB+NT/UkG4+P9AbUKxlfB+CoY XwXjq6BeZZOrYHwVjK+C8VUwvgrGV8H4KhhfBeOrYPw6GN8djARvGRp0+j10K93dHeIT/fYgOmsQ L0U0YUoZkSHJG/cQ0F5NPE9gcF8mqS5Ako9+Sl2ApAseuUjnIcC+UgHcHdt5odZLOCXSrC5F2g/I JV+KJJkiSoYYqXpwnymvIzmZgKzpOruoH+eV4t39XwfVkl3Gt04ybQKAcNpEy9CCLcm0CWb7xuIj D2udlgAF0iZZ/YmkTWJOVVZ/VhfC14W/S+qv66L+4O8y8NVKSus0+f6HQIbhWFI+J5rDiftJHTwl kO5p27k94k3ixuCJbboqUyJL86A345nioJl80HIkvbqDI0l6wQn92pNeb9LqlhJgbR198FyWt9qb 5W3j6JNebVty3rI7EOOtIcNb41TmbZUY2UNiJBFe1kt6kGvHeZFjT3Q031qiA7mNJafoxF4RQZGt gtw8aArFtQfFH2ow3u5DDXtLEWepQkwELFu0xxZg2/RnrZZ/N3kJO+jzHNgAu4TQKwNCPTeEfHHt Dhxrv8dFnFp16VABzbP7wLtbBd73FXjXS3rPsyVLwNaJEtAQzlw0iq3JsLNCeWEQTjH6I4NwqOaO z5bgKbrR38iHWgf59U2SBJTVX5gkAeJJDW5/OEkCf5XVH0mSuJel4Gts6KeV1V9IP60MfI0N/crq L6JfKfg2MpNM+eBrnt3A6Sf/5GSVtJJMWgHRpBWLNLeJZ9xUNS8ImigImlDeDJSTN2NrsnTezBWu yp7ftF61fWbjRBE2D4HwCeX4WFChhViJK/QykGBr31ii0q0SlW8rUXlaK5TXli3KvTLJGAbU9Sqd /IpnYFOWeM03OwMbRzkDq8QwALkWmutmhvx6ssonV/nkQ+aTUzgjgX4lOCevuNt1Dj0xWUFJk7VQ Yrz/HCygKZnPhsE9/K18+NS2R3XF/wmNyVOnjwBsEjATAe1Qx5HqSOlZkwnS7hDOf+rKYBEsg8X3 ICvXPlBR74oCjRWT+f27u2WwIovxGqUe7AMba1NkA8DA13qFNwB4QN/xhYZhtAhC6RWcKiKJ35Ki NGXfI1dOOrGcZ93FnTWg5UqvrOHc/zVt4Vwr7pFzOhDzyIGMRw4OupwJlYwM8YxXRbydzZC4IvzU djoFd8jEu+n76JyS1InkWOAR7HknSWxo7WCXimbj/7vYljxo6z4Vtsi6uieLLCGIe7wHoIjxZ8fM bbmYuZh6lbJLUjapsEotpk5rskQyZIhknDSRhGzNL/A7KyKVkPW1mhgMr7PURFrGo8k2GE/+Gd+T lJeW456VBmPNg4oKIrL12hk4K4YXUnvIYIqiIkgHvuYi4WpesSHqQ6SlgKpJD4pMoxgyImzXKra/ ObaTLUwV218b27f/9fsdFIT/B6FiTugiswEA ----=_9pdjq9po3g121o3fdnah564pc90cdk0bhu.MFSBCHJLHS Content-Type: application/octet-stream; name=acpidump-dt.gz Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=acpidump-dt.gz H4sICDC1qVMCA2FjcGlkdW1wLWR0AO092W7byLLP8VcQfooGGodNUosHyAPFxdGNFkaU4+RgAEEj 044wtuQryTnJDfLvtxdSosjuZnPRZtPAZGz2VltXVVf18u6PM0kauKbkDAd/SX2r+/5zW69falVJ N5z2aOB9fw8u5B/SW7ly9gbWG76Xfyh3d3eqLMtVafLv8vnxvXwm/fHu7J3f0/AvqePN7lff3muw BuxgupzOZ+9BVTK+eaSB1qievYFjtc31aPAvaTj+58GT4Ef9ZmCi4cnndRfyD01RZcVTAWxuLLzx ar4IqsPe/Q+h6vLZG2u2Wky95ftfUgC3Jku/NwDbcJw1wADUGRDXL/cFsfQGguT6VJYxlc0w2ScQ qXZvOOr2Tavz3mkbZ2+chXfnLRbe7cjpjpzF/G764L2/ni2fvMn0burdEua5RnsEG76/hL922yOj ayLwZOXOZ7XV01sdC34bA/+L2XaDTxAKV2u1++5oYH0ilHXcoT60RkZv6P/dBeOR9Xk4anU+4p5l +U/8P9UvgzXXZXek7A6gstGwO9i0apJW/5y9uXIsef1dIS0U1Nuo87mjjDo6REaWnpdVCX9R/S/o 09kbu3Ptfhi57f9A+KuS/9dw0Dbh32dvzOvh11Hftl1riIrxnzdtc/jhPYTI1L+O9M6g+x4otarU 7feCv6B0GFZveD34+r6G2KA7xqjV7w9H+sD48B6O+TC+h6J202r3PptVA4zca8fpD4aWWXU7luWM WtfDYb+3LX7uX2988atDqfrwX3d6jwjq/0DQp4vH0c34X2/02ZuESiB9Hub/jB9Gnfnk3/XgZ28+ ewsiTJtRzPCsBEBD4ksVc9BUM8o5QLBuyXjXtYdUGQcY/MkavD+k9mzlPWCZk4z549N85s1Wkr6Y fJuuvMnqeeGhSnq3I5nT5Xi59B4hNAvpO0FUUmQA5JrS+FNVUD1j/vRzMb3/tpLeTiqwEMrDn7iO P4wxXzzNF+MVbIqqo/823f6U5nfSu9Xj07vx5Gl6+/z4dDGd9VxzVZWGz570P89wOE0Cl38p2l+g hrrVYAeojz4cczobP/i0+uCNb73FX6gE/UCmzsYIE8n/OUc8OQ+KCWukzQ9hs2JYdektZlglqBoQ MlwVSH/AH0lV/vxnupJWGIC3n0GlKs3mUl3DXx/HcIDl8xPEfRX0FfA91FerERQiBrfNEEznRCLO wxUCwSAVAunYqrIFMMELSYD0VpMv62u0EN+niKvBkOdIfs5jxb50Y6yxHBmQQPVGo6EozQoWqTPT u5vOpoi/rQc4NaS359sMHT8+nFd9BlQlKP4BYtUQBtUQqJWzX2eYiZP5EyTs3yNnUMEfyGf0A7Xu xFsuoaDj4gvDuZZxFyDoSINd4d/rFenXb9zw9xn+X2/8iHt1Ybkznvw7vod/wopadJD/eIt5VUrx Jxmlsj0KSBgFfQv1k/wndRQteRRlu5+EP6mj1HY5Sv/JI2pi4N0jkXv7t2m1rqAh/LlceY/tPuJm 0+cyaWFPvYfbdb3Wz5WnTyZVqTdHKhqCuvCW3uK7F4XSbF1BpkhSMywVsdGtL8NuMHjXe5wvfvqi ZdtNFYMB5C0wSIOb+eJWCIpBv4uhQD7Q5mPXpXzsdxVaTYVWU6XVjH/Uu1YXfVQVPhE6xmCbA7Jm Eh4o28jjisIsgNUJC0IgwW9KMlv+dofX7jZImqxSxYLUFIbpCvorAuPftAefouMrOm18UlN4fFh7 IIJ/t23Exrep+OOawuO7hoOGTxj/yum3osNrBpGMreFJRXHqO8j5kpB9CH8DlG8K5ZtK+aZRvtUo 3+qUbw3Ktybl22X8G6DgASh4AAoegIIHoOABKHgACh6Aggeg4AEoeCgUPBQKHgoFD4WCh0LBQ6Hg oVDwUCh4KBQ8FAoeKgWPL1/wt7hb0HftTngudb3VtzmUZriUgUKuIDleud5iOn6Y/p93G5vCd9Lb Dqxh/e8z9EzfurBOH37SF/cydA5Df4JKpbJutWlPHE7ot86wfZU3dXwgseq+vY11TTwfOMPGD6FG BKXWtQ0p0Hq+g4tWCB6pA30iSj3Ar+fClYVHxoQVYbe0IoCLwKbo5tsU+cdR4LaxNr3JwntE65BY RQphTQ8uwRH67dmt9yNA0W8IyREt3+oL/RBcgwaV7cF+xaoHPEFO3nbd3zQOBdX7M1/NsZTpYGh0 t5Vpg2ZcSTVhVWp0272ocTW6ph4zLpg6/hikEakmPFLw07+7W3orLLN2JTSq++FaxKReDXSaq6XJ vlmXtx0tv34OKIEchtLuXMlResXbtPQtzGCjZMzaPbvP8iE1ms9CGghj9rFltqPKDQrLTfSb4yIP Yftbe4A0nSSFXXKz7VrRei5kYkxZxjBtWZazLcl1QMGPVBN3SUBLwCUx+r1h1CWhOCSkmvgs6g1j UgG/Aco3JfZtOOjEpGNtSpyPA7wO5poSX6FiCkQ1ol8GZRJFyOBYlKIatKwINEoRcpaoRUSx49GU uP6+QqGltWlQiCQzzVh/4QNPxoO/bivODaC2bfuDqttV6AOrsYHpsz1qUdSo4t76U5/druG1DR68 snUM8EZrK1RXwQeayE8IqYhE/j1yhm6ySCKWEhGBNJKZYhmMhpbZFZZrFPQj15gSxGqhVdYRnS3u OTcGCNiHfq/E5DGogVYQ8RppOwHRGiHCp8c2TNxaQFxAlUFSVEULNvbg0ZEBc2SM95U+IHibVQn9 XqFWUQLq0Xy0/mLDe9JdvCMfA7LUpqEYzKEN7QJshSZRhEJonAqrEhuIyFxDiJHFOQlAod/FCV+r RAOQm2l3o38UtgSQN3Z0UiWIbBge4hZwVTaEYnr3Ewf6WhfOzaAVdkU3zq6PxTo667ajEAcIjrru FQu/+PAR9REVsRCd1/27iIOi/VO5o8aVCWv6JNfDy4NYvUS8aES9ciwmVTsoiiELYt2bz5+4NOyg GIZ4b2ERMdryxbXbkuNyQhummWMYQUlsxUK93vfpxENzZNBiDoZXv6MPbaj6rOly3Ibgnjs9RzZk 4zyicTaSN9R56PCXkRCXlsAyMgC+a3UzwA6YsBsDNz3s4VjCwFvOnxcTb+g9Pj1AV0d6G1ey8R4I DGgRpCr29AfKkw+88e3NYrryqtTa6wyWTVKzwc+7dygIAv32pdQaLz1+W7SMpLclWUBm69FXGVQK xUI7DBZKsVg0D4OFWiwWxmGw0ArFQs4xL4CcHQu5OCzg6s8+BBZHwwf9GDAAeTCQc0hSrUBJsqxc WIDC+PA7/gnvy/FMlB0OQmHYlGIPBxr4C2SVL9DUuhi1dBftCOt2c3QD/G4GXR3k66Zj9WA3rpun G2UDjZKvmwCaPN2oG2jUfN0E0OTpRttAo+XrJoAmTzc1vxu0mYGycn7+Z7UYT1ZwwYP3D4RVB71F JBBCNj2QdZKgy+gvn5AgswQIV/s2vVt1vLtVMAiErUkPVDAWZvSpEu0bb9BI3zd1/myt7olbRRft SECCTlglM2EV1lyIE1bJRlhFhLBKNsIqCYQ1AsKqGQmrZiasyprWccKq2QirihBWzUZYNYGwG/eL rnQoxA0SDVh70E1csEjezi8nLpJRlCD1KlmX1egq2a+rmwM/WkYphaQxoxEJ+mYZfTCsShC0kTGf 3U3v41vY1oTxYxhJy/AgBbqOv5AhErJayTJLArZBxopOdVpolIKxHsO4WTTGejEYK0Vg3GuhGbCN cTRxHcGFNBHE4BfT8dzkpmuNCiV3bemmycprx/uoX9L6GHzpO+J9NJu0PvSrZpPVByy7jHMhQvPC om52RWiYAwbIkIfWel72nh//QRnEoCMoWsvnR29RlbrTGQQLr4vgH+Mfmz+c+dL0JvPbxMVqdesb XOhcLcaz54cxXGD9TNt0MJ7dewio6ePzI7exbbMaj38kNqaMPIRALx/wVPQlkNcDoPSQsK6rVhlL 7HYf7UBClAZ1Lq0Nu5mdYJzGyQQD1cg3tJx9mN7PUMqY17BJaZgpDoEEGREqkGBnMb99nvgSvBHf mOxK1mw1XXgY06MUZMNuHFKQaWKRLMhVafjzyXNXcJTJ6fHLzMEv1T6o4lHVTIonmV+iSkjLI+y8 xrtTQk25KCUkTqRmHiI1T5pIRzzzNZBHeA8788k+sQPO/FqemV87yMwHr0GoazLIwZcDC7VtHVao 63mEun7i5uyIhbqex4LahxXqS7uxG6HG+RaSyqQxLcQgGv+M8eSbh857o3hC1jy08IoonoYWX9rL rW0OpuRebOR0KkmWlVgPItzz07sY0uBwxkviqJGHo2bJ0aPjKGWThriGtewDctTf45OWo6Ov6Gxu Wq6m3X2BkwpB/rt+McIH4Ybpt19E+8F59GGf1g8+wrlJoQdpNPqgm6R7mJCoLqt7XgqNluxycJZq c7GDYiQFuym3QCTHtjGqTSKGzAqMog2FO72POqd9XBxg5f3BD0Tgbx0v/IoI/Mbxwq+KwG8eEP7L AuS/dbzwg2OXn8sC5P+I5Uc9dv2pFyD/xvHCD45dfvQC5P+I5Uc9dv3ZKkD+zeOFHxy7/LQKkP8j lh/12PWnceL63zhx/W+cuP43Tlz/myeu/80T1//miet/s9T/pf4v9X+p/0v9X+r/E9T/1onHP60T 1//Wiet/68Tlv3Hi+a/Giee/Giee/2qceP4LnLj8gxOXf3Di8g/2Lv/bGygqkWs4yenjz8NmXeyA 4OZksdyQZdpNOvH7bQfW59gJU+qZWvQT3HaLG+U+JQt76bFOySZD7uAXELYhRxfT4ov34htdqCeC 2bDFTgYjLlw4Iq8uiA2AJbU90JMOwDrtlpFcZ2DSCRkXMlHyuq0G4+hxs8kUDNIot2CsgVof/tWo h3+Dn+hV0+Ef69ptRa+dThjrsiJctyaz6todcik6C66Owy+njAXYY7Xx6x4acyx++TVIKFf45XFY mzUWrJajGjx+WD1+OWWseiXdMftAsaLrJTMpVsqtIOvdbjfbzxgpKQzQJcf0iOxE5F8gwSYCyEQE 9QURoW1a2SQBsAAYWFc2y4qu7wKAlVjvfiTTinqVrFJJa4O2HtdAUFcKNCIR8/m53qxHbYpdT3A2 qH3kNjGfLXQPg6DvETCshceW8zDMv7/d5xuBAh3zTM232DsgyRzD6vWBcVdd8kjxB0pSCQeZF8N2 N/I0niFKvwS/no+E/KPB86DkHy2NW2zL3GJZbWp00tBWKAVgo/DhUQG3uF7jFuvN7Lg00+MiK3za 8nGR5SMu3i8dtQQZ5RcruYrBTnmYnY71DJqCD412yZ96dW4xem2Md0qZ3znIoWVqpzYz94sqn21J cysnofaL6k51XpIi2KuZ3K1KlPeLi3KkKjaLqarlmm3HbMn2aqpkvjU5RqUmvogfds3Q45LI+G0/ GRn8xE9OkpZE6J12X07VBhLF7Orp2jTxOCBVGwOPk6oNutzD+NCzRQL79pUSXWuTp+sUmR3Yx43M hHemswRwZWYA13WdIS/A7Xb55U5CeyehfRxWILNhJW9OsvSPa7QSg5e8cti/xe2/yx8/KRgO23P7 dxLwc3Li5yTg5+TEzwnwEw9IXGHxiN/GG66BOk2okdSHmziKmziKmzhKy3BZNYJQJ1Qfsug05t9X HAtnXqE36pOjY2LRJtiZ9JbMXcJVIhtkthM5ItKKZLLCikvxAXYRwGpOgLfet0SKupJUlWCFBE+g KkIUSaBIVdzrtUCvmIhIJgWqYgBcEQAwO5CUJlfFegSJK6cqEoDEnq58CRFA5SoQI0ukKpE7gV59 gRQBIJBaS6QqEXOBXvGkx7MgzSQI9IE5+CynFXkxvRDRDbaobkh2KzY6wiZ3xUd0BJEJtl5gh8eT iQVyEgscmlggoj7dHMQSIF/I7oCMdgfs3e4Qn5N4S8TnIl4q8c+IF+ienN1xxe2OK253XHG744rb HVfc7rjidsct2O644nbHFbc7rrjdccXtjitud1xxu+O+ZrujRHREaXc4xFIj6nPHdidACuNUg+Ol ztf7cr6JP8mNrLQg6K/f7oj9q+N/LZtNCPpj0scMKuPpJBLcQvs3/JhT6A1u+G+3b1ppGipBw2vY Mv2INSSCH/T0I8KG18yG+OnszTPQPkEYTx5t7eOZBaOo/qSNva+eyjmQf7RkHoaxqmycGBoKQY/2 DqUFELVD22mgqc0qqT7gprfw7vqwu/bs1vsR/5vsOIFU1CuQmhBWpZK0vxP9sOWJrZjQD3ODTTJC Pi21CrfWr0TQ0xJGTUWYZOLwCZRIpN0gqewVScZswXFmqKBR10FAnj1MYTu4fFp1x6vJNw6JACJN 1/qE6QQVUHc4SCDVxjRU+A/ABYiTjUvCTLusrPvlwoGq8eh4tjeqCFOEUAMljoSp0RSgBgaWbUPn swk0aTP8bFRgBgOrhv/PyEEGzhyrDtcBg4vdRg4HrD/zlqw0Hq0aEKhGT/DRqiU9rclOyQUqHW+q lX4Vvh+TveYvUODl9AJf51JMWNrlyqZDnsrGVRrJ7042BLgeVEwUtl0rjaOmIRClIai8Lp8Ro147 jNdYP36vMYk8L8RvzIcmx3NMC7q2nv21RODZqjFwVpCRCxbbbIPHXyZqJzTla+WUZ0352uuY8rUX P+WB4JTXMkx5vpvKWTC4fjov2wmrY/O2iW/HzqRtV2PmaBIVoUAsEG0WFcrT+VWZWaCiAxMkSCoK msoHjW1/UHB1Y8Wy0jHJ9cdTsNuxyHKj8CjKASxiaxN3ENKIfEYGymW9rU5NSjTvzIYGpzH9Rcua f8XYG6I3k/iZYAACUPk5693YwXpKvovx/ujMfW1HaIrPgEa2GVCYGkYChgAK0lAo/FGVUAgMUWbr IwkqVPI4rjjH1fGWS8gTrCGDgdazkXxOGiqdNOAu2XEdES8tl73R9mJvwKu0N25pb16tvXFfh71x i7A3bsjeuMdlbwDN3oAd2BtAtzegeHsDeDHwgu0NRjLJUmBx615ZxA6mSkqEtrHIxaQmgOAsENj2 FCQy2Ttb05MHvEDyUPeKCt2U9XmoG5nuR9IETio6N0bsHj+NtWexgHv8dOMCD1ncNX43Bkh3/Z4A yfVrs52J5DWhG6/QTaeC3X9om1XJmi7HbUjIc6fnyIZsn1eY139dt83Em6/coZ79IiU8m8ndieRi Ht7EC2+vC3ld2S9cwttS9nPjEvaF82+BHTn4lqmM1CZcbV3bLfQOMXnDeOg9Pj3gTSSpEzqDT5AP 3nfvoSrpk9X0u9eZ/7cqud/GC/TmcYL1BVW1qlVr1Xq1UQVyFYAqUKpAq4Iaw1ryd7MgpFKFpkdm 2y1IbmW7iu//TDe+cTKcHH3l7UHGXafiWWwzLsFj++7m9RPJjYtRuzesQiBbIFV/ZFc/bKYIhOt5 23rjFbVKCm3GMunfpnerwfT+22prG7PGb4V1IBSZsBoEGdUgZR1Lumpkjw+sH6EOddfkbyPfIkjH u1vhLVuRzWza4df4fDKnWFbQ8AR8ESwi8xhsRmdPpGhljTd9EnKF6RWyixQiyKgQYzpgvWcfpFId m+s3uapjw0JUaUvKOZtEA6cFwSO0xgipHFEtskaa1/3Nt+mDxwhiZdAjs8nCe/Rm61nPka5M4PJW yslGOMIwcV2LWEa6D9qwrLyYl97asZeu7NhLRwcuCaFLL30fXrr+Er10ff9eOpFbGyeNaEdcd++l 6/vx0pu79tL1iJfeWnvpzbWXroNU/QWmVt+3lx7RZqW/Xfrbu/K39TT+tp7Z39aPx9/Ws/nbuoi/ rWfwt/XS3y7M304ypxvXGdXcuM500yvmOhs7dp3VvbjOZYB7X66z8RJdZ+NQrjNZWx/GdTb24zpf 7tp1NiKus7F2nS/XrrMBUvUXWE3jMK5zGeAuHe4jdbiNNA63kdnhNo7H4TayOdyGiMNtZHC4jdLh LtjhZhvhnAHu4rx0c8deurbrbShm6aXv00s3X6KXbh5gG4oZyoCZh/DSzf146fquvXQz4qWbay9d X3vpJkjVX2Bqzb1vQzFLL7300o/YSzfTeOlmZi/dPB4v3czmpZsiXrqZwUs3Sy+9uG0oCUY4p5eO ug9tQzFTeumBeG+sGzRn7STLHyc2UkjucGCgnvpwopx3p5PFfDmHKN1MZ7fz/y6hH08zxFQlyL77 gT+G1Bue57g8AR1Ude3O3m5EUNKNJ7Tccr+6gxzLLSXbrn+/BnYaRRw+BoP76LjMZH7rgXqVeywH XckX/nn3ThqMZ/ee1J3Opo/Pjxkbj38kNQbVyDfYWH+Y3s+QguG96ilTGna82f3qG/uix5xEUpQc RGI33iGRrP0TSdNyEIndeIdEMvZPpHoeSaofQJJk5QBEquUhUu0ARGrtn0iNPNOtcYDpJh9gul2C HERiN94hkdT9E0nPo5P0V2LdrDx+kvU6/CTNzEEkTuNjt26/hU4RO+3se6zgD2c5sbfFgpJnEijy 6/Be9DxE0k+bSINPvbn9ML5f8l4F+6X8zjiF4rdwpphDyi7nEIRMemvMH5/Gq+k/04fp6id6jHvZ HS9X3qIqDRfj2fLOWzR56bJf2u+coifnET35lSzmm3mI1DwEkcABHOc8q4vLV7K6MPJIknEASVLk /bk7w2726Ck4DndHy8Nf7RCWXNuzJZezWvLBMLsz3DoO6WjkkY5GDunQTkU6mlmlw3U+ZlcezeMQ j3qe0FP9EKEnsD/jYPSdPLk17RgYbOeZ//ZpO9ti8x+oaRVA7L4712n3q5L7Ey6jHtFvKEJqy7TL GPx9HaSB4HV1lOx7z/yCr6ejXCNo6mgHbPTquggG+G5CHxbSGWmWGaI1ae7ult4KZbstmXbJoTEg HmWTXgY4ZQqnTOWUaZyyGqeszilrcMqanLJLTpnOKWtxygxOmckpszhlNrvM5PDP5PDP5PDP5PDP 5PDP5PDP5PDP5PDPbCbOnmATjdWzr9Jvndk8RxjeZPp52KxfWD3VqAiN/CXHyP/xFvP0QwdG0TYN ObNRbNC9nmJ270c2o0YRdFQDXxScZ3++vOO9QkiieMbK5yDRhkn3gm+ensamCMhiV8NH9/PKiRtN +ZtMkazycIqQ2N7z1toNSVX+/jsejYrajCtCqwi9Dv1qcwaQC3+wIf5lRwctePNTeG5G5qVlC22+ DRoYzMN6LE7s/tiHXcixD6E1jb+6UDOva5I7SFjb+B00M61v/Mb19Gsc9jonA/EaeYnXyEc8kId4 oHDiCS0UsfTW2cqpiOQaK/FIWZNG9SqahkJz33fOnD1FINQ8EQg1TwSimTXEVN97kib7jMw1Gw8e h0sRpmHMvEJS2smp/u1Vym6OBqEzPv1OP+3RIHSGqv+hzWt2M1/cRpoBfBDpk5xyNKDx3lzfqXsk 9iSGkXQNCiJxgsNFPxWUDmzbEPLqEOcEjlTFzgrVk88KBbBsHegT9jEZJ//s6ezW9Qh1WlN84OyT yDn5Yo52QV26dbQr0/OtAQSR+IDdaQ8EcSYvz70InE0952ztL6gxhryTlb2WEQhRXeuD7BuwajI4 5EsoZRCLq1ZF3sN71UGsRhnEKoNY2YNYh4oh2dfgADGkZt4wSPOAMaRmtjDI6Cvr6p/oYgzWNBJ0 gZbhppXQYoSwfWPjkOFe37TSuhh12z24SoH/FtWf/gX1p38poj9jfRPMp1zLoUYq15yn3De2Eqty Q86yslBEx8AmVbUF1lKhMYSWUjlXL2yBiVVkSQLPHvidRDyza9AeiF6iAVLzZXNVB0vW1mFAKLJ7 DAO6q/FiZXpP3uwWqix71ps7i2mpt3egtwsJX2tpngE+BG+VvLxVXi1v1WPnrWrlnbdWOW+Pdd7m 5a1ilfNWJBwzuw1xlrpSe+GJC/kyv8udMpTfOs0MhHXaGYjGa8tAoCVEodH4pBvl9haNV3YcjVfK aHwB0XgrdTRebeaJxjez3+samw8J4e5IZGR9O+ZpRcntA0fJN2QXpF8+GooBlYaW6bIOyTQVouvO 0ZDzovF7v8mqlLk0uVKmUtKlUpS9p1JeZ9hm9JWnQiKpFCvjMlA8VaFEUhXKOlVhZkql8PtLn0ph 92cVlEpplqmUl5BKUY4mlaKUqZQylVKmUsqQbJlKKedtmUopUyllKiVfKqVRplIOkEppvrpUilJ0 KqV5DKmU9iB6XiNNKgW80Ls3cmgvK5UaSEp3MF4EbabGGo9rRB/cBemSLOBlH3lICZ6ZP4qcNQGX AGiWXODOAtphEYYdWf5hp0rBScctAUdOAVthJpFQzD6wpm0ZjH9BwXhbNBgP5P0G45HdXge77fzB +Fh/OYPx4f6AXAbjy2B8GYwvg/FlUK+0yWUwvgzGl8H4MhhfBuPLYHwZjC+D8WUwfh2M7zhDwVuG nHa/i26lu7tDfKLfHkRnDeKliCaMKSMyJHnjHgLarYjnCTTuyyTlBUj5o5+5LkBSBY9cxPMQYF+p AO6O7bRQqwWcEqmXlyLtB+SCL0XKmSKKhhipenCfKa8jOZmArOk6u6ge55Xinf1fB9XIu4xvnGTa BADhtImSoAUbOdMmmO0bi488rHVaAmRImyT1J5I2CTlVSf3pHQhfB/5bUH8dC/UH/y0CX6WgtE6d 738IZBiOJeVzojmcsJ/UxlMC6Z6Wkdoj3iRuNJ7YxqsyJbIwD3ozXlMctCYftBRJr45zJEkvOKFf etLrVVrdQgKsjaMPnuflrfJqeVs7+qRXy8g5b9kdiPFWy8Nb7VTmbZkY2UNiJBJeVgt6kGvHeZFj T3TUX1uiA7mNBafoxF4RQZGtjNw8aArFMpzsDzVor/ehhr2liJNUISYCli3aYwuwbfyzUkm/m7yA HfRpDmyAXUJoFwGhmhpCvrh2HFPf73ERs1JeOpRB8+w+8G6Vgfd9Bd7Vgt7zbOQlYONECagJZy5q 2dZk2FmhvDAIpxj9kUE4VH3HZ0vwFN3ob+RDrYP86iZJAorqz0+SAPGkBrc/nCSB/xTVH0mSWL1C 8NU29FOK6s+nn1IEvtqGfkX1F9CvEHxriUmmdPDVL0Zw+uV/crJMWuVMWgHRpBWLNLeRZ9xkOS0I iigIilDeDBSTN2NrsnjezBKuyp7ftF6VfWbjRBFuHgLhE8rxsaBCC7ECV+hFIMHWvqFEpVUmKl9X ovK0VigvLVuUemWSMAyoqmU6+QXPwHpe4tVf7QysHeUMLBPDAKRaaK6bafnXk2U+ucwnHzKfHMMZ CfQLwTl6xd2uc+iRyQoKmqyZEuP9J28BTcl8NvDu4b/S248tY1iV3J/QmDy2+wjAOgEzEtD2dRyp jpSePpkg7Q7h/LcqOQtv6S2+e0m5dkdGvUsSNFZM5vfv7pbeiizGK5R6sA9srJsiGwAcV+lm3gBg A3XHFxr60SIIpZ1xqogkfguK0hR9j1wx6cRinnUXd9aAkiq9soZz/9e0+XMtu0fO6UDMIwd5PHJw 0OWMr2TyEE97UcTb2QwJK8KPLbOdcYdMuJu+i84p5TqRHAo8gj3vJAkNrRzsUtFk/H9n25IHbd3H zBZZlfdkkXMI4h7vAchi/NkxcyNfzFxMveayS7lsUmaVmk2dVvISSctDJO2kiSRka36B30kRqYis r9WEM7hJUhNxGQ8mmzOe/Du+JykvJcU9KzXGmgcVZURk67UzcJENL6T2kMEURUWQDnzNRcLVvGJN 1IeISwFVkx4UmVo2ZETYrpRsf3VsJ1uYSra/NLZv//b7DArC/wPtFYekobcBAA== ----=_9pdjq9po3g121o3fdnah564pc90cdk0bhu.MFSBCHJLHS-- From owner-freebsd-acpi@FreeBSD.ORG Tue Jun 24 20:24:44 2014 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3A8A02B9; Tue, 24 Jun 2014 20:24:44 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0F0EA298F; Tue, 24 Jun 2014 20:24:44 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id D83D1B953; Tue, 24 Jun 2014 16:24:42 -0400 (EDT) From: John Baldwin To: Hilko Meyer Subject: Re: powerd stopped working after update from 8.4 to 9.2 Date: Tue, 24 Jun 2014 16:23:39 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20140415; KDE/4.5.5; amd64; ; ) References: <201406241026.52678.jhb@freebsd.org> <6hcjq9540905oeibsjnf8ogee7sqfcdoej@4ax.com> In-Reply-To: <6hcjq9540905oeibsjnf8ogee7sqfcdoej@4ax.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable Message-Id: <201406241623.39328.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 24 Jun 2014 16:24:42 -0400 (EDT) Cc: freebsd-acpi@freebsd.org, freebsd-stable@freebsd.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jun 2014 20:24:44 -0000 On Tuesday, June 24, 2014 1:36:41 pm Hilko Meyer wrote: > On Tue, 24 Jun 2014 10:26:52 -0400, you wrote: > >On Monday, June 23, 2014 7:12:23 pm Hilko Meyer wrote: > >> John Baldwin wrote: > >> >On Sunday, June 22, 2014 9:27:08 pm Hilko Meyer wrote: > >> >>=20 > >> >> powerd doesn't work anymore after the update from 8.4 to 9.2. The s= ystem > >> >> has an old (more than 10 years) mainboard with Via KT133 chipset. > >> >>=20 > >> >> I made a verbose boot with both, 8.4 and 9.2: > >> >> 8.4: http://pastebin.com/iiZXRXgK > >> >> 9.2: http://pastebin.com/sHcd3MHv > >> >> The relevant part of the diff seem to be these parts: > >> >>=20 > >> >> viapropm0: SMBus I/O base at 0x5000 > >> >> viapropm0: SMBus I/O base at 0x5000 > >> >> viapropm0: port 0x5000-0x500= f at > >> >> device 7.4 on pci0 > >> >> -viapropm0: SMBus revision code 0x40 > >> >> -smbus0: on viapropm0 > >> >> -smb0: on smbus0 > >> >> +viapropm0: could not allocate bus space > >> >> +device_attach: viapropm0 attach returned 6 > >> >> [=85] > >> >> acpi_throttle0: on cpu0 > >> >> -acpi_throttle0: P_CNT from P_BLK 0x4010 > >> >> +acpi_throttle0: failed to attach P_CNT > >> >> +device_attach: acpi_throttle0 attach returned 6 > >> >>=20 > >> >> Any ideas what I can do? > >> > > >> >acpi_timer0 also failed to probe due to a resource issue. Can you get= the=20 > >> >output of 'devinfo -rv' and 'devinfo -u' from the both kernels? > >>=20 > >> Yes, no problem. > >> devinfo -rv: > >> 8.4: http://pastebin.com/6xm1tBrU > >> 9.2: http://pastebin.com/whXk32Ab > >>=20 > >> devinfo -u: > >> 8.4: http://pastebin.com/47U7HZb3 > >> 9.2: http://pastebin.com/U85HTw0C > >>=20 > >> thanks for your help, > >> Hilko > > > >Can you provide your acpidump? This box seems confusing. >=20 > Well, its quite old. An Epox 8kta3 from around 2002. I was not sure which= output > you need so I attached acpidump -d and acpidump -dt. Ok, try this: Index: sys/dev/acpica/acpi.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =2D-- acpi.c (revision 267784) +++ acpi.c (working copy) @@ -1196,15 +1196,24 @@ acpi_set_resource(device_t dev, device_t child, in return (0); =20 /* =2D * Ignore memory resources for PCI root bridges. Some BIOSes + * Ignore most resources for PCI root bridges. Some BIOSes * incorrectly enumerate the memory ranges they decode as plain =2D * memory resources instead of as a ResourceProducer range. + * memory resources instead of as ResourceProducer ranges. Other + * BIOSes incorrectly list system resource entries for I/O ranges + * under the PCI bridge. Do allow the one known-correct case on + * x86 of a PCI bridge claiming the I/O ports used for PCI config + * access. */ =2D if (type =3D=3D SYS_RES_MEMORY) { + if (type =3D=3D SYS_RES_MEMORY || type =3D=3D SYS_RES_IOPORT) { if (ACPI_SUCCESS(AcpiGetObjectInfo(ad->ad_handle, &devinfo))) { if ((devinfo->Flags & ACPI_PCI_ROOT_BRIDGE) !=3D 0) { =2D AcpiOsFree(devinfo); =2D return (0); +#if defined(__i386__) || defined(__amd64__) + if (!(type =3D=3D SYS_RES_IOPORT && start =3D=3D CONF1_ADDR_PORT)) +#endif + { + AcpiOsFree(devinfo); + return (0); + } } AcpiOsFree(devinfo); } =2D-=20 John Baldwin From owner-freebsd-acpi@FreeBSD.ORG Wed Jun 25 00:51:20 2014 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 147968BC; Wed, 25 Jun 2014 00:51:20 +0000 (UTC) Received: from mail.metricspace.net (mail.metricspace.net [IPv6:2001:470:1f11:617::103]) by mx1.freebsd.org (Postfix) with ESMTP id 72738229E; Wed, 25 Jun 2014 00:51:19 +0000 (UTC) Received: from [172.16.1.182] (unknown [172.16.1.182]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) (Authenticated sender: eric) by mail.metricspace.net (Postfix) with ESMTPSA id 9D04626880; Wed, 25 Jun 2014 00:51:18 +0000 (UTC) Message-ID: <53AA1D05.6000304@metricspace.net> Date: Tue, 24 Jun 2014 20:51:17 -0400 From: Eric McCorkle User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: John Baldwin Subject: Re: ACPI error messages on Lenovo W540 References: <53A048B1.1080108@metricspace.net> <201406230953.16496.jhb@freebsd.org> <53A8AD54.8040908@metricspace.net> <201406241000.35812.jhb@freebsd.org> In-Reply-To: <201406241000.35812.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@freebsd.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jun 2014 00:51:20 -0000 On 06/24/2014 10:00, John Baldwin wrote: > On Monday, June 23, 2014 6:42:28 pm Eric McCorkle wrote: >> On 06/23/2014 09:53, John Baldwin wrote: >>> On Tuesday, June 17, 2014 9:54:57 am Eric McCorkle wrote: >>>> I suspect these might have something to do with the USB 3.0 system not >>>> working, though I don't have experience with either the ACPI or USB >>>> subsystems. >>> >>> Does it not work in general, or does it not work after resume? >> >> Actually, USB seems to be working quite well. It even detects an >> already plugged-in mouse during the ith resume. >> >> The sign of trouble are some messages that show up during resume: >> >> usb_alloc_device: device init 2 failed (USB_ERR_IOERROR, ignored) >> ugen0.2: at usbus2 (disconnected) >> uhub_reattach_port: could not allocate new device >> >> There had been some timeout messages, which googling seemed to implicate >> was a USB 3.0 issue with lenovos, but those seem to have disappeared (I >> did do a kernel update). >> >> Maybe I should test USB 3.0-specific features to see if they are >> working. Unfortunately, I'm not that familiar with the gritty details >> of USB. Any ideas for how to do that? > > There was a recent fix to acpi_pwrres.c that fixed USB issues on resume for > several ThinkPads because the kernel wasn't properly turning certain things > back on during resume, so if your problems were only with resume, then there's > a good chance they should now be fixed (and it sounds like they did after you > updated). > >>> >>>> Also, the nvidia Xorg driver fails to work, and causes a similar error >>>> message: >>>> >>>> ACPI Warning: \134_SB_.PCI0.PEG_.VID_._DSM: Argument #4 type mismatch - >>>> Found [Buffer], APCI requires [Package] (20130823/nsarguments-97) >>>> (the same message gets repeated about 10 times) >>> >>> That is a very different error, but it might explain nvidia driver problems. >>> The ACPI spec explains how _DSM works (there's an example method in section 9 >>> of the 5.0 spec which you can get from acpi.info). In this case the warning >>> is complaining that the return type is incorrect. Of course, the spec says >>> that this function should return a Buffer, but ACPICA seems to think it should >>> return a Package. It would be good to track down which specific arguments >>> were passed to _DSM and then examine the acpidump to see which path that would >>> take. >> >> I looked at acpidump, and I was able to find the definition of _DSM. Is >> there a way to get better ACPI debugging info out of the kernel (aside >> from adding debug messages directly)? > > Probably not in this case, though just looking at the source of the _DSM method > might be a start. However, re-reading this warning (and checking the source), > the problem is not in the _DSM method, but in some code calling the _DSM method. > Are there any calls to _DSM in your acpidump? It looks like this is the definition: Method (_DSM, 4, NotSerialized) // _DSM: Device-Specific Method { If (\CMPB (Arg0, Buffer (0x10) { /* 0000 */ 0xF8, 0xD8, 0x86, 0xA4, 0xDA, 0x0B, 0x1B, 0x47, /* 0008 */ 0xA7, 0x2B, 0x60, 0x42, 0xA6, 0xB5, 0xBE, 0xE0 })) { Return (NVOP (Arg0, Arg1, Arg2, Arg3)) } If (\CMPB (Arg0, Buffer (0x10) { /* 0000 */ 0x01, 0x2D, 0x13, 0xA3, 0xDA, 0x8C, 0xBA, 0x49, /* 0008 */ 0xA5, 0x2E, 0xBC, 0x9D, 0x46, 0xDF, 0x6B, 0x81 })) { Return (NVPS (Arg0, Arg1, Arg2, Arg3)) } If (\WIN8) { If (\CMPB (Arg0, Buffer (0x10) { /* 0000 */ 0x75, 0x0B, 0xA5, 0xD4, 0xC7, 0x65, 0xF7, 0x46, /* 0008 */ 0xBF, 0xB7, 0x41, 0x51, 0x4C, 0xEA, 0x02, 0x44 })) { Return (NBCI (Arg0, Arg1, Arg2, Arg3)) } } Return (Buffer (0x04) { 0x01, 0x00, 0x00, 0x80 }) } Not sure if that's helpful at all... > Ah, the nvidia driver calls _DSM and it has the bug. In its nvidia_acpi.c file > it uses a Buffer instead of a Package for the fourth argument to _DSM. OTOH, the > warning doesn't prevent the method from running, so the warning may be harmless. > You can try contacting the nvidia folks to tell them about the warning and point > out the bug in their _DSM wrapper in nvidia_acpi.c to see what they say. Will do. Is there a preferred point of contact? From owner-freebsd-acpi@FreeBSD.ORG Wed Jun 25 10:08:23 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 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 73955F3C; Wed, 25 Jun 2014 10:08:23 +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 AEF672390; Wed, 25 Jun 2014 10:08:22 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id s5PA8CQc063038; Wed, 25 Jun 2014 20:08:12 +1000 (EST) (envelope-from smithi@nimnet.asn.au) Date: Wed, 25 Jun 2014 20:08:11 +1000 (EST) From: Ian Smith To: John Baldwin Subject: Re: ACPI error messages on Lenovo W540 In-Reply-To: <201406241000.35812.jhb@freebsd.org> Message-ID: <20140625190106.N609@sola.nimnet.asn.au> References: <53A048B1.1080108@metricspace.net> <201406230953.16496.jhb@freebsd.org> <53A8AD54.8040908@metricspace.net> <201406241000.35812.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: freebsd-acpi@freebsd.org, freebsd-mobile@freebsd.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jun 2014 10:08:23 -0000 On Tue, 24 Jun 2014 10:00:35 -0400, John Baldwin wrote: > On Monday, June 23, 2014 6:42:28 pm Eric McCorkle wrote: > > On 06/23/2014 09:53, John Baldwin wrote: > > > On Tuesday, June 17, 2014 9:54:57 am Eric McCorkle wrote: > > >> I suspect these might have something to do with the USB 3.0 system not > > >> working, though I don't have experience with either the ACPI or USB > > >> subsystems. > > > > > > Does it not work in general, or does it not work after resume? > > > > Actually, USB seems to be working quite well. It even detects an > > already plugged-in mouse during the ith resume. > > > > The sign of trouble are some messages that show up during resume: > > > > usb_alloc_device: device init 2 failed (USB_ERR_IOERROR, ignored) > > ugen0.2: at usbus2 (disconnected) > > uhub_reattach_port: could not allocate new device > > > > There had been some timeout messages, which googling seemed to implicate > > was a USB 3.0 issue with lenovos, but those seem to have disappeared (I > > did do a kernel update). > > > > Maybe I should test USB 3.0-specific features to see if they are > > working. Unfortunately, I'm not that familiar with the gritty details > > of USB. Any ideas for how to do that? > > There was a recent fix to acpi_pwrres.c that fixed USB issues on resume for > several ThinkPads because the kernel wasn't properly turning certain things > back on during resume, so if your problems were only with resume, then there's > a good chance they should now be fixed (and it sounds like they did after you > updated). Well, this is most timely for me; I was about to query you and hps@ for advice re debugging knobs to have another crack at debugging this issue! Not nearly content to wait for MFC, I applied the diff-to-previous from r267647 of /sys/dev/acpica/acpi_powerres.c to stable/9, which was clean, so I updated source, applied the patch and rebuilt world and kernel: FreeBSD x200.smithi.id.au 9.3-PRERELEASE FreeBSD 9.3-PRERELEASE #0: Wed Jun 25 15:29:28 EST 2014 root@x200.smithi.id.au:/usr/obj/usr/src/sys/GENERIC amd64 After which I suspended and resumed 5 times, to be quintuply sure, and yes, my 1GB SwissFlash stick - normally annoying because it has a very bright red LED that's always on when the port is powered - lit up every time, so the external USB ports losing power problem is fixed on mine. However, it loses touch with a mounted UFS partition on the stick after suspend/resume; I've never been sure if I should expect that to work? Even so, umount, fsck then remount fixes it, so now my X200 is actually usable in traveling-without-rebooting-for-weeks mode, so I'm happy and am passing on this good news for all(?) Lenovo Thinkpads to mobile@ too. Many thanks to you and trasz@, and I'm only slightly apologising for riding alongside Eric's other video problem .. cheers, Ian From owner-freebsd-acpi@FreeBSD.ORG Wed Jun 25 12:35:33 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 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 60E3A1CE; Wed, 25 Jun 2014 12:35:33 +0000 (UTC) Received: from mail-in-10.arcor-online.net (mail-in-10.arcor-online.net [151.189.21.50]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mx.arcor.de", Issuer "Thawte SSL CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1935D22BB; Wed, 25 Jun 2014 12:35:32 +0000 (UTC) Received: from mail-in-19-z2.arcor-online.net (mail-in-19-z2.arcor-online.net [151.189.8.36]) by mx.arcor.de (Postfix) with ESMTP id ED4E92D6C8D; Wed, 25 Jun 2014 14:04:01 +0200 (CEST) Received: from mail-in-02.arcor-online.net (mail-in-02.arcor-online.net [151.189.21.42]) by mail-in-19-z2.arcor-online.net (Postfix) with ESMTP id E7E8E3F862F; Wed, 25 Jun 2014 14:04:01 +0200 (CEST) X-Greylist: Passed host: 79.223.81.135 X-DKIM: Sendmail DKIM Filter v2.8.2 mail-in-02.arcor-online.net A25BB3015C X-Greylist: Passed host: 79.223.81.135 X-Greylist: Passed host: 79.223.81.135 Received: from HiltisSchrein.Speedport_W_700V (p4FDF5187.dip0.t-ipconnect.de [79.223.81.135]) (Authenticated sender: hilko.meyer@arcor.de) by mail-in-02.arcor-online.net (Postfix) with ESMTPA id A25BB3015C; Wed, 25 Jun 2014 14:04:01 +0200 (CEST) From: Hilko Meyer To: John Baldwin Subject: Re: powerd stopped working after update from 8.4 to 9.2 Date: Wed, 25 Jun 2014 14:03:58 +0200 Message-ID: References: <201406241026.52678.jhb@freebsd.org> <6hcjq9540905oeibsjnf8ogee7sqfcdoej@4ax.com> <201406241623.39328.jhb@freebsd.org> In-Reply-To: <201406241623.39328.jhb@freebsd.org> X-Mailer: Forte Agent 1.93/32.576 English (American) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-acpi@freebsd.org, freebsd-stable@freebsd.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jun 2014 12:35:33 -0000 John Baldwin schrieb: >On Tuesday, June 24, 2014 1:36:41 pm Hilko Meyer wrote: >> On Tue, 24 Jun 2014 10:26:52 -0400, you wrote: >> >On Monday, June 23, 2014 7:12:23 pm Hilko Meyer wrote: >> >> John Baldwin wrote: >> >> >On Sunday, June 22, 2014 9:27:08 pm Hilko Meyer wrote: >> >> >>=20 >> >> >> powerd doesn't work anymore after the update from 8.4 to 9.2. = The system >> >> >> has an old (more than 10 years) mainboard with Via KT133 = chipset. >> >> >>=20 >> >> >> I made a verbose boot with both, 8.4 and 9.2: >> >> >> 8.4: http://pastebin.com/iiZXRXgK >> >> >> 9.2: http://pastebin.com/sHcd3MHv >> >> >> The relevant part of the diff seem to be these parts: >> >> >>=20 >> >> >> viapropm0: SMBus I/O base at 0x5000 >> >> >> viapropm0: SMBus I/O base at 0x5000 >> >> >> viapropm0: port = 0x5000-0x500f at >> >> >> device 7.4 on pci0 >> >> >> -viapropm0: SMBus revision code 0x40 >> >> >> -smbus0: on viapropm0 >> >> >> -smb0: on smbus0 >> >> >> +viapropm0: could not allocate bus space >> >> >> +device_attach: viapropm0 attach returned 6 >> >> >> [=E2=80=A6] >> >> >> acpi_throttle0: on cpu0 >> >> >> -acpi_throttle0: P_CNT from P_BLK 0x4010 >> >> >> +acpi_throttle0: failed to attach P_CNT >> >> >> +device_attach: acpi_throttle0 attach returned 6 >> >> >>=20 >> >> >> Any ideas what I can do? >> >> > >> >> >acpi_timer0 also failed to probe due to a resource issue. Can you = get the=20 >> >> >output of 'devinfo -rv' and 'devinfo -u' from the both kernels? >> >>=20 >> >> Yes, no problem. >> >> devinfo -rv: >> >> 8.4: http://pastebin.com/6xm1tBrU >> >> 9.2: http://pastebin.com/whXk32Ab >> >>=20 >> >> devinfo -u: >> >> 8.4: http://pastebin.com/47U7HZb3 >> >> 9.2: http://pastebin.com/U85HTw0C >> >>=20 >> >> thanks for your help, >> >> Hilko >> > >> >Can you provide your acpidump? This box seems confusing. >>=20 >> Well, its quite old. An Epox 8kta3 from around 2002. I was not sure = which output >> you need so I attached acpidump -d and acpidump -dt. > >Ok, try this: > >Index: sys/dev/acpica/acpi.c The patch doesn't apply. Was it for head or 9-stable and not for 9.2? regards, Hilko From owner-freebsd-acpi@FreeBSD.ORG Wed Jun 25 15:22:20 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 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 76E2CCDD; Wed, 25 Jun 2014 15:22:20 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4F24E23DE; Wed, 25 Jun 2014 15:22:20 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id E278FB9B9; Wed, 25 Jun 2014 11:22:18 -0400 (EDT) From: John Baldwin To: Hilko Meyer Subject: Re: powerd stopped working after update from 8.4 to 9.2 Date: Wed, 25 Jun 2014 10:17:31 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20140415; KDE/4.5.5; amd64; ; ) References: <201406241623.39328.jhb@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <201406251017.31861.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 25 Jun 2014 11:22:19 -0400 (EDT) Cc: freebsd-acpi@freebsd.org, freebsd-stable@freebsd.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jun 2014 15:22:20 -0000 On Wednesday, June 25, 2014 8:03:58 am Hilko Meyer wrote: > John Baldwin schrieb: > >On Tuesday, June 24, 2014 1:36:41 pm Hilko Meyer wrote: > >> On Tue, 24 Jun 2014 10:26:52 -0400, you wrote: > >> >On Monday, June 23, 2014 7:12:23 pm Hilko Meyer wrote: > >> >> John Baldwin wrote: > >> >> >On Sunday, June 22, 2014 9:27:08 pm Hilko Meyer wrote: > >> >> >>=20 > >> >> >> powerd doesn't work anymore after the update from 8.4 to 9.2. Th= e=20 system > >> >> >> has an old (more than 10 years) mainboard with Via KT133 chipset. > >> >> >>=20 > >> >> >> I made a verbose boot with both, 8.4 and 9.2: > >> >> >> 8.4: http://pastebin.com/iiZXRXgK > >> >> >> 9.2: http://pastebin.com/sHcd3MHv > >> >> >> The relevant part of the diff seem to be these parts: > >> >> >>=20 > >> >> >> viapropm0: SMBus I/O base at 0x5000 > >> >> >> viapropm0: SMBus I/O base at 0x5000 > >> >> >> viapropm0: port=20 0x5000-0x500f at > >> >> >> device 7.4 on pci0 > >> >> >> -viapropm0: SMBus revision code 0x40 > >> >> >> -smbus0: on viapropm0 > >> >> >> -smb0: on smbus0 > >> >> >> +viapropm0: could not allocate bus space > >> >> >> +device_attach: viapropm0 attach returned 6 > >> >> >> [=E2=80=A6] > >> >> >> acpi_throttle0: on cpu0 > >> >> >> -acpi_throttle0: P_CNT from P_BLK 0x4010 > >> >> >> +acpi_throttle0: failed to attach P_CNT > >> >> >> +device_attach: acpi_throttle0 attach returned 6 > >> >> >>=20 > >> >> >> Any ideas what I can do? > >> >> > > >> >> >acpi_timer0 also failed to probe due to a resource issue. Can you = get=20 the=20 > >> >> >output of 'devinfo -rv' and 'devinfo -u' from the both kernels? > >> >>=20 > >> >> Yes, no problem. > >> >> devinfo -rv: > >> >> 8.4: http://pastebin.com/6xm1tBrU > >> >> 9.2: http://pastebin.com/whXk32Ab > >> >>=20 > >> >> devinfo -u: > >> >> 8.4: http://pastebin.com/47U7HZb3 > >> >> 9.2: http://pastebin.com/U85HTw0C > >> >>=20 > >> >> thanks for your help, > >> >> Hilko > >> > > >> >Can you provide your acpidump? This box seems confusing. > >>=20 > >> Well, its quite old. An Epox 8kta3 from around 2002. I was not sure wh= ich=20 output > >> you need so I attached acpidump -d and acpidump -dt. > > > >Ok, try this: > > > >Index: sys/dev/acpica/acpi.c >=20 > The patch doesn't apply. Was it for head or 9-stable and not for 9.2? It is for HEAD though it should apply to 9-stable. It might not apply to 9= =2E2=20 as it patches a previous fix that went to 9.2. For 9.2, please merge the change to stable/9 from=20 http://svnweb.freebsd.org/base?view=3Drevision&revision=3D263022 first and = then=20 apply this patch. =2D-=20 John Baldwin From owner-freebsd-acpi@FreeBSD.ORG Wed Jun 25 15:22:21 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 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7D07DCE1 for ; Wed, 25 Jun 2014 15:22:21 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5722523E0 for ; Wed, 25 Jun 2014 15:22:21 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 49B01B9D0; Wed, 25 Jun 2014 11:22:20 -0400 (EDT) From: John Baldwin To: Eric McCorkle Subject: Re: ACPI error messages on Lenovo W540 Date: Wed, 25 Jun 2014 11:16:04 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20140415; KDE/4.5.5; amd64; ; ) References: <53A048B1.1080108@metricspace.net> <201406241000.35812.jhb@freebsd.org> <53AA1D05.6000304@metricspace.net> In-Reply-To: <53AA1D05.6000304@metricspace.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201406251116.04832.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 25 Jun 2014 11:22:20 -0400 (EDT) Cc: freebsd-acpi@freebsd.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jun 2014 15:22:21 -0000 On Tuesday, June 24, 2014 8:51:17 pm Eric McCorkle wrote: > On 06/24/2014 10:00, John Baldwin wrote: > > Ah, the nvidia driver calls _DSM and it has the bug. In its nvidia_acpi.c file > > it uses a Buffer instead of a Package for the fourth argument to _DSM. OTOH, the > > warning doesn't prevent the method from running, so the warning may be harmless. > > You can try contacting the nvidia folks to tell them about the warning and point > > out the bug in their _DSM wrapper in nvidia_acpi.c to see what they say. > > Will do. Is there a preferred point of contact? Just use the bug report details that come with the driver. They include an e-mail address you can use to send bug reports. -- John Baldwin From owner-freebsd-acpi@FreeBSD.ORG Wed Jun 25 19:48:17 2014 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A9832507; Wed, 25 Jun 2014 19:48:17 +0000 (UTC) Received: from kirk.hochpass.uni-hannover.de (kirk.hochpass.uni-hannover.de [130.75.81.215]) (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 254902DFA; Wed, 25 Jun 2014 19:48:16 +0000 (UTC) Received: from SOLO.hochpass.uni-hannover.de (solo.hochpass.uni-hannover.de [130.75.81.216]) by kirk.hochpass.uni-hannover.de (8.14.7/8.14.7) with SMTP id s5PJm85v017429; Wed, 25 Jun 2014 21:48:08 +0200 (CEST) (envelope-from hilko.meyer@gmx.de) From: Hilko Meyer To: John Baldwin Subject: Re: powerd stopped working after update from 8.4 to 9.2 Date: Wed, 25 Jun 2014 21:48:07 +0200 Message-ID: References: <201406241623.39328.jhb@freebsd.org> <201406251017.31861.jhb@freebsd.org> In-Reply-To: <201406251017.31861.jhb@freebsd.org> X-Mailer: Forte Agent 1.93/32.576 English (American) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: freebsd-acpi@freebsd.org, freebsd-stable@freebsd.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jun 2014 19:48:17 -0000 On Wed, 25 Jun 2014 10:17:31 -0400, John Baldwin wrote: >On Wednesday, June 25, 2014 8:03:58 am Hilko Meyer wrote: >> John Baldwin schrieb: >> >On Tuesday, June 24, 2014 1:36:41 pm Hilko Meyer wrote: >> >> On Tue, 24 Jun 2014 10:26:52 -0400, you wrote: >> >> >On Monday, June 23, 2014 7:12:23 pm Hilko Meyer wrote: >> >> >> John Baldwin wrote: >> >> >> >On Sunday, June 22, 2014 9:27:08 pm Hilko Meyer wrote: >> >> >> >> >> >> >> >> powerd doesn't work anymore after the update from 8.4 to 9.2. The >system >> >> >> >> has an old (more than 10 years) mainboard with Via KT133 chipset. >> >> >> >> >> >> >> >> I made a verbose boot with both, 8.4 and 9.2: >> >> >> >> 8.4: http://pastebin.com/iiZXRXgK >> >> >> >> 9.2: http://pastebin.com/sHcd3MHv >> >> >> >> The relevant part of the diff seem to be these parts: >> >> >> >> >> >> >> >> viapropm0: SMBus I/O base at 0x5000 >> >> >> >> viapropm0: SMBus I/O base at 0x5000 >> >> >> >> viapropm0: port >0x5000-0x500f at >> >> >> >> device 7.4 on pci0 >> >> >> >> -viapropm0: SMBus revision code 0x40 >> >> >> >> -smbus0: on viapropm0 >> >> >> >> -smb0: on smbus0 >> >> >> >> +viapropm0: could not allocate bus space >> >> >> >> +device_attach: viapropm0 attach returned 6 >> >> >> >> […] >> >> >> >> acpi_throttle0: on cpu0 >> >> >> >> -acpi_throttle0: P_CNT from P_BLK 0x4010 >> >> >> >> +acpi_throttle0: failed to attach P_CNT >> >> >> >> +device_attach: acpi_throttle0 attach returned 6 >> >> >> >> >> >> >> >> Any ideas what I can do? >> >> >> > >> >> >> >acpi_timer0 also failed to probe due to a resource issue. Can you get >the >> >> >> >output of 'devinfo -rv' and 'devinfo -u' from the both kernels? >> >> >> >> >> >> Yes, no problem. >> >> >> devinfo -rv: >> >> >> 8.4: http://pastebin.com/6xm1tBrU >> >> >> 9.2: http://pastebin.com/whXk32Ab >> >> >> >> >> >> devinfo -u: >> >> >> 8.4: http://pastebin.com/47U7HZb3 >> >> >> 9.2: http://pastebin.com/U85HTw0C >> >> >> >> >> >> thanks for your help, >> >> >> Hilko >> >> > >> >> >Can you provide your acpidump? This box seems confusing. >> >> >> >> Well, its quite old. An Epox 8kta3 from around 2002. I was not sure which >output >> >> you need so I attached acpidump -d and acpidump -dt. >> > >> >Ok, try this: >> > >> >Index: sys/dev/acpica/acpi.c >> >> The patch doesn't apply. Was it for head or 9-stable and not for 9.2? > >It is for HEAD though it should apply to 9-stable. It might not apply to 9.2 >as it patches a previous fix that went to 9.2. For 9.2, please merge the >change to stable/9 from >http://svnweb.freebsd.org/base?view=revision&revision=263022 first and then >apply this patch. Thanks for the patch. Works now. Diff to the verbose dmesg without your patch: -acpi_timer0: couldn't allocate resource (port 0x4008) +ACPI timer: 1/1 1/1 1/1 1/1 1/1 1/1 1/1 1/1 1/1 1/1 -> 10 +Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 +acpi_timer0: <24-bit timer at 3.579545MHz> port 0x4008-0x400b on acpi0 [...] -pcib0: port 0xcf8-0xcff,0x4000-0x407f,0x4080-0x40ff,0x5000-0x500f,0x6000-0x607f on acpi0 +pcib0: port 0xcf8-0xcff on acpi0 [...] viapropm0: port 0x5000-0x500f at device 7.4 on pci0 -viapropm0: could not allocate bus space -device_attach: viapropm0 attach returned 6 +viapropm0: SMBus revision code 0x40 +smbus0: on viapropm0 +smb0: on smbus0 [...] acpi_throttle0: on cpu0 -acpi_throttle0: failed to attach P_CNT -device_attach: acpi_throttle0 attach returned 6 +acpi_throttle0: P_CNT from P_BLK 0x4010 I could start powerd again. Thanks for your help, Hilko PS: Just for the record, output of dmesg and devinfo from the working system with your patch: devinfo -rv: http://pastebin.com/whga6mxc devinfo -u: http://pastebin.com/xQLdCWTz dmesg -v : http://pastebin.com/jtLmsJzs From owner-freebsd-acpi@FreeBSD.ORG Wed Jun 25 20:31:51 2014 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 17AA0418; Wed, 25 Jun 2014 20:31:51 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E1E1E2294; Wed, 25 Jun 2014 20:31:50 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 3E0CFB945; Wed, 25 Jun 2014 16:31:49 -0400 (EDT) From: John Baldwin To: Hilko Meyer Subject: Re: powerd stopped working after update from 8.4 to 9.2 Date: Wed, 25 Jun 2014 16:31:39 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20140415; KDE/4.5.5; amd64; ; ) References: <201406251017.31861.jhb@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201406251631.39345.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 25 Jun 2014 16:31:49 -0400 (EDT) Cc: freebsd-acpi@freebsd.org, freebsd-stable@freebsd.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jun 2014 20:31:51 -0000 On Wednesday, June 25, 2014 3:48:07 pm Hilko Meyer wrote: > On Wed, 25 Jun 2014 10:17:31 -0400, John Baldwin wrote: > >It is for HEAD though it should apply to 9-stable. It might not apply to 9.2 > >as it patches a previous fix that went to 9.2. For 9.2, please merge the > >change to stable/9 from > >http://svnweb.freebsd.org/base?view=revision&revision=263022 first and then > >apply this patch. > > Thanks for the patch. Works now. Diff to the verbose dmesg without your patch: > > -acpi_timer0: couldn't allocate resource (port 0x4008) > +ACPI timer: 1/1 1/1 1/1 1/1 1/1 1/1 1/1 1/1 1/1 1/1 -> 10 > +Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 > +acpi_timer0: <24-bit timer at 3.579545MHz> port 0x4008-0x400b on acpi0 > [...] > -pcib0: port > 0xcf8-0xcff,0x4000-0x407f,0x4080-0x40ff,0x5000-0x500f,0x6000-0x607f on acpi0 > +pcib0: port 0xcf8-0xcff on acpi0 > [...] > viapropm0: port 0x5000-0x500f at device > 7.4 on pci0 > -viapropm0: could not allocate bus space > -device_attach: viapropm0 attach returned 6 > +viapropm0: SMBus revision code 0x40 > +smbus0: on viapropm0 > +smb0: on smbus0 > [...] > acpi_throttle0: on cpu0 > -acpi_throttle0: failed to attach P_CNT > -device_attach: acpi_throttle0 attach returned 6 > +acpi_throttle0: P_CNT from P_BLK 0x4010 > > I could start powerd again. > > Thanks for your help, > Hilko > > PS: Just for the record, output of dmesg and devinfo from the working system > with your patch: > devinfo -rv: http://pastebin.com/whga6mxc > devinfo -u: http://pastebin.com/xQLdCWTz > dmesg -v : http://pastebin.com/jtLmsJzs Committed to HEAD. It won't make 9.3 release, but it should be in 10.1. Thanks for the report and for testing! -- John Baldwin From owner-freebsd-acpi@FreeBSD.ORG Wed Jun 25 22:29:21 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 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0B3A84F1 for ; Wed, 25 Jun 2014 22:29:21 +0000 (UTC) Received: from mail-la0-x22b.google.com (mail-la0-x22b.google.com [IPv6:2a00:1450:4010:c03::22b]) (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 899402C91 for ; Wed, 25 Jun 2014 22:29:20 +0000 (UTC) Received: by mail-la0-f43.google.com with SMTP id e16so1249824lan.2 for ; Wed, 25 Jun 2014 15:29:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:date:to:cc:subject:message-id:mime-version:content-type :content-disposition; bh=QZZExwTS1n6d5rIUdTgOGln22GLAx07cp7Dtb13JP30=; b=GXhlaRdV7BKueKuQBXjVEwZRYGlYwNIdoGcKjEP9LOWU67iD1BsfzLFHxYdMzX+AWV MvqThcebfPQWs8DJFR7bgNxGhS/WugUQXR1fmY0wuLaXIAwnFdaJZzKtudEHqKMVBLnh IhDxyhLAn7UawfKQ70NUY5q75KQqfLLBU3woJdS/rdNqYgzsJCZl6fMhEvRg6Gpq2Ax4 CBmN60zWpmuGhlS+iih8Xmp7BaKIBaZ7Y5o/lfwL2C+nEQLNAZs6CmJwjjBwNeAOXwF4 7FQl0SAWmjZ3nT8qiwp5fVceSS9Xyz5pZ0c5xOhN3yVoUzi8nZiS2KqZuuJL/R6YH5HF t96g== X-Received: by 10.152.242.164 with SMTP id wr4mr7814678lac.38.1403735357267; Wed, 25 Jun 2014 15:29:17 -0700 (PDT) Received: from hellgate.localdomain (b217-29-190-130.pppoe.mark-itt.net. [217.29.190.130]) by mx.google.com with ESMTPSA id ar1sm5089261lbc.3.2014.06.25.15.29.15 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 25 Jun 2014 15:29:16 -0700 (PDT) From: Bykov Vladislav X-Google-Original-From: Bykov Vladislav Received: by hellgate.localdomain (Postfix, from userid 1001) id B4082F4ED7C; Thu, 26 Jun 2014 02:29:11 +0400 (MSK) Date: Thu, 26 Jun 2014 02:29:11 +0400 To: freebsd-acpi@freebsd.org Subject: Impossible shutdown Message-ID: <20140625222911.GA34447@hellgate.Dlink> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Cc: envolyse@gmail.com X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jun 2014 22:29:21 -0000 Hello. I have a problem with ACPI on HP Envy 4 that causes in impossible shutdown. It reaches an error while prepairing to shutdown, and reboots the machine. I already did sent a bug report about 2-3 months ago, but things doesn't seems to move on. Here's an error when booting the machine: ACPI Error: No handler for Region [RCM0] (0xfffffe0002b0f800) [SystemCMOS] (20110527/evregion-421) ACPI Error: Region SystemCMOS (ID=5) has no handler (20110527/exfldio-310) ACPI Error: Method parse/execution failed [\134_SB_.WMID.ESDT] (Node 0xfffffe0002aee440), AE_NOT_EXIST (20110527/psparse-560) ACPI Error: Method parse/execution failed [\134_SB_.PCI0.LPCB.EC0_._Q42] (Node 0xfffffe0002b16d40), AE_NOT_EXIST (20110527/psparse-560) acpi_ec0: evaluation of query method _Q42 failed: AE_NOT_EXIST And here's the one when I'm trying to shut it down: usbus2: Controller shutdown complete ACPI Error: No handler for Region [RCM0] (0xfffffe0002b15900) [SystemCMOS] (20110527/evregion-421) ACPI Error: Region SystemCMOS (ID=5) has no handler (20110527/exfldio-310) ACPI Error: Method parse/execution failed [\_SB_.WMID.ESDT] (Node 0xfffffe0002af5800), AE_NOT_EXIST (20110527/psparse-560) ACPI Error: Method parse/execution failed [\_PTS] (Node 0xfffffe0002af86c0), AE_NOT_EXIST (20110527/psparse-560) acpi0: AcpiEnterSleepStatePrep failed - AE_NOT_EXIST Rebooting... I've tried FreeBSD 9, FreeBSD 10, and -CURRENT. All have the same problem. Sincerely, Vladislav. From owner-freebsd-acpi@FreeBSD.ORG Thu Jun 26 11:47:17 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 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 81ABF81F for ; Thu, 26 Jun 2014 11:47:17 +0000 (UTC) Received: from nm4-vm3.access.bullet.mail.bf1.yahoo.com (nm4-vm3.access.bullet.mail.bf1.yahoo.com [216.109.114.114]) (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 30BF02F2E for ; Thu, 26 Jun 2014 11:47:16 +0000 (UTC) Received: from [66.196.81.164] by nm4.access.bullet.mail.bf1.yahoo.com with NNFMP; 26 Jun 2014 11:44:36 -0000 Received: from [98.138.104.96] by tm10.access.bullet.mail.bf1.yahoo.com with NNFMP; 26 Jun 2014 11:44:36 -0000 Received: from [127.0.0.1] by smtp116.sbc.mail.ne1.yahoo.com with NNFMP; 26 Jun 2014 11:44:36 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1403783076; bh=LCFp+zfbs6G4C8dg/bNpL6X37a+MufayrvMrY2U+ios=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=bIPdqkB4vJwAPB9ivEv74C1BtIX1yfvvhpPs2qbxLEhWNOuv+V8x+amnCmoTngUz49/g58CUQvZSXfpV4QUXZZgM9krMOlwU536aXK71NCVhAYkvf9BXAD1BNqTkTPXEPCQ0P9jpSyHByxk7Jh4zLVlfbAQDO+jP4dZX7b5Stkc= X-Yahoo-Newman-Id: 389642.31944.bm@smtp116.sbc.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: u0zQrz4VM1mm01ZIHPrYn8kHt6hu5vfvITIY1cbjHxgwrZi Kl0OhMm7HlENTTObjb1BhaZUTyfUz9wGa3424KQeqYBk5DYQgXycefm92Ey2 LBWTOEcsgljQBmXh0lc_KYFFeos2qr1oliMG0.F4VmD5dIAL.P6nZd9pDcmK gCStE3jo4Lq4oiRRIaJIYftS0wVAZ_.4DJz0haQguClS.mWQHuj9TW2VO6VE AYYGHqzstzBHWdgcp5OOZBMH5Ri16zANSYkqn0kRtNsb1m9WQxfaQXR5ksWa f2WPSkftcudb9wBvdxLjYd5P4N8_F_QSNDJu9j9rXZPQJKa91a2.5pAimwmj Lq3_DLYrTUE..hrTmTwOfPSWCLMiJRVLtWT9H4PNvxaxq6bhj1EiCAWeTi9s JTkkww4ib_URdXp6YTQP1s0u3AD64lzIbrTEJOGLBPPUcif56D1Gon.k6jKB ptgvbCkDXWcowSiZrY1FU2GPv.GoDmm06tqM3a1KGq0uY2ywFzGSZ8WCP3on WbXGTBzrZq2y174wf1yvJcLCon.5finXvBsMIXsjCfRcnb3cvdJ8- X-Yahoo-SMTP: OKD1keCswBBTAmAF1s00hLyKW3wE3YfSK0Eazl6b4VZG4LTqJxg- X-Rocket-Received: from [10.0.1.177] (Anthony.B.Jenkins@70.90.74.161 with plain [98.138.84.52]) by smtp116.sbc.mail.ne1.yahoo.com with SMTP; 26 Jun 2014 11:44:36 +0000 UTC Message-ID: <53AC07A3.7070904@att.net> Date: Thu, 26 Jun 2014 07:44:35 -0400 From: Anthony Jenkins User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Bykov Vladislav , freebsd-acpi@freebsd.org Subject: Re: Impossible shutdown References: <20140625222911.GA34447@hellgate.Dlink> In-Reply-To: <20140625222911.GA34447@hellgate.Dlink> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jun 2014 11:47:17 -0000 On 06/25/2014 18:29, Bykov Vladislav wrote: > Hello. > > I have a problem with ACPI on HP Envy 4 that causes in impossible shutdown. It > reaches an error while prepairing to shutdown, and reboots the machine. > > I already did sent a bug report about 2-3 months ago, but things doesn't seems > to move on. > > Here's an error when booting the machine: > > ACPI Error: No handler for Region [RCM0] (0xfffffe0002b0f800) [SystemCMOS] (20110527/evregion-421) > ACPI Error: Region SystemCMOS (ID=5) has no handler (20110527/exfldio-310) > ACPI Error: Method parse/execution failed [\134_SB_.WMID.ESDT] (Node 0xfffffe0002aee440), AE_NOT_EXIST (20110527/psparse-560) > ACPI Error: Method parse/execution failed [\134_SB_.PCI0.LPCB.EC0_._Q42] (Node 0xfffffe0002b16d40), AE_NOT_EXIST (20110527/psparse-560) > acpi_ec0: evaluation of query method _Q42 failed: AE_NOT_EXIST > > And here's the one when I'm trying to shut it down: > > usbus2: Controller shutdown complete > ACPI Error: No handler for Region [RCM0] (0xfffffe0002b15900) [SystemCMOS] (20110527/evregion-421) > ACPI Error: Region SystemCMOS (ID=5) has no handler (20110527/exfldio-310) > ACPI Error: Method parse/execution failed [\_SB_.WMID.ESDT] (Node 0xfffffe0002af5800), AE_NOT_EXIST (20110527/psparse-560) > ACPI Error: Method parse/execution failed [\_PTS] (Node 0xfffffe0002af86c0), AE_NOT_EXIST (20110527/psparse-560) > acpi0: AcpiEnterSleepStatePrep failed - AE_NOT_EXIST > Rebooting... > > I've tried FreeBSD 9, FreeBSD 10, and -CURRENT. All have the same problem. Here's a case where my patch to implement the SystemCMOS region handler should help; it allows my HP Envy to power down and allows it to suspend/resume except the LCD backlight doesn't come back when resuming. Biggest problem with the patch IMHO is I'm stealing ("borrowing") from the real time clock (RTC) I/O region, but I don't think we have an "actual" FreeBSD driver for that. Reposting here, or search this list for "Naive implementation of AcpiExCmosSpaceHandler", let me know if it doesn't apply cleanly to your version of FreeBSD . I've posted it upstream to the acpica mailing list, but no response. diff --git a/source/components/events/evhandler.c b/source/components/events/evhandler.c index d17411e..4f341ca 100644 --- a/source/components/events/evhandler.c +++ b/source/components/events/evhandler.c @@ -142,6 +142,7 @@ UINT8 AcpiGbl_DefaultAddressSpaces[ACPI_NUM_DEFAULT_SPACES] = ACPI_ADR_SPACE_SYSTEM_MEMORY, ACPI_ADR_SPACE_SYSTEM_IO, ACPI_ADR_SPACE_PCI_CONFIG, + ACPI_ADR_SPACE_CMOS, ACPI_ADR_SPACE_DATA_TABLE }; @@ -451,9 +452,12 @@ AcpiEvInstallSpaceHandler ( */ if ((Node->Type != ACPI_TYPE_DEVICE) && (Node->Type != ACPI_TYPE_PROCESSOR) && + (Node->Type != ACPI_TYPE_REGION) && (Node->Type != ACPI_TYPE_THERMAL) && (Node != AcpiGbl_RootNode)) { + ACPI_DEBUG_PRINT ((ACPI_DB_OPREGION, + "Device %p not a DEVICE, PROCESSOR, REGION, THERMAL type or root node.\n", Node)); Status = AE_BAD_PARAMETER; goto UnlockAndExit; } diff --git a/source/components/executer/exregion.c b/source/components/executer/exregion.c index ea10a01..bfdd721 100644 --- a/source/components/executer/exregion.c +++ b/source/components/executer/exregion.c @@ -521,6 +521,20 @@ AcpiExPciConfigSpaceHandler ( return_ACPI_STATUS (Status); } +static UINT8 AcpiExCmosRead(ACPI_PHYSICAL_ADDRESS Address) +{ + UINT32 Value32; + + AcpiHwWritePort((ACPI_IO_ADDRESS) 0x70, (UINT32) Address, 8); + AcpiHwReadPort ((ACPI_IO_ADDRESS) 0x71, &Value32, 8); + return Value32 & 0xFF; +} + +static void AcpiExCmosWrite(ACPI_PHYSICAL_ADDRESS Address, UINT8 Value) +{ + AcpiHwWritePort((ACPI_IO_ADDRESS) 0x70, (UINT32) Address, 8); + AcpiHwWritePort((ACPI_IO_ADDRESS) 0x71, (UINT32) Value, 8); +} /******************************************************************************* * @@ -545,7 +559,7 @@ AcpiExCmosSpaceHandler ( UINT32 Function, ACPI_PHYSICAL_ADDRESS Address, UINT32 BitWidth, - UINT64 *Value, + UINT64 *Value64, void *HandlerContext, void *RegionContext) { @@ -554,7 +568,23 @@ AcpiExCmosSpaceHandler ( ACPI_FUNCTION_TRACE (ExCmosSpaceHandler); - + if (Address < 0x80 && + (Function == ACPI_READ || Function == ACPI_WRITE) && + BitWidth <= 64) + { + UINT32 i; + UINT8 *Value = (UINT8 *)Value64; + + for (i = 0; i < (BitWidth + 7) / 8; ++i, ++Address, ++Value) { + if (Function == ACPI_READ) { + *Value = AcpiExCmosRead(Address); + } else { + AcpiExCmosWrite(Address, *Value); + } + } + } else { + Status = AE_BAD_PARAMETER; + } return_ACPI_STATUS (Status); } diff --git a/source/include/acconfig.h b/source/include/acconfig.h index 6b34484..7fe2eac 100644 --- a/source/include/acconfig.h +++ b/source/include/acconfig.h @@ -270,7 +270,7 @@ /* Maximum SpaceIds for Operation Regions */ #define ACPI_MAX_ADDRESS_SPACE 255 -#define ACPI_NUM_DEFAULT_SPACES 4 +#define ACPI_NUM_DEFAULT_SPACES 5 /* Array sizes. Used for range checking also */ Sincerely, Vladislav. _______________________________________________ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to "freebsd-acpi-unsubscribe@freebsd.org" From owner-freebsd-acpi@FreeBSD.ORG Thu Jun 26 15:24:10 2014 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6CF7BBFF for ; Thu, 26 Jun 2014 15:24:10 +0000 (UTC) Received: from mail-la0-x230.google.com (mail-la0-x230.google.com [IPv6:2a00:1450:4010:c03::230]) (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 E7F6E2507 for ; Thu, 26 Jun 2014 15:24:09 +0000 (UTC) Received: by mail-la0-f48.google.com with SMTP id el20so1969103lab.21 for ; Thu, 26 Jun 2014 08:24:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:date:to:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to; bh=HiomStwcAT9rdeautvmDZo4Eygsjc6uqRL7pBOdJHxo=; b=eeRef9AVy6nwjVpyv/H/KCMU0zuocUSaPw1V6St0kE9T0Y0Y3ayJ6eS0q2lFjt43mo eeWaS4QsERaL/Fm3D4AaYaAUQkeYRDZ9gU6xTlkmUvllK1KMspaGnf1txKFd4CjEbD/r fvppuSwjNKEyYXGRoH066gxfsp4LhE4QU74YCjN8YY5dKlZviwNdS2Wd3TDWSchx08QJ H2VA/30Pe6a6mAFdpqSZ9C09Ox71p0TRpYUyuBMrt2TFx+Ms6tS71U5CPZtRHzDlDys9 OHekh7DDV87nMYTU+kRS2pQmRUebIEondd5Kvb91wRK3jwXp3dhKuLBhdHAPZNzAIzcq cP6w== X-Received: by 10.152.234.201 with SMTP id ug9mr2409590lac.73.1403796247237; Thu, 26 Jun 2014 08:24:07 -0700 (PDT) Received: from hellgate.localdomain (b217-29-190-130.pppoe.mark-itt.net. [217.29.190.130]) by mx.google.com with ESMTPSA id o1sm7916176lbw.27.2014.06.26.08.24.05 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 26 Jun 2014 08:24:06 -0700 (PDT) From: Bykov Vladislav X-Google-Original-From: Bykov Vladislav Received: by hellgate.localdomain (Postfix, from userid 1001) id 7AF68F4ED7C; Thu, 26 Jun 2014 19:23:58 +0400 (MSK) Date: Thu, 26 Jun 2014 19:23:58 +0400 To: Anthony Jenkins , freebsd-acpi@freebsd.org Subject: Re: Impossible shutdown Message-ID: <20140626152358.GA2205@hellgate.Dlink> References: <20140625222911.GA34447@hellgate.Dlink> <53AC07A3.7070904@att.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <53AC07A3.7070904@att.net> X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jun 2014 15:24:10 -0000 On Thu, Jun 26, 2014 at 07:44:35AM -0400, Anthony Jenkins wrote: > Here's a case where my patch to implement the SystemCMOS region handler > should help; it allows my HP Envy to power down and allows it to > suspend/resume except the LCD backlight doesn't come back when resuming. > Biggest problem with the patch IMHO is I'm stealing ("borrowing") from the > real time clock (RTC) I/O region, but I don't think we have an "actual" > FreeBSD driver for that. Thanks, everyting works fine now. Even suspend, except my video driver (xf86-video-intel) that goes mad, and after resume everything is laggy. info: [drm] Changing LVDS panel from (+hsync, -vsync) to (-hsync, -vsync) info: [drm] Changing LVDS panel from (-hsync, -vsync) to (+hsync, -vsync) error: [drm:pid1170:intel_lvds_enable] *ERROR* timed out waiting for panel to power off By the way, I've tried all suspend types, but only this correctly resume the system: /etc/rc.suspend apm 1 From owner-freebsd-acpi@FreeBSD.ORG Thu Jun 26 15:41:16 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 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3DDD334A for ; Thu, 26 Jun 2014 15:41:16 +0000 (UTC) Received: from nm18-vm1.access.bullet.mail.gq1.yahoo.com (nm18-vm1.access.bullet.mail.gq1.yahoo.com [216.39.63.16]) (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 0AC1626D0 for ; Thu, 26 Jun 2014 15:41:15 +0000 (UTC) Received: from [216.39.60.173] by nm18.access.bullet.mail.gq1.yahoo.com with NNFMP; 26 Jun 2014 15:38:35 -0000 Received: from [98.138.226.241] by tm9.access.bullet.mail.gq1.yahoo.com with NNFMP; 26 Jun 2014 15:38:35 -0000 Received: from [127.0.0.1] by smtp112.sbc.mail.ne1.yahoo.com with NNFMP; 26 Jun 2014 15:38:35 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1403797115; bh=lwrl/nI1NoDplvHXciBGorr6Vhv67x1DgK9dV5ZD77I=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=0tNJI4rknhTe/o41sGWk7yvcNglqXXd6TA5CMJ2jWp2d6f9UBO6RtCk/25bSHEl8N50mzVjW/vTb62LzjP+ww3bqOVdOmZWmzku9H09DeGNWnqDYIHxmt9Vq/hLz6QJBG61u0/qQ0vbzbGvPhZQmtN1OXlrjd1CoH853x4Yz/So= X-Yahoo-Newman-Id: 162926.99830.bm@smtp112.sbc.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: E3ioImcVM1meqdI8HJN.t7Z9brBRydHuklLykOUbI1PWM12 G9I9kgxWrZaAKQlE8ZomHT1tvck6q6.yatedZJiI5YewrLe6At4jxg89Fomy h6Detd8SPo0j6UrWy.JLU7N6OnB0tBAjhp8tK8iOqQlDKPEwokWq8B1wlEK0 Ka2cmRR5kEEKBikHHHfImpkS8HfHaZXmi1y5o7FSBK7dWHXvhZ2HQ_JWvXj4 PaLJyxs4FBdMYoIr3jpj_dmJTtnt0VCj397NCuBjg_wBJOoPanbxK3EKaypK YmwUGo6xFJwUp4H4VDFvLGTA5RhyR1W_tviN52TMPWP0DtVvoCUnWbaXdPnr DJNUkkfyXsRdfldysEztSgo9iSpQIRmCA0D9w5KmHNkai8etoSqDity62wlT Kw1WB0RwIX.3zEAfTMZUTeYVKOUEYyjEh_BjpHqoNCEaraHeibYcOJcJhANW UCzCaJ8FDedoiiB0ry_785wKiDwe1I1Fw_0OX7N.DIiR5q9NkzitSYW34N0L PIHWMWh41BE4uj3ImJHsbK7q2D1cOoOa7X_P1NQO.lKEF4EDia5tSQE5EN3C Q0Q0.NA-- X-Yahoo-SMTP: OKD1keCswBBTAmAF1s00hLyKW3wE3YfSK0Eazl6b4VZG4LTqJxg- X-Rocket-Received: from [10.82.232.78] (Anthony.B.Jenkins@64.102.254.33 with plain [98.138.84.52]) by smtp112.sbc.mail.ne1.yahoo.com with SMTP; 26 Jun 2014 08:38:35 -0700 PDT Message-ID: <53AC3E79.9000708@att.net> Date: Thu, 26 Jun 2014 11:38:33 -0400 From: Anthony Jenkins User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Bykov Vladislav , freebsd-acpi@freebsd.org Subject: Re: Impossible shutdown References: <20140625222911.GA34447@hellgate.Dlink> <53AC07A3.7070904@att.net> <20140626152358.GA2205@hellgate.Dlink> In-Reply-To: <20140626152358.GA2205@hellgate.Dlink> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jun 2014 15:41:16 -0000 On 06/26/2014 11:23, Bykov Vladislav wrote: > On Thu, Jun 26, 2014 at 07:44:35AM -0400, Anthony Jenkins wrote: >> Here's a case where my patch to implement the SystemCMOS region handler >> should help; it allows my HP Envy to power down and allows it to >> suspend/resume except the LCD backlight doesn't come back when resuming. >> Biggest problem with the patch IMHO is I'm stealing ("borrowing") from the >> real time clock (RTC) I/O region, but I don't think we have an "actual" >> FreeBSD driver for that. > Thanks, everyting works fine now. Even suspend, except my video driver > (xf86-video-intel) that goes mad, and after resume everything is laggy. Hooray! Maybe I can shove it into -CURRENT... > info: [drm] Changing LVDS panel from (+hsync, -vsync) to (-hsync, -vsync) > info: [drm] Changing LVDS panel from (-hsync, -vsync) to (+hsync, -vsync) > error: [drm:pid1170:intel_lvds_enable] *ERROR* timed out waiting for panel to power off > > By the way, I've tried all suspend types, but only this correctly resume > the system: > > /etc/rc.suspend apm 1 That's wierd (and also not weird).../etc/rc.suspend (at least on my -CURRENT r267519) doesn't even appear to use the '1' argument, and it's just calling /usr/sbin/zzz with the 'apm' argument (which I believe still does an ACPI suspend). My patch is an ACPI patch anyway. People on this list have been wrangling with the Intel driver, there might be fixes for what you're seeing. Anthony > _______________________________________________ > freebsd-acpi@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-acpi > To unsubscribe, send any mail to "freebsd-acpi-unsubscribe@freebsd.org" > From owner-freebsd-acpi@FreeBSD.ORG Fri Jun 27 05:16:36 2014 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5E8CE273 for ; Fri, 27 Jun 2014 05:16:36 +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 9CF7920D6 for ; Fri, 27 Jun 2014 05:16:34 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id s5R5GKJO053604; Fri, 27 Jun 2014 15:16:21 +1000 (EST) (envelope-from smithi@nimnet.asn.au) Date: Fri, 27 Jun 2014 15:16:20 +1000 (EST) From: Ian Smith To: Anthony Jenkins Subject: Re: Impossible shutdown In-Reply-To: <53AC07A3.7070904@att.net> Message-ID: <20140627143031.P50382@sola.nimnet.asn.au> References: <20140625222911.GA34447@hellgate.Dlink> <53AC07A3.7070904@att.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: Bykov Vladislav , freebsd-acpi@freebsd.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jun 2014 05:16:36 -0000 On Thu, 26 Jun 2014 07:44:35 -0400, Anthony Jenkins wrote: > On 06/25/2014 18:29, Bykov Vladislav wrote: > > Hello. > > > > I have a problem with ACPI on HP Envy 4 that causes in impossible shutdown. It > > reaches an error while prepairing to shutdown, and reboots the machine. > > > > I already did sent a bug report about 2-3 months ago, but things doesn't seems > > to move on. > > > > Here's an error when booting the machine: > > > > ACPI Error: No handler for Region [RCM0] (0xfffffe0002b0f800) [SystemCMOS] (20110527/evregion-421) > > ACPI Error: Region SystemCMOS (ID=5) has no handler (20110527/exfldio-310) > > ACPI Error: Method parse/execution failed [\134_SB_.WMID.ESDT] (Node 0xfffffe0002aee440), AE_NOT_EXIST (20110527/psparse-560) > > ACPI Error: Method parse/execution failed [\134_SB_.PCI0.LPCB.EC0_._Q42] (Node 0xfffffe0002b16d40), AE_NOT_EXIST (20110527/psparse-560) > > acpi_ec0: evaluation of query method _Q42 failed: AE_NOT_EXIST > > > > And here's the one when I'm trying to shut it down: > > > > usbus2: Controller shutdown complete > > ACPI Error: No handler for Region [RCM0] (0xfffffe0002b15900) [SystemCMOS] (20110527/evregion-421) > > ACPI Error: Region SystemCMOS (ID=5) has no handler (20110527/exfldio-310) > > ACPI Error: Method parse/execution failed [\_SB_.WMID.ESDT] (Node 0xfffffe0002af5800), AE_NOT_EXIST (20110527/psparse-560) > > ACPI Error: Method parse/execution failed [\_PTS] (Node 0xfffffe0002af86c0), AE_NOT_EXIST (20110527/psparse-560) > > acpi0: AcpiEnterSleepStatePrep failed - AE_NOT_EXIST > > Rebooting... > > > > I've tried FreeBSD 9, FreeBSD 10, and -CURRENT. All have the same problem. > > Here's a case where my patch to implement the SystemCMOS region > handler should help; it allows my HP Envy to power down and allows it > to suspend/resume except the LCD backlight doesn't come back when > resuming. Biggest problem with the patch IMHO is I'm stealing > ("borrowing") from the real time clock (RTC) I/O region, but I don't > think we have an "actual" FreeBSD driver for that. > > Reposting here, or search this list for "Naive implementation of > AcpiExCmosSpaceHandler", let me know if it doesn't apply cleanly to > your version of FreeBSD . I've posted it upstream to the acpica > mailing list, but no response. > > diff --git a/source/components/events/evhandler.c b/source/components/events/evhandler.c Interesting. I wonder if this is needed for reading the RTC for the time on boot, and writing it back on shutdown - which I would have thought too generic to have left out on any machine? Or is this perhaps retrieving at boot then restoring at shutdown some other system-specific information in NVRAM? If the latter, then the usage in /sys/dev/acpi_support/acpi_ibm.c revealed below might illustrate another way of dealing with this? % find /sys/ -type f -exec egrep -H 'rtcin|writertc' {} \; | grep -v drm_mode_set_crtcinfo shows everything using the rtcin() and writertc() functions, implemented for x86 at least in /sys/x86/isa/atrtc.c .. but I have no idea whether you can access those functions from where / when you're tinkering here. Yours looks more likely portable for upstream acpica, but it also looks potentially quite dangerous 'in the wrong hands' :) cheers, Ian From owner-freebsd-acpi@FreeBSD.ORG Fri Jun 27 20:49:01 2014 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 180453F6 for ; Fri, 27 Jun 2014 20:49:01 +0000 (UTC) Received: from nm9-vm7.access.bullet.mail.bf1.yahoo.com (nm9-vm7.access.bullet.mail.bf1.yahoo.com [216.109.114.198]) (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 BC1172B1E for ; Fri, 27 Jun 2014 20:49:00 +0000 (UTC) Received: from [66.196.81.158] by nm9.access.bullet.mail.bf1.yahoo.com with NNFMP; 27 Jun 2014 20:48:58 -0000 Received: from [98.138.104.96] by tm4.access.bullet.mail.bf1.yahoo.com with NNFMP; 27 Jun 2014 20:48:58 -0000 Received: from [127.0.0.1] by smtp116.sbc.mail.ne1.yahoo.com with NNFMP; 27 Jun 2014 20:48:58 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1403902138; bh=eRJndhO/gLOZS/+cS2W5lM+sguyS+ENfKyM/Q27Uvyk=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=mGQJld6C/9R7GGfHZXqnIDX/5ZYCujcDGTNIrS41s1Z/fSGU1JTQV1w0prTq5ziNUuivivKShasbF476cqQH4XCs6KZ9EE6lDmr51i6nNx1DJ161dEHYYUXZRasZONSnGij19l1sZJMuk3M9dHqp5IEcBgySBfdIKJOgmOnMji4= X-Yahoo-Newman-Id: 579312.97843.bm@smtp116.sbc.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: fOWgWV8VM1l3ClK9pWTXs12mjm.EZisrmUCUO5x.sQbBFYN BAlGLtDLUcnbJi4XCPfbRx4j3DFgA7XOX1fENuveOu0wv1Az3ZGojpMAppZP btas_LFN2OTNF7R9md8zFpSTb0KB_OjXUsJNZEfoSVuNuVl9SWM3y9luverS K6olzjlTQ3Jpcd4d3AaHaQGLpP53h9oVkIN0rS4EvCIiIz1j44rSAv6YjfIA PtemuDzGc2Q.RHv3LLRgQzr8rR5D9froqasQaRPT_V76Lj_MERVBB7sWChCE .romLFutxHyuGyv3MAtVO9wSDkYcn9TQ.OZQpuM9tK09BBGFlApZ5EuT3tI4 r4UAZTtBePNlPL7hjVzXE7LV4iy8iEi8dDFw8tE.oF57ScQ1eGl90Dqg9_I6 4xskElNAgBKhtsg68vJ9qNffyQSsjVBf92RlEmQXuvH9A8y3wjUudyZQ2g8L 0SJeCt_sJJFU5732MJPJlGQ4SeiyhReCaeGbJGhIYfHET4hLcnn1iAMDJMFC 1BM.4jm_i9N4JHFrnrCo2e8P_mWPS6c5PmNYhDW72GazlKg-- X-Yahoo-SMTP: OKD1keCswBBTAmAF1s00hLyKW3wE3YfSK0Eazl6b4VZG4LTqJxg- X-Rocket-Received: from [64.100.76.67] (Anthony.B.Jenkins@64.100.76.67 with plain [98.138.84.52]) by smtp116.sbc.mail.ne1.yahoo.com with SMTP; 27 Jun 2014 20:48:58 +0000 UTC Message-ID: <53ADD8B9.5060401@att.net> Date: Fri, 27 Jun 2014 16:48:57 -0400 From: Anthony Jenkins User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Ian Smith Subject: Re: Impossible shutdown References: <20140625222911.GA34447@hellgate.Dlink> <53AC07A3.7070904@att.net> <20140627143031.P50382@sola.nimnet.asn.au> In-Reply-To: <20140627143031.P50382@sola.nimnet.asn.au> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Bykov Vladislav , freebsd-acpi@freebsd.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jun 2014 20:49:01 -0000 On 06/27/2014 01:16, Ian Smith wrote: > On Thu, 26 Jun 2014 07:44:35 -0400, Anthony Jenkins wrote: > > On 06/25/2014 18:29, Bykov Vladislav wrote: > > > Hello. > > > > > > I have a problem with ACPI on HP Envy 4 that causes in impossible shutdown. It > > > reaches an error while prepairing to shutdown, and reboots the machine. > > > > > > I already did sent a bug report about 2-3 months ago, but things doesn't seems > > > to move on. > > > > > > Here's an error when booting the machine: > > > > > > ACPI Error: No handler for Region [RCM0] (0xfffffe0002b0f800) [SystemCMOS] (20110527/evregion-421) > > > ACPI Error: Region SystemCMOS (ID=5) has no handler (20110527/exfldio-310) > > > ACPI Error: Method parse/execution failed [\134_SB_.WMID.ESDT] (Node 0xfffffe0002aee440), AE_NOT_EXIST (20110527/psparse-560) > > > ACPI Error: Method parse/execution failed [\134_SB_.PCI0.LPCB.EC0_._Q42] (Node 0xfffffe0002b16d40), AE_NOT_EXIST (20110527/psparse-560) > > > acpi_ec0: evaluation of query method _Q42 failed: AE_NOT_EXIST > > > > > > And here's the one when I'm trying to shut it down: > > > > > > usbus2: Controller shutdown complete > > > ACPI Error: No handler for Region [RCM0] (0xfffffe0002b15900) [SystemCMOS] (20110527/evregion-421) > > > ACPI Error: Region SystemCMOS (ID=5) has no handler (20110527/exfldio-310) > > > ACPI Error: Method parse/execution failed [\_SB_.WMID.ESDT] (Node 0xfffffe0002af5800), AE_NOT_EXIST (20110527/psparse-560) > > > ACPI Error: Method parse/execution failed [\_PTS] (Node 0xfffffe0002af86c0), AE_NOT_EXIST (20110527/psparse-560) > > > acpi0: AcpiEnterSleepStatePrep failed - AE_NOT_EXIST > > > Rebooting... > > > > > > I've tried FreeBSD 9, FreeBSD 10, and -CURRENT. All have the same problem. > > > > Here's a case where my patch to implement the SystemCMOS region > > handler should help; it allows my HP Envy to power down and allows it > > to suspend/resume except the LCD backlight doesn't come back when > > resuming. Biggest problem with the patch IMHO is I'm stealing > > ("borrowing") from the real time clock (RTC) I/O region, but I don't > > think we have an "actual" FreeBSD driver for that. > > > > Reposting here, or search this list for "Naive implementation of > > AcpiExCmosSpaceHandler", let me know if it doesn't apply cleanly to > > your version of FreeBSD . I've posted it upstream to the acpica > > mailing list, but no response. > > > > diff --git a/source/components/events/evhandler.c b/source/components/events/evhandler.c > > Interesting. I wonder if this is needed for reading the RTC for the > time on boot, and writing it back on shutdown - which I would have > thought too generic to have left out on any machine? Or is this perhaps > retrieving at boot then restoring at shutdown some other system-specific > information in NVRAM? It's the latter; they (presumably the BIOS ACPI shutdown/resume methods) are just reading/writing locations in the non-volatile CMOS storage, which just happens to be shared with the RTC. The RTC proper has some 16 bytes of registers which represent the real time clock - the rest are presumably storage, though the platform could probably do whatever it wants with various locations. > If the latter, then the usage in /sys/dev/acpi_support/acpi_ibm.c > revealed below might illustrate another way of dealing with this? > > % find /sys/ -type f -exec egrep -H 'rtcin|writertc' {} \; | grep -v drm_mode_set_crtcinfo > > shows everything using the rtcin() and writertc() functions, implemented > for x86 at least in /sys/x86/isa/atrtc.c .. but I have no idea whether > you can access those functions from where / when you're tinkering here. This is the way I think it's /supposed/ to be done - from my skimming of one of the ACPI specs, there's a PNP identifier for the CMOS/RTC device. If that identifier is probed, the OS should install a SystemCMOS region handler (which would use the I/O methods of the RTC driver which takes care of locking/consistency). > Yours looks more likely portable for upstream acpica, but it also looks > potentially quite dangerous 'in the wrong hands' :) Personally I don't think my patch can live upstream in acpica-land because it can step on the toes of an existing OS CMOS/RTC driver talking to the RTC I/O ports. I just don't know how to do all this with our rtc driver yet, particularly the PNPxxxxxx stuff. I'll look into it when I get some free cycles. > cheers, Ian > _______________________________________________ > freebsd-acpi@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-acpi > To unsubscribe, send any mail to "freebsd-acpi-unsubscribe@freebsd.org" > From owner-freebsd-acpi@FreeBSD.ORG Mon Jun 30 16:01:59 2014 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 898D6782 for ; Mon, 30 Jun 2014 16:01:59 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3165E2738 for ; Mon, 30 Jun 2014 16:01:59 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 9567FB924; Mon, 30 Jun 2014 12:01:57 -0400 (EDT) From: John Baldwin To: freebsd-acpi@freebsd.org Subject: Re: Impossible shutdown Date: Mon, 30 Jun 2014 10:43:54 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20140415; KDE/4.5.5; amd64; ; ) References: <20140625222911.GA34447@hellgate.Dlink> <20140627143031.P50382@sola.nimnet.asn.au> <53ADD8B9.5060401@att.net> In-Reply-To: <53ADD8B9.5060401@att.net> MIME-Version: 1.0 Message-Id: <201406301043.55003.jhb@freebsd.org> Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 30 Jun 2014 12:01:57 -0400 (EDT) Cc: Anthony Jenkins , Bykov Vladislav , Ian Smith X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jun 2014 16:01:59 -0000 On Friday, June 27, 2014 4:48:57 pm Anthony Jenkins wrote: > On 06/27/2014 01:16, Ian Smith wrote: > > On Thu, 26 Jun 2014 07:44:35 -0400, Anthony Jenkins wrote: > > > On 06/25/2014 18:29, Bykov Vladislav wrote: > > > > Hello. > > > > > > > > I have a problem with ACPI on HP Envy 4 that causes in impossible shutdown. It > > > > reaches an error while prepairing to shutdown, and reboots the machine. > > > > > > > > I already did sent a bug report about 2-3 months ago, but things doesn't seems > > > > to move on. > > > > > > > > Here's an error when booting the machine: > > > > > > > > ACPI Error: No handler for Region [RCM0] (0xfffffe0002b0f800) [SystemCMOS] (20110527/evregion-421) > > > > ACPI Error: Region SystemCMOS (ID=5) has no handler (20110527/exfldio-310) > > > > ACPI Error: Method parse/execution failed [\134_SB_.WMID.ESDT] (Node 0xfffffe0002aee440), AE_NOT_EXIST (20110527/psparse-560) > > > > ACPI Error: Method parse/execution failed [\134_SB_.PCI0.LPCB.EC0_._Q42] (Node 0xfffffe0002b16d40), AE_NOT_EXIST (20110527/psparse-560) > > > > acpi_ec0: evaluation of query method _Q42 failed: AE_NOT_EXIST > > > > > > > > And here's the one when I'm trying to shut it down: > > > > > > > > usbus2: Controller shutdown complete > > > > ACPI Error: No handler for Region [RCM0] (0xfffffe0002b15900) [SystemCMOS] (20110527/evregion-421) > > > > ACPI Error: Region SystemCMOS (ID=5) has no handler (20110527/exfldio-310) > > > > ACPI Error: Method parse/execution failed [\_SB_.WMID.ESDT] (Node 0xfffffe0002af5800), AE_NOT_EXIST (20110527/psparse-560) > > > > ACPI Error: Method parse/execution failed [\_PTS] (Node 0xfffffe0002af86c0), AE_NOT_EXIST (20110527/psparse-560) > > > > acpi0: AcpiEnterSleepStatePrep failed - AE_NOT_EXIST > > > > Rebooting... > > > > > > > > I've tried FreeBSD 9, FreeBSD 10, and -CURRENT. All have the same problem. > > > > > > Here's a case where my patch to implement the SystemCMOS region > > > handler should help; it allows my HP Envy to power down and allows it > > > to suspend/resume except the LCD backlight doesn't come back when > > > resuming. Biggest problem with the patch IMHO is I'm stealing > > > ("borrowing") from the real time clock (RTC) I/O region, but I don't > > > think we have an "actual" FreeBSD driver for that. > > > > > > Reposting here, or search this list for "Naive implementation of > > > AcpiExCmosSpaceHandler", let me know if it doesn't apply cleanly to > > > your version of FreeBSD . I've posted it upstream to the acpica > > > mailing list, but no response. > > > > > > diff --git a/source/components/events/evhandler.c b/source/components/events/evhandler.c > > > > Interesting. I wonder if this is needed for reading the RTC for the > > time on boot, and writing it back on shutdown - which I would have > > thought too generic to have left out on any machine? Or is this perhaps > > retrieving at boot then restoring at shutdown some other system-specific > > information in NVRAM? > It's the latter; they (presumably the BIOS ACPI shutdown/resume methods) are just reading/writing locations in the non-volatile CMOS storage, which just happens to be shared with the RTC. The RTC proper has some 16 bytes of registers which represent the real time clock - the rest are presumably storage, though the platform could probably do whatever it wants with various locations. > > > If the latter, then the usage in /sys/dev/acpi_support/acpi_ibm.c > > revealed below might illustrate another way of dealing with this? > > > > % find /sys/ -type f -exec egrep -H 'rtcin|writertc' {} \; | grep -v drm_mode_set_crtcinfo > > > > shows everything using the rtcin() and writertc() functions, implemented > > for x86 at least in /sys/x86/isa/atrtc.c .. but I have no idea whether > > you can access those functions from where / when you're tinkering here. > This is the way I think it's /supposed/ to be done - from my skimming of one of the ACPI specs, there's a PNP identifier for the CMOS/RTC device. If that identifier is probed, the OS should install a SystemCMOS region handler (which would use the I/O methods of the RTC driver which takes care of locking/consistency). > > Yours looks more likely portable for upstream acpica, but it also looks > > potentially quite dangerous 'in the wrong hands' :) > > Personally I don't think my patch can live upstream in acpica-land because it can step on the toes of an existing OS CMOS/RTC driver talking to the RTC I/O ports. I just don't know how to do all this with our rtc driver yet, particularly the PNPxxxxxx stuff. I'll look into it when I get some free cycles. Probably the "right" thing to do for ACPICA is to have CMOS accesses call out to a set of AcpiOs* hooks that the OS-dependent layer provides (would be in sys/dev/acpica/Osd/*). See how the PCI config space accesses work for an example. I would ask on the ACPICA mailing list (jkim@ can point you at it) for feedback on what approach they would prefer. -- John Baldwin From owner-freebsd-acpi@FreeBSD.ORG Wed Jul 2 21:12:03 2014 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2EEC59B3; Wed, 2 Jul 2014 21:12:03 +0000 (UTC) Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by mx1.freebsd.org (Postfix) with ESMTP id E6246229D; Wed, 2 Jul 2014 21:12:02 +0000 (UTC) Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga102.jf.intel.com with ESMTP; 02 Jul 2014 14:06:27 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.01,590,1400050800"; d="scan'208";a="537960171" Received: from orsmsx107.amr.corp.intel.com ([10.22.240.5]) by orsmga001.jf.intel.com with ESMTP; 02 Jul 2014 14:11:55 -0700 Received: from orsmsx160.amr.corp.intel.com (10.22.226.43) by ORSMSX107.amr.corp.intel.com (10.22.240.5) with Microsoft SMTP Server (TLS) id 14.3.123.3; Wed, 2 Jul 2014 14:11:55 -0700 Received: from orsmsx112.amr.corp.intel.com ([169.254.12.245]) by ORSMSX160.amr.corp.intel.com ([169.254.13.58]) with mapi id 14.03.0123.003; Wed, 2 Jul 2014 14:11:55 -0700 From: "Moore, Robert" To: John Baldwin , "freebsd-acpi@freebsd.org" Subject: RE: Impossible shutdown Thread-Topic: Impossible shutdown Thread-Index: AQHPkMTuhj6F9ToZtkC6GHEq12FPJZuDu8+AgAEl2wCAAQSSgIAEUQAAgAMbdDA= Date: Wed, 2 Jul 2014 21:11:55 +0000 Message-ID: <94F2FBAB4432B54E8AACC7DFDE6C92E37D1BE9E7@ORSMSX112.amr.corp.intel.com> References: <20140625222911.GA34447@hellgate.Dlink> <20140627143031.P50382@sola.nimnet.asn.au> <53ADD8B9.5060401@att.net> <201406301043.55003.jhb@freebsd.org> In-Reply-To: <201406301043.55003.jhb@freebsd.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.22.254.138] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Anthony Jenkins , Bykov Vladislav , Ian Smith X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jul 2014 21:12:03 -0000 The host detects the PNP IDs. Therefore, it needs to recognize the PNP ID f= or system CMOS and install a driver which in turn installs a handler for th= e SystemCMOS address space. > -----Original Message----- > From: owner-freebsd-acpi@freebsd.org [mailto:owner-freebsd- > acpi@freebsd.org] On Behalf Of John Baldwin > Sent: Monday, June 30, 2014 7:44 AM > To: freebsd-acpi@freebsd.org > Cc: Anthony Jenkins; Bykov Vladislav; Ian Smith > Subject: Re: Impossible shutdown >=20 > On Friday, June 27, 2014 4:48:57 pm Anthony Jenkins wrote: > > On 06/27/2014 01:16, Ian Smith wrote: > > > On Thu, 26 Jun 2014 07:44:35 -0400, Anthony Jenkins wrote: > > > > On 06/25/2014 18:29, Bykov Vladislav wrote: > > > > > Hello. > > > > > > > > > > I have a problem with ACPI on HP Envy 4 that causes in > > > impossible > shutdown. It > > > > > reaches an error while prepairing to shutdown, and reboots the > machine. > > > > > > > > > > I already did sent a bug report about 2-3 months ago, but > > > things > doesn't seems > > > > > to move on. > > > > > > > > > > Here's an error when booting the machine: > > > > > > > > > > ACPI Error: No handler for Region [RCM0] (0xfffffe0002b0f800) > [SystemCMOS] (20110527/evregion-421) > > > > > ACPI Error: Region SystemCMOS (ID=3D5) has no handler > (20110527/exfldio-310) > > > > > ACPI Error: Method parse/execution failed [\134_SB_.WMID.ESDT] > (Node 0xfffffe0002aee440), AE_NOT_EXIST (20110527/psparse-560) > > > > > ACPI Error: Method parse/execution failed > [\134_SB_.PCI0.LPCB.EC0_._Q42] (Node 0xfffffe0002b16d40), AE_NOT_EXIST > (20110527/psparse-560) > > > > > acpi_ec0: evaluation of query method _Q42 failed: AE_NOT_EXIST > > > > > > > > > > And here's the one when I'm trying to shut it down: > > > > > > > > > > usbus2: Controller shutdown complete > > > > > ACPI Error: No handler for Region [RCM0] (0xfffffe0002b15900) > [SystemCMOS] (20110527/evregion-421) > > > > > ACPI Error: Region SystemCMOS (ID=3D5) has no handler > (20110527/exfldio-310) > > > > > ACPI Error: Method parse/execution failed [\_SB_.WMID.ESDT] > (Node > 0xfffffe0002af5800), AE_NOT_EXIST (20110527/psparse-560) > > > > > ACPI Error: Method parse/execution failed [\_PTS] (Node > 0xfffffe0002af86c0), AE_NOT_EXIST (20110527/psparse-560) > > > > > acpi0: AcpiEnterSleepStatePrep failed - AE_NOT_EXIST > > > > > Rebooting... > > > > > > > > > > I've tried FreeBSD 9, FreeBSD 10, and -CURRENT. All have the > > > same > problem. > > > > > > > > Here's a case where my patch to implement the SystemCMOS region > > > > handler should help; it allows my HP Envy to power down and allows > > > it > to suspend/resume except the LCD backlight doesn't come back > > > when > resuming. Biggest problem with the patch IMHO is I'm > > > stealing > ("borrowing") from the real time clock (RTC) I/O region, > > > but I don't > think we have an "actual" FreeBSD driver for that. > > > > > > > > Reposting here, or search this list for "Naive implementation of > > > > AcpiExCmosSpaceHandler", let me know if it doesn't apply cleanly > > > to > your version of FreeBSD . I've posted it upstream to the > > > acpica > mailing list, but no response. > > > > > > > > diff --git a/source/components/events/evhandler.c > b/source/components/events/evhandler.c > > > > > > Interesting. I wonder if this is needed for reading the RTC for the > > > time on boot, and writing it back on shutdown - which I would have > > > thought too generic to have left out on any machine? Or is this > perhaps > > > retrieving at boot then restoring at shutdown some other system- > specific > > > information in NVRAM? > > It's the latter; they (presumably the BIOS ACPI shutdown/resume methods= ) > are > just reading/writing locations in the non-volatile CMOS storage, which > just > happens to be shared with the RTC. The RTC proper has some 16 bytes of > registers which represent the real time clock - the rest are presumably > storage, though the platform could probably do whatever it wants with > various > locations. > > > > > If the latter, then the usage in /sys/dev/acpi_support/acpi_ibm.c > > > revealed below might illustrate another way of dealing with this? > > > > > > % find /sys/ -type f -exec egrep -H 'rtcin|writertc' {} \; | grep -v > drm_mode_set_crtcinfo > > > > > > shows everything using the rtcin() and writertc() functions, > implemented > > > for x86 at least in /sys/x86/isa/atrtc.c .. but I have no idea whethe= r > > > you can access those functions from where / when you're tinkering > here. > > This is the way I think it's /supposed/ to be done - from my skimming o= f > one > of the ACPI specs, there's a PNP identifier for the CMOS/RTC device. If > that > identifier is probed, the OS should install a SystemCMOS region handler > (which > would use the I/O methods of the RTC driver which takes care of > locking/consistency). > > > Yours looks more likely portable for upstream acpica, but it also > looks > > > potentially quite dangerous 'in the wrong hands' :) > > > > Personally I don't think my patch can live upstream in acpica-land > because > it can step on the toes of an existing OS CMOS/RTC driver talking to the > RTC > I/O ports. I just don't know how to do all this with our rtc driver yet, > particularly the PNPxxxxxx stuff. I'll look into it when I get some free > cycles. >=20 > Probably the "right" thing to do for ACPICA is to have CMOS accesses call > out > to a set of AcpiOs* hooks that the OS-dependent layer provides (would be > in > sys/dev/acpica/Osd/*). See how the PCI config space accesses work for an > example. I would ask on the ACPICA mailing list (jkim@ can point you at > it) > for feedback on what approach they would prefer. >=20 > -- > John Baldwin > _______________________________________________ > freebsd-acpi@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-acpi > To unsubscribe, send any mail to "freebsd-acpi-unsubscribe@freebsd.org" From owner-freebsd-acpi@FreeBSD.ORG Sat Jul 5 12:10:04 2014 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C5322504 for ; Sat, 5 Jul 2014 12:10:04 +0000 (UTC) Received: from nm20.access.bullet.mail.bf1.yahoo.com (nm20.access.bullet.mail.bf1.yahoo.com [216.109.114.44]) (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 7630B224E for ; Sat, 5 Jul 2014 12:10:04 +0000 (UTC) Received: from [66.196.81.157] by nm20.access.bullet.mail.bf1.yahoo.com with NNFMP; 05 Jul 2014 12:03:46 -0000 Received: from [98.138.104.98] by tm3.access.bullet.mail.bf1.yahoo.com with NNFMP; 05 Jul 2014 12:03:46 -0000 Received: from [127.0.0.1] by smtp118.sbc.mail.ne1.yahoo.com with NNFMP; 05 Jul 2014 12:03:45 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1404561825; bh=vacimiHvlWNSgUEJKc0lKnT61YMID2eIe2FZ3B7a5Fg=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type; b=p8h/4G5wDVhfvCuBYZk7wJ7Kex4XBEhtRp84HQtCPN52wRy0KxMaMECbzigDA5pgreKdcu5+XZASgl39Fa8MzKu8vmSkssOdFnZ9IQrFVBzMml7lqK4UnEZcOcgenwcQRv6ROfoPP43q+fj8+a4wmHulOQsw8obc4OzX+opThoo= X-Yahoo-Newman-Id: 983686.39640.bm@smtp118.sbc.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: .teJtosVM1k3twM2F.C06Jf_doqbefQDXJODcsxRZ_m4_PA mRzZ9XB3X7LodcAdyPRMXDreA2bmsE55RMScUcWdyNnr1BQGLqpOXlmfuFfV mXLJro9VbMycw1QYw2SDwEZEs9eB_ZigkbuIoeUb_ADzKzx4s_3f1YCgb1oz y74iJK2iXxwvaAThk9NZDp4STUNSV.rTkjlkViZIcSlq3DYAbIl0PWu_P6dC wij2rCDhgzR29ZdOHB0W_B.CY5u9B81uwoAhS2i0etp3IEsiqw7e6v7WtBoA rIqAmR9hL6v5kB6.Wl32lM5Ql68pjt.KazvZDJJr2zF8_8hwwm1GYMY9p4dD LNTiFlhelng5QgFNsdQS6FAQxb69LQk2Nu80xlwHjatF_RNSN4MqKj7gDzZ0 RbmzHCt4Hx0NSzWU4gnV3HU5eaQav2MeWIvlKk.Iw7nU7J.JKuBjnlwnesu8 EAEeu7VvK0z3HNTow44KUOXzOqeaKkug8_RbTve50DwYEEZRsL3S3O9MKt7t QwRZ7MyhtidiJIIxRIQF6zPY1t69vG_jH1uUfMe7kNOQ2aO6QoVc8pg-- X-Yahoo-SMTP: OKD1keCswBBTAmAF1s00hLyKW3wE3YfSK0Eazl6b4VZG4LTqJxg- X-Rocket-Received: from [192.168.1.134] (Anthony.B.Jenkins@99.62.101.19 with plain [98.138.84.52]) by smtp118.sbc.mail.ne1.yahoo.com with SMTP; 05 Jul 2014 12:03:45 +0000 UTC Message-ID: <53B7E9A0.3040608@att.net> Date: Sat, 05 Jul 2014 08:03:44 -0400 From: Anthony Jenkins User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Moore, Robert" , John Baldwin , "freebsd-acpi@freebsd.org" Subject: ACPI SystemCMOS region handler rev. 2 (was Re: Impossible shutdown) References: <20140625222911.GA34447@hellgate.Dlink> <20140627143031.P50382@sola.nimnet.asn.au> <53ADD8B9.5060401@att.net> <201406301043.55003.jhb@freebsd.org> <94F2FBAB4432B54E8AACC7DFDE6C92E37D1BE9E7@ORSMSX112.amr.corp.intel.com> In-Reply-To: <94F2FBAB4432B54E8AACC7DFDE6C92E37D1BE9E7@ORSMSX112.amr.corp.intel.com> Content-Type: multipart/mixed; boundary="------------090601000000080708030601" Cc: Bykov Vladislav , Ian Smith X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Jul 2014 12:10:04 -0000 This is a multi-part message in MIME format. --------------090601000000080708030601 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit How about this (attached) patch to atrtc.c? I threw this together (not sure about limiting the width to 8 bits, I can make it more) and backed out my patch to acpica and I can still power down my machine properly (haven't tried suspend/resume yet due to backlight issue). But this seems to be the Right Thing To Do (TM). Anthony On 07/02/2014 17:11, Moore, Robert wrote: > The host detects the PNP IDs. Therefore, it needs to recognize the PNP ID for system CMOS and install a driver which in turn installs a handler for the SystemCMOS address space. > > >> -----Original Message----- >> From: owner-freebsd-acpi@freebsd.org [mailto:owner-freebsd- >> acpi@freebsd.org] On Behalf Of John Baldwin >> Sent: Monday, June 30, 2014 7:44 AM >> To: freebsd-acpi@freebsd.org >> Cc: Anthony Jenkins; Bykov Vladislav; Ian Smith >> Subject: Re: Impossible shutdown >> >> On Friday, June 27, 2014 4:48:57 pm Anthony Jenkins wrote: >>> On 06/27/2014 01:16, Ian Smith wrote: >>>> On Thu, 26 Jun 2014 07:44:35 -0400, Anthony Jenkins wrote: >>>> > On 06/25/2014 18:29, Bykov Vladislav wrote: >>>> > > Hello. >>>> > > >>>> > > I have a problem with ACPI on HP Envy 4 that causes in >>>> impossible >> shutdown. It >>>> > > reaches an error while prepairing to shutdown, and reboots the >> machine. >>>> > > >>>> > > I already did sent a bug report about 2-3 months ago, but >>>> things >> doesn't seems >>>> > > to move on. >>>> > > >>>> > > Here's an error when booting the machine: >>>> > > >>>> > > ACPI Error: No handler for Region [RCM0] (0xfffffe0002b0f800) >> [SystemCMOS] (20110527/evregion-421) >>>> > > ACPI Error: Region SystemCMOS (ID=5) has no handler >> (20110527/exfldio-310) >>>> > > ACPI Error: Method parse/execution failed [\134_SB_.WMID.ESDT] >> (Node 0xfffffe0002aee440), AE_NOT_EXIST (20110527/psparse-560) >>>> > > ACPI Error: Method parse/execution failed >> [\134_SB_.PCI0.LPCB.EC0_._Q42] (Node 0xfffffe0002b16d40), AE_NOT_EXIST >> (20110527/psparse-560) >>>> > > acpi_ec0: evaluation of query method _Q42 failed: AE_NOT_EXIST >>>> > > >>>> > > And here's the one when I'm trying to shut it down: >>>> > > >>>> > > usbus2: Controller shutdown complete >>>> > > ACPI Error: No handler for Region [RCM0] (0xfffffe0002b15900) >> [SystemCMOS] (20110527/evregion-421) >>>> > > ACPI Error: Region SystemCMOS (ID=5) has no handler >> (20110527/exfldio-310) >>>> > > ACPI Error: Method parse/execution failed [\_SB_.WMID.ESDT] >> (Node >> 0xfffffe0002af5800), AE_NOT_EXIST (20110527/psparse-560) >>>> > > ACPI Error: Method parse/execution failed [\_PTS] (Node >> 0xfffffe0002af86c0), AE_NOT_EXIST (20110527/psparse-560) >>>> > > acpi0: AcpiEnterSleepStatePrep failed - AE_NOT_EXIST >>>> > > Rebooting... >>>> > > >>>> > > I've tried FreeBSD 9, FreeBSD 10, and -CURRENT. All have the >>>> same >> problem. >>>> > >>>> > Here's a case where my patch to implement the SystemCMOS region >>>>> handler should help; it allows my HP Envy to power down and allows >>>> it > to suspend/resume except the LCD backlight doesn't come back >>>> when > resuming. Biggest problem with the patch IMHO is I'm >>>> stealing > ("borrowing") from the real time clock (RTC) I/O region, >>>> but I don't > think we have an "actual" FreeBSD driver for that. >>>> > >>>> > Reposting here, or search this list for "Naive implementation of >>>>> AcpiExCmosSpaceHandler", let me know if it doesn't apply cleanly >>>> to > your version of FreeBSD . I've posted it upstream to the >>>> acpica > mailing list, but no response. >>>> > >>>> > diff --git a/source/components/events/evhandler.c >> b/source/components/events/evhandler.c >>>> Interesting. I wonder if this is needed for reading the RTC for the >>>> time on boot, and writing it back on shutdown - which I would have >>>> thought too generic to have left out on any machine? Or is this >> perhaps >>>> retrieving at boot then restoring at shutdown some other system- >> specific >>>> information in NVRAM? >>> It's the latter; they (presumably the BIOS ACPI shutdown/resume methods) >> are >> just reading/writing locations in the non-volatile CMOS storage, which >> just >> happens to be shared with the RTC. The RTC proper has some 16 bytes of >> registers which represent the real time clock - the rest are presumably >> storage, though the platform could probably do whatever it wants with >> various >> locations. >>>> If the latter, then the usage in /sys/dev/acpi_support/acpi_ibm.c >>>> revealed below might illustrate another way of dealing with this? >>>> >>>> % find /sys/ -type f -exec egrep -H 'rtcin|writertc' {} \; | grep -v >> drm_mode_set_crtcinfo >>>> shows everything using the rtcin() and writertc() functions, >> implemented >>>> for x86 at least in /sys/x86/isa/atrtc.c .. but I have no idea whether >>>> you can access those functions from where / when you're tinkering >> here. >>> This is the way I think it's /supposed/ to be done - from my skimming of >> one >> of the ACPI specs, there's a PNP identifier for the CMOS/RTC device. If >> that >> identifier is probed, the OS should install a SystemCMOS region handler >> (which >> would use the I/O methods of the RTC driver which takes care of >> locking/consistency). >>>> Yours looks more likely portable for upstream acpica, but it also >> looks >>>> potentially quite dangerous 'in the wrong hands' :) >>> Personally I don't think my patch can live upstream in acpica-land >> because >> it can step on the toes of an existing OS CMOS/RTC driver talking to the >> RTC >> I/O ports. I just don't know how to do all this with our rtc driver yet, >> particularly the PNPxxxxxx stuff. I'll look into it when I get some free >> cycles. >> >> Probably the "right" thing to do for ACPICA is to have CMOS accesses call >> out >> to a set of AcpiOs* hooks that the OS-dependent layer provides (would be >> in >> sys/dev/acpica/Osd/*). See how the PCI config space accesses work for an >> example. I would ask on the ACPICA mailing list (jkim@ can point you at >> it) >> for feedback on what approach they would prefer. >> >> -- >> John Baldwin >> _______________________________________________ >> freebsd-acpi@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-acpi >> To unsubscribe, send any mail to "freebsd-acpi-unsubscribe@freebsd.org" > _______________________________________________ > freebsd-acpi@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-acpi > To unsubscribe, send any mail to "freebsd-acpi-unsubscribe@freebsd.org" > --------------090601000000080708030601 Content-Type: text/x-patch; name="atrtc.c.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="atrtc.c.patch" Index: sys/x86/isa/atrtc.c =================================================================== --- sys/x86/isa/atrtc.c (revision 267519) +++ sys/x86/isa/atrtc.c (working copy) @@ -31,6 +31,7 @@ __FBSDID("$FreeBSD$"); #include "opt_isa.h" +#include "opt_acpi.h" #include #include @@ -53,6 +54,10 @@ #include #include "clock_if.h" +#include +#include +#include + #define RTC_LOCK do { if (!kdb_active) mtx_lock_spin(&clock_lock); } while (0) #define RTC_UNLOCK do { if (!kdb_active) mtx_unlock_spin(&clock_lock); } while (0) @@ -161,8 +166,33 @@ struct resource *intr_res; void *intr_handler; struct eventtimer et; + ACPI_HANDLE acpi_handle; /* Handle of the PNP0B00 node */ }; +static ACPI_STATUS +acpi_rtc_cmos_handler(UINT32 function, ACPI_PHYSICAL_ADDRESS address, UINT32 width, + UINT64 *value, void *context, void *region_context) +{ + struct atrtc_softc *sc; + + sc = (struct atrtc_softc *)context; + if (!value || !sc) + return AE_BAD_PARAMETER; + if (width != 8 || address >= 64U) + return AE_BAD_PARAMETER; + switch (function) { + case ACPI_READ: + *((UINT8 *)value) = rtcin((int)address); + break; + case ACPI_WRITE: + writertc((int)address, *((UINT8 *)value)); + break; + default: + return AE_BAD_PARAMETER; + } + return AE_OK; +} + static int rtc_start(struct eventtimer *et, sbintime_t first, sbintime_t period) { @@ -245,10 +275,17 @@ int i; sc = device_get_softc(dev); + sc->acpi_handle = acpi_get_handle(dev); sc->port_res = bus_alloc_resource(dev, SYS_RES_IOPORT, &sc->port_rid, IO_RTC, IO_RTC + 1, 2, RF_ACTIVE); if (sc->port_res == NULL) device_printf(dev, "Warning: Couldn't map I/O.\n"); + if (ACPI_FAILURE(AcpiInstallAddressSpaceHandler(sc->acpi_handle, + ACPI_ADR_SPACE_CMOS, acpi_rtc_cmos_handler, NULL, sc))) + { + device_printf(dev, "Error registering ACPI CMOS address space handler.\n"); + return 0; + } atrtc_start(); clock_register(dev, 1000000); bzero(&sc->et, sizeof(struct eventtimer)); @@ -286,6 +323,15 @@ return(0); } +static int atrtc_detach(device_t dev) +{ + struct atrtc_softc *sc; + + sc = device_get_softc(dev); + AcpiRemoveAddressSpaceHandler(sc->acpi_handle, ACPI_ADR_SPACE_CMOS, acpi_rtc_cmos_handler); + return bus_generic_detach(dev); +} + static int atrtc_resume(device_t dev) { @@ -366,7 +412,7 @@ /* Device interface */ DEVMETHOD(device_probe, atrtc_probe), DEVMETHOD(device_attach, atrtc_attach), - DEVMETHOD(device_detach, bus_generic_detach), + DEVMETHOD(device_detach, atrtc_detach), DEVMETHOD(device_shutdown, bus_generic_shutdown), DEVMETHOD(device_suspend, bus_generic_suspend), /* XXX stop statclock? */ @@ -402,3 +448,4 @@ rtcin(RTC_STATUSA), rtcin(RTC_STATUSB), rtcin(RTC_INTR)); } #endif /* DDB */ + --------------090601000000080708030601-- From owner-freebsd-acpi@FreeBSD.ORG Sat Jul 5 12:38:11 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 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AA11EBCB for ; Sat, 5 Jul 2014 12:38:11 +0000 (UTC) Received: from nm12-vm7.access.bullet.mail.bf1.yahoo.com (nm12-vm7.access.bullet.mail.bf1.yahoo.com [216.109.114.246]) (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 59ED2254B for ; Sat, 5 Jul 2014 12:38:11 +0000 (UTC) Received: from [66.196.81.164] by nm12.access.bullet.mail.bf1.yahoo.com with NNFMP; 05 Jul 2014 12:31:14 -0000 Received: from [98.138.226.244] by tm10.access.bullet.mail.bf1.yahoo.com with NNFMP; 05 Jul 2014 12:31:14 -0000 Received: from [127.0.0.1] by smtp115.sbc.mail.ne1.yahoo.com with NNFMP; 05 Jul 2014 12:31:14 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1404563474; bh=QA1ntKlDcHYQWZwxPFX7PAvpfGtnELU5oa7QbY7W3ZQ=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=YBn3t3LDFH7AXL7FOl+sLghmU+B+PeSuJGYkVp4D6ygWf045RQ/OjA5eKZK2SZ2uU0z7OWaqSm7J+poC5MB0HJs2yx1z2ICFdzetmZyyeI/3HQVmRWTN23VystOLqV0u81V7H+22HGqcsIWeSYjKDxPdPvwCxgn5WEXjY+JV+U8= X-Yahoo-Newman-Id: 494213.95372.bm@smtp115.sbc.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: I65yd6wVM1lbPjFXAXQ3aQ5GbTfagn3y0HLMEjMeRPJqU30 WRkIj5kbGtMPEVi1bsw0g8xJ_.Mky_aSgD0lH_OYFVJTSUYdBd_NekjezI6i zIiMaYNmouYQgoZVlheR8l9Q.Rg802Ut77OCk352VFMDwAU1L.xshRalLy1V cSOVQBvYH7_5a497ufHxj9G2DUWcnnB2Zl1knA1TVJr1r1xEzqlLhun5WKYu zaHP30CpGgIfTj0gU8dvXdoWie.sK3x6ZeR4mRlI1U2sufX0Bac5DmAJRpbG 9quG5Qngun.36SzFPLGZ57X_4RJpwYvockeuJiWREy5d5TPdLnTzwOcbY06u fKzbbhBdIbDSoxtLw8GyxmAyVUtb62EXFQPaYa7vF_7C.anQkabNVYB61Mlt 9PNiGflAUTHWMlP8TpRggwDWeO6byqeHjjx1uqFIvkUKjOqkTmaBwga23Ye. UK1xHzEPACg6X2CHPRt2vYhKRYKqkVSMXtJReaeLmtv.03BwpdHSan2RuJfy PrskV6zmjDnrpl5l78fZlgcO_XSBmQKAJRod2TNvUL3LSdf_v X-Yahoo-SMTP: OKD1keCswBBTAmAF1s00hLyKW3wE3YfSK0Eazl6b4VZG4LTqJxg- X-Rocket-Received: from [192.168.1.134] (Anthony.B.Jenkins@99.62.101.19 with plain [98.138.84.52]) by smtp115.sbc.mail.ne1.yahoo.com with SMTP; 05 Jul 2014 12:31:14 +0000 UTC Message-ID: <53B7F010.3030902@att.net> Date: Sat, 05 Jul 2014 08:31:12 -0400 From: Anthony Jenkins User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Moore, Robert" , John Baldwin , "freebsd-acpi@freebsd.org" Subject: Re: ACPI SystemCMOS region handler rev. 2 (was Re: Impossible shutdown) References: <20140625222911.GA34447@hellgate.Dlink> <20140627143031.P50382@sola.nimnet.asn.au> <53ADD8B9.5060401@att.net> <201406301043.55003.jhb@freebsd.org> <94F2FBAB4432B54E8AACC7DFDE6C92E37D1BE9E7@ORSMSX112.amr.corp.intel.com> <53B7E9A0.3040608@att.net> In-Reply-To: <53B7E9A0.3040608@att.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Bykov Vladislav , Ian Smith X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Jul 2014 12:38:11 -0000 What error should the address region handler return for ACPI_WRITE attempts to RTC current date/time registers? >From ACPIspec50.pdf section 5.5.2.4.1 "CMOS Protocols": "All bytes of CMOS that are related to the current time, day, date, month, year and century are read-only." I return AE_BAD_PARAMETER for other failed handler argument checks. I guess I could also return that for bad writes...just seems something like AE_ACCESS might be more appropriate. Also, any opinion as to whether accesses to SystemCMOS region greater than 8 bits wide should be allowed? I don't remember my particular machine trying to access anything wider than 8 bits in this region. I'd probably have to lock multibyte accesses, meaning rewriting the current byte-only I/O functions and adding checks for multibyte write accesses to datetime registers. Thanks, Anthony On 07/05/2014 08:03, Anthony Jenkins wrote: > How about this (attached) patch to atrtc.c? I threw this together (not sure about limiting the width to 8 bits, I can make it more) and backed out my patch to acpica and I can still power down my machine properly (haven't tried suspend/resume yet due to backlight issue). But this seems to be the Right Thing To Do (TM). > > Anthony > > On 07/02/2014 17:11, Moore, Robert wrote: >> The host detects the PNP IDs. Therefore, it needs to recognize the PNP ID for system CMOS and install a driver which in turn installs a handler for the SystemCMOS address space. >> >> >>> -----Original Message----- >>> From: owner-freebsd-acpi@freebsd.org [mailto:owner-freebsd- >>> acpi@freebsd.org] On Behalf Of John Baldwin >>> Sent: Monday, June 30, 2014 7:44 AM >>> To: freebsd-acpi@freebsd.org >>> Cc: Anthony Jenkins; Bykov Vladislav; Ian Smith >>> Subject: Re: Impossible shutdown >>> >>> On Friday, June 27, 2014 4:48:57 pm Anthony Jenkins wrote: >>>> On 06/27/2014 01:16, Ian Smith wrote: >>>>> On Thu, 26 Jun 2014 07:44:35 -0400, Anthony Jenkins wrote: >>>>> > On 06/25/2014 18:29, Bykov Vladislav wrote: >>>>> > > Hello. >>>>> > > >>>>> > > I have a problem with ACPI on HP Envy 4 that causes in >>>>> impossible >>> shutdown. It >>>>> > > reaches an error while prepairing to shutdown, and reboots the >>> machine. >>>>> > > >>>>> > > I already did sent a bug report about 2-3 months ago, but >>>>> things >>> doesn't seems >>>>> > > to move on. >>>>> > > >>>>> > > Here's an error when booting the machine: >>>>> > > >>>>> > > ACPI Error: No handler for Region [RCM0] (0xfffffe0002b0f800) >>> [SystemCMOS] (20110527/evregion-421) >>>>> > > ACPI Error: Region SystemCMOS (ID=5) has no handler >>> (20110527/exfldio-310) >>>>> > > ACPI Error: Method parse/execution failed [\134_SB_.WMID.ESDT] >>> (Node 0xfffffe0002aee440), AE_NOT_EXIST (20110527/psparse-560) >>>>> > > ACPI Error: Method parse/execution failed >>> [\134_SB_.PCI0.LPCB.EC0_._Q42] (Node 0xfffffe0002b16d40), AE_NOT_EXIST >>> (20110527/psparse-560) >>>>> > > acpi_ec0: evaluation of query method _Q42 failed: AE_NOT_EXIST >>>>> > > >>>>> > > And here's the one when I'm trying to shut it down: >>>>> > > >>>>> > > usbus2: Controller shutdown complete >>>>> > > ACPI Error: No handler for Region [RCM0] (0xfffffe0002b15900) >>> [SystemCMOS] (20110527/evregion-421) >>>>> > > ACPI Error: Region SystemCMOS (ID=5) has no handler >>> (20110527/exfldio-310) >>>>> > > ACPI Error: Method parse/execution failed [\_SB_.WMID.ESDT] >>> (Node >>> 0xfffffe0002af5800), AE_NOT_EXIST (20110527/psparse-560) >>>>> > > ACPI Error: Method parse/execution failed [\_PTS] (Node >>> 0xfffffe0002af86c0), AE_NOT_EXIST (20110527/psparse-560) >>>>> > > acpi0: AcpiEnterSleepStatePrep failed - AE_NOT_EXIST >>>>> > > Rebooting... >>>>> > > >>>>> > > I've tried FreeBSD 9, FreeBSD 10, and -CURRENT. All have the >>>>> same >>> problem. >>>>> > >>>>> > Here's a case where my patch to implement the SystemCMOS region >>>>>> handler should help; it allows my HP Envy to power down and allows >>>>> it > to suspend/resume except the LCD backlight doesn't come back >>>>> when > resuming. Biggest problem with the patch IMHO is I'm >>>>> stealing > ("borrowing") from the real time clock (RTC) I/O region, >>>>> but I don't > think we have an "actual" FreeBSD driver for that. >>>>> > >>>>> > Reposting here, or search this list for "Naive implementation of >>>>>> AcpiExCmosSpaceHandler", let me know if it doesn't apply cleanly >>>>> to > your version of FreeBSD . I've posted it upstream to the >>>>> acpica > mailing list, but no response. >>>>> > >>>>> > diff --git a/source/components/events/evhandler.c >>> b/source/components/events/evhandler.c >>>>> Interesting. I wonder if this is needed for reading the RTC for the >>>>> time on boot, and writing it back on shutdown - which I would have >>>>> thought too generic to have left out on any machine? Or is this >>> perhaps >>>>> retrieving at boot then restoring at shutdown some other system- >>> specific >>>>> information in NVRAM? >>>> It's the latter; they (presumably the BIOS ACPI shutdown/resume methods) >>> are >>> just reading/writing locations in the non-volatile CMOS storage, which >>> just >>> happens to be shared with the RTC. The RTC proper has some 16 bytes of >>> registers which represent the real time clock - the rest are presumably >>> storage, though the platform could probably do whatever it wants with >>> various >>> locations. >>>>> If the latter, then the usage in /sys/dev/acpi_support/acpi_ibm.c >>>>> revealed below might illustrate another way of dealing with this? >>>>> >>>>> % find /sys/ -type f -exec egrep -H 'rtcin|writertc' {} \; | grep -v >>> drm_mode_set_crtcinfo >>>>> shows everything using the rtcin() and writertc() functions, >>> implemented >>>>> for x86 at least in /sys/x86/isa/atrtc.c .. but I have no idea whether >>>>> you can access those functions from where / when you're tinkering >>> here. >>>> This is the way I think it's /supposed/ to be done - from my skimming of >>> one >>> of the ACPI specs, there's a PNP identifier for the CMOS/RTC device. If >>> that >>> identifier is probed, the OS should install a SystemCMOS region handler >>> (which >>> would use the I/O methods of the RTC driver which takes care of >>> locking/consistency). >>>>> Yours looks more likely portable for upstream acpica, but it also >>> looks >>>>> potentially quite dangerous 'in the wrong hands' :) >>>> Personally I don't think my patch can live upstream in acpica-land >>> because >>> it can step on the toes of an existing OS CMOS/RTC driver talking to the >>> RTC >>> I/O ports. I just don't know how to do all this with our rtc driver yet, >>> particularly the PNPxxxxxx stuff. I'll look into it when I get some free >>> cycles. >>> >>> Probably the "right" thing to do for ACPICA is to have CMOS accesses call >>> out >>> to a set of AcpiOs* hooks that the OS-dependent layer provides (would be >>> in >>> sys/dev/acpica/Osd/*). See how the PCI config space accesses work for an >>> example. I would ask on the ACPICA mailing list (jkim@ can point you at >>> it) >>> for feedback on what approach they would prefer. >>> >>> -- >>> John Baldwin >>> _______________________________________________ >>> freebsd-acpi@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-acpi >>> To unsubscribe, send any mail to "freebsd-acpi-unsubscribe@freebsd.org" >> _______________________________________________ >> freebsd-acpi@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-acpi >> To unsubscribe, send any mail to "freebsd-acpi-unsubscribe@freebsd.org" >> From owner-freebsd-acpi@FreeBSD.ORG Wed Jul 9 17:12:44 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 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3E2EEACB for ; Wed, 9 Jul 2014 17:12:44 +0000 (UTC) Received: from mout.gmx.com (mout.gmx.com [74.208.4.201]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 18CF724AB for ; Wed, 9 Jul 2014 17:12:44 +0000 (UTC) Received: from [216.115.15.149] by 3capp-mailcom-lxa06.server.lan (via HTTP); Wed, 9 Jul 2014 19:12:37 +0200 Message-ID: From: "Ron Freidel" To: freebsd-acpi@freebsd.org Subject: HP Compaq 8710W Battery status problems Date: Wed, 9 Jul 2014 19:12:37 +0200 Importance: normal Sensitivity: Normal X-Priority: 3 X-Provags-ID: V03:K0:oVaxg3m7GC/FzNqufKOtT6aWOYdBAr1eeNDXy50oiNj ZEQG9ymryspftkvGj1p183KyW+a5a+AW/swhEK3B03i9iZC5FQ lxPLNWof3WivzBLXS2b5+4tN7BfBXxcSSu+rMb5UAHNB5IicSR rxZzyf+J2onjzoJ1hO8y5YqZW4dGEpYZ7yC1GHaSZG9JMKT8rN UfONg9zR9aJJWzU7f8fN5jcoNQzNug8hyMVNMtxTLa1Lz7dgnX mmQGBwkIXVrSojT7KZ74Z6/woDR/haGAAOwxF9waIiklgiq/el RngbfUK1CpihrS1Dj8/09ifo1l+ MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.18 X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jul 2014 17:12:44 -0000 I hope this is the proper list for this issue... This is an older laptop, has the most recent bios update installed, currently running 10.0-RELEASE-p14, have tried 11 as well. Err ahem.. Linux runs well on the laptop, and with FreeBSD everything works except for battery status. The laptop has a feature where there is an available port on the bottom for an add on additional battery that I do not own, but I believe may be the source of the issue, which is the lack of battery status updates. Plugged in and fully charged.... acpiconf -i batt Design capacity: 4368 mAh Last full capacity: 4368 mAh Technology: secondary (rechargeable) Design voltage: 14400 mV Capacity (warn): 219 mAh Capacity (low): 44 mAh Low/warn granularity: 100 mAh Warn/full granularity: 100 mAh Model number: Primary Serial number: 45148 2008/05/12 Type: LIon OEM info: Hewlett-Packard State: high Remaining capacity: 100% Remaining time: unknown Present rate: 0 mA (0 mW) Present voltage: 16721 mV sysctl -a | grep batt debug.acpi.batt.batt_sleep_ms: 0 hw.acpi.battery.life: 100 hw.acpi.battery.time: -1 hw.acpi.battery.state: 0 hw.acpi.battery.units: 2 hw.acpi.battery.info_expire: 5 dev.battery.0.%desc: ACPI Control Method Battery dev.battery.0.%driver: battery dev.battery.0.%location: handle=\_SB_.C1FD dev.battery.0.%pnpinfo: _HID=PNP0C0A _UID=1 dev.battery.0.%parent: acpi0 dev.battery.1.%desc: ACPI Control Method Battery dev.battery.1.%driver: battery dev.battery.1.%location: handle=\_SB_.C1FC dev.battery.1.%pnpinfo: _HID=PNP0C0A _UID=2 dev.battery.1.%parent: acpi0 Have tried forcing in loader.conf with no effect. hw.acpi.battery.units=1 When unplugged the OS seems to recognize that the machine is no longer connected to 110, the screen dims yet the battery status remains the same till the computer either runs out of battery or it is plugged back in, only way to refresh batt stat is to reboot. By the way, here is sysctl -a | grep batt when unplugged for 30 mins with moderate usage. debug.acpi.batt.batt_sleep_ms: 0 hw.acpi.battery.life: 100 hw.acpi.battery.time: 75 hw.acpi.battery.state: 1 hw.acpi.battery.units: 2 and acpiconf -i batt Design capacity: 4368 mAh Last full capacity: 4368 mAh Technology: secondary (rechargeable) Design voltage: 14400 mV Capacity (warn): 219 mAh Capacity (low): 44 mAh Low/warn granularity: 100 mAh Warn/full granularity: 100 mAh Model number: Primary Serial number: 45148 2008/05/12 Type: LIon OEM info: Hewlett-Packard State: discharging Remaining capacity: 100% Remaining time: 1:15 Anyone have any suggestions? FreeBSD is my favorite OS, this keeps me from using it full time my life style is depended on battery usage, cannot afford a newer laptop. Just wish I could get this one thing working. From owner-freebsd-acpi@FreeBSD.ORG Thu Jul 10 20:49:48 2014 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 03BD3F23 for ; Thu, 10 Jul 2014 20:49:48 +0000 (UTC) Received: from mail-ob0-x22d.google.com (mail-ob0-x22d.google.com [IPv6:2607:f8b0:4003:c01::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 C449922E2 for ; Thu, 10 Jul 2014 20:49:47 +0000 (UTC) Received: by mail-ob0-f173.google.com with SMTP id va2so166100obc.32 for ; Thu, 10 Jul 2014 13:49:47 -0700 (PDT) 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=/1mF4Ooey6tqKWkdXQk+CR8YDFwkEnecnhkEDgy1x6I=; b=gH67/ZEONK4wJkHrTCd2M5QNxu7pb1CutmRuZTB65tz9r8XSILjGwnmp+ryh1gHJ+m Hhk+xdk5aCPg1MoNKrX0O2y+rXzKt9ys2xRmoIkDlEtGZez1B3t7lu/TND/Prkepb99i oUlc+WuU0syRtNR4jIf2UVc/7kmx0VSXYJ0blg1YqQ0LufMcaCVs6Zi7Wg2PuGyRavr/ /XRsWc1Ru+KM/NqLfluT3RJc42daKJMTOPKy6EVgO9khRgIKrtp4ePPTAjBBxrpF3uL3 bTDF18Dot7mlUuX70FGyheB3t4e+c2yNV8f6J22OxoMOfObdMFKHeu04NKyuXysbM0vj Sl7w== MIME-Version: 1.0 X-Received: by 10.182.60.65 with SMTP id f1mr6106562obr.78.1405025387109; Thu, 10 Jul 2014 13:49:47 -0700 (PDT) Received: by 10.182.29.9 with HTTP; Thu, 10 Jul 2014 13:49:47 -0700 (PDT) Date: Thu, 10 Jul 2014 22:49:47 +0200 Message-ID: Subject: ACPI support - Freebsd 10 on Sony Vaio VPCCA3C5E From: Daniele Mazzotti To: freebsd-acpi@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18 X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jul 2014 20:49:48 -0000 Hello there, it is been a while since I finished installing Freebsd 10 on my Sony Vaio PC and resolving (or at least I am trying to) one by one, all the problems this hardware is giving me. Actually I cannot find a solution to correctly display the battery level on my laptop. If I unplug my PC from the power and type 'sysctl hw.acpi.battery' this is the result I get: hw.acpi.battery.life: -1 hw.acpi.battery.time: -1 hw.acpi.battery.state: 7 hw.acpi.battery.units: 1 hw.acpi.battery.info_expire: 5 Moreover the suspend mode is giving me some problems as well, but this has definitely a lower priority. I either tried to search for a solution on the FreeBSD Handook with no luck, and google the problem a little bit, but I could not find any valuable help. I would be really interested to investigate the problem further. Is there anyone who can help me out with this and tell me what pieces of information are needed to better understand the problem? Cheers, Daniele. From owner-freebsd-acpi@FreeBSD.ORG Thu Jul 10 21:30:16 2014 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 31E56490 for ; Thu, 10 Jul 2014 21:30:16 +0000 (UTC) Received: from nm12-vm6.access.bullet.mail.gq1.yahoo.com (nm12-vm6.access.bullet.mail.gq1.yahoo.com [216.39.63.160]) (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 DEFA12696 for ; Thu, 10 Jul 2014 21:30:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s2048; t=1405027655; bh=nPLiaFXMXT5jbF2C2tG2o+hMJfksid1XNOTbemusldU=; h=Received:Received:Received:DKIM-Signature:X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=Vo1vx7vkXn80fOGN8ztViAP2TReTyO1qMR/gL1stwb9Ab6C4WyHN/e0a2bSFPpyDLfEf53DAr4qD4z6kBKzC9ivEMydY1cpvqTdWwqDl8ohXioktmeSCtEFkxQTNwmL1Ea1hCE6e/ToIsZzwPrN3OCYLPw7vdLbJMdceK4dmFLfLNXjEb7KLJrq9jYN0KsR9aDlyJ4Qn1s4yJsg+x1iTlLMqy2k75am2lTwSbFgCvBL3U7rdvnD5+QDsBEVtj8b9bEfN5JmmBNvCOZqpHo6s5sLTaP2K1FNVtwv57xm7ZihV3xXCRh1uDIsdpQ6/kVqjyJFlYnK5Qlc1b0kdO0Q3ng== DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s2048; d=att.net; b=WkPqX5a6CMr+2oAd98mpDCJWcWEdYhE9uPYVzjgJM1VauTsDJNoQzy8fnIkQbVxA8Jk7nU1ync3Y1oLPrESwYz93h/lh855l1e/npKkwaHG6GthwWmHMXSGIxRowqNV6nY0Lz7wOaQ+hLNwmDjzNI+9euPMS6eccJ8lLNUf6REqcJ86YBj/+F0TdnC60WZb15VzOr3Ud+MEY1AfgHKQlgKmkM3ntKTHsogF1DNZWWWEFrqZCeqpzPL2Yc6vFJTipNa5qL50W8gY1FlD2q3MqsvvJfpZMh0kZp7xmrhZorHjFR+OThPNxX0ZFwoTQLmPN3UYcBkrixykbU0DpyAhciQ==; Received: from [216.39.60.175] by nm12.access.bullet.mail.gq1.yahoo.com with NNFMP; 10 Jul 2014 21:27:35 -0000 Received: from [98.138.226.244] by tm11.access.bullet.mail.gq1.yahoo.com with NNFMP; 10 Jul 2014 21:27:35 -0000 Received: from [127.0.0.1] by smtp115.sbc.mail.ne1.yahoo.com with NNFMP; 10 Jul 2014 21:27:35 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1405027655; bh=nPLiaFXMXT5jbF2C2tG2o+hMJfksid1XNOTbemusldU=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=5JcOZ7o4zDE+9bhTNsFBriwFyS5/KRQp5cNyxJyZ6h9vtM6c3Oym9zUd6P17ATKxh84U4Z0KUKVpkFEMmSIKcE0Sf7sow909V2jeyzwSZFS1QLyD/cqCoYWz74dH4jBubH/UGuKLS2pt90TqpXGih/wP78MPhH7eyPzrrLNe4tQ= X-Yahoo-Newman-Id: 365879.55297.bm@smtp115.sbc.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: VOq_d3gVM1lAT8UGmmJ2j0oGmYLhL1_xzSQy7fGJQqrSLks gtII0FY1h2Zg_2UHwieGmKlvr7xvOSK2AA0LI9L6Rz1_jjUWhkQNxzj473Yi YuII6B88lnu.uxzGR48ZuAkOIi9GN3Xx6mClZDJbwCLVQd6Rese766DKui.X CbhpkNNt7bXIIYPBw1_ZjeNH6pF7vgz3kLzbFfhQyT8gbAzj9uLD1BHxMFmD gB7QOix6nkLO2W1CF7ddQavKrkJgqp4Vq2EMra3ECRNPfXYHtPFkWuWEH4FU D2rO585shO66aOyakN..rWU7Q.UM0UawKTb4shRq1jzeoCVdX_eKDK3p8DD4 o1yVdg7ATvf5d1HQXaZV_U8K4wbR9r.DDWjoUOrjzjkMHYKyXwQvmf5RkWMA 1MdEGjqBRtwCa0xHjKePqUC4VIjnHw6ILH5gbueRWJYNcNDoVE.3.Ld0.7KL nPZvUZwJQR_f.U4H5SUfhQeJP8zaUXRpArdVGxHJ4oXZk_2mBK1_XxuuATxl E0WcG8a2cJgly_5IrzE6gT.P92m.yd0VEqqa8e7K88HXq1Vxc0_nrj_Q- X-Yahoo-SMTP: OKD1keCswBBTAmAF1s00hLyKW3wE3YfSK0Eazl6b4VZG4LTqJxg- Message-ID: <53BF0546.70505@att.net> Date: Thu, 10 Jul 2014 17:27:34 -0400 From: Anthony Jenkins User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Daniele Mazzotti , freebsd-acpi@freebsd.org Subject: Re: ACPI support - Freebsd 10 on Sony Vaio VPCCA3C5E References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jul 2014 21:30:16 -0000 On 07/10/2014 16:49, Daniele Mazzotti wrote: > Hello there, > > it is been a while since I finished installing Freebsd 10 on my Sony Vaio > PC and resolving (or at least I am trying to) one by one, all the problems > this hardware is giving me. Actually I cannot find a solution to correctly > display the battery level on my laptop. If I unplug my PC from the power > and type 'sysctl hw.acpi.battery' this is the result I get: > > hw.acpi.battery.life: -1 > hw.acpi.battery.time: -1 > hw.acpi.battery.state: 7 > hw.acpi.battery.units: 1 > hw.acpi.battery.info_expire: 5 > > Moreover the suspend mode is giving me some problems as well, but this has > definitely a lower priority. > > I either tried to search for a solution on the FreeBSD Handook with no > luck, and google the problem a little bit, but I could not find any > valuable help. I would be really interested to investigate the problem > further. Is there anyone who can help me out with this and tell me what > pieces of information are needed to better understand the problem? Try enabling the ACPI_BATTERY layer and ACPI_LV_ALL_EXCEPTIONS level in /boot/loader.conf: debug.acpi.layer="ACPI_BATTERY" debug.acpi.level="ACPI_LV_ALL_EXCEPTIONS" debug.acpi.enable_debug_objects="1" # I assume this is how you turn on ACPI debugging without recompiling the kernel with 'options ACPI_DEBUG' and running 'sysctl hw.acpi.battery' again. Post /var/log/messages ACPI messages about battery here. Anthony > > Cheers, > Daniele. > _______________________________________________ > freebsd-acpi@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-acpi > To unsubscribe, send any mail to "freebsd-acpi-unsubscribe@freebsd.org" > From owner-freebsd-acpi@FreeBSD.ORG Thu Jul 10 21:34:05 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 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 51FF75D0 for ; Thu, 10 Jul 2014 21:34:05 +0000 (UTC) Received: from nm3-vm5.access.bullet.mail.bf1.yahoo.com (nm3-vm5.access.bullet.mail.bf1.yahoo.com [216.109.114.100]) (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 EEF6D271F for ; Thu, 10 Jul 2014 21:34:04 +0000 (UTC) Received: from [66.196.81.156] by nm3.access.bullet.mail.bf1.yahoo.com with NNFMP; 10 Jul 2014 21:31:53 -0000 Received: from [98.138.104.96] by tm2.access.bullet.mail.bf1.yahoo.com with NNFMP; 10 Jul 2014 21:31:52 -0000 Received: from [127.0.0.1] by smtp116.sbc.mail.ne1.yahoo.com with NNFMP; 10 Jul 2014 21:31:52 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1405027912; bh=F7UGFnqyxB1cdYAZTOOY6/kGTE2a5WTNJKsq7fWnuE4=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=CF7UKE4u7nRwZc8OalD6E6y99Kvb6ubmKkwUrpXQ8p1AUrNMkBi30JF3lLeqCXgtnvhqmiAp3xtR06QQiALYVPA160hdnzz5E/tdVvICNbzT1TAGYwW7tC6F4AOWGfs4zaCwd8ZCOUDd47OvXCOYIWagirgrX3P5mZSjwLBMXXk= X-Yahoo-Newman-Id: 760624.50577.bm@smtp116.sbc.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: tl0rCu0VM1kswUNGPfxF7PXF04pGiSFaPh7.Jqz955esQc6 aJmS_f19AibRW7cjKrlbLv_wJduWk16FHNe7P.ss.ef6gWtK.dWnpJW4iRL1 ti4tjy2zc3bDiO.tPD_WJwfzUT.eYarp5Wc.45g43ml5PWMp.Y6qGRKsuCkt GVEK6Vmu8gv8y08WVcXlfzyuFWiTbgqGioVbEhmvmizRCY3s1U.K.Z9xqXf5 60lBv3IzyxPe5sUuswLVBf9UnqwxZoh0zAB2hP.PDX0W0Rs9ExSGjBVwFjPK _tPV10GylwJGp3xO1EfzsbFto_H4_3Vj6LCui1XIioNipkDBlsyzCktNbcxR EDeihZe_3hi2xeGLT6qa7QE3mHYi6m1M9dfdC7Bbz7LRYcFgvxItJk1OGW8Z Ex33tMm_vwEhXNkqxAxMG.isRL5N0Bm2AVSFMtPNnsx8_vAAUFhDPozrzSD1 4G9YxsdE82EkD4COeGnKjdyMWy60bRmYJ3lIIMbeTTPdXVPTSzelhAxm8.Nl 84PSNTL3ZEmBfLMVKYW6lJNs8GCiJiq5JYeUcS6lZg5HQWUP7Xw-- X-Yahoo-SMTP: OKD1keCswBBTAmAF1s00hLyKW3wE3YfSK0Eazl6b4VZG4LTqJxg- X-Rocket-Received: from [64.100.112.73] (Anthony.B.Jenkins@64.100.112.73 with plain [98.138.84.52]) by smtp116.sbc.mail.ne1.yahoo.com with SMTP; 10 Jul 2014 21:31:52 +0000 UTC Message-ID: <53BF0648.40602@att.net> Date: Thu, 10 Jul 2014 17:31:52 -0400 From: Anthony Jenkins User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Ron Freidel , freebsd-acpi@freebsd.org Subject: Re: HP Compaq 8710W Battery status problems References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jul 2014 21:34:05 -0000 On 07/09/2014 13:12, Ron Freidel wrote: > I hope this is the proper list for this issue... > > This is an older laptop, has the most recent bios update installed, > currently running 10.0-RELEASE-p14, have tried 11 as well. Err ahem.. > Linux runs well on the laptop, and with FreeBSD everything works except > for battery status. > > The laptop has a feature where there is an available port on the bottom > for an add on additional battery that I do not own, but I believe may > be the source of the issue, which is the lack of battery status > updates. > > Plugged in and fully charged.... > acpiconf -i batt Isn't this supposed to be 'acpiconf -i 0' and 'acpiconf -i 1'? [ajenkins@ajenkins-hplaptop /usr/src/sys]$ acpiconf -i 0 Design capacity: 3695 mAh Last full capacity: 3695 mAh Technology: secondary (rechargeable) Design voltage: 14800 mV Capacity (warn): 180 mAh Capacity (low): 108 mAh Low/warn granularity: 264 mAh Warn/full granularity: 3780 mAh Model number: EG04060 Serial number: 05453 07/15/2012 Type: LION OEM info: 23-17 State: discharging Remaining capacity: 41% Remaining time: 0:56 Present rate: 1647 mA (23766 mW) Present voltage: 14430 mV [ajenkins@ajenkins-hplaptop /usr/src/sys]$ acpiconf -i 1 acpiconf: get battery info (1) failed: Device not configured > Design capacity: 4368 mAh > Last full capacity: 4368 mAh > Technology: secondary (rechargeable) > Design voltage: 14400 mV > Capacity (warn): 219 mAh > Capacity (low): 44 mAh > Low/warn granularity: 100 mAh > Warn/full granularity: 100 mAh > Model number: Primary > Serial number: 45148 2008/05/12 > Type: LIon > OEM info: Hewlett-Packard > State: high > Remaining capacity: 100% > Remaining time: unknown > Present rate: 0 mA (0 mW) > Present voltage: 16721 mV > > sysctl -a | grep batt > debug.acpi.batt.batt_sleep_ms: 0 > hw.acpi.battery.life: 100 > hw.acpi.battery.time: -1 > hw.acpi.battery.state: 0 > hw.acpi.battery.units: 2 > hw.acpi.battery.info_expire: 5 > dev.battery.0.%desc: ACPI Control Method Battery > dev.battery.0.%driver: battery > dev.battery.0.%location: handle=\_SB_.C1FD > dev.battery.0.%pnpinfo: _HID=PNP0C0A _UID=1 > dev.battery.0.%parent: acpi0 > dev.battery.1.%desc: ACPI Control Method Battery > dev.battery.1.%driver: battery > dev.battery.1.%location: handle=\_SB_.C1FC > dev.battery.1.%pnpinfo: _HID=PNP0C0A _UID=2 > dev.battery.1.%parent: acpi0 > > > Have tried forcing in loader.conf with no effect. > > hw.acpi.battery.units=1 > > When unplugged the OS seems to recognize that the machine is no longer > connected to 110, the screen dims yet the battery status remains the > same till the computer either runs out of battery or it is plugged back > in, only way to refresh batt stat is to reboot. > > By the way, here is sysctl -a | grep batt when unplugged for 30 mins > with moderate usage. > debug.acpi.batt.batt_sleep_ms: 0 > hw.acpi.battery.life: 100 > hw.acpi.battery.time: 75 > hw.acpi.battery.state: 1 > hw.acpi.battery.units: 2 > > and acpiconf -i batt > Design capacity: 4368 mAh > Last full capacity: 4368 mAh > Technology: secondary (rechargeable) > Design voltage: 14400 mV > Capacity (warn): 219 mAh > Capacity (low): 44 mAh > Low/warn granularity: 100 mAh > Warn/full granularity: 100 mAh > Model number: Primary > Serial number: 45148 2008/05/12 > Type: LIon > OEM info: Hewlett-Packard > State: discharging > Remaining capacity: 100% > Remaining time: 1:15 > > > Anyone have any suggestions? FreeBSD is my favorite OS, this keeps me > from using it full time my life style is depended on battery usage, > cannot afford a newer laptop. Just wish I could get this one thing > working. For giggles, have you tried running the laptop on A/C power, disconnecting *all* batteries and seeing what 'acpiconf -i {0|1}' and 'sysctl hw.acpi.battery dev.battery' says? Anthony > _______________________________________________ > freebsd-acpi@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-acpi > To unsubscribe, send any mail to "freebsd-acpi-unsubscribe@freebsd.org" > From owner-freebsd-acpi@FreeBSD.ORG Fri Jul 11 05:58:59 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 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8D61DEE0 for ; Fri, 11 Jul 2014 05:58:59 +0000 (UTC) Received: from mail-oa0-x231.google.com (mail-oa0-x231.google.com [IPv6:2607:f8b0:4003:c02::231]) (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 5222B215C for ; Fri, 11 Jul 2014 05:58:59 +0000 (UTC) Received: by mail-oa0-f49.google.com with SMTP id eb12so677201oac.22 for ; Thu, 10 Jul 2014 22:58:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=v3nQmqDVyJZS+xz1BEBDyTWVoSoqRBj3BW895K047fs=; b=ABoizIpOue+VEiuN0hTYjhYvzHlAOM+uAxQaQDyYE5bUaXi/7ESgatMZjcmow32cRv Ek4iz/bl3W4b0HNFVzcajdxAhj/JpUstwR9D9PgzDpPrUj9Hr50M55JnrtdcHPlPi3J3 by6J32mT8ZBH0pLUX+ckpJ5/7tD/ShsZEvogq9TVIm2+Ef4BftT7SRdli/hp1oBRO4yd EHG3WhVfbRrr17s9UGVGjlyx+3e3GL+gpnlrutXwqUM6hx5HIJ/6EH+a3gq3p4n1j7X4 v8KjXFat/qX7o+HM75znw/9YoxePX/FglVDNiNKS1eo510G2ktUggtWgushirPceSuE2 mSdw== MIME-Version: 1.0 X-Received: by 10.182.60.65 with SMTP id f1mr8941730obr.78.1405058338034; Thu, 10 Jul 2014 22:58:58 -0700 (PDT) Received: by 10.182.29.9 with HTTP; Thu, 10 Jul 2014 22:58:57 -0700 (PDT) In-Reply-To: <53BF0546.70505@att.net> References: <53BF0546.70505@att.net> Date: Fri, 11 Jul 2014 07:58:57 +0200 Message-ID: Subject: Re: ACPI support - Freebsd 10 on Sony Vaio VPCCA3C5E From: Daniele Mazzotti To: Anthony Jenkins Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18 Cc: freebsd-acpi@freebsd.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jul 2014 05:58:59 -0000 Hello Anthony, thanks for the quick reply! I tried what you suggested. loader.conf: # Module for Windows Partition & Linux Mount fuse_load="YES" autoboot_delay="5" #acpi_sony_load="YES" # Debugging Symbols for ACPI debug.acpi.layer="ACPI_BATTERY" debug.acpi.level="ACPI_LV_ALL_EXCEPTIONS" debug.acpi.enable_debug_objects="1" sysctl hw.acpi.battery: hw.acpi.battery.life: -1 hw.acpi.battery.time: -1 hw.acpi.battery.state: 7 hw.acpi.battery.units: 1 hw.acpi.battery.info_expire: 5 log/messages: cat /var/log/messages | grep acpi Jul 11 07:30:47 Von-Neumann kernel: acpi0: on motherboard Jul 11 07:30:47 Von-Neumann kernel: acpi_ec0: port 0x62,0x66 on acpi0 Jul 11 07:30:47 Von-Neumann kernel: cpu0: on acpi0 Jul 11 07:30:47 Von-Neumann kernel: cpu1: on acpi0 Jul 11 07:30:47 Von-Neumann kernel: cpu2: on acpi0 Jul 11 07:30:47 Von-Neumann kernel: cpu3: on acpi0 Jul 11 07:30:47 Von-Neumann kernel: hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Jul 11 07:30:47 Von-Neumann kernel: atrtc0: port 0x70-0x77 irq 8 on acpi0 Jul 11 07:30:47 Von-Neumann kernel: attimer0: port 0x40-0x43,0x50-0x53 irq 0 on acpi0 Jul 11 07:30:47 Von-Neumann kernel: acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 Jul 11 07:30:47 Von-Neumann kernel: pcib0: port 0xcf8-0xcff on acpi0 Jul 11 07:30:47 Von-Neumann kernel: battery0: on acpi0 Jul 11 07:30:47 Von-Neumann kernel: acpi_acad0: on acpi0 Jul 11 07:30:47 Von-Neumann kernel: acpi_lid0: on acpi0 Jul 11 07:30:47 Von-Neumann kernel: acpi_button0: on acpi0 Jul 11 07:30:47 Von-Neumann kernel: acpi_tz0: on acpi0 Jul 11 07:30:47 Von-Neumann kernel: acpi_tz1: on acpi0 Jul 11 07:30:47 Von-Neumann kernel: atkbdc0: port 0x60,0x64 irq 1 on acpi0 Jul 11 07:30:47 Von-Neumann kernel: acpi_sony0: on acpi0 Jul 11 07:30:47 Von-Neumann kernel: acpi_sony0: PID 0 Jul 11 07:37:54 Von-Neumann kernel: acpi0: on motherboard Jul 11 07:37:54 Von-Neumann kernel: acpi_ec0: port 0x62,0x66 on acpi0 Jul 11 07:37:54 Von-Neumann kernel: cpu0: on acpi0 Jul 11 07:37:54 Von-Neumann kernel: cpu1: on acpi0 Jul 11 07:37:54 Von-Neumann kernel: cpu2: on acpi0 Jul 11 07:37:54 Von-Neumann kernel: cpu3: on acpi0 Jul 11 07:37:54 Von-Neumann kernel: hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Jul 11 07:37:54 Von-Neumann kernel: atrtc0: port 0x70-0x77 irq 8 on acpi0 Jul 11 07:37:54 Von-Neumann kernel: attimer0: port 0x40-0x43,0x50-0x53 irq 0 on acpi0 Jul 11 07:37:54 Von-Neumann kernel: acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 Jul 11 07:37:54 Von-Neumann kernel: pcib0: port 0xcf8-0xcff on acpi0 Jul 11 07:37:54 Von-Neumann kernel: battery0: on acpi0 Jul 11 07:37:54 Von-Neumann kernel: acpi_acad0: on acpi0 Jul 11 07:37:54 Von-Neumann kernel: acpi_lid0: on acpi0 Jul 11 07:37:54 Von-Neumann kernel: acpi_button0: on acpi0 Jul 11 07:37:54 Von-Neumann kernel: acpi_tz0: on acpi0 Jul 11 07:37:54 Von-Neumann kernel: acpi_tz1: on acpi0 Jul 11 07:37:54 Von-Neumann kernel: atkbdc0: port 0x60,0x64 irq 1 on acpi0 It seems to me the verbose debugging is either not enabled (perhaps I made some mistakes with the loader.conf) or the debug is really enabled but there is no special output on the wrong log file. Actually I am a bit puzzled as I am not a real expert "admin". I only enjoy getting my hands on Unix on my desktop PC just for fun. However, do you think either I missed something or made anything wrong? I look forward to receiving from you. Cheers, Daniele. 2014-07-10 23:27 GMT+02:00 Anthony Jenkins : > On 07/10/2014 16:49, Daniele Mazzotti wrote: > > Hello there, > > > > it is been a while since I finished installing Freebsd 10 on my Sony Vaio > > PC and resolving (or at least I am trying to) one by one, all the > problems > > this hardware is giving me. Actually I cannot find a solution to > correctly > > display the battery level on my laptop. If I unplug my PC from the power > > and type 'sysctl hw.acpi.battery' this is the result I get: > > > > hw.acpi.battery.life: -1 > > hw.acpi.battery.time: -1 > > hw.acpi.battery.state: 7 > > hw.acpi.battery.units: 1 > > hw.acpi.battery.info_expire: 5 > > > > Moreover the suspend mode is giving me some problems as well, but this > has > > definitely a lower priority. > > > > I either tried to search for a solution on the FreeBSD Handook with no > > luck, and google the problem a little bit, but I could not find any > > valuable help. I would be really interested to investigate the problem > > further. Is there anyone who can help me out with this and tell me what > > pieces of information are needed to better understand the problem? > Try enabling the ACPI_BATTERY layer and ACPI_LV_ALL_EXCEPTIONS level in > /boot/loader.conf: > > debug.acpi.layer="ACPI_BATTERY" > debug.acpi.level="ACPI_LV_ALL_EXCEPTIONS" > debug.acpi.enable_debug_objects="1" # I assume this is how you > turn on ACPI debugging without recompiling the kernel with 'options > ACPI_DEBUG' > > and running 'sysctl hw.acpi.battery' again. Post /var/log/messages ACPI > messages about battery here. > > Anthony > > > > > Cheers, > > Daniele. > > _______________________________________________ > > freebsd-acpi@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-acpi > > To unsubscribe, send any mail to "freebsd-acpi-unsubscribe@freebsd.org" > > > > From owner-freebsd-acpi@FreeBSD.ORG Fri Jul 11 11:38:22 2014 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D1165E36 for ; Fri, 11 Jul 2014 11:38:22 +0000 (UTC) Received: from nm23-vm4.access.bullet.mail.gq1.yahoo.com (nm23-vm4.access.bullet.mail.gq1.yahoo.com [216.39.63.111]) (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 955B52F19 for ; Fri, 11 Jul 2014 11:38:22 +0000 (UTC) Received: from [216.39.60.172] by nm23.access.bullet.mail.gq1.yahoo.com with NNFMP; 11 Jul 2014 11:35:18 -0000 Received: from [98.138.104.96] by tm8.access.bullet.mail.gq1.yahoo.com with NNFMP; 11 Jul 2014 11:35:17 -0000 Received: from [127.0.0.1] by smtp116.sbc.mail.ne1.yahoo.com with NNFMP; 11 Jul 2014 11:35:17 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1405078517; bh=MJ1YoUzQDAzE7XwuFUWa5fWMq6kSXlWEIPtgGL8al10=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=GPVedmNeJApOLRNilrQ4kDz1wNIduaUwKQAPke70CLZw3baaaycyCzWBXKkMPSEHneYfVKGoHgjo9ezPs6ySGp+5kLE1WSzVg86m0iE3a5R896zKZMcMc8NEa+FkxCFgnjlS1odlup+FXtPLcsKl1hatqAdyTznBS107Ivs7KSU= X-Yahoo-Newman-Id: 860679.76322.bm@smtp116.sbc.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: Rx0YI4EVM1nYLNEln1oX_NZ4NCT_Amqzu5aOW9MRzCmXOrG R0WOcJC30I.g9qAXo6A9OgIrV3OuQl7BRL2PuisRFViHTDRjHmhNMZZdIX1P GEvfJlZe5iIZJRfZSmK6sH9Gk0zn4.LatXk6AT2C3MrdktwMPmGO.HEcTygO HlV_vyiLQ9EKdfY0GJJKPSzryqEuECWeXqrnJRgVRhgO3GbS3_SwOkI._v4p XC1HomWyvRT2w0frLSoaR72c7qEDR.MWVrbvGuhKgxVqRDW2bGIaIGqORsc6 GragQnzqZz8VD_pjxs5xb0T3h_BO4EuKSJward29t9r5dvEyqXgiW7nGBHqf mpXSBcMckksY7bea0DkdBjwCVDCoWOjJDCVvEe4n9xF1uDFp0YMhVsCUNu3d p8hbiokCP_TSTSSDRo8DuTeyofkb_u6MeV5p0kL3ynVGBy3SCyPdwYvHeGO1 gowmVYZHfIufms22_EfVq9u2X9xoQz.OMropaYRv7YKjCsEv7M9qf124KTBC gTQYXStxReLbEs0l5fkGzbJ2nfCcspH1gRXNtfRVUzRlm24jyEI2u25vdZDF Z X-Yahoo-SMTP: OKD1keCswBBTAmAF1s00hLyKW3wE3YfSK0Eazl6b4VZG4LTqJxg- X-Rocket-Received: from [10.82.251.31] (Anthony.B.Jenkins@64.102.254.33 with plain [98.138.84.52]) by smtp116.sbc.mail.ne1.yahoo.com with SMTP; 11 Jul 2014 11:35:17 +0000 UTC Message-ID: <53BFCBF4.2090104@att.net> Date: Fri, 11 Jul 2014 07:35:16 -0400 From: Anthony Jenkins User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Daniele Mazzotti Subject: Re: ACPI support - Freebsd 10 on Sony Vaio VPCCA3C5E References: <53BF0546.70505@att.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@freebsd.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jul 2014 11:38:22 -0000 Hi Daniele, I was just going from acpi(4) man page; you'll likely have to build a new kernel with 'options ACPI_DEBUG' added to your kernel config file, as I don't know if it's even possible to turn on the logging I want at runtime. [ajenkins@ajenkins-hplaptop /usr/home/ajenkins]$ grep -i acpi /usr/src/sys/amd64/conf/MYKERNEL device acpi options ACPI_DEBUG I also have an 'options ACPI_DMAR' , but I don't recognize that and you don't need that to debug your battery. Anthony On 07/11/2014 01:58, Daniele Mazzotti wrote: > Hello Anthony, > > thanks for the quick reply! I tried what you suggested. > > loader.conf: > > # Module for Windows Partition & Linux Mount > fuse_load="YES" > autoboot_delay="5" > #acpi_sony_load="YES" > > # Debugging Symbols for ACPI > debug.acpi.layer="ACPI_BATTERY" > debug.acpi.level="ACPI_LV_ALL_EXCEPTIONS" > debug.acpi.enable_debug_objects="1" > > sysctl hw.acpi.battery: > > hw.acpi.battery.life: -1 > hw.acpi.battery.time: -1 > hw.acpi.battery.state: 7 > hw.acpi.battery.units: 1 > hw.acpi.battery.info_expire: 5 > > log/messages: > > cat /var/log/messages | grep acpi > > Jul 11 07:30:47 Von-Neumann kernel: acpi0: on motherboard > Jul 11 07:30:47 Von-Neumann kernel: acpi_ec0: 0x17, ECDT> port 0x62,0x66 on acpi0 > Jul 11 07:30:47 Von-Neumann kernel: cpu0: on acpi0 > Jul 11 07:30:47 Von-Neumann kernel: cpu1: on acpi0 > Jul 11 07:30:47 Von-Neumann kernel: cpu2: on acpi0 > Jul 11 07:30:47 Von-Neumann kernel: cpu3: on acpi0 > Jul 11 07:30:47 Von-Neumann kernel: hpet0: > iomem 0xfed00000-0xfed003ff on acpi0 > Jul 11 07:30:47 Von-Neumann kernel: atrtc0: port > 0x70-0x77 irq 8 on acpi0 > Jul 11 07:30:47 Von-Neumann kernel: attimer0: port > 0x40-0x43,0x50-0x53 irq 0 on acpi0 > Jul 11 07:30:47 Von-Neumann kernel: acpi_timer0: <24-bit timer at > 3.579545MHz> port 0x408-0x40b on acpi0 > Jul 11 07:30:47 Von-Neumann kernel: pcib0: port > 0xcf8-0xcff on acpi0 > Jul 11 07:30:47 Von-Neumann kernel: battery0: > on acpi0 > Jul 11 07:30:47 Von-Neumann kernel: acpi_acad0: on acpi0 > Jul 11 07:30:47 Von-Neumann kernel: acpi_lid0: > on acpi0 > Jul 11 07:30:47 Von-Neumann kernel: acpi_button0: on acpi0 > Jul 11 07:30:47 Von-Neumann kernel: acpi_tz0: on acpi0 > Jul 11 07:30:47 Von-Neumann kernel: acpi_tz1: on acpi0 > Jul 11 07:30:47 Von-Neumann kernel: atkbdc0: > port 0x60,0x64 irq 1 on acpi0 > Jul 11 07:30:47 Von-Neumann kernel: acpi_sony0: > on acpi0 > Jul 11 07:30:47 Von-Neumann kernel: acpi_sony0: PID 0 > Jul 11 07:37:54 Von-Neumann kernel: acpi0: on motherboard > Jul 11 07:37:54 Von-Neumann kernel: acpi_ec0: 0x17, ECDT> port 0x62,0x66 on acpi0 > Jul 11 07:37:54 Von-Neumann kernel: cpu0: on acpi0 > Jul 11 07:37:54 Von-Neumann kernel: cpu1: on acpi0 > Jul 11 07:37:54 Von-Neumann kernel: cpu2: on acpi0 > Jul 11 07:37:54 Von-Neumann kernel: cpu3: on acpi0 > Jul 11 07:37:54 Von-Neumann kernel: hpet0: > iomem 0xfed00000-0xfed003ff on acpi0 > Jul 11 07:37:54 Von-Neumann kernel: atrtc0: port > 0x70-0x77 irq 8 on acpi0 > Jul 11 07:37:54 Von-Neumann kernel: attimer0: port > 0x40-0x43,0x50-0x53 irq 0 on acpi0 > Jul 11 07:37:54 Von-Neumann kernel: acpi_timer0: <24-bit timer at > 3.579545MHz> port 0x408-0x40b on acpi0 > Jul 11 07:37:54 Von-Neumann kernel: pcib0: port > 0xcf8-0xcff on acpi0 > Jul 11 07:37:54 Von-Neumann kernel: battery0: > on acpi0 > Jul 11 07:37:54 Von-Neumann kernel: acpi_acad0: on acpi0 > Jul 11 07:37:54 Von-Neumann kernel: acpi_lid0: > on acpi0 > Jul 11 07:37:54 Von-Neumann kernel: acpi_button0: on acpi0 > Jul 11 07:37:54 Von-Neumann kernel: acpi_tz0: on acpi0 > Jul 11 07:37:54 Von-Neumann kernel: acpi_tz1: on acpi0 > Jul 11 07:37:54 Von-Neumann kernel: atkbdc0: > port 0x60,0x64 irq 1 on acpi0 > > It seems to me the verbose debugging is either not enabled (perhaps I made > some mistakes with the loader.conf) or the debug is really enabled but > there is no special output on the wrong log file. Actually I am a bit > puzzled as I am not a real expert "admin". I only enjoy getting my hands on > Unix on my desktop PC just for fun. > > However, do you think either I missed something or made anything wrong? > I look forward to receiving from you. > > Cheers, > Daniele. > > > > 2014-07-10 23:27 GMT+02:00 Anthony Jenkins : > >> On 07/10/2014 16:49, Daniele Mazzotti wrote: >>> Hello there, >>> >>> it is been a while since I finished installing Freebsd 10 on my Sony Vaio >>> PC and resolving (or at least I am trying to) one by one, all the >> problems >>> this hardware is giving me. Actually I cannot find a solution to >> correctly >>> display the battery level on my laptop. If I unplug my PC from the power >>> and type 'sysctl hw.acpi.battery' this is the result I get: >>> >>> hw.acpi.battery.life: -1 >>> hw.acpi.battery.time: -1 >>> hw.acpi.battery.state: 7 >>> hw.acpi.battery.units: 1 >>> hw.acpi.battery.info_expire: 5 >>> >>> Moreover the suspend mode is giving me some problems as well, but this >> has >>> definitely a lower priority. >>> >>> I either tried to search for a solution on the FreeBSD Handook with no >>> luck, and google the problem a little bit, but I could not find any >>> valuable help. I would be really interested to investigate the problem >>> further. Is there anyone who can help me out with this and tell me what >>> pieces of information are needed to better understand the problem? >> Try enabling the ACPI_BATTERY layer and ACPI_LV_ALL_EXCEPTIONS level in >> /boot/loader.conf: >> >> debug.acpi.layer="ACPI_BATTERY" >> debug.acpi.level="ACPI_LV_ALL_EXCEPTIONS" >> debug.acpi.enable_debug_objects="1" # I assume this is how you >> turn on ACPI debugging without recompiling the kernel with 'options >> ACPI_DEBUG' >> >> and running 'sysctl hw.acpi.battery' again. Post /var/log/messages ACPI >> messages about battery here. >> >> Anthony >> >>> Cheers, >>> Daniele. >>> _______________________________________________ >>> freebsd-acpi@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-acpi >>> To unsubscribe, send any mail to "freebsd-acpi-unsubscribe@freebsd.org" >>> >> > _______________________________________________ > freebsd-acpi@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-acpi > To unsubscribe, send any mail to "freebsd-acpi-unsubscribe@freebsd.org" > From owner-freebsd-acpi@FreeBSD.ORG Fri Jul 11 16:10:24 2014 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A4AFBF10 for ; Fri, 11 Jul 2014 16:10:24 +0000 (UTC) Received: from mail-oa0-x233.google.com (mail-oa0-x233.google.com [IPv6:2607:f8b0:4003:c02::233]) (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 69D0F29F4 for ; Fri, 11 Jul 2014 16:10:24 +0000 (UTC) Received: by mail-oa0-f51.google.com with SMTP id j17so1432100oag.24 for ; Fri, 11 Jul 2014 09:10:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=I30SJggj3ypNmt/v6ZSOXY5qSb6L3C399hnZKumDmlE=; b=hwh24udwOUhBD9x7kgw7Gwx9yKKZURTWWuZoKYamCxEB/tby5MUD1FKEvYy1BZSCq/ J9PgxrHUIYtlJwj5nVvepkTlwdIcaTrnKdIuyZxbc+P6gIdFfJlPHbdyFZTuluWawUBN gC1iKTttS372evjZnSBn7NWbmeDXMtbZv54JUAIHtkEybcG+AekxcZWjZsTm6WLd9tFd 64G/zoP1ER/L8cOTPXctNjMSSMdLqPc3pLMrQkYZ0id8QiiPc/lyzCJCf0LN9AELw9Bu 4OvWg0+0j0rWgj3y6C9E1BKhSv/4RnnbtHjiKolnP3NnYzmm4kj7fp+hiYe9SttL6wK7 Wz6g== MIME-Version: 1.0 X-Received: by 10.182.60.65 with SMTP id f1mr13534778obr.78.1405095023737; Fri, 11 Jul 2014 09:10:23 -0700 (PDT) Received: by 10.182.29.9 with HTTP; Fri, 11 Jul 2014 09:10:23 -0700 (PDT) In-Reply-To: <53BFCBF4.2090104@att.net> References: <53BF0546.70505@att.net> <53BFCBF4.2090104@att.net> Date: Fri, 11 Jul 2014 18:10:23 +0200 Message-ID: Subject: Re: ACPI support - Freebsd 10 on Sony Vaio VPCCA3C5E From: Daniele Mazzotti To: Anthony Jenkins , takawata@init-main.com Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18 Cc: freebsd-acpi@freebsd.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jul 2014 16:10:24 -0000 Hi guys, thanks again for the support. @Takanori: here you go http://pastebin.com/F0a2mZP4 @Anthony: I will try to include the options in a custom kernel and compile it. As this is the first time after years I am compiling a custom kernel it will take a few time I guess. Just let me know if the output of the acpidump is of any help to you. Cheers, Daniele. 2014-07-11 13:35 GMT+02:00 Anthony Jenkins : > Hi Daniele, > > I was just going from acpi(4) man page; you'll likely have to build a new > kernel with 'options ACPI_DEBUG' added to your kernel config file, as I > don't know if it's even possible to turn on the logging I want at runtime. > > [ajenkins@ajenkins-hplaptop /usr/home/ajenkins]$ grep -i acpi > /usr/src/sys/amd64/conf/MYKERNEL > device acpi > options ACPI_DEBUG > > I also have an 'options ACPI_DMAR' , but I don't recognize that and you > don't need that to debug your battery. > > Anthony > > On 07/11/2014 01:58, Daniele Mazzotti wrote: > > Hello Anthony, > > > > thanks for the quick reply! I tried what you suggested. > > > > loader.conf: > > > > # Module for Windows Partition & Linux Mount > > fuse_load="YES" > > autoboot_delay="5" > > #acpi_sony_load="YES" > > > > # Debugging Symbols for ACPI > > debug.acpi.layer="ACPI_BATTERY" > > debug.acpi.level="ACPI_LV_ALL_EXCEPTIONS" > > debug.acpi.enable_debug_objects="1" > > > > sysctl hw.acpi.battery: > > > > hw.acpi.battery.life: -1 > > hw.acpi.battery.time: -1 > > hw.acpi.battery.state: 7 > > hw.acpi.battery.units: 1 > > hw.acpi.battery.info_expire: 5 > > > > log/messages: > > > > cat /var/log/messages | grep acpi > > > > Jul 11 07:30:47 Von-Neumann kernel: acpi0: on motherboard > > Jul 11 07:30:47 Von-Neumann kernel: acpi_ec0: > 0x17, ECDT> port 0x62,0x66 on acpi0 > > Jul 11 07:30:47 Von-Neumann kernel: cpu0: on acpi0 > > Jul 11 07:30:47 Von-Neumann kernel: cpu1: on acpi0 > > Jul 11 07:30:47 Von-Neumann kernel: cpu2: on acpi0 > > Jul 11 07:30:47 Von-Neumann kernel: cpu3: on acpi0 > > Jul 11 07:30:47 Von-Neumann kernel: hpet0: > > iomem 0xfed00000-0xfed003ff on acpi0 > > Jul 11 07:30:47 Von-Neumann kernel: atrtc0: port > > 0x70-0x77 irq 8 on acpi0 > > Jul 11 07:30:47 Von-Neumann kernel: attimer0: port > > 0x40-0x43,0x50-0x53 irq 0 on acpi0 > > Jul 11 07:30:47 Von-Neumann kernel: acpi_timer0: <24-bit timer at > > 3.579545MHz> port 0x408-0x40b on acpi0 > > Jul 11 07:30:47 Von-Neumann kernel: pcib0: port > > 0xcf8-0xcff on acpi0 > > Jul 11 07:30:47 Von-Neumann kernel: battery0: Battery> > > on acpi0 > > Jul 11 07:30:47 Von-Neumann kernel: acpi_acad0: on acpi0 > > Jul 11 07:30:47 Von-Neumann kernel: acpi_lid0: Switch> > > on acpi0 > > Jul 11 07:30:47 Von-Neumann kernel: acpi_button0: on acpi0 > > Jul 11 07:30:47 Von-Neumann kernel: acpi_tz0: on acpi0 > > Jul 11 07:30:47 Von-Neumann kernel: acpi_tz1: on acpi0 > > Jul 11 07:30:47 Von-Neumann kernel: atkbdc0: (i8042)> > > port 0x60,0x64 irq 1 on acpi0 > > Jul 11 07:30:47 Von-Neumann kernel: acpi_sony0: controller> > > on acpi0 > > Jul 11 07:30:47 Von-Neumann kernel: acpi_sony0: PID 0 > > Jul 11 07:37:54 Von-Neumann kernel: acpi0: on motherboard > > Jul 11 07:37:54 Von-Neumann kernel: acpi_ec0: > 0x17, ECDT> port 0x62,0x66 on acpi0 > > Jul 11 07:37:54 Von-Neumann kernel: cpu0: on acpi0 > > Jul 11 07:37:54 Von-Neumann kernel: cpu1: on acpi0 > > Jul 11 07:37:54 Von-Neumann kernel: cpu2: on acpi0 > > Jul 11 07:37:54 Von-Neumann kernel: cpu3: on acpi0 > > Jul 11 07:37:54 Von-Neumann kernel: hpet0: > > iomem 0xfed00000-0xfed003ff on acpi0 > > Jul 11 07:37:54 Von-Neumann kernel: atrtc0: port > > 0x70-0x77 irq 8 on acpi0 > > Jul 11 07:37:54 Von-Neumann kernel: attimer0: port > > 0x40-0x43,0x50-0x53 irq 0 on acpi0 > > Jul 11 07:37:54 Von-Neumann kernel: acpi_timer0: <24-bit timer at > > 3.579545MHz> port 0x408-0x40b on acpi0 > > Jul 11 07:37:54 Von-Neumann kernel: pcib0: port > > 0xcf8-0xcff on acpi0 > > Jul 11 07:37:54 Von-Neumann kernel: battery0: Battery> > > on acpi0 > > Jul 11 07:37:54 Von-Neumann kernel: acpi_acad0: on acpi0 > > Jul 11 07:37:54 Von-Neumann kernel: acpi_lid0: Switch> > > on acpi0 > > Jul 11 07:37:54 Von-Neumann kernel: acpi_button0: on acpi0 > > Jul 11 07:37:54 Von-Neumann kernel: acpi_tz0: on acpi0 > > Jul 11 07:37:54 Von-Neumann kernel: acpi_tz1: on acpi0 > > Jul 11 07:37:54 Von-Neumann kernel: atkbdc0: (i8042)> > > port 0x60,0x64 irq 1 on acpi0 > > > > It seems to me the verbose debugging is either not enabled (perhaps I > made > > some mistakes with the loader.conf) or the debug is really enabled but > > there is no special output on the wrong log file. Actually I am a bit > > puzzled as I am not a real expert "admin". I only enjoy getting my hands > on > > Unix on my desktop PC just for fun. > > > > However, do you think either I missed something or made anything wrong? > > I look forward to receiving from you. > > > > Cheers, > > Daniele. > > > > > > > > 2014-07-10 23:27 GMT+02:00 Anthony Jenkins : > > > >> On 07/10/2014 16:49, Daniele Mazzotti wrote: > >>> Hello there, > >>> > >>> it is been a while since I finished installing Freebsd 10 on my Sony > Vaio > >>> PC and resolving (or at least I am trying to) one by one, all the > >> problems > >>> this hardware is giving me. Actually I cannot find a solution to > >> correctly > >>> display the battery level on my laptop. If I unplug my PC from the > power > >>> and type 'sysctl hw.acpi.battery' this is the result I get: > >>> > >>> hw.acpi.battery.life: -1 > >>> hw.acpi.battery.time: -1 > >>> hw.acpi.battery.state: 7 > >>> hw.acpi.battery.units: 1 > >>> hw.acpi.battery.info_expire: 5 > >>> > >>> Moreover the suspend mode is giving me some problems as well, but this > >> has > >>> definitely a lower priority. > >>> > >>> I either tried to search for a solution on the FreeBSD Handook with no > >>> luck, and google the problem a little bit, but I could not find any > >>> valuable help. I would be really interested to investigate the problem > >>> further. Is there anyone who can help me out with this and tell me what > >>> pieces of information are needed to better understand the problem? > >> Try enabling the ACPI_BATTERY layer and ACPI_LV_ALL_EXCEPTIONS level in > >> /boot/loader.conf: > >> > >> debug.acpi.layer="ACPI_BATTERY" > >> debug.acpi.level="ACPI_LV_ALL_EXCEPTIONS" > >> debug.acpi.enable_debug_objects="1" # I assume this is how > you > >> turn on ACPI debugging without recompiling the kernel with 'options > >> ACPI_DEBUG' > >> > >> and running 'sysctl hw.acpi.battery' again. Post /var/log/messages ACPI > >> messages about battery here. > >> > >> Anthony > >> > >>> Cheers, > >>> Daniele. > >>> _______________________________________________ > >>> freebsd-acpi@freebsd.org mailing list > >>> http://lists.freebsd.org/mailman/listinfo/freebsd-acpi > >>> To unsubscribe, send any mail to "freebsd-acpi-unsubscribe@freebsd.org > " > >>> > >> > > _______________________________________________ > > freebsd-acpi@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-acpi > > To unsubscribe, send any mail to "freebsd-acpi-unsubscribe@freebsd.org" > > > > From owner-freebsd-acpi@FreeBSD.ORG Fri Jul 11 17:12:24 2014 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EAE78257 for ; Fri, 11 Jul 2014 17:12:24 +0000 (UTC) Received: from mail-oa0-x229.google.com (mail-oa0-x229.google.com [IPv6:2607:f8b0:4003:c02::229]) (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 AF49F20E9 for ; Fri, 11 Jul 2014 17:12:24 +0000 (UTC) Received: by mail-oa0-f41.google.com with SMTP id l6so1538415oag.0 for ; Fri, 11 Jul 2014 10:12:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=zd/G89BqUZP9d/WAT+oyp592qUzP8T/TPFgzSE8G2VY=; b=ODFgLXIAw5CRO7++XVhC0j5dif2B9KbsXjxEXsNQGlfSKHm9Ih0zpDmIy5WQ/E6X50 pqDkzt9BTjhLfp7KqDIoNc0cIv0iGW0X3FMQK55VXRJrIDblOZA8lB49+LIrPmCWGstH NU40p1ZgW7p+1RoVnPxyzMtUn6KbkmbLLJYAO5UonolY4PVefH70X8fpteNRBtMgnSTY fXHDNZV2S3jvVi7ljVd8uWLz12tOsCuSvn5W2AtZcOX/F/mF2gIWmRDdIS8n75uW0dWf wPvzBZBLFPmSn/SuIjKO6qM4EqyggLPr3OmJm/8ghDNHCeahkBbio6D+IjCLxdSR1Cwp RKUQ== MIME-Version: 1.0 X-Received: by 10.182.98.194 with SMTP id ek2mr187730obb.5.1405098743994; Fri, 11 Jul 2014 10:12:23 -0700 (PDT) Received: by 10.182.29.9 with HTTP; Fri, 11 Jul 2014 10:12:23 -0700 (PDT) In-Reply-To: References: <53BF0546.70505@att.net> <53BFCBF4.2090104@att.net> Date: Fri, 11 Jul 2014 19:12:23 +0200 Message-ID: Subject: Re: ACPI support - Freebsd 10 on Sony Vaio VPCCA3C5E From: Daniele Mazzotti To: Anthony Jenkins , takawata@init-main.com Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18 Cc: freebsd-acpi@freebsd.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jul 2014 17:12:25 -0000 Hi guys, everything as planned! I am getting a compiling error :-). This is the way i managed to update the GENERIC kernel # Bus support. device acpi options ACPI_DEBUG # Debug support for ACPI device pci and this is the result of # *make buildkernel KERNCONF=MYKERNEL* ===> crypto (depend) @ -> /usr/src/sys awk -f @/tools/makeobjops.awk @/opencrypto/cryptodev_if.m -c make[4]: stopped in /usr/src/sys/modules/crypto *** Error code 2 Stop. make[3]: stopped in /usr/src/sys/modules *** Error code 1 Stop. make[2]: stopped in /usr/obj/usr/src/sys/GENERIC *** Error code 1 Stop. make[1]: stopped in /usr/src *** Error code 1 Stop. make: stopped in /usr/src I googled a bit, but I could not find any valuable help and actually I do not know what could be wrong as the custom kernel is essentially the GENERIC with just one line added. Have you ever experienced such a problem? Cheers, Daniele. 2014-07-11 18:10 GMT+02:00 Daniele Mazzotti : > Hi guys, > > thanks again for the support. > > @Takanori: here you go http://pastebin.com/F0a2mZP4 > @Anthony: I will try to include the options in a custom kernel and compile > it. As this is the first time after years I am compiling a custom kernel it > will take a few time I guess. > > Just let me know if the output of the acpidump is of any help to you. > Cheers, > Daniele. > > > 2014-07-11 13:35 GMT+02:00 Anthony Jenkins : > > Hi Daniele, >> >> I was just going from acpi(4) man page; you'll likely have to build a new >> kernel with 'options ACPI_DEBUG' added to your kernel config file, as I >> don't know if it's even possible to turn on the logging I want at runtime. >> >> [ajenkins@ajenkins-hplaptop /usr/home/ajenkins]$ grep -i acpi >> /usr/src/sys/amd64/conf/MYKERNEL >> device acpi >> options ACPI_DEBUG >> >> I also have an 'options ACPI_DMAR' , but I don't recognize that and you >> don't need that to debug your battery. >> >> Anthony >> >> On 07/11/2014 01:58, Daniele Mazzotti wrote: >> > Hello Anthony, >> > >> > thanks for the quick reply! I tried what you suggested. >> > >> > loader.conf: >> > >> > # Module for Windows Partition & Linux Mount >> > fuse_load="YES" >> > autoboot_delay="5" >> > #acpi_sony_load="YES" >> > >> > # Debugging Symbols for ACPI >> > debug.acpi.layer="ACPI_BATTERY" >> > debug.acpi.level="ACPI_LV_ALL_EXCEPTIONS" >> > debug.acpi.enable_debug_objects="1" >> > >> > sysctl hw.acpi.battery: >> > >> > hw.acpi.battery.life: -1 >> > hw.acpi.battery.time: -1 >> > hw.acpi.battery.state: 7 >> > hw.acpi.battery.units: 1 >> > hw.acpi.battery.info_expire: 5 >> > >> > log/messages: >> > >> > cat /var/log/messages | grep acpi >> > >> > Jul 11 07:30:47 Von-Neumann kernel: acpi0: on motherboard >> > Jul 11 07:30:47 Von-Neumann kernel: acpi_ec0: > > 0x17, ECDT> port 0x62,0x66 on acpi0 >> > Jul 11 07:30:47 Von-Neumann kernel: cpu0: on acpi0 >> > Jul 11 07:30:47 Von-Neumann kernel: cpu1: on acpi0 >> > Jul 11 07:30:47 Von-Neumann kernel: cpu2: on acpi0 >> > Jul 11 07:30:47 Von-Neumann kernel: cpu3: on acpi0 >> > Jul 11 07:30:47 Von-Neumann kernel: hpet0: >> > iomem 0xfed00000-0xfed003ff on acpi0 >> > Jul 11 07:30:47 Von-Neumann kernel: atrtc0: port >> > 0x70-0x77 irq 8 on acpi0 >> > Jul 11 07:30:47 Von-Neumann kernel: attimer0: port >> > 0x40-0x43,0x50-0x53 irq 0 on acpi0 >> > Jul 11 07:30:47 Von-Neumann kernel: acpi_timer0: <24-bit timer at >> > 3.579545MHz> port 0x408-0x40b on acpi0 >> > Jul 11 07:30:47 Von-Neumann kernel: pcib0: port >> > 0xcf8-0xcff on acpi0 >> > Jul 11 07:30:47 Von-Neumann kernel: battery0: > Battery> >> > on acpi0 >> > Jul 11 07:30:47 Von-Neumann kernel: acpi_acad0: on acpi0 >> > Jul 11 07:30:47 Von-Neumann kernel: acpi_lid0: > Switch> >> > on acpi0 >> > Jul 11 07:30:47 Von-Neumann kernel: acpi_button0: on >> acpi0 >> > Jul 11 07:30:47 Von-Neumann kernel: acpi_tz0: on acpi0 >> > Jul 11 07:30:47 Von-Neumann kernel: acpi_tz1: on acpi0 >> > Jul 11 07:30:47 Von-Neumann kernel: atkbdc0: > (i8042)> >> > port 0x60,0x64 irq 1 on acpi0 >> > Jul 11 07:30:47 Von-Neumann kernel: acpi_sony0: > controller> >> > on acpi0 >> > Jul 11 07:30:47 Von-Neumann kernel: acpi_sony0: PID 0 >> > Jul 11 07:37:54 Von-Neumann kernel: acpi0: on motherboard >> > Jul 11 07:37:54 Von-Neumann kernel: acpi_ec0: > > 0x17, ECDT> port 0x62,0x66 on acpi0 >> > Jul 11 07:37:54 Von-Neumann kernel: cpu0: on acpi0 >> > Jul 11 07:37:54 Von-Neumann kernel: cpu1: on acpi0 >> > Jul 11 07:37:54 Von-Neumann kernel: cpu2: on acpi0 >> > Jul 11 07:37:54 Von-Neumann kernel: cpu3: on acpi0 >> > Jul 11 07:37:54 Von-Neumann kernel: hpet0: >> > iomem 0xfed00000-0xfed003ff on acpi0 >> > Jul 11 07:37:54 Von-Neumann kernel: atrtc0: port >> > 0x70-0x77 irq 8 on acpi0 >> > Jul 11 07:37:54 Von-Neumann kernel: attimer0: port >> > 0x40-0x43,0x50-0x53 irq 0 on acpi0 >> > Jul 11 07:37:54 Von-Neumann kernel: acpi_timer0: <24-bit timer at >> > 3.579545MHz> port 0x408-0x40b on acpi0 >> > Jul 11 07:37:54 Von-Neumann kernel: pcib0: port >> > 0xcf8-0xcff on acpi0 >> > Jul 11 07:37:54 Von-Neumann kernel: battery0: > Battery> >> > on acpi0 >> > Jul 11 07:37:54 Von-Neumann kernel: acpi_acad0: on acpi0 >> > Jul 11 07:37:54 Von-Neumann kernel: acpi_lid0: > Switch> >> > on acpi0 >> > Jul 11 07:37:54 Von-Neumann kernel: acpi_button0: on >> acpi0 >> > Jul 11 07:37:54 Von-Neumann kernel: acpi_tz0: on acpi0 >> > Jul 11 07:37:54 Von-Neumann kernel: acpi_tz1: on acpi0 >> > Jul 11 07:37:54 Von-Neumann kernel: atkbdc0: > (i8042)> >> > port 0x60,0x64 irq 1 on acpi0 >> > >> > It seems to me the verbose debugging is either not enabled (perhaps I >> made >> > some mistakes with the loader.conf) or the debug is really enabled but >> > there is no special output on the wrong log file. Actually I am a bit >> > puzzled as I am not a real expert "admin". I only enjoy getting my >> hands on >> > Unix on my desktop PC just for fun. >> > >> > However, do you think either I missed something or made anything wrong? >> > I look forward to receiving from you. >> > >> > Cheers, >> > Daniele. >> > >> > >> > >> > 2014-07-10 23:27 GMT+02:00 Anthony Jenkins : >> > >> >> On 07/10/2014 16:49, Daniele Mazzotti wrote: >> >>> Hello there, >> >>> >> >>> it is been a while since I finished installing Freebsd 10 on my Sony >> Vaio >> >>> PC and resolving (or at least I am trying to) one by one, all the >> >> problems >> >>> this hardware is giving me. Actually I cannot find a solution to >> >> correctly >> >>> display the battery level on my laptop. If I unplug my PC from the >> power >> >>> and type 'sysctl hw.acpi.battery' this is the result I get: >> >>> >> >>> hw.acpi.battery.life: -1 >> >>> hw.acpi.battery.time: -1 >> >>> hw.acpi.battery.state: 7 >> >>> hw.acpi.battery.units: 1 >> >>> hw.acpi.battery.info_expire: 5 >> >>> >> >>> Moreover the suspend mode is giving me some problems as well, but this >> >> has >> >>> definitely a lower priority. >> >>> >> >>> I either tried to search for a solution on the FreeBSD Handook with no >> >>> luck, and google the problem a little bit, but I could not find any >> >>> valuable help. I would be really interested to investigate the problem >> >>> further. Is there anyone who can help me out with this and tell me >> what >> >>> pieces of information are needed to better understand the problem? >> >> Try enabling the ACPI_BATTERY layer and ACPI_LV_ALL_EXCEPTIONS level in >> >> /boot/loader.conf: >> >> >> >> debug.acpi.layer="ACPI_BATTERY" >> >> debug.acpi.level="ACPI_LV_ALL_EXCEPTIONS" >> >> debug.acpi.enable_debug_objects="1" # I assume this is how >> you >> >> turn on ACPI debugging without recompiling the kernel with 'options >> >> ACPI_DEBUG' >> >> >> >> and running 'sysctl hw.acpi.battery' again. Post /var/log/messages >> ACPI >> >> messages about battery here. >> >> >> >> Anthony >> >> >> >>> Cheers, >> >>> Daniele. >> >>> _______________________________________________ >> >>> freebsd-acpi@freebsd.org mailing list >> >>> http://lists.freebsd.org/mailman/listinfo/freebsd-acpi >> >>> To unsubscribe, send any mail to " >> freebsd-acpi-unsubscribe@freebsd.org" >> >>> >> >> >> > _______________________________________________ >> > freebsd-acpi@freebsd.org mailing list >> > http://lists.freebsd.org/mailman/listinfo/freebsd-acpi >> > To unsubscribe, send any mail to "freebsd-acpi-unsubscribe@freebsd.org" >> > >> >> > From owner-freebsd-acpi@FreeBSD.ORG Fri Jul 11 17:17:55 2014 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 510C93AF for ; Fri, 11 Jul 2014 17:17:55 +0000 (UTC) Received: from nm4-vm1.access.bullet.mail.gq1.yahoo.com (nm4-vm1.access.bullet.mail.gq1.yahoo.com [216.39.63.2]) (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 0EC8C2134 for ; Fri, 11 Jul 2014 17:17:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s2048; t=1405098934; bh=ahnp74TCuavQFhYTRmVfRViJlaC7gqojzZBNrYF9cm0=; h=Received:Received:Received:DKIM-Signature:X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=MOsL4fJ4hdsG2P9Z0/IM/LFyBIjcB6b8iPocs1BgA0hxz1c2pFJPkE8PIRpy/0y7O12lLqsIgdt/UeTTy84rUSEyxk/72QG/1cMOwcMC1CsO8h4eWskrf7DzTa+jkMTg9rWV50RhFdG6NnVzxo0MS7bSxdDrsfy+VYREfI1FtuRu2a8isLaOTAzCVdC64Y1KS6lSlurvjvMgmdWwsOJ7/bdH4Q0JXJnEkYmJh9C2N8GB/Ba8TkKwgc183724enKykbOIkfE4Lg1XET3prjyNGu4jowrDBaWP2UAxnmGztNu0FhlIoosUSUMVoRA++lCoRfXhCL7xyFCHPXCBjNlo0Q== DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s2048; d=att.net; b=AhT1VSZCyHM1o/QVcZ39dmgu45cxkw8ddu/l6220G9A2VoR99OBO/MghUDYNUseZcQBVifrwfIaEqav/3TMDCF4njQYjQS3YiAn4IabqlfB2hZRywIny+ISiFxR8NcEaB8O3ghLr2qA5mSGBG4zO7CtfM4tfFpCa52RRV9VXOh7qrJ6wE5UWlgybEqEA8xuKg8xRJA6TUoSD/6G0yaT2oHwCpLNb2fhKqnmLOK7V63M/aT8awW++aCFuAIrLWSKMZn9CIwQHryxmFRdWYnN7Q3o2m7t/dm4aIn7eo2K9O3oUlwj381go+kGU3Mk4UWdn9T+nK1OpdAgr6HPVQdj+/w==; Received: from [216.39.60.166] by nm4.access.bullet.mail.gq1.yahoo.com with NNFMP; 11 Jul 2014 17:15:34 -0000 Received: from [67.195.22.118] by tm2.access.bullet.mail.gq1.yahoo.com with NNFMP; 11 Jul 2014 17:15:34 -0000 Received: from [127.0.0.1] by smtp113.sbc.mail.gq1.yahoo.com with NNFMP; 11 Jul 2014 17:15:34 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1405098934; bh=ahnp74TCuavQFhYTRmVfRViJlaC7gqojzZBNrYF9cm0=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=xOdZdiWlmUKW4cwcVSn86/Loe43K6Y0WtUjcBg37Js9LPfzLzAOCKhF8tuQH7Qy6zbxd+s0ECv7q5ewKmGkuIrVa/xIkmo4VarSk2A9D65omMiy7ZiAmxjl2flO2dIwqTwe259IOb2g2ae1/EKfz8X/iWFSrcCyIbH18pADkfec= X-Yahoo-Newman-Id: 814363.3160.bm@smtp113.sbc.mail.gq1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: o0yLoscVM1lZ4YFCyyrfgpNG2wc8rZMTjBcon4KoOOMxnc8 8GMgU_G7KZY9x_rR4ZfyJTMm8CrtM2K5GFOpoMold_PO3S8PCJwcFJ0jhTUl 3j8Olc4FDD6IMaBYl2vHDOe81cLgcJmCqAzT64xyzt5uVsCdkmOCCpDQp5h. r76soeg0krFYqCk.3JHPCdqZJTdAqR3OYpExFRTZZX0jNK67p0O3cQ4i6xqK aX2TLHL2jlT0OZIJWOHuLeY9oce5A.oTcVH1POQT1Jp7AkyAFZlvdW6BhJgw BALTgoY4ng1Pz1bxvXwbuqoixe25HdzRUhpFJykbdysLSVyKSmWnZMAkV_H6 IBpvBjMrkoAQ8Pvbr.YDt_kHQ.rE.eziX31ugyMR9sT0KRqmQsnPK.2dBFzy Dbxgws8ql_1VauNns0wKdiZWsYysVAKr2SQ_QK3ApFpKm6SfeSlHaxTIAoUW vKfs4cBVaPr5u9P800sFeg2K6MM1Wp8nKzvST9._7kWjziyxA1P7phN7eBZv paUGz3qHCMgQ8zI0o2KNZC.s.iFxwuezRFAZY0ckrE0PUTMyS X-Yahoo-SMTP: OKD1keCswBBTAmAF1s00hLyKW3wE3YfSK0Eazl6b4VZG4LTqJxg- Message-ID: <53C01BB6.8080109@att.net> Date: Fri, 11 Jul 2014 13:15:34 -0400 From: Anthony Jenkins User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Daniele Mazzotti , takawata@init-main.com Subject: Re: ACPI support - Freebsd 10 on Sony Vaio VPCCA3C5E References: <53BF0546.70505@att.net> <53BFCBF4.2090104@att.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@freebsd.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jul 2014 17:17:55 -0000 Takawata might be able to help you better than me; I'm trying to learn this ACPI stuff myself (trying to add support for ACPI CMOS regions and fix my own laptop's flakiness). If you're just running a generic kernel, I'm pretty sure all you have to do is: 1. Ensure you have the system sources installed at /usr/src. 2. Copy /usr/src/sys/$(uname -m)/conf/GENERIC to /usr/src/sys/$(uname -m)/conf/MYKERNEL. * 3. Edit /usr/src/sys/$(uname -m)/conf/MYKERNEL to add the 'options ACPI_DEBUG' line. 4. 'cd' to /usr/src. 5. Run 'make kernel KERNCONF=MYKERNEL'. 6. Reboot. * 'uname -m' prints your system architecture (e.g. 'amd64' or 'i386'); you could simply substitute the architecture string in the paths above. Anthony On 07/11/2014 12:10, Daniele Mazzotti wrote: > Hi guys, > > thanks again for the support. > > @Anthony: I will try to include the options in a custom kernel and compile > it. As this is the first time after years I am compiling a custom kernel it > will take a few time I guess. > > Just let me know if the output of the acpidump is of any help to you. > Cheers, > Daniele. > > > 2014-07-11 13:35 GMT+02:00 Anthony Jenkins : > >> Hi Daniele, >> >> I was just going from acpi(4) man page; you'll likely have to build a new >> kernel with 'options ACPI_DEBUG' added to your kernel config file, as I >> don't know if it's even possible to turn on the logging I want at runtime. >> >> [ajenkins@ajenkins-hplaptop /usr/home/ajenkins]$ grep -i acpi >> /usr/src/sys/amd64/conf/MYKERNEL >> device acpi >> options ACPI_DEBUG >> >> I also have an 'options ACPI_DMAR' , but I don't recognize that and you >> don't need that to debug your battery. >> >> Anthony >> >> On 07/11/2014 01:58, Daniele Mazzotti wrote: >>> Hello Anthony, >>> >>> thanks for the quick reply! I tried what you suggested. >>> >>> loader.conf: >>> >>> # Module for Windows Partition & Linux Mount >>> fuse_load="YES" >>> autoboot_delay="5" >>> #acpi_sony_load="YES" >>> >>> # Debugging Symbols for ACPI >>> debug.acpi.layer="ACPI_BATTERY" >>> debug.acpi.level="ACPI_LV_ALL_EXCEPTIONS" >>> debug.acpi.enable_debug_objects="1" >>> >>> sysctl hw.acpi.battery: >>> >>> hw.acpi.battery.life: -1 >>> hw.acpi.battery.time: -1 >>> hw.acpi.battery.state: 7 >>> hw.acpi.battery.units: 1 >>> hw.acpi.battery.info_expire: 5 >>> >>> log/messages: >>> >>> cat /var/log/messages | grep acpi >>> >>> Jul 11 07:30:47 Von-Neumann kernel: acpi0: on motherboard >>> Jul 11 07:30:47 Von-Neumann kernel: acpi_ec0: >> 0x17, ECDT> port 0x62,0x66 on acpi0 >>> Jul 11 07:30:47 Von-Neumann kernel: cpu0: on acpi0 >>> Jul 11 07:30:47 Von-Neumann kernel: cpu1: on acpi0 >>> Jul 11 07:30:47 Von-Neumann kernel: cpu2: on acpi0 >>> Jul 11 07:30:47 Von-Neumann kernel: cpu3: on acpi0 >>> Jul 11 07:30:47 Von-Neumann kernel: hpet0: >>> iomem 0xfed00000-0xfed003ff on acpi0 >>> Jul 11 07:30:47 Von-Neumann kernel: atrtc0: port >>> 0x70-0x77 irq 8 on acpi0 >>> Jul 11 07:30:47 Von-Neumann kernel: attimer0: port >>> 0x40-0x43,0x50-0x53 irq 0 on acpi0 >>> Jul 11 07:30:47 Von-Neumann kernel: acpi_timer0: <24-bit timer at >>> 3.579545MHz> port 0x408-0x40b on acpi0 >>> Jul 11 07:30:47 Von-Neumann kernel: pcib0: port >>> 0xcf8-0xcff on acpi0 >>> Jul 11 07:30:47 Von-Neumann kernel: battery0: > Battery> >>> on acpi0 >>> Jul 11 07:30:47 Von-Neumann kernel: acpi_acad0: on acpi0 >>> Jul 11 07:30:47 Von-Neumann kernel: acpi_lid0: > Switch> >>> on acpi0 >>> Jul 11 07:30:47 Von-Neumann kernel: acpi_button0: on acpi0 >>> Jul 11 07:30:47 Von-Neumann kernel: acpi_tz0: on acpi0 >>> Jul 11 07:30:47 Von-Neumann kernel: acpi_tz1: on acpi0 >>> Jul 11 07:30:47 Von-Neumann kernel: atkbdc0: > (i8042)> >>> port 0x60,0x64 irq 1 on acpi0 >>> Jul 11 07:30:47 Von-Neumann kernel: acpi_sony0: > controller> >>> on acpi0 >>> Jul 11 07:30:47 Von-Neumann kernel: acpi_sony0: PID 0 >>> Jul 11 07:37:54 Von-Neumann kernel: acpi0: on motherboard >>> Jul 11 07:37:54 Von-Neumann kernel: acpi_ec0: >> 0x17, ECDT> port 0x62,0x66 on acpi0 >>> Jul 11 07:37:54 Von-Neumann kernel: cpu0: on acpi0 >>> Jul 11 07:37:54 Von-Neumann kernel: cpu1: on acpi0 >>> Jul 11 07:37:54 Von-Neumann kernel: cpu2: on acpi0 >>> Jul 11 07:37:54 Von-Neumann kernel: cpu3: on acpi0 >>> Jul 11 07:37:54 Von-Neumann kernel: hpet0: >>> iomem 0xfed00000-0xfed003ff on acpi0 >>> Jul 11 07:37:54 Von-Neumann kernel: atrtc0: port >>> 0x70-0x77 irq 8 on acpi0 >>> Jul 11 07:37:54 Von-Neumann kernel: attimer0: port >>> 0x40-0x43,0x50-0x53 irq 0 on acpi0 >>> Jul 11 07:37:54 Von-Neumann kernel: acpi_timer0: <24-bit timer at >>> 3.579545MHz> port 0x408-0x40b on acpi0 >>> Jul 11 07:37:54 Von-Neumann kernel: pcib0: port >>> 0xcf8-0xcff on acpi0 >>> Jul 11 07:37:54 Von-Neumann kernel: battery0: > Battery> >>> on acpi0 >>> Jul 11 07:37:54 Von-Neumann kernel: acpi_acad0: on acpi0 >>> Jul 11 07:37:54 Von-Neumann kernel: acpi_lid0: > Switch> >>> on acpi0 >>> Jul 11 07:37:54 Von-Neumann kernel: acpi_button0: on acpi0 >>> Jul 11 07:37:54 Von-Neumann kernel: acpi_tz0: on acpi0 >>> Jul 11 07:37:54 Von-Neumann kernel: acpi_tz1: on acpi0 >>> Jul 11 07:37:54 Von-Neumann kernel: atkbdc0: > (i8042)> >>> port 0x60,0x64 irq 1 on acpi0 >>> >>> It seems to me the verbose debugging is either not enabled (perhaps I >> made >>> some mistakes with the loader.conf) or the debug is really enabled but >>> there is no special output on the wrong log file. Actually I am a bit >>> puzzled as I am not a real expert "admin". I only enjoy getting my hands >> on >>> Unix on my desktop PC just for fun. >>> >>> However, do you think either I missed something or made anything wrong? >>> I look forward to receiving from you. >>> >>> Cheers, >>> Daniele. >>> >>> >>> >>> 2014-07-10 23:27 GMT+02:00 Anthony Jenkins : >>> >>>> On 07/10/2014 16:49, Daniele Mazzotti wrote: >>>>> Hello there, >>>>> >>>>> it is been a while since I finished installing Freebsd 10 on my Sony >> Vaio >>>>> PC and resolving (or at least I am trying to) one by one, all the >>>> problems >>>>> this hardware is giving me. Actually I cannot find a solution to >>>> correctly >>>>> display the battery level on my laptop. If I unplug my PC from the >> power >>>>> and type 'sysctl hw.acpi.battery' this is the result I get: >>>>> >>>>> hw.acpi.battery.life: -1 >>>>> hw.acpi.battery.time: -1 >>>>> hw.acpi.battery.state: 7 >>>>> hw.acpi.battery.units: 1 >>>>> hw.acpi.battery.info_expire: 5 >>>>> >>>>> Moreover the suspend mode is giving me some problems as well, but this >>>> has >>>>> definitely a lower priority. >>>>> >>>>> I either tried to search for a solution on the FreeBSD Handook with no >>>>> luck, and google the problem a little bit, but I could not find any >>>>> valuable help. I would be really interested to investigate the problem >>>>> further. Is there anyone who can help me out with this and tell me what >>>>> pieces of information are needed to better understand the problem? >>>> Try enabling the ACPI_BATTERY layer and ACPI_LV_ALL_EXCEPTIONS level in >>>> /boot/loader.conf: >>>> >>>> debug.acpi.layer="ACPI_BATTERY" >>>> debug.acpi.level="ACPI_LV_ALL_EXCEPTIONS" >>>> debug.acpi.enable_debug_objects="1" # I assume this is how >> you >>>> turn on ACPI debugging without recompiling the kernel with 'options >>>> ACPI_DEBUG' >>>> >>>> and running 'sysctl hw.acpi.battery' again. Post /var/log/messages ACPI >>>> messages about battery here. >>>> >>>> Anthony >>>> >>>>> Cheers, >>>>> Daniele. >>>>> _______________________________________________ >>>>> freebsd-acpi@freebsd.org mailing list >>>>> http://lists.freebsd.org/mailman/listinfo/freebsd-acpi >>>>> To unsubscribe, send any mail to "freebsd-acpi-unsubscribe@freebsd.org >> " >>> _______________________________________________ >>> freebsd-acpi@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-acpi >>> To unsubscribe, send any mail to "freebsd-acpi-unsubscribe@freebsd.org" >>> >> > _______________________________________________ > freebsd-acpi@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-acpi > To unsubscribe, send any mail to "freebsd-acpi-unsubscribe@freebsd.org" > From owner-freebsd-acpi@FreeBSD.ORG Fri Jul 11 17:37:12 2014 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 882E88F7 for ; Fri, 11 Jul 2014 17:37:12 +0000 (UTC) Received: from mail-ob0-x22b.google.com (mail-ob0-x22b.google.com [IPv6:2607:f8b0:4003:c01::22b]) (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 4C976231B for ; Fri, 11 Jul 2014 17:37:12 +0000 (UTC) Received: by mail-ob0-f171.google.com with SMTP id wm4so1506348obc.30 for ; Fri, 11 Jul 2014 10:37:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=5i5m8j6K9AiTRqCDzcHWWm+BuvP7suoIxgNIu+Yt2fo=; b=r3xldKyTl9QKNIYlsJR9t95ALbNRzPsWk8G102Z7dElr5f7y9SKCZ8OQ/dfdMWmJmn 5E5OFGgBNIPJ5FBqWk83QqnZzkwyIMnxRKXD8K1aAHnKlAvNfR2ngG8f8e7VRk82CEX0 CRifkXyKqlc4Q+A3rNmwFEsld2DuQDCd+yOp+ufdq87knR9NHMyHB/iTTwUW+GnxcQyn CmQPHDbDLdLkSxPp4rHh2m7oaRs88kdMj/p34Bgp/gTUf+Km7lxZFRgk8galRBoq1AnJ FHY7iGWhpCM/LMublOcR/oifLbYfkpY6Ru+2+79Rrqktq1OTsy+pKfIqyrT3Zn38P224 pFcg== MIME-Version: 1.0 X-Received: by 10.60.45.130 with SMTP id n2mr597929oem.12.1405100229406; Fri, 11 Jul 2014 10:37:09 -0700 (PDT) Received: by 10.182.29.9 with HTTP; Fri, 11 Jul 2014 10:37:09 -0700 (PDT) In-Reply-To: <53C01BB6.8080109@att.net> References: <53BF0546.70505@att.net> <53BFCBF4.2090104@att.net> <53C01BB6.8080109@att.net> Date: Fri, 11 Jul 2014 19:37:09 +0200 Message-ID: Subject: Re: ACPI support - Freebsd 10 on Sony Vaio VPCCA3C5E From: Daniele Mazzotti To: Anthony Jenkins Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18 Cc: freebsd-acpi@freebsd.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jul 2014 17:37:12 -0000 Yep. Basically the prerequisites for compiling are ok and the procedure I followed should be correct as well. I am still getting the error when try to compile the module/crypto and I do not know why. I think I am going to write an email to the "general questions" mailing list as suggested in the handbook. Cheers, Daniele. 2014-07-11 19:15 GMT+02:00 Anthony Jenkins : > Takawata might be able to help you better than me; I'm trying to learn > this ACPI stuff myself (trying to add support for ACPI CMOS regions and fix > my own laptop's flakiness). > > If you're just running a generic kernel, I'm pretty sure all you have to > do is: > > 1. Ensure you have the system sources installed at /usr/src. > 2. Copy /usr/src/sys/$(uname -m)/conf/GENERIC to /usr/src/sys/$(uname > -m)/conf/MYKERNEL. * > 3. Edit /usr/src/sys/$(uname -m)/conf/MYKERNEL to add the 'options > ACPI_DEBUG' line. > 4. 'cd' to /usr/src. > 5. Run 'make kernel KERNCONF=MYKERNEL'. > 6. Reboot. > > * 'uname -m' prints your system architecture (e.g. 'amd64' or 'i386'); you > could simply substitute the architecture string in the paths above. > > Anthony > > > On 07/11/2014 12:10, Daniele Mazzotti wrote: > > Hi guys, > > > > thanks again for the support. > > > > @Anthony: I will try to include the options in a custom kernel and > compile > > it. As this is the first time after years I am compiling a custom kernel > it > > will take a few time I guess. > > > > Just let me know if the output of the acpidump is of any help to you. > > Cheers, > > Daniele. > > > > > > 2014-07-11 13:35 GMT+02:00 Anthony Jenkins : > > > >> Hi Daniele, > >> > >> I was just going from acpi(4) man page; you'll likely have to build a > new > >> kernel with 'options ACPI_DEBUG' added to your kernel config file, as I > >> don't know if it's even possible to turn on the logging I want at > runtime. > >> > >> [ajenkins@ajenkins-hplaptop /usr/home/ajenkins]$ grep -i acpi > >> /usr/src/sys/amd64/conf/MYKERNEL > >> device acpi > >> options ACPI_DEBUG > >> > >> I also have an 'options ACPI_DMAR' , but I don't recognize that and you > >> don't need that to debug your battery. > >> > >> Anthony > >> > >> On 07/11/2014 01:58, Daniele Mazzotti wrote: > >>> Hello Anthony, > >>> > >>> thanks for the quick reply! I tried what you suggested. > >>> > >>> loader.conf: > >>> > >>> # Module for Windows Partition & Linux Mount > >>> fuse_load="YES" > >>> autoboot_delay="5" > >>> #acpi_sony_load="YES" > >>> > >>> # Debugging Symbols for ACPI > >>> debug.acpi.layer="ACPI_BATTERY" > >>> debug.acpi.level="ACPI_LV_ALL_EXCEPTIONS" > >>> debug.acpi.enable_debug_objects="1" > >>> > >>> sysctl hw.acpi.battery: > >>> > >>> hw.acpi.battery.life: -1 > >>> hw.acpi.battery.time: -1 > >>> hw.acpi.battery.state: 7 > >>> hw.acpi.battery.units: 1 > >>> hw.acpi.battery.info_expire: 5 > >>> > >>> log/messages: > >>> > >>> cat /var/log/messages | grep acpi > >>> > >>> Jul 11 07:30:47 Von-Neumann kernel: acpi0: on motherboard > >>> Jul 11 07:30:47 Von-Neumann kernel: acpi_ec0: >>> 0x17, ECDT> port 0x62,0x66 on acpi0 > >>> Jul 11 07:30:47 Von-Neumann kernel: cpu0: on acpi0 > >>> Jul 11 07:30:47 Von-Neumann kernel: cpu1: on acpi0 > >>> Jul 11 07:30:47 Von-Neumann kernel: cpu2: on acpi0 > >>> Jul 11 07:30:47 Von-Neumann kernel: cpu3: on acpi0 > >>> Jul 11 07:30:47 Von-Neumann kernel: hpet0: > >>> iomem 0xfed00000-0xfed003ff on acpi0 > >>> Jul 11 07:30:47 Von-Neumann kernel: atrtc0: port > >>> 0x70-0x77 irq 8 on acpi0 > >>> Jul 11 07:30:47 Von-Neumann kernel: attimer0: port > >>> 0x40-0x43,0x50-0x53 irq 0 on acpi0 > >>> Jul 11 07:30:47 Von-Neumann kernel: acpi_timer0: <24-bit timer at > >>> 3.579545MHz> port 0x408-0x40b on acpi0 > >>> Jul 11 07:30:47 Von-Neumann kernel: pcib0: port > >>> 0xcf8-0xcff on acpi0 > >>> Jul 11 07:30:47 Von-Neumann kernel: battery0: >> Battery> > >>> on acpi0 > >>> Jul 11 07:30:47 Von-Neumann kernel: acpi_acad0: on acpi0 > >>> Jul 11 07:30:47 Von-Neumann kernel: acpi_lid0: >> Switch> > >>> on acpi0 > >>> Jul 11 07:30:47 Von-Neumann kernel: acpi_button0: on > acpi0 > >>> Jul 11 07:30:47 Von-Neumann kernel: acpi_tz0: on acpi0 > >>> Jul 11 07:30:47 Von-Neumann kernel: acpi_tz1: on acpi0 > >>> Jul 11 07:30:47 Von-Neumann kernel: atkbdc0: >> (i8042)> > >>> port 0x60,0x64 irq 1 on acpi0 > >>> Jul 11 07:30:47 Von-Neumann kernel: acpi_sony0: >> controller> > >>> on acpi0 > >>> Jul 11 07:30:47 Von-Neumann kernel: acpi_sony0: PID 0 > >>> Jul 11 07:37:54 Von-Neumann kernel: acpi0: on motherboard > >>> Jul 11 07:37:54 Von-Neumann kernel: acpi_ec0: >>> 0x17, ECDT> port 0x62,0x66 on acpi0 > >>> Jul 11 07:37:54 Von-Neumann kernel: cpu0: on acpi0 > >>> Jul 11 07:37:54 Von-Neumann kernel: cpu1: on acpi0 > >>> Jul 11 07:37:54 Von-Neumann kernel: cpu2: on acpi0 > >>> Jul 11 07:37:54 Von-Neumann kernel: cpu3: on acpi0 > >>> Jul 11 07:37:54 Von-Neumann kernel: hpet0: > >>> iomem 0xfed00000-0xfed003ff on acpi0 > >>> Jul 11 07:37:54 Von-Neumann kernel: atrtc0: port > >>> 0x70-0x77 irq 8 on acpi0 > >>> Jul 11 07:37:54 Von-Neumann kernel: attimer0: port > >>> 0x40-0x43,0x50-0x53 irq 0 on acpi0 > >>> Jul 11 07:37:54 Von-Neumann kernel: acpi_timer0: <24-bit timer at > >>> 3.579545MHz> port 0x408-0x40b on acpi0 > >>> Jul 11 07:37:54 Von-Neumann kernel: pcib0: port > >>> 0xcf8-0xcff on acpi0 > >>> Jul 11 07:37:54 Von-Neumann kernel: battery0: >> Battery> > >>> on acpi0 > >>> Jul 11 07:37:54 Von-Neumann kernel: acpi_acad0: on acpi0 > >>> Jul 11 07:37:54 Von-Neumann kernel: acpi_lid0: >> Switch> > >>> on acpi0 > >>> Jul 11 07:37:54 Von-Neumann kernel: acpi_button0: on > acpi0 > >>> Jul 11 07:37:54 Von-Neumann kernel: acpi_tz0: on acpi0 > >>> Jul 11 07:37:54 Von-Neumann kernel: acpi_tz1: on acpi0 > >>> Jul 11 07:37:54 Von-Neumann kernel: atkbdc0: >> (i8042)> > >>> port 0x60,0x64 irq 1 on acpi0 > >>> > >>> It seems to me the verbose debugging is either not enabled (perhaps I > >> made > >>> some mistakes with the loader.conf) or the debug is really enabled but > >>> there is no special output on the wrong log file. Actually I am a bit > >>> puzzled as I am not a real expert "admin". I only enjoy getting my > hands > >> on > >>> Unix on my desktop PC just for fun. > >>> > >>> However, do you think either I missed something or made anything wrong? > >>> I look forward to receiving from you. > >>> > >>> Cheers, > >>> Daniele. > >>> > >>> > >>> > >>> 2014-07-10 23:27 GMT+02:00 Anthony Jenkins >: > >>> > >>>> On 07/10/2014 16:49, Daniele Mazzotti wrote: > >>>>> Hello there, > >>>>> > >>>>> it is been a while since I finished installing Freebsd 10 on my Sony > >> Vaio > >>>>> PC and resolving (or at least I am trying to) one by one, all the > >>>> problems > >>>>> this hardware is giving me. Actually I cannot find a solution to > >>>> correctly > >>>>> display the battery level on my laptop. If I unplug my PC from the > >> power > >>>>> and type 'sysctl hw.acpi.battery' this is the result I get: > >>>>> > >>>>> hw.acpi.battery.life: -1 > >>>>> hw.acpi.battery.time: -1 > >>>>> hw.acpi.battery.state: 7 > >>>>> hw.acpi.battery.units: 1 > >>>>> hw.acpi.battery.info_expire: 5 > >>>>> > >>>>> Moreover the suspend mode is giving me some problems as well, but > this > >>>> has > >>>>> definitely a lower priority. > >>>>> > >>>>> I either tried to search for a solution on the FreeBSD Handook with > no > >>>>> luck, and google the problem a little bit, but I could not find any > >>>>> valuable help. I would be really interested to investigate the > problem > >>>>> further. Is there anyone who can help me out with this and tell me > what > >>>>> pieces of information are needed to better understand the problem? > >>>> Try enabling the ACPI_BATTERY layer and ACPI_LV_ALL_EXCEPTIONS level > in > >>>> /boot/loader.conf: > >>>> > >>>> debug.acpi.layer="ACPI_BATTERY" > >>>> debug.acpi.level="ACPI_LV_ALL_EXCEPTIONS" > >>>> debug.acpi.enable_debug_objects="1" # I assume this is how > >> you > >>>> turn on ACPI debugging without recompiling the kernel with 'options > >>>> ACPI_DEBUG' > >>>> > >>>> and running 'sysctl hw.acpi.battery' again. Post /var/log/messages > ACPI > >>>> messages about battery here. > >>>> > >>>> Anthony > >>>> > >>>>> Cheers, > >>>>> Daniele. > >>>>> _______________________________________________ > >>>>> freebsd-acpi@freebsd.org mailing list > >>>>> http://lists.freebsd.org/mailman/listinfo/freebsd-acpi > >>>>> To unsubscribe, send any mail to " > freebsd-acpi-unsubscribe@freebsd.org > >> " > >>> _______________________________________________ > >>> freebsd-acpi@freebsd.org mailing list > >>> http://lists.freebsd.org/mailman/listinfo/freebsd-acpi > >>> To unsubscribe, send any mail to "freebsd-acpi-unsubscribe@freebsd.org > " > >>> > >> > > _______________________________________________ > > freebsd-acpi@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-acpi > > To unsubscribe, send any mail to "freebsd-acpi-unsubscribe@freebsd.org" > > > > From owner-freebsd-acpi@FreeBSD.ORG Fri Jul 11 17:40:10 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 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4393E971 for ; Fri, 11 Jul 2014 17:40:10 +0000 (UTC) Received: from nm4-vm2.access.bullet.mail.gq1.yahoo.com (nm4-vm2.access.bullet.mail.gq1.yahoo.com [216.39.63.32]) (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 024202334 for ; Fri, 11 Jul 2014 17:40:09 +0000 (UTC) Received: from [216.39.60.172] by nm4.access.bullet.mail.gq1.yahoo.com with NNFMP; 11 Jul 2014 17:37:18 -0000 Received: from [67.195.23.148] by tm8.access.bullet.mail.gq1.yahoo.com with NNFMP; 11 Jul 2014 17:37:18 -0000 Received: from [127.0.0.1] by smtp120.sbc.mail.gq1.yahoo.com with NNFMP; 11 Jul 2014 17:37:18 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1405100238; bh=kKiXr4LnXnMABzVyhq8KZnNlCMNwMGTJCBLQv0LEGgg=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=eleIsgaJnTOTDWcxb3akUl8Phy2IuqnqOjugiLa6CC25gOQEGsOHxlv7nurBaRe3ejlCsf8Esu26vcWcTdOCQWnpDXIvZ+9f1y9Z6A8pdjzpDM4T3nucBaHZ71e85fIn+Lg4JGe/wkLh10CzDS/Dqn0h4fj1Z7rJKO7okZU13Aw= X-Yahoo-Newman-Id: 692934.44482.bm@smtp120.sbc.mail.gq1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: nv30bqAVM1mmiK11UgqNO3yrTLWv3cUON1bkZL.VFtNwtQS q6d2Bal6XkbMYhb7djJrFAibuMCVktT_MSl2LSYoCNDutuqFo3hPCweJrS5h ASnTRDGlnUingLFIOC364kQqtJdM.zom0yot00Fp5.urNSEg5tbsI0PAaJQm OFMMDX97fcvFoeaJo2QwhEt3I0Zv2eVv7laTNKnQVOkE_VCqWoK0PUSgnM2L RkKXKgRqtIj67vlXkYIpPpZri2uQ_wR4hLgE0qJsH4ocuzNx4XcgAmzW9N_v iXLIbVtebXWuXrHBZmNvEC8XCo3kkty.gzBR.rN2e65K2AXgZtXenbAas6PB Bya_pc28tQPuy0z6LJTJLodw7NW7RHvM4vKiAGAz0zfYAYthdJGKBgn57uHo _kwbuEwqeYcQR0.9GmgbZq1I7t_Yv9Nu1MRKAoVSt7KBNL6UYlVWfJcQJDsz dU9h8kiYy6TJ4BcnyRw3cBg9PVvw7Nw5Fp1hDKaTtC9VeF8Vsq9GythbVETr zdxJiIBCV5xtahBzxKGDY1eB5obuGz6bM2X_5HuQAZVYqGbWCK8_v1Eq_2f9 nWNu8UlyJYpgyl7LjPP0iNoSJTPcHnPdacszAMBF0hAJ7fdcxJ_lOI8jT X-Yahoo-SMTP: OKD1keCswBBTAmAF1s00hLyKW3wE3YfSK0Eazl6b4VZG4LTqJxg- X-Rocket-Received: from [64.100.76.103] (Anthony.B.Jenkins@64.100.76.103 with plain [67.195.15.5]) by smtp120.sbc.mail.gq1.yahoo.com with SMTP; 11 Jul 2014 17:37:18 +0000 UTC Message-ID: <53C020CE.8010205@att.net> Date: Fri, 11 Jul 2014 13:37:18 -0400 From: Anthony Jenkins User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Daniele Mazzotti , takawata@init-main.com Subject: Re: ACPI support - Freebsd 10 on Sony Vaio VPCCA3C5E References: <53BF0546.70505@att.net> <53BFCBF4.2090104@att.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@freebsd.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jul 2014 17:40:10 -0000 I just tried a build of GENERIC + 'options ACPI_DEBUG' and it seems to get past the error you're seeing. What revision of the source code are you using... or where'd you get it from? Anthony On 07/11/2014 13:12, Daniele Mazzotti wrote: > Hi guys, > > everything as planned! I am getting a compiling error :-). > > This is the way i managed to update the GENERIC kernel > > # Bus support. > device acpi > options ACPI_DEBUG # Debug support for ACPI > device pci > > and this is the result of > > # *make buildkernel KERNCONF=MYKERNEL* > > > ===> crypto (depend) > @ -> /usr/src/sys > awk -f @/tools/makeobjops.awk @/opencrypto/cryptodev_if.m -c > > make[4]: stopped in /usr/src/sys/modules/crypto > *** Error code 2 > > Stop. > make[3]: stopped in /usr/src/sys/modules > *** Error code 1 > > Stop. > make[2]: stopped in /usr/obj/usr/src/sys/GENERIC > *** Error code 1 > > Stop. > make[1]: stopped in /usr/src > *** Error code 1 > > Stop. > make: stopped in /usr/src > > I googled a bit, but I could not find any valuable help and actually I do > not know what could be wrong as the custom kernel is essentially the > GENERIC with just one line added. > Have you ever experienced such a problem? > > Cheers, > Daniele. > > > > 2014-07-11 18:10 GMT+02:00 Daniele Mazzotti : > >> Hi guys, >> >> thanks again for the support. >> >> @Takanori: here you go http://pastebin.com/F0a2mZP4 >> @Anthony: I will try to include the options in a custom kernel and compile >> it. As this is the first time after years I am compiling a custom kernel it >> will take a few time I guess. >> >> Just let me know if the output of the acpidump is of any help to you. >> Cheers, >> Daniele. >> >> >> 2014-07-11 13:35 GMT+02:00 Anthony Jenkins : >> >> Hi Daniele, >>> I was just going from acpi(4) man page; you'll likely have to build a new >>> kernel with 'options ACPI_DEBUG' added to your kernel config file, as I >>> don't know if it's even possible to turn on the logging I want at runtime. >>> >>> [ajenkins@ajenkins-hplaptop /usr/home/ajenkins]$ grep -i acpi >>> /usr/src/sys/amd64/conf/MYKERNEL >>> device acpi >>> options ACPI_DEBUG >>> >>> I also have an 'options ACPI_DMAR' , but I don't recognize that and you >>> don't need that to debug your battery. >>> >>> Anthony >>> >>> On 07/11/2014 01:58, Daniele Mazzotti wrote: >>>> Hello Anthony, >>>> >>>> thanks for the quick reply! I tried what you suggested. >>>> >>>> loader.conf: >>>> >>>> # Module for Windows Partition & Linux Mount >>>> fuse_load="YES" >>>> autoboot_delay="5" >>>> #acpi_sony_load="YES" >>>> >>>> # Debugging Symbols for ACPI >>>> debug.acpi.layer="ACPI_BATTERY" >>>> debug.acpi.level="ACPI_LV_ALL_EXCEPTIONS" >>>> debug.acpi.enable_debug_objects="1" >>>> >>>> sysctl hw.acpi.battery: >>>> >>>> hw.acpi.battery.life: -1 >>>> hw.acpi.battery.time: -1 >>>> hw.acpi.battery.state: 7 >>>> hw.acpi.battery.units: 1 >>>> hw.acpi.battery.info_expire: 5 >>>> >>>> log/messages: >>>> >>>> cat /var/log/messages | grep acpi >>>> >>>> Jul 11 07:30:47 Von-Neumann kernel: acpi0: on motherboard >>>> Jul 11 07:30:47 Von-Neumann kernel: acpi_ec0: >>> 0x17, ECDT> port 0x62,0x66 on acpi0 >>>> Jul 11 07:30:47 Von-Neumann kernel: cpu0: on acpi0 >>>> Jul 11 07:30:47 Von-Neumann kernel: cpu1: on acpi0 >>>> Jul 11 07:30:47 Von-Neumann kernel: cpu2: on acpi0 >>>> Jul 11 07:30:47 Von-Neumann kernel: cpu3: on acpi0 >>>> Jul 11 07:30:47 Von-Neumann kernel: hpet0: >>>> iomem 0xfed00000-0xfed003ff on acpi0 >>>> Jul 11 07:30:47 Von-Neumann kernel: atrtc0: port >>>> 0x70-0x77 irq 8 on acpi0 >>>> Jul 11 07:30:47 Von-Neumann kernel: attimer0: port >>>> 0x40-0x43,0x50-0x53 irq 0 on acpi0 >>>> Jul 11 07:30:47 Von-Neumann kernel: acpi_timer0: <24-bit timer at >>>> 3.579545MHz> port 0x408-0x40b on acpi0 >>>> Jul 11 07:30:47 Von-Neumann kernel: pcib0: port >>>> 0xcf8-0xcff on acpi0 >>>> Jul 11 07:30:47 Von-Neumann kernel: battery0: >> Battery> >>>> on acpi0 >>>> Jul 11 07:30:47 Von-Neumann kernel: acpi_acad0: on acpi0 >>>> Jul 11 07:30:47 Von-Neumann kernel: acpi_lid0: >> Switch> >>>> on acpi0 >>>> Jul 11 07:30:47 Von-Neumann kernel: acpi_button0: on >>> acpi0 >>>> Jul 11 07:30:47 Von-Neumann kernel: acpi_tz0: on acpi0 >>>> Jul 11 07:30:47 Von-Neumann kernel: acpi_tz1: on acpi0 >>>> Jul 11 07:30:47 Von-Neumann kernel: atkbdc0: >> (i8042)> >>>> port 0x60,0x64 irq 1 on acpi0 >>>> Jul 11 07:30:47 Von-Neumann kernel: acpi_sony0: >> controller> >>>> on acpi0 >>>> Jul 11 07:30:47 Von-Neumann kernel: acpi_sony0: PID 0 >>>> Jul 11 07:37:54 Von-Neumann kernel: acpi0: on motherboard >>>> Jul 11 07:37:54 Von-Neumann kernel: acpi_ec0: >>> 0x17, ECDT> port 0x62,0x66 on acpi0 >>>> Jul 11 07:37:54 Von-Neumann kernel: cpu0: on acpi0 >>>> Jul 11 07:37:54 Von-Neumann kernel: cpu1: on acpi0 >>>> Jul 11 07:37:54 Von-Neumann kernel: cpu2: on acpi0 >>>> Jul 11 07:37:54 Von-Neumann kernel: cpu3: on acpi0 >>>> Jul 11 07:37:54 Von-Neumann kernel: hpet0: >>>> iomem 0xfed00000-0xfed003ff on acpi0 >>>> Jul 11 07:37:54 Von-Neumann kernel: atrtc0: port >>>> 0x70-0x77 irq 8 on acpi0 >>>> Jul 11 07:37:54 Von-Neumann kernel: attimer0: port >>>> 0x40-0x43,0x50-0x53 irq 0 on acpi0 >>>> Jul 11 07:37:54 Von-Neumann kernel: acpi_timer0: <24-bit timer at >>>> 3.579545MHz> port 0x408-0x40b on acpi0 >>>> Jul 11 07:37:54 Von-Neumann kernel: pcib0: port >>>> 0xcf8-0xcff on acpi0 >>>> Jul 11 07:37:54 Von-Neumann kernel: battery0: >> Battery> >>>> on acpi0 >>>> Jul 11 07:37:54 Von-Neumann kernel: acpi_acad0: on acpi0 >>>> Jul 11 07:37:54 Von-Neumann kernel: acpi_lid0: >> Switch> >>>> on acpi0 >>>> Jul 11 07:37:54 Von-Neumann kernel: acpi_button0: on >>> acpi0 >>>> Jul 11 07:37:54 Von-Neumann kernel: acpi_tz0: on acpi0 >>>> Jul 11 07:37:54 Von-Neumann kernel: acpi_tz1: on acpi0 >>>> Jul 11 07:37:54 Von-Neumann kernel: atkbdc0: >> (i8042)> >>>> port 0x60,0x64 irq 1 on acpi0 >>>> >>>> It seems to me the verbose debugging is either not enabled (perhaps I >>> made >>>> some mistakes with the loader.conf) or the debug is really enabled but >>>> there is no special output on the wrong log file. Actually I am a bit >>>> puzzled as I am not a real expert "admin". I only enjoy getting my >>> hands on >>>> Unix on my desktop PC just for fun. >>>> >>>> However, do you think either I missed something or made anything wrong? >>>> I look forward to receiving from you. >>>> >>>> Cheers, >>>> Daniele. >>>> >>>> >>>> >>>> 2014-07-10 23:27 GMT+02:00 Anthony Jenkins : >>>> >>>>> On 07/10/2014 16:49, Daniele Mazzotti wrote: >>>>>> Hello there, >>>>>> >>>>>> it is been a while since I finished installing Freebsd 10 on my Sony >>> Vaio >>>>>> PC and resolving (or at least I am trying to) one by one, all the >>>>> problems >>>>>> this hardware is giving me. Actually I cannot find a solution to >>>>> correctly >>>>>> display the battery level on my laptop. If I unplug my PC from the >>> power >>>>>> and type 'sysctl hw.acpi.battery' this is the result I get: >>>>>> >>>>>> hw.acpi.battery.life: -1 >>>>>> hw.acpi.battery.time: -1 >>>>>> hw.acpi.battery.state: 7 >>>>>> hw.acpi.battery.units: 1 >>>>>> hw.acpi.battery.info_expire: 5 >>>>>> >>>>>> Moreover the suspend mode is giving me some problems as well, but this >>>>> has >>>>>> definitely a lower priority. >>>>>> >>>>>> I either tried to search for a solution on the FreeBSD Handook with no >>>>>> luck, and google the problem a little bit, but I could not find any >>>>>> valuable help. I would be really interested to investigate the problem >>>>>> further. Is there anyone who can help me out with this and tell me >>> what >>>>>> pieces of information are needed to better understand the problem? >>>>> Try enabling the ACPI_BATTERY layer and ACPI_LV_ALL_EXCEPTIONS level in >>>>> /boot/loader.conf: >>>>> >>>>> debug.acpi.layer="ACPI_BATTERY" >>>>> debug.acpi.level="ACPI_LV_ALL_EXCEPTIONS" >>>>> debug.acpi.enable_debug_objects="1" # I assume this is how >>> you >>>>> turn on ACPI debugging without recompiling the kernel with 'options >>>>> ACPI_DEBUG' >>>>> >>>>> and running 'sysctl hw.acpi.battery' again. Post /var/log/messages >>> ACPI >>>>> messages about battery here. >>>>> >>>>> Anthony >>>>> >>>>>> Cheers, >>>>>> Daniele. >>>>>> _______________________________________________ >>>>>> freebsd-acpi@freebsd.org mailing list >>>>>> http://lists.freebsd.org/mailman/listinfo/freebsd-acpi >>>>>> To unsubscribe, send any mail to " >>> freebsd-acpi-unsubscribe@freebsd.org" >>>> _______________________________________________ >>>> freebsd-acpi@freebsd.org mailing list >>>> http://lists.freebsd.org/mailman/listinfo/freebsd-acpi >>>> To unsubscribe, send any mail to "freebsd-acpi-unsubscribe@freebsd.org" >>>> >>> > _______________________________________________ > freebsd-acpi@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-acpi > To unsubscribe, send any mail to "freebsd-acpi-unsubscribe@freebsd.org" > From owner-freebsd-acpi@FreeBSD.ORG Fri Jul 11 17:44: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 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3DD51AC4 for ; Fri, 11 Jul 2014 17:44:56 +0000 (UTC) Received: from mail-oa0-x22c.google.com (mail-oa0-x22c.google.com [IPv6:2607:f8b0:4003:c02::22c]) (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 00AB523D6 for ; Fri, 11 Jul 2014 17:44:55 +0000 (UTC) Received: by mail-oa0-f44.google.com with SMTP id eb12so1547233oac.3 for ; Fri, 11 Jul 2014 10:44:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Wi5CAkPAJBdyYIF8kvv20AN5iHJAFQKyxpzBl6tuBdY=; b=oTbIq2q5YNMQQcNZ33aPcWuYwXr0Upgy8Jfm8V13GCg1YVgwMWIO3OchhlTpkZkPu+ 8wIYRxX2zURiMmxCUdV/bHIiG6PdBdRI+9LrRM7m6vSpqmiy1FsJNRTZfGls7wIvWOyw mqbZqzcj9zsuQa1cwX3SkAr7CTQ9bBmg8HR68CrZEyvBbDmkFWf1YQSITnXldPkKLMm4 GpbpAqrIoDK/Sep9Y5vTGhhrR03q6d3DuFk3zQmd5Y0E/nx9+9fD7kI+o0NSURz4DQW5 IfMwrjYOypEAlSBEJrEPLEQ3fAYJ9QFKzSqN1Q+NEb5vjiUowxBQg47Qo6k3C0QLAI4s P2rw== MIME-Version: 1.0 X-Received: by 10.60.45.130 with SMTP id n2mr651943oem.12.1405100695194; Fri, 11 Jul 2014 10:44:55 -0700 (PDT) Received: by 10.182.29.9 with HTTP; Fri, 11 Jul 2014 10:44:55 -0700 (PDT) Received: by 10.182.29.9 with HTTP; Fri, 11 Jul 2014 10:44:55 -0700 (PDT) In-Reply-To: <53C020CE.8010205@att.net> References: <53BF0546.70505@att.net> <53BFCBF4.2090104@att.net> <53C020CE.8010205@att.net> Date: Fri, 11 Jul 2014 19:44:55 +0200 Message-ID: Subject: Re: ACPI support - Freebsd 10 on Sony Vaio VPCCA3C5E From: Daniele Mazzotti To: Anthony Jenkins Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18 Cc: freebsd-acpi@freebsd.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jul 2014 17:44:56 -0000 Actually I think I downloaded the source code back in May when I updated from RC3 to the current version. How can I check the code revision on my machine? Cheers, Daniele. Il 11/lug/2014 19:37 "Anthony Jenkins" ha scritto: > I just tried a build of GENERIC + 'options ACPI_DEBUG' and it seems to get > past the error you're seeing. What revision of the source code are you > using... or where'd you get it from? > > Anthony > > On 07/11/2014 13:12, Daniele Mazzotti wrote: > > Hi guys, > > > > everything as planned! I am getting a compiling error :-). > > > > This is the way i managed to update the GENERIC kernel > > > > # Bus support. > > device acpi > > options ACPI_DEBUG # Debug support for ACPI > > device pci > > > > and this is the result of > > > > # *make buildkernel KERNCONF=MYKERNEL* > > > > > > ===> crypto (depend) > > @ -> /usr/src/sys > > awk -f @/tools/makeobjops.awk @/opencrypto/cryptodev_if.m -c > > > > make[4]: stopped in /usr/src/sys/modules/crypto > > *** Error code 2 > > > > Stop. > > make[3]: stopped in /usr/src/sys/modules > > *** Error code 1 > > > > Stop. > > make[2]: stopped in /usr/obj/usr/src/sys/GENERIC > > *** Error code 1 > > > > Stop. > > make[1]: stopped in /usr/src > > *** Error code 1 > > > > Stop. > > make: stopped in /usr/src > > > > I googled a bit, but I could not find any valuable help and actually I do > > not know what could be wrong as the custom kernel is essentially the > > GENERIC with just one line added. > > Have you ever experienced such a problem? > > > > Cheers, > > Daniele. > > > > > > > > 2014-07-11 18:10 GMT+02:00 Daniele Mazzotti : > > > >> Hi guys, > >> > >> thanks again for the support. > >> > >> @Takanori: here you go http://pastebin.com/F0a2mZP4 > >> @Anthony: I will try to include the options in a custom kernel and > compile > >> it. As this is the first time after years I am compiling a custom > kernel it > >> will take a few time I guess. > >> > >> Just let me know if the output of the acpidump is of any help to you. > >> Cheers, > >> Daniele. > >> > >> > >> 2014-07-11 13:35 GMT+02:00 Anthony Jenkins : > >> > >> Hi Daniele, > >>> I was just going from acpi(4) man page; you'll likely have to build a > new > >>> kernel with 'options ACPI_DEBUG' added to your kernel config file, as I > >>> don't know if it's even possible to turn on the logging I want at > runtime. > >>> > >>> [ajenkins@ajenkins-hplaptop /usr/home/ajenkins]$ grep -i acpi > >>> /usr/src/sys/amd64/conf/MYKERNEL > >>> device acpi > >>> options ACPI_DEBUG > >>> > >>> I also have an 'options ACPI_DMAR' , but I don't recognize that and you > >>> don't need that to debug your battery. > >>> > >>> Anthony > >>> > >>> On 07/11/2014 01:58, Daniele Mazzotti wrote: > >>>> Hello Anthony, > >>>> > >>>> thanks for the quick reply! I tried what you suggested. > >>>> > >>>> loader.conf: > >>>> > >>>> # Module for Windows Partition & Linux Mount > >>>> fuse_load="YES" > >>>> autoboot_delay="5" > >>>> #acpi_sony_load="YES" > >>>> > >>>> # Debugging Symbols for ACPI > >>>> debug.acpi.layer="ACPI_BATTERY" > >>>> debug.acpi.level="ACPI_LV_ALL_EXCEPTIONS" > >>>> debug.acpi.enable_debug_objects="1" > >>>> > >>>> sysctl hw.acpi.battery: > >>>> > >>>> hw.acpi.battery.life: -1 > >>>> hw.acpi.battery.time: -1 > >>>> hw.acpi.battery.state: 7 > >>>> hw.acpi.battery.units: 1 > >>>> hw.acpi.battery.info_expire: 5 > >>>> > >>>> log/messages: > >>>> > >>>> cat /var/log/messages | grep acpi > >>>> > >>>> Jul 11 07:30:47 Von-Neumann kernel: acpi0: on motherboard > >>>> Jul 11 07:30:47 Von-Neumann kernel: acpi_ec0: GPE > >>>> 0x17, ECDT> port 0x62,0x66 on acpi0 > >>>> Jul 11 07:30:47 Von-Neumann kernel: cpu0: on acpi0 > >>>> Jul 11 07:30:47 Von-Neumann kernel: cpu1: on acpi0 > >>>> Jul 11 07:30:47 Von-Neumann kernel: cpu2: on acpi0 > >>>> Jul 11 07:30:47 Von-Neumann kernel: cpu3: on acpi0 > >>>> Jul 11 07:30:47 Von-Neumann kernel: hpet0: Timer> > >>>> iomem 0xfed00000-0xfed003ff on acpi0 > >>>> Jul 11 07:30:47 Von-Neumann kernel: atrtc0: port > >>>> 0x70-0x77 irq 8 on acpi0 > >>>> Jul 11 07:30:47 Von-Neumann kernel: attimer0: port > >>>> 0x40-0x43,0x50-0x53 irq 0 on acpi0 > >>>> Jul 11 07:30:47 Von-Neumann kernel: acpi_timer0: <24-bit timer at > >>>> 3.579545MHz> port 0x408-0x40b on acpi0 > >>>> Jul 11 07:30:47 Von-Neumann kernel: pcib0: port > >>>> 0xcf8-0xcff on acpi0 > >>>> Jul 11 07:30:47 Von-Neumann kernel: battery0: >>> Battery> > >>>> on acpi0 > >>>> Jul 11 07:30:47 Von-Neumann kernel: acpi_acad0: on acpi0 > >>>> Jul 11 07:30:47 Von-Neumann kernel: acpi_lid0: >>> Switch> > >>>> on acpi0 > >>>> Jul 11 07:30:47 Von-Neumann kernel: acpi_button0: on > >>> acpi0 > >>>> Jul 11 07:30:47 Von-Neumann kernel: acpi_tz0: on acpi0 > >>>> Jul 11 07:30:47 Von-Neumann kernel: acpi_tz1: on acpi0 > >>>> Jul 11 07:30:47 Von-Neumann kernel: atkbdc0: >>> (i8042)> > >>>> port 0x60,0x64 irq 1 on acpi0 > >>>> Jul 11 07:30:47 Von-Neumann kernel: acpi_sony0: >>> controller> > >>>> on acpi0 > >>>> Jul 11 07:30:47 Von-Neumann kernel: acpi_sony0: PID 0 > >>>> Jul 11 07:37:54 Von-Neumann kernel: acpi0: on motherboard > >>>> Jul 11 07:37:54 Von-Neumann kernel: acpi_ec0: GPE > >>>> 0x17, ECDT> port 0x62,0x66 on acpi0 > >>>> Jul 11 07:37:54 Von-Neumann kernel: cpu0: on acpi0 > >>>> Jul 11 07:37:54 Von-Neumann kernel: cpu1: on acpi0 > >>>> Jul 11 07:37:54 Von-Neumann kernel: cpu2: on acpi0 > >>>> Jul 11 07:37:54 Von-Neumann kernel: cpu3: on acpi0 > >>>> Jul 11 07:37:54 Von-Neumann kernel: hpet0: Timer> > >>>> iomem 0xfed00000-0xfed003ff on acpi0 > >>>> Jul 11 07:37:54 Von-Neumann kernel: atrtc0: port > >>>> 0x70-0x77 irq 8 on acpi0 > >>>> Jul 11 07:37:54 Von-Neumann kernel: attimer0: port > >>>> 0x40-0x43,0x50-0x53 irq 0 on acpi0 > >>>> Jul 11 07:37:54 Von-Neumann kernel: acpi_timer0: <24-bit timer at > >>>> 3.579545MHz> port 0x408-0x40b on acpi0 > >>>> Jul 11 07:37:54 Von-Neumann kernel: pcib0: port > >>>> 0xcf8-0xcff on acpi0 > >>>> Jul 11 07:37:54 Von-Neumann kernel: battery0: >>> Battery> > >>>> on acpi0 > >>>> Jul 11 07:37:54 Von-Neumann kernel: acpi_acad0: on acpi0 > >>>> Jul 11 07:37:54 Von-Neumann kernel: acpi_lid0: >>> Switch> > >>>> on acpi0 > >>>> Jul 11 07:37:54 Von-Neumann kernel: acpi_button0: on > >>> acpi0 > >>>> Jul 11 07:37:54 Von-Neumann kernel: acpi_tz0: on acpi0 > >>>> Jul 11 07:37:54 Von-Neumann kernel: acpi_tz1: on acpi0 > >>>> Jul 11 07:37:54 Von-Neumann kernel: atkbdc0: >>> (i8042)> > >>>> port 0x60,0x64 irq 1 on acpi0 > >>>> > >>>> It seems to me the verbose debugging is either not enabled (perhaps I > >>> made > >>>> some mistakes with the loader.conf) or the debug is really enabled but > >>>> there is no special output on the wrong log file. Actually I am a bit > >>>> puzzled as I am not a real expert "admin". I only enjoy getting my > >>> hands on > >>>> Unix on my desktop PC just for fun. > >>>> > >>>> However, do you think either I missed something or made anything > wrong? > >>>> I look forward to receiving from you. > >>>> > >>>> Cheers, > >>>> Daniele. > >>>> > >>>> > >>>> > >>>> 2014-07-10 23:27 GMT+02:00 Anthony Jenkins >: > >>>> > >>>>> On 07/10/2014 16:49, Daniele Mazzotti wrote: > >>>>>> Hello there, > >>>>>> > >>>>>> it is been a while since I finished installing Freebsd 10 on my Sony > >>> Vaio > >>>>>> PC and resolving (or at least I am trying to) one by one, all the > >>>>> problems > >>>>>> this hardware is giving me. Actually I cannot find a solution to > >>>>> correctly > >>>>>> display the battery level on my laptop. If I unplug my PC from the > >>> power > >>>>>> and type 'sysctl hw.acpi.battery' this is the result I get: > >>>>>> > >>>>>> hw.acpi.battery.life: -1 > >>>>>> hw.acpi.battery.time: -1 > >>>>>> hw.acpi.battery.state: 7 > >>>>>> hw.acpi.battery.units: 1 > >>>>>> hw.acpi.battery.info_expire: 5 > >>>>>> > >>>>>> Moreover the suspend mode is giving me some problems as well, but > this > >>>>> has > >>>>>> definitely a lower priority. > >>>>>> > >>>>>> I either tried to search for a solution on the FreeBSD Handook with > no > >>>>>> luck, and google the problem a little bit, but I could not find any > >>>>>> valuable help. I would be really interested to investigate the > problem > >>>>>> further. Is there anyone who can help me out with this and tell me > >>> what > >>>>>> pieces of information are needed to better understand the problem? > >>>>> Try enabling the ACPI_BATTERY layer and ACPI_LV_ALL_EXCEPTIONS level > in > >>>>> /boot/loader.conf: > >>>>> > >>>>> debug.acpi.layer="ACPI_BATTERY" > >>>>> debug.acpi.level="ACPI_LV_ALL_EXCEPTIONS" > >>>>> debug.acpi.enable_debug_objects="1" # I assume this is how > >>> you > >>>>> turn on ACPI debugging without recompiling the kernel with 'options > >>>>> ACPI_DEBUG' > >>>>> > >>>>> and running 'sysctl hw.acpi.battery' again. Post /var/log/messages > >>> ACPI > >>>>> messages about battery here. > >>>>> > >>>>> Anthony > >>>>> > >>>>>> Cheers, > >>>>>> Daniele. > >>>>>> _______________________________________________ > >>>>>> freebsd-acpi@freebsd.org mailing list > >>>>>> http://lists.freebsd.org/mailman/listinfo/freebsd-acpi > >>>>>> To unsubscribe, send any mail to " > >>> freebsd-acpi-unsubscribe@freebsd.org" > >>>> _______________________________________________ > >>>> freebsd-acpi@freebsd.org mailing list > >>>> http://lists.freebsd.org/mailman/listinfo/freebsd-acpi > >>>> To unsubscribe, send any mail to " > freebsd-acpi-unsubscribe@freebsd.org" > >>>> > >>> > > _______________________________________________ > > freebsd-acpi@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-acpi > > To unsubscribe, send any mail to "freebsd-acpi-unsubscribe@freebsd.org" > > > > From owner-freebsd-acpi@FreeBSD.ORG Fri Jul 11 17:59:33 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 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 53111107 for ; Fri, 11 Jul 2014 17:59:33 +0000 (UTC) Received: from nm4-vm2.access.bullet.mail.gq1.yahoo.com (nm4-vm2.access.bullet.mail.gq1.yahoo.com [216.39.63.32]) (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 1935F2500 for ; Fri, 11 Jul 2014 17:59:32 +0000 (UTC) Received: from [216.39.60.168] by nm4.access.bullet.mail.gq1.yahoo.com with NNFMP; 11 Jul 2014 17:59:32 -0000 Received: from [67.195.23.148] by tm4.access.bullet.mail.gq1.yahoo.com with NNFMP; 11 Jul 2014 17:59:32 -0000 Received: from [127.0.0.1] by smtp120.sbc.mail.gq1.yahoo.com with NNFMP; 11 Jul 2014 17:59:32 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1405101572; bh=DDurLmPgt9YFKEixYLHO7vV/WuKEvXgBXxKz8lD78zs=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=J8UfubwRfMRHQE6LmcgFUm7pfoYst6MKoegBSZ9icCjxlMNOfJkBfovG33cE5+OZ5lBmSs4Q1B1dQrTnn3mwz0FA38UwHAP5H6wZQ5BZjFjm7IAHaCKvTfS8Kuv6YWYqTUJ+c5QSUfbtjcWici7L912VbuxzMEGTx5e8zcHXQEI= X-Yahoo-Newman-Id: 144748.20992.bm@smtp120.sbc.mail.gq1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: p5.1jyQVM1lwBJAU5QwGIrgZKkrISFLtdanQQldyh8ZN3tv rtyxU0r.hs4vEYZE_m_WXtpNSaFZzTheEDhwwN_9wFOjO91Ud_wWwswvHUe1 TINNrd4IrwaxPZrCNyfMizzu5mqv26GY94Umh5mV.TmYGSvv_0HkLPHKeoaO Ikud9A5pYli8W8.x2eNzdGbLI0ronrEOWKZdQct6SoNItpm9zMY2wvEpcrES cxloG1jmoTMk_Rv5PlsCq9_cj73KqgtRSN3NoQ.eIKuXUwTYAm_Hgx8bvXaS fMlUqpLwOhEbAonjlBIrPR4FkGSvU1RZ0x6JceLe.C3P1vG24MY8Pmnski_m VLTOGIWxwcZ0jVXTsM18uYpfSkKTr3qKrCkXjCXEQ6xdZ1fqnz5yyu.yA7Ii MPnXo5O9XyRpy0DmJuCxmo4t0fQNZUvqHqMa5jyIJN8hQnUwQFH1xMDV8kvu hblGOw1.mNWOGMrlEtuuMXJMx3_Lv.ROmiURn_f9N2ARc.UOQQtCh.UJ.XBB 4WjVMfsu0sDY_fkn0sGlEhUYZ8L0x_sfBUfwEA8d3oU30Vh_Y0D45l2cSTHH bjlnIhlL5ET8ZHDvI_MgxD_TnHTId5ZoSB6q.nPzwIzcsiSPQsHd08hWV7g- - X-Yahoo-SMTP: OKD1keCswBBTAmAF1s00hLyKW3wE3YfSK0Eazl6b4VZG4LTqJxg- X-Rocket-Received: from [64.100.76.103] (Anthony.B.Jenkins@64.100.76.103 with plain [67.195.15.5]) by smtp120.sbc.mail.gq1.yahoo.com with SMTP; 11 Jul 2014 17:59:32 +0000 UTC Message-ID: <53C02604.9070207@att.net> Date: Fri, 11 Jul 2014 13:59:32 -0400 From: Anthony Jenkins User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Daniele Mazzotti Subject: Re: ACPI support - Freebsd 10 on Sony Vaio VPCCA3C5E References: <53BF0546.70505@att.net> <53BFCBF4.2090104@att.net> <53C020CE.8010205@att.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@freebsd.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jul 2014 17:59:33 -0000 Errrr... good question :-) I got mine from Subversion, so in '/usr/src' I can run 'svn info' and see the revision. Your revision might be at the top of /usr/src/Makefile - it is in mine: # # $FreeBSD: head/Makefile 268191 2014-07-02 22:34:06Z marcel $ # I'm only wondering because it might be a bad copy. Might try getting the sources again. Thanks, Anthony On 07/11/2014 13:44, Daniele Mazzotti wrote: > Actually I think I downloaded the source code back in May when I updated > from RC3 to the current version. > > How can I check the code revision on my machine? > > Cheers, > Daniele. > Il 11/lug/2014 19:37 "Anthony Jenkins" ha > scritto: > >> I just tried a build of GENERIC + 'options ACPI_DEBUG' and it seems to get >> past the error you're seeing. What revision of the source code are you >> using... or where'd you get it from? >> >> Anthony >> >> On 07/11/2014 13:12, Daniele Mazzotti wrote: >>> Hi guys, >>> >>> everything as planned! I am getting a compiling error :-). >>> >>> This is the way i managed to update the GENERIC kernel >>> >>> # Bus support. >>> device acpi >>> options ACPI_DEBUG # Debug support for ACPI >>> device pci >>> >>> and this is the result of >>> >>> # *make buildkernel KERNCONF=MYKERNEL* >>> >>> >>> ===> crypto (depend) >>> @ -> /usr/src/sys >>> awk -f @/tools/makeobjops.awk @/opencrypto/cryptodev_if.m -c >>> >>> make[4]: stopped in /usr/src/sys/modules/crypto >>> *** Error code 2 >>> >>> Stop. >>> make[3]: stopped in /usr/src/sys/modules >>> *** Error code 1 >>> >>> Stop. >>> make[2]: stopped in /usr/obj/usr/src/sys/GENERIC >>> *** Error code 1 >>> >>> Stop. >>> make[1]: stopped in /usr/src >>> *** Error code 1 >>> >>> Stop. >>> make: stopped in /usr/src >>> >>> I googled a bit, but I could not find any valuable help and actually I do >>> not know what could be wrong as the custom kernel is essentially the >>> GENERIC with just one line added. >>> Have you ever experienced such a problem? >>> >>> Cheers, >>> Daniele. >>> >>> >>> >>> 2014-07-11 18:10 GMT+02:00 Daniele Mazzotti : >>> >>>> Hi guys, >>>> >>>> thanks again for the support. >>>> >>>> @Takanori: here you go http://pastebin.com/F0a2mZP4 >>>> @Anthony: I will try to include the options in a custom kernel and >> compile >>>> it. As this is the first time after years I am compiling a custom >> kernel it >>>> will take a few time I guess. >>>> >>>> Just let me know if the output of the acpidump is of any help to you. >>>> Cheers, >>>> Daniele. >>>> >>>> >>>> 2014-07-11 13:35 GMT+02:00 Anthony Jenkins : >>>> >>>> Hi Daniele, >>>>> I was just going from acpi(4) man page; you'll likely have to build a >> new >>>>> kernel with 'options ACPI_DEBUG' added to your kernel config file, as I >>>>> don't know if it's even possible to turn on the logging I want at >> runtime. >>>>> [ajenkins@ajenkins-hplaptop /usr/home/ajenkins]$ grep -i acpi >>>>> /usr/src/sys/amd64/conf/MYKERNEL >>>>> device acpi >>>>> options ACPI_DEBUG >>>>> >>>>> I also have an 'options ACPI_DMAR' , but I don't recognize that and you >>>>> don't need that to debug your battery. >>>>> >>>>> Anthony >>>>> >>>>> On 07/11/2014 01:58, Daniele Mazzotti wrote: >>>>>> Hello Anthony, >>>>>> >>>>>> thanks for the quick reply! I tried what you suggested. >>>>>> >>>>>> loader.conf: >>>>>> >>>>>> # Module for Windows Partition & Linux Mount >>>>>> fuse_load="YES" >>>>>> autoboot_delay="5" >>>>>> #acpi_sony_load="YES" >>>>>> >>>>>> # Debugging Symbols for ACPI >>>>>> debug.acpi.layer="ACPI_BATTERY" >>>>>> debug.acpi.level="ACPI_LV_ALL_EXCEPTIONS" >>>>>> debug.acpi.enable_debug_objects="1" >>>>>> >>>>>> sysctl hw.acpi.battery: >>>>>> >>>>>> hw.acpi.battery.life: -1 >>>>>> hw.acpi.battery.time: -1 >>>>>> hw.acpi.battery.state: 7 >>>>>> hw.acpi.battery.units: 1 >>>>>> hw.acpi.battery.info_expire: 5 >>>>>> >>>>>> log/messages: >>>>>> >>>>>> cat /var/log/messages | grep acpi >>>>>> >>>>>> Jul 11 07:30:47 Von-Neumann kernel: acpi0: on motherboard >>>>>> Jul 11 07:30:47 Von-Neumann kernel: acpi_ec0: > GPE >>>>>> 0x17, ECDT> port 0x62,0x66 on acpi0 >>>>>> Jul 11 07:30:47 Von-Neumann kernel: cpu0: on acpi0 >>>>>> Jul 11 07:30:47 Von-Neumann kernel: cpu1: on acpi0 >>>>>> Jul 11 07:30:47 Von-Neumann kernel: cpu2: on acpi0 >>>>>> Jul 11 07:30:47 Von-Neumann kernel: cpu3: on acpi0 >>>>>> Jul 11 07:30:47 Von-Neumann kernel: hpet0: > Timer> >>>>>> iomem 0xfed00000-0xfed003ff on acpi0 >>>>>> Jul 11 07:30:47 Von-Neumann kernel: atrtc0: port >>>>>> 0x70-0x77 irq 8 on acpi0 >>>>>> Jul 11 07:30:47 Von-Neumann kernel: attimer0: port >>>>>> 0x40-0x43,0x50-0x53 irq 0 on acpi0 >>>>>> Jul 11 07:30:47 Von-Neumann kernel: acpi_timer0: <24-bit timer at >>>>>> 3.579545MHz> port 0x408-0x40b on acpi0 >>>>>> Jul 11 07:30:47 Von-Neumann kernel: pcib0: port >>>>>> 0xcf8-0xcff on acpi0 >>>>>> Jul 11 07:30:47 Von-Neumann kernel: battery0: >>>> Battery> >>>>>> on acpi0 >>>>>> Jul 11 07:30:47 Von-Neumann kernel: acpi_acad0: on acpi0 >>>>>> Jul 11 07:30:47 Von-Neumann kernel: acpi_lid0: >>>> Switch> >>>>>> on acpi0 >>>>>> Jul 11 07:30:47 Von-Neumann kernel: acpi_button0: on >>>>> acpi0 >>>>>> Jul 11 07:30:47 Von-Neumann kernel: acpi_tz0: on acpi0 >>>>>> Jul 11 07:30:47 Von-Neumann kernel: acpi_tz1: on acpi0 >>>>>> Jul 11 07:30:47 Von-Neumann kernel: atkbdc0: >>>> (i8042)> >>>>>> port 0x60,0x64 irq 1 on acpi0 >>>>>> Jul 11 07:30:47 Von-Neumann kernel: acpi_sony0: >>>> controller> >>>>>> on acpi0 >>>>>> Jul 11 07:30:47 Von-Neumann kernel: acpi_sony0: PID 0 >>>>>> Jul 11 07:37:54 Von-Neumann kernel: acpi0: on motherboard >>>>>> Jul 11 07:37:54 Von-Neumann kernel: acpi_ec0: > GPE >>>>>> 0x17, ECDT> port 0x62,0x66 on acpi0 >>>>>> Jul 11 07:37:54 Von-Neumann kernel: cpu0: on acpi0 >>>>>> Jul 11 07:37:54 Von-Neumann kernel: cpu1: on acpi0 >>>>>> Jul 11 07:37:54 Von-Neumann kernel: cpu2: on acpi0 >>>>>> Jul 11 07:37:54 Von-Neumann kernel: cpu3: on acpi0 >>>>>> Jul 11 07:37:54 Von-Neumann kernel: hpet0: > Timer> >>>>>> iomem 0xfed00000-0xfed003ff on acpi0 >>>>>> Jul 11 07:37:54 Von-Neumann kernel: atrtc0: port >>>>>> 0x70-0x77 irq 8 on acpi0 >>>>>> Jul 11 07:37:54 Von-Neumann kernel: attimer0: port >>>>>> 0x40-0x43,0x50-0x53 irq 0 on acpi0 >>>>>> Jul 11 07:37:54 Von-Neumann kernel: acpi_timer0: <24-bit timer at >>>>>> 3.579545MHz> port 0x408-0x40b on acpi0 >>>>>> Jul 11 07:37:54 Von-Neumann kernel: pcib0: port >>>>>> 0xcf8-0xcff on acpi0 >>>>>> Jul 11 07:37:54 Von-Neumann kernel: battery0: >>>> Battery> >>>>>> on acpi0 >>>>>> Jul 11 07:37:54 Von-Neumann kernel: acpi_acad0: on acpi0 >>>>>> Jul 11 07:37:54 Von-Neumann kernel: acpi_lid0: >>>> Switch> >>>>>> on acpi0 >>>>>> Jul 11 07:37:54 Von-Neumann kernel: acpi_button0: on >>>>> acpi0 >>>>>> Jul 11 07:37:54 Von-Neumann kernel: acpi_tz0: on acpi0 >>>>>> Jul 11 07:37:54 Von-Neumann kernel: acpi_tz1: on acpi0 >>>>>> Jul 11 07:37:54 Von-Neumann kernel: atkbdc0: >>>> (i8042)> >>>>>> port 0x60,0x64 irq 1 on acpi0 >>>>>> >>>>>> It seems to me the verbose debugging is either not enabled (perhaps I >>>>> made >>>>>> some mistakes with the loader.conf) or the debug is really enabled but >>>>>> there is no special output on the wrong log file. Actually I am a bit >>>>>> puzzled as I am not a real expert "admin". I only enjoy getting my >>>>> hands on >>>>>> Unix on my desktop PC just for fun. >>>>>> >>>>>> However, do you think either I missed something or made anything >> wrong? >>>>>> I look forward to receiving from you. >>>>>> >>>>>> Cheers, >>>>>> Daniele. >>>>>> >>>>>> >>>>>> >>>>>> 2014-07-10 23:27 GMT+02:00 Anthony Jenkins >> : >>>>>>> On 07/10/2014 16:49, Daniele Mazzotti wrote: >>>>>>>> Hello there, >>>>>>>> >>>>>>>> it is been a while since I finished installing Freebsd 10 on my Sony >>>>> Vaio >>>>>>>> PC and resolving (or at least I am trying to) one by one, all the >>>>>>> problems >>>>>>>> this hardware is giving me. Actually I cannot find a solution to >>>>>>> correctly >>>>>>>> display the battery level on my laptop. If I unplug my PC from the >>>>> power >>>>>>>> and type 'sysctl hw.acpi.battery' this is the result I get: >>>>>>>> >>>>>>>> hw.acpi.battery.life: -1 >>>>>>>> hw.acpi.battery.time: -1 >>>>>>>> hw.acpi.battery.state: 7 >>>>>>>> hw.acpi.battery.units: 1 >>>>>>>> hw.acpi.battery.info_expire: 5 >>>>>>>> >>>>>>>> Moreover the suspend mode is giving me some problems as well, but >> this >>>>>>> has >>>>>>>> definitely a lower priority. >>>>>>>> >>>>>>>> I either tried to search for a solution on the FreeBSD Handook with >> no >>>>>>>> luck, and google the problem a little bit, but I could not find any >>>>>>>> valuable help. I would be really interested to investigate the >> problem >>>>>>>> further. Is there anyone who can help me out with this and tell me >>>>> what >>>>>>>> pieces of information are needed to better understand the problem? >>>>>>> Try enabling the ACPI_BATTERY layer and ACPI_LV_ALL_EXCEPTIONS level >> in >>>>>>> /boot/loader.conf: >>>>>>> >>>>>>> debug.acpi.layer="ACPI_BATTERY" >>>>>>> debug.acpi.level="ACPI_LV_ALL_EXCEPTIONS" >>>>>>> debug.acpi.enable_debug_objects="1" # I assume this is how >>>>> you >>>>>>> turn on ACPI debugging without recompiling the kernel with 'options >>>>>>> ACPI_DEBUG' >>>>>>> >>>>>>> and running 'sysctl hw.acpi.battery' again. Post /var/log/messages >>>>> ACPI >>>>>>> messages about battery here. >>>>>>> >>>>>>> Anthony >>>>>>> >>>>>>>> Cheers, >>>>>>>> Daniele. >>>>>>>> _______________________________________________ >>>>>>>> freebsd-acpi@freebsd.org mailing list >>>>>>>> http://lists.freebsd.org/mailman/listinfo/freebsd-acpi >>>>>>>> To unsubscribe, send any mail to " >>>>> freebsd-acpi-unsubscribe@freebsd.org" >>>>>> _______________________________________________ >>>>>> freebsd-acpi@freebsd.org mailing list >>>>>> http://lists.freebsd.org/mailman/listinfo/freebsd-acpi >>>>>> To unsubscribe, send any mail to " >> freebsd-acpi-unsubscribe@freebsd.org" >>> _______________________________________________ >>> freebsd-acpi@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-acpi >>> To unsubscribe, send any mail to "freebsd-acpi-unsubscribe@freebsd.org" >>> >> > _______________________________________________ > freebsd-acpi@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-acpi > To unsubscribe, send any mail to "freebsd-acpi-unsubscribe@freebsd.org" > From owner-freebsd-acpi@FreeBSD.ORG Fri Jul 11 18:03:19 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 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0572629C for ; Fri, 11 Jul 2014 18:03:19 +0000 (UTC) Received: from mail-ob0-x22c.google.com (mail-ob0-x22c.google.com [IPv6:2607:f8b0:4003:c01::22c]) (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 BB60425B5 for ; Fri, 11 Jul 2014 18:03:18 +0000 (UTC) Received: by mail-ob0-f172.google.com with SMTP id wn1so1560815obc.31 for ; Fri, 11 Jul 2014 11:03:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=4/xLYNqFvO4RSKvN3nbJv8EkAn3EkKq3w3gThWm/fk4=; b=HqEgtiJrAPkmbg+C5Af39ULXRhgbrd8CWl6rUBGqvahiUOvnVrtlmRM1DgsqmiU5Iz fCEwVtGWMPdwTI5YwKN4s2EscZdjDnZj5c8u/9osMhrTTy4QNc6qcF/Mr4dAWISQqY6X HX3Ap/KAjZCqEWc+yt0sqSV4yie5F4gZ3uuabjwtr5K2ZNsnu89w1fkZlIZ5gUFFH+0P Ahaf3GF9UitHU8teufXyJgAuRIR2za6cqv12kMM8In7SpBpqxmB/Z5dC3f8Knfdu1Sz5 JE9wbaVn0vHW3u8PebXm0DicPMT+M83VJNCFd5+vCVZwcX8spPGWw+mETZHXf/QxlBr2 w5Dg== MIME-Version: 1.0 X-Received: by 10.60.16.2 with SMTP id b2mr429192oed.57.1405101796511; Fri, 11 Jul 2014 11:03:16 -0700 (PDT) Received: by 10.182.29.9 with HTTP; Fri, 11 Jul 2014 11:03:16 -0700 (PDT) Received: by 10.182.29.9 with HTTP; Fri, 11 Jul 2014 11:03:16 -0700 (PDT) In-Reply-To: <53C02604.9070207@att.net> References: <53BF0546.70505@att.net> <53BFCBF4.2090104@att.net> <53C020CE.8010205@att.net> <53C02604.9070207@att.net> Date: Fri, 11 Jul 2014 20:03:16 +0200 Message-ID: Subject: Re: ACPI support - Freebsd 10 on Sony Vaio VPCCA3C5E From: Daniele Mazzotti To: Anthony Jenkins Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18 Cc: freebsd-acpi@freebsd.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jul 2014 18:03:19 -0000 Hi Anthony, Thanks for the good hint. I will be searching for the revision info as soon as I will be back home (3 hours from now more or less). Cheers, Daniele. Il 11/lug/2014 19:59 "Anthony Jenkins" ha scritto: > Errrr... good question :-) I got mine from Subversion, so in '/usr/src' I > can run 'svn info' and see the revision. > > Your revision might be at the top of /usr/src/Makefile - it is in mine: > > # > # $FreeBSD: head/Makefile 268191 2014-07-02 22:34:06Z marcel $ > # > > I'm only wondering because it might be a bad copy. Might try getting the > sources again. > > Thanks, > Anthony > > On 07/11/2014 13:44, Daniele Mazzotti wrote: > > Actually I think I downloaded the source code back in May when I updated > > from RC3 to the current version. > > > > How can I check the code revision on my machine? > > > > Cheers, > > Daniele. > > Il 11/lug/2014 19:37 "Anthony Jenkins" ha > > scritto: > > > >> I just tried a build of GENERIC + 'options ACPI_DEBUG' and it seems to > get > >> past the error you're seeing. What revision of the source code are you > >> using... or where'd you get it from? > >> > >> Anthony > >> > >> On 07/11/2014 13:12, Daniele Mazzotti wrote: > >>> Hi guys, > >>> > >>> everything as planned! I am getting a compiling error :-). > >>> > >>> This is the way i managed to update the GENERIC kernel > >>> > >>> # Bus support. > >>> device acpi > >>> options ACPI_DEBUG # Debug support for ACPI > >>> device pci > >>> > >>> and this is the result of > >>> > >>> # *make buildkernel KERNCONF=MYKERNEL* > >>> > >>> > >>> ===> crypto (depend) > >>> @ -> /usr/src/sys > >>> awk -f @/tools/makeobjops.awk @/opencrypto/cryptodev_if.m -c > >>> > >>> make[4]: stopped in /usr/src/sys/modules/crypto > >>> *** Error code 2 > >>> > >>> Stop. > >>> make[3]: stopped in /usr/src/sys/modules > >>> *** Error code 1 > >>> > >>> Stop. > >>> make[2]: stopped in /usr/obj/usr/src/sys/GENERIC > >>> *** Error code 1 > >>> > >>> Stop. > >>> make[1]: stopped in /usr/src > >>> *** Error code 1 > >>> > >>> Stop. > >>> make: stopped in /usr/src > >>> > >>> I googled a bit, but I could not find any valuable help and actually I > do > >>> not know what could be wrong as the custom kernel is essentially the > >>> GENERIC with just one line added. > >>> Have you ever experienced such a problem? > >>> > >>> Cheers, > >>> Daniele. > >>> > >>> > >>> > >>> 2014-07-11 18:10 GMT+02:00 Daniele Mazzotti : > >>> > >>>> Hi guys, > >>>> > >>>> thanks again for the support. > >>>> > >>>> @Takanori: here you go http://pastebin.com/F0a2mZP4 > >>>> @Anthony: I will try to include the options in a custom kernel and > >> compile > >>>> it. As this is the first time after years I am compiling a custom > >> kernel it > >>>> will take a few time I guess. > >>>> > >>>> Just let me know if the output of the acpidump is of any help to you. > >>>> Cheers, > >>>> Daniele. > >>>> > >>>> > >>>> 2014-07-11 13:35 GMT+02:00 Anthony Jenkins >: > >>>> > >>>> Hi Daniele, > >>>>> I was just going from acpi(4) man page; you'll likely have to build a > >> new > >>>>> kernel with 'options ACPI_DEBUG' added to your kernel config file, > as I > >>>>> don't know if it's even possible to turn on the logging I want at > >> runtime. > >>>>> [ajenkins@ajenkins-hplaptop /usr/home/ajenkins]$ grep -i acpi > >>>>> /usr/src/sys/amd64/conf/MYKERNEL > >>>>> device acpi > >>>>> options ACPI_DEBUG > >>>>> > >>>>> I also have an 'options ACPI_DMAR' , but I don't recognize that and > you > >>>>> don't need that to debug your battery. > >>>>> > >>>>> Anthony > >>>>> > >>>>> On 07/11/2014 01:58, Daniele Mazzotti wrote: > >>>>>> Hello Anthony, > >>>>>> > >>>>>> thanks for the quick reply! I tried what you suggested. > >>>>>> > >>>>>> loader.conf: > >>>>>> > >>>>>> # Module for Windows Partition & Linux Mount > >>>>>> fuse_load="YES" > >>>>>> autoboot_delay="5" > >>>>>> #acpi_sony_load="YES" > >>>>>> > >>>>>> # Debugging Symbols for ACPI > >>>>>> debug.acpi.layer="ACPI_BATTERY" > >>>>>> debug.acpi.level="ACPI_LV_ALL_EXCEPTIONS" > >>>>>> debug.acpi.enable_debug_objects="1" > >>>>>> > >>>>>> sysctl hw.acpi.battery: > >>>>>> > >>>>>> hw.acpi.battery.life: -1 > >>>>>> hw.acpi.battery.time: -1 > >>>>>> hw.acpi.battery.state: 7 > >>>>>> hw.acpi.battery.units: 1 > >>>>>> hw.acpi.battery.info_expire: 5 > >>>>>> > >>>>>> log/messages: > >>>>>> > >>>>>> cat /var/log/messages | grep acpi > >>>>>> > >>>>>> Jul 11 07:30:47 Von-Neumann kernel: acpi0: on motherboard > >>>>>> Jul 11 07:30:47 Von-Neumann kernel: acpi_ec0: >> GPE > >>>>>> 0x17, ECDT> port 0x62,0x66 on acpi0 > >>>>>> Jul 11 07:30:47 Von-Neumann kernel: cpu0: on acpi0 > >>>>>> Jul 11 07:30:47 Von-Neumann kernel: cpu1: on acpi0 > >>>>>> Jul 11 07:30:47 Von-Neumann kernel: cpu2: on acpi0 > >>>>>> Jul 11 07:30:47 Von-Neumann kernel: cpu3: on acpi0 > >>>>>> Jul 11 07:30:47 Von-Neumann kernel: hpet0: >> Timer> > >>>>>> iomem 0xfed00000-0xfed003ff on acpi0 > >>>>>> Jul 11 07:30:47 Von-Neumann kernel: atrtc0: port > >>>>>> 0x70-0x77 irq 8 on acpi0 > >>>>>> Jul 11 07:30:47 Von-Neumann kernel: attimer0: port > >>>>>> 0x40-0x43,0x50-0x53 irq 0 on acpi0 > >>>>>> Jul 11 07:30:47 Von-Neumann kernel: acpi_timer0: <24-bit timer at > >>>>>> 3.579545MHz> port 0x408-0x40b on acpi0 > >>>>>> Jul 11 07:30:47 Von-Neumann kernel: pcib0: > port > >>>>>> 0xcf8-0xcff on acpi0 > >>>>>> Jul 11 07:30:47 Von-Neumann kernel: battery0: >>>>> Battery> > >>>>>> on acpi0 > >>>>>> Jul 11 07:30:47 Von-Neumann kernel: acpi_acad0: on > acpi0 > >>>>>> Jul 11 07:30:47 Von-Neumann kernel: acpi_lid0: >>>>> Switch> > >>>>>> on acpi0 > >>>>>> Jul 11 07:30:47 Von-Neumann kernel: acpi_button0: on > >>>>> acpi0 > >>>>>> Jul 11 07:30:47 Von-Neumann kernel: acpi_tz0: on > acpi0 > >>>>>> Jul 11 07:30:47 Von-Neumann kernel: acpi_tz1: on > acpi0 > >>>>>> Jul 11 07:30:47 Von-Neumann kernel: atkbdc0: >>>>> (i8042)> > >>>>>> port 0x60,0x64 irq 1 on acpi0 > >>>>>> Jul 11 07:30:47 Von-Neumann kernel: acpi_sony0: >>>>> controller> > >>>>>> on acpi0 > >>>>>> Jul 11 07:30:47 Von-Neumann kernel: acpi_sony0: PID 0 > >>>>>> Jul 11 07:37:54 Von-Neumann kernel: acpi0: on motherboard > >>>>>> Jul 11 07:37:54 Von-Neumann kernel: acpi_ec0: >> GPE > >>>>>> 0x17, ECDT> port 0x62,0x66 on acpi0 > >>>>>> Jul 11 07:37:54 Von-Neumann kernel: cpu0: on acpi0 > >>>>>> Jul 11 07:37:54 Von-Neumann kernel: cpu1: on acpi0 > >>>>>> Jul 11 07:37:54 Von-Neumann kernel: cpu2: on acpi0 > >>>>>> Jul 11 07:37:54 Von-Neumann kernel: cpu3: on acpi0 > >>>>>> Jul 11 07:37:54 Von-Neumann kernel: hpet0: >> Timer> > >>>>>> iomem 0xfed00000-0xfed003ff on acpi0 > >>>>>> Jul 11 07:37:54 Von-Neumann kernel: atrtc0: port > >>>>>> 0x70-0x77 irq 8 on acpi0 > >>>>>> Jul 11 07:37:54 Von-Neumann kernel: attimer0: port > >>>>>> 0x40-0x43,0x50-0x53 irq 0 on acpi0 > >>>>>> Jul 11 07:37:54 Von-Neumann kernel: acpi_timer0: <24-bit timer at > >>>>>> 3.579545MHz> port 0x408-0x40b on acpi0 > >>>>>> Jul 11 07:37:54 Von-Neumann kernel: pcib0: > port > >>>>>> 0xcf8-0xcff on acpi0 > >>>>>> Jul 11 07:37:54 Von-Neumann kernel: battery0: >>>>> Battery> > >>>>>> on acpi0 > >>>>>> Jul 11 07:37:54 Von-Neumann kernel: acpi_acad0: on > acpi0 > >>>>>> Jul 11 07:37:54 Von-Neumann kernel: acpi_lid0: >>>>> Switch> > >>>>>> on acpi0 > >>>>>> Jul 11 07:37:54 Von-Neumann kernel: acpi_button0: on > >>>>> acpi0 > >>>>>> Jul 11 07:37:54 Von-Neumann kernel: acpi_tz0: on > acpi0 > >>>>>> Jul 11 07:37:54 Von-Neumann kernel: acpi_tz1: on > acpi0 > >>>>>> Jul 11 07:37:54 Von-Neumann kernel: atkbdc0: >>>>> (i8042)> > >>>>>> port 0x60,0x64 irq 1 on acpi0 > >>>>>> > >>>>>> It seems to me the verbose debugging is either not enabled (perhaps > I > >>>>> made > >>>>>> some mistakes with the loader.conf) or the debug is really enabled > but > >>>>>> there is no special output on the wrong log file. Actually I am a > bit > >>>>>> puzzled as I am not a real expert "admin". I only enjoy getting my > >>>>> hands on > >>>>>> Unix on my desktop PC just for fun. > >>>>>> > >>>>>> However, do you think either I missed something or made anything > >> wrong? > >>>>>> I look forward to receiving from you. > >>>>>> > >>>>>> Cheers, > >>>>>> Daniele. > >>>>>> > >>>>>> > >>>>>> > >>>>>> 2014-07-10 23:27 GMT+02:00 Anthony Jenkins < > Anthony.B.Jenkins@att.net > >>> : > >>>>>>> On 07/10/2014 16:49, Daniele Mazzotti wrote: > >>>>>>>> Hello there, > >>>>>>>> > >>>>>>>> it is been a while since I finished installing Freebsd 10 on my > Sony > >>>>> Vaio > >>>>>>>> PC and resolving (or at least I am trying to) one by one, all the > >>>>>>> problems > >>>>>>>> this hardware is giving me. Actually I cannot find a solution to > >>>>>>> correctly > >>>>>>>> display the battery level on my laptop. If I unplug my PC from the > >>>>> power > >>>>>>>> and type 'sysctl hw.acpi.battery' this is the result I get: > >>>>>>>> > >>>>>>>> hw.acpi.battery.life: -1 > >>>>>>>> hw.acpi.battery.time: -1 > >>>>>>>> hw.acpi.battery.state: 7 > >>>>>>>> hw.acpi.battery.units: 1 > >>>>>>>> hw.acpi.battery.info_expire: 5 > >>>>>>>> > >>>>>>>> Moreover the suspend mode is giving me some problems as well, but > >> this > >>>>>>> has > >>>>>>>> definitely a lower priority. > >>>>>>>> > >>>>>>>> I either tried to search for a solution on the FreeBSD Handook > with > >> no > >>>>>>>> luck, and google the problem a little bit, but I could not find > any > >>>>>>>> valuable help. I would be really interested to investigate the > >> problem > >>>>>>>> further. Is there anyone who can help me out with this and tell me > >>>>> what > >>>>>>>> pieces of information are needed to better understand the problem? > >>>>>>> Try enabling the ACPI_BATTERY layer and ACPI_LV_ALL_EXCEPTIONS > level > >> in > >>>>>>> /boot/loader.conf: > >>>>>>> > >>>>>>> debug.acpi.layer="ACPI_BATTERY" > >>>>>>> debug.acpi.level="ACPI_LV_ALL_EXCEPTIONS" > >>>>>>> debug.acpi.enable_debug_objects="1" # I assume this is > how > >>>>> you > >>>>>>> turn on ACPI debugging without recompiling the kernel with 'options > >>>>>>> ACPI_DEBUG' > >>>>>>> > >>>>>>> and running 'sysctl hw.acpi.battery' again. Post /var/log/messages > >>>>> ACPI > >>>>>>> messages about battery here. > >>>>>>> > >>>>>>> Anthony > >>>>>>> > >>>>>>>> Cheers, > >>>>>>>> Daniele. > >>>>>>>> _______________________________________________ > >>>>>>>> freebsd-acpi@freebsd.org mailing list > >>>>>>>> http://lists.freebsd.org/mailman/listinfo/freebsd-acpi > >>>>>>>> To unsubscribe, send any mail to " > >>>>> freebsd-acpi-unsubscribe@freebsd.org" > >>>>>> _______________________________________________ > >>>>>> freebsd-acpi@freebsd.org mailing list > >>>>>> http://lists.freebsd.org/mailman/listinfo/freebsd-acpi > >>>>>> To unsubscribe, send any mail to " > >> freebsd-acpi-unsubscribe@freebsd.org" > >>> _______________________________________________ > >>> freebsd-acpi@freebsd.org mailing list > >>> http://lists.freebsd.org/mailman/listinfo/freebsd-acpi > >>> To unsubscribe, send any mail to "freebsd-acpi-unsubscribe@freebsd.org > " > >>> > >> > > _______________________________________________ > > freebsd-acpi@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-acpi > > To unsubscribe, send any mail to "freebsd-acpi-unsubscribe@freebsd.org" > > > > From owner-freebsd-acpi@FreeBSD.ORG Fri Jul 11 21:26:28 2014 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 508CBEBA for ; Fri, 11 Jul 2014 21:26:28 +0000 (UTC) Received: from mail-ob0-x22f.google.com (mail-ob0-x22f.google.com [IPv6:2607:f8b0:4003:c01::22f]) (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 13999289C for ; Fri, 11 Jul 2014 21:26:28 +0000 (UTC) Received: by mail-ob0-f175.google.com with SMTP id wp18so1852482obc.34 for ; Fri, 11 Jul 2014 14:26:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=kNdczDCxCwlWQLemxgERxb/FrqmyATHNjGGlmcwvQPE=; b=gPdPTgb+4GK8URi2e31Rf7pDO2VWG/Byyvs1XpsUueVxjBrKOeBJfcLhqG6K2nQW75 AKBF4zADHbbPb4Dr+D6WHuN0Jn8Yqj3UPMbb2I/PW+HdBCFCRqNWF8NjGehKCAst08Hh oziln8OF+cBkMYbsGYYXVu04Qeka1DOX9AzBlfB9WXviajcqtddIJikpQcUrCvIm+6Bu R3Q5cZncn19sA7RFBX1bGQZp0ZjL4OquyOuQDgw4ncc4z9bUVaoESM2lRKD2T0d9aPDy p99zDSA9vvRTiHmcNgBrkdWQbyu38a5F99ytqWmeP9iwT4WxKETGiNZRJnfOrdrYrXb+ PewQ== MIME-Version: 1.0 X-Received: by 10.60.52.226 with SMTP id w2mr2000883oeo.3.1405113987326; Fri, 11 Jul 2014 14:26:27 -0700 (PDT) Received: by 10.182.29.9 with HTTP; Fri, 11 Jul 2014 14:26:27 -0700 (PDT) In-Reply-To: References: <53BF0546.70505@att.net> <53BFCBF4.2090104@att.net> <53C020CE.8010205@att.net> <53C02604.9070207@att.net> Date: Fri, 11 Jul 2014 23:26:27 +0200 Message-ID: Subject: Re: ACPI support - Freebsd 10 on Sony Vaio VPCCA3C5E From: Daniele Mazzotti To: Anthony Jenkins Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18 Cc: freebsd-acpi@freebsd.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jul 2014 21:26:28 -0000 Hi Anthony, here it is: $FreeBSD: release/10.0.0/Makefile 255784 2013-09-22 07:30:17Z andrew $ I will try to check how it is possible to update the code base. Cheers, Daniele. 2014-07-11 20:03 GMT+02:00 Daniele Mazzotti : > Hi Anthony, > > Thanks for the good hint. I will be searching for the revision info as > soon as I will be back home (3 hours from now more or less). > > Cheers, > Daniele. > Il 11/lug/2014 19:59 "Anthony Jenkins" ha > scritto: > > Errrr... good question :-) I got mine from Subversion, so in '/usr/src' I >> can run 'svn info' and see the revision. >> >> Your revision might be at the top of /usr/src/Makefile - it is in mine: >> >> # >> # $FreeBSD: head/Makefile 268191 2014-07-02 22:34:06Z marcel $ >> # >> >> I'm only wondering because it might be a bad copy. Might try getting the >> sources again. >> >> Thanks, >> Anthony >> >> On 07/11/2014 13:44, Daniele Mazzotti wrote: >> > Actually I think I downloaded the source code back in May when I updated >> > from RC3 to the current version. >> > >> > How can I check the code revision on my machine? >> > >> > Cheers, >> > Daniele. >> > Il 11/lug/2014 19:37 "Anthony Jenkins" ha >> > scritto: >> > >> >> I just tried a build of GENERIC + 'options ACPI_DEBUG' and it seems to >> get >> >> past the error you're seeing. What revision of the source code are you >> >> using... or where'd you get it from? >> >> >> >> Anthony >> >> >> >> On 07/11/2014 13:12, Daniele Mazzotti wrote: >> >>> Hi guys, >> >>> >> >>> everything as planned! I am getting a compiling error :-). >> >>> >> >>> This is the way i managed to update the GENERIC kernel >> >>> >> >>> # Bus support. >> >>> device acpi >> >>> options ACPI_DEBUG # Debug support for ACPI >> >>> device pci >> >>> >> >>> and this is the result of >> >>> >> >>> # *make buildkernel KERNCONF=MYKERNEL* >> >>> >> >>> >> >>> ===> crypto (depend) >> >>> @ -> /usr/src/sys >> >>> awk -f @/tools/makeobjops.awk @/opencrypto/cryptodev_if.m -c >> >>> >> >>> make[4]: stopped in /usr/src/sys/modules/crypto >> >>> *** Error code 2 >> >>> >> >>> Stop. >> >>> make[3]: stopped in /usr/src/sys/modules >> >>> *** Error code 1 >> >>> >> >>> Stop. >> >>> make[2]: stopped in /usr/obj/usr/src/sys/GENERIC >> >>> *** Error code 1 >> >>> >> >>> Stop. >> >>> make[1]: stopped in /usr/src >> >>> *** Error code 1 >> >>> >> >>> Stop. >> >>> make: stopped in /usr/src >> >>> >> >>> I googled a bit, but I could not find any valuable help and actually >> I do >> >>> not know what could be wrong as the custom kernel is essentially the >> >>> GENERIC with just one line added. >> >>> Have you ever experienced such a problem? >> >>> >> >>> Cheers, >> >>> Daniele. >> >>> >> >>> >> >>> >> >>> 2014-07-11 18:10 GMT+02:00 Daniele Mazzotti : >> >>> >> >>>> Hi guys, >> >>>> >> >>>> thanks again for the support. >> >>>> >> >>>> @Takanori: here you go http://pastebin.com/F0a2mZP4 >> >>>> @Anthony: I will try to include the options in a custom kernel and >> >> compile >> >>>> it. As this is the first time after years I am compiling a custom >> >> kernel it >> >>>> will take a few time I guess. >> >>>> >> >>>> Just let me know if the output of the acpidump is of any help to you. >> >>>> Cheers, >> >>>> Daniele. >> >>>> >> >>>> >> >>>> 2014-07-11 13:35 GMT+02:00 Anthony Jenkins < >> Anthony.B.Jenkins@att.net>: >> >>>> >> >>>> Hi Daniele, >> >>>>> I was just going from acpi(4) man page; you'll likely have to build >> a >> >> new >> >>>>> kernel with 'options ACPI_DEBUG' added to your kernel config file, >> as I >> >>>>> don't know if it's even possible to turn on the logging I want at >> >> runtime. >> >>>>> [ajenkins@ajenkins-hplaptop /usr/home/ajenkins]$ grep -i acpi >> >>>>> /usr/src/sys/amd64/conf/MYKERNEL >> >>>>> device acpi >> >>>>> options ACPI_DEBUG >> >>>>> >> >>>>> I also have an 'options ACPI_DMAR' , but I don't recognize that and >> you >> >>>>> don't need that to debug your battery. >> >>>>> >> >>>>> Anthony >> >>>>> >> >>>>> On 07/11/2014 01:58, Daniele Mazzotti wrote: >> >>>>>> Hello Anthony, >> >>>>>> >> >>>>>> thanks for the quick reply! I tried what you suggested. >> >>>>>> >> >>>>>> loader.conf: >> >>>>>> >> >>>>>> # Module for Windows Partition & Linux Mount >> >>>>>> fuse_load="YES" >> >>>>>> autoboot_delay="5" >> >>>>>> #acpi_sony_load="YES" >> >>>>>> >> >>>>>> # Debugging Symbols for ACPI >> >>>>>> debug.acpi.layer="ACPI_BATTERY" >> >>>>>> debug.acpi.level="ACPI_LV_ALL_EXCEPTIONS" >> >>>>>> debug.acpi.enable_debug_objects="1" >> >>>>>> >> >>>>>> sysctl hw.acpi.battery: >> >>>>>> >> >>>>>> hw.acpi.battery.life: -1 >> >>>>>> hw.acpi.battery.time: -1 >> >>>>>> hw.acpi.battery.state: 7 >> >>>>>> hw.acpi.battery.units: 1 >> >>>>>> hw.acpi.battery.info_expire: 5 >> >>>>>> >> >>>>>> log/messages: >> >>>>>> >> >>>>>> cat /var/log/messages | grep acpi >> >>>>>> >> >>>>>> Jul 11 07:30:47 Von-Neumann kernel: acpi0: on motherboard >> >>>>>> Jul 11 07:30:47 Von-Neumann kernel: acpi_ec0: > >> GPE >> >>>>>> 0x17, ECDT> port 0x62,0x66 on acpi0 >> >>>>>> Jul 11 07:30:47 Von-Neumann kernel: cpu0: on acpi0 >> >>>>>> Jul 11 07:30:47 Von-Neumann kernel: cpu1: on acpi0 >> >>>>>> Jul 11 07:30:47 Von-Neumann kernel: cpu2: on acpi0 >> >>>>>> Jul 11 07:30:47 Von-Neumann kernel: cpu3: on acpi0 >> >>>>>> Jul 11 07:30:47 Von-Neumann kernel: hpet0: > >> Timer> >> >>>>>> iomem 0xfed00000-0xfed003ff on acpi0 >> >>>>>> Jul 11 07:30:47 Von-Neumann kernel: atrtc0: >> port >> >>>>>> 0x70-0x77 irq 8 on acpi0 >> >>>>>> Jul 11 07:30:47 Von-Neumann kernel: attimer0: port >> >>>>>> 0x40-0x43,0x50-0x53 irq 0 on acpi0 >> >>>>>> Jul 11 07:30:47 Von-Neumann kernel: acpi_timer0: <24-bit timer at >> >>>>>> 3.579545MHz> port 0x408-0x40b on acpi0 >> >>>>>> Jul 11 07:30:47 Von-Neumann kernel: pcib0: >> port >> >>>>>> 0xcf8-0xcff on acpi0 >> >>>>>> Jul 11 07:30:47 Von-Neumann kernel: battery0: > >>>>> Battery> >> >>>>>> on acpi0 >> >>>>>> Jul 11 07:30:47 Von-Neumann kernel: acpi_acad0: on >> acpi0 >> >>>>>> Jul 11 07:30:47 Von-Neumann kernel: acpi_lid0: > >>>>> Switch> >> >>>>>> on acpi0 >> >>>>>> Jul 11 07:30:47 Von-Neumann kernel: acpi_button0: on >> >>>>> acpi0 >> >>>>>> Jul 11 07:30:47 Von-Neumann kernel: acpi_tz0: on >> acpi0 >> >>>>>> Jul 11 07:30:47 Von-Neumann kernel: acpi_tz1: on >> acpi0 >> >>>>>> Jul 11 07:30:47 Von-Neumann kernel: atkbdc0: > >>>>> (i8042)> >> >>>>>> port 0x60,0x64 irq 1 on acpi0 >> >>>>>> Jul 11 07:30:47 Von-Neumann kernel: acpi_sony0: > >>>>> controller> >> >>>>>> on acpi0 >> >>>>>> Jul 11 07:30:47 Von-Neumann kernel: acpi_sony0: PID 0 >> >>>>>> Jul 11 07:37:54 Von-Neumann kernel: acpi0: on motherboard >> >>>>>> Jul 11 07:37:54 Von-Neumann kernel: acpi_ec0: > >> GPE >> >>>>>> 0x17, ECDT> port 0x62,0x66 on acpi0 >> >>>>>> Jul 11 07:37:54 Von-Neumann kernel: cpu0: on acpi0 >> >>>>>> Jul 11 07:37:54 Von-Neumann kernel: cpu1: on acpi0 >> >>>>>> Jul 11 07:37:54 Von-Neumann kernel: cpu2: on acpi0 >> >>>>>> Jul 11 07:37:54 Von-Neumann kernel: cpu3: on acpi0 >> >>>>>> Jul 11 07:37:54 Von-Neumann kernel: hpet0: > >> Timer> >> >>>>>> iomem 0xfed00000-0xfed003ff on acpi0 >> >>>>>> Jul 11 07:37:54 Von-Neumann kernel: atrtc0: >> port >> >>>>>> 0x70-0x77 irq 8 on acpi0 >> >>>>>> Jul 11 07:37:54 Von-Neumann kernel: attimer0: port >> >>>>>> 0x40-0x43,0x50-0x53 irq 0 on acpi0 >> >>>>>> Jul 11 07:37:54 Von-Neumann kernel: acpi_timer0: <24-bit timer at >> >>>>>> 3.579545MHz> port 0x408-0x40b on acpi0 >> >>>>>> Jul 11 07:37:54 Von-Neumann kernel: pcib0: >> port >> >>>>>> 0xcf8-0xcff on acpi0 >> >>>>>> Jul 11 07:37:54 Von-Neumann kernel: battery0: > >>>>> Battery> >> >>>>>> on acpi0 >> >>>>>> Jul 11 07:37:54 Von-Neumann kernel: acpi_acad0: on >> acpi0 >> >>>>>> Jul 11 07:37:54 Von-Neumann kernel: acpi_lid0: > >>>>> Switch> >> >>>>>> on acpi0 >> >>>>>> Jul 11 07:37:54 Von-Neumann kernel: acpi_button0: on >> >>>>> acpi0 >> >>>>>> Jul 11 07:37:54 Von-Neumann kernel: acpi_tz0: on >> acpi0 >> >>>>>> Jul 11 07:37:54 Von-Neumann kernel: acpi_tz1: on >> acpi0 >> >>>>>> Jul 11 07:37:54 Von-Neumann kernel: atkbdc0: > >>>>> (i8042)> >> >>>>>> port 0x60,0x64 irq 1 on acpi0 >> >>>>>> >> >>>>>> It seems to me the verbose debugging is either not enabled >> (perhaps I >> >>>>> made >> >>>>>> some mistakes with the loader.conf) or the debug is really enabled >> but >> >>>>>> there is no special output on the wrong log file. Actually I am a >> bit >> >>>>>> puzzled as I am not a real expert "admin". I only enjoy getting my >> >>>>> hands on >> >>>>>> Unix on my desktop PC just for fun. >> >>>>>> >> >>>>>> However, do you think either I missed something or made anything >> >> wrong? >> >>>>>> I look forward to receiving from you. >> >>>>>> >> >>>>>> Cheers, >> >>>>>> Daniele. >> >>>>>> >> >>>>>> >> >>>>>> >> >>>>>> 2014-07-10 23:27 GMT+02:00 Anthony Jenkins < >> Anthony.B.Jenkins@att.net >> >>> : >> >>>>>>> On 07/10/2014 16:49, Daniele Mazzotti wrote: >> >>>>>>>> Hello there, >> >>>>>>>> >> >>>>>>>> it is been a while since I finished installing Freebsd 10 on my >> Sony >> >>>>> Vaio >> >>>>>>>> PC and resolving (or at least I am trying to) one by one, all the >> >>>>>>> problems >> >>>>>>>> this hardware is giving me. Actually I cannot find a solution to >> >>>>>>> correctly >> >>>>>>>> display the battery level on my laptop. If I unplug my PC from >> the >> >>>>> power >> >>>>>>>> and type 'sysctl hw.acpi.battery' this is the result I get: >> >>>>>>>> >> >>>>>>>> hw.acpi.battery.life: -1 >> >>>>>>>> hw.acpi.battery.time: -1 >> >>>>>>>> hw.acpi.battery.state: 7 >> >>>>>>>> hw.acpi.battery.units: 1 >> >>>>>>>> hw.acpi.battery.info_expire: 5 >> >>>>>>>> >> >>>>>>>> Moreover the suspend mode is giving me some problems as well, but >> >> this >> >>>>>>> has >> >>>>>>>> definitely a lower priority. >> >>>>>>>> >> >>>>>>>> I either tried to search for a solution on the FreeBSD Handook >> with >> >> no >> >>>>>>>> luck, and google the problem a little bit, but I could not find >> any >> >>>>>>>> valuable help. I would be really interested to investigate the >> >> problem >> >>>>>>>> further. Is there anyone who can help me out with this and tell >> me >> >>>>> what >> >>>>>>>> pieces of information are needed to better understand the >> problem? >> >>>>>>> Try enabling the ACPI_BATTERY layer and ACPI_LV_ALL_EXCEPTIONS >> level >> >> in >> >>>>>>> /boot/loader.conf: >> >>>>>>> >> >>>>>>> debug.acpi.layer="ACPI_BATTERY" >> >>>>>>> debug.acpi.level="ACPI_LV_ALL_EXCEPTIONS" >> >>>>>>> debug.acpi.enable_debug_objects="1" # I assume this is >> how >> >>>>> you >> >>>>>>> turn on ACPI debugging without recompiling the kernel with >> 'options >> >>>>>>> ACPI_DEBUG' >> >>>>>>> >> >>>>>>> and running 'sysctl hw.acpi.battery' again. Post >> /var/log/messages >> >>>>> ACPI >> >>>>>>> messages about battery here. >> >>>>>>> >> >>>>>>> Anthony >> >>>>>>> >> >>>>>>>> Cheers, >> >>>>>>>> Daniele. >> >>>>>>>> _______________________________________________ >> >>>>>>>> freebsd-acpi@freebsd.org mailing list >> >>>>>>>> http://lists.freebsd.org/mailman/listinfo/freebsd-acpi >> >>>>>>>> To unsubscribe, send any mail to " >> >>>>> freebsd-acpi-unsubscribe@freebsd.org" >> >>>>>> _______________________________________________ >> >>>>>> freebsd-acpi@freebsd.org mailing list >> >>>>>> http://lists.freebsd.org/mailman/listinfo/freebsd-acpi >> >>>>>> To unsubscribe, send any mail to " >> >> freebsd-acpi-unsubscribe@freebsd.org" >> >>> _______________________________________________ >> >>> freebsd-acpi@freebsd.org mailing list >> >>> http://lists.freebsd.org/mailman/listinfo/freebsd-acpi >> >>> To unsubscribe, send any mail to " >> freebsd-acpi-unsubscribe@freebsd.org" >> >>> >> >> >> > _______________________________________________ >> > freebsd-acpi@freebsd.org mailing list >> > http://lists.freebsd.org/mailman/listinfo/freebsd-acpi >> > To unsubscribe, send any mail to "freebsd-acpi-unsubscribe@freebsd.org" >> > >> >> From owner-freebsd-acpi@FreeBSD.ORG Fri Jul 11 23:30:52 2014 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3657C634 for ; Fri, 11 Jul 2014 23:30:52 +0000 (UTC) Received: from mout.gmx.com (mout.gmx.com [74.208.4.200]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 10F1622FD for ; Fri, 11 Jul 2014 23:30:52 +0000 (UTC) Received: from [216.115.15.149] by 3capp-mailcom-lxa02.server.lan (via HTTP); Sat, 12 Jul 2014 01:30:45 +0200 Message-ID: From: "Old Fart" To: freebsd-acpi@freebsd.org Subject: Re: HP Compaq 8710W Battery status problems Date: Sat, 12 Jul 2014 01:30:45 +0200 Importance: normal Sensitivity: Normal In-Reply-To: <53BF0648.40602@att.net> References: , <53BF0648.40602@att.net> X-UI-Message-Type: mail X-Priority: 3 X-Provags-ID: V03:K0:wH5Hy3IhcrBoX4bXE5hZwlKaTX03Kv3j4WErAw0z2co Z1+tEX5IboUc6dQK2wNbC9hKwQ/AtdffWh83ZaVJIgoAVmTsOH 5T6vy4bGVsH4q+9RTDcLLAI5z7HROzbiLmuRoch/sHYZniPdyX zhVVppkLweUIMo1d4oGKAHFZkkRrI6GYl/lvE4ocO+VJ3u1wJL UW1/IkXAeE11YnnXIJj0HIWiWMIpCuurADk1sMmmkxD0fObo44 WjUwo/gaJZ96s88px2qGf2OtjKYjQbDeoQQQ5WQ2/VrYP8bO4N 252azAt1fqWBmnT3Dm76E0BU9zH MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.18 X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jul 2014 23:30:52 -0000 Sent: Thursday, July 10, 2014 at 2:31 PM From: "Anthony Jenkins" To: "Ron Freidel" , freebsd-acpi@freebsd.org Subject: Re: HP Compaq 8710W Battery status problems > Plugged in and fully charged.... > acpiconf -i batt Isn't this supposed to be 'acpiconf -i 0' and 'acpiconf -i 1'? On my machine the two commands (-i 0 & -i batt) deliver identical information, when I posted originally I was tired and bleary eyed/headed... [ajenkins@ajenkins-hplaptop /usr/src/sys]$ acpiconf -i 1 acpiconf: get battery info (1) failed: Device not configured Here's the output of acpiconf-i 1 [ronf@mobile] ~% acpiconf -i 1 Design capacity: 0 mWh Last full capacity: 0 mWh Technology: primary (non-rechargeable) Design voltage: 0 mV Capacity (warn): 0 mWh Capacity (low): 0 mWh Low/warn granularity: 0 mWh Warn/full granularity: 0 mWh Model number: Serial number: Type: OEM info: State: not present Present voltage: unknown Just for giggles I did run acpiconf -i 0 & -i 1 without the battery installed, saw this... [ronf@mobile] ~% acpiconf -i 0 Design capacity: unknown Last full capacity: unknown Technology: secondary (rechargeable) Design voltage: unknown Capacity (warn): 0 mWh Capacity (low): 0 mWh Low/warn granularity: 0 mWh Warn/full granularity: 0 mWh Model number: Serial number: Type: OEM info: State: not present Present voltage: unknown [ronf@mobile] ~% acpiconf -i 1 Design capacity: 0 mWh Last full capacity: 0 mWh Technology: primary (non-rechargeable) Design voltage: 0 mV Capacity (warn): 0 mWh Capacity (low): 0 mWh Low/warn granularity: 0 mWh Warn/full granularity: 0 mWh Model number: Serial number: Type: OEM info: State: not present Present voltage: unknown Apparently if my sysapses are firing correctly, the os is seeing the laptops main battery as secondary and a non existant battery as primary. From owner-freebsd-acpi@FreeBSD.ORG Fri Jul 11 23:53:30 2014 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EAFACE04 for ; Fri, 11 Jul 2014 23:53:29 +0000 (UTC) Received: from mout.gmx.com (mout.gmx.com [74.208.4.201]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C3BF12547 for ; Fri, 11 Jul 2014 23:53:29 +0000 (UTC) Received: from [216.115.15.149] by 3capp-mailcom-lxa02.server.lan (via HTTP); Sat, 12 Jul 2014 01:53:22 +0200 Message-ID: From: "Old Fart" To: freebsd-acpi@freebsd.org Subject: Re: HP Compaq 8710W Battery status problems Date: Sat, 12 Jul 2014 01:53:22 +0200 Importance: normal Sensitivity: Normal In-Reply-To: References: , <53BF0648.40602@att.net>, X-UI-Message-Type: mail X-Priority: 3 X-Provags-ID: V03:K0:oE7ZX08KvqEgOc4W7UmWrxzs/Xlfu5qETCWhbf7+kTC bFBXsl78knSt+8Ex06bYDI1mpqW5RhcWIcKN5dtFAjYSw4RifA U+zCGTXrPDJ0GphOMc+GnLEmlmmGYxVwRL8ua3V7lcS+cPVBrK JHdVlgNDs85zOQWs138mbpXcEbOCBhztuGgxX0cc/Bfzc5JpMe J5iUNtNBR5H3mjUh6Y3Jo9RqTYa5/Q/whgTg/35qBQrowTkLzK ujJ7m49aIZEUNr7DOX56lbpn30jL3ADuH+DAqXBN3/2xxBuFej mliNZF8A8v2gSFTO6+HMhnuELFz MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.18 X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jul 2014 23:53:30 -0000 Sent: Friday, July 11, 2014 at 4:30 PM From: "Old Fart" To: freebsd-acpi@freebsd.org Subject: Re: HP Compaq 8710W Battery status problems Sent: Thursday, July 10, 2014 at 2:31 PM From: "Anthony Jenkins" To: "Ron Freidel" , freebsd-acpi@freebsd.org Subject: Re: HP Compaq 8710W Battery status problems > Plugged in and fully charged.... > acpiconf -i batt Isn't this supposed to be 'acpiconf -i 0' and 'acpiconf -i 1'? On my machine the two commands (-i 0 & -i batt) deliver identical information, when I posted originally I was tired and bleary eyed/headed... [ajenkins@ajenkins-hplaptop /usr/src/sys]$ acpiconf -i 1 acpiconf: get battery info (1) failed: Device not configured Here's the output of acpiconf-i 1 [ronf@mobile] ~% acpiconf -i 1 Design capacity: 0 mWh Last full capacity: 0 mWh Technology: primary (non-rechargeable) Design voltage: 0 mV Capacity (warn): 0 mWh Capacity (low): 0 mWh Low/warn granularity: 0 mWh Warn/full granularity: 0 mWh Model number: Serial number: Type: OEM info: State: not present Present voltage: unknown Just for giggles I did run acpiconf -i 0 & -i 1 without the battery installed, saw this... [ronf@mobile] ~% acpiconf -i 0 Design capacity: unknown Last full capacity: unknown Technology: secondary (rechargeable) Design voltage: unknown Capacity (warn): 0 mWh Capacity (low): 0 mWh Low/warn granularity: 0 mWh Warn/full granularity: 0 mWh Model number: Serial number: Type: OEM info: State: not present Present voltage: unknown [ronf@mobile] ~% acpiconf -i 1 Design capacity: 0 mWh Last full capacity: 0 mWh Technology: primary (non-rechargeable) Design voltage: 0 mV Capacity (warn): 0 mWh Capacity (low): 0 mWh Low/warn granularity: 0 mWh Warn/full granularity: 0 mWh Model number: Serial number: Type: OEM info: State: not present Present voltage: unknown Apparently if my sysapses are firing correctly, the os is seeing the laptops main battery as secondary and a non existant battery as primary. A little more info.. Looking at dmesg I see battery0: on acpi0 battery1: on acpi0 Battery1 does not exist. _______________________________________________ freebsd-acpi@freebsd.org mailing list [1]http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to "freebsd-acpi-unsubscribe@freebsd.org" References 1. http://lists.freebsd.org/mailman/listinfo/freebsd-acpi From owner-freebsd-acpi@FreeBSD.ORG Sat Jul 12 05:44:39 2014 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8E6C7F5B for ; Sat, 12 Jul 2014 05:44:39 +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 CFA7120EC for ; Sat, 12 Jul 2014 05:44:37 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id s6C5iOAK009243; Sat, 12 Jul 2014 15:44:24 +1000 (EST) (envelope-from smithi@nimnet.asn.au) Date: Sat, 12 Jul 2014 15:44:23 +1000 (EST) From: Ian Smith To: Old Fart Subject: Re: HP Compaq 8710W Battery status problems In-Reply-To: Message-ID: <20140712150252.S50382@sola.nimnet.asn.au> References: , <53BF0648.40602@att.net>, MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: Anthony Jenkins , freebsd-acpi@freebsd.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Jul 2014 05:44:39 -0000 On Sat, 12 Jul 2014 01:53:22 +0200, Old Fart wrote: > Sent: Friday, July 11, 2014 at 4:30 PM > From: "Old Fart" > To: freebsd-acpi@freebsd.org > Subject: Re: HP Compaq 8710W Battery status problems > Sent: Thursday, July 10, 2014 at 2:31 PM > From: "Anthony Jenkins" > To: "Ron Freidel" , freebsd-acpi@freebsd.org > Subject: Re: HP Compaq 8710W Battery status problems > > > Plugged in and fully charged.... > > acpiconf -i batt > Isn't this supposed to be 'acpiconf -i 0' and 'acpiconf -i 1'? > On my machine the two commands (-i 0 & -i batt) deliver identical > information, when I posted originally I was tired and bleary > eyed/headed... Yes, '-i anyword' gets you battery 0. Consider it a feature :) > > [ajenkins@ajenkins-hplaptop /usr/src/sys]$ acpiconf -i 1 > acpiconf: get battery info (1) failed: Device not configured > Here's the output of acpiconf-i 1 > [ronf@mobile] ~% acpiconf -i 1 > Design capacity: 0 mWh > Last full capacity: 0 mWh > Technology: primary (non-rechargeable) > Design voltage: 0 mV > Capacity (warn): 0 mWh > Capacity (low): 0 mWh > Low/warn granularity: 0 mWh > Warn/full granularity: 0 mWh > Model number: > Serial number: > Type: > OEM info: > State: not present > Present voltage: unknown > Just for giggles I did run acpiconf -i 0 & -i 1 without the battery > installed, saw this... > [ronf@mobile] ~% acpiconf -i 0 > Design capacity: unknown > Last full capacity: unknown > Technology: secondary (rechargeable) > Design voltage: unknown > Capacity (warn): 0 mWh > Capacity (low): 0 mWh > Low/warn granularity: 0 mWh > Warn/full granularity: 0 mWh > Model number: > Serial number: > Type: > OEM info: > State: not present > Present voltage: unknown That looks completely normal for a removed battery. > [ronf@mobile] ~% acpiconf -i 1 > Design capacity: 0 mWh > Last full capacity: 0 mWh > Technology: primary (non-rechargeable) > Design voltage: 0 mV > Capacity (warn): 0 mWh > Capacity (low): 0 mWh > Low/warn granularity: 0 mWh > Warn/full granularity: 0 mWh > Model number: > Serial number: > Type: > OEM info: > State: not present > Present voltage: unknown > Apparently if my sysapses are firing correctly, the os is seeing the > laptops main battery as secondary and a non existant battery as > primary. I believe 'primary' and 'secondary' here are referring to power-source technology under ACPI, not their relative positions. Why it should consider battery1 to be 'primary (non-rechargeable)' I don't know, unless it has provision for using a pack of non-rechargeable batteries? Or at least, some battery source that the machine won't try to charge? > A little more info.. > > Looking at dmesg I see > > battery0: on acpi0 > battery1: on acpi0 > > Battery1 does not exist. No, your battery1 is not installed, but ACPI claims to be ready when you do install one in the other slot. What does its manual say about this? My old '98 Compaq 1500c - still running, but under APM rather than ACPI, only because its ACPI failed to switch to battery when AC was removed - worked with a second battery also installed, when it replaced the floppy disk drive. It also showed both battery slots in dmesg just like that. However, acpiconf showed both as 'secondary (rechargeable)', and did work properly to work out remaining capacity and time with both fitted, even properly discharging one until near empty before switching to the other, and charging them up in turn when AC was reconnected. Not that this helps your issue of it discharging without updating the capacity %, time remaining etc. This could be a fault in the embedded controller (if the Sony uses one of those?) but perhaps more likely a fault in the coulomb-counter chip in the battery itself. Have you tried another battery? It's not so uncommon for these chips to fail, or at least lose any sensible idea of what's going on with the battery, which sometimes a complete discharge/recharge cycle, or several, _might_ fix. If it fails similarly with another battery, then it may be an issue with the ACPI implementation itself on that machine, in which case other instances of the problem occurring should show up on a search. Are you running the latest BIOS upgrade for your laptop? cheers, Ian From owner-freebsd-acpi@FreeBSD.ORG Sat Jul 12 16:57:31 2014 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8403B9AC for ; Sat, 12 Jul 2014 16:57:31 +0000 (UTC) Received: from mail-oa0-x232.google.com (mail-oa0-x232.google.com [IPv6:2607:f8b0:4003:c02::232]) (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 46CB821FB for ; Sat, 12 Jul 2014 16:57:31 +0000 (UTC) Received: by mail-oa0-f50.google.com with SMTP id g18so2582684oah.23 for ; Sat, 12 Jul 2014 09:57:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=3fNLg1ZojSxZdvDaCYt/+wXrh/IyZnqaXYkQtUq7Mjw=; b=wV226E3QRd0VMoEosAHeZIeemukWRli7z3YUJYYuNjgvQ2gfX4asmZrO8JTDgIxPBK 8hwvPXmEkqtno2tvMPN9lB5EB7A++seetb71PIr4Cv6SnY3XyVkxyIhF6rWdTTewdkmq hClN6d72HW81p3hcAi8+ZBJJavmlIqwaoJUXZ1Crqna5zkdc0LEhI36TyAymp9LlBeDH uCyBV4TxllB5Z+uqMIxV91XsS+Oa8kQr1wIkQQxl899a8zjX7jVB+Xe4ORhD5M6keto8 Z9acYQ2WwyZ30oQ+GXW8toU/7+VOhC71/ia0mZ0k1oheUDCV6KnHVA7ToyxFQXC/ordm 2q1A== MIME-Version: 1.0 X-Received: by 10.182.72.167 with SMTP id e7mr7203058obv.28.1405184250403; Sat, 12 Jul 2014 09:57:30 -0700 (PDT) Received: by 10.182.29.9 with HTTP; Sat, 12 Jul 2014 09:57:30 -0700 (PDT) In-Reply-To: References: <53BF0546.70505@att.net> <53BFCBF4.2090104@att.net> <53C020CE.8010205@att.net> <53C02604.9070207@att.net> Date: Sat, 12 Jul 2014 18:57:30 +0200 Message-ID: Subject: Re: ACPI support - Freebsd 10 on Sony Vaio VPCCA3C5E From: Daniele Mazzotti To: Anthony Jenkins Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18 Cc: freebsd-acpi@freebsd.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Jul 2014 16:57:31 -0000 Hi Guys, I have successfully compiled and installed the kernel with ACPI debug. @Anthony: my problem was definitely related to an outdated code base. So my question is now: "what should I do?". Is there any log or command I should issue in order to have a better understanding of the problem? Cheers, Daniele. 2014-07-11 23:26 GMT+02:00 Daniele Mazzotti : > Hi Anthony, > > here it is: $FreeBSD: release/10.0.0/Makefile 255784 2013-09-22 07:30:17Z > andrew $ > > I will try to check how it is possible to update the code base. > Cheers, > Daniele. > > > 2014-07-11 20:03 GMT+02:00 Daniele Mazzotti : > > Hi Anthony, >> >> Thanks for the good hint. I will be searching for the revision info as >> soon as I will be back home (3 hours from now more or less). >> >> Cheers, >> Daniele. >> Il 11/lug/2014 19:59 "Anthony Jenkins" ha >> scritto: >> >> Errrr... good question :-) I got mine from Subversion, so in '/usr/src' >>> I can run 'svn info' and see the revision. >>> >>> Your revision might be at the top of /usr/src/Makefile - it is in mine: >>> >>> # >>> # $FreeBSD: head/Makefile 268191 2014-07-02 22:34:06Z marcel $ >>> # >>> >>> I'm only wondering because it might be a bad copy. Might try getting >>> the sources again. >>> >>> Thanks, >>> Anthony >>> >>> On 07/11/2014 13:44, Daniele Mazzotti wrote: >>> > Actually I think I downloaded the source code back in May when I >>> updated >>> > from RC3 to the current version. >>> > >>> > How can I check the code revision on my machine? >>> > >>> > Cheers, >>> > Daniele. >>> > Il 11/lug/2014 19:37 "Anthony Jenkins" ha >>> > scritto: >>> > >>> >> I just tried a build of GENERIC + 'options ACPI_DEBUG' and it seems >>> to get >>> >> past the error you're seeing. What revision of the source code are >>> you >>> >> using... or where'd you get it from? >>> >> >>> >> Anthony >>> >> >>> >> On 07/11/2014 13:12, Daniele Mazzotti wrote: >>> >>> Hi guys, >>> >>> >>> >>> everything as planned! I am getting a compiling error :-). >>> >>> >>> >>> This is the way i managed to update the GENERIC kernel >>> >>> >>> >>> # Bus support. >>> >>> device acpi >>> >>> options ACPI_DEBUG # Debug support for ACPI >>> >>> device pci >>> >>> >>> >>> and this is the result of >>> >>> >>> >>> # *make buildkernel KERNCONF=MYKERNEL* >>> >>> >>> >>> >>> >>> ===> crypto (depend) >>> >>> @ -> /usr/src/sys >>> >>> awk -f @/tools/makeobjops.awk @/opencrypto/cryptodev_if.m -c >>> >>> >>> >>> make[4]: stopped in /usr/src/sys/modules/crypto >>> >>> *** Error code 2 >>> >>> >>> >>> Stop. >>> >>> make[3]: stopped in /usr/src/sys/modules >>> >>> *** Error code 1 >>> >>> >>> >>> Stop. >>> >>> make[2]: stopped in /usr/obj/usr/src/sys/GENERIC >>> >>> *** Error code 1 >>> >>> >>> >>> Stop. >>> >>> make[1]: stopped in /usr/src >>> >>> *** Error code 1 >>> >>> >>> >>> Stop. >>> >>> make: stopped in /usr/src >>> >>> >>> >>> I googled a bit, but I could not find any valuable help and actually >>> I do >>> >>> not know what could be wrong as the custom kernel is essentially the >>> >>> GENERIC with just one line added. >>> >>> Have you ever experienced such a problem? >>> >>> >>> >>> Cheers, >>> >>> Daniele. >>> >>> >>> >>> >>> >>> >>> >>> 2014-07-11 18:10 GMT+02:00 Daniele Mazzotti : >>> >>> >>> >>>> Hi guys, >>> >>>> >>> >>>> thanks again for the support. >>> >>>> >>> >>>> @Takanori: here you go http://pastebin.com/F0a2mZP4 >>> >>>> @Anthony: I will try to include the options in a custom kernel and >>> >> compile >>> >>>> it. As this is the first time after years I am compiling a custom >>> >> kernel it >>> >>>> will take a few time I guess. >>> >>>> >>> >>>> Just let me know if the output of the acpidump is of any help to >>> you. >>> >>>> Cheers, >>> >>>> Daniele. >>> >>>> >>> >>>> >>> >>>> 2014-07-11 13:35 GMT+02:00 Anthony Jenkins < >>> Anthony.B.Jenkins@att.net>: >>> >>>> >>> >>>> Hi Daniele, >>> >>>>> I was just going from acpi(4) man page; you'll likely have to >>> build a >>> >> new >>> >>>>> kernel with 'options ACPI_DEBUG' added to your kernel config file, >>> as I >>> >>>>> don't know if it's even possible to turn on the logging I want at >>> >> runtime. >>> >>>>> [ajenkins@ajenkins-hplaptop /usr/home/ajenkins]$ grep -i acpi >>> >>>>> /usr/src/sys/amd64/conf/MYKERNEL >>> >>>>> device acpi >>> >>>>> options ACPI_DEBUG >>> >>>>> >>> >>>>> I also have an 'options ACPI_DMAR' , but I don't recognize that >>> and you >>> >>>>> don't need that to debug your battery. >>> >>>>> >>> >>>>> Anthony >>> >>>>> >>> >>>>> On 07/11/2014 01:58, Daniele Mazzotti wrote: >>> >>>>>> Hello Anthony, >>> >>>>>> >>> >>>>>> thanks for the quick reply! I tried what you suggested. >>> >>>>>> >>> >>>>>> loader.conf: >>> >>>>>> >>> >>>>>> # Module for Windows Partition & Linux Mount >>> >>>>>> fuse_load="YES" >>> >>>>>> autoboot_delay="5" >>> >>>>>> #acpi_sony_load="YES" >>> >>>>>> >>> >>>>>> # Debugging Symbols for ACPI >>> >>>>>> debug.acpi.layer="ACPI_BATTERY" >>> >>>>>> debug.acpi.level="ACPI_LV_ALL_EXCEPTIONS" >>> >>>>>> debug.acpi.enable_debug_objects="1" >>> >>>>>> >>> >>>>>> sysctl hw.acpi.battery: >>> >>>>>> >>> >>>>>> hw.acpi.battery.life: -1 >>> >>>>>> hw.acpi.battery.time: -1 >>> >>>>>> hw.acpi.battery.state: 7 >>> >>>>>> hw.acpi.battery.units: 1 >>> >>>>>> hw.acpi.battery.info_expire: 5 >>> >>>>>> >>> >>>>>> log/messages: >>> >>>>>> >>> >>>>>> cat /var/log/messages | grep acpi >>> >>>>>> >>> >>>>>> Jul 11 07:30:47 Von-Neumann kernel: acpi0: on motherboard >>> >>>>>> Jul 11 07:30:47 Von-Neumann kernel: acpi_ec0: >> Controller: >>> >> GPE >>> >>>>>> 0x17, ECDT> port 0x62,0x66 on acpi0 >>> >>>>>> Jul 11 07:30:47 Von-Neumann kernel: cpu0: on acpi0 >>> >>>>>> Jul 11 07:30:47 Von-Neumann kernel: cpu1: on acpi0 >>> >>>>>> Jul 11 07:30:47 Von-Neumann kernel: cpu2: on acpi0 >>> >>>>>> Jul 11 07:30:47 Von-Neumann kernel: cpu3: on acpi0 >>> >>>>>> Jul 11 07:30:47 Von-Neumann kernel: hpet0: >> >> Timer> >>> >>>>>> iomem 0xfed00000-0xfed003ff on acpi0 >>> >>>>>> Jul 11 07:30:47 Von-Neumann kernel: atrtc0: >>> port >>> >>>>>> 0x70-0x77 irq 8 on acpi0 >>> >>>>>> Jul 11 07:30:47 Von-Neumann kernel: attimer0: port >>> >>>>>> 0x40-0x43,0x50-0x53 irq 0 on acpi0 >>> >>>>>> Jul 11 07:30:47 Von-Neumann kernel: acpi_timer0: <24-bit timer at >>> >>>>>> 3.579545MHz> port 0x408-0x40b on acpi0 >>> >>>>>> Jul 11 07:30:47 Von-Neumann kernel: pcib0: >>> port >>> >>>>>> 0xcf8-0xcff on acpi0 >>> >>>>>> Jul 11 07:30:47 Von-Neumann kernel: battery0: >> >>>>> Battery> >>> >>>>>> on acpi0 >>> >>>>>> Jul 11 07:30:47 Von-Neumann kernel: acpi_acad0: on >>> acpi0 >>> >>>>>> Jul 11 07:30:47 Von-Neumann kernel: acpi_lid0: >> >>>>> Switch> >>> >>>>>> on acpi0 >>> >>>>>> Jul 11 07:30:47 Von-Neumann kernel: acpi_button0: >>> on >>> >>>>> acpi0 >>> >>>>>> Jul 11 07:30:47 Von-Neumann kernel: acpi_tz0: on >>> acpi0 >>> >>>>>> Jul 11 07:30:47 Von-Neumann kernel: acpi_tz1: on >>> acpi0 >>> >>>>>> Jul 11 07:30:47 Von-Neumann kernel: atkbdc0: >> >>>>> (i8042)> >>> >>>>>> port 0x60,0x64 irq 1 on acpi0 >>> >>>>>> Jul 11 07:30:47 Von-Neumann kernel: acpi_sony0: >> >>>>> controller> >>> >>>>>> on acpi0 >>> >>>>>> Jul 11 07:30:47 Von-Neumann kernel: acpi_sony0: PID 0 >>> >>>>>> Jul 11 07:37:54 Von-Neumann kernel: acpi0: on motherboard >>> >>>>>> Jul 11 07:37:54 Von-Neumann kernel: acpi_ec0: >> Controller: >>> >> GPE >>> >>>>>> 0x17, ECDT> port 0x62,0x66 on acpi0 >>> >>>>>> Jul 11 07:37:54 Von-Neumann kernel: cpu0: on acpi0 >>> >>>>>> Jul 11 07:37:54 Von-Neumann kernel: cpu1: on acpi0 >>> >>>>>> Jul 11 07:37:54 Von-Neumann kernel: cpu2: on acpi0 >>> >>>>>> Jul 11 07:37:54 Von-Neumann kernel: cpu3: on acpi0 >>> >>>>>> Jul 11 07:37:54 Von-Neumann kernel: hpet0: >> >> Timer> >>> >>>>>> iomem 0xfed00000-0xfed003ff on acpi0 >>> >>>>>> Jul 11 07:37:54 Von-Neumann kernel: atrtc0: >>> port >>> >>>>>> 0x70-0x77 irq 8 on acpi0 >>> >>>>>> Jul 11 07:37:54 Von-Neumann kernel: attimer0: port >>> >>>>>> 0x40-0x43,0x50-0x53 irq 0 on acpi0 >>> >>>>>> Jul 11 07:37:54 Von-Neumann kernel: acpi_timer0: <24-bit timer at >>> >>>>>> 3.579545MHz> port 0x408-0x40b on acpi0 >>> >>>>>> Jul 11 07:37:54 Von-Neumann kernel: pcib0: >>> port >>> >>>>>> 0xcf8-0xcff on acpi0 >>> >>>>>> Jul 11 07:37:54 Von-Neumann kernel: battery0: >> >>>>> Battery> >>> >>>>>> on acpi0 >>> >>>>>> Jul 11 07:37:54 Von-Neumann kernel: acpi_acad0: on >>> acpi0 >>> >>>>>> Jul 11 07:37:54 Von-Neumann kernel: acpi_lid0: >> >>>>> Switch> >>> >>>>>> on acpi0 >>> >>>>>> Jul 11 07:37:54 Von-Neumann kernel: acpi_button0: >>> on >>> >>>>> acpi0 >>> >>>>>> Jul 11 07:37:54 Von-Neumann kernel: acpi_tz0: on >>> acpi0 >>> >>>>>> Jul 11 07:37:54 Von-Neumann kernel: acpi_tz1: on >>> acpi0 >>> >>>>>> Jul 11 07:37:54 Von-Neumann kernel: atkbdc0: >> >>>>> (i8042)> >>> >>>>>> port 0x60,0x64 irq 1 on acpi0 >>> >>>>>> >>> >>>>>> It seems to me the verbose debugging is either not enabled >>> (perhaps I >>> >>>>> made >>> >>>>>> some mistakes with the loader.conf) or the debug is really >>> enabled but >>> >>>>>> there is no special output on the wrong log file. Actually I am a >>> bit >>> >>>>>> puzzled as I am not a real expert "admin". I only enjoy getting my >>> >>>>> hands on >>> >>>>>> Unix on my desktop PC just for fun. >>> >>>>>> >>> >>>>>> However, do you think either I missed something or made anything >>> >> wrong? >>> >>>>>> I look forward to receiving from you. >>> >>>>>> >>> >>>>>> Cheers, >>> >>>>>> Daniele. >>> >>>>>> >>> >>>>>> >>> >>>>>> >>> >>>>>> 2014-07-10 23:27 GMT+02:00 Anthony Jenkins < >>> Anthony.B.Jenkins@att.net >>> >>> : >>> >>>>>>> On 07/10/2014 16:49, Daniele Mazzotti wrote: >>> >>>>>>>> Hello there, >>> >>>>>>>> >>> >>>>>>>> it is been a while since I finished installing Freebsd 10 on my >>> Sony >>> >>>>> Vaio >>> >>>>>>>> PC and resolving (or at least I am trying to) one by one, all >>> the >>> >>>>>>> problems >>> >>>>>>>> this hardware is giving me. Actually I cannot find a solution to >>> >>>>>>> correctly >>> >>>>>>>> display the battery level on my laptop. If I unplug my PC from >>> the >>> >>>>> power >>> >>>>>>>> and type 'sysctl hw.acpi.battery' this is the result I get: >>> >>>>>>>> >>> >>>>>>>> hw.acpi.battery.life: -1 >>> >>>>>>>> hw.acpi.battery.time: -1 >>> >>>>>>>> hw.acpi.battery.state: 7 >>> >>>>>>>> hw.acpi.battery.units: 1 >>> >>>>>>>> hw.acpi.battery.info_expire: 5 >>> >>>>>>>> >>> >>>>>>>> Moreover the suspend mode is giving me some problems as well, >>> but >>> >> this >>> >>>>>>> has >>> >>>>>>>> definitely a lower priority. >>> >>>>>>>> >>> >>>>>>>> I either tried to search for a solution on the FreeBSD Handook >>> with >>> >> no >>> >>>>>>>> luck, and google the problem a little bit, but I could not find >>> any >>> >>>>>>>> valuable help. I would be really interested to investigate the >>> >> problem >>> >>>>>>>> further. Is there anyone who can help me out with this and tell >>> me >>> >>>>> what >>> >>>>>>>> pieces of information are needed to better understand the >>> problem? >>> >>>>>>> Try enabling the ACPI_BATTERY layer and ACPI_LV_ALL_EXCEPTIONS >>> level >>> >> in >>> >>>>>>> /boot/loader.conf: >>> >>>>>>> >>> >>>>>>> debug.acpi.layer="ACPI_BATTERY" >>> >>>>>>> debug.acpi.level="ACPI_LV_ALL_EXCEPTIONS" >>> >>>>>>> debug.acpi.enable_debug_objects="1" # I assume this >>> is how >>> >>>>> you >>> >>>>>>> turn on ACPI debugging without recompiling the kernel with >>> 'options >>> >>>>>>> ACPI_DEBUG' >>> >>>>>>> >>> >>>>>>> and running 'sysctl hw.acpi.battery' again. Post >>> /var/log/messages >>> >>>>> ACPI >>> >>>>>>> messages about battery here. >>> >>>>>>> >>> >>>>>>> Anthony >>> >>>>>>> >>> >>>>>>>> Cheers, >>> >>>>>>>> Daniele. >>> >>>>>>>> _______________________________________________ >>> >>>>>>>> freebsd-acpi@freebsd.org mailing list >>> >>>>>>>> http://lists.freebsd.org/mailman/listinfo/freebsd-acpi >>> >>>>>>>> To unsubscribe, send any mail to " >>> >>>>> freebsd-acpi-unsubscribe@freebsd.org" >>> >>>>>> _______________________________________________ >>> >>>>>> freebsd-acpi@freebsd.org mailing list >>> >>>>>> http://lists.freebsd.org/mailman/listinfo/freebsd-acpi >>> >>>>>> To unsubscribe, send any mail to " >>> >> freebsd-acpi-unsubscribe@freebsd.org" >>> >>> _______________________________________________ >>> >>> freebsd-acpi@freebsd.org mailing list >>> >>> http://lists.freebsd.org/mailman/listinfo/freebsd-acpi >>> >>> To unsubscribe, send any mail to " >>> freebsd-acpi-unsubscribe@freebsd.org" >>> >>> >>> >> >>> > _______________________________________________ >>> > freebsd-acpi@freebsd.org mailing list >>> > http://lists.freebsd.org/mailman/listinfo/freebsd-acpi >>> > To unsubscribe, send any mail to "freebsd-acpi-unsubscribe@freebsd.org >>> " >>> > >>> >>> > From owner-freebsd-acpi@FreeBSD.ORG Mon Jul 14 12:57:30 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 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CF16D4E5 for ; Mon, 14 Jul 2014 12:57:30 +0000 (UTC) Received: from nm26-vm6.access.bullet.mail.bf1.yahoo.com (nm26-vm6.access.bullet.mail.bf1.yahoo.com [216.109.115.213]) (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 7DB8025BD for ; Mon, 14 Jul 2014 12:57:30 +0000 (UTC) Received: from [66.196.81.157] by nm26.access.bullet.mail.bf1.yahoo.com with NNFMP; 14 Jul 2014 12:55:00 -0000 Received: from [98.138.104.99] by tm3.access.bullet.mail.bf1.yahoo.com with NNFMP; 14 Jul 2014 12:55:00 -0000 Received: from [127.0.0.1] by smtp119.sbc.mail.ne1.yahoo.com with NNFMP; 14 Jul 2014 12:55:00 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1405342500; bh=fZdDcZK3xBqjG8b/7fbqaeZuWYKXxSCD1SgKZnHFx7Y=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=pF3Qg3WCyePYtHcNz9nyNCmKy0oghMzJ9UVMJovd10vjtjiNKdx+2nFWX2sDcCM293mtKWx3RY49w4JLbTR+x3gOXbNnWsNQYCLYN4JWkF9b72fkIkAYBVqwQIfaj2Chg11Fl7PcpMgJddIzN5oSriI5DRwOwVmpEisBmCxo/tw= X-Yahoo-Newman-Id: 272497.33131.bm@smtp119.sbc.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: CLbCepwVM1nmYauHpHasNzLBopz1A9NTZYjrWJK5L_Jw2Mr Lw_GtQ6FDNYmxx1nJ3GoZusAgeX5mixWs2.sYhe1Opnt5miLsmLN5E3sOa2R LrGalxDPL8jUbE6eriq4vkfIAzjiStLKZJKgTGCT2CV5OEkk2AlyGKwuztbh Mh7RXNhL7gXyxtjiaEuFl9TM113hEK5K.itk3lgSTJ3lW.br7sah0ntz.fh2 a1V52XEydlir1tmEu.gdDvw7HqfBtieJ12qsfZAwA4n0xOfJOACjFoZzy2Ow KWbVRPKGBM2OkOFsXAmimvEUvifr5z3RX40bBgH64ZhSR7LeYPk6vq2MVBAI k3I4AkN_BK9uSGg9pgcIz.C2Gn0y7QYH0A4zotVz7X_O3lAu3DK8pYkGfrIf t0vckFgO6O1Sq5sk6TAGF5yVFKPf_mnUg4s4gP1SP3V7JTQFLGX.0dje9u7Q _gmPr1_QQKkCBHnvbAZetJKsTsBMR8tJE0PQ8kqMKFe63pv3Lmv0VCL1YB0M xEZgKMnFQfTiiGr5U2yRTBiCJVlCI9QpJIT3EpQcUa7evGzzb.FWBGMWplIo EMmpG4UO5Jj1YpTQbsay0zMa89nMvD4sWVYIOsL_GrJmloc8.3RskE8YMYIK zcUTs.TmLF_yNw_0- X-Yahoo-SMTP: OKD1keCswBBTAmAF1s00hLyKW3wE3YfSK0Eazl6b4VZG4LTqJxg- X-Rocket-Received: from [10.82.216.130] (Anthony.B.Jenkins@64.102.254.33 with plain [98.138.84.52]) by smtp119.sbc.mail.ne1.yahoo.com with SMTP; 14 Jul 2014 12:55:00 +0000 UTC Message-ID: <53C3D322.3080302@att.net> Date: Mon, 14 Jul 2014 08:54:58 -0400 From: Anthony Jenkins User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Daniele Mazzotti Subject: Re: ACPI support - Freebsd 10 on Sony Vaio VPCCA3C5E References: <53BF0546.70505@att.net> <53BFCBF4.2090104@att.net> <53C020CE.8010205@att.net> <53C02604.9070207@att.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@freebsd.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jul 2014 12:57:31 -0000 Hi Daniele, Sorry it took so long to get back to you. I tried the .layer and .level sysctls I asked you to set, and they didn't result in any valuable output. I tried setting debug.acpi.level to ACPI_LV_VERBOSITY2 which prints every statement interpreted from the AML (presumably only the ACPI_BATTERY related calls), which /might/ be useful, but I wouldn't know what I was looking for. So if you want, you can try setting debug.acpi.layer to ACPI_BATTERY and debug.acpi.level to ACPI_LV_VERBOSITY2 and post the gobs of info from /var/log/messages somewhere, but dunno if that'd be useful. It might be more useful to look at your DSDT ASL, as recommended in the FreeBSD ACPI debugging handbook page: http://www.pl.freebsd.org/doc/handbook/acpi-debug.html Also I'm not a huge fan of throwing random fixes at a problem, but I do have a patch that enables (x86) FreeBSD machines to read/write ACPI CMOS regions. Some BIOSes rely on that functionality for stuff; it fixes most of my suspend/resume and poweroff problems. I can provide that for you to try at some point. Anthony On 07/12/2014 12:57, Daniele Mazzotti wrote: > Hi Guys, > > I have successfully compiled and installed the kernel with ACPI debug. > > @Anthony: my problem was definitely related to an outdated code base. > > So my question is now: "what should I do?". Is there any log or command I > should issue in order to have a better understanding of the problem? > > Cheers, > Daniele. > > > 2014-07-11 23:26 GMT+02:00 Daniele Mazzotti : > >> Hi Anthony, >> >> here it is: $FreeBSD: release/10.0.0/Makefile 255784 2013-09-22 07:30:17Z >> andrew $ >> >> I will try to check how it is possible to update the code base. >> Cheers, >> Daniele. >> >> >> 2014-07-11 20:03 GMT+02:00 Daniele Mazzotti : >> >> Hi Anthony, >>> Thanks for the good hint. I will be searching for the revision info as >>> soon as I will be back home (3 hours from now more or less). >>> >>> Cheers, >>> Daniele. >>> Il 11/lug/2014 19:59 "Anthony Jenkins" ha >>> scritto: >>> >>> Errrr... good question :-) I got mine from Subversion, so in '/usr/src' >>>> I can run 'svn info' and see the revision. >>>> >>>> Your revision might be at the top of /usr/src/Makefile - it is in mine: >>>> >>>> # >>>> # $FreeBSD: head/Makefile 268191 2014-07-02 22:34:06Z marcel $ >>>> # >>>> >>>> I'm only wondering because it might be a bad copy. Might try getting >>>> the sources again. >>>> >>>> Thanks, >>>> Anthony >>>> >>>> On 07/11/2014 13:44, Daniele Mazzotti wrote: >>>>> Actually I think I downloaded the source code back in May when I >>>> updated >>>>> from RC3 to the current version. >>>>> >>>>> How can I check the code revision on my machine? >>>>> >>>>> Cheers, >>>>> Daniele. >>>>> Il 11/lug/2014 19:37 "Anthony Jenkins" ha >>>>> scritto: >>>>> >>>>>> I just tried a build of GENERIC + 'options ACPI_DEBUG' and it seems >>>> to get >>>>>> past the error you're seeing. What revision of the source code are >>>> you >>>>>> using... or where'd you get it from? >>>>>> >>>>>> Anthony >>>>>> >>>>>> On 07/11/2014 13:12, Daniele Mazzotti wrote: >>>>>>> Hi guys, >>>>>>> >>>>>>> everything as planned! I am getting a compiling error :-). >>>>>>> >>>>>>> This is the way i managed to update the GENERIC kernel >>>>>>> >>>>>>> # Bus support. >>>>>>> device acpi >>>>>>> options ACPI_DEBUG # Debug support for ACPI >>>>>>> device pci >>>>>>> >>>>>>> and this is the result of >>>>>>> >>>>>>> # *make buildkernel KERNCONF=MYKERNEL* >>>>>>> >>>>>>> >>>>>>> ===> crypto (depend) >>>>>>> @ -> /usr/src/sys >>>>>>> awk -f @/tools/makeobjops.awk @/opencrypto/cryptodev_if.m -c >>>>>>> >>>>>>> make[4]: stopped in /usr/src/sys/modules/crypto >>>>>>> *** Error code 2 >>>>>>> >>>>>>> Stop. >>>>>>> make[3]: stopped in /usr/src/sys/modules >>>>>>> *** Error code 1 >>>>>>> >>>>>>> Stop. >>>>>>> make[2]: stopped in /usr/obj/usr/src/sys/GENERIC >>>>>>> *** Error code 1 >>>>>>> >>>>>>> Stop. >>>>>>> make[1]: stopped in /usr/src >>>>>>> *** Error code 1 >>>>>>> >>>>>>> Stop. >>>>>>> make: stopped in /usr/src >>>>>>> >>>>>>> I googled a bit, but I could not find any valuable help and actually >>>> I do >>>>>>> not know what could be wrong as the custom kernel is essentially the >>>>>>> GENERIC with just one line added. >>>>>>> Have you ever experienced such a problem? >>>>>>> >>>>>>> Cheers, >>>>>>> Daniele. >>>>>>> >>>>>>> >>>>>>> >>>>>>> 2014-07-11 18:10 GMT+02:00 Daniele Mazzotti : >>>>>>> >>>>>>>> Hi guys, >>>>>>>> >>>>>>>> thanks again for the support. >>>>>>>> >>>>>>>> @Takanori: here you go http://pastebin.com/F0a2mZP4 >>>>>>>> @Anthony: I will try to include the options in a custom kernel and >>>>>> compile >>>>>>>> it. As this is the first time after years I am compiling a custom >>>>>> kernel it >>>>>>>> will take a few time I guess. >>>>>>>> >>>>>>>> Just let me know if the output of the acpidump is of any help to >>>> you. >>>>>>>> Cheers, >>>>>>>> Daniele. >>>>>>>> >>>>>>>> >>>>>>>> 2014-07-11 13:35 GMT+02:00 Anthony Jenkins < >>>> Anthony.B.Jenkins@att.net>: >>>>>>>> Hi Daniele, >>>>>>>>> I was just going from acpi(4) man page; you'll likely have to >>>> build a >>>>>> new >>>>>>>>> kernel with 'options ACPI_DEBUG' added to your kernel config file, >>>> as I >>>>>>>>> don't know if it's even possible to turn on the logging I want at >>>>>> runtime. >>>>>>>>> [ajenkins@ajenkins-hplaptop /usr/home/ajenkins]$ grep -i acpi >>>>>>>>> /usr/src/sys/amd64/conf/MYKERNEL >>>>>>>>> device acpi >>>>>>>>> options ACPI_DEBUG >>>>>>>>> >>>>>>>>> I also have an 'options ACPI_DMAR' , but I don't recognize that >>>> and you >>>>>>>>> don't need that to debug your battery. >>>>>>>>> >>>>>>>>> Anthony >>>>>>>>> >>>>>>>>> On 07/11/2014 01:58, Daniele Mazzotti wrote: >>>>>>>>>> Hello Anthony, >>>>>>>>>> >>>>>>>>>> thanks for the quick reply! I tried what you suggested. >>>>>>>>>> >>>>>>>>>> loader.conf: >>>>>>>>>> >>>>>>>>>> # Module for Windows Partition & Linux Mount >>>>>>>>>> fuse_load="YES" >>>>>>>>>> autoboot_delay="5" >>>>>>>>>> #acpi_sony_load="YES" >>>>>>>>>> >>>>>>>>>> # Debugging Symbols for ACPI >>>>>>>>>> debug.acpi.layer="ACPI_BATTERY" >>>>>>>>>> debug.acpi.level="ACPI_LV_ALL_EXCEPTIONS" >>>>>>>>>> debug.acpi.enable_debug_objects="1" >>>>>>>>>> >>>>>>>>>> sysctl hw.acpi.battery: >>>>>>>>>> >>>>>>>>>> hw.acpi.battery.life: -1 >>>>>>>>>> hw.acpi.battery.time: -1 >>>>>>>>>> hw.acpi.battery.state: 7 >>>>>>>>>> hw.acpi.battery.units: 1 >>>>>>>>>> hw.acpi.battery.info_expire: 5 >>>>>>>>>> >>>>>>>>>> log/messages: >>>>>>>>>> >>>>>>>>>> cat /var/log/messages | grep acpi >>>>>>>>>> >>>>>>>>>> Jul 11 07:30:47 Von-Neumann kernel: acpi0: on motherboard >>>>>>>>>> Jul 11 07:30:47 Von-Neumann kernel: acpi_ec0: >>> Controller: >>>>>> GPE >>>>>>>>>> 0x17, ECDT> port 0x62,0x66 on acpi0 >>>>>>>>>> Jul 11 07:30:47 Von-Neumann kernel: cpu0: on acpi0 >>>>>>>>>> Jul 11 07:30:47 Von-Neumann kernel: cpu1: on acpi0 >>>>>>>>>> Jul 11 07:30:47 Von-Neumann kernel: cpu2: on acpi0 >>>>>>>>>> Jul 11 07:30:47 Von-Neumann kernel: cpu3: on acpi0 >>>>>>>>>> Jul 11 07:30:47 Von-Neumann kernel: hpet0: >>>>> Timer> >>>>>>>>>> iomem 0xfed00000-0xfed003ff on acpi0 >>>>>>>>>> Jul 11 07:30:47 Von-Neumann kernel: atrtc0: >>>> port >>>>>>>>>> 0x70-0x77 irq 8 on acpi0 >>>>>>>>>> Jul 11 07:30:47 Von-Neumann kernel: attimer0: port >>>>>>>>>> 0x40-0x43,0x50-0x53 irq 0 on acpi0 >>>>>>>>>> Jul 11 07:30:47 Von-Neumann kernel: acpi_timer0: <24-bit timer at >>>>>>>>>> 3.579545MHz> port 0x408-0x40b on acpi0 >>>>>>>>>> Jul 11 07:30:47 Von-Neumann kernel: pcib0: >>>> port >>>>>>>>>> 0xcf8-0xcff on acpi0 >>>>>>>>>> Jul 11 07:30:47 Von-Neumann kernel: battery0: >>>>>>>> Battery> >>>>>>>>>> on acpi0 >>>>>>>>>> Jul 11 07:30:47 Von-Neumann kernel: acpi_acad0: on >>>> acpi0 >>>>>>>>>> Jul 11 07:30:47 Von-Neumann kernel: acpi_lid0: >>>>>>>> Switch> >>>>>>>>>> on acpi0 >>>>>>>>>> Jul 11 07:30:47 Von-Neumann kernel: acpi_button0: >>>> on >>>>>>>>> acpi0 >>>>>>>>>> Jul 11 07:30:47 Von-Neumann kernel: acpi_tz0: on >>>> acpi0 >>>>>>>>>> Jul 11 07:30:47 Von-Neumann kernel: acpi_tz1: on >>>> acpi0 >>>>>>>>>> Jul 11 07:30:47 Von-Neumann kernel: atkbdc0: >>>>>>>> (i8042)> >>>>>>>>>> port 0x60,0x64 irq 1 on acpi0 >>>>>>>>>> Jul 11 07:30:47 Von-Neumann kernel: acpi_sony0: >>>>>>>> controller> >>>>>>>>>> on acpi0 >>>>>>>>>> Jul 11 07:30:47 Von-Neumann kernel: acpi_sony0: PID 0 >>>>>>>>>> Jul 11 07:37:54 Von-Neumann kernel: acpi0: on motherboard >>>>>>>>>> Jul 11 07:37:54 Von-Neumann kernel: acpi_ec0: >>> Controller: >>>>>> GPE >>>>>>>>>> 0x17, ECDT> port 0x62,0x66 on acpi0 >>>>>>>>>> Jul 11 07:37:54 Von-Neumann kernel: cpu0: on acpi0 >>>>>>>>>> Jul 11 07:37:54 Von-Neumann kernel: cpu1: on acpi0 >>>>>>>>>> Jul 11 07:37:54 Von-Neumann kernel: cpu2: on acpi0 >>>>>>>>>> Jul 11 07:37:54 Von-Neumann kernel: cpu3: on acpi0 >>>>>>>>>> Jul 11 07:37:54 Von-Neumann kernel: hpet0: >>>>> Timer> >>>>>>>>>> iomem 0xfed00000-0xfed003ff on acpi0 >>>>>>>>>> Jul 11 07:37:54 Von-Neumann kernel: atrtc0: >>>> port >>>>>>>>>> 0x70-0x77 irq 8 on acpi0 >>>>>>>>>> Jul 11 07:37:54 Von-Neumann kernel: attimer0: port >>>>>>>>>> 0x40-0x43,0x50-0x53 irq 0 on acpi0 >>>>>>>>>> Jul 11 07:37:54 Von-Neumann kernel: acpi_timer0: <24-bit timer at >>>>>>>>>> 3.579545MHz> port 0x408-0x40b on acpi0 >>>>>>>>>> Jul 11 07:37:54 Von-Neumann kernel: pcib0: >>>> port >>>>>>>>>> 0xcf8-0xcff on acpi0 >>>>>>>>>> Jul 11 07:37:54 Von-Neumann kernel: battery0: >>>>>>>> Battery> >>>>>>>>>> on acpi0 >>>>>>>>>> Jul 11 07:37:54 Von-Neumann kernel: acpi_acad0: on >>>> acpi0 >>>>>>>>>> Jul 11 07:37:54 Von-Neumann kernel: acpi_lid0: >>>>>>>> Switch> >>>>>>>>>> on acpi0 >>>>>>>>>> Jul 11 07:37:54 Von-Neumann kernel: acpi_button0: >>>> on >>>>>>>>> acpi0 >>>>>>>>>> Jul 11 07:37:54 Von-Neumann kernel: acpi_tz0: on >>>> acpi0 >>>>>>>>>> Jul 11 07:37:54 Von-Neumann kernel: acpi_tz1: on >>>> acpi0 >>>>>>>>>> Jul 11 07:37:54 Von-Neumann kernel: atkbdc0: >>>>>>>> (i8042)> >>>>>>>>>> port 0x60,0x64 irq 1 on acpi0 >>>>>>>>>> >>>>>>>>>> It seems to me the verbose debugging is either not enabled >>>> (perhaps I >>>>>>>>> made >>>>>>>>>> some mistakes with the loader.conf) or the debug is really >>>> enabled but >>>>>>>>>> there is no special output on the wrong log file. Actually I am a >>>> bit >>>>>>>>>> puzzled as I am not a real expert "admin". I only enjoy getting my >>>>>>>>> hands on >>>>>>>>>> Unix on my desktop PC just for fun. >>>>>>>>>> >>>>>>>>>> However, do you think either I missed something or made anything >>>>>> wrong? >>>>>>>>>> I look forward to receiving from you. >>>>>>>>>> >>>>>>>>>> Cheers, >>>>>>>>>> Daniele. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> 2014-07-10 23:27 GMT+02:00 Anthony Jenkins < >>>> Anthony.B.Jenkins@att.net >>>>>>> : >>>>>>>>>>> On 07/10/2014 16:49, Daniele Mazzotti wrote: >>>>>>>>>>>> Hello there, >>>>>>>>>>>> >>>>>>>>>>>> it is been a while since I finished installing Freebsd 10 on my >>>> Sony >>>>>>>>> Vaio >>>>>>>>>>>> PC and resolving (or at least I am trying to) one by one, all >>>> the >>>>>>>>>>> problems >>>>>>>>>>>> this hardware is giving me. Actually I cannot find a solution to >>>>>>>>>>> correctly >>>>>>>>>>>> display the battery level on my laptop. If I unplug my PC from >>>> the >>>>>>>>> power >>>>>>>>>>>> and type 'sysctl hw.acpi.battery' this is the result I get: >>>>>>>>>>>> >>>>>>>>>>>> hw.acpi.battery.life: -1 >>>>>>>>>>>> hw.acpi.battery.time: -1 >>>>>>>>>>>> hw.acpi.battery.state: 7 >>>>>>>>>>>> hw.acpi.battery.units: 1 >>>>>>>>>>>> hw.acpi.battery.info_expire: 5 >>>>>>>>>>>> >>>>>>>>>>>> Moreover the suspend mode is giving me some problems as well, >>>> but >>>>>> this >>>>>>>>>>> has >>>>>>>>>>>> definitely a lower priority. >>>>>>>>>>>> >>>>>>>>>>>> I either tried to search for a solution on the FreeBSD Handook >>>> with >>>>>> no >>>>>>>>>>>> luck, and google the problem a little bit, but I could not find >>>> any >>>>>>>>>>>> valuable help. I would be really interested to investigate the >>>>>> problem >>>>>>>>>>>> further. Is there anyone who can help me out with this and tell >>>> me >>>>>>>>> what >>>>>>>>>>>> pieces of information are needed to better understand the >>>> problem? >>>>>>>>>>> Try enabling the ACPI_BATTERY layer and ACPI_LV_ALL_EXCEPTIONS >>>> level >>>>>> in >>>>>>>>>>> /boot/loader.conf: >>>>>>>>>>> >>>>>>>>>>> debug.acpi.layer="ACPI_BATTERY" >>>>>>>>>>> debug.acpi.level="ACPI_LV_ALL_EXCEPTIONS" >>>>>>>>>>> debug.acpi.enable_debug_objects="1" # I assume this >>>> is how >>>>>>>>> you >>>>>>>>>>> turn on ACPI debugging without recompiling the kernel with >>>> 'options >>>>>>>>>>> ACPI_DEBUG' >>>>>>>>>>> >>>>>>>>>>> and running 'sysctl hw.acpi.battery' again. Post >>>> /var/log/messages >>>>>>>>> ACPI >>>>>>>>>>> messages about battery here. >>>>>>>>>>> >>>>>>>>>>> Anthony >>>>>>>>>>> >>>>>>>>>>>> Cheers, >>>>>>>>>>>> Daniele. >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> freebsd-acpi@freebsd.org mailing list >>>>>>>>>>>> http://lists.freebsd.org/mailman/listinfo/freebsd-acpi >>>>>>>>>>>> To unsubscribe, send any mail to " >>>>>>>>> freebsd-acpi-unsubscribe@freebsd.org" >>>>>>>>>> _______________________________________________ >>>>>>>>>> freebsd-acpi@freebsd.org mailing list >>>>>>>>>> http://lists.freebsd.org/mailman/listinfo/freebsd-acpi >>>>>>>>>> To unsubscribe, send any mail to " >>>>>> freebsd-acpi-unsubscribe@freebsd.org" >>>>>>> _______________________________________________ >>>>>>> freebsd-acpi@freebsd.org mailing list >>>>>>> http://lists.freebsd.org/mailman/listinfo/freebsd-acpi >>>>>>> To unsubscribe, send any mail to " >>>> freebsd-acpi-unsubscribe@freebsd.org" >>>>> _______________________________________________ >>>>> freebsd-acpi@freebsd.org mailing list >>>>> http://lists.freebsd.org/mailman/listinfo/freebsd-acpi >>>>> To unsubscribe, send any mail to "freebsd-acpi-unsubscribe@freebsd.org >>>> " >>>> > _______________________________________________ > freebsd-acpi@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-acpi > To unsubscribe, send any mail to "freebsd-acpi-unsubscribe@freebsd.org" > From owner-freebsd-acpi@FreeBSD.ORG Mon Jul 14 18:21:21 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 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B47124C8 for ; Mon, 14 Jul 2014 18:21:21 +0000 (UTC) Received: from mail-oa0-x22e.google.com (mail-oa0-x22e.google.com [IPv6:2607:f8b0:4003:c02::22e]) (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 74F1423FA for ; Mon, 14 Jul 2014 18:21:21 +0000 (UTC) Received: by mail-oa0-f46.google.com with SMTP id m1so4642073oag.19 for ; Mon, 14 Jul 2014 11:21:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=38IMppoxcGvE30CBhFJg9b22YWUFMBSQ2ttxjNT8JR0=; b=XnHMrAkWaZlog38ItdjROA9LtQEI3GRUoQp8LUS8Rbz52I3wfmIP64PgXFi5hgpXjH QkZ3hdBFVkvV4w02CJXrCIJycDpWIBQLVyqsIqKRSd4h0dLvN13a1VkkeATkOGusEJ58 35WaRaIR5izoIqP9AtT91MwNSc/EIEyPI5JxKzYu4B4LOh1JBx7Zz/5lyJbvomqdKYOp WVV1nseaoTXZh2lsbFgQDZwsbv8h+3Rcrl2tYVtrlTbH24YRPaT4vAoeOCCyf1LRwNJx BF0+wBgFRQrMIaVMCfNsBtDLihRYQmtIDjhpi1l1JD70fFG14SlffSDZDablM60fmTKZ LfBA== MIME-Version: 1.0 X-Received: by 10.182.106.137 with SMTP id gu9mr14028373obb.7.1405362080020; Mon, 14 Jul 2014 11:21:20 -0700 (PDT) Received: by 10.182.29.9 with HTTP; Mon, 14 Jul 2014 11:21:19 -0700 (PDT) In-Reply-To: <53C3D322.3080302@att.net> References: <53BF0546.70505@att.net> <53BFCBF4.2090104@att.net> <53C020CE.8010205@att.net> <53C02604.9070207@att.net> <53C3D322.3080302@att.net> Date: Mon, 14 Jul 2014 20:21:19 +0200 Message-ID: Subject: Re: ACPI support - Freebsd 10 on Sony Vaio VPCCA3C5E From: Daniele Mazzotti To: Anthony Jenkins Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18 Cc: freebsd-acpi@freebsd.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jul 2014 18:21:21 -0000 Hi Anthony, no problem for the "delay". I did not expect you to answer 5 seconds or 5 minutes after my email as I think we all have lives and jobs that keep us busy quite a lot. So, no problem at all! Regarding the issue we are discussing about, I think I already posted the output of "acpidump -dt" here http://pastebin.com/F0a2mZP4 and I also tried to understand a bit of the contents but I had no luck. Unfortunately I am not so much into this ACPI thing, but I am very interested to know how it works and fix (my.... maybe also someone's else) bug. I followed your recommendation and enabled the debug in the loader.conf. You can find my output here: http://pastebin.com/JXMjBhyx. Thanks again for the precious help. Cheers, Daniele. 2014-07-14 14:54 GMT+02:00 Anthony Jenkins : > Hi Daniele, > > Sorry it took so long to get back to you. I tried the .layer and .level > sysctls I asked you to set, and they didn't result in any valuable output. > I tried setting debug.acpi.level to ACPI_LV_VERBOSITY2 which prints every > statement interpreted from the AML (presumably only the ACPI_BATTERY > related calls), which /might/ be useful, but I wouldn't know what I was > looking for. So if you want, you can try setting debug.acpi.layer to > ACPI_BATTERY and debug.acpi.level to ACPI_LV_VERBOSITY2 and post the gobs > of info from /var/log/messages somewhere, but dunno if that'd be useful. > > It might be more useful to look at your DSDT ASL, as recommended in the > FreeBSD ACPI debugging handbook page: > > http://www.pl.freebsd.org/doc/handbook/acpi-debug.html > > Also I'm not a huge fan of throwing random fixes at a problem, but I do > have a patch that enables (x86) FreeBSD machines to read/write ACPI CMOS > regions. Some BIOSes rely on that functionality for stuff; it fixes most > of my suspend/resume and poweroff problems. I can provide that for you to > try at some point. > > Anthony > > On 07/12/2014 12:57, Daniele Mazzotti wrote: > > Hi Guys, > > > > I have successfully compiled and installed the kernel with ACPI debug. > > > > @Anthony: my problem was definitely related to an outdated code base. > > > > So my question is now: "what should I do?". Is there any log or command I > > should issue in order to have a better understanding of the problem? > > > > Cheers, > > Daniele. > > > > > > 2014-07-11 23:26 GMT+02:00 Daniele Mazzotti : > > > >> Hi Anthony, > >> > >> here it is: $FreeBSD: release/10.0.0/Makefile 255784 2013-09-22 > 07:30:17Z > >> andrew $ > >> > >> I will try to check how it is possible to update the code base. > >> Cheers, > >> Daniele. > >> > >> > >> 2014-07-11 20:03 GMT+02:00 Daniele Mazzotti : > >> > >> Hi Anthony, > >>> Thanks for the good hint. I will be searching for the revision info as > >>> soon as I will be back home (3 hours from now more or less). > >>> > >>> Cheers, > >>> Daniele. > >>> Il 11/lug/2014 19:59 "Anthony Jenkins" ha > >>> scritto: > >>> > >>> Errrr... good question :-) I got mine from Subversion, so in > '/usr/src' > >>>> I can run 'svn info' and see the revision. > >>>> > >>>> Your revision might be at the top of /usr/src/Makefile - it is in > mine: > >>>> > >>>> # > >>>> # $FreeBSD: head/Makefile 268191 2014-07-02 22:34:06Z marcel $ > >>>> # > >>>> > >>>> I'm only wondering because it might be a bad copy. Might try getting > >>>> the sources again. > >>>> > >>>> Thanks, > >>>> Anthony > >>>> > >>>> On 07/11/2014 13:44, Daniele Mazzotti wrote: > >>>>> Actually I think I downloaded the source code back in May when I > >>>> updated > >>>>> from RC3 to the current version. > >>>>> > >>>>> How can I check the code revision on my machine? > >>>>> > >>>>> Cheers, > >>>>> Daniele. > >>>>> Il 11/lug/2014 19:37 "Anthony Jenkins" > ha > >>>>> scritto: > >>>>> > >>>>>> I just tried a build of GENERIC + 'options ACPI_DEBUG' and it seems > >>>> to get > >>>>>> past the error you're seeing. What revision of the source code are > >>>> you > >>>>>> using... or where'd you get it from? > >>>>>> > >>>>>> Anthony > >>>>>> > >>>>>> On 07/11/2014 13:12, Daniele Mazzotti wrote: > >>>>>>> Hi guys, > >>>>>>> > >>>>>>> everything as planned! I am getting a compiling error :-). > >>>>>>> > >>>>>>> This is the way i managed to update the GENERIC kernel > >>>>>>> > >>>>>>> # Bus support. > >>>>>>> device acpi > >>>>>>> options ACPI_DEBUG # Debug support for ACPI > >>>>>>> device pci > >>>>>>> > >>>>>>> and this is the result of > >>>>>>> > >>>>>>> # *make buildkernel KERNCONF=MYKERNEL* > >>>>>>> > >>>>>>> > >>>>>>> ===> crypto (depend) > >>>>>>> @ -> /usr/src/sys > >>>>>>> awk -f @/tools/makeobjops.awk @/opencrypto/cryptodev_if.m -c > >>>>>>> > >>>>>>> make[4]: stopped in /usr/src/sys/modules/crypto > >>>>>>> *** Error code 2 > >>>>>>> > >>>>>>> Stop. > >>>>>>> make[3]: stopped in /usr/src/sys/modules > >>>>>>> *** Error code 1 > >>>>>>> > >>>>>>> Stop. > >>>>>>> make[2]: stopped in /usr/obj/usr/src/sys/GENERIC > >>>>>>> *** Error code 1 > >>>>>>> > >>>>>>> Stop. > >>>>>>> make[1]: stopped in /usr/src > >>>>>>> *** Error code 1 > >>>>>>> > >>>>>>> Stop. > >>>>>>> make: stopped in /usr/src > >>>>>>> > >>>>>>> I googled a bit, but I could not find any valuable help and > actually > >>>> I do > >>>>>>> not know what could be wrong as the custom kernel is essentially > the > >>>>>>> GENERIC with just one line added. > >>>>>>> Have you ever experienced such a problem? > >>>>>>> > >>>>>>> Cheers, > >>>>>>> Daniele. > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> 2014-07-11 18:10 GMT+02:00 Daniele Mazzotti : > >>>>>>> > >>>>>>>> Hi guys, > >>>>>>>> > >>>>>>>> thanks again for the support. > >>>>>>>> > >>>>>>>> @Takanori: here you go http://pastebin.com/F0a2mZP4 > >>>>>>>> @Anthony: I will try to include the options in a custom kernel and > >>>>>> compile > >>>>>>>> it. As this is the first time after years I am compiling a custom > >>>>>> kernel it > >>>>>>>> will take a few time I guess. > >>>>>>>> > >>>>>>>> Just let me know if the output of the acpidump is of any help to > >>>> you. > >>>>>>>> Cheers, > >>>>>>>> Daniele. > >>>>>>>> > >>>>>>>> > >>>>>>>> 2014-07-11 13:35 GMT+02:00 Anthony Jenkins < > >>>> Anthony.B.Jenkins@att.net>: > >>>>>>>> Hi Daniele, > >>>>>>>>> I was just going from acpi(4) man page; you'll likely have to > >>>> build a > >>>>>> new > >>>>>>>>> kernel with 'options ACPI_DEBUG' added to your kernel config > file, > >>>> as I > >>>>>>>>> don't know if it's even possible to turn on the logging I want at > >>>>>> runtime. > >>>>>>>>> [ajenkins@ajenkins-hplaptop /usr/home/ajenkins]$ grep -i acpi > >>>>>>>>> /usr/src/sys/amd64/conf/MYKERNEL > >>>>>>>>> device acpi > >>>>>>>>> options ACPI_DEBUG > >>>>>>>>> > >>>>>>>>> I also have an 'options ACPI_DMAR' , but I don't recognize that > >>>> and you > >>>>>>>>> don't need that to debug your battery. > >>>>>>>>> > >>>>>>>>> Anthony > >>>>>>>>> > >>>>>>>>> On 07/11/2014 01:58, Daniele Mazzotti wrote: > >>>>>>>>>> Hello Anthony, > >>>>>>>>>> > >>>>>>>>>> thanks for the quick reply! I tried what you suggested. > >>>>>>>>>> > >>>>>>>>>> loader.conf: > >>>>>>>>>> > >>>>>>>>>> # Module for Windows Partition & Linux Mount > >>>>>>>>>> fuse_load="YES" > >>>>>>>>>> autoboot_delay="5" > >>>>>>>>>> #acpi_sony_load="YES" > >>>>>>>>>> > >>>>>>>>>> # Debugging Symbols for ACPI > >>>>>>>>>> debug.acpi.layer="ACPI_BATTERY" > >>>>>>>>>> debug.acpi.level="ACPI_LV_ALL_EXCEPTIONS" > >>>>>>>>>> debug.acpi.enable_debug_objects="1" > >>>>>>>>>> > >>>>>>>>>> sysctl hw.acpi.battery: > >>>>>>>>>> > >>>>>>>>>> hw.acpi.battery.life: -1 > >>>>>>>>>> hw.acpi.battery.time: -1 > >>>>>>>>>> hw.acpi.battery.state: 7 > >>>>>>>>>> hw.acpi.battery.units: 1 > >>>>>>>>>> hw.acpi.battery.info_expire: 5 > >>>>>>>>>> > >>>>>>>>>> log/messages: > >>>>>>>>>> > >>>>>>>>>> cat /var/log/messages | grep acpi > >>>>>>>>>> > >>>>>>>>>> Jul 11 07:30:47 Von-Neumann kernel: acpi0: on motherboard > >>>>>>>>>> Jul 11 07:30:47 Von-Neumann kernel: acpi_ec0: >>>> Controller: > >>>>>> GPE > >>>>>>>>>> 0x17, ECDT> port 0x62,0x66 on acpi0 > >>>>>>>>>> Jul 11 07:30:47 Von-Neumann kernel: cpu0: on acpi0 > >>>>>>>>>> Jul 11 07:30:47 Von-Neumann kernel: cpu1: on acpi0 > >>>>>>>>>> Jul 11 07:30:47 Von-Neumann kernel: cpu2: on acpi0 > >>>>>>>>>> Jul 11 07:30:47 Von-Neumann kernel: cpu3: on acpi0 > >>>>>>>>>> Jul 11 07:30:47 Von-Neumann kernel: hpet0: >>>>>> Timer> > >>>>>>>>>> iomem 0xfed00000-0xfed003ff on acpi0 > >>>>>>>>>> Jul 11 07:30:47 Von-Neumann kernel: atrtc0: > >>>> port > >>>>>>>>>> 0x70-0x77 irq 8 on acpi0 > >>>>>>>>>> Jul 11 07:30:47 Von-Neumann kernel: attimer0: port > >>>>>>>>>> 0x40-0x43,0x50-0x53 irq 0 on acpi0 > >>>>>>>>>> Jul 11 07:30:47 Von-Neumann kernel: acpi_timer0: <24-bit timer > at > >>>>>>>>>> 3.579545MHz> port 0x408-0x40b on acpi0 > >>>>>>>>>> Jul 11 07:30:47 Von-Neumann kernel: pcib0: bridge> > >>>> port > >>>>>>>>>> 0xcf8-0xcff on acpi0 > >>>>>>>>>> Jul 11 07:30:47 Von-Neumann kernel: battery0: Method > >>>>>>>>> Battery> > >>>>>>>>>> on acpi0 > >>>>>>>>>> Jul 11 07:30:47 Von-Neumann kernel: acpi_acad0: on > >>>> acpi0 > >>>>>>>>>> Jul 11 07:30:47 Von-Neumann kernel: acpi_lid0: Lid > >>>>>>>>> Switch> > >>>>>>>>>> on acpi0 > >>>>>>>>>> Jul 11 07:30:47 Von-Neumann kernel: acpi_button0: > >>>> on > >>>>>>>>> acpi0 > >>>>>>>>>> Jul 11 07:30:47 Von-Neumann kernel: acpi_tz0: on > >>>> acpi0 > >>>>>>>>>> Jul 11 07:30:47 Von-Neumann kernel: acpi_tz1: on > >>>> acpi0 > >>>>>>>>>> Jul 11 07:30:47 Von-Neumann kernel: atkbdc0: controller > >>>>>>>>> (i8042)> > >>>>>>>>>> port 0x60,0x64 irq 1 on acpi0 > >>>>>>>>>> Jul 11 07:30:47 Von-Neumann kernel: acpi_sony0: >>>>>>>>> controller> > >>>>>>>>>> on acpi0 > >>>>>>>>>> Jul 11 07:30:47 Von-Neumann kernel: acpi_sony0: PID 0 > >>>>>>>>>> Jul 11 07:37:54 Von-Neumann kernel: acpi0: on motherboard > >>>>>>>>>> Jul 11 07:37:54 Von-Neumann kernel: acpi_ec0: >>>> Controller: > >>>>>> GPE > >>>>>>>>>> 0x17, ECDT> port 0x62,0x66 on acpi0 > >>>>>>>>>> Jul 11 07:37:54 Von-Neumann kernel: cpu0: on acpi0 > >>>>>>>>>> Jul 11 07:37:54 Von-Neumann kernel: cpu1: on acpi0 > >>>>>>>>>> Jul 11 07:37:54 Von-Neumann kernel: cpu2: on acpi0 > >>>>>>>>>> Jul 11 07:37:54 Von-Neumann kernel: cpu3: on acpi0 > >>>>>>>>>> Jul 11 07:37:54 Von-Neumann kernel: hpet0: >>>>>> Timer> > >>>>>>>>>> iomem 0xfed00000-0xfed003ff on acpi0 > >>>>>>>>>> Jul 11 07:37:54 Von-Neumann kernel: atrtc0: > >>>> port > >>>>>>>>>> 0x70-0x77 irq 8 on acpi0 > >>>>>>>>>> Jul 11 07:37:54 Von-Neumann kernel: attimer0: port > >>>>>>>>>> 0x40-0x43,0x50-0x53 irq 0 on acpi0 > >>>>>>>>>> Jul 11 07:37:54 Von-Neumann kernel: acpi_timer0: <24-bit timer > at > >>>>>>>>>> 3.579545MHz> port 0x408-0x40b on acpi0 > >>>>>>>>>> Jul 11 07:37:54 Von-Neumann kernel: pcib0: bridge> > >>>> port > >>>>>>>>>> 0xcf8-0xcff on acpi0 > >>>>>>>>>> Jul 11 07:37:54 Von-Neumann kernel: battery0: Method > >>>>>>>>> Battery> > >>>>>>>>>> on acpi0 > >>>>>>>>>> Jul 11 07:37:54 Von-Neumann kernel: acpi_acad0: on > >>>> acpi0 > >>>>>>>>>> Jul 11 07:37:54 Von-Neumann kernel: acpi_lid0: Lid > >>>>>>>>> Switch> > >>>>>>>>>> on acpi0 > >>>>>>>>>> Jul 11 07:37:54 Von-Neumann kernel: acpi_button0: > >>>> on > >>>>>>>>> acpi0 > >>>>>>>>>> Jul 11 07:37:54 Von-Neumann kernel: acpi_tz0: on > >>>> acpi0 > >>>>>>>>>> Jul 11 07:37:54 Von-Neumann kernel: acpi_tz1: on > >>>> acpi0 > >>>>>>>>>> Jul 11 07:37:54 Von-Neumann kernel: atkbdc0: controller > >>>>>>>>> (i8042)> > >>>>>>>>>> port 0x60,0x64 irq 1 on acpi0 > >>>>>>>>>> > >>>>>>>>>> It seems to me the verbose debugging is either not enabled > >>>> (perhaps I > >>>>>>>>> made > >>>>>>>>>> some mistakes with the loader.conf) or the debug is really > >>>> enabled but > >>>>>>>>>> there is no special output on the wrong log file. Actually I am > a > >>>> bit > >>>>>>>>>> puzzled as I am not a real expert "admin". I only enjoy getting > my > >>>>>>>>> hands on > >>>>>>>>>> Unix on my desktop PC just for fun. > >>>>>>>>>> > >>>>>>>>>> However, do you think either I missed something or made anything > >>>>>> wrong? > >>>>>>>>>> I look forward to receiving from you. > >>>>>>>>>> > >>>>>>>>>> Cheers, > >>>>>>>>>> Daniele. > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> 2014-07-10 23:27 GMT+02:00 Anthony Jenkins < > >>>> Anthony.B.Jenkins@att.net > >>>>>>> : > >>>>>>>>>>> On 07/10/2014 16:49, Daniele Mazzotti wrote: > >>>>>>>>>>>> Hello there, > >>>>>>>>>>>> > >>>>>>>>>>>> it is been a while since I finished installing Freebsd 10 on > my > >>>> Sony > >>>>>>>>> Vaio > >>>>>>>>>>>> PC and resolving (or at least I am trying to) one by one, all > >>>> the > >>>>>>>>>>> problems > >>>>>>>>>>>> this hardware is giving me. Actually I cannot find a solution > to > >>>>>>>>>>> correctly > >>>>>>>>>>>> display the battery level on my laptop. If I unplug my PC from > >>>> the > >>>>>>>>> power > >>>>>>>>>>>> and type 'sysctl hw.acpi.battery' this is the result I get: > >>>>>>>>>>>> > >>>>>>>>>>>> hw.acpi.battery.life: -1 > >>>>>>>>>>>> hw.acpi.battery.time: -1 > >>>>>>>>>>>> hw.acpi.battery.state: 7 > >>>>>>>>>>>> hw.acpi.battery.units: 1 > >>>>>>>>>>>> hw.acpi.battery.info_expire: 5 > >>>>>>>>>>>> > >>>>>>>>>>>> Moreover the suspend mode is giving me some problems as well, > >>>> but > >>>>>> this > >>>>>>>>>>> has > >>>>>>>>>>>> definitely a lower priority. > >>>>>>>>>>>> > >>>>>>>>>>>> I either tried to search for a solution on the FreeBSD Handook > >>>> with > >>>>>> no > >>>>>>>>>>>> luck, and google the problem a little bit, but I could not > find > >>>> any > >>>>>>>>>>>> valuable help. I would be really interested to investigate the > >>>>>> problem > >>>>>>>>>>>> further. Is there anyone who can help me out with this and > tell > >>>> me > >>>>>>>>> what > >>>>>>>>>>>> pieces of information are needed to better understand the > >>>> problem? > >>>>>>>>>>> Try enabling the ACPI_BATTERY layer and ACPI_LV_ALL_EXCEPTIONS > >>>> level > >>>>>> in > >>>>>>>>>>> /boot/loader.conf: > >>>>>>>>>>> > >>>>>>>>>>> debug.acpi.layer="ACPI_BATTERY" > >>>>>>>>>>> debug.acpi.level="ACPI_LV_ALL_EXCEPTIONS" > >>>>>>>>>>> debug.acpi.enable_debug_objects="1" # I assume this > >>>> is how > >>>>>>>>> you > >>>>>>>>>>> turn on ACPI debugging without recompiling the kernel with > >>>> 'options > >>>>>>>>>>> ACPI_DEBUG' > >>>>>>>>>>> > >>>>>>>>>>> and running 'sysctl hw.acpi.battery' again. Post > >>>> /var/log/messages > >>>>>>>>> ACPI > >>>>>>>>>>> messages about battery here. > >>>>>>>>>>> > >>>>>>>>>>> Anthony > >>>>>>>>>>> > >>>>>>>>>>>> Cheers, > >>>>>>>>>>>> Daniele. > >>>>>>>>>>>> _______________________________________________ > >>>>>>>>>>>> freebsd-acpi@freebsd.org mailing list > >>>>>>>>>>>> http://lists.freebsd.org/mailman/listinfo/freebsd-acpi > >>>>>>>>>>>> To unsubscribe, send any mail to " > >>>>>>>>> freebsd-acpi-unsubscribe@freebsd.org" > >>>>>>>>>> _______________________________________________ > >>>>>>>>>> freebsd-acpi@freebsd.org mailing list > >>>>>>>>>> http://lists.freebsd.org/mailman/listinfo/freebsd-acpi > >>>>>>>>>> To unsubscribe, send any mail to " > >>>>>> freebsd-acpi-unsubscribe@freebsd.org" > >>>>>>> _______________________________________________ > >>>>>>> freebsd-acpi@freebsd.org mailing list > >>>>>>> http://lists.freebsd.org/mailman/listinfo/freebsd-acpi > >>>>>>> To unsubscribe, send any mail to " > >>>> freebsd-acpi-unsubscribe@freebsd.org" > >>>>> _______________________________________________ > >>>>> freebsd-acpi@freebsd.org mailing list > >>>>> http://lists.freebsd.org/mailman/listinfo/freebsd-acpi > >>>>> To unsubscribe, send any mail to " > freebsd-acpi-unsubscribe@freebsd.org > >>>> " > >>>> > > _______________________________________________ > > freebsd-acpi@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-acpi > > To unsubscribe, send any mail to "freebsd-acpi-unsubscribe@freebsd.org" > > > > From owner-freebsd-acpi@FreeBSD.ORG Tue Jul 15 17:49:47 2014 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E4F9248A for ; Tue, 15 Jul 2014 17:49:47 +0000 (UTC) Received: from mail-oa0-x22c.google.com (mail-oa0-x22c.google.com [IPv6:2607:f8b0:4003:c02::22c]) (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 A2EE2213A for ; Tue, 15 Jul 2014 17:49:47 +0000 (UTC) Received: by mail-oa0-f44.google.com with SMTP id eb12so6263259oac.3 for ; Tue, 15 Jul 2014 10:49:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=OWj0alzuaZDC/6EI9oTqoNeOcZh7a8OdUA9zmrgqDPM=; b=sZAZBD7q/iKlQS1mu94+mTnE7dz2dhmhSQpMR+5WGIBJYF3ZnAjNyijBP6uv0JJv8M SvevFvWjOHfVjZgqa4b1/5U8YhuOgYU28sCIEdNwNfnZe52C1sG3RAtnQhLR3y1m19DI JByaRiSIAK2w7kjTcyVTRsGr2kb2lycqkXjvFvmQaOgBfifXC3R8KZ6Bwf49Gy+uahlm gkBYyjWYWIHvF6lNxadT3JFKeOVHAs9tJInFXYnUkehhR4TLgz/c0aEU9z5hSOWID6KH zVjGzczbjkLxqAHcq4qXwaudMZEjUy7DxgAZK8D4YOKUn9TrtmQxBRthfkApZ0nwtFBK Qy2Q== MIME-Version: 1.0 X-Received: by 10.182.98.194 with SMTP id ek2mr27150698obb.5.1405446586780; Tue, 15 Jul 2014 10:49:46 -0700 (PDT) Received: by 10.182.29.9 with HTTP; Tue, 15 Jul 2014 10:49:46 -0700 (PDT) In-Reply-To: References: <53BF0546.70505@att.net> <53BFCBF4.2090104@att.net> <53C020CE.8010205@att.net> <53C02604.9070207@att.net> <53C3D322.3080302@att.net> Date: Tue, 15 Jul 2014 19:49:46 +0200 Message-ID: Subject: Re: ACPI support - Freebsd 10 on Sony Vaio VPCCA3C5E From: Daniele Mazzotti To: Anthony Jenkins Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18 Cc: freebsd-acpi@freebsd.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jul 2014 17:49:48 -0000 Hello Anthony, I made a few step ahead (at least on my side) and tried to follow the recommendation from the handbook ( http://www.pl.freebsd.org/doc/handbook/acpi-debug.html). I was able to turn on the verbose boot and here you can find the output: http://pastebin.com/kkDAZEVb. At boot time I can see an error stating "battery0: battery initialization failed, giving up" which is thrown by the acpi_cmbat_init_battery within acpi_cmbat.c module. After six retries the error is printed out. Actually I am not able to figure out who is calling the method, but that is another story. I just noticed that I forgot to answer the part where you proposed me to "patch" my ACPI. Unfortunately I am running and AMD 64 architecture and I do not think this is fitting with what you already patched. By the way I am not sure that what I wrote is that relevant to you, but I just wanted to give you the feeling that I am not just passively requiring help. Cheers, Daniele. 2014-07-14 20:21 GMT+02:00 Daniele Mazzotti : > Hi Anthony, > > no problem for the "delay". I did not expect you to answer 5 seconds or 5 > minutes after my email as I think we all have lives and jobs that keep us > busy quite a lot. So, no problem at all! > > Regarding the issue we are discussing about, I think I already posted the > output of "acpidump -dt" here http://pastebin.com/F0a2mZP4 and I also > tried to understand a bit of the contents but I had no luck. Unfortunately > I am not so much into this ACPI thing, but I am very interested to know how > it works and fix (my.... maybe also someone's else) bug. > > I followed your recommendation and enabled the debug in the loader.conf. > You can find my output here: http://pastebin.com/JXMjBhyx. > Thanks again for the precious help. > > Cheers, > Daniele. > > > > > 2014-07-14 14:54 GMT+02:00 Anthony Jenkins : > > Hi Daniele, >> >> Sorry it took so long to get back to you. I tried the .layer and .level >> sysctls I asked you to set, and they didn't result in any valuable output. >> I tried setting debug.acpi.level to ACPI_LV_VERBOSITY2 which prints every >> statement interpreted from the AML (presumably only the ACPI_BATTERY >> related calls), which /might/ be useful, but I wouldn't know what I was >> looking for. So if you want, you can try setting debug.acpi.layer to >> ACPI_BATTERY and debug.acpi.level to ACPI_LV_VERBOSITY2 and post the gobs >> of info from /var/log/messages somewhere, but dunno if that'd be useful. >> >> It might be more useful to look at your DSDT ASL, as recommended in the >> FreeBSD ACPI debugging handbook page: >> >> http://www.pl.freebsd.org/doc/handbook/acpi-debug.html >> >> Also I'm not a huge fan of throwing random fixes at a problem, but I do >> have a patch that enables (x86) FreeBSD machines to read/write ACPI CMOS >> regions. Some BIOSes rely on that functionality for stuff; it fixes most >> of my suspend/resume and poweroff problems. I can provide that for you to >> try at some point. >> >> Anthony >> >> On 07/12/2014 12:57, Daniele Mazzotti wrote: >> > Hi Guys, >> > >> > I have successfully compiled and installed the kernel with ACPI debug. >> > >> > @Anthony: my problem was definitely related to an outdated code base. >> > >> > So my question is now: "what should I do?". Is there any log or command >> I >> > should issue in order to have a better understanding of the problem? >> > >> > Cheers, >> > Daniele. >> > >> > >> > 2014-07-11 23:26 GMT+02:00 Daniele Mazzotti : >> > >> >> Hi Anthony, >> >> >> >> here it is: $FreeBSD: release/10.0.0/Makefile 255784 2013-09-22 >> 07:30:17Z >> >> andrew $ >> >> >> >> I will try to check how it is possible to update the code base. >> >> Cheers, >> >> Daniele. >> >> >> >> >> >> 2014-07-11 20:03 GMT+02:00 Daniele Mazzotti : >> >> >> >> Hi Anthony, >> >>> Thanks for the good hint. I will be searching for the revision info as >> >>> soon as I will be back home (3 hours from now more or less). >> >>> >> >>> Cheers, >> >>> Daniele. >> >>> Il 11/lug/2014 19:59 "Anthony Jenkins" ha >> >>> scritto: >> >>> >> >>> Errrr... good question :-) I got mine from Subversion, so in >> '/usr/src' >> >>>> I can run 'svn info' and see the revision. >> >>>> >> >>>> Your revision might be at the top of /usr/src/Makefile - it is in >> mine: >> >>>> >> >>>> # >> >>>> # $FreeBSD: head/Makefile 268191 2014-07-02 22:34:06Z marcel $ >> >>>> # >> >>>> >> >>>> I'm only wondering because it might be a bad copy. Might try getting >> >>>> the sources again. >> >>>> >> >>>> Thanks, >> >>>> Anthony >> >>>> >> >>>> On 07/11/2014 13:44, Daniele Mazzotti wrote: >> >>>>> Actually I think I downloaded the source code back in May when I >> >>>> updated >> >>>>> from RC3 to the current version. >> >>>>> >> >>>>> How can I check the code revision on my machine? >> >>>>> >> >>>>> Cheers, >> >>>>> Daniele. >> >>>>> Il 11/lug/2014 19:37 "Anthony Jenkins" >> ha >> >>>>> scritto: >> >>>>> >> >>>>>> I just tried a build of GENERIC + 'options ACPI_DEBUG' and it seems >> >>>> to get >> >>>>>> past the error you're seeing. What revision of the source code are >> >>>> you >> >>>>>> using... or where'd you get it from? >> >>>>>> >> >>>>>> Anthony >> >>>>>> >> >>>>>> On 07/11/2014 13:12, Daniele Mazzotti wrote: >> >>>>>>> Hi guys, >> >>>>>>> >> >>>>>>> everything as planned! I am getting a compiling error :-). >> >>>>>>> >> >>>>>>> This is the way i managed to update the GENERIC kernel >> >>>>>>> >> >>>>>>> # Bus support. >> >>>>>>> device acpi >> >>>>>>> options ACPI_DEBUG # Debug support for ACPI >> >>>>>>> device pci >> >>>>>>> >> >>>>>>> and this is the result of >> >>>>>>> >> >>>>>>> # *make buildkernel KERNCONF=MYKERNEL* >> >>>>>>> >> >>>>>>> >> >>>>>>> ===> crypto (depend) >> >>>>>>> @ -> /usr/src/sys >> >>>>>>> awk -f @/tools/makeobjops.awk @/opencrypto/cryptodev_if.m -c >> >>>>>>> >> >>>>>>> make[4]: stopped in /usr/src/sys/modules/crypto >> >>>>>>> *** Error code 2 >> >>>>>>> >> >>>>>>> Stop. >> >>>>>>> make[3]: stopped in /usr/src/sys/modules >> >>>>>>> *** Error code 1 >> >>>>>>> >> >>>>>>> Stop. >> >>>>>>> make[2]: stopped in /usr/obj/usr/src/sys/GENERIC >> >>>>>>> *** Error code 1 >> >>>>>>> >> >>>>>>> Stop. >> >>>>>>> make[1]: stopped in /usr/src >> >>>>>>> *** Error code 1 >> >>>>>>> >> >>>>>>> Stop. >> >>>>>>> make: stopped in /usr/src >> >>>>>>> >> >>>>>>> I googled a bit, but I could not find any valuable help and >> actually >> >>>> I do >> >>>>>>> not know what could be wrong as the custom kernel is essentially >> the >> >>>>>>> GENERIC with just one line added. >> >>>>>>> Have you ever experienced such a problem? >> >>>>>>> >> >>>>>>> Cheers, >> >>>>>>> Daniele. >> >>>>>>> >> >>>>>>> >> >>>>>>> >> >>>>>>> 2014-07-11 18:10 GMT+02:00 Daniele Mazzotti : >> >>>>>>> >> >>>>>>>> Hi guys, >> >>>>>>>> >> >>>>>>>> thanks again for the support. >> >>>>>>>> >> >>>>>>>> @Takanori: here you go http://pastebin.com/F0a2mZP4 >> >>>>>>>> @Anthony: I will try to include the options in a custom kernel >> and >> >>>>>> compile >> >>>>>>>> it. As this is the first time after years I am compiling a custom >> >>>>>> kernel it >> >>>>>>>> will take a few time I guess. >> >>>>>>>> >> >>>>>>>> Just let me know if the output of the acpidump is of any help to >> >>>> you. >> >>>>>>>> Cheers, >> >>>>>>>> Daniele. >> >>>>>>>> >> >>>>>>>> >> >>>>>>>> 2014-07-11 13:35 GMT+02:00 Anthony Jenkins < >> >>>> Anthony.B.Jenkins@att.net>: >> >>>>>>>> Hi Daniele, >> >>>>>>>>> I was just going from acpi(4) man page; you'll likely have to >> >>>> build a >> >>>>>> new >> >>>>>>>>> kernel with 'options ACPI_DEBUG' added to your kernel config >> file, >> >>>> as I >> >>>>>>>>> don't know if it's even possible to turn on the logging I want >> at >> >>>>>> runtime. >> >>>>>>>>> [ajenkins@ajenkins-hplaptop /usr/home/ajenkins]$ grep -i acpi >> >>>>>>>>> /usr/src/sys/amd64/conf/MYKERNEL >> >>>>>>>>> device acpi >> >>>>>>>>> options ACPI_DEBUG >> >>>>>>>>> >> >>>>>>>>> I also have an 'options ACPI_DMAR' , but I don't recognize that >> >>>> and you >> >>>>>>>>> don't need that to debug your battery. >> >>>>>>>>> >> >>>>>>>>> Anthony >> >>>>>>>>> >> >>>>>>>>> On 07/11/2014 01:58, Daniele Mazzotti wrote: >> >>>>>>>>>> Hello Anthony, >> >>>>>>>>>> >> >>>>>>>>>> thanks for the quick reply! I tried what you suggested. >> >>>>>>>>>> >> >>>>>>>>>> loader.conf: >> >>>>>>>>>> >> >>>>>>>>>> # Module for Windows Partition & Linux Mount >> >>>>>>>>>> fuse_load="YES" >> >>>>>>>>>> autoboot_delay="5" >> >>>>>>>>>> #acpi_sony_load="YES" >> >>>>>>>>>> >> >>>>>>>>>> # Debugging Symbols for ACPI >> >>>>>>>>>> debug.acpi.layer="ACPI_BATTERY" >> >>>>>>>>>> debug.acpi.level="ACPI_LV_ALL_EXCEPTIONS" >> >>>>>>>>>> debug.acpi.enable_debug_objects="1" >> >>>>>>>>>> >> >>>>>>>>>> sysctl hw.acpi.battery: >> >>>>>>>>>> >> >>>>>>>>>> hw.acpi.battery.life: -1 >> >>>>>>>>>> hw.acpi.battery.time: -1 >> >>>>>>>>>> hw.acpi.battery.state: 7 >> >>>>>>>>>> hw.acpi.battery.units: 1 >> >>>>>>>>>> hw.acpi.battery.info_expire: 5 >> >>>>>>>>>> >> >>>>>>>>>> log/messages: >> >>>>>>>>>> >> >>>>>>>>>> cat /var/log/messages | grep acpi >> >>>>>>>>>> >> >>>>>>>>>> Jul 11 07:30:47 Von-Neumann kernel: acpi0: on >> motherboard >> >>>>>>>>>> Jul 11 07:30:47 Von-Neumann kernel: acpi_ec0: > >>>> Controller: >> >>>>>> GPE >> >>>>>>>>>> 0x17, ECDT> port 0x62,0x66 on acpi0 >> >>>>>>>>>> Jul 11 07:30:47 Von-Neumann kernel: cpu0: on acpi0 >> >>>>>>>>>> Jul 11 07:30:47 Von-Neumann kernel: cpu1: on acpi0 >> >>>>>>>>>> Jul 11 07:30:47 Von-Neumann kernel: cpu2: on acpi0 >> >>>>>>>>>> Jul 11 07:30:47 Von-Neumann kernel: cpu3: on acpi0 >> >>>>>>>>>> Jul 11 07:30:47 Von-Neumann kernel: hpet0: > Event >> >>>>>> Timer> >> >>>>>>>>>> iomem 0xfed00000-0xfed003ff on acpi0 >> >>>>>>>>>> Jul 11 07:30:47 Von-Neumann kernel: atrtc0: >> >>>> port >> >>>>>>>>>> 0x70-0x77 irq 8 on acpi0 >> >>>>>>>>>> Jul 11 07:30:47 Von-Neumann kernel: attimer0: port >> >>>>>>>>>> 0x40-0x43,0x50-0x53 irq 0 on acpi0 >> >>>>>>>>>> Jul 11 07:30:47 Von-Neumann kernel: acpi_timer0: <24-bit timer >> at >> >>>>>>>>>> 3.579545MHz> port 0x408-0x40b on acpi0 >> >>>>>>>>>> Jul 11 07:30:47 Von-Neumann kernel: pcib0: > bridge> >> >>>> port >> >>>>>>>>>> 0xcf8-0xcff on acpi0 >> >>>>>>>>>> Jul 11 07:30:47 Von-Neumann kernel: battery0: > Method >> >>>>>>>>> Battery> >> >>>>>>>>>> on acpi0 >> >>>>>>>>>> Jul 11 07:30:47 Von-Neumann kernel: acpi_acad0: on >> >>>> acpi0 >> >>>>>>>>>> Jul 11 07:30:47 Von-Neumann kernel: acpi_lid0: > Lid >> >>>>>>>>> Switch> >> >>>>>>>>>> on acpi0 >> >>>>>>>>>> Jul 11 07:30:47 Von-Neumann kernel: acpi_button0: > Button> >> >>>> on >> >>>>>>>>> acpi0 >> >>>>>>>>>> Jul 11 07:30:47 Von-Neumann kernel: acpi_tz0: on >> >>>> acpi0 >> >>>>>>>>>> Jul 11 07:30:47 Von-Neumann kernel: acpi_tz1: on >> >>>> acpi0 >> >>>>>>>>>> Jul 11 07:30:47 Von-Neumann kernel: atkbdc0: > controller >> >>>>>>>>> (i8042)> >> >>>>>>>>>> port 0x60,0x64 irq 1 on acpi0 >> >>>>>>>>>> Jul 11 07:30:47 Von-Neumann kernel: acpi_sony0: > >>>>>>>>> controller> >> >>>>>>>>>> on acpi0 >> >>>>>>>>>> Jul 11 07:30:47 Von-Neumann kernel: acpi_sony0: PID 0 >> >>>>>>>>>> Jul 11 07:37:54 Von-Neumann kernel: acpi0: on >> motherboard >> >>>>>>>>>> Jul 11 07:37:54 Von-Neumann kernel: acpi_ec0: > >>>> Controller: >> >>>>>> GPE >> >>>>>>>>>> 0x17, ECDT> port 0x62,0x66 on acpi0 >> >>>>>>>>>> Jul 11 07:37:54 Von-Neumann kernel: cpu0: on acpi0 >> >>>>>>>>>> Jul 11 07:37:54 Von-Neumann kernel: cpu1: on acpi0 >> >>>>>>>>>> Jul 11 07:37:54 Von-Neumann kernel: cpu2: on acpi0 >> >>>>>>>>>> Jul 11 07:37:54 Von-Neumann kernel: cpu3: on acpi0 >> >>>>>>>>>> Jul 11 07:37:54 Von-Neumann kernel: hpet0: > Event >> >>>>>> Timer> >> >>>>>>>>>> iomem 0xfed00000-0xfed003ff on acpi0 >> >>>>>>>>>> Jul 11 07:37:54 Von-Neumann kernel: atrtc0: >> >>>> port >> >>>>>>>>>> 0x70-0x77 irq 8 on acpi0 >> >>>>>>>>>> Jul 11 07:37:54 Von-Neumann kernel: attimer0: port >> >>>>>>>>>> 0x40-0x43,0x50-0x53 irq 0 on acpi0 >> >>>>>>>>>> Jul 11 07:37:54 Von-Neumann kernel: acpi_timer0: <24-bit timer >> at >> >>>>>>>>>> 3.579545MHz> port 0x408-0x40b on acpi0 >> >>>>>>>>>> Jul 11 07:37:54 Von-Neumann kernel: pcib0: > bridge> >> >>>> port >> >>>>>>>>>> 0xcf8-0xcff on acpi0 >> >>>>>>>>>> Jul 11 07:37:54 Von-Neumann kernel: battery0: > Method >> >>>>>>>>> Battery> >> >>>>>>>>>> on acpi0 >> >>>>>>>>>> Jul 11 07:37:54 Von-Neumann kernel: acpi_acad0: on >> >>>> acpi0 >> >>>>>>>>>> Jul 11 07:37:54 Von-Neumann kernel: acpi_lid0: > Lid >> >>>>>>>>> Switch> >> >>>>>>>>>> on acpi0 >> >>>>>>>>>> Jul 11 07:37:54 Von-Neumann kernel: acpi_button0: > Button> >> >>>> on >> >>>>>>>>> acpi0 >> >>>>>>>>>> Jul 11 07:37:54 Von-Neumann kernel: acpi_tz0: on >> >>>> acpi0 >> >>>>>>>>>> Jul 11 07:37:54 Von-Neumann kernel: acpi_tz1: on >> >>>> acpi0 >> >>>>>>>>>> Jul 11 07:37:54 Von-Neumann kernel: atkbdc0: > controller >> >>>>>>>>> (i8042)> >> >>>>>>>>>> port 0x60,0x64 irq 1 on acpi0 >> >>>>>>>>>> >> >>>>>>>>>> It seems to me the verbose debugging is either not enabled >> >>>> (perhaps I >> >>>>>>>>> made >> >>>>>>>>>> some mistakes with the loader.conf) or the debug is really >> >>>> enabled but >> >>>>>>>>>> there is no special output on the wrong log file. Actually I >> am a >> >>>> bit >> >>>>>>>>>> puzzled as I am not a real expert "admin". I only enjoy >> getting my >> >>>>>>>>> hands on >> >>>>>>>>>> Unix on my desktop PC just for fun. >> >>>>>>>>>> >> >>>>>>>>>> However, do you think either I missed something or made >> anything >> >>>>>> wrong? >> >>>>>>>>>> I look forward to receiving from you. >> >>>>>>>>>> >> >>>>>>>>>> Cheers, >> >>>>>>>>>> Daniele. >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>> 2014-07-10 23:27 GMT+02:00 Anthony Jenkins < >> >>>> Anthony.B.Jenkins@att.net >> >>>>>>> : >> >>>>>>>>>>> On 07/10/2014 16:49, Daniele Mazzotti wrote: >> >>>>>>>>>>>> Hello there, >> >>>>>>>>>>>> >> >>>>>>>>>>>> it is been a while since I finished installing Freebsd 10 on >> my >> >>>> Sony >> >>>>>>>>> Vaio >> >>>>>>>>>>>> PC and resolving (or at least I am trying to) one by one, all >> >>>> the >> >>>>>>>>>>> problems >> >>>>>>>>>>>> this hardware is giving me. Actually I cannot find a >> solution to >> >>>>>>>>>>> correctly >> >>>>>>>>>>>> display the battery level on my laptop. If I unplug my PC >> from >> >>>> the >> >>>>>>>>> power >> >>>>>>>>>>>> and type 'sysctl hw.acpi.battery' this is the result I get: >> >>>>>>>>>>>> >> >>>>>>>>>>>> hw.acpi.battery.life: -1 >> >>>>>>>>>>>> hw.acpi.battery.time: -1 >> >>>>>>>>>>>> hw.acpi.battery.state: 7 >> >>>>>>>>>>>> hw.acpi.battery.units: 1 >> >>>>>>>>>>>> hw.acpi.battery.info_expire: 5 >> >>>>>>>>>>>> >> >>>>>>>>>>>> Moreover the suspend mode is giving me some problems as well, >> >>>> but >> >>>>>> this >> >>>>>>>>>>> has >> >>>>>>>>>>>> definitely a lower priority. >> >>>>>>>>>>>> >> >>>>>>>>>>>> I either tried to search for a solution on the FreeBSD >> Handook >> >>>> with >> >>>>>> no >> >>>>>>>>>>>> luck, and google the problem a little bit, but I could not >> find >> >>>> any >> >>>>>>>>>>>> valuable help. I would be really interested to investigate >> the >> >>>>>> problem >> >>>>>>>>>>>> further. Is there anyone who can help me out with this and >> tell >> >>>> me >> >>>>>>>>> what >> >>>>>>>>>>>> pieces of information are needed to better understand the >> >>>> problem? >> >>>>>>>>>>> Try enabling the ACPI_BATTERY layer and ACPI_LV_ALL_EXCEPTIONS >> >>>> level >> >>>>>> in >> >>>>>>>>>>> /boot/loader.conf: >> >>>>>>>>>>> >> >>>>>>>>>>> debug.acpi.layer="ACPI_BATTERY" >> >>>>>>>>>>> debug.acpi.level="ACPI_LV_ALL_EXCEPTIONS" >> >>>>>>>>>>> debug.acpi.enable_debug_objects="1" # I assume this >> >>>> is how >> >>>>>>>>> you >> >>>>>>>>>>> turn on ACPI debugging without recompiling the kernel with >> >>>> 'options >> >>>>>>>>>>> ACPI_DEBUG' >> >>>>>>>>>>> >> >>>>>>>>>>> and running 'sysctl hw.acpi.battery' again. Post >> >>>> /var/log/messages >> >>>>>>>>> ACPI >> >>>>>>>>>>> messages about battery here. >> >>>>>>>>>>> >> >>>>>>>>>>> Anthony >> >>>>>>>>>>> >> >>>>>>>>>>>> Cheers, >> >>>>>>>>>>>> Daniele. >> >>>>>>>>>>>> _______________________________________________ >> >>>>>>>>>>>> freebsd-acpi@freebsd.org mailing list >> >>>>>>>>>>>> http://lists.freebsd.org/mailman/listinfo/freebsd-acpi >> >>>>>>>>>>>> To unsubscribe, send any mail to " >> >>>>>>>>> freebsd-acpi-unsubscribe@freebsd.org" >> >>>>>>>>>> _______________________________________________ >> >>>>>>>>>> freebsd-acpi@freebsd.org mailing list >> >>>>>>>>>> http://lists.freebsd.org/mailman/listinfo/freebsd-acpi >> >>>>>>>>>> To unsubscribe, send any mail to " >> >>>>>> freebsd-acpi-unsubscribe@freebsd.org" >> >>>>>>> _______________________________________________ >> >>>>>>> freebsd-acpi@freebsd.org mailing list >> >>>>>>> http://lists.freebsd.org/mailman/listinfo/freebsd-acpi >> >>>>>>> To unsubscribe, send any mail to " >> >>>> freebsd-acpi-unsubscribe@freebsd.org" >> >>>>> _______________________________________________ >> >>>>> freebsd-acpi@freebsd.org mailing list >> >>>>> http://lists.freebsd.org/mailman/listinfo/freebsd-acpi >> >>>>> To unsubscribe, send any mail to " >> freebsd-acpi-unsubscribe@freebsd.org >> >>>> " >> >>>> >> > _______________________________________________ >> > freebsd-acpi@freebsd.org mailing list >> > http://lists.freebsd.org/mailman/listinfo/freebsd-acpi >> > To unsubscribe, send any mail to "freebsd-acpi-unsubscribe@freebsd.org" >> > >> >> > From owner-freebsd-acpi@FreeBSD.ORG Tue Jul 15 18:22:30 2014 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 65AAD3D5 for ; Tue, 15 Jul 2014 18:22:30 +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 B1E0824D9 for ; Tue, 15 Jul 2014 18:22:28 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id s6FIMLFt086874; Wed, 16 Jul 2014 04:22:21 +1000 (EST) (envelope-from smithi@nimnet.asn.au) Date: Wed, 16 Jul 2014 04:22:21 +1000 (EST) From: Ian Smith To: Daniele Mazzotti Subject: Re: ACPI support - Freebsd 10 on Sony Vaio VPCCA3C5E In-Reply-To: Message-ID: <20140716040719.Y50382@sola.nimnet.asn.au> References: <53BF0546.70505@att.net> <53BFCBF4.2090104@att.net> <53C020CE.8010205@att.net> <53C02604.9070207@att.net> <53C3D322.3080302@att.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: Anthony Jenkins , freebsd-acpi@freebsd.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jul 2014 18:22:30 -0000 On Tue, 15 Jul 2014 19:49:46 +0200, Daniele Mazzotti wrote: > I made a few step ahead (at least on my side) and tried to follow the > recommendation from the handbook ( > http://www.pl.freebsd.org/doc/handbook/acpi-debug.html). > > I was able to turn on the verbose boot and here you can find the output: > http://pastebin.com/kkDAZEVb. At boot time I can see an error stating > "battery0: battery initialization failed, giving up" which is thrown by the > acpi_cmbat_init_battery within acpi_cmbat.c module. After six retries the > error is printed out. Actually I am not able to figure out who is calling > the method, but that is another story. Actually you'll see those messages on a 'normal' verbose boot, ie there's nothing extra logged of note regarding battery issues. If you are up for lots more output on one boot at least, perhaps try what acpi(4) suggests: debug.acpi.layer="ACPI_ALL_COMPONENTS ACPI_ALL_DRIVERS" debug.acpi.level="ACPI_LV_ALL_EXCEPTIONS" which is less deep, but wider :) Communications with batteries often, likely usually, is moderated by the embedded controler (ACPI_EC) and it wouldn't hurt to report any exceptions from other subsystems also. If that yields nothing useful you could increase the level .. Sorry, I can't read messages backwards very well, so I'll drop the tail. cheers, Ian From owner-freebsd-acpi@FreeBSD.ORG Tue Jul 15 18:47:47 2014 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3550BE53 for ; Tue, 15 Jul 2014 18:47:47 +0000 (UTC) Received: from mail-ob0-x22b.google.com (mail-ob0-x22b.google.com [IPv6:2607:f8b0:4003:c01::22b]) (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 E8B812708 for ; Tue, 15 Jul 2014 18:47:46 +0000 (UTC) Received: by mail-ob0-f171.google.com with SMTP id wm4so6211642obc.30 for ; Tue, 15 Jul 2014 11:47:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=/l+Me6rf2Y6BSL8LP08CvsPRN8EkeC0W3Bvo9RcrbKI=; b=nOvhZhd0cDT70HA/oud2eHXTUuu7Dgmhhcml6MVjcpM9G7RwzGYAERYI0Ez8empzyU Czy/4HC0kweQ1iqzNjP/4jyWpCoJ/ud5Fk7anhBpOrHhwZHAzGyu1vKIrKBs3DOByHeb hklsn/KNgCbYirgd4PbSZL6vkskxsY5q8F04lmJKV6oVSgORIlo1pOA3QWCvCi2zp523 ZqAcfzLbBQ60WoCo9paPQWXnSAXmXFy42JsP861Cf+UeXFs8M8A9Y4aJSTwgc46/bbw6 DFFnUN9XlgzKH0UKQEfInrnkD8E7MEgGrD8ODmHS5R08J0J1DGtBQ9zLi88olt+8534V 8o0w== MIME-Version: 1.0 X-Received: by 10.60.16.2 with SMTP id b2mr27886480oed.57.1405450064940; Tue, 15 Jul 2014 11:47:44 -0700 (PDT) Received: by 10.182.29.9 with HTTP; Tue, 15 Jul 2014 11:47:44 -0700 (PDT) In-Reply-To: <20140716040719.Y50382@sola.nimnet.asn.au> References: <53BF0546.70505@att.net> <53BFCBF4.2090104@att.net> <53C020CE.8010205@att.net> <53C02604.9070207@att.net> <53C3D322.3080302@att.net> <20140716040719.Y50382@sola.nimnet.asn.au> Date: Tue, 15 Jul 2014 20:47:44 +0200 Message-ID: Subject: Re: ACPI support - Freebsd 10 on Sony Vaio VPCCA3C5E From: Daniele Mazzotti To: Ian Smith Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18 Cc: Anthony Jenkins , freebsd-acpi@freebsd.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jul 2014 18:47:47 -0000 Hi Ian, I have just rebooted the PC after turning the deep debug on. Here is the output: http://pastebin.com/H61zJhqc. It is very likely that the dmesg has been cut due to the large amount of output. Is there any way to have it all? Cheers, Daniele. 2014-07-15 20:22 GMT+02:00 Ian Smith : > On Tue, 15 Jul 2014 19:49:46 +0200, Daniele Mazzotti wrote: > > > I made a few step ahead (at least on my side) and tried to follow the > > recommendation from the handbook ( > > http://www.pl.freebsd.org/doc/handbook/acpi-debug.html). > > > > I was able to turn on the verbose boot and here you can find the output: > > http://pastebin.com/kkDAZEVb. At boot time I can see an error stating > > "battery0: battery initialization failed, giving up" which is thrown by > the > > acpi_cmbat_init_battery within acpi_cmbat.c module. After six retries > the > > error is printed out. Actually I am not able to figure out who is > calling > > the method, but that is another story. > > Actually you'll see those messages on a 'normal' verbose boot, ie > there's nothing extra logged of note regarding battery issues. If you > are up for lots more output on one boot at least, perhaps try what > acpi(4) suggests: > > debug.acpi.layer="ACPI_ALL_COMPONENTS ACPI_ALL_DRIVERS" > debug.acpi.level="ACPI_LV_ALL_EXCEPTIONS" > > which is less deep, but wider :) Communications with batteries often, > likely usually, is moderated by the embedded controler (ACPI_EC) and it > wouldn't hurt to report any exceptions from other subsystems also. If > that yields nothing useful you could increase the level .. > > Sorry, I can't read messages backwards very well, so I'll drop the tail. > > cheers, Ian > From owner-freebsd-acpi@FreeBSD.ORG Tue Jul 15 19:40:58 2014 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 90F1412D for ; Tue, 15 Jul 2014 19:40:58 +0000 (UTC) Received: from nm2.access.bullet.mail.gq1.yahoo.com (nm2.access.bullet.mail.gq1.yahoo.com [216.39.62.33]) (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 4553D2C77 for ; Tue, 15 Jul 2014 19:40:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s2048; t=1405453156; bh=z6GVkGMYf3XDoLpV9pTn1uggVmGV8V3/o0M3Hzuf1is=; h=Received:Received:Received:DKIM-Signature:X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type; b=IsmYpg0uYQIUe+FGkxNiKmu95cCIS8jOv1qUUaIAtKbOFk/Cr21x/IVPflXFTqm4bBjquW+ZaNcSX8qt/UIxtJOARAdObiUVAqpa8g6OyRUxT6zXxhcxpyBaZmWYVV8HksNldGiGo76HCjhfT1DoZ+K80nluvrI+DZHdhbPrxTAUIe07dUewWYHIUUbh6tg/g5p7B0bluFlmvl57Z1K/56ktFkK7pvccnRYqBdQHkD7oPW0vhsPLj7xmXOK5VCZ0NWSyfylSHBVLPkqxhuPnM5yD97KURZ7kyj5WFb1S/NvT/XY4gFYmoAPSKaI5aOF/nxCih+j2rqUp4bn24124UQ== DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s2048; d=att.net; b=JmRWFbwwC8scO12PRzhWJ2fTWNUSnAS3pJWUIxwziuO0+gJwCnbHdzUcZ8eAQ4wOwJwVWGYUlgqZSGU/khUC8QLpFBvDYvT9bFCeW8aXHiXbqi4WUleF6uUBCm41USnOlEPS/Vi1yOne4FMp6T+3GESHLCxTNtClzuthAAy3U6xxc3QwcFOhVFxg64vEdAjKvRLSiXvoQQzPUIRqSFGMTNI0xbDQSF0i9sIhXPCVGO0JXadDJk7m7D2ECqL1+R7hm+P6CF1QtgIkkqiFwQKJdVaPHtieFzlUKystl0M64VoBUKSiAL+f62GWMGmXE6Thi00K1kfbM/J63mk7VZWULA==; Received: from [216.39.60.170] by nm2.access.bullet.mail.gq1.yahoo.com with NNFMP; 15 Jul 2014 19:39:16 -0000 Received: from [98.138.226.240] by tm6.access.bullet.mail.gq1.yahoo.com with NNFMP; 15 Jul 2014 19:39:16 -0000 Received: from [127.0.0.1] by smtp111.sbc.mail.ne1.yahoo.com with NNFMP; 15 Jul 2014 19:39:16 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1405453156; bh=z6GVkGMYf3XDoLpV9pTn1uggVmGV8V3/o0M3Hzuf1is=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type; b=YMWDlHv8zVN8IGH3AZPg+HkelJIPcG9fQPZFV+OwStGRTtHNGL4ubEG/lKOWLoBzqd0mYBZOnh8A9734zDy3nLrkhAWcfaYBy6V13v3MeVd5XcFCjV4RiMAcMGrFsdbxTJfSDR5e4k5nCHiD+UtPioNAqvou0/tE4Ez+J1K4FVY= X-Yahoo-Newman-Id: 216656.83282.bm@smtp111.sbc.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: YFLVv.cVM1ngvpjys8bV9_ajm.a5RMcp7eyLd4_nDJw5tLB tq.p6ZRwsI3WJteuiSOefgD9Ns1nZDJqyCYv7lXxN6AJeKc.Ce0oNLmYw2EJ 1aOYpVnOg4zxtFioRqVPmZOscGVFAuD1tGqkRHA_9uorVB0sjmIuwNOdTZMR EjU_byzRW9EK28O1Omh6zeaGqsZ2KTaQLRV1mu9UufU8YHhjri9_CyOZCf4m atqCwHsNRO6I6tTfPI5NK0TMGJJy9gAT3iUAIx5gf6QcWbp4AtFDoi_fnpYa OOXOv4pB_US1DSwFbuggotDTGcKpsQDtU6aFfnTIH8HMX07XeVQYTizg2dY5 aRVn5Y4Gwj5i25Fmd41Fvu9nrsoCyNS07GWZhTO6S2V9WiHUXg35JXTnQHaA oULQg4qBwrkZhuKOgCNCD9n7eEMVzER48f4IHhDBYG3Ej.rRRoYatjpnPlQh ckyErYHj6rYTkv6OrN0p59MY7f9eGhChHPqRgOIoP7FuR7a_F1G08MKxtexv VW7lYl75Ty5JdViNhiR0ShMUdBXrS12.tOkGD9befBEXONHgt4R2ZeUwE7qU NssgJ6.nf59x5ask0oEbjaYPG.PZOnxvGBPrl4sNgp8g2XjJeh4kc8zg45g- - X-Yahoo-SMTP: OKD1keCswBBTAmAF1s00hLyKW3wE3YfSK0Eazl6b4VZG4LTqJxg- Message-ID: <53C58363.6050809@att.net> Date: Tue, 15 Jul 2014 15:39:15 -0400 From: Anthony Jenkins User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Daniele Mazzotti Subject: Re: ACPI support - Freebsd 10 on Sony Vaio VPCCA3C5E References: <53BF0546.70505@att.net> <53BFCBF4.2090104@att.net> <53C020CE.8010205@att.net> <53C02604.9070207@att.net> <53C3D322.3080302@att.net> In-Reply-To: Content-Type: multipart/mixed; boundary="------------050503070806000304030204" Cc: freebsd-acpi@freebsd.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jul 2014 19:40:58 -0000 This is a multi-part message in MIME format. --------------050503070806000304030204 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 07/15/2014 13:49, Daniele Mazzotti wrote: > Hello Anthony, > I just noticed that I forgot to answer the part where you proposed me to > "patch" my ACPI. Unfortunately I am running and AMD 64 architecture and I > do not think this is fitting with what you already patched. x86-based architectures use my patch, including amd64. It patches the sys/x86/isa/atrtc.c driver. I'll attach it... might fix some stuff. I've been running it on my laptop for several weeks and posted it to this newsgroup some time ago, so it should be safe at least. # cd /usr/src && patch < path/to/atrtc.c.patch > By the way I am not sure that what I wrote is that relevant to you, but I > just wanted to give you the feeling that I am not just passively requiring > help. Not at all... I'm scared I can't really help you with your problem. At least it helps me learn ACPI. Anthony P.S. I alternate between top-posting and bottom-posting, depending on the audience...I know I've switched at least twice in this thread. > Cheers, > Daniele. > > > 2014-07-14 20:21 GMT+02:00 Daniele Mazzotti : > >> Hi Anthony, >> >> no problem for the "delay". I did not expect you to answer 5 seconds or 5 >> minutes after my email as I think we all have lives and jobs that keep us >> busy quite a lot. So, no problem at all! >> >> Regarding the issue we are discussing about, I think I already posted the >> output of "acpidump -dt" here http://pastebin.com/F0a2mZP4 and I also >> tried to understand a bit of the contents but I had no luck. Unfortunately >> I am not so much into this ACPI thing, but I am very interested to know how >> it works and fix (my.... maybe also someone's else) bug. >> >> I followed your recommendation and enabled the debug in the loader.conf. >> You can find my output here: http://pastebin.com/JXMjBhyx. >> Thanks again for the precious help. >> >> Cheers, >> Daniele. >> --------------050503070806000304030204 Content-Type: text/x-patch; name="atrtc.c.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="atrtc.c.patch" Index: sys/x86/isa/atrtc.c =================================================================== --- sys/x86/isa/atrtc.c (revision 267519) +++ sys/x86/isa/atrtc.c (working copy) @@ -31,6 +31,7 @@ __FBSDID("$FreeBSD$"); #include "opt_isa.h" +#include "opt_acpi.h" #include #include @@ -53,6 +54,10 @@ #include #include "clock_if.h" +#include +#include +#include + #define RTC_LOCK do { if (!kdb_active) mtx_lock_spin(&clock_lock); } while (0) #define RTC_UNLOCK do { if (!kdb_active) mtx_unlock_spin(&clock_lock); } while (0) @@ -161,8 +166,33 @@ struct resource *intr_res; void *intr_handler; struct eventtimer et; + ACPI_HANDLE acpi_handle; /* Handle of the PNP0B00 node */ }; +static ACPI_STATUS +acpi_rtc_cmos_handler(UINT32 function, ACPI_PHYSICAL_ADDRESS address, UINT32 width, + UINT64 *value, void *context, void *region_context) +{ + struct atrtc_softc *sc; + + sc = (struct atrtc_softc *)context; + if (!value || !sc) + return AE_BAD_PARAMETER; + if (width != 8 || address >= 64U) + return AE_BAD_PARAMETER; + switch (function) { + case ACPI_READ: + *((UINT8 *)value) = rtcin((int)address); + break; + case ACPI_WRITE: + writertc((int)address, *((UINT8 *)value)); + break; + default: + return AE_BAD_PARAMETER; + } + return AE_OK; +} + static int rtc_start(struct eventtimer *et, sbintime_t first, sbintime_t period) { @@ -245,10 +275,17 @@ int i; sc = device_get_softc(dev); + sc->acpi_handle = acpi_get_handle(dev); sc->port_res = bus_alloc_resource(dev, SYS_RES_IOPORT, &sc->port_rid, IO_RTC, IO_RTC + 1, 2, RF_ACTIVE); if (sc->port_res == NULL) device_printf(dev, "Warning: Couldn't map I/O.\n"); + if (ACPI_FAILURE(AcpiInstallAddressSpaceHandler(sc->acpi_handle, + ACPI_ADR_SPACE_CMOS, acpi_rtc_cmos_handler, NULL, sc))) + { + device_printf(dev, "Error registering ACPI CMOS address space handler.\n"); + return 0; + } atrtc_start(); clock_register(dev, 1000000); bzero(&sc->et, sizeof(struct eventtimer)); @@ -286,6 +323,15 @@ return(0); } +static int atrtc_detach(device_t dev) +{ + struct atrtc_softc *sc; + + sc = device_get_softc(dev); + AcpiRemoveAddressSpaceHandler(sc->acpi_handle, ACPI_ADR_SPACE_CMOS, acpi_rtc_cmos_handler); + return bus_generic_detach(dev); +} + static int atrtc_resume(device_t dev) { @@ -366,7 +412,7 @@ /* Device interface */ DEVMETHOD(device_probe, atrtc_probe), DEVMETHOD(device_attach, atrtc_attach), - DEVMETHOD(device_detach, bus_generic_detach), + DEVMETHOD(device_detach, atrtc_detach), DEVMETHOD(device_shutdown, bus_generic_shutdown), DEVMETHOD(device_suspend, bus_generic_suspend), /* XXX stop statclock? */ @@ -402,3 +448,4 @@ rtcin(RTC_STATUSA), rtcin(RTC_STATUSB), rtcin(RTC_INTR)); } #endif /* DDB */ + --------------050503070806000304030204-- From owner-freebsd-acpi@FreeBSD.ORG Tue Jul 15 20:09:59 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 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C43A2D0E for ; Tue, 15 Jul 2014 20:09:59 +0000 (UTC) Received: from mail-ob0-x232.google.com (mail-ob0-x232.google.com [IPv6:2607:f8b0:4003:c01::232]) (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 806EE2F20 for ; Tue, 15 Jul 2014 20:09:59 +0000 (UTC) Received: by mail-ob0-f178.google.com with SMTP id nu7so6396157obb.23 for ; Tue, 15 Jul 2014 13:09:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=hYUS4vfSKQtIEDXXFiULHtyEzHkuBAx8UyrvABDoyYw=; b=REK+QR00VGWjwtKRgItedbHFF0VJFGnxjHkRzgng0XoRl6OJGzpR3vSUDOuNkvndLe m3UwyemdxkIhBHzMPtCMBUi6lcJyvgsu6mTnduEKgyzdS4v449YfAQcoVtY1p0+ITek6 E9V0NFJ/70y8DxogBVuR/tzBb+ui+cAon/hfdXuruHFysHJSVuxF/9VDKSwqNwtMRazN hS2qwfJ7Z6rGyyGm0Oe4bEKC4b+r4deYkj2zhobUzjEb+wbfZLQIYZxn0FrHNLObCCMl Au5YZRvPdqQFAMSuCiTtfPlP8/QVHSHDgeWiMN1VOhTLrzf1FwuCfgyU5pX6LDrBx3mF CcLA== MIME-Version: 1.0 X-Received: by 10.182.243.132 with SMTP id wy4mr29199071obc.38.1405454998789; Tue, 15 Jul 2014 13:09:58 -0700 (PDT) Received: by 10.182.29.9 with HTTP; Tue, 15 Jul 2014 13:09:58 -0700 (PDT) In-Reply-To: <53C58363.6050809@att.net> References: <53BF0546.70505@att.net> <53BFCBF4.2090104@att.net> <53C020CE.8010205@att.net> <53C02604.9070207@att.net> <53C3D322.3080302@att.net> <53C58363.6050809@att.net> Date: Tue, 15 Jul 2014 22:09:58 +0200 Message-ID: Subject: Re: ACPI support - Freebsd 10 on Sony Vaio VPCCA3C5E From: Daniele Mazzotti To: Anthony Jenkins Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18 Cc: freebsd-acpi@freebsd.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jul 2014 20:09:59 -0000 Hi Anthony, I tried to apply the patch but it seems like 6 out of 7 entries are dismissed. Is it enough to just type # cd /usr/src && patch < path/to/atrtc.c.patch as root? Shouldn't I recompile anything? Cheers, Daniele. 2014-07-15 21:39 GMT+02:00 Anthony Jenkins : > On 07/15/2014 13:49, Daniele Mazzotti wrote: > > Hello Anthony, > > I just noticed that I forgot to answer the part where you proposed me to > > "patch" my ACPI. Unfortunately I am running and AMD 64 architecture and I > > do not think this is fitting with what you already patched. > x86-based architectures use my patch, including amd64. It patches the > sys/x86/isa/atrtc.c driver. I'll attach it... might fix some stuff. I've > been running it on my laptop for several weeks and posted it to this > newsgroup some time ago, so it should be safe at least. > > # cd /usr/src && patch < path/to/atrtc.c.patch > > > By the way I am not sure that what I wrote is that relevant to you, but I > > just wanted to give you the feeling that I am not just passively > requiring > > help. > > Not at all... I'm scared I can't really help you with your problem. At > least it helps me learn ACPI. > > Anthony > > P.S. I alternate between top-posting and bottom-posting, depending on the > audience...I know I've switched at least twice in this thread. > > > > Cheers, > > Daniele. > > > > > > 2014-07-14 20:21 GMT+02:00 Daniele Mazzotti : > > > >> Hi Anthony, > >> > >> no problem for the "delay". I did not expect you to answer 5 seconds or > 5 > >> minutes after my email as I think we all have lives and jobs that keep > us > >> busy quite a lot. So, no problem at all! > >> > >> Regarding the issue we are discussing about, I think I already posted > the > >> output of "acpidump -dt" here http://pastebin.com/F0a2mZP4 and I also > >> tried to understand a bit of the contents but I had no luck. > Unfortunately > >> I am not so much into this ACPI thing, but I am very interested to know > how > >> it works and fix (my.... maybe also someone's else) bug. > >> > >> I followed your recommendation and enabled the debug in the loader.conf. > >> You can find my output here: http://pastebin.com/JXMjBhyx. > >> Thanks again for the precious help. > >> > >> Cheers, > >> Daniele. > >> > > From owner-freebsd-acpi@FreeBSD.ORG Tue Jul 15 20:26:01 2014 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B338B421 for ; Tue, 15 Jul 2014 20:26:01 +0000 (UTC) Received: from nm21-vm2.access.bullet.mail.gq1.yahoo.com (nm21-vm2.access.bullet.mail.gq1.yahoo.com [216.39.63.49]) (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 689922102 for ; Tue, 15 Jul 2014 20:26:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s2048; t=1405455821; bh=GSUdd1yk8ALlEkleXb8qmN2OAXM3qAXQ101Oeh5DLMo=; h=Received:Received:Received:DKIM-Signature:X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=Ugw+p/Djq+soq2RcV2cKtDSrxS9IfyTioCo2108UnP6OPMBaoRfrTykN4pdkB08/D60tIYdBEaHSicefHuSYRBMOvp9hEr+mSP+/c+Bs2JumB8cmqZVoC1bMKay35gpeB1z9yYlaSEz96h4ij3SVIO0IcTImCkEU7Xc0Cu2A1+tMYhGQS3myINbRiF3BtBmbnQoGMRArknQTkofEGR3t8X3qljSKL3aBWqvuTRVl44uscmAlRc6eHddjeP6OrqnbMzdwiazUP7MaqcEtmHqribF2k8Bp/fJv6TiltnL0jyoCsZwfrLNb1UAtAon1KEal7PJhvYOe/FyCXY3ispMOcA== DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s2048; d=att.net; b=POaYZ4GQPpU+t2RALU7/ukppIo1+CSfpidFong5f5+2RgE0ezGaUBzX8e23Z6QCpIytZieX9IPWVLVQMBAXViWu06xqW9F2uUL0oZ7r13ERB4f/qBAaBYE3uRY+NVnWKnFUIcYfLjwKaqnWYARD52XxWmjnXKkVZAG4xzn5R/NDcoz7EDBp8Ctm2U4sHuj81VhZs88GVyHYwLTCDyJdI/aw8Q91x9Ohv1L6+XaNO/68np9wzjB9gdhAbkM9z2eMqPT+xzJ6AC1cZCo6L7JoL/ppyytgXcz50Wsk9mRTIbJdo/PqfdEJqBcZulYguiSs/ZTvXlkofLnLlNsexy8ZoLA==; Received: from [216.39.60.172] by nm21.access.bullet.mail.gq1.yahoo.com with NNFMP; 15 Jul 2014 20:23:41 -0000 Received: from [98.138.226.243] by tm8.access.bullet.mail.gq1.yahoo.com with NNFMP; 15 Jul 2014 20:23:41 -0000 Received: from [127.0.0.1] by smtp114.sbc.mail.ne1.yahoo.com with NNFMP; 15 Jul 2014 20:23:41 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1405455821; bh=GSUdd1yk8ALlEkleXb8qmN2OAXM3qAXQ101Oeh5DLMo=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=01DYgwBY2WHfVR5Wk5VoBb6QpMk7xNs/E6JwkD6rXGhUuFYyt5vfSETa86GWs2YMorVVJpbLXr4fK0reb3tsXzLdiZlKIGrVJ7hYv5HraWunZPbIf4VVV+bQeSmGe8dR+R6Y03dctlbNnvflO1pWpy3pUw0WtQHdbIRqWKMrqAE= X-Yahoo-Newman-Id: 631503.98164.bm@smtp114.sbc.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: 6Zq7t94VM1l3a25d0SsBPlc7k4S1w2RqCXvC8qcbOq8dV_D KHcX_S5zsAUUx_hW1B3KM4EoykWrNDc_7RZkUq7EH_cUvyWMibz9EFu_nunp HOZ0IGjRNZiTOUH28oEUfD9dF9Tnhcfdl8LwyM_Kn04x4mZRxTztB28xAz7f u.4ohFhRP7CeUbzEknI97rYAnAvxO8IwCoLtce9VW.0UgdEyJJjm.fOeP5c1 n039ZLYW80Mf_GkHVRHjh2Tq3vlSJvxyCSDr1Z8b4KynVpf9Df3MquZaM4i4 3dN.TVcqF9e5akIU5MCtoc8N_21SOkgHn8EJwjcDAQWRdnjLsHrny4cgLVvR 9r_SJnOKiaGLZLfdc0LL44wV3Y53lTYMGZAk2gdYgEFqjSp12UJ9MBkqoLCv A6Vqr7BEUOa9du6R.MrHScpFhKq5Z7jwepdIl5QTwVo6BzFIhHLYvxmOsJ_9 Tr4A_W1JoN_HJhmY5Qn444MSZi3hPf0ol29m2CdDZt9exCy37YXQtNDgMSJv xcThW1JaHR55RDiPmhD_rAK6JQw_qhXVN0s45Efrbd2W26Wwd9TWBl3cVIGw 1BhGg0YYcHpga32JF8pgFFISeWlBZ9jFBDdNPavil5YCkucQXykGvl7HvpB7 v X-Yahoo-SMTP: OKD1keCswBBTAmAF1s00hLyKW3wE3YfSK0Eazl6b4VZG4LTqJxg- Message-ID: <53C58DCB.3030609@att.net> Date: Tue, 15 Jul 2014 16:23:39 -0400 From: Anthony Jenkins User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Daniele Mazzotti Subject: Re: ACPI support - Freebsd 10 on Sony Vaio VPCCA3C5E References: <53BF0546.70505@att.net> <53BFCBF4.2090104@att.net> <53C020CE.8010205@att.net> <53C02604.9070207@att.net> <53C3D322.3080302@att.net> <53C58363.6050809@att.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@freebsd.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jul 2014 20:26:01 -0000 What's the error(s)? As root, you should type cd /usr/src && patch < path/to/atrtc.c.patch ...the '#' was just an indicator of the root user shell prompt. If it applies properly, rebuild the kernel and reboot. If not, send your /usr/src/sys/x86/isa/atrtc.c file and I can manually patch it and send it back. I guess I could roll my kernel sources back to the revision you indicated earlier... Anthony On 07/15/2014 16:09, Daniele Mazzotti wrote: > Hi Anthony, > > I tried to apply the patch but it seems like 6 out of 7 entries are > dismissed. Is it enough to just type > > # cd /usr/src && patch < path/to/atrtc.c.patch > > as root? Shouldn't I recompile anything? > > Cheers, > Daniele. > > > 2014-07-15 21:39 GMT+02:00 Anthony Jenkins : > >> On 07/15/2014 13:49, Daniele Mazzotti wrote: >>> Hello Anthony, >>> I just noticed that I forgot to answer the part where you proposed me to >>> "patch" my ACPI. Unfortunately I am running and AMD 64 architecture and I >>> do not think this is fitting with what you already patched. >> x86-based architectures use my patch, including amd64. It patches the >> sys/x86/isa/atrtc.c driver. I'll attach it... might fix some stuff. I've >> been running it on my laptop for several weeks and posted it to this >> newsgroup some time ago, so it should be safe at least. >> >> # cd /usr/src && patch < path/to/atrtc.c.patch >> >>> By the way I am not sure that what I wrote is that relevant to you, but I >>> just wanted to give you the feeling that I am not just passively >> requiring >>> help. >> Not at all... I'm scared I can't really help you with your problem. At >> least it helps me learn ACPI. >> >> Anthony >> >> P.S. I alternate between top-posting and bottom-posting, depending on the >> audience...I know I've switched at least twice in this thread. >> >> >>> Cheers, >>> Daniele. >>> >>> >>> 2014-07-14 20:21 GMT+02:00 Daniele Mazzotti : >>> >>>> Hi Anthony, >>>> >>>> no problem for the "delay". I did not expect you to answer 5 seconds or >> 5 >>>> minutes after my email as I think we all have lives and jobs that keep >> us >>>> busy quite a lot. So, no problem at all! >>>> >>>> Regarding the issue we are discussing about, I think I already posted >> the >>>> output of "acpidump -dt" here http://pastebin.com/F0a2mZP4 and I also >>>> tried to understand a bit of the contents but I had no luck. >> Unfortunately >>>> I am not so much into this ACPI thing, but I am very interested to know >> how >>>> it works and fix (my.... maybe also someone's else) bug. >>>> >>>> I followed your recommendation and enabled the debug in the loader.conf. >>>> You can find my output here: http://pastebin.com/JXMjBhyx. >>>> Thanks again for the precious help. >>>> >>>> Cheers, >>>> Daniele. >>>> >> > _______________________________________________ > freebsd-acpi@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-acpi > To unsubscribe, send any mail to "freebsd-acpi-unsubscribe@freebsd.org" > From owner-freebsd-acpi@FreeBSD.ORG Wed Jul 16 04:02:54 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 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AE76832B for ; Wed, 16 Jul 2014 04:02:54 +0000 (UTC) Received: from mail-oa0-x22a.google.com (mail-oa0-x22a.google.com [IPv6:2607:f8b0:4003:c02::22a]) (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 6BEC427DD for ; Wed, 16 Jul 2014 04:02:54 +0000 (UTC) Received: by mail-oa0-f42.google.com with SMTP id n16so366982oag.15 for ; Tue, 15 Jul 2014 21:02:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=8mxEyUjWhCADnasMwhmhCrmLlK9rnbEMwCGy01YYO8g=; b=uQkPl24WMNmrDaBAA8rfi0i/RYfAndZWdQ5E94RFxDP5Pl0XevFz7oZN70XI5JCKVj vzxm7647Lldb8XurNTPHte2LkgPnwddM+WywviCcHkYGul9rZ0RIpd0YdacGM76em7b6 uis7rsGRLji2NhzhWO7D9ZX204PwOp5vZO466dZR11WhSONevAvDBx9e93zJUgalrWCl OOc2Oe0rK7L64BulM3RaiV7dth3Oj+ddyWJfhcfkgQgjwcztVPyiWpOEWkuY0cNzIz7m ltMk5L6Ssasdkdq6puotnW5QFD/+maZqK3jg8ljEfzSwiciOB3O0U0wNv3izQ0JMnpM/ b1+g== MIME-Version: 1.0 X-Received: by 10.60.134.102 with SMTP id pj6mr21808993oeb.70.1405483373656; Tue, 15 Jul 2014 21:02:53 -0700 (PDT) Received: by 10.182.29.9 with HTTP; Tue, 15 Jul 2014 21:02:53 -0700 (PDT) Received: by 10.182.29.9 with HTTP; Tue, 15 Jul 2014 21:02:53 -0700 (PDT) In-Reply-To: References: <53BF0546.70505@att.net> <53BFCBF4.2090104@att.net> <53C020CE.8010205@att.net> <53C02604.9070207@att.net> <53C3D322.3080302@att.net> <53C58363.6050809@att.net> Date: Wed, 16 Jul 2014 06:02:53 +0200 Message-ID: Subject: Re: ACPI support - Freebsd 10 on Sony Vaio VPCCA3C5E From: Daniele Mazzotti To: Anthony Jenkins Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18 Cc: freebsd-acpi@freebsd.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jul 2014 04:02:54 -0000 Hi Anthony, The error log was attached to my previous email. Cheers, Daniele. Il 15/lug/2014 22:09 "Daniele Mazzotti" ha scritto: > Hi Anthony, > > I tried to apply the patch but it seems like 6 out of 7 entries are > dismissed. Is it enough to just type > > # cd /usr/src && patch < path/to/atrtc.c.patch > > as root? Shouldn't I recompile anything? > > Cheers, > Daniele. > > > 2014-07-15 21:39 GMT+02:00 Anthony Jenkins : > >> On 07/15/2014 13:49, Daniele Mazzotti wrote: >> > Hello Anthony, >> > I just noticed that I forgot to answer the part where you proposed me to >> > "patch" my ACPI. Unfortunately I am running and AMD 64 architecture and >> I >> > do not think this is fitting with what you already patched. >> x86-based architectures use my patch, including amd64. It patches the >> sys/x86/isa/atrtc.c driver. I'll attach it... might fix some stuff. I've >> been running it on my laptop for several weeks and posted it to this >> newsgroup some time ago, so it should be safe at least. >> >> # cd /usr/src && patch < path/to/atrtc.c.patch >> >> > By the way I am not sure that what I wrote is that relevant to you, but >> I >> > just wanted to give you the feeling that I am not just passively >> requiring >> > help. >> >> Not at all... I'm scared I can't really help you with your problem. At >> least it helps me learn ACPI. >> >> Anthony >> >> P.S. I alternate between top-posting and bottom-posting, depending on the >> audience...I know I've switched at least twice in this thread. >> >> >> > Cheers, >> > Daniele. >> > >> > >> > 2014-07-14 20:21 GMT+02:00 Daniele Mazzotti : >> > >> >> Hi Anthony, >> >> >> >> no problem for the "delay". I did not expect you to answer 5 seconds >> or 5 >> >> minutes after my email as I think we all have lives and jobs that keep >> us >> >> busy quite a lot. So, no problem at all! >> >> >> >> Regarding the issue we are discussing about, I think I already posted >> the >> >> output of "acpidump -dt" here http://pastebin.com/F0a2mZP4 and I also >> >> tried to understand a bit of the contents but I had no luck. >> Unfortunately >> >> I am not so much into this ACPI thing, but I am very interested to >> know how >> >> it works and fix (my.... maybe also someone's else) bug. >> >> >> >> I followed your recommendation and enabled the debug in the >> loader.conf. >> >> You can find my output here: http://pastebin.com/JXMjBhyx. >> >> Thanks again for the precious help. >> >> >> >> Cheers, >> >> Daniele. >> >> >> >> > From owner-freebsd-acpi@FreeBSD.ORG Wed Jul 16 05:20:24 2014 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6802290 for ; Wed, 16 Jul 2014 05:20:24 +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 CEB9F2CCE for ; Wed, 16 Jul 2014 05:20:23 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id s6G5KD98009269; Wed, 16 Jul 2014 15:20:13 +1000 (EST) (envelope-from smithi@nimnet.asn.au) Date: Wed, 16 Jul 2014 15:20:13 +1000 (EST) From: Ian Smith To: Daniele Mazzotti Subject: Re: ACPI support - Freebsd 10 on Sony Vaio VPCCA3C5E In-Reply-To: Message-ID: <20140716143406.V50382@sola.nimnet.asn.au> References: <53BF0546.70505@att.net> <53BFCBF4.2090104@att.net> <53C020CE.8010205@att.net> <53C02604.9070207@att.net> <53C3D322.3080302@att.net> <20140716040719.Y50382@sola.nimnet.asn.au> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: Anthony Jenkins , freebsd-acpi@freebsd.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jul 2014 05:20:24 -0000 On Tue, 15 Jul 2014 20:47:44 +0200, Daniele Mazzotti wrote: > Hi Ian, > > I have just rebooted the PC after turning the deep debug on. Here is the > output: http://pastebin.com/H61zJhqc. It is very likely that the dmesg has > been cut due to the large amount of output. Is there any way to have it all? > > Cheers, > Daniele. >From the boot menu you can drop to the loader, and enter something like: set kern.msgbufsize=120000 boot where the default is about 64K these days, I think. However I couldn't spot anything further regarding 'battery|BAT0', and you did catch the start of initialisation. I'm out of my depth, but you might also try layer 'ACPI_EC' with high verbosity? You shoudn't need to reboot to try things now that ACPI_DEBUG is enabled in your kernel; you can adjust them on the fly. From section 11.16.6 on the acpi-debug page: "If the information you want is triggered by a specific event (say, a suspend and then resume), you can leave out changes to loader.conf and instead use sysctl to specify the layer and level after booting and preparing your system for the specific event. The sysctls are named the same as the tunables in loader.conf." So you could avoid all the boot messages, if they're not helpful, and log events like switching from AC to battery and vice versa, which might trigger interrogating the battery (via the EC, probably), by adjusting those sysctls, just for an example: root# sysctl debug.acpi.layer="ACPI_EC ACPI_BATTERY ACPI_AC_ADAPTER" root# sysctl debug.acpi.level="ACPI_LV_VERBOSITY3" But I'm just stabbing in the dark, really .. good luck. cheers, Ian > 2014-07-15 20:22 GMT+02:00 Ian Smith : > > > On Tue, 15 Jul 2014 19:49:46 +0200, Daniele Mazzotti wrote: > > > > > I made a few step ahead (at least on my side) and tried to follow the > > > recommendation from the handbook ( > > > http://www.pl.freebsd.org/doc/handbook/acpi-debug.html). > > > > > > I was able to turn on the verbose boot and here you can find the output: > > > http://pastebin.com/kkDAZEVb. At boot time I can see an error stating > > > "battery0: battery initialization failed, giving up" which is thrown by > > the > > > acpi_cmbat_init_battery within acpi_cmbat.c module. After six retries > > the > > > error is printed out. Actually I am not able to figure out who is > > calling > > > the method, but that is another story. > > > > Actually you'll see those messages on a 'normal' verbose boot, ie > > there's nothing extra logged of note regarding battery issues. If you > > are up for lots more output on one boot at least, perhaps try what > > acpi(4) suggests: > > > > debug.acpi.layer="ACPI_ALL_COMPONENTS ACPI_ALL_DRIVERS" > > debug.acpi.level="ACPI_LV_ALL_EXCEPTIONS" > > > > which is less deep, but wider :) Communications with batteries often, > > likely usually, is moderated by the embedded controler (ACPI_EC) and it > > wouldn't hurt to report any exceptions from other subsystems also. If > > that yields nothing useful you could increase the level .. > > > > Sorry, I can't read messages backwards very well, so I'll drop the tail. > > > > cheers, Ian From owner-freebsd-acpi@FreeBSD.ORG Wed Jul 16 05:32:51 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 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 696C53CB for ; Wed, 16 Jul 2014 05:32:51 +0000 (UTC) Received: from mail-ob0-x232.google.com (mail-ob0-x232.google.com [IPv6:2607:f8b0:4003:c01::232]) (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 259FC2E0D for ; Wed, 16 Jul 2014 05:32:51 +0000 (UTC) Received: by mail-ob0-f178.google.com with SMTP id nu7so427914obb.23 for ; Tue, 15 Jul 2014 22:32:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=X1bUv/eYCwSCnxml/VMDR4wg/V4mt3+OTaT5DARuEdo=; b=p4lFMF6vRHRO12KcG22gTRrxzOt1jloDc0igJ3TNa9wmksIQqcTW0caXWNcQNdnxff F8c56iKFfUL5UVqH7zbmcjJoxpjJTj22ghScjWROHy6MTf8lxiW3a3yLkI+qQXTS8PKL SxXRldGZS56BsdM67o9U3i0ehHwZubjlOWKo1m0TRF4DrOCSVx0Q4T3rVT7PQr338TIL pWOYQrMkmdj/k/g2h3BKdmzo5M/0e0BJqiwjbXiF4+n89uK8/m+1n9gJDTdmEeKierWT vWwABoXjEjcejbFPxuHSlRSo8vRwqXsy4jKR4lyg16kwVxqW8WhkrwyRg8BFndjDk47S j5ow== MIME-Version: 1.0 X-Received: by 10.60.220.163 with SMTP id px3mr32163675oec.35.1405488770290; Tue, 15 Jul 2014 22:32:50 -0700 (PDT) Received: by 10.182.29.9 with HTTP; Tue, 15 Jul 2014 22:32:50 -0700 (PDT) Received: by 10.182.29.9 with HTTP; Tue, 15 Jul 2014 22:32:50 -0700 (PDT) In-Reply-To: <20140716143406.V50382@sola.nimnet.asn.au> References: <53BF0546.70505@att.net> <53BFCBF4.2090104@att.net> <53C020CE.8010205@att.net> <53C02604.9070207@att.net> <53C3D322.3080302@att.net> <20140716040719.Y50382@sola.nimnet.asn.au> <20140716143406.V50382@sola.nimnet.asn.au> Date: Wed, 16 Jul 2014 07:32:50 +0200 Message-ID: Subject: Re: ACPI support - Freebsd 10 on Sony Vaio VPCCA3C5E From: Daniele Mazzotti To: Ian Smith Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18 Cc: Anthony Jenkins , freebsd-acpi@freebsd.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jul 2014 05:32:51 -0000 Hi guys, thanks again for the support, but I am leaving for a businesses trip and I will be forced to put this debug thing on hold for a while. I will be back on track next week. @Ian: there is only one thing I got from this problem NEVER BUY A SONY VAIO. It took 3 years before having support for my WiFi card on BSD and I hate Linux (especially Ubuntu)... There is no way I am going to use that OS on my desktop :-). Cheers, Daniele. Il 16/lug/2014 07:20 "Ian Smith" ha scritto: > On Tue, 15 Jul 2014 20:47:44 +0200, Daniele Mazzotti wrote: > > Hi Ian, > > > > I have just rebooted the PC after turning the deep debug on. Here is the > > output: http://pastebin.com/H61zJhqc. It is very likely that the dmesg > has > > been cut due to the large amount of output. Is there any way to have it > all? > > > > Cheers, > > Daniele. > > From the boot menu you can drop to the loader, and enter something like: > set kern.msgbufsize=120000 > boot > where the default is about 64K these days, I think. > > However I couldn't spot anything further regarding 'battery|BAT0', and > you did catch the start of initialisation. I'm out of my depth, but you > might also try layer 'ACPI_EC' with high verbosity? > > You shoudn't need to reboot to try things now that ACPI_DEBUG is enabled > in your kernel; you can adjust them on the fly. From section 11.16.6 on > the acpi-debug page: > > "If the information you want is triggered by a specific event (say, a > suspend and then resume), you can leave out changes to loader.conf and > instead use sysctl to specify the layer and level after booting and > preparing your system for the specific event. The sysctls are named the > same as the tunables in loader.conf." > > So you could avoid all the boot messages, if they're not helpful, and > log events like switching from AC to battery and vice versa, which might > trigger interrogating the battery (via the EC, probably), by adjusting > those sysctls, just for an example: > > root# sysctl debug.acpi.layer="ACPI_EC ACPI_BATTERY ACPI_AC_ADAPTER" > root# sysctl debug.acpi.level="ACPI_LV_VERBOSITY3" > > But I'm just stabbing in the dark, really .. good luck. > > cheers, Ian > > > 2014-07-15 20:22 GMT+02:00 Ian Smith : > > > > > On Tue, 15 Jul 2014 19:49:46 +0200, Daniele Mazzotti wrote: > > > > > > > I made a few step ahead (at least on my side) and tried to follow > the > > > > recommendation from the handbook ( > > > > http://www.pl.freebsd.org/doc/handbook/acpi-debug.html). > > > > > > > > I was able to turn on the verbose boot and here you can find the > output: > > > > http://pastebin.com/kkDAZEVb. At boot time I can see an error > stating > > > > "battery0: battery initialization failed, giving up" which is > thrown by > > > the > > > > acpi_cmbat_init_battery within acpi_cmbat.c module. After six > retries > > > the > > > > error is printed out. Actually I am not able to figure out who is > > > calling > > > > the method, but that is another story. > > > > > > Actually you'll see those messages on a 'normal' verbose boot, ie > > > there's nothing extra logged of note regarding battery issues. If you > > > are up for lots more output on one boot at least, perhaps try what > > > acpi(4) suggests: > > > > > > debug.acpi.layer="ACPI_ALL_COMPONENTS ACPI_ALL_DRIVERS" > > > debug.acpi.level="ACPI_LV_ALL_EXCEPTIONS" > > > > > > which is less deep, but wider :) Communications with batteries often, > > > likely usually, is moderated by the embedded controler (ACPI_EC) and > it > > > wouldn't hurt to report any exceptions from other subsystems also. If > > > that yields nothing useful you could increase the level .. > > > > > > Sorry, I can't read messages backwards very well, so I'll drop the > tail. > > > > > > cheers, Ian > From owner-freebsd-acpi@FreeBSD.ORG Wed Jul 16 13:28:30 2014 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A8CED911 for ; Wed, 16 Jul 2014 13:28:30 +0000 (UTC) Received: from nm14-vm7.access.bullet.mail.bf1.yahoo.com (nm14-vm7.access.bullet.mail.bf1.yahoo.com [216.109.115.22]) (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 46A67285D for ; Wed, 16 Jul 2014 13:28:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s2048; t=1405517169; bh=b3KBCcbuBkyQgzD4WxAEVZGXv5y7aW/FSh9HZhSNbls=; h=Received:Received:Received:DKIM-Signature:X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=KSNQ2wQoVJBkmP8XROw460FcU/61/wlBdfKAJnxw7UzS4TnxMQXmpZQmmDqvFeLor1/HnLSOhgvsLkEATwe4kvmiTx63q5bbEouq8mm3AzFZ+X0OhEAqwg92Iv+ex1c/fZkW8GgzXvqcW6w+D6FhPX2khVjz7GLgFwFFBUCjQhLBLuZEFzXxNZDVIxuYlAUiPGtDhH3lc2I9Mjjd/hfxq/R0gMHfTwpF7SdWo+xpI+lgBp6sEhItSP1sxjFOhip3J8Vt5J52+30SgUg3zpQEIzWvf7prTOAk844zXU0fhBY69HhDfvaKjP9QfonFOr3LYbdbPFrn3UWWgb53Pnk2oQ== DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s2048; d=att.net; b=nrq/cflW0YncvDfkYUXRTq+uBP0iMJt8nCGUdnambjGjt3GVPUtOGljqE8UYwE9Gf1dML2j3J+AKbPxnff3B3z/Jvut2+iDh8ObJfLWAk8Oho8s9ChBZf4uxRqI5nQ1Rhvrln+S2OOPpnBuMgvaCqimCOhxfZbLDbz1IDxNZR7Jo5adhe8Y8zUzAUUvm2gvVGrumTYUGMnPKsvt65TX8VWcgobZvKkkF/58Iwnj0nVg/tFOEhwIkpAE+CAWcQ/fG1GN/gRRJq368Wv3l75HhS273Mdgn1oT1jUiUrxouM5q4ElOeMiHJSEPOI8sQUbPX0qymc9gMI81bYSHYWSBKsA==; Received: from [66.196.81.157] by nm14.access.bullet.mail.bf1.yahoo.com with NNFMP; 16 Jul 2014 13:26:09 -0000 Received: from [98.138.104.99] by tm3.access.bullet.mail.bf1.yahoo.com with NNFMP; 16 Jul 2014 13:26:09 -0000 Received: from [127.0.0.1] by smtp119.sbc.mail.ne1.yahoo.com with NNFMP; 16 Jul 2014 13:26:09 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1405517169; bh=b3KBCcbuBkyQgzD4WxAEVZGXv5y7aW/FSh9HZhSNbls=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=KhEKpogXUqTIOkOJNSD45AOmeZeqzyks2UZwAfJjkvAoLNB9+jnAWMCkhZ9VhOoUJMt3FODlJu8I1irGcCx+10BvLs0z/NtpytLnNVx2yhe2sWN5SdBVZ8PziY/ZVHTaVmMQUAJrfBxFPWR1NuihQwCOXsJjhSvESV1eD6WGIlw= X-Yahoo-Newman-Id: 339229.83428.bm@smtp119.sbc.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: JJjDOU8VM1m4crYf9Aao.B9yn7LFhFHYOAxVpAbO4voky6X oayGdMLbaS3_CIxmSktHKpt2S1jb5.8EksUPX9nwIs8l_2GUDIiWM1bxCVIb T7raiXkyr6mjkGfHu0DbngSugikJ1m8tz690AEDAopKHbFECsePBrtZBukCy 6qssQUJOm6dl8Z4aub3FJQpMvrsu2mX1W6S5fKTl72t3AiWjctQdlRkIR8Oe btIGqPgr0rEsU1Ka4GT83vP4hDhcEg3RgtNhBrE0X63OUz.ebLEhlTot425M YGBE0IyFVz6map4ZpvFcX7qc8.MeHcPgMdHZX4VOzl5kyBwNyXfFySx5OePo PtEAlPzP5Ym1cB1SytjSWVKf.xGincAHHatEJGo7l_.uYcnorAYppAhEkl_6 bdmR.guwz.kJVqrVEtmMEtZgxQitXUWk.8yrjfCnfAVLDe.Ctc5ACaPl_kUI FVt_8qTa5FtcGHP8dcxNzxQhU96iIrviO5k6Glgll07RS_8TOBeZe4BQGrpI IFf8_omz8ec1hV3ia4.Y6cvixaVVav0pk66us2UAk6dO2_E_YVO.HEKbFYVf v5Zo6iF_0QWDqO3ua4JXhr.TrGlou2ymglm6FhXcxAMVVgVK.8mO.J0907Zv fVqiWW054uxQ4_TYWMk_9Azk2EYO3cvdB00gBCLDgz4MsFCAeVA5RfrYGRi7 jj3T3EV6GgkInxGBBayk5jb56xh3EXw-- X-Yahoo-SMTP: OKD1keCswBBTAmAF1s00hLyKW3wE3YfSK0Eazl6b4VZG4LTqJxg- Message-ID: <53C67D70.6060603@att.net> Date: Wed, 16 Jul 2014 09:26:08 -0400 From: Anthony Jenkins User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Daniele Mazzotti , Ian Smith Subject: Re: ACPI support - Freebsd 10 on Sony Vaio VPCCA3C5E References: <53BFCBF4.2090104@att.net> <53C020CE.8010205@att.net> <53C02604.9070207@att.net> <53C3D322.3080302@att.net> <20140716040719.Y50382@sola.nimnet.asn.au> <20140716143406.V50382@sola.nimnet.asn.au> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@freebsd.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jul 2014 13:28:30 -0000 On 07/16/2014 01:32, Daniele Mazzotti wrote: > > Hi guys, > > thanks again for the support, but I am leaving for a businesses trip and I will be forced to put this debug thing on hold for a while. I will be back on track next week. > Bah... really wanted to figure out the patch problem. I suspect the file picked up some corruption somewhere between the email and your FreeBSD filesystem. Your OS version has the same revision of that source file as mine, so it should apply cleanly. If you feel like tinkering with it in your free time, I've posted the patch here: http://pastebin.com/P0B44u0c Good luck, Anthony > > @Ian: there is only one thing I got from this problem NEVER BUY A SONY VAIO. It took 3 years before having support for my WiFi card on BSD and I hate Linux (especially Ubuntu)... There is no way I am going to use that OS on my desktop :-). > > Cheers, > Daniele. > > Il 16/lug/2014 07:20 "Ian Smith" > ha scritto: > > On Tue, 15 Jul 2014 20:47:44 +0200, Daniele Mazzotti wrote: > > Hi Ian, > > > > I have just rebooted the PC after turning the deep debug on. Here is the > > output: http://pastebin.com/H61zJhqc. It is very likely that the dmesg has > > been cut due to the large amount of output. Is there any way to have it all? > > > > Cheers, > > Daniele. > > >From the boot menu you can drop to the loader, and enter something like: > set kern.msgbufsize=120000 > boot > where the default is about 64K these days, I think. > > However I couldn't spot anything further regarding 'battery|BAT0', and > you did catch the start of initialisation. I'm out of my depth, but you > might also try layer 'ACPI_EC' with high verbosity? > > You shoudn't need to reboot to try things now that ACPI_DEBUG is enabled > in your kernel; you can adjust them on the fly. From section 11.16.6 on > the acpi-debug page: > > "If the information you want is triggered by a specific event (say, a > suspend and then resume), you can leave out changes to loader.conf and > instead use sysctl to specify the layer and level after booting and > preparing your system for the specific event. The sysctls are named the > same as the tunables in loader.conf." > > So you could avoid all the boot messages, if they're not helpful, and > log events like switching from AC to battery and vice versa, which might > trigger interrogating the battery (via the EC, probably), by adjusting > those sysctls, just for an example: > > root# sysctl debug.acpi.layer="ACPI_EC ACPI_BATTERY ACPI_AC_ADAPTER" > root# sysctl debug.acpi.level="ACPI_LV_VERBOSITY3" > > But I'm just stabbing in the dark, really .. good luck. > > cheers, Ian > > > 2014-07-15 20:22 GMT+02:00 Ian Smith >: > > > > > On Tue, 15 Jul 2014 19:49:46 +0200, Daniele Mazzotti wrote: > > > > > > > I made a few step ahead (at least on my side) and tried to follow the > > > > recommendation from the handbook ( > > > > http://www.pl.freebsd.org/doc/handbook/acpi-debug.html). > > > > > > > > I was able to turn on the verbose boot and here you can find the output: > > > > http://pastebin.com/kkDAZEVb. At boot time I can see an error stating > > > > "battery0: battery initialization failed, giving up" which is thrown by > > > the > > > > acpi_cmbat_init_battery within acpi_cmbat.c module. After six retries > > > the > > > > error is printed out. Actually I am not able to figure out who is > > > calling > > > > the method, but that is another story. > > > > > > Actually you'll see those messages on a 'normal' verbose boot, ie > > > there's nothing extra logged of note regarding battery issues. If you > > > are up for lots more output on one boot at least, perhaps try what > > > acpi(4) suggests: > > > > > > debug.acpi.layer="ACPI_ALL_COMPONENTS ACPI_ALL_DRIVERS" > > > debug.acpi.level="ACPI_LV_ALL_EXCEPTIONS" > > > > > > which is less deep, but wider :) Communications with batteries often, > > > likely usually, is moderated by the embedded controler (ACPI_EC) and it > > > wouldn't hurt to report any exceptions from other subsystems also. If > > > that yields nothing useful you could increase the level .. > > > > > > Sorry, I can't read messages backwards very well, so I'll drop the tail. > > > > > > cheers, Ian > From owner-freebsd-acpi@FreeBSD.ORG Wed Jul 16 17:16:18 2014 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8F0F2AAC for ; Wed, 16 Jul 2014 17:16:18 +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 D17892D9E for ; Wed, 16 Jul 2014 17:16:17 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id s6GHGACk035060; Thu, 17 Jul 2014 03:16:11 +1000 (EST) (envelope-from smithi@nimnet.asn.au) Date: Thu, 17 Jul 2014 03:16:10 +1000 (EST) From: Ian Smith To: Anthony Jenkins Subject: Re: ACPI support - Freebsd 10 on Sony Vaio VPCCA3C5E In-Reply-To: <53C67D70.6060603@att.net> Message-ID: <20140717011710.W50382@sola.nimnet.asn.au> References: <53C020CE.8010205@att.net> <53C02604.9070207@att.net> <53C3D322.3080302@att.net> <20140716040719.Y50382@sola.nimnet.asn.au> <20140716143406.V50382@sola.nimnet.asn.au> <53C67D70.6060603@att.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: freebsd-acpi@freebsd.org, Daniele Mazzotti X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jul 2014 17:16:18 -0000 On Wed, 16 Jul 2014 09:26:08 -0400, Anthony Jenkins wrote: > On 07/16/2014 01:32, Daniele Mazzotti wrote: >> Hi guys, thanks again for the support, but I am leaving for a >> businesses trip and I will be forced to put this debug thing on hold >> for a while. I will be back on track next week. > > Bah... really wanted to figure out the patch problem. I suspect the > file picked up some corruption somewhere between the email and your > FreeBSD filesystem. Your OS version has the same revision of that > source file as mine, so it should apply cleanly. If you feel like > tinkering with it in your free time, I've posted the patch here: > http://pastebin.com/P0B44u0c > > Good luck, > Anthony Either by show raw and save, or by download, the patch has ^M lineends. Interesting, but I can't see atrtc.c being the right sort of place for this, seems way out of scope. Couldn't you include its headers and use functions rtcin() and writertc() from elsewhere in kernel, perhaps a module living in the same hierarchy as acpi_ibm, acpi_asus and such, that one could build and kldload if useful on a certain machine/s? If so, you haven't to do battle with Time Lords :) with something people could add and load at own risk without messing with core kernel stuff. acpi_ibm should be a useful template, as it includes code to read CMOS bytes in the 0x60-0x6f range, presumably updated by the BIOS, whether opaquely or somehow via AML code I don't know. It uses rtcin() so has that scope in place. I'd still like to see your patch reject attempts to read or write to at least below 0x10. Even reading status register/s resets interrupts, and why would anyone need to mess with clock and/or timer regs via ACPI? Have you found exactly which CMOS bytes your box needs to meddle with? Maybe you could add a sysctl to limit access to some specific range? Don't mind me, just thinking aloud, and I've no idea how this might relate to Daniele's issue with stale battery data? cheers, Ian PS Daniele: no, never tempted by Sonys; rusted-on Thinkpad kinda guy :) From owner-freebsd-acpi@FreeBSD.ORG Wed Jul 16 21:11:36 2014 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6022C28C for ; Wed, 16 Jul 2014 21:11:36 +0000 (UTC) Received: from nm26-vm10.access.bullet.mail.bf1.yahoo.com (nm26-vm10.access.bullet.mail.bf1.yahoo.com [216.109.115.217]) (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 F316223DE for ; Wed, 16 Jul 2014 21:11:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s2048; t=1405544884; bh=X70n6pg/UaWLpz1JNOSWw/lNkAGEr0D2Ih2WPV00f9A=; h=Received:Received:Received:DKIM-Signature:X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=IIC7eIAFYwQk7H5jLzdZS4ep2UeSXYq3V5N+XOzyMLGBPdxgfnUt1h67KJj97Z2fypTKqDY6mbnbCblE0xgrt3RL1rgpYcxHX+VefJCvwsp7K52tMznHpDVifJ003JX/s0S2ubh2HN0vJiAh9UvAWyT0Ibiks0dVfg4pSFcOWE3/uFz5Z1It9wTbZnrhisOagbNu6xSQPEJ0NOE+W0grfcJp0kVeAUMBzOjCD/ARhcA+Ntxc7rWW9v79LhbEwW5R7M4jfNgDlLJHuIyx/Lro2H4BM6KIHmYZEqZfW/1n0xvNeonDP31UbHXrhM+0Kj54HdbcdDOB7KXBoLrbtjj14w== DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s2048; d=att.net; b=iVOPb1S2VRhGT6XomGRCoIuTdZS9h1ZUyscHm0R+0eudfpafdnWaSDPplU+0noNsV28FU8SfYOcOryPSjAB0K0Z/FUr50y9WxARI19zK7dw1TWhNyGUWssixdaAr2jdKr9gsDMgXS7IlARqzq/rlj78Y2Hkd2vh5lkjTNy2Q/NqvQO6TXzNHbARxBP2x7DURuFapsRGiKNnB3rHeEwXxj0V2N0E6QK/NRbWwhqCyzujErYzEWQYZsGsvwRdKjac3qfMv14fI7Z15unYIYi3zNkKS8yhhfVlV3z1T2qH9uU1GdoGFFi/D8/mFUiHoqVKsXpMa7wxgI/dAkBCwPcTILg==; Received: from [66.196.81.155] by nm26.access.bullet.mail.bf1.yahoo.com with NNFMP; 16 Jul 2014 21:08:04 -0000 Received: from [98.138.104.97] by tm1.access.bullet.mail.bf1.yahoo.com with NNFMP; 16 Jul 2014 21:08:04 -0000 Received: from [127.0.0.1] by smtp117.sbc.mail.ne1.yahoo.com with NNFMP; 16 Jul 2014 21:08:04 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1405544884; bh=X70n6pg/UaWLpz1JNOSWw/lNkAGEr0D2Ih2WPV00f9A=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=dLE+w4qLYVLi2Le4UiBb/9sZKe56RxC/hQHhlDBFw5yWO1VwZDUcs1cOZRn/vpHm7CVQBzqUwLaFE7hCy2S3LqKRZfOdeDOGQHqefcwNc7jhyhwhfPpUFJccNUwRGrcaqCuoMmsoG0/388UIpUMjVtNHP96VoIwuFgMSrggKSPo= X-Yahoo-Newman-Id: 725203.47979.bm@smtp117.sbc.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: fSIVGDIVM1lL344FtKE8F9cJJHM4gsGTpZ9JvnqWjdH9IM4 _7IcGXPCn2jHUzKASy68RwVuGOr0_K1Q2lT98eAoZ_MhRNO.wQY6NqpyJBvX 2OvXqkMmxv0jkX7zvkzu690j3yEPuGdwLD5d4Yp.8aunZYVbWOopCyzRS82R BIxlpwB_vmcD6kwcZzxH0GDtSmoaQvTB32F4Pb_6e2oH3htIM83b._3_URRf R75GV4S99_5Po3DF3GFa8c3dq3W4xskOkE..oVqQB4635qfiwPHh1w.9Fj8s QiScxV1VOQah6kcUF99o2RaU1HVhBwFGAnmuv96r6MRwkZ07mbT0CatyqONw a9In8jg0C1etFZfLEhl5KXewbY7juQdyP35Pk9sCZ8dlznIz_gm0IE7wVrX6 _asYkZta.zpoaYdUgjUA5LHe_F2.FHJMW2ht2uY0wXYL4aqxmwsGI.evTG3i IqplM_agAx9HzjavbtE_V1LoSaKjG41icehqHr959nWAa4bZVNARCvCBuZXK Ozhg.klzMgnvpN9sEkVGNKSoSc5Q1Tkn0u.4faGHKTrUZSjXMKByoOjer59e 6JLjMweFfYuSWCGhQFfw_WIO32pv6zetR_no3Te91EOCP8jA2K75EYL9y5Hm t X-Yahoo-SMTP: OKD1keCswBBTAmAF1s00hLyKW3wE3YfSK0Eazl6b4VZG4LTqJxg- Message-ID: <53C6E9B3.1080402@att.net> Date: Wed, 16 Jul 2014 17:08:03 -0400 From: Anthony Jenkins User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Ian Smith Subject: atrtc.c patch for ACPI CMOS region (was Re: ACPI support - Freebsd 10 on Sony Vaio VPCCA3C5E) References: <53C020CE.8010205@att.net> <53C02604.9070207@att.net> <53C3D322.3080302@att.net> <20140716040719.Y50382@sola.nimnet.asn.au> <20140716143406.V50382@sola.nimnet.asn.au> <53C67D70.6060603@att.net> <20140717011710.W50382@sola.nimnet.asn.au> In-Reply-To: <20140717011710.W50382@sola.nimnet.asn.au> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@freebsd.org, Daniele Mazzotti X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jul 2014 21:11:36 -0000 On 07/16/2014 13:16, Ian Smith wrote: > On Wed, 16 Jul 2014 09:26:08 -0400, Anthony Jenkins wrote: > > On 07/16/2014 01:32, Daniele Mazzotti wrote: > >> Hi guys, thanks again for the support, but I am leaving for a > >> businesses trip and I will be forced to put this debug thing on hold > >> for a while. I will be back on track next week. > > > > Bah... really wanted to figure out the patch problem. I suspect the > > file picked up some corruption somewhere between the email and your > > FreeBSD filesystem. Your OS version has the same revision of that > > source file as mine, so it should apply cleanly. If you feel like > > tinkering with it in your free time, I've posted the patch here: > > http://pastebin.com/P0B44u0c > > > > Good luck, > > Anthony > > Either by show raw and save, or by download, the patch has ^M lineends. Bah! Well that'd explain it... I'm generating the file on a pure FreeBSD box, opened in gvim, select all, copy, paste to pastebin.com. > Interesting, but I can't see atrtc.c being the right sort of place for > this, seems way out of scope. Couldn't you include its headers and use > functions rtcin() and writertc() from elsewhere in kernel, perhaps a > module living in the same hierarchy as acpi_ibm, acpi_asus and such, > that one could build and kldload if useful on a certain machine/s? This is in support of the PNP0800 device, for which atrtc.c is the driver. The ACPI spec (5.0 is what I'm reading) says that device should implement a handler to read offset 0x00-0x7F. > If so, you haven't to do battle with Time Lords :) with something people > could add and load at own risk without messing with core kernel stuff. > > acpi_ibm should be a useful template, as it includes code to read CMOS > bytes in the 0x60-0x6f range, presumably updated by the BIOS, whether > opaquely or somehow via AML code I don't know. It uses rtcin() so has > that scope in place. > > I'd still like to see your patch reject attempts to read or write to at > least below 0x10. Even reading status register/s resets interrupts, and > why would anyone need to mess with clock and/or timer regs via ACPI? I assume it'd be the BIOS AML which would use my CMOS region handler; it'd be a BIOS bug that reads/writes the clock regs. > Have you found exactly which CMOS bytes your box needs to meddle with? I do have printf()s in my code (don't think I added it to the patch) that says what's read/written, I'll have to look again. > Maybe you could add a sysctl to limit access to some specific range? I dunno... I really think what I have is the Right Thing To Do... Someone else from freebsd-acpi@ suggested this approach. Maybe someone versed in ACPI could clarify from the spec? > Don't mind me, just thinking aloud, and I've no idea how this might > relate to Daniele's issue with stale battery data? Agreed... I'm pretty much just blindly tossing the patch over to her. :-) She did complain about suspend issues, and my patch fixes suspend issues on my HP and another guinea pig from the mailing list (with an HP). Next I need to figure out why acpi_hp doesn't work on my laptop, as I see SystemIO calls to 0x72/0x73 when I try to adjust the brightness. Thanks, Anthony > cheers, Ian > > PS Daniele: no, never tempted by Sonys; rusted-on Thinkpad kinda guy :) > _______________________________________________ > freebsd-acpi@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-acpi > To unsubscribe, send any mail to "freebsd-acpi-unsubscribe@freebsd.org" >