From owner-freebsd-acpi@FreeBSD.ORG Sun Feb 17 04:43:24 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 0CDDC16A41A for ; Sun, 17 Feb 2008 04:43:24 +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 8255E13C457 for ; Sun, 17 Feb 2008 04:43:21 +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 PAA17306; Sun, 17 Feb 2008 15:43:15 +1100 (EST) (envelope-from smithi@nimnet.asn.au) Date: Sun, 17 Feb 2008 15:43:14 +1100 (EST) From: Ian Smith To: acpi@freebsd.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: Richard Arends Subject: Re: Management of Thermal (fwd) 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, 17 Feb 2008 04:43:24 -0000 Hi, Maybe pertinent to current discussions of thermal management on various thinkpads .. I just checked acpi_ibm.c 1.7.2.4 (6.x) and see that it still doesn't include the fan level support introduced to 7.x at 1.10 http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/acpi_support/acpi_ibm.c.diff?r1=text&tr1=1.10&r2=text&tr2=1.7.2.4 Is there any particular reason this wasn't / can't be MFC'd to 6.x? cheers, Ian ---------- Forwarded message ---------- Date: Tue, 16 Oct 2007 21:55:51 +0200 From: Richard Arends To: Ian Smith Cc: Norberto Meijome , FreeBSD Mobile ML Subject: Re: Management of Thermal On Wed, Oct 17, 2007 at 02:27:48AM +1000, Ian Smith wrote: Ian, > Just browsing: > http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/acpi_support/acpi_ibm.c > > What revision of that have you? It's not clear to me tha this fan level > stuff, documented with rev 1.10, was ever MFC'd to 6-STABLE. If I'm > diffing the right versions it appears that it wasn't, and the comment on > 1.7.2.3 (6.X) says only 'MFC: 1.11, 1.12', but that seems not so, if I'm > reading the diffs against any of those versions right (incl 1.14 @ 7.0) You are absolutely right. On my stable tree I MFC'ed the acpi_ibm a few times myself. Totaly forget about it :) Now i'm running the normal acpi_ibm in stable again and indeed the fan_level hook isn't there anymore. Adapting acpi_ibm to stable was not that hard but you can also try to run RELENG_7, it is fairly stable at the moment :) -- Regards, Richard. From owner-freebsd-acpi@FreeBSD.ORG Sun Feb 17 10:49: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 5723516A417 for ; Sun, 17 Feb 2008 10:49:54 +0000 (UTC) (envelope-from dieterich.joh@googlemail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.155]) by mx1.freebsd.org (Postfix) with ESMTP id D479113C447 for ; Sun, 17 Feb 2008 10:49:53 +0000 (UTC) (envelope-from dieterich.joh@googlemail.com) Received: by fg-out-1718.google.com with SMTP id 16so1093352fgg.35 for ; Sun, 17 Feb 2008 02:49:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding:from; bh=nTLGEziwIK/VfsrTQWiFBUA7UNJPxTpowlSmt0r69Vs=; b=aoWAF+LqeblYyv99UHIo4UQ3uGemLkLs+vxM6/lJVEvVa+h8+vrVQJTnBawcXSDj4kP/GX5/F/S1NE7Zq2bjohGsV2uMi5BTSfKZfy0PJEVIorKi/eYBAqgMYgg5Fj9JhiQV4iRv6FUZVrGepcZteUQbQH1jSQAm7NVW9jK0PNU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=message-id:date:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding:from; b=JjF04MFmUHjzJDUGjgbwFXfYVBYoUppi6rCibVKIy8KFCKKtJrGq6lW701Qnqbir80WK/rXZQ1DfO6tVFV2Lqm2sOKUNDnf0iNrfHXlh3QTplxcLSlqe227nxzg0LdWT/5Ges/XKUNlCppqHGpEal3bVWE0qrUrbDwF0KtwJwWY= Received: by 10.86.59.2 with SMTP id h2mr4663118fga.63.1203245392359; Sun, 17 Feb 2008 02:49:52 -0800 (PST) Received: from ?192.168.1.100? ( [79.210.112.37]) by mx.google.com with ESMTPS id l12sm6871549fgb.8.2008.02.17.02.49.50 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 17 Feb 2008 02:49:51 -0800 (PST) Message-ID: <47B8114D.1000707@gmail.com> Date: Sun, 17 Feb 2008 11:49:49 +0100 User-Agent: Thunderbird 2.0.0.9 (X11/20080213) MIME-Version: 1.0 To: ume@freebsd.org, freebsd-acpi@freebsd.org References: <20080208045605.15C874500E@ptavv.es.net> <47ABF402.7030904@root.org> <1202475519.7014.7.camel@RabbitsDen> <1203126071.833.19.camel@RabbitsDen> <47B6B913.9020505@gmail.com> <47B6CC48.5070009@gmail.com> <47B6CD54.3020806@gmail.com> <47B71194.8090804@gmail.com> <47B71804.40002@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit From: Johannes Dieterich Cc: 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: Sun, 17 Feb 2008 10:49:54 -0000 Hi, Hajimu UMEMOTO wrote: > Hi, > >>>>>> On Sat, 16 Feb 2008 18:06:12 +0100 >>>>>> Johannes Dieterich said: > >> dieterich.joh> # hw.acpi.thermal.tz1.passive_cooling=1 >> dieterich.joh> su: hw.acpi.thermal.tz1.passive_cooling=1: command not found >> >> It should be `sysctl hw.acpi.thermal.tz1.passive_cooling=1'. > dieterich.joh> Sorry. Just a typing error. Works now. Should I try to make buildworld? > > No problem. Please make sure hw.acpi.thermal.tz1.passive_cooling is 1 > by typing `sysctl hw.acpi.thermal.tz1.passive_cooling' before trying. > If hw.acpi.thermal.tz1.passive_cooling is 1, passive cooling should be > working. I can confirm that it works, I can get buildworld through. > > You can see if passive cooling is actually working by setting > hw.acpi.verbose to 1 using sysctl. While hw.acpi.verbose is 1, > changing cpufreq by passive cooling is logged into /var/log/messages > like: > > Feb 17 02:26:19 kasuga kernel: acpi_tz0: temperature 86.8C: decreasing clock speed from 1200 MHz to 1000 MHz > Feb 17 02:26:23 kasuga kernel: acpi_tz0: temperature 78.8C: resuming previous clock speed (1200 MHz) > # sysctl hw.acpi.verbose hw.acpi.verbose: 1 but no information is written to /var/log/messages. I've tailed it during buildworld and the only informations written there are from my atheros card. Another question: Ian Smith asked here on the list why the fan levels in acpi_ibm would not have not been implemented yet to 6.x. Since my notebook started overheating when moving to 7, could that be a reason? On my first mail to freebsd-stable I also quoted a case from the LKML where someone with a X60s reported overheating and the problem was in the fan levels of the (linux) acpi_ibm module, if I recall it correct. Regards, Johannes From owner-freebsd-acpi@FreeBSD.ORG Sun Feb 17 13:40:17 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 0609E16A46B for ; Sun, 17 Feb 2008 13:40:17 +0000 (UTC) (envelope-from dieterich.joh@googlemail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.153]) by mx1.freebsd.org (Postfix) with ESMTP id 84E6213C448 for ; Sun, 17 Feb 2008 13:40:16 +0000 (UTC) (envelope-from dieterich.joh@googlemail.com) Received: by fg-out-1718.google.com with SMTP id 16so1131740fgg.35 for ; Sun, 17 Feb 2008 05:40:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding:from; bh=WMLEoAyUvc/GQsdLXwlnvgHIKic5SD32MyxBGYqxTIs=; b=lTGmtbLFMDhZVPVNNZc/q4s5sJBqrMnKn0vjKV36YKkf5TPC28OfvtiWVIkej5rE9Ku74pNlNXF/sBJU0gs3I6KmLEeeniQ+/H3v1uFvKya8lsbraIQi147hqULe2zD5XUBcuAuKZnjgUkIvrts1Fd66oBSeWnvx2YtaCr+Q37Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=message-id:date:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding:from; b=XF6+i/mLs4VikBggbC7pVKoxR57I1LX+TOyknDQ7kXVr4icIAb5ul+VxsnhMlC5WXD69qQc2tlJ2Jn5CPmG1lg28cexPkg+TmQWZmvuHXokI2C+EBQz9isgAwP+3LDzxiwRShIe9s/kautR90ypiqDksOcv6jTOdAqCslFTWJVc= Received: by 10.86.96.18 with SMTP id t18mr4835947fgb.13.1203255614931; Sun, 17 Feb 2008 05:40:14 -0800 (PST) Received: from ?192.168.1.100? ( [79.210.112.37]) by mx.google.com with ESMTPS id e20sm8859174fga.1.2008.02.17.05.40.11 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 17 Feb 2008 05:40:13 -0800 (PST) Message-ID: <47B83939.300@gmail.com> Date: Sun, 17 Feb 2008 14:40:09 +0100 User-Agent: Thunderbird 2.0.0.9 (X11/20080213) MIME-Version: 1.0 To: freebsd-acpi@freebsd.org, ume@freebsd.org References: <20080208045605.15C874500E@ptavv.es.net> <47ABF402.7030904@root.org> <1202475519.7014.7.camel@RabbitsDen> <1203126071.833.19.camel@RabbitsDen> <47B6B913.9020505@gmail.com> <47B6CC48.5070009@gmail.com> <47B6CD54.3020806@gmail.com> <47B71194.8090804@gmail.com> <47B71804.40002@gmail.com> <47B8114D.1000707@gmail.com> In-Reply-To: <47B8114D.1000707@gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit From: Johannes Dieterich Cc: 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: Sun, 17 Feb 2008 13:40:17 -0000 Hi, some not so nice news: Johannes Dieterich wrote: > Hi, > > Hajimu UMEMOTO wrote: >> Hi, >> >>>>>>> On Sat, 16 Feb 2008 18:06:12 +0100 >> No problem. Please make sure hw.acpi.thermal.tz1.passive_cooling is 1 >> by typing `sysctl hw.acpi.thermal.tz1.passive_cooling' before trying. >> If hw.acpi.thermal.tz1.passive_cooling is 1, passive cooling should be >> working. > I can confirm that it works, I can get buildworld through. That still holds true. Unfortunately portupgrade gcc overheats it again. Regards, Johannes From owner-freebsd-acpi@FreeBSD.ORG Sun Feb 17 15:10: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 83DB916A41A for ; Sun, 17 Feb 2008 15:10:38 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from falcon.cybervisiontech.com (falcon.cybervisiontech.com [217.20.163.9]) by mx1.freebsd.org (Postfix) with ESMTP id 09CFA13C4E9 for ; Sun, 17 Feb 2008 15:10:37 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from localhost (localhost [127.0.0.1]) by falcon.cybervisiontech.com (Postfix) with ESMTP id 2F39943F5FE for ; Sun, 17 Feb 2008 17:10:36 +0200 (EET) X-Virus-Scanned: Debian amavisd-new at falcon.cybervisiontech.com Received: from falcon.cybervisiontech.com ([127.0.0.1]) by localhost (falcon.cybervisiontech.com [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id S14zG2GBunch for ; Sun, 17 Feb 2008 17:10:36 +0200 (EET) Received: from [10.74.70.239] (unknown [193.138.145.53]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by falcon.cybervisiontech.com (Postfix) with ESMTP id 78E0B43F5FC for ; Sun, 17 Feb 2008 17:10:35 +0200 (EET) Message-ID: <47B84E61.3060401@icyb.net.ua> Date: Sun, 17 Feb 2008 17:10:25 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.9 (X11/20071208) MIME-Version: 1.0 To: freebsd-acpi@freebsd.org References: <479F0ED4.9030709@icyb.net.ua> <479F62D9.6080703@root.org> <47A33CCB.3090902@icyb.net.ua> <47B0C10F.6000109@icyb.net.ua> <47B4103A.6090902@icyb.net.ua> <47B4A103.7040801@icyb.net.ua> <47B4B31A.4020605@icyb.net.ua> In-Reply-To: <47B4B31A.4020605@icyb.net.ua> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: cx_lowest and CPU usage 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, 17 Feb 2008 15:10:38 -0000 on 14/02/2008 23:31 Andriy Gapon said the following: > I ran a series of tests, repeating each twice to be sure that I didn't > make any mistake. > All tests were performed in single-user mode, so the system was as idle > as possible, top reported idle as 99.N% - 100%. > Then I set hw.acpi.cpu.cx_lowest=C2 and ran top again. > Here's the results: > GENERIC, SCHED_4BSD, default HZ=1000 ==> C2-interrupt 11-14% (!!) > GENERIC, SCHED_4BSD, kern.hz="100" ==> C2-interrupt 99-100% > customized kernel, SCHED_ULE, default HZ=1000 ==> C2-interrupt 99-100% > customized kernel, SCHED_ULE, kern.hz="100" ==> C2-interrupt 99-100% I did some testing and here are some additional data. Running with sched_ule and hz=1000 I measured that mean time spent in C2 state (from starting to go into it, till completely returning from it) is ~860us (end_time - start_time, no overhead adjustments). Additionally, 98.1% of sleeps lasted 800-900us, 1.8% lasted 700-800us, the rest is spread almost uniformly over the remaining intervals of range 0-1000%. Here's a typical backtrace for statclock execution: #9 0xc04cce26 in statclock (usermode=0) at /system/src/sys/kern/kern_clock.c:447 #10 0xc06b5f0c in rtcintr (frame=0xcfb30c78) at /system/src/sys/i386/isa/clock.c:236 #11 0xc06a5275 in intr_execute_handlers (isrc=0xc0736900, frame=0xcfb30c78) at /system/src/sys/i386/i386/intr_machdep.c:362 #12 0xc06b558c in atpic_handle_intr (vector=8, frame=0xcfb30c78) at /system/src/sys/i386/isa/atpic.c:596 #13 0xc06a0d71 in Xatpic_intr8 () at atpic_vector.s:70 #14 0xc06a70c9 in spinlock_exit () at cpufunc.h:365 #15 0xc04e6993 in ithread_loop (arg=0xc22f5980) at /system/src/sys/kern/kern_intr.c:1137 #16 0xc04e32c1 in fork_exit (callout=0xc04e6640 , arg=0xc22f5980, frame=0xcfb30d38) at /system/src/sys/kern/kern_fork.c:754 #17 0xc06a0bc0 in fork_trampoline () at /system/src/sys/i386/i386/exception.s:205 I.e. swi4 kernel thread is "caught" by IRQ8 just when it exits from thread_unlock() in the following snippet: 1132 if (!ithd->it_need && !(ithd->it_flags & IT_DEAD)) { 1133 TD_SET_IWAIT(td); 1134 ie->ie_count = 0; 1135 mi_switch(SW_VOL, NULL); 1136 } 1137 thread_unlock(td); This happens almost deterministically. -- Andriy Gapon From owner-freebsd-acpi@FreeBSD.ORG Sun Feb 17 16:56:42 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 550F116A419 for ; Sun, 17 Feb 2008 16:56:42 +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 0FA5213C442 for ; Sun, 17 Feb 2008 16:56:41 +0000 (UTC) (envelope-from ume@mahoroba.org) Received: from kasuga.mahoroba.org (IDENT:5VwfW5o0HrI/VAU0AdYRZ1MmSR1MPn57QcQQjPYoYO9lhlk1XHTR0+xwVBgdHOU9@kasuga.mahoroba.org [IPv6:2001:2f0:104:8010:20b:97ff:fe2e:b521]) (user=ume mech=CRAM-MD5 bits=0) by ameno.mahoroba.org (8.13.8/8.13.8) with ESMTP/inet6 id m1HGuP8W023926 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 18 Feb 2008 01:56:31 +0900 (JST) (envelope-from ume@mahoroba.org) Date: Mon, 18 Feb 2008 01:56:25 +0900 Message-ID: From: Hajimu UMEMOTO To: Johannes Dieterich In-Reply-To: <47B8114D.1000707@gmail.com> References: <20080208045605.15C874500E@ptavv.es.net> <47ABF402.7030904@root.org> <1202475519.7014.7.camel@RabbitsDen> <1203126071.833.19.camel@RabbitsDen> <47B6B913.9020505@gmail.com> <47B6CC48.5070009@gmail.com> <47B6CD54.3020806@gmail.com> <47B71194.8090804@gmail.com> <47B71804.40002@gmail.com> <47B8114D.1000707@gmail.com> 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-p1 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]); Mon, 18 Feb 2008 01:56:31 +0900 (JST) X-Virus-Scanned: by amavisd-new X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 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: freebsd-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: Sun, 17 Feb 2008 16:56:42 -0000 Hi, >>>>> On Sun, 17 Feb 2008 11:49:49 +0100 >>>>> Johannes Dieterich said: dieterich.joh> # sysctl hw.acpi.verbose dieterich.joh> hw.acpi.verbose: 1 dieterich.joh> but no information is written to /var/log/messages. I've tailed it dieterich.joh> during buildworld and the only informations written there are from my dieterich.joh> atheros card. It's strange to me. I wish to see the value of _TC1, _TC2 and _TSP for tz1. Could you apply the following diff and show me the output of `sysctl hw.acpi.thermal.tz1'? http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/acpica/acpi_thermal.c.diff?r1=1.65;r2=1.66 dieterich.joh> Another question: Ian Smith asked here on the list why the fan levels in dieterich.joh> acpi_ibm would not have not been implemented yet to 6.x. Since my dieterich.joh> notebook started overheating when moving to 7, could that be a reason? dieterich.joh> On my first mail to freebsd-stable I also quoted a case from the LKML dieterich.joh> where someone with a X60s reported overheating and the problem was in dieterich.joh> the fan levels of the (linux) acpi_ibm module, if I recall it correct. Sorry but I don't know about acpi_ibm. 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 Mon Feb 18 04:44:45 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 97A4216A417; Mon, 18 Feb 2008 04:44:45 +0000 (UTC) (envelope-from alex.kovalenko@verizon.net) Received: from vms042pub.verizon.net (vms042pub.verizon.net [206.46.252.42]) by mx1.freebsd.org (Postfix) with ESMTP id 6CC5513C44B; Mon, 18 Feb 2008 04:44:45 +0000 (UTC) (envelope-from alex.kovalenko@verizon.net) Received: from [10.0.3.231] ([70.111.176.151]) by vms042.mailsrvcs.net (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPA id <0JWF00JHC3TQUMN0@vms042.mailsrvcs.net>; Sun, 17 Feb 2008 22:44:15 -0600 (CST) Date: Sun, 17 Feb 2008 23:43:53 -0500 From: "Alexandre \"Sunny\" Kovalenko" In-reply-to: <47B83939.300@gmail.com> To: Johannes Dieterich Message-id: <1203309833.16887.2.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> <1202475519.7014.7.camel@RabbitsDen> <1203126071.833.19.camel@RabbitsDen> <47B6B913.9020505@gmail.com> <47B6CC48.5070009@gmail.com> <47B6CD54.3020806@gmail.com> <47B71194.8090804@gmail.com> <47B71804.40002@gmail.com> <47B8114D.1000707@gmail.com> <47B83939.300@gmail.com> Cc: freebsd-acpi@freebsd.org, ume@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: Mon, 18 Feb 2008 04:44:45 -0000 On Sun, 2008-02-17 at 14:40 +0100, Johannes Dieterich wrote: > Hi, > some not so nice news: > > Johannes Dieterich wrote: > > Hi, > > > > Hajimu UMEMOTO wrote: > >> Hi, > >> > >>>>>>> On Sat, 16 Feb 2008 18:06:12 +0100 > >> No problem. Please make sure hw.acpi.thermal.tz1.passive_cooling is 1 > >> by typing `sysctl hw.acpi.thermal.tz1.passive_cooling' before trying. > >> If hw.acpi.thermal.tz1.passive_cooling is 1, passive cooling should be > >> working. > > I can confirm that it works, I can get buildworld through. > That still holds true. Unfortunately portupgrade gcc overheats it again. You might want to do sysctl hw.acpi.thermal.user_override=1 sysctl hw.acpi.thermal.tz1._PSV=85C and see if this gets you through the gcc compilation. > > > Regards, > > Johannes > > _______________________________________________ > freebsd-acpi@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-acpi > To unsubscribe, send any mail to "freebsd-acpi-unsubscribe@freebsd.org" -- Alexandre "Sunny" Kovalenko (Олександр Коваленко) From owner-freebsd-acpi@FreeBSD.ORG Mon Feb 18 11:07:04 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 2259116A420 for ; Mon, 18 Feb 2008 11:07:04 +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 1229013C458 for ; Mon, 18 Feb 2008 11:07:04 +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 m1IB73I7039317 for ; Mon, 18 Feb 2008 11:07:03 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m1IB73jF039313 for freebsd-acpi@FreeBSD.org; Mon, 18 Feb 2008 11:07:03 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 18 Feb 2008 11:07:03 GMT Message-Id: <200802181107.m1IB73jF039313@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, 18 Feb 2008 11:07:04 -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 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 19 problems total. Non-critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- f 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 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 o kern/120515 acpi [acpi] [patch] acpi_alloc_wakeup_handler: can't alloc o amd64/120568 acpi cannot install 7.0-rc1: ACPI problem with abit ip35 pr 21 problems total. From owner-freebsd-acpi@FreeBSD.ORG Mon Feb 18 11:18: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 37A5016A4C1 for ; Mon, 18 Feb 2008 11:18:38 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from falcon.cybervisiontech.com (falcon.cybervisiontech.com [217.20.163.9]) by mx1.freebsd.org (Postfix) with ESMTP id E45DC13C45B for ; Mon, 18 Feb 2008 11:18:36 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from localhost (localhost [127.0.0.1]) by falcon.cybervisiontech.com (Postfix) with ESMTP id 2385543D7FB for ; Mon, 18 Feb 2008 13:18:35 +0200 (EET) X-Virus-Scanned: Debian amavisd-new at falcon.cybervisiontech.com Received: from falcon.cybervisiontech.com ([127.0.0.1]) by localhost (falcon.cybervisiontech.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9EPRF1qGmc1F for ; Mon, 18 Feb 2008 13:18:35 +0200 (EET) Received: from [10.2.1.87] (gateway.cybervisiontech.com.ua [88.81.251.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by falcon.cybervisiontech.com (Postfix) with ESMTP id 63D0543D681 for ; Mon, 18 Feb 2008 13:18:34 +0200 (EET) Message-ID: <47B96989.6070008@icyb.net.ua> Date: Mon, 18 Feb 2008 13:18:33 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.9 (X11/20080123) MIME-Version: 1.0 To: freebsd-acpi@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: acpi_throttle: quirk based on pci info 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, 18 Feb 2008 11:18:38 -0000 While looking for something else I accidentally noticed that acpi_throttle has one quirk for some early revisions of PIIX4 chipset and the quirk is enabled based on PCI info. I have a newer revision of PIIX4 so the quirk is not applicable in my case. Nevertheless I noticed that acpi_throttle is initialized before PCI bus driver, so when it calls pci_find_device() it always returns NULL and quirk is not applied. At least this is what I see in dmesg on my machine. I am reporting this for the sake of code correctness and also out of curiosity about how such ordering issues are handled. -- Andriy Gapon From owner-freebsd-acpi@FreeBSD.ORG Mon Feb 18 23:19:41 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 4B8CC16A47B for ; Mon, 18 Feb 2008 23:19:41 +0000 (UTC) (envelope-from dieterich.joh@googlemail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.156]) by mx1.freebsd.org (Postfix) with ESMTP id CDBA113C4D9 for ; Mon, 18 Feb 2008 23:19:40 +0000 (UTC) (envelope-from dieterich.joh@googlemail.com) Received: by fg-out-1718.google.com with SMTP id 16so1624562fgg.35 for ; Mon, 18 Feb 2008 15:19:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding:from; bh=sSYKndeo/Bz6iyBzedCnwLaC/rrOWq2Me6X1lvXLigQ=; b=F9yfkcGWmgE4SFYFblJYXOEcDLEyc3vNOQrZoM8T4I9HiPrMiY662fL4FDkmU0/31XVS1FfZbL2PBWzoSbeJTNSbc5e8/ZG1t5SqBR856ZIAHdcWG9uXKJC9G9bBsfxSgVnkOgUIHRDjZ2Me5KivqXV95cdgOLmLuidPb8W4lbQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=message-id:date:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding:from; b=EjQIYgvs5tbeIQbSK9hWYWIfh69Xs43SPj8sjdAPhN5aELqCwYwNioKOrn1apC3jXnyKslPFgrLuunhrRmURvcpIrnleWNy5l/RW9KPAXKqtAywBLjTa/Sb8xUfzd44Dz+mXP8N6KGIDOPoLYd18Vv9O7RZZYJSmeyNzV/k0u18= Received: by 10.86.28.5 with SMTP id b5mr6464355fgb.76.1203376779052; Mon, 18 Feb 2008 15:19:39 -0800 (PST) Received: from ?192.168.1.100? ( [79.210.68.69]) by mx.google.com with ESMTPS id l19sm11306563fgb.0.2008.02.18.15.19.37 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 18 Feb 2008 15:19:37 -0800 (PST) Message-ID: <47BA1288.2070802@gmail.com> Date: Tue, 19 Feb 2008 00:19:36 +0100 User-Agent: Thunderbird 2.0.0.9 (X11/20080213) MIME-Version: 1.0 To: freebsd-acpi@freebsd.org References: <20080208045605.15C874500E@ptavv.es.net> <47ABF402.7030904@root.org> <1202475519.7014.7.camel@RabbitsDen> <1203126071.833.19.camel@RabbitsDen> <47B6B913.9020505@gmail.com> <47B6CC48.5070009@gmail.com> <47B6CD54.3020806@gmail.com> <47B71194.8090804@gmail.com> <47B71804.40002@gmail.com> <47B8114D.1000707@gmail.com> <47BA120A.1040005@gmail.com> In-Reply-To: <47BA120A.1040005@gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit From: 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: Mon, 18 Feb 2008 23:19:41 -0000 Hi, Hajimu UMEMOTO wrote: > Hi, > >>>>>> On Sun, 17 Feb 2008 11:49:49 +0100 >>>>>> Johannes Dieterich said: > dieterich.joh> # sysctl hw.acpi.verbose > dieterich.joh> hw.acpi.verbose: 1 > dieterich.joh> but no information is written to /var/log/messages. I've tailed it > dieterich.joh> during buildworld and the only informations written there are from my > dieterich.joh> atheros card. > > It's strange to me. I wish to see the value of _TC1, _TC2 and _TSP > for tz1. Could you apply the following diff and show me the output of > `sysctl hw.acpi.thermal.tz1'? > > http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/acpica/acpi_thermal.c.diff?r1=1.65;r2=1.66 # sysctl hw.acpi.thermal.tz1 hw.acpi.thermal.tz1.temperature: 66.0C hw.acpi.thermal.tz1.active: -1 hw.acpi.thermal.tz1.passive_cooling: 0 hw.acpi.thermal.tz1.thermal_flags: 0 hw.acpi.thermal.tz1._PSV: 92.5C 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 hw.acpi.thermal.tz1._TC1: 5 hw.acpi.thermal.tz1._TC2: 4 hw.acpi.thermal.tz1._TSP: 600 is the wanted output without Sunny's patch compiled in. Best regards, Johannes From owner-freebsd-acpi@FreeBSD.ORG Tue Feb 19 14:38:51 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 0EFC316A418 for ; Tue, 19 Feb 2008 14:38:51 +0000 (UTC) (envelope-from rpaulo@gmail.com) Received: from fk-out-0910.google.com (fk-out-0910.google.com [209.85.128.187]) by mx1.freebsd.org (Postfix) with ESMTP id 8A12013C45D for ; Tue, 19 Feb 2008 14:38:50 +0000 (UTC) (envelope-from rpaulo@gmail.com) Received: by fk-out-0910.google.com with SMTP id b27so2517909fka.11 for ; Tue, 19 Feb 2008 06:38:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:cc:message-id:from:to:in-reply-to:content-type:content-transfer-encoding:mime-version:subject:date:references:x-mailer:sender; bh=6tNYa+MPIY1WwkE2d0DZcuu2AqOQjEzmP7UK1Y62jAU=; b=dJxZrNfWmN1Ytoaw4q7KYcEDL31QAK7jSuBwmFxi9xSLtT3lRuwqzYFzEzUGgEOACW2rqiWGBb56IzsbTlZ9vraO7m0vi0BKuBkZBeCi6D3qI6Dp4qwn35rnzxWXKegIKGg+KM7qG+UtQQHq8LlKv6u1u6phW7buDAicJ0GFCmw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=cc:message-id:from:to:in-reply-to:content-type:content-transfer-encoding:mime-version:subject:date:references:x-mailer:sender; b=Own0R6SZWtEpH6FX2a49yR7vVOO7Dkuh8N+Y91pkZ6fjSBvUiXmv47tC2c7B4iNS3oFGSbVE5Av8J67evQzxbWGdZ77lMdzgvbt6X0lqRn9eXn7FVK7NTnBDzaqhjiObW/mqCjkiv617Uhg1GZHAWLEZNb05zMiWwdSObBXNn24= Received: by 10.82.127.14 with SMTP id z14mr12658844buc.26.1203431925956; Tue, 19 Feb 2008 06:38:45 -0800 (PST) Received: from ?172.17.7.212? ( [193.136.24.128]) by mx.google.com with ESMTPS id g11sm8405530gve.6.2008.02.19.06.38.44 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 19 Feb 2008 06:38:45 -0800 (PST) Message-Id: <98F7E48C-1CBF-494D-8411-D80E25247214@FreeBSD.org> From: Rui Paulo To: Andriy Gapon In-Reply-To: <47B96989.6070008@icyb.net.ua> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v919.2) Date: Mon, 18 Feb 2008 23:00:52 +0000 References: <47B96989.6070008@icyb.net.ua> X-Mailer: Apple Mail (2.919.2) Sender: Rui Paulo Cc: freebsd-acpi@freebsd.org Subject: Re: acpi_throttle: quirk based on pci info 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, 19 Feb 2008 14:38:51 -0000 On Feb 18, 2008, at 11:18 AM, Andriy Gapon wrote: > > While looking for something else I accidentally noticed that > acpi_throttle has one quirk for some early revisions of PIIX4 chipset > and the quirk is enabled based on PCI info. > I have a newer revision of PIIX4 so the quirk is not applicable in > my case. > > Nevertheless I noticed that acpi_throttle is initialized before PCI > bus > driver, so when it calls pci_find_device() it always returns NULL and > quirk is not applied. At least this is what I see in dmesg on my > machine. I run into a similar problem on my SoC MacBook project and I ended up using the SMI vendor strings because it was too early in boot in order to find the PCI devices. The problem here is very similar. Maybe we should try to use SMI vendor strings instead of pci_find_device()? Regards. -- Rui Paulo From owner-freebsd-acpi@FreeBSD.ORG Tue Feb 19 15:45:02 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 B2D8B16A41A; Tue, 19 Feb 2008 15:45:02 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from falcon.cybervisiontech.com (falcon.cybervisiontech.com [217.20.163.9]) by mx1.freebsd.org (Postfix) with ESMTP id 302C513C44B; Tue, 19 Feb 2008 15:45:01 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from localhost (localhost [127.0.0.1]) by falcon.cybervisiontech.com (Postfix) with ESMTP id E581B744003; Tue, 19 Feb 2008 17:44:59 +0200 (EET) X-Virus-Scanned: Debian amavisd-new at falcon.cybervisiontech.com Received: from falcon.cybervisiontech.com ([127.0.0.1]) by localhost (falcon.cybervisiontech.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EiaHsVgdXOZo; Tue, 19 Feb 2008 17:44:59 +0200 (EET) Received: from [10.2.1.87] (gateway.cybervisiontech.com.ua [88.81.251.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by falcon.cybervisiontech.com (Postfix) with ESMTP id 8D18043F371; Tue, 19 Feb 2008 17:44:59 +0200 (EET) Message-ID: <47BAF97A.80405@icyb.net.ua> Date: Tue, 19 Feb 2008 17:44:58 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.9 (X11/20080123) MIME-Version: 1.0 To: Rui Paulo References: <47B96989.6070008@icyb.net.ua> <98F7E48C-1CBF-494D-8411-D80E25247214@FreeBSD.org> In-Reply-To: <98F7E48C-1CBF-494D-8411-D80E25247214@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@freebsd.org Subject: Re: acpi_throttle: quirk based on pci info 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, 19 Feb 2008 15:45:02 -0000 on 19/02/2008 01:00 Rui Paulo said the following: > On Feb 18, 2008, at 11:18 AM, Andriy Gapon wrote: > >> While looking for something else I accidentally noticed that >> acpi_throttle has one quirk for some early revisions of PIIX4 chipset >> and the quirk is enabled based on PCI info. >> I have a newer revision of PIIX4 so the quirk is not applicable in >> my case. >> >> Nevertheless I noticed that acpi_throttle is initialized before PCI >> bus >> driver, so when it calls pci_find_device() it always returns NULL and >> quirk is not applied. At least this is what I see in dmesg on my >> machine. > > I run into a similar problem on my SoC MacBook project and I ended up > using the SMI vendor strings because it was too early in boot in order > to find the PCI devices. The problem here is very similar. > Maybe we should try to use SMI vendor strings instead of > pci_find_device()? I am not familiar with this approach and I am not sure if that works with that type of (quite old) hardware. When I worked on something else I remember somebody (maybe Nate) recommending me to model my code after ichss: sys/dev/cpufreq/ichss.c Maybe the same approach could be used here? I.e. no identify method for acpi bus. Additional device/driver for pci bus. pci probe method checks for duplicates and adds the acpi device as a child to acpi bus. pci probe method sets quirks based on pci info. pci probe method runs device_probe_and_attach on the acpi device. as a consequence acpi probe and attach (for successful probe) are executed. The only unclear issue is where to place the code that is currently in (acpi) identify method - should it go to pci identify method or should it go to acpi probe method. -- Andriy Gapon From owner-freebsd-acpi@FreeBSD.ORG Tue Feb 19 15:52:12 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 67F0C16A469 for ; Tue, 19 Feb 2008 15:52:12 +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 4512113C4D9 for ; Tue, 19 Feb 2008 15:52:12 +0000 (UTC) (envelope-from nate@root.org) Received: (qmail 49351 invoked from network); 19 Feb 2008 15:52:12 -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; 19 Feb 2008 15:52:12 -0000 Message-ID: <47BAFB27.1050509@root.org> Date: Tue, 19 Feb 2008 07:52:07 -0800 From: Nate Lawson User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Andriy Gapon References: <47B96989.6070008@icyb.net.ua> <98F7E48C-1CBF-494D-8411-D80E25247214@FreeBSD.org> <47BAF97A.80405@icyb.net.ua> In-Reply-To: <47BAF97A.80405@icyb.net.ua> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@freebsd.org Subject: Re: acpi_throttle: quirk based on pci info 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, 19 Feb 2008 15:52:12 -0000 Andriy Gapon wrote: > on 19/02/2008 01:00 Rui Paulo said the following: >> On Feb 18, 2008, at 11:18 AM, Andriy Gapon wrote: >> >>> While looking for something else I accidentally noticed that >>> acpi_throttle has one quirk for some early revisions of PIIX4 chipset >>> and the quirk is enabled based on PCI info. >>> I have a newer revision of PIIX4 so the quirk is not applicable in >>> my case. >>> >>> Nevertheless I noticed that acpi_throttle is initialized before PCI >>> bus >>> driver, so when it calls pci_find_device() it always returns NULL and >>> quirk is not applied. At least this is what I see in dmesg on my >>> machine. >> I run into a similar problem on my SoC MacBook project and I ended up >> using the SMI vendor strings because it was too early in boot in order >> to find the PCI devices. The problem here is very similar. >> Maybe we should try to use SMI vendor strings instead of >> pci_find_device()? > > I am not familiar with this approach and I am not sure if that works > with that type of (quite old) hardware. > > When I worked on something else I remember somebody (maybe Nate) > recommending me to model my code after ichss: > sys/dev/cpufreq/ichss.c > > Maybe the same approach could be used here? > > I.e. no identify method for acpi bus. > Additional device/driver for pci bus. > pci probe method checks for duplicates and adds the acpi device as a > child to acpi bus. > pci probe method sets quirks based on pci info. > pci probe method runs device_probe_and_attach on the acpi device. > as a consequence acpi probe and attach (for successful probe) are executed. > > The only unclear issue is where to place the code that is currently in > (acpi) identify method - should it go to pci identify method or should > it go to acpi probe method. Yeah, it's a problem either way. I remember something like: 1. Separate PCI attachment that adds ACPI device Guaranteed that PCI is available. Bad: won't work if loaded after boot (not probed) 2. Directly calling device_probe() Good: works after boot. Bad: always adds a device even if none present. You can see the first one in ichss.c. It's why cpufreq devices are not loadable. -- Nate From owner-freebsd-acpi@FreeBSD.ORG Tue Feb 19 18:32:32 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 A911216A41B for ; Tue, 19 Feb 2008 18:32:32 +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 4870B13C47E for ; Tue, 19 Feb 2008 18:32:32 +0000 (UTC) (envelope-from ume@mahoroba.org) Received: from kasuga.mahoroba.org (IDENT:2A9yQOoNepsgNbc2Fd6Sw7c56z+AK0pBVxMjsk7I0Nv2AzEdvLbo+iaQhU9/fK8R@kasuga.mahoroba.org [IPv6:2001:2f0:104:8010:20b:97ff:fe2e:b521]) (user=ume mech=CRAM-MD5 bits=0) by ameno.mahoroba.org (8.13.8/8.13.8) with ESMTP/inet6 id m1JIWGIj029367 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 20 Feb 2008 03:32:22 +0900 (JST) (envelope-from ume@mahoroba.org) Date: Wed, 20 Feb 2008 03:32:16 +0900 Message-ID: From: Hajimu UMEMOTO To: Johannes Dieterich In-Reply-To: <47BA1288.2070802@gmail.com> References: <20080208045605.15C874500E@ptavv.es.net> <47ABF402.7030904@root.org> <1202475519.7014.7.camel@RabbitsDen> <1203126071.833.19.camel@RabbitsDen> <47B6B913.9020505@gmail.com> <47B6CC48.5070009@gmail.com> <47B6CD54.3020806@gmail.com> <47B71194.8090804@gmail.com> <47B71804.40002@gmail.com> <47B8114D.1000707@gmail.com> <47BA120A.1040005@gmail.com> <47BA1288.2070802@gmail.com> 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-p1 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]); Wed, 20 Feb 2008 03:32:22 +0900 (JST) X-Virus-Scanned: by amavisd-new X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 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: freebsd-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: Tue, 19 Feb 2008 18:32:32 -0000 Hi, >>>>> On Tue, 19 Feb 2008 00:19:36 +0100 >>>>> Johannes Dieterich said: dieterich.joh> # sysctl hw.acpi.thermal.tz1 dieterich.joh> hw.acpi.thermal.tz1.temperature: 66.0C dieterich.joh> hw.acpi.thermal.tz1.active: -1 dieterich.joh> hw.acpi.thermal.tz1.passive_cooling: 0 dieterich.joh> hw.acpi.thermal.tz1.thermal_flags: 0 dieterich.joh> hw.acpi.thermal.tz1._PSV: 92.5C dieterich.joh> hw.acpi.thermal.tz1._HOT: -1 dieterich.joh> hw.acpi.thermal.tz1._CRT: 97.0C dieterich.joh> hw.acpi.thermal.tz1._ACx: -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 dieterich.joh> hw.acpi.thermal.tz1._TC1: 5 dieterich.joh> hw.acpi.thermal.tz1._TC2: 4 dieterich.joh> hw.acpi.thermal.tz1._TSP: 600 dieterich.joh> is the wanted output without Sunny's patch compiled in. Thank you. It seems good to me. I've tried following setting on my laptop, and it's working well: sysctl hw.acpi.verbose=1 sysctl hw.acpi.thermal.user_override=1 sysctl hw.acpi.thermal.tz0._TC1=5 sysctl hw.acpi.thermal.tz0._TC2=4 sysctl hw.acpi.thermal.tz0._TSP=600 The following was logged into /var/log/messages: Feb 19 11:08:26 kasuga kernel: acpi_tz0: temperature 85.8C: decreasing clock speed from 1200 MHz to 1000 MHz Feb 19 11:09:26 kasuga kernel: acpi_tz0: temperature 82.8C: resuming previous clock speed (1200 MHz) Feb 19 11:10:26 kasuga kernel: acpi_tz0: temperature 86.8C: decreasing clock speed from 1200 MHz to 900 MHz Feb 19 11:11:26 kasuga kernel: acpi_tz0: temperature 79.8C: resuming previous clock speed (1200 MHz) So, I think the value of _TC1, _TC2 and _TSP is valid. Still, I'm not sure why the above message is not logged on your laptop. But, it would be worth to try increasing _TC2 and/or decreasing _TSP. 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 Tue Feb 19 19:25: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 D339116A419; Tue, 19 Feb 2008 19:25:44 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from falcon.cybervisiontech.com (falcon.cybervisiontech.com [217.20.163.9]) by mx1.freebsd.org (Postfix) with ESMTP id 51F7A13C46B; Tue, 19 Feb 2008 19:25:44 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from localhost (localhost [127.0.0.1]) by falcon.cybervisiontech.com (Postfix) with ESMTP id 4433E744004; Tue, 19 Feb 2008 21:25:42 +0200 (EET) X-Virus-Scanned: Debian amavisd-new at falcon.cybervisiontech.com Received: from falcon.cybervisiontech.com ([127.0.0.1]) by localhost (falcon.cybervisiontech.com [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id jrYQkStjpe8X; Tue, 19 Feb 2008 21:25:42 +0200 (EET) Received: from [10.74.70.239] (unknown [193.138.145.53]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by falcon.cybervisiontech.com (Postfix) with ESMTP id 2390B744003; Tue, 19 Feb 2008 21:25:41 +0200 (EET) Message-ID: <47BB2D1F.8000008@icyb.net.ua> Date: Tue, 19 Feb 2008 21:25:19 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.9 (X11/20071208) MIME-Version: 1.0 To: Nate Lawson References: <47B96989.6070008@icyb.net.ua> <98F7E48C-1CBF-494D-8411-D80E25247214@FreeBSD.org> <47BAF97A.80405@icyb.net.ua> <47BAFB27.1050509@root.org> In-Reply-To: <47BAFB27.1050509@root.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@freebsd.org Subject: Re: acpi_throttle: quirk based on pci info 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, 19 Feb 2008 19:25:44 -0000 on 19/02/2008 17:52 Nate Lawson said the following: > Andriy Gapon wrote: >> on 19/02/2008 01:00 Rui Paulo said the following: >>> On Feb 18, 2008, at 11:18 AM, Andriy Gapon wrote: >>> >>>> While looking for something else I accidentally noticed that >>>> acpi_throttle has one quirk for some early revisions of PIIX4 chipset >>>> and the quirk is enabled based on PCI info. >>>> I have a newer revision of PIIX4 so the quirk is not applicable in >>>> my case. >>>> >>>> Nevertheless I noticed that acpi_throttle is initialized before PCI >>>> bus >>>> driver, so when it calls pci_find_device() it always returns NULL and >>>> quirk is not applied. At least this is what I see in dmesg on my >>>> machine. >>> I run into a similar problem on my SoC MacBook project and I ended up >>> using the SMI vendor strings because it was too early in boot in order >>> to find the PCI devices. The problem here is very similar. >>> Maybe we should try to use SMI vendor strings instead of >>> pci_find_device()? >> I am not familiar with this approach and I am not sure if that works >> with that type of (quite old) hardware. >> >> When I worked on something else I remember somebody (maybe Nate) >> recommending me to model my code after ichss: >> sys/dev/cpufreq/ichss.c >> >> Maybe the same approach could be used here? >> >> I.e. no identify method for acpi bus. >> Additional device/driver for pci bus. >> pci probe method checks for duplicates and adds the acpi device as a >> child to acpi bus. >> pci probe method sets quirks based on pci info. >> pci probe method runs device_probe_and_attach on the acpi device. >> as a consequence acpi probe and attach (for successful probe) are executed. >> >> The only unclear issue is where to place the code that is currently in >> (acpi) identify method - should it go to pci identify method or should >> it go to acpi probe method. > > Yeah, it's a problem either way. I remember something like: > > 1. Separate PCI attachment that adds ACPI device > Guaranteed that PCI is available. Bad: won't work if loaded after boot > (not probed) > > 2. Directly calling device_probe() > Good: works after boot. Bad: always adds a device even if none present. > > You can see the first one in ichss.c. It's why cpufreq devices are not > loadable. > As I understand, currently acpi_thermal is always a part of "acpi", not a separate module. And acpi should either be built into kernel or pre-loaded at boot time. So, it seems that we don't have to worry about the issue that you are mentioning in this case, at least for now. If I have time I'll try to write a patch some time later. I have a bit of a practical interest in it: I have a system based on PIIX4E (as you already know). Its ACPI FADT specifies duty offset of 1 and duty width of 1. So, according to FADT only 50% throttling is available. On the other hand, chipset specification updates for PIIX4E and PIIX4M say that PCNTRL (P_CNT) register has 3 bits (at offset 1 indeed) for controlling throttling in 12.5% steps. So it seems, that acpi_throttle controls only the lowest bit of the three; moreover, it seems that BIOS assigns some initial value to those bits. So when throttling is active those bits do not have 001 value corresponding to 87.5% duty cycle, but have some XX1 value and that value seems to be 111 (12.5% duty cycle), because the system becomes extremely slow. So, as experiment, I hardcoded duty width to 3 and everything works great - I have 8 throttling steps and system performance seems to really correspond to expected duty levels. So now I am thinking about writing a proper patch for this (positive) quirk. Reference: http://www.intel.com/design/chipsets/specupdt/29773817.pdf -- Andriy Gapon From owner-freebsd-acpi@FreeBSD.ORG Tue Feb 19 20:09:07 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 5733816A418; Tue, 19 Feb 2008 20:09:07 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from falcon.cybervisiontech.com (falcon.cybervisiontech.com [217.20.163.9]) by mx1.freebsd.org (Postfix) with ESMTP id C97FD13C448; Tue, 19 Feb 2008 20:09:06 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from localhost (localhost [127.0.0.1]) by falcon.cybervisiontech.com (Postfix) with ESMTP id 5674B744005; Tue, 19 Feb 2008 22:09:05 +0200 (EET) X-Virus-Scanned: Debian amavisd-new at falcon.cybervisiontech.com Received: from falcon.cybervisiontech.com ([127.0.0.1]) by localhost (falcon.cybervisiontech.com [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id NaDqh34s+7pb; Tue, 19 Feb 2008 22:09:05 +0200 (EET) Received: from [10.74.70.239] (unknown [193.138.145.53]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by falcon.cybervisiontech.com (Postfix) with ESMTP id 19F81744003; Tue, 19 Feb 2008 22:09:03 +0200 (EET) Message-ID: <47BB375C.5010208@icyb.net.ua> Date: Tue, 19 Feb 2008 22:09:00 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.9 (X11/20071208) MIME-Version: 1.0 To: freebsd-acpi@freebsd.org, freebsd-hackers@freebsd.org References: <479F0ED4.9030709@icyb.net.ua> <479F62D9.6080703@root.org> <47A33CCB.3090902@icyb.net.ua> <47B0C10F.6000109@icyb.net.ua> <47B4103A.6090902@icyb.net.ua> <47B4A103.7040801@icyb.net.ua> <47B4B31A.4020605@icyb.net.ua> <47B84E61.3060401@icyb.net.ua> In-Reply-To: <47B84E61.3060401@icyb.net.ua> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Subject: Re: cx_lowest and CPU usage 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, 19 Feb 2008 20:09:07 -0000 More news about the issue. Finally, I stopped being blind and tried to use KTR. Graphs produces by schedgraph confirmed my suspicion that system spends most if its time in idle thread (sleeping). But, but, RTC interrupt hits with high precision into the relatively very short intervals when swi4 runs. It seems that relatively long transition times of C2 on this hardware cause this "synchronization" but I am not sure exactly how. It is even harder to say how long does it take the hardware (chipset+cpu) to wake from that sleep on interrupt. One interesting thing that I immediately noticed is that having DUMMYNET in my kernel caused a huge difference. A typical KTR sequence looks like this: 1. we are in idle thread (apparently sleeping in C2) 2. clock (IRQ0) interrupt handler is executed (apparently after CPU is waken and idle thread enabled interrupts after post-C2 processing) 3. hardclock() checks if there is any timeout to be processed by softclock, and thanks to dummynet, we have its callout scheduled each tick 4. hardclock() schedules swi4 to run I am fuzzy about the following step, I see traces, but I don't know the code. So I write my guess and knowledgeable people can correct me. 5. near the end of interrupt handler routine we have critical_exit() call, it can call mi_switch() if current thread needs to be preempted by a different thread; in this case interrupt code is executed in context of the system idle thread and the idle thread is "owing preemption" to swi4 (see step4) 6. so apparently mi_switch happens in the idle thread and execution jumps to swi4 thread, which now exits from mi_switch() in soft interrupt loop routine 7. so far, starting from step 2, execution is with disabled interrupts; now swi4 unlocks spin mutex lock and that enables interrupts (see the previous message quoted below) 8. "immediately", RTC (IRQ8) interrupt handler is executed, apparently it has been pending for some time now 9. statclock is called and because we are on a swi thread this rtc tick is charged to "interrupts" So, here we are. But I am still not sure why the above happens so "deterministically" - RTC interrupt can happen anywhere between 2 clock interrupts. So we have 1000us range for RTC and 90us of C2 exit delay, that shouldn't be enough to always put IRQ0 and IRQ8 "together". Anyway, I excluded DUMMYNET from kernel config, but kept SCHED_ULE and HZ=1000. Now with C2 enabled I get 15-20% of (reported!) interrupt load on completely idle system. That is still a lot, but is much less than 99% I had before :-) Now, without DUMMYNET, I will get new KTR dumps for cx_lowest=C1 and cx_lowest=C2. I hope that this much cleaner experiment would give more insights. But even now we can be sure that our cpu statistics code is not always adequate. This is because IRQ8 is not processed like some super-interrupt that looks on a system from above. It is a regular participant of the system, it competes with IRQ0 and is affected by scheduler's decisions. Especially those made while in interrupt handler. on 17/02/2008 17:10 Andriy Gapon said the following: > on 14/02/2008 23:31 Andriy Gapon said the following: >> I ran a series of tests, repeating each twice to be sure that I didn't >> make any mistake. >> All tests were performed in single-user mode, so the system was as idle >> as possible, top reported idle as 99.N% - 100%. >> Then I set hw.acpi.cpu.cx_lowest=C2 and ran top again. >> Here's the results: >> GENERIC, SCHED_4BSD, default HZ=1000 ==> C2-interrupt 11-14% (!!) >> GENERIC, SCHED_4BSD, kern.hz="100" ==> C2-interrupt 99-100% >> customized kernel, SCHED_ULE, default HZ=1000 ==> C2-interrupt 99-100% >> customized kernel, SCHED_ULE, kern.hz="100" ==> C2-interrupt 99-100% > > I did some testing and here are some additional data. > Running with sched_ule and hz=1000 I measured that mean time spent in C2 > state (from starting to go into it, till completely returning from it) > is ~860us (end_time - start_time, no overhead adjustments). > Additionally, 98.1% of sleeps lasted 800-900us, 1.8% lasted 700-800us, > the rest is spread almost uniformly over the remaining intervals of > range 0-1000%. > > Here's a typical backtrace for statclock execution: > #9 0xc04cce26 in statclock (usermode=0) at > /system/src/sys/kern/kern_clock.c:447 > #10 0xc06b5f0c in rtcintr (frame=0xcfb30c78) at > /system/src/sys/i386/isa/clock.c:236 > #11 0xc06a5275 in intr_execute_handlers (isrc=0xc0736900, > frame=0xcfb30c78) at /system/src/sys/i386/i386/intr_machdep.c:362 > #12 0xc06b558c in atpic_handle_intr (vector=8, frame=0xcfb30c78) at > /system/src/sys/i386/isa/atpic.c:596 > #13 0xc06a0d71 in Xatpic_intr8 () at atpic_vector.s:70 > #14 0xc06a70c9 in spinlock_exit () at cpufunc.h:365 > #15 0xc04e6993 in ithread_loop (arg=0xc22f5980) at > /system/src/sys/kern/kern_intr.c:1137 > #16 0xc04e32c1 in fork_exit (callout=0xc04e6640 , > arg=0xc22f5980, frame=0xcfb30d38) at /system/src/sys/kern/kern_fork.c:754 > #17 0xc06a0bc0 in fork_trampoline () at > /system/src/sys/i386/i386/exception.s:205 > > I.e. swi4 kernel thread is "caught" by IRQ8 just when it exits from > thread_unlock() in the following snippet: > 1132 if (!ithd->it_need && !(ithd->it_flags & IT_DEAD)) { > 1133 TD_SET_IWAIT(td); > 1134 ie->ie_count = 0; > 1135 mi_switch(SW_VOL, NULL); > 1136 } > 1137 thread_unlock(td); > > This happens almost deterministically. > -- Andriy Gapon From owner-freebsd-acpi@FreeBSD.ORG Tue Feb 19 21:42:59 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 8C4C916A46C; Tue, 19 Feb 2008 21:42:59 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from falcon.cybervisiontech.com (falcon.cybervisiontech.com [217.20.163.9]) by mx1.freebsd.org (Postfix) with ESMTP id E1AEC13C4DB; Tue, 19 Feb 2008 21:42:58 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from localhost (localhost [127.0.0.1]) by falcon.cybervisiontech.com (Postfix) with ESMTP id 150BF744005; Tue, 19 Feb 2008 23:42:57 +0200 (EET) X-Virus-Scanned: Debian amavisd-new at falcon.cybervisiontech.com Received: from falcon.cybervisiontech.com ([127.0.0.1]) by localhost (falcon.cybervisiontech.com [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id uUZfMHERMuyN; Tue, 19 Feb 2008 23:42:56 +0200 (EET) Received: from [10.74.70.239] (unknown [193.138.145.53]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by falcon.cybervisiontech.com (Postfix) with ESMTP id C05B6744003; Tue, 19 Feb 2008 23:42:55 +0200 (EET) Message-ID: <47BB4D5C.9000406@icyb.net.ua> Date: Tue, 19 Feb 2008 23:42:52 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.9 (X11/20071208) MIME-Version: 1.0 To: freebsd-acpi@freebsd.org, freebsd-hackers@freebsd.org References: <479F0ED4.9030709@icyb.net.ua> <479F62D9.6080703@root.org> <47A33CCB.3090902@icyb.net.ua> <47B0C10F.6000109@icyb.net.ua> <47B4103A.6090902@icyb.net.ua> <47B4A103.7040801@icyb.net.ua> <47B4B31A.4020605@icyb.net.ua> <47B84E61.3060401@icyb.net.ua> <47BB375C.5010208@icyb.net.ua> In-Reply-To: <47BB375C.5010208@icyb.net.ua> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Subject: Re: cx_lowest and CPU usage 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, 19 Feb 2008 21:42:59 -0000 Here are two traces, one for completely idle system (single-user) with C2 disabled and the other with C2 enabled: http://www.icyb.net.ua/~avg/c1.ktr.gz http://www.icyb.net.ua/~avg/c2.ktr.gz Traces are produced with KTR_ALL and taken for approx. 3 seconds (sysctl; sleep 3; sysctl). And a small untidy quick-hack perl script that calculates time difference (in microseconds) between occurrence of a clock interrupt (rtc or clk) and the previous trace line: http://www.icyb.net.ua/~avg/ktr_pl.txt Some interesting results: C1, rtc: values all over the range ("uniformly"), from 1us to 989us; C1, clk: also various values from 2us to 995us, with most values ("naturally") being at the upper end > 900us. C2, clk: handful of values in the lower and middle range, vast majority is higher than 900us C2, rtc: all values are less than 4us (!!!) The last result most probably means that RTC IRQ was not the interrupt to wake CPU from sleeping state. The first possibility that comes to mind is that on this particular hardware RTC interrupt (IRQ8) is not able to wake the system from C2 state. Is this possible? Are there known instances of such breakage? Are there other possible explanations? on 19/02/2008 22:09 Andriy Gapon said the following: > More news about the issue. Finally, I stopped being blind and tried to > use KTR. > Graphs produces by schedgraph confirmed my suspicion that system spends > most if its time in idle thread (sleeping). > But, but, RTC interrupt hits with high precision into the relatively > very short intervals when swi4 runs. > It seems that relatively long transition times of C2 on this hardware > cause this "synchronization" but I am not sure exactly how. It is even > harder to say how long does it take the hardware (chipset+cpu) to wake > from that sleep on interrupt. > One interesting thing that I immediately noticed is that having DUMMYNET > in my kernel caused a huge difference. > A typical KTR sequence looks like this: > 1. we are in idle thread (apparently sleeping in C2) > 2. clock (IRQ0) interrupt handler is executed (apparently after CPU is > waken and idle thread enabled interrupts after post-C2 processing) > 3. hardclock() checks if there is any timeout to be processed by > softclock, and thanks to dummynet, we have its callout scheduled each tick > 4. hardclock() schedules swi4 to run > > I am fuzzy about the following step, I see traces, but I don't know the > code. So I write my guess and knowledgeable people can correct me. > 5. near the end of interrupt handler routine we have critical_exit() > call, it can call mi_switch() if current thread needs to be preempted by > a different thread; in this case interrupt code is executed in context > of the system idle thread and the idle thread is "owing preemption" to > swi4 (see step4) > 6. so apparently mi_switch happens in the idle thread and execution > jumps to swi4 thread, which now exits from mi_switch() in soft interrupt > loop routine > 7. so far, starting from step 2, execution is with disabled interrupts; > now swi4 unlocks spin mutex lock and that enables interrupts (see the > previous message quoted below) > 8. "immediately", RTC (IRQ8) interrupt handler is executed, apparently > it has been pending for some time now > 9. statclock is called and because we are on a swi thread this rtc tick > is charged to "interrupts" > > So, here we are. But I am still not sure why the above happens so > "deterministically" - RTC interrupt can happen anywhere between 2 clock > interrupts. So we have 1000us range for RTC and 90us of C2 exit delay, > that shouldn't be enough to always put IRQ0 and IRQ8 "together". > > Anyway, I excluded DUMMYNET from kernel config, but kept SCHED_ULE and > HZ=1000. Now with C2 enabled I get 15-20% of (reported!) interrupt load > on completely idle system. That is still a lot, but is much less than > 99% I had before :-) > > Now, without DUMMYNET, I will get new KTR dumps for cx_lowest=C1 and > cx_lowest=C2. I hope that this much cleaner experiment would give more > insights. > > But even now we can be sure that our cpu statistics code is not always > adequate. This is because IRQ8 is not processed like some > super-interrupt that looks on a system from above. It is a regular > participant of the system, it competes with IRQ0 and is affected by > scheduler's decisions. Especially those made while in interrupt handler. > > > > on 17/02/2008 17:10 Andriy Gapon said the following: >> on 14/02/2008 23:31 Andriy Gapon said the following: >>> I ran a series of tests, repeating each twice to be sure that I didn't >>> make any mistake. >>> All tests were performed in single-user mode, so the system was as idle >>> as possible, top reported idle as 99.N% - 100%. >>> Then I set hw.acpi.cpu.cx_lowest=C2 and ran top again. >>> Here's the results: >>> GENERIC, SCHED_4BSD, default HZ=1000 ==> C2-interrupt 11-14% (!!) >>> GENERIC, SCHED_4BSD, kern.hz="100" ==> C2-interrupt 99-100% >>> customized kernel, SCHED_ULE, default HZ=1000 ==> C2-interrupt 99-100% >>> customized kernel, SCHED_ULE, kern.hz="100" ==> C2-interrupt 99-100% >> I did some testing and here are some additional data. >> Running with sched_ule and hz=1000 I measured that mean time spent in C2 >> state (from starting to go into it, till completely returning from it) >> is ~860us (end_time - start_time, no overhead adjustments). >> Additionally, 98.1% of sleeps lasted 800-900us, 1.8% lasted 700-800us, >> the rest is spread almost uniformly over the remaining intervals of >> range 0-1000%. >> >> Here's a typical backtrace for statclock execution: >> #9 0xc04cce26 in statclock (usermode=0) at >> /system/src/sys/kern/kern_clock.c:447 >> #10 0xc06b5f0c in rtcintr (frame=0xcfb30c78) at >> /system/src/sys/i386/isa/clock.c:236 >> #11 0xc06a5275 in intr_execute_handlers (isrc=0xc0736900, >> frame=0xcfb30c78) at /system/src/sys/i386/i386/intr_machdep.c:362 >> #12 0xc06b558c in atpic_handle_intr (vector=8, frame=0xcfb30c78) at >> /system/src/sys/i386/isa/atpic.c:596 >> #13 0xc06a0d71 in Xatpic_intr8 () at atpic_vector.s:70 >> #14 0xc06a70c9 in spinlock_exit () at cpufunc.h:365 >> #15 0xc04e6993 in ithread_loop (arg=0xc22f5980) at >> /system/src/sys/kern/kern_intr.c:1137 >> #16 0xc04e32c1 in fork_exit (callout=0xc04e6640 , >> arg=0xc22f5980, frame=0xcfb30d38) at /system/src/sys/kern/kern_fork.c:754 >> #17 0xc06a0bc0 in fork_trampoline () at >> /system/src/sys/i386/i386/exception.s:205 >> >> I.e. swi4 kernel thread is "caught" by IRQ8 just when it exits from >> thread_unlock() in the following snippet: >> 1132 if (!ithd->it_need && !(ithd->it_flags & IT_DEAD)) { >> 1133 TD_SET_IWAIT(td); >> 1134 ie->ie_count = 0; >> 1135 mi_switch(SW_VOL, NULL); >> 1136 } >> 1137 thread_unlock(td); >> >> This happens almost deterministically. >> > > -- Andriy Gapon From owner-freebsd-acpi@FreeBSD.ORG Tue Feb 19 23:40:06 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 22C5616A417 for ; Tue, 19 Feb 2008 23:40:06 +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 154A113C4DB for ; Tue, 19 Feb 2008 23:40:06 +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 m1JNe58r042176 for ; Tue, 19 Feb 2008 23:40:05 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m1JNe5RD042172; Tue, 19 Feb 2008 23:40:05 GMT (envelope-from gnats) Date: Tue, 19 Feb 2008 23:40:05 GMT Message-Id: <200802192340.m1JNe5RD042172@freefall.freebsd.org> To: freebsd-acpi@FreeBSD.org From: Volker Cc: Subject: Re: i386/72179: [acpi] [patch] Inconsistent apm(8) output regarding the remaining battery time, when running acpi enabled laptop on AC power X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Volker List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2008 23:40:06 -0000 The following reply was made to PR i386/72179; it has been noted by GNATS. From: Volker To: bug-followup@FreeBSD.org, nike_d@cytexbg.com Cc: Subject: Re: i386/72179: [acpi] [patch] Inconsistent apm(8) output regarding the remaining battery time, when running acpi enabled laptop on AC power Date: Wed, 20 Feb 2008 00:31:21 +0100 There have been changes made to acpica (in 2006). Now apm gives on 7.0: %apm APM version: 1.2 APM Management: Disabled AC Line status: on-line Battery Status: high Remaining battery life: 98% Remaining battery time: unknown Number of batteries: 2 Battery 0: Battery Status: high Remaining battery life: 97% Remaining battery time: unknown Battery 1: Battery Status: high Remaining battery life: 100% Remaining battery time: unknown Resume timer: unknown Resume on ring indicator: disabled The patch and this PR is now obsolete for at least 6.3 and 7.0. From owner-freebsd-acpi@FreeBSD.ORG Wed Feb 20 15:21:52 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 7C73716A405; Wed, 20 Feb 2008 15:21:52 +0000 (UTC) (envelope-from gavin@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 4CFAF13C43E; Wed, 20 Feb 2008 15:21:52 +0000 (UTC) (envelope-from gavin@FreeBSD.org) Received: from freefall.freebsd.org (gavin@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m1KFLqkF030195; Wed, 20 Feb 2008 15:21:52 GMT (envelope-from gavin@freefall.freebsd.org) Received: (from gavin@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m1KFLq29030191; Wed, 20 Feb 2008 15:21:52 GMT (envelope-from gavin) Date: Wed, 20 Feb 2008 15:21:52 GMT Message-Id: <200802201521.m1KFLq29030191@freefall.freebsd.org> To: nike_d@cytexbg.com, gavin@FreeBSD.org, freebsd-acpi@FreeBSD.org, gavin@FreeBSD.org From: gavin@FreeBSD.org Cc: Subject: Re: i386/72179: [acpi] [patch] Inconsistent apm(8) output regarding the remaining battery time, when running acpi enabled laptop on AC power X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2008 15:21:52 -0000 Synopsis: [acpi] [patch] Inconsistent apm(8) output regarding the remaining battery time, when running acpi enabled laptop on AC power State-Changed-From-To: open->feedback State-Changed-By: gavin State-Changed-When: Wed Feb 20 15:19:48 UTC 2008 State-Changed-Why: To submitter: It looks like this has been fixed in at least FreeBSD 6.3 and 7.0. Can you please retest and confirm that this is the case? Responsible-Changed-From-To: freebsd-acpi->gavin Responsible-Changed-By: gavin Responsible-Changed-When: Wed Feb 20 15:19:48 UTC 2008 Responsible-Changed-Why: Track http://www.freebsd.org/cgi/query-pr.cgi?pr=72179 From owner-freebsd-acpi@FreeBSD.ORG Wed Feb 20 16:10:15 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 D824616A407 for ; Wed, 20 Feb 2008 16:10:15 +0000 (UTC) (envelope-from ndenev@gmail.com) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.233]) by mx1.freebsd.org (Postfix) with ESMTP id 8954F13C459 for ; Wed, 20 Feb 2008 16:10:15 +0000 (UTC) (envelope-from ndenev@gmail.com) Received: by wr-out-0506.google.com with SMTP id 68so2231682wri.3 for ; Wed, 20 Feb 2008 08:10:14 -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:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; bh=0xUYrBUXac4eV379yWnvr7+72968Zb3UMsxTEckVIZ0=; b=MfDMyn8S5tvKeWzKMjo+l5HRdC/8H4Y7/D0GX+MAlik1fI/OaGy8Wes9oitkZS34oUOAPlsQLKQBeoxLohGeu+lOuNMI19/s2xJwM0BB3o4PcZ7jpMxvcfcRfD4YgM0FMQ4DjSt5M5svsGAKhsRDiIWTKi80B78j2OCFftWDxqc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=SlM2D6/Gp+FBF/wTdilMU4jWFABhl4kEQIJbFxFLcleoHxifJSUFwTjM2nC8l+y73z0N8qLQ8Hp2Qo1UxdKLkbT2YqSeXxuC9gbqSmsdswdJK2zF1z/uvSrG7gAW/tGXAcwfh0Vfo1lZ9w4ufKREaA3IF09Oh3lTg1VU2auhQOY= Received: by 10.141.26.18 with SMTP id d18mr5781673rvj.264.1203522285514; Wed, 20 Feb 2008 07:44:45 -0800 (PST) Received: by 10.141.170.18 with HTTP; Wed, 20 Feb 2008 07:44:45 -0800 (PST) Message-ID: <2e77fc10802200744g8e940ccmd1e3a4837f2b83d7@mail.gmail.com> Date: Wed, 20 Feb 2008 15:44:45 +0000 From: "Niki Denev" Sender: ndenev@gmail.com To: gavin@freebsd.org In-Reply-To: <200802201521.m1KFLq29030191@freefall.freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200802201521.m1KFLq29030191@freefall.freebsd.org> X-Google-Sender-Auth: a0bdc72c00913522 Cc: freebsd-acpi@freebsd.org Subject: Re: i386/72179: [acpi] [patch] Inconsistent apm(8) output regarding the remaining battery time, when running acpi enabled laptop on AC power X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2008 16:10:15 -0000 On Feb 20, 2008 3:21 PM, wrote: > Synopsis: [acpi] [patch] Inconsistent apm(8) output regarding the remaining battery time, when running acpi enabled laptop on AC power > > State-Changed-From-To: open->feedback > State-Changed-By: gavin > State-Changed-When: Wed Feb 20 15:19:48 UTC 2008 > State-Changed-Why: > To submitter: It looks like this has been fixed in at least FreeBSD 6.3 > and 7.0. Can you please retest and confirm that this is the case? > > > Responsible-Changed-From-To: freebsd-acpi->gavin > Responsible-Changed-By: gavin > Responsible-Changed-When: Wed Feb 20 15:19:48 UTC 2008 > Responsible-Changed-Why: > Track > > http://www.freebsd.org/cgi/query-pr.cgi?pr=72179 > > This problem was fixed long time ago. The PR should be closed --Niki From owner-freebsd-acpi@FreeBSD.ORG Wed Feb 20 17:22:13 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 D0D5716A409 for ; Wed, 20 Feb 2008 17:22:13 +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 AC00213C448 for ; Wed, 20 Feb 2008 17:22:13 +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 <0JWJ001HXS8PZ890@vms048.mailsrvcs.net> for acpi@freebsd.org; Wed, 20 Feb 2008 11:22:03 -0600 (CST) Date: Wed, 20 Feb 2008 12:22:01 -0500 From: "Alexandre \"Sunny\" Kovalenko" To: acpi@freebsd.org Message-id: <1203528121.1019.25.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 Cc: Subject: Is halting of the CPU0 on SMP supposed to slow down time? 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, 20 Feb 2008 17:22:13 -0000 While trying to understand why setting hw.acpi.cpu.cx_lowest=C3 makes my laptop (ThinkPad X60 with Intel T2400 @ 1.8GHz) literally crawl, I have run across the following observation: if dev.cpu.0.cx_lowest is set to C3 and machdep.cpu_idle_hlt is set to 1 time slows down at about two orders of magnitude. The same result could be achieved by setting machdep.hlt_cpus to 1. Setting dev.cpu.1.cx_lowest to C3 or machdep.hlt_cpus to 2 does not cause any negative side effects. Setting machdep.cpu_idle_hlt to 0 and hw.acpi.cpu.cx_lowest to C3 gets machine warming all the way up to _PSV rather rapidly. This was observed with the HPET and ACPI-fast timecounters without discernible difference. The system is RELENG_7 as of Feb 15, cpufreq is loaded and powerd is running. I would like to have C3 working as it gives me much cooler machine in the idle state, but not at the cost of losing time accounting. Any suggestions will be greatly appreciated. -- Alexandre "Sunny" Kovalenko (Олександр Коваленко) From owner-freebsd-acpi@FreeBSD.ORG Wed Feb 20 18:34:01 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 3B99B16A402; Wed, 20 Feb 2008 18:34:01 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from falcon.cybervisiontech.com (falcon.cybervisiontech.com [217.20.163.9]) by mx1.freebsd.org (Postfix) with ESMTP id 846E413C447; Wed, 20 Feb 2008 18:34:00 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from localhost (localhost [127.0.0.1]) by falcon.cybervisiontech.com (Postfix) with ESMTP id 3033F43CA06; Wed, 20 Feb 2008 20:33:59 +0200 (EET) X-Virus-Scanned: Debian amavisd-new at falcon.cybervisiontech.com Received: from falcon.cybervisiontech.com ([127.0.0.1]) by localhost (falcon.cybervisiontech.com [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id mkO68n+gBezk; Wed, 20 Feb 2008 20:33:59 +0200 (EET) Received: from [10.74.70.239] (unknown [193.138.145.53]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by falcon.cybervisiontech.com (Postfix) with ESMTP id DB83D43C9C9; Wed, 20 Feb 2008 20:33:57 +0200 (EET) Message-ID: <47BC7287.6000301@icyb.net.ua> Date: Wed, 20 Feb 2008 20:33:43 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.9 (X11/20071208) MIME-Version: 1.0 To: freebsd-acpi@freebsd.org, freebsd-hackers@freebsd.org References: <479F0ED4.9030709@icyb.net.ua> <479F62D9.6080703@root.org> <47A33CCB.3090902@icyb.net.ua> <47B0C10F.6000109@icyb.net.ua> <47B4103A.6090902@icyb.net.ua> <47B4A103.7040801@icyb.net.ua> <47B4B31A.4020605@icyb.net.ua> <47B84E61.3060401@icyb.net.ua> <47BB375C.5010208@icyb.net.ua> <47BB4D5C.9000406@icyb.net.ua> In-Reply-To: <47BB4D5C.9000406@icyb.net.ua> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Cc: Subject: Re: cx_lowest and CPU usage 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, 20 Feb 2008 18:34:01 -0000 on 19/02/2008 23:42 Andriy Gapon said the following: > The last result most probably means that RTC IRQ was not the interrupt > to wake CPU from sleeping state. > The first possibility that comes to mind is that on this particular > hardware RTC interrupt (IRQ8) is not able to wake the system from C2 state. So it seems that this was true. Here's a shortcut to the relevant info: PIIX4E (FW82371EB) specification DEVACTB DEVICE ACTIVITY B (FUNCTION 3) pci register description BRLD_EN_IRQ8, bit 5 $ pciconf -r pci0:0:7:3 0x58 03040c07 > Is this possible? > Are there known instances of such breakage? > Are there other possible explanations? > > on 19/02/2008 22:09 Andriy Gapon said the following: >> More news about the issue. Finally, I stopped being blind and tried to >> use KTR. >> Graphs produces by schedgraph confirmed my suspicion that system spends >> most if its time in idle thread (sleeping). >> But, but, RTC interrupt hits with high precision into the relatively >> very short intervals when swi4 runs. >> It seems that relatively long transition times of C2 on this hardware >> cause this "synchronization" but I am not sure exactly how. It is even >> harder to say how long does it take the hardware (chipset+cpu) to wake >> from that sleep on interrupt. >> One interesting thing that I immediately noticed is that having DUMMYNET >> in my kernel caused a huge difference. >> A typical KTR sequence looks like this: >> 1. we are in idle thread (apparently sleeping in C2) >> 2. clock (IRQ0) interrupt handler is executed (apparently after CPU is >> waken and idle thread enabled interrupts after post-C2 processing) >> 3. hardclock() checks if there is any timeout to be processed by >> softclock, and thanks to dummynet, we have its callout scheduled each tick >> 4. hardclock() schedules swi4 to run >> >> I am fuzzy about the following step, I see traces, but I don't know the >> code. So I write my guess and knowledgeable people can correct me. >> 5. near the end of interrupt handler routine we have critical_exit() >> call, it can call mi_switch() if current thread needs to be preempted by >> a different thread; in this case interrupt code is executed in context >> of the system idle thread and the idle thread is "owing preemption" to >> swi4 (see step4) >> 6. so apparently mi_switch happens in the idle thread and execution >> jumps to swi4 thread, which now exits from mi_switch() in soft interrupt >> loop routine >> 7. so far, starting from step 2, execution is with disabled interrupts; >> now swi4 unlocks spin mutex lock and that enables interrupts (see the >> previous message quoted below) >> 8. "immediately", RTC (IRQ8) interrupt handler is executed, apparently >> it has been pending for some time now >> 9. statclock is called and because we are on a swi thread this rtc tick >> is charged to "interrupts" >> >> So, here we are. But I am still not sure why the above happens so >> "deterministically" - RTC interrupt can happen anywhere between 2 clock >> interrupts. So we have 1000us range for RTC and 90us of C2 exit delay, >> that shouldn't be enough to always put IRQ0 and IRQ8 "together". >> >> Anyway, I excluded DUMMYNET from kernel config, but kept SCHED_ULE and >> HZ=1000. Now with C2 enabled I get 15-20% of (reported!) interrupt load >> on completely idle system. That is still a lot, but is much less than >> 99% I had before :-) >> >> Now, without DUMMYNET, I will get new KTR dumps for cx_lowest=C1 and >> cx_lowest=C2. I hope that this much cleaner experiment would give more >> insights. >> >> But even now we can be sure that our cpu statistics code is not always >> adequate. This is because IRQ8 is not processed like some >> super-interrupt that looks on a system from above. It is a regular >> participant of the system, it competes with IRQ0 and is affected by >> scheduler's decisions. Especially those made while in interrupt handler. >> >> >> >> on 17/02/2008 17:10 Andriy Gapon said the following: >>> on 14/02/2008 23:31 Andriy Gapon said the following: >>>> I ran a series of tests, repeating each twice to be sure that I didn't >>>> make any mistake. >>>> All tests were performed in single-user mode, so the system was as idle >>>> as possible, top reported idle as 99.N% - 100%. >>>> Then I set hw.acpi.cpu.cx_lowest=C2 and ran top again. >>>> Here's the results: >>>> GENERIC, SCHED_4BSD, default HZ=1000 ==> C2-interrupt 11-14% (!!) >>>> GENERIC, SCHED_4BSD, kern.hz="100" ==> C2-interrupt 99-100% >>>> customized kernel, SCHED_ULE, default HZ=1000 ==> C2-interrupt 99-100% >>>> customized kernel, SCHED_ULE, kern.hz="100" ==> C2-interrupt 99-100% >>> I did some testing and here are some additional data. >>> Running with sched_ule and hz=1000 I measured that mean time spent in C2 >>> state (from starting to go into it, till completely returning from it) >>> is ~860us (end_time - start_time, no overhead adjustments). >>> Additionally, 98.1% of sleeps lasted 800-900us, 1.8% lasted 700-800us, >>> the rest is spread almost uniformly over the remaining intervals of >>> range 0-1000%. >>> >>> Here's a typical backtrace for statclock execution: >>> #9 0xc04cce26 in statclock (usermode=0) at >>> /system/src/sys/kern/kern_clock.c:447 >>> #10 0xc06b5f0c in rtcintr (frame=0xcfb30c78) at >>> /system/src/sys/i386/isa/clock.c:236 >>> #11 0xc06a5275 in intr_execute_handlers (isrc=0xc0736900, >>> frame=0xcfb30c78) at /system/src/sys/i386/i386/intr_machdep.c:362 >>> #12 0xc06b558c in atpic_handle_intr (vector=8, frame=0xcfb30c78) at >>> /system/src/sys/i386/isa/atpic.c:596 >>> #13 0xc06a0d71 in Xatpic_intr8 () at atpic_vector.s:70 >>> #14 0xc06a70c9 in spinlock_exit () at cpufunc.h:365 >>> #15 0xc04e6993 in ithread_loop (arg=0xc22f5980) at >>> /system/src/sys/kern/kern_intr.c:1137 >>> #16 0xc04e32c1 in fork_exit (callout=0xc04e6640 , >>> arg=0xc22f5980, frame=0xcfb30d38) at /system/src/sys/kern/kern_fork.c:754 >>> #17 0xc06a0bc0 in fork_trampoline () at >>> /system/src/sys/i386/i386/exception.s:205 >>> >>> I.e. swi4 kernel thread is "caught" by IRQ8 just when it exits from >>> thread_unlock() in the following snippet: >>> 1132 if (!ithd->it_need && !(ithd->it_flags & IT_DEAD)) { >>> 1133 TD_SET_IWAIT(td); >>> 1134 ie->ie_count = 0; >>> 1135 mi_switch(SW_VOL, NULL); >>> 1136 } >>> 1137 thread_unlock(td); >>> >>> This happens almost deterministically. >>> >> > > -- Andriy Gapon From owner-freebsd-acpi@FreeBSD.ORG Wed Feb 20 19:46:36 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 1704816A401 for ; Wed, 20 Feb 2008 19:46:36 +0000 (UTC) (envelope-from dieterich.joh@googlemail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.153]) by mx1.freebsd.org (Postfix) with ESMTP id 87F0D13C455 for ; Wed, 20 Feb 2008 19:46:35 +0000 (UTC) (envelope-from dieterich.joh@googlemail.com) Received: by fg-out-1718.google.com with SMTP id 16so2205576fgg.35 for ; Wed, 20 Feb 2008 11:46:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding:from; bh=QsRIhyloPs9qLBDv3LLnZQeSM8aZPV9xRtiEdOJU108=; b=XtLTtW+Z9ttt1bsSuwFrBRNhui1FYziMv50TGO5DjJHuzke4DwKA6oObyJGg1L7JTCZr1HCJUJ5PkUWdLgHVTKIfJxtPn3Ejr4eqw0OmvrOLEMJdzMfdQgBYbDGSBPTl4viUo9k2I88JzteNXydGAbGdinwBTJ15RPzEKiEh894= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=message-id:date:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding:from; b=xZ1qcw/DD/0D44ee6Lfd4byUaAngvnNIcDKqGQjwLYpw5bSCJvE+jQJOP6s3PRLnkv0SKz+QdL0v/Slc6t8ix3Y0blfflhP8bvzmBf3lFuFjdvUZPcXsgcmA0KLR2mBZ8E99Nh+aLDuRUz9QPKZPNPPbhgiRlnAgseRzyL3wuus= Received: by 10.86.68.20 with SMTP id q20mr8582414fga.59.1203536794582; Wed, 20 Feb 2008 11:46:34 -0800 (PST) Received: from ?192.168.1.100? ( [79.210.117.34]) by mx.google.com with ESMTPS id d4sm11404776fga.2.2008.02.20.11.46.32 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 20 Feb 2008 11:46:33 -0800 (PST) Message-ID: <47BC8397.4040207@gmail.com> Date: Wed, 20 Feb 2008 20:46:31 +0100 User-Agent: Thunderbird 2.0.0.9 (X11/20080213) MIME-Version: 1.0 To: Hajimu UMEMOTO , freebsd-acpi@freebsd.org References: <20080208045605.15C874500E@ptavv.es.net> <47ABF402.7030904@root.org> <1202475519.7014.7.camel@RabbitsDen> <1203126071.833.19.camel@RabbitsDen> <47B6B913.9020505@gmail.com> <47B6CC48.5070009@gmail.com> <47B6CD54.3020806@gmail.com> <47B71194.8090804@gmail.com> <47B71804.40002@gmail.com> <47B8114D.1000707@gmail.com> <47BA120A.1040005@gmail.com> <47BA1288.2070802@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit From: Johannes Dieterich Cc: 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: Wed, 20 Feb 2008 19:46:36 -0000 Hi, Hajimu UMEMOTO wrote: > Hi, > >>>>>> On Tue, 19 Feb 2008 00:19:36 +0100 >>>>>> Johannes Dieterich said: > > dieterich.joh> # sysctl hw.acpi.thermal.tz1 > dieterich.joh> hw.acpi.thermal.tz1.temperature: 66.0C > dieterich.joh> hw.acpi.thermal.tz1.active: -1 > dieterich.joh> hw.acpi.thermal.tz1.passive_cooling: 0 > dieterich.joh> hw.acpi.thermal.tz1.thermal_flags: 0 > dieterich.joh> hw.acpi.thermal.tz1._PSV: 92.5C > dieterich.joh> hw.acpi.thermal.tz1._HOT: -1 > dieterich.joh> hw.acpi.thermal.tz1._CRT: 97.0C > dieterich.joh> hw.acpi.thermal.tz1._ACx: -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 > dieterich.joh> hw.acpi.thermal.tz1._TC1: 5 > dieterich.joh> hw.acpi.thermal.tz1._TC2: 4 > dieterich.joh> hw.acpi.thermal.tz1._TSP: 600 > > dieterich.joh> is the wanted output without Sunny's patch compiled in. > > Thank you. It seems good to me. I've tried following setting on my > laptop, and it's working well: > > sysctl hw.acpi.verbose=1 > sysctl hw.acpi.thermal.user_override=1 > sysctl hw.acpi.thermal.tz0._TC1=5 > sysctl hw.acpi.thermal.tz0._TC2=4 > sysctl hw.acpi.thermal.tz0._TSP=600 > and now I start to wonder: that is what happens: # sysctl hw.acpi.verbose=1 hw.acpi.verbose: 0 -> 1 # sysctl hw.acpi.thermal.user_override=1 hw.acpi.thermal.user_override: 0 -> 1 # sysctl hw.acpi.thermal.tz0._TC1=5 hw.acpi.thermal.tz0._TC1: -1 -> 5 # sysctl hw.acpi.thermal.tz0._TC2=4 hw.acpi.thermal.tz0._TC2: -1 -> 4 # sysctl hw.acpi.thermal.tz0._TSP=600 hw.acpi.thermal.tz0._TSP: -1 -> 600 Shouldn't that be somewhat different? And I didn't change anything in between but rebooting the machine. > The following was logged into /var/log/messages: > > Feb 19 11:08:26 kasuga kernel: acpi_tz0: temperature 85.8C: decreasing clock speed from 1200 MHz to 1000 MHz > Feb 19 11:09:26 kasuga kernel: acpi_tz0: temperature 82.8C: resuming previous clock speed (1200 MHz) > Feb 19 11:10:26 kasuga kernel: acpi_tz0: temperature 86.8C: decreasing clock speed from 1200 MHz to 900 MHz > Feb 19 11:11:26 kasuga kernel: acpi_tz0: temperature 79.8C: resuming previous clock speed (1200 MHz) > still nothing. Completely nothing. > So, I think the value of _TC1, _TC2 and _TSP is valid. > > Still, I'm not sure why the above message is not logged on your > laptop. But, it would be worth to try increasing _TC2 and/or > decreasing _TSP. That might be my next test then. Just wanted to let you know about the IMHO strange output above. Regards, Johannes From owner-freebsd-acpi@FreeBSD.ORG Wed Feb 20 21:10: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 E5DE916A404 for ; Wed, 20 Feb 2008 21:10:46 +0000 (UTC) (envelope-from dieterich.joh@googlemail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.152]) by mx1.freebsd.org (Postfix) with ESMTP id 6B74813C447 for ; Wed, 20 Feb 2008 21:10:46 +0000 (UTC) (envelope-from dieterich.joh@googlemail.com) Received: by fg-out-1718.google.com with SMTP id 16so2225478fgg.35 for ; Wed, 20 Feb 2008 13:10:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding:from; bh=VgAK+9pzr4ArSaZ2G5cpv0xCqbJdUvdWlZQGvr61xzE=; b=QLkspe1AMuS4HxEV62J24Ygj9+3AhxU2HusdFKLc2TEmeOsn0c89iHpS4ndTc6oyz/6bbBwLprqhiF8YrC//qC7XIvqTEU0YJ5jVP3mddmdTHt0JhQXHiK2Yzw2tDGAbQl4Ozg7SGIMGg6UNo+nnQ6dv/GCjN+UD6G2/OqURHhw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=message-id:date:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding:from; b=A1FjUloJCLfma9CcYYvs3QorXalidWOurdYPnxAaOH+d9w1zNeHVheJ3+rQL7WXNsRaBu8piyAPMTyUQcSD6hLE1R4fd14ezOJa2IjwD3KdAvkLY1VHlOVzJ+wAgYgSZPKg3mbGKfN3q/z+eAYyoF4w4es1YmFnBidLFPDRGPfo= Received: by 10.86.97.7 with SMTP id u7mr8656272fgb.65.1203541844743; Wed, 20 Feb 2008 13:10:44 -0800 (PST) Received: from ?192.168.1.100? ( [79.210.117.34]) by mx.google.com with ESMTPS id 4sm11508285fgg.4.2008.02.20.13.10.42 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 20 Feb 2008 13:10:43 -0800 (PST) Message-ID: <47BC9751.7050201@gmail.com> Date: Wed, 20 Feb 2008 22:10:41 +0100 User-Agent: Thunderbird 2.0.0.9 (X11/20080213) MIME-Version: 1.0 To: "Alexandre \"Sunny\" Kovalenko" , freebsd-acpi@freebsd.org References: <20080208045605.15C874500E@ptavv.es.net> <47ABF402.7030904@root.org> <1202475519.7014.7.camel@RabbitsDen> <1203126071.833.19.camel@RabbitsDen> <47B6B913.9020505@gmail.com> <47B6CC48.5070009@gmail.com> <47B6CD54.3020806@gmail.com> <47B71194.8090804@gmail.com> <47B71804.40002@gmail.com> <47B8114D.1000707@gmail.com> <47B83939.300@gmail.com> <1203309833.16887.2.camel@RabbitsDen> In-Reply-To: <1203309833.16887.2.camel@RabbitsDen> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit From: Johannes Dieterich Cc: 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: Wed, 20 Feb 2008 21:10:47 -0000 Alexandre "Sunny" Kovalenko wrote: > On Sun, 2008-02-17 at 14:40 +0100, Johannes Dieterich wrote: >> Hi, >> some not so nice news: >> >> That still holds true. Unfortunately portupgrade gcc overheats it again. > You might want to do > > sysctl hw.acpi.thermal.user_override=1 > sysctl hw.acpi.thermal.tz1._PSV=85C > > and see if this gets you through the gcc compilation. for a long long time it looked very good. But then it again overheated.I might want to stress again that it happened out of a sudden. sysctl dev.cpu reports 83-87 degrees for a long time and then it SUDDENLY shuts down saying it is over 127 degrees. The workload between those two data points has not changed. Regards, Joh From owner-freebsd-acpi@FreeBSD.ORG Wed Feb 20 21:32:03 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 7E90516A404 for ; Wed, 20 Feb 2008 21:32:03 +0000 (UTC) (envelope-from SRS0=db828d80fcf05de0320d451243f04ba29ac086bb=617=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 CD37D13C447 for ; Wed, 20 Feb 2008 21:32:02 +0000 (UTC) (envelope-from SRS0=db828d80fcf05de0320d451243f04ba29ac086bb=617=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 AXA96600; Wed, 20 Feb 2008 13:32:00 -0800 Received: from ptavv.es.net (ptavv.es.net [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id BD12E4500F; Wed, 20 Feb 2008 13:32:00 -0800 (PST) To: Johannes Dieterich In-Reply-To: Your message of "Wed, 20 Feb 2008 22:10:41 +0100." <47BC9751.7050201@gmail.com> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==_Exmh_1203543120_81195P"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Wed, 20 Feb 2008 13:32:00 -0800 From: "Kevin Oberman" Message-Id: <20080220213200.BD12E4500F@ptavv.es.net> X-Sender-IP: 198.128.4.29 X-Sender-Domain: es.net X-Recipent: ; ; ; X-Sender: X-To_Name: Johannes Dieterich X-To_Domain: googlemail.com X-To: Johannes Dieterich X-To_Email: dieterich.joh@googlemail.com X-To_Alias: dieterich.joh Cc: freebsd-acpi@freebsd.org, "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: Wed, 20 Feb 2008 21:32:03 -0000 --==_Exmh_1203543120_81195P Content-Type: text/plain; charset=us-ascii Content-Disposition: inline > Date: Wed, 20 Feb 2008 22:10:41 +0100 > From: Johannes Dieterich > Sender: owner-freebsd-acpi@freebsd.org > > Alexandre "Sunny" Kovalenko wrote: > > On Sun, 2008-02-17 at 14:40 +0100, Johannes Dieterich wrote: > >> Hi, > >> some not so nice news: > >> > >> That still holds true. Unfortunately portupgrade gcc overheats it again. > > You might want to do > > > > sysctl hw.acpi.thermal.user_override=1 > > sysctl hw.acpi.thermal.tz1._PSV=85C > > > > and see if this gets you through the gcc compilation. > for a long long time it looked very good. But then it again overheated.I > might want to stress again that it happened out of a sudden. sysctl > dev.cpu reports 83-87 degrees for a long time and then it SUDDENLY shuts > down saying it is over 127 degrees. The workload between those two data > points has not changed. This is sounding like a hardware problem. On almost all modern systems, the CPU temperature is read from a single junction on the silicon of the CPU. If it makes sudden, inexplicable jumps, this implies that either the junction on the chip or the support hardware on the mobo (this is analog stuff) is misbehaving. It is possible that something is causing BIOS to handle the values incorrectly, but that would seem very unlikely to me. -- 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_1203543120_81195P Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (FreeBSD) Comment: Exmh version 2.5 06/03/2002 iD8DBQFHvJxQkn3rs5h7N1ERAj4GAJ0TtRVfOjh6Gn+Qg4S8SsNkpgancQCfTqeB J9+uKHFkD6n0lAPgYtED808= =YV6i -----END PGP SIGNATURE----- --==_Exmh_1203543120_81195P-- From owner-freebsd-acpi@FreeBSD.ORG Wed Feb 20 21:51:43 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 9F6A816A407 for ; Wed, 20 Feb 2008 21:51:43 +0000 (UTC) (envelope-from dieterich.joh@googlemail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.158]) by mx1.freebsd.org (Postfix) with ESMTP id 2C35F13C455 for ; Wed, 20 Feb 2008 21:51:42 +0000 (UTC) (envelope-from dieterich.joh@googlemail.com) Received: by fg-out-1718.google.com with SMTP id 16so2238252fgg.35 for ; Wed, 20 Feb 2008 13:51:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding:from; bh=1GG3p0QT/+dZjpMzGUFNQgGoHFeDoD+mENaRyStsDnE=; b=xw6HkqSx6vefCBfQl1utJjpRX3W8JcB2SXOhSP8tjBJ9LQi5zNRn8SOGb1gJPwYE+RnotxR1VMiDJYh8EigwxJ+jg1jg5na6dcz9BVMoa5AHqugRY77p/+LKTMFYA7IKfLjkFLluSTsSCKxa8AeR6UBIHfgK3VRLPAcVLJtimCE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=message-id:date:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding:from; b=FgeLi+55SMYwsiHGpiM14mkwDMJ3qtXyOtb1h4qD8g0DWItv3r/hqga2AplNEhqN6wVW/H0FVawP+iXxkra6+zUgZq0IUOyRkCARVjwgDLKsujqvc+kom79o3MtqS0oky0i8ST/XIpuPK50ZTTf5L+cADNjF5P8UlZ6BsOlrMBA= Received: by 10.86.97.7 with SMTP id u7mr8713693fgb.39.1203544301976; Wed, 20 Feb 2008 13:51:41 -0800 (PST) Received: from ?192.168.1.100? ( [79.210.117.34]) by mx.google.com with ESMTPS id e20sm14457800fga.1.2008.02.20.13.51.39 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 20 Feb 2008 13:51:40 -0800 (PST) Message-ID: <47BCA0EA.4080508@gmail.com> Date: Wed, 20 Feb 2008 22:51:38 +0100 User-Agent: Thunderbird 2.0.0.9 (X11/20080213) MIME-Version: 1.0 To: Kevin Oberman , freebsd-acpi@freebsd.org References: <20080220213200.BD12E4500F@ptavv.es.net> In-Reply-To: <20080220213200.BD12E4500F@ptavv.es.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit From: Johannes Dieterich Cc: 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: Wed, 20 Feb 2008 21:51:43 -0000 First, thanks for your reply! Kevin Oberman wrote: >> Date: Wed, 20 Feb 2008 22:10:41 +0100 >> From: Johannes Dieterich >> Sender: owner-freebsd-acpi@freebsd.org >> >> Alexandre "Sunny" Kovalenko wrote: >>> On Sun, 2008-02-17 at 14:40 +0100, Johannes Dieterich wrote: >>>> Hi, >>>> some not so nice news: >>>> >>>> That still holds true. Unfortunately portupgrade gcc overheats it again. >>> You might want to do >>> >>> sysctl hw.acpi.thermal.user_override=1 >>> sysctl hw.acpi.thermal.tz1._PSV=85C >>> >>> and see if this gets you through the gcc compilation. >> for a long long time it looked very good. But then it again overheated.I >> might want to stress again that it happened out of a sudden. sysctl >> dev.cpu reports 83-87 degrees for a long time and then it SUDDENLY shuts >> down saying it is over 127 degrees. The workload between those two data >> points has not changed. > > This is sounding like a hardware problem. > > On almost all modern systems, the CPU temperature is read from a single > junction on the silicon of the CPU. If it makes sudden, inexplicable > jumps, this implies that either the junction on the chip or the support > hardware on the mobo (this is analog stuff) is misbehaving. > > It is possible that something is causing BIOS to handle the values > incorrectly, but that would seem very unlikely to me. In general, I am willing to believe these things. There is a but though. The problem appeared when upgrading from 6.2 to 7.0. OK, hardware breaks and coincidences happen. But I tested later with an openSUSE and a Knoppix Live CD (OK, JUST a LiveCD) and a stress test and it never went over 79 degrees. But it reproducibly happens with FreeBSD 7.0 and also there just under load (which puts the temperature anyway to 85 degrees). I do lack an install of a Linux to test these issues there because the notebook is my productive system at the moment. So do you think this issue would not show with a Linux LiveCD but an install? Is it worth in your opinion putting the hard drive out and finding another one to install a quick SuSE/RedHat/whatever for testing? Thanks, Johannes From owner-freebsd-acpi@FreeBSD.ORG Wed Feb 20 22:23:02 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 8D80716A400 for ; Wed, 20 Feb 2008 22:23:02 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.netplex.net (mail.netplex.net [204.213.176.10]) by mx1.freebsd.org (Postfix) with ESMTP id E899113C4D3 for ; Wed, 20 Feb 2008 22:23:01 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.netplex.net (8.14.2/8.14.2/NETPLEX) with ESMTP id m1KM6flB003953; Wed, 20 Feb 2008 17:06:41 -0500 (EST) X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-4.0 (mail.netplex.net [204.213.176.10]); Wed, 20 Feb 2008 17:06:41 -0500 (EST) Date: Wed, 20 Feb 2008 17:06:41 -0500 (EST) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Johannes Dieterich In-Reply-To: <47BCA0EA.4080508@gmail.com> Message-ID: References: <20080220213200.BD12E4500F@ptavv.es.net> <47BCA0EA.4080508@gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-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 Reply-To: Daniel Eischen List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2008 22:23:02 -0000 On Wed, 20 Feb 2008, Johannes Dieterich wrote: > First, thanks for your reply! > > Kevin Oberman wrote: >>> Date: Wed, 20 Feb 2008 22:10:41 +0100 >>> From: Johannes Dieterich >>> Sender: owner-freebsd-acpi@freebsd.org >>> >>> Alexandre "Sunny" Kovalenko wrote: >>>> On Sun, 2008-02-17 at 14:40 +0100, Johannes Dieterich wrote: >>>>> Hi, >>>>> some not so nice news: >>>>> >>>>> That still holds true. Unfortunately portupgrade gcc overheats it again. >>>> You might want to do >>>> >>>> sysctl hw.acpi.thermal.user_override=1 >>>> sysctl hw.acpi.thermal.tz1._PSV=85C >>>> >>>> and see if this gets you through the gcc compilation. >>> for a long long time it looked very good. But then it again overheated.I >>> might want to stress again that it happened out of a sudden. sysctl >>> dev.cpu reports 83-87 degrees for a long time and then it SUDDENLY shuts >>> down saying it is over 127 degrees. The workload between those two data >>> points has not changed. >> >> This is sounding like a hardware problem. >> >> On almost all modern systems, the CPU temperature is read from a single >> junction on the silicon of the CPU. If it makes sudden, inexplicable >> jumps, this implies that either the junction on the chip or the support >> hardware on the mobo (this is analog stuff) is misbehaving. >> >> It is possible that something is causing BIOS to handle the values >> incorrectly, but that would seem very unlikely to me. > > In general, I am willing to believe these things. There is a but though. > The problem appeared when upgrading from 6.2 to 7.0. OK, hardware breaks > and coincidences happen. But I tested later with an openSUSE and a > Knoppix Live CD (OK, JUST a LiveCD) and a stress test and it never went > over 79 degrees. But it reproducibly happens with FreeBSD 7.0 and also > there just under load (which puts the temperature anyway to 85 degrees). > I do lack an install of a Linux to test these issues there because the > notebook is my productive system at the moment. I also have to think that maybe this isn't a hardware issue. I'm having similar problems with an Intel STL2 Tupelo motherboard after upgrading to 7.0. Only under load does the temperature shoot up, but I know the chip isn't getting hot and the fan is running - I've felt around in there and nothing was even close to the 117+C it was sensing. -- DE From owner-freebsd-acpi@FreeBSD.ORG Wed Feb 20 22:38:01 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 D599416A406 for ; Wed, 20 Feb 2008 22:38:01 +0000 (UTC) (envelope-from eischen@vigrid.com) Received: from mail.netplex.net (mail.netplex.net [204.213.176.10]) by mx1.freebsd.org (Postfix) with ESMTP id 8989513C45D for ; Wed, 20 Feb 2008 22:38:01 +0000 (UTC) (envelope-from eischen@vigrid.com) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.netplex.net (8.14.2/8.14.2/NETPLEX) with ESMTP id m1KMFiHL009815; Wed, 20 Feb 2008 17:15:45 -0500 (EST) X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-4.0 (mail.netplex.net [204.213.176.10]); Wed, 20 Feb 2008 17:15:45 -0500 (EST) Date: Wed, 20 Feb 2008 17:15:45 -0500 (EST) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: "Alexandre \"Sunny\" Kovalenko" In-Reply-To: <1203131179.833.32.camel@RabbitsDen> Message-ID: References: <1200369199.2054.38.camel@RabbitsDen> <1203131179.833.32.camel@RabbitsDen> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: acpi@freebsd.org Subject: Re: How to disable acpi thermal? 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, 20 Feb 2008 22:38:01 -0000 On Fri, 15 Feb 2008, Alexandre "Sunny" Kovalenko wrote: > > On Tue, 2008-01-15 at 15:34 -0500, Daniel Eischen wrote: >> [ Redirected from -current ] >> >> On Mon, 14 Jan 2008, Alexandre "Sunny" Kovalenko wrote: >> >>> >>> On Mon, 2008-01-14 at 21:56 -0500, Daniel Eischen wrote: >>>> >>>> Thermal zone 0 skyrockets past 110C in a couple of minutes >>>> when trying to build a kernel. All the other zones stay >>>> relatively static. I suspect something is wrong somewhere >>>> because this machine is very lightly loaded and has never >>>> had a problem until now. I just upgraded it from 4.x to >>>> 7.0. >>> >>> It need not to be bogus -- if I turn off fan on my ThinkPad it will >>> overheat and shut itself down within couple of minutes of buildworld, >>> starting from the relative cool state. From the look of the stuff below >>> your fan should kick in no later then 10 seconds after tz0 reached 77C. >>> Do you hear it running before shutdown? If yes, maybe lowering threshold >>> in AC0 down from 77C will help. If not -- you will need to figure out >>> who is supposed to turn on the fan. You can dump your ASL (instructions >>> in the handbook) and post it someplace accessible -- I will take a look >>> and maybe spot something interesting, but, being far from the expert in >>> the field, I do not promise too much. >> >> I posted the acpidump here: >> >> http://people.freebsd.org/~deischen/stl2.iasl >> >> The problem is that acpi_thermal keeps shutting down the system >> after 2 minutes into a buildkernel. The system has no load other >> than the buildkernel at the time it shuts down. >> >> The system is a Intel STL2 Tupelo motherboard with 1 CPU, the >> other CPU socket being occupied by a CPU terminator thingy. >> I uncovered the rackmount system and watched it while building >> a kernel. With the cover off the acpi monitored temperature >> went to 107C and stayed there. It only took a minute or two >> to get there. I felt around inside the chassis and nothing >> was even near being to warm or hot. With the cover on, the >> temperature goes to 111/112C before being shutdown by acpi_thermal >> (the limit being 110C). There is no way anything in that >> chassis is anywhere near 100C. I've disabled acpi_thermal >> for now, but it'd be nice to get a better fix. >> >> Any ideas? >> > You can try this patch on your ASL, which might just cause passive > cooling to kick in. If you decide to try a patch, I would like to see > the output of I guess I'm confused - how can passive cooling "kick in". Isn't passive cooling always on if you are using a heatsink? > sysctl hw.acpi.thermal > > regardless of the outcome. > > OTOH, it just occurred to me that I have observed something like that on > my previous laptop. I used cheap thermal paste between the CPU and the > heatsink and I used a lot of it. Chassis were relatively cool and yet > CPU sensor hit critical trip point. -- DE From owner-freebsd-acpi@FreeBSD.ORG Wed Feb 20 22:55: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 5F82216A404; Wed, 20 Feb 2008 22:55:44 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from falcon.cybervisiontech.com (falcon.cybervisiontech.com [217.20.163.9]) by mx1.freebsd.org (Postfix) with ESMTP id 53F2D13C43E; Wed, 20 Feb 2008 22:55:38 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from localhost (localhost [127.0.0.1]) by falcon.cybervisiontech.com (Postfix) with ESMTP id 0B6B7744007; Thu, 21 Feb 2008 00:55:37 +0200 (EET) X-Virus-Scanned: Debian amavisd-new at falcon.cybervisiontech.com Received: from falcon.cybervisiontech.com ([127.0.0.1]) by localhost (falcon.cybervisiontech.com [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id 99tCpyNppiy9; Thu, 21 Feb 2008 00:55:36 +0200 (EET) Received: from [10.74.70.239] (unknown [193.138.145.53]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by falcon.cybervisiontech.com (Postfix) with ESMTP id A7BCA744006; Thu, 21 Feb 2008 00:55:35 +0200 (EET) Message-ID: <47BCAFE3.9050703@icyb.net.ua> Date: Thu, 21 Feb 2008 00:55:31 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.9 (X11/20071208) MIME-Version: 1.0 To: freebsd-acpi@freebsd.org, freebsd-current@freebsd.org, freebsd-i386@freebsd.org References: <479F0ED4.9030709@icyb.net.ua> <479F62D9.6080703@root.org> <47A33CCB.3090902@icyb.net.ua> <47B0C10F.6000109@icyb.net.ua> <47B4103A.6090902@icyb.net.ua> <47B4A103.7040801@icyb.net.ua> <47B4B31A.4020605@icyb.net.ua> <47B84E61.3060401@icyb.net.ua> <47BB375C.5010208@icyb.net.ua> <47BB4D5C.9000406@icyb.net.ua> <47BC7287.6000301@icyb.net.ua> In-Reply-To: <47BC7287.6000301@icyb.net.ua> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Cc: freebsd-hackers@freebsd.org Subject: PIIX4 chipset: (non-)exit from CPU states C2, C3 on interrupt 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, 20 Feb 2008 22:55:44 -0000 This is a report on an issue that I had with using C2 CPU power state on a system based on PIIX4E chipset. I think that other users of the chipsets from PIIX4 family might be affected as well. Also, this might be an informative reading for hackers chasing similar problems. Reference material: Intel(R) 82371AB PCI-TO-ISA/IDE Xcelerator (PIIX4) Datasheet http://www.intel.com/design/intarch/datashts/290562.htm Intel 82371AB PIIX4, Intel 82371EB PIIX4E and Intel 82371MB PIIX4M Specification Update http://www.intel.com/design/chipsets/specupdt/297738.htm Intel 82371EB (PIIX4E) Specification Update http://www.intel.com/design/chipsets/specupdt/290635.htm Relevant information can be found in the following sections of the original document and in updates/corrections/errata for them: 11.2. Clock Control 7.2.3. PMCNTRLPOWER MANAGEMENT CONTROL REGISTER (IO) 7.1.16. DEVACTBDEVICE ACTIVITY B (FUNCTION 3) My summarized understanding: To behave in ACPI-compliant way with respect to C2 and C3 states the chipset must generate "Stop Break" events on any interrupt. This is because ACPI specification says the following about C2 state: "The hardware can exit this state for any reason, but must always exit this state whenever an interrupt is to be presented to the processor." For C3 it repeats the same and adds the following: "or when BM_RLD is set and a bus master is attempting to gain access to memory." According to PIIX4 documents the chipset exits "clock control state" either on "Stop Break" event or on "Burst" event. I leave the latter out of consideration because it is not ACPI compliant, CPU state is controlled by hardware, not by OS. Here's an excerpt from description of DEVACTB register, 6 lower bits are described: 5 IRQ8# Clock Event Enable (BRLD_EN_IRQ8)R/W. 1=Enable an unmasked IRQ8# to, when asserted, generate a Fast Burst Timer reload or Stop Break event. 0=Disable. 4 PME Clock Event Enable (BRLD_EN_PME)R/W. 1=Enable an asserted SMI#, GPI1#, PWRBTN#, or LID signal to generate a Fast Burst Timer reload or Stop Break event. 0=Disable. 3 Undefined. Must be written as a 0. 2 Keyboard/Mouse Global Reload Enable (GRLD_EN_KBC_MS)R/W. 1=Enable an assertion of IRQ1 or IRQ12/M to reload the Global Standby Timer. 0=Disable. 1 IRQ Clock Event Enable (BRLD_EN_IRQ)R/W. 1=Enable an unmasked IRQ[1,3:7,9:15], NMI, or INIT to generate a Burst event or Stop Break event. 0=Disable. 0 IRQ0 Clock Event Enable (BRLD_EN_IRQ0)R/W. 1=Enable an unmasked IRQ0 to generate a Burst event or Stop Break event. 0=Disable. In order for the hardware to behave in ACPI-compliant way, that is to generate "Stop Break" events on all interrupts, the following bits of this register must be set: 0 - for IRQ0, 5 - for IRQ8, 1 - for the rest of the maskable interrupts You can read a saga about my investigation of a C2 behavior of a FreeBSD 7.0-RC1 system installed on a hardware based on PIIX4E chipset: http://docs.FreeBSD.org/cgi/mid.cgi?479F0ED4.9030709 This is a long thread with a couple of side-branches that keeps you in suspense until the very end. For those without time to waste, the following link is a pointer to where the most interesting details appear: http://docs.FreeBSD.org/cgi/mid.cgi?47BB375C.5010208 In short: on this system bit 5 of the mentioned above register was reset (i.e. 0), so RTC/IRQ8 didn't cause exit from C2 state. Thus, with cx_lowest=C2, RTC interrupt was handled at the predictable times, usually back-to-back after IRQ0 handler. As a result statclock() gathered CPU usage information (user:nice:system:interrupt:idle) at quite deterministic moments, so the statics was very biased in favor of interrupt usage. This is what the register had after boot: $ pciconf -r pci0:0:7:3 0x58 03040c07 After doing the following CPU statics became reasonable: pciconf -w pci0:0:7:3 0x58 0x03040c27 >From pciconf -lv: intsmb0@pci0:0:7:3: class=0x068000 card=0x00000000 chip=0x71138086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82371AB/EB/MB PIIX4/4E/4M Power Management Controller' class = bridge In the end, my suggestion is that acpi_cpu code should check value of those 3 bits and set them if necessary. I am not actually sure why I have bit 5 reset to 0. Maybe because this is a fault of a vendor of my motherboard/BIOS. Maybe I unwittingly caused this by changing some BIOS setting, but if this is the case, then the setting must appear under a name and description that I would never relate to this issue. Another possible resolution is to check the bits, but instead of changing them just refuse to use anything lower than C1. -- Andriy Gapon From owner-freebsd-acpi@FreeBSD.ORG Wed Feb 20 23:15:01 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 61DD616A400 for ; Wed, 20 Feb 2008 23:15:01 +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 2D73913C458 for ; Wed, 20 Feb 2008 23:15:01 +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 <0JWK00HSQ8KPZE52@vms048.mailsrvcs.net> for acpi@freebsd.org; Wed, 20 Feb 2008 17:14:50 -0600 (CST) Date: Wed, 20 Feb 2008 18:14:47 -0500 From: "Alexandre \"Sunny\" Kovalenko" In-reply-to: To: Daniel Eischen Message-id: <1203549287.1019.43.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: <1200369199.2054.38.camel@RabbitsDen> <1203131179.833.32.camel@RabbitsDen> Cc: acpi@freebsd.org Subject: Re: How to disable acpi thermal? 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, 20 Feb 2008 23:15:01 -0000 On Wed, 2008-02-20 at 17:15 -0500, Daniel Eischen wrote: > On Fri, 15 Feb 2008, Alexandre "Sunny" Kovalenko wrote: > > > > > On Tue, 2008-01-15 at 15:34 -0500, Daniel Eischen wrote: > >> [ Redirected from -current ] > >> > >> On Mon, 14 Jan 2008, Alexandre "Sunny" Kovalenko wrote: > >> > >>> > >>> On Mon, 2008-01-14 at 21:56 -0500, Daniel Eischen wrote: > >>>> > >>>> Thermal zone 0 skyrockets past 110C in a couple of minutes > >>>> when trying to build a kernel. All the other zones stay > >>>> relatively static. I suspect something is wrong somewhere > >>>> because this machine is very lightly loaded and has never > >>>> had a problem until now. I just upgraded it from 4.x to > >>>> 7.0. > >>> > >>> It need not to be bogus -- if I turn off fan on my ThinkPad it will > >>> overheat and shut itself down within couple of minutes of buildworld, > >>> starting from the relative cool state. From the look of the stuff below > >>> your fan should kick in no later then 10 seconds after tz0 reached 77C. > >>> Do you hear it running before shutdown? If yes, maybe lowering threshold > >>> in AC0 down from 77C will help. If not -- you will need to figure out > >>> who is supposed to turn on the fan. You can dump your ASL (instructions > >>> in the handbook) and post it someplace accessible -- I will take a look > >>> and maybe spot something interesting, but, being far from the expert in > >>> the field, I do not promise too much. > >> > >> I posted the acpidump here: > >> > >> http://people.freebsd.org/~deischen/stl2.iasl > >> > >> The problem is that acpi_thermal keeps shutting down the system > >> after 2 minutes into a buildkernel. The system has no load other > >> than the buildkernel at the time it shuts down. > >> > >> The system is a Intel STL2 Tupelo motherboard with 1 CPU, the > >> other CPU socket being occupied by a CPU terminator thingy. > >> I uncovered the rackmount system and watched it while building > >> a kernel. With the cover off the acpi monitored temperature > >> went to 107C and stayed there. It only took a minute or two > >> to get there. I felt around inside the chassis and nothing > >> was even near being to warm or hot. With the cover on, the > >> temperature goes to 111/112C before being shutdown by acpi_thermal > >> (the limit being 110C). There is no way anything in that > >> chassis is anywhere near 100C. I've disabled acpi_thermal > >> for now, but it'd be nice to get a better fix. > >> > >> Any ideas? > >> > > You can try this patch on your ASL, which might just cause passive > > cooling to kick in. If you decide to try a patch, I would like to see > > the output of > > I guess I'm confused - how can passive cooling "kick in". Isn't > passive cooling always on if you are using a heatsink? In the ACPI context (and please, bear with me -- I am no expert -- I just read respective pieces of the spec and experimented with few specimens of my own hardware) "passive" cooling is lowering of the CPU frequency when temperature reaches given point, as denoted by hw.acpi.thermal.tzN._PSV value. This will happen (I have tried ;) regardless of the efforts of powerd to raise the frequency due to the load history. This helps in the situations when CPU could not run at maximum load for protracted periods of time. I assume (possibly incorrectly) that 1) your CPU is capable of the frequency throttling and 2) you are using frequency governor of some sort (see cpufreq(4) for detail). If this is not the case, the change will not help. Also, since I have sent you that change, I have learned that setting hw.acpi.thermal.user_override=1 and hw.acpi.thermal.tz0._PSV=85C might accomplish the same thing as the ASL change. I saw it working for the thermal zone which already had sensible _PSV, but I have no hardware to try this approach when _PSV is not present in the ASL. > > > sysctl hw.acpi.thermal > > > > regardless of the outcome. > > > > OTOH, it just occurred to me that I have observed something like that on > > my previous laptop. I used cheap thermal paste between the CPU and the > > heatsink and I used a lot of it. Chassis were relatively cool and yet > > CPU sensor hit critical trip point. > -- Alexandre "Sunny" Kovalenko (Олександр Коваленко) From owner-freebsd-acpi@FreeBSD.ORG Wed Feb 20 23:29:36 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 DE20716A403 for ; Wed, 20 Feb 2008 23:29:36 +0000 (UTC) (envelope-from crahman@gmail.com) Received: from el-out-1112.google.com (el-out-1112.google.com [209.85.162.180]) by mx1.freebsd.org (Postfix) with ESMTP id 9269213C468 for ; Wed, 20 Feb 2008 23:29:36 +0000 (UTC) (envelope-from crahman@gmail.com) Received: by el-out-1112.google.com with SMTP id r27so1417106ele.3 for ; Wed, 20 Feb 2008 15:29:35 -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:content-transfer-encoding:content-disposition; bh=aKZiLUyWDVEDO90aj0fXTxgggAR6XyRZYJp5CWjuDfc=; b=wARMt6xgymlvwreCNqfFUzXNFCz+qPykfwm1Keh4w2F8LBY9yHU5T94iSL+0M4bfORibKLJgT94HF0YXUT8xHkDyk903pgSRCTxNtnUk5HupJVWzX8UdTznSJwntKW80PQ7VaiVidz6IQOWzdpHwqYcpGqqEA7jFK9qDHuAx/mM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=FlVMGRXuWuIOgN8Z+y+Fk5YOXCorYX1hCWmFYC/DcaR5Xg6hCUs4dtg3t9c8kop/q585rF9jOMqspDY6X5pyGwxrwVz862+3SS5qAF/nYBOrnC1KKzQBDGzwJnN8aGC6Im3rQ+SUbMLGwJEvlWC2eA+/9WJnV8n7g1W8PBnzNSw= Received: by 10.142.83.4 with SMTP id g4mr7020420wfb.103.1203548470766; Wed, 20 Feb 2008 15:01:10 -0800 (PST) Received: by 10.142.188.17 with HTTP; Wed, 20 Feb 2008 15:01:10 -0800 (PST) Message-ID: <9e77bdb50802201501g3bb834b1l92c018a48b7a8976@mail.gmail.com> Date: Wed, 20 Feb 2008 16:01:10 -0700 From: "Cyrus Rahman" To: freebsd-acpi@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: ACPI suspend/resume on amd64 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, 20 Feb 2008 23:29:36 -0000 There's probably some very good reason for it, but in dev/acpica/acpi.c I see that suspend/resume is ifdef'd out for the amd64 platform (or more precisely, anything not i386). I'm curious, what fails running in 64-bit mode? Would it be a difficult thing to enable? From owner-freebsd-acpi@FreeBSD.ORG Wed Feb 20 23:48:37 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 B248E16A403 for ; Wed, 20 Feb 2008 23:48:37 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.netplex.net (mail.netplex.net [204.213.176.10]) by mx1.freebsd.org (Postfix) with ESMTP id 84CC513C45E for ; Wed, 20 Feb 2008 23:48:37 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.netplex.net (8.14.2/8.14.2/NETPLEX) with ESMTP id m1KNmasV012285; Wed, 20 Feb 2008 18:48:36 -0500 (EST) X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-4.0 (mail.netplex.net [204.213.176.10]); Wed, 20 Feb 2008 18:48:36 -0500 (EST) Date: Wed, 20 Feb 2008 18:48:36 -0500 (EST) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: "Alexandre \\Sunny\\ Kovalenko" In-Reply-To: <1203549287.1019.43.camel@RabbitsDen> Message-ID: References: <1200369199.2054.38.camel@RabbitsDen> <1203131179.833.32.camel@RabbitsDen> <1203549287.1019.43.camel@RabbitsDen> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: acpi@freebsd.org Subject: Re: How to disable acpi thermal? X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Daniel Eischen List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2008 23:48:37 -0000 On Wed, 20 Feb 2008, Alexandre \Sunny\ Kovalenko wrote: > > On Wed, 2008-02-20 at 17:15 -0500, Daniel Eischen wrote: >> On Fri, 15 Feb 2008, Alexandre "Sunny" Kovalenko wrote: >> >>> >>> On Tue, 2008-01-15 at 15:34 -0500, Daniel Eischen wrote: >>>> [ Redirected from -current ] >>>> >>>> I posted the acpidump here: >>>> >>>> http://people.freebsd.org/~deischen/stl2.iasl >>>> >>>> The problem is that acpi_thermal keeps shutting down the system >>>> after 2 minutes into a buildkernel. The system has no load other >>>> than the buildkernel at the time it shuts down. >>>> >>>> The system is a Intel STL2 Tupelo motherboard with 1 CPU, the >>>> other CPU socket being occupied by a CPU terminator thingy. >>>> I uncovered the rackmount system and watched it while building >>>> a kernel. With the cover off the acpi monitored temperature >>>> went to 107C and stayed there. It only took a minute or two >>>> to get there. I felt around inside the chassis and nothing >>>> was even near being to warm or hot. With the cover on, the >>>> temperature goes to 111/112C before being shutdown by acpi_thermal >>>> (the limit being 110C). There is no way anything in that >>>> chassis is anywhere near 100C. I've disabled acpi_thermal >>>> for now, but it'd be nice to get a better fix. >>>> >>>> Any ideas? >>>> >>> You can try this patch on your ASL, which might just cause passive >>> cooling to kick in. If you decide to try a patch, I would like to see >>> the output of >> >> I guess I'm confused - how can passive cooling "kick in". Isn't >> passive cooling always on if you are using a heatsink? > In the ACPI context (and please, bear with me -- I am no expert -- I > just read respective pieces of the spec and experimented with few > specimens of my own hardware) "passive" cooling is lowering of the CPU > frequency when temperature reaches given point, as denoted by > hw.acpi.thermal.tzN._PSV value. This will happen (I have tried ;) > regardless of the efforts of powerd to raise the frequency due to the > load history. This helps in the situations when CPU could not run at > maximum load for protracted periods of time. Ok, now this makes sense. > I assume (possibly incorrectly) that 1) your CPU is capable of the > frequency throttling and 2) you are using frequency governor of some > sort (see cpufreq(4) for detail). If this is not the case, the change > will not help. I don't know about 1): CPU: Intel Pentium III (933.08-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x686 Stepping = 6 Features=0x383fbff and 2), no, I'm not using a frequency governor from what I can tell. $ sysctl -a | grep dev.cpu dev.cpu.0.%desc: ACPI CPU dev.cpu.0.%driver: cpu dev.cpu.0.%location: handle=\_PR_.CPU0 dev.cpu.0.%pnpinfo: _HID=none _UID=0 dev.cpu.0.%parent: acpi0 dev.cpu.0.cx_supported: C1/0 dev.cpu.0.cx_lowest: C1 dev.cpu.0.cx_usage: 100.00% $ sudo kldload /boot/kernel/cpufreq.ko $ sysctl -a | grep dev.cpu dev.cpu.0.%desc: ACPI CPU dev.cpu.0.%driver: cpu dev.cpu.0.%location: handle=\_PR_.CPU0 dev.cpu.0.%pnpinfo: _HID=none _UID=0 dev.cpu.0.%parent: acpi0 dev.cpu.0.cx_supported: C1/0 dev.cpu.0.cx_lowest: C1 dev.cpu.0.cx_usage: 100.00% > Also, since I have sent you that change, I have learned that setting > hw.acpi.thermal.user_override=1 and hw.acpi.thermal.tz0._PSV=85C might > accomplish the same thing as the ASL change. I saw it working for the > thermal zone which already had sensible _PSV, but I have no hardware to > try this approach when _PSV is not present in the ASL. Well, this is a server board, not a laptop, so I'm not sure it even has CPU throttling. -- DE From owner-freebsd-acpi@FreeBSD.ORG Thu Feb 21 01:02:32 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 3917C16A401; Thu, 21 Feb 2008 01:02:32 +0000 (UTC) (envelope-from alex.kovalenko@verizon.net) Received: from vms042pub.verizon.net (vms042pub.verizon.net [206.46.252.42]) by mx1.freebsd.org (Postfix) with ESMTP id 18C9313C448; Thu, 21 Feb 2008 01:02:32 +0000 (UTC) (envelope-from alex.kovalenko@verizon.net) Received: from [10.0.3.231] ([70.111.176.151]) by vms042.mailsrvcs.net (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPA id <0JWK0050JDJYJ0V2@vms042.mailsrvcs.net>; Wed, 20 Feb 2008 19:02:24 -0600 (CST) Date: Wed, 20 Feb 2008 20:02:21 -0500 From: "Alexandre \"Sunny\" Kovalenko" In-reply-to: To: Daniel Eischen Message-id: <1203555741.1019.50.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: <1200369199.2054.38.camel@RabbitsDen> <1203131179.833.32.camel@RabbitsDen> <1203549287.1019.43.camel@RabbitsDen> Cc: acpi@freebsd.org Subject: Re: How to disable acpi thermal? 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, 21 Feb 2008 01:02:32 -0000 On Wed, 2008-02-20 at 18:48 -0500, Daniel Eischen wrote: > On Wed, 20 Feb 2008, Alexandre \Sunny\ Kovalenko wrote: > > > > > On Wed, 2008-02-20 at 17:15 -0500, Daniel Eischen wrote: > >> On Fri, 15 Feb 2008, Alexandre "Sunny" Kovalenko wrote: > >> > >>> > >>> On Tue, 2008-01-15 at 15:34 -0500, Daniel Eischen wrote: > >>>> [ Redirected from -current ] > >>>> > >>>> I posted the acpidump here: > >>>> > >>>> http://people.freebsd.org/~deischen/stl2.iasl > >>>> > >>>> The problem is that acpi_thermal keeps shutting down the system > >>>> after 2 minutes into a buildkernel. The system has no load other > >>>> than the buildkernel at the time it shuts down. > >>>> > >>>> The system is a Intel STL2 Tupelo motherboard with 1 CPU, the > >>>> other CPU socket being occupied by a CPU terminator thingy. > >>>> I uncovered the rackmount system and watched it while building > >>>> a kernel. With the cover off the acpi monitored temperature > >>>> went to 107C and stayed there. It only took a minute or two > >>>> to get there. I felt around inside the chassis and nothing > >>>> was even near being to warm or hot. With the cover on, the > >>>> temperature goes to 111/112C before being shutdown by acpi_thermal > >>>> (the limit being 110C). There is no way anything in that > >>>> chassis is anywhere near 100C. I've disabled acpi_thermal > >>>> for now, but it'd be nice to get a better fix. > >>>> > >>>> Any ideas? > >>>> > >>> You can try this patch on your ASL, which might just cause passive > >>> cooling to kick in. If you decide to try a patch, I would like to see > >>> the output of > >> > >> I guess I'm confused - how can passive cooling "kick in". Isn't > >> passive cooling always on if you are using a heatsink? > > In the ACPI context (and please, bear with me -- I am no expert -- I > > just read respective pieces of the spec and experimented with few > > specimens of my own hardware) "passive" cooling is lowering of the CPU > > frequency when temperature reaches given point, as denoted by > > hw.acpi.thermal.tzN._PSV value. This will happen (I have tried ;) > > regardless of the efforts of powerd to raise the frequency due to the > > load history. This helps in the situations when CPU could not run at > > maximum load for protracted periods of time. > > Ok, now this makes sense. > > > I assume (possibly incorrectly) that 1) your CPU is capable of the > > frequency throttling and 2) you are using frequency governor of some > > sort (see cpufreq(4) for detail). If this is not the case, the change > > will not help. > > I don't know about 1): > > CPU: Intel Pentium III (933.08-MHz 686-class CPU) > Origin = "GenuineIntel" Id = 0x686 Stepping = 6 > Features=0x383fbff > > and 2), no, I'm not using a frequency governor from what I can > tell. > > $ sysctl -a | grep dev.cpu > dev.cpu.0.%desc: ACPI CPU > dev.cpu.0.%driver: cpu > dev.cpu.0.%location: handle=\_PR_.CPU0 > dev.cpu.0.%pnpinfo: _HID=none _UID=0 > dev.cpu.0.%parent: acpi0 > dev.cpu.0.cx_supported: C1/0 > dev.cpu.0.cx_lowest: C1 > dev.cpu.0.cx_usage: 100.00% > > $ sudo kldload /boot/kernel/cpufreq.ko > > $ sysctl -a | grep dev.cpu > dev.cpu.0.%desc: ACPI CPU > dev.cpu.0.%driver: cpu > dev.cpu.0.%location: handle=\_PR_.CPU0 > dev.cpu.0.%pnpinfo: _HID=none _UID=0 > dev.cpu.0.%parent: acpi0 > dev.cpu.0.cx_supported: C1/0 > dev.cpu.0.cx_lowest: C1 > dev.cpu.0.cx_usage: 100.00% > > > > Also, since I have sent you that change, I have learned that setting > > hw.acpi.thermal.user_override=1 and hw.acpi.thermal.tz0._PSV=85C might > > accomplish the same thing as the ASL change. I saw it working for the > > thermal zone which already had sensible _PSV, but I have no hardware to > > try this approach when _PSV is not present in the ASL. > > Well, this is a server board, not a laptop, so I'm not sure > it even has CPU throttling. > As far as I can tell from the stuff above -- it does not. I was confused by presence of some pieces in the ASL, which would normally indicate that it does. One thing, which surprises me, is that with the lack of throttling and, what appears to be single speed fan or even a heatsink, I do not see how its thermal mode could behave differently in the presence of the load. Could you, please, send me output of the sysctl machdep. -- Alexandre "Sunny" Kovalenko (Олександр Коваленко) From owner-freebsd-acpi@FreeBSD.ORG Thu Feb 21 01:14:46 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 06A9916A401 for ; Thu, 21 Feb 2008 01:14:46 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.netplex.net (mail.netplex.net [204.213.176.10]) by mx1.freebsd.org (Postfix) with ESMTP id B67ED13C469 for ; Thu, 21 Feb 2008 01:14:45 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.netplex.net (8.14.2/8.14.2/NETPLEX) with ESMTP id m1L1EhhO007865; Wed, 20 Feb 2008 20:14:43 -0500 (EST) X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-4.0 (mail.netplex.net [204.213.176.10]); Wed, 20 Feb 2008 20:14:44 -0500 (EST) Date: Wed, 20 Feb 2008 20:14:44 -0500 (EST) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: "Alexandre \\Sunny\\ Kovalenko" In-Reply-To: <1203555741.1019.50.camel@RabbitsDen> Message-ID: References: <1200369199.2054.38.camel@RabbitsDen> <1203131179.833.32.camel@RabbitsDen> <1203549287.1019.43.camel@RabbitsDen> <1203555741.1019.50.camel@RabbitsDen> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: acpi@freebsd.org Subject: Re: How to disable acpi thermal? X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Daniel Eischen List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2008 01:14:46 -0000 On Wed, 20 Feb 2008, Alexandre \Sunny\ Kovalenko wrote: > > On Wed, 2008-02-20 at 18:48 -0500, Daniel Eischen wrote: >> On Wed, 20 Feb 2008, Alexandre \Sunny\ Kovalenko wrote: >> >>> I assume (possibly incorrectly) that 1) your CPU is capable of the >>> frequency throttling and 2) you are using frequency governor of some >>> sort (see cpufreq(4) for detail). If this is not the case, the change >>> will not help. >> >> I don't know about 1): >> >> CPU: Intel Pentium III (933.08-MHz 686-class CPU) >> Origin = "GenuineIntel" Id = 0x686 Stepping = 6 >> Features=0x383fbff >> >> and 2), no, I'm not using a frequency governor from what I can >> tell. >> >> $ sysctl -a | grep dev.cpu >> dev.cpu.0.%desc: ACPI CPU >> dev.cpu.0.%driver: cpu >> dev.cpu.0.%location: handle=\_PR_.CPU0 >> dev.cpu.0.%pnpinfo: _HID=none _UID=0 >> dev.cpu.0.%parent: acpi0 >> dev.cpu.0.cx_supported: C1/0 >> dev.cpu.0.cx_lowest: C1 >> dev.cpu.0.cx_usage: 100.00% >> >> $ sudo kldload /boot/kernel/cpufreq.ko >> >> $ sysctl -a | grep dev.cpu >> dev.cpu.0.%desc: ACPI CPU >> dev.cpu.0.%driver: cpu >> dev.cpu.0.%location: handle=\_PR_.CPU0 >> dev.cpu.0.%pnpinfo: _HID=none _UID=0 >> dev.cpu.0.%parent: acpi0 >> dev.cpu.0.cx_supported: C1/0 >> dev.cpu.0.cx_lowest: C1 >> dev.cpu.0.cx_usage: 100.00% >> >> >>> Also, since I have sent you that change, I have learned that setting >>> hw.acpi.thermal.user_override=1 and hw.acpi.thermal.tz0._PSV=85C might >>> accomplish the same thing as the ASL change. I saw it working for the >>> thermal zone which already had sensible _PSV, but I have no hardware to >>> try this approach when _PSV is not present in the ASL. >> >> Well, this is a server board, not a laptop, so I'm not sure >> it even has CPU throttling. >> > As far as I can tell from the stuff above -- it does not. I was confused > by presence of some pieces in the ASL, which would normally indicate > that it does. One thing, which surprises me, is that with the lack of > throttling and, what appears to be single speed fan or even a heatsink, > I do not see how its thermal mode could behave differently in the > presence of the load. Could you, please, send me output of the sysctl > machdep. $ sysctl machdep machdep.enable_panic_key: 0 machdep.adjkerntz: 0 machdep.wall_cmos_clock: 0 machdep.disable_rtc_set: 0 machdep.conspeed: 9600 machdep.gdbspeed: 9600 machdep.conrclk: 1843200 machdep.disable_mtrrs: 0 machdep.guessed_bootdev: 2687500288 machdep.cpu_idle_hlt: 1 machdep.prot_fault_translation: 0 machdep.panic_on_nmi: 1 machdep.kdb_on_nmi: 1 machdep.tsc_freq: 933073074 machdep.i8254_freq: 1193182 machdep.acpi_timer_freq: 3579545 machdep.acpi_root: 1009936 -- DE From owner-freebsd-acpi@FreeBSD.ORG Thu Feb 21 01:28:45 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 6BF2816A4A5 for ; Thu, 21 Feb 2008 01:28:45 +0000 (UTC) (envelope-from SRS0=db828d80fcf05de0320d451243f04ba29ac086bb=617=es.net=oberman@es.net) Received: from postal1.es.net (postoffice3.tagpma.org [IPv6:2001:400:14:3::8]) by mx1.freebsd.org (Postfix) with ESMTP id B942413C46B for ; Thu, 21 Feb 2008 01:28:44 +0000 (UTC) (envelope-from SRS0=db828d80fcf05de0320d451243f04ba29ac086bb=617=es.net=oberman@es.net) Received: from ptavv.es.net (ptavv.es.net [198.128.4.29]) by postal3.es.net (Postal Node 3) with ESMTP (SSL) id AYQ18806; Wed, 20 Feb 2008 14:48:06 -0800 Received: from ptavv.es.net (ptavv.es.net [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id 738E94500F; Wed, 20 Feb 2008 14:48:06 -0800 (PST) To: Daniel Eischen In-Reply-To: Your message of "Wed, 20 Feb 2008 17:15:45 EST." Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==_Exmh_1203547686_81195P"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Wed, 20 Feb 2008 14:48:06 -0800 From: "Kevin Oberman" Message-Id: <20080220224806.738E94500F@ptavv.es.net> X-Sender-IP: 198.128.4.29 X-Sender-Domain: es.net X-Recipent: ; ; ; X-Sender: X-To_Name: Daniel Eischen X-To_Domain: vigrid.com X-To: Daniel Eischen X-To_Email: eischen@vigrid.com X-To_Alias: eischen Cc: acpi@freebsd.org, "Alexandre \"Sunny\" Kovalenko" Subject: Re: How to disable acpi thermal? 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, 21 Feb 2008 01:28:45 -0000 --==_Exmh_1203547686_81195P Content-Type: text/plain; charset=us-ascii Content-Disposition: inline > Date: Wed, 20 Feb 2008 17:15:45 -0500 (EST) > From: Daniel Eischen > Sender: owner-freebsd-acpi@freebsd.org > > On Fri, 15 Feb 2008, Alexandre "Sunny" Kovalenko wrote: > > > > > On Tue, 2008-01-15 at 15:34 -0500, Daniel Eischen wrote: > >> [ Redirected from -current ] > >> > >> On Mon, 14 Jan 2008, Alexandre "Sunny" Kovalenko wrote: > >> > >>> > >>> On Mon, 2008-01-14 at 21:56 -0500, Daniel Eischen wrote: > >>>> > >>>> Thermal zone 0 skyrockets past 110C in a couple of minutes > >>>> when trying to build a kernel. All the other zones stay > >>>> relatively static. I suspect something is wrong somewhere > >>>> because this machine is very lightly loaded and has never > >>>> had a problem until now. I just upgraded it from 4.x to > >>>> 7.0. > >>> > >>> It need not to be bogus -- if I turn off fan on my ThinkPad it will > >>> overheat and shut itself down within couple of minutes of buildworld, > >>> starting from the relative cool state. From the look of the stuff below > >>> your fan should kick in no later then 10 seconds after tz0 reached 77C. > >>> Do you hear it running before shutdown? If yes, maybe lowering threshold > >>> in AC0 down from 77C will help. If not -- you will need to figure out > >>> who is supposed to turn on the fan. You can dump your ASL (instructions > >>> in the handbook) and post it someplace accessible -- I will take a look > >>> and maybe spot something interesting, but, being far from the expert in > >>> the field, I do not promise too much. > >> > >> I posted the acpidump here: > >> > >> http://people.freebsd.org/~deischen/stl2.iasl > >> > >> The problem is that acpi_thermal keeps shutting down the system > >> after 2 minutes into a buildkernel. The system has no load other > >> than the buildkernel at the time it shuts down. > >> > >> The system is a Intel STL2 Tupelo motherboard with 1 CPU, the > >> other CPU socket being occupied by a CPU terminator thingy. > >> I uncovered the rackmount system and watched it while building > >> a kernel. With the cover off the acpi monitored temperature > >> went to 107C and stayed there. It only took a minute or two > >> to get there. I felt around inside the chassis and nothing > >> was even near being to warm or hot. With the cover on, the > >> temperature goes to 111/112C before being shutdown by acpi_thermal > >> (the limit being 110C). There is no way anything in that > >> chassis is anywhere near 100C. I've disabled acpi_thermal > >> for now, but it'd be nice to get a better fix. > >> > >> Any ideas? > >> > > You can try this patch on your ASL, which might just cause passive > > cooling to kick in. If you decide to try a patch, I would like to see > > the output of > > I guess I'm confused - how can passive cooling "kick in". Isn't > passive cooling always on if you are using a heatsink? We need some definitions: Active cooling = fan speed Passive cooling = Slowing the speed of the processor to prevent overheating. So "passive cooling kicks in" when the thermal zone temperature reaches the value of _PSV in ACPI. The CPU slows by some amount, depending on the capabilities of the system (P4TCC, SpeedStep, Enhanced SpeedStep, EIST, Enhanced EIST). More capable versions change both CPU speed and voltage. http://en.wikipedia.org/wiki/SpeedStep -- 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_1203547686_81195P Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (FreeBSD) Comment: Exmh version 2.5 06/03/2002 iD8DBQFHvK4mkn3rs5h7N1ERArheAKCNlSLYCo2l2t2SFfrgMcFWuJ7sxQCfZed7 9teZadYGlsNHWcyeN6K7AN8= =ohma -----END PGP SIGNATURE----- --==_Exmh_1203547686_81195P-- From owner-freebsd-acpi@FreeBSD.ORG Thu Feb 21 04:48:47 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 A820316A403; Thu, 21 Feb 2008 04:48:47 +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 62F7813C455; Thu, 21 Feb 2008 04:48:44 +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 PAA21773; Thu, 21 Feb 2008 15:48:33 +1100 (EST) (envelope-from smithi@nimnet.asn.au) Date: Thu, 21 Feb 2008 15:48:32 +1100 (EST) From: Ian Smith To: Johannes Dieterich In-Reply-To: <47BC8397.4040207@gmail.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: freebsd-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: Thu, 21 Feb 2008 04:48:47 -0000 On Wed, 20 Feb 2008, Johannes Dieterich wrote: > Hajimu UMEMOTO wrote: > > Hi, > > > >>>>>> On Tue, 19 Feb 2008 00:19:36 +0100 > >>>>>> Johannes Dieterich said: > > > > dieterich.joh> # sysctl hw.acpi.thermal.tz1 > > dieterich.joh> hw.acpi.thermal.tz1.temperature: 66.0C > > dieterich.joh> hw.acpi.thermal.tz1.active: -1 > > dieterich.joh> hw.acpi.thermal.tz1.passive_cooling: 0 > > dieterich.joh> hw.acpi.thermal.tz1.thermal_flags: 0 > > dieterich.joh> hw.acpi.thermal.tz1._PSV: 92.5C > > dieterich.joh> hw.acpi.thermal.tz1._HOT: -1 > > dieterich.joh> hw.acpi.thermal.tz1._CRT: 97.0C > > dieterich.joh> hw.acpi.thermal.tz1._ACx: -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 > > dieterich.joh> hw.acpi.thermal.tz1._TC1: 5 > > dieterich.joh> hw.acpi.thermal.tz1._TC2: 4 > > dieterich.joh> hw.acpi.thermal.tz1._TSP: 600 > > > > dieterich.joh> is the wanted output without Sunny's patch compiled in. > > > > Thank you. It seems good to me. I've tried following setting on my > > laptop, and it's working well: > > > > sysctl hw.acpi.verbose=1 > > sysctl hw.acpi.thermal.user_override=1 > > sysctl hw.acpi.thermal.tz0._TC1=5 > > sysctl hw.acpi.thermal.tz0._TC2=4 > > sysctl hw.acpi.thermal.tz0._TSP=600 > > > and now I start to wonder: that is what happens: > > # sysctl hw.acpi.verbose=1 > hw.acpi.verbose: 0 -> 1 > # sysctl hw.acpi.thermal.user_override=1 > hw.acpi.thermal.user_override: 0 -> 1 > # sysctl hw.acpi.thermal.tz0._TC1=5 > hw.acpi.thermal.tz0._TC1: -1 -> 5 > # sysctl hw.acpi.thermal.tz0._TC2=4 > hw.acpi.thermal.tz0._TC2: -1 -> 4 > # sysctl hw.acpi.thermal.tz0._TSP=600 > hw.acpi.thermal.tz0._TSP: -1 -> 600 > > Shouldn't that be somewhat different? And I didn't change anything in > between but rebooting the machine. > > > The following was logged into /var/log/messages: > > > > Feb 19 11:08:26 kasuga kernel: acpi_tz0: temperature 85.8C: decreasing clock speed from 1200 MHz to 1000 MHz > > Feb 19 11:09:26 kasuga kernel: acpi_tz0: temperature 82.8C: resuming previous clock speed (1200 MHz) > > Feb 19 11:10:26 kasuga kernel: acpi_tz0: temperature 86.8C: decreasing clock speed from 1200 MHz to 900 MHz > > Feb 19 11:11:26 kasuga kernel: acpi_tz0: temperature 79.8C: resuming previous clock speed (1200 MHz) > > > still nothing. Completely nothing. > > > So, I think the value of _TC1, _TC2 and _TSP is valid. > > > > Still, I'm not sure why the above message is not logged on your > > laptop. But, it would be worth to try increasing _TC2 and/or > > decreasing _TSP. > That might be my next test then. Just wanted to let you know about the > IMHO strange output above. It seems there's some ongoing confusion here between tz0 and tz1. At least, I know I've been confused :) It turned out, I understand, that Alexandre's laptop had the same original settings as yours - is it just the same machine? - and he didn't get any relief until modifying the passive cooling settings (_PSV, _TC1, _TC2 and _TSP) for tz1, not tz0. Alex said elsewhere that he suspected his tz0 might be the GPU rather than CPU, or perhaps it's CPU0 but the passive parameters are applied instead to CPU1, that's still unclear to me, but in either case his .tz0._CRT also said 127C and his .tz1._PSV was around yours, ie 92.5C. Quoting yours from an earlier post: > hw.acpi.cpu.cx_lowest: C2 > hw.acpi.thermal.min_runtime: 0 > hw.acpi.thermal.polling_rate: 10 > hw.acpi.thermal.user_override: 0 > hw.acpi.thermal.tz0.temperature: 62.0C > hw.acpi.thermal.tz0.active: -1 > hw.acpi.thermal.tz0.passive_cooling: 0 > hw.acpi.thermal.tz0.thermal_flags: 0 > hw.acpi.thermal.tz0._PSV: -1 > hw.acpi.thermal.tz0._HOT: -1 > hw.acpi.thermal.tz0._CRT: 127.0C > hw.acpi.thermal.tz0._ACx: -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 > hw.acpi.thermal.tz1.temperature: 63.0C > hw.acpi.thermal.tz1.active: -1 > hw.acpi.thermal.tz1.passive_cooling: 0 > hw.acpi.thermal.tz1.thermal_flags: 0 > hw.acpi.thermal.tz1._PSV: 92.5C > 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 which, I think, is as Alex's was before any .user_override values. But above, you showed applying the overrides to tz0, not tz1, perhaps because Hajimu showed those values applied to _his_ tz0, which would be right for his (and most) laptops, but not, it seems, Alex's and likely yours too? So could you try applying the .user_override=1, .verbose=1 but those _PSV, _TC1, _TC2 and _TSP values to tz1 rather than to tz0, and set .tz1._PSV to some lower value that will be reached, and see if that works, or makes a difference, doing the expected logging to messages? cheers, Ian From owner-freebsd-acpi@FreeBSD.ORG Thu Feb 21 09:03:04 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 A781616A402 for ; Thu, 21 Feb 2008 09:03:04 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from mail08.syd.optusnet.com.au (mail08.syd.optusnet.com.au [211.29.132.189]) by mx1.freebsd.org (Postfix) with ESMTP id 4356713C45A for ; Thu, 21 Feb 2008 09:03:04 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from server.vk2pj.dyndns.org (c220-239-20-82.belrs4.nsw.optusnet.com.au [220.239.20.82]) by mail08.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id m1L8aaF6011497 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 Feb 2008 19:36:37 +1100 Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by server.vk2pj.dyndns.org (8.14.2/8.14.1) with ESMTP id m1L8aakh044895; Thu, 21 Feb 2008 19:36:36 +1100 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.2/8.14.2/Submit) id m1L8aZ5w044894; Thu, 21 Feb 2008 19:36:35 +1100 (EST) (envelope-from peter) Date: Thu, 21 Feb 2008 19:36:35 +1100 From: Peter Jeremy To: Daniel Eischen Message-ID: <20080221083635.GI51095@server.vk2pj.dyndns.org> References: <20080220213200.BD12E4500F@ptavv.es.net> <47BCA0EA.4080508@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="8JPrznbw0YAQ/KXy" Content-Disposition: inline In-Reply-To: X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.17 (2007-11-01) 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: Thu, 21 Feb 2008 09:03:04 -0000 --8JPrznbw0YAQ/KXy Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Feb 20, 2008 at 05:06:41PM -0500, Daniel Eischen wrote: >I'm having similar problems with an Intel STL2 Tupelo motherboard >after upgrading to 7.0. I had problems with one TZ on my laptop occasionally reporting nonsense values. I suspect it was actually a dry joint somewhere near the sensor. The MB eventually failed and the new MB is OK. We had a similar issue on a server at work - the vendor noticed that the system was reporting an abnormally high temperature in one zone whilst investigating an unrelated problem. We eventually decided it was a faulty sensor and a replacement board fixed it. > Only under load does the temperature >shoot up, but I know the chip isn't getting hot and the fan >is running - I've felt around in there and nothing was even >close to the 117+C it was sensing. Apart from the actual CPU, most parts of a system have a fairly significant thermal mass so a rapid change in temperature either indicates a catastrophic failure or the temperature sensor isn't really reporting the temperature of the relevant zone. --=20 Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. --8JPrznbw0YAQ/KXy Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFHvTgT/opHv/APuIcRAla1AJ4ucBwS2GsYrmOsCEnYYgVks5p5hwCgnBPd aykaNfkZAZ2jXzs0UrUqLoU= =kf7U -----END PGP SIGNATURE----- --8JPrznbw0YAQ/KXy-- From owner-freebsd-acpi@FreeBSD.ORG Thu Feb 21 10:28:20 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 5DA0316A400; Thu, 21 Feb 2008 10:28:20 +0000 (UTC) (envelope-from gavin@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id D888713C442; Thu, 21 Feb 2008 10:28:18 +0000 (UTC) (envelope-from gavin@FreeBSD.org) Received: from freefall.freebsd.org (gavin@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m1LASIFe031405; Thu, 21 Feb 2008 10:28:18 GMT (envelope-from gavin@freefall.freebsd.org) Received: (from gavin@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m1LASI0P031401; Thu, 21 Feb 2008 10:28:18 GMT (envelope-from gavin) Date: Thu, 21 Feb 2008 10:28:18 GMT Message-Id: <200802211028.m1LASI0P031401@freefall.freebsd.org> To: vaida.bogdan@gmail.com, gavin@FreeBSD.org, gavin@FreeBSD.org, freebsd-acpi@FreeBSD.org From: gavin@FreeBSD.org Cc: Subject: Re: kern/91038: [panic] [ata] [acpi] 6.0-RELEASE on Fujitsu Siemens Amilo Pro v2040 can't resume from sleep 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, 21 Feb 2008 10:28:20 -0000 Old Synopsis: [panic] 6.0-RELEASE on Fujitsu Siemens Amilo Pro v2040 can't resume from sleep New Synopsis: [panic] [ata] [acpi] 6.0-RELEASE on Fujitsu Siemens Amilo Pro v2040 can't resume from sleep State-Changed-From-To: feedback->suspended State-Changed-By: gavin State-Changed-When: Thu Feb 21 10:25:13 UTC 2008 State-Changed-Why: Original submitter no longer uses FreeBSD on this laptop, mark as suspended until somebody else is able to help Responsible-Changed-From-To: gavin->freebsd-acpi Responsible-Changed-By: gavin Responsible-Changed-When: Thu Feb 21 10:25:13 UTC 2008 Responsible-Changed-Why: Over to freebsd-acpi@ http://www.freebsd.org/cgi/query-pr.cgi?pr=91038 From owner-freebsd-acpi@FreeBSD.ORG Fri Feb 22 02:08:34 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 40FE916A400; Fri, 22 Feb 2008 02:08:34 +0000 (UTC) (envelope-from alex.kovalenko@verizon.net) Received: from vms040pub.verizon.net (vms040pub.verizon.net [206.46.252.40]) by mx1.freebsd.org (Postfix) with ESMTP id 1D6E013C457; Fri, 22 Feb 2008 02:08:34 +0000 (UTC) (envelope-from alex.kovalenko@verizon.net) Received: from [10.0.3.231] ([70.111.176.151]) by vms040.mailsrvcs.net (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPA id <0JWM00M1OBE5WJ21@vms040.mailsrvcs.net>; Thu, 21 Feb 2008 20:10:55 -0600 (CST) Date: Thu, 21 Feb 2008 21:08:16 -0500 From: "Alexandre \"Sunny\" Kovalenko" In-reply-to: To: Daniel Eischen Message-id: <1203646096.16055.22.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: <1200369199.2054.38.camel@RabbitsDen> <1203131179.833.32.camel@RabbitsDen> <1203549287.1019.43.camel@RabbitsDen> <1203555741.1019.50.camel@RabbitsDen> Cc: acpi@freebsd.org Subject: Re: How to disable acpi thermal? 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, 22 Feb 2008 02:08:34 -0000 On Wed, 2008-02-20 at 20:14 -0500, Daniel Eischen wrote: > On Wed, 20 Feb 2008, Alexandre \Sunny\ Kovalenko wrote: > > > > > On Wed, 2008-02-20 at 18:48 -0500, Daniel Eischen wrote: > >> On Wed, 20 Feb 2008, Alexandre \Sunny\ Kovalenko wrote: > >> > >>> I assume (possibly incorrectly) that 1) your CPU is capable of the > >>> frequency throttling and 2) you are using frequency governor of some > >>> sort (see cpufreq(4) for detail). If this is not the case, the change > >>> will not help. > >> > >> I don't know about 1): > >> > >> CPU: Intel Pentium III (933.08-MHz 686-class CPU) > >> Origin = "GenuineIntel" Id = 0x686 Stepping = 6 > >> Features=0x383fbff > >> > >> and 2), no, I'm not using a frequency governor from what I can > >> tell. > >> > >> $ sysctl -a | grep dev.cpu > >> dev.cpu.0.%desc: ACPI CPU > >> dev.cpu.0.%driver: cpu > >> dev.cpu.0.%location: handle=\_PR_.CPU0 > >> dev.cpu.0.%pnpinfo: _HID=none _UID=0 > >> dev.cpu.0.%parent: acpi0 > >> dev.cpu.0.cx_supported: C1/0 > >> dev.cpu.0.cx_lowest: C1 > >> dev.cpu.0.cx_usage: 100.00% > >> > >> $ sudo kldload /boot/kernel/cpufreq.ko > >> > >> $ sysctl -a | grep dev.cpu > >> dev.cpu.0.%desc: ACPI CPU > >> dev.cpu.0.%driver: cpu > >> dev.cpu.0.%location: handle=\_PR_.CPU0 > >> dev.cpu.0.%pnpinfo: _HID=none _UID=0 > >> dev.cpu.0.%parent: acpi0 > >> dev.cpu.0.cx_supported: C1/0 > >> dev.cpu.0.cx_lowest: C1 > >> dev.cpu.0.cx_usage: 100.00% > >> > >> > >>> Also, since I have sent you that change, I have learned that setting > >>> hw.acpi.thermal.user_override=1 and hw.acpi.thermal.tz0._PSV=85C might > >>> accomplish the same thing as the ASL change. I saw it working for the > >>> thermal zone which already had sensible _PSV, but I have no hardware to > >>> try this approach when _PSV is not present in the ASL. > >> > >> Well, this is a server board, not a laptop, so I'm not sure > >> it even has CPU throttling. > >> > > As far as I can tell from the stuff above -- it does not. I was confused > > by presence of some pieces in the ASL, which would normally indicate > > that it does. One thing, which surprises me, is that with the lack of > > throttling and, what appears to be single speed fan or even a heatsink, > > I do not see how its thermal mode could behave differently in the > > presence of the load. Could you, please, send me output of the sysctl > > machdep. > > $ sysctl machdep > machdep.enable_panic_key: 0 > machdep.adjkerntz: 0 > machdep.wall_cmos_clock: 0 > machdep.disable_rtc_set: 0 > machdep.conspeed: 9600 > machdep.gdbspeed: 9600 > machdep.conrclk: 1843200 > machdep.disable_mtrrs: 0 > machdep.guessed_bootdev: 2687500288 > machdep.cpu_idle_hlt: 1 > machdep.prot_fault_translation: 0 > machdep.panic_on_nmi: 1 > machdep.kdb_on_nmi: 1 > machdep.tsc_freq: 933073074 > machdep.i8254_freq: 1193182 > machdep.acpi_timer_freq: 3579545 > machdep.acpi_root: 1009936 > OK, I give up. The only positive idea so far is that your CPU needed these idle moments (machdep.cpu_idle_hlt: 1) to keep temperature under the critical level. AFAICR 4.x did not know much of anything about ACPI, so it did not exhibit any problems. To check whether this is the hardware issue or that of FreeBSD, you can boot from some recent Linux LiveCD and run 'openssl speed aes -multi 256', or some other CPU-intensive thing of you choice, and 'cat /proc/acpi/thermal_zone/TZC0/temperature' periodically to see whether temperature would raise as rapidly. It might not be a bad idea to do the same (former) thing under FreeBSD to make sure that it does indeed cause thermal shutdown ;) Another (and more dangerous) experiment would be to set hw.acpi.thermal.user_override=1 and hw.acpi.thermal.tz0._CRT=150C and see whether temperature would stabilize at some point above the old _CRT value. This might cost you a CPU, though... And last, but not the least, assuming that your CPU has a heatsink glued on top of it, prying it off, cleaning up both surfaces, applying moderate amounts of something like "Arctic Silver" thermal grease and slapping it back together definitely would not hurt. Even if it would not help. I saw in one of your previous E-mails that you have checked inside the chassis and felt nothing near the reported 100C+, but if this is the temperature of the die under not-to-well-connected heatsink, I do not believe you would have felt it unless you have done it with the heatsink off and your finger on the CPU itself -- something I have not tried since the days of overclocking of 486SX-25 ;) I am sorry I was not able to help. -- Alexandre "Sunny" Kovalenko (Олександр Коваленко) From owner-freebsd-acpi@FreeBSD.ORG Fri Feb 22 02:36:03 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 5178416A400; Fri, 22 Feb 2008 02:36:03 +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 30AC713C4D5; Fri, 22 Feb 2008 02:36:02 +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 <0JWM00E4RCERW1V0@vms173003.mailsrvcs.net>; Thu, 21 Feb 2008 20:32:53 -0600 (CST) Date: Thu, 21 Feb 2008 21:35:36 -0500 From: "Alexandre \"Sunny\" Kovalenko" In-reply-to: To: Ian Smith Message-id: <1203647736.16055.45.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: Cc: freebsd-acpi@freebsd.org, Johannes Dieterich , 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, 22 Feb 2008 02:36:03 -0000 On Thu, 2008-02-21 at 15:48 +1100, Ian Smith wrote: > On Wed, 20 Feb 2008, Johannes Dieterich wrote: > > Hajimu UMEMOTO wrote: > > > Hi, > > > > > >>>>>> On Tue, 19 Feb 2008 00:19:36 +0100 > > >>>>>> Johannes Dieterich said: > > > > > > dieterich.joh> # sysctl hw.acpi.thermal.tz1 > > > dieterich.joh> hw.acpi.thermal.tz1.temperature: 66.0C > > > dieterich.joh> hw.acpi.thermal.tz1.active: -1 > > > dieterich.joh> hw.acpi.thermal.tz1.passive_cooling: 0 > > > dieterich.joh> hw.acpi.thermal.tz1.thermal_flags: 0 > > > dieterich.joh> hw.acpi.thermal.tz1._PSV: 92.5C > > > dieterich.joh> hw.acpi.thermal.tz1._HOT: -1 > > > dieterich.joh> hw.acpi.thermal.tz1._CRT: 97.0C > > > dieterich.joh> hw.acpi.thermal.tz1._ACx: -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 > > > dieterich.joh> hw.acpi.thermal.tz1._TC1: 5 > > > dieterich.joh> hw.acpi.thermal.tz1._TC2: 4 > > > dieterich.joh> hw.acpi.thermal.tz1._TSP: 600 > > > > > > dieterich.joh> is the wanted output without Sunny's patch compiled in. > > > > > > Thank you. It seems good to me. I've tried following setting on my > > > laptop, and it's working well: > > > > > > sysctl hw.acpi.verbose=1 > > > sysctl hw.acpi.thermal.user_override=1 > > > sysctl hw.acpi.thermal.tz0._TC1=5 > > > sysctl hw.acpi.thermal.tz0._TC2=4 > > > sysctl hw.acpi.thermal.tz0._TSP=600 > > > > > and now I start to wonder: that is what happens: > > > > # sysctl hw.acpi.verbose=1 > > hw.acpi.verbose: 0 -> 1 > > # sysctl hw.acpi.thermal.user_override=1 > > hw.acpi.thermal.user_override: 0 -> 1 > > # sysctl hw.acpi.thermal.tz0._TC1=5 > > hw.acpi.thermal.tz0._TC1: -1 -> 5 > > # sysctl hw.acpi.thermal.tz0._TC2=4 > > hw.acpi.thermal.tz0._TC2: -1 -> 4 > > # sysctl hw.acpi.thermal.tz0._TSP=600 > > hw.acpi.thermal.tz0._TSP: -1 -> 600 > > > > Shouldn't that be somewhat different? And I didn't change anything in > > between but rebooting the machine. > > > > > The following was logged into /var/log/messages: > > > > > > Feb 19 11:08:26 kasuga kernel: acpi_tz0: temperature 85.8C: decreasing clock speed from 1200 MHz to 1000 MHz > > > Feb 19 11:09:26 kasuga kernel: acpi_tz0: temperature 82.8C: resuming previous clock speed (1200 MHz) > > > Feb 19 11:10:26 kasuga kernel: acpi_tz0: temperature 86.8C: decreasing clock speed from 1200 MHz to 900 MHz > > > Feb 19 11:11:26 kasuga kernel: acpi_tz0: temperature 79.8C: resuming previous clock speed (1200 MHz) > > > > > still nothing. Completely nothing. > > > > > So, I think the value of _TC1, _TC2 and _TSP is valid. > > > > > > Still, I'm not sure why the above message is not logged on your > > > laptop. But, it would be worth to try increasing _TC2 and/or > > > decreasing _TSP. > > > That might be my next test then. Just wanted to let you know about the > > IMHO strange output above. > > It seems there's some ongoing confusion here between tz0 and tz1. At > least, I know I've been confused :) It turned out, I understand, that > Alexandre's laptop had the same original settings as yours - is it just > the same machine? - and he didn't get any relief until modifying the > passive cooling settings (_PSV, _TC1, _TC2 and _TSP) for tz1, not tz0. My laptop (ThinkPad X60 1709-73U) is similar, but not identical to the one Johannes has. AFAIK, his is ThinkPad X60s, which has slightly slower CPU (1.6GHz Core Duo vs. mine 1.8GHz Core Duo) and slightly smaller (or, for the purpose of this discussion, slightly more densely packed) form factor. This said, I would not expect much, if any difference in any kind of the firmware (BIOS, ASL, etc.) > > Alex said elsewhere that he suspected his tz0 might be the GPU rather > than CPU, or perhaps it's CPU0 but the passive parameters are applied > instead to CPU1, that's still unclear to me, but in either case his > .tz0._CRT also said 127C and his .tz1._PSV was around yours, ie 92.5C. I do not know whether tz0 is the GPU, but overriding passive cooling setting for it on my laptop accomplished precisely nothing. Looking into my ASL, I can also see that tz0 has no _TC1, _TC2 or _TSP values associated with it. Neither it has _PSL, which would normally indicate which device needs to be throttled to achieve passive cooling in this zone. It's _CRT (0x7F) and conditional returns of 0x80 from its _TMP method also suggest that this is unlikely the CPU thermal sensor. Second thermal zone (tz1) has _TC1, _TC2 and _TSP as well as _PSL encompassing both CPU devices. Setting hw.acpi.thermal.tz1.passive_cooling=1 and experimenting with hw.acpi.thermal.tz1._PSV values, I can say that passive cooling in this zone works well. With the patch, Umemoto-san has provided, there is no obvious need to override, but since passive cooling has some hysteresis, and the difference between tz1._PSV and tz1._CRT is only 4.5C, I would recommend lowering tz1._PSV anyway. > Quoting yours from an earlier post: > > > hw.acpi.cpu.cx_lowest: C2 > > hw.acpi.thermal.min_runtime: 0 > > hw.acpi.thermal.polling_rate: 10 > > hw.acpi.thermal.user_override: 0 > > hw.acpi.thermal.tz0.temperature: 62.0C > > hw.acpi.thermal.tz0.active: -1 > > hw.acpi.thermal.tz0.passive_cooling: 0 > > hw.acpi.thermal.tz0.thermal_flags: 0 > > hw.acpi.thermal.tz0._PSV: -1 > > hw.acpi.thermal.tz0._HOT: -1 > > hw.acpi.thermal.tz0._CRT: 127.0C > > hw.acpi.thermal.tz0._ACx: -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 > > hw.acpi.thermal.tz1.temperature: 63.0C > > hw.acpi.thermal.tz1.active: -1 > > hw.acpi.thermal.tz1.passive_cooling: 0 > > hw.acpi.thermal.tz1.thermal_flags: 0 > > hw.acpi.thermal.tz1._PSV: 92.5C > > 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 > > which, I think, is as Alex's was before any .user_override values. > > But above, you showed applying the overrides to tz0, not tz1, perhaps > because Hajimu showed those values applied to _his_ tz0, which would be > right for his (and most) laptops, but not, it seems, Alex's and likely > yours too? > > So could you try applying the .user_override=1, .verbose=1 but those > _PSV, _TC1, _TC2 and _TSP values to tz1 rather than to tz0, and set > .tz1._PSV to some lower value that will be reached, and see if that > works, or makes a difference, doing the expected logging to messages? I would recommend leaving _TC1, _TC2 and _TSP alone for now and only set sysctl hw.acpi.thermal.user_override=1 sysctl hw.acpi.thermal.tz1.passive_cooling=1 sysctl hw.acpi.thermal.tz1._PSV=80C for now. > > cheers, Ian > -- Alexandre "Sunny" Kovalenko (Олександр Коваленко) From owner-freebsd-acpi@FreeBSD.ORG Fri Feb 22 15:57:00 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 21D9016A401; Fri, 22 Feb 2008 15:57:00 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from falcon.cybervisiontech.com (falcon.cybervisiontech.com [217.20.163.9]) by mx1.freebsd.org (Postfix) with ESMTP id 7BAF613C44B; Fri, 22 Feb 2008 15:56:59 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from localhost (localhost [127.0.0.1]) by falcon.cybervisiontech.com (Postfix) with ESMTP id 38D9C43E5B0; Fri, 22 Feb 2008 17:56:57 +0200 (EET) X-Virus-Scanned: Debian amavisd-new at falcon.cybervisiontech.com Received: from falcon.cybervisiontech.com ([127.0.0.1]) by localhost (falcon.cybervisiontech.com [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id La6-LvFfxug6; Fri, 22 Feb 2008 17:56:57 +0200 (EET) Received: from [10.74.70.239] (unknown [193.138.145.53]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by falcon.cybervisiontech.com (Postfix) with ESMTP id C0D7B43CEAD; Fri, 22 Feb 2008 17:56:55 +0200 (EET) Message-ID: <47BEF0C1.5090800@icyb.net.ua> Date: Fri, 22 Feb 2008 17:56:49 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.9 (X11/20071208) MIME-Version: 1.0 To: Nate Lawson References: <47B96989.6070008@icyb.net.ua> <98F7E48C-1CBF-494D-8411-D80E25247214@FreeBSD.org> <47BAF97A.80405@icyb.net.ua> <47BAFB27.1050509@root.org> <47BB2D1F.8000008@icyb.net.ua> In-Reply-To: <47BB2D1F.8000008@icyb.net.ua> Content-Type: multipart/mixed; boundary="------------030404020107030602050006" Cc: freebsd-acpi@freebsd.org Subject: Re: acpi_throttle: quirk based on pci info 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, 22 Feb 2008 15:57:00 -0000 This is a multi-part message in MIME format. --------------030404020107030602050006 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit on 19/02/2008 21:25 Andriy Gapon said the following: >> Andriy Gapon wrote: >>>> On Feb 18, 2008, at 11:18 AM, Andriy Gapon wrote: >>>> >>>>> While looking for something else I accidentally noticed that >>>>> acpi_throttle has one quirk for some early revisions of PIIX4 chipset >>>>> and the quirk is enabled based on PCI info. >>>>> I have a newer revision of PIIX4 so the quirk is not applicable in >>>>> my case. >>>>> >>>>> Nevertheless I noticed that acpi_throttle is initialized before PCI >>>>> bus >>>>> driver, so when it calls pci_find_device() it always returns NULL and >>>>> quirk is not applied. At least this is what I see in dmesg on my >>>>> machine. [snip] >>> I.e. no identify method for acpi bus. >>> Additional device/driver for pci bus. >>> pci probe method checks for duplicates and adds the acpi device as a >>> child to acpi bus. >>> pci probe method sets quirks based on pci info. >>> pci probe method runs device_probe_and_attach on the acpi device. >>> as a consequence acpi probe and attach (for successful probe) are executed. [snip] > I have a bit of a practical interest in it: I have a system based on > PIIX4E (as you already know). Its ACPI FADT specifies duty offset of 1 > and duty width of 1. So, according to FADT only 50% throttling is available. > On the other hand, chipset specification updates for PIIX4E and PIIX4M > say that PCNTRL (P_CNT) register has 3 bits (at offset 1 indeed) for > controlling throttling in 12.5% steps. > So it seems, that acpi_throttle controls only the lowest bit of the > three; moreover, it seems that BIOS assigns some initial value to those > bits. So when throttling is active those bits do not have 001 value > corresponding to 87.5% duty cycle, but have some XX1 value and that > value seems to be 111 (12.5% duty cycle), because the system becomes > extremely slow. > So, as experiment, I hardcoded duty width to 3 and everything works > great - I have 8 throttling steps and system performance seems to really > correspond to expected duty levels. > So now I am thinking about writing a proper patch for this (positive) quirk. Please find attached a patch that makes sure that acpi_thermal is initialized after PCI bus is available, so that it is possible to decide about hardware quirks based on PCI information. The code uses the same approach as ichss does. The patch is tested to work. NOTE: This patch in contaminated! It contains code that forces throttle duty width to be 3 bits for PIIX4E and PIIX4M. This is in accordance with the chipsets specifications. Some motherboard/bios vendors lie about this value in FADT. If not accepted, this quirk can be easily stripped from the patch as its code is contained in distinct hunks. > Reference: > http://www.intel.com/design/chipsets/specupdt/29773817.pdf > -- Andriy Gapon --------------030404020107030602050006 Content-Type: text/x-patch; name="acpi_throttle-piix4-width.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="acpi_throttle-piix4-width.patch" --- acpi_throttle.c.orig 2008-02-21 21:08:28.000000000 +0200 +++ acpi_throttle.c 2008-02-21 21:16:25.000000000 +0200 @@ -80,18 +80,21 @@ (CPU_SPEED_PERCENT(x) % 10) #define CPU_P_CNT_THT_EN (1<<4) #define CPU_QUIRK_NO_THROTTLE (1<<1) /* Throttling is not usable. */ +#define CPU_QUIRK_PIIX4_WIDTH (1<<2) #define PCI_VENDOR_INTEL 0x8086 #define PCI_DEVICE_82371AB_3 0x7113 /* PIIX4 chipset for quirks. */ #define PCI_REVISION_A_STEP 0 #define PCI_REVISION_B_STEP 1 +#define PCI_REVISION_4E 2 +#define PCI_REVISION_4M 3 static uint32_t cpu_duty_offset; /* Offset in P_CNT of throttle val. */ static uint32_t cpu_duty_width; /* Bit width of throttle value. */ static int thr_rid; /* Driver-wide resource id. */ static int thr_quirks; /* Indicate any hardware bugs. */ -static void acpi_throttle_identify(driver_t *driver, device_t parent); +static int acpi_throttle_pci_probe(device_t dev); static int acpi_throttle_probe(device_t dev); static int acpi_throttle_attach(device_t dev); static int acpi_throttle_evaluate(struct acpi_throttle_softc *sc); @@ -104,7 +107,6 @@ static device_method_t acpi_throttle_methods[] = { /* Device interface */ - DEVMETHOD(device_identify, acpi_throttle_identify), DEVMETHOD(device_probe, acpi_throttle_probe), DEVMETHOD(device_attach, acpi_throttle_attach), @@ -125,25 +127,46 @@ static devclass_t acpi_throttle_devclass; DRIVER_MODULE(acpi_throttle, cpu, acpi_throttle_driver, acpi_throttle_devclass, 0, 0); +MODULE_DEPEND(acpi_throttle, acpi, 1, 1, 1); -static void -acpi_throttle_identify(driver_t *driver, device_t parent) +static device_method_t acpi_throttle_pci_methods[] = { + DEVMETHOD(device_probe, acpi_throttle_pci_probe), + {0, 0} +}; + +static driver_t acpi_throttle_pci_driver = { + "acpi_throttle_pci", + acpi_throttle_pci_methods, + 0 +}; + +static devclass_t acpi_throttle_pci_devclass; +DRIVER_MODULE(acpi_throttle_pci, pci, acpi_throttle_pci_driver, + acpi_throttle_pci_devclass, 0, 0); + +static int +acpi_throttle_pci_probe(device_t dev) { ACPI_BUFFER buf; ACPI_HANDLE handle; ACPI_OBJECT *obj; + device_t parent; + device_t child; + + parent = devclass_get_device(devclass_find("acpi"), 0); + KASSERT(parent != NULL, ("acpi parent is NULL")); /* Make sure we're not being doubly invoked. */ if (device_find_child(parent, "acpi_throttle", -1)) - return; + return (ENXIO); /* Check for a valid duty width and parent CPU type. */ handle = acpi_get_handle(parent); if (handle == NULL) - return; + return (ENXIO); if (AcpiGbl_FADT.DutyWidth == 0 || acpi_get_type(parent) != ACPI_TYPE_PROCESSOR) - return; + return (ENXIO); /* * Add a child if there's a non-NULL P_BLK and correct length, or @@ -152,14 +175,18 @@ buf.Pointer = NULL; buf.Length = ACPI_ALLOCATE_BUFFER; if (ACPI_FAILURE(AcpiEvaluateObject(handle, NULL, NULL, &buf))) - return; + return (ENXIO); obj = (ACPI_OBJECT *)buf.Pointer; if ((obj->Processor.PblkAddress && obj->Processor.PblkLength >= 4) || ACPI_SUCCESS(AcpiEvaluateObject(handle, "_PTC", NULL, NULL))) { - if (BUS_ADD_CHILD(parent, 0, "acpi_throttle", -1) == NULL) + child = BUS_ADD_CHILD(parent, 0, "acpi_throttle", -1); + if (child == NULL) device_printf(parent, "add throttle child failed\n"); + else + device_probe_and_attach(child); } AcpiOsFree(obj); + return (ENXIO); } static int @@ -247,6 +274,8 @@ } if (cpu_duty_width == 0 || (thr_quirks & CPU_QUIRK_NO_THROTTLE) != 0) return (ENXIO); + if ((thr_quirks & CPU_QUIRK_PIIX4_WIDTH) != 0) + cpu_duty_width = 3; /* Validate the duty offset/width. */ duty_end = cpu_duty_offset + cpu_duty_width - 1; @@ -333,8 +362,14 @@ case PCI_REVISION_A_STEP: case PCI_REVISION_B_STEP: thr_quirks |= CPU_QUIRK_NO_THROTTLE; + device_printf(sc->cpu_dev, + "throttling is disabled for PIIX4 rev. A/B\n"); break; - default: + case PCI_REVISION_4E: + case PCI_REVISION_4M: + thr_quirks |= CPU_QUIRK_PIIX4_WIDTH; + device_printf(sc->cpu_dev, + "throttling has 12.5%% step for PIIX4E/M\n"); break; } } --------------030404020107030602050006-- From owner-freebsd-acpi@FreeBSD.ORG Fri Feb 22 16:02:30 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 E689F16A400; Fri, 22 Feb 2008 16:02:30 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from falcon.cybervisiontech.com (falcon.cybervisiontech.com [217.20.163.9]) by mx1.freebsd.org (Postfix) with ESMTP id 6C01B13C447; Fri, 22 Feb 2008 16:02:30 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from localhost (localhost [127.0.0.1]) by falcon.cybervisiontech.com (Postfix) with ESMTP id 819E243F99A; Fri, 22 Feb 2008 18:02:29 +0200 (EET) X-Virus-Scanned: Debian amavisd-new at falcon.cybervisiontech.com Received: from falcon.cybervisiontech.com ([127.0.0.1]) by localhost (falcon.cybervisiontech.com [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id pG2Bteft80vS; Fri, 22 Feb 2008 18:02:29 +0200 (EET) Received: from [10.74.70.239] (unknown [193.138.145.53]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by falcon.cybervisiontech.com (Postfix) with ESMTP id 0959E43F783; Fri, 22 Feb 2008 18:02:27 +0200 (EET) Message-ID: <47BEF211.4030608@icyb.net.ua> Date: Fri, 22 Feb 2008 18:02:25 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.9 (X11/20071208) MIME-Version: 1.0 To: Nate Lawson References: <47B96989.6070008@icyb.net.ua> <98F7E48C-1CBF-494D-8411-D80E25247214@FreeBSD.org> <47BAF97A.80405@icyb.net.ua> <47BAFB27.1050509@root.org> <47BB2D1F.8000008@icyb.net.ua> <47BEF0C1.5090800@icyb.net.ua> In-Reply-To: <47BEF0C1.5090800@icyb.net.ua> Content-Type: multipart/mixed; boundary="------------040300070806020408060602" Cc: freebsd-acpi@freebsd.org Subject: Re: acpi_throttle: quirk based on pci info 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, 22 Feb 2008 16:02:31 -0000 This is a multi-part message in MIME format. --------------040300070806020408060602 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit on 22/02/2008 17:56 Andriy Gapon said the following: > Please find attached a patch that makes sure that acpi_thermal is > initialized after PCI bus is available, so that it is possible to decide > about hardware quirks based on PCI information. > The code uses the same approach as ichss does. > The patch is tested to work. Oops! I attached on older version of the patch, sorry. Correct patch is here. (parent of acpi_throttle is cpu, not acpi) > NOTE: This patch in contaminated! It contains code that forces throttle > duty width to be 3 bits for PIIX4E and PIIX4M. This is in accordance > with the chipsets specifications. Some motherboard/bios vendors lie > about this value in FADT. > If not accepted, this quirk can be easily stripped from the patch as its > code is contained in distinct hunks. -- Andriy Gapon --------------040300070806020408060602 Content-Type: text/x-patch; name="acpi_throttle-piix4-width.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="acpi_throttle-piix4-width.patch" --- acpi_throttle.c.orig 2008-02-21 21:08:28.000000000 +0200 +++ acpi_throttle.c 2008-02-21 23:55:25.000000000 +0200 @@ -80,18 +80,21 @@ (CPU_SPEED_PERCENT(x) % 10) #define CPU_P_CNT_THT_EN (1<<4) #define CPU_QUIRK_NO_THROTTLE (1<<1) /* Throttling is not usable. */ +#define CPU_QUIRK_PIIX4_WIDTH (1<<2) #define PCI_VENDOR_INTEL 0x8086 #define PCI_DEVICE_82371AB_3 0x7113 /* PIIX4 chipset for quirks. */ #define PCI_REVISION_A_STEP 0 #define PCI_REVISION_B_STEP 1 +#define PCI_REVISION_4E 2 +#define PCI_REVISION_4M 3 static uint32_t cpu_duty_offset; /* Offset in P_CNT of throttle val. */ static uint32_t cpu_duty_width; /* Bit width of throttle value. */ static int thr_rid; /* Driver-wide resource id. */ static int thr_quirks; /* Indicate any hardware bugs. */ -static void acpi_throttle_identify(driver_t *driver, device_t parent); +static int acpi_throttle_pci_probe(device_t dev); static int acpi_throttle_probe(device_t dev); static int acpi_throttle_attach(device_t dev); static int acpi_throttle_evaluate(struct acpi_throttle_softc *sc); @@ -104,7 +107,6 @@ static device_method_t acpi_throttle_methods[] = { /* Device interface */ - DEVMETHOD(device_identify, acpi_throttle_identify), DEVMETHOD(device_probe, acpi_throttle_probe), DEVMETHOD(device_attach, acpi_throttle_attach), @@ -125,25 +127,46 @@ static devclass_t acpi_throttle_devclass; DRIVER_MODULE(acpi_throttle, cpu, acpi_throttle_driver, acpi_throttle_devclass, 0, 0); +MODULE_DEPEND(acpi_throttle, acpi, 1, 1, 1); -static void -acpi_throttle_identify(driver_t *driver, device_t parent) +static device_method_t acpi_throttle_pci_methods[] = { + DEVMETHOD(device_probe, acpi_throttle_pci_probe), + {0, 0} +}; + +static driver_t acpi_throttle_pci_driver = { + "acpi_throttle_pci", + acpi_throttle_pci_methods, + 0 +}; + +static devclass_t acpi_throttle_pci_devclass; +DRIVER_MODULE(acpi_throttle_pci, pci, acpi_throttle_pci_driver, + acpi_throttle_pci_devclass, 0, 0); + +static int +acpi_throttle_pci_probe(device_t dev) { ACPI_BUFFER buf; ACPI_HANDLE handle; ACPI_OBJECT *obj; + device_t parent; + device_t child; + + parent = devclass_get_device(devclass_find("cpu"), 0); + KASSERT(parent != NULL, ("cpu parent is NULL")); /* Make sure we're not being doubly invoked. */ if (device_find_child(parent, "acpi_throttle", -1)) - return; + return (ENXIO); /* Check for a valid duty width and parent CPU type. */ handle = acpi_get_handle(parent); if (handle == NULL) - return; + return (ENXIO); if (AcpiGbl_FADT.DutyWidth == 0 || acpi_get_type(parent) != ACPI_TYPE_PROCESSOR) - return; + return (ENXIO); /* * Add a child if there's a non-NULL P_BLK and correct length, or @@ -152,14 +175,18 @@ buf.Pointer = NULL; buf.Length = ACPI_ALLOCATE_BUFFER; if (ACPI_FAILURE(AcpiEvaluateObject(handle, NULL, NULL, &buf))) - return; + return (ENXIO); obj = (ACPI_OBJECT *)buf.Pointer; if ((obj->Processor.PblkAddress && obj->Processor.PblkLength >= 4) || ACPI_SUCCESS(AcpiEvaluateObject(handle, "_PTC", NULL, NULL))) { - if (BUS_ADD_CHILD(parent, 0, "acpi_throttle", -1) == NULL) + child = BUS_ADD_CHILD(parent, 0, "acpi_throttle", -1); + if (child == NULL) device_printf(parent, "add throttle child failed\n"); + else + device_probe_and_attach(child); } AcpiOsFree(obj); + return (ENXIO); } static int @@ -247,6 +274,8 @@ } if (cpu_duty_width == 0 || (thr_quirks & CPU_QUIRK_NO_THROTTLE) != 0) return (ENXIO); + if ((thr_quirks & CPU_QUIRK_PIIX4_WIDTH) != 0) + cpu_duty_width = 3; /* Validate the duty offset/width. */ duty_end = cpu_duty_offset + cpu_duty_width - 1; @@ -333,8 +362,14 @@ case PCI_REVISION_A_STEP: case PCI_REVISION_B_STEP: thr_quirks |= CPU_QUIRK_NO_THROTTLE; + device_printf(sc->cpu_dev, + "throttling is disabled for PIIX4 rev. A/B\n"); break; - default: + case PCI_REVISION_4E: + case PCI_REVISION_4M: + thr_quirks |= CPU_QUIRK_PIIX4_WIDTH; + device_printf(sc->cpu_dev, + "throttling has 12.5%% step for PIIX4E/M\n"); break; } } --------------040300070806020408060602-- From owner-freebsd-acpi@FreeBSD.ORG Fri Feb 22 16:05:04 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 9F85216A407; Fri, 22 Feb 2008 16:05:04 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from falcon.cybervisiontech.com (falcon.cybervisiontech.com [217.20.163.9]) by mx1.freebsd.org (Postfix) with ESMTP id 22BDB13C459; Fri, 22 Feb 2008 16:05:04 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from localhost (localhost [127.0.0.1]) by falcon.cybervisiontech.com (Postfix) with ESMTP id E9ED943FA41; Fri, 22 Feb 2008 18:05:02 +0200 (EET) X-Virus-Scanned: Debian amavisd-new at falcon.cybervisiontech.com Received: from falcon.cybervisiontech.com ([127.0.0.1]) by localhost (falcon.cybervisiontech.com [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id ytRs3ICfiOFV; Fri, 22 Feb 2008 18:05:01 +0200 (EET) Received: from [10.74.70.239] (unknown [193.138.145.53]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by falcon.cybervisiontech.com (Postfix) with ESMTP id 4A71B43CEAD; Fri, 22 Feb 2008 18:05:00 +0200 (EET) Message-ID: <47BEF2AA.900@icyb.net.ua> Date: Fri, 22 Feb 2008 18:04:58 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.9 (X11/20071208) MIME-Version: 1.0 To: freebsd-acpi@freebsd.org, freebsd-hackers@freebsd.org References: <479F0ED4.9030709@icyb.net.ua> <479F62D9.6080703@root.org> <47A33CCB.3090902@icyb.net.ua> <47B0C10F.6000109@icyb.net.ua> <47B4103A.6090902@icyb.net.ua> <47B4A103.7040801@icyb.net.ua> <47B4B31A.4020605@icyb.net.ua> <47B84E61.3060401@icyb.net.ua> <47BB375C.5010208@icyb.net.ua> <47BB4D5C.9000406@icyb.net.ua> <47BC7287.6000301@icyb.net.ua> In-Reply-To: <47BC7287.6000301@icyb.net.ua> Content-Type: multipart/mixed; boundary="------------060709010905010700020005" Cc: Subject: Re: cx_lowest and CPU usage 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, 22 Feb 2008 16:05:04 -0000 This is a multi-part message in MIME format. --------------060709010905010700020005 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit on 20/02/2008 20:33 Andriy Gapon said the following: > on 19/02/2008 23:42 Andriy Gapon said the following: >> The last result most probably means that RTC IRQ was not the interrupt >> to wake CPU from sleeping state. >> The first possibility that comes to mind is that on this particular >> hardware RTC interrupt (IRQ8) is not able to wake the system from C2 state. > > So it seems that this was true. > Here's a shortcut to the relevant info: > PIIX4E (FW82371EB) specification > DEVACTB DEVICE ACTIVITY B (FUNCTION 3) pci register description > BRLD_EN_IRQ8, bit 5 > > $ pciconf -r pci0:0:7:3 0x58 > 03040c07 Attached is a patch that fixes the issue for me (without any side-effects) and should not cause any harm for others. -- Andriy Gapon --------------060709010905010700020005 Content-Type: text/x-patch; name="acpi_cpu-piix4-irqs.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="acpi_cpu-piix4-irqs.patch" --- acpi_cpu.c.orig 2008-02-21 21:08:16.000000000 +0200 +++ acpi_cpu.c 2008-02-21 21:13:54.000000000 +0200 @@ -113,6 +113,12 @@ #define PCI_REVISION_B_STEP 1 #define PCI_REVISION_4E 2 #define PCI_REVISION_4M 3 +#define PIIX4_DEVACTB_REG 0x58 +#define PIIX4_BRLD_EN_IRQ0 (1<<0) +#define PIIX4_BRLD_EN_IRQ (1<<1) +#define PIIX4_BRLD_EN_IRQ8 (1<<5) +#define PIIX4_STOP_BREAK_MASK (PIIX4_BRLD_EN_IRQ0 | PIIX4_BRLD_EN_IRQ | PIIX4_BRLD_EN_IRQ8) +#define PIIX4_PCNTRL_BST_EN (1<<10) /* Platform hardware resource information. */ static uint32_t cpu_smi_cmd; /* Value to write to SMI_CMD. */ @@ -1004,6 +1010,7 @@ acpi_cpu_quirks(void) { device_t acpi_dev; + uint32_t val; ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__); @@ -1052,12 +1059,25 @@ * See erratum #18 ("C3 Power State/BMIDE and Type-F DMA * Livelock") from the January 2002 PIIX4 specification update. * Applies to all PIIX4 models. + * + * Also, make sure that all interrupts cause a "Stop Break" + * event to exit from C2 state. */ + case PCI_REVISION_A_STEP: + case PCI_REVISION_B_STEP: case PCI_REVISION_4E: case PCI_REVISION_4M: cpu_quirks |= CPU_QUIRK_NO_C3; ACPI_DEBUG_PRINT((ACPI_DB_INFO, "acpi_cpu: working around PIIX4 bug, disabling C3\n")); + + val = pci_read_config(acpi_dev, PIIX4_DEVACTB_REG, 4); + if ((val & PIIX4_STOP_BREAK_MASK) != PIIX4_STOP_BREAK_MASK) { + ACPI_DEBUG_PRINT((ACPI_DB_INFO, + "PIIX4: enabling IRQs to generate Stop Break\n")); + val |= PIIX4_STOP_BREAK_MASK; + pci_write_config(acpi_dev, PIIX4_DEVACTB_REG, val, 4); + } break; default: break; --------------060709010905010700020005-- From owner-freebsd-acpi@FreeBSD.ORG Fri Feb 22 17:52:59 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 4316B16A402 for ; Fri, 22 Feb 2008 17:52:59 +0000 (UTC) (envelope-from rpaulo@gmail.com) Received: from fk-out-0910.google.com (fk-out-0910.google.com [209.85.128.187]) by mx1.freebsd.org (Postfix) with ESMTP id C127313C448 for ; Fri, 22 Feb 2008 17:52:58 +0000 (UTC) (envelope-from rpaulo@gmail.com) Received: by fk-out-0910.google.com with SMTP id b27so619649fka.11 for ; Fri, 22 Feb 2008 09:52:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:cc:message-id:from:to:in-reply-to:content-type:content-transfer-encoding:mime-version:subject:date:references:x-mailer:sender; bh=erlxXRcRv3Jqyqqvm6mXAqL0P9rM4aGiF4jQQpruAak=; b=XQ3gxd+SY8IhUM/buDxhtcUN7PA74aOfq7UgKDy7vDkSoDxPYdEz7KN0KwPjimmVh7OFolME5f1z2FZL0TNFF9hN1a5Q3u4ev+E3fzkHNfej4VrTBybpyZhXcJ8UNfL/xIT2013PpOd512NBgWoNDjpIxuSFEYiITfanexxnhp0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=cc:message-id:from:to:in-reply-to:content-type:content-transfer-encoding:mime-version:subject:date:references:x-mailer:sender; b=jjHAhtkogDy1yt9J8HOlmPHiIo0XEAHUIfvT9dTaRjVByCL+612pQvemc9cXtX3qZopnWmOoO4QItYNU0gMGCQd9YaTvt9MyBtcv0fAgEj02EJw3MwniG9L/oKo79AiIjxPPT7KFgeS7wi3X0JEaLbUhLksXhFSvsNXzF2jZOr4= Received: by 10.82.113.6 with SMTP id l6mr465809buc.22.1203702776564; Fri, 22 Feb 2008 09:52:56 -0800 (PST) Received: from ?88.214.149.122? ( [88.214.149.122]) by mx.google.com with ESMTPS id p10sm1587572gvf.8.2008.02.22.09.52.53 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 22 Feb 2008 09:52:55 -0800 (PST) Message-Id: <96814C17-2A19-4EA5-89B6-9B9DA55252ED@freebsd.org> From: Rui Paulo To: Andriy Gapon In-Reply-To: <47BEF211.4030608@icyb.net.ua> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v919.2) Date: Fri, 22 Feb 2008 17:52:50 +0000 References: <47B96989.6070008@icyb.net.ua> <98F7E48C-1CBF-494D-8411-D80E25247214@FreeBSD.org> <47BAF97A.80405@icyb.net.ua> <47BAFB27.1050509@root.org> <47BB2D1F.8000008@icyb.net.ua> <47BEF0C1.5090800@icyb.net.ua> <47BEF211.4030608@icyb.net.ua> X-Mailer: Apple Mail (2.919.2) Sender: Rui Paulo Cc: freebsd-acpi@freebsd.org Subject: Re: acpi_throttle: quirk based on pci info 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, 22 Feb 2008 17:52:59 -0000 I'll handle this. Thanks! On Feb 22, 2008, at 4:02 PM, Andriy Gapon wrote: > on 22/02/2008 17:56 Andriy Gapon said the following: >> Please find attached a patch that makes sure that acpi_thermal is >> initialized after PCI bus is available, so that it is possible to >> decide >> about hardware quirks based on PCI information. >> The code uses the same approach as ichss does. >> The patch is tested to work. > > Oops! I attached on older version of the patch, sorry. > Correct patch is here. > (parent of acpi_throttle is cpu, not acpi) > >> NOTE: This patch in contaminated! It contains code that forces >> throttle >> duty width to be 3 bits for PIIX4E and PIIX4M. This is in accordance >> with the chipsets specifications. Some motherboard/bios vendors lie >> about this value in FADT. >> If not accepted, this quirk can be easily stripped from the patch >> as its >> code is contained in distinct hunks. > > > > -- > Andriy Gapon > --- acpi_throttle.c.orig 2008-02-21 21:08:28.000000000 +0200 > +++ acpi_throttle.c 2008-02-21 23:55:25.000000000 +0200 > @@ -80,18 +80,21 @@ > (CPU_SPEED_PERCENT(x) % 10) > #define CPU_P_CNT_THT_EN (1<<4) > #define CPU_QUIRK_NO_THROTTLE (1<<1) /* Throttling is not usable. */ > +#define CPU_QUIRK_PIIX4_WIDTH (1<<2) > > #define PCI_VENDOR_INTEL 0x8086 > #define PCI_DEVICE_82371AB_3 0x7113 /* PIIX4 chipset for quirks. */ > #define PCI_REVISION_A_STEP 0 > #define PCI_REVISION_B_STEP 1 > +#define PCI_REVISION_4E 2 > +#define PCI_REVISION_4M 3 > > static uint32_t cpu_duty_offset; /* Offset in P_CNT of throttle val. > */ > static uint32_t cpu_duty_width; /* Bit width of throttle value. */ > static int thr_rid; /* Driver-wide resource id. */ > static int thr_quirks; /* Indicate any hardware bugs. */ > > -static void acpi_throttle_identify(driver_t *driver, device_t > parent); > +static int acpi_throttle_pci_probe(device_t dev); > static int acpi_throttle_probe(device_t dev); > static int acpi_throttle_attach(device_t dev); > static int acpi_throttle_evaluate(struct acpi_throttle_softc *sc); > @@ -104,7 +107,6 @@ > > static device_method_t acpi_throttle_methods[] = { > /* Device interface */ > - DEVMETHOD(device_identify, acpi_throttle_identify), > DEVMETHOD(device_probe, acpi_throttle_probe), > DEVMETHOD(device_attach, acpi_throttle_attach), > > @@ -125,25 +127,46 @@ > static devclass_t acpi_throttle_devclass; > DRIVER_MODULE(acpi_throttle, cpu, acpi_throttle_driver, > acpi_throttle_devclass, > 0, 0); > +MODULE_DEPEND(acpi_throttle, acpi, 1, 1, 1); > > -static void > -acpi_throttle_identify(driver_t *driver, device_t parent) > +static device_method_t acpi_throttle_pci_methods[] = { > + DEVMETHOD(device_probe, acpi_throttle_pci_probe), > + {0, 0} > +}; > + > +static driver_t acpi_throttle_pci_driver = { > + "acpi_throttle_pci", > + acpi_throttle_pci_methods, > + 0 > +}; > + > +static devclass_t acpi_throttle_pci_devclass; > +DRIVER_MODULE(acpi_throttle_pci, pci, acpi_throttle_pci_driver, > + acpi_throttle_pci_devclass, 0, 0); > + > +static int > +acpi_throttle_pci_probe(device_t dev) > { > ACPI_BUFFER buf; > ACPI_HANDLE handle; > ACPI_OBJECT *obj; > + device_t parent; > + device_t child; > + > + parent = devclass_get_device(devclass_find("cpu"), 0); > + KASSERT(parent != NULL, ("cpu parent is NULL")); > > /* Make sure we're not being doubly invoked. */ > if (device_find_child(parent, "acpi_throttle", -1)) > - return; > + return (ENXIO); > > /* Check for a valid duty width and parent CPU type. */ > handle = acpi_get_handle(parent); > if (handle == NULL) > - return; > + return (ENXIO); > if (AcpiGbl_FADT.DutyWidth == 0 || > acpi_get_type(parent) != ACPI_TYPE_PROCESSOR) > - return; > + return (ENXIO); > > /* > * Add a child if there's a non-NULL P_BLK and correct length, or > @@ -152,14 +175,18 @@ > buf.Pointer = NULL; > buf.Length = ACPI_ALLOCATE_BUFFER; > if (ACPI_FAILURE(AcpiEvaluateObject(handle, NULL, NULL, &buf))) > - return; > + return (ENXIO); > obj = (ACPI_OBJECT *)buf.Pointer; > if ((obj->Processor.PblkAddress && obj->Processor.PblkLength >= 4) || > ACPI_SUCCESS(AcpiEvaluateObject(handle, "_PTC", NULL, NULL))) { > - if (BUS_ADD_CHILD(parent, 0, "acpi_throttle", -1) == NULL) > + child = BUS_ADD_CHILD(parent, 0, "acpi_throttle", -1); > + if (child == NULL) > device_printf(parent, "add throttle child failed\n"); > + else > + device_probe_and_attach(child); > } > AcpiOsFree(obj); > + return (ENXIO); > } > > static int > @@ -247,6 +274,8 @@ > } > if (cpu_duty_width == 0 || (thr_quirks & CPU_QUIRK_NO_THROTTLE) != 0) > return (ENXIO); > + if ((thr_quirks & CPU_QUIRK_PIIX4_WIDTH) != 0) > + cpu_duty_width = 3; > > /* Validate the duty offset/width. */ > duty_end = cpu_duty_offset + cpu_duty_width - 1; > @@ -333,8 +362,14 @@ > case PCI_REVISION_A_STEP: > case PCI_REVISION_B_STEP: > thr_quirks |= CPU_QUIRK_NO_THROTTLE; > + device_printf(sc->cpu_dev, > + "throttling is disabled for PIIX4 rev. A/B\n"); > break; > - default: > + case PCI_REVISION_4E: > + case PCI_REVISION_4M: > + thr_quirks |= CPU_QUIRK_PIIX4_WIDTH; > + device_printf(sc->cpu_dev, > + "throttling has 12.5%% step for PIIX4E/M\n"); > break; > } > } -- Rui Paulo From owner-freebsd-acpi@FreeBSD.ORG Fri Feb 22 17:53:14 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 006C316A404 for ; Fri, 22 Feb 2008 17:53:13 +0000 (UTC) (envelope-from rpaulo@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.158]) by mx1.freebsd.org (Postfix) with ESMTP id 7410713C504 for ; Fri, 22 Feb 2008 17:53:13 +0000 (UTC) (envelope-from rpaulo@gmail.com) Received: by fg-out-1718.google.com with SMTP id 16so379770fgg.35 for ; Fri, 22 Feb 2008 09:53:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:cc:message-id:from:to:in-reply-to:content-type:content-transfer-encoding:mime-version:subject:date:references:x-mailer:sender; bh=9mL7+FRjAvzVc6v5cC6SilYkTXTh0Vxbnjy5TygP+WU=; b=mH37R0w970OM4foWqfX4jLEzkrorumpzrJq4tkiqNL4LLUb5vjcGaCBexKSLFME2wnJIhDb87Am3fkqbiFc53NW/Z9JccmCmdKl9JaRrAh7t8y8E+qpEWJfjjoTy3PFeoIBvbspR00EmwiAosQ2OMy5JOC97CmlaXztQQU1HX5w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=cc:message-id:from:to:in-reply-to:content-type:content-transfer-encoding:mime-version:subject:date:references:x-mailer:sender; b=piJRTsFvdaMs5QSUJBgeapWmWnaeY25VdpS4MDvrBaUj+cN9+XyIZx09FZHVfypVmi7Utjgu5VCDRXtKNx3n3eeugW2m7SM9dSWyoy9B3pm7dulRz0Zit2abs/GZu5bb8as+BdIhbyw2nUgZiQbVuH++6oGjyhnYqslmGJkC4EE= Received: by 10.82.121.15 with SMTP id t15mr513671buc.1.1203702791486; Fri, 22 Feb 2008 09:53:11 -0800 (PST) Received: from ?88.214.149.122? ( [88.214.149.122]) by mx.google.com with ESMTPS id p10sm1587572gvf.8.2008.02.22.09.53.08 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 22 Feb 2008 09:53:10 -0800 (PST) Message-Id: <77122846-92A6-47D2-B94C-3368AF167963@fnop.net> From: Rui Paulo To: Andriy Gapon In-Reply-To: <47BEF2AA.900@icyb.net.ua> Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v919.2) Date: Fri, 22 Feb 2008 17:53:03 +0000 References: <479F0ED4.9030709@icyb.net.ua> <479F62D9.6080703@root.org> <47A33CCB.3090902@icyb.net.ua> <47B0C10F.6000109@icyb.net.ua> <47B4103A.6090902@icyb.net.ua> <47B4A103.7040801@icyb.net.ua> <47B4B31A.4020605@icyb.net.ua> <47B84E61.3060401@icyb.net.ua> <47BB375C.5010208@icyb.net.ua> <47BB4D5C.9000406@icyb.net.ua> <47BC7287.6000301@icyb.net.ua> <47BEF2AA.900@icyb.net.ua> X-Mailer: Apple Mail (2.919.2) Sender: Rui Paulo Cc: freebsd-hackers@freebsd.org, freebsd-acpi@freebsd.org Subject: Re: cx_lowest and CPU usage 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, 22 Feb 2008 17:53:14 -0000 I'll handle this. Thanks! On Feb 22, 2008, at 4:04 PM, Andriy Gapon wrote: > on 20/02/2008 20:33 Andriy Gapon said the following: >> on 19/02/2008 23:42 Andriy Gapon said the following: >>> The last result most probably means that RTC IRQ was not the =20 >>> interrupt >>> to wake CPU from sleeping state. >>> The first possibility that comes to mind is that on this particular >>> hardware RTC interrupt (IRQ8) is not able to wake the system from =20= >>> C2 state. >> >> So it seems that this was true. >> Here's a shortcut to the relevant info: >> PIIX4E (FW82371EB) specification >> DEVACTB =97 DEVICE ACTIVITY B (FUNCTION 3) pci register description >> BRLD_EN_IRQ8, bit 5 >> >> $ pciconf -r pci0:0:7:3 0x58 >> 03040c07 > > Attached is a patch that fixes the issue for me (without any > side-effects) and should not cause any harm for others. > > --=20 > Andriy Gapon > --- acpi_cpu.c.orig 2008-02-21 21:08:16.000000000 +0200 > +++ acpi_cpu.c 2008-02-21 21:13:54.000000000 +0200 > @@ -113,6 +113,12 @@ > #define PCI_REVISION_B_STEP 1 > #define PCI_REVISION_4E 2 > #define PCI_REVISION_4M 3 > +#define PIIX4_DEVACTB_REG 0x58 > +#define PIIX4_BRLD_EN_IRQ0 (1<<0) > +#define PIIX4_BRLD_EN_IRQ (1<<1) > +#define PIIX4_BRLD_EN_IRQ8 (1<<5) > +#define PIIX4_STOP_BREAK_MASK (PIIX4_BRLD_EN_IRQ0 | =20 > PIIX4_BRLD_EN_IRQ | PIIX4_BRLD_EN_IRQ8) > +#define PIIX4_PCNTRL_BST_EN (1<<10) > > /* Platform hardware resource information. */ > static uint32_t cpu_smi_cmd; /* Value to write to = SMI_CMD. */ > @@ -1004,6 +1010,7 @@ > acpi_cpu_quirks(void) > { > device_t acpi_dev; > + uint32_t val; > > ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__); > > @@ -1052,12 +1059,25 @@ > * See erratum #18 ("C3 Power State/BMIDE and Type-F DMA > * Livelock") from the January 2002 PIIX4 specification update. > * Applies to all PIIX4 models. > + * > + * Also, make sure that all interrupts cause a "Stop Break" > + * event to exit from C2 state. > */ > + case PCI_REVISION_A_STEP: > + case PCI_REVISION_B_STEP: > case PCI_REVISION_4E: > case PCI_REVISION_4M: > cpu_quirks |=3D CPU_QUIRK_NO_C3; > ACPI_DEBUG_PRINT((ACPI_DB_INFO, > "acpi_cpu: working around PIIX4 bug, disabling C3\n")); > + > + val =3D pci_read_config(acpi_dev, PIIX4_DEVACTB_REG, 4); > + if ((val & PIIX4_STOP_BREAK_MASK) !=3D = PIIX4_STOP_BREAK_MASK) { > + ACPI_DEBUG_PRINT((ACPI_DB_INFO, > + "PIIX4: enabling IRQs to generate Stop Break\n")); > + val |=3D PIIX4_STOP_BREAK_MASK; > + pci_write_config(acpi_dev, PIIX4_DEVACTB_REG, val, 4); > + } > break; > default: > break; > _______________________________________________ > freebsd-acpi@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-acpi > To unsubscribe, send any mail to "freebsd-acpi-=20 > unsubscribe@freebsd.org" -- Rui Paulo From owner-freebsd-acpi@FreeBSD.ORG Fri Feb 22 20:04:18 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 4CC0216A403; Fri, 22 Feb 2008 20:04:18 +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 2F83313C4DB; Fri, 22 Feb 2008 20:04:18 +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 m1MK4IkE005226; Fri, 22 Feb 2008 20:04:18 GMT (envelope-from remko@freefall.freebsd.org) Received: (from remko@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m1MK4IFP005222; Fri, 22 Feb 2008 20:04:18 GMT (envelope-from remko) Date: Fri, 22 Feb 2008 20:04:18 GMT Message-Id: <200802222004.m1MK4IFP005222@freefall.freebsd.org> To: remko@FreeBSD.org, freebsd-i386@FreeBSD.org, freebsd-acpi@FreeBSD.org From: remko@FreeBSD.org Cc: Subject: Re: kern/120953: [acpi]: FreeBSD 6.3 Release: acpi_tz0: _TMP value is absurd, ignored (-73.0C) 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, 22 Feb 2008 20:04:18 -0000 Old Synopsis: FreeBSD 6.3 Release: acpi_tz0: _TMP value is absurd, ignored (-73.0C) New Synopsis: [acpi]: FreeBSD 6.3 Release: acpi_tz0: _TMP value is absurd, ignored (-73.0C) Responsible-Changed-From-To: freebsd-i386->freebsd-acpi Responsible-Changed-By: remko Responsible-Changed-When: Fri Feb 22 20:03:58 UTC 2008 Responsible-Changed-Why: reassign to acpi team http://www.freebsd.org/cgi/query-pr.cgi?pr=120953 From owner-freebsd-acpi@FreeBSD.ORG Fri Feb 22 22:08:13 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 017B016A400 for ; Fri, 22 Feb 2008 22:08:13 +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 C6F3D13C442 for ; Fri, 22 Feb 2008 22:08:12 +0000 (UTC) (envelope-from nate@root.org) Received: (qmail 1582 invoked from network); 22 Feb 2008 22:08:13 -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; 22 Feb 2008 22:08:13 -0000 Message-ID: <47BF47C7.3010107@root.org> Date: Fri, 22 Feb 2008 14:08:07 -0800 From: Nate Lawson User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Andriy Gapon References: <47B96989.6070008@icyb.net.ua> <98F7E48C-1CBF-494D-8411-D80E25247214@FreeBSD.org> <47BAF97A.80405@icyb.net.ua> <47BAFB27.1050509@root.org> <47BB2D1F.8000008@icyb.net.ua> <47BEF0C1.5090800@icyb.net.ua> <47BEF211.4030608@icyb.net.ua> In-Reply-To: <47BEF211.4030608@icyb.net.ua> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@freebsd.org Subject: Re: acpi_throttle: quirk based on pci info 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, 22 Feb 2008 22:08:13 -0000 Andriy Gapon wrote: > on 22/02/2008 17:56 Andriy Gapon said the following: >> Please find attached a patch that makes sure that acpi_thermal is >> initialized after PCI bus is available, so that it is possible to decide >> about hardware quirks based on PCI information. >> The code uses the same approach as ichss does. >> The patch is tested to work. > > Oops! I attached on older version of the patch, sorry. > Correct patch is here. > (parent of acpi_throttle is cpu, not acpi) > >> NOTE: This patch in contaminated! It contains code that forces throttle >> duty width to be 3 bits for PIIX4E and PIIX4M. This is in accordance >> with the chipsets specifications. Some motherboard/bios vendors lie >> about this value in FADT. >> If not accepted, this quirk can be easily stripped from the patch as its >> code is contained in distinct hunks. I'm going to think about this a little before saying it should be committed in current form. The C2 fix is fine. Thanks, -- Nate From owner-freebsd-acpi@FreeBSD.ORG Sat Feb 23 03:04: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 5010D16A406; Sat, 23 Feb 2008 03:04:03 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 24E8C13C4F2; Sat, 23 Feb 2008 03:04:03 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (linimon@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m1N34377040413; Sat, 23 Feb 2008 03:04:03 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m1N342Br040409; Sat, 23 Feb 2008 03:04:02 GMT (envelope-from linimon) Date: Sat, 23 Feb 2008 03:04:02 GMT Message-Id: <200802230304.m1N342Br040409@freefall.freebsd.org> To: nollan@phreaker.net, linimon@FreeBSD.org, freebsd-acpi@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: i386/119485: [hang] 6.3 RC2 boot only CD hangs in dell d830 - 'ACPI autoload failed' 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, 23 Feb 2008 03:04:03 -0000 Synopsis: [hang] 6.3 RC2 boot only CD hangs in dell d830 - 'ACPI autoload failed' State-Changed-From-To: open->feedback State-Changed-By: linimon State-Changed-When: Sat Feb 23 03:01:22 UTC 2008 State-Changed-Why: Submitter was asked for feedback by Dylan Cochran on IRC. http://www.freebsd.org/cgi/query-pr.cgi?pr=119485 From owner-freebsd-acpi@FreeBSD.ORG Sat Feb 23 04:10:04 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 A7AA516A404 for ; Sat, 23 Feb 2008 04:10:04 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 905D413C459 for ; Sat, 23 Feb 2008 04:10:04 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m1N4A4i8046753 for ; Sat, 23 Feb 2008 04:10:04 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m1N4A40t046741; Sat, 23 Feb 2008 04:10:04 GMT (envelope-from gnats) Date: Sat, 23 Feb 2008 04:10:04 GMT Message-Id: <200802230410.m1N4A40t046741@freefall.freebsd.org> To: freebsd-acpi@FreeBSD.org From: Sean Bruno Cc: Subject: Re: kern/120953: [acpi]: FreeBSD 6.3 Release: acpi_tz0: _TMP value is absurd, ignored (-73.0C) X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Sean Bruno List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Feb 2008 04:10:04 -0000 The following reply was made to PR kern/120953; it has been noted by GNATS. From: Sean Bruno To: bug-followup@FreeBSD.org, ericnk@esreco.net Cc: Subject: Re: kern/120953: [acpi]: FreeBSD 6.3 Release: acpi_tz0: _TMP value is absurd, ignored (-73.0C) Date: Fri, 22 Feb 2008 20:01:55 -0800 I have the same issue with a similar Shuttle machine and posted about it here: http://groups.google.com/group/lucky.freebsd.acpi/browse_thread/thread/c7e757e7440405db/b6fc147d66666e41 Essentially, the shuttle ACPI implementation is broken and I don't know if they are going to do anything about it. Linux has the same problems here. Sean From owner-freebsd-acpi@FreeBSD.ORG Sat Feb 23 14:38:16 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 C859E16A401; Sat, 23 Feb 2008 14:38:16 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 98A0A13C467; Sat, 23 Feb 2008 14:38:16 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (linimon@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m1NEcGQv004449; Sat, 23 Feb 2008 14:38:16 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m1NEcGwJ004445; Sat, 23 Feb 2008 14:38:16 GMT (envelope-from linimon) Date: Sat, 23 Feb 2008 14:38:16 GMT Message-Id: <200802231438.m1NEcGwJ004445@freefall.freebsd.org> To: nollan@phreaker.net, linimon@FreeBSD.org, freebsd-acpi@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: i386/119485: [hang] 6.3 RC2 boot only CD hangs in dell d830 - 'ACPI autoload failed' 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, 23 Feb 2008 14:38:16 -0000 Synopsis: [hang] 6.3 RC2 boot only CD hangs in dell d830 - 'ACPI autoload failed' State-Changed-From-To: feedback->closed State-Changed-By: linimon State-Changed-When: Sat Feb 23 14:37:52 UTC 2008 State-Changed-Why: Submitter notes that this was an issue caused by a bad burn. http://www.freebsd.org/cgi/query-pr.cgi?pr=119485