TECRA A9-S9017 -- Idles too hot -- Hardware Support

freebsd_user at guice.ath.cx freebsd_user at guice.ath.cx
Sun Aug 31 22:38:11 UTC 2008


In an effort to keep this thread *as a thread*, it appears to have
branched off in to a totally different entity due to edits to the
subject, I'm duplicating this message as part of this original thread to
better help other with the same issue and/or machine keep up with what
has taken place with this TECRA_A9-S9017.

Errors-To: owner-freebsd-mobile at freebsd.org


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"


On Sat, Aug 30, 2008 at 05:07:36PM -0400, freebsd_user at guice.ath.cx wrote:
> 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