TECRA A9-S9017 -- Idles too hot -- Hardware Support
freebsd_user at guice.ath.cx
freebsd_user at guice.ath.cx
Sun Aug 31 20:30:29 UTC 2008
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 at guice.ath.cx
> To: freebsd-mobile at freebsd.org
> Cc: Ian Smith <smithi at nimnet.asn.au>
> Subject: Re: TECRA A9-S9017 -- Idles too hot -- Hardware Support
>
> On Thu, Jan 01, 1970 at 12:00:00AM +0000, email at 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 at 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 at . 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 at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-mobile
> To unsubscribe, send any mail to "freebsd-mobile-unsubscribe at freebsd.org"
More information about the freebsd-mobile
mailing list