From owner-freebsd-acpi@FreeBSD.ORG Mon Mar 29 11:06:49 2010 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 1E377106566C for ; Mon, 29 Mar 2010 11:06:49 +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 E5C8A8FC16 for ; Mon, 29 Mar 2010 11:06:48 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o2TB6mdl057885 for ; Mon, 29 Mar 2010 11:06:48 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o2TB6mA8057883 for freebsd-acpi@FreeBSD.org; Mon, 29 Mar 2010 11:06:48 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 29 Mar 2010 11:06:48 GMT Message-Id: <201003291106.o2TB6mA8057883@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, 29 Mar 2010 11:06:49 -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 amd64/144551 acpi [acpi] ACPI issues on SuperMicro X7SPA-H o i386/144045 acpi [acpi] [panic] kernel trap with acpi enabled o i386/143798 acpi [acpi] shutdown problem with SiS K7S5A o kern/143420 acpi [acpi] ACPI issues with Toshiba o kern/142263 acpi [acpi] ACPI regression on Asus K8N7-E deluxe motherboa o kern/142009 acpi [acpi] [panic] Panic in AcpiNsGetAttachedObject o amd64/140751 acpi [acpi] BIOS resource allocation and FreeBSD ACPI in TO o kern/139088 acpi [acpi] ACPI Exception: AE_AML_INFINITE_LOOP error o amd64/138210 acpi [acpi] acer aspire 5536 ACPI problems (S3, brightness, o bin/137053 acpi [hang] FreeBSD 8.0 BETA2Compaq Mini 700 locks on boot o kern/137042 acpi [acpi] hp laptop's lcd not wakes up after suspend to r o kern/136808 acpi [acpi] panic when switching to s3 o i386/136008 acpi [acpi] Dell Vostro 1310 will not shutdown (Requires us o bin/135349 acpi [patch] teach acpidump(8) to disassemble arbitrary mem o kern/135070 acpi [acpi] [patch] BIOS resource allocation and FreeBSD AC 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 f 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/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 amd64/121439 acpi [boot] Installation of FreeBSD 7.0 fails: ACPI problem 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/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/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 o i386/83018 acpi [install] Installer will not boot on Asus P4S8X BIOS 1 f 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 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 59 problems total. From owner-freebsd-acpi@FreeBSD.ORG Tue Mar 30 03:32:59 2010 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 00BAD106564A for ; Tue, 30 Mar 2010 03:32:59 +0000 (UTC) (envelope-from dan@obluda.cz) Received: from smtp1.kolej.mff.cuni.cz (smtp1.kolej.mff.cuni.cz [78.128.192.10]) by mx1.freebsd.org (Postfix) with ESMTP id 916178FC15 for ; Tue, 30 Mar 2010 03:32:57 +0000 (UTC) X-Envelope-From: dan@obluda.cz Received: from kgw.obluda.cz (kgw.obluda.cz [193.179.199.50]) by smtp1.kolej.mff.cuni.cz (8.14.3/8.14.3) with ESMTP id o2U3Wt9R030896 for ; Tue, 30 Mar 2010 05:32:56 +0200 (CEST) (envelope-from dan@obluda.cz) Message-ID: <4BB170E7.3030407@obluda.cz> Date: Tue, 30 Mar 2010 05:32:55 +0200 From: Dan Lukes User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.1.8) Gecko/20100221 SeaMonkey/2.0.3 MIME-Version: 1.0 To: freebsd-acpi@freebsd.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Brightness change on notebook that follow ACPI specification (par. B.7) 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, 30 Mar 2010 03:32:59 -0000 Most notebooks have special keys (mostly Fn+something) to change brightness of LCD display. Some of them (my notebok, for example) follows the ACPI specification (paragraph B.7) how to announce the user request for brightness change to OS. I implemented such handling as part of acpi-video module. It's verified to work on my HP Mini 5101 & FreeBSD 8.0. No test on other notebook done as I have no other notebook. No test on other OS version, but verified that patched module can be compiled on 6.4-R, 7.2-R, 8.0-R. I assume (not verified) it's compilable on all 6.x-8.x. I assume (not verified) it should work on all of these versions. If someone want to test it then the patch is here: http://www.freebsd.cz/~dan/patch-acpi-video installation: cd /usr/src ; patch < patch-acpi-video then compile the module: http://www.freebsd.org/doc/handbook/acpi-debug.html#ACPI-DEBUGOUTPUT then kldload acpi_video then try keys for brightness change. I'm interested to know on which notebook and FreeBSD version is verified to be (not)working. If it doesn't work it may be either: 1. bug in my patch 2. your notebook doesn't follow ACPI specification (par. B.7) If you are skilled user and you want to know more (and you have compiled ACPI modules with ACPI_DEBUG) you can set debug.acpi.level="ACPI_LV_ALL_EXCEPTIONS" then look on console messages what happens when you press the special keys. Dan P.S. Brief info how it works: Specification claim the ACPI will send notification of the type 0x85-0x88 (brightness cycle/inc/dec/zero) to the output device handler. It's catched by my code (in acpi_video module) so I know what key user pressed. With such knowledge and current brightness (obtained from _BCQ method evaluation) and list of allowed brightnesses (obtained from _BCL method evaluation), I can calculate new brightness. It's set using _BCM method. No more fun here ... From owner-freebsd-acpi@FreeBSD.ORG Tue Mar 30 08:47:17 2010 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 71B98106566B for ; Tue, 30 Mar 2010 08:47:17 +0000 (UTC) (envelope-from rpaulo@gmail.com) Received: from mail-bw0-f216.google.com (mail-bw0-f216.google.com [209.85.218.216]) by mx1.freebsd.org (Postfix) with ESMTP id EE0B18FC12 for ; Tue, 30 Mar 2010 08:47:16 +0000 (UTC) Received: by bwz8 with SMTP id 8so5418269bwz.3 for ; Tue, 30 Mar 2010 01:47:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=xvzm/rVnRJJanocNDz16YluT2UElIp2fIGC1cNuhdGI=; b=LpDChi2H/lI8PE+/qviiS5NcVHf5ytxI6ieJFh2GpISwzLU1GhB+Bd6YDTO/nBPLav Anin+C57T066upyseR4ELwHIkWGWoqpcrPQ4Y/jkTHmkt2vLuozv/onrSLUf8d5ufxhV gKePbwu83151Egx+DovFlsIz5YvY8NICgUyWQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=Cn3vOtL//18Edu13TQLpNBxygjyajwV2sq1WhqhD36CZtGFT5KRL2wpVv1eRAbgFT9 iN0z9IVJCezjdxHLXOSwshxhypJpzrL9fRZ/YyZP9ckXSV5Wj+2KB9KJzOMoQ6/sQ0k6 fczWMxCSUWnES1pmdYGnMUWkV3qHlaeKsGJJs= Received: by 10.204.174.194 with SMTP id u2mr6498936bkz.40.1269938835708; Tue, 30 Mar 2010 01:47:15 -0700 (PDT) Received: from [10.0.10.2] (54.81.54.77.rev.vodafone.pt [77.54.81.54]) by mx.google.com with ESMTPS id s17sm46065845bkd.4.2010.03.30.01.47.14 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 30 Mar 2010 01:47:14 -0700 (PDT) Sender: Rui Paulo Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Rui Paulo In-Reply-To: <4BB170E7.3030407@obluda.cz> Date: Tue, 30 Mar 2010 09:47:12 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <8D820BAA-C1B9-408C-AAF3-EA69612D2C46@freebsd.org> References: <4BB170E7.3030407@obluda.cz> To: Dan Lukes X-Mailer: Apple Mail (2.1078) Cc: freebsd-acpi@freebsd.org Subject: Re: Brightness change on notebook that follow ACPI specification (par. B.7) 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, 30 Mar 2010 08:47:17 -0000 On 30 Mar 2010, at 04:32, Dan Lukes wrote: >=20 > Most notebooks have special keys (mostly Fn+something) to change = brightness of LCD display. >=20 > Some of them (my notebok, for example) follows the ACPI specification = (paragraph B.7) how to announce the user request for brightness change = to OS. >=20 > I implemented such handling as part of acpi-video module. >=20 > It's verified to work on my HP Mini 5101 & FreeBSD 8.0. >=20 > No test on other notebook done as I have no other notebook. >=20 > No test on other OS version, but verified that patched module can be = compiled on 6.4-R, 7.2-R, 8.0-R. I assume (not verified) it's compilable = on all 6.x-8.x. I assume (not verified) it should work on all of these = versions. >=20 > If someone want to test it then the patch is here: > http://www.freebsd.cz/~dan/patch-acpi-video >=20 > installation: > cd /usr/src ; patch < patch-acpi-video > then compile the module: > http://www.freebsd.org/doc/handbook/acpi-debug.html#ACPI-DEBUGOUTPUT > then kldload acpi_video > then try keys for brightness change. >=20 > I'm interested to know on which notebook and FreeBSD version is = verified to be (not)working. >=20 > If it doesn't work it may be either: > 1. bug in my patch > 2. your notebook doesn't follow ACPI specification (par. B.7) >=20 > If you are skilled user and you want to know more (and you have = compiled ACPI modules with ACPI_DEBUG) you can set > debug.acpi.level=3D"ACPI_LV_ALL_EXCEPTIONS" > then look on console messages what happens when you press the special = keys. >=20 > Dan I see nothing wrong with this patch and I think it can be committed, but = I would like others to take a look. -- Rui Paulo From owner-freebsd-acpi@FreeBSD.ORG Tue Mar 30 09:05:47 2010 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 8FA9D106564A for ; Tue, 30 Mar 2010 09:05:47 +0000 (UTC) (envelope-from dan@obluda.cz) Received: from smtp1.kolej.mff.cuni.cz (smtp1.kolej.mff.cuni.cz [78.128.192.10]) by mx1.freebsd.org (Postfix) with ESMTP id 291B28FC15 for ; Tue, 30 Mar 2010 09:05:46 +0000 (UTC) X-Envelope-From: dan@obluda.cz Received: from kgw.obluda.cz (kgw.obluda.cz [193.179.199.50]) by smtp1.kolej.mff.cuni.cz (8.14.3/8.14.3) with ESMTP id o2U95i7v007190; Tue, 30 Mar 2010 11:05:45 +0200 (CEST) (envelope-from dan@obluda.cz) Message-ID: <4BB1BEE8.8070505@obluda.cz> Date: Tue, 30 Mar 2010 11:05:44 +0200 From: Dan Lukes User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.1.8) Gecko/20100221 SeaMonkey/2.0.3 MIME-Version: 1.0 To: Rui Paulo References: <4BB170E7.3030407@obluda.cz> <8D820BAA-C1B9-408C-AAF3-EA69612D2C46@freebsd.org> In-Reply-To: <8D820BAA-C1B9-408C-AAF3-EA69612D2C46@freebsd.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@freebsd.org Subject: Re: Brightness change on notebook that follow ACPI specification (par. B.7) 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, 30 Mar 2010 09:05:47 -0000 On 03/30/10 10:47, Rui Paulo: >> Most notebooks have special keys (mostly Fn+something) to change brightness of LCD display. >> Some of them (my notebok, for example) follows the ACPI specification (paragraph B.7) how to announce the user request for brightness change to OS. >> I implemented such handling as part of acpi-video module. > I see nothing wrong with this patch and I think it can be committed, but I would like others to take a look. Thanks. Code review needs to be done also, but it would be nice to have more "yes, it works with my NB and OS ?.??" reports at this phase ... Did you tried it ? Which notebook and FreeBSD version ? Dan From owner-freebsd-acpi@FreeBSD.ORG Tue Mar 30 09:53:50 2010 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 EA21B1065670 for ; Tue, 30 Mar 2010 09:53:50 +0000 (UTC) (envelope-from rpaulo@gmail.com) Received: from mail-bw0-f216.google.com (mail-bw0-f216.google.com [209.85.218.216]) by mx1.freebsd.org (Postfix) with ESMTP id 72CFB8FC16 for ; Tue, 30 Mar 2010 09:53:50 +0000 (UTC) Received: by bwz8 with SMTP id 8so5463294bwz.3 for ; Tue, 30 Mar 2010 02:53:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=Ak0/gKGJLRsrqheqeg7tONk5c7q+r/wqqQPV8umJVYo=; b=vcp/QGNI51yVpu/R8l6vCWrmGZZ+7MOEDv0jBU0JGyeDI3D2f7Geu9GJc/mwyLBeVf UerAN9CN8EovfzplYGl0hEit0HaPeG2UFpXb4XYSVRRLsMCBMJurVh1YuC8Vibzj0Lv6 /yI18HTswll5b0ks9pVQ7/JJM8ktUOCnS0vmQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=wrTwW0ZzVGSr4DYlTSczBUXmJNbO9oA8PRMtVjC1hYWHsaDSggprm6coUJ+jMQgQ4F 37BqWe0VjERkvuHT78jiBcRkg7Ln8d7liBxYWbb9jjMguD6U+Zv9QjA9tvQfVkxefQZa o0lJUGnk6uH7KKXRLbDA5mD4a2p+/uRhxWrQw= Received: by 10.204.74.32 with SMTP id s32mr1914439bkj.148.1269942829412; Tue, 30 Mar 2010 02:53:49 -0700 (PDT) Received: from [10.0.10.2] (54.81.54.77.rev.vodafone.pt [77.54.81.54]) by mx.google.com with ESMTPS id l1sm46503114bkl.14.2010.03.30.02.53.47 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 30 Mar 2010 02:53:48 -0700 (PDT) Sender: Rui Paulo Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Rui Paulo In-Reply-To: <4BB1BEE8.8070505@obluda.cz> Date: Tue, 30 Mar 2010 10:53:46 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4BB170E7.3030407@obluda.cz> <8D820BAA-C1B9-408C-AAF3-EA69612D2C46@freebsd.org> <4BB1BEE8.8070505@obluda.cz> To: Dan Lukes X-Mailer: Apple Mail (2.1078) Cc: freebsd-acpi@freebsd.org Subject: Re: Brightness change on notebook that follow ACPI specification (par. B.7) 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, 30 Mar 2010 09:53:51 -0000 On 30 Mar 2010, at 10:05, Dan Lukes wrote: > On 03/30/10 10:47, Rui Paulo: >>> Most notebooks have special keys (mostly Fn+something) to change = brightness of LCD display. >>> Some of them (my notebok, for example) follows the ACPI = specification (paragraph B.7) how to announce the user request for = brightness change to OS. >>> I implemented such handling as part of acpi-video module. >=20 >> I see nothing wrong with this patch and I think it can be committed, = but I would like others to take a look. >=20 > Thanks. Code review needs to be done also, but it would be nice to = have more "yes, it works with my NB and OS ?.??" reports at this phase = ... >=20 > Did you tried it ? Which notebook and FreeBSD version ? I haven't tried it. -- Rui Paulo From owner-freebsd-acpi@FreeBSD.ORG Tue Mar 30 13:53:07 2010 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 B26E2106566B; Tue, 30 Mar 2010 13:53:07 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 87E3D8FC13; Tue, 30 Mar 2010 13:53:07 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o2UDr744084901; Tue, 30 Mar 2010 13:53:07 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o2UDr7mr084897; Tue, 30 Mar 2010 13:53:07 GMT (envelope-from linimon) Date: Tue, 30 Mar 2010 13:53:07 GMT Message-Id: <201003301353.o2UDr7mr084897@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-acpi@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: bin/145063: [patch] powerd(8): Add -m and -M (minimum and maximum frequency) options to powerd 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, 30 Mar 2010 13:53:07 -0000 Synopsis: [patch] powerd(8): Add -m and -M (minimum and maximum frequency) options to powerd Responsible-Changed-From-To: freebsd-bugs->freebsd-acpi Responsible-Changed-By: linimon Responsible-Changed-When: Tue Mar 30 13:52:32 UTC 2010 Responsible-Changed-Why: Submitter has requested review from acpi group. http://www.freebsd.org/cgi/query-pr.cgi?pr=145063 From owner-freebsd-acpi@FreeBSD.ORG Tue Mar 30 14:55:10 2010 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 6B0181065670 for ; Tue, 30 Mar 2010 14:55:10 +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 3C3FC8FC13 for ; Tue, 30 Mar 2010 14:55:10 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id E1C8446B2D; Tue, 30 Mar 2010 10:55:09 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 15A738A021; Tue, 30 Mar 2010 10:55:03 -0400 (EDT) From: John Baldwin To: freebsd-acpi@freebsd.org Date: Tue, 30 Mar 2010 10:11:40 -0400 User-Agent: KMail/1.12.1 (FreeBSD/7.3-CBSD-20100217; KDE/4.3.1; amd64; ; ) References: <4BB170E7.3030407@obluda.cz> In-Reply-To: <4BB170E7.3030407@obluda.cz> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201003301011.40215.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Tue, 30 Mar 2010 10:55:03 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.7 required=4.2 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: Subject: Re: Brightness change on notebook that follow ACPI specification (par. B.7) 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, 30 Mar 2010 14:55:10 -0000 On Monday 29 March 2010 11:32:55 pm Dan Lukes wrote: > > Most notebooks have special keys (mostly Fn+something) to change > brightness of LCD display. > > Some of them (my notebok, for example) follows the ACPI specification > (paragraph B.7) how to announce the user request for brightness change > to OS. > > I implemented such handling as part of acpi-video module. > > It's verified to work on my HP Mini 5101 & FreeBSD 8.0. > > No test on other notebook done as I have no other notebook. A patch to implement the brightness controls was already committed to HEAD a while ago and have already been merged to 8-stable and 7-stable. Can you test the a kernel from 8-stable to ensure it works ok on your machine? The patches in HEAD work fine on an HP Mini 2140 that I have here. -- John Baldwin From owner-freebsd-acpi@FreeBSD.ORG Tue Mar 30 19:30:40 2010 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 ADC80106564A for ; Tue, 30 Mar 2010 19:30:40 +0000 (UTC) (envelope-from dan@obluda.cz) Received: from smtp1.kolej.mff.cuni.cz (smtp1.kolej.mff.cuni.cz [78.128.192.10]) by mx1.freebsd.org (Postfix) with ESMTP id 2B1D78FC13 for ; Tue, 30 Mar 2010 19:30:39 +0000 (UTC) X-Envelope-From: dan@obluda.cz Received: from kgw.obluda.cz (kgw.obluda.cz [193.179.199.50]) by smtp1.kolej.mff.cuni.cz (8.14.3/8.14.3) with ESMTP id o2UJUbTf076745; Tue, 30 Mar 2010 21:30:38 +0200 (CEST) (envelope-from dan@obluda.cz) Message-ID: <4BB2515D.1060808@obluda.cz> Date: Tue, 30 Mar 2010 21:30:37 +0200 From: Dan Lukes User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.1.8) Gecko/20100221 SeaMonkey/2.0.3 MIME-Version: 1.0 To: John Baldwin References: <4BB170E7.3030407@obluda.cz> <201003301011.40215.jhb@freebsd.org> In-Reply-To: <201003301011.40215.jhb@freebsd.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@freebsd.org Subject: Re: Brightness change on notebook that follow ACPI specification (par. B.7) 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, 30 Mar 2010 19:30:40 -0000 On 03/30/10 16:11, John Baldwin: >> Most notebooks have special keys (mostly Fn+something) to change >> brightness of LCD display. >> >> Some of them (my notebok, for example) follows the ACPI specification >> (paragraph B.7) how to announce the user request for brightness change >> to OS. >> >> I implemented such handling as part of acpi-video module. >> >> It's verified to work on my HP Mini 5101& FreeBSD 8.0. >> >> No test on other notebook done as I have no other notebook. > A patch to implement the brightness controls was already committed to HEAD a > while ago and have already been merged to 8-stable and 7-stable. Can you test > the a kernel from 8-stable to ensure it works ok on your machine? The patches > in HEAD work fine on an HP Mini 2140 that I have here. I'm sure there has been a regular PR before commitment assigned to ACPI group for review, but I missed them. It resulted in waste of time. My fault. I will test it later (I have no 8-STABLE here), I'm almost sure it will work (based on code review). There are several notices related to coding of the committed patch: --- 1 --------------- /* events */ #define VID_NOTIFY_SWITCHED 0x80 #define VID_NOTIFY_REPROBE 0x81 #define VID_NOTIFY_CYCLE_BRN 0x85 #define VID_NOTIFY_INC_BRN 0x86 #define VID_NOTIFY_DEC_BRN 0x87 #define VID_NOTIFY_ZERO_BRN 0x88 The events 0x80 and 0x81 are "Display Devices" device specific notifications (according ACPI specification B.5), but events 0x85-0x88 are "Output devices" device specific notification (ACPI spec. B.7). The common name VID_NOTIFY_* for values that come from different domains is confusing. Note that future versions of ACPI specification may overlaps (there may be defined 0x80 event for Output device or event 0x85 event for Display device). --- 2 --------------- The code of acpi_video_vo_notify_handler(): Handling of event 0x85 refuse do anything when there are less than four levels. I see no reason for such limitation - we can safely cycle trougth three or even trougth two levels as well. It advance, the 0x85 handling assume the _BCL list is sorted and ignores vo_levels[0] and vo_levels[1] (note that handling of 0x86/0x87 just few lines bellow doesn't assume sorted levels nor ignore levels [0] and [1]). The 0x88 handling is duplicate implementation of acpi_video_vo_check_level instead just calling the already implemented function. ------------------------ Such notices should not be considered offence against the autor nor committer in any way. Just my $0.02 related to the code. Dan From owner-freebsd-acpi@FreeBSD.ORG Tue Mar 30 20:12:30 2010 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 CA50B1065672 for ; Tue, 30 Mar 2010 20:12:30 +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 885CB8FC16 for ; Tue, 30 Mar 2010 20:12:30 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 21AFD46B2D; Tue, 30 Mar 2010 16:12:30 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 52A0F8A01F; Tue, 30 Mar 2010 16:12:29 -0400 (EDT) From: John Baldwin To: Dan Lukes Date: Tue, 30 Mar 2010 16:12:18 -0400 User-Agent: KMail/1.12.1 (FreeBSD/7.3-CBSD-20100217; KDE/4.3.1; amd64; ; ) References: <4BB170E7.3030407@obluda.cz> <201003301011.40215.jhb@freebsd.org> <4BB2515D.1060808@obluda.cz> In-Reply-To: <4BB2515D.1060808@obluda.cz> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201003301612.18045.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Tue, 30 Mar 2010 16:12:29 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.8 required=4.2 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: freebsd-acpi@freebsd.org Subject: Re: Brightness change on notebook that follow ACPI specification (par. B.7) 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, 30 Mar 2010 20:12:31 -0000 On Tuesday 30 March 2010 3:30:37 pm Dan Lukes wrote: > On 03/30/10 16:11, John Baldwin: > >> Most notebooks have special keys (mostly Fn+something) to change > >> brightness of LCD display. > >> > >> Some of them (my notebok, for example) follows the ACPI specification > >> (paragraph B.7) how to announce the user request for brightness change > >> to OS. > >> > >> I implemented such handling as part of acpi-video module. > >> > >> It's verified to work on my HP Mini 5101& FreeBSD 8.0. > >> > >> No test on other notebook done as I have no other notebook. > > > A patch to implement the brightness controls was already committed to HEAD a > > while ago and have already been merged to 8-stable and 7-stable. Can you test > > the a kernel from 8-stable to ensure it works ok on your machine? The patches > > in HEAD work fine on an HP Mini 2140 that I have here. > > I'm sure there has been a regular PR before commitment assigned to ACPI > group for review, but I missed them. It resulted in waste of time. My fault. I'm not sure if there was a PR. I do recall a thread on the acpi@ mailing list when the patch was first submitted. > I will test it later (I have no 8-STABLE here), I'm almost sure it will > work (based on code review). > > There are several notices related to coding of the committed patch: > > --- 1 --------------- > /* events */ > #define VID_NOTIFY_SWITCHED 0x80 > #define VID_NOTIFY_REPROBE 0x81 > #define VID_NOTIFY_CYCLE_BRN 0x85 > #define VID_NOTIFY_INC_BRN 0x86 > #define VID_NOTIFY_DEC_BRN 0x87 > #define VID_NOTIFY_ZERO_BRN 0x88 > > The events 0x80 and 0x81 are "Display Devices" device specific > notifications (according ACPI specification B.5), but events 0x85-0x88 > are "Output devices" device specific notification (ACPI spec. B.7). The > common name VID_NOTIFY_* for values that come from different domains is > confusing. Note that future versions of ACPI specification may overlaps > (there may be defined 0x80 event for Output device or event 0x85 event > for Display device). > > --- 2 --------------- > The code of acpi_video_vo_notify_handler(): > > Handling of event 0x85 refuse do anything when there are less than four > levels. I see no reason for such limitation - we can safely cycle > trougth three or even trougth two levels as well. > > It advance, the 0x85 handling assume the _BCL list is sorted and ignores > vo_levels[0] and vo_levels[1] (note that handling of 0x86/0x87 just few > lines bellow doesn't assume sorted levels nor ignore levels [0] and [1]). > > The 0x88 handling is duplicate implementation of > acpi_video_vo_check_level instead just calling the already implemented > function. > ------------------------ > > Such notices should not be considered offence against the autor nor > committer in any way. Just my $0.02 related to the code. These all sound like good fixes to me. If you can code up a patch that implements them I would be happy to test it. (My netbook only has keys for up and down, so I can't test changes for 0x85 and 0x88.) -- John Baldwin From owner-freebsd-acpi@FreeBSD.ORG Tue Mar 30 20:59:29 2010 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 7D4E1106566B; Tue, 30 Mar 2010 20:59:29 +0000 (UTC) (envelope-from dan@obluda.cz) Received: from smtp1.kolej.mff.cuni.cz (smtp1.kolej.mff.cuni.cz [78.128.192.10]) by mx1.freebsd.org (Postfix) with ESMTP id F015B8FC14; Tue, 30 Mar 2010 20:59:28 +0000 (UTC) X-Envelope-From: dan@obluda.cz Received: from kgw.obluda.cz (kgw.obluda.cz [193.179.199.50]) by smtp1.kolej.mff.cuni.cz (8.14.3/8.14.3) with ESMTP id o2UKxQ20092691; Tue, 30 Mar 2010 22:59:27 +0200 (CEST) (envelope-from dan@obluda.cz) Message-ID: <4BB2662E.9050003@obluda.cz> Date: Tue, 30 Mar 2010 22:59:26 +0200 From: Dan Lukes User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.1.8) Gecko/20100221 SeaMonkey/2.0.3 MIME-Version: 1.0 To: John Baldwin References: <4BB170E7.3030407@obluda.cz> <201003301011.40215.jhb@freebsd.org> <4BB2515D.1060808@obluda.cz> <201003301612.18045.jhb@freebsd.org> In-Reply-To: <201003301612.18045.jhb@freebsd.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@freebsd.org Subject: Re: Brightness change on notebook that follow ACPI specification (par. B.7) 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, 30 Mar 2010 20:59:29 -0000 On 03/30/10 22:12, John Baldwin: >>>> It's verified to work on my HP Mini 5101& FreeBSD 8.0. >> --- 1 --------------- >> --- 2 --------------- > These all sound like good fixes to me. If you can code up a patch Sure, but not today nor tomorrow. At the first I need to install 8-STABLE and before them I need sleep sometimes ... ;-) Dan From owner-freebsd-acpi@FreeBSD.ORG Tue Mar 30 23:30:12 2010 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 90D17106564A for ; Tue, 30 Mar 2010 23:30:12 +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 667DE8FC1F for ; Tue, 30 Mar 2010 23:30:12 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o2UNUBIO072779 for ; Tue, 30 Mar 2010 23:30:11 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o2UNUBCV072774; Tue, 30 Mar 2010 23:30:11 GMT (envelope-from gnats) Date: Tue, 30 Mar 2010 23:30:11 GMT Message-Id: <201003302330.o2UNUBCV072774@freefall.freebsd.org> To: freebsd-acpi@FreeBSD.org From: Alexander Best Cc: Subject: Re: kern/136808: [acpi] panic when switching to s3 X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Alexander Best List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Mar 2010 23:30:12 -0000 The following reply was made to PR kern/136808; it has been noted by GNATS. From: Alexander Best To: Cc: Subject: Re: kern/136808: [acpi] panic when switching to s3 Date: Wed, 31 Mar 2010 01:24:26 +0200 (CEST) running r205860 i'm no longer able to produce this panic nor do i get a "acpi0: device_suspend failed" message when switching to 's3'. please close this pr. -- Alexander Best From owner-freebsd-acpi@FreeBSD.ORG Tue Mar 30 23:32:22 2010 Return-Path: Delivered-To: freebsd-acpi@FreeBSD.org Received: from [127.0.0.1] (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by hub.freebsd.org (Postfix) with ESMTP id AE5CB106564A; Tue, 30 Mar 2010 23:32:19 +0000 (UTC) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: freebsd-acpi@FreeBSD.org Date: Tue, 30 Mar 2010 19:32:09 -0400 User-Agent: KMail/1.6.2 References: <4BB170E7.3030407@obluda.cz> <201003301011.40215.jhb@freebsd.org> <4BB2515D.1060808@obluda.cz> In-Reply-To: <4BB2515D.1060808@obluda.cz> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201003301932.11258.jkim@FreeBSD.org> Cc: Subject: Re: Brightness change on notebook that follow ACPI specification (par. B.7) 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, 30 Mar 2010 23:32:22 -0000 On Tuesday 30 March 2010 03:30 pm, Dan Lukes wrote: > On 03/30/10 16:11, John Baldwin: > >> Most notebooks have special keys (mostly Fn+something) to change > >> brightness of LCD display. > >> > >> Some of them (my notebok, for example) follows the ACPI > >> specification (paragraph B.7) how to announce the user request > >> for brightness change to OS. > >> > >> I implemented such handling as part of acpi-video module. > >> > >> It's verified to work on my HP Mini 5101& FreeBSD 8.0. > >> > >> No test on other notebook done as I have no other notebook. > > > > A patch to implement the brightness controls was already > > committed to HEAD a while ago and have already been merged to > > 8-stable and 7-stable. Can you test the a kernel from 8-stable > > to ensure it works ok on your machine? The patches in HEAD work > > fine on an HP Mini 2140 that I have here. > > I'm sure there has been a regular PR before commitment assigned to > ACPI group for review, but I missed them. It resulted in waste of > time. My fault. I wrote it based on Daniel Walter's initial work. > I will test it later (I have no 8-STABLE here), I'm almost sure it > will work (based on code review). > > There are several notices related to coding of the committed patch: > > --- 1 --------------- > /* events */ > #define VID_NOTIFY_SWITCHED 0x80 > #define VID_NOTIFY_REPROBE 0x81 > #define VID_NOTIFY_CYCLE_BRN 0x85 > #define VID_NOTIFY_INC_BRN 0x86 > #define VID_NOTIFY_DEC_BRN 0x87 > #define VID_NOTIFY_ZERO_BRN 0x88 > > The events 0x80 and 0x81 are "Display Devices" device specific > notifications (according ACPI specification B.5), but events > 0x85-0x88 are "Output devices" device specific notification (ACPI > spec. B.7). The common name VID_NOTIFY_* for values that come from > different domains is confusing. Note that future versions of ACPI > specification may overlaps (there may be defined 0x80 event for > Output device or event 0x85 event for Display device). I didn't think it was necessary because ACPI will not define overlapping events, AFAIK. > --- 2 --------------- > The code of acpi_video_vo_notify_handler(): > > Handling of event 0x85 refuse do anything when there are less than > four levels. I see no reason for such limitation - we can safely > cycle trougth three or even trougth two levels as well. B.6.2 _BCL (Query List of Brightness Control Levels Supported) The first number in the package is the level of the panel when full power is connected to the machine. The second number in the package is the level of the panel when the machine is on batteries. All other numbers are treated as a list of levels OSPM will cycle through when the user toggles (via a keystroke) the brightness level of the display. Please note the last sentence. I know a lot of BIOSes do not follow the rule but I wanted to implement it as close as possible. > It advance, the 0x85 handling assume the _BCL list is sorted and > ignores vo_levels[0] and vo_levels[1] (note that handling of > 0x86/0x87 just few lines bellow doesn't assume sorted levels nor > ignore levels [0] and [1]). It was intentional, i.e., I didn't want to implement increase/decrease via cycle up/down or to miss the first two levels. The spec. was little vague about those cases and I abused it. :-) > The 0x88 handling is duplicate implementation of > acpi_video_vo_check_level instead just calling the already > implemented function. Again, it was intentional, i.e., to mimic the style of other cases in the switch statement and to avoid an unnecessary assertion. > ------------------------ > > Such notices should not be considered offence against the autor nor > committer in any way. Just my $0.02 related to the code. No offense taken. Thanks, Jung-uk Kim From owner-freebsd-acpi@FreeBSD.ORG Wed Mar 31 01:31:28 2010 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 76107106564A; Wed, 31 Mar 2010 01:31:28 +0000 (UTC) (envelope-from dan@obluda.cz) Received: from smtp1.kolej.mff.cuni.cz (smtp1.kolej.mff.cuni.cz [78.128.192.10]) by mx1.freebsd.org (Postfix) with ESMTP id 1DF7F8FC1B; Wed, 31 Mar 2010 01:31:27 +0000 (UTC) X-Envelope-From: dan@obluda.cz Received: from kgw.obluda.cz (kgw.obluda.cz [193.179.199.50]) by smtp1.kolej.mff.cuni.cz (8.14.3/8.14.3) with ESMTP id o2V1VPCM046934; Wed, 31 Mar 2010 03:31:26 +0200 (CEST) (envelope-from dan@obluda.cz) Message-ID: <4BB2A5ED.1070006@obluda.cz> Date: Wed, 31 Mar 2010 03:31:25 +0200 From: Dan Lukes User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.1.8) Gecko/20100221 SeaMonkey/2.0.3 MIME-Version: 1.0 To: Jung-uk Kim References: <4BB170E7.3030407@obluda.cz> <201003301011.40215.jhb@freebsd.org> <4BB2515D.1060808@obluda.cz> <201003301932.11258.jkim@FreeBSD.org> In-Reply-To: <201003301932.11258.jkim@FreeBSD.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@FreeBSD.org Subject: Re: Brightness change on notebook that follow ACPI specification (par. B.7) 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, 31 Mar 2010 01:31:28 -0000 On 03/31/10 01:32, Jung-uk Kim: >> --- 1 --------------- >> /* events */ >> #define VID_NOTIFY_SWITCHED 0x80 >> #define VID_NOTIFY_REPROBE 0x81 >> #define VID_NOTIFY_CYCLE_BRN 0x85 >> #define VID_NOTIFY_INC_BRN 0x86 >> #define VID_NOTIFY_DEC_BRN 0x87 >> #define VID_NOTIFY_ZERO_BRN 0x88 >> >> The events 0x80 and 0x81 are "Display Devices" device specific >> notifications (according ACPI specification B.5), but events >> 0x85-0x88 are "Output devices" device specific notification (ACPI >> spec. B.7). The common name VID_NOTIFY_* for values that come from >> different domains is confusing. Note that future versions of ACPI >> specification may overlaps (there may be defined 0x80 event for >> Output device or event 0x85 event for Display device). > > I didn't think it was necessary because ACPI will not define > overlapping events, AFAIK. Of course. Language problem. I'm speaking about the meaning of the event. We are speaking about range of "device specific" events and they are different meaning for every type of devices. >> Handling of event 0x85 refuse do anything when there are less than >> four levels. I see no reason for such limitation - we can safely >> cycle trougth three or even trougth two levels as well. > > B.6.2 _BCL (Query List of Brightness Control Levels Supported) > > The first number in the package is the level of the panel when full > power is connected to the machine. The second number in the package is > the level of the panel when the machine is on batteries. All other > numbers are treated as a list of levels OSPM will cycle through when > the user toggles (via a keystroke) the brightness level of the > display. > > Please note the last sentence. I know a lot of BIOSes do not follow > the rule but I wanted to implement it as close as possible. There is no "only" word in mentioned sequence. They are list of levels the OSPM will cycle through when ..., but sentence doesn't say that the levels come from such list only. It's sounds like your over-assumption of text rather than "close as possible" implementation. Or, in the world of mathematics symbols, '=>' operator is not '<=>'. I interpret whole _BCL list as list of levels. Yes, first two levels have additional meaning, but it doesn't mean they lost the basic attribute. You should look into description of event, e.g. table B-7 which sounds very clear to me. It doesn't distinquish between first two levels in the list and other levels in the list. But I'm not native english speaker, so it's hard to dispute about exact meaning of the specification text and meaning of wording in the sentences for me. In the fact, I can say for sure only I see nothing in the specification, that can be interpret as "with only three levels in _BCL you can't cycle trough it". >> It advance, the 0x85 handling assume the _BCL list is sorted and >> ignores vo_levels[0] and vo_levels[1] (note that handling of >> 0x86/0x87 just few lines bellow doesn't assume sorted levels nor >> ignore levels [0] and [1]). > > It was intentional, i.e., I didn't want to implement increase/decrease > via cycle up/down or to miss the first two levels. The spec. was > little vague about those cases and I abused it. :-) I'm sayed the actual implementation looks to me like not to be optimal approach. Nothing more... >> The 0x88 handling is duplicate implementation of >> acpi_video_vo_check_level instead just calling the already >> implemented function. > > Again, it was intentional, i.e., to mimic the style of other cases in > the switch statement and to avoid an unnecessary assertion. So you implemented the functionality you already have just few lines above because it looks more uniform when printed on paper ? Well, it's not my way, but it's your code and it works, so it's between you and comitter - and because you are comitter, then it's between you and you ;-) Dan P.S. Don't forget the english is not my native language. It doesn't affect my interpertation of the specification text only but such disputation as well. From owner-freebsd-acpi@FreeBSD.ORG Wed Mar 31 19:41:27 2010 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 40EEC106566B for ; Wed, 31 Mar 2010 19:41:27 +0000 (UTC) (envelope-from robert.moore@intel.com) Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by mx1.freebsd.org (Postfix) with ESMTP id 197AC8FC13 for ; Wed, 31 Mar 2010 19:41:26 +0000 (UTC) Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga102.jf.intel.com with ESMTP; 31 Mar 2010 12:41:23 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.51,343,1267430400"; d="scan'208";a="609237474" Received: from orsmsx601.amr.corp.intel.com ([10.22.226.213]) by orsmga001.jf.intel.com with ESMTP; 31 Mar 2010 12:41:26 -0700 Received: from orsmsx001.amr.corp.intel.com (10.22.226.42) by orsmsx601.amr.corp.intel.com (10.22.226.213) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 31 Mar 2010 12:41:26 -0700 Received: from orsmsx503.amr.corp.intel.com ([10.22.226.47]) by orsmsx001.amr.corp.intel.com ([10.22.226.42]) with mapi; Wed, 31 Mar 2010 12:41:25 -0700 From: "Moore, Robert" To: "Moore, Robert" Date: Wed, 31 Mar 2010 12:41:24 -0700 Thread-Topic: ACPICA version 20100331 released Thread-Index: AcrRCiWpyhbR9mMwQlGfr5jVFqL6bw== Message-ID: <4911F71203A09E4D9981D27F9D83085861769D3F@orsmsx503.amr.corp.intel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Wed, 31 Mar 2010 19:55:11 +0000 Cc: Subject: ACPICA version 20100331 released 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, 31 Mar 2010 19:41:27 -0000 31 March 2010. Summary of changes for version 20100331: This release is available at www.acpica.org/downloads 1) ACPI CA Core Subsystem: Completed a major update for the GPE support in order to improve support fo= r shared GPEs and to simplify both host OS and ACPICA code. Added a referen= ce count mechanism to support shared GPEs that require multiple device driv= ers. Several external interfaces have changed. One external interface has b= een removed. One new external interface was added. Most of the GPE external= interfaces now use the GPE spinlock instead of the events mutex (and the F= lags parameter for many GPE interfaces has been removed.) See the updated A= CPICA Programmer Reference for details. Matthew Garrett, Bob Moore, Rafael = Wysocki. ACPICA BZ 831. Changed: AcpiEnableGpe, AcpiDisableGpe, AcpiClearGpe, AcpiGetGpeStatus Removed: AcpiSetGpeType New: AcpiSetGpe Implemented write support for DataTable operation regions. These regions ar= e defined via the DataTableRegion() operator. Previously, only read support= was implemented. The ACPI specification allows DataTableRegions to be read= /write, however. Implemented a new subsystem option to force a copy of the DSDT to local mem= ory. Optionally copy the entire DSDT to local memory (instead of simply map= ping it.) There are some (albeit very rare) BIOSs that corrupt or replace t= he original DSDT, creating the need for this option. Default is FALSE, do n= ot copy the DSDT. Implemented detection of a corrupted or replaced DSDT. This change adds sup= port to detect a DSDT that has been corrupted and/or replaced from outside = the OS (by firmware). This is typically catastrophic for the system, but ha= s been seen on some machines. Once this problem has been detected, the DSDT= copy option can be enabled via system configuration. Lin Ming, Bob Moore. Fixed two problems with AcpiReallocateRootTable during the root table copy.= When copying the root table to the new allocation, the length used was inc= orrect. The new size was used instead of the current table size, meaning to= o much data was copied. Also, the count of available slots for ACPI tables = was not set correctly. Alexey Starikovskiy, Bob Moore. Example Code and Data Size: These are the sizes for the OS-independent acpi= ca.lib produced by the Microsoft Visual C++ 6.0 32-bit compiler. The debug = version of the code includes the debug output trace mechanism and has a muc= h larger code and data size. Previous Release: Non-Debug Version: 87.5K Code, 18.4K Data, 105.9K Total Debug Version: 163.4K Code, 51.1K Data, 214.5K Total Current Release: Non-Debug Version: 87.9K Code, 18.6K Data, 106.5K Total Debug Version: 163.5K Code, 51.3K Data, 214.8K Total 2) iASL Compiler/Disassembler and Tools: iASL: Implement limited typechecking for values returned from predefined co= ntrol methods. The type of any returned static (unnamed) object is now vali= dated. For example, Return(1). ACPICA BZ 786. iASL: Fixed a predefined name object verification regression. Fixes a probl= em introduced in version 20100304. An error is incorrectly generated if a p= redefined name is declared as a static named object with a value defined us= ing the keywords "Zero", "One", or "Ones". Lin Ming. iASL: Added Windows 7 support for the -g option (get local ACPI tables) by = reducing the requested registry access rights. ACPICA BZ 842. Disassembler: fixed a possible fault when generating External() statements.= Introduced in commit ae7d6fd: Properly handle externals with parent-prefix= (carat). Fixes a string length allocation calculation. Lin Ming. From owner-freebsd-acpi@FreeBSD.ORG Sat Apr 3 01:16:22 2010 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 49FAD106566B for ; Sat, 3 Apr 2010 01:16:22 +0000 (UTC) (envelope-from freebsd@chillt.de) Received: from dd15624.kasserver.com (dd15624.kasserver.com [85.13.136.215]) by mx1.freebsd.org (Postfix) with ESMTP id 0D7E98FC16 for ; Sat, 3 Apr 2010 01:16:21 +0000 (UTC) Received: from taiko.lan (84-203-79-36.mysmart.ie [84.203.79.36]) by dd15624.kasserver.com (Postfix) with ESMTP id D47582C083C43 for ; Sat, 3 Apr 2010 02:57:34 +0200 (CEST) Message-ID: <4BB69279.6060005@chillt.de> Date: Sat, 03 Apr 2010 01:57:29 +0100 From: Bartosz Fabianowski User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.8) Gecko/20100303 Thunderbird/3.0.3 MIME-Version: 1.0 To: freebsd-acpi@freebsd.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Spurious thermal shutdowns on Dell Studio 1557 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: Sat, 03 Apr 2010 01:16:22 -0000 Hi list I have a Dell Studio 1557 laptop. When I first set up the machine in January 2010, I was able to compile the FreeBSD 8-STABLE base system and 700 ports without any thermal issues. Around mid-February 2010, I updated to a newer 8-STABLE. Since then, the computer has been shutting down due to "critical temperatures" whenever I run a CPU-intensive task for more than a few minutes. It is now impossible to compile Firefox or OpenOffice.org. The shutdowns are caused by TZ1, representing the CPU. The relevant sysctl output is: hw.acpi.thermal.tz1.temperature: 60.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: 95.0C hw.acpi.thermal.tz1._HOT: -1 hw.acpi.thermal.tz1._CRT: 85.0C hw.acpi.thermal.tz1._ACx: 71.0C 55.0C -1 -1 -1 -1 -1 -1 -1 -1 hw.acpi.thermal.tz1._TC1: 0 hw.acpi.thermal.tz1._TC2: 10 hw.acpi.thermal.tz1._TSP: 2 Notice how _PSV=95°C > _CRT=85°C. This looks very fishy to me. At 95°C, the CPU should start throttling its speed, passively reducing temperature. But before it gets a chance to do so, the system shuts down due to reaching 85°C. I can work around this by overriding _CRT, setting it to e.g. 99°C. But this clearly is a hack. Prior to some change in FreeBSD, I did not experience any such problems. I disassembled the DSDT. The threshold values are computed as follows: Method (_PSV, 0, Serialized) { Return (Add (0x0AAC, Multiply (PSVT, 0x0A))) } Method (_CRT, 0, Serialized) { Return (Add (0x0AAC, Multiply (CRTT, 0x0A))) } The constants PSVT and CRTT are found in the following memory region: OperationRegion (GNVS, SystemMemory, 0xC779BC9E, 0x0200) Their actual values are PSVT=0x5F and CRTT=0x55, corresponding to a _PSV threshold 10°C higher than _CRT. All of this could be the BIOS' fault - a table of nonsense values set up incorrectly by Dell. However, I never touched the BIOS since first setting up the machine. The only thing that has changed is FreeBSD, not the BIOS. Could this be some problem in FreeBSD's ACPI implementation? Are the values being read or interpreted wrong? I know manufacturers often provide sloppy, wrong DSDTs. But these values would make even Windows shut down under moderate to high load. That cannot be right. I am happy to debug further if someone could give me pointers where to look. - Bartosz From owner-freebsd-acpi@FreeBSD.ORG Sat Apr 3 04:41:40 2010 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 87229106566B for ; Sat, 3 Apr 2010 04:41:40 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [115.70.110.159]) by mx1.freebsd.org (Postfix) with ESMTP id D90748FC18 for ; Sat, 3 Apr 2010 04:41:39 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id o334fUpT066791; Sat, 3 Apr 2010 15:41:31 +1100 (EST) (envelope-from smithi@nimnet.asn.au) Date: Sat, 3 Apr 2010 15:41:30 +1100 (EST) From: Ian Smith To: Bartosz Fabianowski In-Reply-To: <4BB69279.6060005@chillt.de> Message-ID: <20100403152134.V35463@sola.nimnet.asn.au> References: <4BB69279.6060005@chillt.de> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-1982801494-1270269690=:35463" Cc: freebsd-acpi@freebsd.org Subject: Re: Spurious thermal shutdowns on Dell Studio 1557 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: Sat, 03 Apr 2010 04:41:40 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-1982801494-1270269690=:35463 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT On Sat, 3 Apr 2010, Bartosz Fabianowski wrote: > I have a Dell Studio 1557 laptop. When I first set up the machine in January > 2010, I was able to compile the FreeBSD 8-STABLE base system and 700 ports > without any thermal issues. > > Around mid-February 2010, I updated to a newer 8-STABLE. Since then, the > computer has been shutting down due to "critical temperatures" whenever I run > a CPU-intensive task for more than a few minutes. It is now impossible to > compile Firefox or OpenOffice.org. > > The shutdowns are caused by TZ1, representing the CPU. The relevant sysctl > output is: > > > hw.acpi.thermal.tz1.temperature: 60.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: 95.0C > hw.acpi.thermal.tz1._HOT: -1 > hw.acpi.thermal.tz1._CRT: 85.0C > hw.acpi.thermal.tz1._ACx: 71.0C 55.0C -1 -1 -1 -1 -1 -1 -1 -1 > hw.acpi.thermal.tz1._TC1: 0 > hw.acpi.thermal.tz1._TC2: 10 > hw.acpi.thermal.tz1._TSP: 2 > > > Notice how _PSV=95°C > _CRT=85°C. This looks very fishy to me. At 95°C, the > CPU should start throttling its speed, passively reducing temperature. But > before it gets a chance to do so, the system shuts down due to reaching 85°C. > I can work around this by overriding _CRT, setting it to e.g. 99°C. But this > clearly is a hack. Prior to some change in FreeBSD, I did not experience any > such problems. It certainly seems a strange _CRT value, and silly having it less than _PSV, though it seems unlikely that FreeBSD ACPI would be messing with these values, which you appear to have tracked down correctly. However there may be other reasons the laptop is getting even that hot. You should hear the fan come on at 55C, and run faster at 71C, as active cooling is also on. Is that happening? If the fan is running properly, have you checked that the airways aren't blocked by dust and/or fluff? > I disassembled the DSDT. The threshold values are computed as follows: > > > Method (_PSV, 0, Serialized) > { > Return (Add (0x0AAC, Multiply (PSVT, 0x0A))) > } > > Method (_CRT, 0, Serialized) > { > Return (Add (0x0AAC, Multiply (CRTT, 0x0A))) > } > > > The constants PSVT and CRTT are found in the following memory region: > > > OperationRegion (GNVS, SystemMemory, 0xC779BC9E, 0x0200) > > > Their actual values are PSVT=0x5F and CRTT=0x55, corresponding to a _PSV > threshold 10°C higher than _CRT. Yes, they're 95 and 85 respectively. > All of this could be the BIOS' fault - a table of nonsense values set up > incorrectly by Dell. However, I never touched the BIOS since first setting up > the machine. The only thing that has changed is FreeBSD, not the BIOS. Could > this be some problem in FreeBSD's ACPI implementation? Are the values being > read or interpreted wrong? > > I know manufacturers often provide sloppy, wrong DSDTs. But these values > would make even Windows shut down under moderate to high load. That cannot be > right. > > I am happy to debug further if someone could give me pointers where to look. > > - Bartosz Maybe Dell don't trust non-Windows OS to take care of passive cooling? Could be worth seeing if those values come up the same if you spoof some type of Windows as your OS, as detailed in the ACPI debugging section? cheers, Ian --0-1982801494-1270269690=:35463-- From owner-freebsd-acpi@FreeBSD.ORG Sat Apr 3 05:01:32 2010 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 91689106564A for ; Sat, 3 Apr 2010 05:01:32 +0000 (UTC) (envelope-from freebsd@chillt.de) Received: from dd15624.kasserver.com (dd15624.kasserver.com [85.13.136.215]) by mx1.freebsd.org (Postfix) with ESMTP id 5282F8FC08 for ; Sat, 3 Apr 2010 05:01:32 +0000 (UTC) Received: from taiko.lan (84-203-79-36.mysmart.ie [84.203.79.36]) by dd15624.kasserver.com (Postfix) with ESMTP id D3B8D2C083C43; Sat, 3 Apr 2010 07:01:30 +0200 (CEST) Message-ID: <4BB6CBA5.6090000@chillt.de> Date: Sat, 03 Apr 2010 06:01:25 +0100 From: Bartosz Fabianowski User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.9) Gecko/20100403 Thunderbird/3.0.4 MIME-Version: 1.0 To: Ian Smith References: <4BB69279.6060005@chillt.de> <20100403152134.V35463@sola.nimnet.asn.au> In-Reply-To: <20100403152134.V35463@sola.nimnet.asn.au> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-acpi@freebsd.org Subject: Re: Spurious thermal shutdowns on Dell Studio 1557 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: Sat, 03 Apr 2010 05:01:32 -0000 > You should hear the fan come on at 55C, and run faster at 71C, as > active cooling is also on. Is that happening? Temperature never drops below 55°C and so the fan is always running. As far as memory serves me, this has been the case since day one. I have not noticed any difference in fan noise at different temperature levels. Considering how hot this machine is running, I would not be surprised if the fan was always in its "high" setting. > If the fan is running properly, have you checked that the airways > aren't blocked by dust and/or fluff? The laptop has feet of ~5mm height. I have extended that to about 1cm by placing the computer on four stacks of post-it notes. This, again, has been the case since day one. I added a few more millimeters of post-it notes today and cleaned out any dust I could find. This might have improved things slightly but temperature still exceeds 85°C when compiling larger ports. > Maybe Dell don't trust non-Windows OS to take care of passive > cooling? Could be worth seeing if those values come up the same if > you spoof some type of Windows as your OS, as detailed in the ACPI > debugging section? Yes, this is definitely something I will try. I thought that all the magic would be present in the DSDT. But now that I think about it, of course the BIOS could be changing the values read from the GNVS table based on OS. I will try spoofing Vista or Windows 7 and report back my findings. - Bartosz From owner-freebsd-acpi@FreeBSD.ORG Sat Apr 3 07:42:10 2010 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 9F3B5106564A; Sat, 3 Apr 2010 07:42:10 +0000 (UTC) (envelope-from remko@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 762668FC0A; Sat, 3 Apr 2010 07:42:10 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o337gADS097796; Sat, 3 Apr 2010 07:42:10 GMT (envelope-from remko@freefall.freebsd.org) Received: (from remko@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o337gAoX097792; Sat, 3 Apr 2010 07:42:10 GMT (envelope-from remko) Date: Sat, 3 Apr 2010 07:42:10 GMT Message-Id: <201004030742.o337gAoX097792@freefall.freebsd.org> To: remko@FreeBSD.org, freebsd-i386@FreeBSD.org, freebsd-acpi@FreeBSD.org From: remko@FreeBSD.org Cc: Subject: Re: kern/145306: [acpi]: Can't change brightness on HP ProBook 4510s 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: Sat, 03 Apr 2010 07:42:10 -0000 Old Synopsis: Can't change brightness on HP ProBook 4510s New Synopsis: [acpi]: Can't change brightness on HP ProBook 4510s Responsible-Changed-From-To: freebsd-i386->freebsd-acpi Responsible-Changed-By: remko Responsible-Changed-When: Sat Apr 3 07:41:51 UTC 2010 Responsible-Changed-Why: Assign to ACPI team. http://www.freebsd.org/cgi/query-pr.cgi?pr=145306 From owner-freebsd-acpi@FreeBSD.ORG Sat Apr 3 10:46:51 2010 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 D2581106566B; Sat, 3 Apr 2010 10:46:51 +0000 (UTC) (envelope-from brucec@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id A90F78FC12; Sat, 3 Apr 2010 10:46:51 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o33AkpEO060405; Sat, 3 Apr 2010 10:46:51 GMT (envelope-from brucec@freefall.freebsd.org) Received: (from brucec@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o33Akp3g060401; Sat, 3 Apr 2010 10:46:51 GMT (envelope-from brucec) Date: Sat, 3 Apr 2010 10:46:51 GMT Message-Id: <201004031046.o33Akp3g060401@freefall.freebsd.org> To: alexbestms@math.uni-muenster.de, brucec@FreeBSD.org, freebsd-acpi@FreeBSD.org From: brucec@FreeBSD.org Cc: Subject: Re: kern/136808: [acpi] panic when switching to s3 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: Sat, 03 Apr 2010 10:46:51 -0000 Synopsis: [acpi] panic when switching to s3 State-Changed-From-To: open->closed State-Changed-By: brucec State-Changed-When: Sat Apr 3 10:46:22 UTC 2010 State-Changed-Why: Closed at submitter's request. http://www.freebsd.org/cgi/query-pr.cgi?pr=136808 From owner-freebsd-acpi@FreeBSD.ORG Sat Apr 3 14:08:11 2010 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 49C491065672 for ; Sat, 3 Apr 2010 14:08:11 +0000 (UTC) (envelope-from freebsd@chillt.de) Received: from dd15624.kasserver.com (dd15624.kasserver.com [85.13.136.215]) by mx1.freebsd.org (Postfix) with ESMTP id 0BAA88FC12 for ; Sat, 3 Apr 2010 14:08:10 +0000 (UTC) Received: from taiko.lan (84-203-79-36.mysmart.ie [84.203.79.36]) by dd15624.kasserver.com (Postfix) with ESMTP id 97A452C083C52; Sat, 3 Apr 2010 16:08:09 +0200 (CEST) Message-ID: <4BB74BC4.9070409@chillt.de> Date: Sat, 03 Apr 2010 15:08:04 +0100 From: Bartosz Fabianowski User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.9) Gecko/20100403 Thunderbird/3.0.4 MIME-Version: 1.0 To: Ian Smith References: <4BB69279.6060005@chillt.de> <20100403152134.V35463@sola.nimnet.asn.au> In-Reply-To: <20100403152134.V35463@sola.nimnet.asn.au> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@freebsd.org Subject: Re: Spurious thermal shutdowns on Dell Studio 1557 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: Sat, 03 Apr 2010 14:08:11 -0000 I have tried spoofing Windows Vista - no joy, nothing changes. Overriding the _OS variable had no effect as the DSDT actually checks _OSI. I applied the patch in kern/121504 and overrode _OSI with "Windows 2006". Unfortunately, this had no effect on thermal settings at all. Any other ideas for what to try? - Bartosz From owner-freebsd-acpi@FreeBSD.ORG Sat Apr 3 14:59:31 2010 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 31F06106566B for ; Sat, 3 Apr 2010 14:59:31 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [115.70.110.159]) by mx1.freebsd.org (Postfix) with ESMTP id AA0998FC0C for ; Sat, 3 Apr 2010 14:59:29 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id o33ExLQs095466; Sun, 4 Apr 2010 01:59:22 +1100 (EST) (envelope-from smithi@nimnet.asn.au) Date: Sun, 4 Apr 2010 01:59:21 +1100 (EST) From: Ian Smith To: Bartosz Fabianowski In-Reply-To: <4BB74BC4.9070409@chillt.de> Message-ID: <20100404012906.I35463@sola.nimnet.asn.au> References: <4BB69279.6060005@chillt.de> <20100403152134.V35463@sola.nimnet.asn.au> <4BB74BC4.9070409@chillt.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: freebsd-acpi@freebsd.org Subject: Re: Spurious thermal shutdowns on Dell Studio 1557 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: Sat, 03 Apr 2010 14:59:31 -0000 On Sat, 3 Apr 2010, Bartosz Fabianowski wrote: > I have tried spoofing Windows Vista - no joy, nothing changes. > > Overriding the _OS variable had no effect as the DSDT actually checks _OSI. I > applied the patch in kern/121504 and overrode _OSI with "Windows 2006". > Unfortunately, this had no effect on thermal settings at all. > > Any other ideas for what to try? No, apart from maybe overriding _CRT and/or _PSV, perhaps swapping them? You called changing these a hack, but a hack's fine if it works :) My Thinkpad T23 has 90C _PSV, 96C _CRT, but I've yet to see it hit 90C; the last buildworld got it to about 86C, and that was in our summer. Perhaps see if you can get it to start passive cooling at say 80C, with _CRT set at maybe 90C, to see whether passive cooling handles the load? Apart from feeding it a can of air, hopefully someone else has an idea? cheers, Ian From owner-freebsd-acpi@FreeBSD.ORG Sat Apr 3 15:54:59 2010 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 5ED02106566C for ; Sat, 3 Apr 2010 15:54:59 +0000 (UTC) (envelope-from freebsd@chillt.de) Received: from dd15624.kasserver.com (dd15624.kasserver.com [85.13.136.215]) by mx1.freebsd.org (Postfix) with ESMTP id 02FD08FC12 for ; Sat, 3 Apr 2010 15:54:58 +0000 (UTC) Received: from taiko.lan (84-203-79-36.mysmart.ie [84.203.79.36]) by dd15624.kasserver.com (Postfix) with ESMTP id 475972C083C52; Sat, 3 Apr 2010 17:54:57 +0200 (CEST) Message-ID: <4BB764CC.60500@chillt.de> Date: Sat, 03 Apr 2010 16:54:52 +0100 From: Bartosz Fabianowski User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.9) Gecko/20100403 Thunderbird/3.0.4 MIME-Version: 1.0 To: "Alexandre \"Sunny\" Kovalenko" References: <4BB69279.6060005@chillt.de> <20100403152134.V35463@sola.nimnet.asn.au> <4BB74BC4.9070409@chillt.de> <20100404012906.I35463@sola.nimnet.asn.au> <1270308642.1455.10.camel@RabbitsDen> In-Reply-To: <1270308642.1455.10.camel@RabbitsDen> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-acpi@freebsd.org, Ian Smith Subject: Re: Spurious thermal shutdowns on Dell Studio 1557 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: Sat, 03 Apr 2010 15:54:59 -0000 > I would not override _CRT Intel seem not to have documented the maximal operating temperature for this CPU (Core i7 Q720M). But overclocking enthusiast forums mention automatic throttling from 100°C onward. So while I cannot be sure, I think the CPU should survive just fine with a _CRT of more than 85°C. > Something to the tune of: > > hw.acpi.thermal.tz0.passive_cooling=1 hw.acpi.thermal.user_override=1 > hw.acpi.thermal.tz0._PSV=75C I can do that. But since the CPU is running at ~60°C when completely idle, this will essentially force throttling whenever I do anything that demands a bit of CPU. I bought a quad-core i7 specifically because I want CPU power. Forcing the CPU to throttle all the time would remove any advantage of having bought such an expensive CPU. > * Is tz0 the only thermal zone you have on this machine? All of this is TZ1. TZ0 does exist as well but reports a constant 26.8°C with a _CRT of 127.0°C - not very interesting. > * Are you using 'powerd' and, if so, what are the settings? Yes, powerd is running with default settings. I can see dev.cpu.0.freq going up and down so powerd seems to be working. > * What does 'sysctl dev.cpu' say? As the output is rather long, I put it at the end of this e-mail. > Perennial favorite is to pry off the heatsink, clean and re-apply the > grease in moderation. I am very reluctant to do this. The laptop is barely three months old. As long as it is still under warranty, I really do not want to take it apart. Also, shaving off 3-4°C will not cut it anyway. To prevent the spurious shutdowns without overriding _CRT, I would need the CPU to run at least 10-15°C cooler. - Bartosz Output of sysctl dev.cpu: dev.cpu.0.%desc: ACPI CPU dev.cpu.0.%driver: cpu dev.cpu.0.%location: handle=\_PR_.CPU0 dev.cpu.0.%pnpinfo: _HID=none _UID=0 dev.cpu.0.%parent: acpi0 dev.cpu.0.temperature: 55.0C dev.cpu.0.freq: 1463 dev.cpu.0.freq_levels: 1597/35000 1463/31000 1330/27000 1197/23000 1064/19000 931/15000 814/13125 698/11250 581/9375 465/7500 349/5625 232/3750 116/1875 dev.cpu.0.cx_supported: C1/3 dev.cpu.0.cx_lowest: C1 dev.cpu.0.cx_usage: 100.00% last 500us dev.cpu.1.%desc: ACPI CPU dev.cpu.1.%driver: cpu dev.cpu.1.%location: handle=\_PR_.CPU1 dev.cpu.1.%pnpinfo: _HID=none _UID=0 dev.cpu.1.%parent: acpi0 dev.cpu.1.temperature: 56.0C dev.cpu.1.cx_supported: C1/3 dev.cpu.1.cx_lowest: C1 dev.cpu.1.cx_usage: 100.00% last 500us dev.cpu.2.%desc: ACPI CPU dev.cpu.2.%driver: cpu dev.cpu.2.%location: handle=\_PR_.CPU2 dev.cpu.2.%pnpinfo: _HID=none _UID=0 dev.cpu.2.%parent: acpi0 dev.cpu.2.temperature: 54.0C dev.cpu.2.cx_supported: C1/3 dev.cpu.2.cx_lowest: C1 dev.cpu.2.cx_usage: 100.00% last 500us dev.cpu.3.%desc: ACPI CPU dev.cpu.3.%driver: cpu dev.cpu.3.%location: handle=\_PR_.CPU3 dev.cpu.3.%pnpinfo: _HID=none _UID=0 dev.cpu.3.%parent: acpi0 dev.cpu.3.temperature: 54.0C dev.cpu.3.cx_supported: C1/3 dev.cpu.3.cx_lowest: C1 dev.cpu.3.cx_usage: 100.00% last 500us dev.cpu.4.%desc: ACPI CPU dev.cpu.4.%driver: cpu dev.cpu.4.%location: handle=\_PR_.CPU4 dev.cpu.4.%pnpinfo: _HID=none _UID=0 dev.cpu.4.%parent: acpi0 dev.cpu.4.temperature: 56.0C dev.cpu.4.cx_supported: C1/3 dev.cpu.4.cx_lowest: C1 dev.cpu.4.cx_usage: 100.00% last 500us dev.cpu.5.%desc: ACPI CPU dev.cpu.5.%driver: cpu dev.cpu.5.%location: handle=\_PR_.CPU5 dev.cpu.5.%pnpinfo: _HID=none _UID=0 dev.cpu.5.%parent: acpi0 dev.cpu.5.temperature: 56.0C dev.cpu.5.cx_supported: C1/3 dev.cpu.5.cx_lowest: C1 dev.cpu.5.cx_usage: 100.00% last 500us dev.cpu.6.%desc: ACPI CPU dev.cpu.6.%driver: cpu dev.cpu.6.%location: handle=\_PR_.CPU6 dev.cpu.6.%pnpinfo: _HID=none _UID=0 dev.cpu.6.%parent: acpi0 dev.cpu.6.temperature: 54.0C dev.cpu.6.cx_supported: C1/3 dev.cpu.6.cx_lowest: C1 dev.cpu.6.cx_usage: 100.00% last 500us dev.cpu.7.%desc: ACPI CPU dev.cpu.7.%driver: cpu dev.cpu.7.%location: handle=\_PR_.CPU7 dev.cpu.7.%pnpinfo: _HID=none _UID=0 dev.cpu.7.%parent: acpi0 dev.cpu.7.temperature: 54.0C dev.cpu.7.cx_supported: C1/3 dev.cpu.7.cx_lowest: C1 dev.cpu.7.cx_usage: 100.00% last 500us From owner-freebsd-acpi@FreeBSD.ORG Sat Apr 3 16:19:12 2010 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 7B7FC1065672 for ; Sat, 3 Apr 2010 16:19:12 +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 512958FC17 for ; Sat, 3 Apr 2010 16:19:12 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o33GJBZ0043319 for ; Sat, 3 Apr 2010 16:19:11 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o33GJBHd043318; Sat, 3 Apr 2010 16:19:11 GMT (envelope-from gnats) Date: Sat, 3 Apr 2010 16:19:11 GMT Message-Id: <201004031619.o33GJBHd043318@freefall.freebsd.org> To: freebsd-acpi@FreeBSD.org From: Dan Lukes Cc: Subject: Re: kern/145306: [acpi]: Can't change brightness on HP ProBook 4510s X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Dan Lukes List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Apr 2010 16:19:12 -0000 The following reply was made to PR kern/145306; it has been noted by GNATS. From: Dan Lukes To: bug-followup@FreeBSD.org, demelier.david@gmail.com Cc: Subject: Re: kern/145306: [acpi]: Can't change brightness on HP ProBook 4510s Date: Sat, 03 Apr 2010 10:12:27 +0200 The brightness change part of acpi-video is based on ACPI specification 4.0 paragpraph B.7 Maybe the notebook doesn't support it. The acpidump -dt may help. Also, it's necesarry to compile kernel with ACPI_DEBUG, then setup debug messages in loadr.conf, then check the BIOS will generate the required notifications. Dan From owner-freebsd-acpi@FreeBSD.ORG Sat Apr 3 23:03:28 2010 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 EA38D106566B for ; Sat, 3 Apr 2010 23:03:27 +0000 (UTC) (envelope-from freebsd@chillt.de) Received: from dd15624.kasserver.com (dd15624.kasserver.com [85.13.136.215]) by mx1.freebsd.org (Postfix) with ESMTP id A7A188FC0A for ; Sat, 3 Apr 2010 23:03:27 +0000 (UTC) Received: from taiko.lan (84-203-79-36.mysmart.ie [84.203.79.36]) by dd15624.kasserver.com (Postfix) with ESMTP id 788732C083C43; Sun, 4 Apr 2010 01:03:25 +0200 (CEST) Message-ID: <4BB7C937.9050106@chillt.de> Date: Sun, 04 Apr 2010 00:03:19 +0100 From: Bartosz Fabianowski User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.9) Gecko/20100403 Thunderbird/3.0.4 MIME-Version: 1.0 To: "Alexandre \"Sunny\" Kovalenko" References: <4BB69279.6060005@chillt.de> <20100403152134.V35463@sola.nimnet.asn.au> <4BB74BC4.9070409@chillt.de> <20100404012906.I35463@sola.nimnet.asn.au> <1270308642.1455.10.camel@RabbitsDen> <4BB764CC.60500@chillt.de> <1270334546.1455.45.camel@RabbitsDen> In-Reply-To: <1270334546.1455.45.camel@RabbitsDen> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@freebsd.org, Ian Smith Subject: Re: Spurious thermal shutdowns on Dell Studio 1557 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: Sat, 03 Apr 2010 23:03:28 -0000 > you would like to be able use this machine to full extent and keep > temperature below the critical shutdown level. Ideally, yes. I do not need much CPU power throughout most of the day. But when a larger update comes along and it is time to rebuild say OpenOffice.org, I would really like to exercise the CPU to its fullest. This is why I bought it after all. > [snip] > > The latter will ensure that your fan will run at highest setting for > at least 2 minutes, even if temperature drops below 71C. Very interesting tips. I will experiment with different settings and see whether I can make the machine run cooler. A very low-tech solution I am planning to apply later tonight is to hoover all air vents. Even though the machine is very new, there might be some dust stuck somewhere. > If this is not sufficient, you can also modify your ASL I did think of that. Unfortunately, the ASL produced by acpidump -d does not recompile, producing over 200 errors. They all have to do with references to a non-existent table. I will probably be able to solve them all by fixing a single typo somewhere. Again something I will look into for sure. > If you go this route, I would strongly recommend reading thermal > chapter of the ACPI spec -- it is short, well written and contains > well-commented example. I have the ACPI spec here - will have a look at that chapter, thanks. > please, understand that this route is more then moderately dangerous > and could cause harm to your system. Yes, I am aware of that. Then again, I have a system that out-of-the-box is running way too hot. If I just ignore the issue, the system may harm itself. Trying to do something about it IMHO is the better way. > If all of the above fails, I would dare say that your system was not > designed to withstand the use you have intended for it and you will > need to resort to hardware modifications (more powerful fan, case > fan, water cooling, etc.). Case fan, water cooling - now that will make for one interesting laptop :). Having read various forums, I am beginning to think the system was really not designed to handle its CPU's thermal requirements. Apparently Dell has a questionable track record when it comes to thermal design. Still, I paid for a piece of hardware and now I expect to use it. Granted, this machine might have been built to run under Windows. But the fan control settings and thermal thresholds would all be the same there. So even with the supplied OS, the machine would be running too hot and shutting down. This is clearly not acceptable. I think I will contact Dell support and see what they can do for me. Of course, first-level support is just there to read off scripts... I might have a difficult time getting through to someone who actually understands the issue. - Bartosz