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: [email protected]
> To: [email protected]
> Cc: Ian Smith <[email protected]>
> Subject: Re: TECRA A9-S9017 -- Idles too hot -- Hardware Support
>
> On Thu, Jan 01, 1970 at 12:00:00AM +0000, [email protected] 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
> > > > [email protected]:/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
> _______________________________________________
> [email protected] mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-mobile
> To unsubscribe, send any mail to "[email protected]"
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-mobile
To unsubscribe, send any mail to "[email protected]"
lmpx.com only provides a reader for public news (NNTP) servers. It is not
affiliated with the servers or forums shown here and is not responsible for
the content of articles, which is written by their respective authors.