Date: Sun, 31 Aug 2008 16:29:39 -0400 From: freebsd_user@guice.ath.cx To: freebsd-mobile@freebsd.org Cc: Ian Smith <smithi@nimnet.asn.au> Subject: Re: TECRA A9-S9017 -- Idles too hot -- Hardware Support Message-ID: <20080831202938.GB2191@WORKSTATION.guice.ath.cx> In-Reply-To: <20080901020747.A1667@sola.nimnet.asn.au> References: <20080901020747.A1667@sola.nimnet.asn.au>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Sep 01, 2008 at 02:45:44AM +1000, Ian Smith wrote: > 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. I was recently introduced to this URL: http://lists.freebsd.org/pipermail/cvs-src/2007-August/081246.html. > > 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. In addition to the above URL, other findings: hw.acpi.toshiba.cpu_speed=7 hw.acpi.toshiba.force_fan=1 hw.acpi.thermal.min_runtime=30 hw.acpi.thermal.polling_rate: 10 hw.acpi.thermal.user_override=1 hw.acpi.thermal.tz0.temperature: 61.0C # On 6.3-RELEASE -p3 - # this value is bogus hw.acpi.thermal.tz0.active: -1 # Can not change hw.acpi.thermal.tz0.passive_cooling: 0 # Can not change hw.acpi.thermal.tz0.thermal_flags: 0 hw.acpi.thermal.tz0._PSV=10.0C # passive_cooling will- # activate @ this temp. # Above, passive_cooling # currently N/A. Since Sat Aug 30 06:20:00 EDT 2008, with the above sysctl variables set, we have logged the following results at 20-min intervals: Sat Aug 30 21:20:00 EDT 2008 Id Refs Address Size Name 1 4 0xc0400000 7d229c kernel 2 1 0xc0bd3000 3bf8 acpi_toshiba.ko 3 3 0xc0bd7000 5c304 acpi.ko dev.cpu.0.freq: 2201 hw.acpi.thermal.tz0.temperature: 61.0C The frquencies during the above time frame have not gone above 2201 and not fallen below 2200. During which time the hw.acpi.thermal.tz0.temperature: 61.0C has remained static. Moving forward ... It has been suggested that we try the following: Attempting to: --> sysctl dev.cpu.0.freq=900 dev.cpu.0.freq: 2201 -> 900 Here in lies 'a' rub, so to speak; after setting the above dev.cpu.0.freq: 2201 -> 900, the machine appeared to be running cooler --as in placing a finger near the output of the fan, the machine wasn't breathing fire. However, the reading of hw.acpi.thermal.tz0.temperature: 61.0C remained the same --how could this be? Sat Aug 30 21:40:00 EDT 2008 Id Refs Address Size Name 1 4 0xc0400000 7d229c kernel 2 1 0xc0bd3000 3bf8 acpi_toshiba.ko 3 3 0xc0bd7000 5c304 acpi.ko dev.cpu.0.freq: 900 hw.acpi.thermal.tz0.temperature: 61.0C - Sat Aug 30 23:40:00 EDT 2008 Id Refs Address Size Name 1 4 0xc0400000 7d229c kernel 2 1 0xc0bd3000 3bf8 acpi_toshiba.ko 3 3 0xc0bd7000 5c304 acpi.ko dev.cpu.0.freq: 900 hw.acpi.thermal.tz0.temperature: 61.0C If you'll notice the time stamps, I've allowed time for the temperatures both actual and ambient to adjust, yet hw.acpi.thermal.tz0.temperature: 61.0C remains constant. Another suggestion/recommendation, 'kldload coretemp', no 'man page' within 6.3. After doing so, we began to log the following data: ... Notice and compare the time stamp(s)... Sun Aug 31 00:00:01 EDT 2008 Id Refs Address Size Name 1 5 0xc0400000 7d229c kernel 2 1 0xc0bd3000 3bf8 acpi_toshiba.ko 3 3 0xc0bd7000 5c304 acpi.ko 4 1 0xc7240000 2000 coretemp.ko dev.cpu.0.freq: 900 hw.acpi.thermal.tz0.temperature: 61.0C - Sun Aug 31 00:40:01 EDT 2008 Id Refs Address Size Name 1 5 0xc0400000 7d229c kernel 2 1 0xc0bd3000 3bf8 acpi_toshiba.ko 3 3 0xc0bd7000 5c304 acpi.ko 4 1 0xc7240000 2000 coretemp.ko dev.cpu.0.freq: 900 hw.acpi.thermal.tz0.temperature: 61.0C hw.acpi.thermal.tz0.temperature: 61.0C <--> remains unchanged. Here's the entry to drive my point home: Sun Aug 31 01:00:00 EDT 2008 Id Refs Address Size Name 1 5 0xc0400000 7d229c kernel 2 1 0xc0bd3000 3bf8 acpi_toshiba.ko 3 3 0xc0bd7000 5c304 acpi.ko 4 1 0xc7240000 2000 coretemp.ko dev.cpu.0.freq: 900 hw.acpi.thermal.tz0.temperature: 61.0C dev.cpu.0.temperature: 44 - Sun Aug 31 01:20:00 EDT 2008 Id Refs Address Size Name 1 5 0xc0400000 7d229c kernel 2 1 0xc0bd3000 3bf8 acpi_toshiba.ko 3 3 0xc0bd7000 5c304 acpi.ko 4 1 0xc7240000 2000 coretemp.ko Sun Aug 31 01:20:00 EDT 2008 -- dev.cpu.0.freq: 900 Sun Aug 31 01:20:00 EDT 2008 -- hw.acpi.thermal.tz0.temperature: 61.0C Sun Aug 31 01:20:00 EDT 2008 -- dev.cpu.0.temperature: 45 - Sun Aug 31 15:40:00 EDT 2008 Id Refs Address Size Name 1 5 0xc0400000 7d229c kernel 2 1 0xc0bd3000 3bf8 acpi_toshiba.ko 3 3 0xc0bd7000 5c304 acpi.ko 4 1 0xc7240000 2000 coretemp.ko Sun Aug 31 15:40:00 EDT 2008 -- dev.cpu.0.freq: 900 Sun Aug 31 15:40:00 EDT 2008 -- hw.acpi.thermal.tz0.temperature: 61.0C Sun Aug 31 15:40:00 EDT 2008 -- dev.cpu.0.temperature: 44 It is now thought, to say the least, that hw.acpi.thermal.tz0.temperature: 61.0C are not correct in comparison to the output of dev.cpu.0.temperature: 45. If I hadn't of experienced this back in 3.x to 4.x I may have dismissed it as a first time occurrance, but this heat issue has now haunted me using i386 AMD on a Tiger MPX as well as the TECRA_A9-S9017 laptops. Now we find out that there are numerous issues causing this, powerd, incorrect temp/sensor readings and perhaps an OEM ACPI implementation issue. With that being said, please allow me this one (1) rhetorical question; how is a common end-user supposed to keep his machine running and maintain her/his sanity chasing after issues such as we've discussed here? I'd like to extend my continued thanks to: FreeBSD-mobile FreeBSD-questions FreeBSDhelp @ EFnet > > [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 <smithi@nimnet.asn.au> > 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: <TOSHIB A0056 > > > > > 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<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE> > > > > Features2=0xe3bd<SSE3,RSVD2,MON,DS_CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM> > > > > AMD Features=0x20100000<NX,LM> > > > > AMD Features2=0x1<LAHF> > > > > Cores per package: 2 > > > > real memory = 2113142784 (2015 MB) > > > > avail memory = 2058563584 (1963 MB) > > > > ioapic0: Changing APIC ID to 1 > > > > ioapic0 <Version 2.0> irqs 0-23 on motherboard > > > [..] > > > > acpi0: <TOSHIB A0056> 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: <High Precision Event Timer> iomem 0xfed00000-0xfed003ff on acpi0 > > > > Timecounter "HPET" frequency 14318180 Hz quality 900 > > > > cpu0: <ACPI CPU> on acpi0 > > > [..] > > > > acpi_lid0: <Control Method Lid Switch> on acpi0 > > > > battery0: <ACPI Control Method Battery> on acpi0 > > > > acpi_button0: <Power Button> on acpi0 > > > > acpi_acad0: <AC Adapter> on acpi0 > > > > acpi_tz0: <Thermal Zone> 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: <ACPI CPU> on acpi0 > est0: <Enhanced SpeedStep Frequency Control> on cpu0 > p4tcc0: <CPU Frequency Thermal Control> 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 > _______________________________________________ > freebsd-mobile@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-mobile > To unsubscribe, send any mail to "freebsd-mobile-unsubscribe@freebsd.org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080831202938.GB2191>