From owner-freebsd-acpi@FreeBSD.ORG Sun Feb 13 00:22:00 2005 Return-Path: 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 51A4616A4CE for ; Sun, 13 Feb 2005 00:22:00 +0000 (GMT) Received: from ylpvm29.prodigy.net (ylpvm29-ext.prodigy.net [207.115.57.60]) by mx1.FreeBSD.org (Postfix) with ESMTP id C0FDC43D2F for ; Sun, 13 Feb 2005 00:21:57 +0000 (GMT) (envelope-from nate@root.org) Received: from [10.0.5.51] (adsl-64-171-186-189.dsl.snfc21.pacbell.net [64.171.186.189])j1D0Lch2026996; Sat, 12 Feb 2005 19:21:38 -0500 Message-ID: <420E9D9D.3010908@root.org> Date: Sat, 12 Feb 2005 16:21:49 -0800 From: Nate Lawson User-Agent: Mozilla Thunderbird 1.0RC1 (X11/20041205) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Frank References: <420E5B85.1050404@deze.org> In-Reply-To: <420E5B85.1050404@deze.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: acpi@freebsd.org Subject: Re: Ethernet cards not working - Interrrupt routing problem? X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Feb 2005 00:22:00 -0000 Frank wrote: > [I posted this message on -STABLE yesterday, but I got a mail, > that I should try this mailing list instead. Also I forgot to > mention that the machine in question is a Fujitsu Siemens > Primergy RX300 -- thanks for any advice, Frank] > > I have a weird problem with hardware that runs fine under FreeBSD 4.9 > but is unusable under FreeBSD 5.3. The problem concentrates apparently > arround interrupt assignments, the Adaptec scsci card in combination > with the Ethernet cards. The difference is that 4.9 doesn't support full IOAPIC, 5.x does. The first thing you should do is upgrade your BIOS to the latest stable version. There were some problems with older ServerWorks BIOSen. If that doesn't work, send dmesg from boot -v. > ACPI APIC Table: > Timecounter "i8254" frequency 1193182 Hz quality 0 > CPU: Intel(R) Xeon(TM) CPU 2.66GHz (2666.78-MHz 686-class CPU) > Origin = "GenuineIntel" Id = 0xf29 Stepping = 9 > Hyperthreading: 2 logical CPUs > real memory = 536870912 (512 MB) > avail memory = 515682304 (491 MB) > ioapic0 irqs 0-15 on motherboard > ioapic1 irqs 16-31 on motherboard > npx0: on motherboard > npx0: INT 16 interface > acpi0: on motherboard Yep, ServerWorks which we all know and love. :) -- Nate From owner-freebsd-acpi@FreeBSD.ORG Sun Feb 13 05:39:21 2005 Return-Path: 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 ED80B16A4CE for ; Sun, 13 Feb 2005 05:39:21 +0000 (GMT) Received: from ylpvm15.prodigy.net (ylpvm15-ext.prodigy.net [207.115.57.46]) by mx1.FreeBSD.org (Postfix) with ESMTP id A34C843D1F for ; Sun, 13 Feb 2005 05:39:21 +0000 (GMT) (envelope-from nate@root.org) Received: from [10.0.0.115] (adsl-64-171-186-189.dsl.snfc21.pacbell.net [64.171.186.189])j1D5Z6bs021875; Sun, 13 Feb 2005 00:35:07 -0500 Message-ID: <420EE804.8030805@root.org> Date: Sat, 12 Feb 2005 21:39:16 -0800 From: Nate Lawson User-Agent: Mozilla Thunderbird 1.0RC1 (X11/20041205) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Stephane E. Potvin" References: <42068A5C.1030300@root.org> <4206D5C6.1060109@videotron.ca> In-Reply-To: <4206D5C6.1060109@videotron.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: acpi@freebsd.org Subject: Re: HEADSUP: cpufreq import complete, acpi_throttling changed X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Feb 2005 05:39:22 -0000 Stephane E. Potvin wrote: > I've lost cpu throttling with this commit on my Dell Inspiron XPS. The > acpi_throttle driver doesn't probe correctly on the HT cpu which seems > to cause some problems. > > ... > acpi0: on motherboard > cpu0: on acpi0 > acpi_throttle0: on cpu0 > cpu1: on acpi0 > cpu1: acpi_throttle: add child failed > ... Ok, I committed a patch just now that should fix your problem. Let me know if it doesn't work. The acpi_throttle driver wasn't registering with cpufreq(4) but on systems with other methods, their registration allowed things to work. -- Nate From owner-freebsd-acpi@FreeBSD.ORG Sun Feb 13 18:59:24 2005 Return-Path: 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 341E916A4CE; Sun, 13 Feb 2005 18:59:24 +0000 (GMT) Received: from ylpvm01.prodigy.net (ylpvm01-ext.prodigy.net [207.115.57.32]) by mx1.FreeBSD.org (Postfix) with ESMTP id B989C43D46; Sun, 13 Feb 2005 18:59:23 +0000 (GMT) (envelope-from nate@root.org) Received: from [10.0.0.115] (adsl-64-171-186-189.dsl.snfc21.pacbell.net [64.171.186.189])j1DIxMvE021892; Sun, 13 Feb 2005 13:59:22 -0500 Message-ID: <420FA38A.6080009@root.org> Date: Sun, 13 Feb 2005 10:59:22 -0800 From: Nate Lawson User-Agent: Mozilla Thunderbird 1.0RC1 (X11/20041205) X-Accept-Language: en-us, en MIME-Version: 1.0 To: acpi@FreeBSD.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: current@FreeBSD.org Subject: [Fwd: cvs commit: src/sys/dev/acpica acpi_perf.c src/sys/kern kern_cpu.c] X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Feb 2005 18:59:24 -0000 The commit below allows acpi_perf(4) to attach to FFixedHW devices and export settings to other drivers (say, EST and Powernow). The code snippet for foo_probe() to do this is as follows: /* Find an acpi_perf child under our common parent. */ device_t child; child = device_find_child(device_get_parent(dev), "acpi_perf", -1); if (child == NULL || !device_is_attached(child)) ... do whatever you can from static tables or fail ... /* Get its settings so we know what frequencies it offers. */ error = CPUFREQ_DRV_SETTINGS(child, sets, &count, &type); if (error) ... fall back to static tables ... /* * If the device is not offering info, it thinks it can control * settings itself. We fail out of our probe in this case since * it is already in charge. */ if ((type & CPUFREQ_FLAG_INFO_ONLY) == 0) return (ENXIO); /* Loop through all settings and match up to our levels */ for () powernow_sets[i].freq = sets[i].freq powernow_sets[i].power = sets[i].power; ... -------- Original Message -------- njl 2005-02-13 18:49:48 UTC FreeBSD src repository Modified files: sys/dev/acpica acpi_perf.c sys/kern kern_cpu.c Log: Add support for the CPUFREQ_FLAG_INFO_ONLY flag. Devices that report this are not added to the list(s) of available settings. However, other drivers can call the CPUFREQ_DRV_SETTINGS() method on those devices directly to get info about available settings. Update the acpi_perf(4) driver to use this flag in the presence of "functional fixed hardware." Thus, future drivers like Powernow can query acpi_perf for platform info but perform frequency transitions themselves. Revision Changes Path 1.7 +39 -12 src/sys/dev/acpica/acpi_perf.c 1.4 +8 -1 src/sys/kern/kern_cpu.c -- Nate From owner-freebsd-acpi@FreeBSD.ORG Sun Feb 13 20:04:20 2005 Return-Path: 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 4B5FE16A4CE for ; Sun, 13 Feb 2005 20:04:20 +0000 (GMT) Received: from ylpvm15.prodigy.net (ylpvm15-ext.prodigy.net [207.115.57.46]) by mx1.FreeBSD.org (Postfix) with ESMTP id E74FE43D54 for ; Sun, 13 Feb 2005 20:04:19 +0000 (GMT) (envelope-from nate@root.org) Received: from [10.0.0.115] (adsl-64-171-186-189.dsl.snfc21.pacbell.net [64.171.186.189])j1DK05bs005959; Sun, 13 Feb 2005 15:00:05 -0500 Message-ID: <420FB25B.8010106@root.org> Date: Sun, 13 Feb 2005 12:02:35 -0800 From: Nate Lawson User-Agent: Mozilla Thunderbird 1.0RC1 (X11/20041205) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Alexandre \"Sunny\" Kovalenko" References: <1107914318.1015.15.camel@RabbitsDen> In-Reply-To: <1107914318.1015.15.camel@RabbitsDen> Content-Type: text/plain; charset=ISO-8859-5; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-acpi@freebsd.org Subject: Re: Thermal state switching X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Feb 2005 20:04:20 -0000 Alexandre "Sunny" Kovalenko wrote: > Good people, > > I was looking at thermal states switching by acpi_thermal.c and it looks > like follows (provided that temperature raises and falls slowly and > gradually): > > NONE =up> AC2 =up> AC1 =up> AC0 =down> NONE (1) > > I do not know whether this was intentional or not and, for me, something > along the lines of > > NONE =up> AC2 =up> AC1 =up> AC0 =down> AC1 =down> AC2 =down> NONE (2) > > seemed more natural. > > If (2) and not (1) was indeed the desired behavior attached patch seems > to do the job. If (1) is what was intended, I do apologize for the > noise. > > I am running -CURRENT from February 3. The behavior should be as in #2. If it isn't, we should fix that. However, I'm not sure how your patch would fix this. It seems more correct in that we only set the starting time after switching coolers but I don't see how this affects the ACx levels. Could you explain more? Thanks, -- Nate From owner-freebsd-acpi@FreeBSD.ORG Sun Feb 13 20:34:20 2005 Return-Path: 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 30C7A16A4CE; Sun, 13 Feb 2005 20:34:20 +0000 (GMT) Received: from ylpvm01.prodigy.net (ylpvm01-ext.prodigy.net [207.115.57.32]) by mx1.FreeBSD.org (Postfix) with ESMTP id C701043D39; Sun, 13 Feb 2005 20:34:19 +0000 (GMT) (envelope-from nate@root.org) Received: from [10.0.0.115] (adsl-64-171-186-189.dsl.snfc21.pacbell.net [64.171.186.189])j1DKYHvE031959; Sun, 13 Feb 2005 15:34:18 -0500 Message-ID: <420FB9C9.8010106@root.org> Date: Sun, 13 Feb 2005 12:34:17 -0800 From: Nate Lawson User-Agent: Mozilla Thunderbird 1.0RC1 (X11/20041205) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ewald Jenisch References: <20041122160803.GA16224@athena.oekb.co.at> In-Reply-To: <20041122160803.GA16224@athena.oekb.co.at> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-acpi@freebsd.org cc: freebsd-questions@freebsd.org Subject: Re: Machine refuses to boot with ACPI enabled by default X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Feb 2005 20:34:20 -0000 Ewald Jenisch wrote: > I've got a strange problem wrt. ACPI on one of my boxes under FreeBSD > 5.3: The box comes up with ACPI *disabled* by default. > > Only by manually selecting the menu option that says "Boot with ACPI > enabled" can I make the box run ACPI which is kinda annoying when > e.g. I remotely reboot the box - after the reboot it comes up without > ACPI and as a consequence SMP turned off. > > To cross check that it's not a config issue I've "diffed" the files in > /boot between the machine in question and another one that runs with > ACPI enabled by default - absolutely no differences. One box > (different hardware) runs with ACPI, this one runs with ACPI disabled > by default. Sorry about the long reply time. > So my questions are: > > 1) How can I make this box boot with ACPI enabled by default? In your /boot/loader.conf, set: hint.acpi.0.disabled="0" > 2) Why does this box come up without ACPI by default after all? I checked the quirks table and found nothing that should match your machine. Can you send a full dmesg of booting when acpi is automatically disabled? There's usually a quirk message printed if this is the case. -- Nate From owner-freebsd-acpi@FreeBSD.ORG Sun Feb 13 21:46:06 2005 Return-Path: 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 A0C6C16A4DB for ; Sun, 13 Feb 2005 21:46:06 +0000 (GMT) Received: from ylpvm01.prodigy.net (ylpvm01-ext.prodigy.net [207.115.57.32]) by mx1.FreeBSD.org (Postfix) with ESMTP id 43C9A43D2F for ; Sun, 13 Feb 2005 21:46:06 +0000 (GMT) (envelope-from nate@root.org) Received: from [10.0.0.115] (adsl-64-171-186-189.dsl.snfc21.pacbell.net [64.171.186.189])j1DLk4vE026568; Sun, 13 Feb 2005 16:46:05 -0500 Message-ID: <420FCA9C.9020809@root.org> Date: Sun, 13 Feb 2005 13:46:04 -0800 From: Nate Lawson User-Agent: Mozilla Thunderbird 1.0RC1 (X11/20041205) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ewald Jenisch References: <20050209100953.GA717@aurora.oekb.co.at> In-Reply-To: <20050209100953.GA717@aurora.oekb.co.at> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-acpi@freebsd.org Subject: Re: HP d530 - no ACPI per default? thermal missing? X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Feb 2005 21:46:06 -0000 Ewald Jenisch wrote: > Hi, > > I've got a rather strange problem with one of my machines: > > 1) The system comes up with ACPI disabled per default; i.e. from the > loader menu the default entry starts up with ACPI turned off. Only > when I manually select "start with ACPI enabled" from the loader-menu > I get ACPI enabled, i.e. acpi.ko loaded. > > Sure enough when I set "acpi_load="YES"" in /boot/loader.conf I can > force ACPI to be loaded but I wonder why doesn't this box come up with > ACPI turned on like almost all recent machines? I just replied to your old message separately. It looks like acpi isn't even being loaded, not that a quirk is disabling it. Since that has nothing to do with acpi, you should check your loader settings. Is your /boot/loader new enough? Perhaps this is a failure in upgrading from 4.x? > 2) When running with ACPI enabled I noticed that the output of "sysctl > -a" doesn't show anything about the "thermal"-part of ACPI. Is this > OK? Shouldn't it be there once ACPI is enabled= That is normal for systems that don't export thermal info to ACPI. In this case, your BIOS should handle the fan. -- Nate From owner-freebsd-acpi@FreeBSD.ORG Sun Feb 13 23:13:07 2005 Return-Path: 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 BC95616A4CE; Sun, 13 Feb 2005 23:13:07 +0000 (GMT) Received: from postal1.es.net (postal1.es.net [198.128.3.205]) by mx1.FreeBSD.org (Postfix) with ESMTP id 891F143D39; Sun, 13 Feb 2005 23:13:07 +0000 (GMT) (envelope-from oberman@es.net) Received: from ptavv.es.net ([198.128.4.29]) by postal1.es.net (Postal Node 1) with ESMTP (SSL) id IBA74465; Sun, 13 Feb 2005 15:13:07 -0800 Received: from ptavv (localhost [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id 376E05D07; Sun, 13 Feb 2005 15:13:06 -0800 (PST) To: Nate Lawson In-reply-to: Your message of "Sun, 06 Feb 2005 13:21:32 PST." <42068A5C.1030300@root.org> Date: Sun, 13 Feb 2005 15:13:06 -0800 From: "Kevin Oberman" Message-Id: <20050213231306.376E05D07@ptavv.es.net> cc: acpi@freebsd.org cc: current@freebsd.org Subject: Re: HEADSUP: cpufreq import complete, acpi_throttling changed X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Feb 2005 23:13:07 -0000 > Date: Sun, 06 Feb 2005 13:21:32 -0800 > From: Nate Lawson > Sender: owner-freebsd-acpi@freebsd.org > > I've finished the major work of importing cpufreq. As part of this, the > sysctls for acpi throttling have been removed. The power_profile script > has been updated, so you can use performance/economy_cpu_freq= in > rc.conf to set AC on/offline cpu frequencies. The acpi throttling > support has been compiled into acpi_perf.ko so load that to get > throttling. Do a sysctl dev.cpu to get an understanding of the cpufreq > sysctls. > > If you have throttling, please test the new configuration to be sure it > still works as before. Final upcoming work will be manpage support and > bugfixing as necessary. On my T30, throttling has simply vanished. Kernel sources as of this afternoon at about 11:00 PST. Id Refs Address Size Name 1 24 0xc0400000 3ba9c4 kernel 2 1 0xc07bb000 1e4b0 if_wi.ko 3 1 0xc07da000 4ce4 acpi_video.ko 4 18 0xc07df000 53650 acpi.ko 5 1 0xc0833000 32a0 cpufreq.ko 6 1 0xc0837000 3b8c acpi_ibm.ko 7 1 0xc083b000 49c0 acpi_perf.ko 8 1 0xc0840000 2ca8 wlan_wep.ko 9 1 0xc1d04000 a000 ntfs.ko 10 1 0xc1d83000 6000 linprocfs.ko 11 1 0xc1d89000 15000 linux.ko 12 1 0xc1dab000 3000 fdescfs.ko 13 1 0xc1e54000 3000 daemon_saver.ko sysctl hw.acpi does not list any throttling entries at all. It does list an amazing number of frequency settings, but only 1800 and 1200 seem to actually work. Perhaps the others are derived by mixing the two capabilities? On the earlier versions of cpufreq I was getting only the two frequencies listed along with the 8 throttling states. Did I miss a message on this? I am especially concerned because my CPU is now running VERY hot when busy. It never used to exceed about 180F and now it quickly jumps to 190+ when the system is working (such as a buildkernel). Since it was previously running without throttling, I don't understand why things are suddenly worse. Any idea on what is happening? I don't want to fry my T30. dmesg and config available on request. -- 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 Sun Feb 13 23:33:38 2005 Return-Path: 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 DA2A116A4D7; Sun, 13 Feb 2005 23:33:38 +0000 (GMT) Received: from www.cryptography.com (li-22.members.linode.com [64.5.53.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4472843D1F; Sun, 13 Feb 2005 23:33:38 +0000 (GMT) (envelope-from nate@root.org) Received: from [10.0.0.250] (adsl-64-171-186-189.dsl.snfc21.pacbell.net [64.171.186.189]) by www.cryptography.com (8.12.8/8.12.8) with ESMTP id j1DNXSZj000976 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 13 Feb 2005 15:33:29 -0800 Message-ID: <420FE3C7.6020003@root.org> Date: Sun, 13 Feb 2005 15:33:27 -0800 From: Nate Lawson User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Kevin Oberman References: <20050213231306.376E05D07@ptavv.es.net> In-Reply-To: <20050213231306.376E05D07@ptavv.es.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: acpi@freebsd.org cc: current@freebsd.org Subject: Re: HEADSUP: cpufreq import complete, acpi_throttling changed X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Feb 2005 23:33:39 -0000 Kevin Oberman wrote: >>Date: Sun, 06 Feb 2005 13:21:32 -0800 >>From: Nate Lawson >>Sender: owner-freebsd-acpi@freebsd.org >> >> >>If you have throttling, please test the new configuration to be sure it >>still works as before. Final upcoming work will be manpage support and >>bugfixing as necessary. > > > On my T30, throttling has simply vanished. Kernel sources as of this > afternoon at about 11:00 PST. > > sysctl hw.acpi does not list any throttling entries at all. It shouldn't, they were merged into the sysctl dev.cpu output as you mention below. > It does list an amazing number of frequency settings, but only 1800 and > 1200 seem to actually work. Perhaps the others are derived by mixing the > two capabilities? On the earlier versions of cpufreq I was getting only > the two frequencies listed along with the 8 throttling states. > > Did I miss a message on this? Try cvsupping to now. I did some commits about an hour or two ago that should address throttling not attaching. > I am especially concerned because my CPU is now running VERY hot when > busy. It never used to exceed about 180F and now it quickly jumps to > 190+ when the system is working (such as a buildkernel). Since it was > previously running without throttling, I don't understand why things are > suddenly worse. > > Any idea on what is happening? I don't want to fry my T30. One person reported Cx states being broken by the cpufreq import. (Well, actually he got a C3 state that he didn't have before but it didn't work.) Try setting hw.acpi.cpu.cx_lowest to C1 or something you're sure works. Send me the output of sysctl dev.cpu, dmesg, and devinfo -rv. -- Nate From owner-freebsd-acpi@FreeBSD.ORG Mon Feb 14 03:00:46 2005 Return-Path: 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 7094D16A4D0 for ; Mon, 14 Feb 2005 03:00:46 +0000 (GMT) Received: from mh2.centtech.com (moat3.centtech.com [207.200.51.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5611A43D1F for ; Mon, 14 Feb 2005 03:00:34 +0000 (GMT) (envelope-from anderson@centtech.com) Received: from [192.168.42.24] (andersonbox4.centtech.com [192.168.42.24]) by mh2.centtech.com (8.13.1/8.13.1) with ESMTP id j1E30XxH015560 for ; Sun, 13 Feb 2005 21:00:33 -0600 (CST) (envelope-from anderson@centtech.com) Message-ID: <4210144C.8080007@centtech.com> Date: Sun, 13 Feb 2005 21:00:28 -0600 From: Eric Anderson User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.5) Gecko/20050210 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-acpi@freebsd.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.80/585/Thu Nov 11 06:22:42 2004 clamav-milter version 0.80j on mh2.centtech.com X-Virus-Status: Clean Subject: Dell D600 S4BIOS - working? X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Feb 2005 03:00:46 -0000 I have a Dell Latitude D600, running -STABLE. I've heard S4BIOS works on this laptop, with the correct setup.. Here's my setup (not working): (partition 1 is supposed to be my hibernate partition): # fdisk ad0 The data for partition 1 is: sysid 132 (0x84),(OS/2 hidden C: drive) start 63, size 1654632 (807 Meg), flag 0 beg: cyl 0/ head 1/ sector 1; end: cyl 102/ head 254/ sector 63 The data for partition 2 is: sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD) start 1654695, size 75489435 (36860 Meg), flag 80 (active) beg: cyl 103/ head 0/ sector 1; end: cyl 1023/ head 254/ sector 63 The data for partition 3 is: sysid 12 (0x0c),(DOS or Windows 95 with 32 bit FAT (LBA)) start 77144130, size 20482875 (10001 Meg), flag 0 beg: cyl 1023/ head 254/ sector 63; end: cyl 1023/ head 254/ sector 63 The data for partition 4 is: sysid 15 (0x0f),(Extended DOS (LBA)) start 97627005, size 58669380 (28647 Meg), flag 0 beg: cyl 1023/ head 254/ sector 63; end: cyl 1023/ head 254/ sector 63 sysctl stuff: hw.acpi.supported_sleep_state: S1 S3 S4 S5 hw.acpi.power_button_state: S5 hw.acpi.sleep_button_state: S1 hw.acpi.lid_switch_state: NONE hw.acpi.standby_state: S1 hw.acpi.suspend_state: S3 hw.acpi.sleep_delay: 1 hw.acpi.s4bios: 1 Has anyone gotten this to work? Does anyone know if I even have the right partition setup? Eric -- ------------------------------------------------------------------------ Eric Anderson Sr. Systems Administrator Centaur Technology I have seen the future and it is just like the present, only longer. ------------------------------------------------------------------------ From owner-freebsd-acpi@FreeBSD.ORG Mon Feb 14 10:46:10 2005 Return-Path: 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 ECA0716A4CE for ; Mon, 14 Feb 2005 10:46:10 +0000 (GMT) Received: from mx2.nl.atosorigin.com (mx2.nl.atosorigin.com [212.159.203.210]) by mx1.FreeBSD.org (Postfix) with ESMTP id E70B743D1F for ; Mon, 14 Feb 2005 10:46:08 +0000 (GMT) (envelope-from Frank.Volf@atosorigin.com) Received: from nlav01.nl.atosorigin.com ([161.90.121.88]) by mx2.nl.atosorigin.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 14 Feb 2005 11:46:07 +0100 Received: from nodnsquery(161.90.121.93) by nlav01.nl.atosorigin.com via csmap id 9d6ed75c_7e75_11d9_8b1e_00304811c359_16117; Mon, 14 Feb 2005 11:46:00 +0100 (CET) Received: from nlex003.europe.nl.intra ([161.90.126.16]) by nlex100.europe.nl.intra with Microsoft SMTPSVC(5.0.2195.6713); Mon, 14 Feb 2005 11:45:06 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 14 Feb 2005 11:45:05 +0100 Message-ID: <9FAFEFB20AA5374391ED09FE09EE5885775CE7@nlex003.nl.int.atosorigin.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Ethernet cards not working - Interrrupt routing problem? Thread-Index: AcUSgjwaKzAK5VOxTyKQ8aHk5/iumg== From: "Volf, Frank" To: "Nate Lawson" X-OriginalArrivalTime: 14 Feb 2005 10:45:06.0074 (UTC) FILETIME=[3EEDAFA0:01C51282] cc: acpi@freebsd.org Subject: RE: Ethernet cards not working - Interrrupt routing problem? X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Feb 2005 10:46:11 -0000 Hi Nate, Thanks for your reply, here is the boot -v that you requested (upgrading the BIOS was a NO-OP since we were already running the latest version. I can't make heads-or-tails of this, hopefully you can find something. This is with FreeBSD-5 STABLE from last week. I have also included the Kernel config file for your reference. Any help is appreciated! Regards, Frank KDB: debugger backends: ddb KDB: current backend: ddb SMAP type=3D01 base=3D0000000000000000 len=3D000000000009e800 SMAP type=3D02 base=3D000000000009e800 len=3D0000000000001800 SMAP type=3D02 base=3D00000000000ca000 len=3D000000000000a000 SMAP type=3D02 base=3D00000000000e0000 len=3D0000000000020000 SMAP type=3D01 base=3D0000000000100000 len=3D000000001fdf0000 SMAP type=3D03 base=3D000000001fef0000 len=3D000000000000f000 SMAP type=3D04 base=3D000000001feff000 len=3D0000000000001000 SMAP type=3D01 base=3D000000001ff00000 len=3D0000000000100000 SMAP type=3D02 base=3D00000000fec00000 len=3D0000000000100000 SMAP type=3D02 base=3D00000000fee00000 len=3D0000000000100000 SMAP type=3D02 base=3D00000000ffc00000 len=3D0000000000400000 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.3-STABLE #3: Mon Feb 14 09:59:09 CET 2005 volf@oz:/home1/volf/Firewall/FreeBSD/sys-5/i386/compile/FILTER WARNING: debug.mpsafenet forced to 0 as ipsec requires Giant WARNING: MPSAFE network stack disabled, expect reduced performance. Preloaded elf kernel "/boot/kernel/kernel" at 0xc0826000. Preloaded elf module "/boot/kernel/acpi.ko" at 0xc08262a0. Table 'FACP' at 0x1fefa83b Table 'SPCR' at 0x1fefef14 Table 'APIC' at 0x1fefef64 MADT: Found table at 0x1fefef64 MP Configuration Table version 1.4 found at 0xc009ea80 APIC: Using the MADT enumerator. MADT: Found CPU APIC ID 0 ACPI ID 0: enabled MADT: Found CPU APIC ID 1 ACPI ID 1: disabled ACPI APIC Table: Calibrating clock(s) ... i8254 clock: 1193148 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter "i8254" frequency 1193182 Hz quality 0 Calibrating TSC clock ... TSC clock: 2666774044 Hz CPU: Intel(R) Xeon(TM) CPU 2.66GHz (2666.77-MHz 686-class CPU) Origin =3D "GenuineIntel" Id =3D 0xf29 Stepping =3D 9 =20 Features=3D0xbfebfbff Hyperthreading: 2 logical CPUs real memory =3D 536870912 (512 MB) Physical memory chunk(s): 0x0000000000001000 - 0x000000000009dfff, 643072 bytes (157 pages) 0x0000000000100000 - 0x00000000003fffff, 3145728 bytes (768 pages) 0x0000000000c25000 - 0x000000001f5c7fff, 513421312 bytes (125347 pages) 0x000000001ff00000 - 0x000000001fff7fff, 1015808 bytes (248 pages) avail memory =3D 515780608 (491 MB) bios32: Found BIOS32 Service Directory header at 0xc00f69d0 bios32: Entry =3D 0xfd907 (c00fd907) Rev =3D 0 Len =3D 1 pcibios: PCI BIOS entry at 0xfd840+0x1f2 pnpbios: Found PnP BIOS data at 0xc00f6a60 pnpbios: Entry =3D f0000:9daf Rev =3D 1.0 Other BIOS signatures found: APIC: CPU 0 has ACPI ID 0 MADT: Found IO APIC ID 2, Interrupt 0 at 0xfec00000 ioapic0: Routing external 8259A's -> intpin 0 ioapic0: intpin 0 -> ExtINT (edge, high) ioapic0: intpin 1 -> ISA IRQ 1 (edge, high) ioapic0: intpin 2 -> ISA IRQ 2 (edge, high) ioapic0: intpin 3 -> ISA IRQ 3 (edge, high) ioapic0: intpin 4 -> ISA IRQ 4 (edge, high) ioapic0: intpin 5 -> ISA IRQ 5 (edge, high) ioapic0: intpin 6 -> ISA IRQ 6 (edge, high) ioapic0: intpin 7 -> ISA IRQ 7 (edge, high) ioapic0: intpin 8 -> ISA IRQ 8 (edge, high) ioapic0: intpin 9 -> ISA IRQ 9 (edge, high) ioapic0: intpin 10 -> ISA IRQ 10 (edge, high) ioapic0: intpin 11 -> ISA IRQ 11 (edge, high) ioapic0: intpin 12 -> ISA IRQ 12 (edge, high) ioapic0: intpin 13 -> ISA IRQ 13 (edge, high) ioapic0: intpin 14 -> ISA IRQ 14 (edge, high) ioapic0: intpin 15 -> ISA IRQ 15 (edge, high) MADT: Found IO APIC ID 3, Interrupt 16 at 0xfec10000 ioapic1: intpin 0 -> PCI IRQ 16 (level, low) ioapic1: intpin 1 -> PCI IRQ 17 (level, low) ioapic1: intpin 2 -> PCI IRQ 18 (level, low) ioapic1: intpin 3 -> PCI IRQ 19 (level, low) ioapic1: intpin 4 -> PCI IRQ 20 (level, low) ioapic1: intpin 5 -> PCI IRQ 21 (level, low) ioapic1: intpin 6 -> PCI IRQ 22 (level, low) ioapic1: intpin 7 -> PCI IRQ 23 (level, low) ioapic1: intpin 8 -> PCI IRQ 24 (level, low) ioapic1: intpin 9 -> PCI IRQ 25 (level, low) ioapic1: intpin 10 -> PCI IRQ 26 (level, low) ioapic1: intpin 11 -> PCI IRQ 27 (level, low) ioapic1: intpin 12 -> PCI IRQ 28 (level, low) ioapic1: intpin 13 -> PCI IRQ 29 (level, low) ioapic1: intpin 14 -> PCI IRQ 30 (level, low) ioapic1: intpin 15 -> PCI IRQ 31 (level, low) MADT: intr override: source 0, irq 2 ioapic0: Routing IRQ 0 -> intpin 2 ioapic0: intpin 2 trigger: edge ioapic0: intpin 2 polarity: high MADT: intr override: source 9, irq 9 ioapic0: intpin 9 trigger: level ioapic0: intpin 9 polarity: low lapic0: Routing NMI -> LINT1 lapic0: LINT1 trigger: edge lapic0: LINT1 polarity: active-high MADT: Ignoring local NMI routed to ACPI CPU 1 ioapic0 irqs 0-15 on motherboard ioapic1 irqs 16-31 on motherboard cpu0 BSP: ID: 0x00000000 VER: 0x00050014 LDR: 0x01000000 DFR: 0x0fffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff io: null: random: mem: Pentium Pro MTRR support enabled npx0: [FAST] npx0: on motherboard npx0: INT 16 interface acpi0: on motherboard acpi0: [MPSAFE] pci_open(1): mode 1 addr port (0x0cf8) is 0x800078ac pci_open(1a): mode1res=3D0x80000000 (0x80000000) pci_cfgcheck: device 0 [class=3D060000] [hdr=3D80] is there = (id=3D00141166) pcibios: BIOS version 2.10 Found $PIR table, 16 entries at 0xc00fdec0 PCI-Only Interrupts: none Location Bus Device Pin Link IRQs slot 5 0 8 A 0x10 3 4 5 6 7 9 10 11 12 14 15 slot 5 0 8 B 0x11 3 4 5 6 7 9 10 11 12 14 15 slot 5 0 8 C 0x10 3 4 5 6 7 9 10 11 12 14 15 slot 5 0 8 D 0x11 3 4 5 6 7 9 10 11 12 14 15 embedded 0 15 A 0x01 3 4 5 6 7 9 10 11 12 14 15 slot 4 1 8 A 0x1c 3 4 5 6 7 9 10 11 12 14 15 slot 4 1 8 B 0x1d 3 4 5 6 7 9 10 11 12 14 15 slot 4 1 8 C 0x1e 3 4 5 6 7 9 10 11 12 14 15 slot 4 1 8 D 0x1f 3 4 5 6 7 9 10 11 12 14 15 slot 7 1 10 A 0x1d 3 4 5 6 7 9 10 11 12 14 15 slot 7 1 10 B 0x1e 3 4 5 6 7 9 10 11 12 14 15 slot 7 1 10 C 0x1f 3 4 5 6 7 9 10 11 12 14 15 slot 7 1 10 D 0x1c 3 4 5 6 7 9 10 11 12 14 15 slot 8 1 11 A 0x1e 3 4 5 6 7 9 10 11 12 14 15 slot 8 1 11 B 0x1f 3 4 5 6 7 9 10 11 12 14 15 slot 8 1 11 C 0x1c 3 4 5 6 7 9 10 11 12 14 15 slot 8 1 11 D 0x1d 3 4 5 6 7 9 10 11 12 14 15 slot 9 1 12 A 0x1f 3 4 5 6 7 9 10 11 12 14 15 slot 9 1 12 B 0x1c 3 4 5 6 7 9 10 11 12 14 15 slot 9 1 12 C 0x1d 3 4 5 6 7 9 10 11 12 14 15 slot 9 1 12 D 0x1e 3 4 5 6 7 9 10 11 12 14 15 embedded 3 0 A 0x12 3 4 5 6 7 9 10 11 12 14 15 embedded 3 0 B 0x13 3 4 5 6 7 9 10 11 12 14 15 slot 3 4 8 A 0x18 3 4 5 6 7 9 10 11 12 14 15 slot 3 4 8 B 0x19 3 4 5 6 7 9 10 11 12 14 15 slot 3 4 8 C 0x1a 3 4 5 6 7 9 10 11 12 14 15 slot 3 4 8 D 0x1b 3 4 5 6 7 9 10 11 12 14 15 embedded 4 9 A 0x1a 3 4 5 6 7 9 10 11 12 14 15 embedded 4 9 B 0x1b 3 4 5 6 7 9 10 11 12 14 15 embedded 4 4 A 0x1a 3 4 5 6 7 9 10 11 12 14 15 embedded 4 4 B 0x1b 3 4 5 6 7 9 10 11 12 14 15 slot 1 5 8 A 0x14 3 4 5 6 7 9 10 11 12 14 15 slot 1 5 8 B 0x15 3 4 5 6 7 9 10 11 12 14 15 slot 1 5 8 C 0x16 3 4 5 6 7 9 10 11 12 14 15 slot 1 5 8 D 0x17 3 4 5 6 7 9 10 11 12 14 15 slot 2 5 9 A 0x16 3 4 5 6 7 9 10 11 12 14 15 slot 2 5 9 B 0x17 3 4 5 6 7 9 10 11 12 14 15 slot 2 5 9 C 0x14 3 4 5 6 7 9 10 11 12 14 15 slot 2 5 9 D 0x15 3 4 5 6 7 9 10 11 12 14 15 AcpiOsDerivePciId: bus 0 dev 16 func 0 AcpiOsDerivePciId: bus 0 dev 16 func 2 acpi0: Power Button (fixed) AcpiOsDerivePciId: bus 0 dev 0 func 0 ACPI timer: 1/2 0/3 0/3 1/2 0/3 1/2 0/3 0/3 0/3 0/3 -> 3 Timecounter "ACPI-safe" frequency 3579545 Hz quality 1000 acpi_timer0: <32-bit timer at 3.579545MHz> port 0xf008-0xf00b on acpi0 cpu0: on acpi0 acpi_button0: on acpi0 pcib0: on acpi0 ACPI PCI link initial configuration: \_SB_.PCI0.LPC_.LNKU irq 0: [ 3 4 5 6 7 9 10 11 12 14 15] 0+ low,level,sh arable 0.15.0 pci0: on pcib0 pci0: physical bus=3D0 found-> vendor=3D0x1166, dev=3D0x0014, revid=3D0x33 bus=3D0, slot=3D0, func=3D0 class=3D06-00-00, hdrtype=3D0x00, mfdev=3D1 cmdreg=3D0x0000, statreg=3D0x0000, cachelnsz=3D16 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 = ns) found-> vendor=3D0x1166, dev=3D0x0014, revid=3D0x00 bus=3D0, slot=3D0, func=3D1 class=3D06-00-00, hdrtype=3D0x00, mfdev=3D1 cmdreg=3D0x0000, statreg=3D0x0000, cachelnsz=3D16 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 = ns) found-> vendor=3D0x1166, dev=3D0x0014, revid=3D0x00 bus=3D0, slot=3D0, func=3D2 class=3D06-00-00, hdrtype=3D0x00, mfdev=3D1 cmdreg=3D0x0000, statreg=3D0x0000, cachelnsz=3D16 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 = ns) map[10]: type 1, range 32, base fb000000, size 24, enabled map[14]: type 4, range 32, base 00001000, size 8, enabled map[18]: type 1, range 32, base fc000000, size 12, enabled found-> vendor=3D0x1002, dev=3D0x4752, revid=3D0x27 bus=3D0, slot=3D4, func=3D0 class=3D03-00-00, hdrtype=3D0x00, mfdev=3D0 cmdreg=3D0x0087, statreg=3D0x0290, cachelnsz=3D16 (dwords) lattimer=3D0x42 (1980 ns), mingnt=3D0x08 (2000 ns), = maxlat=3D0x00 (0 ns) powerspec 2 supports D0 D1 D2 D3 current D0 map[14]: type 4, range 32, base 00001400, size 3, enabled pcib0: matched entry for 0.8.INTA pcib0: slot 8 INTA hardwired to IRQ 16 found-> vendor=3D0x110a, dev=3D0x007b, revid=3D0x00 bus=3D0, slot=3D8, func=3D0 class=3Dff-00-00, hdrtype=3D0x00, mfdev=3D1 cmdreg=3D0x0147, statreg=3D0x0290, cachelnsz=3D16 (dwords) lattimer=3D0x40 (1920 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 = (0 ns) intpin=3Da, irq=3D16 powerspec 2 supports D0 D3 current D0 map[10]: type 1, range 32, base fc001000, size 12, enabled map[14]: type 4, range 32, base 00001800, size 6, enabled map[18]: type 3, range 32, base fc300000, size 14, enabled pcib0: matched entry for 0.8.INTA pcib0: slot 8 INTA hardwired to IRQ 16 found-> vendor=3D0x110a, dev=3D0x007c, revid=3D0x00 bus=3D0, slot=3D8, func=3D1 class=3Dff-00-00, hdrtype=3D0x00, mfdev=3D1 cmdreg=3D0x0143, statreg=3D0x0290, cachelnsz=3D16 (dwords) lattimer=3D0x40 (1920 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 = (0 ns) intpin=3Da, irq=3D16 powerspec 2 supports D0 D3 current D0 found-> vendor=3D0x110a, dev=3D0x007d, revid=3D0x00 bus=3D0, slot=3D8, func=3D2 class=3Dff-00-00, hdrtype=3D0x00, mfdev=3D1 cmdreg=3D0x0143, statreg=3D0x0290, cachelnsz=3D16 (dwords) lattimer=3D0x40 (1920 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 = (0 ns) powerspec 2 supports D0 D3 current D0 found-> vendor=3D0x1166, dev=3D0x0203, revid=3D0xa0 bus=3D0, slot=3D15, func=3D0 class=3D06-00-00, hdrtype=3D0x00, mfdev=3D1 cmdreg=3D0x0147, statreg=3D0x2200, cachelnsz=3D0 (dwords) lattimer=3D0xf8 (7440 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 = (0 ns) map[20]: type 4, range 32, base 00001c00, size 4, enabled found-> vendor=3D0x1166, dev=3D0x0213, revid=3D0xa0 bus=3D0, slot=3D15, func=3D1 class=3D01-01-8a, hdrtype=3D0x00, mfdev=3D1 cmdreg=3D0x0145, statreg=3D0x0200, cachelnsz=3D16 (dwords) lattimer=3D0x40 (1920 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 = (0 ns) found-> vendor=3D0x1166, dev=3D0x0227, revid=3D0x00 bus=3D0, slot=3D15, func=3D3 class=3D06-01-00, hdrtype=3D0x00, mfdev=3D1 cmdreg=3D0x0144, statreg=3D0x0200, cachelnsz=3D0 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 = ns) found-> vendor=3D0x1166, dev=3D0x0110, revid=3D0x12 bus=3D0, slot=3D16, func=3D0 class=3D06-00-00, hdrtype=3D0x00, mfdev=3D1 cmdreg=3D0x0142, statreg=3D0x22b0, cachelnsz=3D0 (dwords) lattimer=3D0x40 (1920 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 = (0 ns) found-> vendor=3D0x1166, dev=3D0x0110, revid=3D0x12 bus=3D0, slot=3D16, func=3D2 class=3D06-00-00, hdrtype=3D0x00, mfdev=3D1 cmdreg=3D0x0142, statreg=3D0x2230, cachelnsz=3D0 (dwords) lattimer=3D0x40 (1920 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 = (0 ns) found-> vendor=3D0x1166, dev=3D0x0101, revid=3D0x05 bus=3D0, slot=3D17, func=3D0 class=3D06-00-00, hdrtype=3D0x00, mfdev=3D1 cmdreg=3D0x0142, statreg=3D0x2230, cachelnsz=3D0 (dwords) lattimer=3D0x40 (1920 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 = (0 ns) found-> vendor=3D0x1166, dev=3D0x0101, revid=3D0x05 bus=3D0, slot=3D17, func=3D2 class=3D06-00-00, hdrtype=3D0x00, mfdev=3D1 cmdreg=3D0x0142, statreg=3D0x2230, cachelnsz=3D0 (dwords) lattimer=3D0x40 (1920 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 = (0 ns) pci0: at device 4.0 (no driver attached) pci0: at device 8.0 (no driver attached) pci0: at device 8.1 (no driver attached) pci0: at device 8.2 (no driver attached) atapci0: port 0x1c00-0x1c0f,0x376,0x170-0x 177,0x3f6,0x1f0-0x1f7 at device 15.1 on pci0 atapci0: Reserved 0x10 bytes for rid 0x20 type 4 at 0x1c00 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=3D00 ostat0=3Dff ostat1=3Dff 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=3D03 ostat0=3D50 ostat1=3D00 ata1-master: stat=3D0x00 err=3D0x01 lsb=3D0x14 msb=3D0xeb ata1-slave: stat=3D0x00 err=3D0x04 lsb=3D0x00 msb=3D0x00 ata1: reset tp2 stat0=3D00 stat1=3D00 devices=3D0x4 ata1: [MPSAFE] isab0: at device 15.3 on pci0 isa0: on isab0 pcib1: on acpi0 ACPI PCI link initial configuration: pci1: on pcib1 pci1: physical bus=3D1 found-> vendor=3D0x1014, dev=3D0x01a7, revid=3D0x02 bus=3D1, slot=3D10, func=3D0 class=3D06-04-00, hdrtype=3D0x01, mfdev=3D0 cmdreg=3D0x0147, statreg=3D0x02b0, cachelnsz=3D16 (dwords) lattimer=3D0x40 (1920 ns), mingnt=3D0x07 (1750 ns), = maxlat=3D0x00 (0 ns) map[10]: type 4, range 32, base 00002000, size 8, enabled map[14]: type 1, range 64, base fc400000, size 12, enabled pcib1: matched entry for 1.11.INTA pcib1: slot 11 INTA hardwired to IRQ 30 found-> vendor=3D0x9005, dev=3D0x0080, revid=3D0x02 bus=3D1, slot=3D11, func=3D0 class=3D01-00-00, hdrtype=3D0x00, mfdev=3D0 cmdreg=3D0x0157, statreg=3D0x02b0, cachelnsz=3D16 (dwords) lattimer=3D0x48 (2160 ns), mingnt=3D0x28 (10000 ns), = maxlat=3D0x19 (6250 ns) intpin=3Da, irq=3D30 powerspec 2 supports D0 D3 current D0 map[10]: type 1, range 32, base fc401000, size 12, enabled map[14]: type 4, range 32, base 00002400, size 6, enabled map[18]: type 1, range 32, base fc500000, size 20, enabled pcib1: matched entry for 1.12.INTA pcib1: slot 12 INTA hardwired to IRQ 31 found-> vendor=3D0x8086, dev=3D0x1229, revid=3D0x08 bus=3D1, slot=3D12, func=3D0 class=3D02-00-00, hdrtype=3D0x00, mfdev=3D0 cmdreg=3D0x0157, statreg=3D0x0290, cachelnsz=3D16 (dwords) lattimer=3D0x42 (1980 ns), mingnt=3D0x08 (2000 ns), = maxlat=3D0x38 (14000 ns) intpin=3Da, irq=3D31 powerspec 2 supports D0 D1 D2 D3 current D0 pcib2: at device 10.0 on pci1 pcib2: secondary bus 2 pcib2: subordinate bus 2 pcib2: I/O decode 0x3000-0x3fff pcib2: memory decode 0xfc600000-0xfc6fffff pcib2: prefetched decode 0xfff00000-0xfffff pci2: on pcib2 pci2: physical bus=3D2 map[10]: type 1, range 64, base fc600000, size 17, enabled pcib2: device (null) requested decoded memory range 0xfc600000-0xfc61ffff map[20]: type 4, range 32, base 00003000, size 6, enabled pcib2: device (null) requested decoded I/O range 0x3000-0x303f pcib1: matched entry for 1.10.INTA pcib1: slot 10 INTA hardwired to IRQ 29 pcib2: slot 4 INTA is routed to irq 29 found-> vendor=3D0x8086, dev=3D0x101d, revid=3D0x01 bus=3D2, slot=3D4, func=3D0 class=3D02-00-00, hdrtype=3D0x00, mfdev=3D1 cmdreg=3D0x0157, statreg=3D0x0230, cachelnsz=3D16 (dwords) lattimer=3D0x40 (1920 ns), mingnt=3D0xff (63750 ns), = maxlat=3D0x00 (0 ns) intpin=3Da, irq=3D29 powerspec 2 supports D0 D3 current D0 MSI supports 1 message, 64 bit map[10]: type 1, range 64, base fc620000, size 17, enabled pcib2: device (null) requested decoded memory range 0xfc620000-0xfc63ffff map[20]: type 4, range 32, base 00003400, size 6, enabled pcib2: device (null) requested decoded I/O range 0x3400-0x343f pcib1: matched entry for 1.10.INTB pcib1: slot 10 INTB hardwired to IRQ 30 pcib2: slot 4 INTB is routed to irq 30 found-> vendor=3D0x8086, dev=3D0x101d, revid=3D0x01 bus=3D2, slot=3D4, func=3D1 class=3D02-00-00, hdrtype=3D0x00, mfdev=3D1 cmdreg=3D0x0157, statreg=3D0x0230, cachelnsz=3D16 (dwords) lattimer=3D0x40 (1920 ns), mingnt=3D0xff (63750 ns), = maxlat=3D0x00 (0 ns) intpin=3Db, irq=3D30 powerspec 2 supports D0 D3 current D0 MSI supports 1 message, 64 bit map[10]: type 1, range 64, base fc640000, size 17, enabled pcib2: device (null) requested decoded memory range 0xfc640000-0xfc65ffff map[20]: type 4, range 32, base 00003800, size 6, enabled pcib2: device (null) requested decoded I/O range 0x3800-0x383f pcib1: matched entry for 1.10.INTC pcib1: slot 10 INTC hardwired to IRQ 31 pcib2: slot 6 INTA is routed to irq 31 found-> vendor=3D0x8086, dev=3D0x101d, revid=3D0x01 bus=3D2, slot=3D6, func=3D0 class=3D02-00-00, hdrtype=3D0x00, mfdev=3D1 cmdreg=3D0x0157, statreg=3D0x0230, cachelnsz=3D16 (dwords) lattimer=3D0x40 (1920 ns), mingnt=3D0xff (63750 ns), = maxlat=3D0x00 (0 ns) intpin=3Da, irq=3D31 powerspec 2 supports D0 D3 current D0 MSI supports 1 message, 64 bit map[10]: type 1, range 64, base fc660000, size 17, enabled pcib2: device (null) requested decoded memory range 0xfc660000-0xfc67ffff map[20]: type 4, range 32, base 00003c00, size 6, enabled pcib2: device (null) requested decoded I/O range 0x3c00-0x3c3f pcib1: matched entry for 1.10.INTD pcib1: slot 10 INTD hardwired to IRQ 28 pcib2: slot 6 INTB is routed to irq 28 found-> vendor=3D0x8086, dev=3D0x101d, revid=3D0x01 bus=3D2, slot=3D6, func=3D1 class=3D02-00-00, hdrtype=3D0x00, mfdev=3D1 cmdreg=3D0x0157, statreg=3D0x0230, cachelnsz=3D16 (dwords) lattimer=3D0x40 (1920 ns), mingnt=3D0xff (63750 ns), = maxlat=3D0x00 (0 ns) intpin=3Db, irq=3D28 powerspec 2 supports D0 D3 current D0 MSI supports 1 message, 64 bit em0: port 0x3000-0x303f mem 0xfc600000-0xfc61ffff irq 29 at device 4.0 on pci2 em0: Reserved 0x20000 bytes for rid 0x10 type 3 at 0xfc600000 em0: Reserved 0x40 bytes for rid 0x20 type 4 at 0x3000 em0: [GIANT-LOCKED] em0: bpf attached em0: Ethernet address: 00:04:23:b1:58:84 em0: Speed:N/A Duplex:N/A em1: port 0x3400-0x343f mem 0xfc620000-0xfc63ffff irq 30 at device 4.1 on pci2 em1: Reserved 0x20000 bytes for rid 0x10 type 3 at 0xfc620000 em1: Reserved 0x40 bytes for rid 0x20 type 4 at 0x3400 em1: [GIANT-LOCKED] em1: bpf attached em1: Ethernet address: 00:04:23:b1:58:85 em1: Speed:N/A Duplex:N/A em2: port 0x3800-0x383f mem 0xfc640000-0xfc65ffff irq 31 at device 6.0 on pci2 em2: Reserved 0x20000 bytes for rid 0x10 type 3 at 0xfc640000 em2: Reserved 0x40 bytes for rid 0x20 type 4 at 0x3800 em2: [GIANT-LOCKED] em2: bpf attached em2: Ethernet address: 00:04:23:b1:58:86 em2: Speed:N/A Duplex:N/A em3: port 0x3c00-0x3c3f mem 0xfc660000-0xfc67ffff irq 28 at device 6.1 on pci2 em3: Reserved 0x20000 bytes for rid 0x10 type 3 at 0xfc660000 em3: Reserved 0x40 bytes for rid 0x20 type 4 at 0x3c00 em3: [GIANT-LOCKED] em3: bpf attached em3: Ethernet address: 00:04:23:b1:58:87 em3: Speed:N/A Duplex:N/A ahc0: port 0x2000-0x20ff mem 0xfc400000-0x fc400fff irq 30 at device 11.0 on pci1 ahc0: Defaulting to MEMIO off ahc0: Reserved 0x100 bytes for rid 0x10 type 4 at 0x2000 ahc0: Reading SEEPROM...done. ahc0: BIOS eeprom is present ahc0: Secondary High byte termination Enabled ahc0: Secondary Low byte termination Enabled ahc0: Primary Low Byte termination Enabled ahc0: Primary High Byte termination Enabled ahc0: Downloading Sequencer Program... 423 instructions downloaded ahc0: Features 0x1def6, Bugs 0x40, Flags 0x20485560 ahc0: [GIANT-LOCKED] aic7892: Ultra160 Wide Channel A, SCSI Id=3D7, 32/253 SCBs fxp0: port 0x2400-0x243f mem 0xfc500000-0xfc5ffff f,0xfc401000-0xfc401fff irq 31 at device 12.0 on pci1 fxp0: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xfc401000 fxp0: using memory space register mapping fxp0: PCI IDs: 8086 1229 103c 10cb 0008 fxp0: Dynamic Standby mode is disabled miibus0: on fxp0 inphy0: on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto fxp0: bpf attached fxp0: Ethernet address: 00:d0:b7:9e:5b:c5 fxp0: [GIANT-LOCKED] pcib3: on acpi0 ACPI PCI link initial configuration: pci3: on pcib3 pci3: physical bus=3D3 map[10]: type 1, range 64, base fc910000, size 16, enabled map[18]: type 1, range 64, base fc900000, size 16, enabled pcib3: matched entry for 3.0.INTA pcib3: slot 0 INTA hardwired to IRQ 18 found-> vendor=3D0x14e4, dev=3D0x1648, revid=3D0x02 bus=3D3, slot=3D0, func=3D0 class=3D02-00-00, hdrtype=3D0x00, mfdev=3D1 cmdreg=3D0x0156, statreg=3D0x02b0, cachelnsz=3D16 (dwords) lattimer=3D0x40 (1920 ns), mingnt=3D0x40 (16000 ns), = maxlat=3D0x00 (0 ns) intpin=3Da, irq=3D18 powerspec 2 supports D0 D3 current D0 MSI supports 8 messages, 64 bit map[10]: type 1, range 64, base fc930000, size 16, enabled map[18]: type 1, range 64, base fc920000, size 16, enabled pcib3: matched entry for 3.0.INTB pcib3: slot 0 INTB hardwired to IRQ 19 found-> vendor=3D0x14e4, dev=3D0x1648, revid=3D0x02 bus=3D3, slot=3D0, func=3D1 class=3D02-00-00, hdrtype=3D0x00, mfdev=3D1 cmdreg=3D0x0156, statreg=3D0x02b0, cachelnsz=3D16 (dwords) lattimer=3D0x40 (1920 ns), mingnt=3D0x40 (16000 ns), = maxlat=3D0x00 (0 ns) intpin=3Db, irq=3D19 powerspec 2 supports D0 D3 current D0 MSI supports 8 messages, 64 bit bge0: mem 0xfc900000 -0xfc90ffff,0xfc910000-0xfc91ffff irq 18 at device 0.0 on pci3 bge0: Reserved 0x10000 bytes for rid 0x10 type 3 at 0xfc910000 miibus1: on bge0 brgphy0: on miibus1 brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX, 1000baseTX -FDX, auto bge0: bpf attached bge0: Ethernet address: 00:30:05:81:83:8e bge0: [GIANT-LOCKED] bge1: mem 0xfc920000 -0xfc92ffff,0xfc930000-0xfc93ffff irq 19 at device 0.1 on pci3 bge1: Reserved 0x10000 bytes for rid 0x10 type 3 at 0xfc930000 miibus2: on bge1 brgphy1: on miibus2 brgphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX, 1000baseTX -FDX, auto bge1: bpf attached bge1: Ethernet address: 00:30:05:81:83:8f bge1: [GIANT-LOCKED] pcib4: on acpi0 ACPI PCI link initial configuration: pci4: on pcib4 pci4: physical bus=3D4 pcib5: on acpi0 ACPI PCI link initial configuration: pci5: on pcib5 pci5: physical bus=3D5 unknown: not probed (disabled) unknown: not probed (disabled) unknown: not probed (disabled) unknown: not probed (disabled) unknown: not probed (disabled) unknown: not probed (disabled) unknown: not probed (disabled) unknown: not probed (disabled) unknown: not probed (disabled) unknown: not probed (disabled) unknown: not probed (disabled) unknown: not probed (disabled) unknown: not probed (disabled) 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 006d atkbd: keyboard ID 0x41ab (2) kbdc: RESET_KBD return code:00fa kbdc: RESET_KBD status:00aa kbd0 at atkbd0 kbd0: atkbd0, AT 101/102 (2), config:0x0, flags:0x1d0000 atkbd0: [GIANT-LOCKED] psm0: unable to allocate IRQ psmcpnp0: irq 12 on acpi0 psm0: current command byte:006d kbdc: TEST_AUX_PORT status:0002 psm0: strange result for test aux port (2). kbdc: RESET_AUX return code:00fe kbdc: RESET_AUX return code:00fe kbdc: RESET_AUX return code:00fe kbdc: DIAGNOSE status:0055 kbdc: TEST_KBD_PORT status:0000 psm0: failed to reset the aux device. fdc0: port 0x3f7,0x3f0-0x3f5 irq 6 drq 2 on acpi0 fdc0: ic_type 90 part_id 80 fdc0: [MPSAFE] fdc0: [FAST] fd0: <1440-KB 3.5" drive> on fdc0 drive 0 unknown: not probed (disabled) unknown: not probed (disabled) sio0: irq maps: 0x21 0x29 0x21 0x21 sio0: <16550A-compatible COM port> port 0x2f8-0x2ff irq 3 flags 0x30 on acpi0 sio0: type 16550A, console sio1: irq maps: 0x21 0x31 0x21 0x21 sio1: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 on acpi0 sio1: type 16550A unknown: not probed (disabled) unknown: not probed (disabled) unknown: not probed (disabled) unknown: not probed (disabled) unknown: not probed (disabled) unknown: not probed (disabled) unknown: not probed (disabled) unknown: not probed (disabled) unknown: not probed (disabled) unknown: not probed (disabled) unknown: not probed (disabled) unknown: not probed (disabled) unknown: not probed (disabled) unknown: not probed (disabled) unknown: not probed (disabled) unknown: not probed (disabled) unknown: not probed (disabled) unknown: not probed (disabled) 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 ahc_isa_probe 0: ioport 0xc00 alloc failed ahc_isa_probe 1: ioport 0x1c00 alloc failed ahc_isa_probe 3: ioport 0x3c00 alloc failed ata: ata0 already exists; skipping it ata: ata1 already exists; skipping it atkbdc: atkbdc0 already exists; skipping it fdc: fdc0 already exists; skipping it sc: sc0 already exists; skipping it sio: sio0 already exists; skipping it sio: sio1 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 0xc9000-0xcb7ff,0xc0000-0xc8fff on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=3D0x100> sc0: fb0, kbd0, terminal emulator: sc (syscons terminal) 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=20 bf 1f 00 4f 0d 0e 00 00 07 80 9c 8e 8f 28 1f 96=20 b9 a3 ff 00 01 02 03 04 05 14 07 38 39 3a 3b 3c=20 3d 3e 3f 0c 00 0f 08 00 00 00 00 00 10 0e 00 ff=20 VGA parameters in BIOS for mode 24 50 18 10 00 10 00 03 00 02 67 5f 4f 50 82 55 81=20 bf 1f 00 4f 0d 0e 00 00 00 00 9c 8e 8f 28 1f 96=20 b9 a3 ff 00 01 02 03 04 05 14 07 38 39 3a 3b 3c=20 3d 3e 3f 0c 00 0f 08 00 00 00 00 00 10 0e 00 ff=20 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=20 bf 1f 00 4f 0d 0e 00 00 00 00 9c 8e 8f 28 1f 96=20 b9 a3 ff 00 01 02 03 04 05 14 07 38 39 3a 3b 3c=20 3d 3e 3f 0c 00 0f 08 00 00 00 00 00 10 0e 00 ff=20 adv0: not probed (disabled) aha0: not probed (disabled) aic0: not probed (disabled) bt0: not probed (disabled) cs0: not probed (disabled) ed0: not probed (disabled) 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) ppc0 failed to probe at irq 7 on isa0 sio2: not probed (disabled) sio3: not probed (disabled) sn0: not probed (disabled) vt0: not probed (disabled) isa_probe_children: probing PnP devices Device configuration finished. procfs registered Timecounter "TSC" frequency 2666774044 Hz quality 800 Timecounters tick every 1.000 msec carp: attached IPsec: Initialized Security Association Processing. IP Filter: v4.1.5 initialized. Default =3D block all, Logging =3D = enabled lo0: bpf attached ata1-master: pio=3D0x0c wdma=3D0x22 udma=3D0x42 cable=3D40pin ata1-master: setting PIO4 on ServerWorks CSB6 chip ata1-master: setting UDMA33 on ServerWorks CSB6 chip acd0: CDROM drive at ata1 as master acd0: read 4125KB/s (4125KB/s), 128KB buffer, UDMA33 acd0: Reads: CDR, CDRW, CDDA stream, packet acd0: Writes: acd0: Audio: play, 255 volume levels acd0: Mechanism: ejectable tray, unlocked acd0: Medium: no/blank disc Waiting 8 seconds for SCSI devices to settle (noperiph:ahc0:0:-1:-1): SCSI bus reset delivered. 0 SCBs aborted. ahc0: Selection Timeout on A:2. 0 SCBs aborted ahc0: Selection Timeout on A:3. 0 SCBs aborted ahc0: Selection Timeout on A:6. 0 SCBs aborted ahc0: Selection Timeout on A:9. 0 SCBs aborted ahc0: Selection Timeout on A:11. 0 SCBs aborted ahc0: Selection Timeout on A:12. 0 SCBs aborted ahc0: Selection Timeout on A:13. 0 SCBs aborted ahc0: Selection Timeout on A:4. 0 SCBs aborted ahc0: Selection Timeout on A:5. 0 SCBs aborted ahc0: Selection Timeout on A:10. 0 SCBs aborted ahc0: Selection Timeout on A:14. 0 SCBs aborted ahc0: Selection Timeout on A:15. 0 SCBs aborted (probe1:ahc0:0:1:0): Retrying Command (probe0:ahc0:0:0:0): Retrying Command (ahc0:A:1:0): Sending PPR bus_width 1, period 9, offset 7f, ppr_options 2 (ahc0:A:1:0): Received PPR width 1, period 9, offset 7f,options 2 Filtered to width 1, period 9, offset 7f, options 2 ahc0: target 1 using 16bit transfers ahc0: target 1 synchronous at 80.0MHz DT, offset =3D 0x7f (ahc0:A:0:0): Sending PPR bus_width 1, period 9, offset 7f, ppr_options 2 (ahc0:A:0:0): Received PPR width 1, period 9, offset 7f,options 2 Filtered to width 1, period 9, offset 7f, options 2 ahc0: target 0 using 16bit transfers ahc0: target 0 synchronous at 80.0MHz DT, offset =3D 0x7f pass0 at ahc0 bus 0 target 0 lun 0 pass0: Fixed Direct Access SCSI-3 device=20 pass0: Serial Number UPP4P4C0D01E pass0: 160.000MB/s transfers (80.000MHz, offset 127, 16bit), Tagged Queueing Ena bled pass1 at ahc0 bus 0 target 1 lun 0 pass1: Fixed Direct Access SCSI-3 device=20 pass1: Serial Number UPP4P4C0CYU7 pass1: 160.000MB/s transfers (80.000MHz, offset 127, 16bit), Tagged Queueing Ena bled pass2 at ahc0 bus 0 target 8 lun 0 pass2: Fixed Processor SCSI-2 device=20 pass2: Serial Number 1 pass2: 3.300MB/s transfers ses0 at ahc0 bus 0 target 8 lun 0 ses0: Fixed Processor SCSI-2 device=20 ses0: Serial Number 1 ses0: 3.300MB/s transfers ses0: SAF-TE Compliant Device da0 at ahc0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-3 device=20 da0: Serial Number UPP4P4C0D01E da0: 160.000MB/s transfers (80.000MHz, offset 127, 16bit), Tagged Queueing Enabl ed da0: 35046MB (71775284 512 byte sectors: 255H 63S/T 4467C) da1 at ahc0 bus 0 target 1 lun 0 da1: Fixed Direct Access SCSI-3 device=20 da1: Serial Number UPP4P4C0CYU7 da1: 160.000MB/s transfers (80.000MHz, offset 127, 16bit), Tagged Queueing Enabl ed da1: 35046MB (71775284 512 byte sectors: 255H 63S/T 4467C) GEOM: new disk da0 GEOM: new disk da1 ioapic0: routing intpin 1 (ISA IRQ 1) to cluster 0 ioapic0: routing intpin 3 (ISA IRQ 3) to cluster 0 ioapic0: routing intpin 4 (ISA IRQ 4) to cluster 0 ioapic0: routing intpin 6 (ISA IRQ 6) to cluster 0 ioapic0: routing intpin 8 (ISA IRQ 8) to cluster 0 ioapic0: routing intpin 9 (ISA IRQ 9) to cluster 0 ioapic0: routing intpin 13 (ISA IRQ 13) to cluster 0 ioapic0: routing intpin 14 (ISA IRQ 14) to cluster 0 ioapic0: routing intpin 15 (ISA IRQ 15) to cluster 0 ioapic1: routing intpin 2 (PCI IRQ 18) to cluster 0 ioapic1: routing intpin 3 (PCI IRQ 19) to cluster 0 ioapic1: routing intpin 12 (PCI IRQ 28) to cluster 0 ioapic1: routing intpin 13 (PCI IRQ 29) to cluster 0 ioapic1: routing intpin 14 (PCI IRQ 30) to cluster 0 ioapic1: routing intpin 15 (PCI IRQ 31) to cluster 0 [0] f:00 typ:165 s(CHS):0/1/1 e(CHS):1023/254/63 s:63 l:71762292 [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 da0s1, start 32256 length 36742293504 end 36742325759 [0] f:80 typ:165 s(CHS):0/1/1 e(CHS):1023/254/63 s:63 l:71762292 [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 da1s1, start 32256 length 36742293504 end 36742325759 [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/255/63 s:0 l:50000 GEOM: Configure da0s1a, start 0 length 536870912 end 536870911 GEOM: Configure da0s1b, start 536870912 length 536870912 end 1073741823 GEOM: Configure da0s1c, start 0 length 36742293504 end 36742293503 GEOM: Configure da0s1e, start 1073741824 length 35668551680 end 36742293503 [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/255/63 s:0 l:50000 GEOM: Configure da1s1a, start 0 length 1073741824 end 1073741823 GEOM: Configure da1s1b, start 1073741824 length 1073741824 end 2147483647 GEOM: Configure da1s1c, start 0 length 36742293504 end 36742293503 GEOM: Configure da1s1e, start 2147483648 length 34594809856 end 36742293503 [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/255/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/255/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/255/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/255/63 s:0 l:50000 Mounting root from ufs:/dev/da1s1a start_init: trying /sbin/init [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/255/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/255/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/255/63 s:0 l:50000 obreak: MAP_WIREFUTURE set obreak: MAP_WIREFUTURE set obreak: MAP_WIREFUTURE set obreak: MAP_WIREFUTURE set obreak: MAP_WIREFUTURE set obreak: MAP_WIREFUTURE set obreak: MAP_WIREFUTURE set obreak: MAP_WIREFUTURE set obreak: MAP_WIREFUTURE set obreak: MAP_WIREFUTURE set obreak: MAP_WIREFUTURE set obreak: MAP_WIREFUTURE set # # $Id: FILTER,v 1.8 2005/02/11 10:47:25 volf Exp $ # machine i386 cpu I586_CPU cpu I686_CPU ident FILTER # # The `maxusers' parameter controls the static sizing of a number of # internal system tables by a formula defined in subr_param.c. # Omitting this parameter or setting it to 0 will cause the system to # auto-size based on physical memory. # maxusers 128 # # The `makeoptions' parameter allows variables to be passed to the # generated Makefile in the build area. # makeoptions DEBUG=3D-g #Build kernel with gdb(1) debug symbols makeoptions MODULES_OVERRIDE=3D"acpi" # This allows you to actually store this configuration file into # the kernel binary itself, where it may be later read by saying: # strings -n 3 /boot/kernel/kernel | sed -n 's/^___//p' > MYKERNEL # options INCLUDE_CONFIG_FILE # Include this file in kernel # # Compile with kernel debugger related code. # options KDB # # Print a stack trace of the current thread on the console for a panic. # options KDB_TRACE # # Don't enter the debugger for a panic. Intended for unattended operation # where you may want to enter the debugger from the console, but still want # the machine to recover from a panic. # options KDB_UNATTENDED # # Enable the ddb debugger backend. # options DDB options SCHED_4BSD # 4BSD scheduler options INET # InterNETworking options INET6 # IPv6 communications protocols options IPSEC #IP security options IPSEC_ESP #IP security (crypto; define w/ IPSEC) options IPSEC_FILTERGIF #filter ipsec packets from a tunnel options FFS # Berkeley Fast Filesystem options SOFTUPDATES # Enable FFS soft updates support options UFS_DIRHASH # Improve performance on big directories options CD9660 # ISO 9660 Filesystem options PROCFS # Process filesystem (requires PSEUDOFS) options PSEUDOFS # Pseudo-filesystem framework options GEOM_GPT # GUID Partition Tables. options COMPAT_43 # Compatible with BSD 4.3 [KEEP THIS!] options COMPAT_FREEBSD4 # Compatible with FreeBSD4 options SCSI_DELAY=3D8000 # Delay (in ms) before probing SCSI options KTRACE # ktrace(1) support options SYSVSHM # SYSV-style shared memory options SYSVMSG # SYSV-style message queues options SYSVSEM # SYSV-style semaphores options _KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B real-time extensions options KBD_INSTALL_CDEV # install a CDEV entry in /dev options AHC_REG_PRETTY_PRINT # Print register bitfields in debug # output. Adds ~128k to driver. options AHD_REG_PRETTY_PRINT # Print register bitfields in debug # output. Adds ~215k to driver. options ADAPTIVE_GIANT # Giant mutex is adaptive. ##################################################################### # SMP OPTIONS: # # The apic device enables the use of the I/O APIC for interrupt delivery. # The apic device can be used in both UP and SMP kernels, but is required # for SMP kernels. Thus, the apic device is not strictly an SMP option, # but it is a prerequisite for SMP. # # Notes: # # Be sure to disable 'cpu I386_CPU' for SMP kernels. # # By default, mixed mode is used to route IRQ0 from the AT timer via # the 8259A master PIC through the ExtINT pin on the first I/O APIC. # This can be disabled via the NO_MIXED_MODE option. In that case, # IRQ0 will be routed via an intpin on the first I/O APIC. Not all # motherboards hook IRQ0 up to the first I/O APIC even though their # MP table or MADT may claim to do so. That is why mixed mode is # enabled by default. # # HTT CPUs should only be used if they are enabled in the BIOS. For # the ACPI case, ACPI only correctly tells us about any HTT CPUs if # they are enabled. However, most HTT systems do not list HTT CPUs # in the MP Table if they are enabled, thus we guess at the HTT CPUs # for the MP Table case. However, we shouldn't try to guess and use # these CPUs if HTT is disabled. Thus, HTT guessing is only enabled # for the MP Table if the user explicitly asks for it via the # MPTABLE_FORCE_HTT option. Do NOT use this option if you have HTT # disabled in your BIOS. # # Mandatory: device apic # I/O apic # Bus support. Do not remove isa, even if you have no isa slots device isa device pci # Floppy drives device fdc # ATA and ATAPI devices device ata device atapicd # ATAPI CDROM drives options ATA_STATIC_ID # Static device numbering # SCSI Controllers device ahc # AHA2940 and onboard AIC7xxx devices device mpt # LSI-Logic MPT-Fusion device sym # NCR/Symbios Logic (newer chipsets + those of `ncr') # SCSI peripherals device scbus # SCSI bus (required for SCSI) device da # Direct Access (disks) device cd # CD device pass # Passthrough device (direct SCSI access) device ses # SCSI Environmental Services (and SAF-TE) # atkbdc0 controls both the keyboard and the PS/2 mouse device atkbdc # AT keyboard controller device atkbd # AT keyboard device psm # PS/2 mouse device vga # VGA video card driver # syscons is the default console driver, resembling an SCO console device sc # Floating point support - do not disable. device npx # Serial (COM) ports device sio # 8250, 16[45]50 based serial ports # PCI Ethernet NICs. device em # Intel PRO/1000 adapter Gigabit Ethernet Card # PCI Ethernet NICs that use the common MII bus controller code. # NOTE: Be sure to keep the 'device miibus' line in order to use these NICs! device miibus # MII bus support device bge # Broadcom BCM570xx Gigabit Ethernet device fxp # Intel EtherExpress PRO/100B (82557, 82558) device sf # Adaptec AIC-6915 (``Starfire'') device xl # 3Com 3c90x (``Boomerang'', ``Cyclone'') # Pseudo devices. device loop # Network loopback device mem # Memory and kernel memory devices device io # I/O device device random # Entropy device device ether # Ethernet support device vlan # VLAN support (needs miibus) device gre # IP over IP tunneling device pty # Pseudo-ttys (telnet etc) device md # Memory "disks" device gif # IPv6 and IPv4 tunneling device faith # IPv6-to-IPv4 relaying (translation) device carp # CARP # The `bpf' device enables the Berkeley Packet Filter. # Be aware of the administrative consequences of enabling this! device bpf # Berkeley packet filter # The granularity of operation is controlled by the kernel option HZ whose # default value (100) means a granularity of 10ms (1s/HZ). # Some subsystems, such as DUMMYNET, might benefit from a smaller # granularity such as 1ms or less, for a smoother scheduling of packets. # Consider, however, that reducing the granularity too much might # cause excessive overhead in clock interrupt processing, # potentially causing ticks to be missed and thus actually reducing # the accuracy of operation. options HZ=3D1000 # # DEVICE_POLLING adds support for mixed interrupt-polling handling # of network device drivers, which has significant benefits in terms # of robustness to overloads and responsivity, as well as permitting # accurate scheduling of the CPU time between kernel network processing # and other activities. The drawback is a moderate (up to 1/HZ seconds) # potential increase in response times. # It is strongly recommended to use HZ=3D1000 or 2000 with = DEVICE_POLLING # to achieve smoother behaviour. # Additionally, you can enable/disable polling at runtime with the # sysctl variable kern.polling.enable (defaults off), and select # the CPU fraction reserved to userland with the sysctl variable # kern.polling.user_frac (default 50, range 0..100). # # Not all device drivers support this mode of operation at the time of # this writing. See polling(4) for more details. options DEVICE_POLLING # # Local additions # options IPFILTER # ipfilter support options IPFILTER_LOG # ipfilter logging options IPFILTER_DEFAULT_BLOCK # default is to block unmatched IP packets options IPSTATE_SIZE=3D30011 # MUST BE PRIME!!!!=09 options IPSTATE_MAX=3D49152 options IPFILTER_LOGSIZE=3D(1024*1024) # 1024 Kbyte buffer options IPFILTER_SYNC options IPFILTER_BPF -----Original Message----- From: Nate Lawson [mailto:nate@root.org]=20 Sent: Sunday, February 13, 2005 01:22 To: Frank Cc: acpi@freebsd.org Subject: Re: Ethernet cards not working - Interrrupt routing problem? Frank wrote: > [I posted this message on -STABLE yesterday, but I got a mail, > that I should try this mailing list instead. Also I forgot to > mention that the machine in question is a Fujitsu Siemens > Primergy RX300 -- thanks for any advice, Frank] >=20 > I have a weird problem with hardware that runs fine under FreeBSD 4.9 > but is unusable under FreeBSD 5.3. The problem concentrates apparently > arround interrupt assignments, the Adaptec scsci card in combination > with the Ethernet cards. The difference is that 4.9 doesn't support full IOAPIC, 5.x does. The=20 first thing you should do is upgrade your BIOS to the latest stable=20 version. There were some problems with older ServerWorks BIOSen. If=20 that doesn't work, send dmesg from boot -v. > ACPI APIC Table: > Timecounter "i8254" frequency 1193182 Hz quality 0 > CPU: Intel(R) Xeon(TM) CPU 2.66GHz (2666.78-MHz 686-class CPU) > Origin =3D "GenuineIntel" Id =3D 0xf29 Stepping =3D 9 > Hyperthreading: 2 logical CPUs > real memory =3D 536870912 (512 MB) > avail memory =3D 515682304 (491 MB) > ioapic0 irqs 0-15 on motherboard > ioapic1 irqs 16-31 on motherboard > npx0: on motherboard > npx0: INT 16 interface > acpi0: on motherboard Yep, ServerWorks which we all know and love. :) --=20 Nate From owner-freebsd-acpi@FreeBSD.ORG Mon Feb 14 11:01:48 2005 Return-Path: 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 8D12E16A4D1 for ; Mon, 14 Feb 2005 11:01:48 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 72E9A43D1F for ; Mon, 14 Feb 2005 11:01:48 +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.1/8.13.1) with ESMTP id j1EB1mjv015069 for ; Mon, 14 Feb 2005 11:01:48 GMT (envelope-from owner-bugmaster@freebsd.org) Received: (from peter@localhost) by freefall.freebsd.org (8.13.1/8.13.1/Submit) id j1EB1lks015063 for freebsd-acpi@freebsd.org; Mon, 14 Feb 2005 11:01:47 GMT (envelope-from owner-bugmaster@freebsd.org) Date: Mon, 14 Feb 2005 11:01:47 GMT Message-Id: <200502141101.j1EB1lks015063@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 Subject: Current problem reports assigned to you X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Feb 2005 11:01:48 -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 f [2003/09/10] kern/56659 acpi ACPI trouble on IBM ThinkPad X31 f [2003/12/17] i386/60317 acpi FreeBSD 5.2rc1 doesn't boot with ACPI ena 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 10 problems total. Non-critical problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- f [2004/01/22] i386/61703 acpi ACPI + Sound + Boot = Reboot o [2004/03/17] kern/64365 acpi ACPI problems f [2004/05/25] i386/67189 acpi ACPI S3 reboot computer on Dell Latitude o [2004/05/28] kern/67309 acpi zzz reboot computer (ACPI S3) f [2004/06/23] i386/68219 acpi ACPI + snd_maestro3 problem o [2004/07/29] i386/69750 acpi Boot without ACPI failed on ASUS L5 o [2004/11/11] i386/73822 acpi acpi / thermal support o [2004/11/21] kern/74215 acpi [request] add ACPI headers to /usr/includ 8 problems total. From owner-freebsd-acpi@FreeBSD.ORG Mon Feb 14 14:24:08 2005 Return-Path: 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 7D1CA16A4CE; Mon, 14 Feb 2005 14:24:08 +0000 (GMT) Received: from mailout09.sul.t-online.com (mailout09.sul.t-online.com [194.25.134.84]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1E81743D31; Mon, 14 Feb 2005 14:24:08 +0000 (GMT) (envelope-from netchild@FreeBSD.org) Received: from fwd03.aul.t-online.de by mailout09.sul.t-online.com with smtp id 1D0h8v-0000TR-04; Mon, 14 Feb 2005 15:24:05 +0100 Received: from Andro-Beta.Leidinger.net (GvdBC8ZTgey4vPCft3WJ8c6OP0XmhHufSF6qWan1CtrQGn5g6s79rk@[217.83.22.45]) by fmrl03.sul.t-online.com with esmtp id 1D0h8g-1GTGJk0; Mon, 14 Feb 2005 15:23:50 +0100 Received: from localhost (localhost [127.0.0.1])j1EENKfI075153; Mon, 14 Feb 2005 15:23:20 +0100 (CET) (envelope-from netchild@FreeBSD.org) Received: from 141.113.101.32 ([141.113.101.32]) by netchild.homeip.net (Horde) with HTTP for ; Mon, 14 Feb 2005 15:23:19 +0100 Message-ID: <20050214152319.bqxon1xk0g008s4k@netchild.homeip.net> X-Priority: 3 (Normal) Date: Mon, 14 Feb 2005 15:23:19 +0100 From: Alexander Leidinger To: Nate Lawson References: <20050213231306.376E05D07@ptavv.es.net> <420FE3C7.6020003@root.org> In-Reply-To: <420FE3C7.6020003@root.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.0.2) / FreeBSD-4.11 X-ID: GvdBC8ZTgey4vPCft3WJ8c6OP0XmhHufSF6qWan1CtrQGn5g6s79rk@t-dialin.net X-TOI-MSGID: 953de613-f48f-4b1f-b963-6ef3a1318536 cc: acpi@freebsd.org cc: current@freebsd.org Subject: Re: HEADSUP: cpufreq import complete, acpi_throttling changed X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Feb 2005 14:24:08 -0000 Nate Lawson wrote: > One person reported Cx states being broken by the cpufreq import. > (Well, actually he got a C3 state that he didn't have before but it > didn't work.) I don't know if it is because of the cpufreq import. But because of the cpufreq import I've looked again at the acpi sysctl's and noticed this new state which wasn't there before. "Didn't work" means "the systems freezes hard, no keyboard interrupt is processed". Bye, Alexander. -- http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 LAWSUIT: A machine which you go into as a pig and come out as a sausage. -- Ambrose Bierce From owner-freebsd-acpi@FreeBSD.ORG Mon Feb 14 14:54:09 2005 Return-Path: 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 D074716A4CE for ; Mon, 14 Feb 2005 14:54:09 +0000 (GMT) Received: from poup.poupinou.org (poup.poupinou.org [195.101.94.96]) by mx1.FreeBSD.org (Postfix) with ESMTP id 62E9B43D1F for ; Mon, 14 Feb 2005 14:54:09 +0000 (GMT) (envelope-from ducrot@poupinou.org) Received: from ducrot by poup.poupinou.org with local (Exim) id 1D0hbz-0006pb-00; Mon, 14 Feb 2005 15:54:07 +0100 Date: Mon, 14 Feb 2005 15:54:07 +0100 To: ZC Wong Message-ID: <20050214145407.GL1145@poupinou.org> References: <420C9C32.5090409@acm.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <420C9C32.5090409@acm.org> User-Agent: Mutt/1.5.6+20040907i From: Bruno Ducrot cc: freebsd-acpi@freebsd.org Subject: Re: Suspend to disk on a Toshiba Portege R100 X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Feb 2005 14:54:09 -0000 On Fri, Feb 11, 2005 at 11:51:14AM +0000, ZC Wong wrote: > Hi, > > I installed FreeBSD 5.3 release on my Toshiba Portege R100. > > S4BIOS worked but it doesn't suspend to disk, it looks like it?s > basically doing the same thing as S3 when I try ?acpiconf ?s 4? with > hw.acpi.s4bios set to 1. S4OS (hw.acpi.s4bios=0) doesn?t work, it brings > the machine down. > Is that one a real toshiba? If not, I used some time ago a toshiba with a phoenix's notebook bios and after using http://www.procyon.com/~pda/lphdisk/ this worked for me (but under Linux, though I'm sure it would have worked under FreeBSD). If it's a real toshiba, there is some stuff that may be need to be implemented, using some propritary interfaces documented here: http://www.buzzard.org.uk/toshiba/docs.html (you need the 2 pdf). It may be possible also that, when under ACPI mode, all you need is an IBM suspend partition, but I can't tell for sure. Cheers, -- Bruno Ducrot -- Which is worse: ignorance or apathy? -- Don't know. Don't care. From owner-freebsd-acpi@FreeBSD.ORG Mon Feb 14 15:18:18 2005 Return-Path: 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 9686916A4CE for ; Mon, 14 Feb 2005 15:18:18 +0000 (GMT) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.204]) by mx1.FreeBSD.org (Postfix) with ESMTP id 63B2143D31 for ; Mon, 14 Feb 2005 15:18:17 +0000 (GMT) (envelope-from leafy7382@gmail.com) Received: by rproxy.gmail.com with SMTP id 34so447634rns for ; Mon, 14 Feb 2005 07:18:16 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=XOB7cR7d3J5mI4WJ2FbH+5RMxUtrVUWrV7hcXWng/AIGRq7K7ETk6FWrl00hhCBm8N+hkELD2k/ufJDja6F4hhy0L1qPdqhAz59R4sloJLLhftgiu0qMzkv79MOmo0w9ex7LNla+a00yDgBVtkPqVVD7joFVkcXemFPVVYm2O7k= Received: by 10.38.206.80 with SMTP id d80mr169109rng; Mon, 14 Feb 2005 07:18:16 -0800 (PST) Received: by 10.38.8.9 with HTTP; Mon, 14 Feb 2005 07:18:15 -0800 (PST) Message-ID: Date: Mon, 14 Feb 2005 23:18:15 +0800 From: Jiawei Ye To: Alexander Leidinger In-Reply-To: <20050214152319.bqxon1xk0g008s4k@netchild.homeip.net> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <20050213231306.376E05D07@ptavv.es.net> <420FE3C7.6020003@root.org> <20050214152319.bqxon1xk0g008s4k@netchild.homeip.net> cc: acpi@freebsd.org cc: current@freebsd.org Subject: Re: HEADSUP: cpufreq import complete, acpi_throttling changed X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Jiawei Ye List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Feb 2005 15:18:18 -0000 On Mon, 14 Feb 2005 15:23:19 +0100, Alexander Leidinger wrote: > I don't know if it is because of the cpufreq import. But because of the > cpufreq import I've looked again at the acpi sysctl's and noticed this new > state which wasn't there before. "Didn't work" means "the systems freezes > hard, no keyboard interrupt is processed". > > Bye, > Alexander. I have a funny situation there. kldloading acpi_perf and then unloading results in this: leafy@chihiro:~$ sudo kldunload acpi_perf kldunload: can't unload file: Device not configured leafy@chihiro:~$ sysctl dev.cpu dev.cpu.0.%desc: ACPI CPU dev.cpu.0.%driver: cpu dev.cpu.0.%location: handle=\_PR_.CPU1 dev.cpu.0.%pnpinfo: _HID=none _UID=0 dev.cpu.0.%parent: acpi0 leafy@chihiro:~$ dmesg -a |grep CPU CPU: Intel(R) Pentium(R) 4 CPU 1.80GHz (1816.99-MHz 686-class CPU) cpu0: on acpi0 acpi_throttle0: on cpu0 Is this expected? -- "Without the userland, the kernel is useless." --inspired by The Tao of Programming From owner-freebsd-acpi@FreeBSD.ORG Mon Feb 14 16:27:03 2005 Return-Path: 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 86C0216A4CF; Mon, 14 Feb 2005 16:27:03 +0000 (GMT) Received: from ylpvm01.prodigy.net (ylpvm01-ext.prodigy.net [207.115.57.32]) by mx1.FreeBSD.org (Postfix) with ESMTP id 326F943D39; Mon, 14 Feb 2005 16:27:03 +0000 (GMT) (envelope-from nate@root.org) Received: from [10.0.5.51] (adsl-64-171-186-189.dsl.snfc21.pacbell.net [64.171.186.189])j1EGR1vE022165; Mon, 14 Feb 2005 11:27:01 -0500 Message-ID: <4210D155.6080706@root.org> Date: Mon, 14 Feb 2005 08:27:01 -0800 From: Nate Lawson User-Agent: Mozilla Thunderbird 1.0RC1 (X11/20041205) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jiawei Ye References: <20050213231306.376E05D07@ptavv.es.net> <420FE3C7.6020003@root.org> <20050214152319.bqxon1xk0g008s4k@netchild.homeip.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: acpi@freebsd.org cc: Alexander Leidinger cc: current@freebsd.org Subject: Re: HEADSUP: cpufreq import complete, acpi_throttling changed X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Feb 2005 16:27:03 -0000 Jiawei Ye wrote: > On Mon, 14 Feb 2005 15:23:19 +0100, Alexander Leidinger > wrote: > >>I don't know if it is because of the cpufreq import. But because of the >>cpufreq import I've looked again at the acpi sysctl's and noticed this new >>state which wasn't there before. "Didn't work" means "the systems freezes >>hard, no keyboard interrupt is processed". >> >>Bye, >>Alexander. > > I have a funny situation there. kldloading acpi_perf and then > unloading results in this: > leafy@chihiro:~$ sudo kldunload acpi_perf > kldunload: can't unload file: Device not configured cpufreq et al don't fully support unloading yet. -- Nate From owner-freebsd-acpi@FreeBSD.ORG Mon Feb 14 16:41:48 2005 Return-Path: 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 10E4116A4CE; Mon, 14 Feb 2005 16:41:48 +0000 (GMT) Received: from postal3.es.net (postal3.es.net [198.128.3.207]) by mx1.FreeBSD.org (Postfix) with ESMTP id A02C243D49; Mon, 14 Feb 2005 16:41:47 +0000 (GMT) (envelope-from oberman@es.net) Received: from ptavv.es.net ([198.128.4.29]) by postal3.es.net (Postal Node 3) with ESMTP (SSL) id IBA74465; Mon, 14 Feb 2005 08:41:47 -0800 Received: from ptavv (localhost [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id 7BB8B5D07; Mon, 14 Feb 2005 08:41:46 -0800 (PST) To: Nate Lawson In-reply-to: Your message of "Sun, 13 Feb 2005 15:33:27 PST." <420FE3C7.6020003@root.org> Date: Mon, 14 Feb 2005 08:41:46 -0800 From: "Kevin Oberman" Message-Id: <20050214164146.7BB8B5D07@ptavv.es.net> cc: acpi@freebsd.org cc: current@freebsd.org Subject: Re: HEADSUP: cpufreq import complete, acpi_throttling changed X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Feb 2005 16:41:48 -0000 > Date: Sun, 13 Feb 2005 15:33:27 -0800 > From: Nate Lawson > > Kevin Oberman wrote: > >>Date: Sun, 06 Feb 2005 13:21:32 -0800 > >>From: Nate Lawson > >>Sender: owner-freebsd-acpi@freebsd.org > >> > >> > >>If you have throttling, please test the new configuration to be sure it > >>still works as before. Final upcoming work will be manpage support and > >>bugfixing as necessary. > > > > > > On my T30, throttling has simply vanished. Kernel sources as of this > > afternoon at about 11:00 PST. > > > > sysctl hw.acpi does not list any throttling entries at all. > > It shouldn't, they were merged into the sysctl dev.cpu output as you > mention below. > > > It does list an amazing number of frequency settings, but only 1800 and > > 1200 seem to actually work. Perhaps the others are derived by mixing the > > two capabilities? On the earlier versions of cpufreq I was getting only > > the two frequencies listed along with the 8 throttling states. > > > > Did I miss a message on this? > > Try cvsupping to now. I did some commits about an hour or two ago that > should address throttling not attaching. > > > I am especially concerned because my CPU is now running VERY hot when > > busy. It never used to exceed about 180F and now it quickly jumps to > > 190+ when the system is working (such as a buildkernel). Since it was > > previously running without throttling, I don't understand why things are > > suddenly worse. > > > > Any idea on what is happening? I don't want to fry my T30. > > One person reported Cx states being broken by the cpufreq import. > (Well, actually he got a C3 state that he didn't have before but it > didn't work.) Try setting hw.acpi.cpu.cx_lowest to C1 or something > you're sure works. > > Send me the output of sysctl dev.cpu, dmesg, and devinfo -rv. Things are better now, and it was not really an ACPI issue. For about the millionth time I remind myself: Only change one thing at a time! At the same time that I started running cpufreq and acpi_perf, I also switched from 4BSD to ULE. This is why the system started running so much hotter! Throttling is now working correctly and I can keep my CPU at about 175(F) degrees or a kernel build by lowering the "frequency" from 1800 to 1350. My dmesg shows ACPI throttling setting up fine: cpu0: on acpi0 acpi_perf0: on cpu0 acpi_throttle0: on cpu0 I guess all I have really done is demonstrate that ULE is much more efficient than 4BSD. Thanks for the quick response and sorry for the false alarm. -- 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 Feb 14 17:24:40 2005 Return-Path: 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 3316E16A4CF for ; Mon, 14 Feb 2005 17:24:40 +0000 (GMT) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 81F9B43D45 for ; Mon, 14 Feb 2005 17:24:39 +0000 (GMT) (envelope-from leafy7382@gmail.com) Received: by rproxy.gmail.com with SMTP id 34so459749rns for ; Mon, 14 Feb 2005 09:24:38 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=mfpoFyknmwDQQXh6yZ47rzaKsXsiV5mI+O/RvJXPxtXVQ4/n0XL7P36R081WrnbUQteJDjWHDu3ZkghedWG42+mTlA+HeKn2SsBm3cXLDyLfsiAyMzrDqUg8OxGunb7yWZ57+BIqTAYxfpdgrs04Pzguzf7+94DmIcnahWz89RI= Received: by 10.38.179.61 with SMTP id b61mr163165rnf; Mon, 14 Feb 2005 09:24:38 -0800 (PST) Received: by 10.38.8.9 with HTTP; Mon, 14 Feb 2005 09:24:38 -0800 (PST) Message-ID: Date: Tue, 15 Feb 2005 01:24:38 +0800 From: Jiawei Ye To: Nate Lawson In-Reply-To: <4210D155.6080706@root.org> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <20050213231306.376E05D07@ptavv.es.net> <420FE3C7.6020003@root.org> <20050214152319.bqxon1xk0g008s4k@netchild.homeip.net> <4210D155.6080706@root.org> cc: acpi@freebsd.org cc: Alexander Leidinger cc: current@freebsd.org Subject: Re: HEADSUP: cpufreq import complete, acpi_throttling changed X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Jiawei Ye List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Feb 2005 17:24:40 -0000 On Mon, 14 Feb 2005 08:27:01 -0800, Nate Lawson wrote: > Jiawei Ye wrote: > cpufreq et al don't fully support unloading yet. > > -- > Nate > I've got it working, but the available frequencies seem to drift: root@chihiro:/home/leafy# sysctl dev.cpu dev.cpu.0.%desc: ACPI CPU dev.cpu.0.%driver: cpu dev.cpu.0.%location: handle=\_PR_.CPU1 dev.cpu.0.%pnpinfo: _HID=none _UID=0 dev.cpu.0.%parent: acpi0 dev.cpu.0.freq: 1819 dev.cpu.0.freq_levels: 2355/0 2060/0 1766/0 1471/0 1177/0 883/0 588/0 294/0 root@chihiro:/home/leafy# sysctl dev.cpu dev.cpu.0.%desc: ACPI CPU dev.cpu.0.%driver: cpu dev.cpu.0.%location: handle=\_PR_.CPU1 dev.cpu.0.%pnpinfo: _HID=none _UID=0 dev.cpu.0.%parent: acpi0 dev.cpu.0.freq: 1819 dev.cpu.0.freq_levels: 1821/0 1593/0 1365/0 1138/0 910/0 682/0 455/0 227/0 -- "Without the userland, the kernel is useless." --inspired by The Tao of Programming From owner-freebsd-acpi@FreeBSD.ORG Mon Feb 14 17:47:30 2005 Return-Path: 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 E7CD016A4CE for ; Mon, 14 Feb 2005 17:47:30 +0000 (GMT) Received: from sun13.bham.ac.uk (sun13.bham.ac.uk [147.188.128.145]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8049443D48 for ; Mon, 14 Feb 2005 17:47:30 +0000 (GMT) (envelope-from zcwong@acm.org) Received: from [147.188.128.127] (helo=bham.ac.uk) by sun13.bham.ac.uk with esmtp (Exim 4.10) id 1D0kJl-0003eW-00 for freebsd-acpi@freebsd.org; Mon, 14 Feb 2005 17:47:29 +0000 Received: from sci-fs1.bham.ac.uk ([147.188.118.71]) by bham.ac.uk with esmtp (Exim 4.43) id 1D0kJl-00046G-3l for freebsd-acpi@freebsd.org; Mon, 14 Feb 2005 17:47:29 +0000 Received: from hercules not authenticated [147.188.140.34] Novell NetWare; Mon, 14 Feb 2005 17:47:29 +0000 From: "ZC Wong" To: "'Bruno Ducrot'" Date: Mon, 14 Feb 2005 17:50:36 -0000 Message-ID: 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.3790.224 Thread-Index: AcUSpQkCoUtfsGLaRQGv8zNAYs8+dAAFw5Hw In-Reply-To: <20050214145407.GL1145@poupinou.org> X-BHAM-CUBE-wlist: LOCAL sci-fs1.bham.ac.uk X-BHAM-CUBE-processed: yes cc: freebsd-acpi@freebsd.org Subject: RE: Suspend to disk on a Toshiba Portege R100 X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Feb 2005 17:47:31 -0000 I've no idea if it's a 'real' Toshiba, this laptops is released a couple of years ago ish. It doesn't say anything indicating it has got a phoenix BIOS though. The configuration interface of the BIOS doesn't look like a phoenix one (I haven't seen a phoenix laptop BIOS before, but if it's similar to those PC ones). Can I just assume it's a real Toshiba? (I can try all the possibilities, just want to save a bit of time...I'm a bummer) Also, it doesn't use a hibernation partition but a hibernation file under windows, does that mean there are other possibilities or is the hibernation file part of S4OS which has nothing to do with S4BIOS? -----Original Message----- From: Bruno Ducrot [mailto:ducrot@poupinou.org] Sent: Monday, February 14, 2005 2:54 PM To: ZC Wong Cc: freebsd-acpi@freebsd.org Subject: Re: Suspend to disk on a Toshiba Portege R100 On Fri, Feb 11, 2005 at 11:51:14AM +0000, ZC Wong wrote: > Hi, > > I installed FreeBSD 5.3 release on my Toshiba Portege R100. > > S4BIOS worked but it doesn't suspend to disk, it looks like it?s > basically doing the same thing as S3 when I try ?acpiconf ?s 4? with > hw.acpi.s4bios set to 1. S4OS (hw.acpi.s4bios=0) doesn?t work, it brings > the machine down. > Is that one a real toshiba? If not, I used some time ago a toshiba with a phoenix's notebook bios and after using http://www.procyon.com/~pda/lphdisk/ this worked for me (but under Linux, though I'm sure it would have worked under FreeBSD). If it's a real toshiba, there is some stuff that may be need to be implemented, using some propritary interfaces documented here: http://www.buzzard.org.uk/toshiba/docs.html (you need the 2 pdf). It may be possible also that, when under ACPI mode, all you need is an IBM suspend partition, but I can't tell for sure. Cheers, -- Bruno Ducrot -- Which is worse: ignorance or apathy? -- Don't know. Don't care. From owner-freebsd-acpi@FreeBSD.ORG Mon Feb 14 18:32:28 2005 Return-Path: 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 1C72416A4CE for ; Mon, 14 Feb 2005 18:32:28 +0000 (GMT) Received: from poup.poupinou.org (poup.poupinou.org [195.101.94.96]) by mx1.FreeBSD.org (Postfix) with ESMTP id C404343D2D for ; Mon, 14 Feb 2005 18:32:27 +0000 (GMT) (envelope-from ducrot@poupinou.org) Received: from ducrot by poup.poupinou.org with local (Exim) id 1D0l1H-00077U-00; Mon, 14 Feb 2005 19:32:27 +0100 Date: Mon, 14 Feb 2005 19:32:27 +0100 To: ZC Wong Message-ID: <20050214183227.GO1145@poupinou.org> References: <20050214145407.GL1145@poupinou.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6+20040907i From: Bruno Ducrot cc: freebsd-acpi@freebsd.org Subject: Re: Suspend to disk on a Toshiba Portege R100 X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Feb 2005 18:32:28 -0000 On Mon, Feb 14, 2005 at 05:50:36PM -0000, ZC Wong wrote: > I've no idea if it's a 'real' Toshiba, this laptops is released a couple of > years ago ish. It doesn't say anything indicating it has got a phoenix BIOS > though. The configuration interface of the BIOS doesn't look like a phoenix > one (I haven't seen a phoenix laptop BIOS before, but if it's similar to > those PC ones). Can I just assume it's a real Toshiba? (I can try all the > possibilities, just want to save a bit of time...I'm a bummer) I just checked. Its shipped with a toshiba bios. > Also, it doesn't use a hibernation partition but a hibernation file under > windows, does that mean there are other possibilities or is the hibernation > file part of S4OS which has nothing to do with S4BIOS? S4BIOS is a sort of compatibility thing when the OS is unable to provide a way to suspend-to-disk (and require a suspend partition or sometimes a FAT95 partition as the first primary which I think is the case for you). S4OS is when the OS is able to suspend-to-disk with minimal help from the BIOS. With S4OS, you just have to design how you save memory to disk since thats no more provided by the BIOS. Cheers, -- Bruno Ducrot -- Which is worse: ignorance or apathy? -- Don't know. Don't care. From owner-freebsd-acpi@FreeBSD.ORG Mon Feb 14 18:33:07 2005 Return-Path: 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 CBD2D16A4CE; Mon, 14 Feb 2005 18:33:07 +0000 (GMT) Received: from www.cryptography.com (li-22.members.linode.com [64.5.53.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id 82E6243D41; Mon, 14 Feb 2005 18:33:07 +0000 (GMT) (envelope-from nate@root.org) Received: from [10.0.0.34] (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 j1EIX6Zj013368 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 14 Feb 2005 10:33:06 -0800 Message-ID: <4210EEE1.8090802@root.org> Date: Mon, 14 Feb 2005 10:33:05 -0800 From: Nate Lawson User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jiawei Ye References: <20050213231306.376E05D07@ptavv.es.net> <420FE3C7.6020003@root.org> <20050214152319.bqxon1xk0g008s4k@netchild.homeip.net> <4210D155.6080706@root.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: acpi@freebsd.org cc: current@freebsd.org Subject: Re: HEADSUP: cpufreq import complete, acpi_throttling changed X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Feb 2005 18:33:07 -0000 Jiawei Ye wrote: > On Mon, 14 Feb 2005 08:27:01 -0800, Nate Lawson wrote: > >>Jiawei Ye wrote: >>cpufreq et al don't fully support unloading yet. >> >>-- >>Nate >> > > I've got it working, but the available frequencies seem to drift: > root@chihiro:/home/leafy# sysctl dev.cpu > dev.cpu.0.%desc: ACPI CPU > dev.cpu.0.%driver: cpu > dev.cpu.0.%location: handle=\_PR_.CPU1 > dev.cpu.0.%pnpinfo: _HID=none _UID=0 > dev.cpu.0.%parent: acpi0 > dev.cpu.0.freq: 1819 > dev.cpu.0.freq_levels: 2355/0 2060/0 1766/0 1471/0 1177/0 883/0 588/0 294/0 > root@chihiro:/home/leafy# sysctl dev.cpu > dev.cpu.0.%desc: ACPI CPU > dev.cpu.0.%driver: cpu > dev.cpu.0.%location: handle=\_PR_.CPU1 > dev.cpu.0.%pnpinfo: _HID=none _UID=0 > dev.cpu.0.%parent: acpi0 > dev.cpu.0.freq: 1819 > dev.cpu.0.freq_levels: 1821/0 1593/0 1365/0 1138/0 910/0 682/0 455/0 227/0 Thanks. This is a bug in how we handle relative-only systems (i.e., just acpi_throttle and no other driver). I'll work on a fix. The only effect is that the values look incorrect due to a calibration error. Actually using them should work properly. -- Nate From owner-freebsd-acpi@FreeBSD.ORG Mon Feb 14 18:35:18 2005 Return-Path: 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 6E45816A4CE; Mon, 14 Feb 2005 18:35:18 +0000 (GMT) Received: from www.cryptography.com (li-22.members.linode.com [64.5.53.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id 178F243D1F; Mon, 14 Feb 2005 18:35:18 +0000 (GMT) (envelope-from nate@root.org) Received: from [10.0.0.34] (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 j1EIZBZj013391 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 14 Feb 2005 10:35:11 -0800 Message-ID: <4210EF5E.6020901@root.org> Date: Mon, 14 Feb 2005 10:35:10 -0800 From: Nate Lawson User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Kevin Oberman References: <20050214164146.7BB8B5D07@ptavv.es.net> In-Reply-To: <20050214164146.7BB8B5D07@ptavv.es.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: acpi@freebsd.org cc: current@freebsd.org Subject: Re: HEADSUP: cpufreq import complete, acpi_throttling changed X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Feb 2005 18:35:18 -0000 Kevin Oberman wrote: >>Date: Sun, 13 Feb 2005 15:33:27 -0800 >>From: Nate Lawson >> >>One person reported Cx states being broken by the cpufreq import. >>(Well, actually he got a C3 state that he didn't have before but it >>didn't work.) Try setting hw.acpi.cpu.cx_lowest to C1 or something >>you're sure works. I think I've figured that one out also. When we write PSTATE_CNT to the SMI control register, his system decides to offer another Cx state in addition to providing OS control over Px states. It probably is using this as an ad-hoc way to detect that we're an advanced OS. > Things are better now, and it was not really an ACPI issue. > > For about the millionth time I remind myself: Only change one thing at a > time! > > At the same time that I started running cpufreq and acpi_perf, I also > switched from 4BSD to ULE. This is why the system started running so > much hotter! Weird. > Throttling is now working correctly and I can keep my CPU at about 175(F) > degrees or a kernel build by lowering the "frequency" from 1800 to > 1350. My dmesg shows ACPI throttling setting up fine: > cpu0: on acpi0 > acpi_perf0: on cpu0 > acpi_throttle0: on cpu0 Great! -- Nate From owner-freebsd-acpi@FreeBSD.ORG Mon Feb 14 18:35:54 2005 Return-Path: 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 7B83C16A4CE for ; Mon, 14 Feb 2005 18:35:54 +0000 (GMT) Received: from www.cryptography.com (li-22.members.linode.com [64.5.53.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id 27C6043D2D for ; Mon, 14 Feb 2005 18:35:54 +0000 (GMT) (envelope-from nate@root.org) Received: from [10.0.0.34] (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 j1EIZkZj013399 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 14 Feb 2005 10:35:47 -0800 Message-ID: <4210EF82.5000405@root.org> Date: Mon, 14 Feb 2005 10:35:46 -0800 From: Nate Lawson User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Volf, Frank" References: <9FAFEFB20AA5374391ED09FE09EE5885775CE7@nlex003.nl.int.atosorigin.com> In-Reply-To: <9FAFEFB20AA5374391ED09FE09EE5885775CE7@nlex003.nl.int.atosorigin.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: acpi@freebsd.org Subject: Re: Ethernet cards not working - Interrrupt routing problem? X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Feb 2005 18:35:54 -0000 Volf, Frank wrote: > Hi Nate, > > Thanks for your reply, here is the boot -v that you requested (upgrading > the > BIOS was a NO-OP since we were already running the latest version. > > I can't make heads-or-tails of this, hopefully you can find something. > > This is with FreeBSD-5 STABLE from last week. I have also included the > Kernel config file for your reference. I saw your reply saying this is a bad SCSI cable issue. Thanks. -- Nate From owner-freebsd-acpi@FreeBSD.ORG Mon Feb 14 21:20:27 2005 Return-Path: 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 1F5A316A4CE for ; Mon, 14 Feb 2005 21:20:27 +0000 (GMT) Received: from pne-smtpout1-sn2.hy.skanova.net (pne-smtpout1-sn2.hy.skanova.net [81.228.8.83]) by mx1.FreeBSD.org (Postfix) with ESMTP id A4FBC43D5A for ; Mon, 14 Feb 2005 21:20:26 +0000 (GMT) (envelope-from pawel.worach@telia.com) Received: from [127.0.0.1] (81.225.14.129) by pne-smtpout1-sn2.hy.skanova.net (7.1.026.7) (authenticated as u86211448) id 41E321670054F5D4; Mon, 14 Feb 2005 22:19:50 +0100 Message-ID: <421115F4.60100@telia.com> Date: Mon, 14 Feb 2005 22:19:48 +0100 From: Pawel Worach User-Agent: Mozilla Thunderbird 1.0 (X11/20050214) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Nate Lawson References: <42068A5C.1030300@root.org> <4206B5A6.20100@telia.com> <420FC806.5060200@root.org> In-Reply-To: <420FC806.5060200@root.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: acpi@freebsd.org Subject: Re: HEADSUP: cpufreq import complete, acpi_throttling changed X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Feb 2005 21:20:27 -0000 Nate Lawson wrote: > Any word if the patch I sent helped? Hi, sorry for the delay. I bumped the number of retries to 2000 and I can still repro. the error if the cpu has some load, I believe that is expected. Even when "idle" (gnome desktop running) it works fine with 100, I think the first time I tested it I had mplayer running. I can't see a real-life reason for bumping the number of retries, from all speeds above 200Mhz I can step back up to 1.7Ghz without problems under light cpu load. The power_profile script should probably have a min limit, 75Mhz is ridiculous :) Another cool thing would be if the speed could be stepped automagically based on current battery level, that would likely be the job for a powerd(8). - Pawel > > Pawel Worach wrote: > >> Nate Lawson wrote: >> >>> I've finished the major work of importing cpufreq. As part of this, >>> the sysctls for acpi throttling have been removed. The power_profile >>> script has been updated, so you can use performance/economy_cpu_freq= >>> in rc.conf to set AC on/offline cpu frequencies. The acpi throttling >>> support has been compiled into acpi_perf.ko so load that to get >>> throttling. Do a sysctl dev.cpu to get an understanding of the >>> cpufreq sysctls. >>> >> >> Tried this on my ThinkPad T41, seems to work great except I managed to >> produce >> this message one time. >> >> -- Power is plugged in here, freq=1700 >> acpi_acad0: Off Line >> cpu0: Performance states changed >> -- Power unplugged, power_profile adjusted freq to 75 :) >> acpi_acad0: On Line >> -- Power reconnected, freq stayed at 75 >> acpi_perf0: Px transition to 1700 failed >> acpi_perf0: set freq failed, err 6 >> stray irq7 >> stray irq7 >> stray irq7 >> stray irq7 >> too many stray irq 7's: not logging anymore >> cpu0: Performance states changed >> -- Manually pushed freq back to 1700 without problems >> >> CPU: Intel(R) Pentium(R) M processor 1700MHz (1698.56-MHz 686-class CPU) >> Origin = "GenuineIntel" Id = 0x695 Stepping = 5 >> >> # sysctl dev.cpu >> dev.cpu.0.%desc: ACPI CPU (3 Cx states) >> dev.cpu.0.%driver: cpu >> dev.cpu.0.%location: handle=\_PR_.CPU_ >> dev.cpu.0.%pnpinfo: _HID=none _UID=0 >> dev.cpu.0.%parent: acpi0 >> dev.cpu.0.freq: 1700 >> dev.cpu.0.freq_levels: 1700/24500 1487/21437 1400/19500 1275/18375 >> 1225/17062 1200/16000 1062/15312 1000/13000 900/12000 875/12187 >> 850/12250 800/9500 750/10000 700/9750 637/9187 600/6000 525/7312 >> 500/6500 450/6000 425/6125 400/4750 375/4875 350/4875 300/4000 >> 250/3250 212/3062 175/2437 150/2000 125/1625 100/1187 75/750 >> >> Both acpi_perf.ko and cpufreq.ko loaded. >> > > From owner-freebsd-acpi@FreeBSD.ORG Mon Feb 14 21:44:24 2005 Return-Path: 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 1E2A016A4CE for ; Mon, 14 Feb 2005 21:44:24 +0000 (GMT) Received: from postal1.es.net (postal1.es.net [198.128.3.205]) by mx1.FreeBSD.org (Postfix) with ESMTP id B38BC43D3F for ; Mon, 14 Feb 2005 21:44:23 +0000 (GMT) (envelope-from oberman@es.net) Received: from ptavv.es.net ([198.128.4.29]) by postal1.es.net (Postal Node 1) with ESMTP (SSL) id IBA74465; Mon, 14 Feb 2005 13:44:23 -0800 Received: from ptavv (localhost [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id C9F925D07; Mon, 14 Feb 2005 13:44:22 -0800 (PST) To: Pawel Worach In-reply-to: Your message of "Mon, 14 Feb 2005 22:19:48 +0100." <421115F4.60100@telia.com> Date: Mon, 14 Feb 2005 13:44:22 -0800 From: "Kevin Oberman" Message-Id: <20050214214422.C9F925D07@ptavv.es.net> cc: acpi@freebsd.org Subject: Re: HEADSUP: cpufreq import complete, acpi_throttling changed X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Feb 2005 21:44:24 -0000 > Date: Mon, 14 Feb 2005 22:19:48 +0100 > From: Pawel Worach > Sender: owner-freebsd-acpi@freebsd.org > > Nate Lawson wrote: > > Any word if the patch I sent helped? > > Hi, sorry for the delay. I bumped the number of retries to 2000 and I > can still repro. the error if the cpu has some load, I believe that is > expected. Even when "idle" (gnome desktop running) it works fine with > 100, I think the first time I tested it I had mplayer running. I can't > see a real-life reason for bumping the number of retries, from all > speeds above 200Mhz I can step back up to 1.7Ghz without problems > under light cpu load. The power_profile script should probably have a > min limit, 75Mhz is ridiculous :) > > Another cool thing would be if the speed could be stepped > automagically based on current battery level, that would likely be the > job for a powerd(8). I've been things about this, too, and I think that stepping things down with battery level is not the answer. I think it MIGHT make sense to do so based on battery discharge rate. This would allow a user to configure an approximate battery "lifetime". It is especially important as batteries wear and, if two batteries are present, one discharges faster than the other. The other issue is thermal. I would assume that the frequency should be decreased when _PSV is reached, but should it continue to drop the frequency until the temperature stabilizes or until it drops to _PSV. I believe the latter is a better choice, especially as the effect is not quite instantaneous, and since it is only read by ACPI at fairly long intervals. This means that the adjustment should not be too aggressive to prevent continual oscillation of the frequency and temperature. And when do you start increasing the frequency again when temperature drops? Once again, you want to reach a thermal stability and not oscillate around _PSV (or at least do so slowly. As there is probably substantial variation between systems, so a settable hysteresis is probably needed for really good results. (This gets worse for system which don't support both throttling and frequencies.) And, should TCC be folded into the equation for P4 systems? After all, that's what it's for. I dont; see any way to set TCC to automatic at the moment, but that could be a significant tool in thermal stability. (There may be a way, but I didn't see it in the sources.) Lot of things to consider. -- 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 Tue Feb 15 07:46:39 2005 Return-Path: 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 46ACF16A4CE; Tue, 15 Feb 2005 07:46:39 +0000 (GMT) Received: from ylpvm15.prodigy.net (ylpvm15-ext.prodigy.net [207.115.57.46]) by mx1.FreeBSD.org (Postfix) with ESMTP id E366443D46; Tue, 15 Feb 2005 07:46:38 +0000 (GMT) (envelope-from nate@root.org) Received: from [10.0.5.51] (adsl-64-171-186-189.dsl.snfc21.pacbell.net [64.171.186.189])j1F7gObs007595; Tue, 15 Feb 2005 02:42:25 -0500 Message-ID: <4211A8DD.4010406@root.org> Date: Mon, 14 Feb 2005 23:46:37 -0800 From: Nate Lawson User-Agent: Mozilla Thunderbird 1.0RC1 (X11/20041205) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jiawei Ye References: <20050213231306.376E05D07@ptavv.es.net> <420FE3C7.6020003@root.org> <20050214152319.bqxon1xk0g008s4k@netchild.homeip.net> <4210D155.6080706@root.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: acpi@freebsd.org cc: Alexander Leidinger cc: current@freebsd.org Subject: Re: HEADSUP: cpufreq import complete, acpi_throttling changed X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Feb 2005 07:46:39 -0000 Jiawei Ye wrote: > On Mon, 14 Feb 2005 08:27:01 -0800, Nate Lawson wrote: > >>Jiawei Ye wrote: >>cpufreq et al don't fully support unloading yet. >> >>-- >>Nate >> > > I've got it working, but the available frequencies seem to drift: > root@chihiro:/home/leafy# sysctl dev.cpu > dev.cpu.0.%desc: ACPI CPU > dev.cpu.0.%driver: cpu > dev.cpu.0.%location: handle=\_PR_.CPU1 > dev.cpu.0.%pnpinfo: _HID=none _UID=0 > dev.cpu.0.%parent: acpi0 > dev.cpu.0.freq: 1819 > dev.cpu.0.freq_levels: 2355/0 2060/0 1766/0 1471/0 1177/0 883/0 588/0 294/0 > root@chihiro:/home/leafy# sysctl dev.cpu > dev.cpu.0.%desc: ACPI CPU > dev.cpu.0.%driver: cpu > dev.cpu.0.%location: handle=\_PR_.CPU1 > dev.cpu.0.%pnpinfo: _HID=none _UID=0 > dev.cpu.0.%parent: acpi0 > dev.cpu.0.freq: 1819 > dev.cpu.0.freq_levels: 1821/0 1593/0 1365/0 1138/0 910/0 682/0 455/0 227/0 > I just committed a patch that may fix this issue. -- Nate From owner-freebsd-acpi@FreeBSD.ORG Tue Feb 15 08:13:14 2005 Return-Path: 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 23CB816A4E9 for ; Tue, 15 Feb 2005 08:13:14 +0000 (GMT) Received: from ylpvm01.prodigy.net (ylpvm01-ext.prodigy.net [207.115.57.32]) by mx1.FreeBSD.org (Postfix) with ESMTP id 95DCA43D48 for ; Tue, 15 Feb 2005 08:13:11 +0000 (GMT) (envelope-from nate@root.org) Received: from [10.0.5.51] (adsl-64-171-186-189.dsl.snfc21.pacbell.net [64.171.186.189])j1F8D6vE005877; Tue, 15 Feb 2005 03:13:06 -0500 Message-ID: <4211AF11.7050109@root.org> Date: Tue, 15 Feb 2005 00:13:05 -0800 From: Nate Lawson User-Agent: Mozilla Thunderbird 1.0RC1 (X11/20041205) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Kevin Oberman References: <20050214214422.C9F925D07@ptavv.es.net> In-Reply-To: <20050214214422.C9F925D07@ptavv.es.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: acpi@freebsd.org Subject: Re: HEADSUP: cpufreq import complete, acpi_throttling changed X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Feb 2005 08:13:14 -0000 Kevin Oberman wrote: >>Date: Mon, 14 Feb 2005 22:19:48 +0100 >>From: Pawel Worach >> >>Hi, sorry for the delay. I bumped the number of retries to 2000 and I >>can still repro. the error if the cpu has some load, I believe that is >>expected. Even when "idle" (gnome desktop running) it works fine with >>100, I think the first time I tested it I had mplayer running. I can't >>see a real-life reason for bumping the number of retries, from all >>speeds above 200Mhz I can step back up to 1.7Ghz without problems >>under light cpu load. The power_profile script should probably have a >>min limit, 75Mhz is ridiculous :) Ok, no problem. >>Another cool thing would be if the speed could be stepped >>automagically based on current battery level, that would likely be the >>job for a powerd(8). > > > I've been things about this, too, Strangely, I've thought about this for 2 years. ;-) > and I think that stepping things down > with battery level is not the answer. I think it MIGHT make sense to do > so based on battery discharge rate. This would allow a user to configure > an approximate battery "lifetime". It is especially important as > batteries wear and, if two batteries are present, one discharges faster > than the other. I don't think battery level or discharge rate is a useful control input. Think about if you have your laptop sitting on your desk for an hour, and then want to buildworld for an hour. You certainly want the system to power everything possible down for the first hour and run as fast as possible the second hour. The factor almost everyone gets wrong is the integral: Nate Efficiency = Useful Work Done / Amp-hours burned Total amp-hours = Sum[t: 0...Tdead](PowerUsed(t)) This formula explains why you should run the CPU at full speed whenever there is work to be done (increasing the numerator) and run it as low as possible when idle (decreasing the loss of the denominator). The denominator is ultimately fixed (you only have so much battery). On AC power, the denominator is infinite (meaning Nate is never very efficient). In this case, thermal (and hence noise) issues become an issue. You also want to keep your power bill low so conserving AC power is a minor but valid concern (think: server farm.) I think the control inputs should be current system load and thermal level. The system load control function would take the current instantaneous load, all previous measured loads, and current CPU freq level and output its desired frequency. The thermal function would take into account temperatures of each zone, current active coolers, desired temperature, current CPU freq, and output its desired frequency. There would be a weighting value that would allow the user to select which factor dominates the decision. All this is a good research project. Don't forget to throw in sleep states (i.e. S1 or S3) and disk spindown if you want to be complete. The Linux "laptop mode" patches are a good example how to do some of this right, as well as iBook behavior. > The other issue is thermal. I would assume that the frequency should be > decreased when _PSV is reached, but should it continue to drop the > frequency until the temperature stabilizes or until it drops to _PSV. I > believe the latter is a better choice, especially as the effect is not > quite instantaneous, and since it is only read by ACPI at fairly long > intervals. This means that the adjustment should not be too aggressive > to prevent continual oscillation of the frequency and temperature. > > And when do you start increasing the frequency again when temperature > drops? Once again, you want to reach a thermal stability and not > oscillate around _PSV (or at least do so slowly. As there is probably > substantial variation between systems, so a settable hysteresis is > probably needed for really good results. (This gets worse for system > which don't support both throttling and frequencies.) _PSV should be implemented in acpi_thermal. It would control the frequency through CPUFREQ_GET/SET. That's one main reason why I added both user and kernel interfaces. acpi_thermal doesn't have to know what cpufreq devices are on the system, it just can use whatever is there. If you read the section of the ACPI spec on _PSV, you'll see it offers an equation and methods for the BIOS to signal the appropriate coefficients for getting good hysteresis. > And, should TCC be folded into the equation for P4 systems? After all, > that's what it's for. I dont; see any way to set TCC to automatic at the > moment, but that could be a significant tool in thermal stability. > (There may be a way, but I didn't see it in the sources.) I'm soon going to move p4tcc to be another relative cpufreq driver. It will be under manual control although the driver is free to implement some hidden ultimate limit via automatic control to keep the chip from melting. I think TCC already has that non-configurable feature in hw no matter what we do. Whatever the case, I think optional cpufreq management (i.e. powerd) should be done in usermode. This allows it to make complex decisions and link with lots of components (want to coordinate with a cluster over the network? sure!) If it crashes, the system just uses more power or is slow until a user restarts it. However, thermal or other emergency uses of cpufreq should be in the kernel and use the higher priorities so that the system doesn't melt down when a fan dies. -- Nate From owner-freebsd-acpi@FreeBSD.ORG Tue Feb 15 15:10:08 2005 Return-Path: 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 6EE2E16A4D1 for ; Tue, 15 Feb 2005 15:10:08 +0000 (GMT) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.197]) by mx1.FreeBSD.org (Postfix) with ESMTP id C7EE543D49 for ; Tue, 15 Feb 2005 15:10:07 +0000 (GMT) (envelope-from leafy7382@gmail.com) Received: by rproxy.gmail.com with SMTP id 34so37098rns for ; Tue, 15 Feb 2005 07:10:07 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=QQBW7oWT3xH7GizAHkW+z8A4UbePRXkqLXRNwolp0Za4oN9ggVYbpHnbKtnYPs6B227QjJpPxRdBhx597GW/CUjLnht298sEmaqj0fpQRlNhmPMddqBmUXnV9eWAbNOYdDEgH0GoJQaInPIcjJNPVwegeKhBkMxZWSmtEAwzc+g= Received: by 10.38.8.16 with SMTP id 16mr25224rnh; Tue, 15 Feb 2005 07:10:07 -0800 (PST) Received: by 10.38.8.9 with HTTP; Tue, 15 Feb 2005 07:10:07 -0800 (PST) Message-ID: Date: Tue, 15 Feb 2005 23:10:07 +0800 From: Jiawei Ye To: Nate Lawson In-Reply-To: <4211A8DD.4010406@root.org> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <20050213231306.376E05D07@ptavv.es.net> <420FE3C7.6020003@root.org> <20050214152319.bqxon1xk0g008s4k@netchild.homeip.net> <4210D155.6080706@root.org> <4211A8DD.4010406@root.org> cc: acpi@freebsd.org cc: Alexander Leidinger cc: current@freebsd.org Subject: Re: HEADSUP: cpufreq import complete, acpi_throttling changed X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Jiawei Ye List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Feb 2005 15:10:08 -0000 On Mon, 14 Feb 2005 23:46:37 -0800, Nate Lawson wrote: > I just committed a patch that may fix this issue. > > -- > Nate > Does this look right to you? leafy@chihiro:~$ sysctl dev.cpu dev.cpu.0.%desc: ACPI CPU dev.cpu.0.%driver: cpu dev.cpu.0.%location: handle=\_PR_.CPU1 dev.cpu.0.%pnpinfo: _HID=none _UID=0 dev.cpu.0.%parent: acpi0 dev.cpu.0.freq: 1818 dev.cpu.0.freq_levels: 1818/-1 1590/-1 1363/-1 1136/-1 909/-1 681/-1 454/-1 227/-1 -- "Without the userland, the kernel is useless." --inspired by The Tao of Programming From owner-freebsd-acpi@FreeBSD.ORG Tue Feb 15 16:34:19 2005 Return-Path: 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 E7F6C16A4CE; Tue, 15 Feb 2005 16:34:19 +0000 (GMT) Received: from www.cryptography.com (li-22.members.linode.com [64.5.53.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id A410443D2D; Tue, 15 Feb 2005 16:34:19 +0000 (GMT) (envelope-from nate@root.org) Received: from [10.0.5.51] (adsl-64-171-186-189.dsl.snfc21.pacbell.net [64.171.186.189]) by www.cryptography.com (8.12.8/8.12.8) with ESMTP id j1FGYIZj029166 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 15 Feb 2005 08:34:18 -0800 Message-ID: <42122489.4030705@root.org> Date: Tue, 15 Feb 2005 08:34:17 -0800 From: Nate Lawson User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jiawei Ye References: <20050213231306.376E05D07@ptavv.es.net> <420FE3C7.6020003@root.org> <20050214152319.bqxon1xk0g008s4k@netchild.homeip.net> <4210D155.6080706@root.org> <4211A8DD.4010406@root.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: acpi@freebsd.org cc: Alexander Leidinger cc: current@freebsd.org Subject: Re: HEADSUP: cpufreq import complete, acpi_throttling changed X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Feb 2005 16:34:20 -0000 Jiawei Ye wrote: > On Mon, 14 Feb 2005 23:46:37 -0800, Nate Lawson wrote: > >>I just committed a patch that may fix this issue. >> >>-- >>Nate >> > > Does this look right to you? > > leafy@chihiro:~$ sysctl dev.cpu > dev.cpu.0.%desc: ACPI CPU > dev.cpu.0.%driver: cpu > dev.cpu.0.%location: handle=\_PR_.CPU1 > dev.cpu.0.%pnpinfo: _HID=none _UID=0 > dev.cpu.0.%parent: acpi0 > dev.cpu.0.freq: 1818 > dev.cpu.0.freq_levels: 1818/-1 1590/-1 1363/-1 1136/-1 909/-1 681/-1 > 454/-1 227/-1 I don't know, what's your CPUs actual full speed clock rate? Your system only has throttling so the only way to get those levels is to estimate the full speed rate and derive the rest from it. I'm working to make the estimate more correct in the future, but the current code should be right +/- a few Mhz. -- Nate From owner-freebsd-acpi@FreeBSD.ORG Tue Feb 15 16:36:27 2005 Return-Path: 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 C8C1D16A4CE for ; Tue, 15 Feb 2005 16:36:27 +0000 (GMT) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.199]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0871943D5F for ; Tue, 15 Feb 2005 16:36:26 +0000 (GMT) (envelope-from leafy7382@gmail.com) Received: by rproxy.gmail.com with SMTP id 34so44780rns for ; Tue, 15 Feb 2005 08:36:25 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=W9796Mowf6GRB65YcRZ+uEIe19Pl4O1/qVXOo72aDcH2b5ktbIylnP/E6QKSrkZhfFISCSK4TGvS68jgPY4ro558lsgBjnyAzi1cbgvIW0LhXQO4NEfpPZO+4rQYPx5bfWDghiUFWY81TWY6KcKUTANmRY74YhJqL6oFN8qKVfM= Received: by 10.38.179.80 with SMTP id b80mr30844rnf; Tue, 15 Feb 2005 08:36:25 -0800 (PST) Received: by 10.38.8.9 with HTTP; Tue, 15 Feb 2005 08:36:25 -0800 (PST) Message-ID: Date: Wed, 16 Feb 2005 00:36:25 +0800 From: Jiawei Ye To: Nate Lawson In-Reply-To: <42122489.4030705@root.org> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <20050213231306.376E05D07@ptavv.es.net> <420FE3C7.6020003@root.org> <20050214152319.bqxon1xk0g008s4k@netchild.homeip.net> <4210D155.6080706@root.org> <4211A8DD.4010406@root.org> <42122489.4030705@root.org> cc: acpi@freebsd.org cc: Alexander Leidinger cc: current@freebsd.org Subject: Re: HEADSUP: cpufreq import complete, acpi_throttling changed X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Jiawei Ye List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Feb 2005 16:36:27 -0000 On Tue, 15 Feb 2005 08:34:17 -0800, Nate Lawson wrote: > > dev.cpu.0.freq_levels: 1818/-1 1590/-1 1363/-1 1136/-1 909/-1 681/-1 > > 454/-1 227/-1 > > I don't know, what's your CPUs actual full speed clock rate? Your > system only has throttling so the only way to get those levels is to > estimate the full speed rate and derive the rest from it. I'm working > to make the estimate more correct in the future, but the current code > should be right +/- a few Mhz. > > -- > Nate Sorry I didn't make myself clear. I was referring to the '-1'. It used to be 0 there. Jiawei -- "Without the userland, the kernel is useless." --inspired by The Tao of Programming From owner-freebsd-acpi@FreeBSD.ORG Tue Feb 15 17:24:08 2005 Return-Path: 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 7DFF416A4CE; Tue, 15 Feb 2005 17:24:08 +0000 (GMT) Received: from www.cryptography.com (li-22.members.linode.com [64.5.53.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id 37AE143D41; Tue, 15 Feb 2005 17:24:08 +0000 (GMT) (envelope-from nate@root.org) Received: from [10.0.5.51] (adsl-64-171-186-189.dsl.snfc21.pacbell.net [64.171.186.189]) by www.cryptography.com (8.12.8/8.12.8) with ESMTP id j1FHO7Zj030026 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 15 Feb 2005 09:24:07 -0800 Message-ID: <42123035.50009@root.org> Date: Tue, 15 Feb 2005 09:24:05 -0800 From: Nate Lawson User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jiawei Ye References: <20050213231306.376E05D07@ptavv.es.net> <420FE3C7.6020003@root.org> <20050214152319.bqxon1xk0g008s4k@netchild.homeip.net> <4210D155.6080706@root.org> <4211A8DD.4010406@root.org> <42122489.4030705@root.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: acpi@freebsd.org cc: Alexander Leidinger cc: current@freebsd.org Subject: Re: HEADSUP: cpufreq import complete, acpi_throttling changed X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Feb 2005 17:24:08 -0000 Jiawei Ye wrote: > On Tue, 15 Feb 2005 08:34:17 -0800, Nate Lawson wrote: > >>>dev.cpu.0.freq_levels: 1818/-1 1590/-1 1363/-1 1136/-1 909/-1 681/-1 >>>454/-1 227/-1 >> >>I don't know, what's your CPUs actual full speed clock rate? Your >>system only has throttling so the only way to get those levels is to >>estimate the full speed rate and derive the rest from it. I'm working >>to make the estimate more correct in the future, but the current code >>should be right +/- a few Mhz. >> >>-- >>Nate > > Sorry I didn't make myself clear. I was referring to the '-1'. It used > to be 0 there. Yeah, that was part of something I corrected and is right. The power is set to -1 which is "I don't know." Without a base power to derive from, there's no way to know how much each state saves you. Once the Enhanced SpeedStep driver is committed, you'll have more settings and also known power values. So it looks like your system is working just fine. -- Nate From owner-freebsd-acpi@FreeBSD.ORG Tue Feb 15 19:22:51 2005 Return-Path: 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 9580216A50D; Tue, 15 Feb 2005 19:22:51 +0000 (GMT) Received: from mail.takas.lt (mail-src.takas.lt [212.59.31.78]) by mx1.FreeBSD.org (Postfix) with ESMTP id BEE9743D55; Tue, 15 Feb 2005 19:22:50 +0000 (GMT) (envelope-from leafy7382@gmail.com) Received: from mail pickup service by mail.takas.lt with Microsoft SMTPSVC; Tue, 15 Feb 2005 21:22:34 +0200 Received: from mx2.freebsd.org ([216.136.204.119]) by mail.takas.lt with Microsoft SMTPSVC(5.0.2195.6713); Tue, 15 Feb 2005 17:10:54 +0200 Received: from hub.freebsd.org (hub.freebsd.org [216.136.204.18]) by mx2.freebsd.org (Postfix) with ESMTP id 6C30956C29; Tue, 15 Feb 2005 15:10:42 +0000 (GMT) (envelope-from owner-freebsd-current@freebsd.org) Received: from hub.freebsd.org (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 328BC16A4D6; Tue, 15 Feb 2005 15:10:40 +0000 (GMT) Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6AF7D16A4D0 for ; Tue, 15 Feb 2005 15:10:08 +0000 (GMT) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.198]) by mx1.FreeBSD.org (Postfix) with ESMTP id CF90343D4C for ; Tue, 15 Feb 2005 15:10:07 +0000 (GMT) (envelope-from leafy7382@gmail.com) Received: by rproxy.gmail.com with SMTP id 34so37099rns for ; Tue, 15 Feb 2005 07:10:07 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=QQBW7oWT3xH7GizAHkW+z8A4UbePRXkqLXRNwolp0Za4oN9ggVYbpHnbKtnYPs6B227QjJpPxRdBhx597GW/CUjLnht298sEmaqj0fpQRlNhmPMddqBmUXnV9eWAbNOYdDEgH0GoJQaInPIcjJNPVwegeKhBkMxZWSmtEAwzc+g= Received: by 10.38.8.16 with SMTP id 16mr25224rnh; Tue, 15 Feb 2005 07:10:07 -0800 (PST) Received: by 10.38.8.9 with HTTP; Tue, 15 Feb 2005 07:10:07 -0800 (PST) Message-ID: Date: Tue, 15 Feb 2005 23:10:07 +0800 From: Jiawei Ye To: Nate Lawson In-Reply-To: <4211A8DD.4010406@root.org> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <20050213231306.376E05D07@ptavv.es.net> <420FE3C7.6020003@root.org> <20050214152319.bqxon1xk0g008s4k@netchild.homeip.net> <4210D155.6080706@root.org> <4211A8DD.4010406@root.org> X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Sender: owner-freebsd-current@freebsd.org Errors-To: owner-freebsd-current@freebsd.org X-OriginalArrivalTime: 15 Feb 2005 15:10:54.0812 (UTC) FILETIME=[8B87B9C0:01C51370] cc: acpi@freebsd.org cc: Alexander Leidinger cc: current@freebsd.org Subject: Re: HEADSUP: cpufreq import complete, acpi_throttling changed X-BeenThere: freebsd-acpi@freebsd.org Reply-To: Jiawei Ye List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Feb 2005 19:22:51 -0000 On Mon, 14 Feb 2005 23:46:37 -0800, Nate Lawson wrote: > I just committed a patch that may fix this issue. > > -- > Nate > Does this look right to you? leafy@chihiro:~$ sysctl dev.cpu dev.cpu.0.%desc: ACPI CPU dev.cpu.0.%driver: cpu dev.cpu.0.%location: handle=\_PR_.CPU1 dev.cpu.0.%pnpinfo: _HID=none _UID=0 dev.cpu.0.%parent: acpi0 dev.cpu.0.freq: 1818 dev.cpu.0.freq_levels: 1818/-1 1590/-1 1363/-1 1136/-1 909/-1 681/-1 454/-1 227/-1 -- "Without the userland, the kernel is useless." --inspired by The Tao of Programming _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-acpi@FreeBSD.ORG Thu Feb 17 00:57:38 2005 Return-Path: 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 D7E1916A4CE for ; Thu, 17 Feb 2005 00:57:38 +0000 (GMT) Received: from out008.verizon.net (out008pub.verizon.net [206.46.170.108]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3F37343D46 for ; Thu, 17 Feb 2005 00:57:38 +0000 (GMT) (envelope-from Alex.Kovalenko@verizon.net) Received: from RabbitsDen ([70.21.161.195]) by out008.verizon.net (InterMail vM.5.01.06.06 201-253-122-130-106-20030910) with ESMTP id <20050217005737.ZHVZ9672.out008.verizon.net@RabbitsDen>; Wed, 16 Feb 2005 18:57:37 -0600 From: "Alexandre \"Sunny\" Kovalenko" To: Nate Lawson In-Reply-To: <420FB25B.8010106@root.org> References: <1107914318.1015.15.camel@RabbitsDen> <420FB25B.8010106@root.org> Content-Type: text/plain; charset=iso-8859-5 Date: Wed, 16 Feb 2005 18:39:41 -0500 Message-Id: <1108597181.1001.8.camel@RabbitsDen> Mime-Version: 1.0 X-Mailer: Evolution 2.0.3 FreeBSD GNOME Team Port Content-Transfer-Encoding: 8bit X-Authentication-Info: Submitted using SMTP AUTH at out008.verizon.net from [70.21.161.195] at Wed, 16 Feb 2005 18:57:37 -0600 cc: freebsd-acpi@freebsd.org Subject: Re: Thermal state switching X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Feb 2005 00:57:39 -0000 On Sun, 2005-02-13 at 12:02 -0800, Nate Lawson wrote: > Alexandre "Sunny" Kovalenko wrote: > > Good people, > > > > I was looking at thermal states switching by acpi_thermal.c and it looks > > like follows (provided that temperature raises and falls slowly and > > gradually): > > > > NONE =up> AC2 =up> AC1 =up> AC0 =down> NONE (1) > > > > I do not know whether this was intentional or not and, for me, something > > along the lines of > > > > NONE =up> AC2 =up> AC1 =up> AC0 =down> AC1 =down> AC2 =down> NONE (2) > > > > seemed more natural. > > > > If (2) and not (1) was indeed the desired behavior attached patch seems > > to do the job. If (1) is what was intended, I do apologize for the > > noise. > > > > I am running -CURRENT from February 3. > > The behavior should be as in #2. If it isn't, we should fix that. > However, I'm not sure how your patch would fix this. It seems more > correct in that we only set the starting time after switching coolers > but I don't see how this affects the ACx levels. Could you explain more? > > Thanks, I do apologize for delay in answer -- day job decided to catch up with me. I guess, I have not explained it properly to start with -- behavior (2) could not be achieved because start time will be reset as long as you have _ACx state with the threshold lower then your current temperature. Or, rather, it could not be achieved if you have non-zero min_runtime. Moving reset of the start time out of that loop gets everything working along the lines of (2). Resetting it there did look suspicious to start with, but since I am just learning my way through ACPI stuff, I have decided to ask the question instead of filing PR. Hope this was better explanation then previous one. -- Alexandre "Sunny" Kovalenko (¾ÛÕÚáÐÝÔà ºÞÒÐÛÕÝÚÞ) From owner-freebsd-acpi@FreeBSD.ORG Thu Feb 17 01:16:28 2005 Return-Path: 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 A471F16A4CE; Thu, 17 Feb 2005 01:16:28 +0000 (GMT) Received: from ylpvm01.prodigy.net (ylpvm01-ext.prodigy.net [207.115.57.32]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8B9AB43D55; Thu, 17 Feb 2005 01:16:25 +0000 (GMT) (envelope-from nate@root.org) Received: from [10.0.0.34] (adsl-67-119-74-222.dsl.sntc01.pacbell.net [67.119.74.222])j1H1GMvE007982; Wed, 16 Feb 2005 20:16:23 -0500 Message-ID: <4213F066.2050708@root.org> Date: Wed, 16 Feb 2005 17:16:22 -0800 From: Nate Lawson User-Agent: Mozilla Thunderbird 1.0RC1 (X11/20041205) X-Accept-Language: en-us, en MIME-Version: 1.0 To: current@freebsd.org Content-Type: multipart/mixed; boundary="------------060506010507060809010505" cc: acpi@freebsd.org Subject: patch: p4tcc and speedstep cpufreq drivers X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Feb 2005 01:16:28 -0000 This is a multi-part message in MIME format. --------------060506010507060809010505 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Attached is a patch that I'd like to get tested. After applying it, rebuild and load the cpufreq.ko module. Be sure you do _not_ have "options CPU_ENABLE_TCC" in your kernel config or the new driver will conflict with the old. I do not have either hardware so I am not certain the drivers work. For starters, I'd just like to get results from people saying whether or not the driver attaches and they show new settings and second, whether it does anything useful when changing settings. Try a command like "dd if=/dev/zero bs=1m count=100 | md5" and see how the bytes/sec vary with settings. If it appears to work, please run through the settings being sure each one lowers or raises the performance accordingly, and also making sure each setting has been used twice. That way I know if there is a problem going from 50% back up to 100% again, for instance. Also, if your system supports both p4tcc and acpi_throttle, I'm interested in if these settings are truly independent for all systems. The way to see if they are independent is to compare the performance after setting each value and make sure it changes appropriately. If there are duplicates, then I'm wrong. The patch should either work or crash, but please be careful to shut down if your cpu gets too hot, etc. Thanks, -- Nate --------------060506010507060809010505 Content-Type: text/plain; name="cpufreq_est_p4tcc.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="cpufreq_est_p4tcc.diff" Index: conf/files.i386 =================================================================== RCS file: /home/ncvs/src/sys/conf/files.i386,v retrieving revision 1.516 diff -u -r1.516 files.i386 --- conf/files.i386 9 Feb 2005 20:03:39 -0000 1.516 +++ conf/files.i386 16 Feb 2005 16:05:02 -0000 @@ -218,6 +218,8 @@ i386/bios/smapi_bios.S optional smapi i386/bios/smbios.c optional smbios i386/bios/vpd.c optional vpd +i386/cpufreq/est.c optional cpufreq +i386/cpufreq/p4tcc.c optional cpufreq #i386/i386/apic_vector.s optional apic i386/i386/atomic.c standard \ compile-with "${CC} -c ${CFLAGS} ${DEFINED_PROF:S/^$/-fomit-frame-pointer/} ${.IMPSRC}" Index: modules/cpufreq/Makefile =================================================================== RCS file: /home/ncvs/src/sys/modules/cpufreq/Makefile,v retrieving revision 1.1 diff -u -r1.1 Makefile --- modules/cpufreq/Makefile 4 Feb 2005 05:49:36 -0000 1.1 +++ modules/cpufreq/Makefile 17 Feb 2005 01:03:30 -0000 @@ -1,10 +1,15 @@ # $FreeBSD$ -.PATH: ${.CURDIR}/../../dev/cpufreq +.PATH: ${.CURDIR}/../../dev/cpufreq \ + ${.CURDIR}/../../${MACHINE_ARCH}/cpufreq KMOD= cpufreq WARNS?= 2 SRCS= ichss.c SRCS+= bus_if.h cpufreq_if.h device_if.h pci_if.h +.if ${MACHINE} == "i386" +SRCS+= est.c p4tcc.c +.endif + .include Index: i386/cpufreq/est.c =================================================================== RCS file: i386/cpufreq/est.c diff -N i386/cpufreq/est.c --- /dev/null 1 Jan 1970 00:00:00 -0000 +++ i386/cpufreq/est.c 17 Feb 2005 00:57:02 -0000 @@ -0,0 +1,779 @@ +/*- + * Copyright (c) 2004 Colin Percival + * Copyright (c) 2005 Nate Lawson + * All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted providing that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * + * THIS SOFTWARE IS PROVIDED BY THE AUTHOR``AS IS'' AND ANY EXPRESS OR + * IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED + * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY + * DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, + * STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING + * IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE + * POSSIBILITY OF SUCH DAMAGE. + */ + +#include +__FBSDID("$FreeBSD$"); + +#include +#include +#include +#include +#include +#include +#include + +#include "cpufreq_if.h" +#include + +/* Status/control registers (from the IA-32 System Programming Guide). */ +#define MSR_PERF_STATUS 0x198 +#define MSR_PERF_CTL 0x199 + +/* Register and bit for enabling SpeedStep. */ +#define MSR_MISC_ENABLE 0x1a0 +#define MSR_SS_ENABLE (1<<16) + +/* Frequency and MSR control values. */ +typedef struct { + uint16_t freq; + uint16_t volts; + uint16_t id16; +} freq_info; + +/* Identifying characteristics of a processor and supported frequencies. */ +typedef struct { + const char *vendor; + uint32_t id32; + uint32_t bus_clk; + const freq_info *freqtab; +} cpu_info; + +struct est_softc { + device_t dev; + const freq_info *freq_list; +}; + +/* Convert MHz and mV into IDs for passing to the MSR. */ +#define ID16(MHz, mV, bus_clk) \ + (((MHz / bus_clk) << 8) | ((mV ? mV - 700 : 0) >> 4)) +#define ID32(MHz_hi, mV_hi, MHz_lo, mV_lo, bus_clk) \ + ((ID16(MHz_lo, mV_lo, bus_clk) << 16) | (ID16(MHz_hi, mV_hi, bus_clk))) + +/* Format for storing IDs in our table. */ +#define FREQ_INFO(MHz, mV, bus_clk) \ + { MHz, mV, ID16(MHz, mV, bus_clk) } +#define INTEL(tab, zhi, vhi, zlo, vlo, bus_clk) \ + { GenuineIntel, ID32(zhi, vhi, zlo, vlo, bus_clk), bus_clk, tab } + +const char GenuineIntel[] = "GenuineIntel"; + +/* Default bus clock value for Centrino processors. */ +#define INTEL_BUS_CLK 100 + +/* XXX Update this if new CPUs have more settings. */ +#define EST_MAX_SETTINGS 10 +CTASSERT(EST_MAX_SETTINGS <= MAX_SETTINGS); + +/* Estimate in microseconds of latency for performing a transition. */ +#define EST_TRANS_LAT 10 + +/* + * Frequency (MHz) and voltage (mV) settings. Data from the + * Intel Pentium M Processor Datasheet (Order Number 252612), Table 5. + * + * XXX New Dothan processors have multiple VID# with different + * settings for each VID#. Since we can't uniquely identify this info + * without undisclosed methods from Intel, we can't support newer + * processors with this table method. If ACPI Px states are supported, + * we can get info from them. + */ +const freq_info PM17_130[] = { + /* 130nm 1.70GHz Pentium M */ + FREQ_INFO(1700, 1484, INTEL_BUS_CLK), + FREQ_INFO(1400, 1308, INTEL_BUS_CLK), + FREQ_INFO(1200, 1228, INTEL_BUS_CLK), + FREQ_INFO(1000, 1116, INTEL_BUS_CLK), + FREQ_INFO( 800, 1004, INTEL_BUS_CLK), + FREQ_INFO( 600, 956, INTEL_BUS_CLK), + FREQ_INFO( 0, 0, 1), +}; +const freq_info PM16_130[] = { + /* 130nm 1.60GHz Pentium M */ + FREQ_INFO(1600, 1484, INTEL_BUS_CLK), + FREQ_INFO(1400, 1420, INTEL_BUS_CLK), + FREQ_INFO(1200, 1276, INTEL_BUS_CLK), + FREQ_INFO(1000, 1164, INTEL_BUS_CLK), + FREQ_INFO( 800, 1036, INTEL_BUS_CLK), + FREQ_INFO( 600, 956, INTEL_BUS_CLK), + FREQ_INFO( 0, 0, 1), +}; +const freq_info PM15_130[] = { + /* 130nm 1.50GHz Pentium M */ + FREQ_INFO(1500, 1484, INTEL_BUS_CLK), + FREQ_INFO(1400, 1452, INTEL_BUS_CLK), + FREQ_INFO(1200, 1356, INTEL_BUS_CLK), + FREQ_INFO(1000, 1228, INTEL_BUS_CLK), + FREQ_INFO( 800, 1116, INTEL_BUS_CLK), + FREQ_INFO( 600, 956, INTEL_BUS_CLK), + FREQ_INFO( 0, 0, 1), +}; +const freq_info PM14_130[] = { + /* 130nm 1.40GHz Pentium M */ + FREQ_INFO(1400, 1484, INTEL_BUS_CLK), + FREQ_INFO(1200, 1436, INTEL_BUS_CLK), + FREQ_INFO(1000, 1308, INTEL_BUS_CLK), + FREQ_INFO( 800, 1180, INTEL_BUS_CLK), + FREQ_INFO( 600, 956, INTEL_BUS_CLK), + FREQ_INFO( 0, 0, 1), +}; +const freq_info PM13_130[] = { + /* 130nm 1.30GHz Pentium M */ + FREQ_INFO(1300, 1388, INTEL_BUS_CLK), + FREQ_INFO(1200, 1356, INTEL_BUS_CLK), + FREQ_INFO(1000, 1292, INTEL_BUS_CLK), + FREQ_INFO( 800, 1260, INTEL_BUS_CLK), + FREQ_INFO( 600, 956, INTEL_BUS_CLK), + FREQ_INFO( 0, 0, 1), +}; +const freq_info PM13_LV_130[] = { + /* 130nm 1.30GHz Low Voltage Pentium M */ + FREQ_INFO(1300, 1180, INTEL_BUS_CLK), + FREQ_INFO(1200, 1164, INTEL_BUS_CLK), + FREQ_INFO(1100, 1100, INTEL_BUS_CLK), + FREQ_INFO(1000, 1020, INTEL_BUS_CLK), + FREQ_INFO( 900, 1004, INTEL_BUS_CLK), + FREQ_INFO( 800, 988, INTEL_BUS_CLK), + FREQ_INFO( 600, 956, INTEL_BUS_CLK), + FREQ_INFO( 0, 0, 1), +}; +const freq_info PM12_LV_130[] = { + /* 130 nm 1.20GHz Low Voltage Pentium M */ + FREQ_INFO(1200, 1180, INTEL_BUS_CLK), + FREQ_INFO(1100, 1164, INTEL_BUS_CLK), + FREQ_INFO(1000, 1100, INTEL_BUS_CLK), + FREQ_INFO( 900, 1020, INTEL_BUS_CLK), + FREQ_INFO( 800, 1004, INTEL_BUS_CLK), + FREQ_INFO( 600, 956, INTEL_BUS_CLK), + FREQ_INFO( 0, 0, 1), +}; +const freq_info PM11_LV_130[] = { + /* 130 nm 1.10GHz Low Voltage Pentium M */ + FREQ_INFO(1100, 1180, INTEL_BUS_CLK), + FREQ_INFO(1000, 1164, INTEL_BUS_CLK), + FREQ_INFO( 900, 1100, INTEL_BUS_CLK), + FREQ_INFO( 800, 1020, INTEL_BUS_CLK), + FREQ_INFO( 600, 956, INTEL_BUS_CLK), + FREQ_INFO( 0, 0, 1), +}; +const freq_info PM11_ULV_130[] = { + /* 130 nm 1.10GHz Ultra Low Voltage Pentium M */ + FREQ_INFO(1100, 1004, INTEL_BUS_CLK), + FREQ_INFO(1000, 988, INTEL_BUS_CLK), + FREQ_INFO( 900, 972, INTEL_BUS_CLK), + FREQ_INFO( 800, 956, INTEL_BUS_CLK), + FREQ_INFO( 600, 844, INTEL_BUS_CLK), + FREQ_INFO( 0, 0, 1), +}; +const freq_info PM10_ULV_130[] = { + /* 130 nm 1.00GHz Ultra Low Voltage Pentium M */ + FREQ_INFO(1000, 1004, INTEL_BUS_CLK), + FREQ_INFO( 900, 988, INTEL_BUS_CLK), + FREQ_INFO( 800, 972, INTEL_BUS_CLK), + FREQ_INFO( 600, 844, INTEL_BUS_CLK), + FREQ_INFO( 0, 0, 1), +}; + +/* + * Data from "Intel Pentium M Processor on 90nm Process with + * 2-MB L2 Cache Datasheet", Order Number 302189, Table 5. + */ +const freq_info PM_765A_90[] = { + /* 90 nm 2.10GHz Pentium M, VID #A */ + FREQ_INFO(2100, 1340, INTEL_BUS_CLK), + FREQ_INFO(1800, 1276, INTEL_BUS_CLK), + FREQ_INFO(1600, 1228, INTEL_BUS_CLK), + FREQ_INFO(1400, 1180, INTEL_BUS_CLK), + FREQ_INFO(1200, 1132, INTEL_BUS_CLK), + FREQ_INFO(1000, 1084, INTEL_BUS_CLK), + FREQ_INFO( 800, 1036, INTEL_BUS_CLK), + FREQ_INFO( 600, 988, INTEL_BUS_CLK), + FREQ_INFO( 0, 0, 1), +}; +const freq_info PM_765B_90[] = { + /* 90 nm 2.10GHz Pentium M, VID #B */ + FREQ_INFO(2100, 1324, INTEL_BUS_CLK), + FREQ_INFO(1800, 1260, INTEL_BUS_CLK), + FREQ_INFO(1600, 1212, INTEL_BUS_CLK), + FREQ_INFO(1400, 1180, INTEL_BUS_CLK), + FREQ_INFO(1200, 1132, INTEL_BUS_CLK), + FREQ_INFO(1000, 1084, INTEL_BUS_CLK), + FREQ_INFO( 800, 1036, INTEL_BUS_CLK), + FREQ_INFO( 600, 988, INTEL_BUS_CLK), + FREQ_INFO( 0, 0, 1), +}; +const freq_info PM_765C_90[] = { + /* 90 nm 2.10GHz Pentium M, VID #C */ + FREQ_INFO(2100, 1308, INTEL_BUS_CLK), + FREQ_INFO(1800, 1244, INTEL_BUS_CLK), + FREQ_INFO(1600, 1212, INTEL_BUS_CLK), + FREQ_INFO(1400, 1164, INTEL_BUS_CLK), + FREQ_INFO(1200, 1116, INTEL_BUS_CLK), + FREQ_INFO(1000, 1084, INTEL_BUS_CLK), + FREQ_INFO( 800, 1036, INTEL_BUS_CLK), + FREQ_INFO( 600, 988, INTEL_BUS_CLK), + FREQ_INFO( 0, 0, 1), +}; +const freq_info PM_765E_90[] = { + /* 90 nm 2.10GHz Pentium M, VID #E */ + FREQ_INFO(2100, 1356, INTEL_BUS_CLK), + FREQ_INFO(1800, 1292, INTEL_BUS_CLK), + FREQ_INFO(1600, 1244, INTEL_BUS_CLK), + FREQ_INFO(1400, 1196, INTEL_BUS_CLK), + FREQ_INFO(1200, 1148, INTEL_BUS_CLK), + FREQ_INFO(1000, 1100, INTEL_BUS_CLK), + FREQ_INFO( 800, 1052, INTEL_BUS_CLK), + FREQ_INFO( 600, 988, INTEL_BUS_CLK), + FREQ_INFO( 0, 0, 1), +}; +const freq_info PM_755A_90[] = { + /* 90 nm 2.00GHz Pentium M, VID #A */ + FREQ_INFO(2000, 1340, INTEL_BUS_CLK), + FREQ_INFO(1800, 1292, INTEL_BUS_CLK), + FREQ_INFO(1600, 1244, INTEL_BUS_CLK), + FREQ_INFO(1400, 1196, INTEL_BUS_CLK), + FREQ_INFO(1200, 1148, INTEL_BUS_CLK), + FREQ_INFO(1000, 1100, INTEL_BUS_CLK), + FREQ_INFO( 800, 1052, INTEL_BUS_CLK), + FREQ_INFO( 600, 988, INTEL_BUS_CLK), + FREQ_INFO( 0, 0, 1), +}; +const freq_info PM_755B_90[] = { + /* 90 nm 2.00GHz Pentium M, VID #B */ + FREQ_INFO(2000, 1324, INTEL_BUS_CLK), + FREQ_INFO(1800, 1276, INTEL_BUS_CLK), + FREQ_INFO(1600, 1228, INTEL_BUS_CLK), + FREQ_INFO(1400, 1180, INTEL_BUS_CLK), + FREQ_INFO(1200, 1132, INTEL_BUS_CLK), + FREQ_INFO(1000, 1084, INTEL_BUS_CLK), + FREQ_INFO( 800, 1036, INTEL_BUS_CLK), + FREQ_INFO( 600, 988, INTEL_BUS_CLK), + FREQ_INFO( 0, 0, 1), +}; +const freq_info PM_755C_90[] = { + /* 90 nm 2.00GHz Pentium M, VID #C */ + FREQ_INFO(2000, 1308, INTEL_BUS_CLK), + FREQ_INFO(1800, 1276, INTEL_BUS_CLK), + FREQ_INFO(1600, 1228, INTEL_BUS_CLK), + FREQ_INFO(1400, 1180, INTEL_BUS_CLK), + FREQ_INFO(1200, 1132, INTEL_BUS_CLK), + FREQ_INFO(1000, 1084, INTEL_BUS_CLK), + FREQ_INFO( 800, 1036, INTEL_BUS_CLK), + FREQ_INFO( 600, 988, INTEL_BUS_CLK), + FREQ_INFO( 0, 0, 1), +}; +const freq_info PM_755D_90[] = { + /* 90 nm 2.00GHz Pentium M, VID #D */ + FREQ_INFO(2000, 1276, INTEL_BUS_CLK), + FREQ_INFO(1800, 1244, INTEL_BUS_CLK), + FREQ_INFO(1600, 1196, INTEL_BUS_CLK), + FREQ_INFO(1400, 1164, INTEL_BUS_CLK), + FREQ_INFO(1200, 1116, INTEL_BUS_CLK), + FREQ_INFO(1000, 1084, INTEL_BUS_CLK), + FREQ_INFO( 800, 1036, INTEL_BUS_CLK), + FREQ_INFO( 600, 988, INTEL_BUS_CLK), + FREQ_INFO( 0, 0, 1), +}; +const freq_info PM_745A_90[] = { + /* 90 nm 1.80GHz Pentium M, VID #A */ + FREQ_INFO(1800, 1340, INTEL_BUS_CLK), + FREQ_INFO(1600, 1292, INTEL_BUS_CLK), + FREQ_INFO(1400, 1228, INTEL_BUS_CLK), + FREQ_INFO(1200, 1164, INTEL_BUS_CLK), + FREQ_INFO(1000, 1116, INTEL_BUS_CLK), + FREQ_INFO( 800, 1052, INTEL_BUS_CLK), + FREQ_INFO( 600, 988, INTEL_BUS_CLK), + FREQ_INFO( 0, 0, 1), +}; +const freq_info PM_745B_90[] = { + /* 90 nm 1.80GHz Pentium M, VID #B */ + FREQ_INFO(1800, 1324, INTEL_BUS_CLK), + FREQ_INFO(1600, 1276, INTEL_BUS_CLK), + FREQ_INFO(1400, 1212, INTEL_BUS_CLK), + FREQ_INFO(1200, 1164, INTEL_BUS_CLK), + FREQ_INFO(1000, 1116, INTEL_BUS_CLK), + FREQ_INFO( 800, 1052, INTEL_BUS_CLK), + FREQ_INFO( 600, 988, INTEL_BUS_CLK), + FREQ_INFO( 0, 0, 1), +}; +const freq_info PM_745C_90[] = { + /* 90 nm 1.80GHz Pentium M, VID #C */ + FREQ_INFO(1800, 1308, INTEL_BUS_CLK), + FREQ_INFO(1600, 1260, INTEL_BUS_CLK), + FREQ_INFO(1400, 1212, INTEL_BUS_CLK), + FREQ_INFO(1200, 1148, INTEL_BUS_CLK), + FREQ_INFO(1000, 1100, INTEL_BUS_CLK), + FREQ_INFO( 800, 1052, INTEL_BUS_CLK), + FREQ_INFO( 600, 988, INTEL_BUS_CLK), + FREQ_INFO( 0, 0, 1), +}; +const freq_info PM_745D_90[] = { + /* 90 nm 1.80GHz Pentium M, VID #D */ + FREQ_INFO(1800, 1276, INTEL_BUS_CLK), + FREQ_INFO(1600, 1228, INTEL_BUS_CLK), + FREQ_INFO(1400, 1180, INTEL_BUS_CLK), + FREQ_INFO(1200, 1132, INTEL_BUS_CLK), + FREQ_INFO(1000, 1084, INTEL_BUS_CLK), + FREQ_INFO( 800, 1036, INTEL_BUS_CLK), + FREQ_INFO( 600, 988, INTEL_BUS_CLK), + FREQ_INFO( 0, 0, 1), +}; +const freq_info PM_735A_90[] = { + /* 90 nm 1.70GHz Pentium M, VID #A */ + FREQ_INFO(1700, 1340, INTEL_BUS_CLK), + FREQ_INFO(1400, 1244, INTEL_BUS_CLK), + FREQ_INFO(1200, 1180, INTEL_BUS_CLK), + FREQ_INFO(1000, 1116, INTEL_BUS_CLK), + FREQ_INFO( 800, 1052, INTEL_BUS_CLK), + FREQ_INFO( 600, 988, INTEL_BUS_CLK), + FREQ_INFO( 0, 0, 1), +}; +const freq_info PM_735B_90[] = { + /* 90 nm 1.70GHz Pentium M, VID #B */ + FREQ_INFO(1700, 1324, INTEL_BUS_CLK), + FREQ_INFO(1400, 1244, INTEL_BUS_CLK), + FREQ_INFO(1200, 1180, INTEL_BUS_CLK), + FREQ_INFO(1000, 1116, INTEL_BUS_CLK), + FREQ_INFO( 800, 1052, INTEL_BUS_CLK), + FREQ_INFO( 600, 988, INTEL_BUS_CLK), + FREQ_INFO( 0, 0, 1), +}; +const freq_info PM_735C_90[] = { + /* 90 nm 1.70GHz Pentium M, VID #C */ + FREQ_INFO(1700, 1308, INTEL_BUS_CLK), + FREQ_INFO(1400, 1228, INTEL_BUS_CLK), + FREQ_INFO(1200, 1164, INTEL_BUS_CLK), + FREQ_INFO(1000, 1116, INTEL_BUS_CLK), + FREQ_INFO( 800, 1052, INTEL_BUS_CLK), + FREQ_INFO( 600, 988, INTEL_BUS_CLK), + FREQ_INFO( 0, 0, 1), +}; +const freq_info PM_735D_90[] = { + /* 90 nm 1.70GHz Pentium M, VID #D */ + FREQ_INFO(1700, 1276, INTEL_BUS_CLK), + FREQ_INFO(1400, 1212, INTEL_BUS_CLK), + FREQ_INFO(1200, 1148, INTEL_BUS_CLK), + FREQ_INFO(1000, 1100, INTEL_BUS_CLK), + FREQ_INFO( 800, 1052, INTEL_BUS_CLK), + FREQ_INFO( 600, 988, INTEL_BUS_CLK), + FREQ_INFO( 0, 0, 1), +}; +const freq_info PM_725A_90[] = { + /* 90 nm 1.60GHz Pentium M, VID #A */ + FREQ_INFO(1600, 1340, INTEL_BUS_CLK), + FREQ_INFO(1400, 1276, INTEL_BUS_CLK), + FREQ_INFO(1200, 1212, INTEL_BUS_CLK), + FREQ_INFO(1000, 1132, INTEL_BUS_CLK), + FREQ_INFO( 800, 1068, INTEL_BUS_CLK), + FREQ_INFO( 600, 988, INTEL_BUS_CLK), + FREQ_INFO( 0, 0, 1), +}; +const freq_info PM_725B_90[] = { + /* 90 nm 1.60GHz Pentium M, VID #B */ + FREQ_INFO(1600, 1324, INTEL_BUS_CLK), + FREQ_INFO(1400, 1260, INTEL_BUS_CLK), + FREQ_INFO(1200, 1196, INTEL_BUS_CLK), + FREQ_INFO(1000, 1132, INTEL_BUS_CLK), + FREQ_INFO( 800, 1068, INTEL_BUS_CLK), + FREQ_INFO( 600, 988, INTEL_BUS_CLK), + FREQ_INFO( 0, 0, 1), +}; +const freq_info PM_725C_90[] = { + /* 90 nm 1.60GHz Pentium M, VID #C */ + FREQ_INFO(1600, 1308, INTEL_BUS_CLK), + FREQ_INFO(1400, 1244, INTEL_BUS_CLK), + FREQ_INFO(1200, 1180, INTEL_BUS_CLK), + FREQ_INFO(1000, 1116, INTEL_BUS_CLK), + FREQ_INFO( 800, 1052, INTEL_BUS_CLK), + FREQ_INFO( 600, 988, INTEL_BUS_CLK), + FREQ_INFO( 0, 0, 1), +}; +const freq_info PM_725D_90[] = { + /* 90 nm 1.60GHz Pentium M, VID #D */ + FREQ_INFO(1600, 1276, INTEL_BUS_CLK), + FREQ_INFO(1400, 1228, INTEL_BUS_CLK), + FREQ_INFO(1200, 1164, INTEL_BUS_CLK), + FREQ_INFO(1000, 1116, INTEL_BUS_CLK), + FREQ_INFO( 800, 1052, INTEL_BUS_CLK), + FREQ_INFO( 600, 988, INTEL_BUS_CLK), + FREQ_INFO( 0, 0, 1), +}; +const freq_info PM_715A_90[] = { + /* 90 nm 1.50GHz Pentium M, VID #A */ + FREQ_INFO(1500, 1340, INTEL_BUS_CLK), + FREQ_INFO(1200, 1228, INTEL_BUS_CLK), + FREQ_INFO(1000, 1148, INTEL_BUS_CLK), + FREQ_INFO( 800, 1068, INTEL_BUS_CLK), + FREQ_INFO( 600, 988, INTEL_BUS_CLK), + FREQ_INFO( 0, 0, 1), +}; +const freq_info PM_715B_90[] = { + /* 90 nm 1.50GHz Pentium M, VID #B */ + FREQ_INFO(1500, 1324, INTEL_BUS_CLK), + FREQ_INFO(1200, 1212, INTEL_BUS_CLK), + FREQ_INFO(1000, 1148, INTEL_BUS_CLK), + FREQ_INFO( 800, 1068, INTEL_BUS_CLK), + FREQ_INFO( 600, 988, INTEL_BUS_CLK), + FREQ_INFO( 0, 0, 1), +}; +const freq_info PM_715C_90[] = { + /* 90 nm 1.50GHz Pentium M, VID #C */ + FREQ_INFO(1500, 1308, INTEL_BUS_CLK), + FREQ_INFO(1200, 1212, INTEL_BUS_CLK), + FREQ_INFO(1000, 1132, INTEL_BUS_CLK), + FREQ_INFO( 800, 1068, INTEL_BUS_CLK), + FREQ_INFO( 600, 988, INTEL_BUS_CLK), + FREQ_INFO( 0, 0, 1), +}; +const freq_info PM_715D_90[] = { + /* 90 nm 1.50GHz Pentium M, VID #D */ + FREQ_INFO(1500, 1276, INTEL_BUS_CLK), + FREQ_INFO(1200, 1180, INTEL_BUS_CLK), + FREQ_INFO(1000, 1116, INTEL_BUS_CLK), + FREQ_INFO( 800, 1052, INTEL_BUS_CLK), + FREQ_INFO( 600, 988, INTEL_BUS_CLK), + FREQ_INFO( 0, 0, 1), +}; +const freq_info PM_738_90[] = { + /* 90 nm 1.40GHz Low Voltage Pentium M */ + FREQ_INFO(1400, 1116, INTEL_BUS_CLK), + FREQ_INFO(1300, 1116, INTEL_BUS_CLK), + FREQ_INFO(1200, 1100, INTEL_BUS_CLK), + FREQ_INFO(1100, 1068, INTEL_BUS_CLK), + FREQ_INFO(1000, 1052, INTEL_BUS_CLK), + FREQ_INFO( 900, 1036, INTEL_BUS_CLK), + FREQ_INFO( 800, 1020, INTEL_BUS_CLK), + FREQ_INFO( 600, 988, INTEL_BUS_CLK), + FREQ_INFO( 0, 0, 1), +}; +const freq_info PM_733_90[] = { + /* 90 nm 1.10GHz Ultra Low Voltage Pentium M */ + FREQ_INFO(1100, 940, INTEL_BUS_CLK), + FREQ_INFO(1000, 924, INTEL_BUS_CLK), + FREQ_INFO( 900, 892, INTEL_BUS_CLK), + FREQ_INFO( 800, 876, INTEL_BUS_CLK), + FREQ_INFO( 600, 812, INTEL_BUS_CLK), + FREQ_INFO( 0, 0, 1), +}; +const freq_info PM_723_90[] = { + /* 90 nm 1.00GHz Ultra Low Voltage Pentium M */ + FREQ_INFO(1000, 940, INTEL_BUS_CLK), + FREQ_INFO( 900, 908, INTEL_BUS_CLK), + FREQ_INFO( 800, 876, INTEL_BUS_CLK), + FREQ_INFO( 600, 812, INTEL_BUS_CLK), + FREQ_INFO( 0, 0, 1), +}; + +const cpu_info ESTprocs[] = { + INTEL(PM17_130, 1700, 1484, 600, 956, INTEL_BUS_CLK), + INTEL(PM16_130, 1600, 1484, 600, 956, INTEL_BUS_CLK), + INTEL(PM15_130, 1500, 1484, 600, 956, INTEL_BUS_CLK), + INTEL(PM14_130, 1400, 1484, 600, 956, INTEL_BUS_CLK), + INTEL(PM13_130, 1300, 1388, 600, 956, INTEL_BUS_CLK), + INTEL(PM13_LV_130, 1300, 1180, 600, 956, INTEL_BUS_CLK), + INTEL(PM12_LV_130, 1200, 1180, 600, 956, INTEL_BUS_CLK), + INTEL(PM11_LV_130, 1100, 1180, 600, 956, INTEL_BUS_CLK), + INTEL(PM11_ULV_130, 1100, 1004, 600, 844, INTEL_BUS_CLK), + INTEL(PM10_ULV_130, 1000, 1004, 600, 844, INTEL_BUS_CLK), + INTEL(PM_765A_90, 2100, 1340, 600, 988, INTEL_BUS_CLK), + INTEL(PM_765B_90, 2100, 1324, 600, 988, INTEL_BUS_CLK), + INTEL(PM_765C_90, 2100, 1308, 600, 988, INTEL_BUS_CLK), + INTEL(PM_765E_90, 2100, 1356, 600, 988, INTEL_BUS_CLK), + INTEL(PM_755A_90, 2000, 1340, 600, 988, INTEL_BUS_CLK), + INTEL(PM_755B_90, 2000, 1324, 600, 988, INTEL_BUS_CLK), + INTEL(PM_755C_90, 2000, 1308, 600, 988, INTEL_BUS_CLK), + INTEL(PM_755D_90, 2000, 1276, 600, 988, INTEL_BUS_CLK), + INTEL(PM_745A_90, 1800, 1340, 600, 988, INTEL_BUS_CLK), + INTEL(PM_745B_90, 1800, 1324, 600, 988, INTEL_BUS_CLK), + INTEL(PM_745C_90, 1800, 1308, 600, 988, INTEL_BUS_CLK), + INTEL(PM_745D_90, 1800, 1276, 600, 988, INTEL_BUS_CLK), + INTEL(PM_735A_90, 1700, 1340, 600, 988, INTEL_BUS_CLK), + INTEL(PM_735B_90, 1700, 1324, 600, 988, INTEL_BUS_CLK), + INTEL(PM_735C_90, 1700, 1308, 600, 988, INTEL_BUS_CLK), + INTEL(PM_735D_90, 1700, 1276, 600, 988, INTEL_BUS_CLK), + INTEL(PM_725A_90, 1600, 1340, 600, 988, INTEL_BUS_CLK), + INTEL(PM_725B_90, 1600, 1324, 600, 988, INTEL_BUS_CLK), + INTEL(PM_725C_90, 1600, 1308, 600, 988, INTEL_BUS_CLK), + INTEL(PM_725D_90, 1600, 1276, 600, 988, INTEL_BUS_CLK), + INTEL(PM_715A_90, 1500, 1340, 600, 988, INTEL_BUS_CLK), + INTEL(PM_715B_90, 1500, 1324, 600, 988, INTEL_BUS_CLK), + INTEL(PM_715C_90, 1500, 1308, 600, 988, INTEL_BUS_CLK), + INTEL(PM_715D_90, 1500, 1276, 600, 988, INTEL_BUS_CLK), + INTEL(PM_738_90, 1400, 1116, 600, 988, INTEL_BUS_CLK), + INTEL(PM_733_90, 1100, 940, 600, 812, INTEL_BUS_CLK), + INTEL(PM_723_90, 1000, 940, 600, 812, INTEL_BUS_CLK), + { NULL, 0, 0, NULL }, +}; + +static void est_identify(driver_t *driver, device_t parent); +static int est_probe(device_t parent); +static int est_attach(device_t parent); +static int est_detach(device_t parent); +static int est_find_cpu(const char *vendor, uint64_t msr, uint32_t bus_clk, + const freq_info **freqs); +static const freq_info *est_get_current(const freq_info *freq_list); +static int est_settings(device_t dev, struct cf_setting *sets, int *count, + int *type); +static int est_set(device_t dev, const struct cf_setting *set); +static int est_get(device_t dev, struct cf_setting *set); + +static device_method_t est_methods[] = { + /* Device interface */ + DEVMETHOD(device_identify, est_identify), + DEVMETHOD(device_probe, est_probe), + DEVMETHOD(device_attach, est_attach), + DEVMETHOD(device_detach, est_detach), + + /* cpufreq interface */ + DEVMETHOD(cpufreq_drv_set, est_set), + DEVMETHOD(cpufreq_drv_get, est_get), + DEVMETHOD(cpufreq_drv_settings, est_settings), + {0, 0} +}; + +static driver_t est_driver = { + "est", + est_methods, + sizeof(struct est_softc), +}; + +static devclass_t est_devclass; +DRIVER_MODULE(est, cpu, est_driver, est_devclass, 0, 0); + +static void +est_identify(driver_t *driver, device_t parent) +{ + u_int p[4]; + + /* + * XXX If we're not on cpu 0, don't add a child. We should add + * MP support instead. + */ + if (device_get_unit(parent) != 0) + return; + + /* Make sure we're not being doubly invoked. */ + if (device_find_child(parent, "est", -1) != NULL) + return; + + /* Check that CPUID is supported and the vendor is Intel.*/ + if (cpu_high == 0 || strcmp(cpu_vendor, GenuineIntel) != 0) + return; + + /* Read capability bits and check if the CPU supports EST. */ + do_cpuid(1, p); + if ((p[2] & 0x80) == 0) + return; + + if (BUS_ADD_CHILD(parent, 0, "est", -1) == NULL) + device_printf(parent, "add est child failed\n"); +} + +static int +est_probe(device_t dev) +{ + struct cf_setting set; + const freq_info *f; + device_t perf_dev; + uint64_t msr; + int count, type; + + /* + * If the ACPI perf driver has attached and is not just offering + * info, let it manage things. + */ + perf_dev = device_find_child(device_get_parent(dev), "acpi_perf", -1); + if (perf_dev && device_is_attached(perf_dev)) { + type = 0; + count = 1; + CPUFREQ_DRV_SETTINGS(perf_dev, &set, &count, &type); + if ((type & CPUFREQ_FLAG_INFO_ONLY) == 0) + return (ENXIO); + } + + /* Attempt to enable SpeedStep if not currently enabled. */ + msr = rdmsr(MSR_MISC_ENABLE); + if ((msr & MSR_SS_ENABLE) == 0) { + msr |= MSR_SS_ENABLE; + wrmsr(MSR_MISC_ENABLE, msr); + + /* Check if the enable failed. */ + msr = rdmsr(MSR_MISC_ENABLE); + if ((msr & MSR_SS_ENABLE) == 0) { + device_printf(dev, "failed to enable SpeedStep\n"); + return (ENXIO); + } + } + + /* Identify the exact CPU model */ + msr = rdmsr(MSR_PERF_STATUS); + if (est_find_cpu(cpu_vendor, msr, INTEL_BUS_CLK, &f) != 0) { + printf( + "CPU claims to support Enhanced Speedstep, but is not recognized.\n" + "Please update driver or contact the maintainer.\n" + "cpu_vendor = %s msr = %0jx, bus_clk = %x\n", + cpu_vendor, msr, INTEL_BUS_CLK); + return (ENXIO); + } + + device_set_desc(dev, "Enhanced SpeedStep Frequency Control"); + return (0); +} + +static int +est_attach(device_t dev) +{ + struct est_softc *sc; + uint64_t msr; + + sc = device_get_softc(dev); + sc->dev = dev; + msr = rdmsr(MSR_PERF_STATUS); + est_find_cpu(cpu_vendor, msr, INTEL_BUS_CLK, &sc->freq_list); + + return (0); +} + +static int +est_detach(device_t dev) +{ + return (ENXIO); +} + +static int +est_find_cpu(const char *vendor, uint64_t msr, uint32_t bus_clk, + const freq_info **freqs) +{ + const cpu_info *p; + uint32_t id; + + /* Find a table which matches (vendor, id, bus_clk). */ + id = msr >> 32; + for (p = ESTprocs; p->id32 != 0; p++) { + if (strcmp(p->vendor, vendor) == 0 && p->id32 == id && + p->bus_clk == bus_clk) + break; + } + if (p->id32 == 0) + return (EOPNOTSUPP); + + /* Make sure the current setpoint is valid. */ + if (est_get_current(p->freqtab) == NULL) + return (EOPNOTSUPP); + + *freqs = p->freqtab; + return (0); +} + +static const freq_info * +est_get_current(const freq_info *freq_list) +{ + const freq_info *f; + int i; + uint16_t id16; + + /* + * Try a few times to get a valid value. Sometimes, if the CPU + * is in the middle of an asynchronous transition (i.e., P4TCC), + * we get a temporary invalid result. + */ + for (i = 0; i < 5; i++) { + id16 = rdmsr(MSR_PERF_STATUS) & 0xffff; + for (f = freq_list; f->id16 != 0; f++) { + if (f->id16 == id16) + return (f); + } + } + return (NULL); +} + +static int +est_settings(device_t dev, struct cf_setting *sets, int *count, int *type) +{ + struct est_softc *sc; + const freq_info *f; + int i; + + if (*count < EST_MAX_SETTINGS) + return (E2BIG); + + i = 0; + for (f = sc->freq_list; f->freq != 0; f++) { + sets[i].freq = f->freq; + sets[i].volts = f->volts; + sets[i].power = CPUFREQ_VAL_UNKNOWN; + sets[i].lat = EST_TRANS_LAT; + sets[i].dev = dev; + i++; + } + *count = i + 1; + *type = CPUFREQ_TYPE_ABSOLUTE; + + return (0); +} + +static int +est_set(device_t dev, const struct cf_setting *set) +{ + struct est_softc *sc; + const freq_info *f; + uint64_t msr; + + /* Find the setting matching the requested one. */ + sc = device_get_softc(dev); + for (f = sc->freq_list; f->freq != 0; f++) { + if (f->freq == set->freq) + break; + } + if (f->freq == 0) + return (EINVAL); + + /* Read the current register, mask out the old, set the new id. */ + msr = rdmsr(MSR_PERF_CTL); + msr = (msr & ~0xffffLL) | f->id16; + wrmsr(MSR_PERF_CTL, msr); + + return (0); +} + +static int +est_get(device_t dev, struct cf_setting *set) +{ + struct est_softc *sc; + const freq_info *f; + + sc = device_get_softc(dev); + f = est_get_current(sc->freq_list); + if (f == NULL) + return (ENXIO); + + set->freq = f->freq; + set->volts = f->volts; + set->power = CPUFREQ_VAL_UNKNOWN; + set->lat = EST_TRANS_LAT; + set->dev = dev; + return (0); +} Index: i386/cpufreq/p4tcc.c =================================================================== RCS file: i386/cpufreq/p4tcc.c diff -N i386/cpufreq/p4tcc.c --- /dev/null 1 Jan 1970 00:00:00 -0000 +++ i386/cpufreq/p4tcc.c 17 Feb 2005 01:04:41 -0000 @@ -0,0 +1,246 @@ +/*- + * Copyright (c) 2003 Ted Unangst + * Copyright (c) 2004 Maxim Sobolev + * Copyright (c) 2005 Nate Lawson + * All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * + * THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR + * IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES + * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. + * IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, + * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, + * BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; + * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED + * AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, + * OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * SUCH DAMAGE. + */ + +/* + * Throttle clock frequency by using the thermal control circuit. This + * operates independently of SpeedStep and ACPI throttling and is supported + * on Pentium 4 and later models (feature TM). + * + * Reference: Intel Developer's manual v.3 #245472-012 + */ + +#include +__FBSDID("$FreeBSD$"); + +#include +#include +#include +#include +#include +#include + +#include +#include + +#include "cpufreq_if.h" + +struct p4tcc_softc { + device_t dev; + int set_count; +}; + +#define TCC_NUM_SETTINGS 8 + +#define TCC_ENABLE_BIT (1<<4) +#define TCC_REG_OFFSET 1 +#define TCC_SPEED_PERCENT(x) ((10000 * (x)) / TCC_NUM_SETTINGS) + +static void p4tcc_identify(driver_t *driver, device_t parent); +static int p4tcc_probe(device_t dev); +static int p4tcc_attach(device_t dev); +static int p4tcc_settings(device_t dev, struct cf_setting *sets, + int *count, int *type); +static int p4tcc_set(device_t dev, const struct cf_setting *set); +static int p4tcc_get(device_t dev, struct cf_setting *set); + +static device_method_t p4tcc_methods[] = { + /* Device interface */ + DEVMETHOD(device_identify, p4tcc_identify), + DEVMETHOD(device_probe, p4tcc_probe), + DEVMETHOD(device_attach, p4tcc_attach), + + /* cpufreq interface */ + DEVMETHOD(cpufreq_drv_set, p4tcc_set), + DEVMETHOD(cpufreq_drv_get, p4tcc_get), + DEVMETHOD(cpufreq_drv_settings, p4tcc_settings), + {0, 0} +}; + +static driver_t p4tcc_driver = { + "p4tcc", + p4tcc_methods, + sizeof(struct p4tcc_softc), +}; + +static devclass_t p4tcc_devclass; +DRIVER_MODULE(p4tcc, cpu, p4tcc_driver, p4tcc_devclass, 0, 0); + +static void +p4tcc_identify(driver_t *driver, device_t parent) +{ + + if ((cpu_feature & (CPUID_ACPI | CPUID_TM)) != (CPUID_ACPI | CPUID_TM)) + return; + if (BUS_ADD_CHILD(parent, 0, "p4tcc", -1) == NULL) + device_printf(parent, "add p4tcc child failed\n"); +} + +static int +p4tcc_probe(device_t dev) +{ + + device_set_desc(dev, "CPU Frequency Thermal Control"); + return (0); +} + +static int +p4tcc_attach(device_t dev) +{ + struct p4tcc_softc *sc; + struct cf_setting set; + + sc = device_get_softc(dev); + sc->dev = dev; + sc->set_count = TCC_NUM_SETTINGS; + + switch (cpu_id & 0xf) { + case 0x22: + case 0x24: + case 0x25: + case 0x27: + case 0x29: + /* + * These CPU models hang when set to 12.5%. + * See Errata O50, P44, and Z21. + */ + sc->set_count -= 1; + break; + case 0x07: /* errata N44 and P18 */ + case 0x0a: + case 0x12: + case 0x13: + /* + * These CPU models hang when set to 12.5% or 25%. + * See Errata N44 and P18l. + */ + sc->set_count -= 2; + break; + } + + /* + * On boot, the TCC is usually in Automatic mode where reading the + * current performance level is likely to produce bogus results. + * We switch it to On-Demand mode and set a known performance level + * to avoid ambiguity. Unfortunately, there is no reliable way to + * check that TCC is in the Automatic mode. Reading bit 4 of ACPI + * Thermal Monitor Control Register produces 0 no matter what the + * current mode. + */ + set.freq = 10000; + set.dev = dev; + CPUFREQ_DRV_SET(dev, &set); + + return (0); +} + +static int +p4tcc_settings(device_t dev, struct cf_setting *sets, int *count, int *type) +{ + struct p4tcc_softc *sc; + int i, val; + + sc = device_get_softc(dev); + if (sets == NULL || count == NULL) + return (EINVAL); + if (*count < sc->set_count) + return (E2BIG); + + /* Return a list of valid settings for this driver. */ + memset(sets, CPUFREQ_VAL_UNKNOWN, sizeof(*sets) * sc->set_count); + for (i = 0, val = sc->set_count; val != 0; i++, val--) { + sets[i].freq = TCC_SPEED_PERCENT(val); + sets[i].dev = dev; + } + *count = sc->set_count; + *type = CPUFREQ_TYPE_RELATIVE; + + return (0); +} + +static int +p4tcc_set(device_t dev, const struct cf_setting *set) +{ + struct p4tcc_softc *sc; + uint64_t mask, msr; + int val; + + if (set == NULL) + return (EINVAL); + sc = device_get_softc(dev); + + /* + * Validate requested state converts to a setting that is an + * integer from [1 .. sc->set_count]. + */ + val = set->freq * sc->set_count / 10000; + if (val * 10000 != set->freq * sc->set_count || + val < 1 || val > sc->set_count) + return (EINVAL); + + /* Convert a setting of TCC_NUM_SETTINGS to 0. */ + if (val == TCC_NUM_SETTINGS) + val = 0; + + /* + * Read the current register and mask off the old setting/enable bit. + * If the new val is nonzero, set it and the enable bit. Finally, + * write the new register. + */ + msr = rdmsr(MSR_THERM_CONTROL); + mask = (TCC_NUM_SETTINGS - 1) << TCC_REG_OFFSET; + msr &= ~(mask | TCC_ENABLE_BIT); + if (val) + msr |= (val << TCC_REG_OFFSET) | TCC_ENABLE_BIT; + wrmsr(MSR_THERM_CONTROL, msr); + + return (0); +} + +static int +p4tcc_get(device_t dev, struct cf_setting *set) +{ + uint64_t msr; + int val; + + if (set == NULL) + return (EINVAL); + + /* Read the current register and extract the current setting. */ + msr = rdmsr(MSR_THERM_CONTROL); + val = (msr >> TCC_REG_OFFSET) & (TCC_NUM_SETTINGS - 1); + + /* Convert a setting of 0 to TCC_NUM_SETTINGS. */ + if (val == 0) + val = TCC_NUM_SETTINGS; + + memset(set, CPUFREQ_VAL_UNKNOWN, sizeof(*set)); + set->freq = TCC_SPEED_PERCENT(val); + set->dev = dev; + + return (0); +} --------------060506010507060809010505-- From owner-freebsd-acpi@FreeBSD.ORG Thu Feb 17 03:38:38 2005 Return-Path: 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 39A5D16A4CE for ; Thu, 17 Feb 2005 03:38:38 +0000 (GMT) Received: from pne-smtpout1-sn2.hy.skanova.net (pne-smtpout1-sn2.hy.skanova.net [81.228.8.83]) by mx1.FreeBSD.org (Postfix) with ESMTP id D574843D41 for ; Thu, 17 Feb 2005 03:38:37 +0000 (GMT) (envelope-from pawel.worach@telia.com) Received: from [127.0.0.1] (81.225.14.129) by pne-smtpout1-sn2.hy.skanova.net (7.1.026.7) (authenticated as u86211448) id 41E32167005AE888; Thu, 17 Feb 2005 04:38:05 +0100 Message-ID: <4214119B.2010909@telia.com> Date: Thu, 17 Feb 2005 04:38:03 +0100 From: Pawel Worach User-Agent: Mozilla Thunderbird 1.0 (X11/20050214) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Nate Lawson References: <4213F066.2050708@root.org> In-Reply-To: <4213F066.2050708@root.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: acpi@freebsd.org Subject: Re: patch: p4tcc and speedstep cpufreq drivers X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Feb 2005 03:38:38 -0000 Nate Lawson wrote: > Attached is a patch that I'd like to get tested. After applying it, > rebuild and load the cpufreq.ko module. Be sure you do _not_ have > "options CPU_ENABLE_TCC" in your kernel config or the new driver will > conflict with the old. Hi Nate, This is what I get on a TP T41, do the cpufreq results below look right? Also if I loaded both modules all I got for dev.cpu.0.freq was -1 or 1700 and no levels. CPU: Intel(R) Pentium(R) M processor 1700MHz (1698.56-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x695 Stepping = 5 Features=0xa7e9f9bf Only acpi_perf loaded at boot: +acpi_perf0: on cpu0 +acpi_throttle0: on cpu0 # sysctl dev.cpu|grep freq dev.cpu.0.freq: 1700 dev.cpu.0.freq_levels: 1700/24500 1487/21437 1400/19500 1275/18375 1225/17062 1200/16000 1062/15312 1000/13000 900/12000 875/12187 850/12250 800/9500 750/10000 700/9750 637/9187 600/6000 525/7312 500/6500 450/6000 425/6125 400/4750 375/4875 350/4875 300/4000 250/3250 212/3062 175/2437 150/2000 125/1625 100/1187 75/750 Only cpufreq loaded at boot: +est0: on cpu0 +p4tcc0: on cpu0 +ichss: enabling SpeedStep support +ichss0: on cpu0 # sysctl dev.cpu|grep freq dev.cpu.0.freq: 1699 -- Pawel From owner-freebsd-acpi@FreeBSD.ORG Thu Feb 17 10:07:18 2005 Return-Path: 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 9005A16A4CE for ; Thu, 17 Feb 2005 10:07:18 +0000 (GMT) Received: from poup.poupinou.org (poup.poupinou.org [195.101.94.96]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2D48A43D55 for ; Thu, 17 Feb 2005 10:07:18 +0000 (GMT) (envelope-from ducrot@poupinou.org) Received: from ducrot by poup.poupinou.org with local (Exim) id 1D1iYe-0001bF-00; Thu, 17 Feb 2005 11:06:52 +0100 Date: Thu, 17 Feb 2005 11:06:52 +0100 To: Pawel Worach Message-ID: <20050217100652.GS1145@poupinou.org> References: <4213F066.2050708@root.org> <4214119B.2010909@telia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4214119B.2010909@telia.com> User-Agent: Mutt/1.5.6+20040907i From: Bruno Ducrot cc: acpi@freebsd.org Subject: Re: patch: p4tcc and speedstep cpufreq drivers X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Feb 2005 10:07:18 -0000 On Thu, Feb 17, 2005 at 04:38:03AM +0100, Pawel Worach wrote: > Only cpufreq loaded at boot: > +est0: on cpu0 > +p4tcc0: on cpu0 > +ichss: enabling SpeedStep support > +ichss0: on cpu0 est0 and ichss0? I doubt this work. I'm afraid there is something wrong there. -- Bruno Ducrot -- Which is worse: ignorance or apathy? -- Don't know. Don't care. From owner-freebsd-acpi@FreeBSD.ORG Thu Feb 17 11:39:46 2005 Return-Path: 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 8180616A4CE for ; Thu, 17 Feb 2005 11:39:46 +0000 (GMT) Received: from svm.csie.ntu.edu.tw (svm.csie.ntu.edu.tw [140.112.90.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id EF37C43D3F for ; Thu, 17 Feb 2005 11:39:45 +0000 (GMT) (envelope-from rafan@svm.csie.ntu.edu.tw) Received: from svm.csie.ntu.edu.tw (localhost [127.0.0.1]) by svm.csie.ntu.edu.tw (8.13.1/8.13.1) with ESMTP id j1HBdiMI096670; Thu, 17 Feb 2005 19:39:44 +0800 (CST) (envelope-from rafan@svm.csie.ntu.edu.tw) Received: (from rafan@localhost) by svm.csie.ntu.edu.tw (8.13.1/8.13.1/Submit) id j1HBddS5096669; Thu, 17 Feb 2005 19:39:39 +0800 (CST) (envelope-from rafan) Date: Thu, 17 Feb 2005 19:39:39 +0800 From: Rong-En Fan To: acpi@freebsd.org Message-ID: <20050217113939.GA96580@svm.csie.ntu.edu.tw> References: <4213F066.2050708@root.org> <4214119B.2010909@telia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4214119B.2010909@telia.com> User-Agent: Mutt/1.5.7i Subject: Re: patch: p4tcc and speedstep cpufreq drivers X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Feb 2005 11:39:46 -0000 On Thu, Feb 17, 2005 at 04:38:03AM +0100, Pawel Worach wrote: > Nate Lawson wrote: > >Attached is a patch that I'd like to get tested. After applying it, > >rebuild and load the cpufreq.ko module. Be sure you do _not_ have > >"options CPU_ENABLE_TCC" in your kernel config or the new driver will > >conflict with the old. > > Hi Nate, > > This is what I get on a TP T41, do the cpufreq results below look right? > Also if I loaded both modules all I got for dev.cpu.0.freq was -1 or 1700 > and no levels. Strange, I get no freq info in dev.cpu on a TP X31. load cpufreq only: est0: on cpu0 p4tcc0: on cpu0 dev.cpu.0.%desc: ACPI CPU (3 Cx states) dev.cpu.0.%driver: cpu dev.cpu.0.%location: handle=\_PR_.CPU_ dev.cpu.0.%pnpinfo: _HID=none _UID=0 dev.cpu.0.%parent: acpi0 dev.est.0.%desc: Enhanced SpeedStep Frequency Control dev.est.0.%driver: est dev.est.0.%parent: cpu0 load cpufreq and acpi_freq acpi_perf0: on cpu0 acpi_throttle0: on cpu0 acpi_throttle0: P_CNT from P_BLK 0x1010 and dev.cpu.0.freq: -1 Regards, Rong-En Fan From owner-freebsd-acpi@FreeBSD.ORG Thu Feb 17 19:38:28 2005 Return-Path: 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 E93DF16A4CE for ; Thu, 17 Feb 2005 19:38:28 +0000 (GMT) Received: from mailtest.sd73.bc.ca (smtp.sd73.bc.ca [142.24.13.149]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8FE1243D1D for ; Thu, 17 Feb 2005 19:38:28 +0000 (GMT) (envelope-from fcash-ml@sd73.bc.ca) Received: from localhost (localhost [127.0.0.1]) by mailtest.sd73.bc.ca (Postfix) with ESMTP id 9E340F2772 for ; Thu, 17 Feb 2005 11:38:26 -0800 (PST) Received: from mailtest.sd73.bc.ca ([127.0.0.1]) by localhost (mailtest.sd73.bc.ca [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 10018-01-91 for ; Thu, 17 Feb 2005 11:38:26 -0800 (PST) Received: from s9.sbo (s9.sbo [192.168.0.9]) by mailtest.sd73.bc.ca (Postfix) with ESMTP id EC47CF276B for ; Thu, 17 Feb 2005 11:38:25 -0800 (PST) From: Freddie Cash Organization: School District 73 - Kamloops, BC To: freebsd-acpi@freebsd.org Date: Thu, 17 Feb 2005 11:38:24 -0800 User-Agent: KMail/1.7.2 References: <4213F066.2050708@root.org> In-Reply-To: <4213F066.2050708@root.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200502171138.25123.fcash-ml@sd73.bc.ca> X-Virus-Scanned: by amavisd-new using ClamAV at sd73.bc.ca Subject: Re: patch: p4tcc and speedstep cpufreq drivers X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Feb 2005 19:38:29 -0000 On February 16, 2005 05:16 pm, Nate Lawson wrote: > Attached is a patch that I'd like to get tested. After applying it, > rebuild and load the cpufreq.ko module. Be sure you do _not_ have > "options CPU_ENABLE_TCC" in your kernel config or the new driver will > conflict with the old. I'm not too versed in the use of patch, or reading diffs. Where would one run patch to use this diff? From /usr/src or /usr/src/sys? With or without -p0? Anything else to watch for? I've like to try this as my laptop only has throttling support via p4tcc right now. -- Freddie Cash, CCNT CCLP Helpdesk / Network Support Tech. School District 73 (250) 377-HELP [377-4357] fcash-ml@sd73.bc.ca From owner-freebsd-acpi@FreeBSD.ORG Thu Feb 17 20:57:32 2005 Return-Path: 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 982BB16A4CE for ; Thu, 17 Feb 2005 20:57:32 +0000 (GMT) Received: from mailtest.sd73.bc.ca (smtp.sd73.bc.ca [142.24.13.149]) by mx1.FreeBSD.org (Postfix) with ESMTP id 52BD543D1D for ; Thu, 17 Feb 2005 20:57:32 +0000 (GMT) (envelope-from fcash-ml@sd73.bc.ca) Received: from localhost (localhost [127.0.0.1]) by mailtest.sd73.bc.ca (Postfix) with ESMTP id 2BAAFF20F4 for ; Thu, 17 Feb 2005 12:57:32 -0800 (PST) Received: from mailtest.sd73.bc.ca ([127.0.0.1]) by localhost (mailtest.sd73.bc.ca [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 12302-01-11 for ; Thu, 17 Feb 2005 12:57:31 -0800 (PST) Received: from s9.sbo (s9.sbo [192.168.0.9]) by mailtest.sd73.bc.ca (Postfix) with ESMTP id 7D9F0F1FE1 for ; Thu, 17 Feb 2005 12:57:31 -0800 (PST) From: Freddie Cash Organization: School District 73 - Kamloops, BC To: freebsd-acpi@freebsd.org Date: Thu, 17 Feb 2005 12:57:29 -0800 User-Agent: KMail/1.7.2 References: <4213F066.2050708@root.org> In-Reply-To: <4213F066.2050708@root.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200502171257.30422.fcash-ml@sd73.bc.ca> X-Virus-Scanned: by amavisd-new using ClamAV at sd73.bc.ca Subject: Re: patch: p4tcc and speedstep cpufreq drivers X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Feb 2005 20:57:32 -0000 On February 16, 2005 05:16 pm, Nate Lawson wrote: > Attached is a patch that I'd like to get tested. After applying it, > rebuild and load the cpufreq.ko module. Be sure you do _not_ have > "options CPU_ENABLE_TCC" in your kernel config or the new driver will > conflict with the old. I get an error during the kernel build: ===> cpufreq (depend) @ -> /usr/src/sys machine -> /usr/src/sys/i386/include awk -f @/tools/makeobjops.awk @/kern/bus_if.m -h awk -f @/tools/makeobjops.awk @/kern/cpufreq_if.m -h awk -f @/tools/makeobjops.awk @/kern/device_if.m -h awk -f @/tools/makeobjops.awk @/dev/pci/pci_if.m -h make: don't know how to make est.c. Stop This is on 6-CURRENT, cvsup'd yesterday afternoon. -- Freddie Cash, CCNT CCLP Helpdesk / Network Support Tech. School District 73 (250) 377-HELP [377-4357] fcash-ml@sd73.bc.ca From owner-freebsd-acpi@FreeBSD.ORG Fri Feb 18 00:06:50 2005 Return-Path: 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 48D8016A4D6 for ; Fri, 18 Feb 2005 00:06:50 +0000 (GMT) Received: from mailtest.sd73.bc.ca (smtp.sd73.bc.ca [142.24.13.149]) by mx1.FreeBSD.org (Postfix) with ESMTP id 03DB143D1D for ; Fri, 18 Feb 2005 00:06:50 +0000 (GMT) (envelope-from fcash-ml@sd73.bc.ca) Received: from localhost (localhost [127.0.0.1]) by mailtest.sd73.bc.ca (Postfix) with ESMTP id E0035F2783 for ; Thu, 17 Feb 2005 16:06:49 -0800 (PST) Received: from mailtest.sd73.bc.ca ([127.0.0.1]) by localhost (mailtest.sd73.bc.ca [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 15014-01-78 for ; Thu, 17 Feb 2005 16:06:49 -0800 (PST) Received: from s9.sbo (s9.sbo [192.168.0.9]) by mailtest.sd73.bc.ca (Postfix) with ESMTP id 22B20F279C for ; Thu, 17 Feb 2005 16:06:49 -0800 (PST) From: Freddie Cash Organization: School District 73 - Kamloops, BC To: freebsd-acpi@freebsd.org Date: Thu, 17 Feb 2005 16:06:49 -0800 User-Agent: KMail/1.7.2 References: <4213F066.2050708@root.org> In-Reply-To: <4213F066.2050708@root.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200502171606.49459.fcash-ml@sd73.bc.ca> X-Virus-Scanned: by amavisd-new using ClamAV at sd73.bc.ca Subject: Re: patch: p4tcc and speedstep cpufreq drivers X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Feb 2005 00:06:50 -0000 On February 16, 2005 05:16 pm, Nate Lawson wrote: > Attached is a patch that I'd like to get tested. After applying it, > rebuild and load the cpufreq.ko module. Be sure you do _not_ have > "options CPU_ENABLE_TCC" in your kernel config or the new driver will > conflict with the old. > I do not have either hardware so I am not certain the drivers work. > For starters, I'd just like to get results from people saying whether > or not the driver attaches and they show new settings and second, > whether it does anything useful when changing settings. Try a Took me a little bit to figure it out, but the module is built and loading. But, it doesn't provide anything useful. In fact, it doesn't provide anything at all. :( A kernel with CPU_ENABLE_TCC provides me with the hw.p4tcc sysctls that I can use to change the CPU frequency. A kernel without CPU_ENABLE_TCC doesn't give me any throttling / frequency settings. Loading the cpufreq.ko module doesn't change anything. This is on a Toshiba Satellite A60, bios 1.80c. It's a 2.8 GHz Celeron (P4). It's not the greatest BIOS or ACPI implementation. :( -- Freddie Cash, CCNT CCLP Helpdesk / Network Support Tech. School District 73 (250) 377-HELP [377-4357] fcash-ml@sd73.bc.ca From owner-freebsd-acpi@FreeBSD.ORG Fri Feb 18 00:33:50 2005 Return-Path: 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 BD68D16A4CE; Fri, 18 Feb 2005 00:33:50 +0000 (GMT) Received: from ylpvm01.prodigy.net (ylpvm01-ext.prodigy.net [207.115.57.32]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0E4F343D3F; Fri, 18 Feb 2005 00:33:48 +0000 (GMT) (envelope-from nate@root.org) Received: from [10.0.0.34] (adsl-67-119-74-222.dsl.sntc01.pacbell.net [67.119.74.222])j1I0XjvE011617; Thu, 17 Feb 2005 19:33:45 -0500 Message-ID: <421537E9.8050203@root.org> Date: Thu, 17 Feb 2005 16:33:45 -0800 From: Nate Lawson User-Agent: Mozilla Thunderbird 1.0RC1 (X11/20041205) X-Accept-Language: en-us, en MIME-Version: 1.0 To: acpi@freebsd.org References: <4213F066.2050708@root.org> <4214119B.2010909@telia.com> In-Reply-To: <4214119B.2010909@telia.com> Content-Type: multipart/mixed; boundary="------------090907050404050609010507" cc: current@freebsd.org Subject: Re: patch: p4tcc and speedstep cpufreq drivers X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Feb 2005 00:33:50 -0000 This is a multi-part message in MIME format. --------------090907050404050609010507 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Pawel Worach wrote: > Nate Lawson wrote: > >> Attached is a patch that I'd like to get tested. After applying it, >> rebuild and load the cpufreq.ko module. Be sure you do _not_ have >> "options CPU_ENABLE_TCC" in your kernel config or the new driver will >> conflict with the old. > > > Hi Nate, > > This is what I get on a TP T41, do the cpufreq results below look right? > Also if I loaded both modules all I got for dev.cpu.0.freq was -1 or > 1700 and no levels. > > CPU: Intel(R) Pentium(R) M processor 1700MHz (1698.56-MHz 686-class CPU) > Origin = "GenuineIntel" Id = 0x695 Stepping = 5 > Features=0xa7e9f9bf Apologies. I found 2 bugs, one was not calling cpufreq_register() and the other was that the code to detect acpi_perf (in ichss and est) was incorrect. I've committed fixes for that and have updated the patch. Please ues this version and test again. Thanks, -- Nate --------------090907050404050609010507 Content-Type: text/plain; name="cpufreq_est_p4tcc.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="cpufreq_est_p4tcc.diff" Index: conf/files.i386 =================================================================== RCS file: /home/ncvs/src/sys/conf/files.i386,v retrieving revision 1.516 diff -u -r1.516 files.i386 --- conf/files.i386 9 Feb 2005 20:03:39 -0000 1.516 +++ conf/files.i386 16 Feb 2005 16:05:02 -0000 @@ -218,6 +218,8 @@ i386/bios/smapi_bios.S optional smapi i386/bios/smbios.c optional smbios i386/bios/vpd.c optional vpd +i386/cpufreq/est.c optional cpufreq +i386/cpufreq/p4tcc.c optional cpufreq #i386/i386/apic_vector.s optional apic i386/i386/atomic.c standard \ compile-with "${CC} -c ${CFLAGS} ${DEFINED_PROF:S/^$/-fomit-frame-pointer/} ${.IMPSRC}" Index: modules/cpufreq/Makefile =================================================================== RCS file: /home/ncvs/src/sys/modules/cpufreq/Makefile,v retrieving revision 1.1 diff -u -r1.1 Makefile --- modules/cpufreq/Makefile 4 Feb 2005 05:49:36 -0000 1.1 +++ modules/cpufreq/Makefile 17 Feb 2005 01:03:30 -0000 @@ -1,10 +1,15 @@ # $FreeBSD$ -.PATH: ${.CURDIR}/../../dev/cpufreq +.PATH: ${.CURDIR}/../../dev/cpufreq \ + ${.CURDIR}/../../${MACHINE_ARCH}/cpufreq KMOD= cpufreq WARNS?= 2 SRCS= ichss.c SRCS+= bus_if.h cpufreq_if.h device_if.h pci_if.h +.if ${MACHINE} == "i386" +SRCS+= est.c p4tcc.c +.endif + .include Index: i386/cpufreq/est.c =================================================================== RCS file: i386/cpufreq/est.c diff -N i386/cpufreq/est.c --- /dev/null 1 Jan 1970 00:00:00 -0000 +++ i386/cpufreq/est.c 18 Feb 2005 00:09:59 -0000 @@ -0,0 +1,788 @@ +/*- + * Copyright (c) 2004 Colin Percival + * Copyright (c) 2005 Nate Lawson + * All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted providing that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * + * THIS SOFTWARE IS PROVIDED BY THE AUTHOR``AS IS'' AND ANY EXPRESS OR + * IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED + * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY + * DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, + * STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING + * IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE + * POSSIBILITY OF SUCH DAMAGE. + */ + +#include +__FBSDID("$FreeBSD$"); + +#include +#include +#include +#include +#include +#include +#include + +#include "cpufreq_if.h" +#include + +/* Status/control registers (from the IA-32 System Programming Guide). */ +#define MSR_PERF_STATUS 0x198 +#define MSR_PERF_CTL 0x199 + +/* Register and bit for enabling SpeedStep. */ +#define MSR_MISC_ENABLE 0x1a0 +#define MSR_SS_ENABLE (1<<16) + +/* Frequency and MSR control values. */ +typedef struct { + uint16_t freq; + uint16_t volts; + uint16_t id16; +} freq_info; + +/* Identifying characteristics of a processor and supported frequencies. */ +typedef struct { + const char *vendor; + uint32_t id32; + uint32_t bus_clk; + const freq_info *freqtab; +} cpu_info; + +struct est_softc { + device_t dev; + const freq_info *freq_list; +}; + +/* Convert MHz and mV into IDs for passing to the MSR. */ +#define ID16(MHz, mV, bus_clk) \ + (((MHz / bus_clk) << 8) | ((mV ? mV - 700 : 0) >> 4)) +#define ID32(MHz_hi, mV_hi, MHz_lo, mV_lo, bus_clk) \ + ((ID16(MHz_lo, mV_lo, bus_clk) << 16) | (ID16(MHz_hi, mV_hi, bus_clk))) + +/* Format for storing IDs in our table. */ +#define FREQ_INFO(MHz, mV, bus_clk) \ + { MHz, mV, ID16(MHz, mV, bus_clk) } +#define INTEL(tab, zhi, vhi, zlo, vlo, bus_clk) \ + { GenuineIntel, ID32(zhi, vhi, zlo, vlo, bus_clk), bus_clk, tab } + +const char GenuineIntel[] = "GenuineIntel"; + +/* Default bus clock value for Centrino processors. */ +#define INTEL_BUS_CLK 100 + +/* XXX Update this if new CPUs have more settings. */ +#define EST_MAX_SETTINGS 10 +CTASSERT(EST_MAX_SETTINGS <= MAX_SETTINGS); + +/* Estimate in microseconds of latency for performing a transition. */ +#define EST_TRANS_LAT 10 + +/* + * Frequency (MHz) and voltage (mV) settings. Data from the + * Intel Pentium M Processor Datasheet (Order Number 252612), Table 5. + * + * XXX New Dothan processors have multiple VID# with different + * settings for each VID#. Since we can't uniquely identify this info + * without undisclosed methods from Intel, we can't support newer + * processors with this table method. If ACPI Px states are supported, + * we can get info from them. + */ +const freq_info PM17_130[] = { + /* 130nm 1.70GHz Pentium M */ + FREQ_INFO(1700, 1484, INTEL_BUS_CLK), + FREQ_INFO(1400, 1308, INTEL_BUS_CLK), + FREQ_INFO(1200, 1228, INTEL_BUS_CLK), + FREQ_INFO(1000, 1116, INTEL_BUS_CLK), + FREQ_INFO( 800, 1004, INTEL_BUS_CLK), + FREQ_INFO( 600, 956, INTEL_BUS_CLK), + FREQ_INFO( 0, 0, 1), +}; +const freq_info PM16_130[] = { + /* 130nm 1.60GHz Pentium M */ + FREQ_INFO(1600, 1484, INTEL_BUS_CLK), + FREQ_INFO(1400, 1420, INTEL_BUS_CLK), + FREQ_INFO(1200, 1276, INTEL_BUS_CLK), + FREQ_INFO(1000, 1164, INTEL_BUS_CLK), + FREQ_INFO( 800, 1036, INTEL_BUS_CLK), + FREQ_INFO( 600, 956, INTEL_BUS_CLK), + FREQ_INFO( 0, 0, 1), +}; +const freq_info PM15_130[] = { + /* 130nm 1.50GHz Pentium M */ + FREQ_INFO(1500, 1484, INTEL_BUS_CLK), + FREQ_INFO(1400, 1452, INTEL_BUS_CLK), + FREQ_INFO(1200, 1356, INTEL_BUS_CLK), + FREQ_INFO(1000, 1228, INTEL_BUS_CLK), + FREQ_INFO( 800, 1116, INTEL_BUS_CLK), + FREQ_INFO( 600, 956, INTEL_BUS_CLK), + FREQ_INFO( 0, 0, 1), +}; +const freq_info PM14_130[] = { + /* 130nm 1.40GHz Pentium M */ + FREQ_INFO(1400, 1484, INTEL_BUS_CLK), + FREQ_INFO(1200, 1436, INTEL_BUS_CLK), + FREQ_INFO(1000, 1308, INTEL_BUS_CLK), + FREQ_INFO( 800, 1180, INTEL_BUS_CLK), + FREQ_INFO( 600, 956, INTEL_BUS_CLK), + FREQ_INFO( 0, 0, 1), +}; +const freq_info PM13_130[] = { + /* 130nm 1.30GHz Pentium M */ + FREQ_INFO(1300, 1388, INTEL_BUS_CLK), + FREQ_INFO(1200, 1356, INTEL_BUS_CLK), + FREQ_INFO(1000, 1292, INTEL_BUS_CLK), + FREQ_INFO( 800, 1260, INTEL_BUS_CLK), + FREQ_INFO( 600, 956, INTEL_BUS_CLK), + FREQ_INFO( 0, 0, 1), +}; +const freq_info PM13_LV_130[] = { + /* 130nm 1.30GHz Low Voltage Pentium M */ + FREQ_INFO(1300, 1180, INTEL_BUS_CLK), + FREQ_INFO(1200, 1164, INTEL_BUS_CLK), + FREQ_INFO(1100, 1100, INTEL_BUS_CLK), + FREQ_INFO(1000, 1020, INTEL_BUS_CLK), + FREQ_INFO( 900, 1004, INTEL_BUS_CLK), + FREQ_INFO( 800, 988, INTEL_BUS_CLK), + FREQ_INFO( 600, 956, INTEL_BUS_CLK), + FREQ_INFO( 0, 0, 1), +}; +const freq_info PM12_LV_130[] = { + /* 130 nm 1.20GHz Low Voltage Pentium M */ + FREQ_INFO(1200, 1180, INTEL_BUS_CLK), + FREQ_INFO(1100, 1164, INTEL_BUS_CLK), + FREQ_INFO(1000, 1100, INTEL_BUS_CLK), + FREQ_INFO( 900, 1020, INTEL_BUS_CLK), + FREQ_INFO( 800, 1004, INTEL_BUS_CLK), + FREQ_INFO( 600, 956, INTEL_BUS_CLK), + FREQ_INFO( 0, 0, 1), +}; +const freq_info PM11_LV_130[] = { + /* 130 nm 1.10GHz Low Voltage Pentium M */ + FREQ_INFO(1100, 1180, INTEL_BUS_CLK), + FREQ_INFO(1000, 1164, INTEL_BUS_CLK), + FREQ_INFO( 900, 1100, INTEL_BUS_CLK), + FREQ_INFO( 800, 1020, INTEL_BUS_CLK), + FREQ_INFO( 600, 956, INTEL_BUS_CLK), + FREQ_INFO( 0, 0, 1), +}; +const freq_info PM11_ULV_130[] = { + /* 130 nm 1.10GHz Ultra Low Voltage Pentium M */ + FREQ_INFO(1100, 1004, INTEL_BUS_CLK), + FREQ_INFO(1000, 988, INTEL_BUS_CLK), + FREQ_INFO( 900, 972, INTEL_BUS_CLK), + FREQ_INFO( 800, 956, INTEL_BUS_CLK), + FREQ_INFO( 600, 844, INTEL_BUS_CLK), + FREQ_INFO( 0, 0, 1), +}; +const freq_info PM10_ULV_130[] = { + /* 130 nm 1.00GHz Ultra Low Voltage Pentium M */ + FREQ_INFO(1000, 1004, INTEL_BUS_CLK), + FREQ_INFO( 900, 988, INTEL_BUS_CLK), + FREQ_INFO( 800, 972, INTEL_BUS_CLK), + FREQ_INFO( 600, 844, INTEL_BUS_CLK), + FREQ_INFO( 0, 0, 1), +}; + +/* + * Data from "Intel Pentium M Processor on 90nm Process with + * 2-MB L2 Cache Datasheet", Order Number 302189, Table 5. + */ +const freq_info PM_765A_90[] = { + /* 90 nm 2.10GHz Pentium M, VID #A */ + FREQ_INFO(2100, 1340, INTEL_BUS_CLK), + FREQ_INFO(1800, 1276, INTEL_BUS_CLK), + FREQ_INFO(1600, 1228, INTEL_BUS_CLK), + FREQ_INFO(1400, 1180, INTEL_BUS_CLK), + FREQ_INFO(1200, 1132, INTEL_BUS_CLK), + FREQ_INFO(1000, 1084, INTEL_BUS_CLK), + FREQ_INFO( 800, 1036, INTEL_BUS_CLK), + FREQ_INFO( 600, 988, INTEL_BUS_CLK), + FREQ_INFO( 0, 0, 1), +}; +const freq_info PM_765B_90[] = { + /* 90 nm 2.10GHz Pentium M, VID #B */ + FREQ_INFO(2100, 1324, INTEL_BUS_CLK), + FREQ_INFO(1800, 1260, INTEL_BUS_CLK), + FREQ_INFO(1600, 1212, INTEL_BUS_CLK), + FREQ_INFO(1400, 1180, INTEL_BUS_CLK), + FREQ_INFO(1200, 1132, INTEL_BUS_CLK), + FREQ_INFO(1000, 1084, INTEL_BUS_CLK), + FREQ_INFO( 800, 1036, INTEL_BUS_CLK), + FREQ_INFO( 600, 988, INTEL_BUS_CLK), + FREQ_INFO( 0, 0, 1), +}; +const freq_info PM_765C_90[] = { + /* 90 nm 2.10GHz Pentium M, VID #C */ + FREQ_INFO(2100, 1308, INTEL_BUS_CLK), + FREQ_INFO(1800, 1244, INTEL_BUS_CLK), + FREQ_INFO(1600, 1212, INTEL_BUS_CLK), + FREQ_INFO(1400, 1164, INTEL_BUS_CLK), + FREQ_INFO(1200, 1116, INTEL_BUS_CLK), + FREQ_INFO(1000, 1084, INTEL_BUS_CLK), + FREQ_INFO( 800, 1036, INTEL_BUS_CLK), + FREQ_INFO( 600, 988, INTEL_BUS_CLK), + FREQ_INFO( 0, 0, 1), +}; +const freq_info PM_765E_90[] = { + /* 90 nm 2.10GHz Pentium M, VID #E */ + FREQ_INFO(2100, 1356, INTEL_BUS_CLK), + FREQ_INFO(1800, 1292, INTEL_BUS_CLK), + FREQ_INFO(1600, 1244, INTEL_BUS_CLK), + FREQ_INFO(1400, 1196, INTEL_BUS_CLK), + FREQ_INFO(1200, 1148, INTEL_BUS_CLK), + FREQ_INFO(1000, 1100, INTEL_BUS_CLK), + FREQ_INFO( 800, 1052, INTEL_BUS_CLK), + FREQ_INFO( 600, 988, INTEL_BUS_CLK), + FREQ_INFO( 0, 0, 1), +}; +const freq_info PM_755A_90[] = { + /* 90 nm 2.00GHz Pentium M, VID #A */ + FREQ_INFO(2000, 1340, INTEL_BUS_CLK), + FREQ_INFO(1800, 1292, INTEL_BUS_CLK), + FREQ_INFO(1600, 1244, INTEL_BUS_CLK), + FREQ_INFO(1400, 1196, INTEL_BUS_CLK), + FREQ_INFO(1200, 1148, INTEL_BUS_CLK), + FREQ_INFO(1000, 1100, INTEL_BUS_CLK), + FREQ_INFO( 800, 1052, INTEL_BUS_CLK), + FREQ_INFO( 600, 988, INTEL_BUS_CLK), + FREQ_INFO( 0, 0, 1), +}; +const freq_info PM_755B_90[] = { + /* 90 nm 2.00GHz Pentium M, VID #B */ + FREQ_INFO(2000, 1324, INTEL_BUS_CLK), + FREQ_INFO(1800, 1276, INTEL_BUS_CLK), + FREQ_INFO(1600, 1228, INTEL_BUS_CLK), + FREQ_INFO(1400, 1180, INTEL_BUS_CLK), + FREQ_INFO(1200, 1132, INTEL_BUS_CLK), + FREQ_INFO(1000, 1084, INTEL_BUS_CLK), + FREQ_INFO( 800, 1036, INTEL_BUS_CLK), + FREQ_INFO( 600, 988, INTEL_BUS_CLK), + FREQ_INFO( 0, 0, 1), +}; +const freq_info PM_755C_90[] = { + /* 90 nm 2.00GHz Pentium M, VID #C */ + FREQ_INFO(2000, 1308, INTEL_BUS_CLK), + FREQ_INFO(1800, 1276, INTEL_BUS_CLK), + FREQ_INFO(1600, 1228, INTEL_BUS_CLK), + FREQ_INFO(1400, 1180, INTEL_BUS_CLK), + FREQ_INFO(1200, 1132, INTEL_BUS_CLK), + FREQ_INFO(1000, 1084, INTEL_BUS_CLK), + FREQ_INFO( 800, 1036, INTEL_BUS_CLK), + FREQ_INFO( 600, 988, INTEL_BUS_CLK), + FREQ_INFO( 0, 0, 1), +}; +const freq_info PM_755D_90[] = { + /* 90 nm 2.00GHz Pentium M, VID #D */ + FREQ_INFO(2000, 1276, INTEL_BUS_CLK), + FREQ_INFO(1800, 1244, INTEL_BUS_CLK), + FREQ_INFO(1600, 1196, INTEL_BUS_CLK), + FREQ_INFO(1400, 1164, INTEL_BUS_CLK), + FREQ_INFO(1200, 1116, INTEL_BUS_CLK), + FREQ_INFO(1000, 1084, INTEL_BUS_CLK), + FREQ_INFO( 800, 1036, INTEL_BUS_CLK), + FREQ_INFO( 600, 988, INTEL_BUS_CLK), + FREQ_INFO( 0, 0, 1), +}; +const freq_info PM_745A_90[] = { + /* 90 nm 1.80GHz Pentium M, VID #A */ + FREQ_INFO(1800, 1340, INTEL_BUS_CLK), + FREQ_INFO(1600, 1292, INTEL_BUS_CLK), + FREQ_INFO(1400, 1228, INTEL_BUS_CLK), + FREQ_INFO(1200, 1164, INTEL_BUS_CLK), + FREQ_INFO(1000, 1116, INTEL_BUS_CLK), + FREQ_INFO( 800, 1052, INTEL_BUS_CLK), + FREQ_INFO( 600, 988, INTEL_BUS_CLK), + FREQ_INFO( 0, 0, 1), +}; +const freq_info PM_745B_90[] = { + /* 90 nm 1.80GHz Pentium M, VID #B */ + FREQ_INFO(1800, 1324, INTEL_BUS_CLK), + FREQ_INFO(1600, 1276, INTEL_BUS_CLK), + FREQ_INFO(1400, 1212, INTEL_BUS_CLK), + FREQ_INFO(1200, 1164, INTEL_BUS_CLK), + FREQ_INFO(1000, 1116, INTEL_BUS_CLK), + FREQ_INFO( 800, 1052, INTEL_BUS_CLK), + FREQ_INFO( 600, 988, INTEL_BUS_CLK), + FREQ_INFO( 0, 0, 1), +}; +const freq_info PM_745C_90[] = { + /* 90 nm 1.80GHz Pentium M, VID #C */ + FREQ_INFO(1800, 1308, INTEL_BUS_CLK), + FREQ_INFO(1600, 1260, INTEL_BUS_CLK), + FREQ_INFO(1400, 1212, INTEL_BUS_CLK), + FREQ_INFO(1200, 1148, INTEL_BUS_CLK), + FREQ_INFO(1000, 1100, INTEL_BUS_CLK), + FREQ_INFO( 800, 1052, INTEL_BUS_CLK), + FREQ_INFO( 600, 988, INTEL_BUS_CLK), + FREQ_INFO( 0, 0, 1), +}; +const freq_info PM_745D_90[] = { + /* 90 nm 1.80GHz Pentium M, VID #D */ + FREQ_INFO(1800, 1276, INTEL_BUS_CLK), + FREQ_INFO(1600, 1228, INTEL_BUS_CLK), + FREQ_INFO(1400, 1180, INTEL_BUS_CLK), + FREQ_INFO(1200, 1132, INTEL_BUS_CLK), + FREQ_INFO(1000, 1084, INTEL_BUS_CLK), + FREQ_INFO( 800, 1036, INTEL_BUS_CLK), + FREQ_INFO( 600, 988, INTEL_BUS_CLK), + FREQ_INFO( 0, 0, 1), +}; +const freq_info PM_735A_90[] = { + /* 90 nm 1.70GHz Pentium M, VID #A */ + FREQ_INFO(1700, 1340, INTEL_BUS_CLK), + FREQ_INFO(1400, 1244, INTEL_BUS_CLK), + FREQ_INFO(1200, 1180, INTEL_BUS_CLK), + FREQ_INFO(1000, 1116, INTEL_BUS_CLK), + FREQ_INFO( 800, 1052, INTEL_BUS_CLK), + FREQ_INFO( 600, 988, INTEL_BUS_CLK), + FREQ_INFO( 0, 0, 1), +}; +const freq_info PM_735B_90[] = { + /* 90 nm 1.70GHz Pentium M, VID #B */ + FREQ_INFO(1700, 1324, INTEL_BUS_CLK), + FREQ_INFO(1400, 1244, INTEL_BUS_CLK), + FREQ_INFO(1200, 1180, INTEL_BUS_CLK), + FREQ_INFO(1000, 1116, INTEL_BUS_CLK), + FREQ_INFO( 800, 1052, INTEL_BUS_CLK), + FREQ_INFO( 600, 988, INTEL_BUS_CLK), + FREQ_INFO( 0, 0, 1), +}; +const freq_info PM_735C_90[] = { + /* 90 nm 1.70GHz Pentium M, VID #C */ + FREQ_INFO(1700, 1308, INTEL_BUS_CLK), + FREQ_INFO(1400, 1228, INTEL_BUS_CLK), + FREQ_INFO(1200, 1164, INTEL_BUS_CLK), + FREQ_INFO(1000, 1116, INTEL_BUS_CLK), + FREQ_INFO( 800, 1052, INTEL_BUS_CLK), + FREQ_INFO( 600, 988, INTEL_BUS_CLK), + FREQ_INFO( 0, 0, 1), +}; +const freq_info PM_735D_90[] = { + /* 90 nm 1.70GHz Pentium M, VID #D */ + FREQ_INFO(1700, 1276, INTEL_BUS_CLK), + FREQ_INFO(1400, 1212, INTEL_BUS_CLK), + FREQ_INFO(1200, 1148, INTEL_BUS_CLK), + FREQ_INFO(1000, 1100, INTEL_BUS_CLK), + FREQ_INFO( 800, 1052, INTEL_BUS_CLK), + FREQ_INFO( 600, 988, INTEL_BUS_CLK), + FREQ_INFO( 0, 0, 1), +}; +const freq_info PM_725A_90[] = { + /* 90 nm 1.60GHz Pentium M, VID #A */ + FREQ_INFO(1600, 1340, INTEL_BUS_CLK), + FREQ_INFO(1400, 1276, INTEL_BUS_CLK), + FREQ_INFO(1200, 1212, INTEL_BUS_CLK), + FREQ_INFO(1000, 1132, INTEL_BUS_CLK), + FREQ_INFO( 800, 1068, INTEL_BUS_CLK), + FREQ_INFO( 600, 988, INTEL_BUS_CLK), + FREQ_INFO( 0, 0, 1), +}; +const freq_info PM_725B_90[] = { + /* 90 nm 1.60GHz Pentium M, VID #B */ + FREQ_INFO(1600, 1324, INTEL_BUS_CLK), + FREQ_INFO(1400, 1260, INTEL_BUS_CLK), + FREQ_INFO(1200, 1196, INTEL_BUS_CLK), + FREQ_INFO(1000, 1132, INTEL_BUS_CLK), + FREQ_INFO( 800, 1068, INTEL_BUS_CLK), + FREQ_INFO( 600, 988, INTEL_BUS_CLK), + FREQ_INFO( 0, 0, 1), +}; +const freq_info PM_725C_90[] = { + /* 90 nm 1.60GHz Pentium M, VID #C */ + FREQ_INFO(1600, 1308, INTEL_BUS_CLK), + FREQ_INFO(1400, 1244, INTEL_BUS_CLK), + FREQ_INFO(1200, 1180, INTEL_BUS_CLK), + FREQ_INFO(1000, 1116, INTEL_BUS_CLK), + FREQ_INFO( 800, 1052, INTEL_BUS_CLK), + FREQ_INFO( 600, 988, INTEL_BUS_CLK), + FREQ_INFO( 0, 0, 1), +}; +const freq_info PM_725D_90[] = { + /* 90 nm 1.60GHz Pentium M, VID #D */ + FREQ_INFO(1600, 1276, INTEL_BUS_CLK), + FREQ_INFO(1400, 1228, INTEL_BUS_CLK), + FREQ_INFO(1200, 1164, INTEL_BUS_CLK), + FREQ_INFO(1000, 1116, INTEL_BUS_CLK), + FREQ_INFO( 800, 1052, INTEL_BUS_CLK), + FREQ_INFO( 600, 988, INTEL_BUS_CLK), + FREQ_INFO( 0, 0, 1), +}; +const freq_info PM_715A_90[] = { + /* 90 nm 1.50GHz Pentium M, VID #A */ + FREQ_INFO(1500, 1340, INTEL_BUS_CLK), + FREQ_INFO(1200, 1228, INTEL_BUS_CLK), + FREQ_INFO(1000, 1148, INTEL_BUS_CLK), + FREQ_INFO( 800, 1068, INTEL_BUS_CLK), + FREQ_INFO( 600, 988, INTEL_BUS_CLK), + FREQ_INFO( 0, 0, 1), +}; +const freq_info PM_715B_90[] = { + /* 90 nm 1.50GHz Pentium M, VID #B */ + FREQ_INFO(1500, 1324, INTEL_BUS_CLK), + FREQ_INFO(1200, 1212, INTEL_BUS_CLK), + FREQ_INFO(1000, 1148, INTEL_BUS_CLK), + FREQ_INFO( 800, 1068, INTEL_BUS_CLK), + FREQ_INFO( 600, 988, INTEL_BUS_CLK), + FREQ_INFO( 0, 0, 1), +}; +const freq_info PM_715C_90[] = { + /* 90 nm 1.50GHz Pentium M, VID #C */ + FREQ_INFO(1500, 1308, INTEL_BUS_CLK), + FREQ_INFO(1200, 1212, INTEL_BUS_CLK), + FREQ_INFO(1000, 1132, INTEL_BUS_CLK), + FREQ_INFO( 800, 1068, INTEL_BUS_CLK), + FREQ_INFO( 600, 988, INTEL_BUS_CLK), + FREQ_INFO( 0, 0, 1), +}; +const freq_info PM_715D_90[] = { + /* 90 nm 1.50GHz Pentium M, VID #D */ + FREQ_INFO(1500, 1276, INTEL_BUS_CLK), + FREQ_INFO(1200, 1180, INTEL_BUS_CLK), + FREQ_INFO(1000, 1116, INTEL_BUS_CLK), + FREQ_INFO( 800, 1052, INTEL_BUS_CLK), + FREQ_INFO( 600, 988, INTEL_BUS_CLK), + FREQ_INFO( 0, 0, 1), +}; +const freq_info PM_738_90[] = { + /* 90 nm 1.40GHz Low Voltage Pentium M */ + FREQ_INFO(1400, 1116, INTEL_BUS_CLK), + FREQ_INFO(1300, 1116, INTEL_BUS_CLK), + FREQ_INFO(1200, 1100, INTEL_BUS_CLK), + FREQ_INFO(1100, 1068, INTEL_BUS_CLK), + FREQ_INFO(1000, 1052, INTEL_BUS_CLK), + FREQ_INFO( 900, 1036, INTEL_BUS_CLK), + FREQ_INFO( 800, 1020, INTEL_BUS_CLK), + FREQ_INFO( 600, 988, INTEL_BUS_CLK), + FREQ_INFO( 0, 0, 1), +}; +const freq_info PM_733_90[] = { + /* 90 nm 1.10GHz Ultra Low Voltage Pentium M */ + FREQ_INFO(1100, 940, INTEL_BUS_CLK), + FREQ_INFO(1000, 924, INTEL_BUS_CLK), + FREQ_INFO( 900, 892, INTEL_BUS_CLK), + FREQ_INFO( 800, 876, INTEL_BUS_CLK), + FREQ_INFO( 600, 812, INTEL_BUS_CLK), + FREQ_INFO( 0, 0, 1), +}; +const freq_info PM_723_90[] = { + /* 90 nm 1.00GHz Ultra Low Voltage Pentium M */ + FREQ_INFO(1000, 940, INTEL_BUS_CLK), + FREQ_INFO( 900, 908, INTEL_BUS_CLK), + FREQ_INFO( 800, 876, INTEL_BUS_CLK), + FREQ_INFO( 600, 812, INTEL_BUS_CLK), + FREQ_INFO( 0, 0, 1), +}; + +const cpu_info ESTprocs[] = { + INTEL(PM17_130, 1700, 1484, 600, 956, INTEL_BUS_CLK), + INTEL(PM16_130, 1600, 1484, 600, 956, INTEL_BUS_CLK), + INTEL(PM15_130, 1500, 1484, 600, 956, INTEL_BUS_CLK), + INTEL(PM14_130, 1400, 1484, 600, 956, INTEL_BUS_CLK), + INTEL(PM13_130, 1300, 1388, 600, 956, INTEL_BUS_CLK), + INTEL(PM13_LV_130, 1300, 1180, 600, 956, INTEL_BUS_CLK), + INTEL(PM12_LV_130, 1200, 1180, 600, 956, INTEL_BUS_CLK), + INTEL(PM11_LV_130, 1100, 1180, 600, 956, INTEL_BUS_CLK), + INTEL(PM11_ULV_130, 1100, 1004, 600, 844, INTEL_BUS_CLK), + INTEL(PM10_ULV_130, 1000, 1004, 600, 844, INTEL_BUS_CLK), + INTEL(PM_765A_90, 2100, 1340, 600, 988, INTEL_BUS_CLK), + INTEL(PM_765B_90, 2100, 1324, 600, 988, INTEL_BUS_CLK), + INTEL(PM_765C_90, 2100, 1308, 600, 988, INTEL_BUS_CLK), + INTEL(PM_765E_90, 2100, 1356, 600, 988, INTEL_BUS_CLK), + INTEL(PM_755A_90, 2000, 1340, 600, 988, INTEL_BUS_CLK), + INTEL(PM_755B_90, 2000, 1324, 600, 988, INTEL_BUS_CLK), + INTEL(PM_755C_90, 2000, 1308, 600, 988, INTEL_BUS_CLK), + INTEL(PM_755D_90, 2000, 1276, 600, 988, INTEL_BUS_CLK), + INTEL(PM_745A_90, 1800, 1340, 600, 988, INTEL_BUS_CLK), + INTEL(PM_745B_90, 1800, 1324, 600, 988, INTEL_BUS_CLK), + INTEL(PM_745C_90, 1800, 1308, 600, 988, INTEL_BUS_CLK), + INTEL(PM_745D_90, 1800, 1276, 600, 988, INTEL_BUS_CLK), + INTEL(PM_735A_90, 1700, 1340, 600, 988, INTEL_BUS_CLK), + INTEL(PM_735B_90, 1700, 1324, 600, 988, INTEL_BUS_CLK), + INTEL(PM_735C_90, 1700, 1308, 600, 988, INTEL_BUS_CLK), + INTEL(PM_735D_90, 1700, 1276, 600, 988, INTEL_BUS_CLK), + INTEL(PM_725A_90, 1600, 1340, 600, 988, INTEL_BUS_CLK), + INTEL(PM_725B_90, 1600, 1324, 600, 988, INTEL_BUS_CLK), + INTEL(PM_725C_90, 1600, 1308, 600, 988, INTEL_BUS_CLK), + INTEL(PM_725D_90, 1600, 1276, 600, 988, INTEL_BUS_CLK), + INTEL(PM_715A_90, 1500, 1340, 600, 988, INTEL_BUS_CLK), + INTEL(PM_715B_90, 1500, 1324, 600, 988, INTEL_BUS_CLK), + INTEL(PM_715C_90, 1500, 1308, 600, 988, INTEL_BUS_CLK), + INTEL(PM_715D_90, 1500, 1276, 600, 988, INTEL_BUS_CLK), + INTEL(PM_738_90, 1400, 1116, 600, 988, INTEL_BUS_CLK), + INTEL(PM_733_90, 1100, 940, 600, 812, INTEL_BUS_CLK), + INTEL(PM_723_90, 1000, 940, 600, 812, INTEL_BUS_CLK), + { NULL, 0, 0, NULL }, +}; + +static void est_identify(driver_t *driver, device_t parent); +static int est_probe(device_t parent); +static int est_attach(device_t parent); +static int est_detach(device_t parent); +static int est_find_cpu(const char *vendor, uint64_t msr, uint32_t bus_clk, + const freq_info **freqs); +static const freq_info *est_get_current(const freq_info *freq_list); +static int est_settings(device_t dev, struct cf_setting *sets, int *count); +static int est_set(device_t dev, const struct cf_setting *set); +static int est_get(device_t dev, struct cf_setting *set); +static int est_type(device_t dev, int *type); + +static device_method_t est_methods[] = { + /* Device interface */ + DEVMETHOD(device_identify, est_identify), + DEVMETHOD(device_probe, est_probe), + DEVMETHOD(device_attach, est_attach), + DEVMETHOD(device_detach, est_detach), + + /* cpufreq interface */ + DEVMETHOD(cpufreq_drv_set, est_set), + DEVMETHOD(cpufreq_drv_get, est_get), + DEVMETHOD(cpufreq_drv_type, est_type), + DEVMETHOD(cpufreq_drv_settings, est_settings), + {0, 0} +}; + +static driver_t est_driver = { + "est", + est_methods, + sizeof(struct est_softc), +}; + +static devclass_t est_devclass; +DRIVER_MODULE(est, cpu, est_driver, est_devclass, 0, 0); + +static void +est_identify(driver_t *driver, device_t parent) +{ + u_int p[4]; + + /* + * XXX If we're not on cpu 0, don't add a child. We should add + * MP support instead. + */ + if (device_get_unit(parent) != 0) + return; + + /* Make sure we're not being doubly invoked. */ + if (device_find_child(parent, "est", -1) != NULL) + return; + + /* Check that CPUID is supported and the vendor is Intel.*/ + if (cpu_high == 0 || strcmp(cpu_vendor, GenuineIntel) != 0) + return; + + /* Read capability bits and check if the CPU supports EST. */ + do_cpuid(1, p); + if ((p[2] & 0x80) == 0) + return; + + if (BUS_ADD_CHILD(parent, 0, "est", -1) == NULL) + device_printf(parent, "add est child failed\n"); +} + +static int +est_probe(device_t dev) +{ + const freq_info *f; + device_t perf_dev; + uint64_t msr; + int error, type; + + /* + * If the ACPI perf driver has attached and is not just offering + * info, let it manage things. + */ + perf_dev = device_find_child(device_get_parent(dev), "acpi_perf", -1); + if (perf_dev && device_is_attached(perf_dev)) { + error = CPUFREQ_DRV_TYPE(perf_dev, &type); + if (error == 0 && (type & CPUFREQ_FLAG_INFO_ONLY) == 0) + return (ENXIO); + } + + /* Attempt to enable SpeedStep if not currently enabled. */ + msr = rdmsr(MSR_MISC_ENABLE); + if ((msr & MSR_SS_ENABLE) == 0) { + msr |= MSR_SS_ENABLE; + wrmsr(MSR_MISC_ENABLE, msr); + + /* Check if the enable failed. */ + msr = rdmsr(MSR_MISC_ENABLE); + if ((msr & MSR_SS_ENABLE) == 0) { + device_printf(dev, "failed to enable SpeedStep\n"); + return (ENXIO); + } + } + + /* Identify the exact CPU model */ + msr = rdmsr(MSR_PERF_STATUS); + if (est_find_cpu(cpu_vendor, msr, INTEL_BUS_CLK, &f) != 0) { + printf( + "CPU claims to support Enhanced Speedstep, but is not recognized.\n" + "Please update driver or contact the maintainer.\n" + "cpu_vendor = %s msr = %0jx, bus_clk = %x\n", + cpu_vendor, msr, INTEL_BUS_CLK); + return (ENXIO); + } + + device_set_desc(dev, "Enhanced SpeedStep Frequency Control"); + return (0); +} + +static int +est_attach(device_t dev) +{ + struct est_softc *sc; + uint64_t msr; + + sc = device_get_softc(dev); + sc->dev = dev; + msr = rdmsr(MSR_PERF_STATUS); + est_find_cpu(cpu_vendor, msr, INTEL_BUS_CLK, &sc->freq_list); + cpufreq_register(dev); + + return (0); +} + +static int +est_detach(device_t dev) +{ + return (ENXIO); +} + +static int +est_find_cpu(const char *vendor, uint64_t msr, uint32_t bus_clk, + const freq_info **freqs) +{ + const cpu_info *p; + uint32_t id; + + /* Find a table which matches (vendor, id, bus_clk). */ + id = msr >> 32; + for (p = ESTprocs; p->id32 != 0; p++) { + if (strcmp(p->vendor, vendor) == 0 && p->id32 == id && + p->bus_clk == bus_clk) + break; + } + if (p->id32 == 0) + return (EOPNOTSUPP); + + /* Make sure the current setpoint is valid. */ + if (est_get_current(p->freqtab) == NULL) + return (EOPNOTSUPP); + + *freqs = p->freqtab; + return (0); +} + +static const freq_info * +est_get_current(const freq_info *freq_list) +{ + const freq_info *f; + int i; + uint16_t id16; + + /* + * Try a few times to get a valid value. Sometimes, if the CPU + * is in the middle of an asynchronous transition (i.e., P4TCC), + * we get a temporary invalid result. + */ + for (i = 0; i < 5; i++) { + id16 = rdmsr(MSR_PERF_STATUS) & 0xffff; + for (f = freq_list; f->id16 != 0; f++) { + if (f->id16 == id16) + return (f); + } + } + return (NULL); +} + +static int +est_settings(device_t dev, struct cf_setting *sets, int *count) +{ + struct est_softc *sc; + const freq_info *f; + int i; + + if (*count < EST_MAX_SETTINGS) + return (E2BIG); + + i = 0; + for (f = sc->freq_list; f->freq != 0; f++) { + sets[i].freq = f->freq; + sets[i].volts = f->volts; + sets[i].power = CPUFREQ_VAL_UNKNOWN; + sets[i].lat = EST_TRANS_LAT; + sets[i].dev = dev; + i++; + } + *count = i + 1; + + return (0); +} + +static int +est_set(device_t dev, const struct cf_setting *set) +{ + struct est_softc *sc; + const freq_info *f; + uint64_t msr; + + /* Find the setting matching the requested one. */ + sc = device_get_softc(dev); + for (f = sc->freq_list; f->freq != 0; f++) { + if (f->freq == set->freq) + break; + } + if (f->freq == 0) + return (EINVAL); + + /* Read the current register, mask out the old, set the new id. */ + msr = rdmsr(MSR_PERF_CTL); + msr = (msr & ~0xffffLL) | f->id16; + wrmsr(MSR_PERF_CTL, msr); + + return (0); +} + +static int +est_get(device_t dev, struct cf_setting *set) +{ + struct est_softc *sc; + const freq_info *f; + + sc = device_get_softc(dev); + f = est_get_current(sc->freq_list); + if (f == NULL) + return (ENXIO); + + set->freq = f->freq; + set->volts = f->volts; + set->power = CPUFREQ_VAL_UNKNOWN; + set->lat = EST_TRANS_LAT; + set->dev = dev; + return (0); +} + +static int +est_type(device_t dev, int *type) +{ + + if (type == NULL) + return (EINVAL); + + *type = CPUFREQ_TYPE_ABSOLUTE; + return (0); +} Index: i386/cpufreq/p4tcc.c =================================================================== RCS file: i386/cpufreq/p4tcc.c diff -N i386/cpufreq/p4tcc.c --- /dev/null 1 Jan 1970 00:00:00 -0000 +++ i386/cpufreq/p4tcc.c 18 Feb 2005 00:05:53 -0000 @@ -0,0 +1,259 @@ +/*- + * Copyright (c) 2003 Ted Unangst + * Copyright (c) 2004 Maxim Sobolev + * Copyright (c) 2005 Nate Lawson + * All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * + * THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR + * IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES + * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. + * IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, + * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, + * BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; + * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED + * AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, + * OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * SUCH DAMAGE. + */ + +/* + * Throttle clock frequency by using the thermal control circuit. This + * operates independently of SpeedStep and ACPI throttling and is supported + * on Pentium 4 and later models (feature TM). + * + * Reference: Intel Developer's manual v.3 #245472-012 + */ + +#include +__FBSDID("$FreeBSD$"); + +#include +#include +#include +#include +#include +#include + +#include +#include + +#include "cpufreq_if.h" + +struct p4tcc_softc { + device_t dev; + int set_count; +}; + +#define TCC_NUM_SETTINGS 8 + +#define TCC_ENABLE_BIT (1<<4) +#define TCC_REG_OFFSET 1 +#define TCC_SPEED_PERCENT(x) ((10000 * (x)) / TCC_NUM_SETTINGS) + +static void p4tcc_identify(driver_t *driver, device_t parent); +static int p4tcc_probe(device_t dev); +static int p4tcc_attach(device_t dev); +static int p4tcc_settings(device_t dev, struct cf_setting *sets, + int *count); +static int p4tcc_set(device_t dev, const struct cf_setting *set); +static int p4tcc_get(device_t dev, struct cf_setting *set); +static int p4tcc_type(device_t dev, int *type); + +static device_method_t p4tcc_methods[] = { + /* Device interface */ + DEVMETHOD(device_identify, p4tcc_identify), + DEVMETHOD(device_probe, p4tcc_probe), + DEVMETHOD(device_attach, p4tcc_attach), + + /* cpufreq interface */ + DEVMETHOD(cpufreq_drv_set, p4tcc_set), + DEVMETHOD(cpufreq_drv_get, p4tcc_get), + DEVMETHOD(cpufreq_drv_type, p4tcc_type), + DEVMETHOD(cpufreq_drv_settings, p4tcc_settings), + {0, 0} +}; + +static driver_t p4tcc_driver = { + "p4tcc", + p4tcc_methods, + sizeof(struct p4tcc_softc), +}; + +static devclass_t p4tcc_devclass; +DRIVER_MODULE(p4tcc, cpu, p4tcc_driver, p4tcc_devclass, 0, 0); + +static void +p4tcc_identify(driver_t *driver, device_t parent) +{ + + if ((cpu_feature & (CPUID_ACPI | CPUID_TM)) != (CPUID_ACPI | CPUID_TM)) + return; + if (BUS_ADD_CHILD(parent, 0, "p4tcc", -1) == NULL) + device_printf(parent, "add p4tcc child failed\n"); +} + +static int +p4tcc_probe(device_t dev) +{ + + device_set_desc(dev, "CPU Frequency Thermal Control"); + return (0); +} + +static int +p4tcc_attach(device_t dev) +{ + struct p4tcc_softc *sc; + struct cf_setting set; + + sc = device_get_softc(dev); + sc->dev = dev; + sc->set_count = TCC_NUM_SETTINGS; + + switch (cpu_id & 0xf) { + case 0x22: + case 0x24: + case 0x25: + case 0x27: + case 0x29: + /* + * These CPU models hang when set to 12.5%. + * See Errata O50, P44, and Z21. + */ + sc->set_count -= 1; + break; + case 0x07: /* errata N44 and P18 */ + case 0x0a: + case 0x12: + case 0x13: + /* + * These CPU models hang when set to 12.5% or 25%. + * See Errata N44 and P18l. + */ + sc->set_count -= 2; + break; + } + + /* + * On boot, the TCC is usually in Automatic mode where reading the + * current performance level is likely to produce bogus results. + * We switch it to On-Demand mode and set a known performance level + * to avoid ambiguity. Unfortunately, there is no reliable way to + * check that TCC is in the Automatic mode. Reading bit 4 of ACPI + * Thermal Monitor Control Register produces 0 no matter what the + * current mode. + */ + set.freq = 10000; + set.dev = dev; + CPUFREQ_DRV_SET(dev, &set); + + cpufreq_register(dev); + return (0); +} + +static int +p4tcc_settings(device_t dev, struct cf_setting *sets, int *count) +{ + struct p4tcc_softc *sc; + int i, val; + + sc = device_get_softc(dev); + if (sets == NULL || count == NULL) + return (EINVAL); + if (*count < sc->set_count) + return (E2BIG); + + /* Return a list of valid settings for this driver. */ + memset(sets, CPUFREQ_VAL_UNKNOWN, sizeof(*sets) * sc->set_count); + for (i = 0, val = sc->set_count; val != 0; i++, val--) { + sets[i].freq = TCC_SPEED_PERCENT(val); + sets[i].dev = dev; + } + *count = sc->set_count; + + return (0); +} + +static int +p4tcc_set(device_t dev, const struct cf_setting *set) +{ + struct p4tcc_softc *sc; + uint64_t mask, msr; + int val; + + if (set == NULL) + return (EINVAL); + sc = device_get_softc(dev); + + /* + * Validate requested state converts to a setting that is an + * integer from [1 .. sc->set_count]. + */ + val = set->freq * sc->set_count / 10000; + if (val * 10000 != set->freq * sc->set_count || + val < 1 || val > sc->set_count) + return (EINVAL); + + /* Convert a setting of TCC_NUM_SETTINGS to 0. */ + if (val == TCC_NUM_SETTINGS) + val = 0; + + /* + * Read the current register and mask off the old setting/enable bit. + * If the new val is nonzero, set it and the enable bit. Finally, + * write the new register. + */ + msr = rdmsr(MSR_THERM_CONTROL); + mask = (TCC_NUM_SETTINGS - 1) << TCC_REG_OFFSET; + msr &= ~(mask | TCC_ENABLE_BIT); + if (val) + msr |= (val << TCC_REG_OFFSET) | TCC_ENABLE_BIT; + wrmsr(MSR_THERM_CONTROL, msr); + + return (0); +} + +static int +p4tcc_get(device_t dev, struct cf_setting *set) +{ + uint64_t msr; + int val; + + if (set == NULL) + return (EINVAL); + + /* Read the current register and extract the current setting. */ + msr = rdmsr(MSR_THERM_CONTROL); + val = (msr >> TCC_REG_OFFSET) & (TCC_NUM_SETTINGS - 1); + + /* Convert a setting of 0 to TCC_NUM_SETTINGS. */ + if (val == 0) + val = TCC_NUM_SETTINGS; + + memset(set, CPUFREQ_VAL_UNKNOWN, sizeof(*set)); + set->freq = TCC_SPEED_PERCENT(val); + set->dev = dev; + + return (0); +} + +static int +p4tcc_type(device_t dev, int *type) +{ + + if (type == NULL) + return (EINVAL); + + *type = CPUFREQ_TYPE_RELATIVE; + return (0); +} --------------090907050404050609010507-- From owner-freebsd-acpi@FreeBSD.ORG Fri Feb 18 03:24:15 2005 Return-Path: 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 AAFE516A4CE; Fri, 18 Feb 2005 03:24:15 +0000 (GMT) Received: from pne-smtpout1-sn2.hy.skanova.net (pne-smtpout1-sn2.hy.skanova.net [81.228.8.83]) by mx1.FreeBSD.org (Postfix) with ESMTP id 32F3843D41; Fri, 18 Feb 2005 03:24:15 +0000 (GMT) (envelope-from pawel.worach@telia.com) Received: from [127.0.0.1] (81.225.14.129) by pne-smtpout1-sn2.hy.skanova.net (7.1.026.7) (authenticated as u86211448) id 41E32167005DE136; Fri, 18 Feb 2005 04:23:43 +0100 Message-ID: <42155FBD.5050701@telia.com> Date: Fri, 18 Feb 2005 04:23:41 +0100 From: Pawel Worach User-Agent: Mozilla Thunderbird 1.0 (X11/20050214) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Nate Lawson References: <4213F066.2050708@root.org> <4214119B.2010909@telia.com> <421537E9.8050203@root.org> In-Reply-To: <421537E9.8050203@root.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: acpi@freebsd.org cc: current@freebsd.org Subject: Re: patch: p4tcc and speedstep cpufreq drivers X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Feb 2005 03:24:15 -0000 Nate Lawson wrote: > > Apologies. I found 2 bugs, one was not calling cpufreq_register() and > the other was that the code to detect acpi_perf (in ichss and est) was > incorrect. I've committed fixes for that and have updated the patch. > Please ues this version and test again. > On boot pre-seed PRNG does 'sysctl -a' which panics like this. - only cpufreq.ko loaded - last line of 'sysctl -a' output is "dev.cpu.0.%parent: acpi0" Fatal trap 12: page fault while in kernel mode fault virtual address = 0x63204b53 fault code = supervisor read, page not present instruction pointer = 0x8:0xc08ac32b stack pointer = 0x10:0xe4d38ab8 frame pointer = 0x10:0xe4d38ac4 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 56 (sysctl) [thread pid 56 tid 100043 ] Stopped at est_settings+0x1b: movzwl 0(%ecx),%eax db> tr Tracing pid 56 tid 100043 td 0xc2329450 est_settings(c2367880,c23c2e00,e4d38af4,c231b800,c23c2e00) at est_settings+0x1b cf_levels_method(c2367980,c2590000,e4d38b50,5000,1) at cf_levels_method+0x18a cf_get_method(c2367980,c258b000,c06d2c98,1,c228b960) at cf_get_method+0xb5 cpufreq_curr_sysctl(c236c740,c231b800,0,e4d38c08,e4d38c08) at cpufreq_curr_sysctl+0x96 sysctl_root(0,e4d38c78,4,e4d38c08,c2329450) at sysctl_root+0x134 userland_sysctl(c2329450,e4d38c78,4,0,bfbfdbac) at userland_sysctl+0x13c __sysctl(c2329450,e4d38d14,18,0,e4d38d20) at __sysctl+0xdc syscall(2f,2f,2f,bfbfdbac,bfbfe470) at syscall+0x330 Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall (202, FreeBSD ELF32, __sysctl), eip = 0x280bdc3f, esp = 0xbfbfdb2c, ebp = 0xbfbfdb58 --- db> call doadump Dumping 1023 MB 16 32 48 64 80 96 112 128 144 160 176 192 208 224 240 256 272 288 304 320 336 352 368 384 400 416 432 448 464 480 496 512 528 544 560 576 592 608 624 640 656 672 688 704 720 736 752 768 784 800 816 832 848 864 880 896 912 928 944 960 976 992 1008 (kgdb) l *est_settings+0x1b 0x243b is in est_settings (/usr/src/sys/modules/cpufreq/../../i386/cpufreq/est.c:723). 718 719 if (*count < EST_MAX_SETTINGS) 720 return (E2BIG); 721 722 i = 0; 723 for (f = sc->freq_list; f->freq != 0; f++) { 724 sets[i].freq = f->freq; 725 sets[i].volts = f->volts; 726 sets[i].power = CPUFREQ_VAL_UNKNOWN; 727 sets[i].lat = EST_TRANS_LAT; -- Pawel From owner-freebsd-acpi@FreeBSD.ORG Fri Feb 18 07:58:51 2005 Return-Path: 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 3C83016A4CE; Fri, 18 Feb 2005 07:58:51 +0000 (GMT) Received: from svm.csie.ntu.edu.tw (svm.csie.ntu.edu.tw [140.112.90.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 89E1743D39; Fri, 18 Feb 2005 07:58:49 +0000 (GMT) (envelope-from rafan@svm.csie.ntu.edu.tw) Received: from svm.csie.ntu.edu.tw (localhost [127.0.0.1]) by svm.csie.ntu.edu.tw (8.13.1/8.13.1) with ESMTP id j1I7wmMD042399; Fri, 18 Feb 2005 15:58:48 +0800 (CST) (envelope-from rafan@svm.csie.ntu.edu.tw) Received: (from rafan@localhost) by svm.csie.ntu.edu.tw (8.13.1/8.13.1/Submit) id j1I7whUd042398; Fri, 18 Feb 2005 15:58:43 +0800 (CST) (envelope-from rafan) Date: Fri, 18 Feb 2005 15:58:43 +0800 From: Rong-En Fan To: Nate Lawson Message-ID: <20050218075843.GA42365@svm.csie.ntu.edu.tw> References: <4213F066.2050708@root.org> <4214119B.2010909@telia.com> <421537E9.8050203@root.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <421537E9.8050203@root.org> User-Agent: Mutt/1.5.7i cc: acpi@freebsd.org cc: current@freebsd.org Subject: Re: patch: p4tcc and speedstep cpufreq drivers X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Feb 2005 07:58:51 -0000 On Thu, Feb 17, 2005 at 04:33:45PM -0800, Nate Lawson wrote: > Pawel Worach wrote: > >Nate Lawson wrote: > > > >>Attached is a patch that I'd like to get tested. After applying it, > >>rebuild and load the cpufreq.ko module. Be sure you do _not_ have > >>"options CPU_ENABLE_TCC" in your kernel config or the new driver will > >>conflict with the old. > > > > > >Hi Nate, > > > >This is what I get on a TP T41, do the cpufreq results below look right? > >Also if I loaded both modules all I got for dev.cpu.0.freq was -1 or > >1700 and no levels. > > > >CPU: Intel(R) Pentium(R) M processor 1700MHz (1698.56-MHz 686-class CPU) > > Origin = "GenuineIntel" Id = 0x695 Stepping = 5 > >Features=0xa7e9f9bf > > Apologies. I found 2 bugs, one was not calling cpufreq_register() and > the other was that the code to detect acpi_perf (in ichss and est) was > incorrect. I've committed fixes for that and have updated the patch. > Please ues this version and test again. Hi, This is an TP X31. CPU: Intel(R) Pentium(R) M processor 1400MHz (1398.82-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x695 Stepping = 5 Features=0xa7e9f9bf freq_levels looks strange.. and changes... (only cpufreq is loaded at boot) rafan@woodstock|UTF-8 [~] (15:57)$ sysctl dev.cpu dev.cpu.0.%desc: ACPI CPU (3 Cx states) dev.cpu.0.%driver: cpu dev.cpu.0.%location: handle=\_PR_.CPU_ dev.cpu.0.%pnpinfo: _HID=none _UID=0 dev.cpu.0.%parent: acpi0 dev.cpu.0.freq: 1399 dev.cpu.0.freq_levels: -738340620/0 0/0 0/0 rafan@woodstock|UTF-8 [~] (15:57)$ sysctl dev.cpu dev.cpu.0.%desc: ACPI CPU (3 Cx states) dev.cpu.0.%driver: cpu dev.cpu.0.%location: handle=\_PR_.CPU_ dev.cpu.0.%pnpinfo: _HID=none _UID=0 dev.cpu.0.%parent: acpi0 dev.cpu.0.freq: 1399 dev.cpu.0.freq_levels: 1398/-1 1398/-1 0/0 rafan@woodstock|UTF-8 [~] (15:57)$ sysctl dev.cpu dev.cpu.0.%desc: ACPI CPU (3 Cx states) dev.cpu.0.%driver: cpu dev.cpu.0.%location: handle=\_PR_.CPU_ dev.cpu.0.%pnpinfo: _HID=none _UID=0 dev.cpu.0.%parent: acpi0 dev.cpu.0.freq: 1399 dev.cpu.0.freq_levels: 1398/-1 1398/-1 0/0 Regarad, Rong-En Fan From owner-freebsd-acpi@FreeBSD.ORG Fri Feb 18 17:07:00 2005 Return-Path: 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 B1D9016A4CE for ; Fri, 18 Feb 2005 17:07:00 +0000 (GMT) Received: from mailtest.sd73.bc.ca (smtp.sd73.bc.ca [142.24.13.149]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6335043D41 for ; Fri, 18 Feb 2005 17:07:00 +0000 (GMT) (envelope-from fcash-ml@sd73.bc.ca) Received: from localhost (localhost [127.0.0.1]) by mailtest.sd73.bc.ca (Postfix) with ESMTP id A0081F186F for ; Fri, 18 Feb 2005 09:07:00 -0800 (PST) Received: from mailtest.sd73.bc.ca ([127.0.0.1]) by localhost (mailtest.sd73.bc.ca [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 32357-01-21 for ; Fri, 18 Feb 2005 09:06:59 -0800 (PST) Received: from s9.sbo (s9.sbo [192.168.0.9]) by mailtest.sd73.bc.ca (Postfix) with ESMTP id E3EE4F1819 for ; Fri, 18 Feb 2005 09:06:59 -0800 (PST) From: Freddie Cash Organization: School District 73 - Kamloops, BC Date: Fri, 18 Feb 2005 09:06:59 -0800 User-Agent: KMail/1.7.2 To: acpi@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200502180906.59414.fcash-ml@sd73.bc.ca> X-Virus-Scanned: by amavisd-new using ClamAV at sd73.bc.ca Subject: Re: patch: p4tcc and speedstep cpufreq drivers X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Feb 2005 17:07:00 -0000 On February 17, 2005 04:33 pm, Nate Lawson wrote: > Apologies. I found 2 bugs, one was not calling cpufreq_register() > and the other was that the code to detect acpi_perf (in ichss and > est) was incorrect. I've committed fixes for that and have updated > the patch. Please ues this version and test again. Unfortunately, it still doesn't do anything on this laptop. :( Toshiba Satellite A60, BIOS 1.80C CPU: Intel(R) Celeron(R) CPU 2.80GHz (2800.11-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0xf29 Stepping = 9 Features=0xbfebfbff ACPI APIC Table: Without CPU_ENABLE_TCC in the kernel, nothing shows up in sysctl relating to frequency levels, p4tcc, or throttling. :( Doesn't matter if acpi_perf or cpufreq is installed or not. There's also no console messages from loading the module(s). And no changes in the number of sysctls available. -- Freddie Cash, CCNT CCLP Helpdesk / Network Support Tech. School District 73 (250) 377-HELP [377-4357] fcash-ml@sd73.bc.ca -- Freddie Cash, CCNT CCLP Helpdesk / Network Support Tech. School District 73 (250) 377-HELP [377-4357] fcash-ml@sd73.bc.ca From owner-freebsd-acpi@FreeBSD.ORG Fri Feb 18 17:52:32 2005 Return-Path: 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 E33B216A4D1 for ; Fri, 18 Feb 2005 17:52:32 +0000 (GMT) Received: from smtprelay04.ispgateway.de (smtprelay04.ispgateway.de [80.67.18.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 07A4743D46 for ; Fri, 18 Feb 2005 17:52:31 +0000 (GMT) (envelope-from dady0815@web.de) Received: (qmail 11431 invoked from network); 18 Feb 2005 17:52:30 -0000 Received: from unknown (HELO localhost) (527118@[84.56.8.250]) (envelope-sender ) by smtprelay04.ispgateway.de (qmail-ldap-1.03) with SMTP for ; 18 Feb 2005 17:52:30 -0000 From: Tobias Grosser To: acpi@freebsd.org, current@freebsd.org In-Reply-To: <421537E9.8050203@root.org> References: <4213F066.2050708@root.org> <4214119B.2010909@telia.com> <421537E9.8050203@root.org> Content-Type: multipart/mixed; boundary="=-n7uDlthGdslTLvtFaWcW" Date: Fri, 18 Feb 2005 18:51:57 +0100 Message-Id: <1108749117.981.1.camel@tobias.home.web-wahnsinn.de> Mime-Version: 1.0 X-Mailer: Evolution 2.0.3 FreeBSD GNOME Team Port Subject: Re: patch: p4tcc and speedstep cpufreq drivers X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Feb 2005 17:52:33 -0000 --=-n7uDlthGdslTLvtFaWcW Content-Type: text/plain Content-Transfer-Encoding: 7bit Hi, i tried your patch on my IBM Thinkpad T41p. Unfortunately it doesn't work very well. But I would like it to do so I offer my help. ;-) 1. If I put acpi_perf_load="YES" before cpufreq_load="YES" in my loader.conf everything boots fine. If I change the order and cpufreq_load is first, my kernel crashes. I copyed last lines of the screen for you: -------------------------------------------------------------------- Pre-seeding: PRNG: acpi_ec0: info: new max delay is 70 us Fatal trap 12 = page fault while in kernel mode fault virtual address = 0x458b0d74 fault code = supervisor read, page not present instruction pointer = 0x8:0xc0866429 stack pointer = 0x10:0xe6652ad4 frame pointer = 0x10:0xe6652ae4 code segment = base 0x0, limit dxfffff, = DPC 0, pres 1, def32, gran 1 processor flags = interrupt enabled, resume, IOPL = 0 current process = 62 sysctl trap number = 12 panic: page fault -------------------------------------------------------------------- sysctl.conf -------------------------------------------------------------------- hw.snd.pcm0.vchans=4 hw.ath.outdoor=0 dev.ath.0.rate_interval=200 -------------------------------------------------------------------- loader.conf -------------------------------------------------------------------- ath_hal_load="YES" hw.ath.outdoor="0" ath_rate_load="YES" if_ath_load="YES" wlan_wep_load="YES" autoboot_delay="1" #ng_ubt_load="YES" hw.ata.wc="0" hw.snd.pcm0.vchans="4" hw.acpi.verbose="1" acpi_ibm_load="YES" cpufreq_load="YES" acpi_perf_load="YES" -------------------------------------------------------------------- 2. My dev.cpu sysctl shows not very much with this new patch: with patch: "sysctl dev.cpu" -------------------------------------------------------------------- dev.cpu.0.%desc: ACPI CPU (3 Cx states) dev.cpu.0.%driver: cpu dev.cpu.0.%location: handle=\_PR_.CPU_ dev.cpu.0.%pnpinfo: _HID=none _UID=0 dev.cpu.0.%parent: acpi0 dev.cpu.0.freq: -1 -------------------------------------------------------------------- without patch: "sysctl dev.cpu" -------------------------------------------------------------------- dev.cpu.0.%desc: ACPI CPU (3 Cx states) dev.cpu.0.%driver: cpu dev.cpu.0.%location: handle=\_PR_.CPU_ dev.cpu.0.%pnpinfo: _HID=none _UID=0 dev.cpu.0.%parent: acpi0 dev.cpu.0.freq: 1700 dev.cpu.0.freq_levels: 1700/24500 1487/21437 1400/19500 1275/18375 1225/17062 12 00/16000 1062/15312 1000/13000 900/12000 875/12187 850/12250 800/9500 750/10000 700/9750 637/9187 600/6000 525/7312 500/6500 450/6000 425/6125 400/4750 375/4875 350/4875 300/4000 250/3250 212/3062 175/2437 150/2000 125/1625 100/1187 75/750 -------------------------------------------------------------------- 3. Since always my CPU gets different numbers of Cx states, if connected to power during boot or not. 3 states with power 4 without. The number of the states doesn't change, if I plug or unplug the power connection. 4. One question. Under Windows my battery should reach about 4.7 hrs under FBSD i reached about 3 hrs with est. Will your new patches change the BSD values? Sincerly Tobias --=-n7uDlthGdslTLvtFaWcW Content-Disposition: attachment; filename=dmesg_with_patch Content-Type: text/plain; name=dmesg_with_patch; charset=UTF-8 Content-Transfer-Encoding: 7bit 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 6.0-CURRENT #12: Fri Feb 18 17:58:01 CET 2005 root@tobias.home.web-wahnsinn.de:/usr/obj/usr/src/sys/MYKERNEL WARNING: debug.mpsafenet forced to 0 as ipsec requires Giant WARNING: MPSAFE network stack disabled, expect reduced performance. Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Pentium(R) M processor 1700MHz (1694.51-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x695 Stepping = 5 Features=0xa7e9f9bf real memory = 536215552 (511 MB) avail memory = 515444736 (491 MB) ath_hal: 0.9.14.9 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413) npx0: [FAST] npx0: on motherboard npx0: INT 16 interface acpi0: on motherboard acpi_ec0: port 0x66,0x62 on acpi0 acpi0: Power Button (fixed) Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 cpu0: on acpi0 acpi_perf0: on cpu0 acpi_throttle0: on cpu0 p4tcc0: on cpu0 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: on acpi0 pci_link5: on acpi0 pci_link6: on acpi0 pci_link7: irq 11 on acpi0 acpi_lid0: on acpi0 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 agp0: mem 0xd0000000-0xdfffffff at device 0.0 on pci0 pcib1: at device 1.0 on pci0 pci1: on pcib1 pci1: at device 0.0 (no driver attached) pci0: at device 29.0 (no driver attached) pci0: at device 29.1 (no driver attached) pci0: at device 29.2 (no driver attached) pci0: at device 29.7 (no driver attached) pcib2: at device 30.0 on pci0 pci2: on pcib2 cbb0: mem 0xb0000000-0xb0000fff irq 11 at device 0.0 on pci2 cardbus0: on cbb0 pccard0: <16-bit PCCard bus> on cbb0 cbb1: mem 0xb1000000-0xb1000fff irq 11 at device 0.1 on pci2 cardbus1: on cbb1 pccard1: <16-bit PCCard bus> on cbb1 em0: port 0x8000-0x803f mem 0xc0200000-0xc020ffff,0xc0220000-0xc023ffff irq 11 at device 1.0 on pci2 em0: [GIANT-LOCKED] em0: Ethernet address: 00:0d:60:f9:2a:44 em0: Speed:N/A Duplex:N/A ath0: mem 0xc0210000-0xc021ffff irq 11 at device 2.0 on pci2 ath0: [GIANT-LOCKED] ath0: Ethernet address: 00:05:4e:4a:49:ae ath0: mac 5.6 phy 4.1 5ghz radio 1.7 2ghz radio 2.3 ichss: enabling SpeedStep support isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1860-0x186f,0x376,0x170-0x177,0x3f6,0x1f0-0x1f7 at device 31.1 on pci0 ata0: channel #0 on atapci0 ata1: channel #1 on atapci0 pci0: at device 31.3 (no driver attached) pcm0: port 0x18c0-0x18ff,0x1c00-0x1cff mem 0xc0000800-0xc00008ff,0xc0000c00-0xc0000dff irq 11 at device 31.5 on pci0 pcm0: [GIANT-LOCKED] pcm0: pci0: at device 31.6 (no driver attached) acpi_tz0: on acpi0 atkbdc0: port 0x64,0x60 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: model Generic PS/2 mouse, device ID 0 sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 8250 or not responding sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled acpi_ec0: info: new max delay is 60 us acpi_cmbat0: on acpi0 acpi_acad0: on acpi0 acpi_ibm0: on acpi0 acpi_ibm0: Version 100 acpi_ibm0: Available Mask 9dc acpi_ibm0: Initial Mask 80c sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled pmtimer0 on isa0 ppc0: parallel port not found. 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 1694509693 Hz quality 800 Timecounters tick every 1.000 msec IPsec: Initialized Security Association Processing. acpi_cmbat0: battery initialization start acpi_cmbat0: battery initialization done, tried 1 times acpi_acad0: acline initialization start acpi_acad0: On Line acpi_acad0: acline initialization done, tried 1 times ad0: 57231MB [116280/16/63] at ata0-master UDMA100 acd0: CDRW at ata1-master UDMA33 cd0 at ata1 bus 0 target 0 lun 0 cd0: Removable CD-ROM SCSI-0 device cd0: 33.000MB/s transfers cd0: Attempt to query device size failed: NOT READY, Medium not present Trying to mount root from ufs:/dev/ad0s1a WARNING: / was not properly dismounted WARNING: /usr was not properly dismounted WARNING: /var was not properly dismounted acpi_ec0: info: new max delay is 70 us acpi_ec0: info: new max delay is 230 us acpi_ec0: info: new max delay is 290 us --=-n7uDlthGdslTLvtFaWcW Content-Disposition: attachment; filename=dmesg_without_patch Content-Type: text/plain; name=dmesg_without_patch; charset=UTF-8 Content-Transfer-Encoding: 7bit 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 6.0-CURRENT #10: Mon Feb 14 13:33:08 CET 2005 root@tobias.home.web-wahnsinn.de:/usr/obj/usr/src/sys/MYKERNEL WARNING: debug.mpsafenet forced to 0 as ipsec requires Giant WARNING: MPSAFE network stack disabled, expect reduced performance. link_elf: symbol cpufreq_drv_type_desc undefined KLD file cpufreq.ko - could not finalize loading Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Pentium(R) M processor 1700MHz (1694.51-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x695 Stepping = 5 Features=0xa7e9f9bf real memory = 536215552 (511 MB) avail memory = 515448832 (491 MB) ath_hal: 0.9.14.9 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413) npx0: [FAST] npx0: on motherboard npx0: INT 16 interface acpi0: on motherboard acpi_ec0: port 0x66,0x62 on acpi0 acpi0: Power Button (fixed) acpi_ec0: info: new max delay is 60 us Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 cpu0: on acpi0 acpi_perf0: on cpu0 acpi_throttle0: on cpu0 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: on acpi0 pci_link5: on acpi0 pci_link6: on acpi0 pci_link7: irq 11 on acpi0 acpi_lid0: on acpi0 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 agp0: mem 0xd0000000-0xdfffffff at device 0.0 on pci0 pcib1: at device 1.0 on pci0 pci1: on pcib1 pci1: at device 0.0 (no driver attached) pci0: at device 29.0 (no driver attached) pci0: at device 29.1 (no driver attached) pci0: at device 29.2 (no driver attached) pci0: at device 29.7 (no driver attached) pcib2: at device 30.0 on pci0 pci2: on pcib2 cbb0: mem 0xb0000000-0xb0000fff irq 11 at device 0.0 on pci2 cardbus0: on cbb0 pccard0: <16-bit PCCard bus> on cbb0 cbb1: mem 0xb1000000-0xb1000fff irq 11 at device 0.1 on pci2 cardbus1: on cbb1 pccard1: <16-bit PCCard bus> on cbb1 em0: port 0x8000-0x803f mem 0xc0200000-0xc020ffff,0xc0220000-0xc023ffff irq 11 at device 1.0 on pci2 em0: [GIANT-LOCKED] em0: Ethernet address: 00:0d:60:f9:2a:44 em0: Speed:N/A Duplex:N/A ath0: mem 0xc0210000-0xc021ffff irq 11 at device 2.0 on pci2 ath0: [GIANT-LOCKED] ath0: Ethernet address: 00:05:4e:4a:49:ae ath0: mac 5.6 phy 4.1 5ghz radio 1.7 2ghz radio 2.3 isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1860-0x186f,0x376,0x170-0x177,0x3f6,0x1f0-0x1f7 at device 31.1 on pci0 ata0: channel #0 on atapci0 ata1: channel #1 on atapci0 pci0: at device 31.3 (no driver attached) pcm0: port 0x18c0-0x18ff,0x1c00-0x1cff mem 0xc0000800-0xc00008ff,0xc0000c00-0xc0000dff irq 11 at device 31.5 on pci0 pcm0: [GIANT-LOCKED] pcm0: pci0: at device 31.6 (no driver attached) acpi_tz0: on acpi0 atkbdc0: port 0x64,0x60 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: model Generic PS/2 mouse, device ID 0 sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 8250 or not responding sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled acpi_cmbat0: on acpi0 acpi_acad0: on acpi0 acpi_ibm0: on acpi0 acpi_ibm0: Version 100 acpi_ibm0: Available Mask 9dc acpi_ibm0: Initial Mask 80c sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled pmtimer0 on isa0 ppc0: parallel port not found. 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 1694509531 Hz quality 800 Timecounters tick every 1.000 msec IPsec: Initialized Security Association Processing. acpi_cmbat0: battery initialization start acpi_ec0: info: new max delay is 70 us acpi_cmbat0: battery initialization done, tried 1 times acpi_acad0: acline initialization start acpi_acad0: On Line acpi_acad0: acline initialization done, tried 1 times ad0: 57231MB [116280/16/63] at ata0-master UDMA100 acd0: CDRW at ata1-master UDMA33 cd0 at ata1 bus 0 target 0 lun 0 cd0: Removable CD-ROM SCSI-0 device cd0: 33.000MB/s transfers cd0: Attempt to query device size failed: NOT READY, Medium not present Trying to mount root from ufs:/dev/ad0s1a acpi_ec0: info: new max delay is 100 us acpi_ec0: info: new max delay is 150 us acpi_ec0: info: new max delay is 180 us --=-n7uDlthGdslTLvtFaWcW-- From owner-freebsd-acpi@FreeBSD.ORG Fri Feb 18 19:26:32 2005 Return-Path: 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 3296516A4CF; Fri, 18 Feb 2005 19:26:32 +0000 (GMT) Received: from www.cryptography.com (li-22.members.linode.com [64.5.53.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id D4A3543D39; Fri, 18 Feb 2005 19:26:31 +0000 (GMT) (envelope-from nate@root.org) Received: from [10.0.0.34] (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 j1IJQUZj020177 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 18 Feb 2005 11:26:31 -0800 Message-ID: <42164162.5090005@root.org> Date: Fri, 18 Feb 2005 11:26:26 -0800 From: Nate Lawson User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Rong-En Fan References: <4213F066.2050708@root.org> <4214119B.2010909@telia.com> <421537E9.8050203@root.org> <20050218075843.GA42365@svm.csie.ntu.edu.tw> In-Reply-To: <20050218075843.GA42365@svm.csie.ntu.edu.tw> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: acpi@freebsd.org cc: current@freebsd.org Subject: Re: patch: p4tcc and speedstep cpufreq drivers X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Feb 2005 19:26:34 -0000 Rong-En Fan wrote: > On Thu, Feb 17, 2005 at 04:33:45PM -0800, Nate Lawson wrote: > >>Pawel Worach wrote: >> >>>Nate Lawson wrote: >>> >>> >>>>Attached is a patch that I'd like to get tested. After applying it, >>>>rebuild and load the cpufreq.ko module. Be sure you do _not_ have >>>>"options CPU_ENABLE_TCC" in your kernel config or the new driver will >>>>conflict with the old. >>> >>> >>>Hi Nate, >>> >>>This is what I get on a TP T41, do the cpufreq results below look right? >>>Also if I loaded both modules all I got for dev.cpu.0.freq was -1 or >>>1700 and no levels. >>> >>>CPU: Intel(R) Pentium(R) M processor 1700MHz (1698.56-MHz 686-class CPU) >>> Origin = "GenuineIntel" Id = 0x695 Stepping = 5 >>>Features=0xa7e9f9bf >> >>Apologies. I found 2 bugs, one was not calling cpufreq_register() and >>the other was that the code to detect acpi_perf (in ichss and est) was >>incorrect. I've committed fixes for that and have updated the patch. >>Please ues this version and test again. > > > Hi, > > This is an TP X31. > > CPU: Intel(R) Pentium(R) M processor 1400MHz (1398.82-MHz 686-class CPU) > Origin = "GenuineIntel" Id = 0x695 Stepping = 5 > Features=0xa7e9f9bf LFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,TM,PBE> > > freq_levels looks strange.. and changes... > (only cpufreq is loaded at boot) > > rafan@woodstock|UTF-8 [~] (15:57)$ sysctl dev.cpu > dev.cpu.0.%desc: ACPI CPU (3 Cx states) > dev.cpu.0.%driver: cpu > dev.cpu.0.%location: handle=\_PR_.CPU_ > dev.cpu.0.%pnpinfo: _HID=none _UID=0 > dev.cpu.0.%parent: acpi0 > dev.cpu.0.freq: 1399 > dev.cpu.0.freq_levels: -738340620/0 0/0 0/0 Which cpufreq drivers are detected in dmesg (ichss, est, p4tcc, acpi_perf, acpi_throttle)? -- Nate From owner-freebsd-acpi@FreeBSD.ORG Fri Feb 18 19:34:07 2005 Return-Path: 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 3F80716A4EF; Fri, 18 Feb 2005 19:34:07 +0000 (GMT) Received: from www.cryptography.com (li-22.members.linode.com [64.5.53.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8C09243D1F; Fri, 18 Feb 2005 19:34:06 +0000 (GMT) (envelope-from nate@root.org) Received: from [10.0.0.34] (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 j1IJY5Zj020354 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 18 Feb 2005 11:34:05 -0800 Message-ID: <42164329.8080801@root.org> Date: Fri, 18 Feb 2005 11:34:01 -0800 From: Nate Lawson User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pawel Worach References: <4213F066.2050708@root.org> <4214119B.2010909@telia.com> <421537E9.8050203@root.org> <42155FBD.5050701@telia.com> In-Reply-To: <42155FBD.5050701@telia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: acpi@freebsd.org cc: current@freebsd.org Subject: Re: patch: p4tcc and speedstep cpufreq drivers X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Feb 2005 19:34:07 -0000 Pawel Worach wrote: > Nate Lawson wrote: > >> >> Apologies. I found 2 bugs, one was not calling cpufreq_register() and >> the other was that the code to detect acpi_perf (in ichss and est) was >> incorrect. I've committed fixes for that and have updated the patch. >> Please ues this version and test again. >> > > On boot pre-seed PRNG does 'sysctl -a' which panics like this. > - only cpufreq.ko loaded > - last line of 'sysctl -a' output is "dev.cpu.0.%parent: acpi0" > > Fatal trap 12: page fault while in kernel mode Thakn you, this is a helpful problem report. I'll find the bug and send you an updated patch. -- Nate From owner-freebsd-acpi@FreeBSD.ORG Fri Feb 18 20:23:05 2005 Return-Path: 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 1989016A4CE; Fri, 18 Feb 2005 20:23:05 +0000 (GMT) Received: from svm.csie.ntu.edu.tw (svm.csie.ntu.edu.tw [140.112.90.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 75F3D43D31; Fri, 18 Feb 2005 20:23:04 +0000 (GMT) (envelope-from rafan@svm.csie.ntu.edu.tw) Received: from svm.csie.ntu.edu.tw (localhost [127.0.0.1]) by svm.csie.ntu.edu.tw (8.13.1/8.13.1) with ESMTP id j1IKN0HX071660; Sat, 19 Feb 2005 04:23:00 +0800 (CST) (envelope-from rafan@svm.csie.ntu.edu.tw) Received: (from rafan@localhost) by svm.csie.ntu.edu.tw (8.13.1/8.13.1/Submit) id j1IKMtHx071659; Sat, 19 Feb 2005 04:22:55 +0800 (CST) (envelope-from rafan) Date: Sat, 19 Feb 2005 04:22:55 +0800 From: Rong-En Fan To: Nate Lawson Message-ID: <20050218202255.GA71615@svm.csie.ntu.edu.tw> References: <4213F066.2050708@root.org> <4214119B.2010909@telia.com> <421537E9.8050203@root.org> <20050218075843.GA42365@svm.csie.ntu.edu.tw> <42164162.5090005@root.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: <42164162.5090005@root.org> User-Agent: Mutt/1.5.7i cc: acpi@freebsd.org cc: current@freebsd.org Subject: Re: patch: p4tcc and speedstep cpufreq drivers X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Feb 2005 20:23:05 -0000 On Fri, Feb 18, 2005 at 11:26:26AM -0800, Nate Lawson wrote: > Rong-En Fan wrote: > >This is an TP X31. > > > >CPU: Intel(R) Pentium(R) M processor 1400MHz (1398.82-MHz 686-class CPU) > > Origin =3D "GenuineIntel" Id =3D 0x695 Stepping =3D 5 > > Features=3D0xa7e9f9bf >LFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,TM,PBE> > > > >freq_levels looks strange.. and changes... > >(only cpufreq is loaded at boot) > > > >rafan@woodstock|UTF-8 [~] (15:57)$ sysctl dev.cpu > >dev.cpu.0.%desc: ACPI CPU (3 Cx states) > >dev.cpu.0.%driver: cpu > >dev.cpu.0.%location: handle=3D\_PR_.CPU_ > >dev.cpu.0.%pnpinfo: _HID=3Dnone _UID=3D0 > >dev.cpu.0.%parent: acpi0 > >dev.cpu.0.freq: 1399 > >dev.cpu.0.freq_levels: -738340620/0 0/0 0/0 >=20 > Which cpufreq drivers are detected in dmesg (ichss, est, p4tcc,=20 > acpi_perf, acpi_throttle)? cpu0: on acpi0 est0: on cpu0 p4tcc0: on cpu0=20 but I think Pentium M is est only, no p4tcc. Regards, Rong-En Fan From owner-freebsd-acpi@FreeBSD.ORG Fri Feb 18 20:31:50 2005 Return-Path: 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 664F716A4CE; Fri, 18 Feb 2005 20:31:50 +0000 (GMT) Received: from www.cryptography.com (li-22.members.linode.com [64.5.53.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1BAB843D54; Fri, 18 Feb 2005 20:31:50 +0000 (GMT) (envelope-from nate@root.org) Received: from [10.0.0.34] (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 j1IKVmZj021548 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 18 Feb 2005 12:31:49 -0800 Message-ID: <421650B1.3080408@root.org> Date: Fri, 18 Feb 2005 12:31:45 -0800 From: Nate Lawson User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Rong-En Fan References: <4213F066.2050708@root.org> <4214119B.2010909@telia.com> <421537E9.8050203@root.org> <20050218075843.GA42365@svm.csie.ntu.edu.tw> <42164162.5090005@root.org> <20050218202255.GA71615@svm.csie.ntu.edu.tw> In-Reply-To: <20050218202255.GA71615@svm.csie.ntu.edu.tw> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: acpi@freebsd.org cc: current@freebsd.org Subject: Re: patch: p4tcc and speedstep cpufreq drivers X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Feb 2005 20:31:50 -0000 Rong-En Fan wrote: > On Fri, Feb 18, 2005 at 11:26:26AM -0800, Nate Lawson wrote: > >>Rong-En Fan wrote: >> >>>This is an TP X31. >>> >>>CPU: Intel(R) Pentium(R) M processor 1400MHz (1398.82-MHz 686-class CPU) >>> Origin = "GenuineIntel" Id = 0x695 Stepping = 5 >>> Features=0xa7e9f9bf>>LFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,TM,PBE> >>> >>>freq_levels looks strange.. and changes... >>>(only cpufreq is loaded at boot) >>> >>>rafan@woodstock|UTF-8 [~] (15:57)$ sysctl dev.cpu >>>dev.cpu.0.%desc: ACPI CPU (3 Cx states) >>>dev.cpu.0.%driver: cpu >>>dev.cpu.0.%location: handle=\_PR_.CPU_ >>>dev.cpu.0.%pnpinfo: _HID=none _UID=0 >>>dev.cpu.0.%parent: acpi0 >>>dev.cpu.0.freq: 1399 >>>dev.cpu.0.freq_levels: -738340620/0 0/0 0/0 >> >>Which cpufreq drivers are detected in dmesg (ichss, est, p4tcc, >>acpi_perf, acpi_throttle)? > > > cpu0: on acpi0 > est0: on cpu0 > p4tcc0: on cpu0 > > but I think Pentium M is est only, no p4tcc. Nope, you almost certainly have p4tcc since your CPU has the ACPI and TM bits set above. -- Nate From owner-freebsd-acpi@FreeBSD.ORG Sat Feb 19 05:30:25 2005 Return-Path: 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 93ABF16A4CE; Sat, 19 Feb 2005 05:30:25 +0000 (GMT) Received: from postal2.es.net (postal2.es.net [198.128.3.206]) by mx1.FreeBSD.org (Postfix) with ESMTP id 503DB43D55; Sat, 19 Feb 2005 05:30:25 +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; Fri, 18 Feb 2005 21:30:24 -0800 Received: from ptavv (localhost [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id 025DF5D07; Fri, 18 Feb 2005 21:30:23 -0800 (PST) X-Mailer: exmh version 2.7.0 06/18/2004 with nmh-1.0.4 To: Nate Lawson In-reply-to: Your message of "Thu, 17 Feb 2005 16:33:45 PST." <421537E9.8050203@root.org> Mime-Version: 1.0 Content-Type: multipart/mixed ; boundary="==_Exmh_4198249080" Date: Fri, 18 Feb 2005 21:30:23 -0800 From: "Kevin Oberman" Message-Id: <20050219053023.025DF5D07@ptavv.es.net> cc: acpi@freebsd.org cc: current@freebsd.org Subject: Re: patch: p4tcc and speedstep cpufreq drivers X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Feb 2005 05:30:25 -0000 This is a multipart MIME message. --==_Exmh_4198249080 Content-Type: text/plain; charset=us-ascii > Date: Thu, 17 Feb 2005 16:33:45 -0800 > From: Nate Lawson > Sender: owner-freebsd-acpi@freebsd.org > Pawel Worach wrote: > > Nate Lawson wrote: > > > >> Attached is a patch that I'd like to get tested. After applying it, > >> rebuild and load the cpufreq.ko module. Be sure you do _not_ have > >> "options CPU_ENABLE_TCC" in your kernel config or the new driver will > >> conflict with the old. > > > > > > Hi Nate, > > > > This is what I get on a TP T41, do the cpufreq results below look right? > > Also if I loaded both modules all I got for dev.cpu.0.freq was -1 or > > 1700 and no levels. > > > > CPU: Intel(R) Pentium(R) M processor 1700MHz (1698.56-MHz 686-class CPU) > > Origin = "GenuineIntel" Id = 0x695 Stepping = 5 > > Features=0xa7e9f9bf > > Apologies. I found 2 bugs, one was not calling cpufreq_register() and > the other was that the code to detect acpi_perf (in ichss and est) was > incorrect. I've committed fixes for that and have updated the patch. > Please ues this version and test again. > > Thanks, > -- > Nate Well, it all seems working, but the performance is not proportional to the "frequency". I am attaching the results of testing. The fist column is value of freq and the second is the transfer rate from dd to md5. FWIW, when I did have TCC working I had 31 freq_levels, but if I set the freq below about 200, my system freezes and requires a hard power cycle. I am running ULE but no PREEMPTION. The exact point at which it locks up is not consistent. -- 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_4198249080 Content-Type: text/plain ; name="result.dat"; charset=us-ascii Content-Description: result.dat Content-Disposition: attachment; filename="result.dat" 1800 81668412 1575 71668443 1378 58558755 1350 61811066 1200 57563243 1125 52375978 1050 50566365 1012 39348776 984 39065432 900 42731558 843 29862236 787 28684250 750 36504585 703 29017105 675 32053763 600 29716681 562 18906700 506 18847782 450 20757733 421 15552950 393 8823479 337 8813267 300 14117150 262 7505668 262 7504739 300 14098650 337 8832118 393 8809254 421 15511277 450 20810595 506 18806831 562 18876877 600 29786587 675 32042771 703 29040273 750 36509861 787 28743443 843 29824058 900 42624546 984 38689042 1012 39030680 1050 50404117 1125 52225250 1200 57551960 1350 61504422 1378 58605230 1575 71371080 1800 81360013 --==_Exmh_4198249080-- From owner-freebsd-acpi@FreeBSD.ORG Sat Feb 19 18:11:58 2005 Return-Path: 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 F27D316A4CE; Sat, 19 Feb 2005 18:11:57 +0000 (GMT) Received: from bgo1smout1.broadpark.no (bgo1smout1.broadpark.no [217.13.4.94]) by mx1.FreeBSD.org (Postfix) with ESMTP id 02FE143D1D; Sat, 19 Feb 2005 18:11:57 +0000 (GMT) (envelope-from morten@rodal.no) Received: from bgo1sminn1.broadpark.no ([217.13.4.93]) by bgo1smout1.broadpark.no (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTP id <0IC6000HJ7MLP380@bgo1smout1.broadpark.no>; Sat, 19 Feb 2005 19:06:21 +0100 (CET) Received: from slimy.rodal.no ([80.202.56.120]) by bgo1sminn1.broadpark.no (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTP id <0IC600KGQ7Z7PIA0@bgo1sminn1.broadpark.no>; Sat, 19 Feb 2005 19:13:55 +0100 (CET) Received: from burton.rodal.no (burton.rodal.no [192.168.20.70]) by slimy.rodal.no (8.12.11/8.12.11) with ESMTP id j1JIBcKD070719; Sat, 19 Feb 2005 19:11:38 +0100 (CET envelope-from morten@rodal.no) Received: from localhost (localhost [[UNIX: localhost]]) by burton.rodal.no (8.13.1/8.13.1/Submit) id j1JIBaBS020089; Sat, 19 Feb 2005 19:11:36 +0100 (CET envelope-from morten@rodal.no) Date: Sat, 19 Feb 2005 19:11:35 +0100 From: Morten Rodal In-reply-to: <42068A5C.1030300@root.org> To: Nate Lawson Message-id: <200502191911.36228.morten@rodal.no> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Content-disposition: inline X-Virus-Scanned: by amavisd-new References: <42068A5C.1030300@root.org> X-Authentication-warning: burton.rodal.no: morten set sender to morten@rodal.no using -f User-Agent: KMail/1.7.2 cc: acpi@freebsd.org cc: current@freebsd.org Subject: Re: HEADSUP: cpufreq import complete, acpi_throttling changed X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Feb 2005 18:11:58 -0000 On Sunday 06 February 2005 22:21, Nate Lawson wrote: > If you have throttling, please test the new configuration to be sure it > still works as before. Final upcoming work will be manpage support and > bugfixing as necessary. > Throttling used to work on my Dell Inspiron 8200, but with the new cpufreq/acpi_perf I only get errors when trying to set a new cpu frequency, like this: # sysctl dev.cpu.0.freq=1200 acpi_perf0: Px transition to 1200 failed acpi_perf0: set freq failed, err 6 Regardless of what value I use, it either says 'Px transition to 1200 failed' or 'Px transition to 1700 failed.' Here's more info from various sysctl's: # sysctl hw.acpi.cpu hw.acpi.cpu.cx_supported: C1/0 C2/50 hw.acpi.cpu.cx_lowest: C2 hw.acpi.cpu.cx_usage: 0.00% 100.00% # sysctl dev.cpu dev.cpu.0.%desc: ACPI CPU (2 Cx states) dev.cpu.0.%driver: cpu dev.cpu.0.%location: handle=\_PR_.CPU0 dev.cpu.0.%pnpinfo: _HID=none _UID=0 dev.cpu.0.%parent: acpi0 dev.cpu.0.freq: 1700 dev.cpu.0.freq_levels: 1700/0 1487/0 1275/0 1200/0 1062/0 900/0 850/0 750/0 637/0 600/0 450/0 425/0 300/0 212/0 150/0 If I remember correctly the old interface said something about 8 throttling states ranging from 12.X% to 100%, but I seem to have many more freq_levels now? The CPU is a Pentium 4 Mobile 1.7GHz # dmesg | grep -i cpu CPU: Intel(R) Pentium(R) 4 Mobile CPU 1.70GHz (1695.01-MHz 686-class CPU) cpu0: on acpi0 acpi_perf0: on cpu0 acpi_throttle0: on cpu0 -- Morten Rodal "A supercomputer is a device for turning compute-bound problems into I/O bound problems." -- Ken Batcher (Goodyear Aerospace) From owner-freebsd-acpi@FreeBSD.ORG Sat Feb 19 18:51:18 2005 Return-Path: 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 51EA216A4CE; Sat, 19 Feb 2005 18:51:18 +0000 (GMT) Received: from ylpvm15.prodigy.net (ylpvm15-ext.prodigy.net [207.115.57.46]) by mx1.FreeBSD.org (Postfix) with ESMTP id EEC6243D31; Sat, 19 Feb 2005 18:51:17 +0000 (GMT) (envelope-from nate@root.org) Received: from [10.0.5.51] (adsl-64-171-186-189.dsl.snfc21.pacbell.net [64.171.186.189])j1JIl5bs015337; Sat, 19 Feb 2005 13:47:05 -0500 Message-ID: <42178A8E.1060305@root.org> Date: Sat, 19 Feb 2005 10:50:54 -0800 From: Nate Lawson User-Agent: Mozilla Thunderbird 1.0RC1 (X11/20041205) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Morten Rodal References: <42068A5C.1030300@root.org> <200502191911.36228.morten@rodal.no> In-Reply-To: <200502191911.36228.morten@rodal.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: acpi@freebsd.org cc: current@freebsd.org Subject: Re: HEADSUP: cpufreq import complete, acpi_throttling changed X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Feb 2005 18:51:18 -0000 Morten Rodal wrote: > On Sunday 06 February 2005 22:21, Nate Lawson wrote: > >>If you have throttling, please test the new configuration to be sure it >>still works as before. Final upcoming work will be manpage support and >>bugfixing as necessary. >> > > > Throttling used to work on my Dell Inspiron 8200, but with the new > cpufreq/acpi_perf I only get errors when trying to set a new cpu > frequency, like this: > > # sysctl dev.cpu.0.freq=1200 > acpi_perf0: Px transition to 1200 failed > acpi_perf0: set freq failed, err 6 > > Regardless of what value I use, it either says 'Px transition to 1200 > failed' or 'Px transition to 1700 failed.' > > Here's more info from various sysctl's: > > # sysctl hw.acpi.cpu > hw.acpi.cpu.cx_supported: C1/0 C2/50 > hw.acpi.cpu.cx_lowest: C2 > hw.acpi.cpu.cx_usage: 0.00% 100.00% > > # sysctl dev.cpu > dev.cpu.0.%desc: ACPI CPU (2 Cx states) > dev.cpu.0.%driver: cpu > dev.cpu.0.%location: handle=\_PR_.CPU0 > dev.cpu.0.%pnpinfo: _HID=none _UID=0 > dev.cpu.0.%parent: acpi0 > dev.cpu.0.freq: 1700 > dev.cpu.0.freq_levels: 1700/0 1487/0 1275/0 1200/0 1062/0 900/0 850/0 > 750/0 637/0 600/0 450/0 425/0 300/0 212/0 150/0 > > If I remember correctly the old interface said something about 8 > throttling states ranging from 12.X% to 100%, but I seem to have many > more freq_levels now? Is this a -current as of today? If not, please cvsup and test again. -- Nate