From owner-freebsd-acpi@FreeBSD.ORG Sun Feb 3 10:52:16 2008 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 B4E5016A417 for ; Sun, 3 Feb 2008 10:52:16 +0000 (UTC) (envelope-from cihan@enderunix.org) Received: from istanbul.enderunix.org (freefall.marmara.edu.tr [193.140.143.23]) by mx1.freebsd.org (Postfix) with ESMTP id BB78613C43E for ; Sun, 3 Feb 2008 10:52:15 +0000 (UTC) (envelope-from cihan@enderunix.org) Received: (qmail 51829 invoked by uid 1040); 3 Feb 2008 10:24:16 -0000 Received: from unknown (HELO localhost) (cihan@85.105.200.118) by 0 with ESMTPA; 3 Feb 2008 10:24:15 -0000 Date: Sun, 3 Feb 2008 12:24:03 +0200 From: =?utf-8?B?Q2loYW4gS8O2bWXDp2/En2x1?= X-Mailer: The Bat! (v3.99.29) UNREG X-Priority: 3 (Normal) Message-ID: <406342466.20080203122403@enderunix.org> To: freebsd-acpi@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: quoted-printable X-Antivirus: avast! (VPS 080202-0, 02.02.2008), Outbound message X-Antivirus-Status: Clean X-SMTP-Filter: SurGATE SMTP Filter Engine Release 1.0.1 http://www.endersys.com X-SurGATE-Result: Clean (Content eval: -4.40 points) Subject: get mAh value in state file? 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: Sun, 03 Feb 2008 10:52:16 -0000 Dear list I have to write a c program which gets mAh value for battery energy measurement from state file. I need to know wheter ACPI send any signal or like when this values will be written to state file. That is , How can I know when this values will be written? And the second question , for file locking mechanism when I read this value from state file What do I have to use?(maybe flock function?) --=20 Cihan K=F6me=E7o=F0lu, EnderUNIX SDT mailto:cihan@enderunix.org From owner-freebsd-acpi@FreeBSD.ORG Sun Feb 3 19:50:05 2008 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 8BBB316A418 for ; Sun, 3 Feb 2008 19:50:05 +0000 (UTC) (envelope-from nate@root.org) Received: from root.org (root.org [67.118.192.226]) by mx1.freebsd.org (Postfix) with ESMTP id 603C013C46A for ; Sun, 3 Feb 2008 19:50:05 +0000 (UTC) (envelope-from nate@root.org) Received: (qmail 60166 invoked from network); 3 Feb 2008 19:50:05 -0000 Received: from ppp-71-139-22-142.dsl.snfc21.pacbell.net (HELO ?10.0.5.18?) (nate-mail@71.139.22.142) by root.org with ESMTPA; 3 Feb 2008 19:50:05 -0000 Message-ID: <47A61AE8.5030603@root.org> Date: Sun, 03 Feb 2008 11:50:00 -0800 From: Nate Lawson User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: =?UTF-8?B?Q2loYW4gS8O2bWXDp2/En2x1?= References: <406342466.20080203122403@enderunix.org> In-Reply-To: <406342466.20080203122403@enderunix.org> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-acpi@freebsd.org Subject: Re: get mAh value in state file? 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: Sun, 03 Feb 2008 19:50:05 -0000 Cihan Kömeçoğlu wrote: > Dear list > > I have to write a c program which gets mAh value for battery energy > measurement from state file. I need to know wheter ACPI send any signal > or like when this values will be written to state file. That is , How > can I know when this values will be written? > > And the second question , for file locking mechanism when I read this > value from state file What do I have to use?(maybe flock function?) > acpiconf -i flag is what you want, I think. Not sure if you mean current capacity or total. Also look at sysctl hw.acpi -- Nate From owner-freebsd-acpi@FreeBSD.ORG Mon Feb 4 11:06:54 2008 Return-Path: Delivered-To: freebsd-acpi@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 26CCA16A507 for ; Mon, 4 Feb 2008 11:06:54 +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 115A113C45D for ; Mon, 4 Feb 2008 11:06:54 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m14B6rLE017159 for ; Mon, 4 Feb 2008 11:06:53 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m14B6r1u017155 for freebsd-acpi@FreeBSD.org; Mon, 4 Feb 2008 11:06:53 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 4 Feb 2008 11:06:53 GMT Message-Id: <200802041106.m14B6r1u017155@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, 04 Feb 2008 11:06:54 -0000 Current FreeBSD problem reports Critical problems Serious problems S Tracker Resp. Description -------------------------------------------------------------------------------- o i386/54756 acpi ACPI suspend/resume problem on CF-W2 laptop o i386/55661 acpi ACPI suspend/resume problem on ARMADA M700 o kern/56024 acpi ACPI suspend drains battery while in S3 o i386/72566 acpi ACPI, FreeBSD disables fan on Compaq Armada 1750 o i386/79081 acpi ACPI suspend/resume not working on HP nx6110 o kern/81000 acpi [apic] Via 8235 sound card worked great with FreeBSD 5 s i386/91748 acpi acpi problem on Acer TravelMare 4652LMi (nvidia panic, o kern/102252 acpi acpi thermal does not work on Abit AW8D (intel 975) o kern/104625 acpi ACPI on ASUS A8N-32 SLI/ASUS P4P800 does not show ther o kern/106924 acpi [acpi] ACPI resume returns g_vfs_done() errors and ker o kern/108954 acpi [acpi] 'sleep(1)' sleeps >1 seconds when speedstep (Cx o kern/114113 acpi [acpi] [patch] ACPI kernel panic during S3 suspend / r o i386/114562 acpi [acpi] cardbus is dead after s3 on Thinkpad T43 with a o amd64/115011 acpi ACPI problem ,reboot system down. o kern/116939 acpi [acpi] PCI-to-PCI misconfigured for bus three and can o i386/117918 acpi HP dc5750 will only boot with ACPI disabled o bin/118973 acpi [acpi]: Kernel panic with acpi boot o kern/119200 acpi [acpi] Lid close switch suspends CPU for 1 second on H o kern/119356 acpi [acpi]: i386 ACPI wakeup not work due resource exhaust o i386/119485 acpi [hang] 6.3 RC2 boot only CD hangs in dell d830 - 'ACPI o kern/119716 acpi [acpi] vm_fault when trying to boot 7.0 ACPI on HP dc5 21 problems total. Non-critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/67309 acpi zzz reboot computer (ACPI S3) o i386/69750 acpi Boot without ACPI failed on ASUS L5 o i386/72179 acpi [acpi] [patch] Inconsistent apm(8) output regarding th s kern/73823 acpi [request] acpi / power-on by timer support o kern/76950 acpi ACPI wrongly blacklisted on Micron ClientPro 766Xi sys o kern/89411 acpi [acpi] acpiconf bug o kern/97383 acpi Volume buttons on IBM Thinkpad crash system with ACPI o kern/98171 acpi [acpi] ACPI 1304 / 0501 errors on Acer 5024WLMi Laptop o kern/103365 acpi [acpi] acpi poweroff doesn't work with geli device att o kern/105537 acpi [acpi] problems in acpi on HP Compaq nc6320 o kern/108017 acpi [acpi]: Acer Aspire 5600 o kern/108488 acpi [acpi] ACPI-1304: *** Error: Method execution failed o kern/108581 acpi [sysctl] sysctl: hw.acpi.cpu.cx_lowest: Invalid argume o kern/108695 acpi [acpi]: Fatal trap 9: general protection fault when in f bin/109760 acpi [acpi]: [modules] kldunload acpi_video - crash o kern/111591 acpi [acpi] dev.acpi_ibm.0.events returns I/O error (regres o kern/112544 acpi [acpi] [patch] Add High Precision Event Timer Driver f o kern/114165 acpi [acpi] Dell C810 - ACPI problem o kern/114649 acpi [patch][acpi] panic: recursed on non-recursive mutex o kern/117605 acpi [acpi] [request] add debug.cpufreq.highest 20 problems total. From owner-freebsd-acpi@FreeBSD.ORG Mon Feb 4 14:30:46 2008 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 3F06E16A418 for ; Mon, 4 Feb 2008 14:30:46 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 1EED913C4E3 for ; Mon, 4 Feb 2008 14:30:46 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from zion.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by elvis.mu.org (Postfix) with ESMTP id BF85F1A4D7E; Mon, 4 Feb 2008 06:30:45 -0800 (PST) From: John Baldwin To: freebsd-acpi@freebsd.org Date: Mon, 4 Feb 2008 09:00:54 -0500 User-Agent: KMail/1.9.7 References: <429F40B0-20EE-4F47-847A-A6B1E91BA79F@liveoaksf.org> <47A217FC.1080606@root.org> <8EE3D963-E390-4F45-A1D1-2295C1767B80@liveoaksf.org> In-Reply-To: <8EE3D963-E390-4F45-A1D1-2295C1767B80@liveoaksf.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200802040900.54630.jhb@freebsd.org> Cc: Tech Lab Manager Subject: Re: SMP, ACPI and interrupt storm 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, 04 Feb 2008 14:30:46 -0000 On Thursday 31 January 2008 02:35:52 pm Tech Lab Manager wrote: > On Jan 31, 2008, at 10:48 AM, Nate Lawson wrote: > > > Tech Lab Manager wrote: > >> Sorry for the cross-post from freebsd-smb. > >> Building 6.3-RELEASE and 7.0-RC1 on dual Xeon (4 CPU) boxes: > >> options SMP > >> device apic > >> SMP kernel builds fine, all 4 CPUs launch on reboot. > >> But I get a TON of interrupts from acpi0 -- about 67,000 per second > >> according to vmstat -i. With system at idle and almost no services > >> running, here is output of top -S: > >> last pid: 877; load averages: 1.18, 0.48, 0.19 > >> 75 processes: 6 running, 54 sleeping, 15 waiting > >> CPU states: 0.0% user, 0.0% nice, 0.2% system, 22.4% > >> interrupt, 77.4% idle > >> Mem: 31M Active, 12M Inact, 28M Wired, 16K Cache, 15M Buf, 3822M Free > >> Swap: 4096M Total, 4096M Free > >> PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU > >> COMMAND > >> 10 root 1 171 52 0K 8K RUN 3 1:11 99.18% > >> idle: cpu3 > >> 13 root 1 171 52 0K 8K CPU0 0 1:10 98.88% > >> idle: cpu0 > >> 12 root 1 171 52 0K 8K CPU1 1 1:09 98.78% > >> idle: cpu1 > >> 21 root 1 -52 -171 0K 8K CPU2 2 0:54 87.24% > >> irq9: acpi0 > >> 11 root 1 171 52 0K 8K RUN 2 0:17 11.19% > >> idle: cpu2 > >> Notice high load and interrupt % of CPU. > >> If turn off ACPI (e.g. set hint.apic.0.disabled=1 in /boot/ > >> loader.conf), > >> the interrupt storm ceases, but then I'm only running on one CPU. > > > > That doesn't turn off acpi, that turns of the APIC (interrupt > > controller). Try: > > hint.acpi.0.disabled=1 > > Sorry, my mistake in writing ACPI above -- I *was* trying to turn off > apic, based on a note in the FreeBSD handbook. > > Disabling ACPI as you suggest above has the same effect as turning > off APIC: the interrupt storm is disabled but only one CPU is launched. > > > > >> The BIOS ACPI settings are all Enabled. Hyperthreading is Enabled. > >> These machines have been running RedHat Enterprise 5.0 with full > >> multiprocessor support. > > > > This looks like a failure to sleep in C1 (hlt). Someone else > > reported this probably earlier, but all debugging showed the > > inexplicable -- the HLT instruction was being executed but just did > > not work (returned immediately). > > > > There will be a new 7.0 build that fixes one interrupt storm > > related to level-triggered GPEs. If you can cvsup your 7.0 branch > > (RELENG_7_0) and retry, that might be helpful to see if it also > > fixes your problem. > > okay, I'm on RC1, will switch to RELENG and report back. > > I'm not sure if this is a red herring, but acpidump -t reports: > > Type=INT Override > BUS=0 > IRQ=0 > INTR=2 > Flags={Polarity=conforming, Trigger=conforming} > > which looks wrong on several counts (IRQ, INTR should be 9, > Trigger=level). dmesg even says: > "MADT: Forcing active-low polarity and level trigger for SCI" No, this is an entry for something other than the SCI. You can have multiple interrupt override entries and this entry is typical on all x86 systems with APICs (the 8259As are tied into pin 0 as a daisy chain and IRQ0 is tied into intpin 2 since IRQ2 isn't usable with 8259As. Do you have an entry at all for IRQ 9? If not, then the hw.acpi.sci tunables currently won't do anything (I can fix it so that they do, however). -- John Baldwin From owner-freebsd-acpi@FreeBSD.ORG Mon Feb 4 17:25:40 2008 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 F001D16A46D for ; Mon, 4 Feb 2008 17:25:39 +0000 (UTC) (envelope-from tech@liveoaksf.org) Received: from assassin.liveoaksf.org (mail.liveoaksf.org [216.31.235.91]) by mx1.freebsd.org (Postfix) with SMTP id C8A7E13C467 for ; Mon, 4 Feb 2008 17:25:39 +0000 (UTC) (envelope-from tech@liveoaksf.org) Received: (qmail 63765 invoked by uid 1004); 4 Feb 2008 17:26:12 -0000 Received: from 192.168.1.45 by assassin.liveoaksf.org (envelope-from , uid 1002) with qmail-scanner-1.25-st-qms (clamdscan: 0.92/5575. spamassassin: 3.2.4. perlscan: 1.25-st-qms. Clear:RC:0(192.168.1.45):SA:0(-4.3/4.5):. Processed in 2.772656 secs); 04 Feb 2008 17:26:12 -0000 X-Spam-Status: No, hits=-4.3 required=4.5 X-Antivirus-LIVEOAKSF-Mail-From: tech@liveoaksf.org via assassin.liveoaksf.org X-Antivirus-LIVEOAKSF: 1.25-st-qms (Clear:RC:0(192.168.1.45):SA:0(-4.3/4.5):. Processed in 2.772656 secs Process 63758) Received: from unknown (HELO ?192.168.1.45?) (tech@liveoaksf.org@192.168.1.45) by assassin.liveoaksf.org with SMTP; 4 Feb 2008 17:26:09 -0000 In-Reply-To: <200802040900.54630.jhb@freebsd.org> References: <429F40B0-20EE-4F47-847A-A6B1E91BA79F@liveoaksf.org> <47A217FC.1080606@root.org> <8EE3D963-E390-4F45-A1D1-2295C1767B80@liveoaksf.org> <200802040900.54630.jhb@freebsd.org> Mime-Version: 1.0 (Apple Message framework v753) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <1756A487-5F0B-466D-921D-B9F6B6FF8E18@liveoaksf.org> Content-Transfer-Encoding: 7bit From: Tech Lab Manager Date: Mon, 4 Feb 2008 09:25:37 -0800 To: freebsd-acpi@freebsd.org X-Mailer: Apple Mail (2.753) Cc: Subject: Re: SMP, ACPI and interrupt storm 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, 04 Feb 2008 17:25:40 -0000 On Feb 4, 2008, at 6:00 AM, John Baldwin wrote: > On Thursday 31 January 2008 02:35:52 pm Tech Lab Manager wrote: >> On Jan 31, 2008, at 10:48 AM, Nate Lawson wrote: >> >>> Tech Lab Manager wrote: >>>> Sorry for the cross-post from freebsd-smb. >>>> Building 6.3-RELEASE and 7.0-RC1 on dual Xeon (4 CPU) boxes: >>>> options SMP >>>> device apic >>>> SMP kernel builds fine, all 4 CPUs launch on reboot. >>>> But I get a TON of interrupts from acpi0 -- about 67,000 per second >>>> according to vmstat -i. With system at idle and almost no services >>>> running, here is output of top -S: >>>> last pid: 877; load averages: 1.18, 0.48, 0.19 >>>> 75 processes: 6 running, 54 sleeping, 15 waiting >>>> CPU states: 0.0% user, 0.0% nice, 0.2% system, 22.4% >>>> interrupt, 77.4% idle >>>> Mem: 31M Active, 12M Inact, 28M Wired, 16K Cache, 15M Buf, 3822M >>>> Free >>>> Swap: 4096M Total, 4096M Free >>>> PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU >>>> COMMAND >>>> 10 root 1 171 52 0K 8K RUN 3 1:11 99.18% >>>> idle: cpu3 >>>> 13 root 1 171 52 0K 8K CPU0 0 1:10 98.88% >>>> idle: cpu0 >>>> 12 root 1 171 52 0K 8K CPU1 1 1:09 98.78% >>>> idle: cpu1 >>>> 21 root 1 -52 -171 0K 8K CPU2 2 0:54 87.24% >>>> irq9: acpi0 >>>> 11 root 1 171 52 0K 8K RUN 2 0:17 11.19% >>>> idle: cpu2 >>>> Notice high load and interrupt % of CPU. >>>> If turn off ACPI (e.g. set hint.apic.0.disabled=1 in /boot/ >>>> loader.conf), >>>> the interrupt storm ceases, but then I'm only running on one CPU. >>> >>> That doesn't turn off acpi, that turns of the APIC (interrupt >>> controller). Try: >>> hint.acpi.0.disabled=1 >> >> Sorry, my mistake in writing ACPI above -- I *was* trying to turn off >> apic, based on a note in the FreeBSD handbook. >> >> Disabling ACPI as you suggest above has the same effect as turning >> off APIC: the interrupt storm is disabled but only one CPU is >> launched. >> >>> >>>> The BIOS ACPI settings are all Enabled. Hyperthreading is Enabled. >>>> These machines have been running RedHat Enterprise 5.0 with full >>>> multiprocessor support. >>> >>> This looks like a failure to sleep in C1 (hlt). Someone else >>> reported this probably earlier, but all debugging showed the >>> inexplicable -- the HLT instruction was being executed but just did >>> not work (returned immediately). >>> >>> There will be a new 7.0 build that fixes one interrupt storm >>> related to level-triggered GPEs. If you can cvsup your 7.0 branch >>> (RELENG_7_0) and retry, that might be helpful to see if it also >>> fixes your problem. >> >> okay, I'm on RC1, will switch to RELENG and report back. >> >> I'm not sure if this is a red herring, but acpidump -t reports: >> >> Type=INT Override >> BUS=0 >> IRQ=0 >> INTR=2 >> Flags={Polarity=conforming, Trigger=conforming} >> >> which looks wrong on several counts (IRQ, INTR should be 9, >> Trigger=level). dmesg even says: >> "MADT: Forcing active-low polarity and level trigger for SCI" > > No, this is an entry for something other than the SCI. You can > have multiple > interrupt override entries and this entry is typical on all x86 > systems with > APICs (the 8259As are tied into pin 0 as a daisy chain and IRQ0 is > tied into > intpin 2 since IRQ2 isn't usable with 8259As. Do you have an entry > at all > for IRQ 9? If not, then the hw.acpi.sci tunables currently won't > do anything > (I can fix it so that they do, however). > Gotcha. (I'm really not much of a hardware guy so bear with me here. note: I csup'ed the RELENG_7_0 branch last Friday but no luck on this issue yet.) Anyway, I see no IRQ 9 entry in acpidump, which I guess would explain why the attempt to set SCI tunables has so apparent effect. # acpidump -t |less /* RSD PTR: OEM=ACPIAM, ACPI_Rev=1.0x (0) RSDT=0xf7ff0000, cksum=64 */ /* RSDT: Length=48, Revision=1, Checksum=38, OEMID=A M I, OEM Table ID=OEMRSDT, OEM Revision=0x4000308, Creator ID=MSFT, Creator Revision=0x97 Entries={ 0xf7ff0200, 0xf7ff0300, 0xf7fff040 } */ /* FACP: Length=129, Revision=2, Checksum=65, OEMID=A M I, OEM Table ID=OEMFACP, OEM Revision=0x4000308, Creator ID=MSFT, Creator Revision=0x97 FACS=0xf7fff000, DSDT=0xf7ff03a0 INT_MODEL=APIC Preferred_PM_Profile=Unspecified (0) SCI_INT=9 SMI_CMD=0xb2, ACPI_ENABLE=0xe1, ACPI_DISABLE=0x1e, S4BIOS_REQ=0x0 PSTATE_CNT=0xe2 PM1a_EVT_BLK=0x400-0x403 PM1a_CNT_BLK=0x404-0x405 PM2_CNT_BLK=0x420-0x420 PM_TMR_BLK=0x408-0x40b GPE0_BLK=0x428-0x42b GPE1_BLK=0x42c-0x42f, GPE1_BASE=16 CST_CNT=0xe3 P_LVL2_LAT=101 us, P_LVL3_LAT=1001 us FLUSH_SIZE=1024, FLUSH_STRIDE=16 DUTY_OFFSET=1, DUTY_WIDTH=3 DAY_ALRM=13, MON_ALRM=0, CENTURY=0 IAPC_BOOT_ARCH={LEGACY_DEV,8042} Flags={WBINVD,PROC_C1,P_LVL2_UP,SLP_BUTTON,RTC_S4,HEADLESS} */ /* FACS: Length=64, HwSig=0x00000000, Firm_Wake_Vec=0x00000000 Global_Lock= Flags= Version=1 */ /* DSDT: Length=12275, Revision=1, Checksum=151, OEMID=0ABBP, OEM Table ID=0ABBP000, OEM Revision=0x0, Creator ID=INTL, Creator Revision=0x2002026 */ /* APIC: Length=146, Revision=1, Checksum=145, OEMID=A M I, OEM Table ID=OEMAPIC, OEM Revision=0x4000308, Creator ID=MSFT, Creator Revision=0x97 Local APIC ADDR=0xfee00000 Flags={PC-AT} Type=Local APIC ACPI CPU=1 Flags={ENABLED} APIC ID=0 Type=Local APIC ACPI CPU=2 Flags={ENABLED} APIC ID=6 Type=Local APIC ACPI CPU=3 Flags={ENABLED} APIC ID=1 Type=Local APIC ACPI CPU=4 Flags={ENABLED} APIC ID=7 Type=IO APIC APIC ID=8 INT BASE=0 ADDR=0x00000000fec00000 Type=IO APIC APIC ID=9 INT BASE=24 ADDR=0x00000000fec80000 Type=IO APIC APIC ID=10 INT BASE=48 ADDR=0x00000000fec80400 Type=IO APIC APIC ID=11 INT BASE=72 ADDR=0x00000000fec81000 Type=IO APIC APIC ID=12 INT BASE=96 ADDR=0x00000000fec81400 Type=INT Override BUS=0 IRQ=0 INTR=2 Flags={Polarity=conforming, Trigger=conforming} */ /* OEMB: Length=63, Revision=1, Checksum=73, OEMID=A M I, OEM Table ID=OEMBIOS, OEM Revision=0x4000308, Creator ID=MSFT, Creator Revision=0x97 */ From owner-freebsd-acpi@FreeBSD.ORG Tue Feb 5 04:21:19 2008 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 51ECF16A418; Tue, 5 Feb 2008 04:21:19 +0000 (UTC) (envelope-from alex.kovalenko@verizon.net) Received: from vms048pub.verizon.net (vms048pub.verizon.net [206.46.252.48]) by mx1.freebsd.org (Postfix) with ESMTP id 276C413C4EE; Tue, 5 Feb 2008 04:21:19 +0000 (UTC) (envelope-from alex.kovalenko@verizon.net) Received: from [10.0.3.231] ([70.111.176.151]) by vms048.mailsrvcs.net (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPA id <0JVR00DDV02OO9X1@vms048.mailsrvcs.net>; Mon, 04 Feb 2008 22:20:50 -0600 (CST) Date: Mon, 04 Feb 2008 23:20:41 -0500 From: "Alexandre \"Sunny\" Kovalenko" In-reply-to: <200801310535.15540.jhb@freebsd.org> To: John Baldwin Message-id: <1202185241.821.8.camel@RabbitsDen> MIME-version: 1.0 X-Mailer: Evolution 2.12.3 FreeBSD GNOME Team Port Content-type: multipart/mixed; boundary="Boundary_(ID_CcJ724C+3L/87kIVLlCe0w)" References: <1201733779.902.18.camel@RabbitsDen> <200801310535.15540.jhb@freebsd.org> Cc: freebsd-acpi@freebsd.org, Ian Smith , Johannes Dieterich Subject: Re: [RFC] Patch to enable temperature ceiling in powerd X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Feb 2008 04:21:19 -0000 --Boundary_(ID_CcJ724C+3L/87kIVLlCe0w) Content-type: text/plain; charset=UTF-8 Content-transfer-encoding: 8BIT On Thu, 2008-01-31 at 05:35 -0500, John Baldwin wrote: > On Wednesday 30 January 2008 05:56:19 pm Alexandre "Sunny" Kovalenko wrote: > > Some time ago I have put together patch for powerd, which allows user to > > specify the temperature threshold at which powerd will lower CPU > > frequency no matter what the load was at the time. I recently had to > > adapt it to the 7.0-PRERELEASE for someone with the overheating laptop, > > which got me to think that it might be useful for someone else yet. > > > > Basic idea is fairly simple -- check temperature in TZ0 and, if it has > > reached certain value, either override frequency with the lowest > > available (in the case of 'max' setting) or change idle time to 100% and > > let adaptive algorithm decrease frequency gradually. > > > > I imagine it also could be poor man's substitute for the low noise > > acoustic policy ;) > > > > If there is an interest, I will go ahead and submit a PR, otherwise it > > will live in the mail archives for someone to find. Any comments, > > suggestions or criticisms are welcome. > > > > Temperature threshold (in Celsius) could be set by means of '-T' command > > line option (as in '-T 60'). > > A couple of suggestions: > > - I would make the default temperature 0 instead of 200 and just disable the > feature altogether if it is set to 0 (i.e. don't read the current > temperature and don't do any checks if it is 0). > - I would allow the temperature to be specified in either C, K or F with a > suffix to indicate the scale. (e.g., "80C", "120F", "300K") > - I would let the thermal zone name be configurable with a default of "tz0". > (e.g. "-z tz3"). You would then snprintf the sysctl mib name that gets > passed to sysctlbyname(3). > John, I have attached new patch, implementing your suggestions (some of these were already implemented by Ian Smith and sent to me privately). I have also attached first crack at the patch to powerd.8. Both patches are against 7.0 as of late January 31, EST. Johannes, could you, by any chance, apply the attached patch to the original copy of the powerd.c and see if it still allows you to use your system? Do not expect any improvements, though ;) -- Alexandre "Sunny" Kovalenko (Олександр Коваленко) --Boundary_(ID_CcJ724C+3L/87kIVLlCe0w) Content-type: text/x-patch; name=powerd.8.patch; charset=UTF-8 Content-transfer-encoding: 7BIT Content-disposition: attachment; filename=powerd.8.patch --- powerd.8.orig 2008-02-04 22:48:14.000000000 -0500 +++ powerd.8 2008-02-04 23:08:59.000000000 -0500 @@ -39,7 +39,9 @@ .Op Fl p Ar ival .Op Fl P Ar pidfile .Op Fl r Ar percent +.Op Fl T Ar temperature .Op Fl v +.Op Fl z Ar thermal zone .Sh DESCRIPTION The .Nm @@ -92,11 +94,23 @@ adaptive mode should consider the CPU running and increase performance. The default is 65% or lower. +.It Fl T Ar temperature +Specifies temperature which will cause powerd to switch to the lowest +available frequency in the maximum mode or to reduce frequency in the +adaptive mode. Temperature could be specified using qualifiers C, F and K, +for Celsius, Fahrenheit and Kelvin respectively. Number without the qualifier +will be treated as the number with the qualifier C. Please, note that +negative temperature values and temperatures in the excess of 999 degrees, with +any qualifier, are considered invalid. .It Fl v Verbose mode. Messages about power changes will be printed to stdout and .Nm will operate in the foreground. +.It Fl z Ar thermal zone +Specifies the name of the thermal zone, used to monitor temperature for the 'T' +option above. This will be used as the part of the mib name, e.g. '-z tz2' will +result in 'hw.acpi.thermal.tz2.temperature' being monitored. .El .Sh SEE ALSO .Xr acpi 4 , --Boundary_(ID_CcJ724C+3L/87kIVLlCe0w) Content-type: text/x-patch; name=powerd.c.patch; charset=UTF-8 Content-transfer-encoding: 7BIT Content-disposition: attachment; filename=powerd.c.patch --- powerd.c.orig 2008-01-31 22:46:42.000000000 -0500 +++ powerd.c 2008-02-04 22:44:01.000000000 -0500 @@ -28,6 +28,13 @@ #include __FBSDID("$FreeBSD: src/usr.sbin/powerd/powerd.c,v 1.21 2007/06/13 19:05:11 marck Exp $"); +/* + * 29/9/6 Ian Smith merged Alexandre "Sunny" Kovalenko's + * patch providing passive cooling override option (thanks David Wolfskill) + * + just in case, only read and test temperature when -T option is specified + * + for MODE_MAX, only switch high if not switching low for over temperature + */ + #include #include #include @@ -40,6 +47,7 @@ #include #include #include +#include #include #include #include @@ -87,18 +95,22 @@ static void handle_sigs(int sig); static void parse_mode(char *arg, int *mode, int ch); static void usage(void); +static int convert_temperature_to_acpi(const char *temp); /* Sysctl data structures. */ static int cp_time_mib[2]; static int freq_mib[4]; static int levels_mib[4]; static int acline_mib[3]; +static int temp_mib[5]; /* Configuration */ static int cpu_running_mark; static int cpu_idle_mark; static int poll_ival; +static int passive_cooling_mark; static int vflag; +static int tflag; static volatile sig_atomic_t exit_requested; static power_src_t acline_status; @@ -357,10 +369,67 @@ { fprintf(stderr, -"usage: powerd [-v] [-a mode] [-b mode] [-i %%] [-n mode] [-p ival] [-r %%] [-P pidfile]\n"); +"usage: powerd [-v] [-a mode] [-b mode] [-i %%] [-n mode] [-p ival] [-r %%] [-P pidfile] [-T temperature] [-z thermal zone]\n"); exit(1); } +/* Convert temperature in the form of nnC, nnK and nnF into tenths + * of the K as used by ACPI subsystem. Temperatures without qualifier + * are assumed to be in Celsius. Temperatures, longer then three + * digits or having qualifiers other then C, K or F are considered + * invalid. Function will return negative value if invalid temperature + * is encountered as well as upon reaching error condition. + */ +int convert_temperature_to_acpi(const char *temp) +{ + regex_t preg; + regmatch_t pmatch[3]; + int result = 0; + char temp_value[4]; + char qualifier = 'C'; /* If no qualifier is specified, defaulting to Celsius */ + + /* That would be an internal error -- return -1 */ + if (regcomp(&preg, "^([0-9]+)([CKF]?)$", REG_EXTENDED)) + result = -1; + /* If it looks like nothing we expect -- return -2 */ + if (!result && (regexec(&preg, temp, 3, pmatch, 0) == REG_NOMATCH)) + result = -2; + /* If we were able to successfully allocate 'preg' we need to free it */ + if (result != -1) + regfree(&preg); + /* If there were no problems so far, let's interpret the string */ + if (!result) { + if (pmatch[2].rm_so != pmatch[2].rm_eo) + qualifier = temp[pmatch[2].rm_so]; + /* Three digits of the temperature are enough for practical purposes */ + if ((pmatch[1].rm_eo - pmatch[1].rm_so) <= 3) { + memcpy(temp_value, &temp[pmatch[1].rm_so], pmatch[1].rm_eo - pmatch[1].rm_so); + temp_value[pmatch[1].rm_eo - pmatch[1].rm_so] = '\0'; + result = atoi(temp_value); + } + else + result = -3; + + if (result >= 0) { + switch (qualifier) { + case 'F': + result = ((result - 32) * 5) / 9; + /* Fallthrough is intentional */ + case 'C': + result += 273; + /* Fallthrough is intentional */ + case 'K': + result *= 10; + break; + default: + result = -4; + break; + } + } + } + return(result); +} + int main(int argc, char * argv[]) { @@ -371,6 +440,7 @@ const char *pidfile = NULL; long idle, total; int curfreq, *freqs, i, *mwatts, numfreqs; + int temperature; int ch, mode, mode_ac, mode_battery, mode_none; uint64_t mjoules_used; size_t len; @@ -381,13 +451,18 @@ cpu_idle_mark = DEFAULT_IDLE_PERCENT; poll_ival = DEFAULT_POLL_INTERVAL; mjoules_used = 0; + tflag = 0; vflag = 0; + char tz_mib_name[40]; /* This should be sufficient to hold "hw.acpi.thermal.%s.temperature" */ /* User must be root to control frequencies. */ if (geteuid() != 0) errx(1, "must be root to run"); - while ((ch = getopt(argc, argv, "a:b:i:n:p:P:r:v")) != EOF) + /* Set default mib name for the thermal zone */ + snprintf(tz_mib_name, sizeof(tz_mib_name), "hw.acpi.thermal.%s.temperature", "tz0"); + + while ((ch = getopt(argc, argv, "a:b:i:n:p:P:r:T:v:z:")) != EOF) switch (ch) { case 'a': parse_mode(optarg, &mode_ac, ch); @@ -424,9 +499,26 @@ usage(); } break; + case 'T': + passive_cooling_mark = convert_temperature_to_acpi(optarg); + if (passive_cooling_mark < 0) { + warnx("%d is not valid temperature for passive cooling", + passive_cooling_mark); + usage(); + } else if (passive_cooling_mark > 0) + tflag = 1; + break; case 'v': vflag = 1; break; + case 'z': + /* + * We will decipher thermal zone here but it will not + * be used unless -T was also present + */ + snprintf(tz_mib_name, sizeof(tz_mib_name), + "hw.acpi.thermal.%s.temperature", optarg); + break; default: usage(); } @@ -446,6 +538,11 @@ len = 4; if (sysctlnametomib("dev.cpu.0.freq_levels", levels_mib, &len)) err(1, "lookup freq_levels"); + if (tflag) { /* if no -T option don't fail if temp not available */ + len = 5; + if (sysctlnametomib(tz_mib_name, temp_mib, &len)) + err(1, "lookup temperature"); + } /* Check if we can read the idle time and supported freqs. */ if (read_usage_times(NULL, NULL)) @@ -528,6 +625,13 @@ warn("error reading current CPU frequency"); continue; } + /* Read current temperature if -T option is set */ + if(tflag) { + len = sizeof(temperature); + if(sysctl(temp_mib, 5, &temperature, &len, NULL, 0)) + err(1, "error reading current temperature"); + } + if (vflag) { for (i = 0; i < numfreqs; i++) { @@ -571,6 +675,19 @@ if (set_freq(freqs[0]) != 0) { warn("error setting CPU freq %d", freqs[0]); + /* ... unless passive cooling override */ + if(tflag && temperature > passive_cooling_mark) { + if(curfreq != freqs[numfreqs - 1]) { + if (vflag) { + printf("passive cooling override; " + "changing frequency to %d MHz\n", + freqs[numfreqs - 1]); + } + if (set_freq(freqs[numfreqs - 1])) + err(1, "error setting CPU freq %d", + freqs[numfreqs - 1]); + } + } continue; } } @@ -583,6 +700,14 @@ warn("read_usage_times() failed"); continue; } + /* + * If temperature has risen over passive cooling mark, we + * would want to decrease frequency regardless of the load, + * Simplest way to go about this would be to report 100% + * idle CPU and let adaptive algorithm do its job. + */ + if(temperature > passive_cooling_mark) + idle = total; /* * If we're idle less than the active mark, bump up two levels. --Boundary_(ID_CcJ724C+3L/87kIVLlCe0w)-- From owner-freebsd-acpi@FreeBSD.ORG Tue Feb 5 10:23:06 2008 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 DBD0716A46C; Tue, 5 Feb 2008 10:23:06 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from gaia.nimnet.asn.au (nimbin.lnk.telstra.net [139.130.45.143]) by mx1.freebsd.org (Postfix) with ESMTP id 6DFC813C478; Tue, 5 Feb 2008 10:23:03 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from localhost (smithi@localhost) by gaia.nimnet.asn.au (8.8.8/8.8.8R1.5) with ESMTP id VAA08751; Tue, 5 Feb 2008 21:22:55 +1100 (EST) (envelope-from smithi@nimnet.asn.au) Date: Tue, 5 Feb 2008 21:22:54 +1100 (EST) From: Ian Smith To: "Alexandre \"Sunny\" Kovalenko" In-Reply-To: <1202185241.821.8.camel@RabbitsDen> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Cc: freebsd-acpi@freebsd.org, Johannes Dieterich Subject: Re: [RFC] Patch to enable temperature ceiling in powerd X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Feb 2008 10:23:06 -0000 On Mon, 4 Feb 2008, Alexandre "Sunny" Kovalenko wrote: > On Thu, 2008-01-31 at 05:35 -0500, John Baldwin wrote: > > On Wednesday 30 January 2008 05:56:19 pm Alexandre "Sunny" Kovalenko wrote: > > > Some time ago I have put together patch for powerd, which allows user to > > > specify the temperature threshold at which powerd will lower CPU > > > frequency no matter what the load was at the time. I recently had to > > > adapt it to the 7.0-PRERELEASE for someone with the overheating laptop, > > > which got me to think that it might be useful for someone else yet. > > > > > > Basic idea is fairly simple -- check temperature in TZ0 and, if it has > > > reached certain value, either override frequency with the lowest > > > available (in the case of 'max' setting) or change idle time to 100% and > > > let adaptive algorithm decrease frequency gradually. > > > > > > I imagine it also could be poor man's substitute for the low noise > > > acoustic policy ;) > > > > > > If there is an interest, I will go ahead and submit a PR, otherwise it > > > will live in the mail archives for someone to find. Any comments, > > > suggestions or criticisms are welcome. > > > > > > Temperature threshold (in Celsius) could be set by means of '-T' command > > > line option (as in '-T 60'). > > > > A couple of suggestions: > > > > - I would make the default temperature 0 instead of 200 and just disable the > > feature altogether if it is set to 0 (i.e. don't read the current > > temperature and don't do any checks if it is 0). > > - I would allow the temperature to be specified in either C, K or F with a > > suffix to indicate the scale. (e.g., "80C", "120F", "300K") > > - I would let the thermal zone name be configurable with a default of "tz0". > > (e.g. "-z tz3"). You would then snprintf the sysctl mib name that gets > > passed to sysctlbyname(3). > > > John, > I have attached new patch, implementing your suggestions (some of these > were already implemented by Ian Smith and sent to me privately). I have > also attached first crack at the patch to powerd.8. Both patches are > against 7.0 as of late January 31, EST. Alexandre, please remove my gratuitous 4-line comment at the top, it's OTT and was really just to document for myself what I was playing around with then. Though it's implied, I think the mod to powerd(8) should mention that tz0 is the default. Also I think 999C is just a wee bit high to test against, when 150C would melt most laptops (not to mention laps :) I recall seeing 150C tested against somewhere else as a 'reasonable' max. Cheers, Ian > Johannes, > could you, by any chance, apply the attached patch to the original copy > of the powerd.c and see if it still allows you to use your system? Do > not expect any improvements, though ;) > > -- > Alexandre "Sunny" Kovalenko (Олександр Коваленко) > From owner-freebsd-acpi@FreeBSD.ORG Tue Feb 5 14:36:19 2008 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 1F2BB16A41B; Tue, 5 Feb 2008 14:36:19 +0000 (UTC) (envelope-from alex.kovalenko@verizon.net) Received: from vms173003pub.verizon.net (vms173003pub.verizon.net [206.46.173.3]) by mx1.freebsd.org (Postfix) with ESMTP id E77CA13C468; Tue, 5 Feb 2008 14:36:18 +0000 (UTC) (envelope-from alex.kovalenko@verizon.net) Received: from [10.0.3.231] ([70.111.176.151]) by vms173003.mailsrvcs.net (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPA id <0JVR0053APMOXOG2@vms173003.mailsrvcs.net>; Tue, 05 Feb 2008 07:32:50 -0600 (CST) Date: Tue, 05 Feb 2008 08:35:31 -0500 From: "Alexandre \"Sunny\" Kovalenko" In-reply-to: To: Ian Smith Message-id: <1202218531.815.6.camel@RabbitsDen> MIME-version: 1.0 X-Mailer: Evolution 2.12.3 FreeBSD GNOME Team Port Content-type: multipart/mixed; boundary="Boundary_(ID_R/ClezF+eqUygbAW99Xw7Q)" References: Cc: freebsd-acpi@freebsd.org, Johannes Dieterich Subject: Re: [RFC] Patch to enable temperature ceiling in powerd X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Feb 2008 14:36:19 -0000 --Boundary_(ID_R/ClezF+eqUygbAW99Xw7Q) Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8BIT On Tue, 2008-02-05 at 21:22 +1100, Ian Smith wrote: > On Mon, 4 Feb 2008, Alexandre "Sunny" Kovalenko wrote: > > On Thu, 2008-01-31 at 05:35 -0500, John Baldwin wrote: > > > On Wednesday 30 January 2008 05:56:19 pm Alexandre "Sunny" Kovalenko wrote: > > > > Some time ago I have put together patch for powerd, which allows user to > > > > specify the temperature threshold at which powerd will lower CPU > > > > frequency no matter what the load was at the time. I recently had to > > > > adapt it to the 7.0-PRERELEASE for someone with the overheating laptop, > > > > which got me to think that it might be useful for someone else yet. > > > > > > > > Basic idea is fairly simple -- check temperature in TZ0 and, if it has > > > > reached certain value, either override frequency with the lowest > > > > available (in the case of 'max' setting) or change idle time to 100% and > > > > let adaptive algorithm decrease frequency gradually. > > > > > > > > I imagine it also could be poor man's substitute for the low noise > > > > acoustic policy ;) > > > > > > > > If there is an interest, I will go ahead and submit a PR, otherwise it > > > > will live in the mail archives for someone to find. Any comments, > > > > suggestions or criticisms are welcome. > > > > > > > > Temperature threshold (in Celsius) could be set by means of '-T' command > > > > line option (as in '-T 60'). > > > > > > A couple of suggestions: > > > > > > - I would make the default temperature 0 instead of 200 and just disable the > > > feature altogether if it is set to 0 (i.e. don't read the current > > > temperature and don't do any checks if it is 0). > > > - I would allow the temperature to be specified in either C, K or F with a > > > suffix to indicate the scale. (e.g., "80C", "120F", "300K") > > > - I would let the thermal zone name be configurable with a default of "tz0". > > > (e.g. "-z tz3"). You would then snprintf the sysctl mib name that gets > > > passed to sysctlbyname(3). > > > > > John, > > I have attached new patch, implementing your suggestions (some of these > > were already implemented by Ian Smith and sent to me privately). I have > > also attached first crack at the patch to powerd.8. Both patches are > > against 7.0 as of late January 31, EST. > > Alexandre, > > please remove my gratuitous 4-line comment at the top, it's OTT and was > really just to document for myself what I was playing around with then. Done. > > Though it's implied, I think the mod to powerd(8) should mention that > tz0 is the default. Done. > Also I think 999C is just a wee bit high to test > against, when 150C would melt most laptops (not to mention laps :) I > recall seeing 150C tested against somewhere else as a 'reasonable' max. Even 999K will melt quite a few things... I did not test for the absolute value -- I just wanted to limit number of characters, used in the option value, to simplify my own life. Two-digit temperatures are not enough even for C and three should be plenty. I can introduce test for 150C (and equivalent thereof) if you think it is necessary. > > Cheers, Ian > > > Johannes, > > could you, by any chance, apply the attached patch to the original copy > > of the powerd.c and see if it still allows you to use your system? Do > > not expect any improvements, though ;) > > > > -- > > Alexandre "Sunny" Kovalenko (ОлекÑандр Коваленко) > > > -- Alexandre "Sunny" Kovalenko (Олександр Коваленко) --Boundary_(ID_R/ClezF+eqUygbAW99Xw7Q) Content-type: text/x-patch; name=powerd.8.patch; charset=utf-8 Content-transfer-encoding: 7BIT Content-disposition: attachment; filename=powerd.8.patch --- powerd.8.orig 2008-02-04 22:48:14.000000000 -0500 +++ powerd.8 2008-02-05 08:25:08.000000000 -0500 @@ -39,7 +39,9 @@ .Op Fl p Ar ival .Op Fl P Ar pidfile .Op Fl r Ar percent +.Op Fl T Ar temperature .Op Fl v +.Op Fl z Ar thermal zone .Sh DESCRIPTION The .Nm @@ -92,11 +94,25 @@ adaptive mode should consider the CPU running and increase performance. The default is 65% or lower. +.It Fl T Ar temperature +Specifies temperature which will cause powerd to switch to the lowest +available frequency in the maximum mode or to reduce frequency in the +adaptive mode. Temperature could be specified using qualifiers C, F and K, +for Celsius, Fahrenheit and Kelvin respectively. Number without the qualifier +will be treated as the number with the qualifier C. Please, note that +negative temperature values and temperatures in the excess of 999 degrees, with +any qualifier, are considered invalid. .It Fl v Verbose mode. Messages about power changes will be printed to stdout and .Nm will operate in the foreground. +.It Fl z Ar thermal zone +Specifies the name of the thermal zone, used to monitor temperature for the 'T' +option above. This will be used as the part of the mib name, e.g. '-z tz2' will +result in 'hw.acpi.thermal.tz2.temperature' being monitored. If no thermal zone +name was specified on the command line, 'tz0' is assumed. In the absence of the 'T' +option, this option is ignored. .El .Sh SEE ALSO .Xr acpi 4 , --Boundary_(ID_R/ClezF+eqUygbAW99Xw7Q) Content-type: text/x-patch; name=powerd.c.patch; charset=utf-8 Content-transfer-encoding: 7BIT Content-disposition: attachment; filename=powerd.c.patch --- powerd.c.orig 2008-01-31 22:46:42.000000000 -0500 +++ powerd.c 2008-02-04 22:44:01.000000000 -0500 @@ -40,6 +47,7 @@ #include #include #include +#include #include #include #include @@ -87,18 +95,22 @@ static void handle_sigs(int sig); static void parse_mode(char *arg, int *mode, int ch); static void usage(void); +static int convert_temperature_to_acpi(const char *temp); /* Sysctl data structures. */ static int cp_time_mib[2]; static int freq_mib[4]; static int levels_mib[4]; static int acline_mib[3]; +static int temp_mib[5]; /* Configuration */ static int cpu_running_mark; static int cpu_idle_mark; static int poll_ival; +static int passive_cooling_mark; static int vflag; +static int tflag; static volatile sig_atomic_t exit_requested; static power_src_t acline_status; @@ -357,10 +369,67 @@ { fprintf(stderr, -"usage: powerd [-v] [-a mode] [-b mode] [-i %%] [-n mode] [-p ival] [-r %%] [-P pidfile]\n"); +"usage: powerd [-v] [-a mode] [-b mode] [-i %%] [-n mode] [-p ival] [-r %%] [-P pidfile] [-T temperature] [-z thermal zone]\n"); exit(1); } +/* Convert temperature in the form of nnC, nnK and nnF into tenths + * of the K as used by ACPI subsystem. Temperatures without qualifier + * are assumed to be in Celsius. Temperatures, longer then three + * digits or having qualifiers other then C, K or F are considered + * invalid. Function will return negative value if invalid temperature + * is encountered as well as upon reaching error condition. + */ +int convert_temperature_to_acpi(const char *temp) +{ + regex_t preg; + regmatch_t pmatch[3]; + int result = 0; + char temp_value[4]; + char qualifier = 'C'; /* If no qualifier is specified, defaulting to Celsius */ + + /* That would be an internal error -- return -1 */ + if (regcomp(&preg, "^([0-9]+)([CKF]?)$", REG_EXTENDED)) + result = -1; + /* If it looks like nothing we expect -- return -2 */ + if (!result && (regexec(&preg, temp, 3, pmatch, 0) == REG_NOMATCH)) + result = -2; + /* If we were able to successfully allocate 'preg' we need to free it */ + if (result != -1) + regfree(&preg); + /* If there were no problems so far, let's interpret the string */ + if (!result) { + if (pmatch[2].rm_so != pmatch[2].rm_eo) + qualifier = temp[pmatch[2].rm_so]; + /* Three digits of the temperature are enough for practical purposes */ + if ((pmatch[1].rm_eo - pmatch[1].rm_so) <= 3) { + memcpy(temp_value, &temp[pmatch[1].rm_so], pmatch[1].rm_eo - pmatch[1].rm_so); + temp_value[pmatch[1].rm_eo - pmatch[1].rm_so] = '\0'; + result = atoi(temp_value); + } + else + result = -3; + + if (result >= 0) { + switch (qualifier) { + case 'F': + result = ((result - 32) * 5) / 9; + /* Fallthrough is intentional */ + case 'C': + result += 273; + /* Fallthrough is intentional */ + case 'K': + result *= 10; + break; + default: + result = -4; + break; + } + } + } + return(result); +} + int main(int argc, char * argv[]) { @@ -371,6 +440,7 @@ const char *pidfile = NULL; long idle, total; int curfreq, *freqs, i, *mwatts, numfreqs; + int temperature; int ch, mode, mode_ac, mode_battery, mode_none; uint64_t mjoules_used; size_t len; @@ -381,13 +451,18 @@ cpu_idle_mark = DEFAULT_IDLE_PERCENT; poll_ival = DEFAULT_POLL_INTERVAL; mjoules_used = 0; + tflag = 0; vflag = 0; + char tz_mib_name[40]; /* This should be sufficient to hold "hw.acpi.thermal.%s.temperature" */ /* User must be root to control frequencies. */ if (geteuid() != 0) errx(1, "must be root to run"); - while ((ch = getopt(argc, argv, "a:b:i:n:p:P:r:v")) != EOF) + /* Set default mib name for the thermal zone */ + snprintf(tz_mib_name, sizeof(tz_mib_name), "hw.acpi.thermal.%s.temperature", "tz0"); + + while ((ch = getopt(argc, argv, "a:b:i:n:p:P:r:T:v:z:")) != EOF) switch (ch) { case 'a': parse_mode(optarg, &mode_ac, ch); @@ -424,9 +499,26 @@ usage(); } break; + case 'T': + passive_cooling_mark = convert_temperature_to_acpi(optarg); + if (passive_cooling_mark < 0) { + warnx("%d is not valid temperature for passive cooling", + passive_cooling_mark); + usage(); + } else if (passive_cooling_mark > 0) + tflag = 1; + break; case 'v': vflag = 1; break; + case 'z': + /* + * We will decipher thermal zone here but it will not + * be used unless -T was also present + */ + snprintf(tz_mib_name, sizeof(tz_mib_name), + "hw.acpi.thermal.%s.temperature", optarg); + break; default: usage(); } @@ -446,6 +538,11 @@ len = 4; if (sysctlnametomib("dev.cpu.0.freq_levels", levels_mib, &len)) err(1, "lookup freq_levels"); + if (tflag) { /* if no -T option don't fail if temp not available */ + len = 5; + if (sysctlnametomib(tz_mib_name, temp_mib, &len)) + err(1, "lookup temperature"); + } /* Check if we can read the idle time and supported freqs. */ if (read_usage_times(NULL, NULL)) @@ -528,6 +625,13 @@ warn("error reading current CPU frequency"); continue; } + /* Read current temperature if -T option is set */ + if(tflag) { + len = sizeof(temperature); + if(sysctl(temp_mib, 5, &temperature, &len, NULL, 0)) + err(1, "error reading current temperature"); + } + if (vflag) { for (i = 0; i < numfreqs; i++) { @@ -571,6 +675,19 @@ if (set_freq(freqs[0]) != 0) { warn("error setting CPU freq %d", freqs[0]); + /* ... unless passive cooling override */ + if(tflag && temperature > passive_cooling_mark) { + if(curfreq != freqs[numfreqs - 1]) { + if (vflag) { + printf("passive cooling override; " + "changing frequency to %d MHz\n", + freqs[numfreqs - 1]); + } + if (set_freq(freqs[numfreqs - 1])) + err(1, "error setting CPU freq %d", + freqs[numfreqs - 1]); + } + } continue; } } @@ -583,6 +700,14 @@ warn("read_usage_times() failed"); continue; } + /* + * If temperature has risen over passive cooling mark, we + * would want to decrease frequency regardless of the load, + * Simplest way to go about this would be to report 100% + * idle CPU and let adaptive algorithm do its job. + */ + if(temperature > passive_cooling_mark) + idle = total; /* * If we're idle less than the active mark, bump up two levels. --Boundary_(ID_R/ClezF+eqUygbAW99Xw7Q)-- From owner-freebsd-acpi@FreeBSD.ORG Tue Feb 5 21:15:54 2008 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 95FB416A41B for ; Tue, 5 Feb 2008 21:15:54 +0000 (UTC) (envelope-from robert.moore@intel.com) Received: from mga03.intel.com (mga03.intel.com [143.182.124.21]) by mx1.freebsd.org (Postfix) with ESMTP id 6493413C467 for ; Tue, 5 Feb 2008 21:15:54 +0000 (UTC) (envelope-from robert.moore@intel.com) Received: from azsmga001.ch.intel.com ([10.2.17.19]) by azsmga101.ch.intel.com with ESMTP; 05 Feb 2008 13:15:46 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.25,309,1199692800"; d="scan'208";a="375575200" Received: from orsmsx335.jf.intel.com ([10.22.226.40]) by azsmga001.ch.intel.com with ESMTP; 05 Feb 2008 13:10:01 -0800 Received: from orsmsx415.amr.corp.intel.com ([10.22.226.49]) by orsmsx335.jf.intel.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 5 Feb 2008 13:09:59 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 5 Feb 2008 13:09:59 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANNOUNCE] ACPICA website - acpica.org Thread-Index: AchoIiIznnywpw51RC+xvPG9z5VZjQAGOGQgAAAIySAAAA0RgA== From: "Moore, Robert" To: X-OriginalArrivalTime: 05 Feb 2008 21:09:59.0834 (UTC) FILETIME=[778FEFA0:01C8683B] Subject: [ANNOUNCE] ACPICA website - acpica.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: Tue, 05 Feb 2008 21:15:54 -0000 The ACPICA project now has its own website, at www.acpica.org. This will be the central point for all ACPICA-related activities. Features of the website include: 1) From now on, this will be the place to download the ACPICA source. Both the current release and several previous releases will always be available. Currently, the source tarballs and zipfiles are available as they were on intel.developer.com. In the near future, we will publish the source tree for browsing and checkout. 2) There is a new mailing list for ACPICA-specific topics. You can join the mailing list from the website. 3) There is a bugzilla for ACPICA-specific problem reports. This bugzilla is intended for problems that reside in the ACPICA core code, and are thus independent of any operating system. 4) All ACPICA documentation is available for download. The acpica.org website obsoletes the downloads page found under http://developer.intel.com/technology/iapc/acpi/downloads.htm. This page will be removed in the very near future. From owner-freebsd-acpi@FreeBSD.ORG Wed Feb 6 01:10:03 2008 Return-Path: Delivered-To: freebsd-acpi@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3B8D916A417 for ; Wed, 6 Feb 2008 01:10:03 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 1ED4413C467 for ; Wed, 6 Feb 2008 01:10:03 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m161A2V0003046 for ; Wed, 6 Feb 2008 01:10:02 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m161A20M003045; Wed, 6 Feb 2008 01:10:02 GMT (envelope-from gnats) Date: Wed, 6 Feb 2008 01:10:02 GMT Message-Id: <200802060110.m161A20M003045@freefall.freebsd.org> To: freebsd-acpi@FreeBSD.org From: Pete French Cc: Subject: Re: kern/119716: [acpi] vm_fault when trying to boot 7.0 ACPI on HP dc5750 X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Pete French List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Feb 2008 01:10:03 -0000 The following reply was made to PR kern/119716; it has been noted by GNATS. From: Pete French To: bug-followup@FreeBSD.org, petefrench@ticketswitch.com Cc: Subject: Re: kern/119716: [acpi] vm_fault when trying to boot 7.0 ACPI on HP dc5750 Date: Wed, 6 Feb 2008 01:07:21 +0000 This has been found and fixed by John Baldwin. See the patch in the mailing list post: http://lists.freebsd.org/pipermail/freebsd-stable/2008-January/ 040077.html From owner-freebsd-acpi@FreeBSD.ORG Wed Feb 6 01:20:03 2008 Return-Path: Delivered-To: freebsd-acpi@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 93F5416A41B for ; Wed, 6 Feb 2008 01:20:03 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 7928C13C45A for ; Wed, 6 Feb 2008 01:20:03 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m161K3vq004940 for ; Wed, 6 Feb 2008 01:20:03 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m161K3AL004939; Wed, 6 Feb 2008 01:20:03 GMT (envelope-from gnats) Date: Wed, 6 Feb 2008 01:20:03 GMT Message-Id: <200802060120.m161K3AL004939@freefall.freebsd.org> To: freebsd-acpi@FreeBSD.org From: Pete French Cc: Subject: Re: i386/117918: HP dc5750 will only boot with ACPI disabled X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Pete French List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Feb 2008 01:20:03 -0000 The following reply was made to PR i386/117918; it has been noted by GNATS. From: Pete French To: bug-followup@FreeBSD.org, petefrench@ticketswitch.com Cc: Subject: Re: i386/117918: HP dc5750 will only boot with ACPI disabled Date: Wed, 6 Feb 2008 01:10:02 +0000 This is probably the same bug as 119716 and thus should be fixed by the patch in the mailing list post: http://lists.freebsd.org/pipermail/freebsd-stable/2008-January/ 040077.html From owner-freebsd-acpi@FreeBSD.ORG Wed Feb 6 21:00:14 2008 Return-Path: Delivered-To: freebsd-acpi@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 57A1716A41B; Wed, 6 Feb 2008 21:00:14 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 09D4413C4E3; Wed, 6 Feb 2008 21:00:14 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from freefall.freebsd.org (jhb@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m16L0EIM093550; Wed, 6 Feb 2008 21:00:14 GMT (envelope-from jhb@freefall.freebsd.org) Received: (from jhb@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m16L0DSp093546; Wed, 6 Feb 2008 21:00:13 GMT (envelope-from jhb) Date: Wed, 6 Feb 2008 21:00:13 GMT Message-Id: <200802062100.m16L0DSp093546@freefall.freebsd.org> To: petefrench@ticketswitch.com, jhb@FreeBSD.org, freebsd-acpi@FreeBSD.org, jhb@FreeBSD.org From: jhb@FreeBSD.org Cc: Subject: Re: kern/119716: [acpi] vm_fault when trying to boot 7.0 ACPI on HP dc5750 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, 06 Feb 2008 21:00:14 -0000 Synopsis: [acpi] vm_fault when trying to boot 7.0 ACPI on HP dc5750 State-Changed-From-To: open->patched State-Changed-By: jhb State-Changed-When: Wed Feb 6 20:59:38 UTC 2008 State-Changed-Why: I'll take this. Responsible-Changed-From-To: freebsd-acpi->jhb Responsible-Changed-By: jhb Responsible-Changed-When: Wed Feb 6 20:59:38 UTC 2008 Responsible-Changed-Why: I'll take this. http://www.freebsd.org/cgi/query-pr.cgi?pr=119716 From owner-freebsd-acpi@FreeBSD.ORG Wed Feb 6 21:01:12 2008 Return-Path: Delivered-To: freebsd-acpi@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CEB5C16A41A; Wed, 6 Feb 2008 21:01:12 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 825DC13C468; Wed, 6 Feb 2008 21:01:12 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from freefall.freebsd.org (jhb@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m16L1C40093659; Wed, 6 Feb 2008 21:01:12 GMT (envelope-from jhb@freefall.freebsd.org) Received: (from jhb@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m16L1CIf093655; Wed, 6 Feb 2008 21:01:12 GMT (envelope-from jhb) Date: Wed, 6 Feb 2008 21:01:12 GMT Message-Id: <200802062101.m16L1CIf093655@freefall.freebsd.org> To: petefrench@ticketswitch.com, jhb@FreeBSD.org, freebsd-acpi@FreeBSD.org From: jhb@FreeBSD.org Cc: Subject: Re: i386/117918: HP dc5750 will only boot with ACPI disabled 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, 06 Feb 2008 21:01:12 -0000 Synopsis: HP dc5750 will only boot with ACPI disabled State-Changed-From-To: open->closed State-Changed-By: jhb State-Changed-When: Wed Feb 6 21:00:29 UTC 2008 State-Changed-Why: Dup of 119716. http://www.freebsd.org/cgi/query-pr.cgi?pr=117918 From owner-freebsd-acpi@FreeBSD.ORG Thu Feb 7 03:19:31 2008 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 802F516A468 for ; Thu, 7 Feb 2008 03:19:31 +0000 (UTC) (envelope-from alex.kovalenko@verizon.net) Received: from vms173001pub.verizon.net (vms173001pub.verizon.net [206.46.173.1]) by mx1.freebsd.org (Postfix) with ESMTP id 4C84713C442 for ; Thu, 7 Feb 2008 03:19:31 +0000 (UTC) (envelope-from alex.kovalenko@verizon.net) Received: from [10.0.3.231] ([70.111.176.151]) by vms173001.mailsrvcs.net (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPA id <0JVU00HXIM0C9A12@vms173001.mailsrvcs.net> for freebsd-acpi@freebsd.org; Wed, 06 Feb 2008 21:07:25 -0600 (CST) Date: Wed, 06 Feb 2008 22:19:09 -0500 From: "Alexandre \"Sunny\" Kovalenko" In-reply-to: <1202185241.821.8.camel@RabbitsDen> To: freebsd-acpi Message-id: <1202354349.1157.55.camel@RabbitsDen> MIME-version: 1.0 X-Mailer: Evolution 2.12.3 FreeBSD GNOME Team Port Content-type: multipart/mixed; boundary="Boundary_(ID_ZU9lgbhirRsxebqErOTx4w)" References: <1201733779.902.18.camel@RabbitsDen> <200801310535.15540.jhb@freebsd.org> <1202185241.821.8.camel@RabbitsDen> Cc: Ian Smith , Johannes Dieterich Subject: Re: [RFC] Patch to enable temperature ceiling in powerd X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Feb 2008 03:19:31 -0000 --Boundary_(ID_ZU9lgbhirRsxebqErOTx4w) Content-type: text/plain; charset=UTF-8 Content-transfer-encoding: 8BIT On Mon, 2008-02-04 at 23:20 -0500, Alexandre "Sunny" Kovalenko wrote: > On Thu, 2008-01-31 at 05:35 -0500, John Baldwin wrote: > > On Wednesday 30 January 2008 05:56:19 pm Alexandre "Sunny" Kovalenko wrote: > > > Some time ago I have put together patch for powerd, which allows user to > > > specify the temperature threshold at which powerd will lower CPU > > > frequency no matter what the load was at the time. I recently had to > > > adapt it to the 7.0-PRERELEASE for someone with the overheating laptop, > > > which got me to think that it might be useful for someone else yet. > > > > > > Basic idea is fairly simple -- check temperature in TZ0 and, if it has > > > reached certain value, either override frequency with the lowest > > > available (in the case of 'max' setting) or change idle time to 100% and > > > let adaptive algorithm decrease frequency gradually. > > > > > > I imagine it also could be poor man's substitute for the low noise > > > acoustic policy ;) > > > > > > If there is an interest, I will go ahead and submit a PR, otherwise it > > > will live in the mail archives for someone to find. Any comments, > > > suggestions or criticisms are welcome. > > > > > > Temperature threshold (in Celsius) could be set by means of '-T' command > > > line option (as in '-T 60'). > > > > A couple of suggestions: > > > > - I would make the default temperature 0 instead of 200 and just disable the > > feature altogether if it is set to 0 (i.e. don't read the current > > temperature and don't do any checks if it is 0). > > - I would allow the temperature to be specified in either C, K or F with a > > suffix to indicate the scale. (e.g., "80C", "120F", "300K") > > - I would let the thermal zone name be configurable with a default of "tz0". > > (e.g. "-z tz3"). You would then snprintf the sysctl mib name that gets > > passed to sysctlbyname(3). > > I have filed bin/120336: [patch] Enable temperature ceiling in powerd with the patch, implementing what was outlined above including suggestions from John Baldwin. It should apply cleanly to the version 1.21 of powerd.c and version 1.10 of powerd.8. It has been running on my ThinkPad X60 for a while, and some older versions were used by at least two other people. Thanks go to Ian Smith for reviewing it from the functional standpoint and for style(9) compliance. Patch, attached to the PR, is the combination of the two patches, attached to this E-mail due to the fact that PR web form only allows single file to be attached. -- Alexandre "Sunny" Kovalenko (Олександр Коваленко) --Boundary_(ID_ZU9lgbhirRsxebqErOTx4w) Content-type: text/x-patch; name=powerd.8.patch; charset=UTF-8 Content-transfer-encoding: 7BIT Content-disposition: attachment; filename=powerd.8.patch --- powerd.8.orig 2008-02-04 22:48:14.000000000 -0500 +++ powerd.8 2008-02-06 16:33:42.000000000 -0500 @@ -39,7 +39,9 @@ .Op Fl p Ar ival .Op Fl P Ar pidfile .Op Fl r Ar percent +.Op Fl T Ar temperature .Op Fl v +.Op Fl z Ar thermal zone .Sh DESCRIPTION The .Nm @@ -92,11 +94,25 @@ adaptive mode should consider the CPU running and increase performance. The default is 65% or lower. +.It Fl T Ar temperature +Specifies temperature which will cause powerd to switch to the lowest +available frequency in the maximum mode or to reduce frequency in the +adaptive mode. Temperature could be specified using qualifiers C, F and K, +for Celsius, Fahrenheit and Kelvin respectively. Number without the qualifier +will be treated as the number with the qualifier C. Please, note that +negative temperature values and values in the excess of the equivalent of +150C are considered invalid. .It Fl v Verbose mode. Messages about power changes will be printed to stdout and .Nm will operate in the foreground. +.It Fl z Ar thermal zone +Specifies the name of the thermal zone, used to monitor temperature for the 'T' +option above. This will be used as the part of the mib name, e.g. '-z tz2' will +result in 'hw.acpi.thermal.tz2.temperature' being monitored. If no thermal zone +name was specified on the command line, 'tz0' is assumed. In the absence of the 'T' +option, this option is ignored. .El .Sh SEE ALSO .Xr acpi 4 , --Boundary_(ID_ZU9lgbhirRsxebqErOTx4w) Content-type: text/x-patch; name=powerd.c.patch; charset=UTF-8 Content-transfer-encoding: 7BIT Content-disposition: attachment; filename=powerd.c.patch --- powerd.c.orig 2008-02-06 16:03:10.000000000 -0500 +++ powerd.c 2008-02-06 21:13:53.000000000 -0500 @@ -40,6 +40,7 @@ #include #include #include +#include #include #include #include @@ -87,18 +88,22 @@ static void handle_sigs(int sig); static void parse_mode(char *arg, int *mode, int ch); static void usage(void); +static int convert_temperature_to_acpi(const char *temp); /* Sysctl data structures. */ static int cp_time_mib[2]; static int freq_mib[4]; static int levels_mib[4]; static int acline_mib[3]; +static int temp_mib[5]; /* Configuration */ static int cpu_running_mark; static int cpu_idle_mark; static int poll_ival; +static int passive_cooling_mark; static int vflag; +static int tflag; static volatile sig_atomic_t exit_requested; static power_src_t acline_status; @@ -357,10 +362,80 @@ { fprintf(stderr, -"usage: powerd [-v] [-a mode] [-b mode] [-i %%] [-n mode] [-p ival] [-r %%] [-P pidfile]\n"); +"usage: powerd [-v] [-a mode] [-b mode] [-i %%] [-n mode] [-p ival] [-r %%] [-P pidfile] [-T temperature] [-z thermal zone]\n"); exit(1); } +/* Convert temperature in the form of nnC, nnK and nnF into tenths + * of the K as used by ACPI subsystem. Temperatures without qualifier + * are assumed to be in Celsius. Temperatures, longer then three + * digits or having qualifiers other then C, K or F are considered + * invalid. Function will return negative value if invalid temperature + * is encountered as well as upon reaching error condition. + */ +static int +convert_temperature_to_acpi(const char *temp) +{ + regex_t preg; + regmatch_t pmatch[3]; + int result = 0; + char temp_value[4]; + /* If no qualifier is specified, defaulting to Celsius */ + char qualifier = 'C'; + + /* That would be an internal error -- return -1 */ + if (regcomp(&preg, "^([0-9]+)([CKF]?)$", REG_EXTENDED)) + result = -1; + /* If it looks like nothing we expect -- return -2 */ + if (!result && (regexec(&preg, temp, 3, pmatch, 0) == REG_NOMATCH)) + result = -2; + /* If we were able to successfully allocate 'preg' we need to free it */ + if (result != -1) + regfree(&preg); + /* If there were no problems so far, let's interpret the string */ + if (!result) { + if (pmatch[2].rm_so != pmatch[2].rm_eo) + qualifier = temp[pmatch[2].rm_so]; + /* + * Three digits of the temperature are enough for practical + * purposes + */ + if ((pmatch[1].rm_eo - pmatch[1].rm_so) <= 3) { + memcpy(temp_value, &temp[pmatch[1].rm_so], + pmatch[1].rm_eo - pmatch[1].rm_so); + temp_value[pmatch[1].rm_eo - pmatch[1].rm_so] = '\0'; + result = atoi(temp_value); + } + else + result = -3; + + if (result >= 0) { + switch (qualifier) { + case 'F': + result = ((result - 32) * 5) / 9; + /* Fallthrough is intentional */ + case 'C': + result += 273; + /* Fallthrough is intentional */ + case 'K': + result *= 10; + /* + * 150C (which equals to 4230 units + * here) should be more than modern + * electronics could endure. + */ + if (result > 4230) + result = -5; + break; + default: + result = -4; + break; + } + } + } + return(result); +} + int main(int argc, char * argv[]) { @@ -371,6 +446,7 @@ const char *pidfile = NULL; long idle, total; int curfreq, *freqs, i, *mwatts, numfreqs; + int temperature; int ch, mode, mode_ac, mode_battery, mode_none; uint64_t mjoules_used; size_t len; @@ -382,12 +458,17 @@ poll_ival = DEFAULT_POLL_INTERVAL; mjoules_used = 0; vflag = 0; + tflag = temperature = passive_cooling_mark = 0; + char tz_mib_name[40]; /* This should be sufficient to hold "hw.acpi.thermal.%s.temperature" */ /* User must be root to control frequencies. */ if (geteuid() != 0) errx(1, "must be root to run"); - while ((ch = getopt(argc, argv, "a:b:i:n:p:P:r:v")) != EOF) + /* Set default mib name for the thermal zone */ + snprintf(tz_mib_name, sizeof(tz_mib_name), "hw.acpi.thermal.%s.temperature", "tz0"); + + while ((ch = getopt(argc, argv, "a:b:i:n:p:P:r:T:v:z:")) != EOF) switch (ch) { case 'a': parse_mode(optarg, &mode_ac, ch); @@ -424,9 +505,27 @@ usage(); } break; + case 'T': + passive_cooling_mark = + convert_temperature_to_acpi(optarg); + if (passive_cooling_mark < 0) { + warnx("%s is not valid temperature for passive cooling", + optarg); + usage(); + } else if (passive_cooling_mark > 0) + tflag = 1; + break; case 'v': vflag = 1; break; + case 'z': + /* + * We will decipher thermal zone here but it will not + * be used unless -T was also present + */ + snprintf(tz_mib_name, sizeof(tz_mib_name), + "hw.acpi.thermal.%s.temperature", optarg); + break; default: usage(); } @@ -446,6 +545,11 @@ len = 4; if (sysctlnametomib("dev.cpu.0.freq_levels", levels_mib, &len)) err(1, "lookup freq_levels"); + if (tflag) { /* if no -T option don't fail if temp not available */ + len = 5; + if (sysctlnametomib(tz_mib_name, temp_mib, &len)) + err(1, "lookup temperature"); + } /* Check if we can read the idle time and supported freqs. */ if (read_usage_times(NULL, NULL)) @@ -528,6 +632,12 @@ warn("error reading current CPU frequency"); continue; } + /* Read current temperature if -T option is set */ + if (tflag) { + len = sizeof(temperature); + if (sysctl(temp_mib, 5, &temperature, &len, NULL, 0)) + err(1, "error reading current temperature"); + } if (vflag) { for (i = 0; i < numfreqs; i++) { @@ -559,20 +669,34 @@ continue; } - /* Always switch to the highest frequency in max mode. */ if (mode == MODE_MAX) { - if (curfreq != freqs[0]) { + /* Unless passive cooling override is in effect... */ + if (tflag && (temperature > passive_cooling_mark)) { + if (curfreq != freqs[numfreqs - 1]) { + if (vflag) { + printf("passive cooling override; " + "changing frequency to %d MHz\n", + freqs[numfreqs - 1]); + } + if (set_freq(freqs[numfreqs - 1])) { + warn("error setting CPU freq %d", + freqs[numfreqs - 1]); + continue; + } + } + /* ... always switch to the highest frequency in max mode. */ + } else if (curfreq != freqs[0]) { if (vflag) { printf("now operating on %s power; " - "changing frequency to %d MHz\n", - modes[acline_status], - freqs[0]); + "changing frequency to %d MHz\n", + modes[acline_status], + freqs[0]); } if (set_freq(freqs[0]) != 0) { warn("error setting CPU freq %d", - freqs[0]); + freqs[0]); continue; - } + } } continue; } @@ -583,6 +707,14 @@ warn("read_usage_times() failed"); continue; } + /* + * If temperature has risen over passive cooling mark, we + * would want to decrease frequency regardless of the load, + * Simplest way to go about this would be to report 100% + * idle CPU and let adaptive algorithm do its job. + */ + if (tflag && (temperature > passive_cooling_mark)) + idle = total; /* * If we're idle less than the active mark, bump up two levels. --Boundary_(ID_ZU9lgbhirRsxebqErOTx4w)-- From owner-freebsd-acpi@FreeBSD.ORG Thu Feb 7 15:51:18 2008 Return-Path: Delivered-To: acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 52BFB16A418 for ; Thu, 7 Feb 2008 15:51:18 +0000 (UTC) (envelope-from ume@mahoroba.org) Received: from ameno.mahoroba.org (ent.mahoroba.org [IPv6:2001:2f0:104:8010::1]) by mx1.freebsd.org (Postfix) with ESMTP id 9202613C465 for ; Thu, 7 Feb 2008 15:51:16 +0000 (UTC) (envelope-from ume@mahoroba.org) Received: from kasuga.mahoroba.org (IDENT:u6FwuCF0EhRVdKbdPAsXh57WVOnLvo6G/ApbYzCMLVM0Z7V7I56jJ5qziF/h9BPz@[IPv6:2001:200:161:1cf0:212:f0ff:fe52:6ac]) (user=ume mech=CRAM-MD5 bits=0) by ameno.mahoroba.org (8.13.8/8.13.8) with ESMTP/inet6 id m17Fp6p0083378 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 8 Feb 2008 00:51:07 +0900 (JST) (envelope-from ume@mahoroba.org) Date: Fri, 08 Feb 2008 00:50:54 +0900 Message-ID: From: Hajimu UMEMOTO To: "Alexandre \"Sunny\" Kovalenko" In-Reply-To: <1201733779.902.18.camel@RabbitsDen> References: <1201733779.902.18.camel@RabbitsDen> User-Agent: xcite1.57> Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (=?ISO-8859-4?Q?Shij=F2?=) APEL/10.7 Emacs/22.1 (i386-pc-freebsd) MULE/5.0 (SAKAKI) X-Operating-System: FreeBSD 6.3-RELEASE X-PGP-Key: http://www.imasy.or.jp/~ume/publickey.asc X-PGP-Fingerprint: 1F00 0B9E 2164 70FC 6DC5 BF5F 04E9 F086 BF90 71FE Organization: Internet Mutual Aid Society, YOKOHAMA MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (ameno.mahoroba.org [IPv6:2001:2f0:104:8010::1]); Fri, 08 Feb 2008 00:51:07 +0900 (JST) X-Virus-Scanned: by amavisd-new X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.2.4 X-Spam-Checker-Version: SpamAssassin 3.2.4 (2008-01-01) on ameno.mahoroba.org Cc: acpi@freebsd.org Subject: Re: [RFC] Patch to enable temperature ceiling in powerd X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Feb 2008 15:51:18 -0000 Hi, >>>>> On Wed, 30 Jan 2008 17:56:19 -0500 >>>>> "Alexandre \"Sunny\" Kovalenko" said: alex.kovalenko> Some time ago I have put together patch for powerd, which allows user to alex.kovalenko> specify the temperature threshold at which powerd will lower CPU alex.kovalenko> frequency no matter what the load was at the time. I recently had to alex.kovalenko> adapt it to the 7.0-PRERELEASE for someone with the overheating laptop, alex.kovalenko> which got me to think that it might be useful for someone else yet. alex.kovalenko> Basic idea is fairly simple -- check temperature in TZ0 and, if it has alex.kovalenko> reached certain value, either override frequency with the lowest alex.kovalenko> available (in the case of 'max' setting) or change idle time to 100% and alex.kovalenko> let adaptive algorithm decrease frequency gradually. alex.kovalenko> I imagine it also could be poor man's substitute for the low noise alex.kovalenko> acoustic policy ;) alex.kovalenko> If there is an interest, I will go ahead and submit a PR, otherwise it alex.kovalenko> will live in the mail archives for someone to find. Any comments, alex.kovalenko> suggestions or criticisms are welcome. alex.kovalenko> Temperature threshold (in Celsius) could be set by means of '-T' command alex.kovalenko> line option (as in '-T 60'). Our kernel has passive cooling feature, already. Is it not enough for you? Sincerely, -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan ume@mahoroba.org ume@{,jp.}FreeBSD.org http://www.imasy.org/~ume/ From owner-freebsd-acpi@FreeBSD.ORG Fri Feb 8 01:48:19 2008 Return-Path: Delivered-To: acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ECF1416A419; Fri, 8 Feb 2008 01:48:19 +0000 (UTC) (envelope-from alex.kovalenko@verizon.net) Received: from vms044pub.verizon.net (vms044pub.verizon.net [206.46.252.44]) by mx1.freebsd.org (Postfix) with ESMTP id D460D13C457; Fri, 8 Feb 2008 01:48:19 +0000 (UTC) (envelope-from alex.kovalenko@verizon.net) Received: from [10.0.3.231] ([70.111.176.151]) by vms044.mailsrvcs.net (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPA id <0JVW00HRPD086070@vms044.mailsrvcs.net>; Thu, 07 Feb 2008 19:48:09 -0600 (CST) Date: Thu, 07 Feb 2008 20:47:56 -0500 From: "Alexandre \"Sunny\" Kovalenko" In-reply-to: To: Hajimu UMEMOTO Message-id: <1202435276.1157.90.camel@RabbitsDen> MIME-version: 1.0 X-Mailer: Evolution 2.12.3 FreeBSD GNOME Team Port Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8BIT References: <1201733779.902.18.camel@RabbitsDen> Cc: acpi@freebsd.org Subject: Re: [RFC] Patch to enable temperature ceiling in powerd X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Feb 2008 01:48:20 -0000 On Fri, 2008-02-08 at 00:50 +0900, Hajimu UMEMOTO wrote: > Hi, > > >>>>> On Wed, 30 Jan 2008 17:56:19 -0500 > >>>>> "Alexandre \"Sunny\" Kovalenko" said: > > alex.kovalenko> Some time ago I have put together patch for powerd, which allows user to > alex.kovalenko> specify the temperature threshold at which powerd will lower CPU > alex.kovalenko> frequency no matter what the load was at the time. I recently had to > alex.kovalenko> adapt it to the 7.0-PRERELEASE for someone with the overheating laptop, > alex.kovalenko> which got me to think that it might be useful for someone else yet. > > alex.kovalenko> Basic idea is fairly simple -- check temperature in TZ0 and, if it has > alex.kovalenko> reached certain value, either override frequency with the lowest > alex.kovalenko> available (in the case of 'max' setting) or change idle time to 100% and > alex.kovalenko> let adaptive algorithm decrease frequency gradually. > > alex.kovalenko> I imagine it also could be poor man's substitute for the low noise > alex.kovalenko> acoustic policy ;) > > alex.kovalenko> If there is an interest, I will go ahead and submit a PR, otherwise it > alex.kovalenko> will live in the mail archives for someone to find. Any comments, > alex.kovalenko> suggestions or criticisms are welcome. > > alex.kovalenko> Temperature threshold (in Celsius) could be set by means of '-T' command > alex.kovalenko> line option (as in '-T 60'). > > Our kernel has passive cooling feature, already. Is it not enough for > you? I must have missed it somehow, if you could, please, point me in the right direction I will really appreciate it. > > Sincerely, > > -- > Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan > ume@mahoroba.org ume@{,jp.}FreeBSD.org > http://www.imasy.org/~ume/ -- Alexandre "Sunny" Kovalenko (Олександр Коваленко) From owner-freebsd-acpi@FreeBSD.ORG Fri Feb 8 04:56:11 2008 Return-Path: Delivered-To: acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 92DEB16A41A; Fri, 8 Feb 2008 04:56:11 +0000 (UTC) (envelope-from SRS0=b35f54ca481a23fdb8329a3de16b981d29c12770=604=es.net=oberman@es.net) Received: from postal1.es.net (postal1.es.net [IPv6:2001:400:14:3::6]) by mx1.freebsd.org (Postfix) with ESMTP id DD76413C447; Fri, 8 Feb 2008 04:56:10 +0000 (UTC) (envelope-from SRS0=b35f54ca481a23fdb8329a3de16b981d29c12770=604=es.net=oberman@es.net) Received: from ptavv.es.net (ptavv.es.net [198.128.4.29]) by postal1.es.net (Postal Node 1) with ESMTP (SSL) id OGM13608; Thu, 07 Feb 2008 20:56:08 -0800 Received: from ptavv.es.net (ptavv.es.net [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id 15C874500E; Thu, 7 Feb 2008 20:56:05 -0800 (PST) To: "Alexandre \"Sunny\" Kovalenko" In-Reply-To: Your message of "Thu, 07 Feb 2008 20:47:56 EST." <1202435276.1157.90.camel@RabbitsDen> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==_Exmh_1202446565_99651P"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Thu, 07 Feb 2008 20:56:05 -0800 From: "Kevin Oberman" Message-Id: <20080208045605.15C874500E@ptavv.es.net> X-Sender-IP: 198.128.4.29 X-Sender-Domain: es.net X-Recipent: ; ; ; X-Sender: X-To_Name: Alexandre \"Sunny\" Kovalenko X-To_Domain: verizon.net X-To: "Alexandre \"Sunny\" Kovalenko" X-To_Email: alex.kovalenko@verizon.net X-To_Alias: alex.kovalenko Cc: acpi@freebsd.org, Hajimu UMEMOTO Subject: Re: [RFC] Patch to enable temperature ceiling in powerd X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Feb 2008 04:56:11 -0000 --==_Exmh_1202446565_99651P Content-Type: text/plain; charset=us-ascii Content-Disposition: inline > Date: Thu, 07 Feb 2008 20:47:56 -0500 > From: "Alexandre \"Sunny\" Kovalenko" > Sender: owner-freebsd-acpi@freebsd.org > > > On Fri, 2008-02-08 at 00:50 +0900, Hajimu UMEMOTO wrote: > > Hi, > > > > >>>>> On Wed, 30 Jan 2008 17:56:19 -0500 > > >>>>> "Alexandre \"Sunny\" Kovalenko" said: > > > > alex.kovalenko> Some time ago I have put together patch for powerd, which allows user to > > alex.kovalenko> specify the temperature threshold at which powerd will lower CPU > > alex.kovalenko> frequency no matter what the load was at the time. I recently had to > > alex.kovalenko> adapt it to the 7.0-PRERELEASE for someone with the overheating laptop, > > alex.kovalenko> which got me to think that it might be useful for someone else yet. > > > > alex.kovalenko> Basic idea is fairly simple -- check temperature in TZ0 and, if it has > > alex.kovalenko> reached certain value, either override frequency with the lowest > > alex.kovalenko> available (in the case of 'max' setting) or change idle time to 100% and > > alex.kovalenko> let adaptive algorithm decrease frequency gradually. > > > > alex.kovalenko> I imagine it also could be poor man's substitute for the low noise > > alex.kovalenko> acoustic policy ;) > > > > alex.kovalenko> If there is an interest, I will go ahead and submit a PR, otherwise it > > alex.kovalenko> will live in the mail archives for someone to find. Any comments, > > alex.kovalenko> suggestions or criticisms are welcome. > > > > alex.kovalenko> Temperature threshold (in Celsius) could be set by means of '-T' command > > alex.kovalenko> line option (as in '-T 60'). > > > > Our kernel has passive cooling feature, already. Is it not enough for > > you? > I must have missed it somehow, if you could, please, point me in the > right direction I will really appreciate it. When the temperature reaches hw.acpi.thermal.tz0._PSV, the system will slow down until the CPU drops to a level below the _PSV value. The operation, if enabled, is under the control of BIOS (and/or the EC) and typically runs with substantial hysteresis, but is usually adequate for keeping the CPU temperature to a safe point. My Pentium-M 2GHz has a value of 94.5C for _PSV. This may seem very high, but the maximum "safe" operating temperature for the CPU is 100C, so it is designed for pretty high temperatures. Quiescent temperature runs about 51C and, during a CPU intensive operation such as a big build (e.g. make -j2 buildworld) will rise to near 80C. Before I blew two years of dust out of the heat sinks, I was seeing about 60C quiescent and about 95 during CPU intensive operations. Passive cooling was kicking in then and the temperature never went higher (although the build took longer). -- 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 --==_Exmh_1202446565_99651P Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (FreeBSD) Comment: Exmh version 2.5 06/03/2002 iD8DBQFHq+Dlkn3rs5h7N1ERAhK/AJwP23VOm9R57YAA6H1hK0uY1Q5OMQCfS8JI 98FLxBY8wRt2/7wFun7QeOk= =D3QH -----END PGP SIGNATURE----- --==_Exmh_1202446565_99651P-- From owner-freebsd-acpi@FreeBSD.ORG Fri Feb 8 06:17:42 2008 Return-Path: Delivered-To: acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1D89E16A46E for ; Fri, 8 Feb 2008 06:17:42 +0000 (UTC) (envelope-from nate@root.org) Received: from root.org (root.org [67.118.192.226]) by mx1.freebsd.org (Postfix) with ESMTP id 07F2C13C45B for ; Fri, 8 Feb 2008 06:17:41 +0000 (UTC) (envelope-from nate@root.org) Received: (qmail 48599 invoked from network); 8 Feb 2008 06:17:43 -0000 Received: from adsl-71-141-98-131.dsl.snfc21.pacbell.net (HELO ?192.168.1.77?) (nate-mail@71.141.98.131) by root.org with ESMTPA; 8 Feb 2008 06:17:43 -0000 Message-ID: <47ABF402.7030904@root.org> Date: Thu, 07 Feb 2008 22:17:38 -0800 From: Nate Lawson User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Kevin Oberman References: <20080208045605.15C874500E@ptavv.es.net> In-Reply-To: <20080208045605.15C874500E@ptavv.es.net> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: acpi@freebsd.org, Hajimu UMEMOTO , "Alexandre \"Sunny\" Kovalenko" Subject: Re: [RFC] Patch to enable temperature ceiling in powerd X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Feb 2008 06:17:42 -0000 Kevin Oberman wrote: >> From: "Alexandre \"Sunny\" Kovalenko" >> >> On Fri, 2008-02-08 at 00:50 +0900, Hajimu UMEMOTO wrote: >>>>>>>> On Wed, 30 Jan 2008 17:56:19 -0500 >>>>>>>> "Alexandre \"Sunny\" Kovalenko" said: >>> alex.kovalenko> Some time ago I have put together patch for powerd, which allows user to >>> alex.kovalenko> specify the temperature threshold at which powerd will lower CPU >>> alex.kovalenko> frequency no matter what the load was at the time. I recently had to >>> alex.kovalenko> adapt it to the 7.0-PRERELEASE for someone with the overheating laptop, >>> alex.kovalenko> which got me to think that it might be useful for someone else yet. >>> >>> alex.kovalenko> Basic idea is fairly simple -- check temperature in TZ0 and, if it has >>> alex.kovalenko> reached certain value, either override frequency with the lowest >>> alex.kovalenko> available (in the case of 'max' setting) or change idle time to 100% and >>> alex.kovalenko> let adaptive algorithm decrease frequency gradually. >>> >>> alex.kovalenko> I imagine it also could be poor man's substitute for the low noise >>> alex.kovalenko> acoustic policy ;) >>> >>> alex.kovalenko> If there is an interest, I will go ahead and submit a PR, otherwise it >>> alex.kovalenko> will live in the mail archives for someone to find. Any comments, >>> alex.kovalenko> suggestions or criticisms are welcome. >>> >>> alex.kovalenko> Temperature threshold (in Celsius) could be set by means of '-T' command >>> alex.kovalenko> line option (as in '-T 60'). >>> >>> Our kernel has passive cooling feature, already. Is it not enough for >>> you? >> I must have missed it somehow, if you could, please, point me in the >> right direction I will really appreciate it. > > When the temperature reaches hw.acpi.thermal.tz0._PSV, the system will > slow down until the CPU drops to a level below the _PSV value. The > operation, if enabled, is under the control of BIOS (and/or the EC) and > typically runs with substantial hysteresis, but is usually adequate for > keeping the CPU temperature to a safe point. > > My Pentium-M 2GHz has a value of 94.5C for _PSV. This may seem very > high, but the maximum "safe" operating temperature for the CPU is 100C, > so it is designed for pretty high temperatures. Quiescent temperature > runs about 51C and, during a CPU intensive operation such as a big build > (e.g. make -j2 buildworld) will rise to near 80C. > > Before I blew two years of dust out of the heat sinks, I was seeing > about 60C quiescent and about 95 during CPU intensive operations. > Passive cooling was kicking in then and the temperature never went > higher (although the build took longer). You can override the _PSV value by setting: hw.acpi.thermal.user_override=1 Then: hw.acpi.thermal.tz0._PSV=70C This will maintain a lower temperature. Note that user_override is potentially a bit dangerous because there is no sanity checking of the value you set. -- Nate From owner-freebsd-acpi@FreeBSD.ORG Fri Feb 8 09:42:38 2008 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 8F97816A4DC for ; Fri, 8 Feb 2008 09:42:38 +0000 (UTC) (envelope-from williamrockt@gmail.com) Received: from rv-out-0910.google.com (rv-out-0910.google.com [209.85.198.185]) by mx1.freebsd.org (Postfix) with ESMTP id 64C6913C457 for ; Fri, 8 Feb 2008 09:42:38 +0000 (UTC) (envelope-from williamrockt@gmail.com) Received: by rv-out-0910.google.com with SMTP id g13so2758641rvb.43 for ; Fri, 08 Feb 2008 01:42:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type; bh=XhV8K2N+O9d/ITK7aXdYfTWefs0LubAYTKqWvTdN1is=; b=JV0pVnBSR1RQYKvIIfkMROfpH4wQ9FJJUeUEatrQaSifpEkDcXMc6EYjlDF5ASnXezEOfjg0VrKkyMxNjUBoPonXu1aLjBoaFtb2uB9yaUBR/aiA7eHeyMdH+wBZK7nl34hVWN8/ba9I14y+OVGpZGEX2k39p49Ltw5Whf9qNa0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type; b=jlQr90gm0+sT96MxBJA3YxH5hGCbqL3PUOJx6a5FgBg2gyA4XJJWMi8zVj9P0PhTwyhumci/uAwvxV8y4ZjkfqN8sFBrQhjTV5lP0AzGW+OFRnKWdN9ZVBGA4p/vnhSQo0u3yL3hmdJYgxBxInIhEdmiijvh9jDt3ZpDSppyTWU= Received: by 10.140.179.25 with SMTP id b25mr8318765rvf.186.1202462105449; Fri, 08 Feb 2008 01:15:05 -0800 (PST) Received: by 10.141.86.17 with HTTP; Fri, 8 Feb 2008 01:15:05 -0800 (PST) Message-ID: <1ff813d0802080115s31b0c49fn93cc27e280f990d6@mail.gmail.com> Date: Fri, 8 Feb 2008 11:15:05 +0200 From: "william rockt" To: freebsd-acpi@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: FAQ Interactive, Video Production Tips In Your Email Box Every 15 Days 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, 08 Feb 2008 09:42:38 -0000 FAQ Interactive, Video Production Tips In Your Email Box Every 15 Days http://www.faqinteractive.com/ 1-866-268-5588 Dallas, TX (PRWEB) July 18, 2007 -- Television and video are huge parts of our lives and we are very accustomed to top quality programming. Today's audiences are sophisticated and expect broadcast quality video productions. If your video is anything less, your message and image will suffer greatly. To help video producers of all levels improve the quality of their projects, Eyecon Video Productions can email video production tips to producers every 15 days. Eyecon Video gives Internet users free video production tips from A to Z. With tips for the novices all the way to the pros, these emails have information for everyone with an interest in video production. To receive these tips, go to Eyecon Video Productions Web Site (). Then go to the Production Tips tab. Once there, click on the "Eyecon Tips" link to sign up. The emails include tips for lighting, audio, shooting, editing, location shooting, and even hints for those who have their own video production business. A new category has been created talking specifically about producing projects in high definition. These tips include quick pointers that share an idea to longer articles giving advice about concepts. All are aimed to assist anyone with the video production process. All articles and hints are written by video pros from around the world and include a credit to those who wrote them, many times including an email address and direct link to a web site they may have themselves. Eyecon Video Productions is a full service, award-winning professional video production company that can help guide a client from concept and scriptwriting to shooting, editing and duplication. Whether looking for Professional Video, Broadcast or High Definition, Eyecon is very budget-minded and can work within the parameters given by clients. Not all production companies are alike. Eyecon Video Production pride themselves on the high standards put in all their work. The videos they produce will be ones you will be proud to have represent your company and your clients. In addition to providing turnkey productions, Eyecon Video Productions also provide professional on-location production services in the Dallas/Ft. Worth, Texas area for out of town clients as well as production across the country and around the world. ### From owner-freebsd-acpi@FreeBSD.ORG Fri Feb 8 12:59:05 2008 Return-Path: Delivered-To: acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DE7F016A41B; Fri, 8 Feb 2008 12:59:04 +0000 (UTC) (envelope-from alex.kovalenko@verizon.net) Received: from vms044pub.verizon.net (vms044pub.verizon.net [206.46.252.44]) by mx1.freebsd.org (Postfix) with ESMTP id BFA0D13C47E; Fri, 8 Feb 2008 12:59:04 +0000 (UTC) (envelope-from alex.kovalenko@verizon.net) Received: from [10.0.3.231] ([70.111.176.151]) by vms044.mailsrvcs.net (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPA id <0JVX000C98251NO3@vms044.mailsrvcs.net>; Fri, 08 Feb 2008 06:58:54 -0600 (CST) Date: Fri, 08 Feb 2008 07:58:39 -0500 From: "Alexandre \"Sunny\" Kovalenko" In-reply-to: <47ABF402.7030904@root.org> To: Nate Lawson Message-id: <1202475519.7014.7.camel@RabbitsDen> MIME-version: 1.0 X-Mailer: Evolution 2.12.3 FreeBSD GNOME Team Port Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8BIT References: <20080208045605.15C874500E@ptavv.es.net> <47ABF402.7030904@root.org> Cc: acpi@freebsd.org, Hajimu UMEMOTO Subject: Re: [RFC] Patch to enable temperature ceiling in powerd X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Feb 2008 12:59:05 -0000 On Thu, 2008-02-07 at 22:17 -0800, Nate Lawson wrote: > Kevin Oberman wrote: > >> From: "Alexandre \"Sunny\" Kovalenko" > >> > >> On Fri, 2008-02-08 at 00:50 +0900, Hajimu UMEMOTO wrote: > >>>>>>>> On Wed, 30 Jan 2008 17:56:19 -0500 > >>>>>>>> "Alexandre \"Sunny\" Kovalenko" said: > >>> alex.kovalenko> Some time ago I have put together patch for powerd, which allows user to > >>> alex.kovalenko> specify the temperature threshold at which powerd will lower CPU > >>> alex.kovalenko> frequency no matter what the load was at the time. I recently had to > >>> alex.kovalenko> adapt it to the 7.0-PRERELEASE for someone with the overheating laptop, > >>> alex.kovalenko> which got me to think that it might be useful for someone else yet. > >>> > >>> alex.kovalenko> Basic idea is fairly simple -- check temperature in TZ0 and, if it has > >>> alex.kovalenko> reached certain value, either override frequency with the lowest > >>> alex.kovalenko> available (in the case of 'max' setting) or change idle time to 100% and > >>> alex.kovalenko> let adaptive algorithm decrease frequency gradually. > >>> > >>> alex.kovalenko> I imagine it also could be poor man's substitute for the low noise > >>> alex.kovalenko> acoustic policy ;) > >>> > >>> alex.kovalenko> If there is an interest, I will go ahead and submit a PR, otherwise it > >>> alex.kovalenko> will live in the mail archives for someone to find. Any comments, > >>> alex.kovalenko> suggestions or criticisms are welcome. > >>> > >>> alex.kovalenko> Temperature threshold (in Celsius) could be set by means of '-T' command > >>> alex.kovalenko> line option (as in '-T 60'). > >>> > >>> Our kernel has passive cooling feature, already. Is it not enough for > >>> you? > >> I must have missed it somehow, if you could, please, point me in the > >> right direction I will really appreciate it. > > > > When the temperature reaches hw.acpi.thermal.tz0._PSV, the system will > > slow down until the CPU drops to a level below the _PSV value. The > > operation, if enabled, is under the control of BIOS (and/or the EC) and > > typically runs with substantial hysteresis, but is usually adequate for > > keeping the CPU temperature to a safe point. > > > > My Pentium-M 2GHz has a value of 94.5C for _PSV. This may seem very > > high, but the maximum "safe" operating temperature for the CPU is 100C, > > so it is designed for pretty high temperatures. Quiescent temperature > > runs about 51C and, during a CPU intensive operation such as a big build > > (e.g. make -j2 buildworld) will rise to near 80C. > > > > Before I blew two years of dust out of the heat sinks, I was seeing > > about 60C quiescent and about 95 during CPU intensive operations. > > Passive cooling was kicking in then and the temperature never went > > higher (although the build took longer). > > You can override the _PSV value by setting: > hw.acpi.thermal.user_override=1 > > Then: > hw.acpi.thermal.tz0._PSV=70C > > This will maintain a lower temperature. Note that user_override is > potentially a bit dangerous because there is no sanity checking of the > value you set. > I'd say it is not working here (ThinkPad X60 1709-73U, BIOS was up to date as of day before yesterday, FreeBSD 7.0 as of January 31): RabbitsDen# sysctl hw.acpi.thermal hw.acpi.thermal.min_runtime: 0 hw.acpi.thermal.polling_rate: 10 --> hw.acpi.thermal.user_override: 1 --> hw.acpi.thermal.tz0.temperature: 67.0C hw.acpi.thermal.tz0.active: -1 hw.acpi.thermal.tz0.passive_cooling: 0 hw.acpi.thermal.tz0.thermal_flags: 1 --> hw.acpi.thermal.tz0._PSV: 60.0C hw.acpi.thermal.tz0._HOT: -1 hw.acpi.thermal.tz0._CRT: 127.0C hw.acpi.thermal.tz0._ACx: -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 --> hw.acpi.thermal.tz1.temperature: 68.0C hw.acpi.thermal.tz1.active: -1 hw.acpi.thermal.tz1.passive_cooling: 0 hw.acpi.thermal.tz1.thermal_flags: 1 --> hw.acpi.thermal.tz1._PSV: 60.0C hw.acpi.thermal.tz1._HOT: -1 hw.acpi.thermal.tz1._CRT: 97.0C hw.acpi.thermal.tz1._ACx: -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 Anything, I have missed? -- Alexandre "Sunny" Kovalenko (Олександр Коваленко) From owner-freebsd-acpi@FreeBSD.ORG Fri Feb 8 18:06:06 2008 Return-Path: Delivered-To: acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A177A16A417 for ; Fri, 8 Feb 2008 18:06:06 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from gaia.nimnet.asn.au (nimbin.lnk.telstra.net [139.130.45.143]) by mx1.freebsd.org (Postfix) with ESMTP id 9A6DA13C457 for ; Fri, 8 Feb 2008 18:06:03 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from localhost (smithi@localhost) by gaia.nimnet.asn.au (8.8.8/8.8.8R1.5) with SMTP id FAA19926; Sat, 9 Feb 2008 05:05:54 +1100 (EST) (envelope-from smithi@nimnet.asn.au) Date: Sat, 9 Feb 2008 05:05:53 +1100 (EST) From: Ian Smith To: Nate Lawson In-Reply-To: <47ABF402.7030904@root.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: acpi@freebsd.org, Hajimu UMEMOTO , "Alexandre \"Sunny\" Kovalenko" Subject: Re: [RFC] Patch to enable temperature ceiling in powerd X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Feb 2008 18:06:06 -0000 On Thu, 7 Feb 2008, Nate Lawson wrote: > Kevin Oberman wrote: > >> From: "Alexandre \"Sunny\" Kovalenko" > >> > >> On Fri, 2008-02-08 at 00:50 +0900, Hajimu UMEMOTO wrote: > >>>>>>>> On Wed, 30 Jan 2008 17:56:19 -0500 > >>>>>>>> "Alexandre \"Sunny\" Kovalenko" said: > >>> alex.kovalenko> Some time ago I have put together patch for powerd, which allows user to > >>> alex.kovalenko> specify the temperature threshold at which powerd will lower CPU > >>> alex.kovalenko> frequency no matter what the load was at the time. I recently had to > >>> alex.kovalenko> adapt it to the 7.0-PRERELEASE for someone with the overheating laptop, > >>> alex.kovalenko> which got me to think that it might be useful for someone else yet. > >>> > >>> alex.kovalenko> Basic idea is fairly simple -- check temperature in TZ0 and, if it has > >>> alex.kovalenko> reached certain value, either override frequency with the lowest > >>> alex.kovalenko> available (in the case of 'max' setting) or change idle time to 100% and > >>> alex.kovalenko> let adaptive algorithm decrease frequency gradually. > >>> > >>> alex.kovalenko> I imagine it also could be poor man's substitute for the low noise > >>> alex.kovalenko> acoustic policy ;) > >>> > >>> alex.kovalenko> If there is an interest, I will go ahead and submit a PR, otherwise it > >>> alex.kovalenko> will live in the mail archives for someone to find. Any comments, > >>> alex.kovalenko> suggestions or criticisms are welcome. > >>> > >>> alex.kovalenko> Temperature threshold (in Celsius) could be set by means of '-T' command > >>> alex.kovalenko> line option (as in '-T 60'). > >>> > >>> Our kernel has passive cooling feature, already. Is it not enough for > >>> you? > >> I must have missed it somehow, if you could, please, point me in the > >> right direction I will really appreciate it. > > > > When the temperature reaches hw.acpi.thermal.tz0._PSV, the system will > > slow down until the CPU drops to a level below the _PSV value. The > > operation, if enabled, is under the control of BIOS (and/or the EC) and > > typically runs with substantial hysteresis, but is usually adequate for > > keeping the CPU temperature to a safe point. Doesn't ACPI take this control from BIOS, using cpufreq and _thermal? > > My Pentium-M 2GHz has a value of 94.5C for _PSV. This may seem very > > high, but the maximum "safe" operating temperature for the CPU is 100C, > > so it is designed for pretty high temperatures. Quiescent temperature > > runs about 51C and, during a CPU intensive operation such as a big build > > (e.g. make -j2 buildworld) will rise to near 80C. > > > > Before I blew two years of dust out of the heat sinks, I was seeing > > about 60C quiescent and about 95 during CPU intensive operations. > > Passive cooling was kicking in then and the temperature never went > > higher (although the build took longer). > > You can override the _PSV value by setting: > hw.acpi.thermal.user_override=1 > > Then: > hw.acpi.thermal.tz0._PSV=70C > > This will maintain a lower temperature. Note that user_override is > potentially a bit dangerous because there is no sanity checking of the > value you set. Assuming passive cooling on tz0 is enabled and working for machine x, acpi_thermal's acpi_tz_cooling_thread saves current freq then uses the enabled cpufreq driver/s (eg est + p4tcc or acpi_perf ..) to reduce freq according to temperature differential until temp < _PSV, then restores the previously saved cpu freq - if I'm reading that right? Meanwhile powerd, every polling interval default .5s, if in max mode or adaptive mode under load, is trying to increase freq every time, failing and emitting warnings, no? Or maybe powerd is reducing freq if (now) idle(r), which I guess should succeed, perhaps without confusing acpi_tz_cooling_thread's adjustments? So, wondering how powerd might learn of and defer to thermal tinkering? Cheers, Ian (still trying to fit pieces of the ACPI jigsaw puzzle ..) From owner-freebsd-acpi@FreeBSD.ORG Fri Feb 8 20:53:55 2008 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 6470216A468 for ; Fri, 8 Feb 2008 20:53:55 +0000 (UTC) (envelope-from cihan@enderunix.org) Received: from istanbul.enderunix.org (freefall.marmara.edu.tr [193.140.143.23]) by mx1.freebsd.org (Postfix) with ESMTP id 7603513C4CC for ; Fri, 8 Feb 2008 20:53:53 +0000 (UTC) (envelope-from cihan@enderunix.org) Received: (qmail 81628 invoked by uid 1040); 8 Feb 2008 20:54:00 -0000 Received: from unknown (HELO localhost) (cihan@85.105.200.118) by 0 with ESMTPA; 8 Feb 2008 20:53:59 -0000 Date: Fri, 8 Feb 2008 22:53:41 +0200 From: =?utf-8?B?Q2loYW4gS8O2bWXDp2/En2x1?= X-Mailer: The Bat! (v3.99.29) UNREG X-Priority: 3 (Normal) Message-ID: <1219327882.20080208225341@enderunix.org> To: freebsd-acpi@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: quoted-printable X-Antivirus: avast! (VPS 080208-0, 08.02.2008), Outbound message X-Antivirus-Status: Clean X-SMTP-Filter: SurGATE SMTP Filter Engine Release 1.0.1 http://www.endersys.com X-SurGATE-Result: Clean (Content eval: -4.40 points) Subject: acpi status file 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, 08 Feb 2008 20:53:55 -0000 hello list I want to find source code which writes battery status in proc/acpi/state file. where is this code in freebsd tree? thanks --=20 Cihan K=F6me=E7o=F0lu, EnderUNIX SDT mailto:cihan@enderunix.org From owner-freebsd-acpi@FreeBSD.ORG Sat Feb 9 14:01:57 2008 Return-Path: Delivered-To: freebsd-acpi@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 46E9C16A41B; Sat, 9 Feb 2008 14:01:57 +0000 (UTC) (envelope-from remko@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 201B013C4D5; Sat, 9 Feb 2008 14:01:57 +0000 (UTC) (envelope-from remko@FreeBSD.org) Received: from freefall.freebsd.org (remko@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m19E1uJQ099758; Sat, 9 Feb 2008 14:01:56 GMT (envelope-from remko@freefall.freebsd.org) Received: (from remko@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m19E1urf099754; Sat, 9 Feb 2008 14:01:56 GMT (envelope-from remko) Date: Sat, 9 Feb 2008 14:01:56 GMT Message-Id: <200802091401.m19E1urf099754@freefall.freebsd.org> To: merlyn500@gmail.com, remko@FreeBSD.org, freebsd-acpi@FreeBSD.org From: remko@FreeBSD.org Cc: Subject: Re: bin/109760: [acpi]: [modules] kldunload acpi_video - crash X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Feb 2008 14:01:57 -0000 Synopsis: [acpi]: [modules] kldunload acpi_video - crash State-Changed-From-To: feedback->closed State-Changed-By: remko State-Changed-When: Sat Feb 9 14:01:56 UTC 2008 State-Changed-Why: feedback timeout. http://www.freebsd.org/cgi/query-pr.cgi?pr=109760 From owner-freebsd-acpi@FreeBSD.ORG Sat Feb 9 19:19:44 2008 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 0AD2A16A417 for ; Sat, 9 Feb 2008 19:19:44 +0000 (UTC) (envelope-from nate@root.org) Received: from root.org (root.org [67.118.192.226]) by mx1.freebsd.org (Postfix) with ESMTP id CC13213C455 for ; Sat, 9 Feb 2008 19:19:43 +0000 (UTC) (envelope-from nate@root.org) Received: (qmail 27269 invoked from network); 9 Feb 2008 19:19:44 -0000 Received: from ppp-71-139-43-58.dsl.snfc21.pacbell.net (HELO ?10.0.5.18?) (nate-mail@71.139.43.58) by root.org with ESMTPA; 9 Feb 2008 19:19:44 -0000 Message-ID: <47ADFCCD.3030402@root.org> Date: Sat, 09 Feb 2008 11:19:41 -0800 From: Nate Lawson User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: =?UTF-8?B?Q2loYW4gS8O2bWXDp2/En2x1?= References: <1219327882.20080208225341@enderunix.org> In-Reply-To: <1219327882.20080208225341@enderunix.org> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-acpi@freebsd.org Subject: Re: acpi status file X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Feb 2008 19:19:44 -0000 Cihan Kömeçoğlu wrote: > hello list > > I want to find source code which writes battery status in > proc/acpi/state file. where is this code in freebsd tree? > > thanks Linux uses /proc. We use sysctl. Run sysctl hw.acpi or man acpi. -- Nate From owner-freebsd-acpi@FreeBSD.ORG Sat Feb 9 21:34:57 2008 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 8C29F16A421 for ; Sat, 9 Feb 2008 21:34:57 +0000 (UTC) (envelope-from LoN_Kamikaze@gmx.de) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by mx1.freebsd.org (Postfix) with SMTP id D378413C46E for ; Sat, 9 Feb 2008 21:34:56 +0000 (UTC) (envelope-from LoN_Kamikaze@gmx.de) Received: (qmail invoked by alias); 09 Feb 2008 21:08:15 -0000 Received: from nat-wh-1.rz.uni-karlsruhe.de (EHLO mobileKamikaze.norad) [129.13.72.169] by mail.gmx.net (mp050) with SMTP; 09 Feb 2008 22:08:15 +0100 X-Authenticated: #5465401 X-Provags-ID: V01U2FsdGVkX18zDgY6aiYziuW/6py9Sfpas6DEGsxIXoJgOQEoJj W3BcWGzYvwxcmt Message-ID: <47AE163F.9000008@gmx.de> Date: Sat, 09 Feb 2008 22:08:15 +0100 From: Dominic Fandrey User-Agent: Thunderbird 2.0.0.9 (X11/20080205) MIME-Version: 1.0 To: freebsd-acpi@freebsd.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 Subject: Acpi problems with HP 6501b X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Feb 2008 21:34:57 -0000 Apart from there not being a specific acpi module for HP notebooks my new HP Compaq 6510b GR695EA#ABD has some other problems. First of all there seems to be a fault in the ACPI-BIOS, for it defines a CRT of 256°C for tz0: Feb 9 21:46:37 mobileKamikaze kernel: acpi_tz0: _CRT value is absurd, ignored (256.0C) This message is quite uselessly posted every couple of seconds. I fear this asks for one more addition to the quirks, for I doubt the vendor will come up with a BIOS update that fixes this behaviour. The next problem is that acpiconf -s # doesn't work: # acpiconf -s 3 0 /root acpiconf: request sleep type (3) failed: Operation not supported # acpiconf -s 4 74 /root acpiconf: request sleep type (4) failed: Operation not supported # acpiconf -s 5 74 /root acpiconf: request sleep type (4) failed: Operation not supported # 74 /root The number on the right displays the return value of the previous command. Here are some select sysctl values: hw.acpi.supported_sleep_state: S3 S4 S5 hw.acpi.power_button_state: S5 hw.acpi.sleep_button_state: S3 hw.acpi.lid_switch_state: NONE hw.acpi.standby_state: S1 hw.acpi.suspend_state: S3 hw.acpi.sleep_delay: 1 hw.acpi.s4bios: 1 I was especially happy about the last value. To bad I cannot put it to the test.