From owner-freebsd-acpi@FreeBSD.ORG Sun Aug 7 20:15:54 2005 Return-Path: X-Original-To: freebsd-acpi@freebsd.org Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4DE3D16A41F for ; Sun, 7 Aug 2005 20:15:54 +0000 (GMT) (envelope-from oberman@es.net) Received: from postal2.es.net (postal2.es.net [198.128.3.206]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0D0CF441C2 for ; Sun, 7 Aug 2005 20:15:54 +0000 (GMT) (envelope-from oberman@es.net) Received: from ptavv.es.net ([198.128.4.29]) by postal2.es.net (Postal Node 2) with ESMTP (SSL) id IBA74465; Sun, 07 Aug 2005 13:15:52 -0700 Received: from ptavv (localhost [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id 8D6975D07; Sun, 7 Aug 2005 13:15:52 -0700 (PDT) To: Tijl Coosemans In-reply-to: Your message of "Tue, 02 Aug 2005 00:22:02 +0200." <200508020022.02992.tijl@ulyssis.org> Date: Sun, 07 Aug 2005 13:15:52 -0700 From: "Kevin Oberman" Message-Id: <20050807201552.8D6975D07@ptavv.es.net> Cc: freebsd-acpi@freebsd.org Subject: Re: 5-STABLE cpufreq hotter than est from ports 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, 07 Aug 2005 20:15:54 -0000 > From: Tijl Coosemans > Date: Tue, 2 Aug 2005 00:22:02 +0200 > Sender: owner-freebsd-stable@freebsd.org > > A couple days ago I updated my system and was excited to see cpufreq > and powerd in 5-stable. Since then however I noticed that my laptop > temperature is about 5°C higher than with est and estctrl. I found that > cpufreq when setting 200MHz for example set the absolute frequency to > 1600MHz (max for this laptop) and the relative frequency (p4tcc) to > 12.5% instead of using a more power conserving setting like 800MHz/25%. > > The problem is that cpufreq_expand_set() (sys/kern/kern_cpu.c) > traverses freq levels from high to low when adding relative levels and > skips duplicates. When it wants to add 800MHz/25% it sees this setting > as a duplicate of 1600MHz/12.5% it has found before. This can be fixed > by letting cpufreq_expand_set() traverse freq levels in reverse order > (and still skipping duplicates). Then each frequency level has the > lowest possible absolute setting. This is a one line change in > sys/kern/kern_cpu.c (line 653). > > --- sys/kern/kern_cpu.c.orig Mon Aug 1 14:42:26 2005 > +++ sys/kern/kern_cpu.c Mon Aug 1 15:17:55 2005 > @@ -650,7 +650,7 @@ > > CF_MTX_ASSERT(&sc->lock); > > - TAILQ_FOREACH(search, &sc->all_levels, link) { > + TAILQ_FOREACH_REVERSE(search, &sc->all_levels, cf_level_lst, link) { > /* Skip this level if we've already modified it. */ > for (i = 0; i < search->rel_count; i++) { > if (search->rel_set[i].dev == set_arr->sets[0].> dev) > > With this patch temperature is almost as low as with est again (only > 1°C hotter). However, there are still such levels like 1400/12.5 > (175MHz) which are lower than let's say 600/37.5 (225MHz), but consume > a lot more power. On my laptop this problem doesn't really occur > because of the way powerd works, only the absolute levels 1600, 800 and > 600 are ever used. I can imagine somebody with a 1700MHz cpu not being > so lucky though. So, I've worked out a patch (attached) that makes sure > that a lower frequency level has at most the same absolute setting > (preferably less of course). This eliminates quite a few levels so > somebody with a better knowledge of cpufreq should check if this patch > really does something good. This is the first time I've taken a look at > FreeBSD source code by the way. > > Also, somewhat related, the p4tcc driver doesn't recognise > acpi_throttle, which means that when you load the cpufreq module after > booting, the freq levels are messed up. I'm not sure what the best > solution for this is. Let p4tcc detect acpi_throttle and don't attach > if it's present (like acpi_throttle does now if it finds p4tcc) or > detach it before attaching? Or maybe p4tcc and acpi_throttle should be > merged into one driver? > > Finally, is the kernel config option CPU_ENABLE_TCC still relevant? > Because it's still listed in NOTES. Tijl, Thanks so much for doing this work. I had done exactly the same sort of testing and found the same issues, but ave not had time to track down the kernel changes required to fix them. And I DO see both problems. I have a P4m with ICHSS and P4TCC and I do hit both the problem of the wrong mode being selected when there is a tie for performance level and the case of lower performance resulting in higher power consumption. You can see the results of my testing in messages to freebsd-acpi@ archives. I have been wanting to write some patches to fix the problems, but have simply not had time, so these patches look great! I run -current on my laptop, so I may have to make adjustments to your patches, but I m sure that you have saved me a lot of time in any case. Could you please be sure to copy ducrot@ with these messages? He and Nate are the primary author of the code involved and can get it into the system. In the future you should probably send these reports to freebsd-acpi@. That's where most of the work on this sort of thing is done. (Yes, I realize that this is not technically ACPI stuff, but it is all tied to ACPI capabilities.) To take a stab at your questions: First, if P4TCC is available, it should be used and CPU throttling should be disabled. This is because P4TCC does better than CPU throttle, but really does the exact same thing. The results of my testing of P4TCC vs. throttling are also in the archives of freebsd-acpi@. I have not seen any problem with this. Could you describe exactly whet behavior you are seeing? I am pretty sure that 'option CPU_TCC_ENABLE' is obsolete. It's gone from V6 and current. I suspect that it was missed when the CPU power management stuff was MFCed to V5. Please drop freebsd-acpi@ a note so this can be fixed. finally, you might want to subscribe to freebsd-acpi@. It's fairly low volume, but covers pretty much all of the work being done in this area. (By fairly low, I mean it averages around 3 or 4 messages a day. Again, thanks for the patches! -- 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 From owner-freebsd-acpi@FreeBSD.ORG Mon Aug 8 11:01:47 2005 Return-Path: X-Original-To: freebsd-acpi@freebsd.org Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B740A16A41F for ; Mon, 8 Aug 2005 11:01:47 +0000 (GMT) (envelope-from owner-bugmaster@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7F62343D46 for ; Mon, 8 Aug 2005 11:01:47 +0000 (GMT) (envelope-from owner-bugmaster@freebsd.org) Received: from freefall.freebsd.org (peter@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.3/8.13.3) with ESMTP id j78B1l5N006718 for ; Mon, 8 Aug 2005 11:01:47 GMT (envelope-from owner-bugmaster@freebsd.org) Received: (from peter@localhost) by freefall.freebsd.org (8.13.3/8.13.1/Submit) id j78B1kYb006712 for freebsd-acpi@freebsd.org; Mon, 8 Aug 2005 11:01:46 GMT (envelope-from owner-bugmaster@freebsd.org) Date: Mon, 8 Aug 2005 11:01:46 GMT Message-Id: <200508081101.j78B1kYb006712@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: peter set sender to owner-bugmaster@freebsd.org using -f From: FreeBSD bugmaster To: freebsd-acpi@FreeBSD.org Cc: Subject: Current problem reports assigned to you 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, 08 Aug 2005 11:01:47 -0000 Current FreeBSD problem reports Critical problems Serious problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2003/07/22] i386/54756 acpi ACPI suspend/resume problem on CF-W2 lapt o [2003/08/17] i386/55661 acpi ACPI suspend/resume problem on ARMADA M70 o [2003/08/20] kern/55822 acpi No ACPI power off with SMP kernel o [2003/08/27] kern/56024 acpi ACPI suspend drains battery while in S3 o [2003/09/03] i386/56372 acpi acpi don't work on TYAN tiger100 M/B o [2004/03/09] i386/64002 acpi acpi problem o [2004/05/27] i386/67273 acpi [hang] system hangs with acpi and Xfree o [2004/10/12] i386/72566 acpi ACPI, FreeBSD disables fan on Compaq Arma o [2005/03/21] i386/79080 acpi acpi thermal changes freezes HP nx6110 o [2005/03/21] i386/79081 acpi ACPI suspend/resume not working on HP nx6 10 problems total. Non-critical problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2004/03/17] kern/64365 acpi ACPI problems o [2004/05/28] kern/67309 acpi zzz reboot computer (ACPI S3) o [2004/07/29] i386/69750 acpi Boot without ACPI failed on ASUS L5 o [2004/11/11] i386/73822 acpi [request] add thermal support to ACPI o [2004/11/11] kern/73823 acpi acpi / power-on by timer support o [2004/11/17] kern/74030 acpi Unplugging AC causes battery % to stay lo o [2004/11/21] kern/74215 acpi [request] add ACPI headers to /usr/includ o [2005/05/09] kern/80815 acpi ACPI(pci_link) problem in 5.4-STABLE: TIM 8 problems total. From owner-freebsd-acpi@FreeBSD.ORG Mon Aug 8 14:18:23 2005 Return-Path: X-Original-To: freebsd-acpi@freebsd.org Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2438B16A41F for ; Mon, 8 Aug 2005 14:18:23 +0000 (GMT) (envelope-from tijl@ulyssis.org) Received: from outmx023.isp.belgacom.be (outmx023.isp.belgacom.be [195.238.2.204]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7939943D46; Mon, 8 Aug 2005 14:18:16 +0000 (GMT) (envelope-from tijl@ulyssis.org) Received: from outmx023.isp.belgacom.be (localhost [127.0.0.1]) by outmx023.isp.belgacom.be (8.12.11/8.12.11/Skynet-OUT-2.22) with ESMTP id j78EIBAS011909; Mon, 8 Aug 2005 16:18:12 +0200 (envelope-from ) Received: from kalimero.kotnet.org (117-122.247.81.adsl.skynet.be [81.247.122.117]) by outmx023.isp.belgacom.be (8.12.11/8.12.11/Skynet-OUT-2.22) with ESMTP id j78EI2Yk011820; Mon, 8 Aug 2005 16:18:03 +0200 (envelope-from ) Received: from kalimero.kotnet.org (kalimero.kotnet.org [127.0.0.1]) by kalimero.kotnet.org (8.13.3/8.13.3) with ESMTP id j78EI1m6057761; Mon, 8 Aug 2005 16:18:02 +0200 (CEST) (envelope-from tijl@ulyssis.org) From: Tijl Coosemans To: freebsd-acpi@freebsd.org Date: Mon, 8 Aug 2005 16:18:00 +0200 User-Agent: KMail/1.8.1 References: <20050807201552.8D6975D07@ptavv.es.net> In-Reply-To: <20050807201552.8D6975D07@ptavv.es.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200508081618.01362.tijl@ulyssis.org> Cc: ducrot@freebsd.org Subject: Re: 5-STABLE cpufreq hotter than est from ports 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, 08 Aug 2005 14:18:23 -0000 Kevin, Thanks for your reply. I was beginning to think I sent my mail to the wrong list. I've subscribed to freebsd-acpi@ now. For reference, the issues (+patch) discussed are available at: http://lists.freebsd.org/pipermail/freebsd-stable/2005-August/017535.html http://lists.freebsd.org/pipermail/freebsd-stable/2005-August/017536.html > I have a P4m with ICHSS and P4TCC and I do hit both the problem of the > wrong mode being selected when there is a tie for performance level > and the case of lower performance resulting in higher power > consumption. You can see the results of my testing in messages to > freebsd-acpi@ archives. I have been wanting to write some patches to > fix the problems, but have simply not had time, so these patches look > great! In my experience throttling doesn't really gain that much. There's almost no difference between running at 600MHz/100% and 600MHz/12.5%, except that it is 8 times slower, so I've set debug.cpufreq.lowest to 400 to limit the performance drop. I've also slightly modified powerd to not jump to the maximum frequency, but to step up one level at a time to save energy. I've been thinking, since throttling doesn't gain much, it might be better for powerd to use only absolute settings when stepping up, but that would require an extra sysctl entry (dev.cpu.0.freq_abs or something). All this together with the patch above gives me a good desktop experience. It's not too slow and it doesn't consume much power either. Of course, other users might prefer different power profiles. > To take a stab at your questions: > First, if P4TCC is available, it should be used and CPU throttling > should be disabled. This is because P4TCC does better than CPU > throttle, but really does the exact same thing. The results of my > testing of P4TCC vs. throttling are also in the archives of > freebsd-acpi@. > > I have not seen any problem with this. Could you describe exactly > whet behavior you are seeing? Currently, acpi_throttle (driver) doesn't attach when it finds p4tcc0 (device), but p4tcc (driver) always attaches even if acpi_throttle0 (device) is present. As I understand things, both do exactly the same (but in a different way), so they shouldn't both be enabled at the same time. You can get in this situation by not loading cpufreq.ko through loader.conf (so acpi_throttle attaches) and then kldload it later. If p4tcc is prefered, I suppose it should find acpi_throttle0 and detach it (or maybe acpi_throttle should become part of cpufreq.ko). > I am pretty sure that 'option CPU_TCC_ENABLE' is obsolete. It's gone > from V6 and current. I suspect that it was missed when the CPU power > management stuff was MFCed to V5. Please drop freebsd-acpi@ a note so > this can be fixed. I've found references in the following files. There may be more of course. sys/conf/files.i386 (line 258) sys/conf/options.i386 (line 56) sys/i386/conf/NOTES (line 133 + line 215). sys/i386/i386/p4tcc.c (can be removed?) From owner-freebsd-acpi@FreeBSD.ORG Mon Aug 8 18:03:48 2005 Return-Path: X-Original-To: freebsd-acpi@freebsd.org Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5757E16A41F for ; Mon, 8 Aug 2005 18:03:48 +0000 (GMT) (envelope-from oberman@es.net) Received: from postal2.es.net (postal2.es.net [198.128.3.206]) by mx1.FreeBSD.org (Postfix) with ESMTP id F13D243D45; Mon, 8 Aug 2005 18:03:47 +0000 (GMT) (envelope-from oberman@es.net) Received: from ptavv.es.net ([198.128.4.29]) by postal2.es.net (Postal Node 2) with ESMTP (SSL) id IBA74465; Mon, 08 Aug 2005 11:03:46 -0700 Received: from ptavv (localhost [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id CABF35D08; Mon, 8 Aug 2005 11:03:45 -0700 (PDT) X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.0.4 To: Tijl Coosemans In-reply-to: Your message of "Mon, 08 Aug 2005 16:18:00 +0200." <200508081618.01362.tijl@ulyssis.org> Mime-Version: 1.0 Content-Type: multipart/mixed ; boundary="==_Exmh_1123524209_272550" Date: Mon, 08 Aug 2005 11:03:45 -0700 From: "Kevin Oberman" Message-Id: <20050808180345.CABF35D08@ptavv.es.net> Cc: freebsd-acpi@freebsd.org, ducrot@freebsd.org Subject: Re: 5-STABLE cpufreq hotter than est from ports 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, 08 Aug 2005 18:03:48 -0000 This is a multipart MIME message. --==_Exmh_1123524209_272550 Content-Type: text/plain; charset=us-ascii > From: Tijl Coosemans > Date: Mon, 8 Aug 2005 16:18:00 +0200 > > Kevin, > > Thanks for your reply. I was beginning to think I sent my mail to the > wrong list. I've subscribed to freebsd-acpi@ now. For reference, the > issues (+patch) discussed are available at: > > http://lists.freebsd.org/pipermail/freebsd-stable/2005-August/017535.html > http://lists.freebsd.org/pipermail/freebsd-stable/2005-August/017536.html > > > I have a P4m with ICHSS and P4TCC and I do hit both the problem of the > > wrong mode being selected when there is a tie for performance level > > and the case of lower performance resulting in higher power > > consumption. You can see the results of my testing in messages to > > freebsd-acpi@ archives. I have been wanting to write some patches to > > fix the problems, but have simply not had time, so these patches look > > great! > > In my experience throttling doesn't really gain that much. There's > almost no difference between running at 600MHz/100% and 600MHz/12.5%, > except that it is 8 times slower, so I've set debug.cpufreq.lowest to > 400 to limit the performance drop. Odd. I don't see that at all. I am running at either 1.8 GHz or 1.2 GHz and the performance ramps almost in lock-step with the setting and power consumption does, as well. Without your patch, using the values of dev.cpu.0.freq that run the CPU at the slower speed (1.2 GHz), I get the following: dev.cpu.0.freq Temp. Savings 1200 73 1050 69 5.5% 750 64 12.3% 600 62 15.1% 300 58 20.5% 150 54 25.0% The lowest 1.8 GHz value (1350) results in 85.I find these power savings to be significant. I test performance with: dd bs=1m count=100 if=/dev/zero | md5 This should be totally CPU bound as the only I/O is from /dev/zero. I report the number of bytes/second processed. I have a small perl script that I use for this. (I will attach it.) For power consumption I run the CPU at 100% until the CPU temperature stabilizes. I realize that this is only an approximation of power consumption, but I think it's close enough. > I've also slightly modified powerd to not jump to the maximum frequency, > but to step up one level at a time to save energy. I've been thinking, > since throttling doesn't gain much, it might be better for powerd to > use only absolute settings when stepping up, but that would require an > extra sysctl entry (dev.cpu.0.freq_abs or something). I have long espoused a different adaptive algorithm and use a "down by 1/up by 2" algorithm, myself. I wrote my own patch, but phk has posted a cleaner one to current. See http://lists.freebsd.org/mailman/htdig/freebsd-current/2005-April/048877.html > All this together with the patch above gives me a good desktop > experience. It's not too slow and it doesn't consume much power either. > Of course, other users might prefer different power profiles. Very true, and the desired profile for a given user might well change with a different situation (e.g. when on a long flight). > > To take a stab at your questions: > > First, if P4TCC is available, it should be used and CPU throttling > > should be disabled. This is because P4TCC does better than CPU > > throttle, but really does the exact same thing. The results of my > > testing of P4TCC vs. throttling are also in the archives of > > freebsd-acpi@. > > > > I have not seen any problem with this. Could you describe exactly > > whet behavior you are seeing? > > Currently, acpi_throttle (driver) doesn't attach when it finds p4tcc0 > (device), but p4tcc (driver) always attaches even if acpi_throttle0 > (device) is present. As I understand things, both do exactly the same > (but in a different way), so they shouldn't both be enabled at the same > time. This is correct and is the designed behavior. TCC is a throttling system that is internal to the CPU while throttling is externally controlled. Testing shows that TCC works better than throttling. It's more linear and provides better power reduction at a specified performance level in most cases (never worse, but sometime equal). > You can get in this situation by not loading cpufreq.ko through > loader.conf (so acpi_throttle attaches) and then kldload it later. If > p4tcc is prefered, I suppose it should find acpi_throttle0 and detach > it (or maybe acpi_throttle should become part of cpufreq.ko). Ahh. I don't think that I have ever tried this. > > > I am pretty sure that 'option CPU_TCC_ENABLE' is obsolete. It's gone > > from V6 and current. I suspect that it was missed when the CPU power > > management stuff was MFCed to V5. Please drop freebsd-acpi@ a note so > > this can be fixed. > > I've found references in the following files. There may be more of > course. > > sys/conf/files.i386 (line 258) > sys/conf/options.i386 (line 56) > sys/i386/conf/NOTES (line 133 + line 215). > sys/i386/i386/p4tcc.c (can be removed?) I don't know if the merge from current should have included these. I can now confirm that the patch applied cleanly to -current and works as advertised. I have only done performance testing at this time. Testing for power consumption takes quite a bit longer and I have a day job stuff that will prevent testing for a while. Thanks again, -- 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 --==_Exmh_1123524209_272550 Content-Type: text/plain ; name="test-speed"; charset=us-ascii Content-Description: test-speed Content-Disposition: attachment; filename="test-speed" #!/usr/bin/perl $min_speed = 150; ($freq) = `sysctl dev.cpu.0.freq_levels`; @freq = split ' ', $freq; @freq = grep /\d+\/-?\d+/, @freq; foreach (@freq) {s/^(\d+).+$/$1/;} foreach (@freq) { # if ($_ < $min_speed) {next;} `sysctl dev.cpu.0.freq=$_`; `dd if=/dev/zero bs=1m count=100 2>/tmp/testresult | md5`; @result = `cat /tmp/testresult`; $result = $result[2]; $result =~ /secs \((\d+) bytes\/sec/; printf "%4d %s\n", $_, $1; } # Now do it backwards (speed up) for ($i=$#freq; $i>=0; $i--) { # if ($freq[$i] < $min_speed) {next;} `sysctl dev.cpu.0.freq=$freq[$i]`; `dd if=/dev/zero bs=1m count=100 2>/tmp/testresult | md5`; @result = `cat /tmp/testresult`; $result = $result[2]; $result =~ /secs \((\d+) bytes\/sec/; printf "%4d %s\n", $freq[$i], $1; } `sysctl dev.cpu.0.freq=1800`; unlink "/tmp/testresult"; exit; --==_Exmh_1123524209_272550-- From owner-freebsd-acpi@FreeBSD.ORG Mon Aug 8 22:53:55 2005 Return-Path: X-Original-To: acpi@FreeBSD.org Delivered-To: freebsd-acpi@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EDC8816A41F; Mon, 8 Aug 2005 22:53:55 +0000 (GMT) (envelope-from nate@root.org) Received: from www.cryptography.com (li-22.members.linode.com [64.5.53.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9ED9943D46; Mon, 8 Aug 2005 22:53:55 +0000 (GMT) (envelope-from nate@root.org) Received: from [10.0.5.50] (adsl-64-171-187-230.dsl.snfc21.pacbell.net [64.171.187.230]) by www.cryptography.com (8.12.8/8.12.8) with ESMTP id j78Mrqo5028030 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 8 Aug 2005 15:53:56 -0700 Message-ID: <42F7E27E.9090302@root.org> Date: Mon, 08 Aug 2005 15:53:50 -0700 From: Nate Lawson User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tijl Coosemans References: <200508020022.02992.tijl@ulyssis.org> In-Reply-To: <200508020022.02992.tijl@ulyssis.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: acpi@FreeBSD.org Subject: Re: 5-STABLE cpufreq hotter than est from ports 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, 08 Aug 2005 22:53:56 -0000 Tijl Coosemans wrote: > A couple days ago I updated my system and was excited to see cpufreq > and powerd in 5-stable. Since then however I noticed that my laptop > temperature is about 5°C higher than with est and estctrl. I found that > cpufreq when setting 200MHz for example set the absolute frequency to > 1600MHz (max for this laptop) and the relative frequency (p4tcc) to > 12.5% instead of using a more power conserving setting like 800MHz/25%. > > The problem is that cpufreq_expand_set() (sys/kern/kern_cpu.c) > traverses freq levels from high to low when adding relative levels and > skips duplicates. When it wants to add 800MHz/25% it sees this setting > as a duplicate of 1600MHz/12.5% it has found before. This can be fixed > by letting cpufreq_expand_set() traverse freq levels in reverse order > (and still skipping duplicates). Then each frequency level has the > lowest possible absolute setting. This is a one line change in > sys/kern/kern_cpu.c (line 653). You have some valid issues but I need some time to analyze your patch to be sure it doesn't introduce new problems. There may be some issues with traversing the list backwards. > Also, somewhat related, the p4tcc driver doesn't recognise > acpi_throttle, which means that when you load the cpufreq module after > booting, the freq levels are messed up. I'm not sure what the best > solution for this is. Let p4tcc detect acpi_throttle and don't attach > if it's present (like acpi_throttle does now if it finds p4tcc) or > detach it before attaching? Or maybe p4tcc and acpi_throttle should be > merged into one driver? cpufreq is not set up for loading after boot currently. It must be loaded at boot. There are architectural issues that need to be solved to make this happen, namely real arbitration between drivers loaded that support the same feature through different mechanisms. p4tcc and acpi_throttle on some architectures is such a combo that needs special attention. > Finally, is the kernel config option CPU_ENABLE_TCC still relevant? > Because it's still listed in NOTES. The old option should be removed. I'll try to review this patch and commit it sometime soon. -- Nate From owner-freebsd-acpi@FreeBSD.ORG Tue Aug 9 09:35:34 2005 Return-Path: X-Original-To: acpi@freebsd.org Delivered-To: freebsd-acpi@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3690F16A41F; Tue, 9 Aug 2005 09:35:34 +0000 (GMT) (envelope-from ducrot@poupinou.org) Received: from poup.poupinou.org (poup.poupinou.org [195.101.94.96]) by mx1.FreeBSD.org (Postfix) with ESMTP id A3E0343D45; Tue, 9 Aug 2005 09:35:33 +0000 (GMT) (envelope-from ducrot@poupinou.org) Received: from ducrot by poup.poupinou.org with local (Exim) id 1E2QW9-0001nZ-00; Tue, 09 Aug 2005 11:35:29 +0200 Date: Tue, 9 Aug 2005 11:35:29 +0200 To: Tijl Coosemans Message-ID: <20050809093529.GG852@poupinou.org> References: <200508020022.02992.tijl@ulyssis.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <200508020022.02992.tijl@ulyssis.org> User-Agent: Mutt/1.5.9i From: Bruno Ducrot Cc: acpi@FreeBSD.org, freebsd-stable@freebsd.org Subject: Re: 5-STABLE cpufreq hotter than est from ports 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, 09 Aug 2005 09:35:34 -0000 On Tue, Aug 02, 2005 at 12:22:02AM +0200, Tijl Coosemans wrote: > A couple days ago I updated my system and was excited to see cpufreq > and powerd in 5-stable. Since then however I noticed that my laptop > temperature is about 5°C higher than with est and estctrl. I found that > cpufreq when setting 200MHz for example set the absolute frequency to > 1600MHz (max for this laptop) and the relative frequency (p4tcc) to > 12.5% instead of using a more power conserving setting like 800MHz/25%. > > The problem is that cpufreq_expand_set() (sys/kern/kern_cpu.c) > traverses freq levels from high to low when adding relative levels and > skips duplicates. When it wants to add 800MHz/25% it sees this setting > as a duplicate of 1600MHz/12.5% it has found before. This can be fixed > by letting cpufreq_expand_set() traverse freq levels in reverse order > (and still skipping duplicates). Then each frequency level has the > lowest possible absolute setting. This is a one line change in > sys/kern/kern_cpu.c (line 653). It's a well known bug. Someday I think I will have enough time to fix that one if Nate don't bite me. > With this patch temperature is almost as low as with est again (only > 1°C hotter). However, there are still such levels like 1400/12.5 > (175MHz) which are lower than let's say 600/37.5 (225MHz), but consume > a lot more power. On my laptop this problem doesn't really occur > because of the way powerd works, only the absolute levels 1600, 800 and > 600 are ever used. I can imagine somebody with a 1700MHz cpu not being > so lucky though. So, I've worked out a patch (attached) that makes sure > that a lower frequency level has at most the same absolute setting > (preferably less of course). This eliminates quite a few levels so > somebody with a better knowledge of cpufreq should check if this patch > really does something good. This is the first time I've taken a look at > FreeBSD source code by the way. It's in my todo list in a so long time that I must admit I must be blamed to have not fixed that already. > Also, somewhat related, the p4tcc driver doesn't recognise > acpi_throttle, which means that when you load the cpufreq module after > booting, the freq levels are messed up. I'm not sure what the best > solution for this is. Let p4tcc detect acpi_throttle and don't attach > if it's present (like acpi_throttle does now if it finds p4tcc) or > detach it before attaching? Or maybe p4tcc and acpi_throttle should be > merged into one driver? > > Finally, is the kernel config option CPU_ENABLE_TCC still relevant? > Because it's still listed in NOTES. Right. I forgot to kill that option. -- Bruno Ducrot -- Which is worse: ignorance or apathy? -- Don't know. Don't care. From owner-freebsd-acpi@FreeBSD.ORG Wed Aug 10 10:01:38 2005 Return-Path: X-Original-To: freebsd-acpi@freebsd.org Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8B71716A41F for ; Wed, 10 Aug 2005 10:01:38 +0000 (GMT) (envelope-from tijl@ulyssis.org) Received: from outmx028.isp.belgacom.be (outmx028.isp.belgacom.be [195.238.3.49]) by mx1.FreeBSD.org (Postfix) with ESMTP id AC2C343D49; Wed, 10 Aug 2005 10:01:36 +0000 (GMT) (envelope-from tijl@ulyssis.org) Received: from outmx028.isp.belgacom.be (localhost [127.0.0.1]) by outmx028.isp.belgacom.be (8.12.11/8.12.11/Skynet-OUT-2.22) with ESMTP id j7AA1P3M012159; Wed, 10 Aug 2005 12:01:25 +0200 (envelope-from ) Received: from kalimero.kotnet.org (160-127.247.81.adsl.skynet.be [81.247.127.160]) by outmx028.isp.belgacom.be (8.12.11/8.12.11/Skynet-OUT-2.22) with ESMTP id j7AA1KFk012109; Wed, 10 Aug 2005 12:01:20 +0200 (envelope-from ) Received: from kalimero.kotnet.org (kalimero.kotnet.org [127.0.0.1]) by kalimero.kotnet.org (8.13.3/8.13.3) with ESMTP id j7AA1J4G003242; Wed, 10 Aug 2005 12:01:20 +0200 (CEST) (envelope-from tijl@ulyssis.org) From: Tijl Coosemans To: freebsd-acpi@freebsd.org Date: Wed, 10 Aug 2005 12:01:18 +0200 User-Agent: KMail/1.8.1 References: <20050808180345.CABF35D08@ptavv.es.net> In-Reply-To: <20050808180345.CABF35D08@ptavv.es.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200508101201.19489.tijl@ulyssis.org> Cc: ducrot@freebsd.org Subject: Re: 5-STABLE cpufreq hotter than est from ports 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, 10 Aug 2005 10:01:38 -0000 On Monday 08 August 2005 20:03, Kevin Oberman wrote: > > From: Tijl Coosemans > > Date: Mon, 8 Aug 2005 16:18:00 +0200 > > > > In my experience throttling doesn't really gain that much. There's > > almost no difference between running at 600MHz/100% and > > 600MHz/12.5%, except that it is 8 times slower, so I've set > > debug.cpufreq.lowest to 400 to limit the performance drop. > > Odd. I don't see that at all. I am running at either 1.8 GHz or 1.2 > GHz and the performance ramps almost in lock-step with the setting > and power consumption does, as well. Without your patch, using the > values of dev.cpu.0.freq that run the CPU at the slower speed (1.2 > GHz), I get the following: > dev.cpu.0.freq Temp. Savings > 1200 73 > 1050 69 5.5% > 750 64 12.3% > 600 62 15.1% > 300 58 20.5% > 150 54 25.0% > The lowest 1.8 GHz value (1350) results in 85.I find these power > savings to be significant. > > For power consumption I run the CPU at 100% until the CPU temperature > stabilizes. I realize that this is only an approximation of power > consumption, but I think it's close enough. I've done this too now and I must admit throttling does seem to have an=20 effect on power consumption, though it seems to be less and less=20 effective with lower absolute settings. 1600/100% (1600) 69=B0C 1600/12.5% (200) 55=B0C 600/100% (600) 48=B0C 600/12.5% (75) 45=B0C =46or me, dropping to the lowest frequency (75MHz) is just way too=20 expensive. From owner-freebsd-acpi@FreeBSD.ORG Wed Aug 10 20:13:31 2005 Return-Path: X-Original-To: acpi@FreeBSD.org Delivered-To: freebsd-acpi@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8A89716A41F; Wed, 10 Aug 2005 20:13:31 +0000 (GMT) (envelope-from oberman@es.net) Received: from postal2.es.net (postal2.es.net [198.128.3.206]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1502243D48; Wed, 10 Aug 2005 20:13:30 +0000 (GMT) (envelope-from oberman@es.net) Received: from ptavv.es.net ([198.128.4.29]) by postal2.es.net (Postal Node 2) with ESMTP (SSL) id IBA74465; Wed, 10 Aug 2005 13:13:29 -0700 Received: from ptavv (localhost [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id C6B6D5D07; Wed, 10 Aug 2005 13:13:29 -0700 (PDT) To: Bruno Ducrot In-reply-to: Your message of "Tue, 09 Aug 2005 11:35:29 +0200." <20050809093529.GG852@poupinou.org> Date: Wed, 10 Aug 2005 13:13:29 -0700 From: "Kevin Oberman" Message-Id: <20050810201329.C6B6D5D07@ptavv.es.net> Cc: acpi@FreeBSD.org, freebsd-stable@freebsd.org Subject: Re: 5-STABLE cpufreq hotter than est from ports 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, 10 Aug 2005 20:13:31 -0000 > Date: Tue, 9 Aug 2005 11:35:29 +0200 > From: Bruno Ducrot > Sender: owner-freebsd-stable@freebsd.org > > On Tue, Aug 02, 2005 at 12:22:02AM +0200, Tijl Coosemans wrote: > > A couple days ago I updated my system and was excited to see cpufreq > > and powerd in 5-stable. Since then however I noticed that my laptop > > temperature is about 5°C higher than with est and estctrl. I found that > > cpufreq when setting 200MHz for example set the absolute frequency to > > 1600MHz (max for this laptop) and the relative frequency (p4tcc) to > > 12.5% instead of using a more power conserving setting like 800MHz/25%. > > > > The problem is that cpufreq_expand_set() (sys/kern/kern_cpu.c) > > traverses freq levels from high to low when adding relative levels and > > skips duplicates. When it wants to add 800MHz/25% it sees this setting > > as a duplicate of 1600MHz/12.5% it has found before. This can be fixed > > by letting cpufreq_expand_set() traverse freq levels in reverse order > > (and still skipping duplicates). Then each frequency level has the > > lowest possible absolute setting. This is a one line change in > > sys/kern/kern_cpu.c (line 653). > > It's a well known bug. Someday I think I will have enough time to fix > that one if Nate don't bite me. I have been running with Tijl's patch set for several days with great results. Testing has shown that the patches resolve both issues and I now see only 11 CPU speeds, all of those below the lower CPU clock speed are at that lower speed. Thus far I have seen no negative issues. The temperature of my system is noticeably cooler when not running something that is compute intensive. -- 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 From owner-freebsd-acpi@FreeBSD.ORG Thu Aug 11 06:14:08 2005 Return-Path: X-Original-To: acpi@FreeBSD.org Delivered-To: freebsd-acpi@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1298D16A41F for ; Thu, 11 Aug 2005 06:14:08 +0000 (GMT) (envelope-from nate@root.org) Received: from ylpvm12.prodigy.net (ylpvm12-ext.prodigy.net [207.115.57.43]) by mx1.FreeBSD.org (Postfix) with ESMTP id 57C5B43D53 for ; Thu, 11 Aug 2005 06:14:05 +0000 (GMT) (envelope-from nate@root.org) Received: from pimout5-ext.prodigy.net (pimout5-int.prodigy.net [207.115.4.21]) by ylpvm12.prodigy.net (8.12.10 outbound/8.12.10) with ESMTP id j7B6E5ck006842 for ; Thu, 11 Aug 2005 02:14:05 -0400 X-ORBL: [64.171.187.230] Received: from [10.0.5.50] (adsl-64-171-187-230.dsl.snfc21.pacbell.net [64.171.187.230]) by pimout5-ext.prodigy.net (8.13.4 outbound domainkey aix/8.13.4) with ESMTP id j7B6DxLl164278; Thu, 11 Aug 2005 02:13:59 -0400 Message-ID: <42FAEC77.3020003@root.org> Date: Wed, 10 Aug 2005 23:13:11 -0700 From: Nate Lawson User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050723) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Kevin Oberman References: <20050810201329.C6B6D5D07@ptavv.es.net> In-Reply-To: <20050810201329.C6B6D5D07@ptavv.es.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: acpi@FreeBSD.org, freebsd-stable@FreeBSD.org Subject: Re: 5-STABLE cpufreq hotter than est from ports 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, 11 Aug 2005 06:14:08 -0000 Kevin Oberman wrote: >>Date: Tue, 9 Aug 2005 11:35:29 +0200 >>From: Bruno Ducrot >>Sender: owner-freebsd-stable@freebsd.org >> >>On Tue, Aug 02, 2005 at 12:22:02AM +0200, Tijl Coosemans wrote: >> >>>A couple days ago I updated my system and was excited to see cpufreq >>>and powerd in 5-stable. Since then however I noticed that my laptop >>>temperature is about 5°C higher than with est and estctrl. I found that >>>cpufreq when setting 200MHz for example set the absolute frequency to >>>1600MHz (max for this laptop) and the relative frequency (p4tcc) to >>>12.5% instead of using a more power conserving setting like 800MHz/25%. >>> >>>The problem is that cpufreq_expand_set() (sys/kern/kern_cpu.c) >>>traverses freq levels from high to low when adding relative levels and >>>skips duplicates. When it wants to add 800MHz/25% it sees this setting >>>as a duplicate of 1600MHz/12.5% it has found before. This can be fixed >>>by letting cpufreq_expand_set() traverse freq levels in reverse order >>>(and still skipping duplicates). Then each frequency level has the >>>lowest possible absolute setting. This is a one line change in >>>sys/kern/kern_cpu.c (line 653). >> >>It's a well known bug. Someday I think I will have enough time to fix >>that one if Nate don't bite me. > > I have been running with Tijl's patch set for several days with great > results. Testing has shown that the patches resolve both issues and I > now see only 11 CPU speeds, all of those below the lower CPU clock speed > are at that lower speed. Thus far I have seen no negative issues. The > temperature of my system is noticeably cooler when not running something > that is compute intensive. I'm working on reviewing and perhaps rewriting some of the patches. They may work fine but there are some subtle issues, for instance, with future systems that support more than one relative driver. The goals are correct but the implementation needs a little work. -- Nate From owner-freebsd-acpi@FreeBSD.ORG Thu Aug 11 09:30:25 2005 Return-Path: X-Original-To: freebsd-acpi@hub.freebsd.org Delivered-To: freebsd-acpi@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 528C916A41F for ; Thu, 11 Aug 2005 09:30:25 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id F1AE843D48 for ; Thu, 11 Aug 2005 09:30:24 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.3/8.13.3) with ESMTP id j7B9UOkH088064 for ; Thu, 11 Aug 2005 09:30:24 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.3/8.13.1/Submit) id j7B9UOs7088062; Thu, 11 Aug 2005 09:30:24 GMT (envelope-from gnats) Date: Thu, 11 Aug 2005 09:30:24 GMT Message-Id: <200508110930.j7B9UOs7088062@freefall.freebsd.org> To: freebsd-acpi@FreeBSD.org From: Damien Chaumette Cc: Subject: Re: kern/63666: [acpi] Network card 3c575B do not work after the 5.1 release X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Damien Chaumette List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Aug 2005 09:30:25 -0000 The following reply was made to PR kern/63666; it has been noted by GNATS. From: Damien Chaumette To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/63666: [acpi] Network card 3c575B do not work after the 5.1 release Date: Thu, 11 Aug 2005 10:22:59 +0100 Sorry for the delay, I just tried the latest 6.0-Beta2 and the acpi problem is still there. Will send dmesg later on as the system is now higly unstable and prone to unexpected crashes. -- Damien From owner-freebsd-acpi@FreeBSD.ORG Thu Aug 11 14:41:37 2005 Return-Path: X-Original-To: acpi@FreeBSD.org Delivered-To: freebsd-acpi@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4D32716A421; Thu, 11 Aug 2005 14:41:37 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: from mv.twc.weather.com (mv.twc.weather.com [65.212.71.225]) by mx1.FreeBSD.org (Postfix) with ESMTP id BDB5743D45; Thu, 11 Aug 2005 14:41:36 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: from [10.50.40.201] (Not Verified[65.202.103.25]) by mv.twc.weather.com with NetIQ MailMarshal (v6, 0, 3, 8) id ; Thu, 11 Aug 2005 10:56:26 -0400 From: John Baldwin To: freebsd-current@freebsd.org Date: Thu, 11 Aug 2005 10:26:01 -0400 User-Agent: KMail/1.8 References: <20050810173347.I30058@gauntlet.os.org.za> In-Reply-To: <20050810173347.I30058@gauntlet.os.org.za> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200508111026.02924.jhb@FreeBSD.org> Cc: acpi@FreeBSD.org, Khetan Gajjar Subject: Re: ACPI issue in 7-current ? 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, 11 Aug 2005 14:41:37 -0000 On Wednesday 10 August 2005 11:41 am, Khetan Gajjar wrote: > Hi. > > I've been running a 6-current box which I upgraded recently to 7. > At the same time, I disabled WITNESS and INVARIANTS in the kernel. > I've noticed the machine doing some very weird things ever since. Looks like the locking in acpi_tz is rather busted as it has tried to hold a mutex across kthread_create() which is not ok. That is where the LOR's come from at least. I'm not sure if that is the cause of your other problems though. > acpi_tz0: on acpi0 > malloc(M_WAITOK) of "PROC", forcing M_NOWAIT with the following > non-sleepable lo cks held: > exclusive sleep mutex ACPI thermal zone r = 0 (0xc0859d20) locked @ > /usr/src/sys /modules/acpi/acpi/../../../dev/acpica/acpi_thermal.c:1023 > KDB: stack backtrace: > kdb_backtrace(1,c1a406d4,c1042000,0,c0c20ba0) at kdb_backtrace+0x29 > witness_warn(5,0,c06ae269,c06938e6,c1a406d4) at witness_warn+0x18e > uma_zalloc_arg(c1042000,0,2) at uma_zalloc_arg+0x41 > fork1(c06fb400,60034,0,c0c20bf4) at fork1+0x106 > kthread_create(c08453bc,c1a40600,c1a406d4,40000,0) at kthread_create+0x3d > acpi_tz_cooling_thread_start(c1a40600,307a74,c0858558,c197e7e0,c1a68100) at > acpi _tz_cooling_thread_start+0x66 > acpi_tz_attach(c1a68100) at acpi_tz_attach+0x408 > device_attach(c1a68100,c1a68400,c1a68100,c1a3f180,0) at device_attach+0x58 > device_probe_and_attach(c1a68100) at device_probe_and_attach+0xe0 > bus_generic_attach(c1a3f200,1,c0c20cd8,c083c2bc,c1a3f200) at > bus_generic_attach+ 0x16 > acpi_probe_children(c1a3f200,404f398,c1a3f200,c1a3f200,0) at > acpi_probe_children +0x2f > acpi_attach(c1a3f200) at acpi_attach+0x514 > device_attach(c1a3f200,c0857960,c1a3f200,c19bf080,0) at device_attach+0x58 > device_probe_and_attach(c1a3f200) at device_probe_and_attach+0xe0 > bus_generic_attach(c19bf080,c19bf080,c19bf080,c0c20d40,c0511070) at > bus_generic_ attach+0x16 > nexus_attach(c19bf080) at nexus_attach+0x13 > device_attach(c19bf080,c197185c,c19bf080,c06e6ff0,c28000) at > device_attach+0x58 device_probe_and_attach(c19bf080) at > device_probe_and_attach+0xe0 > root_bus_configure(c0c20d88,c04d4aea,0,c1ec00,c1e000) at > root_bus_configure+0x16 configure(0,c1ec00,c1e000,0,c0432d95) at > configure+0x9 > mi_startup() at mi_startup+0x96 > begin() at begin+0x2c > lock order reversal > 1st 0xc0859d20 ACPI thermal zone (ACPI thermal zone) @ > /usr/src/sys/modules/acp i/acpi/../../../dev/acpica/acpi_thermal.c:1023 > 2nd 0xc06fd440 proctree (proctree) @ kern/kern_fork.c:277 > KDB: stack backtrace: > kdb_backtrace(0,ffffffff,c0712138,c0712f98,c06d59ac) at kdb_backtrace+0x29 > witness_checkorder(c06fd440,1,c069187b,115) at witness_checkorder+0x564 > _sx_slock(c06fd440,c0691872,115,c1a3a3c0,c1a3a274,0,0,0) at _sx_slock+0x50 > fork1(c06fb400,60034,0,c0c20bf4) at fork1+0x135 > kthread_create(c08453bc,c1a40600,c1a406d4,40000,0) at kthread_create+0x3d > acpi_tz_cooling_thread_start(c1a40600,307a74,c0858558,c197e7e0,c1a68100) at > acpi _tz_cooling_thread_start+0x66 > acpi_tz_attach(c1a68100) at acpi_tz_attach+0x408 > device_attach(c1a68100,c1a68400,c1a68100,c1a3f180,0) at device_attach+0x58 > device_probe_and_attach(c1a68100) at device_probe_and_attach+0xe0 > bus_generic_attach(c1a3f200,1,c0c20cd8,c083c2bc,c1a3f200) at > bus_generic_attach+ 0x16 > acpi_probe_children(c1a3f200,404f398,c1a3f200,c1a3f200,0) at > acpi_probe_children +0x2f > acpi_attach(c1a3f200) at acpi_attach+0x514 > device_attach(c1a3f200,c0857960,c1a3f200,c19bf080,0) at device_attach+0x58 > device_probe_and_attach(c1a3f200) at device_probe_and_attach+0xe0 > bus_generic_attach(c19bf080,c19bf080,c19bf080,c0c20d40,c0511070) at > bus_generic_ attach+0x16 > nexus_attach(c19bf080) at nexus_attach+0x13 > device_attach(c19bf080,c197185c,c19bf080,c06e6ff0,c28000) at > device_attach+0x58 device_probe_and_attach(c19bf080) at > device_probe_and_attach+0xe0 > root_bus_configure(c0c20d88,c04d4aea,0,c1ec00,c1e000) at > root_bus_configure+0x16 configure(0,c1ec00,c1e000,0,c0432d95) at > configure+0x9 > mi_startup() at mi_startup+0x96 > begin() at begin+0x2c > malloc(M_WAITOK) of "4096", forcing M_NOWAIT with the following > non-sleepable lo cks held: > exclusive sleep mutex ACPI thermal zone r = 0 (0xc0859d20) locked @ > /usr/src/sys /modules/acpi/acpi/../../../dev/acpica/acpi_thermal.c:1023 > KDB: stack backtrace: > kdb_backtrace(1,ad0,c104ab40,8,c0c20b70) at kdb_backtrace+0x29 > witness_warn(5,0,c06ae269,c0692706,ad0) at witness_warn+0x18e > uma_zalloc_arg(c104ab40,0,102) at uma_zalloc_arg+0x41 > malloc(acc,c06d47c0,102,24,c0c20bdc) at malloc+0xae > sigacts_alloc(c0c20bf4,c051e423,1,0,c051ddf8) at sigacts_alloc+0x18 > fork1(c06fb400,60034,0,c0c20bf4) at fork1+0x48d > kthread_create(c08453bc,c1a40600,c1a406d4,40000,0) at kthread_create+0x3d > acpi_tz_cooling_thread_start(c1a40600,307a74,c0858558,c197e7e0,c1a68100) at > acpi _tz_cooling_thread_start+0x66 > acpi_tz_attach(c1a68100) at acpi_tz_attach+0x408 > device_attach(c1a68100,c1a68400,c1a68100,c1a3f180,0) at device_attach+0x58 > device_probe_and_attach(c1a68100) at device_probe_and_attach+0xe0 > bus_generic_attach(c1a3f200,1,c0c20cd8,c083c2bc,c1a3f200) at > bus_generic_attach+ 0x16 > acpi_probe_children(c1a3f200,404f398,c1a3f200,c1a3f200,0) at > acpi_probe_children +0x2f > acpi_attach(c1a3f200) at acpi_attach+0x514 > device_attach(c1a3f200,c0857960,c1a3f200,c19bf080,0) at device_attach+0x58 > device_probe_and_attach(c1a3f200) at device_probe_and_attach+0xe0 > bus_generic_attach(c19bf080,c19bf080,c19bf080,c0c20d40,c0511070) at > bus_generic_ attach+0x16 > nexus_attach(c19bf080) at nexus_attach+0x13 > device_attach(c19bf080,c197185c,c19bf080,c06e6ff0,c28000) at > device_attach+0x58 device_probe_and_attach(c19bf080) at > device_probe_and_attach+0xe0 > root_bus_configure(c0c20d88,c04d4aea,0,c1ec00,c1e000) at > root_bus_configure+0x16 configure(0,c1ec00,c1e000,0,c0432d95) at > configure+0x9 > mi_startup() at mi_startup+0x96 > begin() at begin+0x2c > malloc(M_WAITOK) of "256", forcing M_NOWAIT with the following > non-sleepable loc ks held: > exclusive sleep mutex ACPI thermal zone r = 0 (0xc0859d20) locked @ > /usr/src/sys /modules/acpi/acpi/../../../dev/acpica/acpi_thermal.c:1023 > KDB: stack backtrace: > kdb_backtrace(1,d0,c104a3c0,4,c0c20b38) at kdb_backtrace+0x29 > witness_warn(5,0,c06ae269,c0698bee,d0) at witness_warn+0x18e > uma_zalloc_arg(c104a3c0,0,102) at uma_zalloc_arg+0x41 > malloc(cc,c06d1600,102,c04f44ec,24) at malloc+0xae > fdinit(c1985400,c1a42aa8,c0694670,0,0) at fdinit+0x20 > fdcopy(c1985400,c0c20bf4,c051e423,1,c1a42000) at fdcopy+0x20 > fork1(c06fb400,60034,0,c0c20bf4) at fork1+0x4c6 > kthread_create(c08453bc,c1a40600,c1a406d4,40000,0) at kthread_create+0x3d > acpi_tz_cooling_thread_start(c1a40600,307a74,c0858558,c197e7e0,c1a68100) at > acpi _tz_cooling_thread_start+0x66 > acpi_tz_attach(c1a68100) at acpi_tz_attach+0x408 > device_attach(c1a68100,c1a68400,c1a68100,c1a3f180,0) at device_attach+0x58 > device_probe_and_attach(c1a68100) at device_probe_and_attach+0xe0 > bus_generic_attach(c1a3f200,1,c0c20cd8,c083c2bc,c1a3f200) at > bus_generic_attach+ 0x16 > acpi_probe_children(c1a3f200,404f398,c1a3f200,c1a3f200,0) at > acpi_probe_children +0x2f > acpi_attach(c1a3f200) at acpi_attach+0x514 > device_attach(c1a3f200,c0857960,c1a3f200,c19bf080,0) at device_attach+0x58 > device_probe_and_attach(c1a3f200) at device_probe_and_attach+0xe0 > bus_generic_attach(c19bf080,c19bf080,c19bf080,c0c20d40,c0511070) at > bus_generic_ attach+0x16 > nexus_attach(c19bf080) at nexus_attach+0x13 > device_attach(c19bf080,c197185c,c19bf080,c06e6ff0,c28000) at > device_attach+0x58 device_probe_and_attach(c19bf080) at > device_probe_and_attach+0xe0 > root_bus_configure(c0c20d88,c04d4aea,0,c1ec00,c1e000) at > root_bus_configure+0x16 configure(0,c1ec00,c1e000,0,c0432d95) at > configure+0x9 > mi_startup() at mi_startup+0x96 > begin() at begin+0x2c -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-acpi@FreeBSD.ORG Thu Aug 11 14:52:59 2005 Return-Path: X-Original-To: acpi@FreeBSD.org Delivered-To: freebsd-acpi@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CF53016A41F for ; Thu, 11 Aug 2005 14:52:59 +0000 (GMT) (envelope-from oberman@es.net) Received: from postal2.es.net (postal2.es.net [198.128.3.206]) by mx1.FreeBSD.org (Postfix) with ESMTP id 96DBD43D5D for ; Thu, 11 Aug 2005 14:52:59 +0000 (GMT) (envelope-from oberman@es.net) Received: from ptavv.es.net ([198.128.4.29]) by postal2.es.net (Postal Node 2) with ESMTP (SSL) id IBA74465; Thu, 11 Aug 2005 07:52:58 -0700 Received: from ptavv (localhost [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id 10F615D08; Thu, 11 Aug 2005 07:52:58 -0700 (PDT) To: Nate Lawson In-reply-to: Your message of "Wed, 10 Aug 2005 23:13:11 PDT." <42FAEC77.3020003@root.org> Date: Thu, 11 Aug 2005 07:52:58 -0700 From: "Kevin Oberman" Message-Id: <20050811145258.10F615D08@ptavv.es.net> Cc: acpi@FreeBSD.org Subject: Re: 5-STABLE cpufreq hotter than est from ports 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, 11 Aug 2005 14:52:59 -0000 > Date: Wed, 10 Aug 2005 23:13:11 -0700 > From: Nate Lawson > > Kevin Oberman wrote: > >>Date: Tue, 9 Aug 2005 11:35:29 +0200 > >>From: Bruno Ducrot > >>Sender: owner-freebsd-stable@freebsd.org > >> > >>On Tue, Aug 02, 2005 at 12:22:02AM +0200, Tijl Coosemans wrote: > >> > >>>A couple days ago I updated my system and was excited to see cpufreq > >>>and powerd in 5-stable. Since then however I noticed that my laptop > >>>temperature is about 5°C higher than with est and estctrl. I found that > >>>cpufreq when setting 200MHz for example set the absolute frequency to > >>>1600MHz (max for this laptop) and the relative frequency (p4tcc) to > >>>12.5% instead of using a more power conserving setting like 800MHz/25%. > >>> > >>>The problem is that cpufreq_expand_set() (sys/kern/kern_cpu.c) > >>>traverses freq levels from high to low when adding relative levels and > >>>skips duplicates. When it wants to add 800MHz/25% it sees this setting > >>>as a duplicate of 1600MHz/12.5% it has found before. This can be fixed > >>>by letting cpufreq_expand_set() traverse freq levels in reverse order > >>>(and still skipping duplicates). Then each frequency level has the > >>>lowest possible absolute setting. This is a one line change in > >>>sys/kern/kern_cpu.c (line 653). > >> > >>It's a well known bug. Someday I think I will have enough time to fix > >>that one if Nate don't bite me. > > > > I have been running with Tijl's patch set for several days with great > > results. Testing has shown that the patches resolve both issues and I > > now see only 11 CPU speeds, all of those below the lower CPU clock speed > > are at that lower speed. Thus far I have seen no negative issues. The > > temperature of my system is noticeably cooler when not running something > > that is compute intensive. > > I'm working on reviewing and perhaps rewriting some of the patches. > They may work fine but there are some subtle issues, for instance, with > future systems that support more than one relative driver. The goals > are correct but the implementation needs a little work. No problem. I was just confirming that the patch was working well on a system using TCC and SpeedStep. I have only given the actual patch a quick scan to confirm that it did pretty much what was claimed. "More than one relative driver"? I had never considered that, but I can see the possibility. Guess that's why Bruno and you are doing this and I'm not. (Well, the fact that I write ugly code and have never read all of the ACPI spec has something to do with it, too.) -- 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 From owner-freebsd-acpi@FreeBSD.ORG Thu Aug 11 16:19:17 2005 Return-Path: X-Original-To: acpi@FreeBSD.org Delivered-To: freebsd-acpi@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5A35916A41F; Thu, 11 Aug 2005 16:19:17 +0000 (GMT) (envelope-from khetan@os.org.za) Received: from gauntlet.os.org.za (gauntlet.os.org.za [196.35.70.242]) by mx1.FreeBSD.org (Postfix) with ESMTP id B2B3643D48; Thu, 11 Aug 2005 16:19:13 +0000 (GMT) (envelope-from khetan@os.org.za) Received: from localhost (localhost [127.0.0.1]) by gauntlet.os.org.za (Postfix) with ESMTP id E207A6784D; Thu, 11 Aug 2005 18:19:09 +0200 (SAST) Received: from gauntlet.os.org.za ([127.0.0.1]) by localhost (gauntlet.os.org.za [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 39430-02; Thu, 11 Aug 2005 18:19:02 +0200 (SAST) Received: from khetangajjar (c1-208-1.rrba.isadsl.co.za [196.34.192.208]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) (Authenticated sender: khetan) by gauntlet.os.org.za (Postfix) with ESMTP id E155E67828; Thu, 11 Aug 2005 18:19:01 +0200 (SAST) From: "Khetan Gajjar" To: "'John Baldwin'" , Date: Thu, 11 Aug 2005 18:22:07 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 thread-index: AcWehOx2rbTm/GylQDOJys7L4XBaawAC9qZQ In-Reply-To: <200508111026.02924.jhb@FreeBSD.org> Message-Id: <20050811161901.E155E67828@gauntlet.os.org.za> X-Virus-Scanned: amavisd-new at os.org.za Cc: acpi@FreeBSD.org Subject: RE: ACPI issue in 7-current ? 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, 11 Aug 2005 16:19:17 -0000 Well, I'm swopping out the hardware to an Intel processor and board. Lets see if that solves the problem :-) -----Original Message----- From: John Baldwin [mailto:jhb@FreeBSD.org] Sent: Thursday, August 11, 2005 4:26 PM To: freebsd-current@freebsd.org Cc: Khetan Gajjar; acpi@FreeBSD.org Subject: Re: ACPI issue in 7-current ? On Wednesday 10 August 2005 11:41 am, Khetan Gajjar wrote: > Hi. > > I've been running a 6-current box which I upgraded recently to 7. > At the same time, I disabled WITNESS and INVARIANTS in the kernel. > I've noticed the machine doing some very weird things ever since. Looks like the locking in acpi_tz is rather busted as it has tried to hold a mutex across kthread_create() which is not ok. That is where the LOR's come from at least. I'm not sure if that is the cause of your other problems though. > acpi_tz0: on acpi0 > malloc(M_WAITOK) of "PROC", forcing M_NOWAIT with the following > non-sleepable lo cks held: > exclusive sleep mutex ACPI thermal zone r = 0 (0xc0859d20) locked @ > /usr/src/sys /modules/acpi/acpi/../../../dev/acpica/acpi_thermal.c:1023 > KDB: stack backtrace: > kdb_backtrace(1,c1a406d4,c1042000,0,c0c20ba0) at kdb_backtrace+0x29 > witness_warn(5,0,c06ae269,c06938e6,c1a406d4) at witness_warn+0x18e > uma_zalloc_arg(c1042000,0,2) at uma_zalloc_arg+0x41 > fork1(c06fb400,60034,0,c0c20bf4) at fork1+0x106 > kthread_create(c08453bc,c1a40600,c1a406d4,40000,0) at kthread_create+0x3d > acpi_tz_cooling_thread_start(c1a40600,307a74,c0858558,c197e7e0,c1a68100) at > acpi _tz_cooling_thread_start+0x66 > acpi_tz_attach(c1a68100) at acpi_tz_attach+0x408 > device_attach(c1a68100,c1a68400,c1a68100,c1a3f180,0) at device_attach+0x58 > device_probe_and_attach(c1a68100) at device_probe_and_attach+0xe0 > bus_generic_attach(c1a3f200,1,c0c20cd8,c083c2bc,c1a3f200) at > bus_generic_attach+ 0x16 > acpi_probe_children(c1a3f200,404f398,c1a3f200,c1a3f200,0) at > acpi_probe_children +0x2f > acpi_attach(c1a3f200) at acpi_attach+0x514 > device_attach(c1a3f200,c0857960,c1a3f200,c19bf080,0) at device_attach+0x58 > device_probe_and_attach(c1a3f200) at device_probe_and_attach+0xe0 > bus_generic_attach(c19bf080,c19bf080,c19bf080,c0c20d40,c0511070) at > bus_generic_ attach+0x16 > nexus_attach(c19bf080) at nexus_attach+0x13 > device_attach(c19bf080,c197185c,c19bf080,c06e6ff0,c28000) at > device_attach+0x58 device_probe_and_attach(c19bf080) at > device_probe_and_attach+0xe0 > root_bus_configure(c0c20d88,c04d4aea,0,c1ec00,c1e000) at > root_bus_configure+0x16 configure(0,c1ec00,c1e000,0,c0432d95) at > configure+0x9 > mi_startup() at mi_startup+0x96 > begin() at begin+0x2c > lock order reversal > 1st 0xc0859d20 ACPI thermal zone (ACPI thermal zone) @ > /usr/src/sys/modules/acp i/acpi/../../../dev/acpica/acpi_thermal.c:1023 > 2nd 0xc06fd440 proctree (proctree) @ kern/kern_fork.c:277 > KDB: stack backtrace: > kdb_backtrace(0,ffffffff,c0712138,c0712f98,c06d59ac) at kdb_backtrace+0x29 > witness_checkorder(c06fd440,1,c069187b,115) at witness_checkorder+0x564 > _sx_slock(c06fd440,c0691872,115,c1a3a3c0,c1a3a274,0,0,0) at _sx_slock+0x50 > fork1(c06fb400,60034,0,c0c20bf4) at fork1+0x135 > kthread_create(c08453bc,c1a40600,c1a406d4,40000,0) at kthread_create+0x3d > acpi_tz_cooling_thread_start(c1a40600,307a74,c0858558,c197e7e0,c1a68100) at > acpi _tz_cooling_thread_start+0x66 > acpi_tz_attach(c1a68100) at acpi_tz_attach+0x408 > device_attach(c1a68100,c1a68400,c1a68100,c1a3f180,0) at device_attach+0x58 > device_probe_and_attach(c1a68100) at device_probe_and_attach+0xe0 > bus_generic_attach(c1a3f200,1,c0c20cd8,c083c2bc,c1a3f200) at > bus_generic_attach+ 0x16 > acpi_probe_children(c1a3f200,404f398,c1a3f200,c1a3f200,0) at > acpi_probe_children +0x2f > acpi_attach(c1a3f200) at acpi_attach+0x514 > device_attach(c1a3f200,c0857960,c1a3f200,c19bf080,0) at device_attach+0x58 > device_probe_and_attach(c1a3f200) at device_probe_and_attach+0xe0 > bus_generic_attach(c19bf080,c19bf080,c19bf080,c0c20d40,c0511070) at > bus_generic_ attach+0x16 > nexus_attach(c19bf080) at nexus_attach+0x13 > device_attach(c19bf080,c197185c,c19bf080,c06e6ff0,c28000) at > device_attach+0x58 device_probe_and_attach(c19bf080) at > device_probe_and_attach+0xe0 > root_bus_configure(c0c20d88,c04d4aea,0,c1ec00,c1e000) at > root_bus_configure+0x16 configure(0,c1ec00,c1e000,0,c0432d95) at > configure+0x9 > mi_startup() at mi_startup+0x96 > begin() at begin+0x2c > malloc(M_WAITOK) of "4096", forcing M_NOWAIT with the following > non-sleepable lo cks held: > exclusive sleep mutex ACPI thermal zone r = 0 (0xc0859d20) locked @ > /usr/src/sys /modules/acpi/acpi/../../../dev/acpica/acpi_thermal.c:1023 > KDB: stack backtrace: > kdb_backtrace(1,ad0,c104ab40,8,c0c20b70) at kdb_backtrace+0x29 > witness_warn(5,0,c06ae269,c0692706,ad0) at witness_warn+0x18e > uma_zalloc_arg(c104ab40,0,102) at uma_zalloc_arg+0x41 > malloc(acc,c06d47c0,102,24,c0c20bdc) at malloc+0xae > sigacts_alloc(c0c20bf4,c051e423,1,0,c051ddf8) at sigacts_alloc+0x18 > fork1(c06fb400,60034,0,c0c20bf4) at fork1+0x48d > kthread_create(c08453bc,c1a40600,c1a406d4,40000,0) at kthread_create+0x3d > acpi_tz_cooling_thread_start(c1a40600,307a74,c0858558,c197e7e0,c1a68100) at > acpi _tz_cooling_thread_start+0x66 > acpi_tz_attach(c1a68100) at acpi_tz_attach+0x408 > device_attach(c1a68100,c1a68400,c1a68100,c1a3f180,0) at device_attach+0x58 > device_probe_and_attach(c1a68100) at device_probe_and_attach+0xe0 > bus_generic_attach(c1a3f200,1,c0c20cd8,c083c2bc,c1a3f200) at > bus_generic_attach+ 0x16 > acpi_probe_children(c1a3f200,404f398,c1a3f200,c1a3f200,0) at > acpi_probe_children +0x2f > acpi_attach(c1a3f200) at acpi_attach+0x514 > device_attach(c1a3f200,c0857960,c1a3f200,c19bf080,0) at device_attach+0x58 > device_probe_and_attach(c1a3f200) at device_probe_and_attach+0xe0 > bus_generic_attach(c19bf080,c19bf080,c19bf080,c0c20d40,c0511070) at > bus_generic_ attach+0x16 > nexus_attach(c19bf080) at nexus_attach+0x13 > device_attach(c19bf080,c197185c,c19bf080,c06e6ff0,c28000) at > device_attach+0x58 device_probe_and_attach(c19bf080) at > device_probe_and_attach+0xe0 > root_bus_configure(c0c20d88,c04d4aea,0,c1ec00,c1e000) at > root_bus_configure+0x16 configure(0,c1ec00,c1e000,0,c0432d95) at > configure+0x9 > mi_startup() at mi_startup+0x96 > begin() at begin+0x2c > malloc(M_WAITOK) of "256", forcing M_NOWAIT with the following > non-sleepable loc ks held: > exclusive sleep mutex ACPI thermal zone r = 0 (0xc0859d20) locked @ > /usr/src/sys /modules/acpi/acpi/../../../dev/acpica/acpi_thermal.c:1023 > KDB: stack backtrace: > kdb_backtrace(1,d0,c104a3c0,4,c0c20b38) at kdb_backtrace+0x29 > witness_warn(5,0,c06ae269,c0698bee,d0) at witness_warn+0x18e > uma_zalloc_arg(c104a3c0,0,102) at uma_zalloc_arg+0x41 > malloc(cc,c06d1600,102,c04f44ec,24) at malloc+0xae > fdinit(c1985400,c1a42aa8,c0694670,0,0) at fdinit+0x20 > fdcopy(c1985400,c0c20bf4,c051e423,1,c1a42000) at fdcopy+0x20 > fork1(c06fb400,60034,0,c0c20bf4) at fork1+0x4c6 > kthread_create(c08453bc,c1a40600,c1a406d4,40000,0) at kthread_create+0x3d > acpi_tz_cooling_thread_start(c1a40600,307a74,c0858558,c197e7e0,c1a68100) at > acpi _tz_cooling_thread_start+0x66 > acpi_tz_attach(c1a68100) at acpi_tz_attach+0x408 > device_attach(c1a68100,c1a68400,c1a68100,c1a3f180,0) at device_attach+0x58 > device_probe_and_attach(c1a68100) at device_probe_and_attach+0xe0 > bus_generic_attach(c1a3f200,1,c0c20cd8,c083c2bc,c1a3f200) at > bus_generic_attach+ 0x16 > acpi_probe_children(c1a3f200,404f398,c1a3f200,c1a3f200,0) at > acpi_probe_children +0x2f > acpi_attach(c1a3f200) at acpi_attach+0x514 > device_attach(c1a3f200,c0857960,c1a3f200,c19bf080,0) at device_attach+0x58 > device_probe_and_attach(c1a3f200) at device_probe_and_attach+0xe0 > bus_generic_attach(c19bf080,c19bf080,c19bf080,c0c20d40,c0511070) at > bus_generic_ attach+0x16 > nexus_attach(c19bf080) at nexus_attach+0x13 > device_attach(c19bf080,c197185c,c19bf080,c06e6ff0,c28000) at > device_attach+0x58 device_probe_and_attach(c19bf080) at > device_probe_and_attach+0xe0 > root_bus_configure(c0c20d88,c04d4aea,0,c1ec00,c1e000) at > root_bus_configure+0x16 configure(0,c1ec00,c1e000,0,c0432d95) at > configure+0x9 > mi_startup() at mi_startup+0x96 > begin() at begin+0x2c -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-acpi@FreeBSD.ORG Thu Aug 11 17:05:57 2005 Return-Path: X-Original-To: acpi@FreeBSD.org Delivered-To: freebsd-acpi@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id ECB2116A41F; Thu, 11 Aug 2005 17:05:57 +0000 (GMT) (envelope-from nate@root.org) Received: from ylpvm12.prodigy.net (ylpvm12-ext.prodigy.net [207.115.57.43]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7A45F43D45; Thu, 11 Aug 2005 17:05:56 +0000 (GMT) (envelope-from nate@root.org) Received: from ylpvm01.prodigy.net (ylpvm01-int.prodigy.net [207.115.5.207]) by ylpvm12.prodigy.net (8.12.10 outbound/8.12.10) with ESMTP id j7BH5sck027301; Thu, 11 Aug 2005 13:05:54 -0400 X-ORBL: [64.171.187.230] Received: from [10.0.5.50] (adsl-64-171-187-230.dsl.snfc21.pacbell.net [64.171.187.230]) by ylpvm01.prodigy.net (8.13.4 dk-milter linux/8.13.4) with ESMTP id j7BH5jOs001761; Thu, 11 Aug 2005 13:05:45 -0400 Message-ID: <42FB856C.1000205@root.org> Date: Thu, 11 Aug 2005 10:05:48 -0700 From: Nate Lawson User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050723) X-Accept-Language: en-us, en MIME-Version: 1.0 To: John Baldwin References: <20050810173347.I30058@gauntlet.os.org.za> <200508111026.02924.jhb@FreeBSD.org> In-Reply-To: <200508111026.02924.jhb@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: acpi@FreeBSD.org, freebsd-current@FreeBSD.org, Khetan Gajjar Subject: Re: ACPI issue in 7-current ? 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, 11 Aug 2005 17:05:58 -0000 John Baldwin wrote: > On Wednesday 10 August 2005 11:41 am, Khetan Gajjar wrote: > >>Hi. >> >>I've been running a 6-current box which I upgraded recently to 7. >>At the same time, I disabled WITNESS and INVARIANTS in the kernel. >>I've noticed the machine doing some very weird things ever since. > > > Looks like the locking in acpi_tz is rather busted as it has tried to hold a > mutex across kthread_create() which is not ok. That is where the LOR's come > from at least. I'm not sure if that is the cause of your other problems > though. > > >>acpi_tz0: on acpi0 >>malloc(M_WAITOK) of "PROC", forcing M_NOWAIT with the following >>non-sleepable lo cks held: >>exclusive sleep mutex ACPI thermal zone r = 0 (0xc0859d20) locked @ Too late, it was introduced by the passive cooling commit and fixed a while ago by ume@. -- Nate From owner-freebsd-acpi@FreeBSD.ORG Fri Aug 12 20:02:56 2005 Return-Path: X-Original-To: freebsd-acpi@freebsd.org Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CE68F16A420 for ; Fri, 12 Aug 2005 20:02:56 +0000 (GMT) (envelope-from colazelli@gmail.com) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.206]) by mx1.FreeBSD.org (Postfix) with ESMTP id DE7F743D6B for ; Fri, 12 Aug 2005 20:02:52 +0000 (GMT) (envelope-from colazelli@gmail.com) Received: by wproxy.gmail.com with SMTP id i5so644498wra for ; Fri, 12 Aug 2005 13:02:52 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:x-accept-language:mime-version:to:subject:content-type:content-transfer-encoding; b=HoW7r15lznfY+plJyUKl1fALQcoHIZBKb2JAXBD/RrsUXbHM/zgtrGmBd9ialVbhYSxVQzFNtwqvJ4kSp8oN5uIJiPbQVsr1uIGkDC++s8WQrLi1FhI3R/7qE8tQQRFgbNu0pAzZK6HAPDygj/s+QQ/AGK+SluIdGKOknGTTxKk= Received: by 10.54.57.32 with SMTP id f32mr2119694wra; Fri, 12 Aug 2005 13:02:51 -0700 (PDT) Received: from ?192.168.1.10? ([200.148.109.102]) by mx.gmail.com with ESMTP id 6sm9782280wrl.2005.08.12.13.02.50; Fri, 12 Aug 2005 13:02:51 -0700 (PDT) Message-ID: <42FCFFAB.9060006@gmail.com> Date: Fri, 12 Aug 2005 16:59:39 -0300 From: Wesley Gentine User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050805) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-acpi@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: acpi_fujitsu doesnt work 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, 12 Aug 2005 20:02:57 -0000 I have a Fujitsu FmV Biblo MG50H (japanese) and I tried to compile acpi_fujitsu inside kernel and nothing happened. But loading kernel module I have the following output: acpi_fujitsu0: on acpi0 acpi_fujitsu0: Couldn't query volume level acpi_fujitsu0: Couldn't init button states acpi_fujitsu0: Couldn't initialize button states! I have another question. Is est0 compatible with Celeron M? Because it only recognized p4tcc0 and ichss0 that id had to disable. (Celeron M doesnt support this feature). My dmesg: FreeBSD 6.0-BETA2 #3: Fri Aug 12 15:23:02 BRT 2005 wgentine@stardust:/usr/src/sys/i386/compile/STARDUST6 Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Celeron(R) M processor 1300MHz (1299.96-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x695 Stepping = 5 Features=0xa7e9f9bf real memory = 258932736 (246 MB) avail memory = 243920896 (232 MB) ichwd module loaded ath_hal: 0.9.14.9 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413) npx0: [FAST] npx0: on motherboard npx0: INT 16 interface acpi0: on motherboard acpi0: Power Button (fixed) pci_link0: irq 11 on acpi0 pci_link1: irq 11 on acpi0 pci_link2: irq 11 on acpi0 pci_link3: irq 11 on acpi0 pci_link4: irq 11 on acpi0 pci_link5: irq 11 on acpi0 pci_link6: irq 0 on acpi0 pci_link7: irq 11 on acpi0 Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0xfc08-0xfc0b on acpi0 cpu0: on acpi0 p4tcc0: on cpu0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pci0: at device 0.1 (no driver attached) pci0: at device 0.3 (no driver attached) agp0: port 0x1800-0x1807 mem 0xd8000000 -0xdfffffff,0xd0000000-0xd007ffff irq 11 at device 2.0 on pci0 agp0: detected 8060k stolen memory agp0: aperture size is 128M pci0: at device 2.1 (no driver attached) uhci0: port 0x1820-0x183f irq 11 at dev ice 29.0 on pci0 uhci0: [GIANT-LOCKED] usb0: on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered uhci1: port 0x1840-0x185f irq 11 at dev ice 29.1 on pci0 uhci1: [GIANT-LOCKED] usb1: on uhci1 usb1: USB revision 1.0 uhub1: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered uhci2: port 0x1860-0x187f irq 11 at dev ice 29.2 on pci0 uhci2: [GIANT-LOCKED] usb2: on uhci2 usb2: USB revision 1.0 uhub2: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub2: 2 ports with 2 removable, self powered ehci0: mem 0xd0100000-0xd01003ff irq 11 at device 29.7 on pci0 ehci0: [GIANT-LOCKED] usb3: EHCI version 1.0 usb3: companion controllers, 2 ports each: usb0 usb1 usb2 usb3: on ehci0 usb3: USB revision 2.0 uhub3: Intel EHCI root hub, class 9/0, rev 2.00/1.00, addr 1 uhub3: 6 ports with 6 removable, self powered pcib1: at device 30.0 on pci0 pci1: on pcib1 cbb0: irq 11 at device 10.0 on pci1 cardbus0: on cbb0 pccard0: <16-bit PCCard bus> on cbb0 cbb1: irq 11 at device 10.1 on pci1 cardbus1: on cbb1 pccard1: <16-bit PCCard bus> on cbb1 pci1: at device 10.2 (no driver attached) cbb2: at device 10.3 on pci1 cardbus2: on cbb2 pccard2: <16-bit PCCard bus> on cbb2 bfe0: mem 0xd0214000-0xd0215fff irq 11 at devic e 12.0 on pci1 miibus0: on bfe0 bmtphy0: on miibus0 bmtphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto bfe0: Ethernet address: 00:0b:5d:48:7e:7a ath0: mem 0xd0200000-0xd020ffff irq 11 at device 13.0 on pci1 ath0: Ethernet address: 00:90:96:a6:24:58 ath0: mac 5.6 phy 4.1 radio 4.6 fwohci0: mem 0xd0217000-0xd02177ff,0xd02100 00-0xd0213fff irq 11 at device 14.0 on pci1 fwohci0: OHCI version 1.10 (ROM=0) fwohci0: No. of Isochronous channels is 4. fwohci0: EUI64 00:00:0e:10:02:d0:44:db fwohci0: Phy 1394a available S400, 1 ports. fwohci0: Link S400, max_rec 2048 bytes. firewire0: on fwohci0 fwe0: on firewire0 if_fwe0: Fake Ethernet address: 02:00:0e:d0:44:db fwe0: Ethernet address: 02:00:0e:d0:44:db fwe0: if_start running deferred for Giant sbp0: on firewire0 fwohci0: Initiate bus reset fwohci0: node_id=0xc800ffc0, gen=1, CYCLEMASTER mode firewire0: 1 nodes, maxhop <= 0, cable IRM = 0 (me) firewire0: bus manager 0 (me) isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0 x1810-0x181f at device 31.1 on pci0 ata0: on atapci0 ata1: on atapci0 ichsmb0: port 0x1880-0x189f irq 11 at devic e 31.3 on pci0 ichsmb0: [GIANT-LOCKED] smbus0: on ichsmb0 smb0: on smbus0 pcm0: port 0x1c00-0x1cff,0x18c0-0x18ff mem 0xd0100c00-0xd010 0dff,0xd0100800-0xd01008ff irq 11 at device 31.5 on pci0 pcm0: [GIANT-LOCKED] pcm0: pci0: at device 31.6 (no driver attached) acpi_button0: on acpi0 acpi_lid0: on acpi0 acpi_acad0: on acpi0 battery0: on acpi0 battery1: on acpi0 pmtimer0 on isa0 orm0: at iomem 0xdc000-0xdffff on isa0 atkbdc0: at port 0x60,0x64 on isa0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: model GlidePoint, device ID 0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 Timecounter "TSC" frequency 1299964850 Hz quality 800 Timecounters tick every 1.000 msec ad0: 57231MB at ata0-master UDMA100 acd0: CDRW at ata1-master UDMA33 ata2: at port 0x100-0x10f irq 11 function 0 config 1 on pccard2 Thanks! Wesley Gentine From owner-freebsd-acpi@FreeBSD.ORG Fri Aug 12 21:11:25 2005 Return-Path: X-Original-To: freebsd-acpi@freebsd.org Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EA7AC16A41F for ; Fri, 12 Aug 2005 21:11:25 +0000 (GMT) (envelope-from nate@root.org) Received: from www.cryptography.com (li-22.members.linode.com [64.5.53.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id 958CA43D48 for ; Fri, 12 Aug 2005 21:11:25 +0000 (GMT) (envelope-from nate@root.org) Received: from [10.0.0.33] (adsl-67-119-74-222.dsl.sntc01.pacbell.net [67.119.74.222]) by www.cryptography.com (8.12.8/8.12.8) with ESMTP id j7CLBQo5016004 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 12 Aug 2005 14:11:27 -0700 Message-ID: <42FD1079.3020607@root.org> Date: Fri, 12 Aug 2005 14:11:21 -0700 From: Nate Lawson User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Wesley Gentine References: <42FCFFAB.9060006@gmail.com> In-Reply-To: <42FCFFAB.9060006@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@freebsd.org Subject: Re: acpi_fujitsu doesnt work 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, 12 Aug 2005 21:11:26 -0000 Wesley Gentine wrote: > I have a Fujitsu FmV Biblo MG50H (japanese) and I tried to compile > acpi_fujitsu inside kernel and nothing happened. But loading kernel > module I have the following output: > > acpi_fujitsu0: on acpi0 > acpi_fujitsu0: Couldn't query volume level > acpi_fujitsu0: Couldn't init button states > acpi_fujitsu0: Couldn't initialize button states! It appears your system has a different version of the fujitsu button hardware. Post the url of your ASL, acpidump -t -d > fmv-mg50h.asl > I have another question. Is est0 compatible with Celeron M? Because it > only recognized p4tcc0 and ichss0 that id had to disable. (Celeron M > doesnt support this feature). No, est is not supported by Celeron M. -- Nate From owner-freebsd-acpi@FreeBSD.ORG Sat Aug 13 13:35:35 2005 Return-Path: X-Original-To: freebsd-acpi@freebsd.org Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7F0CA16A41F for ; Sat, 13 Aug 2005 13:35:35 +0000 (GMT) (envelope-from sp.ibm@gmx.de) Received: from mail.gmx.net (mail.gmx.de [213.165.64.20]) by mx1.FreeBSD.org (Postfix) with SMTP id 75C1443D46 for ; Sat, 13 Aug 2005 13:35:34 +0000 (GMT) (envelope-from sp.ibm@gmx.de) Received: (qmail invoked by alias); 13 Aug 2005 13:35:31 -0000 Received: from p85.212.11.170.tisdip.tiscali.de (EHLO monster) [85.212.11.170] by mail.gmx.net (mp018) with SMTP; 13 Aug 2005 15:35:31 +0200 X-Authenticated: #832750 Message-ID: <004901c5a00b$d6409bd0$6701a8c0@monster> From: "Sebastian Pahlke" To: Date: Sat, 13 Aug 2005 15:35:13 +0200 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2527 X-RFC2646: Format=Flowed; Original X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 X-Y-GMX-Trusted: 0 Subject: ACPI power-off failed - timeout 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, 13 Aug 2005 13:35:35 -0000 Hello, I can't power off my FreeBSD release 5.4 box using "shutdown -p now". Error message: Powering system off using ACPI ACPI power-off failed - timeout I've a ASUS CUSI-FX mainboard with SIS630E chipset and use it with 2 IDE HDD's, no other peripherie. By googeling I found some other posts regrding the same problem, but no real solution. There were posts saying you should enable APM in the kernel, but the handbook states explicitly that ACPI and APM cannot coexist, which sounds logic to me. I tried playing with the BIOS settings (Power Management off, PNP-OS...) and different BIOS versions without success. What else can I do? Many thanks for your help in advance! Here some debugging output: # sysctl hw.acpi ----------------- hw.acpi.supported_sleep_state: S1 S4 S5 hw.acpi.power_button_state: S5 hw.acpi.sleep_button_state: S1 hw.acpi.lid_switch_state: NONE hw.acpi.standby_state: S1 hw.acpi.suspend_state: S3 hw.acpi.sleep_delay: 1 hw.acpi.s4bios: 0 hw.acpi.verbose: 1 hw.acpi.reset_video: 1 hw.acpi.cpu.cx_supported: C1/0 hw.acpi.cpu.cx_lowest: C1 hw.acpi.cpu.cx_usage: 100.00% Dmesg after boot -v: ---------------------- Copyright (c) 1992-2005 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.4-RELEASE #0: Fri Aug 12 18:48:11 CEST 2005 Preloaded elf kernel "/boot/kernel/kernel" at 0xc0791000. Preloaded elf module "/boot/kernel/geom_mirror.ko" at 0xc0791200. Preloaded elf module "/boot/kernel/acpi.ko" at 0xc07912b0. Calibrating clock(s) ... i8254 clock: 1193174 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter "i8254" frequency 1193182 Hz quality 0 Calibrating TSC clock ... TSC clock: 801821583 Hz CPU: Intel Pentium III (801.82-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x686 Stepping = 6 Features=0x383f9ff real memory = 251641856 (239 MB) Physical memory chunk(s): 0x0000000000001000 - 0x000000000009efff, 647168 bytes (158 pages) 0x0000000000100000 - 0x00000000003fffff, 3145728 bytes (768 pages) 0x0000000000825000 - 0x000000000eb93fff, 238481408 bytes (58223 pages) avail memory = 240775168 (229 MB) bios32: Found BIOS32 Service Directory header at 0xc00f14a0 bios32: Entry = 0xf0e80 (c00f0e80) Rev = 0 Len = 1 pcibios: PCI BIOS entry at 0xf0000+0xeb0 pnpbios: Found PnP BIOS data at 0xc00fbee0 pnpbios: Entry = f0000:bf10 Rev = 1.0 pnpbios: OEM ID cd041 Other BIOS signatures found: null: random: mem: Pentium Pro MTRR support enabled io: npx0: [FAST] npx0: on motherboard npx0: INT 16 interface acpi0: on motherboard acpi0: [MPSAFE] pci_open(1): mode 1 addr port (0x0cf8) is 0x80000070 pci_open(1a): mode1res=0x80000000 (0x80000000) pci_cfgcheck: device 0 [class=060000] [hdr=80] is there (id=06301039) pcibios: BIOS version 2.10 Found $PIR table, 5 entries at 0xc00f1420 PCI-Only Interrupts: none Location Bus Device Pin Link IRQs embedded 1 0 A 0x41 3 4 5 7 9 10 11 12 embedded 0 1 A 0x41 3 4 5 7 9 10 11 12 embedded 0 1 B 0x42 3 4 5 7 9 10 11 12 embedded 0 1 C 0x43 3 4 5 7 9 10 11 12 embedded 0 1 D 0x44 3 4 5 7 9 10 11 12 slot 1 0 13 A 0x41 3 4 5 7 9 10 11 12 slot 1 0 13 B 0x42 3 4 5 7 9 10 11 12 slot 1 0 13 C 0x43 3 4 5 7 9 10 11 12 slot 1 0 13 D 0x44 3 4 5 7 9 10 11 12 slot 2 0 14 A 0x42 3 4 5 7 9 10 11 12 slot 2 0 14 B 0x43 3 4 5 7 9 10 11 12 slot 2 0 14 C 0x44 3 4 5 7 9 10 11 12 slot 2 0 14 D 0x41 3 4 5 7 9 10 11 12 embedded 0 5 A 0x43 3 4 5 7 9 10 11 12 acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: bus 0 dev 1 func 0 acpi0: Power Button (fixed) atpic: Programming IRQ9 as level/low ACPI timer: 1/1 1/1 1/1 1/1 1/1 1/1 1/1 1/1 1/1 1/1 -> 10 Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0xe408-0xe40b on acpi0 unknown: not probed (disabled) cpu0: on acpi0 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 ACPI PCI link initial configuration: \\_SB_.LNKA irq 0: [ 3 4 5 6 7 9 10 11 12 14 15] 11+ low,level,sharable 0.1.0 \\_SB_.LNKB irq 0: [ 3 4 5 6 7 9 10 11 12 14 15] 0+ low,level,sharable 0.1.1 \\_SB_.LNKC irq 0: [ 3 4 5 6 7 9 10 11 12 14 15] 10+ low,level,sharable 0.1.2 \\_SB_.LNKD irq 0: [ 3 4 5 6 7 9 10 11 12 14 15] 5+ low,level,sharable 0.1.3 \\_SB_.LNKA irq 0: [ 3 4 5 6 7 9 10 11 12 14 15] 11+ low,level,sharable 0.13.0 \\_SB_.LNKB irq 0: [ 3 4 5 6 7 9 10 11 12 14 15] 0+ low,level,sharable 0.13.1 \\_SB_.LNKC irq 0: [ 3 4 5 6 7 9 10 11 12 14 15] 10+ low,level,sharable 0.13.2 \\_SB_.LNKD irq 0: [ 3 4 5 6 7 9 10 11 12 14 15] 5+ low,level,sharable 0.13.3 \\_SB_.LNKB irq 0: [ 3 4 5 6 7 9 10 11 12 14 15] 0+ low,level,sharable 0.14.0 \\_SB_.LNKC irq 0: [ 3 4 5 6 7 9 10 11 12 14 15] 10+ low,level,sharable 0.14.1 \\_SB_.LNKD irq 0: [ 3 4 5 6 7 9 10 11 12 14 15] 5+ low,level,sharable 0.14.2 \\_SB_.LNKA irq 0: [ 3 4 5 6 7 9 10 11 12 14 15] 11+ low,level,sharable 0.14.3 \\_SB_.LNKC irq 0: [ 3 4 5 6 7 9 10 11 12 14 15] 10+ low,level,sharable 0.5.0 pci0: on pcib0 pci0: physical bus=0 map[10]: type 1, range 32, base ec000000, size 26, enabled found-> vendor=0x1039, dev=0x0630, revid=0x21 bus=0, slot=0, func=0 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0007, statreg=0x2210, cachelnsz=0 (dwords) lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) map[20]: type 4, range 32, base 0000d800, size 4, enabled found-> vendor=0x1039, dev=0x5513, revid=0xd0 bus=0, slot=0, func=1 class=01-01-80, hdrtype=0x00, mfdev=1 cmdreg=0x0007, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x80 (3840 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x1039, dev=0x0008, revid=0x00 bus=0, slot=1, func=0 class=06-01-00, hdrtype=0x00, mfdev=1 cmdreg=0x000f, statreg=0x0200, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) map[10]: type 4, range 32, base 0000d400, size 8, enabled map[14]: type 1, range 32, base eb800000, size 12, enabled pcib0: matched entry for 0.1.INTC (src \\_SB_.LNKC) pcib0: possible interrupts: 3 4 5 6 7 9 10 11 12 14 15 ACPI PCI link arbitrated settings: \\_SB_.LNKC (references 4, priority 46040): interrupts: 11 10 5 9 12 7 6 4 3 15 14 penalty: 130 130 180 260 5130 5130 5130 5130 5130 50130 50130 \\_SB_.LNKA (references 3, priority 34530): interrupts: 11 10 5 9 12 7 6 4 3 15 14 penalty: 130 130 180 260 5130 5130 5130 5130 5130 50130 50130 \\_SB_.LNKB (references 3, priority 34530): interrupts: 11 10 5 9 12 7 6 4 3 15 14 penalty: 130 130 180 260 5130 5130 5130 5130 5130 50130 50130 \\_SB_.LNKD (references 3, priority 34530): interrupts: 11 10 5 9 12 7 6 4 3 15 14 penalty: 130 130 180 260 5130 5130 5130 5130 5130 50130 50130 pcib0: slot 1 INTC routed to irq 10 via \\_SB_.LNKC found-> vendor=0x1039, dev=0x0900, revid=0x83 bus=0, slot=1, func=1 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x20 (960 ns), mingnt=0x34 (13000 ns), maxlat=0x0b (2750 ns) intpin=c, irq=10 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type 1, range 32, base eb000000, size 12, enabled pcib0: matched entry for 0.1.INTD (src \\_SB_.LNKD) pcib0: possible interrupts: 3 4 5 6 7 9 10 11 12 14 15 ACPI PCI link arbitrated settings: \\_SB_.LNKA (references 3, priority 34966): interrupts: 11 10 5 9 12 7 6 4 3 15 14 penalty: 260 300 310 520 5260 5260 5260 5260 5260 50260 50260 \\_SB_.LNKB (references 3, priority 34966): interrupts: 11 10 5 9 12 7 6 4 3 15 14 penalty: 260 300 310 520 5260 5260 5260 5260 5260 50260 50260 \\_SB_.LNKD (references 3, priority 34966): interrupts: 11 10 5 9 12 7 6 4 3 15 14 penalty: 260 300 310 520 5260 5260 5260 5260 5260 50260 50260 pcib0: slot 1 INTD routed to irq 5 via \\_SB_.LNKD found-> vendor=0x1039, dev=0x7001, revid=0x07 bus=0, slot=1, func=2 class=0c-03-10, hdrtype=0x00, mfdev=0 cmdreg=0x0017, statreg=0x0280, cachelnsz=8 (dwords) lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x50 (20000 ns) intpin=d, irq=5 map[10]: type 1, range 32, base ea800000, size 12, enabled pcib0: matched entry for 0.1.INTD (src \\_SB_.LNKD) pcib0: slot 1 INTD is already routed to irq 5 found-> vendor=0x1039, dev=0x7001, revid=0x07 bus=0, slot=1, func=3 class=0c-03-10, hdrtype=0x00, mfdev=0 cmdreg=0x0017, statreg=0x0280, cachelnsz=8 (dwords) lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x50 (20000 ns) intpin=d, irq=5 found-> vendor=0x1039, dev=0x0001, revid=0x00 bus=0, slot=2, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0007, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x08 (2000 ns), maxlat=0x00 (0 ns) map[10]: type 4, range 32, base 00009800, size 8, enabled pcib0: matched entry for 0.5.INTA (src \\_SB_.LNKC) pcib0: slot 5 INTA is already routed to irq 10 found-> vendor=0x13f6, dev=0x0111, revid=0x10 bus=0, slot=5, func=0 class=04-01-00, hdrtype=0x00, mfdev=0 cmdreg=0x0085, statreg=0x0210, cachelnsz=0 (dwords) lattimer=0x20 (960 ns), mingnt=0x02 (500 ns), maxlat=0x18 (6000 ns) intpin=a, irq=10 powerspec 2 supports D0 D1 D2 D3 current D0 agp0: mem 0xec000000-0xefffffff at device 0.0 on pci0 agp0: Reserved 0x4000000 bytes for rid 0x10 type 3 at 0xec000000 agp0: allocating GATT for aperture of size 64M atapci0: port 0xd800-0xd80f,0x376,0x170-0x177,0x3f6,0x1f0-0x1f7 at device 0.1 on pci0 atapci0: Reserved 0x10 bytes for rid 0x20 type 4 at 0xd800 ata0: channel #0 on atapci0 atapci0: Reserved 0x8 bytes for rid 0x10 type 4 at 0x1f0 atapci0: Reserved 0x1 bytes for rid 0x14 type 4 at 0x3f6 ata0: reset tp1 mask=03 ostat0=50 ostat1=00 ata0-master: stat=0x50 err=0x01 lsb=0x00 msb=0x00 ata0-slave: stat=0x00 err=0x01 lsb=0x00 msb=0x00 ata0: reset tp2 stat0=50 stat1=00 devices=0x1 ata0: [MPSAFE] ata1: channel #1 on atapci0 atapci0: Reserved 0x8 bytes for rid 0x18 type 4 at 0x170 atapci0: Reserved 0x1 bytes for rid 0x1c type 4 at 0x376 ata1: reset tp1 mask=03 ostat0=50 ostat1=00 ata1-master: stat=0x50 err=0x01 lsb=0x00 msb=0x00 ata1-slave: stat=0x00 err=0x01 lsb=0x00 msb=0x00 ata1: reset tp2 stat0=50 stat1=00 devices=0x1 ata1: [MPSAFE] isab0: at device 1.0 on pci0 isa0: on isab0 sis0: port 0xd400-0xd4ff mem 0xeb800000-0xeb800fff irq 10 at device 1.1 on pci0 sis0: Reserved 0x100 bytes for rid 0x10 type 4 at 0xd400 miibus0: on sis0 ukphy0: on miibus0 ukphy0: OUI 0x000760, model 0x0000, rev. 0 ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto sis0: bpf attached sis0: Ethernet address: 00:e0:18:5e:b5:93 sis0: [MPSAFE] ohci0: mem 0xeb000000-0xeb000fff irq 5 at device 1.2 on pci0 ohci0: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xeb000000 ohci0: [GIANT-LOCKED] usb0: OHCI version 1.0, legacy support usb0: on ohci0 usb0: USB revision 1.0 uhub0: SiS OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 3 ports with 3 removable, self powered ohci1: mem 0xea800000-0xea800fff irq 5 at device 1.3 on pci0 ohci1: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xea800000 ohci1: [GIANT-LOCKED] usb1: OHCI version 1.0, legacy support usb1: on ohci1 usb1: USB revision 1.0 uhub1: SiS OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered pcib1: at device 2.0 on pci0 pcib1: secondary bus 1 pcib1: subordinate bus 1 pcib1: I/O decode 0xa000-0xafff pcib1: memory decode 0xe9800000-0xe9ffffff pcib1: prefetched decode 0xf0000000-0xfeafffff ACPI PCI link initial configuration: \\_SB_.LNKA irq 0: [ 3 4 5 6 7 9 10 11 12 14 15] 11+ low,level,sharable 1.0.0 pci1: on pcib1 pci1: physical bus=1 map[10]: type 3, range 32, base f0000000, size 27, enabled pcib1: device (null) requested decoded memory range 0xf0000000-0xf7ffffff map[14]: type 1, range 32, base e9800000, size 17, enabled pcib1: device (null) requested decoded memory range 0xe9800000-0xe981ffff map[18]: type 4, range 32, base 0000a800, size 7, enabled pcib1: device (null) requested decoded I/O range 0xa800-0xa87f pcib1: matched entry for 1.0.INTA (src \\_SB_.LNKA) pcib1: possible interrupts: 3 4 5 6 7 9 10 11 12 14 15 ACPI PCI link arbitrated settings: \\_SB_.LNKA (references 4, priority 46712): interrupts: 11 10 5 9 12 7 6 4 3 15 14 penalty: 280 320 360 540 5280 5280 5280 5280 5280 50280 50280 \\_SB_.LNKB (references 3, priority 35034): interrupts: 11 10 5 9 3 4 6 7 12 14 15 penalty: 280 320 360 540 5280 5280 5280 5280 5280 50280 50280 pcib1: slot 0 INTA routed to irq 11 via \\_SB_.LNKA found-> vendor=0x1039, dev=0x6300, revid=0x21 bus=1, slot=0, func=0 class=03-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0003, statreg=0x02b0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 powerspec 1 supports D0 D1 D2 D3 current D0 pci1: at device 0.0 (no driver attached) pcm0: port 0x9800-0x98ff irq 10 at device 5.0 on pci0 pcm0: Reserved 0x100 bytes for rid 0x10 type 4 at 0x9800 pcm0: [MPSAFE] pcm0: sndbuf_setmap e9e7000, 4000; 0xcfd07000 -> e9e7000 pcm0: sndbuf_setmap e9e3000, 4000; 0xcfd0b000 -> e9e3000 unknown: not probed (disabled) unknown: not probed (disabled) ppc0: using extended I/O port range ppc0: ECP SPP ECP+EPP SPP ppc0: port 0x778-0x77b,0x378-0x37f irq 7 drq 3 on acpi0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/16 bytes threshold ppbus0: on ppc0 lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 sio0: irq maps: 0x1 0x11 0x1 0x1 sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A sio1: irq maps: 0x1 0x9 0x1 0x1 sio1: <16550A-compatible COM port> port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A unknown: not probed (disabled) unknown: not probed (disabled) unknown: not probed (disabled) atkbdc0: port 0x64,0x60 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 atkbd: the current kbd controller command byte 0047 atkbd: keyboard ID 0x41ab (2) kbd0 at atkbd0 kbd0: atkbd0, AT 101/102 (2), config:0x0, flags:0x3d0000 atkbd0: [GIANT-LOCKED] psm0: unable to allocate IRQ psmcpnp0: irq 12 on acpi0 psm0: current command byte:0047 psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: model Generic PS/2 mouse, device ID 0-00, 2 buttons psm0: config:00000000, flags:00000008, packet size:3 psm0: syncmask:c0, syncbits:00 unknown: not probed (disabled) unknown: not probed (disabled) unknown: not probed (disabled) unknown: not probed (disabled) unknown: not probed (disabled) unknown: not probed (disabled) ata: ata0 already exists; skipping it ata: ata1 already exists; skipping it atkbdc: atkbdc0 already exists; skipping it ppc: ppc0 already exists; skipping it sio: sio0 already exists; skipping it sio: sio1 already exists; skipping it Trying Read_Port at 203 Trying Read_Port at 243 Trying Read_Port at 283 Trying Read_Port at 2c3 Trying Read_Port at 303 Trying Read_Port at 343 Trying Read_Port at 383 Trying Read_Port at 3c3 sc: sc0 already exists; skipping it vga: vga0 already exists; skipping it isa_probe_children: disabling PnP devices isa_probe_children: probing non-PnP devices orm0: at iomem 0xc0000-0xcbfff on isa0 pmtimer0 on isa0 adv0: not probed (disabled) aha0: not probed (disabled) aic0: not probed (disabled) bt0: not probed (disabled) cs0: not probed (disabled) ed0: not probed (disabled) fdc0: cannot allocate I/O port (6 ports) fdc0 failed to probe at port 0x3f0 irq 6 drq 2 on isa0 fe0: not probed (disabled) ie0: not probed (disabled) lnc0: not probed (disabled) pcic0 failed to probe at port 0x3e0 iomem 0xd0000 on isa0 pcic1: not probed (disabled) fb: new array size 4 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sc0: fb0, kbd0, terminal emulator: sc (syscons terminal) sio2: not probed (disabled) sio3: not probed (disabled) sn0: not probed (disabled) vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 fb0: vga0, vga, type:VGA (5), flags:0x7007f fb0: port:0x3c0-0x3df, crtc:0x3d4, mem:0xa0000 0x20000 fb0: init mode:24, bios mode:3, current mode:24 fb0: window:0xc00b8000 size:32k gran:32k, buf:0 size:32k VGA parameters upon power-up 50 18 10 00 00 00 03 00 02 67 5f 4f 50 82 55 81 bf 1f 00 4f 0d 0e 00 00 07 80 9c 8e 8f 28 1f 96 b9 a3 ff 00 01 02 03 04 05 14 07 38 39 3a 3b 3c 3d 3e 3f 0c 00 0f 08 00 00 00 00 00 10 0e 00 ff VGA parameters in BIOS for mode 24 50 18 10 00 10 00 03 00 02 67 5f 4f 50 82 55 81 bf 1f 00 4f 0d 0e 00 00 00 00 9c 8e 8f 28 1f 96 b9 a3 ff 00 01 02 03 04 05 14 07 38 39 3a 3b 3c 3d 3e 3f 0c 00 0f 08 00 00 00 00 00 10 0e 00 ff EGA/VGA parameters to be used for mode 24 50 18 10 00 10 00 03 00 02 67 5f 4f 50 82 55 81 bf 1f 00 4f 0d 0e 00 00 00 00 9c 8e 8f 28 1f 96 b9 a3 ff 00 01 02 03 04 05 14 07 38 39 3a 3b 3c 3d 3e 3f 0c 00 0f 08 00 00 00 00 00 10 0e 00 ff vt0: not probed (disabled) isa_probe_children: probing PnP devices Device configuration finished. procfs registered Timecounter "TSC" frequency 801821583 Hz quality 800 Timecounters tick every 10.000 msec lo0: bpf attached ata0-master: pio=0x0c wdma=0x22 udma=0x45 cable=80pin ata0-master: setting PIO4 on SiS 630 chip ata0-master: setting UDMA66 on SiS 630 chip ad0: ATA-7 disk at ata0-master ad0: 152627MB (312581808 sectors), 310101 C, 16 H, 63 S, 512 B ad0: 16 secs/int, 1 depth queue, UDMA66 GEOM: new disk ad0 ata1-master: pio=0x0c wdma=0x22 udma=0x45 cable=80pin ata1-master: setting PIO4 on SiS 630 chip ata1-master: setting UDMA66 on SiS 630 chip ad2: ATA-7 disk at ata1-master ad2: 152627MB (312581808 sectors), 310101 C, 16 H, 63 S, 512 B ad2: 16 secs/int, 1 depth queue, UDMA66 GEOM_MIRROR: Device gm0 created (id=4283719881). GEOM_MIRROR: Device gm0: provider ad0 detected. [0] f:80 typ:165 s(CHS):0/1/1 e(CHS):1023/254/63 s:63 l:312576642 [1] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [2] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [3] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 GEOM: Configure ad0s1, start 32256 length 160039240704 end 160039272959 GEOM: new disk ad2 GEOM_MIRROR: Device gm0: provider ad2 detected. GEOM_MIRROR: Device gm0: provider ad2 activated. GEOM_MIRROR: Device gm0: provider ad0 activated. GEOM_MIRROR: Device gm0: provider mirror/gm0 launched. [0] f:80 typ:165 s(CHS):0/1/1 e(CHS):1023/254/63 s:63 l:312576642 [1] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [2] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [3] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 GEOM: Configure ad2s1, start 32256 length 160039240704 end 160039272959 [0] f:80 typ:165 s(CHS):0/1/1 e(CHS):1023/254/63 s:63 l:312576642 [1] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [2] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [3] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 GEOM: Configure mirror/gm0s1, start 32256 length 160039240704 end 160039272959 [0] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [1] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [2] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [3] f:80 typ:165 s(CHS):0/0/1 e(CHS):1023/254/63 s:0 l:50000 GEOM: Configure mirror/gm0s1a, start 0 length 268435456 end 268435455 GEOM: Configure mirror/gm0s1b, start 268435456 length 477011968 end 745447423 GEOM: Configure mirror/gm0s1c, start 0 length 160039240704 end 160039240703 GEOM: Configure mirror/gm0s1d, start 745447424 length 268435456 end 1013882879 GEOM: Configure mirror/gm0s1e, start 1013882880 length 268435456 end 1282318335 GEOM: Configure mirror/gm0s1f, start 1282318336 length 8589934592 end 9872252927 GEOM: Configure mirror/gm0s1g, start 9872252928 length 150166987776 end 160039240703 [0] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [1] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [2] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [3] f:80 typ:165 s(CHS):0/0/1 e(CHS):1023/254/63 s:0 l:50000 [0] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [1] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [2] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [3] f:80 typ:165 s(CHS):0/0/1 e(CHS):1023/254/63 s:0 l:50000 Mounting root from ufs:/dev/mirror/gm0s1a start_init: trying /sbin/init ----------------end dmesg------------- greetings, Sebastian Pahlke From owner-freebsd-acpi@FreeBSD.ORG Sat Aug 13 16:16:53 2005 Return-Path: X-Original-To: freebsd-acpi@freebsd.org Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F296716A41F for ; Sat, 13 Aug 2005 16:16:52 +0000 (GMT) (envelope-from colazelli@gmail.com) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.200]) by mx1.FreeBSD.org (Postfix) with ESMTP id 823D243D46 for ; Sat, 13 Aug 2005 16:16:52 +0000 (GMT) (envelope-from colazelli@gmail.com) Received: by wproxy.gmail.com with SMTP id i22so753513wra for ; Sat, 13 Aug 2005 09:16:51 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:x-accept-language:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=kAlC/jZySPSHW7HNJqpnH+gz2jJqEI7LVVnlZNKk0T/+qJpFoRDJsysQRXRDp4XisVidWk+m97U/tPy6Bfa/8ICATY5p2zEfszh9/zsgvRZrZcGkS1aFB7hZ7fV33jn07x97ClPatXWBM/lJQfDhnbHve+PLSn4In9EZ4J7MeT8= Received: by 10.54.143.7 with SMTP id q7mr2585366wrd; Sat, 13 Aug 2005 09:16:51 -0700 (PDT) Received: from ?192.168.1.10? ([200.158.149.220]) by mx.gmail.com with ESMTP id 26sm1463586wrl.2005.08.13.09.16.50; Sat, 13 Aug 2005 09:16:51 -0700 (PDT) Message-ID: <42FDF2C0.8040100@gmail.com> Date: Sat, 13 Aug 2005 10:16:48 -0300 From: Wesley Gentine User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050805) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Nate Lawson References: <42FCFFAB.9060006@gmail.com> <42FD1079.3020607@root.org> In-Reply-To: <42FD1079.3020607@root.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@freebsd.org Subject: Re: acpi_fujitsu doesnt work 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, 13 Aug 2005 16:16:53 -0000 Nate Lawson wrote: > Wesley Gentine wrote: > >> I have a Fujitsu FmV Biblo MG50H (japanese) and I tried to compile >> acpi_fujitsu inside kernel and nothing happened. But loading kernel >> module I have the following output: >> >> acpi_fujitsu0: on acpi0 >> acpi_fujitsu0: Couldn't query volume level >> acpi_fujitsu0: Couldn't init button states >> acpi_fujitsu0: Couldn't initialize button states! > > > It appears your system has a different version of the fujitsu button > hardware. Post the url of your ASL, acpidump -t -d > fmv-mg50h.asl > >> I have another question. Is est0 compatible with Celeron M? Because >> it only recognized p4tcc0 and ichss0 that id had to disable. (Celeron >> M doesnt support this feature). > > > No, est is not supported by Celeron M. > Thanks Nate, I inserted this file in a URL: http://crystalwall.sites.uol.com.br/fmv-mg50h.asl Best Regards, Wesley Gentine From owner-freebsd-acpi@FreeBSD.ORG Sat Aug 13 16:21:32 2005 Return-Path: X-Original-To: freebsd-acpi@freebsd.org Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8195616A41F for ; Sat, 13 Aug 2005 16:21:32 +0000 (GMT) (envelope-from colazelli@gmail.com) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.206]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1144F43D48 for ; Sat, 13 Aug 2005 16:21:31 +0000 (GMT) (envelope-from colazelli@gmail.com) Received: by wproxy.gmail.com with SMTP id i5so741527wra for ; Sat, 13 Aug 2005 09:21:31 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:x-accept-language:mime-version:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=a4GOz1kGFGM/wKyehesxxB+UQF8Uy2CFtaJwB7qF8adgnzmK9tjWMSuIX6+QD/PK+sSe7d8HympspwjkwILgEX17u/R/S4WxvHQBbSv6ixpC41hDhMEsXc0hkSMPoMU4TwjaZgi8hQEZAQ0kMptJ5QjJzOmaz3S3Pv00KPVwUs0= Received: by 10.54.21.9 with SMTP id 9mr2613032wru; Sat, 13 Aug 2005 09:21:30 -0700 (PDT) Received: from ?192.168.1.10? ([200.158.149.220]) by mx.gmail.com with ESMTP id 43sm536557wri.2005.08.13.09.21.26; Sat, 13 Aug 2005 09:21:27 -0700 (PDT) Message-ID: <42FDF3CF.9060605@gmail.com> Date: Sat, 13 Aug 2005 10:21:19 -0300 From: Wesley Gentine User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050805) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <42FCFFAB.9060006@gmail.com> <42FD1079.3020607@root.org> <42FDF2C0.8040100@gmail.com> In-Reply-To: <42FDF2C0.8040100@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@freebsd.org Subject: Re: acpi_fujitsu doesnt work 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, 13 Aug 2005 16:21:32 -0000 Wesley Gentine wrote: > Nate Lawson wrote: > >> Wesley Gentine wrote: >> >>> I have a Fujitsu FmV Biblo MG50H (japanese) and I tried to compile >>> acpi_fujitsu inside kernel and nothing happened. But loading kernel >>> module I have the following output: >>> >>> acpi_fujitsu0: on acpi0 >>> acpi_fujitsu0: Couldn't query volume level >>> acpi_fujitsu0: Couldn't init button states >>> acpi_fujitsu0: Couldn't initialize button states! >> >> >> >> It appears your system has a different version of the fujitsu button >> hardware. Post the url of your ASL, acpidump -t -d > fmv-mg50h.asl >> >>> I have another question. Is est0 compatible with Celeron M? Because >>> it only recognized p4tcc0 and ichss0 that id had to disable. >>> (Celeron M doesnt support this feature). >> >> >> >> No, est is not supported by Celeron M. >> > Thanks Nate, > > I inserted this file in a URL: > http://crystalwall.sites.uol.com.br/fmv-mg50h.asl > > Best Regards, > > Wesley Gentine > Sorry, Use this file: http://crystalwall.sites.uol.com.br/fmv-mg50h.asl.html Thanks, Wesley Gentine