From owner-freebsd-acpi@FreeBSD.ORG Mon Mar 23 11:06:51 2009 Return-Path: Delivered-To: freebsd-acpi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9D25F106564A for ; Mon, 23 Mar 2009 11:06:51 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 8A5A98FC1B for ; Mon, 23 Mar 2009 11:06:51 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n2NB6ps4003908 for ; Mon, 23 Mar 2009 11:06:51 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n2NB6pBa003904 for freebsd-acpi@FreeBSD.org; Mon, 23 Mar 2009 11:06:51 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 23 Mar 2009 11:06:51 GMT Message-Id: <200903231106.n2NB6pBa003904@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 Cc: Subject: Current problem reports assigned to freebsd-acpi@FreeBSD.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 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 Mar 2009 11:06:52 -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/132602 acpi [acpi] ACPI Problem with Intel SS4200: System does not o kern/130683 acpi [ACPI] shutdown hangs after syncing disks - ACPI race? o i386/129953 acpi [acpi] ACPI timeout (CDROM) with Shuttle X27D o kern/129618 acpi [acpi] Problem with ACPI on HP Pavilion DV2899 laptop o kern/129563 acpi [acpi] sleep broken on IBM/Lenovo T61 in amd64 mode o kern/128639 acpi [patch] [acpi_asus] acpi for ASUS A6F,A3E,A3F,A3N not f kern/128634 acpi [patch] fix acpi_asus(4) in asus a6f laptop o kern/127581 acpi [patch] [acpi_sony] Add support for more Sony features o kern/124744 acpi [acpi] [patch] incorrect _BST result validation for To o kern/124412 acpi [acpi] power off error on Toshiba M40 laptop o kern/123039 acpi [acpi] ACPI AML_BUFFER_LIMIT errors during boot o kern/121504 acpi [patch] Correctly set hw.acpi.osname on certain machin f kern/121454 acpi [pst] Promise SuperTrak SX6000 does not load during bo o kern/121102 acpi [acpi_fujitsu] [patch] update acpi_fujitsu for the P80 o kern/120515 acpi [acpi] [patch] acpi_alloc_wakeup_handler: can't alloc o kern/119356 acpi [acpi]: i386 ACPI wakeup not work due resource exhaust o kern/119200 acpi [acpi] Lid close switch suspends CPU for 1 second on H o kern/118973 acpi [acpi]: Kernel panic with acpi boot o kern/117605 acpi [acpi] [request] add debug.cpufreq.highest o kern/116939 acpi [acpi] PCI-to-PCI misconfigured for bus three and can o i386/114562 acpi [acpi] cardbus is dead after s3 on Thinkpad T43 with a o kern/114165 acpi [acpi] Dell C810 - ACPI problem s kern/112544 acpi [acpi] [patch] Add High Precision Event Timer Driver f o kern/108954 acpi [acpi] 'sleep(1)' sleeps >1 seconds when speedstep (Cx o kern/108695 acpi [acpi]: Fatal trap 9: general protection fault when in o kern/108581 acpi [sysctl] sysctl: hw.acpi.cpu.cx_lowest: Invalid argume o kern/108488 acpi [acpi] ACPI-1304: *** Error: Method execution failed o kern/108017 acpi [acpi]: Acer Aspire 5600 o kern/106924 acpi [acpi] ACPI resume returns g_vfs_done() errors and ker o kern/105537 acpi [acpi] problems in acpi on HP Compaq nc6320 o kern/104625 acpi ACPI on ASUS A8N-32 SLI/ASUS P4P800 does not show ther o kern/102252 acpi acpi thermal does not work on Abit AW8D (intel 975) o kern/97383 acpi Volume buttons on IBM Thinkpad crash system with ACPI s i386/91748 acpi acpi problem on Acer TravelMare 4652LMi (nvidia panic, s kern/91038 acpi [panic] [ata] [acpi] 6.0-RELEASE on Fujitsu Siemens Am s kern/90243 acpi Laptop fan doesn't turn off (ACPI enabled) (Packard Be f kern/89411 acpi [acpi] acpiconf bug o i386/83018 acpi [install] Installer will not boot on Asus P4S8X BIOS 1 o kern/81000 acpi [apic] Via 8235 sound card worked great with FreeBSD 5 o i386/79081 acpi ACPI suspend/resume not working on HP nx6110 o kern/76950 acpi ACPI wrongly blacklisted on Micron ClientPro 766Xi sys s kern/73823 acpi [request] acpi / power-on by timer support o i386/72566 acpi ACPI, FreeBSD disables fan on Compaq Armada 1750 o i386/69750 acpi Boot without ACPI failed on ASUS L5 f kern/67309 acpi zzz reboot computer (ACPI S3) o kern/56024 acpi ACPI suspend drains battery while in S3 o i386/55661 acpi ACPI suspend/resume problem on ARMADA M700 o i386/54756 acpi ACPI suspend/resume problem on CF-W2 laptop 48 problems total. From owner-freebsd-acpi@FreeBSD.ORG Mon Mar 23 22:44:50 2009 Return-Path: Delivered-To: freebsd-acpi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 289FC1065670 for ; Mon, 23 Mar 2009 22:44:50 +0000 (UTC) (envelope-from cwhiteh@onetel.com) Received: from woodbine.london.02.net (woodbine.london.02.net [87.194.255.145]) by mx1.freebsd.org (Postfix) with ESMTP id E59C38FC1F for ; Mon, 23 Mar 2009 22:44:49 +0000 (UTC) (envelope-from cwhiteh@onetel.com) Received: from [192.168.1.75] (93.97.24.219) by woodbine.london.02.net (8.5.016.1) id 4979BCBF019750E0 for freebsd-acpi@FreeBSD.org; Mon, 23 Mar 2009 22:34:14 +0000 Message-ID: <49C80E65.9090500@onetel.com> Date: Mon, 23 Mar 2009 22:34:13 +0000 From: Chris Whitehouse User-Agent: Thunderbird 2.0.0.19 (X11/20090113) MIME-Version: 1.0 To: freebsd-acpi@FreeBSD.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: acpi_tz0: _CRT value is absurd, ignored (256.0C) (was pr kern/105537) X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 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 Mar 2009 22:44:50 -0000 Hi, I sent this a while ago but don't think there was a reply. I'm about to embark on a custom ASL to load in loader.conf as per http://www.freebsd.org/doc/en/books/handbook/acpi-debug.html but just wondering if their might be a 'proper' fix on the way. I do have the latest bios installed. Would it help if I installed 8-CURRENT? As below please would you cc me in any reply as I'm not subscribed. Thanks Chris -------- Original Message -------- Subject: pr kern/105537 Date: Mon, 12 Jan 2009 15:00:49 +0000 From: Chris Whitehouse To: freebsd-acpi@FreeBSD.org hi, Please would you cc me in any reply as I'm not subscribed, thanks. I have the same problem noted in http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/105537 of frequent messages saying acpi_tz0: _CRT value is absurd, ignored (256.0C) on my HP nc6320 laptop, model RH383ET. Is there any progress on this PR? Would it help if I arranged root access on this machine for someone to have a look at it? Currently has PCBSD but I can replace that with something else if required. FreeBSD muji 7.1-PRERELEASE FreeBSD 7.1-PRERELEASE #0: Mon Nov 24 20:22:16 EST 2008 root@pcbsdx32-7:/usr/obj/pcbsd-build/cvs/7.0.2-src/sys/PCBSD i386 thanks Chris From owner-freebsd-acpi@FreeBSD.ORG Mon Mar 23 23:36:10 2009 Return-Path: Delivered-To: freebsd-acpi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A5942106566C for ; Mon, 23 Mar 2009 23:36:10 +0000 (UTC) (envelope-from nate@root.org) Received: from nlpi015.prodigy.net (nlpi015.sbcis.sbc.com [207.115.36.44]) by mx1.freebsd.org (Postfix) with ESMTP id 794A18FC16 for ; Mon, 23 Mar 2009 23:36:10 +0000 (UTC) (envelope-from nate@root.org) Received: from [10.0.5.18] (ppp-71-139-10-86.dsl.snfc21.pacbell.net [71.139.10.86]) (authenticated bits=0) by nlpi015.prodigy.net (8.13.8 smtpauth/dk/map_regex/8.13.8) with ESMTP id n2NNPxc2006599; Mon, 23 Mar 2009 18:26:00 -0500 Message-ID: <49C81A84.7060004@root.org> Date: Mon, 23 Mar 2009 16:25:56 -0700 From: Nate Lawson User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Chris Whitehouse References: <49C80E65.9090500@onetel.com> In-Reply-To: <49C80E65.9090500@onetel.com> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@FreeBSD.org Subject: Re: acpi_tz0: _CRT value is absurd, ignored (256.0C) (was pr kern/105537) X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 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 Mar 2009 23:36:11 -0000 It's probably the EC timing out, not ASL. -Nate Chris Whitehouse wrote: > Hi, I sent this a while ago but don't think there was a reply. I'm about > to embark on a custom ASL to load in loader.conf as per > http://www.freebsd.org/doc/en/books/handbook/acpi-debug.html but just > wondering if their might be a 'proper' fix on the way. I do have the > latest bios installed. > > Would it help if I installed 8-CURRENT? > > As below please would you cc me in any reply as I'm not subscribed. > > Thanks > > Chris > > -------- Original Message -------- > Subject: pr kern/105537 > Date: Mon, 12 Jan 2009 15:00:49 +0000 > From: Chris Whitehouse > To: freebsd-acpi@FreeBSD.org > > hi, > > Please would you cc me in any reply as I'm not subscribed, thanks. > > I have the same problem noted in > > http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/105537 > > of frequent messages saying > > acpi_tz0: _CRT value is absurd, ignored (256.0C) > > on my HP nc6320 laptop, model RH383ET. > > Is there any progress on this PR? Would it help if I arranged root > access on this machine for someone to have a look at it? > > Currently has PCBSD but I can replace that with something else if required. > > FreeBSD muji 7.1-PRERELEASE FreeBSD 7.1-PRERELEASE #0: Mon Nov 24 > 20:22:16 EST 2008 > root@pcbsdx32-7:/usr/obj/pcbsd-build/cvs/7.0.2-src/sys/PCBSD i386 > > > thanks > > Chris > > _______________________________________________ > 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" -- Nate From owner-freebsd-acpi@FreeBSD.ORG Tue Mar 24 12:43:40 2009 Return-Path: Delivered-To: acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D71FD106567A for ; Tue, 24 Mar 2009 12:43:40 +0000 (UTC) (envelope-from invite+ppvicpif@facebookmail.com) Received: from mx-out.facebook.com (outmail018.snc1.tfbnw.net [69.63.178.177]) by mx1.freebsd.org (Postfix) with ESMTP id B4A908FC1A for ; Tue, 24 Mar 2009 12:43:40 +0000 (UTC) (envelope-from invite+ppvicpif@facebookmail.com) DKIM-Signature: v=1; a=rsa-sha1; d=facebookmail.com; s=q1-2009b; c=relaxed/relaxed; q=dns/txt; i=@facebookmail.com; t=1237897720; h=From:Subject:Date:To:MIME-Version:Content-Type; bh=JfGDVAWqIF+KN8u4K7Dpln96Oro=; b=Rv4PqIlqDw/eLHX+fWl23GkQHpXqzn1xsAVNsUFCiUKGvSDOgkMxynpcN75ApczT n5xEX+G026R8KwR5tXJZBQ==; Received: from [10.18.255.176] ([10.18.255.176:9896] helo=localhost.localdomain) by mta005.snc1.facebook.com (envelope-from ) (ecelerity 2.2.2.37 r(28805/28844)) with ESMTP id 1E/45-18605-8F1D8C94; Tue, 24 Mar 2009 05:28:40 -0700 X-Facebook: from zuckmail by localhost.localdomain with local (ZuckMail); Date: Tue, 24 Mar 2009 05:28:40 -0700 To: acpi@freebsd.org From: Vahid Chitsazzadeh Message-ID: <1f395b901198befac92278d23bf38254@localhost.localdomain> X-Priority: 3 X-Mailer: ZuckMail [version 1.00] X-Facebook-Notify: general_invite; mailid=32cf26G5fbc18d9G0G8 Errors-To: invite+ppvicpif@facebookmail.com X-FACEBOOK-PRIORITY: 1 MIME-Version: 1.0 Content-Type: text/plain; charset = "UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Check out my photos on Facebook X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Vahid Chitsazzadeh List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 12:43:42 -0000 I set up a Facebook profile where I can post my pictures, videos and events and I want to add you as a friend so you can see it. First, you need to join Facebook! Once you join, you can also create your own profile. ---------- hello! ---------- Thanks, Vahid To sign up for Facebook, follow the link below: http://www.facebook.com/p.php?i=3D1485341899&k=3D5VCUZ2U23ZVM5DDFPD4ZU4&r This e-mail may contain promotional materials. If you do not wish to receive future commercial mailings from Facebook, please click on the link below. Facebook's offices are located at 156 University Ave., Palo Alto, CA 94301. http://www.facebook.com/o.php?k=3De1b487&u=3D1606162649&mid=3D32cf26G5fbc18d9G0G8 From owner-freebsd-acpi@FreeBSD.ORG Tue Mar 24 13:33:59 2009 Return-Path: Delivered-To: freebsd-acpi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B7BC21065670 for ; Tue, 24 Mar 2009 13:33:59 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id EDF048FC08 for ; Tue, 24 Mar 2009 13:33:58 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id PAA01668 for ; Tue, 24 Mar 2009 15:33:56 +0200 (EET) (envelope-from avg@icyb.net.ua) Message-ID: <49C8E143.2080305@icyb.net.ua> Date: Tue, 24 Mar 2009 15:33:55 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.19 (X11/20090110) MIME-Version: 1.0 To: freebsd-acpi@FreeBSD.org X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Subject: shutdown via power button: "acpi: resumed at..." X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 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 Mar 2009 13:34:00 -0000 I noticed that sometimes I am getting "acpi: resumed at..." message on console and in system log when I initiate system shutdown by pressing power button. I think that the cause is in acpi_UserNotify("Resume") call and this call is only found in acpi_EnterSleepState(). I see the following code in that function: case ACPI_STATE_S5: /* * Shut down cleanly and power off. This will call us back through the * shutdown handlers. */ shutdown_nice(RB_POWEROFF); break; So it seems that it is expected that shutdown_nice() would return immediately. I think it makes S5 a special case comparing to other states where return happens upon resuming from the state. In this case, maybe it is not necessary for S5 request to go through the resume/wakeup half of acpi_EnterSleepState. -- Andriy Gapon From owner-freebsd-acpi@FreeBSD.ORG Tue Mar 24 19:40:07 2009 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DC1F210659D5 for ; Tue, 24 Mar 2009 19:40:07 +0000 (UTC) (envelope-from pasi.parviainen@iki.fi) Received: from smtp3.dnainternet.fi (smtp3.dnainternet.fi [87.94.96.71]) by mx1.freebsd.org (Postfix) with ESMTP id 5D82D8FC23 for ; Tue, 24 Mar 2009 19:40:07 +0000 (UTC) (envelope-from pasi.parviainen@iki.fi) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp3.dnainternet.fi (Postfix) with ESMTP id 4ADA74938087; Tue, 24 Mar 2009 21:22:24 +0200 (EET) X-Virus-Scanned: DNA Postiturva at dnainternet.net X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-100 required=7 tests=[RDNS_DYNAMIC=0] autolearn=disabled Received: from [192.168.0.2] (87-94-148-28.tampere.customers.dnainternet.fi [87.94.148.28]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp3.dnainternet.fi (Postfix) with ESMTPS; Tue, 24 Mar 2009 21:22:22 +0200 (EET) Message-ID: <49C93309.6050708@iki.fi> Date: Tue, 24 Mar 2009 21:22:49 +0200 From: Pasi Parviainen User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Chris Whitehouse References: <49C80E65.9090500@onetel.com> In-Reply-To: <49C80E65.9090500@onetel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@freebsd.org Subject: Re: acpi_tz0: _CRT value is absurd, ignored (256.0C) (was pr kern/105537) X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 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 Mar 2009 19:40:10 -0000 Chris Whitehouse wrote: > Hi, I sent this a while ago but don't think there was a reply. I'm about > to embark on a custom ASL to load in loader.conf as per > http://www.freebsd.org/doc/en/books/handbook/acpi-debug.html but just > wondering if their might be a 'proper' fix on the way. I do have the > latest bios installed. Loading custom ASL with modified _CRT value for temperature zone in question will solve the problem, see below for more information. > Would it help if I installed 8-CURRENT? Probably not, see below. > -------- Original Message -------- > Subject: pr kern/105537 > Date: Mon, 12 Jan 2009 15:00:49 +0000 > From: Chris Whitehouse > To: freebsd-acpi@FreeBSD.org > > hi, > > Please would you cc me in any reply as I'm not subscribed, thanks. > > I have the same problem noted in > > http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/105537 > > of frequent messages saying > > acpi_tz0: _CRT value is absurd, ignored (256.0C) > > on my HP nc6320 laptop, model RH383ET. > I have HP 6510b and HP 2510p laptops and had same problem with those. Actual problem is that the ACPI thermal code in kernel does sanity-check for temperature values, and accepts only values between 0 - 200 Celsius. To solve the problem you either create custom DSDT which returns 200.0C value instead of 256.0C for thermal zone in question or increase the limit of the sanity-check code of ACPI thermal code (src/sys/dev/acpica/acpi_thermal.c function: acpi_tz_sanity). Proper way to solve this in my opinion is to increase the range of sanity-check function from 0 - 200 Celsius to 0 - 256 Celsius, or at least provide sysctl variable to disable thermal sanity-checks. From owner-freebsd-acpi@FreeBSD.ORG Wed Mar 25 03:30:11 2009 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8F10C106566B for ; Wed, 25 Mar 2009 03:30:11 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [220.233.188.227]) by mx1.freebsd.org (Postfix) with ESMTP id E0B9E8FC14 for ; Wed, 25 Mar 2009 03:30:10 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id n2P3JPST048523; Wed, 25 Mar 2009 14:19:25 +1100 (EST) (envelope-from smithi@nimnet.asn.au) Date: Wed, 25 Mar 2009 14:19:24 +1100 (EST) From: Ian Smith To: Pasi Parviainen In-Reply-To: <49C93309.6050708@iki.fi> Message-ID: <20090325140718.J95588@sola.nimnet.asn.au> References: <49C80E65.9090500@onetel.com> <49C93309.6050708@iki.fi> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: freebsd-acpi@freebsd.org, Chris Whitehouse Subject: Re: acpi_tz0: _CRT value is absurd, ignored (256.0C) (was pr kern/105537) X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 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 Mar 2009 03:30:12 -0000 On Tue, 24 Mar 2009, Pasi Parviainen wrote: > Chris Whitehouse wrote: > > Hi, I sent this a while ago but don't think there was a reply. I'm about to > > embark on a custom ASL to load in loader.conf as per > > http://www.freebsd.org/doc/en/books/handbook/acpi-debug.html but just > > wondering if their might be a 'proper' fix on the way. I do have the latest > > bios installed. > > Loading custom ASL with modified _CRT value for temperature zone in > question will solve the problem, see below for more information. > > > Would it help if I installed 8-CURRENT? > > Probably not, see below. > > > -------- Original Message -------- > > Subject: pr kern/105537 > > Date: Mon, 12 Jan 2009 15:00:49 +0000 > > From: Chris Whitehouse > > To: freebsd-acpi@FreeBSD.org > > > > hi, > > > > Please would you cc me in any reply as I'm not subscribed, thanks. > > > > I have the same problem noted in > > > > http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/105537 > > > > of frequent messages saying > > > > acpi_tz0: _CRT value is absurd, ignored (256.0C) > > > > on my HP nc6320 laptop, model RH383ET. > > > > I have HP 6510b and HP 2510p laptops and had same problem with those. > Actual problem is that the ACPI thermal code in kernel does sanity-check > for temperature values, and accepts only values between 0 - 200 Celsius. > To solve the problem you either create custom DSDT which returns 200.0C > value instead of 256.0C for thermal zone in question or increase the limit of > the sanity-check code of ACPI thermal code (src/sys/dev/acpica/acpi_thermal.c > function: acpi_tz_sanity). > > Proper way to solve this in my opinion is to increase the range of > sanity-check function from 0 - 200 Celsius to 0 - 256 Celsius, or at > least provide sysctl variable to disable thermal sanity-checks. Even 200C is absurd, really. That's above the melting point of many types of solder (http://www.rfcafe.com/references/electrical/solder.htm) while 256C exceeds the melting point of _most_ types of solder. I seem to recall that this limit used to be 150C, still hotter than anything you actually want to have anywhere on a computer board. No sense checking sanity to then accept insane values; fix the broken ASL. 256 sounds suspiciously like a byte-swapped value, perhaps? cheers, Ian From owner-freebsd-acpi@FreeBSD.ORG Wed Mar 25 08:30:23 2009 Return-Path: Delivered-To: freebsd-acpi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 13359106566C for ; Wed, 25 Mar 2009 08:30:23 +0000 (UTC) (envelope-from cwhiteh@onetel.com) Received: from honeysuckle.london.02.net (honeysuckle.london.02.net [87.194.255.144]) by mx1.freebsd.org (Postfix) with ESMTP id A59A48FC1A for ; Wed, 25 Mar 2009 08:30:22 +0000 (UTC) (envelope-from cwhiteh@onetel.com) Received: from [192.168.1.75] (93.97.24.219) by honeysuckle.london.02.net (8.5.016.1) id 497A2AF001970505; Wed, 25 Mar 2009 08:30:20 +0000 Message-ID: <49C9EB9B.4020601@onetel.com> Date: Wed, 25 Mar 2009 08:30:19 +0000 From: Chris Whitehouse User-Agent: Thunderbird 2.0.0.19 (X11/20090113) MIME-Version: 1.0 To: Nate Lawson References: <49C80E65.9090500@onetel.com> <49C81A84.7060004@root.org> In-Reply-To: <49C81A84.7060004@root.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@FreeBSD.org Subject: Re: acpi_tz0: _CRT value is absurd, ignored (256.0C) (was pr kern/105537) X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 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 Mar 2009 08:30:23 -0000 Nate Lawson wrote: > It's probably the EC timing out, not ASL. > > -Nate Someone on questions@ noted recently he had fixed something very similar with a custom ASL so I thought I would have a go. What is EC? Chris > > Chris Whitehouse wrote: >> Hi, I sent this a while ago but don't think there was a reply. I'm about >> to embark on a custom ASL to load in loader.conf as per >> http://www.freebsd.org/doc/en/books/handbook/acpi-debug.html but just >> wondering if their might be a 'proper' fix on the way. I do have the >> latest bios installed. >> >> Would it help if I installed 8-CURRENT? >> >> As below please would you cc me in any reply as I'm not subscribed. >> >> Thanks >> >> Chris >> >> -------- Original Message -------- >> Subject: pr kern/105537 >> Date: Mon, 12 Jan 2009 15:00:49 +0000 >> From: Chris Whitehouse >> To: freebsd-acpi@FreeBSD.org >> >> hi, >> >> Please would you cc me in any reply as I'm not subscribed, thanks. >> >> I have the same problem noted in >> >> http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/105537 >> >> of frequent messages saying >> >> acpi_tz0: _CRT value is absurd, ignored (256.0C) >> >> on my HP nc6320 laptop, model RH383ET. >> >> Is there any progress on this PR? Would it help if I arranged root >> access on this machine for someone to have a look at it? >> >> Currently has PCBSD but I can replace that with something else if required. >> >> FreeBSD muji 7.1-PRERELEASE FreeBSD 7.1-PRERELEASE #0: Mon Nov 24 >> 20:22:16 EST 2008 >> root@pcbsdx32-7:/usr/obj/pcbsd-build/cvs/7.0.2-src/sys/PCBSD i386 >> >> >> thanks >> >> Chris >> >> _______________________________________________ >> 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 Mar 25 08:42:07 2009 Return-Path: Delivered-To: freebsd-acpi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 50C081065670 for ; Wed, 25 Mar 2009 08:42:07 +0000 (UTC) (envelope-from cwhiteh@onetel.com) Received: from honeysuckle.london.02.net (honeysuckle.london.02.net [87.194.255.144]) by mx1.freebsd.org (Postfix) with ESMTP id E3FBE8FC19 for ; Wed, 25 Mar 2009 08:42:06 +0000 (UTC) (envelope-from cwhiteh@onetel.com) Received: from [192.168.1.75] (93.97.24.219) by honeysuckle.london.02.net (8.5.016.1) id 497A2AF001971EAE; Wed, 25 Mar 2009 08:41:52 +0000 Message-ID: <49C9EE50.6070507@onetel.com> Date: Wed, 25 Mar 2009 08:41:52 +0000 From: Chris Whitehouse User-Agent: Thunderbird 2.0.0.19 (X11/20090113) MIME-Version: 1.0 To: Ian Smith , freebsd-acpi@FreeBSD.org References: <49C80E65.9090500@onetel.com> <49C93309.6050708@iki.fi> <20090325140718.J95588@sola.nimnet.asn.au> In-Reply-To: <20090325140718.J95588@sola.nimnet.asn.au> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: acpi_tz0: _CRT value is absurd, ignored (256.0C) (was pr kern/105537) X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 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 Mar 2009 08:42:07 -0000 [Please would you cc me in any reply as I'm not subscribed, thanks.] Ian Smith wrote: > On Tue, 24 Mar 2009, Pasi Parviainen wrote: > > Chris Whitehouse wrote: > > > Hi, I sent this a while ago but don't think there was a reply. I'm about to > > > embark on a custom ASL to load in loader.conf as per > > > http://www.freebsd.org/doc/en/books/handbook/acpi-debug.html but just > > > wondering if their might be a 'proper' fix on the way. I do have the latest > > > bios installed. > > > > Loading custom ASL with modified _CRT value for temperature zone in > > question will solve the problem, see below for more information. > > > > > Would it help if I installed 8-CURRENT? > > > > Probably not, see below. > > > > > -------- Original Message -------- > > > Subject: pr kern/105537 > > > Date: Mon, 12 Jan 2009 15:00:49 +0000 > > > From: Chris Whitehouse > > > To: freebsd-acpi@FreeBSD.org > > > > > > hi, > > > > > > Please would you cc me in any reply as I'm not subscribed, thanks. > > > > > > I have the same problem noted in > > > > > > http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/105537 > > > > > > of frequent messages saying > > > > > > acpi_tz0: _CRT value is absurd, ignored (256.0C) > > > > > > on my HP nc6320 laptop, model RH383ET. > > > > > > > I have HP 6510b and HP 2510p laptops and had same problem with those. > > Actual problem is that the ACPI thermal code in kernel does sanity-check > > for temperature values, and accepts only values between 0 - 200 Celsius. > > To solve the problem you either create custom DSDT which returns 200.0C > > value instead of 256.0C for thermal zone in question or increase the limit of > > the sanity-check code of ACPI thermal code (src/sys/dev/acpica/acpi_thermal.c > > function: acpi_tz_sanity). > > > > Proper way to solve this in my opinion is to increase the range of > > sanity-check function from 0 - 200 Celsius to 0 - 256 Celsius, or at > > least provide sysctl variable to disable thermal sanity-checks. > > Even 200C is absurd, really. That's above the melting point of many > types of solder (http://www.rfcafe.com/references/electrical/solder.htm) > while 256C exceeds the melting point of _most_ types of solder. I seem > to recall that this limit used to be 150C, still hotter than anything > you actually want to have anywhere on a computer board. > > No sense checking sanity to then accept insane values; fix the broken > ASL. 256 sounds suspiciously like a byte-swapped value, perhaps? > > cheers, Ian > Getting the ASL in the actual BIOS firmware fixed would be great, but I tried once to get Asus to correct a byte swapped value without success. I don't suppose HP will be any more cooperative but I can try. I will have a look at an acpidump tonight. A custom ASL would at least prove what is wrong. Does anyone know what this value is supposed to be measuring? Chris From owner-freebsd-acpi@FreeBSD.ORG Wed Mar 25 10:02:25 2009 Return-Path: Delivered-To: freebsd-acpi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 43A4A10656C0 for ; Wed, 25 Mar 2009 10:02:25 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [220.233.188.227]) by mx1.freebsd.org (Postfix) with ESMTP id 9454A8FC2D for ; Wed, 25 Mar 2009 10:02:24 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id n2PA2Mne062479; Wed, 25 Mar 2009 21:02:23 +1100 (EST) (envelope-from smithi@nimnet.asn.au) Date: Wed, 25 Mar 2009 21:02:22 +1100 (EST) From: Ian Smith To: Chris Whitehouse In-Reply-To: <49C9EE50.6070507@onetel.com> Message-ID: <20090325203237.F95588@sola.nimnet.asn.au> References: <49C80E65.9090500@onetel.com> <49C93309.6050708@iki.fi> <20090325140718.J95588@sola.nimnet.asn.au> <49C9EE50.6070507@onetel.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: freebsd-acpi@FreeBSD.org Subject: Re: acpi_tz0: _CRT value is absurd, ignored (256.0C) (was pr kern/105537) X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 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 Mar 2009 10:02:26 -0000 On Wed, 25 Mar 2009, Chris Whitehouse wrote: > Getting the ASL in the actual BIOS firmware fixed would be great, but I tried > once to get Asus to correct a byte swapped value without success. I don't > suppose HP will be any more cooperative but I can try. I will have a look at > an acpidump tonight. A custom ASL would at least prove what is wrong. Well, it might fix it, too .. unless Nate's suspicion about the Embedded Controller timing out is right. I don't know how that might be fixed. > Does anyone know what this value is supposed to be measuring? Maybe sysctl hw.acpi.thermal would provide a clue? cheers, Ian From owner-freebsd-acpi@FreeBSD.ORG Wed Mar 25 15:05:44 2009 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 966271065701 for ; Wed, 25 Mar 2009 15:05:44 +0000 (UTC) (envelope-from gaijin.k@gmail.com) Received: from mail-gx0-f224.google.com (mail-gx0-f224.google.com [209.85.217.224]) by mx1.freebsd.org (Postfix) with ESMTP id 40FCF8FC18 for ; Wed, 25 Mar 2009 15:05:43 +0000 (UTC) (envelope-from gaijin.k@gmail.com) Received: by gxk24 with SMTP id 24so209569gxk.19 for ; Wed, 25 Mar 2009 08:05:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:from:to:cc :in-reply-to:references:content-type:date:message-id:mime-version :x-mailer:content-transfer-encoding; bh=aZAuLsAoJfh/APNIjsYqxAdpO/dr0hvixmef+8YW8Bg=; b=OGyNSTKNU3I+DxlLyoHvbVJXpC5A7wmJ2Nvfg7762nNv18xiJ/u6iW2191Ng4cVTmk altqYG3OA4DyoHJ9HphEAChFYlHMsSlw31+Y8wH7R16XbVpjQZndr/vcLbNc25Kiamo9 QBEYCcvfR2IyACEhnMJj5zbblsBc3O3HZGQHA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:from:to:cc:in-reply-to:references:content-type:date :message-id:mime-version:x-mailer:content-transfer-encoding; b=dK2NlYlyhnogIf8mucD6TZz0v0nVvXsww8n3rxrC0EjWD26dPgVUWG+swnadd/3hc/ XAe7T5ib7rqWd+neUquMIgN2mZJHn/XP00rMDhZ52ZAWkH7yF2/2CA8/PgFtddUw4ZOP fEsnBgeu8+1Jooykz5VcNhqlXfPkvgmTRRRk0= Received: by 10.90.26.10 with SMTP id 10mr2411829agz.99.1237993542804; Wed, 25 Mar 2009 08:05:42 -0700 (PDT) Received: from ?10.0.3.231? (pool-71-250-44-232.nwrknj.east.verizon.net [71.250.44.232]) by mx.google.com with ESMTPS id 2sm1728762aga.78.2009.03.25.08.05.41 (version=SSLv3 cipher=RC4-MD5); Wed, 25 Mar 2009 08:05:42 -0700 (PDT) From: "Alexandre \"Sunny\" Kovalenko" To: Chris Whitehouse In-Reply-To: <49C9EE50.6070507@onetel.com> References: <49C80E65.9090500@onetel.com> <49C93309.6050708@iki.fi> <20090325140718.J95588@sola.nimnet.asn.au> <49C9EE50.6070507@onetel.com> Content-Type: text/plain Date: Wed, 25 Mar 2009 10:47:42 -0400 Message-Id: <1237992462.1297.22.camel@RabbitsDen> Mime-Version: 1.0 X-Mailer: Evolution 2.24.5 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@FreeBSD.org, Ian Smith Subject: Re: acpi_tz0: _CRT value is absurd, ignored (256.0C) (was pr kern/105537) X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 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 Mar 2009 15:05:47 -0000 On Wed, 2009-03-25 at 08:41 +0000, Chris Whitehouse wrote: > [Please would you cc me in any reply as I'm not subscribed, thanks.] > > Ian Smith wrote: > > On Tue, 24 Mar 2009, Pasi Parviainen wrote: > > > Chris Whitehouse wrote: > > > > Hi, I sent this a while ago but don't think there was a reply. I'm about to > > > > embark on a custom ASL to load in loader.conf as per > > > > http://www.freebsd.org/doc/en/books/handbook/acpi-debug.html but just > > > > wondering if their might be a 'proper' fix on the way. I do have the latest > > > > bios installed. > > > > > > Loading custom ASL with modified _CRT value for temperature zone in > > > question will solve the problem, see below for more information. > > > > > > > Would it help if I installed 8-CURRENT? > > > > > > Probably not, see below. > > > > > > > -------- Original Message -------- > > > > Subject: pr kern/105537 > > > > Date: Mon, 12 Jan 2009 15:00:49 +0000 > > > > From: Chris Whitehouse > > > > To: freebsd-acpi@FreeBSD.org > > > > > > > > hi, > > > > > > > > Please would you cc me in any reply as I'm not subscribed, thanks. > > > > > > > > I have the same problem noted in > > > > > > > > http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/105537 > > > > > > > > of frequent messages saying > > > > > > > > acpi_tz0: _CRT value is absurd, ignored (256.0C) > > > > > > > > on my HP nc6320 laptop, model RH383ET. > > > > > > > > > > I have HP 6510b and HP 2510p laptops and had same problem with those. > > > Actual problem is that the ACPI thermal code in kernel does sanity-check > > > for temperature values, and accepts only values between 0 - 200 Celsius. > > > To solve the problem you either create custom DSDT which returns 200.0C > > > value instead of 256.0C for thermal zone in question or increase the limit of > > > the sanity-check code of ACPI thermal code (src/sys/dev/acpica/acpi_thermal.c > > > function: acpi_tz_sanity). > > > > > > Proper way to solve this in my opinion is to increase the range of > > > sanity-check function from 0 - 200 Celsius to 0 - 256 Celsius, or at > > > least provide sysctl variable to disable thermal sanity-checks. > > > > Even 200C is absurd, really. That's above the melting point of many > > types of solder (http://www.rfcafe.com/references/electrical/solder.htm) > > while 256C exceeds the melting point of _most_ types of solder. I seem > > to recall that this limit used to be 150C, still hotter than anything > > you actually want to have anywhere on a computer board. > > > > No sense checking sanity to then accept insane values; fix the broken > > ASL. 256 sounds suspiciously like a byte-swapped value, perhaps? > > > > cheers, Ian > > > > Getting the ASL in the actual BIOS firmware fixed would be great, but I > tried once to get Asus to correct a byte swapped value without success. > I don't suppose HP will be any more cooperative but I can try. I will > have a look at an acpidump tonight. A custom ASL would at least prove > what is wrong. > > Does anyone know what this value is supposed to be measuring? _CRT method in ASL is supposed to return temperature (in the tenth of Kelvin) at which you would like to have your computer shut down rather rapidly. On my ThinkPad X60 it is 97C. Overriding ASL is simple, if you are following the instruction in the "Handbook", but the ease of fixing it really depends on what is broken. Your case does not seem to look like the most popular exercise by the BIOS writers -- returning temperature in the whole degrees of Celsius, resulting in absurd negative values. If you would like to post your ASL someplace and send out link to it or forward it to me privately, I can take a look at it. I make no promises -- unless it is something obvious it will require understanding of your specific hardware. To be fair, if all you want is to override _CRT, you should be able to put something to the tune of hw.acpi.thermal.user_override=1 hw.acpi.thermal.tz0._CRT=90C in your /etc/sysctl.conf and not deal with the ASL at all. You might want to take a look at your output of 'sysctl hw.acpi.thermal' -- your specific thermal zone, might be different from the one, I have used as an example above. In fact, on my laptop, it is tz1 and not tz0. In either case, I would recommend reading thermal chapter of the ACPI specification -- it is short, well-written and has an example, I was stealing stuff from, shamelessly, in the past. HTH, -- Alexandre "Sunny" Kovalenko From owner-freebsd-acpi@FreeBSD.ORG Wed Mar 25 16:06:39 2009 Return-Path: Delivered-To: freebsd-acpi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C7A12106571B for ; Wed, 25 Mar 2009 16:06:39 +0000 (UTC) (envelope-from nate@root.org) Received: from nlpi043.prodigy.net (nlpi043.sbcis.sbc.com [207.115.36.72]) by mx1.freebsd.org (Postfix) with ESMTP id 2B7A88FC1D for ; Wed, 25 Mar 2009 16:06:38 +0000 (UTC) (envelope-from nate@root.org) Received: from [10.0.5.18] (ppp-71-139-16-151.dsl.snfc21.pacbell.net [71.139.16.151]) (authenticated bits=0) by nlpi043.prodigy.net (8.13.8 smtpauth/dk/map_regex/8.13.8) with ESMTP id n2PG6ZGH028081; Wed, 25 Mar 2009 11:06:36 -0500 Message-ID: <49CA568B.6030305@root.org> Date: Wed, 25 Mar 2009 09:06:35 -0700 From: Nate Lawson User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: "Alexandre \"Sunny\" Kovalenko" References: <49C80E65.9090500@onetel.com> <49C93309.6050708@iki.fi> <20090325140718.J95588@sola.nimnet.asn.au> <49C9EE50.6070507@onetel.com> <1237992462.1297.22.camel@RabbitsDen> In-Reply-To: <1237992462.1297.22.camel@RabbitsDen> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@FreeBSD.org, Ian Smith , Chris Whitehouse Subject: Re: acpi_tz0: _CRT value is absurd, ignored (256.0C) (was pr kern/105537) X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 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 Mar 2009 16:06:41 -0000 Alexandre "Sunny" Kovalenko wrote: > On Wed, 2009-03-25 at 08:41 +0000, Chris Whitehouse wrote: >> [Please would you cc me in any reply as I'm not subscribed, thanks.] >> >> Ian Smith wrote: >>> On Tue, 24 Mar 2009, Pasi Parviainen wrote: >>> > Chris Whitehouse wrote: >>> > > Hi, I sent this a while ago but don't think there was a reply. I'm about to >>> > > embark on a custom ASL to load in loader.conf as per >>> > > http://www.freebsd.org/doc/en/books/handbook/acpi-debug.html but just >>> > > wondering if their might be a 'proper' fix on the way. I do have the latest >>> > > bios installed. >>> > >>> > Loading custom ASL with modified _CRT value for temperature zone in >>> > question will solve the problem, see below for more information. >>> > >>> > > Would it help if I installed 8-CURRENT? >>> > >>> > Probably not, see below. >>> > >>> > > -------- Original Message -------- >>> > > Subject: pr kern/105537 >>> > > Date: Mon, 12 Jan 2009 15:00:49 +0000 >>> > > From: Chris Whitehouse >>> > > To: freebsd-acpi@FreeBSD.org >>> > > >>> > > hi, >>> > > >>> > > Please would you cc me in any reply as I'm not subscribed, thanks. >>> > > >>> > > I have the same problem noted in >>> > > >>> > > http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/105537 >>> > > >>> > > of frequent messages saying >>> > > >>> > > acpi_tz0: _CRT value is absurd, ignored (256.0C) >>> > > >>> > > on my HP nc6320 laptop, model RH383ET. >>> > > >>> > >>> > I have HP 6510b and HP 2510p laptops and had same problem with those. >>> > Actual problem is that the ACPI thermal code in kernel does sanity-check >>> > for temperature values, and accepts only values between 0 - 200 Celsius. >>> > To solve the problem you either create custom DSDT which returns 200.0C >>> > value instead of 256.0C for thermal zone in question or increase the limit of >>> > the sanity-check code of ACPI thermal code (src/sys/dev/acpica/acpi_thermal.c >>> > function: acpi_tz_sanity). >>> > >>> > Proper way to solve this in my opinion is to increase the range of >>> > sanity-check function from 0 - 200 Celsius to 0 - 256 Celsius, or at >>> > least provide sysctl variable to disable thermal sanity-checks. >>> >>> Even 200C is absurd, really. That's above the melting point of many >>> types of solder (http://www.rfcafe.com/references/electrical/solder.htm) >>> while 256C exceeds the melting point of _most_ types of solder. I seem >>> to recall that this limit used to be 150C, still hotter than anything >>> you actually want to have anywhere on a computer board. >>> >>> No sense checking sanity to then accept insane values; fix the broken >>> ASL. 256 sounds suspiciously like a byte-swapped value, perhaps? >>> >>> cheers, Ian >>> >> Getting the ASL in the actual BIOS firmware fixed would be great, but I >> tried once to get Asus to correct a byte swapped value without success. >> I don't suppose HP will be any more cooperative but I can try. I will >> have a look at an acpidump tonight. A custom ASL would at least prove >> what is wrong. >> >> Does anyone know what this value is supposed to be measuring? > _CRT method in ASL is supposed to return temperature (in the tenth of > Kelvin) at which you would like to have your computer shut down rather > rapidly. On my ThinkPad X60 it is 97C. > > To be fair, if all you want is to override _CRT, you should be able to > put something to the tune of > > hw.acpi.thermal.user_override=1 > hw.acpi.thermal.tz0._CRT=90C > > in your /etc/sysctl.conf and not deal with the ASL at all. Yes, this is the best way instead of messing with ASL. -- Nate From owner-freebsd-acpi@FreeBSD.ORG Wed Mar 25 16:08:13 2009 Return-Path: Delivered-To: freebsd-acpi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 265D810656ED for ; Wed, 25 Mar 2009 16:08:08 +0000 (UTC) (envelope-from nate@root.org) Received: from nlpi043.prodigy.net (nlpi043.sbcis.sbc.com [207.115.36.72]) by mx1.freebsd.org (Postfix) with ESMTP id 25BEC8FC23 for ; Wed, 25 Mar 2009 16:08:08 +0000 (UTC) (envelope-from nate@root.org) Received: from [10.0.5.18] (ppp-71-139-16-151.dsl.snfc21.pacbell.net [71.139.16.151]) (authenticated bits=0) by nlpi043.prodigy.net (8.13.8 smtpauth/dk/map_regex/8.13.8) with ESMTP id n2PG868F028931; Wed, 25 Mar 2009 11:08:06 -0500 Message-ID: <49CA56E6.3030509@root.org> Date: Wed, 25 Mar 2009 09:08:06 -0700 From: Nate Lawson User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Chris Whitehouse References: <49C80E65.9090500@onetel.com> <49C81A84.7060004@root.org> <49C9EB9B.4020601@onetel.com> In-Reply-To: <49C9EB9B.4020601@onetel.com> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@FreeBSD.org Subject: Re: acpi_tz0: _CRT value is absurd, ignored (256.0C) (was pr kern/105537) X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 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 Mar 2009 16:08:14 -0000 Chris Whitehouse wrote: > Nate Lawson wrote: >> It's probably the EC timing out, not ASL. >> >> -Nate > > Someone on questions@ noted recently he had fixed something very similar > with a custom ASL so I thought I would have a go. What is EC? > > Chris I misread the original message. _CRT is usually not reported by the embedded controller. It is hard-coded. If you saw a stray temperature reading that was incorrect, that is probably the EC. -- Nate From owner-freebsd-acpi@FreeBSD.ORG Wed Mar 25 16:12:21 2009 Return-Path: Delivered-To: freebsd-acpi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3A5F6106564A for ; Wed, 25 Mar 2009 16:12:21 +0000 (UTC) (envelope-from nate@root.org) Received: from nlpi043.prodigy.net (nlpi043.sbcis.sbc.com [207.115.36.72]) by mx1.freebsd.org (Postfix) with ESMTP id 0EB4B8FC08 for ; Wed, 25 Mar 2009 16:12:20 +0000 (UTC) (envelope-from nate@root.org) Received: from [10.0.5.18] (ppp-71-139-16-151.dsl.snfc21.pacbell.net [71.139.16.151]) (authenticated bits=0) by nlpi043.prodigy.net (8.13.8 smtpauth/dk/map_regex/8.13.8) with ESMTP id n2PGCIjp031533; Wed, 25 Mar 2009 11:12:19 -0500 Message-ID: <49CA57E2.7090805@root.org> Date: Wed, 25 Mar 2009 09:12:18 -0700 From: Nate Lawson User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Andriy Gapon References: <49C8E143.2080305@icyb.net.ua> In-Reply-To: <49C8E143.2080305@icyb.net.ua> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@FreeBSD.org Subject: Re: shutdown via power button: "acpi: resumed at..." X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 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 Mar 2009 16:12:21 -0000 Andriy Gapon wrote: > I noticed that sometimes I am getting "acpi: resumed at..." message on console and > in system log when I initiate system shutdown by pressing power button. > I think that the cause is in acpi_UserNotify("Resume") call and this call is only > found in acpi_EnterSleepState(). > > I see the following code in that function: > case ACPI_STATE_S5: > /* > * Shut down cleanly and power off. This will call us back through the > * shutdown handlers. > */ > shutdown_nice(RB_POWEROFF); > break; > > So it seems that it is expected that shutdown_nice() would return immediately. > I think it makes S5 a special case comparing to other states where return happens > upon resuming from the state. > In this case, maybe it is not necessary for S5 request to go through the > resume/wakeup half of acpi_EnterSleepState. > I thought shutdown*() should never return at all. It sounds like interrupts are being re-enabled or something. -- Nate From owner-freebsd-acpi@FreeBSD.ORG Wed Mar 25 16:24:47 2009 Return-Path: Delivered-To: freebsd-acpi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A81A1106567B for ; Wed, 25 Mar 2009 16:24:47 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id DD5AA8FC12 for ; Wed, 25 Mar 2009 16:24:46 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id SAA17710; Wed, 25 Mar 2009 18:24:42 +0200 (EET) (envelope-from avg@icyb.net.ua) Message-ID: <49CA5AC9.1040601@icyb.net.ua> Date: Wed, 25 Mar 2009 18:24:41 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.21 (X11/20090323) MIME-Version: 1.0 To: Nate Lawson References: <49C8E143.2080305@icyb.net.ua> <49CA57E2.7090805@root.org> In-Reply-To: <49CA57E2.7090805@root.org> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@FreeBSD.org Subject: Re: shutdown via power button: "acpi: resumed at..." X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 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 Mar 2009 16:24:49 -0000 on 25/03/2009 18:12 Nate Lawson said the following: > Andriy Gapon wrote: >> I noticed that sometimes I am getting "acpi: resumed at..." message on console and >> in system log when I initiate system shutdown by pressing power button. >> I think that the cause is in acpi_UserNotify("Resume") call and this call is only >> found in acpi_EnterSleepState(). >> >> I see the following code in that function: >> case ACPI_STATE_S5: >> /* >> * Shut down cleanly and power off. This will call us back through the >> * shutdown handlers. >> */ >> shutdown_nice(RB_POWEROFF); >> break; >> >> So it seems that it is expected that shutdown_nice() would return immediately. >> I think it makes S5 a special case comparing to other states where return happens >> upon resuming from the state. >> In this case, maybe it is not necessary for S5 request to go through the >> resume/wakeup half of acpi_EnterSleepState. >> > > I thought shutdown*() should never return at all. It sounds like > interrupts are being re-enabled or something. > No, this is a different kind of shutdown, this one just send a signal to init: void shutdown_nice(int howto) { shutdown_howto = howto; /* Send a signal to init(8) and have it shutdown the world */ if (initproc != NULL) { PROC_LOCK(initproc); psignal(initproc, SIGINT); PROC_UNLOCK(initproc); } else { /* No init(8) running, so simply reboot */ boot(RB_NOSYNC); } return; } -- Andriy Gapon From owner-freebsd-acpi@FreeBSD.ORG Wed Mar 25 16:28:49 2009 Return-Path: Delivered-To: freebsd-acpi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 24826106566B for ; Wed, 25 Mar 2009 16:28:49 +0000 (UTC) (envelope-from nate@root.org) Received: from nlpi043.prodigy.net (nlpi043.sbcis.sbc.com [207.115.36.72]) by mx1.freebsd.org (Postfix) with ESMTP id EC7598FC12 for ; Wed, 25 Mar 2009 16:28:48 +0000 (UTC) (envelope-from nate@root.org) Received: from [10.0.5.18] (ppp-71-139-16-151.dsl.snfc21.pacbell.net [71.139.16.151]) (authenticated bits=0) by nlpi043.prodigy.net (8.13.8 smtpauth/dk/map_regex/8.13.8) with ESMTP id n2PGSlJM008951; Wed, 25 Mar 2009 11:28:47 -0500 Message-ID: <49CA5BBE.2040305@root.org> Date: Wed, 25 Mar 2009 09:28:46 -0700 From: Nate Lawson User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Andriy Gapon References: <49C8E143.2080305@icyb.net.ua> <49CA57E2.7090805@root.org> <49CA5AC9.1040601@icyb.net.ua> In-Reply-To: <49CA5AC9.1040601@icyb.net.ua> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@FreeBSD.org Subject: Re: shutdown via power button: "acpi: resumed at..." X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 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 Mar 2009 16:28:49 -0000 Andriy Gapon wrote: > on 25/03/2009 18:12 Nate Lawson said the following: >> Andriy Gapon wrote: >>> I noticed that sometimes I am getting "acpi: resumed at..." message on console and >>> in system log when I initiate system shutdown by pressing power button. >>> I think that the cause is in acpi_UserNotify("Resume") call and this call is only >>> found in acpi_EnterSleepState(). >>> >>> I see the following code in that function: >>> case ACPI_STATE_S5: >>> /* >>> * Shut down cleanly and power off. This will call us back through the >>> * shutdown handlers. >>> */ >>> shutdown_nice(RB_POWEROFF); >>> break; >>> >>> So it seems that it is expected that shutdown_nice() would return immediately. >>> I think it makes S5 a special case comparing to other states where return happens >>> upon resuming from the state. >>> In this case, maybe it is not necessary for S5 request to go through the >>> resume/wakeup half of acpi_EnterSleepState. >>> >> I thought shutdown*() should never return at all. It sounds like >> interrupts are being re-enabled or something. >> > > No, this is a different kind of shutdown, this one just send a signal to init: > void > shutdown_nice(int howto) > { > > shutdown_howto = howto; > > /* Send a signal to init(8) and have it shutdown the world */ > if (initproc != NULL) { > PROC_LOCK(initproc); > psignal(initproc, SIGINT); > PROC_UNLOCK(initproc); > } else { > /* No init(8) running, so simply reboot */ > boot(RB_NOSYNC); > } > return; > } But the shutdown that is initiated through ACPI is RB_POWEROFF. There should be no returning from there. What has changed in the code so that RB_POWEROFF does not immediately call back into acpi_shutdown_final() which powers off the system? Anyway, the resume notification could be moved under the "if (state != S5)" line right above it if this behavior is legal. -- Nate From owner-freebsd-acpi@FreeBSD.ORG Wed Mar 25 16:41:11 2009 Return-Path: Delivered-To: freebsd-acpi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ACD611065691 for ; Wed, 25 Mar 2009 16:41:11 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id E09EA8FC13 for ; Wed, 25 Mar 2009 16:41:10 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id SAA18163; Wed, 25 Mar 2009 18:41:07 +0200 (EET) (envelope-from avg@icyb.net.ua) Message-ID: <49CA5EA3.3000500@icyb.net.ua> Date: Wed, 25 Mar 2009 18:41:07 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.21 (X11/20090323) MIME-Version: 1.0 To: Nate Lawson References: <49C8E143.2080305@icyb.net.ua> <49CA57E2.7090805@root.org> <49CA5AC9.1040601@icyb.net.ua> <49CA5BBE.2040305@root.org> In-Reply-To: <49CA5BBE.2040305@root.org> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@FreeBSD.org Subject: Re: shutdown via power button: "acpi: resumed at..." X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 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 Mar 2009 16:41:12 -0000 on 25/03/2009 18:28 Nate Lawson said the following: > Andriy Gapon wrote: >> on 25/03/2009 18:12 Nate Lawson said the following: >>> Andriy Gapon wrote: >>>> I noticed that sometimes I am getting "acpi: resumed at..." message on console and >>>> in system log when I initiate system shutdown by pressing power button. >>>> I think that the cause is in acpi_UserNotify("Resume") call and this call is only >>>> found in acpi_EnterSleepState(). >>>> >>>> I see the following code in that function: >>>> case ACPI_STATE_S5: >>>> /* >>>> * Shut down cleanly and power off. This will call us back through the >>>> * shutdown handlers. >>>> */ >>>> shutdown_nice(RB_POWEROFF); >>>> break; >>>> >>>> So it seems that it is expected that shutdown_nice() would return immediately. >>>> I think it makes S5 a special case comparing to other states where return happens >>>> upon resuming from the state. >>>> In this case, maybe it is not necessary for S5 request to go through the >>>> resume/wakeup half of acpi_EnterSleepState. >>>> >>> I thought shutdown*() should never return at all. It sounds like >>> interrupts are being re-enabled or something. >>> >> No, this is a different kind of shutdown, this one just send a signal to init: >> void >> shutdown_nice(int howto) >> { >> >> shutdown_howto = howto; >> >> /* Send a signal to init(8) and have it shutdown the world */ >> if (initproc != NULL) { >> PROC_LOCK(initproc); >> psignal(initproc, SIGINT); >> PROC_UNLOCK(initproc); >> } else { >> /* No init(8) running, so simply reboot */ >> boot(RB_NOSYNC); >> } >> return; >> } > > But the shutdown that is initiated through ACPI is RB_POWEROFF. Not sure what exactly you meant here, so can't argue, just can comment - we are just handing power button press in acpi_EnterSleepState. > There > should be no returning from there. What has changed in the code so that > RB_POWEROFF does not immediately call back into acpi_shutdown_final() > which powers off the system? I am not sure what you are asking here, so I can't answer, but... power off or not, shouldn't userland be given a chance to shutdown gracefully? I thought it always worked this way. > Anyway, the resume notification could be moved under the "if (state != > S5)" line right above it if this behavior is legal. > Yes, I also think so. -- Andriy Gapon From owner-freebsd-acpi@FreeBSD.ORG Wed Mar 25 16:42:09 2009 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BB5E4106567A for ; Wed, 25 Mar 2009 16:42:09 +0000 (UTC) (envelope-from gaijin.k@gmail.com) Received: from mail-gx0-f224.google.com (mail-gx0-f224.google.com [209.85.217.224]) by mx1.freebsd.org (Postfix) with ESMTP id 69B648FC1C for ; Wed, 25 Mar 2009 16:42:09 +0000 (UTC) (envelope-from gaijin.k@gmail.com) Received: by gxk24 with SMTP id 24so335840gxk.19 for ; Wed, 25 Mar 2009 09:42:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:from:to:cc :in-reply-to:references:content-type:date:message-id:mime-version :x-mailer:content-transfer-encoding; bh=pQ/zkmbkMma0jbWP53IZOYmoZa6GJCAdrOvNbThOC6g=; b=ZeZ7ii5mYqBAi8iMKZQviU1V0L3zl5xXs+UJ6f+mpRn1WTZo4RUQd02Av2H4mh/YsU Z2LY+Q+/cDvUcfNGv2ToZ89cyezr5ziKrq2BJJeVlqXvqp60qrAT+Hv2dugAzLvV2cFH xhqSHyx0hQkXcl/CEwwwXrSFJZv6l365RJfgA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:from:to:cc:in-reply-to:references:content-type:date :message-id:mime-version:x-mailer:content-transfer-encoding; b=H4clRQtoBI2VpVPDh7CKOFyeL4cFuF10HPFT1bbk5OxNgpkgWw4CevMC/+Ru+UaaGb lrZNHtsIB5pKrxi1TmlwIHsd9MBYgzXw2Zr7rDEdKrfjsNhomMbSv2HNbgoqjY5fvTzN xIeR0IAih/kzB3+MKbdsMjzvAVLug8e6ESDf0= Received: by 10.90.100.17 with SMTP id x17mr5164183agb.84.1237999328505; Wed, 25 Mar 2009 09:42:08 -0700 (PDT) Received: from ?10.0.3.231? (pool-71-250-44-232.nwrknj.east.verizon.net [71.250.44.232]) by mx.google.com with ESMTPS id 8sm1364671agd.58.2009.03.25.09.42.07 (version=SSLv3 cipher=RC4-MD5); Wed, 25 Mar 2009 09:42:08 -0700 (PDT) From: "Alexandre \"Sunny\" Kovalenko" To: Nate Lawson In-Reply-To: <49CA568B.6030305@root.org> References: <49C80E65.9090500@onetel.com> <49C93309.6050708@iki.fi> <20090325140718.J95588@sola.nimnet.asn.au> <49C9EE50.6070507@onetel.com> <1237992462.1297.22.camel@RabbitsDen> <49CA568B.6030305@root.org> Content-Type: text/plain Date: Wed, 25 Mar 2009 12:41:54 -0400 Message-Id: <1237999314.83221.20.camel@RabbitsDen> Mime-Version: 1.0 X-Mailer: Evolution 2.24.5 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@FreeBSD.org, Ian Smith , Chris Whitehouse Subject: Re: acpi_tz0: _CRT value is absurd, ignored (256.0C) (was pr kern/105537) X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 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 Mar 2009 16:42:10 -0000 On Wed, 2009-03-25 at 09:06 -0700, Nate Lawson wrote: > > Alexandre "Sunny" Kovalenko wrote: > > On Wed, 2009-03-25 at 08:41 +0000, Chris Whitehouse wrote: > >> [Please would you cc me in any reply as I'm not subscribed, thanks.] > >> > >> Ian Smith wrote: > >>> On Tue, 24 Mar 2009, Pasi Parviainen wrote: > >>> > Chris Whitehouse wrote: > >>> > > Hi, I sent this a while ago but don't think there was a reply. I'm about to > >>> > > embark on a custom ASL to load in loader.conf as per > >>> > > http://www.freebsd.org/doc/en/books/handbook/acpi-debug.html but just > >>> > > wondering if their might be a 'proper' fix on the way. I do have the latest > >>> > > bios installed. > >>> > > >>> > Loading custom ASL with modified _CRT value for temperature zone in > >>> > question will solve the problem, see below for more information. > >>> > > >>> > > Would it help if I installed 8-CURRENT? > >>> > > >>> > Probably not, see below. > >>> > > >>> > > -------- Original Message -------- > >>> > > Subject: pr kern/105537 > >>> > > Date: Mon, 12 Jan 2009 15:00:49 +0000 > >>> > > From: Chris Whitehouse > >>> > > To: freebsd-acpi@FreeBSD.org > >>> > > > >>> > > hi, > >>> > > > >>> > > Please would you cc me in any reply as I'm not subscribed, thanks. > >>> > > > >>> > > I have the same problem noted in > >>> > > > >>> > > http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/105537 > >>> > > > >>> > > of frequent messages saying > >>> > > > >>> > > acpi_tz0: _CRT value is absurd, ignored (256.0C) > >>> > > > >>> > > on my HP nc6320 laptop, model RH383ET. > >>> > > > >>> > > >>> > I have HP 6510b and HP 2510p laptops and had same problem with those. > >>> > Actual problem is that the ACPI thermal code in kernel does sanity-check > >>> > for temperature values, and accepts only values between 0 - 200 Celsius. > >>> > To solve the problem you either create custom DSDT which returns 200.0C > >>> > value instead of 256.0C for thermal zone in question or increase the limit of > >>> > the sanity-check code of ACPI thermal code (src/sys/dev/acpica/acpi_thermal.c > >>> > function: acpi_tz_sanity). > >>> > > >>> > Proper way to solve this in my opinion is to increase the range of > >>> > sanity-check function from 0 - 200 Celsius to 0 - 256 Celsius, or at > >>> > least provide sysctl variable to disable thermal sanity-checks. > >>> > >>> Even 200C is absurd, really. That's above the melting point of many > >>> types of solder (http://www.rfcafe.com/references/electrical/solder.htm) > >>> while 256C exceeds the melting point of _most_ types of solder. I seem > >>> to recall that this limit used to be 150C, still hotter than anything > >>> you actually want to have anywhere on a computer board. > >>> > >>> No sense checking sanity to then accept insane values; fix the broken > >>> ASL. 256 sounds suspiciously like a byte-swapped value, perhaps? > >>> > >>> cheers, Ian > >>> > >> Getting the ASL in the actual BIOS firmware fixed would be great, but I > >> tried once to get Asus to correct a byte swapped value without success. > >> I don't suppose HP will be any more cooperative but I can try. I will > >> have a look at an acpidump tonight. A custom ASL would at least prove > >> what is wrong. > >> > >> Does anyone know what this value is supposed to be measuring? > > _CRT method in ASL is supposed to return temperature (in the tenth of > > Kelvin) at which you would like to have your computer shut down rather > > rapidly. On my ThinkPad X60 it is 97C. > > > > > To be fair, if all you want is to override _CRT, you should be able to > > put something to the tune of > > > > hw.acpi.thermal.user_override=1 > > hw.acpi.thermal.tz0._CRT=90C > > > > in your /etc/sysctl.conf and not deal with the ASL at all. > > Yes, this is the best way instead of messing with ASL. > While it is true that, unlike _PSV, _CRT should not be changed while OS is running, it is not impossible to imagine that it could be calculated at boot, taking into account point-in-time configuration of the hardware (and causing EC timeout in process). Hence, I would recommend looking into ASL anyway, at least so OP understands what he is giving up by hardcoding the value. If I am not mistaken, 256C should look like Return(0x14AD), which is somewhat odd a number to say the least. Besides, FreeBSD makes ASL overriding so easy ;) -- Alexandre "Sunny" Kovalenko From owner-freebsd-acpi@FreeBSD.ORG Wed Mar 25 20:18:46 2009 Return-Path: Delivered-To: acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 142DF106566B for ; Wed, 25 Mar 2009 20:18:46 +0000 (UTC) (envelope-from getmoney@jinno.com) Received: from smtp4.apollo.lv (smtp4.apollo.lv [80.232.168.199]) by mx1.freebsd.org (Postfix) with ESMTP id 99E928FC18 for ; Wed, 25 Mar 2009 20:18:45 +0000 (UTC) (envelope-from getmoney@jinno.com) X-Junk-Score: 0 [] X-Cloudmark-Score: 0 [] X-Virus-Scanned: by cgpav Received: from [81.198.153.82] (HELO amd) by smtp4.apollo.lv (CommuniGate Pro SMTP 5.2.3) with ESMTP id 307849005 for acpi@freebsd.org; Wed, 25 Mar 2009 21:18:41 +0200 Message-ID: <00fce596-39897-08668871352315@amd> From: "Fast Money" To: acpi@freebsd.org Date: Wed, 25 Mar 2009 21:17:28 +0200 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Priority: 3 Cc: Subject: Click-Paid.Com X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 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 Mar 2009 20:18:46 -0000 <<< The Project is Paying!>>> Join This site New PTC Project!!! http://click-paid.com >>>>> Join Now!!! <<<<< From owner-freebsd-acpi@FreeBSD.ORG Wed Mar 25 22:39:37 2009 Return-Path: Delivered-To: freebsd-acpi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3D7EB1065672 for ; Wed, 25 Mar 2009 22:39:37 +0000 (UTC) (envelope-from bruce@cran.org.uk) Received: from muon.cran.org.uk (brucec-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:c09::2]) by mx1.freebsd.org (Postfix) with ESMTP id 0DF758FC12 for ; Wed, 25 Mar 2009 22:39:37 +0000 (UTC) (envelope-from bruce@cran.org.uk) Received: from muon.cran.org.uk (localhost [127.0.0.1]) by muon.cran.org.uk (Postfix) with ESMTP id BD59219017; Wed, 25 Mar 2009 22:39:35 +0000 (GMT) X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on muon X-Spam-Level: X-Spam-Status: No, score=-2.5 required=8.0 tests=AWL,BAYES_00,NO_RELAYS autolearn=ham version=3.2.5 Received: from gluon.draftnet (unknown [IPv6:2a01:348:10f:0:240:f4ff:fe57:9871]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by muon.cran.org.uk (Postfix) with ESMTPSA; Wed, 25 Mar 2009 22:39:35 +0000 (GMT) Date: Wed, 25 Mar 2009 22:39:14 +0000 From: Bruce Cran To: Daniel =?UTF-8?Q?Dvo=C5=99=C3=A1k?= Message-ID: <20090325223914.4387eeae@gluon.draftnet> In-Reply-To: <200903200030.n2K0U3iG011009@freefall.freebsd.org> References: <200903200030.n2K0U3iG011009@freefall.freebsd.org> X-Mailer: Claws Mail 3.7.1 (GTK+ 2.14.7; i386-portbld-freebsd7.2) Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-acpi@FreeBSD.org Subject: Re: kern/108581: [sysctl] sysctl: hw.acpi.cpu.cx_lowest: Invalid argument X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 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 Mar 2009 22:39:37 -0000 On Fri, 20 Mar 2009 00:30:03 GMT Daniel Dvo=C5=99=C3=A1k wrote: > The following reply was made to PR kern/108581; it has been noted by > GNATS. >=20 > From: =3D?UTF-8?Q?Daniel_Dvo=3DC5=3D99=3DC3=3DA1k?=3D > To: , > > Cc: =20 > Subject: Re: kern/108581: [sysctl] sysctl: hw.acpi.cpu.cx_lowest: > Invalid argument Date: Fri, 20 Mar 2009 01:01:51 +0100 >=20 > This is a multi-part message in MIME format. > =20 > ------=3D_NextPart_000_0007_01C9A8F7.746C4190 > Content-Type: text/plain; > charset=3D"UTF-8" > Content-Transfer-Encoding: quoted-printable > =20 > Hi acpi team, > =3D20 > today I have installed fbsd 7.1R on one box with this relativly old =3D > error and I was surprised about results .. it is the same: > =3D20 > # uname -a > FreeBSD X.Y.Z 7.1-RELEASE FreeBSD 7.1-RELEASE #0: Thu Jan 1 > 14:37:25 =3D UTC 2009 > root@logan.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC =3D i386 > =20 > # sysctl dev.cpu.0.cx_supported > dev.cpu.0.cx_supported: C1/0 > =20 > # sysctl hw.acpi.cpu.cx_lowest=3D3DC1 > hw.acpi.cpu.cx_lowest: C1 > sysctl: hw.acpi.cpu.cx_lowest: Invalid argument > =3D20 > # sysctl hw.acpi.cpu.cx_lowest=3D3DC0 > hw.acpi.cpu.cx_lowest: C1 > sysctl: hw.acpi.cpu.cx_lowest: Invalid argument > =3D20 > # sysctl hw.acpi.cpu.cx_lowest=3D3DC1/0 > hw.acpi.cpu.cx_lowest: C1 > sysctl: hw.acpi.cpu.cx_lowest: Invalid argument > =20 > # dmesg -a | grep "acpi" > acpi0: on motherboard > acpi0: Overriding SCI Interrupt from IRQ 9 to IRQ 20 > acpi0: [ITHREAD] > acpi0: Power Button (fixed) > acpi0: reservation of 0, a0000 (3) failed > acpi0: reservation of 100000, ff00000 (3) failed > acpi_timer0: <24-bit timer at 3.579545MHz> port 0xe408-0xe40b on > acpi0 acpi_button0: on acpi0 > pcib0: port 0xcf8-0xcff on acpi0 > atkbdc0: port 0x60,0x64 irq 1 on acpi0 > cpu0: on acpi0 > hw.acpi.cpu.cx_lowest: > hw.acpi.cpu.cx_lowest I think I've found the problem and have updated the PR kern/108581 (http://www.freebsd.org/cgi/query-pr.cgi?pr=3Dkern/108581). The global cpu_cx_count was being initialized to 0 in acpi_cpu_startup (in /sys/dev/acpica/acpi_cpu.c) but code below it appears to assume that it's been intialized to 3 because it only sets it if it's higher than the current CPU supports - that is, cpu_cx_count should reflect the highest Cx state that all CPUs support. There's also a bug in the _CST section just below it; I think the line: if (sc->cpu_cx_count > cpu_cx_count) should be if (sc->cpu_cx_count < cpu_cx_count) --=20 Bruce Cran From owner-freebsd-acpi@FreeBSD.ORG Wed Mar 25 22:40:05 2009 Return-Path: Delivered-To: freebsd-acpi@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0A3AE1065672 for ; Wed, 25 Mar 2009 22:40:05 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id EC1CB8FC1D for ; Wed, 25 Mar 2009 22:40:04 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n2PMe4cu073658 for ; Wed, 25 Mar 2009 22:40:04 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n2PMe4eZ073657; Wed, 25 Mar 2009 22:40:04 GMT (envelope-from gnats) Date: Wed, 25 Mar 2009 22:40:04 GMT Message-Id: <200903252240.n2PMe4eZ073657@freefall.freebsd.org> To: freebsd-acpi@FreeBSD.org From: Bruce Cran Cc: Subject: Re: kern/108581: [sysctl] sysctl: hw.acpi.cpu.cx_lowest: Invalid argument X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Bruce Cran List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 22:40:05 -0000 The following reply was made to PR kern/108581; it has been noted by GNATS. From: Bruce Cran To: bug-followup@FreeBSD.org, lars.stokholm@gmail.com Cc: Subject: Re: kern/108581: [sysctl] sysctl: hw.acpi.cpu.cx_lowest: Invalid argument Date: Wed, 25 Mar 2009 22:32:16 +0000 In acpi_cpu_startup in /sys/dev/acpi_cpu.c cpu_cx_count is initialized to 0. If the generic Cx mode is being used (which it appears to be on older CPUs) then a loop is run over all the CPUs to find the highest Cx state common to all of them. However that code assumes that cpu_cx_count has been initialized too *high*, since it only sets it if it finds a CPU with a maximum Cx state lower than the current value of cpu_cx_count. This means that while setting the per-CPU cx_lowest sysctl works because it correctly gets initialized to 1 in acpi_cpu_generic_cx_probe, the global systl hw.acpi.cpu.cx_lowest always fails because it thinks there are no Cx states. Initializing cpu_cx_count to 3 instead of 0 should fix the problem. There appears to be a related bug in the _CST mode handling below; if there exists a CPU in the system which supports a higher Cx state than the others, the global cx_cpu_count will be set too high if the purpose of that sysctl is to reflect the maximum Cx state that all CPUs support. -- Bruce From owner-freebsd-acpi@FreeBSD.ORG Wed Mar 25 23:20:05 2009 Return-Path: Delivered-To: freebsd-acpi@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0FDA6106564A for ; Wed, 25 Mar 2009 23:20:05 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id F19908FC25 for ; Wed, 25 Mar 2009 23:20:04 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n2PNK4W3033069 for ; Wed, 25 Mar 2009 23:20:04 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n2PNK4nj033068; Wed, 25 Mar 2009 23:20:04 GMT (envelope-from gnats) Date: Wed, 25 Mar 2009 23:20:04 GMT Message-Id: <200903252320.n2PNK4nj033068@freefall.freebsd.org> To: freebsd-acpi@FreeBSD.org From: Bruce Cran Cc: Subject: Re: kern/108581: [sysctl] sysctl: hw.acpi.cpu.cx_lowest: Invalid argument X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Bruce Cran List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 23:20:05 -0000 The following reply was made to PR kern/108581; it has been noted by GNATS. From: Bruce Cran To: bug-followup@FreeBSD.org, lars.stokholm@gmail.com Cc: Subject: Re: kern/108581: [sysctl] sysctl: hw.acpi.cpu.cx_lowest: Invalid argument Date: Wed, 25 Mar 2009 23:13:55 +0000 --MP_/.Mqqm3g9tTbq0b=KU9SrVSj Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline --MP_/.Mqqm3g9tTbq0b=KU9SrVSj Content-Type: text/plain Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=acpi_cpu.c.diff.txt --- acpi_cpu.c 2009-03-25 23:06:24.000000000 +0000 +++ sys/dev/acpica/acpi_cpu.c 2009-03-25 23:07:45.000000000 +0000 @@ -742,7 +742,7 @@ */ acpi_cpu_quirks(); - cpu_cx_count = 0; + cpu_cx_count = 3; if (cpu_cx_generic) { /* * We are using generic Cx mode, probe for available Cx states @@ -775,7 +775,7 @@ if (cpu_quirks & CPU_QUIRK_NO_C3) { sc->cpu_cx_count = sc->cpu_non_c3 + 1; } - if (sc->cpu_cx_count > cpu_cx_count) + if (sc->cpu_cx_count < cpu_cx_count) cpu_cx_count = sc->cpu_cx_count; AcpiInstallNotifyHandler(sc->cpu_handle, ACPI_DEVICE_NOTIFY, acpi_cpu_notify, sc); --MP_/.Mqqm3g9tTbq0b=KU9SrVSj-- From owner-freebsd-acpi@FreeBSD.ORG Thu Mar 26 13:57:08 2009 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 043EA1065708 for ; Thu, 26 Mar 2009 13:57:08 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id BC8518FC1D for ; Thu, 26 Mar 2009 13:57:07 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (pool-98-109-39-197.nwrknj.fios.verizon.net [98.109.39.197]) by cyrus.watson.org (Postfix) with ESMTPSA id 4FB4D46B2A; Thu, 26 Mar 2009 09:57:07 -0400 (EDT) Received: from localhost (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.14.3/8.14.3) with ESMTP id n2QDuXGo082619; Thu, 26 Mar 2009 09:57:01 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-acpi@freebsd.org Date: Thu, 26 Mar 2009 09:37:50 -0400 User-Agent: KMail/1.9.7 References: <200903200030.n2K0U3iG011009@freefall.freebsd.org> <20090325223914.4387eeae@gluon.draftnet> In-Reply-To: <20090325223914.4387eeae@gluon.draftnet> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200903260937.51028.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Thu, 26 Mar 2009 09:57:01 -0400 (EDT) X-Virus-Scanned: ClamAV 0.94.2/9169/Thu Mar 26 00:13:48 2009 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: Daniel =?utf-8?q?Dvo=C5=99=C3=A1k?= Subject: Re: kern/108581: [sysctl] sysctl: hw.acpi.cpu.cx_lowest: Invalid argument X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 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 Mar 2009 13:57:09 -0000 On Wednesday 25 March 2009 6:39:14 pm Bruce Cran wrote: > On Fri, 20 Mar 2009 00:30:03 GMT > Daniel Dvo=C5=99=C3=A1k wrote: >=20 > > The following reply was made to PR kern/108581; it has been noted by > > GNATS. > >=20 > > From: =3D?UTF-8?Q?Daniel_Dvo=3DC5=3D99=3DC3=3DA1k?=3D > > To: , > > > > Cc: =20 > > Subject: Re: kern/108581: [sysctl] sysctl: hw.acpi.cpu.cx_lowest: > > Invalid argument Date: Fri, 20 Mar 2009 01:01:51 +0100 > >=20 > > This is a multi-part message in MIME format. > > =20 > > ------=3D_NextPart_000_0007_01C9A8F7.746C4190 > > Content-Type: text/plain; > > charset=3D"UTF-8" > > Content-Transfer-Encoding: quoted-printable > > =20 > > Hi acpi team, > > =3D20 > > today I have installed fbsd 7.1R on one box with this relativly old =3D > > error and I was surprised about results .. it is the same: > > =3D20 > > # uname -a > > FreeBSD X.Y.Z 7.1-RELEASE FreeBSD 7.1-RELEASE #0: Thu Jan 1 > > 14:37:25 =3D UTC 2009 > > root@logan.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC =3D i386 > > =20 > > # sysctl dev.cpu.0.cx_supported > > dev.cpu.0.cx_supported: C1/0 > > =20 > > # sysctl hw.acpi.cpu.cx_lowest=3D3DC1 > > hw.acpi.cpu.cx_lowest: C1 > > sysctl: hw.acpi.cpu.cx_lowest: Invalid argument > > =3D20 > > # sysctl hw.acpi.cpu.cx_lowest=3D3DC0 > > hw.acpi.cpu.cx_lowest: C1 > > sysctl: hw.acpi.cpu.cx_lowest: Invalid argument > > =3D20 > > # sysctl hw.acpi.cpu.cx_lowest=3D3DC1/0 > > hw.acpi.cpu.cx_lowest: C1 > > sysctl: hw.acpi.cpu.cx_lowest: Invalid argument > > =20 > > # dmesg -a | grep "acpi" > > acpi0: on motherboard > > acpi0: Overriding SCI Interrupt from IRQ 9 to IRQ 20 > > acpi0: [ITHREAD] > > acpi0: Power Button (fixed) > > acpi0: reservation of 0, a0000 (3) failed > > acpi0: reservation of 100000, ff00000 (3) failed > > acpi_timer0: <24-bit timer at 3.579545MHz> port 0xe408-0xe40b on > > acpi0 acpi_button0: on acpi0 > > pcib0: port 0xcf8-0xcff on acpi0 > > atkbdc0: port 0x60,0x64 irq 1 on acpi0 > > cpu0: on acpi0 > > hw.acpi.cpu.cx_lowest: > > hw.acpi.cpu.cx_lowest >=20 > I think I've found the problem and have updated the PR kern/108581 > (http://www.freebsd.org/cgi/query-pr.cgi?pr=3Dkern/108581). The global > cpu_cx_count was being initialized to 0 in acpi_cpu_startup > (in /sys/dev/acpica/acpi_cpu.c) but code below it appears to assume that > it's been intialized to 3 because it only sets it if it's higher than > the current CPU supports - that is, cpu_cx_count should reflect the > highest Cx state that all CPUs support. >=20 > There's also a bug in the _CST section just below it; I think the line: >=20 > if (sc->cpu_cx_count > cpu_cx_count) >=20 > should be >=20 > if (sc->cpu_cx_count < cpu_cx_count) No, the code is doing things differently on purpose (though I'm not complet= ely=20 sure why). For _CST it sets cpu_cx_count to the maximum Cx level supported= =20 by any CPU in the system. For non-_CST it sets it to the maximum Cx level= =20 supported by all CPUs in the system. I think it is correct for cpu_cx_coun= t=20 to always start at 0 and only be bumped up to a higher setting. Setting it= =20 to 3 would be very wrong for the _CST case as I've seen CPUs that support C= 4. Note that C1 _always_ exists as it is simply the "hlt" instruction that has= =20 existed since the 8086. Only C2+ require power-saving extension support in= =20 the CPU, so cpu_cx_count should always end up >=3D 1. It would be interest= ing=20 if you could add some debug printfs to print out the values that=20 acpi_cpu_generic_cx_probe() computes for 'sc->cpu_cx_count' (sysctl dev.cpu= =20 could be useful for this) as well as all changes to the 'cpu_cx_count' glob= al=20 variable. =2D-=20 John Baldwin From owner-freebsd-acpi@FreeBSD.ORG Thu Mar 26 14:09:17 2009 Return-Path: Delivered-To: freebsd-acpi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3AB6F106564A for ; Thu, 26 Mar 2009 14:09:17 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 5F6638FC14 for ; Thu, 26 Mar 2009 14:09:15 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id QAA27073; Thu, 26 Mar 2009 16:09:10 +0200 (EET) (envelope-from avg@icyb.net.ua) Message-ID: <49CB8C86.4020800@icyb.net.ua> Date: Thu, 26 Mar 2009 16:09:10 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.21 (X11/20090323) MIME-Version: 1.0 To: Bruce Cran References: <200903200030.n2K0U3iG011009@freefall.freebsd.org> <20090325223914.4387eeae@gluon.draftnet> In-Reply-To: <20090325223914.4387eeae@gluon.draftnet> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: freebsd-acpi@FreeBSD.org Subject: Re: kern/108581: [sysctl] sysctl: hw.acpi.cpu.cx_lowest: Invalid argument X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 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 Mar 2009 14:09:17 -0000 on 26/03/2009 00:39 Bruce Cran said the following: > On Fri, 20 Mar 2009 00:30:03 GMT > Daniel Dvořák wrote: > >> The following reply was made to PR kern/108581; it has been noted by >> GNATS. >> >> From: =?UTF-8?Q?Daniel_Dvo=C5=99=C3=A1k?= >> To: , >> >> Cc: >> Subject: Re: kern/108581: [sysctl] sysctl: hw.acpi.cpu.cx_lowest: >> Invalid argument Date: Fri, 20 Mar 2009 01:01:51 +0100 >> >> This is a multi-part message in MIME format. >> >> ------=_NextPart_000_0007_01C9A8F7.746C4190 >> Content-Type: text/plain; >> charset="UTF-8" >> Content-Transfer-Encoding: quoted-printable >> >> Hi acpi team, >> =20 >> today I have installed fbsd 7.1R on one box with this relativly old = >> error and I was surprised about results .. it is the same: >> =20 >> # uname -a >> FreeBSD X.Y.Z 7.1-RELEASE FreeBSD 7.1-RELEASE #0: Thu Jan 1 >> 14:37:25 = UTC 2009 >> root@logan.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC = i386 >> >> # sysctl dev.cpu.0.cx_supported >> dev.cpu.0.cx_supported: C1/0 >> >> # sysctl hw.acpi.cpu.cx_lowest=3DC1 >> hw.acpi.cpu.cx_lowest: C1 >> sysctl: hw.acpi.cpu.cx_lowest: Invalid argument >> =20 >> # sysctl hw.acpi.cpu.cx_lowest=3DC0 >> hw.acpi.cpu.cx_lowest: C1 >> sysctl: hw.acpi.cpu.cx_lowest: Invalid argument >> =20 >> # sysctl hw.acpi.cpu.cx_lowest=3DC1/0 >> hw.acpi.cpu.cx_lowest: C1 >> sysctl: hw.acpi.cpu.cx_lowest: Invalid argument >> >> # dmesg -a | grep "acpi" >> acpi0: on motherboard >> acpi0: Overriding SCI Interrupt from IRQ 9 to IRQ 20 >> acpi0: [ITHREAD] >> acpi0: Power Button (fixed) >> acpi0: reservation of 0, a0000 (3) failed >> acpi0: reservation of 100000, ff00000 (3) failed >> acpi_timer0: <24-bit timer at 3.579545MHz> port 0xe408-0xe40b on >> acpi0 acpi_button0: on acpi0 >> pcib0: port 0xcf8-0xcff on acpi0 >> atkbdc0: port 0x60,0x64 irq 1 on acpi0 >> cpu0: on acpi0 >> hw.acpi.cpu.cx_lowest: >> hw.acpi.cpu.cx_lowest > > I think I've found the problem and have updated the PR kern/108581 > (http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/108581). The global > cpu_cx_count was being initialized to 0 in acpi_cpu_startup > (in /sys/dev/acpica/acpi_cpu.c) but code below it appears to assume that > it's been intialized to 3 because it only sets it if it's higher than > the current CPU supports - that is, cpu_cx_count should reflect the > highest Cx state that all CPUs support. If you specifically mean the generic case (non-cst) as you mention in the PR, then I think that you didn't notice that cpu_cx_count (the global variable) gets updated in acpi_cpu_generic_cx_probe, So after looping over all CPUs it has the value of the maximum Cx level supported by at least one CPU. Only then we loop again and determine the smallest of the supported maximums. -- Andriy Gapon From owner-freebsd-acpi@FreeBSD.ORG Thu Mar 26 14:25:20 2009 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5311F1065675; Thu, 26 Mar 2009 14:25:20 +0000 (UTC) (envelope-from bruce@cran.org.uk) Received: from muon.cran.org.uk (brucec-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:c09::2]) by mx1.freebsd.org (Postfix) with ESMTP id EC5DF8FC12; Thu, 26 Mar 2009 14:25:19 +0000 (UTC) (envelope-from bruce@cran.org.uk) Received: from muon.cran.org.uk (localhost [127.0.0.1]) by muon.cran.org.uk (Postfix) with ESMTP id A434819017; Thu, 26 Mar 2009 14:25:17 +0000 (GMT) X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on muon X-Spam-Level: X-Spam-Status: No, score=-2.6 required=8.0 tests=AWL,BAYES_00,NO_RELAYS autolearn=ham version=3.2.5 Received: from gluon.draftnet (unknown [IPv6:2a01:348:10f:0:240:f4ff:fe57:9871]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by muon.cran.org.uk (Postfix) with ESMTPSA; Thu, 26 Mar 2009 14:25:17 +0000 (GMT) Date: Thu, 26 Mar 2009 14:24:56 +0000 From: Bruce Cran To: John Baldwin Message-ID: <20090326142456.042ea2f0@gluon.draftnet> In-Reply-To: <200903260937.51028.jhb@freebsd.org> References: <200903200030.n2K0U3iG011009@freefall.freebsd.org> <20090325223914.4387eeae@gluon.draftnet> <200903260937.51028.jhb@freebsd.org> X-Mailer: Claws Mail 3.7.1 (GTK+ 2.14.7; i386-portbld-freebsd7.2) Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: Daniel =?utf-8?Q?Dvo=C5=99=C3=A1k?= , freebsd-acpi@freebsd.org Subject: Re: kern/108581: [sysctl] sysctl: hw.acpi.cpu.cx_lowest: Invalid argument X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 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 Mar 2009 14:25:20 -0000 On Thu, 26 Mar 2009 09:37:50 -0400 John Baldwin wrote: > On Wednesday 25 March 2009 6:39:14 pm Bruce Cran wrote: > > On Fri, 20 Mar 2009 00:30:03 GMT > > Daniel Dvo=C5=99=C3=A1k wrote: > >=20 > > > The following reply was made to PR kern/108581; it has been noted > > > by GNATS. > > >=20 > > > From: =3D?UTF-8?Q?Daniel_Dvo=3DC5=3D99=3DC3=3DA1k?=3D > > > To: , > > > > > > Cc: =20 > > > Subject: Re: kern/108581: [sysctl] sysctl: hw.acpi.cpu.cx_lowest: > > > Invalid argument Date: Fri, 20 Mar 2009 01:01:51 +0100 > > >=20 > > > This is a multi-part message in MIME format. > > > =20 > > > ------=3D_NextPart_000_0007_01C9A8F7.746C4190 > > > Content-Type: text/plain; > > > charset=3D"UTF-8" > > > Content-Transfer-Encoding: quoted-printable > > > =20 > > > Hi acpi team, > > > =3D20 > > > today I have installed fbsd 7.1R on one box with this relativly > > > old =3D error and I was surprised about results .. it is the same: > > > =3D20 > > > # uname -a > > > FreeBSD X.Y.Z 7.1-RELEASE FreeBSD 7.1-RELEASE #0: Thu Jan 1 > > > 14:37:25 =3D UTC 2009 > > > root@logan.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC =3D i386 > > > =20 > > > # sysctl dev.cpu.0.cx_supported > > > dev.cpu.0.cx_supported: C1/0 > > > =20 > > > # sysctl hw.acpi.cpu.cx_lowest=3D3DC1 > > > hw.acpi.cpu.cx_lowest: C1 > > > sysctl: hw.acpi.cpu.cx_lowest: Invalid argument > > > =3D20 > > > # sysctl hw.acpi.cpu.cx_lowest=3D3DC0 > > > hw.acpi.cpu.cx_lowest: C1 > > > sysctl: hw.acpi.cpu.cx_lowest: Invalid argument > > > =3D20 > > > # sysctl hw.acpi.cpu.cx_lowest=3D3DC1/0 > > > hw.acpi.cpu.cx_lowest: C1 > > > sysctl: hw.acpi.cpu.cx_lowest: Invalid argument > > > =20 > > > # dmesg -a | grep "acpi" > > > acpi0: on motherboard > > > acpi0: Overriding SCI Interrupt from IRQ 9 to IRQ 20 > > > acpi0: [ITHREAD] > > > acpi0: Power Button (fixed) > > > acpi0: reservation of 0, a0000 (3) failed > > > acpi0: reservation of 100000, ff00000 (3) failed > > > acpi_timer0: <24-bit timer at 3.579545MHz> port 0xe408-0xe40b on > > > acpi0 acpi_button0: on acpi0 > > > pcib0: port 0xcf8-0xcff on acpi0 > > > atkbdc0: port 0x60,0x64 irq 1 on > > > acpi0 cpu0: on acpi0 > > > hw.acpi.cpu.cx_lowest: > > > hw.acpi.cpu.cx_lowest > >=20 > > I think I've found the problem and have updated the PR kern/108581 > > (http://www.freebsd.org/cgi/query-pr.cgi?pr=3Dkern/108581). The global > > cpu_cx_count was being initialized to 0 in acpi_cpu_startup > > (in /sys/dev/acpica/acpi_cpu.c) but code below it appears to assume > > that it's been intialized to 3 because it only sets it if it's > > higher than the current CPU supports - that is, cpu_cx_count should > > reflect the highest Cx state that all CPUs support. > >=20 > > There's also a bug in the _CST section just below it; I think the > > line: > >=20 > > if (sc->cpu_cx_count > cpu_cx_count) > >=20 > > should be > >=20 > > if (sc->cpu_cx_count < cpu_cx_count) >=20 > No, the code is doing things differently on purpose (though I'm not > completely sure why). For _CST it sets cpu_cx_count to the maximum > Cx level supported by any CPU in the system. For non-_CST it sets it > to the maximum Cx level supported by all CPUs in the system. I think > it is correct for cpu_cx_count to always start at 0 and only be > bumped up to a higher setting. Setting it to 3 would be very wrong > for the _CST case as I've seen CPUs that support C4. >=20 > Note that C1 _always_ exists as it is simply the "hlt" instruction > that has existed since the 8086. Only C2+ require power-saving > extension support in the CPU, so cpu_cx_count should always end up >=3D > 1. It would be interesting if you could add some debug printfs to > print out the values that acpi_cpu_generic_cx_probe() computes for > 'sc->cpu_cx_count' (sysctl dev.cpu could be useful for this) as well > as all changes to the 'cpu_cx_count' global variable. >=20 For my Athlon XP CPU, acpi_cpu_generic_cx_probe sets sc->cpu_cx_count to 1, and subsequently dev.cpu.0.cx_lowest has always worked. After adding printfs I found that the problem is that the cpu_cx_generic block in acpi_cpu_startup is being run and because cpu_cx_count is set to 0 it never gets updated; the statement "if (sc->cpu_cx_count < cpu_cx_count)" is never true. --=20 Bruce Cran From owner-freebsd-acpi@FreeBSD.ORG Thu Mar 26 14:28:54 2009 Return-Path: Delivered-To: freebsd-acpi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9242D10656D0 for ; Thu, 26 Mar 2009 14:28:54 +0000 (UTC) (envelope-from bruce@cran.org.uk) Received: from muon.cran.org.uk (brucec-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:c09::2]) by mx1.freebsd.org (Postfix) with ESMTP id 622C58FC13 for ; Thu, 26 Mar 2009 14:28:54 +0000 (UTC) (envelope-from bruce@cran.org.uk) Received: from muon.cran.org.uk (localhost [127.0.0.1]) by muon.cran.org.uk (Postfix) with ESMTP id 02D7E19017; Thu, 26 Mar 2009 14:28:53 +0000 (GMT) X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on muon X-Spam-Level: X-Spam-Status: No, score=-2.6 required=8.0 tests=AWL,BAYES_00,NO_RELAYS autolearn=ham version=3.2.5 Received: from gluon.draftnet (unknown [IPv6:2a01:348:10f:0:240:f4ff:fe57:9871]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by muon.cran.org.uk (Postfix) with ESMTPSA; Thu, 26 Mar 2009 14:28:52 +0000 (GMT) Date: Thu, 26 Mar 2009 14:28:32 +0000 From: Bruce Cran To: Andriy Gapon Message-ID: <20090326142832.0dba187a@gluon.draftnet> In-Reply-To: <49CB8C86.4020800@icyb.net.ua> References: <200903200030.n2K0U3iG011009@freefall.freebsd.org> <20090325223914.4387eeae@gluon.draftnet> <49CB8C86.4020800@icyb.net.ua> X-Mailer: Claws Mail 3.7.1 (GTK+ 2.14.7; i386-portbld-freebsd7.2) Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-acpi@FreeBSD.org Subject: Re: kern/108581: [sysctl] sysctl: hw.acpi.cpu.cx_lowest: Invalid argument X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 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 Mar 2009 14:28:55 -0000 On Thu, 26 Mar 2009 16:09:10 +0200 Andriy Gapon wrote: > on 26/03/2009 00:39 Bruce Cran said the following: > > On Fri, 20 Mar 2009 00:30:03 GMT > > Daniel Dvo=C5=99=C3=A1k wrote: > >=20 > >> The following reply was made to PR kern/108581; it has been noted > >> by GNATS. > >> > >> From: =3D?UTF-8?Q?Daniel_Dvo=3DC5=3D99=3DC3=3DA1k?=3D > >> To: , > >> > >> Cc: =20 > >> Subject: Re: kern/108581: [sysctl] sysctl: hw.acpi.cpu.cx_lowest: > >> Invalid argument Date: Fri, 20 Mar 2009 01:01:51 +0100 > >> > >> This is a multi-part message in MIME format. > >> =20 > >> ------=3D_NextPart_000_0007_01C9A8F7.746C4190 > >> Content-Type: text/plain; > >> charset=3D"UTF-8" > >> Content-Transfer-Encoding: quoted-printable > >> =20 > >> Hi acpi team, > >> =3D20 > >> today I have installed fbsd 7.1R on one box with this relativly > >> old =3D error and I was surprised about results .. it is the same: > >> =3D20 > >> # uname -a > >> FreeBSD X.Y.Z 7.1-RELEASE FreeBSD 7.1-RELEASE #0: Thu Jan 1 > >> 14:37:25 =3D UTC 2009 > >> root@logan.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC =3D i386 > >> =20 > >> # sysctl dev.cpu.0.cx_supported > >> dev.cpu.0.cx_supported: C1/0 > >> =20 > >> # sysctl hw.acpi.cpu.cx_lowest=3D3DC1 > >> hw.acpi.cpu.cx_lowest: C1 > >> sysctl: hw.acpi.cpu.cx_lowest: Invalid argument > >> =3D20 > >> # sysctl hw.acpi.cpu.cx_lowest=3D3DC0 > >> hw.acpi.cpu.cx_lowest: C1 > >> sysctl: hw.acpi.cpu.cx_lowest: Invalid argument > >> =3D20 > >> # sysctl hw.acpi.cpu.cx_lowest=3D3DC1/0 > >> hw.acpi.cpu.cx_lowest: C1 > >> sysctl: hw.acpi.cpu.cx_lowest: Invalid argument > >> =20 > >> # dmesg -a | grep "acpi" > >> acpi0: on motherboard > >> acpi0: Overriding SCI Interrupt from IRQ 9 to IRQ 20 > >> acpi0: [ITHREAD] > >> acpi0: Power Button (fixed) > >> acpi0: reservation of 0, a0000 (3) failed > >> acpi0: reservation of 100000, ff00000 (3) failed > >> acpi_timer0: <24-bit timer at 3.579545MHz> port 0xe408-0xe40b on > >> acpi0 acpi_button0: on acpi0 > >> pcib0: port 0xcf8-0xcff on acpi0 > >> atkbdc0: port 0x60,0x64 irq 1 on > >> acpi0 cpu0: on acpi0 > >> hw.acpi.cpu.cx_lowest: > >> hw.acpi.cpu.cx_lowest > >=20 > > I think I've found the problem and have updated the PR kern/108581 > > (http://www.freebsd.org/cgi/query-pr.cgi?pr=3Dkern/108581). The global > > cpu_cx_count was being initialized to 0 in acpi_cpu_startup > > (in /sys/dev/acpica/acpi_cpu.c) but code below it appears to assume > > that it's been intialized to 3 because it only sets it if it's > > higher than the current CPU supports - that is, cpu_cx_count should > > reflect the highest Cx state that all CPUs support. >=20 > If you specifically mean the generic case (non-cst) as you mention in > the PR, then I think that you didn't notice that cpu_cx_count (the > global variable) gets updated in acpi_cpu_generic_cx_probe, So after > looping over all CPUs it has the value of the maximum Cx level > supported by at least one CPU. Only then we loop again and determine > the smallest of the supported maximums. Yes, I had missed that. I think the problem however is still that in the generic cx case the global is re-initialized to 0 and never gets updated. --=20 Bruce Cran From owner-freebsd-acpi@FreeBSD.ORG Thu Mar 26 14:33:14 2009 Return-Path: Delivered-To: freebsd-acpi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F0BE51065679 for ; Thu, 26 Mar 2009 14:33:14 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 39D278FC23 for ; Thu, 26 Mar 2009 14:33:13 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id QAA27886; Thu, 26 Mar 2009 16:33:09 +0200 (EET) (envelope-from avg@icyb.net.ua) Message-ID: <49CB9224.6010509@icyb.net.ua> Date: Thu, 26 Mar 2009 16:33:08 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.21 (X11/20090323) MIME-Version: 1.0 To: Bruce Cran References: <200903200030.n2K0U3iG011009@freefall.freebsd.org> <20090325223914.4387eeae@gluon.draftnet> <49CB8C86.4020800@icyb.net.ua> <20090326142832.0dba187a@gluon.draftnet> In-Reply-To: <20090326142832.0dba187a@gluon.draftnet> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@FreeBSD.org Subject: Re: kern/108581: [sysctl] sysctl: hw.acpi.cpu.cx_lowest: Invalid argument X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 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 Mar 2009 14:33:15 -0000 on 26/03/2009 16:28 Bruce Cran said the following: > On Thu, 26 Mar 2009 16:09:10 +0200 > Andriy Gapon wrote: >> If you specifically mean the generic case (non-cst) as you mention in >> the PR, then I think that you didn't notice that cpu_cx_count (the >> global variable) gets updated in acpi_cpu_generic_cx_probe, So after >> looping over all CPUs it has the value of the maximum Cx level >> supported by at least one CPU. Only then we loop again and determine >> the smallest of the supported maximums. > > Yes, I had missed that. I think the problem however is still that in > the generic cx case the global is re-initialized to 0 and never gets > updated. It would be interesting to catch where/when this happens if this is indeed the case. -- Andriy Gapon From owner-freebsd-acpi@FreeBSD.ORG Thu Mar 26 14:37:53 2009 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2B21B106564A; Thu, 26 Mar 2009 14:37:53 +0000 (UTC) (envelope-from bruce@cran.org.uk) Received: from muon.cran.org.uk (brucec-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:c09::2]) by mx1.freebsd.org (Postfix) with ESMTP id D9F8D8FC19; Thu, 26 Mar 2009 14:37:52 +0000 (UTC) (envelope-from bruce@cran.org.uk) Received: from muon.cran.org.uk (localhost [127.0.0.1]) by muon.cran.org.uk (Postfix) with ESMTP id A5F0119017; Thu, 26 Mar 2009 14:37:51 +0000 (GMT) X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on muon X-Spam-Level: X-Spam-Status: No, score=-2.6 required=8.0 tests=AWL,BAYES_00,NO_RELAYS autolearn=ham version=3.2.5 Received: from gluon.draftnet (unknown [IPv6:2a01:348:10f:0:240:f4ff:fe57:9871]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by muon.cran.org.uk (Postfix) with ESMTPSA; Thu, 26 Mar 2009 14:37:51 +0000 (GMT) Date: Thu, 26 Mar 2009 14:37:31 +0000 From: Bruce Cran To: John Baldwin Message-ID: <20090326143731.0d2b7711@gluon.draftnet> In-Reply-To: <200903260937.51028.jhb@freebsd.org> References: <200903200030.n2K0U3iG011009@freefall.freebsd.org> <20090325223914.4387eeae@gluon.draftnet> <200903260937.51028.jhb@freebsd.org> X-Mailer: Claws Mail 3.7.1 (GTK+ 2.14.7; i386-portbld-freebsd7.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Cc: Daniel =?utf-8?Q?Dvo=C5=99=C3=A1k?= , freebsd-acpi@freebsd.org Subject: Re: kern/108581: [sysctl] sysctl: hw.acpi.cpu.cx_lowest: Invalid argument X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 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 Mar 2009 14:37:53 -0000 On Thu, 26 Mar 2009 09:37:50 -0400 John Baldwin wrote: > No, the code is doing things differently on purpose (though I'm not > completely sure why). For _CST it sets cpu_cx_count to the maximum > Cx level supported by any CPU in the system. For non-_CST it sets it > to the maximum Cx level supported by all CPUs in the system. I think > it is correct for cpu_cx_count to always start at 0 and only be > bumped up to a higher setting. Setting it to 3 would be very wrong > for the _CST case as I've seen CPUs that support C4. =46rom briefly reading through the specifications I'd assumed the maximum power state was C3. =20 I had thought the _CST block was wrong because in acpi_cpu_global_cx_lowest_sysctl it validates the new value against cpu_cx_count; if one CPU has a lower cx state than the others, then won't this tell the other CPUs to use an unsupported state? --=20 Bruce Cran From owner-freebsd-acpi@FreeBSD.ORG Thu Mar 26 14:42:02 2009 Return-Path: Delivered-To: freebsd-acpi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4CA2D1065723 for ; Thu, 26 Mar 2009 14:42:02 +0000 (UTC) (envelope-from bruce@cran.org.uk) Received: from muon.cran.org.uk (brucec-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:c09::2]) by mx1.freebsd.org (Postfix) with ESMTP id 136968FC14 for ; Thu, 26 Mar 2009 14:42:02 +0000 (UTC) (envelope-from bruce@cran.org.uk) Received: from muon.cran.org.uk (localhost [127.0.0.1]) by muon.cran.org.uk (Postfix) with ESMTP id BBC5419017; Thu, 26 Mar 2009 14:42:00 +0000 (GMT) X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on muon X-Spam-Level: X-Spam-Status: No, score=-2.6 required=8.0 tests=AWL,BAYES_00,NO_RELAYS autolearn=ham version=3.2.5 Received: from gluon.draftnet (unknown [IPv6:2a01:348:10f:0:240:f4ff:fe57:9871]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by muon.cran.org.uk (Postfix) with ESMTPSA; Thu, 26 Mar 2009 14:42:00 +0000 (GMT) Date: Thu, 26 Mar 2009 14:41:40 +0000 From: Bruce Cran To: Andriy Gapon Message-ID: <20090326144140.2203c0d8@gluon.draftnet> In-Reply-To: <49CB9224.6010509@icyb.net.ua> References: <200903200030.n2K0U3iG011009@freefall.freebsd.org> <20090325223914.4387eeae@gluon.draftnet> <49CB8C86.4020800@icyb.net.ua> <20090326142832.0dba187a@gluon.draftnet> <49CB9224.6010509@icyb.net.ua> X-Mailer: Claws Mail 3.7.1 (GTK+ 2.14.7; i386-portbld-freebsd7.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@FreeBSD.org Subject: Re: kern/108581: [sysctl] sysctl: hw.acpi.cpu.cx_lowest: Invalid argument X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 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 Mar 2009 14:42:07 -0000 On Thu, 26 Mar 2009 16:33:08 +0200 Andriy Gapon wrote: > on 26/03/2009 16:28 Bruce Cran said the following: > > On Thu, 26 Mar 2009 16:09:10 +0200 > > Andriy Gapon wrote: > >> If you specifically mean the generic case (non-cst) as you mention > >> in the PR, then I think that you didn't notice that cpu_cx_count > >> (the global variable) gets updated in acpi_cpu_generic_cx_probe, > >> So after looping over all CPUs it has the value of the maximum Cx > >> level supported by at least one CPU. Only then we loop again and > >> determine the smallest of the supported maximums. > > > > Yes, I had missed that. I think the problem however is still that > > in the generic cx case the global is re-initialized to 0 and never > > gets updated. > > It would be interesting to catch where/when this happens if this is > indeed the case. > I added lots of printfs to acpi_cpu.c and found that it's occuring in acpi_cpu_startup; initializing it to 3 in that function (which I wrongly assumed was the lowest Cx state supported in ACPI) fixed the problem on my Athlon XP PC because the generic cx handling code then lowered cpu_cx_count to 1 based on the fact that sc->cpu_cx_count was also 1. -- Bruce Cran From owner-freebsd-acpi@FreeBSD.ORG Thu Mar 26 14:51:11 2009 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B99B310656D0 for ; Thu, 26 Mar 2009 14:51:11 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 7D1858FC1E for ; Thu, 26 Mar 2009 14:51:11 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (pool-98-109-39-197.nwrknj.fios.verizon.net [98.109.39.197]) by cyrus.watson.org (Postfix) with ESMTPSA id 0A19146B46; Thu, 26 Mar 2009 10:51:11 -0400 (EDT) Received: from localhost (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.14.3/8.14.3) with ESMTP id n2QEowM6083075; Thu, 26 Mar 2009 10:51:04 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: Bruce Cran Date: Thu, 26 Mar 2009 10:49:02 -0400 User-Agent: KMail/1.9.7 References: <200903200030.n2K0U3iG011009@freefall.freebsd.org> <200903260937.51028.jhb@freebsd.org> <20090326142456.042ea2f0@gluon.draftnet> In-Reply-To: <20090326142456.042ea2f0@gluon.draftnet> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200903261049.02977.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Thu, 26 Mar 2009 10:51:04 -0400 (EDT) X-Virus-Scanned: ClamAV 0.94.2/9169/Thu Mar 26 00:13:48 2009 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: Daniel =?utf-8?q?Dvo=C5=99=C3=A1k?= , freebsd-acpi@freebsd.org Subject: Re: kern/108581: [sysctl] sysctl: hw.acpi.cpu.cx_lowest: Invalid argument X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 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 Mar 2009 14:51:13 -0000 On Thursday 26 March 2009 10:24:56 am Bruce Cran wrote: > On Thu, 26 Mar 2009 09:37:50 -0400 > John Baldwin wrote: >=20 > > On Wednesday 25 March 2009 6:39:14 pm Bruce Cran wrote: > > > On Fri, 20 Mar 2009 00:30:03 GMT > > > Daniel Dvo=C5=99=C3=A1k wrote: > > >=20 > > > > The following reply was made to PR kern/108581; it has been noted > > > > by GNATS. > > > >=20 > > > > From: =3D?UTF-8?Q?Daniel_Dvo=3DC5=3D99=3DC3=3DA1k?=3D > > > > To: , > > > > > > > > Cc: =20 > > > > Subject: Re: kern/108581: [sysctl] sysctl: hw.acpi.cpu.cx_lowest: > > > > Invalid argument Date: Fri, 20 Mar 2009 01:01:51 +0100 > > > >=20 > > > > This is a multi-part message in MIME format. > > > > =20 > > > > ------=3D_NextPart_000_0007_01C9A8F7.746C4190 > > > > Content-Type: text/plain; > > > > charset=3D"UTF-8" > > > > Content-Transfer-Encoding: quoted-printable > > > > =20 > > > > Hi acpi team, > > > > =3D20 > > > > today I have installed fbsd 7.1R on one box with this relativly > > > > old =3D error and I was surprised about results .. it is the same: > > > > =3D20 > > > > # uname -a > > > > FreeBSD X.Y.Z 7.1-RELEASE FreeBSD 7.1-RELEASE #0: Thu Jan 1 > > > > 14:37:25 =3D UTC 2009 > > > > root@logan.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC =3D i386 > > > > =20 > > > > # sysctl dev.cpu.0.cx_supported > > > > dev.cpu.0.cx_supported: C1/0 > > > > =20 > > > > # sysctl hw.acpi.cpu.cx_lowest=3D3DC1 > > > > hw.acpi.cpu.cx_lowest: C1 > > > > sysctl: hw.acpi.cpu.cx_lowest: Invalid argument > > > > =3D20 > > > > # sysctl hw.acpi.cpu.cx_lowest=3D3DC0 > > > > hw.acpi.cpu.cx_lowest: C1 > > > > sysctl: hw.acpi.cpu.cx_lowest: Invalid argument > > > > =3D20 > > > > # sysctl hw.acpi.cpu.cx_lowest=3D3DC1/0 > > > > hw.acpi.cpu.cx_lowest: C1 > > > > sysctl: hw.acpi.cpu.cx_lowest: Invalid argument > > > > =20 > > > > # dmesg -a | grep "acpi" > > > > acpi0: on motherboard > > > > acpi0: Overriding SCI Interrupt from IRQ 9 to IRQ 20 > > > > acpi0: [ITHREAD] > > > > acpi0: Power Button (fixed) > > > > acpi0: reservation of 0, a0000 (3) failed > > > > acpi0: reservation of 100000, ff00000 (3) failed > > > > acpi_timer0: <24-bit timer at 3.579545MHz> port 0xe408-0xe40b on > > > > acpi0 acpi_button0: on acpi0 > > > > pcib0: port 0xcf8-0xcff on acpi0 > > > > atkbdc0: port 0x60,0x64 irq 1 on > > > > acpi0 cpu0: on acpi0 > > > > hw.acpi.cpu.cx_lowest: > > > > hw.acpi.cpu.cx_lowest > > >=20 > > > I think I've found the problem and have updated the PR kern/108581 > > > (http://www.freebsd.org/cgi/query-pr.cgi?pr=3Dkern/108581). The global > > > cpu_cx_count was being initialized to 0 in acpi_cpu_startup > > > (in /sys/dev/acpica/acpi_cpu.c) but code below it appears to assume > > > that it's been intialized to 3 because it only sets it if it's > > > higher than the current CPU supports - that is, cpu_cx_count should > > > reflect the highest Cx state that all CPUs support. > > >=20 > > > There's also a bug in the _CST section just below it; I think the > > > line: > > >=20 > > > if (sc->cpu_cx_count > cpu_cx_count) > > >=20 > > > should be > > >=20 > > > if (sc->cpu_cx_count < cpu_cx_count) > >=20 > > No, the code is doing things differently on purpose (though I'm not > > completely sure why). For _CST it sets cpu_cx_count to the maximum > > Cx level supported by any CPU in the system. For non-_CST it sets it > > to the maximum Cx level supported by all CPUs in the system. I think > > it is correct for cpu_cx_count to always start at 0 and only be > > bumped up to a higher setting. Setting it to 3 would be very wrong > > for the _CST case as I've seen CPUs that support C4. > >=20 > > Note that C1 _always_ exists as it is simply the "hlt" instruction > > that has existed since the 8086. Only C2+ require power-saving > > extension support in the CPU, so cpu_cx_count should always end up >=3D > > 1. It would be interesting if you could add some debug printfs to > > print out the values that acpi_cpu_generic_cx_probe() computes for > > 'sc->cpu_cx_count' (sysctl dev.cpu could be useful for this) as well > > as all changes to the 'cpu_cx_count' global variable. > >=20 >=20 > For my Athlon XP CPU, acpi_cpu_generic_cx_probe sets sc->cpu_cx_count > to 1, and subsequently dev.cpu.0.cx_lowest has always worked. After > adding printfs I found that the problem is that the cpu_cx_generic > block in acpi_cpu_startup is being run and because cpu_cx_count is set > to 0 it never gets updated; the statement "if (sc->cpu_cx_count < > cpu_cx_count)" is never true. Err, you missed the end of acpi_cpu_generic_cx_probe() where it does this: /* Update the largest cx_count seen so far */ if (sc->cpu_cx_count > cpu_cx_count) cpu_cx_count =3D sc->cpu_cx_count; That is effectively the same as the for loop in the _CST case that finds th= e=20 maximum supported state of all CPUs. It would probably be clearer to move= =20 that into acpi_cpu_startup() instead. =2D-=20 John Baldwin From owner-freebsd-acpi@FreeBSD.ORG Thu Mar 26 14:51:17 2009 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 35B4E10656C8 for ; Thu, 26 Mar 2009 14:51:17 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 043588FC1B for ; Thu, 26 Mar 2009 14:51:17 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (pool-98-109-39-197.nwrknj.fios.verizon.net [98.109.39.197]) by cyrus.watson.org (Postfix) with ESMTPSA id 8DB9E46B43; Thu, 26 Mar 2009 10:51:16 -0400 (EDT) Received: from localhost (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.14.3/8.14.3) with ESMTP id n2QEowM7083075; Thu, 26 Mar 2009 10:51:10 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: Bruce Cran Date: Thu, 26 Mar 2009 10:50:51 -0400 User-Agent: KMail/1.9.7 References: <200903200030.n2K0U3iG011009@freefall.freebsd.org> <200903260937.51028.jhb@freebsd.org> <20090326143731.0d2b7711@gluon.draftnet> In-Reply-To: <20090326143731.0d2b7711@gluon.draftnet> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200903261050.51602.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Thu, 26 Mar 2009 10:51:10 -0400 (EDT) X-Virus-Scanned: ClamAV 0.94.2/9169/Thu Mar 26 00:13:48 2009 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: Daniel =?utf-8?q?Dvo=C5=99=C3=A1k?= , freebsd-acpi@freebsd.org Subject: Re: kern/108581: [sysctl] sysctl: hw.acpi.cpu.cx_lowest: Invalid argument X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 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 Mar 2009 14:51:17 -0000 On Thursday 26 March 2009 10:37:31 am Bruce Cran wrote: > On Thu, 26 Mar 2009 09:37:50 -0400 > John Baldwin wrote: > > > No, the code is doing things differently on purpose (though I'm not > > completely sure why). For _CST it sets cpu_cx_count to the maximum > > Cx level supported by any CPU in the system. For non-_CST it sets it > > to the maximum Cx level supported by all CPUs in the system. I think > > it is correct for cpu_cx_count to always start at 0 and only be > > bumped up to a higher setting. Setting it to 3 would be very wrong > > for the _CST case as I've seen CPUs that support C4. > > From briefly reading through the specifications I'd assumed the maximum > power state was C3. For the non _CST case that is all that is defined, yes. However, _CST is a variable length array of Cx states, so it can support arbitrary numbers of states. > I had thought the _CST block was wrong because in > acpi_cpu_global_cx_lowest_sysctl it validates the new value against > cpu_cx_count; if one CPU has a lower cx state than the others, then > won't this tell the other CPUs to use an unsupported state? It depends on if the CPU driver is smart enough to cap requests to sc->cpu_cx_count, though if it does presumably it would do that in the cx_generic case as well. I'm not sure why it behaves differently for the _CST case, but I do think it is on purpose at least rather than an accidental bug. Perhaps Nate can chime in with why? -- John Baldwin From owner-freebsd-acpi@FreeBSD.ORG Thu Mar 26 15:04:27 2009 Return-Path: Delivered-To: freebsd-acpi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 252BC10657DF; Thu, 26 Mar 2009 15:04:27 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 3CE968FC22; Thu, 26 Mar 2009 15:04:24 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id RAA28791; Thu, 26 Mar 2009 17:04:20 +0200 (EET) (envelope-from avg@icyb.net.ua) Message-ID: <49CB9973.3010306@icyb.net.ua> Date: Thu, 26 Mar 2009 17:04:19 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.21 (X11/20090323) MIME-Version: 1.0 To: Bruce Cran References: <200903200030.n2K0U3iG011009@freefall.freebsd.org> <20090325223914.4387eeae@gluon.draftnet> <49CB8C86.4020800@icyb.net.ua> <20090326142832.0dba187a@gluon.draftnet> <49CB9224.6010509@icyb.net.ua> <20090326144140.2203c0d8@gluon.draftnet> In-Reply-To: <20090326144140.2203c0d8@gluon.draftnet> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@FreeBSD.org, John Baldwin Subject: Re: kern/108581: [sysctl] sysctl: hw.acpi.cpu.cx_lowest: Invalid argument X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 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 Mar 2009 15:04:28 -0000 on 26/03/2009 16:41 Bruce Cran said the following: > On Thu, 26 Mar 2009 16:33:08 +0200 > Andriy Gapon wrote: > >> on 26/03/2009 16:28 Bruce Cran said the following: >>> On Thu, 26 Mar 2009 16:09:10 +0200 >>> Andriy Gapon wrote: >>>> If you specifically mean the generic case (non-cst) as you mention >>>> in the PR, then I think that you didn't notice that cpu_cx_count >>>> (the global variable) gets updated in acpi_cpu_generic_cx_probe, >>>> So after looping over all CPUs it has the value of the maximum Cx >>>> level supported by at least one CPU. Only then we loop again and >>>> determine the smallest of the supported maximums. >>> Yes, I had missed that. I think the problem however is still that >>> in the generic cx case the global is re-initialized to 0 and never >>> gets updated. >> It would be interesting to catch where/when this happens if this is >> indeed the case. >> > > I added lots of printfs to acpi_cpu.c and found that it's occuring in > acpi_cpu_startup; initializing it to 3 in that function (which I wrongly > assumed was the lowest Cx state supported in ACPI) fixed the problem on > my Athlon XP PC because the generic cx handling code then lowered > cpu_cx_count to 1 based on the fact that sc->cpu_cx_count was also 1. > Ok, yes, the real issue is in acpi_cpu_generic_cx_probe, namely in early exits from it. So, sc->cpu_cx_count is always set to at least 1, but if we exit via one of the returns before the end of function, then global cpu_cx_count is never updated. -- Andriy Gapon From owner-freebsd-acpi@FreeBSD.ORG Thu Mar 26 15:10:58 2009 Return-Path: Delivered-To: freebsd-acpi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 919521065674; Thu, 26 Mar 2009 15:10:58 +0000 (UTC) (envelope-from bruce@cran.org.uk) Received: from muon.cran.org.uk (brucec-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:c09::2]) by mx1.freebsd.org (Postfix) with ESMTP id 4B0D58FC21; Thu, 26 Mar 2009 15:10:58 +0000 (UTC) (envelope-from bruce@cran.org.uk) Received: from muon.cran.org.uk (localhost [127.0.0.1]) by muon.cran.org.uk (Postfix) with ESMTP id E61DC19017; Thu, 26 Mar 2009 15:10:56 +0000 (GMT) X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on muon X-Spam-Level: X-Spam-Status: No, score=-2.6 required=8.0 tests=AWL,BAYES_00,NO_RELAYS autolearn=ham version=3.2.5 Received: from gluon.draftnet (unknown [IPv6:2a01:348:10f:0:240:f4ff:fe57:9871]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by muon.cran.org.uk (Postfix) with ESMTPSA; Thu, 26 Mar 2009 15:10:56 +0000 (GMT) Date: Thu, 26 Mar 2009 15:10:35 +0000 From: Bruce Cran To: Andriy Gapon Message-ID: <20090326151035.51e4196e@gluon.draftnet> In-Reply-To: <49CB9973.3010306@icyb.net.ua> References: <200903200030.n2K0U3iG011009@freefall.freebsd.org> <20090325223914.4387eeae@gluon.draftnet> <49CB8C86.4020800@icyb.net.ua> <20090326142832.0dba187a@gluon.draftnet> <49CB9224.6010509@icyb.net.ua> <20090326144140.2203c0d8@gluon.draftnet> <49CB9973.3010306@icyb.net.ua> X-Mailer: Claws Mail 3.7.1 (GTK+ 2.14.7; i386-portbld-freebsd7.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@FreeBSD.org, John Baldwin Subject: Re: kern/108581: [sysctl] sysctl: hw.acpi.cpu.cx_lowest: Invalid argument X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 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 Mar 2009 15:10:59 -0000 On Thu, 26 Mar 2009 17:04:19 +0200 Andriy Gapon wrote: > on 26/03/2009 16:41 Bruce Cran said the following: > > I added lots of printfs to acpi_cpu.c and found that it's occuring > > in acpi_cpu_startup; initializing it to 3 in that function (which I > > wrongly assumed was the lowest Cx state supported in ACPI) fixed > > the problem on my Athlon XP PC because the generic cx handling code > > then lowered cpu_cx_count to 1 based on the fact that > > sc->cpu_cx_count was also 1. > > > > Ok, yes, the real issue is in acpi_cpu_generic_cx_probe, namely in > early exits from it. So, sc->cpu_cx_count is always set to at least > 1, but if we exit via one of the returns before the end of function, > then global cpu_cx_count is never updated. > Exactly: acpi: acpi_cpu_startup: initializing cpu_cx_count to 0 acpi_cpu_generic_cx_probe if sc->cpu_p_blk_len < 5 [sc->cpu_p_blk_len = 0] acpi: acpi_cpu_startup: cpu 0,cpu_cx_count = 0,sc->cpu_cx_count = 1 So we're hitting an early exit in acpi_cpu_generic_cx_probe. -- Bruce Cran From owner-freebsd-acpi@FreeBSD.ORG Thu Mar 26 15:14:28 2009 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6ACB110656D5 for ; Thu, 26 Mar 2009 15:14:28 +0000 (UTC) (envelope-from sepotvin@FreeBSD.org) Received: from zerofail.com (gatekeeper1.zerofail.com [208.71.11.38]) by mx1.freebsd.org (Postfix) with ESMTP id 0E6568FC29 for ; Thu, 26 Mar 2009 15:14:27 +0000 (UTC) (envelope-from sepotvin@FreeBSD.org) Received: from telcobridges.com by freebsd.org (zerofail.com) (SecurityGateway 1.1.4) with SMTP id SG002296242.MSG for ; Thu, 26 Mar 2009 11:04:18 -0400 Received: from leia.telcobridges.lan ([208.94.105.59]) by telcobridges.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 26 Mar 2009 11:04:18 -0400 Message-ID: <49CB9972.4030502@FreeBSD.org> Date: Thu, 26 Mar 2009 11:04:18 -0400 From: "Stephane E. Potvin" Organization: FreeBSD Project User-Agent: Thunderbird 2.0.0.21 (X11/20090323) MIME-Version: 1.0 To: John Baldwin References: <200903200030.n2K0U3iG011009@freefall.freebsd.org> <200903260937.51028.jhb@freebsd.org> <20090326143731.0d2b7711@gluon.draftnet> <200903261050.51602.jhb@freebsd.org> In-Reply-To: <200903261050.51602.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Mar 2009 15:04:18.0836 (UTC) FILETIME=[23239540:01C9AE24] X-SGHeloLookup-Result: hardfail smtp.helo=telcobridges.com (does not match 208.71.8.41) X-SGOP-RefID: str=0001.0A090205.49CB9973.007F,ss=1,fgs=0 (_st=1 _vt=0 _iwf=0) Cc: =?ISO-8859-1?Q?Daniel_Dvor=28=E1k?= , freebsd-acpi@freebsd.org Subject: Re: kern/108581: [sysctl] sysctl: hw.acpi.cpu.cx_lowest: Invalid argument X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 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 Mar 2009 15:14:29 -0000 John Baldwin wrote: > On Thursday 26 March 2009 10:37:31 am Bruce Cran wrote: >> On Thu, 26 Mar 2009 09:37:50 -0400 >> John Baldwin wrote: >> >>> No, the code is doing things differently on purpose (though I'm not >>> completely sure why). For _CST it sets cpu_cx_count to the maximum >>> Cx level supported by any CPU in the system. For non-_CST it sets it >>> to the maximum Cx level supported by all CPUs in the system. I think >>> it is correct for cpu_cx_count to always start at 0 and only be >>> bumped up to a higher setting. Setting it to 3 would be very wrong >>> for the _CST case as I've seen CPUs that support C4. >> From briefly reading through the specifications I'd assumed the maximum >> power state was C3. > > For the non _CST case that is all that is defined, yes. However, _CST is a > variable length array of Cx states, so it can support arbitrary numbers of > states. > >> I had thought the _CST block was wrong because in >> acpi_cpu_global_cx_lowest_sysctl it validates the new value against >> cpu_cx_count; if one CPU has a lower cx state than the others, then >> won't this tell the other CPUs to use an unsupported state? > > It depends on if the CPU driver is smart enough to cap requests to > sc->cpu_cx_count, though if it does presumably it would do that in the > cx_generic case as well. I'm not sure why it behaves differently for the > _CST case, but I do think it is on purpose at least rather than an accidental > bug. Perhaps Nate can chime in with why? > The intent when I added support for cx states on SMP systems was to use the same maximum cx_state for all CPUs when _CST is not used (cx_generic case) and to respect per-processor maximum cx_state when _CST is present and can be used. This whole piece of code is really convoluted and there's been a few errors found in it over time so I wouldn't be surprised if there were some still lurking. Could you send me privately a copy of your ASL and a verbose boot log? Steph From owner-freebsd-acpi@FreeBSD.ORG Thu Mar 26 15:15:43 2009 Return-Path: Delivered-To: freebsd-acpi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5389010656BD; Thu, 26 Mar 2009 15:15:43 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 4E2378FC15; Thu, 26 Mar 2009 15:15:41 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id RAA29006; Thu, 26 Mar 2009 17:15:40 +0200 (EET) (envelope-from avg@icyb.net.ua) Message-ID: <49CB9C1B.4070308@icyb.net.ua> Date: Thu, 26 Mar 2009 17:15:39 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.21 (X11/20090323) MIME-Version: 1.0 To: John Baldwin References: <200903200030.n2K0U3iG011009@freefall.freebsd.org> <20090325223914.4387eeae@gluon.draftnet> <49CB8C86.4020800@icyb.net.ua> <20090326142832.0dba187a@gluon.draftnet> <49CB9224.6010509@icyb.net.ua> <20090326144140.2203c0d8@gluon.draftnet> <49CB9973.3010306@icyb.net.ua> <20090326151035.51e4196e@gluon.draftnet> In-Reply-To: <20090326151035.51e4196e@gluon.draftnet> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@FreeBSD.org Subject: Re: kern/108581: [sysctl] sysctl: hw.acpi.cpu.cx_lowest: Invalid argument X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 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 Mar 2009 15:15:45 -0000 on 26/03/2009 17:10 Bruce Cran said the following: > On Thu, 26 Mar 2009 17:04:19 +0200 > Andriy Gapon wrote: > >> on 26/03/2009 16:41 Bruce Cran said the following: > >>> I added lots of printfs to acpi_cpu.c and found that it's occuring >>> in acpi_cpu_startup; initializing it to 3 in that function (which I >>> wrongly assumed was the lowest Cx state supported in ACPI) fixed >>> the problem on my Athlon XP PC because the generic cx handling code >>> then lowered cpu_cx_count to 1 based on the fact that >>> sc->cpu_cx_count was also 1. >>> >> Ok, yes, the real issue is in acpi_cpu_generic_cx_probe, namely in >> early exits from it. So, sc->cpu_cx_count is always set to at least >> 1, but if we exit via one of the returns before the end of function, >> then global cpu_cx_count is never updated. >> > > Exactly: > > acpi: acpi_cpu_startup: initializing cpu_cx_count to 0 > acpi_cpu_generic_cx_probe > if sc->cpu_p_blk_len < 5 [sc->cpu_p_blk_len = 0] > acpi: acpi_cpu_startup: cpu 0,cpu_cx_count = 0,sc->cpu_cx_count = 1 > > So we're hitting an early exit in acpi_cpu_generic_cx_probe. > John, what would be a better fix - initialize the global variable to 1 or use goto in acpi_cpu_generic_cx_probe? I think the latter is more consistent and obvious, the former is simpler and safer, though. -- Andriy Gapon From owner-freebsd-acpi@FreeBSD.ORG Thu Mar 26 15:33:58 2009 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EA260106564A for ; Thu, 26 Mar 2009 15:33:58 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 7FDCF8FC0A for ; Thu, 26 Mar 2009 15:33:58 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (pool-98-109-39-197.nwrknj.fios.verizon.net [98.109.39.197]) by cyrus.watson.org (Postfix) with ESMTPSA id EA86A46B58; Thu, 26 Mar 2009 11:33:57 -0400 (EDT) Received: from localhost (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.14.3/8.14.3) with ESMTP id n2QFXpS0083482; Thu, 26 Mar 2009 11:33:52 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: Andriy Gapon Date: Thu, 26 Mar 2009 11:29:50 -0400 User-Agent: KMail/1.9.7 References: <200903200030.n2K0U3iG011009@freefall.freebsd.org> <20090326151035.51e4196e@gluon.draftnet> <49CB9C1B.4070308@icyb.net.ua> In-Reply-To: <49CB9C1B.4070308@icyb.net.ua> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200903261129.50419.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Thu, 26 Mar 2009 11:33:52 -0400 (EDT) X-Virus-Scanned: ClamAV 0.94.2/9169/Thu Mar 26 00:13:48 2009 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: freebsd-acpi@freebsd.org Subject: Re: kern/108581: [sysctl] sysctl: hw.acpi.cpu.cx_lowest: Invalid argument X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 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 Mar 2009 15:33:59 -0000 On Thursday 26 March 2009 11:15:39 am Andriy Gapon wrote: > on 26/03/2009 17:10 Bruce Cran said the following: > > On Thu, 26 Mar 2009 17:04:19 +0200 > > Andriy Gapon wrote: > > > >> on 26/03/2009 16:41 Bruce Cran said the following: > > > >>> I added lots of printfs to acpi_cpu.c and found that it's occuring > >>> in acpi_cpu_startup; initializing it to 3 in that function (which I > >>> wrongly assumed was the lowest Cx state supported in ACPI) fixed > >>> the problem on my Athlon XP PC because the generic cx handling code > >>> then lowered cpu_cx_count to 1 based on the fact that > >>> sc->cpu_cx_count was also 1. > >>> > >> Ok, yes, the real issue is in acpi_cpu_generic_cx_probe, namely in > >> early exits from it. So, sc->cpu_cx_count is always set to at least > >> 1, but if we exit via one of the returns before the end of function, > >> then global cpu_cx_count is never updated. > >> > > > > Exactly: > > > > acpi: acpi_cpu_startup: initializing cpu_cx_count to 0 > > acpi_cpu_generic_cx_probe > > if sc->cpu_p_blk_len < 5 [sc->cpu_p_blk_len = 0] > > acpi: acpi_cpu_startup: cpu 0,cpu_cx_count = 0,sc->cpu_cx_count = 1 > > > > So we're hitting an early exit in acpi_cpu_generic_cx_probe. > > > > John, what would be a better fix - initialize the global variable to 1 or use goto > in acpi_cpu_generic_cx_probe? > I think the latter is more consistent and obvious, the former is simpler and > safer, though. I would rather move the cpu_cx_count code out into acpi_cpu_startup() completely. It would more closely match the _CST code in that case. It is also easier to follow the logic this way as well as it is only modified in one place and not via a secret side-effect. --- //depot/vendor/freebsd/src/sys/dev/acpica/acpi_cpu.c 2009/02/19 14:40:18 +++ //depot/user/jhb/acpipci/dev/acpica/acpi_cpu.c 2009/03/26 15:28:32 @@ -609,10 +609,6 @@ sc->cpu_cx_count++; } } - - /* Update the largest cx_count seen so far */ - if (sc->cpu_cx_count > cpu_cx_count) - cpu_cx_count = sc->cpu_cx_count; } /* @@ -752,6 +748,8 @@ for (i = 0; i < cpu_ndevices; i++) { sc = device_get_softc(cpu_devices[i]); acpi_cpu_generic_cx_probe(sc); + if (sc->cpu_cx_count > cpu_cx_count) + cpu_cx_count = sc->cpu_cx_count; } /* -- John Baldwin From owner-freebsd-acpi@FreeBSD.ORG Thu Mar 26 15:40:24 2009 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BE70F1065670 for ; Thu, 26 Mar 2009 15:40:24 +0000 (UTC) (envelope-from sepotvin@FreeBSD.org) Received: from zerofail.com (gatekeeper1.zerofail.com [208.71.11.38]) by mx1.freebsd.org (Postfix) with ESMTP id 768FA8FC20 for ; Thu, 26 Mar 2009 15:40:24 +0000 (UTC) (envelope-from sepotvin@FreeBSD.org) Received: from telcobridges.com by freebsd.org (zerofail.com) (SecurityGateway 1.1.4) with SMTP id SG002297095.MSG for ; Thu, 26 Mar 2009 11:40:22 -0400 Received: from leia.telcobridges.lan ([208.94.105.59]) by telcobridges.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 26 Mar 2009 11:40:21 -0400 Message-ID: <49CBA1E5.2090902@FreeBSD.org> Date: Thu, 26 Mar 2009 11:40:21 -0400 From: "Stephane E. Potvin" Organization: FreeBSD Project User-Agent: Thunderbird 2.0.0.21 (X11/20090323) MIME-Version: 1.0 To: Andriy Gapon References: <200903200030.n2K0U3iG011009@freefall.freebsd.org> <20090325223914.4387eeae@gluon.draftnet> <49CB8C86.4020800@icyb.net.ua> <20090326142832.0dba187a@gluon.draftnet> <49CB9224.6010509@icyb.net.ua> <20090326144140.2203c0d8@gluon.draftnet> <49CB9973.3010306@icyb.net.ua> <20090326151035.51e4196e@gluon.draftnet> <49CB9C1B.4070308@icyb.net.ua> In-Reply-To: <49CB9C1B.4070308@icyb.net.ua> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Mar 2009 15:40:21.0344 (UTC) FILETIME=[2C181E00:01C9AE29] X-SGHeloLookup-Result: hardfail smtp.helo=telcobridges.com (does not match 208.71.8.41) X-SGOP-RefID: str=0001.0A090205.49CBA1E5.01E8,ss=1,fgs=0 (_st=1 _vt=0 _iwf=0) Cc: freebsd-acpi@freebsd.org Subject: Re: kern/108581: [sysctl] sysctl: hw.acpi.cpu.cx_lowest: Invalid argument X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 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 Mar 2009 15:40:25 -0000 Andriy Gapon wrote: > on 26/03/2009 17:10 Bruce Cran said the following: >> On Thu, 26 Mar 2009 17:04:19 +0200 >> Andriy Gapon wrote: >> >>> on 26/03/2009 16:41 Bruce Cran said the following: >>>> I added lots of printfs to acpi_cpu.c and found that it's occuring >>>> in acpi_cpu_startup; initializing it to 3 in that function (which I >>>> wrongly assumed was the lowest Cx state supported in ACPI) fixed >>>> the problem on my Athlon XP PC because the generic cx handling code >>>> then lowered cpu_cx_count to 1 based on the fact that >>>> sc->cpu_cx_count was also 1. >>>> >>> Ok, yes, the real issue is in acpi_cpu_generic_cx_probe, namely in >>> early exits from it. So, sc->cpu_cx_count is always set to at least >>> 1, but if we exit via one of the returns before the end of function, >>> then global cpu_cx_count is never updated. >>> >> Exactly: >> >> acpi: acpi_cpu_startup: initializing cpu_cx_count to 0 >> acpi_cpu_generic_cx_probe >> if sc->cpu_p_blk_len < 5 [sc->cpu_p_blk_len = 0] >> acpi: acpi_cpu_startup: cpu 0,cpu_cx_count = 0,sc->cpu_cx_count = 1 >> >> So we're hitting an early exit in acpi_cpu_generic_cx_probe. >> > > John, what would be a better fix - initialize the global variable to 1 or use goto > in acpi_cpu_generic_cx_probe? > I think the latter is more consistent and obvious, the former is simpler and > safer, though. > Your right, it seems that I need to order some more pointy hats. There should have been a goto there to jump at the end in order to initialize the global cpu_cx_count. The following patch should fix your issue. John, is this ok with you? Index: acpi_cpu.c =================================================================== --- acpi_cpu.c (revision 190318) +++ acpi_cpu.c (working copy) @@ -576,7 +576,7 @@ * "only" C1-C3 is not a hardship. */ if (sc->cpu_p_blk_len < 5) - return; + goto done; /* Validate and allocate resources for C2 (P_LVL2). */ gas.SpaceId = ACPI_ADR_SPACE_SYSTEM_IO; @@ -594,7 +594,7 @@ } } if (sc->cpu_p_blk_len < 6) - return; + goto done; /* Validate and allocate resources for C3 (P_LVL3). */ if (AcpiGbl_FADT.C3Latency <= 1000 && !(cpu_quirks & CPU_QUIRK_NO_C3)) { @@ -610,6 +610,7 @@ } } +done: /* Update the largest cx_count seen so far */ if (sc->cpu_cx_count > cpu_cx_count) cpu_cx_count = sc->cpu_cx_count; From owner-freebsd-acpi@FreeBSD.ORG Thu Mar 26 15:41:19 2009 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 431111065691; Thu, 26 Mar 2009 15:41:19 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 3C80A8FC13; Thu, 26 Mar 2009 15:41:17 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id RAA29798; Thu, 26 Mar 2009 17:41:16 +0200 (EET) (envelope-from avg@icyb.net.ua) Message-ID: <49CBA21B.5050207@icyb.net.ua> Date: Thu, 26 Mar 2009 17:41:15 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.21 (X11/20090323) MIME-Version: 1.0 To: John Baldwin References: <200903200030.n2K0U3iG011009@freefall.freebsd.org> <20090326151035.51e4196e@gluon.draftnet> <49CB9C1B.4070308@icyb.net.ua> <200903261129.50419.jhb@freebsd.org> In-Reply-To: <200903261129.50419.jhb@freebsd.org> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@freebsd.org Subject: Re: kern/108581: [sysctl] sysctl: hw.acpi.cpu.cx_lowest: Invalid argument X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 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 Mar 2009 15:41:21 -0000 on 26/03/2009 17:29 John Baldwin said the following: > On Thursday 26 March 2009 11:15:39 am Andriy Gapon wrote: >> on 26/03/2009 17:10 Bruce Cran said the following: >>> On Thu, 26 Mar 2009 17:04:19 +0200 >>> Andriy Gapon wrote: >>> >>>> on 26/03/2009 16:41 Bruce Cran said the following: >>>>> I added lots of printfs to acpi_cpu.c and found that it's occuring >>>>> in acpi_cpu_startup; initializing it to 3 in that function (which I >>>>> wrongly assumed was the lowest Cx state supported in ACPI) fixed >>>>> the problem on my Athlon XP PC because the generic cx handling code >>>>> then lowered cpu_cx_count to 1 based on the fact that >>>>> sc->cpu_cx_count was also 1. >>>>> >>>> Ok, yes, the real issue is in acpi_cpu_generic_cx_probe, namely in >>>> early exits from it. So, sc->cpu_cx_count is always set to at least >>>> 1, but if we exit via one of the returns before the end of function, >>>> then global cpu_cx_count is never updated. >>>> >>> Exactly: >>> >>> acpi: acpi_cpu_startup: initializing cpu_cx_count to 0 >>> acpi_cpu_generic_cx_probe >>> if sc->cpu_p_blk_len < 5 [sc->cpu_p_blk_len = 0] >>> acpi: acpi_cpu_startup: cpu 0,cpu_cx_count = 0,sc->cpu_cx_count = 1 >>> >>> So we're hitting an early exit in acpi_cpu_generic_cx_probe. >>> >> John, what would be a better fix - initialize the global variable to 1 or > use goto >> in acpi_cpu_generic_cx_probe? >> I think the latter is more consistent and obvious, the former is simpler and >> safer, though. > > I would rather move the cpu_cx_count code out into acpi_cpu_startup() > completely. It would more closely match the _CST code in that case. It is > also easier to follow the logic this way as well as it is only modified in > one place and not via a secret side-effect. Perfect! > --- //depot/vendor/freebsd/src/sys/dev/acpica/acpi_cpu.c 2009/02/19 14:40:18 > +++ //depot/user/jhb/acpipci/dev/acpica/acpi_cpu.c 2009/03/26 15:28:32 > @@ -609,10 +609,6 @@ > sc->cpu_cx_count++; > } > } > - > - /* Update the largest cx_count seen so far */ > - if (sc->cpu_cx_count > cpu_cx_count) > - cpu_cx_count = sc->cpu_cx_count; > } > > /* > @@ -752,6 +748,8 @@ > for (i = 0; i < cpu_ndevices; i++) { > sc = device_get_softc(cpu_devices[i]); > acpi_cpu_generic_cx_probe(sc); > + if (sc->cpu_cx_count > cpu_cx_count) > + cpu_cx_count = sc->cpu_cx_count; > } > > /* > > -- Andriy Gapon From owner-freebsd-acpi@FreeBSD.ORG Thu Mar 26 16:38:42 2009 Return-Path: Delivered-To: freebsd-acpi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D5B641065675 for ; Thu, 26 Mar 2009 16:38:42 +0000 (UTC) (envelope-from nate@root.org) Received: from nlpi029.prodigy.net (nlpi029.sbcis.sbc.com [207.115.36.58]) by mx1.freebsd.org (Postfix) with ESMTP id A30618FC0C for ; Thu, 26 Mar 2009 16:38:42 +0000 (UTC) (envelope-from nate@root.org) Received: from [10.0.5.18] (ppp-71-139-12-243.dsl.snfc21.pacbell.net [71.139.12.243]) (authenticated bits=0) by nlpi029.prodigy.net (8.13.8 smtpauth/dk/8.13.8) with ESMTP id n2QGcdeP025152; Thu, 26 Mar 2009 11:38:40 -0500 Message-ID: <49CBAF8F.9080301@root.org> Date: Thu, 26 Mar 2009 09:38:39 -0700 From: Nate Lawson User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: "Stephane E. Potvin" References: <200903200030.n2K0U3iG011009@freefall.freebsd.org> <20090325223914.4387eeae@gluon.draftnet> <49CB8C86.4020800@icyb.net.ua> <20090326142832.0dba187a@gluon.draftnet> <49CB9224.6010509@icyb.net.ua> <20090326144140.2203c0d8@gluon.draftnet> <49CB9973.3010306@icyb.net.ua> <20090326151035.51e4196e@gluon.draftnet> <49CB9C1B.4070308@icyb.net.ua> <49CBA1E5.2090902@FreeBSD.org> In-Reply-To: <49CBA1E5.2090902@FreeBSD.org> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@FreeBSD.org, Andriy Gapon Subject: Re: kern/108581: [sysctl] sysctl: hw.acpi.cpu.cx_lowest: Invalid argument X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 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 Mar 2009 16:38:43 -0000 Stephane E. Potvin wrote: > Andriy Gapon wrote: >> on 26/03/2009 17:10 Bruce Cran said the following: >>> On Thu, 26 Mar 2009 17:04:19 +0200 >>> Andriy Gapon wrote: >>> >>>> on 26/03/2009 16:41 Bruce Cran said the following: >>>>> I added lots of printfs to acpi_cpu.c and found that it's occuring >>>>> in acpi_cpu_startup; initializing it to 3 in that function (which I >>>>> wrongly assumed was the lowest Cx state supported in ACPI) fixed >>>>> the problem on my Athlon XP PC because the generic cx handling code >>>>> then lowered cpu_cx_count to 1 based on the fact that >>>>> sc->cpu_cx_count was also 1. >>>>> >>>> Ok, yes, the real issue is in acpi_cpu_generic_cx_probe, namely in >>>> early exits from it. So, sc->cpu_cx_count is always set to at least >>>> 1, but if we exit via one of the returns before the end of function, >>>> then global cpu_cx_count is never updated. >>>> >>> Exactly: >>> >>> acpi: acpi_cpu_startup: initializing cpu_cx_count to 0 >>> acpi_cpu_generic_cx_probe >>> if sc->cpu_p_blk_len < 5 [sc->cpu_p_blk_len = 0] >>> acpi: acpi_cpu_startup: cpu 0,cpu_cx_count = 0,sc->cpu_cx_count = 1 >>> >>> So we're hitting an early exit in acpi_cpu_generic_cx_probe. >>> >> John, what would be a better fix - initialize the global variable to 1 or use goto >> in acpi_cpu_generic_cx_probe? >> I think the latter is more consistent and obvious, the former is simpler and >> safer, though. >> > > Your right, it seems that I need to order some more pointy hats. There > should have been a goto there to jump at the end in order to initialize > the global cpu_cx_count. The following patch should fix your issue. > John, is this ok with you? John's patch does the same thing without a goto (see message <200903261129.50419.jhb@freebsd.org>) -- Nate From owner-freebsd-acpi@FreeBSD.ORG Thu Mar 26 17:50:05 2009 Return-Path: Delivered-To: freebsd-acpi@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5E2A81065673 for ; Thu, 26 Mar 2009 17:50:05 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 4CE138FC15 for ; Thu, 26 Mar 2009 17:50:05 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n2QHo45u007677 for ; Thu, 26 Mar 2009 17:50:04 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n2QHo41h007676; Thu, 26 Mar 2009 17:50:04 GMT (envelope-from gnats) Date: Thu, 26 Mar 2009 17:50:04 GMT Message-Id: <200903261750.n2QHo41h007676@freefall.freebsd.org> To: freebsd-acpi@FreeBSD.org From: Andriy Gapon Cc: Subject: Re: kern/108581: [sysctl] sysctl: hw.acpi.cpu.cx_lowest: Invalid argument X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Andriy Gapon List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2009 17:50:05 -0000 The following reply was made to PR kern/108581; it has been noted by GNATS. From: Andriy Gapon To: Bruce Cran Cc: bug-followup@FreeBSD.org, lars.stokholm@gmail.com Subject: Re: kern/108581: [sysctl] sysctl: hw.acpi.cpu.cx_lowest: Invalid argument Date: Thu, 26 Mar 2009 19:46:56 +0200 on 26/03/2009 17:29 John Baldwin said the following: > I would rather move the cpu_cx_count code out into acpi_cpu_startup() > completely. It would more closely match the _CST code in that case. It is > also easier to follow the logic this way as well as it is only modified in > one place and not via a secret side-effect. Just in case: Bruce, Lars, could you please test John's patch (verbatim) and report back? Thank you! > --- //depot/vendor/freebsd/src/sys/dev/acpica/acpi_cpu.c 2009/02/19 14:40:18 > +++ //depot/user/jhb/acpipci/dev/acpica/acpi_cpu.c 2009/03/26 15:28:32 > @@ -609,10 +609,6 @@ > sc->cpu_cx_count++; > } > } > - > - /* Update the largest cx_count seen so far */ > - if (sc->cpu_cx_count > cpu_cx_count) > - cpu_cx_count = sc->cpu_cx_count; > } > > /* > @@ -752,6 +748,8 @@ > for (i = 0; i < cpu_ndevices; i++) { > sc = device_get_softc(cpu_devices[i]); > acpi_cpu_generic_cx_probe(sc); > + if (sc->cpu_cx_count > cpu_cx_count) > + cpu_cx_count = sc->cpu_cx_count; > } > > /* > > -- Andriy Gapon From owner-freebsd-acpi@FreeBSD.ORG Thu Mar 26 17:58:07 2009 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7389F106564A for ; Thu, 26 Mar 2009 17:58:07 +0000 (UTC) (envelope-from sepotvin@FreeBSD.org) Received: from zerofail.com (gatekeeper1.zerofail.com [208.71.11.38]) by mx1.freebsd.org (Postfix) with ESMTP id 141F78FC08 for ; Thu, 26 Mar 2009 17:58:06 +0000 (UTC) (envelope-from sepotvin@FreeBSD.org) Received: from telcobridges.com by freebsd.org (zerofail.com) (SecurityGateway 1.1.4) with SMTP id SG002299787.MSG for ; Thu, 26 Mar 2009 13:58:05 -0400 Received: from leia.telcobridges.lan ([208.94.105.59]) by telcobridges.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 26 Mar 2009 13:58:05 -0400 Message-ID: <49CBC22D.9090606@FreeBSD.org> Date: Thu, 26 Mar 2009 13:58:05 -0400 From: "Stephane E. Potvin" Organization: FreeBSD Project User-Agent: Thunderbird 2.0.0.21 (X11/20090323) MIME-Version: 1.0 To: Nate Lawson References: <200903200030.n2K0U3iG011009@freefall.freebsd.org> <20090325223914.4387eeae@gluon.draftnet> <49CB8C86.4020800@icyb.net.ua> <20090326142832.0dba187a@gluon.draftnet> <49CB9224.6010509@icyb.net.ua> <20090326144140.2203c0d8@gluon.draftnet> <49CB9973.3010306@icyb.net.ua> <20090326151035.51e4196e@gluon.draftnet> <49CB9C1B.4070308@icyb.net.ua> <49CBA1E5.2090902@FreeBSD.org> <49CBAF8F.9080301@root.org> In-Reply-To: <49CBAF8F.9080301@root.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Mar 2009 17:58:05.0601 (UTC) FILETIME=[69F9A910:01C9AE3C] X-SGHeloLookup-Result: hardfail smtp.helo=telcobridges.com (does not match 208.71.8.41) X-SGOP-RefID: str=0001.0A090202.49CBC22D.02CA,ss=1,fgs=0 (_st=1 _vt=0 _iwf=0) Cc: freebsd-acpi@freebsd.org, Andriy Gapon Subject: Re: kern/108581: [sysctl] sysctl: hw.acpi.cpu.cx_lowest: Invalid argument X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 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 Mar 2009 17:58:07 -0000 Nate Lawson wrote: > Stephane E. Potvin wrote: >> Andriy Gapon wrote: >>> on 26/03/2009 17:10 Bruce Cran said the following: >>>> On Thu, 26 Mar 2009 17:04:19 +0200 >>>> Andriy Gapon wrote: >>>> >>>>> on 26/03/2009 16:41 Bruce Cran said the following: >>>>>> I added lots of printfs to acpi_cpu.c and found that it's occuring >>>>>> in acpi_cpu_startup; initializing it to 3 in that function (which I >>>>>> wrongly assumed was the lowest Cx state supported in ACPI) fixed >>>>>> the problem on my Athlon XP PC because the generic cx handling code >>>>>> then lowered cpu_cx_count to 1 based on the fact that >>>>>> sc->cpu_cx_count was also 1. >>>>>> >>>>> Ok, yes, the real issue is in acpi_cpu_generic_cx_probe, namely in >>>>> early exits from it. So, sc->cpu_cx_count is always set to at least >>>>> 1, but if we exit via one of the returns before the end of function, >>>>> then global cpu_cx_count is never updated. >>>>> >>>> Exactly: >>>> >>>> acpi: acpi_cpu_startup: initializing cpu_cx_count to 0 >>>> acpi_cpu_generic_cx_probe >>>> if sc->cpu_p_blk_len < 5 [sc->cpu_p_blk_len = 0] >>>> acpi: acpi_cpu_startup: cpu 0,cpu_cx_count = 0,sc->cpu_cx_count = 1 >>>> >>>> So we're hitting an early exit in acpi_cpu_generic_cx_probe. >>>> >>> John, what would be a better fix - initialize the global variable to 1 or use goto >>> in acpi_cpu_generic_cx_probe? >>> I think the latter is more consistent and obvious, the former is simpler and >>> safer, though. >>> >> Your right, it seems that I need to order some more pointy hats. There >> should have been a goto there to jump at the end in order to initialize >> the global cpu_cx_count. The following patch should fix your issue. >> John, is this ok with you? > > John's patch does the same thing without a goto (see message > <200903261129.50419.jhb@freebsd.org>) > I saw it after sending mine, John's patch is indeed better. Steph From owner-freebsd-acpi@FreeBSD.ORG Thu Mar 26 18:40:04 2009 Return-Path: Delivered-To: freebsd-acpi@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ABD711065670 for ; Thu, 26 Mar 2009 18:40:04 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 9A3D68FC20 for ; Thu, 26 Mar 2009 18:40:04 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n2QIe3dJ075204 for ; Thu, 26 Mar 2009 18:40:03 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n2QIe325075203; Thu, 26 Mar 2009 18:40:03 GMT (envelope-from gnats) Date: Thu, 26 Mar 2009 18:40:03 GMT Message-Id: <200903261840.n2QIe325075203@freefall.freebsd.org> To: freebsd-acpi@FreeBSD.org From: Bruce Cran Cc: Subject: Re: kern/108581: [sysctl] sysctl: hw.acpi.cpu.cx_lowest: Invalid argument X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Bruce Cran List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2009 18:40:05 -0000 The following reply was made to PR kern/108581; it has been noted by GNATS. From: Bruce Cran To: Andriy Gapon Cc: bug-followup@FreeBSD.org, lars.stokholm@gmail.com Subject: Re: kern/108581: [sysctl] sysctl: hw.acpi.cpu.cx_lowest: Invalid argument Date: Thu, 26 Mar 2009 18:29:53 +0000 On Thu, 26 Mar 2009 19:46:56 +0200 Andriy Gapon wrote: > on 26/03/2009 17:29 John Baldwin said the following: > > I would rather move the cpu_cx_count code out into > > acpi_cpu_startup() completely. It would more closely match the > > _CST code in that case. It is also easier to follow the logic this > > way as well as it is only modified in one place and not via a > > secret side-effect. > > Just in case: > Bruce, Lars, > could you please test John's patch (verbatim) and report back? > Thank you! Works here - thanks! -- Bruce Cran From owner-freebsd-acpi@FreeBSD.ORG Thu Mar 26 20:11:06 2009 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 986C110656DC; Thu, 26 Mar 2009 20:11:06 +0000 (UTC) (envelope-from dandee@hellteam.net) Received: from lucifer.hellteam.net (lucifer.hellteam.net [88.86.107.21]) by mx1.freebsd.org (Postfix) with ESMTP id 1D14F8FC1A; Thu, 26 Mar 2009 20:11:05 +0000 (UTC) (envelope-from dandee@hellteam.net) Received: from smtp.hellteam.net (rik.hellteam.net [78.108.102.225]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by lucifer.hellteam.net (Postfix) with ESMTPS id 3236810B4; Thu, 26 Mar 2009 20:55:27 +0100 (CET) Received: from gandalf (gandalf.tocnet28.jspoj.czf [10.40.8.101]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by smtp.hellteam.net (Postfix) with ESMTPSA id 3BCCD57004F; Thu, 26 Mar 2009 20:51:51 +0100 (CET) From: =?iso-8859-1?Q?Daniel_Dvor=E1k?= To: "'Stephane E. Potvin'" , "'John Baldwin'" References: <200903200030.n2K0U3iG011009@freefall.freebsd.org> <200903260937.51028.jhb@freebsd.org> <20090326143731.0d2b7711@gluon.draftnet> <200903261050.51602.jhb@freebsd.org> <49CB9972.4030502@FreeBSD.org> Date: Thu, 26 Mar 2009 20:51:51 +0100 Organization: Projekt HELL Message-ID: <7DFA954C8D084B4DAF8C7CC3306DF096@tocnet28.jspoj.czf> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <49CB9972.4030502@FreeBSD.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4325 Thread-Index: AcmuJV8k2YX85jS8Qsm/mMvpDja+BwAJpaxw Cc: freebsd-acpi@freebsd.org Subject: RE: kern/108581: [sysctl] sysctl: hw.acpi.cpu.cx_lowest: Invalid argument X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dandee@hellteam.net List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2009 20:11:08 -0000 Hi all, I found out this error on the other computers. Will it be helpful for analyzing to send infromation about cpu, acpi table and so on ? Or is = the first example enough ? DD -----Original Message----- From: Stephane E. Potvin [mailto:sepotvin@FreeBSD.org]=20 Sent: Thursday, March 26, 2009 4:04 PM To: John Baldwin Cc: Bruce Cran; Daniel Dvor(=E1k; freebsd-acpi@freebsd.org Subject: Re: kern/108581: [sysctl] sysctl: hw.acpi.cpu.cx_lowest: = Invalid argument John Baldwin wrote: > On Thursday 26 March 2009 10:37:31 am Bruce Cran wrote: >> On Thu, 26 Mar 2009 09:37:50 -0400 >> John Baldwin wrote: >> >>> No, the code is doing things differently on purpose (though I'm not=20 >>> completely sure why). For _CST it sets cpu_cx_count to the maximum=20 >>> Cx level supported by any CPU in the system. For non-_CST it sets=20 >>> it to the maximum Cx level supported by all CPUs in the system. I=20 >>> think it is correct for cpu_cx_count to always start at 0 and only=20 >>> be bumped up to a higher setting. Setting it to 3 would be very=20 >>> wrong for the _CST case as I've seen CPUs that support C4. >> From briefly reading through the specifications I'd assumed the=20 >> maximum power state was C3. >=20 > For the non _CST case that is all that is defined, yes. However, _CST = > is a variable length array of Cx states, so it can support arbitrary=20 > numbers of states. >=20 >> I had thought the _CST block was wrong because in=20 >> acpi_cpu_global_cx_lowest_sysctl it validates the new value against=20 >> cpu_cx_count; if one CPU has a lower cx state than the others, then=20 >> won't this tell the other CPUs to use an unsupported state? >=20 > It depends on if the CPU driver is smart enough to cap requests to > sc->cpu_cx_count, though if it does presumably it would do that in the > cx_generic case as well. I'm not sure why it behaves differently for=20 > the _CST case, but I do think it is on purpose at least rather than an = > accidental bug. Perhaps Nate can chime in with why? >=20 The intent when I added support for cx states on SMP systems was to use = the same maximum cx_state for all CPUs when _CST is not used (cx_generic case) and to respect per-processor maximum cx_state when _CST is present = and can be used. This whole piece of code is really convoluted and there's = been a few errors found in it over time so I wouldn't be surprised if there = were some still lurking. Could you send me privately a copy of your ASL and a verbose boot log? Steph From owner-freebsd-acpi@FreeBSD.ORG Thu Mar 26 20:29:17 2009 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 326291065670; Thu, 26 Mar 2009 20:29:17 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id E50098FC16; Thu, 26 Mar 2009 20:29:16 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (pool-98-109-39-197.nwrknj.fios.verizon.net [98.109.39.197]) by cyrus.watson.org (Postfix) with ESMTPSA id 8915546B06; Thu, 26 Mar 2009 16:29:16 -0400 (EDT) Received: from localhost (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.14.3/8.14.3) with ESMTP id n2QKTAct085752; Thu, 26 Mar 2009 16:29:10 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: dandee@hellteam.net Date: Thu, 26 Mar 2009 16:29:05 -0400 User-Agent: KMail/1.9.7 References: <200903200030.n2K0U3iG011009@freefall.freebsd.org> <49CB9972.4030502@FreeBSD.org> <7DFA954C8D084B4DAF8C7CC3306DF096@tocnet28.jspoj.czf> In-Reply-To: <7DFA954C8D084B4DAF8C7CC3306DF096@tocnet28.jspoj.czf> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200903261629.06238.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Thu, 26 Mar 2009 16:29:10 -0400 (EDT) X-Virus-Scanned: ClamAV 0.94.2/9171/Thu Mar 26 13:49:28 2009 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: freebsd-acpi@freebsd.org, "'Stephane E. Potvin'" Subject: Re: kern/108581: [sysctl] sysctl: hw.acpi.cpu.cx_lowest: Invalid argument X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 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 Mar 2009 20:29:17 -0000 On Thursday 26 March 2009 3:51:51 pm Daniel Dvor=E1k wrote: > Hi all, >=20 > I found out this error on the other computers. Will it be helpful for > analyzing to send infromation about cpu, acpi table and so on ? Or is the > first example enough ? The example is enough, we just need someone to test the patch and make sure= it=20 fixes the problem. > DD >=20 > -----Original Message----- > From: Stephane E. Potvin [mailto:sepotvin@FreeBSD.org]=20 > Sent: Thursday, March 26, 2009 4:04 PM > To: John Baldwin > Cc: Bruce Cran; Daniel Dvor(=E1k; freebsd-acpi@freebsd.org > Subject: Re: kern/108581: [sysctl] sysctl: hw.acpi.cpu.cx_lowest: Invalid > argument >=20 > John Baldwin wrote: > > On Thursday 26 March 2009 10:37:31 am Bruce Cran wrote: > >> On Thu, 26 Mar 2009 09:37:50 -0400 > >> John Baldwin wrote: > >> > >>> No, the code is doing things differently on purpose (though I'm not=20 > >>> completely sure why). For _CST it sets cpu_cx_count to the maximum=20 > >>> Cx level supported by any CPU in the system. For non-_CST it sets=20 > >>> it to the maximum Cx level supported by all CPUs in the system. I=20 > >>> think it is correct for cpu_cx_count to always start at 0 and only=20 > >>> be bumped up to a higher setting. Setting it to 3 would be very=20 > >>> wrong for the _CST case as I've seen CPUs that support C4. > >> From briefly reading through the specifications I'd assumed the=20 > >> maximum power state was C3. > >=20 > > For the non _CST case that is all that is defined, yes. However, _CST= =20 > > is a variable length array of Cx states, so it can support arbitrary=20 > > numbers of states. > >=20 > >> I had thought the _CST block was wrong because in=20 > >> acpi_cpu_global_cx_lowest_sysctl it validates the new value against=20 > >> cpu_cx_count; if one CPU has a lower cx state than the others, then=20 > >> won't this tell the other CPUs to use an unsupported state? > >=20 > > It depends on if the CPU driver is smart enough to cap requests to > > sc->cpu_cx_count, though if it does presumably it would do that in the > > cx_generic case as well. I'm not sure why it behaves differently for=20 > > the _CST case, but I do think it is on purpose at least rather than an= =20 > > accidental bug. Perhaps Nate can chime in with why? > >=20 >=20 > The intent when I added support for cx states on SMP systems was to use t= he > same maximum cx_state for all CPUs when _CST is not used (cx_generic > case) and to respect per-processor maximum cx_state when _CST is present = and > can be used. This whole piece of code is really convoluted and there's be= en > a few errors found in it over time so I wouldn't be surprised if there we= re > some still lurking. >=20 > Could you send me privately a copy of your ASL and a verbose boot log? >=20 > Steph >=20 >=20 =2D-=20 John Baldwin From owner-freebsd-acpi@FreeBSD.ORG Thu Mar 26 21:20:05 2009 Return-Path: Delivered-To: freebsd-acpi@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9851C1065677 for ; Thu, 26 Mar 2009 21:20:05 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 867D98FC08 for ; Thu, 26 Mar 2009 21:20:05 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n2QLK5wA094808 for ; Thu, 26 Mar 2009 21:20:05 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n2QLK5sm094807; Thu, 26 Mar 2009 21:20:05 GMT (envelope-from gnats) Date: Thu, 26 Mar 2009 21:20:05 GMT Message-Id: <200903262120.n2QLK5sm094807@freefall.freebsd.org> To: freebsd-acpi@FreeBSD.org From: dfilter@FreeBSD.ORG (dfilter service) Cc: Subject: Re: kern/108581: commit references a PR X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dfilter service List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2009 21:20:06 -0000 The following reply was made to PR kern/108581; it has been noted by GNATS. From: dfilter@FreeBSD.ORG (dfilter service) To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/108581: commit references a PR Date: Thu, 26 Mar 2009 21:10:49 +0000 (UTC) Author: jhb Date: Thu Mar 26 21:10:35 2009 New Revision: 190454 URL: http://svn.freebsd.org/changeset/base/190454 Log: Move the code to update cpu_cx_count out of acpi_cpu_generic_cx_probe() and into acpi_cpu_startup() which is where all the other code to update this global variable lives. This fixes a bug where cpu_cx_count was not updated correctly if acpi_cpu_generic_cx_probe() returned early. PR: kern/108581 Debugged by: Bruce Cran Reviewed by: avg, njl, sepotvin MFC after: 3 days Modified: head/sys/dev/acpica/acpi_cpu.c Modified: head/sys/dev/acpica/acpi_cpu.c ============================================================================== --- head/sys/dev/acpica/acpi_cpu.c Thu Mar 26 20:23:21 2009 (r190453) +++ head/sys/dev/acpica/acpi_cpu.c Thu Mar 26 21:10:35 2009 (r190454) @@ -609,10 +609,6 @@ acpi_cpu_generic_cx_probe(struct acpi_cp sc->cpu_cx_count++; } } - - /* Update the largest cx_count seen so far */ - if (sc->cpu_cx_count > cpu_cx_count) - cpu_cx_count = sc->cpu_cx_count; } /* @@ -752,6 +748,8 @@ acpi_cpu_startup(void *arg) for (i = 0; i < cpu_ndevices; i++) { sc = device_get_softc(cpu_devices[i]); acpi_cpu_generic_cx_probe(sc); + if (sc->cpu_cx_count > cpu_cx_count) + cpu_cx_count = sc->cpu_cx_count; } /* _______________________________________________ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscribe@freebsd.org" From owner-freebsd-acpi@FreeBSD.ORG Thu Mar 26 21:22:23 2009 Return-Path: Delivered-To: freebsd-acpi@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ED3801065676; Thu, 26 Mar 2009 21:22:23 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id C15B48FC0C; Thu, 26 Mar 2009 21:22:23 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from freefall.freebsd.org (jhb@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n2QLMNvr007701; Thu, 26 Mar 2009 21:22:23 GMT (envelope-from jhb@freefall.freebsd.org) Received: (from jhb@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n2QLMNVa007697; Thu, 26 Mar 2009 21:22:23 GMT (envelope-from jhb) Date: Thu, 26 Mar 2009 21:22:23 GMT Message-Id: <200903262122.n2QLMNVa007697@freefall.freebsd.org> To: lars.stokholm@gmail.com, jhb@FreeBSD.org, freebsd-acpi@FreeBSD.org, jhb@FreeBSD.org From: jhb@FreeBSD.org Cc: Subject: Re: kern/108581: [patch] [acpi] sysctl: hw.acpi.cpu.cx_lowest: Invalid argument X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 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 Mar 2009 21:22:24 -0000 Synopsis: [patch] [acpi] sysctl: hw.acpi.cpu.cx_lowest: Invalid argument State-Changed-From-To: open->patched State-Changed-By: jhb State-Changed-When: Thu Mar 26 21:21:55 UTC 2009 State-Changed-Why: Fix is in HEAD, will MFC in a few days. Responsible-Changed-From-To: freebsd-acpi->jhb Responsible-Changed-By: jhb Responsible-Changed-When: Thu Mar 26 21:21:55 UTC 2009 Responsible-Changed-Why: Fix is in HEAD, will MFC in a few days. http://www.freebsd.org/cgi/query-pr.cgi?pr=108581 From owner-freebsd-acpi@FreeBSD.ORG Thu Mar 26 21:47:13 2009 Return-Path: Delivered-To: freebsd-acpi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 75ABA1065670 for ; Thu, 26 Mar 2009 21:47:13 +0000 (UTC) (envelope-from cwhiteh@onetel.com) Received: from honeysuckle.london.02.net (honeysuckle.london.02.net [87.194.255.144]) by mx1.freebsd.org (Postfix) with ESMTP id 10EDA8FC0C for ; Thu, 26 Mar 2009 21:47:13 +0000 (UTC) (envelope-from cwhiteh@onetel.com) Received: from [192.168.1.75] (93.97.24.219) by honeysuckle.london.02.net (8.5.016.1) id 497A2AF001AE8317; Thu, 26 Mar 2009 21:46:57 +0000 Message-ID: <49CBF7D1.20102@onetel.com> Date: Thu, 26 Mar 2009 21:46:57 +0000 From: Chris Whitehouse User-Agent: Thunderbird 2.0.0.19 (X11/20090113) MIME-Version: 1.0 To: "Alexandre \"Sunny\" Kovalenko" References: <49C80E65.9090500@onetel.com> <49C93309.6050708@iki.fi> <20090325140718.J95588@sola.nimnet.asn.au> <49C9EE50.6070507@onetel.com> <1237992462.1297.22.camel@RabbitsDen> In-Reply-To: <1237992462.1297.22.camel@RabbitsDen> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@FreeBSD.org, Ian Smith Subject: Re: acpi_tz0: _CRT value is absurd, ignored (256.0C) (was pr kern/105537) X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 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 Mar 2009 21:47:13 -0000 Alexandre "Sunny" Kovalenko wrote: > To be fair, if all you want is to override _CRT, you should be able to > put something to the tune of > > hw.acpi.thermal.user_override=1 > hw.acpi.thermal.tz0._CRT=90C > > in your /etc/sysctl.conf and not deal with the ASL at all. I tried this and it sets hw.acpi.thermal.tz0._CRT correctly until hw.acpi.thermal.tz0.active and hw.acpi.thermal.tz0.temperature change values at which point hw.acpi.thermal.tz0._CRT reverts to -1. At idle having set hw.acpi.thermal.tz0._CRT to 90C with sysctl: chrisw@muji% sysctl hw.acpi.thermal.tz0 hw.acpi.thermal.tz0.temperature: 55.0C hw.acpi.thermal.tz0.active: 3 hw.acpi.thermal.tz0.passive_cooling: 0 hw.acpi.thermal.tz0.thermal_flags: 0 hw.acpi.thermal.tz0._PSV: -1 hw.acpi.thermal.tz0._HOT: -1 hw.acpi.thermal.tz0._CRT: 90.0C hw.acpi.thermal.tz0._ACx: 80.0C 70.0C 60.0C 45.0C -1 -1 -1 -1 -1 -1 hw.acpi.thermal.tz0._TC1: -1 hw.acpi.thermal.tz0._TC2: -1 hw.acpi.thermal.tz0._TSP: -1 Heat it up a bit with cpuburn: chrisw@muji% sysctl hw.acpi.thermal.tz0 hw.acpi.thermal.tz0.temperature: 60.0C hw.acpi.thermal.tz0.active: 2 hw.acpi.thermal.tz0.passive_cooling: 0 hw.acpi.thermal.tz0.thermal_flags: 0 hw.acpi.thermal.tz0._PSV: -1 hw.acpi.thermal.tz0._HOT: -1 hw.acpi.thermal.tz0._CRT: -1 hw.acpi.thermal.tz0._ACx: 80.0C 70.0C 55.0C 45.0C -1 -1 -1 -1 -1 -1 hw.acpi.thermal.tz0._TC1: -1 hw.acpi.thermal.tz0._TC2: -1 hw.acpi.thermal.tz0._TSP: -1 hw.acpi.thermal.tz0._CRT will now stay at -1 until I reset it with sysctl. So I suppose I need to find out where hw.acpi.thermal.tz0._CRT is getting its value from - which must be the ASL. acpidump -td says ThermalZone (TZ0) { snip Method (_CRT, 0, Serialized) { Return (C316 (0x04, 0x00)) } snip } The whole asl is fetch(1)able as www.fishercroft.plus.com/nc6320.asl.gz Watching /var/log/messages I can't see a correlation between when the warning messages appear and changing the temperature states so I don't even know what is actually triggering them. I've started reading the ACPI specs as suggested but in the meantime all suggestions welcome. Thanks Chris > > You might want to take a look at your output of 'sysctl hw.acpi.thermal' > -- your specific thermal zone, might be different from the one, I have > used as an example above. In fact, on my laptop, it is tz1 and not tz0. > > In either case, I would recommend reading thermal chapter of the ACPI > specification -- it is short, well-written and has an example, I was > stealing stuff from, shamelessly, in the past. > > HTH, > From owner-freebsd-acpi@FreeBSD.ORG Thu Mar 26 23:49:18 2009 Return-Path: Delivered-To: freebsd-acpi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5BC26106564A for ; Thu, 26 Mar 2009 23:49:18 +0000 (UTC) (envelope-from nate@root.org) Received: from nlpi015.prodigy.net (nlpi015.sbcis.sbc.com [207.115.36.44]) by mx1.freebsd.org (Postfix) with ESMTP id 2AD528FC0C for ; Thu, 26 Mar 2009 23:49:18 +0000 (UTC) (envelope-from nate@root.org) Received: from [192.168.2.117] (adsl-99-161-102-210.dsl.pltn13.sbcglobal.net [99.161.102.210]) (authenticated bits=0) by nlpi015.prodigy.net (8.13.8 smtpauth/dk/map_regex/8.13.8) with ESMTP id n2QNnEFG021655; Thu, 26 Mar 2009 18:49:15 -0500 Message-ID: <49CC147A.3030805@root.org> Date: Thu, 26 Mar 2009 16:49:14 -0700 From: Nate Lawson User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Chris Whitehouse References: <49C80E65.9090500@onetel.com> <49C93309.6050708@iki.fi> <20090325140718.J95588@sola.nimnet.asn.au> <49C9EE50.6070507@onetel.com> <1237992462.1297.22.camel@RabbitsDen> <49CBF7D1.20102@onetel.com> In-Reply-To: <49CBF7D1.20102@onetel.com> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@FreeBSD.org, Ian Smith Subject: Re: acpi_tz0: _CRT value is absurd, ignored (256.0C) (was pr kern/105537) X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 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 Mar 2009 23:49:18 -0000 Chris Whitehouse wrote: > Alexandre "Sunny" Kovalenko wrote: >> To be fair, if all you want is to override _CRT, you should be able to >> put something to the tune of >> >> hw.acpi.thermal.user_override=1 >> hw.acpi.thermal.tz0._CRT=90C >> >> in your /etc/sysctl.conf and not deal with the ASL at all. > > I tried this and it sets hw.acpi.thermal.tz0._CRT correctly until > hw.acpi.thermal.tz0.active and hw.acpi.thermal.tz0.temperature change > values at which point hw.acpi.thermal.tz0._CRT reverts to -1. > Thermal zones are re-evaluated when a Notify comes in that says to do so. Perhaps if "user_override" is set to 1, we should not re-evaluate them. However, perhaps that should only be done for values the user actually overrode. There has to be a different solution Windows used. Maybe they ignore _crt. -- Nate From owner-freebsd-acpi@FreeBSD.ORG Fri Mar 27 01:50:36 2009 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 927B9106564A for ; Fri, 27 Mar 2009 01:50:36 +0000 (UTC) (envelope-from gaijin.k@gmail.com) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.29]) by mx1.freebsd.org (Postfix) with ESMTP id 41CB88FC0A for ; Fri, 27 Mar 2009 01:50:35 +0000 (UTC) (envelope-from gaijin.k@gmail.com) Received: by yw-out-2324.google.com with SMTP id 5so659303ywh.13 for ; Thu, 26 Mar 2009 18:50:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:from:to:cc :in-reply-to:references:content-type:date:message-id:mime-version :x-mailer:content-transfer-encoding; bh=7oICB1uBS1arzkv4IT2vwYivVCV1PaQFcl6MkUhnHts=; b=FbnDZbPQfkRLuuX//NZQYeF9EVaIvApzHmlaSgmLrOGmoKlWHvePmBlhA2g24e5SlF PsuS3BJt0rB3cNKeca1mTjnPuile1pOeEg5ghaBoY0fERxMOIz/tGqhtqCkYfx9sXtyT kQXc0snYACrnuNwjTqB/LYZcmAdgB4u4/xL+0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:from:to:cc:in-reply-to:references:content-type:date :message-id:mime-version:x-mailer:content-transfer-encoding; b=evTHEKzvHWrtzYIH+G1zTt8W4t6id9eHpPYMtIxVqyaycEt7m8tIcAMPeaFVUABOJc m954bZDDTA4HW9LWQm+qHigeW0zlUs1e+6RMK6/f8bMFxgYC2NhW/V9fggJX0oROpDRi LYI1D9AgKOO+/LxIVVtbTPtFlcw3UDbIrak+s= Received: by 10.90.66.10 with SMTP id o10mr901750aga.29.1238118635448; Thu, 26 Mar 2009 18:50:35 -0700 (PDT) Received: from ?10.0.3.231? (pool-71-250-44-232.nwrknj.east.verizon.net [71.250.44.232]) by mx.google.com with ESMTPS id 39sm1364398agd.43.2009.03.26.18.50.34 (version=SSLv3 cipher=RC4-MD5); Thu, 26 Mar 2009 18:50:35 -0700 (PDT) From: "Alexandre \"Sunny\" Kovalenko" To: Nate Lawson In-Reply-To: <49CC147A.3030805@root.org> References: <49C80E65.9090500@onetel.com> <49C93309.6050708@iki.fi> <20090325140718.J95588@sola.nimnet.asn.au> <49C9EE50.6070507@onetel.com> <1237992462.1297.22.camel@RabbitsDen> <49CBF7D1.20102@onetel.com> <49CC147A.3030805@root.org> Content-Type: text/plain; charset="UTF-8" Date: Thu, 26 Mar 2009 21:50:21 -0400 Message-Id: <1238118621.1365.35.camel@RabbitsDen> Mime-Version: 1.0 X-Mailer: Evolution 2.24.5 FreeBSD GNOME Team Port Content-Transfer-Encoding: 8bit Cc: freebsd-acpi@FreeBSD.org, Ian Smith , Chris Whitehouse Subject: Re: acpi_tz0: _CRT value is absurd, ignored (256.0C) (was pr kern/105537) X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 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 Mar 2009 01:50:37 -0000 On Thu, 2009-03-26 at 16:49 -0700, Nate Lawson wrote: > Chris Whitehouse wrote: > > Alexandre "Sunny" Kovalenko wrote: > >> To be fair, if all you want is to override _CRT, you should be able to > >> put something to the tune of > >> > >> hw.acpi.thermal.user_override=1 > >> hw.acpi.thermal.tz0._CRT=90C > >> > >> in your /etc/sysctl.conf and not deal with the ASL at all. > > > > I tried this and it sets hw.acpi.thermal.tz0._CRT correctly until > > hw.acpi.thermal.tz0.active and hw.acpi.thermal.tz0.temperature change > > values at which point hw.acpi.thermal.tz0._CRT reverts to -1. > > > > Thermal zones are re-evaluated when a Notify comes in that says to do > so. Perhaps if "user_override" is set to 1, we should not re-evaluate > them. However, perhaps that should only be done for values the user > actually overrode. ACPI 2.0 spec explicitly talks about updating of the _PSV and _ACx on Notify(..., 0x81). ACPI 3.0b is shade more vague, but still talking about "active and passive cooling temperature trip points". Maybe we should not reevaluate _HOT and _CRT at all? > > There has to be a different solution Windows used. Maybe they ignore _crt. Looking at ASL I can see five thermal zone objects defined and only one of them (TZ4) looking somewhat normal: _CRT is 110C and _TMP method goes to the trouble of making sane return value. Maybe Windows somehow knows which thermal zones to ignore? Given the snippet below this _was_ geared heavily towards Windows: If (\_OSI ("Windows 2001")) { Store (0x04, C014) } If (\_OSI ("Windows 2001 SP1")) { Store (0x04, C014) } If (\_OSI ("Windows 2001 SP2")) { Store (0x05, C014) } If (\_OSI ("Windows 2006")) { Store (0x06, C014) } Chris, you should be able to set hw.acpi.osname= in loader.conf and see if things improve somewhat. Note that "Windows 2001" and "Windows 2001 SP1" are identical. Could you also, please, post the full output of the sysctl hw.acpi.thermal -- Alexandre Kovalenko (Олександр Коваленко) From owner-freebsd-acpi@FreeBSD.ORG Fri Mar 27 05:44:25 2009 Return-Path: Delivered-To: freebsd-acpi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B1B5E1065678 for ; Fri, 27 Mar 2009 05:44:25 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [220.233.188.227]) by mx1.freebsd.org (Postfix) with ESMTP id 0D3CE8FC19 for ; Fri, 27 Mar 2009 05:44:24 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id n2R5iMA5056745; Fri, 27 Mar 2009 16:44:22 +1100 (EST) (envelope-from smithi@nimnet.asn.au) Date: Fri, 27 Mar 2009 16:44:21 +1100 (EST) From: Ian Smith To: Chris Whitehouse In-Reply-To: <49CBF7D1.20102@onetel.com> Message-ID: <20090327155343.C95588@sola.nimnet.asn.au> References: <49C80E65.9090500@onetel.com> <49C93309.6050708@iki.fi> <20090325140718.J95588@sola.nimnet.asn.au> <49C9EE50.6070507@onetel.com> <1237992462.1297.22.camel@RabbitsDen> <49CBF7D1.20102@onetel.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: freebsd-acpi@FreeBSD.org Subject: Re: acpi_tz0: _CRT value is absurd, ignored (256.0C) (was pr kern/105537) X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 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 Mar 2009 05:44:26 -0000 On Thu, 26 Mar 2009, Chris Whitehouse wrote: > Alexandre "Sunny" Kovalenko wrote: > > To be fair, if all you want is to override _CRT, you should be able to > > put something to the tune of > > > > hw.acpi.thermal.user_override=1 > > hw.acpi.thermal.tz0._CRT=90C > > > > in your /etc/sysctl.conf and not deal with the ASL at all. > > I tried this and it sets hw.acpi.thermal.tz0._CRT correctly until > hw.acpi.thermal.tz0.active and hw.acpi.thermal.tz0.temperature change values > at which point hw.acpi.thermal.tz0._CRT reverts to -1. > > At idle having set hw.acpi.thermal.tz0._CRT to 90C with sysctl: > > chrisw@muji% sysctl hw.acpi.thermal.tz0 > hw.acpi.thermal.tz0.temperature: 55.0C > hw.acpi.thermal.tz0.active: 3 > hw.acpi.thermal.tz0.passive_cooling: 0 > hw.acpi.thermal.tz0.thermal_flags: 0 > hw.acpi.thermal.tz0._PSV: -1 > hw.acpi.thermal.tz0._HOT: -1 > hw.acpi.thermal.tz0._CRT: 90.0C > hw.acpi.thermal.tz0._ACx: 80.0C 70.0C 60.0C 45.0C -1 -1 -1 -1 -1 -1 > hw.acpi.thermal.tz0._TC1: -1 > hw.acpi.thermal.tz0._TC2: -1 > hw.acpi.thermal.tz0._TSP: -1 Just towards figuring out what this zone might represent .. perhaps it's a case temperature sensor, seemingly controlling a fan? No passive cooling, and here at 55C tz0.active is 3, being the zero-based index into the active cooling array _ACx (ie, temp > 45C). > Heat it up a bit with cpuburn: > > chrisw@muji% sysctl hw.acpi.thermal.tz0 > hw.acpi.thermal.tz0.temperature: 60.0C > hw.acpi.thermal.tz0.active: 2 > hw.acpi.thermal.tz0.passive_cooling: 0 > hw.acpi.thermal.tz0.thermal_flags: 0 > hw.acpi.thermal.tz0._PSV: -1 > hw.acpi.thermal.tz0._HOT: -1 > hw.acpi.thermal.tz0._CRT: -1 > hw.acpi.thermal.tz0._ACx: 80.0C 70.0C 55.0C 45.0C -1 -1 -1 -1 -1 -1 > hw.acpi.thermal.tz0._TC1: -1 > hw.acpi.thermal.tz0._TC2: -1 > hw.acpi.thermal.tz0._TSP: -1 And now tz0.active is 2, ie > 55C. Some fan should be running faster, is that anything noticeable? It could be separate from the CPU fan. > hw.acpi.thermal.tz0._CRT will now stay at -1 until I reset it with sysctl. > > So I suppose I need to find out where hw.acpi.thermal.tz0._CRT is getting its > value from - which must be the ASL. > > acpidump -td says > > ThermalZone (TZ0) > { > > snip > > Method (_CRT, 0, Serialized) > { > Return (C316 (0x04, 0x00)) > } > > snip > > } > > The whole asl is fetch(1)able as www.fishercroft.plus.com/nc6320.asl.gz > > Watching /var/log/messages I can't see a correlation between when the warning > messages appear and changing the temperature states so I don't even know what > is actually triggering them. What's the highest temperature you've observed for that zone? I wonder how that may correlate with your CPU and/or GPU temperatures / zones? > I've started reading the ACPI specs as suggested but in the meantime all > suggestions welcome. > > Thanks > > Chris > > > > > You might want to take a look at your output of 'sysctl hw.acpi.thermal' > > -- your specific thermal zone, might be different from the one, I have > > used as an example above. In fact, on my laptop, it is tz1 and not tz0. As Alexandre says, showing all of the hw.acpi.thermal zones may help. My earlier guess about maybe being byte-swapped seems more unlikely, I forgot these were returned as tenths of a degree Kelvin, not Celcius. Nate suggested Windows might ignore _crt for this one .. or perhaps this odd figure of 256.0C signals something to Windows? Just speculating .. > > In either case, I would recommend reading thermal chapter of the ACPI > > specification -- it is short, well-written and has an example, I was > > stealing stuff from, shamelessly, in the past. Indeed, it's one of the few chapters that made a lot of sense to me :) cheers, Ian From owner-freebsd-acpi@FreeBSD.ORG Fri Mar 27 13:58:21 2009 Return-Path: Delivered-To: freebsd-acpi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BF00D10656BC for ; Fri, 27 Mar 2009 13:58:21 +0000 (UTC) (envelope-from cwhiteh@onetel.com) Received: from woodbine.london.02.net (woodbine.london.02.net [87.194.255.145]) by mx1.freebsd.org (Postfix) with ESMTP id 5ED218FC1A for ; Fri, 27 Mar 2009 13:58:21 +0000 (UTC) (envelope-from cwhiteh@onetel.com) Received: from [192.168.1.75] (93.97.24.219) by woodbine.london.02.net (8.5.016.1) id 4979BCBF01CE03A5; Fri, 27 Mar 2009 13:55:19 +0000 Message-ID: <49CCDAC6.2060407@onetel.com> Date: Fri, 27 Mar 2009 13:55:18 +0000 From: Chris Whitehouse User-Agent: Thunderbird 2.0.0.19 (X11/20090113) MIME-Version: 1.0 To: Ian Smith References: <49C80E65.9090500@onetel.com> <49C93309.6050708@iki.fi> <20090325140718.J95588@sola.nimnet.asn.au> <49C9EE50.6070507@onetel.com> <1237992462.1297.22.camel@RabbitsDen> <49CBF7D1.20102@onetel.com> <20090327155343.C95588@sola.nimnet.asn.au> In-Reply-To: <20090327155343.C95588@sola.nimnet.asn.au> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@FreeBSD.org Subject: Re: acpi_tz0: _CRT value is absurd, ignored (256.0C) (was pr kern/105537) X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 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 Mar 2009 13:58:22 -0000 Ian Smith wrote: > On Thu, 26 Mar 2009, Chris Whitehouse wrote: >> Alexandre "Sunny" Kovalenko wrote: >>> To be fair, if all you want is to override _CRT, you should be >>> able to put something to the tune of >>> >>> hw.acpi.thermal.user_override=1 hw.acpi.thermal.tz0._CRT=90C >>> >>> in your /etc/sysctl.conf and not deal with the ASL at all. >> >> I tried this and it sets hw.acpi.thermal.tz0._CRT correctly until >> hw.acpi.thermal.tz0.active and hw.acpi.thermal.tz0.temperature >> change values at which point hw.acpi.thermal.tz0._CRT reverts to >> -1. >> >> At idle having set hw.acpi.thermal.tz0._CRT to 90C with sysctl: >> >> chrisw@muji% sysctl hw.acpi.thermal.tz0 >> hw.acpi.thermal.tz0.temperature: 55.0C hw.acpi.thermal.tz0.active: >> 3 hw.acpi.thermal.tz0.passive_cooling: 0 >> hw.acpi.thermal.tz0.thermal_flags: 0 hw.acpi.thermal.tz0._PSV: -1 >> hw.acpi.thermal.tz0._HOT: -1 hw.acpi.thermal.tz0._CRT: 90.0C >> hw.acpi.thermal.tz0._ACx: 80.0C 70.0C 60.0C 45.0C -1 -1 -1 -1 -1 -1 >> hw.acpi.thermal.tz0._TC1: -1 hw.acpi.thermal.tz0._TC2: -1 >> hw.acpi.thermal.tz0._TSP: -1 > > Just towards figuring out what this zone might represent .. perhaps > it's a case temperature sensor, seemingly controlling a fan? No > passive cooling, and here at 55C tz0.active is 3, being the > zero-based index into the active cooling array _ACx (ie, temp > 45C). > The lowest temperature I have seen is 45C. > >> Heat it up a bit with cpuburn: >> >> chrisw@muji% sysctl hw.acpi.thermal.tz0 >> hw.acpi.thermal.tz0.temperature: 60.0C hw.acpi.thermal.tz0.active: >> 2 hw.acpi.thermal.tz0.passive_cooling: 0 >> hw.acpi.thermal.tz0.thermal_flags: 0 hw.acpi.thermal.tz0._PSV: -1 >> hw.acpi.thermal.tz0._HOT: -1 hw.acpi.thermal.tz0._CRT: -1 >> hw.acpi.thermal.tz0._ACx: 80.0C 70.0C 55.0C 45.0C -1 -1 -1 -1 -1 -1 >> hw.acpi.thermal.tz0._TC1: -1 hw.acpi.thermal.tz0._TC2: -1 >> hw.acpi.thermal.tz0._TSP: -1 > > And now tz0.active is 2, ie > 55C. Some fan should be running > faster, is that anything noticeable? It could be separate from the > CPU fan. There is one fan and it changes speed with hw.acpi.thermal.tz0.temperature and hw.acpi.thermal.tz0.active which move together. I'm pretty sure it is located to cool the cpu but I'd have to check some hardware docs to be certain. See also my other post with details of /var/log/messages. > >> hw.acpi.thermal.tz0._CRT will now stay at -1 until I reset it with >> sysctl. >> >> So I suppose I need to find out where hw.acpi.thermal.tz0._CRT is >> getting its value from - which must be the ASL. >> >> acpidump -td says >> >> ThermalZone (TZ0) { >> >> snip >> >> Method (_CRT, 0, Serialized) { Return (C316 (0x04, 0x00)) } >> >> snip >> >> } >> >> The whole asl is fetch(1)able as >> www.fishercroft.plus.com/nc6320.asl.gz >> >> Watching /var/log/messages I can't see a correlation between when >> the warning messages appear and changing the temperature states so >> I don't even know what is actually triggering them. > > What's the highest temperature you've observed for that zone? I > wonder how that may correlate with your CPU and/or GPU temperatures / > zones? Highest temperature I've seen for hw.acpi.thermal.tz0.temperature is 80C. And on looking closer I see they do correlate - also see my other post. Chris From owner-freebsd-acpi@FreeBSD.ORG Fri Mar 27 14:01:03 2009 Return-Path: Delivered-To: freebsd-acpi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 875771065836 for ; Fri, 27 Mar 2009 14:01:03 +0000 (UTC) (envelope-from cwhiteh@onetel.com) Received: from honeysuckle.london.02.net (honeysuckle.london.02.net [87.194.255.144]) by mx1.freebsd.org (Postfix) with ESMTP id 21D858FC18 for ; Fri, 27 Mar 2009 14:01:03 +0000 (UTC) (envelope-from cwhiteh@onetel.com) Received: from [192.168.1.75] (93.97.24.219) by honeysuckle.london.02.net (8.5.016.1) id 497A2AF001B8040B; Fri, 27 Mar 2009 14:00:57 +0000 Message-ID: <49CCDC19.3040606@onetel.com> Date: Fri, 27 Mar 2009 14:00:57 +0000 From: Chris Whitehouse User-Agent: Thunderbird 2.0.0.19 (X11/20090113) MIME-Version: 1.0 To: Nate Lawson References: <49C80E65.9090500@onetel.com> <49C93309.6050708@iki.fi> <20090325140718.J95588@sola.nimnet.asn.au> <49C9EE50.6070507@onetel.com> <1237992462.1297.22.camel@RabbitsDen> <49CBF7D1.20102@onetel.com> <49CC147A.3030805@root.org> In-Reply-To: <49CC147A.3030805@root.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@FreeBSD.org Subject: Re: acpi_tz0: _CRT value is absurd, ignored (256.0C) (was pr kern/105537) X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 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 Mar 2009 14:01:05 -0000 Nate Lawson wrote: > > Thermal zones are re-evaluated when a Notify comes in that says to do > so. Perhaps if "user_override" is set to 1, we should not re-evaluate > them. However, perhaps that should only be done for values the user > actually overrode. > > There has to be a different solution Windows used. Maybe they ignore _crt. I wondered about this. Surely if the laptop is running Windows and it overheats it would shut down? I do have Windows Xp installed as well as FreeBSD. I had a quick look in the registry - couldn't find _CRT and CRT was too common. I also found some references to acpi and thermal zone but couldn't take the time to look properly right now (supposed to be working). I could look later if anybody is interested. Chris > From owner-freebsd-acpi@FreeBSD.ORG Fri Mar 27 14:03:55 2009 Return-Path: Delivered-To: freebsd-acpi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 40EA61065678 for ; Fri, 27 Mar 2009 14:03:55 +0000 (UTC) (envelope-from cwhiteh@onetel.com) Received: from april.london.02.net (april.london.02.net [87.194.255.143]) by mx1.freebsd.org (Postfix) with ESMTP id CE7848FC22 for ; Fri, 27 Mar 2009 14:03:54 +0000 (UTC) (envelope-from cwhiteh@onetel.com) Received: from [192.168.1.75] (93.97.24.219) by april.london.02.net (8.5.016.1) id 4967C92C01D2EA6A; Fri, 27 Mar 2009 14:03:39 +0000 Message-ID: <49CCDCBA.3000406@onetel.com> Date: Fri, 27 Mar 2009 14:03:38 +0000 From: Chris Whitehouse User-Agent: Thunderbird 2.0.0.19 (X11/20090113) MIME-Version: 1.0 To: "Alexandre \"Sunny\" Kovalenko" References: <49C80E65.9090500@onetel.com> <49C93309.6050708@iki.fi> <20090325140718.J95588@sola.nimnet.asn.au> <49C9EE50.6070507@onetel.com> <1237992462.1297.22.camel@RabbitsDen> <49CBF7D1.20102@onetel.com> <49CC147A.3030805@root.org> <1238118621.1365.35.camel@RabbitsDen> In-Reply-To: <1238118621.1365.35.camel@RabbitsDen> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@FreeBSD.org, Ian Smith Subject: Re: acpi_tz0: _CRT value is absurd, ignored (256.0C) (was pr kern/105537) X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 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 Mar 2009 14:03:55 -0000 Alexandre "Sunny" Kovalenko wrote: > On Thu, 2009-03-26 at 16:49 -0700, Nate Lawson wrote: >> Chris Whitehouse wrote: >>> Alexandre "Sunny" Kovalenko wrote: >>>> To be fair, if all you want is to override _CRT, you should be able to >>>> put something to the tune of >>>> >>>> hw.acpi.thermal.user_override=1 >>>> hw.acpi.thermal.tz0._CRT=90C >>>> >>>> in your /etc/sysctl.conf and not deal with the ASL at all. >>> I tried this and it sets hw.acpi.thermal.tz0._CRT correctly until >>> hw.acpi.thermal.tz0.active and hw.acpi.thermal.tz0.temperature change >>> values at which point hw.acpi.thermal.tz0._CRT reverts to -1. >>> > > Looking at ASL I can see five thermal zone objects defined and only one > of them (TZ4) looking somewhat normal: _CRT is 110C and _TMP method goes > to the trouble of making sane return value. Maybe Windows somehow knows > which thermal zones to ignore? Given the snippet below this _was_ geared > heavily towards Windows: > > If (\_OSI ("Windows 2001")) > { > Store (0x04, C014) > } > > If (\_OSI ("Windows 2001 SP1")) > { > Store (0x04, C014) > } > > If (\_OSI ("Windows 2001 SP2")) > { > Store (0x05, C014) > } > > If (\_OSI ("Windows 2006")) > { > Store (0x06, C014) > } > > Chris, you should be able to set hw.acpi.osname= above> in loader.conf and see if things improve somewhat. Note that > "Windows 2001" and "Windows 2001 SP1" are identical. sysctl says it is an unknown oid > > Could you also, please, post the full output of the sysctl > hw.acpi.thermal > hw.acpi.thermal.min_runtime: 0 hw.acpi.thermal.polling_rate: 10 hw.acpi.thermal.user_override: 1 hw.acpi.thermal.tz0.temperature: 45.0C hw.acpi.thermal.tz0.active: -1 hw.acpi.thermal.tz0.passive_cooling: 0 hw.acpi.thermal.tz0.thermal_flags: 0 hw.acpi.thermal.tz0._PSV: -1 hw.acpi.thermal.tz0._HOT: -1 hw.acpi.thermal.tz0._CRT: -1 hw.acpi.thermal.tz0._ACx: 80.0C 70.0C 60.0C 50.0C -1 -1 -1 -1 -1 -1 hw.acpi.thermal.tz0._TC1: -1 hw.acpi.thermal.tz0._TC2: -1 hw.acpi.thermal.tz0._TSP: -1 hw.acpi.thermal.tz1.temperature: 43.0C hw.acpi.thermal.tz1.active: -1 hw.acpi.thermal.tz1.passive_cooling: 1 hw.acpi.thermal.tz1.thermal_flags: 0 hw.acpi.thermal.tz1._PSV: 102.0C hw.acpi.thermal.tz1._HOT: -1 hw.acpi.thermal.tz1._CRT: 105.0C 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: 2 hw.acpi.thermal.tz1._TSP: 300 hw.acpi.thermal.tz2.temperature: 43.0C hw.acpi.thermal.tz2.active: -1 hw.acpi.thermal.tz2.passive_cooling: 0 hw.acpi.thermal.tz2.thermal_flags: 0 hw.acpi.thermal.tz2._PSV: -1 hw.acpi.thermal.tz2._HOT: -1 hw.acpi.thermal.tz2._CRT: 105.0C hw.acpi.thermal.tz2._ACx: -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 hw.acpi.thermal.tz2._TC1: 1 hw.acpi.thermal.tz2._TC2: 2 hw.acpi.thermal.tz2._TSP: 300 hw.acpi.thermal.tz3.temperature: 28.9C hw.acpi.thermal.tz3.active: -1 hw.acpi.thermal.tz3.passive_cooling: 0 hw.acpi.thermal.tz3.thermal_flags: 0 hw.acpi.thermal.tz3._PSV: 60.0C hw.acpi.thermal.tz3._HOT: -1 hw.acpi.thermal.tz3._CRT: 105.0C hw.acpi.thermal.tz3._ACx: -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 hw.acpi.thermal.tz3._TC1: 1 hw.acpi.thermal.tz3._TC2: 2 hw.acpi.thermal.tz3._TSP: 300 hw.acpi.thermal.tz4.temperature: 0.0C hw.acpi.thermal.tz4.active: -1 hw.acpi.thermal.tz4.passive_cooling: 0 hw.acpi.thermal.tz4.thermal_flags: 0 hw.acpi.thermal.tz4._PSV: -1 hw.acpi.thermal.tz4._HOT: -1 hw.acpi.thermal.tz4._CRT: 110.0C hw.acpi.thermal.tz4._ACx: -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 hw.acpi.thermal.tz4._TC1: -1 hw.acpi.thermal.tz4._TC2: -1 hw.acpi.thermal.tz4._TSP: -1 Also fetch www.fishercroft.plus.com/messages.gz will get bits of /var/log/messages with the normal startup messages and the output of #!/bin/sh while [ TRUE ]; do logger \ ` sysctl -n dev.cpu.0.temperature ; sysctl -n dev.cpu.1.temperature ; \ sysctl -n hw.acpi.thermal.tz0.temperature ; sysctl -n hw.acpi.thermal.tz0.active ; sysctl -n hw.acpi.thermal.tz0._CRT ; \ sysctl -n hw.acpi.thermal.tz1.temperature ; sysctl -n hw.acpi.thermal.tz1.active ; sysctl -n hw.acpi.thermal.tz1._CRT ; \ sysctl -n hw.acpi.thermal.tz2.temperature ; sysctl -n hw.acpi.thermal.tz2.active ; sysctl -n hw.acpi.thermal.tz2._CRT ; \ sysctl -n hw.acpi.thermal.tz3.temperature ; sysctl -n hw.acpi.thermal.tz3.active ; sysctl -n hw.acpi.thermal.tz3._CRT ; \ sysctl -n hw.acpi.thermal.tz4.temperature ; sysctl -n hw.acpi.thermal.tz4.active ; sysctl -n hw.acpi.thermal.tz4._CRT ` sleep 5 done (sorry bad wrapping) The two cpu temps come from coretemp.ko module. While this was running I changed the temp with burnK7 and an icepack :). It's clear that the messages do correspond to changes of state but there are further triggers that I am not watching. Chris From owner-freebsd-acpi@FreeBSD.ORG Sat Mar 28 08:50:03 2009 Return-Path: Delivered-To: freebsd-acpi@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 96F79106566B for ; Sat, 28 Mar 2009 08:50:03 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 359A78FC15 for ; Sat, 28 Mar 2009 08:50:03 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n2S8o22K092795 for ; Sat, 28 Mar 2009 08:50:02 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n2S8o248092794; Sat, 28 Mar 2009 08:50:02 GMT (envelope-from gnats) Date: Sat, 28 Mar 2009 08:50:02 GMT Message-Id: <200903280850.n2S8o248092794@freefall.freebsd.org> To: freebsd-acpi@FreeBSD.org From: Martin Birgmeier Cc: Subject: Re: kern/132602: [acpi] ACPI Problem with Intel SS4200: System does not power off X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Martin Birgmeier List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Mar 2009 08:50:03 -0000 The following reply was made to PR kern/132602; it has been noted by GNATS. From: Martin Birgmeier To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/132602: [acpi] ACPI Problem with Intel SS4200: System does not power off Date: Sat, 28 Mar 2009 09:43:36 +0100 (CET) From the description I'd say that this is a duplicate of the bug report I submitted, kern/130683.