Spurious thermal shutdowns on Dell Studio 1557
Bartosz Fabianowski
I have a Dell Studio 1557 laptop. When I first set up the machine in
January 2010, I was able to compile the FreeBSD 8-STABLE base system and
700 ports without any thermal issues.
Around mid-February 2010, I updated to a newer 8-STABLE. Since then, the
computer has been shutting down due to "critical temperatures" whenever
I run a CPU-intensive task for more than a few minutes. It is now
impossible to compile Firefox or OpenOffice.org.
The shutdowns are caused by TZ1, representing the CPU. The relevant
sysctl output is:
hw.acpi.thermal.tz1.temperature: 60.0C
hw.acpi.thermal.tz1.active: 1
hw.acpi.thermal.tz1.passive_cooling: 1
hw.acpi.thermal.tz1.thermal_flags: 0
hw.acpi.thermal.tz1._PSV: 95.0C
hw.acpi.thermal.tz1._HOT: -1
hw.acpi.thermal.tz1._CRT: 85.0C
hw.acpi.thermal.tz1._ACx: 71.0C 55.0C -1 -1 -1 -1 -1 -1 -1 -1
hw.acpi.thermal.tz1._TC1: 0
hw.acpi.thermal.tz1._TC2: 10
hw.acpi.thermal.tz1._TSP: 2
Notice how _PSV=95°C > _CRT=85°C. This looks very fishy to me. At 95°C,
the CPU should start throttling its speed, passively reducing
temperature. But before it gets a chance to do so, the system shuts down
due to reaching 85°C. I can work around this by overriding _CRT, setting
it to e.g. 99°C. But this clearly is a hack. Prior to some change in
FreeBSD, I did not experience any such problems.
I disassembled the DSDT. The threshold values are computed as follows:
Method (_PSV, 0, Serialized)
{
Return (Add (0x0AAC, Multiply (PSVT, 0x0A)))
}
Method (_CRT, 0, Serialized)
{
Return (Add (0x0AAC, Multiply (CRTT, 0x0A)))
}
The constants PSVT and CRTT are found in the following memory region:
OperationRegion (GNVS, SystemMemory, 0xC779BC9E, 0x0200)
Their actual values are PSVT=0x5F and CRTT=0x55, corresponding to a _PSV
threshold 10°C higher than _CRT.
All of this could be the BIOS' fault - a table of nonsense values set up
incorrectly by Dell. However, I never touched the BIOS since first
setting up the machine. The only thing that has changed is FreeBSD, not
the BIOS. Could this be some problem in FreeBSD's ACPI implementation?
Are the values being read or interpreted wrong?
I know manufacturers often provide sloppy, wrong DSDTs. But these values
would make even Windows shut down under moderate to high load. That
cannot be right.
I am happy to debug further if someone could give me pointers where to look.
- Bartosz
Bartosz Fabianowski
> active cooling is also on. Is that happening?
Temperature never drops below 55°C and so the fan is always running. As
far as memory serves me, this has been the case since day one. I have
not noticed any difference in fan noise at different temperature levels.
Considering how hot this machine is running, I would not be surprised if
the fan was always in its "high" setting.
> If the fan is running properly, have you checked that the airways
> aren't blocked by dust and/or fluff?
The laptop has feet of ~5mm height. I have extended that to about 1cm by
placing the computer on four stacks of post-it notes. This, again, has
been the case since day one. I added a few more millimeters of post-it
notes today and cleaned out any dust I could find. This might have
improved things slightly but temperature still exceeds 85°C when
compiling larger ports.
> Maybe Dell don't trust non-Windows OS to take care of passive
> cooling? Could be worth seeing if those values come up the same if
> you spoof some type of Windows as your OS, as detailed in the ACPI
> debugging section?
Yes, this is definitely something I will try. I thought that all the
magic would be present in the DSDT. But now that I think about it, of
course the BIOS could be changing the values read from the GNVS table
based on OS. I will try spoofing Vista or Windows 7 and report back my
findings.
- Bartosz
Ian Smith
It certainly seems a strange _CRT value, and silly having it less than
_PSV, though it seems unlikely that FreeBSD ACPI would be messing with
these values, which you appear to have tracked down correctly.
However there may be other reasons the laptop is getting even that hot.
You should hear the fan come on at 55C, and run faster at 71C, as active
cooling is also on. Is that happening? If the fan is running properly,
have you checked that the airways aren't blocked by dust and/or fluff?
> I disassembled the DSDT. The threshold values are computed as follows:
>
>
> Method (_PSV, 0, Serialized)
> {
> Return (Add (0x0AAC, Multiply (PSVT, 0x0A)))
> }
>
> Method (_CRT, 0, Serialized)
> {
> Return (Add (0x0AAC, Multiply (CRTT, 0x0A)))
> }
>
>
> The constants PSVT and CRTT are found in the following memory region:
>
>
> OperationRegion (GNVS, SystemMemory, 0xC779BC9E, 0x0200)
>
>
> Their actual values are PSVT=0x5F and CRTT=0x55, corresponding to a _PSV
> threshold 10°C higher than _CRT.
Yes, they're 95 and 85 respectively.
> All of this could be the BIOS' fault - a table of nonsense values set up
> incorrectly by Dell. However, I never touched the BIOS since first setting up
> the machine. The only thing that has changed is FreeBSD, not the BIOS. Could
> this be some problem in FreeBSD's ACPI implementation? Are the values being
> read or interpreted wrong?
>
> I know manufacturers often provide sloppy, wrong DSDTs. But these values
> would make even Windows shut down under moderate to high load. That cannot be
> right.
>
> I am happy to debug further if someone could give me pointers where to look.
>
> - Bartosz
Maybe Dell don't trust non-Windows OS to take care of passive cooling?
Could be worth seeing if those values come up the same if you spoof some
type of Windows as your OS, as detailed in the ACPI debugging section?
cheers, Ian
Bartosz Fabianowski
Overriding the _OS variable had no effect as the DSDT actually checks
_OSI. I applied the patch in kern/121504 and overrode _OSI with "Windows
2006". Unfortunately, this had no effect on thermal settings at all.
Any other ideas for what to try?
- Bartosz
Ian Smith
No, apart from maybe overriding _CRT and/or _PSV, perhaps swapping them?
You called changing these a hack, but a hack's fine if it works :)
My Thinkpad T23 has 90C _PSV, 96C _CRT, but I've yet to see it hit 90C;
the last buildworld got it to about 86C, and that was in our summer.
Perhaps see if you can get it to start passive cooling at say 80C, with
_CRT set at maybe 90C, to see whether passive cooling handles the load?
Apart from feeding it a can of air, hopefully someone else has an idea?
cheers, Ian
Bartosz Fabianowski
Intel seem not to have documented the maximal operating temperature for
this CPU (Core i7 Q720M). But overclocking enthusiast forums mention
automatic throttling from 100°C onward. So while I cannot be sure, I
think the CPU should survive just fine with a _CRT of more than 85°C.
> Something to the tune of:
>
> hw.acpi.thermal.tz0.passive_cooling=1 hw.acpi.thermal.user_override=1
> hw.acpi.thermal.tz0._PSV=75C
I can do that. But since the CPU is running at ~60°C when completely
idle, this will essentially force throttling whenever I do anything that
demands a bit of CPU. I bought a quad-core i7 specifically because I
want CPU power. Forcing the CPU to throttle all the time would remove
any advantage of having bought such an expensive CPU.
> * Is tz0 the only thermal zone you have on this machine?
All of this is TZ1. TZ0 does exist as well but reports a constant 26.8°C
with a _CRT of 127.0°C - not very interesting.
> * Are you using 'powerd' and, if so, what are the settings?
Yes, powerd is running with default settings. I can see dev.cpu.0.freq
going up and down so powerd seems to be working.
> * What does 'sysctl dev.cpu' say?
As the output is rather long, I put it at the end of this e-mail.
> Perennial favorite is to pry off the heatsink, clean and re-apply the
> grease in moderation.
I am very reluctant to do this. The laptop is barely three months old.
As long as it is still under warranty, I really do not want to take it
apart. Also, shaving off 3-4°C will not cut it anyway. To prevent the
spurious shutdowns without overriding _CRT, I would need the CPU to run
at least 10-15°C cooler.
- Bartosz
Output of sysctl dev.cpu:
dev.cpu.0.%desc: ACPI CPU
dev.cpu.0.%driver: cpu
dev.cpu.0.%location: handle=\_PR_.CPU0
dev.cpu.0.%pnpinfo: _HID=none _UID=0
dev.cpu.0.%parent: acpi0
dev.cpu.0.temperature: 55.0C
dev.cpu.0.freq: 1463
dev.cpu.0.freq_levels: 1597/35000 1463/31000 1330/27000 1197/23000
1064/19000 931/15000 814/13125 698/11250 581/9375 465/7500 349/5625
232/3750 116/1875
dev.cpu.0.cx_supported: C1/3
dev.cpu.0.cx_lowest: C1
dev.cpu.0.cx_usage: 100.00% last 500us
dev.cpu.1.%desc: ACPI CPU
dev.cpu.1.%driver: cpu
dev.cpu.1.%location: handle=\_PR_.CPU1
dev.cpu.1.%pnpinfo: _HID=none _UID=0
dev.cpu.1.%parent: acpi0
dev.cpu.1.temperature: 56.0C
dev.cpu.1.cx_supported: C1/3
dev.cpu.1.cx_lowest: C1
dev.cpu.1.cx_usage: 100.00% last 500us
dev.cpu.2.%desc: ACPI CPU
dev.cpu.2.%driver: cpu
dev.cpu.2.%location: handle=\_PR_.CPU2
dev.cpu.2.%pnpinfo: _HID=none _UID=0
dev.cpu.2.%parent: acpi0
dev.cpu.2.temperature: 54.0C
dev.cpu.2.cx_supported: C1/3
dev.cpu.2.cx_lowest: C1
dev.cpu.2.cx_usage: 100.00% last 500us
dev.cpu.3.%desc: ACPI CPU
dev.cpu.3.%driver: cpu
dev.cpu.3.%location: handle=\_PR_.CPU3
dev.cpu.3.%pnpinfo: _HID=none _UID=0
dev.cpu.3.%parent: acpi0
dev.cpu.3.temperature: 54.0C
dev.cpu.3.cx_supported: C1/3
dev.cpu.3.cx_lowest: C1
dev.cpu.3.cx_usage: 100.00% last 500us
dev.cpu.4.%desc: ACPI CPU
dev.cpu.4.%driver: cpu
dev.cpu.4.%location: handle=\_PR_.CPU4
dev.cpu.4.%pnpinfo: _HID=none _UID=0
dev.cpu.4.%parent: acpi0
dev.cpu.4.temperature: 56.0C
dev.cpu.4.cx_supported: C1/3
dev.cpu.4.cx_lowest: C1
dev.cpu.4.cx_usage: 100.00% last 500us
dev.cpu.5.%desc: ACPI CPU
dev.cpu.5.%driver: cpu
dev.cpu.5.%location: handle=\_PR_.CPU5
dev.cpu.5.%pnpinfo: _HID=none _UID=0
dev.cpu.5.%parent: acpi0
dev.cpu.5.temperature: 56.0C
dev.cpu.5.cx_supported: C1/3
dev.cpu.5.cx_lowest: C1
dev.cpu.5.cx_usage: 100.00% last 500us
dev.cpu.6.%desc: ACPI CPU
dev.cpu.6.%driver: cpu
dev.cpu.6.%location: handle=\_PR_.CPU6
dev.cpu.6.%pnpinfo: _HID=none _UID=0
dev.cpu.6.%parent: acpi0
dev.cpu.6.temperature: 54.0C
dev.cpu.6.cx_supported: C1/3
dev.cpu.6.cx_lowest: C1
dev.cpu.6.cx_usage: 100.00% last 500us
dev.cpu.7.%desc: ACPI CPU
dev.cpu.7.%driver: cpu
dev.cpu.7.%location: handle=\_PR_.CPU7
dev.cpu.7.%pnpinfo: _HID=none _UID=0
dev.cpu.7.%parent: acpi0
dev.cpu.7.temperature: 54.0C
dev.cpu.7.cx_supported: C1/3
dev.cpu.7.cx_lowest: C1
dev.cpu.7.cx_usage: 100.00% last 500us
Bartosz Fabianowski
> temperature below the critical shutdown level.
Ideally, yes. I do not need much CPU power throughout most of the day.
But when a larger update comes along and it is time to rebuild say
OpenOffice.org, I would really like to exercise the CPU to its fullest.
This is why I bought it after all.
> [snip]
>
> The latter will ensure that your fan will run at highest setting for
> at least 2 minutes, even if temperature drops below 71C.
Very interesting tips. I will experiment with different settings and see
whether I can make the machine run cooler. A very low-tech solution I am
planning to apply later tonight is to hoover all air vents. Even though
the machine is very new, there might be some dust stuck somewhere.
> If this is not sufficient, you can also modify your ASL
I did think of that. Unfortunately, the ASL produced by acpidump -d does
not recompile, producing over 200 errors. They all have to do with
references to a non-existent table. I will probably be able to solve
them all by fixing a single typo somewhere. Again something I will look
into for sure.
> If you go this route, I would strongly recommend reading thermal
> chapter of the ACPI spec -- it is short, well written and contains
> well-commented example.
I have the ACPI spec here - will have a look at that chapter, thanks.
> please, understand that this route is more then moderately dangerous
> and could cause harm to your system.
Yes, I am aware of that. Then again, I have a system that out-of-the-box
is running way too hot. If I just ignore the issue, the system may harm
itself. Trying to do something about it IMHO is the better way.
> If all of the above fails, I would dare say that your system was not
> designed to withstand the use you have intended for it and you will
> need to resort to hardware modifications (more powerful fan, case
> fan, water cooling, etc.).
Case fan, water cooling - now that will make for one interesting laptop :).
Having read various forums, I am beginning to think the system was
really not designed to handle its CPU's thermal requirements. Apparently
Dell has a questionable track record when it comes to thermal design.
Still, I paid for a piece of hardware and now I expect to use it.
Granted, this machine might have been built to run under Windows. But
the fan control settings and thermal thresholds would all be the same
there. So even with the supplied OS, the machine would be running too
hot and shutting down. This is clearly not acceptable. I think I will
contact Dell support and see what they can do for me. Of course,
first-level support is just there to read off scripts... I might have a
difficult time getting through to someone who actually understands the
issue.
- Bartosz
Bartosz Fabianowski
> USB-powered fans when doing buildworld and/or compiling something
> comparably heavy.
I have no problem with using such a contraption. What still has me
confused though is that I built world and 700 ports before hitting the
first thermal-related shutdown. How come the problem only appeared after
a couple of months? Dust buildup - that quickly?
> It is really hard to second guess what Windows does if _PSV> _CRT.
True, it might be doing some magic. The only Windows installation I have
is inside VirtualBox - so I cannot investigate what it would do under
these circumstances.
Right now, I am running with _PSV and _CRT swapped, as per Ian Smith's
suggestion (_PSV=85.0C and _CRT=95.0C). While building KDE, the machine
just hit 85°C. Passive cooling successfully prevented the temperature
from increasing beyond 87°C - but at huge cost: it reduced the CPU speed
to 119 MHz.
I have upgraded the two stacks of post-it notes at the back of the
machine to packs of handkerchiefs. This increases the space between desk
and laptop from 1cm to 3cm and seems to reduce temperatures a bit.
Dell's stock laptop feet are only 5mm tall... so having to do this is
odd yet again.
- Bartosz
Rui Paulo
>> I use $20.00 USD aluminum cooling pad with the pair of built-in
>> USB-powered fans when doing buildworld and/or compiling something
>> comparably heavy.
>
> I have no problem with using such a contraption. What still has me confused though is that I built world and 700 ports before hitting the first thermal-related shutdown. How come the problem only appeared after a couple of months? Dust buildup - that quickly?
In those few months, dust could've easily clobbered the air vents and made the fan unable to remove the heat from inside the computer.
Regards,
--
Rui Paulo
Ian Smith
>
> > I would not override _CRT
>
> Intel seem not to have documented the maximal operating temperature for
> this CPU (Core i7 Q720M). But overclocking enthusiast forums mention
> automatic throttling from 100�C onward. So while I cannot be sure, I
> think the CPU should survive just fine with a _CRT of more than 85�C.
I think so too, but suspect those overclockers would be talking about
desktop boxes, not laptops? I've seen few laptop _CRT levels at 100C.
Personally I suspect they've just got the _PSV and _CRT backwards (95
vs 85C) and that swapping those should give safe passive and critical
values .. it could never make sense to have _PSV hotter than _CRT; if
they'd intended making _PSV unavailable it should be set -1 like _HOT.
Some things to try anyway, along with Alexandre's good clues re thermal
polling interval etc - and maybe the cheap cooling pad to boot, or even
a more heavy duty one; you likely don't run buildworlds on your lap? :)
> > Something to the tune of:
> >
> > hw.acpi.thermal.tz0.passive_cooling=1 hw.acpi.thermal.user_override=1
> > hw.acpi.thermal.tz0._PSV=75C
>
> I can do that. But since the CPU is running at ~60�C when completely
Sure, but there still should be a discernable fan speedup around 71C; if
not then your active cooling may not be working right either. A length
of plastic tubing makes a useful 'stethoscope' for listening to fans.
> idle, this will essentially force throttling whenever I do anything that
> demands a bit of CPU. I bought a quad-core i7 specifically because I want CPU
> power. Forcing the CPU to throttle all the time would remove any advantage of
> having bought such an expensive CPU.
Indeed. You might ask on freebsd-mobile@ is anyone else has one of
these beasties, to see whether yours is behaving true to type?
As others have mentioned recently as well as Alexandre since, CPU duty
cycle throttling seems mostly ineffective on modern multi-cores, and is
likely best disabled, leaving stepping between fewer real frequencies to
make positive differences in power consumption, thus heat generation.
If you do reduce the number of frequencies as mentioned, you may want
to reconsider powerd's default values .. only playing around will get
you the best optimum between responsiveness, performance and cooling.
> > * Is tz0 the only thermal zone you have on this machine?
>
> All of this is TZ1. TZ0 does exist as well but reports a constant 26.8�C
> with a _CRT of 127.0�C - not very interesting.
Definitely no active or passive cooling parameters at all for tz0?
[..]
> I am very reluctant to do this. The laptop is barely three months old. As
> long as it is still under warranty, I really do not want to take it apart.
> Also, shaving off 3-4�C will not cut it anyway. To prevent the spurious
> shutdowns without overriding _CRT, I would need the CPU to run at least
> 10-15�C cooler.
I guess google would reveal any overheating problems people with this
model may be having under Windows, or not? You may just have a faulty
unit, and if so installing W on it may be needed for a warranty claim;
sadly, the first thing they might blame problems on is an 'other' OS.
> dev.cpu.0.freq: 1463
> dev.cpu.0.freq_levels: 1597/35000 1463/31000 1330/27000 1197/23000 1064/19000
> 931/15000 814/13125 698/11250 581/9375 465/7500 349/5625 232/3750 116/1875
I'd be interested to see exactly which of those frequencies remain after
you disable p4tcc or acpi_throttle, but maybe you could post dmesg.boot
to see which cpufreq drivers are now being used, to save some guesswork?
Also, is that 35 Watts at full speed for the whole package, all 4 cores?
cheers, Ian
Bartosz Fabianowski
> the system performance with some kind of CPU-bound benchmark.
Unfortunately, the old kernel is long gone.
> Theoretically, your laptop should be able to run with CPU stuck at
> its highest frequency without shutting down.
I agree. This is precisely what I am trying to achieve.
> ISTR there are few CPU frequency drivers that could use some
> disabling.
Disabling p4tcc changed nothing. Disabling apci_throttle as well finally
reduced the frequencies from 13 to 6. I have yet to see what effect this
will have on system performance.
> Does 'hw.acpi.thermal.tz1.active' show value of '0' an this point?
> Does it go back to '1' when temperature drops below 71C? Does it ever
> show '-1'?
The value varies between 0 and 1. When the machine is idling,
temperature tends to drop to 55°C and then hover there. As this is
exactly the lowest _ACx threshold, active stays at 0.
Just as I was writing this e-mail, the temperature finally reached 54°C
and active went to -1. The fan is still on, however.
- Bartosz
Bartosz Fabianowski
minutes, I would be a bit disappointed. Still, I guess I could accept
it. What I cannot accept is a silly setup where instead of throttling
the CPU as appropriate, the machine shuts down. I am logged in remotely
most of the time and it is a real pain when the machine goes down in the
middle of the day.
- Bartosz
Dana Myers
>
>> Theoretically, your laptop should be able to run with CPU stuck at
>> its highest frequency without shutting down.
>
> I agree. This is precisely what I am trying to achieve.
[Coming into this thread late]
Why do you think that's true? While this is desirable, it's
certainly possible that the machine was built with a thermal
design that is unable to achieve this, and depends on
software to reduce CPU P-state to avoid shut-down.
One example I've seen is the Acer Ferrari 3400, which would
run the CPU at P0 (full clock rate) by default, but after a
few minutes of aggressive use (like, building a kernel), would
drop the highest CPU state to P1 (10% slower) via a GPE. This
notebook simply can't run the CPU at a full clock rate load
for more than a few minutes before it overheats, apparently
by design.
Thermal design in notebooks seems to be quite tricky.
Dana
Dana Myers
> If the CPU really cannot run at maximal speed for more than a few
> minutes, I would be a bit disappointed.
It's in a notebook, afterall. There's not a lot of room for optimal
thermal design
in there.
> Still, I guess I could accept it. What I cannot accept is a silly
> setup where instead of throttling the CPU as appropriate, the machine
> shuts down.
Agreed. I came into this thread late and admit I'm not sure what support
for CPU throttling is in FreeBSD. Ideally, Notify() events on the CPU
objects
will cause dynamic re-evaluation of the associated _PPC object.
Dana
Bartosz Fabianowski
> support for CPU throttling is in FreeBSD. Ideally, Notify() events on
> the CPU objects will cause dynamic re-evaluation of the associated
> _PPC object.
There seems to be plenty of support for throttling. But if the BIOS
provides bogus _PSV and _CRT values, there is only that much FreeBSD can
do. That is how the thread started, with the question: "How come _PSV >
_CRT on my machine and what should I do about it?"
- Bartosz
Dana Myers
My apologies. Indeed, a lying BIOS is hard to deal with,
especially when the system really depends on the BIOS
to keep things sane (as in this case).
Dana
Ian Smith
> Dana Myers wrote:
Unfortunately this issue appears only to be symptomatic of a larger set
of overheating problems with this laptop. I googled "overheating Dell
Studio 1557" and the results are plentiful and not at all encouraging.
I'd particularly recommend reading through the 8-page thread of the top
hit: http://forum.notebookreview.com/showthread.php?t=432243 .. which
includes lots of useful info, including ways to work replacement or
refund, and a good photo of fan and (dual) heatpipes/sinks arrangement.
Apparently models made before sometime in January had a single heat pipe
for CPU and GPU (where GPU heat seems to be the main issue, especially
for gamers of course) but even the January dual heat pipe redesign and a
BIOS update seems not to have resolved issues for many. Dell recently
replaced the ATI GPU with another model (again, dmesg may be helpful)
and in some cases have bumped the power supply from 90 to 130W, though
there's little indication that these issues are yet actually solved.
cheers anyway, Ian
Bartosz Fabianowski
> slowing down your machine without really cooling the CPU.
After a couple of days of testing, I believe this did the trick. I
reduced the number of frequencies as per Alexandre's tip. I also swapped
_PSV and _CRT for good measure (_PSV is now 85°C and _CRT 95°C).
I just rebuilt OpenOffice.org, using a parallel build that stresses all
cores. The machine did not overheat. The highest temperature it reached
was 84°C for a few minutes. This is still high but not too high.
I will try hoovering the air vents and keep my eye on things. If they
stay stable from here, I will not be bothering with Dell support.
Thanks for all the tips,
- Bartosz
Ian Smith
> > I think some of the frequencies, provided by acpi_throttle and TCC are
> > slowing down your machine without really cooling the CPU.
>
> After a couple of days of testing, I believe this did the trick. I reduced
> the number of frequencies as per Alexandre's tip. I also swapped _PSV and
> _CRT for good measure (_PSV is now 85°C and _CRT 95°C).
>
> I just rebuilt OpenOffice.org, using a parallel build that stresses all
> cores. The machine did not overheat. The highest temperature it reached was
> 84°C for a few minutes. This is still high but not too high.
A result, good.
> I will try hoovering the air vents and keep my eye on things. If they stay
> stable from here, I will not be bothering with Dell support.
Great. I'd still like to know what your remaining frequencies are, as I
couldn't correlate your previous full set with the throttling N * 12.5%?
cheers, Ian
Bartosz Fabianowski
> couldn't correlate your previous full set with the throttling N * 12.5%?
The remaining frequencies are:
1597/35000 1463/31000 1330/27000 1197/23000 1064/19000 931/15000
Additionally, I do not remember how many CX states I had before - but I
am pretty sure that it was more than just one. Now, the only CX state
remaining is C1/3.
Interestingly, disabling either the p4tcc or the acpi_throttle driver on
its own does nothing to cut down on frequencies. Only when both are
disabled via hints does the list drop from 13 frequencies to the 6 above.
- Bartosz
Kevin Oberman
> From: Bartosz Fabianowski <fre...@chillt.de>
> Sender: owner-fre...@freebsd.org
This is by design. TCC and throttling do the exact same thing, but TCC
does it better, so if only throttling is available , it is used and when
both are available, TCC is used.
Again, there techniques a=were designed for thermal management, not
power management. (TCC is Thermal Control Circuit) They are very close
to useless for power management and I have been campaigning for some
time to have them pulled from the FreeBSD power management system. EST
and similar tools actually do power management well.
Now, for a really weird suggestion, one that makes no sense, but works
perfectly on my laptop:
In /boot/loader.conf:
hint.p4tcc.0.disable="1"
hint.acpi_throttle.0.disable="1"
hw.pci.do_power_nodriver="2" (also, try 3, but my system hangs with 3)
Then build a kernel WITHOUT "device cpufreq" (or nodevice cpufreq)
I would expect this to provide NO frequency control, but I get (and use)
the five frequencies provided by EST: dev.cpu.0.freq_levels: 2000/27000
1600/22600 1333/19666 1066/16733 800/13800
Testing has shown that this is a REAL power savings.
--
R. Kevin Oberman, Network Engineer
Energy Sciences Network (ESnet)
Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab)
E-mail: obe...@es.net Phone: +1 510 486-8634
Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751
Ian Smith
> The remaining frequencies are:
>
> 1597/35000 1463/31000 1330/27000 1197/23000 1064/19000 931/15000
Thanks. From that, turns out all of the others, requoting:
> dev.cpu.0.freq_levels: 1597/35000 1463/31000 1330/27000 1197/23000 1064/19000
> 931/15000 814/13125 698/11250 581/9375 465/7500 349/5625 232/3750 116/1875
were just throttling freqs, 7/8 of downto 1/8 of the now lowest 931MHz,
while those remaining come to 12, 11, 10, 9, 8 and 7 * ~133MHz (FWIW)
> Additionally, I do not remember how many CX states I had before - but I am
> pretty sure that it was more than just one. Now, the only CX state remaining
> is C1/3.
Same as the previous dev.cpu data you showed, anyway.
> Interestingly, disabling either the p4tcc or the acpi_throttle driver on its
> own does nothing to cut down on frequencies. Only when both are disabled via
> hints does the list drop from 13 frequencies to the 6 above.
That'd be right; they'll each try to attach, one claiming priority.
Ah, I see Kevin just chimed in about that, and better said.
cheers, Ian