From owner-freebsd-acpi@FreeBSD.ORG Mon May 11 06:13: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 BC8F11065672; Mon, 11 May 2009 06:13:59 +0000 (UTC) (envelope-from kientzle@freebsd.org) Received: from kientzle.com (kientzle.com [66.166.149.50]) by mx1.freebsd.org (Postfix) with ESMTP id 8C9258FC0A; Mon, 11 May 2009 06:13:59 +0000 (UTC) (envelope-from kientzle@freebsd.org) Received: (from root@localhost) by kientzle.com (8.14.3/8.14.3) id n4B5n1UB053816; Sun, 10 May 2009 22:49:01 -0700 (PDT) (envelope-from kientzle@freebsd.org) Received: from dark.x.kientzle.com (fw2.kientzle.com [10.123.1.2]) by kientzle.com with SMTP id uc8j7saqsugxnw4y76kruznc3i; Sun, 10 May 2009 22:49:01 -0700 (PDT) (envelope-from kientzle@freebsd.org) Message-ID: <4A07BC4D.7080604@freebsd.org> Date: Sun, 10 May 2009 22:49:01 -0700 From: Tim Kientzle User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.8.1.21) Gecko/20090409 SeaMonkey/1.1.15 MIME-Version: 1.0 To: Alexander Motin References: <49FE1826.4060000@FreeBSD.org> In-Reply-To: <49FE1826.4060000@FreeBSD.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD acpi , FreeBSD-Current , freebsd-mobile@freebsd.org Subject: Re: Fighting for the power. 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, 11 May 2009 06:14:00 -0000 Alexander Motin wrote: > I would like to summarize some of my knowledge on reducing FreeBSD power > consumption and describe some new things I have recently implemented in > 8-CURRENT. ... This is great work! > - C3 state allows CPU completely stop all internal clocks, reduce > voltage and disconnect from system bus. This state gives additional > power saving effect, but .... local APIC timers in > each CPU core, used by FreeBSD as event sources on SMP, are not > functioning. ... Originally, before SMP era, FreeBSD used i8254 (for HZ) > and RTC (for stats) chipset timers. I have made changes to 8-CURRENT to > resurrect them for SMP systems. To use them, you can disable local APIC > timers by adding to /boot/loader.conf: > hint.apic.0.clock=0 I experimented a little bit with this and had a few odd experiences: sysctl hw.acpi.cpu.cx_lowest=C3 did drop power consumption significantly but made the system pretty unresponsive. In particular, the system completely hung at shutdown. I presume the hang was the APIC timer problem you mentioned. I started to try the "hint.apic.0.clock", but noticed in your commit r191720: > Add hint.apic.0.clock tunable. Setting it 0 disables using > LAPIC timers as hard-/stat-/profclock sources falling back > to using i8254 and rtc timers. > ... > This technique is not working for SMP yet, as only one CPU > receives timer interrupts. But I think that problem could > be fixed by forwarding interrupts to other CPUs with IPI. Is anyone looking at this yet? Tim From owner-freebsd-acpi@FreeBSD.ORG Mon May 11 11:06:48 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 063B21065672 for ; Mon, 11 May 2009 11:06:48 +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 E76398FC22 for ; Mon, 11 May 2009 11:06:47 +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 n4BB6l2Q085842 for ; Mon, 11 May 2009 11:06:47 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n4BB6lH9085838 for freebsd-acpi@FreeBSD.org; Mon, 11 May 2009 11:06:47 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 11 May 2009 11:06:47 GMT Message-Id: <200905111106.n4BB6lH9085838@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, 11 May 2009 11:06:48 -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/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 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 46 problems total. From owner-freebsd-acpi@FreeBSD.ORG Mon May 11 12:22: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 86ED2106564A; Mon, 11 May 2009 12:22:10 +0000 (UTC) (envelope-from mav@FreeBSD.org) Received: from cmail.optima.ua (cmail.optima.ua [195.248.191.121]) by mx1.freebsd.org (Postfix) with ESMTP id 9F7958FC20; Mon, 11 May 2009 12:22:09 +0000 (UTC) (envelope-from mav@FreeBSD.org) X-Spam-Flag: SKIP X-Spam-Yversion: Spamooborona-2.1.0 Received: from [212.86.226.11] (account mav@alkar.net HELO mavbook.mavhome.dp.ua) by cmail.optima.ua (CommuniGate Pro SMTP 5.2.9) with ESMTPSA id 242430880; Mon, 11 May 2009 15:22:08 +0300 Message-ID: <4A081868.6010906@FreeBSD.org> Date: Mon, 11 May 2009 15:22:00 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.21 (X11/20090405) MIME-Version: 1.0 To: Tim Kientzle References: <49FE1826.4060000@FreeBSD.org> <4A07BC4D.7080604@freebsd.org> In-Reply-To: <4A07BC4D.7080604@freebsd.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD acpi , FreeBSD-Current , freebsd-mobile@freebsd.org Subject: Re: Fighting for the power. 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, 11 May 2009 12:22:11 -0000 Tim Kientzle wrote: > I started to try the "hint.apic.0.clock", but noticed > in your commit r191720: > Alexander Motin wrote: >> Add hint.apic.0.clock tunable. Setting it 0 disables using >> LAPIC timers as hard-/stat-/profclock sources falling back >> to using i8254 and rtc timers. >> ... >> This technique is not working for SMP yet, as only one CPU >> receives timer interrupts. But I think that problem could >> be fixed by forwarding interrupts to other CPUs with IPI. > > Is anyone looking at this yet? I have implemented SMP support for i386 and amd64 in some of my later commits. -- Alexander Motin From owner-freebsd-acpi@FreeBSD.ORG Mon May 11 16:49:38 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 BE2671065670; Mon, 11 May 2009 16:49:38 +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 8F4FC8FC1A; Mon, 11 May 2009 16:49:38 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 421B546B2E; Mon, 11 May 2009 12:49:38 -0400 (EDT) Received: from jhbbsd.hudson-trading.com (unknown [209.249.190.8]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 01E8E8A025; Mon, 11 May 2009 12:49:37 -0400 (EDT) From: John Baldwin To: Jung-uk Kim Date: Mon, 11 May 2009 09:52:01 -0400 User-Agent: KMail/1.9.7 References: <49F8B859.7060908@umn.edu> <200905051609.38689.jkim@FreeBSD.org> <200905051743.03520.jkim@FreeBSD.org> In-Reply-To: <200905051743.03520.jkim@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200905110952.01736.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Mon, 11 May 2009 12:49:37 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=4.2 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: Alan Amesbury , freebsd-acpi@freebsd.org, freebsd-stable@freebsd.org, Andriy Gapon Subject: Re: Garbled output from kgdb? 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, 11 May 2009 16:49:39 -0000 On Tuesday 05 May 2009 5:43:01 pm Jung-uk Kim wrote: > On Tuesday 05 May 2009 04:09 pm, Jung-uk Kim wrote: > > On Tuesday 05 May 2009 12:51 pm, Andriy Gapon wrote: > > > BTW, this issue seems to be fixed in Jung-uk's acpi patches for > > > newer acpica imports, but it is not fixed both in stable/7 and > > > head. > > > > Yes, it was fixed in my patchsets long ago, which uses spin lock > > for AcpiOsAcquireLock(). :-) > > The attached patch is for -STABLE. Note that it is only compile > tested on amd64. This looks fine to test. The patch has gratuitous style changes I wouldn't include in a commit though. -- John Baldwin From owner-freebsd-acpi@FreeBSD.ORG Mon May 11 17:45:41 2009 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 5EB5D1065673; Mon, 11 May 2009 17:45:41 +0000 (UTC) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: John Baldwin Date: Mon, 11 May 2009 13:44:59 -0400 User-Agent: KMail/1.6.2 References: <49F8B859.7060908@umn.edu> <200905051743.03520.jkim@FreeBSD.org> <200905110952.01736.jhb@freebsd.org> In-Reply-To: <200905110952.01736.jhb@freebsd.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200905111345.29761.jkim@FreeBSD.org> Cc: Alan Amesbury , freebsd-acpi@freebsd.org, freebsd-stable@freebsd.org, Andriy Gapon Subject: Re: Garbled output from kgdb? 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, 11 May 2009 17:45:42 -0000 On Monday 11 May 2009 09:52 am, John Baldwin wrote: > On Tuesday 05 May 2009 5:43:01 pm Jung-uk Kim wrote: > > On Tuesday 05 May 2009 04:09 pm, Jung-uk Kim wrote: > > > On Tuesday 05 May 2009 12:51 pm, Andriy Gapon wrote: > > > > BTW, this issue seems to be fixed in Jung-uk's acpi patches > > > > for newer acpica imports, but it is not fixed both in > > > > stable/7 and head. > > > > > > Yes, it was fixed in my patchsets long ago, which uses spin > > > lock for AcpiOsAcquireLock(). :-) > > > > The attached patch is for -STABLE. Note that it is only compile > > tested on amd64. > > This looks fine to test. The patch has gratuitous style changes I > wouldn't include in a commit though. It should work but I don't plan to commit it any time soon. :-) In fact, the patch was meant to be a rewrite for new ACPI-CA, which actually has a real mutex. Currently, mutex is emulated with semaphore. The problem is semaphore has no concept of ownership while mutex does, i.e., any thread can acquire/release it without checking its ownership or order. FYI, the OSL API (ACPI_MUTEX_TYPE) is finalized in ACPI-CA 20081204. Jung-uk Kim From owner-freebsd-acpi@FreeBSD.ORG Mon May 11 18:25: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 6E64F1065674; Mon, 11 May 2009 18:25:13 +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 17EA58FC15; Mon, 11 May 2009 18:25:13 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 9ACCD46B8D; Mon, 11 May 2009 14:25:12 -0400 (EDT) Received: from jhbbsd.hudson-trading.com (unknown [209.249.190.8]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 4ED2F8A025; Mon, 11 May 2009 14:25:11 -0400 (EDT) From: John Baldwin To: freebsd-acpi@freebsd.org Date: Mon, 11 May 2009 14:25:01 -0400 User-Agent: KMail/1.9.7 References: <43b1bb350904230622u4b7790f0p9f665b649c97a3b@mail.gmail.com> <200905011450.13899.jhb@freebsd.org> <43b1bb350905011230p1372e1ffw5ab61985e7672e19@mail.gmail.com> In-Reply-To: <43b1bb350905011230p1372e1ffw5ab61985e7672e19@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200905111425.01887.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Mon, 11 May 2009 14:25:11 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=4.2 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: Alexander Motin Subject: Re: Fwd: Kernel panic on 7.2-RC1 when booting with ACPI enabled kernel. 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, 11 May 2009 18:25:13 -0000 On Friday 01 May 2009 3:30:28 pm Magnus Kling wrote: > 2009/5/1 John Baldwin >=20 > > On Friday 01 May 2009 2:30:28 pm Magnus Kling wrote: > > > 2009/4/30 John Baldwin > > > > > > > On Saturday 25 April 2009 6:27:23 am Magnus Kling wrote: > > > > > 2009/4/24 John Baldwin > > > > > > Can you do 'frame 10' followed by 'p *(struct acpi_pci_devinfo > > > > > > *)child->ivars' > > > > > > > > > > > > -- > > > > > > John Baldwin > > > > > > > > > > > > > > > Sure, no problem. This is a none critical server so I can do alot= of > > > > > debugging and testing if that is needed. > > > > > > > > > > > > > > > (kgdb) frame 10 > > > > > #10 0xc0db4ca8 in acpi_pci_child_location_str_method > > (cbdev=3D0xc2212680, > > > > > child=3D0xc2243400, buf=3D0xc22c2400 "slot=3D0 function=3D0 h= andle=3D", > > > > > buflen=3D1024) > > > > > at > > /usr/src/sys/modules/acpi/acpi/../../../dev/acpica/acpi_pci.c:150 > > > > > 150 strlcat(buf, acpi_name(dinfo->ap_handle), buflen); > > > > > > > > > > (kgdb) p *(struct acpi_pci_devinfo *)child->ivars > > > > > $1 =3D {ap_dinfo =3D {pci_links =3D {stqe_next =3D 0xc0b00f8c}, r= esources =3D { > > > > > stqh_first =3D 0xc0b00f8c, stqh_last =3D 0x1030000}, cfg = =3D {dev =3D > > 0x0, > > > > > bar =3D {4, 0, 0, 3257136600, 0, 0}, bios =3D 0, subvendor = =3D 0, > > > > > subdevice =3D 0, vendor =3D 0, device =3D 0, cmdreg =3D 0, = statreg =3D 0, > > > > > baseclass =3D 0 '\0', subclass =3D 0 '\0', progif =3D 0 '\0= ', revid =3D > > 0 > > > > > > > > Hmm, this is all completely wrong and trashed. What if you do 'p > > *child'? > > > > > > > > -- > > > > John Baldwin > > > > > > > (kgdb) p *child > > > $2 =3D {ops =3D 0xc2161800, link =3D {tqe_next =3D 0xc2243380, tqe_pr= ev =3D > > > 0xc2243484}, devlink =3D {tqe_next =3D 0xc2243380, tqe_prev =3D 0xc22= 4348c}, > > > parent =3D 0xc2212680, children =3D {tqh_first =3D 0xc2262880, tqh_= last =3D > > > 0xc2262704}, driver =3D 0xc0b7066c, devclass =3D 0xc211e240, unit =3D= 0, > > > nameunit =3D 0xc2241640 "atapci0", desc =3D 0xc223f900 "Promise PDC= 20621 > > > UDMA100 controller", busy =3D 0, state =3D DS_ATTACHED, devflags =3D = 0, > > > flags =3D 13, order =3D 0 '\0', pad =3D 0 '\0', ivars =3D 0xc223f5c= 0, softc =3D > > > 0xc2244800, sysctl_ctx =3D {tqh_first =3D 0xc2264380, tqh_last =3D 0x= c2241594}, > > > sysctl_tree =3D 0xc223f840} > > > (kgdb) > > > > Maybe try adding KTR traces for all calls to device_set_ivars(). I won= der > > if > > something is trashing this device's ivars. > > > > Oh, dear. The ata(4) driver overwrites the ivars of some PCI devices it > > attaches to. This is very, very wrong. Which ATA controller do you ha= ve? > > > > -- > > John Baldwin > > >=20 > Aha, I=B4m using a Promise Fasttrack SX4000 for a RAID1 setup. And the one > included on the motherboard for the OS. > And yes, I can confirm that without the Fasttrack SX4000 the system boots= up > correctly. (Pulled out the card and edited fstab.) > So you are right regarding that the ata driver messes something up. Do you > contact someone that is responsible for ata driver? >=20 > Thank you for taking the time to "correct" this, Can you please try this patch? =2D-- //depot/vendor/freebsd/src/sys/dev/ata/ata-pci.h 2009/03/30 22:20:14 +++ //depot/user/jhb/acpipci/dev/ata/ata-pci.h 2009/05/08 20:27:43 @@ -66,6 +66,7 @@ void (*function)(void *); void *argument; } interrupt[8]; /* XXX SOS max ch# for now */ + void *chipset_data; }; =20 /* defines for known chipset PCI id's */ =2D-- //depot/vendor/freebsd/src/sys/dev/ata/chipsets/ata-acard.c 2009/02/1= 9 00:35:16 +++ //depot/user/jhb/acpipci/dev/ata/chipsets/ata-acard.c 2009/05/08 20:27:= 43 @@ -51,6 +51,12 @@ #include #include =20 +struct ata_serialize { + struct mtx locked_mtx; + int locked_ch; + int restart_ch; +}; + /* local prototypes */ static int ata_acard_chipinit(device_t dev); static int ata_acard_ch_attach(device_t dev); @@ -58,6 +64,7 @@ static void ata_acard_850_setmode(device_t dev, int mode); static void ata_acard_86X_setmode(device_t dev, int mode); static int ata_serialize(device_t dev, int flags); +static void ata_serialize_init(struct ata_serialize *serial); =20 /* misc defines */ #define ATP_OLD 1 @@ -93,6 +100,7 @@ ata_acard_chipinit(device_t dev) { struct ata_pci_controller *ctlr =3D device_get_softc(dev); + struct ata_serialize *serial; =20 if (ata_setup_interrupt(dev, ata_generic_intr)) return ENXIO; @@ -100,8 +108,12 @@ ctlr->ch_attach =3D ata_acard_ch_attach; ctlr->ch_detach =3D ata_pci_ch_detach; if (ctlr->chip->cfg1 =3D=3D ATP_OLD) { =2D ctlr->setmode =3D ata_acard_850_setmode; + ctlr->setmode =3D ata_acard_850_setmode;=09 ctlr->locking =3D ata_serialize; + serial =3D malloc(sizeof(struct ata_serialize), + M_TEMP, M_WAITOK | M_ZERO); + ata_serialize_init(serial); + ctlr->chipset_data =3D serial; } else ctlr->setmode =3D ata_acard_86X_setmode; @@ -225,11 +237,14 @@ /* we could set PIO mode timings, but we assume the BIOS did that */ } =20 =2Dstruct ata_serialize { =2D struct mtx locked_mtx; =2D int locked_ch; =2D int restart_ch; =2D}; +static void +ata_serialize_init(struct ata_serialize *serial) +{ + + mtx_init(&serial->locked_mtx, "ATA serialize lock", NULL, MTX_DEF);=20 + serial->locked_ch =3D -1; + serial->restart_ch =3D -1; +} =20 static int ata_serialize(device_t dev, int flags) @@ -237,20 +252,9 @@ struct ata_pci_controller *ctlr =3D device_get_softc(device_get_parent= (dev)); struct ata_channel *ch =3D device_get_softc(dev); struct ata_serialize *serial; =2D static int inited =3D 0; int res; =20 =2D if (!inited) { =2D serial =3D malloc(sizeof(struct ata_serialize), =2D M_TEMP, M_NOWAIT | M_ZERO); =2D mtx_init(&serial->locked_mtx, "ATA serialize lock", NULL, MTX_DEF);=20 =2D serial->locked_ch =3D -1; =2D serial->restart_ch =3D -1; =2D device_set_ivars(ctlr->dev, serial); =2D inited =3D 1; =2D } =2D else =2D serial =3D device_get_ivars(ctlr->dev); + serial =3D ctlr->chipset_data; =20 mtx_lock(&serial->locked_mtx); switch (flags) { =2D-- //depot/vendor/freebsd/src/sys/dev/ata/chipsets/ata-promise.c 2009/03= /30 22:20:14 +++ //depot/user/jhb/acpipci/dev/ata/chipsets/ata-promise.c 2009/05/08 20:2= 7:43 @@ -283,7 +283,7 @@ mtx_init(&hpkt->mtx, "ATA promise HPKT lock", NULL, MTX_DEF); TAILQ_INIT(&hpkt->queue); hpkt->busy =3D 0; =2D device_set_ivars(dev, hpkt); + ctlr->chipset_data =3D hpkt; ctlr->ch_attach =3D ata_promise_mio_ch_attach; ctlr->ch_detach =3D ata_promise_mio_ch_detach; ctlr->reset =3D ata_promise_mio_reset; @@ -730,7 +730,7 @@ case PR_SX4X: =20 /* softreset channel ATA module */ =2D hpktp =3D device_get_ivars(ctlr->dev); + hpktp =3D ctlr->chipset_data; ATA_OUTL(ctlr->r_res2, 0xc0260 + (ch->unit << 7), ch->unit + 1); ata_udelay(1000); ATA_OUTL(ctlr->r_res2, 0xc0260 + (ch->unit << 7), @@ -1208,7 +1208,7 @@ static void ata_promise_queue_hpkt(struct ata_pci_controller *ctlr, u_int32_t hpkt) { =2D struct ata_promise_sx4 *hpktp =3D device_get_ivars(ctlr->dev); + struct ata_promise_sx4 *hpktp =3D ctlr->chipset_data; =20 mtx_lock(&hpktp->mtx); if (hpktp->busy) { @@ -1227,7 +1227,7 @@ static void ata_promise_next_hpkt(struct ata_pci_controller *ctlr) { =2D struct ata_promise_sx4 *hpktp =3D device_get_ivars(ctlr->dev); + struct ata_promise_sx4 *hpktp =3D ctlr->chipset_data; struct host_packet *hp; =20 mtx_lock(&hpktp->mtx); =2D-=20 John Baldwin From owner-freebsd-acpi@FreeBSD.ORG Mon May 11 19:01: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 BBCED106566C for ; Mon, 11 May 2009 19:01:43 +0000 (UTC) (envelope-from ivakras1@gmail.com) Received: from mu-out-0910.google.com (mu-out-0910.google.com [209.85.134.190]) by mx1.freebsd.org (Postfix) with ESMTP id 0B0E18FC17 for ; Mon, 11 May 2009 19:01:42 +0000 (UTC) (envelope-from ivakras1@gmail.com) Received: by mu-out-0910.google.com with SMTP id w9so1328998mue.3 for ; Mon, 11 May 2009 12:01:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:reply-to:organization:to :subject:date:user-agent:references:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :message-id; bh=5tjV/4dfMMr0xhd3jhqEvQqXOvtBUV73imSrG9ks/KE=; b=gVcX5QNmTkWZ0hl07YpXhSTUWX0Ug0fP9Fp8olhGsKjW/3EPDQLXRsX0jdqUlVFt7E TxGf5kKSTaH11T90QC2Izvycul5BxxPERIvaGm/dQjh4sUbmN9Kb5ySaBv57Tdud2dKj H9aCfz6yngP7MWmLN/YG/DywAcuehHqh2C3B4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:reply-to:organization:to:subject:date:user-agent:references :in-reply-to:mime-version:content-type:content-transfer-encoding :content-disposition:message-id; b=uFzAkLyw+tUFc69jhJeURCgJW/mnz1mUNthwhPfgH7UqGn5N9+Ny3k6rchvOT1eyIe gEwCYgZ0NRXQCbDA/MokO7mNNQGXcqy0mxI5kVopVJVHA9J+YHKXHLEVu5aKmNG0RA40 tjJ5hfIKWjWxcHcmATkWT/DSO5ajMyn/VRytw= Received: by 10.103.165.18 with SMTP id s18mr4386747muo.124.1242068501890; Mon, 11 May 2009 12:01:41 -0700 (PDT) Received: from onyx_hp.dhcp.loc ([92.50.244.69]) by mx.google.com with ESMTPS id j9sm5153848mue.21.2009.05.11.12.01.39 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 11 May 2009 12:01:40 -0700 (PDT) From: Dmitry Kolosov Organization: Home To: freebsd-acpi@freebsd.org Date: Mon, 11 May 2009 22:59:13 +0400 User-Agent: KMail/1.11.3 (FreeBSD/7.2-STABLE; KDE/4.2.3; i386; ; ) References: <49FE1826.4060000@FreeBSD.org> In-Reply-To: <49FE1826.4060000@FreeBSD.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="koi8-r" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200905112259.14233.ivakras1@gmail.com> Subject: Re: Fighting for the power. X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ivakras1@gmail.com List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 May 2009 19:01:44 -0000 =F0=CF=CE=C5=C4=C5=CC=D8=CE=C9=CB 04 =CD=C1=D1 2009 02:18:14 Alexander Moti= n =D0=C9=D3=C1=CC=C9: > I would like to summarize some of my knowledge on reducing FreeBSD power > consumption and describe some new things I have recently implemented in > 8-CURRENT. The main character of this story is my 12" Acer TravelMate > 6292 laptop with C2D T7700 2.4GHz CPU, 965GM chipset and SATA HDD, under > amd64 8-CURRENT. >=20 > Modern systems, especially laptops, are implementing big number of=20 > power-saving technologies. Some of them are working automatically, other= =20 > have significant requirements and need special system tuning or=20 > trade-offs to be effectively used. >=20 > So here is the steps: >=20 > 1. CPU > CPU is the most consuming part of the system. Under the full load it > alone may consume more then 40W of power, but for real laptop usage the > most important is idle consumption. > Core2Duo T7700 CPU has 2 cores, runs on 2.4GHz frequency, supports EIST > technology with P-states at 2400, 2000, 1600, 1200 and 800MHz levels, > supports C1, C2 and C3 idle C-states, plus throttling. So how can we use = it: > P-states and throttling > Enabling powerd allows to effectively control CPU frequency/voltage > depending on CPU load. powerd on recent system can handle it quite > transparently. By default, frequency controlled via mix of EIST and > throttling technologies. First one controls both core frequency and > voltage, second - only core frequency. Both technologies give positive > power-saving effect. But effect of throttling is small and can be > completely hidden by using C2 state, that's why I recommend to disable > throttling control by adding to /boot/loader.conf: > hint.p4tcc.0.disabled=3D1 > hint.acpi_throttle.0.disabled=3D1 > In my case frequency/voltage control saves about 5W of idle power. > C-states > - C1 stops clock on some parts of CPU core during inactivity. It is > safe, cheap and supported by CPUs for ages. System uses C1 state by defau= lt. > - C2 state allows CPU to turn off all core clocks on idle. It is also > cheap, but requires correct ACPI-chipset-CPU interoperation to be used. > Use of C2 state can be enabled by adding to /etc/rc.conf: > performance_cx_lowest=3D"C2" > economy_cx_lowest=3D"C2" > Effect from this state is not so big when powerd is used, but still > noticeable, > - C3 state allows CPU completely stop all internal clocks, reduce > voltage and disconnect from system bus. This state gives additional > power saving effect, but it is not cheap and require trade-offs. > As soon as CPU is completely stopped in C3 state, local APIC timers in > each CPU core, used by FreeBSD as event sources on SMP, are not > functioning. It stops system time, breaks scheduling that makes system > close to dead. The only solution for this problem is to use some > external timers. Originally, before SMP era, FreeBSD used i8254 (for HZ) > and RTC (for stats) chipset timers. I have made changes to 8-CURRENT to > resurrect them for SMP systems. To use them, you can disable local APIC > timers by adding to /boot/loader.conf: > hint.apic.0.clock=3D0 > Also, to drop/rise voltage on C3, CPU needs time (57us for my system). > It means that C3 state can't be effectively used when system is waking > up often. To increase inactivity periods we should reduce interrupt rate > as much as possible by adding to loader.conf: > kern.hz=3D100 > It may increase system response time a bit, but it is not significant > for laptop. Also we may avoid additional 128 interrupts per second per > core, by the cost of scheduling precision, with using i8254 timer also > for statistic collection purposes instead of RTC clock, by using another > newly added option: > hint.atrtc.0.clock=3D0 > As result, system has only 100 interrupts per core and CPUs are using C3 > with high efficiency: > %sysctl dev.cpu |grep cx > dev.cpu.0.cx_supported: C1/1 C2/1 C3/57 > dev.cpu.0.cx_lowest: C3 > dev.cpu.0.cx_usage: 0.00% 0.00% 100.00% last 7150us > dev.cpu.1.cx_supported: C1/1 C2/1 C3/57 > dev.cpu.1.cx_lowest: C3 > dev.cpu.1.cx_usage: 0.00% 0.00% 100.00% last 2235us > Result of effective C3 state usage, comparing to C2+powerd, is about 2W. >=20 > 2. PCI devices > PCI bus provides method to control device power. For example, I have > completely no use for my FireWire controller and most of time - EHCI USB > controller. Disabling them allows me to save about 3W of power. To > disable all unneeded PCI devices you should build kernel without their > drivers and add to loader.conf: > hw.pci.do_power_nodriver=3D3 > To enable devices back all you need to do is just load their drivers as > modules. >=20 > 3. Radios > WiFi and Bluetooth adapters can consume significant power when used (up > to 2W when my iwn WiFi is connected) or just enabled (0.5W). Disabling > them with mechanical switch on laptop case saves energy even when they > are not connected. >=20 > 4. HDA modem > I was surprised, but integrated HDA modem consumed about 1W of power > even when not used. I have used the most radical solution - removed it > mechanically from socket. Case surface in that area become much cooler. >=20 > 5. HDA sound > To reduce number of sound generated interrupts I have added to the > loader.conf: > hint.pcm.0.buffersize=3D65536 > hint.pcm.1.buffersize=3D65536 > hw.snd.feeder_buffersize=3D65536 > hw.snd.latency=3D7 >=20 > 6. HDD > First common recommendation is use tmpfs for temporary files. RAM is > cheap, fast and anyway with you. > Also you may try to setup automatic idle drive spin-down, but if it is > the only system drive you should be careful, as every spin-up reduces > drive's life time. > For several months (until I have bought SATA SSD) I have successfully > used SDHC card in built-in PCI sdhci card reader as main filesystem. On > random read requests it is much faster then HDD, but it is very slow on > random write. Same time it consumes almost nothing. USB drives could > also be used, but effect is much less as EHCI USB controller consumes > much power. > Spinning-down my 2.5" Hitachi SATA HDD saves about 1W of power. Removing > it completely saves 2W. >=20 > 7. SATA > Comparing to PATA, SATA interface uses differential signaling for data > transfer. To work properly it has to transmit pseudo-random scrambled > sequence even when idle. As you understand, that requires power. But > SATA implements two power saving modes: PARTIAL and SLUMBER. These modes > could be activated by either host or device if both sides support them. > PARTIAL mode just stops scrambling, but keeps neutral link state, resume > time is 50-100us. SLUMBER mode powers down interface completely, but > respective resume time is 3-10ms. > I have added minimal SATA power management to AHCI driver. There are > hint.ata.X.pm_level loader tunables can be used to control it now. > Setting it to 1 allows drive itself to initiate power saving, when it > wish. Values 2 and 3 make AHCI controller to initiate PARTIAL and > SLUMBER transitions after every command completion. > Note that SATA power saving is not compatible with drive hot-swap, as > controller unable to detect drive presence when link is powered-down. > In my case PARTIAL mode saves 0.5W and SLUMBER - 0.8W of power. >=20 > So what have I got? To monitor real system power consumption I am using > information provided by ACPI battery via `acpiconf -i0` command: >=20 > Original system: > Design capacity: 4800 mAh > Last full capacity: 4190 mAh > Technology: secondary (rechargeable) > Design voltage: 11100 mV > Capacity (warn): 300 mAh > Capacity (low): 167 mAh > Low/warn granularity: 32 mAh > Warn/full granularity: 32 mAh > Model number: Victoria > Serial number: 292 > Type: LION > OEM info: SIMPLO > State: discharging > Remaining capacity: 93% > Remaining time: 2:24 > Present rate: 1621 mA > Voltage: 12033 mV >=20 > Tuned system: > %acpiconf -i0 > Design capacity: 4800 mAh > Last full capacity: 4190 mAh > Technology: secondary (rechargeable) > Design voltage: 11100 mV > Capacity (warn): 300 mAh > Capacity (low): 167 mAh > Low/warn granularity: 32 mAh > Warn/full granularity: 32 mAh > Model number: Victoria > Serial number: 292 > Type: LION > OEM info: SIMPLO > State: discharging > Remaining capacity: 94% > Remaining time: 4:47 > Present rate: 826 mA > Voltage: 12231 mV >=20 > So I have really doubled my on-battery time by this tuning - 4:47 hours=20 > instead of 2:24 with default settings. Preinstalled vendor-tuned Windows= =20 > XP on the same system, provides maximum 3:20 hours. >=20 My EC does not present rate and time info: 10:49pm][/home/onyx# acpiconf -i0 Design capacity: 6000 mAh Last full capacity: 3328 mAh Technology: secondary (rechargeable) Design voltage: 14800 mV Capacity (warn): 172 mAh Capacity (low): 104 mAh Low/warn granularity: 10 mAh Warn/full granularity: 25 mAh Model number: Primary Serial number: =20 Type: LION OEM info: Hewlett-Packard State: high=20 Remaining capacity: 100% Remaining time: unknown Present rate: unknown Voltage: 12522 mV Where to dig? I'm realy need at least 'present rate' to fight for the power= =2E. Also it is an error in capacity detection, i think. Any ideas? From owner-freebsd-acpi@FreeBSD.ORG Mon May 11 19:13: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 400971065674 for ; Mon, 11 May 2009 19:13:11 +0000 (UTC) (envelope-from oberman@es.net) Received: from mailgw.es.net (mail3.es.net [IPv6:2001:400:4c01::2]) by mx1.freebsd.org (Postfix) with ESMTP id 0B55B8FC22 for ; Mon, 11 May 2009 19:13:11 +0000 (UTC) (envelope-from oberman@es.net) Received: from ptavv.es.net (ptavv.es.net [IPv6:2001:400:910::29]) by mailgw.es.net (8.14.3/8.14.3) with ESMTP id n4BJD9vS019246 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 11 May 2009 12:13:10 -0700 Received: from ptavv.es.net (ptavv.es.net [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id 79F0E1CC0B; Mon, 11 May 2009 12:13:09 -0700 (PDT) To: ivakras1@gmail.com In-reply-to: Your message of "Mon, 11 May 2009 22:59:13 +0400." <200905112259.14233.ivakras1@gmail.com> Date: Mon, 11 May 2009 12:13:09 -0700 From: "Kevin Oberman" Message-Id: <20090511191309.79F0E1CC0B@ptavv.es.net> Cc: freebsd-acpi@freebsd.org Subject: Re: Fighting for the power. 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, 11 May 2009 19:13:11 -0000 > From: Dmitry Kolosov > Date: Mon, 11 May 2009 22:59:13 +0400 > Sender: owner-freebsd-acpi@freebsd.org > > 04 2009 02:18:14 Alexander Motin : > > I would like to summarize some of my knowledge on reducing FreeBSD power > > consumption and describe some new things I have recently implemented in > > 8-CURRENT. The main character of this story is my 12" Acer TravelMate > > 6292 laptop with C2D T7700 2.4GHz CPU, 965GM chipset and SATA HDD, under > > amd64 8-CURRENT. > > > > Modern systems, especially laptops, are implementing big number of > > power-saving technologies. Some of them are working automatically, other > > have significant requirements and need special system tuning or > > trade-offs to be effectively used. > > > > So here is the steps: > > > > 1. CPU > > CPU is the most consuming part of the system. Under the full load it > > alone may consume more then 40W of power, but for real laptop usage the > > most important is idle consumption. > > Core2Duo T7700 CPU has 2 cores, runs on 2.4GHz frequency, supports EIST > > technology with P-states at 2400, 2000, 1600, 1200 and 800MHz levels, > > supports C1, C2 and C3 idle C-states, plus throttling. So how can we use it: > > P-states and throttling > > Enabling powerd allows to effectively control CPU frequency/voltage > > depending on CPU load. powerd on recent system can handle it quite > > transparently. By default, frequency controlled via mix of EIST and > > throttling technologies. First one controls both core frequency and > > voltage, second - only core frequency. Both technologies give positive > > power-saving effect. But effect of throttling is small and can be > > completely hidden by using C2 state, that's why I recommend to disable > > throttling control by adding to /boot/loader.conf: > > hint.p4tcc.0.disabled=1 > > hint.acpi_throttle.0.disabled=1 > > In my case frequency/voltage control saves about 5W of idle power. > > C-states > > - C1 stops clock on some parts of CPU core during inactivity. It is > > safe, cheap and supported by CPUs for ages. System uses C1 state by default. > > - C2 state allows CPU to turn off all core clocks on idle. It is also > > cheap, but requires correct ACPI-chipset-CPU interoperation to be used. > > Use of C2 state can be enabled by adding to /etc/rc.conf: > > performance_cx_lowest="C2" > > economy_cx_lowest="C2" > > Effect from this state is not so big when powerd is used, but still > > noticeable, > > - C3 state allows CPU completely stop all internal clocks, reduce > > voltage and disconnect from system bus. This state gives additional > > power saving effect, but it is not cheap and require trade-offs. > > As soon as CPU is completely stopped in C3 state, local APIC timers in > > each CPU core, used by FreeBSD as event sources on SMP, are not > > functioning. It stops system time, breaks scheduling that makes system > > close to dead. The only solution for this problem is to use some > > external timers. Originally, before SMP era, FreeBSD used i8254 (for HZ) > > and RTC (for stats) chipset timers. I have made changes to 8-CURRENT to > > resurrect them for SMP systems. To use them, you can disable local APIC > > timers by adding to /boot/loader.conf: > > hint.apic.0.clock=0 > > Also, to drop/rise voltage on C3, CPU needs time (57us for my system). > > It means that C3 state can't be effectively used when system is waking > > up often. To increase inactivity periods we should reduce interrupt rate > > as much as possible by adding to loader.conf: > > kern.hz=100 > > It may increase system response time a bit, but it is not significant > > for laptop. Also we may avoid additional 128 interrupts per second per > > core, by the cost of scheduling precision, with using i8254 timer also > > for statistic collection purposes instead of RTC clock, by using another > > newly added option: > > hint.atrtc.0.clock=0 > > As result, system has only 100 interrupts per core and CPUs are using C3 > > with high efficiency: > > %sysctl dev.cpu |grep cx > > dev.cpu.0.cx_supported: C1/1 C2/1 C3/57 > > dev.cpu.0.cx_lowest: C3 > > dev.cpu.0.cx_usage: 0.00% 0.00% 100.00% last 7150us > > dev.cpu.1.cx_supported: C1/1 C2/1 C3/57 > > dev.cpu.1.cx_lowest: C3 > > dev.cpu.1.cx_usage: 0.00% 0.00% 100.00% last 2235us > > Result of effective C3 state usage, comparing to C2+powerd, is about 2W. > > > > 2. PCI devices > > PCI bus provides method to control device power. For example, I have > > completely no use for my FireWire controller and most of time - EHCI USB > > controller. Disabling them allows me to save about 3W of power. To > > disable all unneeded PCI devices you should build kernel without their > > drivers and add to loader.conf: > > hw.pci.do_power_nodriver=3 > > To enable devices back all you need to do is just load their drivers as > > modules. > > > > 3. Radios > > WiFi and Bluetooth adapters can consume significant power when used (up > > to 2W when my iwn WiFi is connected) or just enabled (0.5W). Disabling > > them with mechanical switch on laptop case saves energy even when they > > are not connected. > > > > 4. HDA modem > > I was surprised, but integrated HDA modem consumed about 1W of power > > even when not used. I have used the most radical solution - removed it > > mechanically from socket. Case surface in that area become much cooler. > > > > 5. HDA sound > > To reduce number of sound generated interrupts I have added to the > > loader.conf: > > hint.pcm.0.buffersize=65536 > > hint.pcm.1.buffersize=65536 > > hw.snd.feeder_buffersize=65536 > > hw.snd.latency=7 > > > > 6. HDD > > First common recommendation is use tmpfs for temporary files. RAM is > > cheap, fast and anyway with you. > > Also you may try to setup automatic idle drive spin-down, but if it is > > the only system drive you should be careful, as every spin-up reduces > > drive's life time. > > For several months (until I have bought SATA SSD) I have successfully > > used SDHC card in built-in PCI sdhci card reader as main filesystem. On > > random read requests it is much faster then HDD, but it is very slow on > > random write. Same time it consumes almost nothing. USB drives could > > also be used, but effect is much less as EHCI USB controller consumes > > much power. > > Spinning-down my 2.5" Hitachi SATA HDD saves about 1W of power. Removing > > it completely saves 2W. > > > > 7. SATA > > Comparing to PATA, SATA interface uses differential signaling for data > > transfer. To work properly it has to transmit pseudo-random scrambled > > sequence even when idle. As you understand, that requires power. But > > SATA implements two power saving modes: PARTIAL and SLUMBER. These modes > > could be activated by either host or device if both sides support them. > > PARTIAL mode just stops scrambling, but keeps neutral link state, resume > > time is 50-100us. SLUMBER mode powers down interface completely, but > > respective resume time is 3-10ms. > > I have added minimal SATA power management to AHCI driver. There are > > hint.ata.X.pm_level loader tunables can be used to control it now. > > Setting it to 1 allows drive itself to initiate power saving, when it > > wish. Values 2 and 3 make AHCI controller to initiate PARTIAL and > > SLUMBER transitions after every command completion. > > Note that SATA power saving is not compatible with drive hot-swap, as > > controller unable to detect drive presence when link is powered-down. > > In my case PARTIAL mode saves 0.5W and SLUMBER - 0.8W of power. > > > > So what have I got? To monitor real system power consumption I am using > > information provided by ACPI battery via `acpiconf -i0` command: > > > > Original system: > > Design capacity: 4800 mAh > > Last full capacity: 4190 mAh > > Technology: secondary (rechargeable) > > Design voltage: 11100 mV > > Capacity (warn): 300 mAh > > Capacity (low): 167 mAh > > Low/warn granularity: 32 mAh > > Warn/full granularity: 32 mAh > > Model number: Victoria > > Serial number: 292 > > Type: LION > > OEM info: SIMPLO > > State: discharging > > Remaining capacity: 93% > > Remaining time: 2:24 > > Present rate: 1621 mA > > Voltage: 12033 mV > > > > Tuned system: > > %acpiconf -i0 > > Design capacity: 4800 mAh > > Last full capacity: 4190 mAh > > Technology: secondary (rechargeable) > > Design voltage: 11100 mV > > Capacity (warn): 300 mAh > > Capacity (low): 167 mAh > > Low/warn granularity: 32 mAh > > Warn/full granularity: 32 mAh > > Model number: Victoria > > Serial number: 292 > > Type: LION > > OEM info: SIMPLO > > State: discharging > > Remaining capacity: 94% > > Remaining time: 4:47 > > Present rate: 826 mA > > Voltage: 12231 mV > > > > So I have really doubled my on-battery time by this tuning - 4:47 hours > > instead of 2:24 with default settings. Preinstalled vendor-tuned Windows > > XP on the same system, provides maximum 3:20 hours. > > > > My EC does not present rate and time info: > 10:49pm][/home/onyx# acpiconf -i0 > Design capacity: 6000 mAh > Last full capacity: 3328 mAh > Technology: secondary (rechargeable) > Design voltage: 14800 mV > Capacity (warn): 172 mAh > Capacity (low): 104 mAh > Low/warn granularity: 10 mAh > Warn/full granularity: 25 mAh > Model number: Primary > Serial number: > Type: LION > OEM info: Hewlett-Packard > State: high > Remaining capacity: 100% > Remaining time: unknown > Present rate: unknown > Voltage: 12522 mV > > Where to dig? I'm realy need at least 'present rate' to fight for the > power.. Also it is an error in capacity detection, i think. Any ideas? Is the system connected to AC power when you issue the command? Many systems do not provide this information unless they are no battery power. Thy may also need to have been on battery for at least a minute or two to calculate drain rate. (Also, that battery is getting fairly old. It has only 55% of it's designed capacity.) -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 From owner-freebsd-acpi@FreeBSD.ORG Mon May 11 20:08:48 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 DE0EB106564A; Mon, 11 May 2009 20:08:48 +0000 (UTC) (envelope-from onemda@gmail.com) Received: from mail-bw0-f213.google.com (mail-bw0-f213.google.com [209.85.218.213]) by mx1.freebsd.org (Postfix) with ESMTP id A79B18FC34; Mon, 11 May 2009 20:08:47 +0000 (UTC) (envelope-from onemda@gmail.com) Received: by bwz9 with SMTP id 9so2934421bwz.43 for ; Mon, 11 May 2009 13:08:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=pjduoZjO9e/tARa/LHOUOlq+GsDIVg8hnlxEfquo2J4=; b=JjjpwOhrnYn/uQZuRlqQHglZ44ozRErI8aXPsNVH7uQuOGHZHlizLTn2iSR7zktQvL kW2Cf+VVyp+0ILy2FXtk1DD+j+uFOJ4X7vK3Iyybhd8ogywqBHB/M7o3uc+x1byGvobX i49hYqgEN1yYtlaAp1L0pnFNzFl31jb6QBo5M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=wFdz7WtsskDY/OKWDi2XoCNdmajhqCLSwYrgXdKprLFebbQTIBqcSs4iBMDmUjJgJx ys2j3vgS9AtfURMwWqucGuGCxknv/icLQm+2a0l6TtcDvTwXqma3sn21TzqT6XtsDihT YtGlVhaCjixl8YAUxOtNfirkj/Fwqk3iKeTZo= MIME-Version: 1.0 Received: by 10.239.133.67 with SMTP id 3mr590274hbu.63.1242072526309; Mon, 11 May 2009 13:08:46 -0700 (PDT) In-Reply-To: <4A081868.6010906@FreeBSD.org> References: <49FE1826.4060000@FreeBSD.org> <4A07BC4D.7080604@freebsd.org> <4A081868.6010906@FreeBSD.org> Date: Mon, 11 May 2009 22:08:46 +0200 Message-ID: <3a142e750905111308o62a11c8em5465ea9aa1cfaebc@mail.gmail.com> From: "Paul B. Mahol" To: Alexander Motin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: FreeBSD acpi , Tim Kientzle , freebsd-mobile@freebsd.org, FreeBSD-Current Subject: Re: Fighting for the power. 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, 11 May 2009 20:08:51 -0000 On 5/11/09, Alexander Motin wrote: > Tim Kientzle wrote: >> I started to try the "hint.apic.0.clock", but noticed >> in your commit r191720: >> Alexander Motin wrote: >>> Add hint.apic.0.clock tunable. Setting it 0 disables using >>> LAPIC timers as hard-/stat-/profclock sources falling back >>> to using i8254 and rtc timers. >>> ... >>> This technique is not working for SMP yet, as only one CPU >>> receives timer interrupts. But I think that problem could >>> be fixed by forwarding interrupts to other CPUs with IPI. >> >> Is anyone looking at this yet? > > I have implemented SMP support for i386 and amd64 in some of my later > commits. And all those hacks helps verry little in my case, most gain I get when laptop monitor is switched off. Even switching hard disk off improves battery life very little. interrupt total rate irq1: atkbd0 5206 3 irq0: clk 156008 99 irq9: acpi0 1152 0 irq12: psm0 16092 10 irq14: ata0 6587 4 irq15: ata1 1 0 irq17: ndis0 28646 18 irq256: hdac0 18 0 Total 213710 136 -- Paul From owner-freebsd-acpi@FreeBSD.ORG Mon May 11 20:24: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 696601065670 for ; Mon, 11 May 2009 20:24:19 +0000 (UTC) (envelope-from ivakras1@gmail.com) Received: from mail-bw0-f213.google.com (mail-bw0-f213.google.com [209.85.218.213]) by mx1.freebsd.org (Postfix) with ESMTP id B21508FC12 for ; Mon, 11 May 2009 20:24:18 +0000 (UTC) (envelope-from ivakras1@gmail.com) Received: by bwz9 with SMTP id 9so2942683bwz.43 for ; Mon, 11 May 2009 13:24:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:reply-to:organization:to :subject:date:user-agent:references:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :message-id; bh=RcobeobVaEhKulq3PY8NsX1NmuZB0xmzvj4IFBFd1UU=; b=MOgw0eY0C3rghqOb1lFScLQEb+hV9YPialCxvOoahUG6jGGvZ+VU5fuaO41ilgbqQI qZ1tn7cnil6iBDoA04ANthXErz2HliKIH83pk9jT3xWLnSIftju4mqls1hbOWfIc6/5r 23/p6K/HuB4dCZ1ZW0xPlkuVsrKIgA3D7gHiw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:reply-to:organization:to:subject:date:user-agent:references :in-reply-to:mime-version:content-type:content-transfer-encoding :content-disposition:message-id; b=PlNvPZaGpOF6I3b6XPW8q9cZyU3NpFvGBS0F4rd7zljEYUYbBp9et60AiCRDNURjK3 HA/QOelTzXWnOjcxILRzyk/4EYFpNDKTCq9TevTHy+0Cq+PBTcIpNh0BLSrZAG1aUw1f MahKHtPXEVW5xyHfEUg6vNsXKO3rRQ3g+KBh8= Received: by 10.103.117.8 with SMTP id u8mr4617567mum.123.1242073457638; Mon, 11 May 2009 13:24:17 -0700 (PDT) Received: from onyx_hp.dhcp.loc ([92.50.244.69]) by mx.google.com with ESMTPS id j2sm1305165mue.12.2009.05.11.13.24.12 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 11 May 2009 13:24:17 -0700 (PDT) From: Dmitry Kolosov Organization: Home To: freebsd-acpi@freebsd.org Date: Tue, 12 May 2009 00:21:22 +0400 User-Agent: KMail/1.11.3 (FreeBSD/7.2-STABLE; KDE/4.2.3; i386; ; ) References: <20090511191309.79F0E1CC0B@ptavv.es.net> In-Reply-To: <20090511191309.79F0E1CC0B@ptavv.es.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="koi8-r" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200905120021.23223.ivakras1@gmail.com> Subject: Re: Fighting for the power. X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ivakras1@gmail.com List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 May 2009 20:24:19 -0000 =F0=CF=CE=C5=C4=C5=CC=D8=CE=C9=CB 11 =CD=C1=D1 2009 23:13:09 Kevin Oberman = =D0=C9=D3=C1=CC=C9: > > From: Dmitry Kolosov > > Date: Mon, 11 May 2009 22:59:13 +0400 > > Sender: owner-freebsd-acpi@freebsd.org > >=20 > > =F0=CF=CE=C5=C4=C5=CC=D8=CE=C9=CB 04 =CD=C1=D1 2009 02:18:14 Alexander = Motin =D0=C9=D3=C1=CC=C9: > > > I would like to summarize some of my knowledge on reducing FreeBSD po= wer > > > consumption and describe some new things I have recently implemented = in > > > 8-CURRENT. The main character of this story is my 12" Acer TravelMate > > > 6292 laptop with C2D T7700 2.4GHz CPU, 965GM chipset and SATA HDD, un= der > > > amd64 8-CURRENT. > > >=20 > > > Modern systems, especially laptops, are implementing big number of=20 > > > power-saving technologies. Some of them are working automatically, ot= her=20 > > > have significant requirements and need special system tuning or=20 > > > trade-offs to be effectively used. > > >=20 > > > So here is the steps: > > >=20 > > > 1. CPU > > > CPU is the most consuming part of the system. Under the full load it > > > alone may consume more then 40W of power, but for real laptop usage t= he > > > most important is idle consumption. > > > Core2Duo T7700 CPU has 2 cores, runs on 2.4GHz frequency, supports EI= ST > > > technology with P-states at 2400, 2000, 1600, 1200 and 800MHz levels, > > > supports C1, C2 and C3 idle C-states, plus throttling. So how can we = use it: > > > P-states and throttling > > > Enabling powerd allows to effectively control CPU frequency/voltage > > > depending on CPU load. powerd on recent system can handle it quite > > > transparently. By default, frequency controlled via mix of EIST and > > > throttling technologies. First one controls both core frequency and > > > voltage, second - only core frequency. Both technologies give positive > > > power-saving effect. But effect of throttling is small and can be > > > completely hidden by using C2 state, that's why I recommend to disable > > > throttling control by adding to /boot/loader.conf: > > > hint.p4tcc.0.disabled=3D1 > > > hint.acpi_throttle.0.disabled=3D1 > > > In my case frequency/voltage control saves about 5W of idle power. > > > C-states > > > - C1 stops clock on some parts of CPU core during inactivity. It is > > > safe, cheap and supported by CPUs for ages. System uses C1 state by d= efault. > > > - C2 state allows CPU to turn off all core clocks on idle. It is al= so > > > cheap, but requires correct ACPI-chipset-CPU interoperation to be use= d. > > > Use of C2 state can be enabled by adding to /etc/rc.conf: > > > performance_cx_lowest=3D"C2" > > > economy_cx_lowest=3D"C2" > > > Effect from this state is not so big when powerd is used, but still > > > noticeable, > > > - C3 state allows CPU completely stop all internal clocks, reduce > > > voltage and disconnect from system bus. This state gives additional > > > power saving effect, but it is not cheap and require trade-offs. > > > As soon as CPU is completely stopped in C3 state, local APIC timers in > > > each CPU core, used by FreeBSD as event sources on SMP, are not > > > functioning. It stops system time, breaks scheduling that makes system > > > close to dead. The only solution for this problem is to use some > > > external timers. Originally, before SMP era, FreeBSD used i8254 (for = HZ) > > > and RTC (for stats) chipset timers. I have made changes to 8-CURRENT = to > > > resurrect them for SMP systems. To use them, you can disable local AP= IC > > > timers by adding to /boot/loader.conf: > > > hint.apic.0.clock=3D0 > > > Also, to drop/rise voltage on C3, CPU needs time (57us for my system). > > > It means that C3 state can't be effectively used when system is waking > > > up often. To increase inactivity periods we should reduce interrupt r= ate > > > as much as possible by adding to loader.conf: > > > kern.hz=3D100 > > > It may increase system response time a bit, but it is not significant > > > for laptop. Also we may avoid additional 128 interrupts per second per > > > core, by the cost of scheduling precision, with using i8254 timer also > > > for statistic collection purposes instead of RTC clock, by using anot= her > > > newly added option: > > > hint.atrtc.0.clock=3D0 > > > As result, system has only 100 interrupts per core and CPUs are using= C3 > > > with high efficiency: > > > %sysctl dev.cpu |grep cx > > > dev.cpu.0.cx_supported: C1/1 C2/1 C3/57 > > > dev.cpu.0.cx_lowest: C3 > > > dev.cpu.0.cx_usage: 0.00% 0.00% 100.00% last 7150us > > > dev.cpu.1.cx_supported: C1/1 C2/1 C3/57 > > > dev.cpu.1.cx_lowest: C3 > > > dev.cpu.1.cx_usage: 0.00% 0.00% 100.00% last 2235us > > > Result of effective C3 state usage, comparing to C2+powerd, is about = 2W. > > >=20 > > > 2. PCI devices > > > PCI bus provides method to control device power. For example, I have > > > completely no use for my FireWire controller and most of time - EHCI = USB > > > controller. Disabling them allows me to save about 3W of power. To > > > disable all unneeded PCI devices you should build kernel without their > > > drivers and add to loader.conf: > > > hw.pci.do_power_nodriver=3D3 > > > To enable devices back all you need to do is just load their drivers = as > > > modules. > > >=20 > > > 3. Radios > > > WiFi and Bluetooth adapters can consume significant power when used (= up > > > to 2W when my iwn WiFi is connected) or just enabled (0.5W). Disabling > > > them with mechanical switch on laptop case saves energy even when they > > > are not connected. > > >=20 > > > 4. HDA modem > > > I was surprised, but integrated HDA modem consumed about 1W of power > > > even when not used. I have used the most radical solution - removed it > > > mechanically from socket. Case surface in that area become much coole= r. > > >=20 > > > 5. HDA sound > > > To reduce number of sound generated interrupts I have added to the > > > loader.conf: > > > hint.pcm.0.buffersize=3D65536 > > > hint.pcm.1.buffersize=3D65536 > > > hw.snd.feeder_buffersize=3D65536 > > > hw.snd.latency=3D7 > > >=20 > > > 6. HDD > > > First common recommendation is use tmpfs for temporary files. RAM is > > > cheap, fast and anyway with you. > > > Also you may try to setup automatic idle drive spin-down, but if it is > > > the only system drive you should be careful, as every spin-up reduces > > > drive's life time. > > > For several months (until I have bought SATA SSD) I have successfully > > > used SDHC card in built-in PCI sdhci card reader as main filesystem. = On > > > random read requests it is much faster then HDD, but it is very slow = on > > > random write. Same time it consumes almost nothing. USB drives could > > > also be used, but effect is much less as EHCI USB controller consumes > > > much power. > > > Spinning-down my 2.5" Hitachi SATA HDD saves about 1W of power. Remov= ing > > > it completely saves 2W. > > >=20 > > > 7. SATA > > > Comparing to PATA, SATA interface uses differential signaling for data > > > transfer. To work properly it has to transmit pseudo-random scrambled > > > sequence even when idle. As you understand, that requires power. But > > > SATA implements two power saving modes: PARTIAL and SLUMBER. These mo= des > > > could be activated by either host or device if both sides support the= m. > > > PARTIAL mode just stops scrambling, but keeps neutral link state, res= ume > > > time is 50-100us. SLUMBER mode powers down interface completely, but > > > respective resume time is 3-10ms. > > > I have added minimal SATA power management to AHCI driver. There are > > > hint.ata.X.pm_level loader tunables can be used to control it now. > > > Setting it to 1 allows drive itself to initiate power saving, when it > > > wish. Values 2 and 3 make AHCI controller to initiate PARTIAL and > > > SLUMBER transitions after every command completion. > > > Note that SATA power saving is not compatible with drive hot-swap, as > > > controller unable to detect drive presence when link is powered-down. > > > In my case PARTIAL mode saves 0.5W and SLUMBER - 0.8W of power. > > >=20 > > > So what have I got? To monitor real system power consumption I am usi= ng > > > information provided by ACPI battery via `acpiconf -i0` command: > > >=20 > > > Original system: > > > Design capacity: 4800 mAh > > > Last full capacity: 4190 mAh > > > Technology: secondary (rechargeable) > > > Design voltage: 11100 mV > > > Capacity (warn): 300 mAh > > > Capacity (low): 167 mAh > > > Low/warn granularity: 32 mAh > > > Warn/full granularity: 32 mAh > > > Model number: Victoria > > > Serial number: 292 > > > Type: LION > > > OEM info: SIMPLO > > > State: discharging > > > Remaining capacity: 93% > > > Remaining time: 2:24 > > > Present rate: 1621 mA > > > Voltage: 12033 mV > > >=20 > > > Tuned system: > > > %acpiconf -i0 > > > Design capacity: 4800 mAh > > > Last full capacity: 4190 mAh > > > Technology: secondary (rechargeable) > > > Design voltage: 11100 mV > > > Capacity (warn): 300 mAh > > > Capacity (low): 167 mAh > > > Low/warn granularity: 32 mAh > > > Warn/full granularity: 32 mAh > > > Model number: Victoria > > > Serial number: 292 > > > Type: LION > > > OEM info: SIMPLO > > > State: discharging > > > Remaining capacity: 94% > > > Remaining time: 4:47 > > > Present rate: 826 mA > > > Voltage: 12231 mV > > >=20 > > > So I have really doubled my on-battery time by this tuning - 4:47 hou= rs=20 > > > instead of 2:24 with default settings. Preinstalled vendor-tuned Wind= ows=20 > > > XP on the same system, provides maximum 3:20 hours. > > >=20 > >=20 > > My EC does not present rate and time info: > > 10:49pm][/home/onyx# acpiconf -i0 > > Design capacity: 6000 mAh > > Last full capacity: 3328 mAh > > Technology: secondary (rechargeable) > > Design voltage: 14800 mV > > Capacity (warn): 172 mAh > > Capacity (low): 104 mAh > > Low/warn granularity: 10 mAh > > Warn/full granularity: 25 mAh > > Model number: Primary > > Serial number: =20 > > Type: LION > > OEM info: Hewlett-Packard > > State: high=20 > > Remaining capacity: 100% > > Remaining time: unknown > > Present rate: unknown > > Voltage: 12522 mV > >=20 > > Where to dig? I'm realy need at least 'present rate' to fight for the > > power.. Also it is an error in capacity detection, i think. Any ideas? >=20 > Is the system connected to AC power when you issue the command? Many > systems do not provide this information unless they are no battery > power. Thy may also need to have been on battery for at least a minute > or two to calculate drain rate. (Also, that battery is getting fairly > old. It has only 55% of it's designed capacity.) 20 minutes on battery. Still no 'Remaining time' nor 'Present rate'. It dra= ins 1% in a minute, while economy profile is C3 state for processor and 500= MHz of speed. Anyway, laptop runs less than a hour on battery on economy pr= ofile. That laptop (HP Pavilion dv6840er) is less than 1 year old. It's C4 state available in BIOS settings, i'll try it. From owner-freebsd-acpi@FreeBSD.ORG Mon May 11 20:38: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 A72F01065672 for ; Mon, 11 May 2009 20:38:27 +0000 (UTC) (envelope-from oberman@es.net) Received: from mailgw.es.net (mail3.es.net [IPv6:2001:400:4c01::2]) by mx1.freebsd.org (Postfix) with ESMTP id 72F0D8FC13 for ; Mon, 11 May 2009 20:38:27 +0000 (UTC) (envelope-from oberman@es.net) Received: from ptavv.es.net (ptavv.es.net [IPv6:2001:400:910::29]) by mailgw.es.net (8.14.3/8.14.3) with ESMTP id n4BKcPnk021300 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 11 May 2009 13:38:26 -0700 Received: from ptavv.es.net (ptavv.es.net [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id BDC351CC0B; Mon, 11 May 2009 13:38:25 -0700 (PDT) To: ivakras1@gmail.com In-reply-to: Your message of "Tue, 12 May 2009 00:21:22 +0400." <200905120021.23223.ivakras1@gmail.com> Date: Mon, 11 May 2009 13:38:25 -0700 From: "Kevin Oberman" Message-Id: <20090511203825.BDC351CC0B@ptavv.es.net> Cc: freebsd-acpi@freebsd.org Subject: Re: Fighting for the power. 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, 11 May 2009 20:38:27 -0000 > From: Dmitry Kolosov > Date: Tue, 12 May 2009 00:21:22 +0400 > Sender: owner-freebsd-acpi@freebsd.org > > 11 2009 23:13:09 Kevin Oberman : > > > From: Dmitry Kolosov > > > Date: Mon, 11 May 2009 22:59:13 +0400 > > > Sender: owner-freebsd-acpi@freebsd.org > > > > > > 04 2009 02:18:14 Alexander Motin : > > > > I would like to summarize some of my knowledge on reducing FreeBSD power > > > > consumption and describe some new things I have recently implemented in > > > > 8-CURRENT. The main character of this story is my 12" Acer TravelMate > > > > 6292 laptop with C2D T7700 2.4GHz CPU, 965GM chipset and SATA HDD, under > > > > amd64 8-CURRENT. > > > > > > > > Modern systems, especially laptops, are implementing big number of > > > > power-saving technologies. Some of them are working automatically, other > > > > have significant requirements and need special system tuning or > > > > trade-offs to be effectively used. > > > > > > > > So here is the steps: > > > > > > > > 1. CPU > > > > CPU is the most consuming part of the system. Under the full load it > > > > alone may consume more then 40W of power, but for real laptop usage the > > > > most important is idle consumption. > > > > Core2Duo T7700 CPU has 2 cores, runs on 2.4GHz frequency, supports EIST > > > > technology with P-states at 2400, 2000, 1600, 1200 and 800MHz levels, > > > > supports C1, C2 and C3 idle C-states, plus throttling. So how can we use it: > > > > P-states and throttling > > > > Enabling powerd allows to effectively control CPU frequency/voltage > > > > depending on CPU load. powerd on recent system can handle it quite > > > > transparently. By default, frequency controlled via mix of EIST and > > > > throttling technologies. First one controls both core frequency and > > > > voltage, second - only core frequency. Both technologies give positive > > > > power-saving effect. But effect of throttling is small and can be > > > > completely hidden by using C2 state, that's why I recommend to disable > > > > throttling control by adding to /boot/loader.conf: > > > > hint.p4tcc.0.disabled=1 > > > > hint.acpi_throttle.0.disabled=1 > > > > In my case frequency/voltage control saves about 5W of idle power. > > > > C-states > > > > - C1 stops clock on some parts of CPU core during inactivity. It is > > > > safe, cheap and supported by CPUs for ages. System uses C1 state by default. > > > > - C2 state allows CPU to turn off all core clocks on idle. It is also > > > > cheap, but requires correct ACPI-chipset-CPU interoperation to be used. > > > > Use of C2 state can be enabled by adding to /etc/rc.conf: > > > > performance_cx_lowest="C2" > > > > economy_cx_lowest="C2" > > > > Effect from this state is not so big when powerd is used, but still > > > > noticeable, > > > > - C3 state allows CPU completely stop all internal clocks, reduce > > > > voltage and disconnect from system bus. This state gives additional > > > > power saving effect, but it is not cheap and require trade-offs. > > > > As soon as CPU is completely stopped in C3 state, local APIC timers in > > > > each CPU core, used by FreeBSD as event sources on SMP, are not > > > > functioning. It stops system time, breaks scheduling that makes system > > > > close to dead. The only solution for this problem is to use some > > > > external timers. Originally, before SMP era, FreeBSD used i8254 (for HZ) > > > > and RTC (for stats) chipset timers. I have made changes to 8-CURRENT to > > > > resurrect them for SMP systems. To use them, you can disable local APIC > > > > timers by adding to /boot/loader.conf: > > > > hint.apic.0.clock=0 > > > > Also, to drop/rise voltage on C3, CPU needs time (57us for my system). > > > > It means that C3 state can't be effectively used when system is waking > > > > up often. To increase inactivity periods we should reduce interrupt rate > > > > as much as possible by adding to loader.conf: > > > > kern.hz=100 > > > > It may increase system response time a bit, but it is not significant > > > > for laptop. Also we may avoid additional 128 interrupts per second per > > > > core, by the cost of scheduling precision, with using i8254 timer also > > > > for statistic collection purposes instead of RTC clock, by using another > > > > newly added option: > > > > hint.atrtc.0.clock=0 > > > > As result, system has only 100 interrupts per core and CPUs are using C3 > > > > with high efficiency: > > > > %sysctl dev.cpu |grep cx > > > > dev.cpu.0.cx_supported: C1/1 C2/1 C3/57 > > > > dev.cpu.0.cx_lowest: C3 > > > > dev.cpu.0.cx_usage: 0.00% 0.00% 100.00% last 7150us > > > > dev.cpu.1.cx_supported: C1/1 C2/1 C3/57 > > > > dev.cpu.1.cx_lowest: C3 > > > > dev.cpu.1.cx_usage: 0.00% 0.00% 100.00% last 2235us > > > > Result of effective C3 state usage, comparing to C2+powerd, is about 2W. > > > > > > > > 2. PCI devices > > > > PCI bus provides method to control device power. For example, I have > > > > completely no use for my FireWire controller and most of time - EHCI USB > > > > controller. Disabling them allows me to save about 3W of power. To > > > > disable all unneeded PCI devices you should build kernel without their > > > > drivers and add to loader.conf: > > > > hw.pci.do_power_nodriver=3 > > > > To enable devices back all you need to do is just load their drivers as > > > > modules. > > > > > > > > 3. Radios > > > > WiFi and Bluetooth adapters can consume significant power when used (up > > > > to 2W when my iwn WiFi is connected) or just enabled (0.5W). Disabling > > > > them with mechanical switch on laptop case saves energy even when they > > > > are not connected. > > > > > > > > 4. HDA modem > > > > I was surprised, but integrated HDA modem consumed about 1W of power > > > > even when not used. I have used the most radical solution - removed it > > > > mechanically from socket. Case surface in that area become much cooler. > > > > > > > > 5. HDA sound > > > > To reduce number of sound generated interrupts I have added to the > > > > loader.conf: > > > > hint.pcm.0.buffersize=65536 > > > > hint.pcm.1.buffersize=65536 > > > > hw.snd.feeder_buffersize=65536 > > > > hw.snd.latency=7 > > > > > > > > 6. HDD > > > > First common recommendation is use tmpfs for temporary files. RAM is > > > > cheap, fast and anyway with you. > > > > Also you may try to setup automatic idle drive spin-down, but if it is > > > > the only system drive you should be careful, as every spin-up reduces > > > > drive's life time. > > > > For several months (until I have bought SATA SSD) I have successfully > > > > used SDHC card in built-in PCI sdhci card reader as main filesystem. On > > > > random read requests it is much faster then HDD, but it is very slow on > > > > random write. Same time it consumes almost nothing. USB drives could > > > > also be used, but effect is much less as EHCI USB controller consumes > > > > much power. > > > > Spinning-down my 2.5" Hitachi SATA HDD saves about 1W of power. Removing > > > > it completely saves 2W. > > > > > > > > 7. SATA > > > > Comparing to PATA, SATA interface uses differential signaling for data > > > > transfer. To work properly it has to transmit pseudo-random scrambled > > > > sequence even when idle. As you understand, that requires power. But > > > > SATA implements two power saving modes: PARTIAL and SLUMBER. These modes > > > > could be activated by either host or device if both sides support them. > > > > PARTIAL mode just stops scrambling, but keeps neutral link state, resume > > > > time is 50-100us. SLUMBER mode powers down interface completely, but > > > > respective resume time is 3-10ms. > > > > I have added minimal SATA power management to AHCI driver. There are > > > > hint.ata.X.pm_level loader tunables can be used to control it now. > > > > Setting it to 1 allows drive itself to initiate power saving, when it > > > > wish. Values 2 and 3 make AHCI controller to initiate PARTIAL and > > > > SLUMBER transitions after every command completion. > > > > Note that SATA power saving is not compatible with drive hot-swap, as > > > > controller unable to detect drive presence when link is powered-down. > > > > In my case PARTIAL mode saves 0.5W and SLUMBER - 0.8W of power. > > > > > > > > So what have I got? To monitor real system power consumption I am using > > > > information provided by ACPI battery via `acpiconf -i0` command: > > > > > > > > Original system: > > > > Design capacity: 4800 mAh > > > > Last full capacity: 4190 mAh > > > > Technology: secondary (rechargeable) > > > > Design voltage: 11100 mV > > > > Capacity (warn): 300 mAh > > > > Capacity (low): 167 mAh > > > > Low/warn granularity: 32 mAh > > > > Warn/full granularity: 32 mAh > > > > Model number: Victoria > > > > Serial number: 292 > > > > Type: LION > > > > OEM info: SIMPLO > > > > State: discharging > > > > Remaining capacity: 93% > > > > Remaining time: 2:24 > > > > Present rate: 1621 mA > > > > Voltage: 12033 mV > > > > > > > > Tuned system: > > > > %acpiconf -i0 > > > > Design capacity: 4800 mAh > > > > Last full capacity: 4190 mAh > > > > Technology: secondary (rechargeable) > > > > Design voltage: 11100 mV > > > > Capacity (warn): 300 mAh > > > > Capacity (low): 167 mAh > > > > Low/warn granularity: 32 mAh > > > > Warn/full granularity: 32 mAh > > > > Model number: Victoria > > > > Serial number: 292 > > > > Type: LION > > > > OEM info: SIMPLO > > > > State: discharging > > > > Remaining capacity: 94% > > > > Remaining time: 4:47 > > > > Present rate: 826 mA > > > > Voltage: 12231 mV > > > > > > > > So I have really doubled my on-battery time by this tuning - 4:47 hours > > > > instead of 2:24 with default settings. Preinstalled vendor-tuned Windows > > > > XP on the same system, provides maximum 3:20 hours. > > > > > > > > > > My EC does not present rate and time info: > > > 10:49pm][/home/onyx# acpiconf -i0 > > > Design capacity: 6000 mAh > > > Last full capacity: 3328 mAh > > > Technology: secondary (rechargeable) > > > Design voltage: 14800 mV > > > Capacity (warn): 172 mAh > > > Capacity (low): 104 mAh > > > Low/warn granularity: 10 mAh > > > Warn/full granularity: 25 mAh > > > Model number: Primary > > > Serial number: > > > Type: LION > > > OEM info: Hewlett-Packard > > > State: high > > > Remaining capacity: 100% > > > Remaining time: unknown > > > Present rate: unknown > > > Voltage: 12522 mV > > > > > > Where to dig? I'm realy need at least 'present rate' to fight for the > > > power.. Also it is an error in capacity detection, i think. Any ideas? > > > > Is the system connected to AC power when you issue the command? Many > > systems do not provide this information unless they are no battery > > power. Thy may also need to have been on battery for at least a minute > > or two to calculate drain rate. (Also, that battery is getting fairly > > old. It has only 55% of it's designed capacity.) > 20 minutes on battery. Still no 'Remaining time' nor 'Present rate'. It drains 1% in a minute, while economy profile is C3 state for processor and 500MHz of speed. Anyway, laptop runs less than a hour on battery on economy profile. That laptop (HP Pavilion dv6840er) is less than 1 year old. > It's C4 state available in BIOS settings, i'll try it. If the battery is in that bad a shape after a year, either it is a crappy battery (not likely) or it is being abused by being kept at full charge almost all of the time. LI-Ion batteries will deteriorate if not fully discharged periodically and even more if almost always on AC power and fully charged. IBM/Lenovo recommend a full discharge of LI-Ion batteries on a monthly basis and, if always on AC power, keeping them at no more than 80% charge. IBM/Lenovo power management software can be set to keep the power at a reduced level. FreeBSD does not have this capability, though it could be folded into the IBM ACPI module with a command to set the charge point. "Full discharge" means disabling automatic suspend on low battery in power management and letting them run down as far as possible. I try to discharge my battery monthly and to keep spare batteries at about 50% charge when they will be in storage for more than a week or two and it seems to have helped a great deal. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 From owner-freebsd-acpi@FreeBSD.ORG Mon May 11 23:13:38 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 CAE1B10656E2; Mon, 11 May 2009 23:13:38 +0000 (UTC) (envelope-from mav@FreeBSD.org) Received: from cmail.optima.ua (cmail.optima.ua [195.248.191.121]) by mx1.freebsd.org (Postfix) with ESMTP id D33CB8FC1B; Mon, 11 May 2009 23:13:37 +0000 (UTC) (envelope-from mav@FreeBSD.org) X-Spam-Flag: SKIP X-Spam-Yversion: Spamooborona-2.1.0 Received: from [66.135.97.2] (account mav@alkar.net HELO mavbook.mavhome.dp.ua) by cmail.optima.ua (CommuniGate Pro SMTP 5.2.9) with ESMTPSA id 242454679; Tue, 12 May 2009 02:13:35 +0300 Message-ID: <4A08B10E.4040702@FreeBSD.org> Date: Tue, 12 May 2009 02:13:18 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.21 (X11/20090405) MIME-Version: 1.0 To: "Paul B. Mahol" References: <49FE1826.4060000@FreeBSD.org> <4A07BC4D.7080604@freebsd.org> <4A081868.6010906@FreeBSD.org> <3a142e750905111308o62a11c8em5465ea9aa1cfaebc@mail.gmail.com> In-Reply-To: <3a142e750905111308o62a11c8em5465ea9aa1cfaebc@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD acpi , FreeBSD-Current , freebsd-mobile@freebsd.org Subject: Re: Fighting for the power. 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, 11 May 2009 23:13:39 -0000 Paul B. Mahol wrote: > On 5/11/09, Alexander Motin wrote: >> Tim Kientzle wrote: >>> I started to try the "hint.apic.0.clock", but noticed >>> in your commit r191720: >>> Alexander Motin wrote: >>>> Add hint.apic.0.clock tunable. Setting it 0 disables using >>>> LAPIC timers as hard-/stat-/profclock sources falling back >>>> to using i8254 and rtc timers. >>>> ... >>>> This technique is not working for SMP yet, as only one CPU >>>> receives timer interrupts. But I think that problem could >>>> be fixed by forwarding interrupts to other CPUs with IPI. >>> Is anyone looking at this yet? >> I have implemented SMP support for i386 and amd64 in some of my later >> commits. > > And all those hacks helps verry little in my case, most gain I get when > laptop monitor is switched off. Even switching hard disk off improves battery > life very little. Monitor is surely one of major power consumers, but there are not so much things which you can do about it, as without power there will be no backlight. All you can do is tune backlight to minimum level required in every specific situation. What's about general effect, the main idea here is the same as in audio processing: result mostly depends on quality of the worst component. Your system may just have some other consumers which I don't have. For example, desktop CPU instead of mobile, desktop chipset instead of mobile, powerful external video instead of (or even in addition to) built-in, and so on. -- Alexander Motin From owner-freebsd-acpi@FreeBSD.ORG Tue May 12 03:24: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 8A245106566C for ; Tue, 12 May 2009 03:24:37 +0000 (UTC) (envelope-from dsewnr.buffer@gmail.com) Received: from mail-ew0-f207.google.com (mail-ew0-f207.google.com [209.85.219.207]) by mx1.freebsd.org (Postfix) with ESMTP id 16ABA8FC1D for ; Tue, 12 May 2009 03:24:31 +0000 (UTC) (envelope-from dsewnr.buffer@gmail.com) Received: by ewy3 with SMTP id 3so3896767ewy.43 for ; Mon, 11 May 2009 20:24:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:reply-to :user-agent:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=04e0AaaM+02H2J6/GwcS6CiU1Dmg9NAl5Xusv8DPYLw=; b=RJnkgJyiK8k9X9eea/D3fdLThCspVCkyBjNfA6WnWHlVbGf/rq1TOfxj7s33WeKlTH we7Vd1nHJzC1bobMETYNslzbzdCUoGu0pEIho3SrCwHByY6+6/i0f+tA6Sb9Y8zH3T/7 Ox5yYt0sECjhZy1W+ylVyj9TjfqZItvTR+8Dc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:reply-to:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; b=e7uLtiku66diyu9oXjGvuenl8EaKr4CAZO3nr2M8l/1g/544QY8mMUm2Bajviybpu7 HmyfJSy/7TIVDXKF/UcXGVq74qf7HoStPsXgdg/EU6OKr0hFX/WZ7plSo8UxA29+voiC o/byNW0MDQxUG2wXK6A3vuYZGeDhpG+ZlWDLU= Received: by 10.216.11.207 with SMTP id 57mr3699190wex.154.1242098670937; Mon, 11 May 2009 20:24:30 -0700 (PDT) Received: from dorara.twbbs.org (59-127-33-87.HINET-IP.hinet.net [59.127.33.87]) by mx.google.com with ESMTPS id u14sm14617808gvf.17.2009.05.11.20.24.28 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 11 May 2009 20:24:30 -0700 (PDT) Message-ID: <4A08EBE5.5000507@gmail.com> Date: Tue, 12 May 2009 11:24:21 +0800 From: Dsewnr Lu User-Agent: Thunderbird 2.0.0.21 (X11/20090501) MIME-Version: 1.0 To: freebsd-acpi@freebsd.org References: <4A0397B2.5000303@gmail.com> <4A043734.7080700@icyb.net.ua> <4A045715.3030503@gmail.com> <4A045983.9060600@icyb.net.ua> <4A045A18.90807@gmail.com> In-Reply-To: <4A045A18.90807@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: acpi problem ? X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dsewnr.buffer@gmail.com List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2009 03:24:37 -0000 Dsewnr Lu wrote: > Andriy Gapon wrote: >> on 08/05/2009 19:00 Dsewnr Lu said the following: >> >>> This is my acpidump -dt output. >>> >> >> I couldn't find anything obviously wrong, sorry. Maybe somebody else >> could spot >> something. >> >> > Thanks a lot. :) > > Dsewnr Lu > I've upgraded to 8.0-CURRENT-amd64 and it works fine now. I tried 7.2-RELEASE-i386 and 8.0-CURRENT-i386 with the same kernel config and similar enviromnent, all work fine. I guess the problem may occur only on 7.2-RELEASE-amd64.... Regards, Dsewnr Lu. From owner-freebsd-acpi@FreeBSD.ORG Tue May 12 07:38:15 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 48C261065670; Tue, 12 May 2009 07:38:15 +0000 (UTC) (envelope-from knowtree@aloha.com) Received: from relay.pixi.com (relay.pixi.com [206.127.224.101]) by mx1.freebsd.org (Postfix) with ESMTP id 3FDC48FC13; Tue, 12 May 2009 07:38:13 +0000 (UTC) (envelope-from knowtree@aloha.com) Received: from leka.aloha.com (leka.aloha.com [206.127.224.85]) by relay.pixi.com (8.13.8+Sun/8.13.6) with ESMTP id n4C6f0Tb004161; Mon, 11 May 2009 20:41:00 -1000 (HST) Received: from [10.0.1.195] (atm-251-63.pixi.com [206.127.251.63]) by leka.aloha.com (8.13.8+Sun/8.12.11) with ESMTP id n4C6ewk9004101; Mon, 11 May 2009 20:40:59 -1000 (HST) From: Gary Dunn To: Alexander Motin In-Reply-To: <4A08B10E.4040702@FreeBSD.org> References: <49FE1826.4060000@FreeBSD.org> <4A07BC4D.7080604@freebsd.org> <4A081868.6010906@FreeBSD.org> <3a142e750905111308o62a11c8em5465ea9aa1cfaebc@mail.gmail.com> <4A08B10E.4040702@FreeBSD.org> Content-Type: text/plain Date: Mon, 11 May 2009 20:40:55 -1000 Message-Id: <1242110455.2664.9.camel@slate01> Mime-Version: 1.0 X-Mailer: Evolution 2.24.5 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: FreeBSD acpi , "Paul B. Mahol" , freebsd-mobile@freebsd.org, FreeBSD-Current Subject: Re: Fighting for the power. 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, 12 May 2009 07:38:15 -0000 On Tue, 2009-05-12 at 02:13 +0300, Alexander Motin wrote: ... > > What's about general effect, the main idea here is the same as in audio > processing: result mostly depends on quality of the worst component. > Your system may just have some other consumers which I don't have. For > example, desktop CPU instead of mobile, desktop chipset instead of > mobile, powerful external video instead of (or even in addition to) > built-in, and so on. > Interesting point. Is there a power consumption benchmark for evaluating hardware for use with FreeBSD? -- Gary Dunn, Honolulu osp@aloha.com http://openslate.net/ http://e9erust.blogspot.com/ Sent from Slate001 From owner-freebsd-acpi@FreeBSD.ORG Tue May 12 10:25: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 AF788106564A; Tue, 12 May 2009 10:25:36 +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 102C48FC22; Tue, 12 May 2009 10:25:35 +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 n4CAPRHB063767; Tue, 12 May 2009 20:25:27 +1000 (EST) (envelope-from smithi@nimnet.asn.au) Date: Tue, 12 May 2009 20:25:27 +1000 (EST) From: Ian Smith To: Gary Dunn In-Reply-To: <1242110455.2664.9.camel@slate01> Message-ID: <20090512182420.K46325@sola.nimnet.asn.au> References: <49FE1826.4060000@FreeBSD.org> <4A07BC4D.7080604@freebsd.org> <4A081868.6010906@FreeBSD.org> <3a142e750905111308o62a11c8em5465ea9aa1cfaebc@mail.gmail.com> <4A08B10E.4040702@FreeBSD.org> <1242110455.2664.9.camel@slate01> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: Alexander Motin , "Paul B. Mahol" , FreeBSD acpi , FreeBSD-Current , freebsd-mobile@freebsd.org Subject: Re: Fighting for the power. 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, 12 May 2009 10:25:37 -0000 On Mon, 11 May 2009, Gary Dunn wrote: > On Tue, 2009-05-12 at 02:13 +0300, Alexander Motin wrote: > ... > > > > What's about general effect, the main idea here is the same as in audio > > processing: result mostly depends on quality of the worst component. > > Your system may just have some other consumers which I don't have. For > > example, desktop CPU instead of mobile, desktop chipset instead of > > mobile, powerful external video instead of (or even in addition to) > > built-in, and so on. > > > > Interesting point. Is there a power consumption benchmark for evaluating > hardware for use with FreeBSD? make buildworld, running on battery? :-) More seriously: thanks to Nate's earlier niggling, I've been thinking towards a richer set of power profiles than our {performance,economy} dichotomy for a while, both in terms of various different work/play and AC/battery scenarious, and re specific settings that may be more or less optimal for particular hardware, that could be distributed or advised as more of a basic working set rather than as a series of 'try this' hints. Many of the useful points Alexander makes apply to lots of recent kit, but perhaps not as applicably to some older machines - just one example being whether using C3 is likely to help or hinder, eg with the C3 quirks for (some) PIIX4 chipset variants that got some work last? year. I'm not a C programmer, so I've been thinking more towards inclusion as a deeper level of rc.conf variables and parsing of these by sh script, tweaking sysctls after the fashion of the present power_profile and its triggering by devd events. Some features of individual machine / scenario profiles could include min/max cpu freq settings, whether or not to use p4tcc/acpi_throttle, highest C-state, powerd high/low load shift up/down percentages, and perhaps whether or not to power-down (D3) various devices/subsystems .. Recent exposure to (debian etch) cpufreqd profiles provides a few more ideas, eg here are a few examples from its default cpufreqd.conf, noting that cpufreqd and friends are add-ons, not system components, in debian. # stay in performance mode for the first minutes [Rule] name=AC Off - High Power ac=off # (on/off) battery_interval=70-100 #exec_post=echo 5 > /proc/acpi/sony/brightness profile=Performance Low [/Rule] # conservative mode when not AC [Rule] name=AC Off - Medium Battery ac=off # (on/off) battery_interval=30-70 #exec_post=echo 3 > /proc/acpi/sony/brightness profile=Powersave High [/Rule] # conservative mode when not AC [Rule] name=AC Off - Low Battery ac=off # (on/off) battery_interval=0-30 #exec_post=echo 3 > /proc/acpi/sony/brightness profile=Powersave Low [/Rule] ## # Special Rules ## # CPU Too hot! [Rule] name=CPU Too Hot acpi_temperature=55-100 cpu_interval=50-100 profile=Performance Low [/Rule] # use performance mode if I'm watching a movie # I don't care for batteries! # But don't heat too much. [Rule] name=Movie Watcher programs=xine,mplayer,gmplayer battery_interval=0-100 acpi_temperature=0-60 cpu_interval=0-100 profile=Performance High [/Rule] cheers, Ian From owner-freebsd-acpi@FreeBSD.ORG Tue May 12 10:43: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 23A8C1065670 for ; Tue, 12 May 2009 10:43:44 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from mail18.syd.optusnet.com.au (mail18.syd.optusnet.com.au [211.29.132.199]) by mx1.freebsd.org (Postfix) with ESMTP id A9D608FC14 for ; Tue, 12 May 2009 10:43:43 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from server.vk2pj.dyndns.org (c122-106-216-167.belrs3.nsw.optusnet.com.au [122.106.216.167]) by mail18.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id n4CAhZbI009199 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 12 May 2009 20:43:36 +1000 X-Bogosity: Ham, spamicity=0.000000 Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by server.vk2pj.dyndns.org (8.14.3/8.14.3) with ESMTP id n4CAhY5t042811; Tue, 12 May 2009 20:43:34 +1000 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.3/8.14.3/Submit) id n4CAhYCH042810; Tue, 12 May 2009 20:43:34 +1000 (EST) (envelope-from peter) Date: Tue, 12 May 2009 20:43:33 +1000 From: Peter Jeremy To: Kevin Oberman Message-ID: <20090512104333.GD41857@server.vk2pj.dyndns.org> References: <200905120021.23223.ivakras1@gmail.com> <20090511203825.BDC351CC0B@ptavv.es.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="kvUQC+jR9YzypDnK" Content-Disposition: inline In-Reply-To: <20090511203825.BDC351CC0B@ptavv.es.net> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.19 (2009-01-05) Cc: freebsd-acpi@freebsd.org Subject: Re: Fighting for the power. 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, 12 May 2009 10:43:44 -0000 --kvUQC+jR9YzypDnK Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2009-May-11 13:38:25 -0700, Kevin Oberman wrote: >LI-Ion batteries will deteriorate if not fully discharged periodically >and even more if almost always on AC power and fully charged. Li-ION batteries deterioriate under virtually any conditions. My reading suggests storing them partially charged in a fridge is best. >charge point. "Full discharge" means disabling automatic suspend on low >battery in power management and letting them run down as far as >possible. A friend & I both have HP nx6125 laptops. We have both accidently run our batteries to cutoff on a number of occasions and every time we do, acpiconf reports the battery capacity drops by about 5%. --=20 Peter Jeremy --kvUQC+jR9YzypDnK Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iEYEARECAAYFAkoJUtUACgkQ/opHv/APuIeX6wCeKcpPyKJR77N6uY1vq73Hts8E pA0AnjoOlG8V32Era/Ccta7sQY7BwthA =Mx7K -----END PGP SIGNATURE----- --kvUQC+jR9YzypDnK-- From owner-freebsd-acpi@FreeBSD.ORG Tue May 12 10:51: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 0BE771065674 for ; Tue, 12 May 2009 10:51:59 +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 8160F8FC23 for ; Tue, 12 May 2009 10:51:58 +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 n4CApgo9064566; Tue, 12 May 2009 20:51:42 +1000 (EST) (envelope-from smithi@nimnet.asn.au) Date: Tue, 12 May 2009 20:51:42 +1000 (EST) From: Ian Smith To: Peter Jeremy In-Reply-To: <20090512104333.GD41857@server.vk2pj.dyndns.org> Message-ID: <20090512204716.W46325@sola.nimnet.asn.au> References: <200905120021.23223.ivakras1@gmail.com> <20090511203825.BDC351CC0B@ptavv.es.net> <20090512104333.GD41857@server.vk2pj.dyndns.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: freebsd-acpi@freebsd.org Subject: Re: Fighting for the power. 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, 12 May 2009 10:51:59 -0000 On Tue, 12 May 2009, Peter Jeremy wrote: > On 2009-May-11 13:38:25 -0700, Kevin Oberman wrote: > >LI-Ion batteries will deteriorate if not fully discharged periodically > >and even more if almost always on AC power and fully charged. > > Li-ION batteries deterioriate under virtually any conditions. My > reading suggests storing them partially charged in a fridge is best. My reading also. I've got a spare virtually-new Li-Ion battery for my old Compaq Armada (my main server :) in the fridge at the moment, its present battery looking like it might last another year at best. > >charge point. "Full discharge" means disabling automatic suspend on low > >battery in power management and letting them run down as far as > >possible. > > A friend & I both have HP nx6125 laptops. We have both accidently run > our batteries to cutoff on a number of occasions and every time we do, > acpiconf reports the battery capacity drops by about 5%. Might that be because the battery only adjusts its capacity data on full discharge, though? cheers, Ian From owner-freebsd-acpi@FreeBSD.ORG Tue May 12 11:45: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 A975C106566B; Tue, 12 May 2009 11:45:13 +0000 (UTC) (envelope-from mav@FreeBSD.org) Received: from cmail.optima.ua (cmail.optima.ua [195.248.191.121]) by mx1.freebsd.org (Postfix) with ESMTP id AA38D8FC13; Tue, 12 May 2009 11:45:12 +0000 (UTC) (envelope-from mav@FreeBSD.org) X-Spam-Flag: SKIP X-Spam-Yversion: Spamooborona-2.1.0 Received: from [66.135.97.2] (account mav@alkar.net HELO mavbook.mavhome.dp.ua) by cmail.optima.ua (CommuniGate Pro SMTP 5.2.9) with ESMTPSA id 242526780; Tue, 12 May 2009 14:45:10 +0300 Message-ID: <4A096131.4040405@FreeBSD.org> Date: Tue, 12 May 2009 14:44:49 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.21 (X11/20090405) MIME-Version: 1.0 To: Gary Dunn References: <49FE1826.4060000@FreeBSD.org> <4A07BC4D.7080604@freebsd.org> <4A081868.6010906@FreeBSD.org> <3a142e750905111308o62a11c8em5465ea9aa1cfaebc@mail.gmail.com> <4A08B10E.4040702@FreeBSD.org> <1242110455.2664.9.camel@slate01> In-Reply-To: <1242110455.2664.9.camel@slate01> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD acpi , "Paul B. Mahol" , freebsd-mobile@freebsd.org, FreeBSD-Current Subject: Re: Fighting for the power. 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, 12 May 2009 11:45:14 -0000 Gary Dunn wrote: > On Tue, 2009-05-12 at 02:13 +0300, Alexander Motin wrote: > ... >> What's about general effect, the main idea here is the same as in audio >> processing: result mostly depends on quality of the worst component. >> Your system may just have some other consumers which I don't have. For >> example, desktop CPU instead of mobile, desktop chipset instead of >> mobile, powerful external video instead of (or even in addition to) >> built-in, and so on. > > Interesting point. Is there a power consumption benchmark for evaluating > hardware for use with FreeBSD? It is difficult to speak about benchmark, as soon as we are talking about idle power. I think the first step evaluation could be made with vendor provided data, as it mostly depends on hardware. If vendor speaks about 2 hours on battery, then there is quite small probability to get much out of that system, as it looks mostly positioned as desktop and may have many desktop components. And opposite, system declaring 9 hours must support a lot of different power-saving technologies to reach it. -- Alexander Motin From owner-freebsd-acpi@FreeBSD.ORG Tue May 12 15:31: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 6C9A61065702; Tue, 12 May 2009 15:31:58 +0000 (UTC) (envelope-from mav@FreeBSD.org) Received: from cmail.optima.ua (cmail.optima.ua [195.248.191.121]) by mx1.freebsd.org (Postfix) with ESMTP id 26B528FC0A; Tue, 12 May 2009 15:31:53 +0000 (UTC) (envelope-from mav@FreeBSD.org) X-Spam-Flag: SKIP X-Spam-Yversion: Spamooborona-2.1.0 Received: from [66.78.101.3] (account mav@alkar.net HELO mavbook.mavhome.dp.ua) by cmail.optima.ua (CommuniGate Pro SMTP 5.2.9) with ESMTPSA id 242567282; Tue, 12 May 2009 18:31:53 +0300 Message-ID: <4A099661.7080404@FreeBSD.org> Date: Tue, 12 May 2009 18:31:45 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.21 (X11/20090405) MIME-Version: 1.0 To: John Baldwin References: <43b1bb350904230622u4b7790f0p9f665b649c97a3b@mail.gmail.com> <200905011450.13899.jhb@freebsd.org> <43b1bb350905011230p1372e1ffw5ab61985e7672e19@mail.gmail.com> <200905111425.01887.jhb@freebsd.org> In-Reply-To: <200905111425.01887.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-acpi@freebsd.org Subject: Re: Fwd: Kernel panic on 7.2-RC1 when booting with ACPI enabled kernel. 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, 12 May 2009 15:32:15 -0000 John Baldwin wrote: > On Friday 01 May 2009 3:30:28 pm Magnus Kling wrote: >> 2009/5/1 John Baldwin >>> Maybe try adding KTR traces for all calls to device_set_ivars(). I wonder >>> if >>> something is trashing this device's ivars. >>> >>> Oh, dear. The ata(4) driver overwrites the ivars of some PCI devices it >>> attaches to. This is very, very wrong. Which ATA controller do you have? >>> >> Aha, Im using a Promise Fasttrack SX4000 for a RAID1 setup. And the one >> included on the motherboard for the OS. >> And yes, I can confirm that without the Fasttrack SX4000 the system boots up >> correctly. (Pulled out the card and edited fstab.) >> So you are right regarding that the ata driver messes something up. Do you >> contact someone that is responsible for ata driver? >> >> Thank you for taking the time to "correct" this, > > Can you please try this patch? Current behavior is definitely broken. Luckily it done so only for two types of controllers. As for me, this patch looks fine. Thanks. -- Alexander Motin From owner-freebsd-acpi@FreeBSD.ORG Wed May 13 18:55: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 0D7121065741 for ; Wed, 13 May 2009 18:55:39 +0000 (UTC) (envelope-from scjamorim@bsd.com.br) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.26]) by mx1.freebsd.org (Postfix) with ESMTP id A31708FC2E for ; Wed, 13 May 2009 18:55:38 +0000 (UTC) (envelope-from scjamorim@bsd.com.br) Received: by ey-out-2122.google.com with SMTP id 9so274609eyd.7 for ; Wed, 13 May 2009 11:55:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.210.37.11 with SMTP id k11mr8781411ebk.98.1242239622538; Wed, 13 May 2009 11:33:42 -0700 (PDT) Date: Wed, 13 May 2009 15:33:42 -0300 Message-ID: <5859850b0905131133l32a43cd2k8eecc695dc175a3a@mail.gmail.com> From: =?ISO-8859-1?Q?Sylvio_C=E9sar_Teixeira_Amorim?= To: freebsd-acpi@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Hi Guys 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, 13 May 2009 18:55:39 -0000 I have one laptop Dell Latitude E4300 with FreeBSD-8-Current, The temperature of the processor is very high when I'm compiling the kernel, I get to stay with 88 Celsius, how do I force a download this temperature? Att, Sylvio Cesar. -- -=-=-=-=-=-=-=- Live free or die - UNIX* -=-=-=-=-=-=-= From owner-freebsd-acpi@FreeBSD.ORG Wed May 13 19:54:45 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 4B36F1065678 for ; Wed, 13 May 2009 19:54:45 +0000 (UTC) (envelope-from glen.j.barber@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 A684C8FC17 for ; Wed, 13 May 2009 19:54:44 +0000 (UTC) (envelope-from glen.j.barber@gmail.com) Received: by yw-out-2324.google.com with SMTP id 9so478765ywe.13 for ; Wed, 13 May 2009 12:54:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=cUyNQJ56LxbXVMx/Q5taCk8Y9wu5RjvS1qFL2MZed58=; b=jDsosyNUPT+GcnsIxTRv060gQzJ0KKF2oK5tEmb8XbMjV9Z1Ywnp2Y3/WBMfvetFg8 M3fC33A7V6MF5uiPbj7OJOrFKvhlsjsIVgGQ1omF0TACbHzfo1D0bm5dQUpN+mucGxtw H5ezi7COnXPjiZuyTivQAq4fsfQO14QLk5d6E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=R1ieMmNvPsLSIEIUas6x+6gg75akbaOgy91Trj5y2JlT/JrorB8nuiFXSosktEp6AE qH8pXY7sPTHUbNY54TpiSjaVqDeJ75yVVIfuzH7vcAPsfP31FwSRjBKiaKrFQ8fGuHXr kCIbIic3tdKstnM7zqabKM6zltJHdrxhHyd9w= MIME-Version: 1.0 Received: by 10.100.172.16 with SMTP id u16mr1870275ane.85.1242242726863; Wed, 13 May 2009 12:25:26 -0700 (PDT) In-Reply-To: <5859850b0905131133l32a43cd2k8eecc695dc175a3a@mail.gmail.com> References: <5859850b0905131133l32a43cd2k8eecc695dc175a3a@mail.gmail.com> Date: Wed, 13 May 2009 15:25:26 -0400 Message-ID: <4ad871310905131225q488736e3s292d3e4e63bf00c9@mail.gmail.com> From: Glen Barber To: =?ISO-8859-1?Q?Sylvio_C=E9sar_Teixeira_Amorim?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-acpi@freebsd.org Subject: Re: Hi Guys 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, 13 May 2009 19:54:46 -0000 2009/5/13 Sylvio C=E9sar Teixeira Amorim : > I have one laptop Dell Latitude E4300 with FreeBSD-8-Current, The > temperature of the processor is very high when I'm compiling the kernel, = I > get to stay with 88 Celsius, how do I force a download this temperature? > You could try throttling the CPU during the build, however this will make the build take longer. man powerd(8) --=20 Glen Barber From owner-freebsd-acpi@FreeBSD.ORG Wed May 13 20:06:41 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 3C46B106567D for ; Wed, 13 May 2009 20:06:41 +0000 (UTC) (envelope-from saifi.khan@twincling.org) Received: from s217.sureserver.com (s217.sureserver.com [203.194.200.22]) by mx1.freebsd.org (Postfix) with ESMTP id 710558FC2C for ; Wed, 13 May 2009 20:06:40 +0000 (UTC) (envelope-from saifi.khan@twincling.org) Received: (qmail 28392 invoked by uid 1002); 13 May 2009 19:39:58 -0000 Received: from unknown (HELO ?10.10.10.9?) (saifi.khan@twincling.org@59.92.188.48) by s217.sureserver.com with ESMTPA; 13 May 2009 19:39:58 -0000 Date: Thu, 14 May 2009 01:12:50 +0000 (GMT) From: Saifi Khan X-X-Sender: saifi@localhost To: =?ISO-8859-1?Q?Sylvio_C=E9sar_Teixeira_Amorim?= In-Reply-To: <5859850b0905131133l32a43cd2k8eecc695dc175a3a@mail.gmail.com> Message-ID: References: <5859850b0905131133l32a43cd2k8eecc695dc175a3a@mail.gmail.com> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="8323328-454477744-1242263570=:8671" Cc: freebsd-acpi@freebsd.org Subject: Re: Hi Guys 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, 13 May 2009 20:06:41 -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. --8323328-454477744-1242263570=:8671 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN Content-Transfer-Encoding: 8BIT On Wed, 13 May 2009, Sylvio Csar Teixeira Amorim wrote: > I have one laptop Dell Latitude E4300 with FreeBSD-8-Current, The > temperature of the processor is very high when I'm compiling the kernel, I > get to stay with 88 Celsius, how do I force a download this temperature? > > Att, > Sylvio Cesar. > It seems many people have experienced this issue. http://forum.notebookreview.com/showthread.php?p=4805607 Can an additional external fan/blower be of some help ? It's a sleek device and this points to heat dissipation system. thanks Saifi. --8323328-454477744-1242263570=:8671-- From owner-freebsd-acpi@FreeBSD.ORG Wed May 13 20:08:30 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 7589410656DC for ; Wed, 13 May 2009 20:08:30 +0000 (UTC) (envelope-from oberman@es.net) Received: from mailgw.es.net (mail1.es.net [IPv6:2001:400:201:1::2]) by mx1.freebsd.org (Postfix) with ESMTP id 60AAF8FC1C for ; Wed, 13 May 2009 20:08:30 +0000 (UTC) (envelope-from oberman@es.net) Received: from ptavv.es.net (ptavv.es.net [IPv6:2001:400:910::29]) by mailgw.es.net (8.14.3/8.14.3) with ESMTP id n4DK8O3q015892 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 13 May 2009 13:08:24 -0700 Received: from ptavv.es.net (ptavv.es.net [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id ECB7F1CC0B; Wed, 13 May 2009 13:08:23 -0700 (PDT) To: =?ISO-8859-1?Q?Sylvio_C=E9sar_Teixeira_Amorim?= In-reply-to: Your message of "Wed, 13 May 2009 15:33:42 -0300." <5859850b0905131133l32a43cd2k8eecc695dc175a3a@mail.gmail.com> Date: Wed, 13 May 2009 13:08:23 -0700 From: "Kevin Oberman" Message-Id: <20090513200823.ECB7F1CC0B@ptavv.es.net> Cc: freebsd-acpi@freebsd.org Subject: Re: Hi Guys 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, 13 May 2009 20:08:30 -0000 > Date: Wed, 13 May 2009 15:33:42 -0300 > From: =?ISO-8859-1?Q?Sylvio_C=E9sar_Teixeira_Amorim?= > Sender: owner-freebsd-acpi@freebsd.org > > I have one laptop Dell Latitude E4300 with FreeBSD-8-Current, The > temperature of the processor is very high when I'm compiling the kernel, I > get to stay with 88 Celsius, how do I force a download this temperature? Probably the first place to start is to clean the heat sink on your laptop. Simply opening the unit and blowing it out with compressed air can drop CPU temperature by over 10 degrees Celsius. This is probably something that should be done at least annually and more often if the laptop is run in dusty locations, such as sitting on a bed or table covered with a table cloth. It is also possible that the heatsink is not properly attached to the CPU. Several people have reported that cleaning and re-applying heatsink grease greatly improved the temperature. Next, take a look at the values of _PSV and _CRT. (sysctl hw.acpi). If PSV is higher than 88, your system is still within normal operating temperatures. For example, Pentium-M chips are speced to run at a steady temperature of 100C. _PSV on my laptop is 94.5C and _CRT is 99.0C. This means that the system does not start doing anything beyond normal fan cooling until the CPU reaches 94.5C and will reach 99C before starting to shutdown. (This is different from the emergency crowbar shutdown which is for thermal spikes of about 130-150C which might occur when a heatsink becomes dislodged.) When _PSV is reached, the system should simply slow down until the temperature drops. There is hysteresis to keep it from continually cycling. I don't recall numbers, though. If you want to lower the temperature "manually", you can kill powerd (/etc/rc.d/powerd stop) and set the CPU frequency lower. (sysctl dev.cpu.?.freq) where '?' is the CPU number. The available frequencies may be found in sysctl dev.cpu.0.freq_levels. If you are doing the manually, be sure to adjust all CPUs to the same frequency. Finally, placing the system on a surface that leaves an air gap under the system will help, too. Running it on a soft surface inhibits convection cooling and most soft surfaces are pretty goods thermal insulators. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 From owner-freebsd-acpi@FreeBSD.ORG Wed May 13 20:11: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 B43821065677 for ; Wed, 13 May 2009 20:11:58 +0000 (UTC) (envelope-from scjamorim@bsd.com.br) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.27]) by mx1.freebsd.org (Postfix) with ESMTP id 513788FC08 for ; Wed, 13 May 2009 20:11:58 +0000 (UTC) (envelope-from scjamorim@bsd.com.br) Received: by ey-out-2122.google.com with SMTP id 9so287372eyd.7 for ; Wed, 13 May 2009 13:11:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.210.130.14 with SMTP id c14mr729825ebd.81.1242245517390; Wed, 13 May 2009 13:11:57 -0700 (PDT) In-Reply-To: References: <5859850b0905131133l32a43cd2k8eecc695dc175a3a@mail.gmail.com> Date: Wed, 13 May 2009 17:11:57 -0300 Message-ID: <5859850b0905131311qb49622evf49fb4b2f50aefce@mail.gmail.com> From: =?ISO-8859-1?Q?Sylvio_C=E9sar_Teixeira_Amorim?= To: Saifi Khan Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-acpi@freebsd.org Subject: Re: Hi Guys 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, 13 May 2009 20:11:59 -0000 2009/5/13 Saifi Khan > On Wed, 13 May 2009, Sylvio C=E9sar Teixeira Amorim wrote: > > > I have one laptop Dell Latitude E4300 with FreeBSD-8-Current, The > > temperature of the processor is very high when I'm compiling the kernel= , > I > > get to stay with 88 Celsius, how do I force a download this temperature= ? > > > > Att, > > Sylvio Cesar. > > > > It seems many people have experienced this issue. > http://forum.notebookreview.com/showthread.php?p=3D4805607 > > Can an additional external fan/blower be of some help ? > It's a sleek device and this points to heat dissipation system. > No, I can't. > > > thanks > Saifi. --=20 -=3D-=3D-=3D-=3D-=3D-=3D-=3D- Live free or die - UNIX* -=3D-=3D-=3D-=3D-=3D= -=3D-=3D From owner-freebsd-acpi@FreeBSD.ORG Wed May 13 20:17: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 D6D17106564A for ; Wed, 13 May 2009 20:17:03 +0000 (UTC) (envelope-from scjamorim@bsd.com.br) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.25]) by mx1.freebsd.org (Postfix) with ESMTP id 5EA6C8FC13 for ; Wed, 13 May 2009 20:17:03 +0000 (UTC) (envelope-from scjamorim@bsd.com.br) Received: by ey-out-2122.google.com with SMTP id 9so288185eyd.7 for ; Wed, 13 May 2009 13:17:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.210.37.16 with SMTP id k16mr1766861ebk.22.1242245822392; Wed, 13 May 2009 13:17:02 -0700 (PDT) In-Reply-To: <20090513200823.ECB7F1CC0B@ptavv.es.net> References: <5859850b0905131133l32a43cd2k8eecc695dc175a3a@mail.gmail.com> <20090513200823.ECB7F1CC0B@ptavv.es.net> Date: Wed, 13 May 2009 17:17:02 -0300 Message-ID: <5859850b0905131317i49342181n64773b0e8ff37022@mail.gmail.com> From: =?ISO-8859-1?Q?Sylvio_C=E9sar_Teixeira_Amorim?= To: Kevin Oberman Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-acpi@freebsd.org Subject: Re: Hi Guys 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, 13 May 2009 20:17:04 -0000 Kevin, my laptop is Intel Core 2 duo 2.26, FSB 1066Mhz, DDR3. my sysctl hw.acipi.thermal.tz0._PSV: -1 hw.acipi.thermal.tz0._CRT: 107.0C 2009/5/13 Kevin Oberman > > Date: Wed, 13 May 2009 15:33:42 -0300 > > From: =?ISO-8859-1?Q?Sylvio_C=E9sar_Teixeira_Amorim?= < > scjamorim@bsd.com.br> > > Sender: owner-freebsd-acpi@freebsd.org > > > > I have one laptop Dell Latitude E4300 with FreeBSD-8-Current, The > > temperature of the processor is very high when I'm compiling the kernel, > I > > get to stay with 88 Celsius, how do I force a download this temperature? > > Probably the first place to start is to clean the heat sink on your > laptop. Simply opening the unit and blowing it out with compressed air > can drop CPU temperature by over 10 degrees Celsius. This is probably > something that should be done at least annually and more often if the > laptop is run in dusty locations, such as sitting on a bed or table > covered with a table cloth. > > It is also possible that the heatsink is not properly attached to the > CPU. Several people have reported that cleaning and re-applying heatsink > grease greatly improved the temperature. > > Next, take a look at the values of _PSV and _CRT. (sysctl hw.acpi). If > PSV is higher than 88, your system is still within normal operating > temperatures. For example, Pentium-M chips are speced to run at a steady > temperature of 100C. _PSV on my laptop is 94.5C and _CRT is 99.0C. This > means that the system does not start doing anything beyond normal fan > cooling until the CPU reaches 94.5C and will reach 99C before starting > to shutdown. (This is different from the emergency crowbar shutdown > which is for thermal spikes of about 130-150C which might occur when a > heatsink becomes dislodged.) > > When _PSV is reached, the system should simply slow down until the > temperature drops. There is hysteresis to keep it from continually > cycling. I don't recall numbers, though. > > If you want to lower the temperature "manually", you can kill powerd > (/etc/rc.d/powerd stop) and set the CPU frequency lower. (sysctl > dev.cpu.?.freq) where '?' is the CPU number. The available frequencies > may be found in sysctl dev.cpu.0.freq_levels. If you are doing the > manually, be sure to adjust all CPUs to the same frequency. > > Finally, placing the system on a surface that leaves an air gap under > the system will help, too. Running it on a soft surface inhibits > convection cooling and most soft surfaces are pretty goods thermal > insulators. > -- > R. Kevin Oberman, Network Engineer > Energy Sciences Network (ESnet) > Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) > E-mail: oberman@es.net Phone: +1 510 486-8634 > Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 > -- -=-=-=-=-=-=-=- Live free or die - UNIX* -=-=-=-=-=-=-= From owner-freebsd-acpi@FreeBSD.ORG Wed May 13 20:44:05 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 808B61065672 for ; Wed, 13 May 2009 20:44:05 +0000 (UTC) (envelope-from spawk@acm.poly.edu) Received: from acm.poly.edu (acm.poly.edu [128.238.9.200]) by mx1.freebsd.org (Postfix) with ESMTP id 1E8AC8FC14 for ; Wed, 13 May 2009 20:44:04 +0000 (UTC) (envelope-from spawk@acm.poly.edu) Received: (qmail 87928 invoked from network); 13 May 2009 20:17:23 -0000 Received: from unknown (HELO ?10.0.0.135?) (spawk@128.238.64.31) by acm.poly.edu with AES256-SHA encrypted SMTP; 13 May 2009 20:17:23 -0000 Message-ID: <4A0B2A84.9030809@acm.poly.edu> Date: Wed, 13 May 2009 16:16:04 -0400 From: Boris Kochergin User-Agent: Thunderbird 2.0.0.19 (X11/20090108) MIME-Version: 1.0 To: =?ISO-8859-1?Q?Sylvio_C=E9sar_Teixeira_Amorim?= References: <5859850b0905131133l32a43cd2k8eecc695dc175a3a@mail.gmail.com> In-Reply-To: <5859850b0905131133l32a43cd2k8eecc695dc175a3a@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-acpi@freebsd.org Subject: Re: Hi Guys 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, 13 May 2009 20:44:05 -0000 Sylvio Csar Teixeira Amorim wrote: > I have one laptop Dell Latitude E4300 with FreeBSD-8-Current, The > temperature of the processor is very high when I'm compiling the kernel, I > get to stay with 88 Celsius, how do I force a download this temperature? > > Att, > > Sylvio Cesar. > > > > The short thread at http://lists.freebsd.org/pipermail/freebsd-current/2008-November/000299.html might be useful, both for the patch to introduce a debug.cpufreq.highest sysctl, which you can use in conjunction with powerd(8) to prevent the system from being clocked higher than a particular frequency, and for the instructions on how to override the passive cooling threshold. -Boris From owner-freebsd-acpi@FreeBSD.ORG Wed May 13 23:39:57 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 ABF891065670; Wed, 13 May 2009 23:39:56 +0000 (UTC) (envelope-from nate@root.org) Received: from fulgencio.claresco.com (209-128-117-004.bayarea.net [209.128.117.4]) by mx1.freebsd.org (Postfix) with ESMTP id 8B7348FC16; Wed, 13 May 2009 23:39:55 +0000 (UTC) (envelope-from nate@root.org) Received: from [10.0.8.5] (fw.claresco.com [209.128.117.3]) by fulgencio.claresco.com (Postfix) with ESMTP id 66E21133F35; Wed, 13 May 2009 14:55:14 -0700 (PDT) Message-ID: <4A0B43DC.9060708@root.org> Date: Wed, 13 May 2009 15:04:12 -0700 From: Nate Lawson User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Ian Smith References: <49FE1826.4060000@FreeBSD.org> <4A07BC4D.7080604@freebsd.org> <4A081868.6010906@FreeBSD.org> <3a142e750905111308o62a11c8em5465ea9aa1cfaebc@mail.gmail.com> <4A08B10E.4040702@FreeBSD.org> <1242110455.2664.9.camel@slate01> <20090512182420.K46325@sola.nimnet.asn.au> In-Reply-To: <20090512182420.K46325@sola.nimnet.asn.au> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Alexander Motin , freebsd-mobile@freebsd.org, Gary Dunn , FreeBSD-Current , "Paul B. Mahol" , FreeBSD acpi Subject: Re: Fighting for the power. 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, 13 May 2009 23:39:58 -0000 Ian Smith wrote: > On Mon, 11 May 2009, Gary Dunn wrote: > > On Tue, 2009-05-12 at 02:13 +0300, Alexander Motin wrote: > > ... > > > > > > What's about general effect, the main idea here is the same as in audio > > > processing: result mostly depends on quality of the worst component. > > > Your system may just have some other consumers which I don't have. For > > > example, desktop CPU instead of mobile, desktop chipset instead of > > > mobile, powerful external video instead of (or even in addition to) > > > built-in, and so on. > > > > > > > Interesting point. Is there a power consumption benchmark for evaluating > > hardware for use with FreeBSD? > > make buildworld, running on battery? :-) > > More seriously: thanks to Nate's earlier niggling, I've been thinking > towards a richer set of power profiles than our {performance,economy} > dichotomy for a while, both in terms of various different work/play and > AC/battery scenarious, and re specific settings that may be more or less > optimal for particular hardware, that could be distributed or advised as > more of a basic working set rather than as a series of 'try this' hints. > FYI, Cyrille Szymanski has implemented a patch to add this kind of power profile support to powerd(8). I'd like to see it finished and committed. -- Nate From owner-freebsd-acpi@FreeBSD.ORG Thu May 14 00:36:35 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 4A8F3106564A for ; Thu, 14 May 2009 00:36:35 +0000 (UTC) (envelope-from gaijin.k@gmail.com) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.24]) by mx1.freebsd.org (Postfix) with ESMTP id F03778FC18 for ; Thu, 14 May 2009 00:36:34 +0000 (UTC) (envelope-from gaijin.k@gmail.com) Received: by qw-out-2122.google.com with SMTP id 3so701788qwe.7 for ; Wed, 13 May 2009 17:36:34 -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=UaUnle8p/AN/2NnpxpTixLdLtQk1DI4ZSEkgtdpU1mw=; b=bKwcBqe4+J3Cpg9zlcTiqb2rhvkd2rr/3KVWhOu1j10oyTEdK5JTvKhtAMvBge8b4s h6VZjA+szR9U4qyOtG0Vh5sqf8Hep5JlPSi5sCPJXZeW2SOe0+TWbN1RFIsZC0swMpop jFIlFpqvk0qO3bfe91/lBDf4AO11d/b5r0B1k= 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=tt/bmR3w8A46cHLSVmpJRB/cYKpguK2DXOrQTpnOSWWaDic7LCijVRROwVUVXk7eSZ H02DfmDiQQk/jTgwChOI8zM5/O4noDK6FQkBVrxORs6ek2QYmxSpe5ya04Y5gSSlEFmq hrjyrs037a3yOwbFIFwjIbe/mpfblQwMoPXTM= Received: by 10.224.11.72 with SMTP id s8mr2116391qas.138.1242261394242; Wed, 13 May 2009 17:36:34 -0700 (PDT) Received: from ?10.0.3.231? (pool-70-111-173-180.nwrk.east.verizon.net [70.111.173.180]) by mx.google.com with ESMTPS id 7sm1296579qwf.35.2009.05.13.17.36.32 (version=SSLv3 cipher=RC4-MD5); Wed, 13 May 2009 17:36:33 -0700 (PDT) From: "Alexandre \"Sunny\" Kovalenko" To: Sylvio =?ISO-8859-1?Q?C=E9sar?= Teixeira Amorim In-Reply-To: <5859850b0905131317i49342181n64773b0e8ff37022@mail.gmail.com> References: <5859850b0905131133l32a43cd2k8eecc695dc175a3a@mail.gmail.com> <20090513200823.ECB7F1CC0B@ptavv.es.net> <5859850b0905131317i49342181n64773b0e8ff37022@mail.gmail.com> Content-Type: text/plain; charset="UTF-8" Date: Wed, 13 May 2009 20:36:10 -0400 Message-Id: <1242261370.1192.10.camel@RabbitsDen> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 8bit Cc: freebsd-acpi@freebsd.org Subject: Re: Hi Guys 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, 14 May 2009 00:36:35 -0000 On Wed, 2009-05-13 at 17:17 -0300, Sylvio César Teixeira Amorim wrote: > Kevin, > > my laptop is Intel Core 2 duo 2.26, FSB 1066Mhz, DDR3. > my sysctl > > hw.acipi.thermal.tz0._PSV: -1 > hw.acipi.thermal.tz0._CRT: 107.0C Please, do not top-post -- it makes it harder to follow the thread. Do you by any chance have message to the tune of "acpi_tz0: _PSV value is absurd, ignored..." in you boot log? "grep absurd /var/log/messages" should give you the answer to this question. If answer is "yes" and you are willing to override your ASL, dump it according to the "Handbook" instructions and put it somewhere, I can get to it. As an alternative, you can add hw.acpi.thermal.tz0.passive_cooling=1 hw.acpi.thermal.user_override=1 hw.acpi.thermal.tz0._PSV=75C to /etc/sysctl.conf. This might or might not work as BIOS might tell OS to reevaluate _PSV and restore absurd value. You should replace 75C with the value you have in mind for your system. HTH, > > > > 2009/5/13 Kevin Oberman > > > > Date: Wed, 13 May 2009 15:33:42 -0300 > > > From: =?ISO-8859-1?Q?Sylvio_C=E9sar_Teixeira_Amorim?= < > > scjamorim@bsd.com.br> > > > Sender: owner-freebsd-acpi@freebsd.org > > > > > > I have one laptop Dell Latitude E4300 with FreeBSD-8-Current, The > > > temperature of the processor is very high when I'm compiling the kernel, > > I > > > get to stay with 88 Celsius, how do I force a download this temperature? > > > > Probably the first place to start is to clean the heat sink on your > > laptop. Simply opening the unit and blowing it out with compressed air > > can drop CPU temperature by over 10 degrees Celsius. This is probably > > something that should be done at least annually and more often if the > > laptop is run in dusty locations, such as sitting on a bed or table > > covered with a table cloth. > > > > It is also possible that the heatsink is not properly attached to the > > CPU. Several people have reported that cleaning and re-applying heatsink > > grease greatly improved the temperature. > > > > Next, take a look at the values of _PSV and _CRT. (sysctl hw.acpi). If > > PSV is higher than 88, your system is still within normal operating > > temperatures. For example, Pentium-M chips are speced to run at a steady > > temperature of 100C. _PSV on my laptop is 94.5C and _CRT is 99.0C. This > > means that the system does not start doing anything beyond normal fan > > cooling until the CPU reaches 94.5C and will reach 99C before starting > > to shutdown. (This is different from the emergency crowbar shutdown > > which is for thermal spikes of about 130-150C which might occur when a > > heatsink becomes dislodged.) > > > > When _PSV is reached, the system should simply slow down until the > > temperature drops. There is hysteresis to keep it from continually > > cycling. I don't recall numbers, though. > > > > If you want to lower the temperature "manually", you can kill powerd > > (/etc/rc.d/powerd stop) and set the CPU frequency lower. (sysctl > > dev.cpu.?.freq) where '?' is the CPU number. The available frequencies > > may be found in sysctl dev.cpu.0.freq_levels. If you are doing the > > manually, be sure to adjust all CPUs to the same frequency. > > > > Finally, placing the system on a surface that leaves an air gap under > > the system will help, too. Running it on a soft surface inhibits > > convection cooling and most soft surfaces are pretty goods thermal > > insulators. > > -- > > R. Kevin Oberman, Network Engineer > > Energy Sciences Network (ESnet) > > Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) > > E-mail: oberman@es.net Phone: +1 510 486-8634 > > Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 > > > > > -- Alexandre Kovalenko (Олександр Коваленко) From owner-freebsd-acpi@FreeBSD.ORG Thu May 14 04:04: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 51812106564A for ; Thu, 14 May 2009 04:04:58 +0000 (UTC) (envelope-from oberman@es.net) Received: from mailgw.es.net (mail3.es.net [IPv6:2001:400:4c01::2]) by mx1.freebsd.org (Postfix) with ESMTP id 20BEE8FC0A for ; Thu, 14 May 2009 04:04:58 +0000 (UTC) (envelope-from oberman@es.net) Received: from ptavv.es.net (ptavv.es.net [IPv6:2001:400:910::29]) by mailgw.es.net (8.14.3/8.14.3) with ESMTP id n4E44swm011305 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 13 May 2009 21:04:55 -0700 Received: from ptavv.es.net (ptavv.es.net [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id 52AFA1CC0B; Wed, 13 May 2009 21:04:54 -0700 (PDT) To: "Alexandre \"Sunny\" Kovalenko" In-reply-to: Your message of "Wed, 13 May 2009 20:36:10 EDT." <1242261370.1192.10.camel@RabbitsDen> Date: Wed, 13 May 2009 21:04:54 -0700 From: "Kevin Oberman" Message-Id: <20090514040454.52AFA1CC0B@ptavv.es.net> Cc: freebsd-acpi@freebsd.org Subject: Re: Hi Guys 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, 14 May 2009 04:04:58 -0000 > From: "Alexandre \"Sunny\" Kovalenko" > Date: Wed, 13 May 2009 20:36:10 -0400 > > On Wed, 2009-05-13 at 17:17 -0300, Sylvio César Teixeira Amorim wrote: > > Kevin, > > > > my laptop is Intel Core 2 duo 2.26, FSB 1066Mhz, DDR3. > > my sysctl > > > > hw.acipi.thermal.tz0._PSV: -1 > > hw.acipi.thermal.tz0._CRT: 107.0C > > Please, do not top-post -- it makes it harder to follow the thread. > > Do you by any chance have message to the tune of > > "acpi_tz0: _PSV value is absurd, ignored..." > > in you boot log? "grep absurd /var/log/messages" should give you the > answer to this question. > > If answer is "yes" and you are willing to override your ASL, dump it > according to the "Handbook" instructions and put it somewhere, I can get > to it. > > As an alternative, you can add > > hw.acpi.thermal.tz0.passive_cooling=1 > hw.acpi.thermal.user_override=1 > hw.acpi.thermal.tz0._PSV=75C > > to /etc/sysctl.conf. This might or might not work as BIOS might tell OS > to reevaluate _PSV and restore absurd value. You should replace 75C with > the value you have in mind for your system. A Core2 Duo system can run VERY hot without a problem. You may note that _CRT is 107. That is possibly correct. Three 2.26 GHz chips, all P8400s, are speced at 105C. There is no thermal spec listed for the SP9300, though. In any case, 88C is certainly well within normal operating parameters for this processor, but you can certainly force _PSV to whatever you like. Just remember that it will slow the system by at least 12.5% and maybe more. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 From owner-freebsd-acpi@FreeBSD.ORG Thu May 14 05:12: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 4F032106564A; Thu, 14 May 2009 05:12:06 +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 B96668FC15; Thu, 14 May 2009 05:12:05 +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 n4E5Bt99042717; Thu, 14 May 2009 15:11:55 +1000 (EST) (envelope-from smithi@nimnet.asn.au) Date: Thu, 14 May 2009 15:11:54 +1000 (EST) From: Ian Smith To: Nate Lawson In-Reply-To: <4A0B43DC.9060708@root.org> Message-ID: <20090514145235.T46325@sola.nimnet.asn.au> References: <49FE1826.4060000@FreeBSD.org> <4A07BC4D.7080604@freebsd.org> <4A081868.6010906@FreeBSD.org> <3a142e750905111308o62a11c8em5465ea9aa1cfaebc@mail.gmail.com> <4A08B10E.4040702@FreeBSD.org> <1242110455.2664.9.camel@slate01> <20090512182420.K46325@sola.nimnet.asn.au> <4A0B43DC.9060708@root.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: Gary Dunn , Alexander Motin , "Paul B. Mahol" , FreeBSD acpi , freebsd-mobile@freebsd.org Subject: Re: Fighting for the power. 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, 14 May 2009 05:12:06 -0000 On Wed, 13 May 2009, Nate Lawson wrote: > Ian Smith wrote: > > On Mon, 11 May 2009, Gary Dunn wrote: > > > On Tue, 2009-05-12 at 02:13 +0300, Alexander Motin wrote: > > > ... > > > > > > > > What's about general effect, the main idea here is the same as in audio > > > > processing: result mostly depends on quality of the worst component. > > > > Your system may just have some other consumers which I don't have. For > > > > example, desktop CPU instead of mobile, desktop chipset instead of > > > > mobile, powerful external video instead of (or even in addition to) > > > > built-in, and so on. > > > > > > > > > > Interesting point. Is there a power consumption benchmark for evaluating > > > hardware for use with FreeBSD? > > > > make buildworld, running on battery? :-) > > > > More seriously: thanks to Nate's earlier niggling, I've been thinking > > towards a richer set of power profiles than our {performance,economy} > > dichotomy for a while, both in terms of various different work/play and > > AC/battery scenarious, and re specific settings that may be more or less > > optimal for particular hardware, that could be distributed or advised as > > more of a basic working set rather than as a series of 'try this' hints. > > > > FYI, Cyrille Szymanski has implemented a patch to add this kind of power > profile support to powerd(8). I'd like to see it finished and committed. Good to hear, thanks. I'd like to see where it's up to. PR? cheers, Ian [removed current@ cc as I'm not subscribed - add it back if relevant] From owner-freebsd-acpi@FreeBSD.ORG Fri May 15 01:33:38 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 7B376106566C for ; Fri, 15 May 2009 01:33:38 +0000 (UTC) (envelope-from mogunus@gmail.com) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.30]) by mx1.freebsd.org (Postfix) with ESMTP id 36ADC8FC0A for ; Fri, 15 May 2009 01:33:38 +0000 (UTC) (envelope-from mogunus@gmail.com) Received: by yx-out-2324.google.com with SMTP id 8so945379yxb.13 for ; Thu, 14 May 2009 18:33:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type:content-transfer-encoding; bh=IbA1M/OrtS9/Pid0l0773xXhpsg5egNs1B5F25HpLKw=; b=A2qSD6UaWi98WLg1SMwCEN6gv2qYOmZbrRS4/S/4W1iaZx4KYq7Llz0MOqB+lFBD86 K3jXAHU4H1rhPVi/4Z812XF1WIjikncnkHWRZZWnmIrPuETRETx0paQ3MGwMwYydgeCU tbBBmAOKnm/ayewqnhXQLBiUw48zQVibjdvq4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=SML+HBXQwL1NrUXcIR7leL8+mwBAXmNdyGQLsH1dmjPoJDF8esfFZQJMz4/HNuORHB CsYoU252KoiCr72aM1axqzuO79SA36cUbGp4VhoGCoT4zke2IJ9+f1pMG9cLEVj104uv 1GHh8t5Yg4ScDBxISUj2fPIEwMC52LcwJ9ixM= MIME-Version: 1.0 Received: by 10.151.124.1 with SMTP id b1mr4787561ybn.160.1242349390444; Thu, 14 May 2009 18:03:10 -0700 (PDT) Date: Thu, 14 May 2009 21:03:10 -0400 Message-ID: <24a7fa6d0905141803x2205621s5f99642ce61ae56b@mail.gmail.com> From: Marco Carmosino To: freebsd-acpi@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: suspend/resume, amd64, FreeBSD 7.2 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, 15 May 2009 01:33:38 -0000 Hello, I have been attempting to use suspend/resume on my desktop computer. I think it probably should work, since S3 suspend works fine under linux. This is the output of sysctl hw.acpi: hw.acpi.supported_sleep_state: S1 S3 S4 S5 hw.acpi.power_button_state: S5 hw.acpi.sleep_button_state: S1 hw.acpi.lid_switch_state: NONE hw.acpi.standby_state: S1 hw.acpi.suspend_state: S3 hw.acpi.sleep_delay: 1 hw.acpi.s4bios: 0 hw.acpi.verbose: 0 hw.acpi.disable_on_reboot: 0 hw.acpi.handle_reboot: 0 hw.acpi.cpu.cx_lowest: C1 this is my problem: [root@hydra /usr/home/mog]# acpiconf -s 1 acpiconf: request sleep type (1) failed: Operation not supported [root@hydra /usr/home/mog]# acpiconf -s 2 acpiconf: request sleep type (2) failed: Operation not supported [root@hydra /usr/home/mog]# acpiconf -s 3 acpiconf: request sleep type (3) failed: Operation not supported [root@hydra /usr/home/mog]# acpiconf -s 4 acpiconf: request sleep type (4) failed: Operation not supported [root@hydra /usr/home/mog]# acpiconf -s 5 acpiconf: invalid sleep type (5) There seem to be no other error messages, just "Operation not supported." This is confusing, because S3 is listed as supported, and I found http://lists.freebsd.org/pipermail/freebsd-amd64/2009-March/011982.html this thread from back in march saying that amd64 suspend code has been committed. Here is my ASL file: http://mogunate.org/mogunus-desktop.asl I built the system myself from parts on newegg. My motherboard is an asus p5n32-SLI SE deluxe, I am running a core 2 duo processor. This is my first time running FreeBSD. If there is any way I can help getting suspend to work, please let me know. Thanks, Mog From owner-freebsd-acpi@FreeBSD.ORG Fri May 15 06:48:05 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 2DC831065690 for ; Fri, 15 May 2009 06:48:05 +0000 (UTC) (envelope-from klingfon@gmail.com) Received: from mail-ew0-f159.google.com (mail-ew0-f159.google.com [209.85.219.159]) by mx1.freebsd.org (Postfix) with ESMTP id 851D88FC17 for ; Fri, 15 May 2009 06:48:04 +0000 (UTC) (envelope-from klingfon@gmail.com) Received: by ewy3 with SMTP id 3so2108948ewy.43 for ; Thu, 14 May 2009 23:48:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=VsnEF1oAnXK3sif8rcVFTSjHuxMsy4Y8cbJyAVqM7z4=; b=ElDIX+CiY4OtiVRul1yMV3mQAEkt+4JH2YY/zAwoQeWeWj4zxDqPEQTCRdXx9yLFrG RuxufsX2TyPkaH/Cdu87y0z1+0ruRovKmgQKaJvwu7GbXix4w843qlZDXuSGehmOMsVF h1RFti7y/TZ9jhziVZsdxQ6JaZRbpkM0kGjTI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=m0duKxToMPbD7DaGSpK0CGWp0YBe9++TneE6pbLGPt4l5vi2QEUOeG+qwwKoT+6+3R 9T1pYxUGnizqnsnqhzmdg6WpPextu0meF2Yxykr3WWizzlsUpV2Li2+d0ASmGX/Lwjzf o46aEQ1xHAFlV5rtgl8jtRBSml7s7meLeYTBI= MIME-Version: 1.0 Received: by 10.216.39.194 with SMTP id d44mr1147586web.116.1242370083495; Thu, 14 May 2009 23:48:03 -0700 (PDT) In-Reply-To: <200905111425.01887.jhb@freebsd.org> References: <43b1bb350904230622u4b7790f0p9f665b649c97a3b@mail.gmail.com> <200905011450.13899.jhb@freebsd.org> <43b1bb350905011230p1372e1ffw5ab61985e7672e19@mail.gmail.com> <200905111425.01887.jhb@freebsd.org> Date: Fri, 15 May 2009 08:48:03 +0200 Message-ID: <43b1bb350905142348u7b8385acjd2ff4ca1ac4da9d5@mail.gmail.com> From: Magnus Kling To: freebsd-acpi@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: Fwd: Kernel panic on 7.2-RC1 when booting with ACPI enabled kernel. 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, 15 May 2009 06:48:05 -0000 2009/5/11 John Baldwin > On Friday 01 May 2009 3:30:28 pm Magnus Kling wrote: > > 2009/5/1 John Baldwin > > > > > On Friday 01 May 2009 2:30:28 pm Magnus Kling wrote: > > > > 2009/4/30 John Baldwin > > > > > > > > > On Saturday 25 April 2009 6:27:23 am Magnus Kling wrote: > > > > > > 2009/4/24 John Baldwin > > > > > > > Can you do 'frame 10' followed by 'p *(struct acpi_pci_devinf= o > > > > > > > *)child->ivars' > > > > > > > > > > > > > > -- > > > > > > > John Baldwin > > > > > > > > > > > > > > > > > > Sure, no problem. This is a none critical server so I can do al= ot > of > > > > > > debugging and testing if that is needed. > > > > > > > > > > > > > > > > > > (kgdb) frame 10 > > > > > > #10 0xc0db4ca8 in acpi_pci_child_location_str_method > > > (cbdev=3D0xc2212680, > > > > > > child=3D0xc2243400, buf=3D0xc22c2400 "slot=3D0 function=3D0= handle=3D", > > > > > > buflen=3D1024) > > > > > > at > > > /usr/src/sys/modules/acpi/acpi/../../../dev/acpica/acpi_pci.c:150 > > > > > > 150 strlcat(buf, acpi_name(dinfo->ap_handle), > buflen); > > > > > > > > > > > > (kgdb) p *(struct acpi_pci_devinfo *)child->ivars > > > > > > $1 =3D {ap_dinfo =3D {pci_links =3D {stqe_next =3D 0xc0b00f8c},= resources > =3D { > > > > > > stqh_first =3D 0xc0b00f8c, stqh_last =3D 0x1030000}, cfg = =3D {dev > =3D > > > 0x0, > > > > > > bar =3D {4, 0, 0, 3257136600, 0, 0}, bios =3D 0, subvendo= r =3D 0, > > > > > > subdevice =3D 0, vendor =3D 0, device =3D 0, cmdreg =3D 0= , statreg > =3D 0, > > > > > > baseclass =3D 0 '\0', subclass =3D 0 '\0', progif =3D 0 '= \0', > revid =3D > > > 0 > > > > > > > > > > Hmm, this is all completely wrong and trashed. What if you do 'p > > > *child'? > > > > > > > > > > -- > > > > > John Baldwin > > > > > > > > > (kgdb) p *child > > > > $2 =3D {ops =3D 0xc2161800, link =3D {tqe_next =3D 0xc2243380, tqe_= prev =3D > > > > 0xc2243484}, devlink =3D {tqe_next =3D 0xc2243380, tqe_prev =3D > 0xc224348c}, > > > > parent =3D 0xc2212680, children =3D {tqh_first =3D 0xc2262880, tq= h_last =3D > > > > 0xc2262704}, driver =3D 0xc0b7066c, devclass =3D 0xc211e240, unit = =3D 0, > > > > nameunit =3D 0xc2241640 "atapci0", desc =3D 0xc223f900 "Promise > PDC20621 > > > > UDMA100 controller", busy =3D 0, state =3D DS_ATTACHED, devflags = =3D 0, > > > > flags =3D 13, order =3D 0 '\0', pad =3D 0 '\0', ivars =3D 0xc223f= 5c0, softc > =3D > > > > 0xc2244800, sysctl_ctx =3D {tqh_first =3D 0xc2264380, tqh_last =3D > 0xc2241594}, > > > > sysctl_tree =3D 0xc223f840} > > > > (kgdb) > > > > > > Maybe try adding KTR traces for all calls to device_set_ivars(). I > wonder > > > if > > > something is trashing this device's ivars. > > > > > > Oh, dear. The ata(4) driver overwrites the ivars of some PCI devices > it > > > attaches to. This is very, very wrong. Which ATA controller do you > have? > > > > > > -- > > > John Baldwin > > > > > > > Aha, I=B4m using a Promise Fasttrack SX4000 for a RAID1 setup. And the = one > > included on the motherboard for the OS. > > And yes, I can confirm that without the Fasttrack SX4000 the system boo= ts > up > > correctly. (Pulled out the card and edited fstab.) > > So you are right regarding that the ata driver messes something up. Do > you > > contact someone that is responsible for ata driver? > > > > Thank you for taking the time to "correct" this, > > Can you please try this patch? > > --- //depot/vendor/freebsd/src/sys/dev/ata/ata-pci.h 2009/03/30 22:20:= 14 > +++ //depot/user/jhb/acpipci/dev/ata/ata-pci.h 2009/05/08 20:27:43 > @@ -66,6 +66,7 @@ > void (*function)(void *); > void *argument; > } interrupt[8]; /* XXX SOS max ch# for now */ > + void *chipset_data; > }; > > /* defines for known chipset PCI id's */ > --- //depot/vendor/freebsd/src/sys/dev/ata/chipsets/ata-acard.c 2009/02/1= 9 > 00:35:16 > +++ //depot/user/jhb/acpipci/dev/ata/chipsets/ata-acard.c 2009/05/0= 8 > 20:27:43 > @@ -51,6 +51,12 @@ > #include > #include > > +struct ata_serialize { > + struct mtx locked_mtx; > + int locked_ch; > + int restart_ch; > +}; > + > /* local prototypes */ > static int ata_acard_chipinit(device_t dev); > static int ata_acard_ch_attach(device_t dev); > @@ -58,6 +64,7 @@ > static void ata_acard_850_setmode(device_t dev, int mode); > static void ata_acard_86X_setmode(device_t dev, int mode); > static int ata_serialize(device_t dev, int flags); > +static void ata_serialize_init(struct ata_serialize *serial); > > /* misc defines */ > #define ATP_OLD 1 > @@ -93,6 +100,7 @@ > ata_acard_chipinit(device_t dev) > { > struct ata_pci_controller *ctlr =3D device_get_softc(dev); > + struct ata_serialize *serial; > > if (ata_setup_interrupt(dev, ata_generic_intr)) > return ENXIO; > @@ -100,8 +108,12 @@ > ctlr->ch_attach =3D ata_acard_ch_attach; > ctlr->ch_detach =3D ata_pci_ch_detach; > if (ctlr->chip->cfg1 =3D=3D ATP_OLD) { > - ctlr->setmode =3D ata_acard_850_setmode; > + ctlr->setmode =3D ata_acard_850_setmode; > ctlr->locking =3D ata_serialize; > + serial =3D malloc(sizeof(struct ata_serialize), > + M_TEMP, M_WAITOK | M_ZERO); > + ata_serialize_init(serial); > + ctlr->chipset_data =3D serial; > } > else > ctlr->setmode =3D ata_acard_86X_setmode; > @@ -225,11 +237,14 @@ > /* we could set PIO mode timings, but we assume the BIOS did that */ > } > > -struct ata_serialize { > - struct mtx locked_mtx; > - int locked_ch; > - int restart_ch; > -}; > +static void > +ata_serialize_init(struct ata_serialize *serial) > +{ > + > + mtx_init(&serial->locked_mtx, "ATA serialize lock", NULL, MTX_DEF); > + serial->locked_ch =3D -1; > + serial->restart_ch =3D -1; > +} > > static int > ata_serialize(device_t dev, int flags) > @@ -237,20 +252,9 @@ > struct ata_pci_controller *ctlr =3D > device_get_softc(device_get_parent(dev)); > struct ata_channel *ch =3D device_get_softc(dev); > struct ata_serialize *serial; > - static int inited =3D 0; > int res; > > - if (!inited) { > - serial =3D malloc(sizeof(struct ata_serialize), > - M_TEMP, M_NOWAIT | M_ZERO); > - mtx_init(&serial->locked_mtx, "ATA serialize lock", NULL, MTX_DEF= ); > - serial->locked_ch =3D -1; > - serial->restart_ch =3D -1; > - device_set_ivars(ctlr->dev, serial); > - inited =3D 1; > - } > - else > - serial =3D device_get_ivars(ctlr->dev); > + serial =3D ctlr->chipset_data; > > mtx_lock(&serial->locked_mtx); > switch (flags) { > --- //depot/vendor/freebsd/src/sys/dev/ata/chipsets/ata-promise.c > 2009/03/30 22:20:14 > +++ //depot/user/jhb/acpipci/dev/ata/chipsets/ata-promise.c 2009/05/0= 8 > 20:27:43 > @@ -283,7 +283,7 @@ > mtx_init(&hpkt->mtx, "ATA promise HPKT lock", NULL, MTX_DEF); > TAILQ_INIT(&hpkt->queue); > hpkt->busy =3D 0; > - device_set_ivars(dev, hpkt); > + ctlr->chipset_data =3D hpkt; > ctlr->ch_attach =3D ata_promise_mio_ch_attach; > ctlr->ch_detach =3D ata_promise_mio_ch_detach; > ctlr->reset =3D ata_promise_mio_reset; > @@ -730,7 +730,7 @@ > case PR_SX4X: > > /* softreset channel ATA module */ > - hpktp =3D device_get_ivars(ctlr->dev); > + hpktp =3D ctlr->chipset_data; > ATA_OUTL(ctlr->r_res2, 0xc0260 + (ch->unit << 7), ch->unit + 1); > ata_udelay(1000); > ATA_OUTL(ctlr->r_res2, 0xc0260 + (ch->unit << 7), > @@ -1208,7 +1208,7 @@ > static void > ata_promise_queue_hpkt(struct ata_pci_controller *ctlr, u_int32_t hpkt) > { > - struct ata_promise_sx4 *hpktp =3D device_get_ivars(ctlr->dev); > + struct ata_promise_sx4 *hpktp =3D ctlr->chipset_data; > > mtx_lock(&hpktp->mtx); > if (hpktp->busy) { > @@ -1227,7 +1227,7 @@ > static void > ata_promise_next_hpkt(struct ata_pci_controller *ctlr) > { > - struct ata_promise_sx4 *hpktp =3D device_get_ivars(ctlr->dev); > + struct ata_promise_sx4 *hpktp =3D ctlr->chipset_data; > struct host_packet *hp; > > mtx_lock(&hpktp->mtx); > > -- > John Baldwin > This is only a response to everyone that is following this thread and have had the same errors as I have... and are looking for a solution. The patch will NOT work for FreeBSD 7.0 or 7.1. This patch www.freebsd.org/~jhb/patches/ata_ivars_7.patch. will WORK for FreeBSD 7. I have tried it with 7.1-RC2 and it works. John Baldwin will commit the bits to source at a later stage. (Said in an non-list email). /Magnus From owner-freebsd-acpi@FreeBSD.ORG Fri May 15 09:04: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 665471065675 for ; Fri, 15 May 2009 09:04:54 +0000 (UTC) (envelope-from ghostp@dzsy.org) Received: from s2.mcss.hu (s2.mcss.hu [87.229.26.185]) by mx1.freebsd.org (Postfix) with ESMTP id 285B08FC17 for ; Fri, 15 May 2009 09:04:53 +0000 (UTC) (envelope-from ghostp@dzsy.org) Received: from dzsy-note.dzsy.org (catv-89-133-19-82.catv.broadband.hu [89.133.19.82]) by s2.mcss.hu (Postfix) with ESMTP id ADA344E58F1 for ; Fri, 15 May 2009 11:04:50 +0200 (CEST) Message-ID: <4A0D3032.7060106@dzsy.org> Date: Fri, 15 May 2009 11:04:50 +0200 From: =?ISO-8859-1?Q?Sz=E9kv=F6lgyi_P=E9ter?= User-Agent: Thunderbird 2.0.0.21 (X11/20090501) MIME-Version: 1.0 To: freebsd-acpi@freebsd.org References: <4A05EA96.4090908@dzsy.org> In-Reply-To: <4A05EA96.4090908@dzsy.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: No brightness control on Acer laptop 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, 15 May 2009 09:04:54 -0000 Hi everyone, If i upgrade my system to CURRENT may be the brightness control working? I don't known better the ACPI support on CURRENT? Peter Szkvlgyi Pter wrote: > Hi everyone, > > I have a Acer Extensa 5620 laptop and i didn't change the brightness > with keys or sysctl value. > I loaded asus, ibm and other laptop acpi modul, but nothing change. > Anyone has an idea how > can i change the brightness fater the system booted? ( Without ACPI i > can change, the brightness. ) > > I send a PR too: > http://www.freebsd.org/cgi/query-pr.cgi?pr=132535 > > Now my system is: > FreeBSD dzsy-note.dzsy.org 7.2-STABLE FreeBSD 7.2-STABLE #0: Thu May 7 > 23:13:54 CEST 2009 ... i386 > > Thanks, > Peter > > > _______________________________________________ > freebsd-acpi@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-acpi > To unsubscribe, send any mail to "freebsd-acpi-unsubscribe@freebsd.org" From owner-freebsd-acpi@FreeBSD.ORG Fri May 15 13:01:56 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 04CF81065673 for ; Fri, 15 May 2009 13:01:56 +0000 (UTC) (envelope-from mickey242@gmx.net) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by mx1.freebsd.org (Postfix) with SMTP id 452FF8FC08 for ; Fri, 15 May 2009 13:01:54 +0000 (UTC) (envelope-from mickey242@gmx.net) Received: (qmail invoked by alias); 15 May 2009 12:35:13 -0000 Received: from brln-4d0c4f38.pool.mediaWays.net (EHLO gunhead.enforcer.cc) [77.12.79.56] by mail.gmx.net (mp004) with SMTP; 15 May 2009 14:35:13 +0200 X-Authenticated: #8913523 X-Provags-ID: V01U2FsdGVkX18RiuZiFNQR8la3n9/C4OrEfhqBYKr1sCgR5A4Z2p ZldrlNZAHwLj1J Message-ID: <4A0D617D.5070008@gmx.net> Date: Fri, 15 May 2009 14:35:09 +0200 From: Andreas Wetzel User-Agent: Thunderbird 2.0.0.21 (X11/20090407) MIME-Version: 1.0 To: freebsd-acpi@freebsd.org Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.58 Subject: ThinkPad T30, 7.2-RELEASE, wrong CPU speed detected? 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, 15 May 2009 13:01:56 -0000 After an upgrade from 7.1-RELEASE-p3 to 7.2-RELEASE, on an IBM ThinkPad T30: CPU: Mobile Intel(R) Pentium(R) 4 - M CPU 2.00GHz (1196.13-MHz 686-class CPU) ^^^^^^^ ^^^^^^^^ This seems not right. Additionally sysctl shows these: dev.cpu.0.freq: 1200 dev.cpu.0.freq_levels: 1200/0 1050/0 900/0 750/0 600/0 450/0 300/0 I know there has been some discussion going on a while ago, which suggested to not compile cpufreq into the kernel, which i will try in a few moments. Anyway, this does not seem right. -- Keep it icy man. I don't want to end up a corpse before my time because you were daydreaming. From owner-freebsd-acpi@FreeBSD.ORG Fri May 15 13:11:04 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 CC1BE1065670 for ; Fri, 15 May 2009 13:11:04 +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 9E7418FC24 for ; Fri, 15 May 2009 13:11:04 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 3475846C0F; Fri, 15 May 2009 09:11:04 -0400 (EDT) Received: from jhbbsd.hudson-trading.com (unknown [209.249.190.8]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 22D728A025; Fri, 15 May 2009 09:11:03 -0400 (EDT) From: John Baldwin To: freebsd-acpi@freebsd.org Date: Fri, 15 May 2009 08:02:54 -0400 User-Agent: KMail/1.9.7 References: <24a7fa6d0905141803x2205621s5f99642ce61ae56b@mail.gmail.com> In-Reply-To: <24a7fa6d0905141803x2205621s5f99642ce61ae56b@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200905150802.56267.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Fri, 15 May 2009 09:11:03 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=4.2 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: Subject: Re: suspend/resume, amd64, FreeBSD 7.2 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, 15 May 2009 13:11:05 -0000 On Thursday 14 May 2009 9:03:10 pm Marco Carmosino wrote: > There seem to be no other error messages, just "Operation not > supported." This is confusing, because S3 is listed as supported, and > I found http://lists.freebsd.org/pipermail/freebsd-amd64/2009-March/011982.html > this thread from back in march saying that amd64 suspend code has been > committed. It has only been committed to HEAD (aka 8.0). It is not present in 7.x. -- John Baldwin From owner-freebsd-acpi@FreeBSD.ORG Fri May 15 21:06: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 98B131065673 for ; Fri, 15 May 2009 21:06:59 +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 6D6CC8FC19 for ; Fri, 15 May 2009 21:06:59 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 2214F46BC5; Fri, 15 May 2009 17:06:59 -0400 (EDT) Received: from jhbbsd.hudson-trading.com (unknown [209.249.190.8]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 064078A026; Fri, 15 May 2009 17:06:58 -0400 (EDT) From: John Baldwin To: freebsd-acpi@freebsd.org Date: Fri, 15 May 2009 16:02:36 -0400 User-Agent: KMail/1.9.7 References: <4A0D617D.5070008@gmx.net> In-Reply-To: <4A0D617D.5070008@gmx.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200905151602.36747.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Fri, 15 May 2009 17:06:58 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=4.2 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: Subject: Re: ThinkPad T30, 7.2-RELEASE, wrong CPU speed detected? 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, 15 May 2009 21:07:00 -0000 On Friday 15 May 2009 8:35:09 am Andreas Wetzel wrote: > After an upgrade from 7.1-RELEASE-p3 to 7.2-RELEASE, on an IBM ThinkPad T30: > > > CPU: Mobile Intel(R) Pentium(R) 4 - M CPU 2.00GHz (1196.13-MHz 686-class CPU) > ^^^^^^^ ^^^^^^^^ > > This seems not right. > > Additionally sysctl shows these: > > dev.cpu.0.freq: 1200 > dev.cpu.0.freq_levels: 1200/0 1050/0 900/0 750/0 600/0 450/0 300/0 > > I know there has been some discussion going on a while ago, which suggested to > not compile cpufreq into the kernel, which i will try in a few moments. > Anyway, this does not seem right. Are you on battery? -- John Baldwin