From owner-freebsd-acpi@FreeBSD.ORG Sun Aug 31 16:45:58 2008 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4642E106566B; Sun, 31 Aug 2008 16:45:58 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [220.233.188.227]) by mx1.freebsd.org (Postfix) with ESMTP id A3EBD8FC2D; Sun, 31 Aug 2008 16:45:56 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id m7VGji9D005813; Mon, 1 Sep 2008 02:45:45 +1000 (EST) (envelope-from smithi@nimnet.asn.au) Date: Mon, 1 Sep 2008 02:45:44 +1000 (EST) From: Ian Smith To: freebsd_user@guice.ath.cx Message-ID: <20080901020747.A1667@sola.nimnet.asn.au> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: freebsd-acpi@freebsd.org, Wes Morgan , freebsd-mobile@freebsd.org Subject: Re: TECRA A9-S9017 -- Idles too hot -- Hardware Support (fwd) X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Aug 2008 16:45:58 -0000 Ok, I think we've finally obtained enough info to pin this issue down. I'm going to just forward your message to freebsd-acpi@ because your symptoms (two cpu frequencies only 1 unit apart (one bogus), powerd therefore not shifting to a real lower frequency, so running flat out all the time) came up there several times this year on some machines. While I can't recall the details, nor have access to my own archives currently, I'm pretty sure there was a patch - not sure if it covers or can be applied to 6.3 though. You could browse the -acpi archives for this, but hopefully someone will show mercy and provide a pointer or two, if not directly help out? As Wes since mentioned, 61C isn't hot at all (at that frequency anyway) but still it'd be better to get the mangled cpu freqs sorted out so that powerd can do its thing properly. [FWIW, I'm the OP in this ongoing conversation on -mobile below .. sorry I didn't pay a bit more attention back when this was a 'hot issue' ..] cheers, Ian ---------- Forwarded message ---------- Date: Sat, 30 Aug 2008 17:07:36 -0400 From: freebsd_user@guice.ath.cx To: freebsd-mobile@freebsd.org Cc: Ian Smith Subject: Re: TECRA A9-S9017 -- Idles too hot -- Hardware Support On Thu, Jan 01, 1970 at 12:00:00AM +0000, email@WORKSTATION.guice.ath.cx wrote: FROM THE LAST MESSAGE ... > > > > > However we need some empirical data about what it's doing. Showing your > > > > /var/run/dmesg.boot and 'sysctl hw.acpi' output would be a good start. > > > > > > > Initially we didn't provide that data until someone asked for it to be sure that is > > > in fact what was needed or if the was some other incorrect setting. > > > > > > /var/run/dmesg.boot ... > > > > I'm trimming this down to the likely relevant ACPI stuff .. > > > > > Copyright (c) 1992-2008 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 is a registered trademark of The FreeBSD Foundation. > > > FreeBSD 6.3-RELEASE-p3 #1: Mon Aug 4 23:37:02 EDT 2008 > > > root@WORKSTATION.ath.cx:/usr/obj/usr/src/sys/WORKSTATION > > > ACPI APIC Table: > > > Timecounter "i8254" frequency 1193182 Hz quality 0 > > > CPU: Intel(R) Core(TM)2 Duo CPU T7500 @ 2.20GHz (2194.52-MHz 686-class CPU) > > > Origin = "GenuineIntel" Id = 0x6fb Stepping = 11 > > > Features=0xbfebfbff > > > Features2=0xe3bd > > > AMD Features=0x20100000 > > > AMD Features2=0x1 > > > Cores per package: 2 > > > real memory = 2113142784 (2015 MB) > > > avail memory = 2058563584 (1963 MB) > > > ioapic0: Changing APIC ID to 1 > > > ioapic0 irqs 0-23 on motherboard > > [..] > > > acpi0: on motherboard > > > acpi0: Power Button (fixed) > > > Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 > > > acpi_timer0: <24-bit timer at 3.579545MHz> port 0xd808-0xd80b on acpi0 > > > acpi_hpet0: iomem 0xfed00000-0xfed003ff on acpi0 > > > Timecounter "HPET" frequency 14318180 Hz quality 900 > > > cpu0: on acpi0 > > [..] > > > acpi_lid0: on acpi0 > > > battery0: on acpi0 > > > acpi_button0: on acpi0 > > > acpi_acad0: on acpi0 > > > acpi_tz0: on acpi0 > > [..] > > > > No cpufreq driver/s. cpufreq removed from your custom kernel? So no > > CPU frequency control. So, powerd is rendered powerless .. > > > 'powerd' is now operational: idle time > 90%, decreasing clock speed from 2201 MHz to 2200 MHz^M idle time > 90%, decreasing clock speed from 2201 MHz to 2200 MHz^M idle time > 90%, decreasing clock speed from 2201 MHz to 2200 MHz^M idle time > 90%, decreasing clock speed from 2201 MHz to 2200 MHz^M idle time > 90%, decreasing clock speed from 2201 MHz to 2200 MHz^M ^Ctotal joules used: 41737.500^M > > Try booting with the GENERIC kernel, you should see one or two of the > > supported drivers listed in cpufreq(4) loaded in dmesg.boot. Then see > > if powerd isn't doing the right thing (w/ powerd -v as discussed below) > > > This has always been the /GENERIC kernel copied to a custome name. This was a 6.0-RELEASE UPGRADED TO -p3. Apparently cpufreq wasn't considered as a default entry in the /GENERIC. > > > > > sysctl hw.acpi ... > > > > > > hw.acpi.supported_sleep_state: S3 S4 S5 > > > hw.acpi.power_button_state: S5 > > > hw.acpi.sleep_button_state: S3 > > > hw.acpi.lid_switch_state: NONE > > > hw.acpi.standby_state: S1 > > > hw.acpi.suspend_state: S3 > > > hw.acpi.sleep_delay: 1 > > > hw.acpi.s4bios: 0 > > > hw.acpi.verbose: 0 > > > hw.acpi.disable_on_reboot: 0 > > > hw.acpi.handle_reboot: 0 > > > hw.acpi.reset_video: 0 > > > hw.acpi.cpu.cx_lowest: C1 > > > hw.acpi.battery.life: 100 > > > hw.acpi.battery.time: -1 > > > hw.acpi.battery.state: 0 > > > hw.acpi.battery.units: 1 > > > hw.acpi.battery.info_expire: 5 > > > hw.acpi.acline: 1 > > > hw.acpi.thermal.min_runtime: 0 > > > hw.acpi.thermal.polling_rate: 10 > > > hw.acpi.thermal.user_override: 0 > > > hw.acpi.thermal.tz0.temperature: 63.0C > > > hw.acpi.thermal.tz0.active: -1 > > > hw.acpi.thermal.tz0.passive_cooling: 0 > > > hw.acpi.thermal.tz0.thermal_flags: 0 > > > hw.acpi.thermal.tz0._PSV: -1 > > > hw.acpi.thermal.tz0._HOT: -1 > > > hw.acpi.thermal.tz0._CRT: 102.0C > > > hw.acpi.thermal.tz0._ACx: -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 > > > > No passive cooling. See acpi_thermal(4) .. you may want to set some > > overrides .. but it might all just work with the GENERIC kernel anyway. > Attempting to: --> sysctl hw.acpi.thermal.user_override hw.acpi.thermal.user_override: 0 Attempting to: --> sysctl hw.acpi.thermal.user_override=1 hw.acpi.thermal.user_override: 0 -> 1 Attempting to: --> sysctl hw.acpi.thermal.tz0.passive_cooling hw.acpi.thermal.tz0.passive_cooling: 0 Attempting to: --> sysctl hw.acpi.thermal.tz0.passive_cooling=1 hw.acpi.thermal.tz0.passive_cooling: 0 sysctl: hw.acpi.thermal.tz0.passive_cooling: Operation not supported by device NOTE: While we are able to change the threshold for: hw.acpi.thermal.tz0._PSV: -1, we don't see the need to do so because the above passive_cooling is not enabled. Well, so much for passive_cooling. :=\ > > Also, have you set anything in BIOS regarding power usage, speedstep or > > any other settings that might get reflected into your boot ACPI setup? Initially we left the BIOS power settings the way the OEM set them (Vista). We are able to choose from one of Dynamic, High or low not much else to play with in the way of power settings (ACPI) with the exception of LCD and/or letting the OS control devices. Unable to directly set CPU steppings/freq settings within this BIOS. > > And, are you loading acpi_toshiba(4)? Not sure if it would help with > > this, but may at least provide some useful info in its sysctls .. > > > This is an issue revisited; take a deep breath. Better yet, here's the short version, in the kernel 'device acpi_toshiba' does not work for us on this machine unless we neglected to make an accompanying needed acpi entry. Aa we understand it, we were to only add 'device acpi_toshiba' to load the neccessary acpi toshiba extras. Using 'acpi_toshiba_load="YES"' in the /boot/loader.conf -and- using 'kldload acpi_toshiba' from the cli works like a charm but has no positive affect on the current discussion (heat). > > > > Secondly, in its own window or vty, as root, run /etc/rc.d/powerd stop > > > > (if it's running) then run 'powerd -v' which runs in foreground and says > > > > exactly what it's doing re shifting CPU frequency under various loads. idle time > 90%, decreasing clock speed from 2201 MHz to 2200 MHz^M idle time > 90%, decreasing clock speed from 2201 MHz to 2200 MHz^M idle time > 90%, decreasing clock speed from 2201 MHz to 2200 MHz^M ^Ctotal joules used: 41737.500 > > > > > > > > It's also useful to watch the temperature(s) directly over the time, see > > > > acpi_thermal(4) and try logging those sysctls periodically in a script. The following data is the result of the concerns I have; running too hot. These figures are the lowest temperatures this machine idles while FreeBSD is installed and running. The temperatures shown herein only rise with use but never go lower than what we're showing here when the laptop returns to idle. Attempting to: --> sysctl hw.acpi.thermal.tz0. hw.acpi.thermal.tz0.temperature: 61.0C hw.acpi.thermal.tz0.active: -1 hw.acpi.thermal.tz0.passive_cooling: 0 hw.acpi.thermal.tz0.thermal_flags: 0 hw.acpi.thermal.tz0._PSV: -1 hw.acpi.thermal.tz0._HOT: -1 hw.acpi.thermal.tz0._CRT: 102.0C hw.acpi.thermal.tz0._ACx: -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 > > > > Firstly, yes that comment isn't too helpful .. power_profile only acts > > > > (so far) when you apply or remove AC power, using the following values > > > > from /etc/defaults/rc.conf unless you've set them otherwise: > > > > > > > > performance_cx_lowest="HIGH" # Online CPU idle state > > > > performance_cpu_freq="HIGH" # Online CPU frequency > > > > economy_cx_lowest="HIGH" # Offline CPU idle state > > > > economy_cpu_freq="HIGH" # Offline CPU frequency Our /etc/defaults/rc.conf performance_cx_lowest="HIGH" # Online CPU idle state performance_cpu_freq="NONE" # Online CPU frequency economy_cx_lowest="HIGH" # Offline CPU idle state economy_cpu_freq="NONE" # Offline CPU frequency > > > > If you have a look at /etc/rc.d/power_profile you'll see that these are > > > > applied to sysctl hw.acpi.cpu.cx_lowest (from hw.acpi.cpu.cx_supported) > > > > and dev.cpu.0.freq (from dev.cpu.0.freq_levels). You can set the above > > > > variables to HIGH, LOW, a specific value, or NONE. Attempting to: --> sysctl hw.acpi.cpu.cx_supported sysctl: unknown oid 'hw.acpi.cpu.cx_supported' Attempting to: --> sysctl hw.acpi.cpu hw.acpi.cpu.cx_lowest: C1 Above, where is "hw.acpi.cpu.cx_supported"? Did FreeBSD 'not' probe something? Attempting to: --> sysctl dev.cpu.0.freq_levels dev.cpu.0.freq_levels: 2201/35000 2200/35000 1925/30625 1650/26250 1600/23000 1400/20125 1200/16000 1050/14000 900/12000 800/14300 700/12512 600/10725 500/8937 400/7150 300/5362 200/3575 100/1787 Following is grepped from /var/run/dmesg.boot: CPU: Intel(R) Core(TM)2 Duo CPU T7500 @ 2.20GHz (2194.54-MHz 686-class CPU) cpu0: on acpi0 est0: on cpu0 p4tcc0: on cpu0 > > > > Specify "NONE" to have power_profile make no changes. "C3" or at least > > > > "C2" can be useful CX values, in some machines helping with temperature. > > > > powerd will soon override the dev.cpu.0.freq setting anyway, so it's not > > > > a problem - again, watch powerd -v output - and I guess you'll rarely > > > > run on battery (you've got a nice 2-3 hour UPS, though :) > Our /etc/rc.conf performance_cx_lowest="C4" # Online CPU idle state #performance_cpu_freq="HIGH" # Online CPU frequency economy_cx_lowest="C5" # Offline CPU idle state #economy_cpu_freq="HIGH" # Offline CPU frequency This machine can afford to go to C4 and C5 unless needed otherwise. I'll try anything to lowwer this machines temp. > > > This is another issue in addition to the heat. As you say, this battery > > > should last any where from 2-3 hours, however as it is now; > > > out-of-the-box so to speak, this machine will only stay powered up > > > approximately 1-hour on using the oem battery. > > > > That's because it runs at (presumably) its maximum frequency all of the > > time; you're lucky to get an hour at that rate, and yes it'll run hot :) > > > > 'sysctl dev.cpu.0.freq hw.acpi.thermal.tz0.temperature' now and again. These numbers have not changed (lowwer) prior to or during this thread. Attempting to: --> sysctl dev.cpu.0.freq dev.cpu.0.freq: 2201 <-- has gone down to 2200; no lowwer. Attempting to: --> sysctl hw.acpi.thermal.tz0.temperature hw.acpi.thermal.tz0.temperature: 61.0C > > > > This machine has never run this hot, prior to running 'powerd'-- or run > > > > > this warm, while idling with 'powerd' in comparison to running under windows > > > > > --not trying to start and OS confilict here, trying to learn, understand > > > > > and control this beast of a machine if possible. > > > > > > > > Of course, and it's likely doable, though you might need to run 7-STABLE > > > > for the latest dual-core ACPI handling. Let's see how we go with some > > > > real information, before suggesting taking this to freebsd-acpi@. I > > > > don't see where you've mentioned what version of FreeBSD it's running? > > > > > > I believe I did so at the outset of this thread. In any case dmesg has > > > now provided that information. > > > > ok, 6.3-R-p3. Frankly I've no idea whether your dual-core Toshiba is or > > is not subject to any of the dual-core issues solved or being actively > > worked on in freebsd-acpi and being applied mostly or at least firstly > > back into 7-STABLE. I'd suggest browsing the -acpi archives for the > > last few months, it's not that big .. that is, if using the GENERIC > > kernel and running powerd doesn't improve matters sufficiently. > > > > cheers, Ian