dev.cpu.X.freq does reflect the current frequency; I don't know whether or how any internal clock throttling might be exposed.
From what I have seen, dev.cpu.X.freq always retains the value I set it to. Internal CPU throttling does not seem to be reported this way.
a bit of hunting found your previous overheating problems on a Dell Studio 1557 from April last year: and your eventual apparent solution which included some fiddling with thermal parameters but primarily by disabling p4tcc and acpi_throttle
Yes, that thread described the issues I had with my previous laptop before Dell exchanged it. I never posted an actual solution as I never found one. The problem only went away because the laptop went away. Disabling p4tcc and acpi_throttle may have seemed to address the problems at first - but longer-term evaluation showed that the issues persisted unchanged.
hint.p4tcc.0.disabled="1" hint.acpi_throttle.0.disabled="1"
I just tried this on my current Dell Studio 1558, with devastating results. The first boot attempt ended with the machine shutting down due to overheating while loading the kernel. I let it cool down a bit and then booted again. This time, I got to my desktop - with a CPU temperature of 95°C. If the DSDT was fixed, the machine would have shut down at this point.
I only got down the temperature by reducing the maximal temperature to 1.2GHz again. With the above settings, the machine is idling at 80°C now and very sluggish - some internal throttling appears to be active again.
tz0 looks to be a fan. It seems unlikely that any temp. sensor inside a machine with CPU temp. at 82C could possibly be as low as 26.8C, so this value is likely as bogus as the 0.0C CPU reported by tz1.
Yes, the 26.8°C is bogus. It never changes. Unfortunately, I have not found a way to fix this reading. The two thermal zones are implemented very differently in the DSDT and I have only managed to fix tz1. However, there is no second fan inside the laptop. I have taken it apart down to the last screw. There is one fan only and that corresponds to tz0.
This fan should come on at 55C and run fastest above 71C. If your CPU is at 82C and the fan isn't running flat out, it'd overheat for sure. tz0.active is -1, not running - but maybe the BIOS is controlling it?
Yes, the BIOS appears to control the fan. The thresholds exposed via ACPI seem to be purely informative. Whether I fix the DSDT so that temperature readings work or not, the fan turns on at 55°C and speeds up at 71°C. It never spins down again after that as the CPU keeps running very hot.
_ACx is N/A here, unless there's a separate CPU fan? Anyway at bogus 0.0C it's never going to trigger passive or active cooling. You said before that with the fixed DSDT to get proper temperature reading here, it shut down due to over temperature, which of course it should .. does that fixed DSDT include fixing detected tz0 temperature .. if so the fan might behave itself without having to use .thermal.user_override=1
See above: Fixing the DSDT makes tz1 work. tz0 remains broken.
Are you limiting it to 1333 manually, or with powerd's -M switch?
I have tried both. It appears to make no difference whether I use powerd -M or just set dev.cpu.0.freq directly.
Clearly including p4tcc and/or acpi_throttle N*12.5% rates; compare to dev.est.0.freq_settings below to figure the freqs added by throttling. Hopefully this machine will respond as well to disabling both methods as your earlier one, as you reported here (same subject, later thread):
See above: Unfortunately, the machine did nor respond well at all. Instead, it is overheating even worse.
Try using C2. It helps more with some CPUs than others, but it's worth a try for further reducing heat, especially at idle. Ie in rc.conf: performance_cx_lowest="C2" economy_cx_lowest="C2"
I have set dev.cpu.X.cx_lowest="C2" at run-time. If I understand correctly, this should achieve the same effect. The CPU does not seem to ever make it to C2 though, even after I enable it:
%sysctl dev.cpu | grep cx_usage dev.cpu.0.cx_usage: 100.00% 0.00% last 270us dev.cpu.1.cx_usage: 100.00% 0.00% last 399us dev.cpu.2.cx_usage: 100.00% 0.00% last 403us dev.cpu.3.cx_usage: 100.00% 0.00% last 404us dev.cpu.4.cx_usage: 100.00% 0.00% last 323us dev.cpu.5.cx_usage: 100.00% 0.00% last 313us dev.cpu.6.cx_usage: 100.00% 0.00% last 174us dev.cpu.7.cx_usage: 100.00% 0.00% last 137us
> dev.est.0.freq_settings: 1734/45000 1733/45000 1599/41741 1466/38582 > 1333/35485 1199/32426 1066/29457 933/26552 With throttling disabled, those are what you should be left with for dev.cpu.0.freq_levels.
Yes, these are the frequencies I have available now. 1333 makes the machine idle around 85°C, 1999 leads to 78-80°C.
- Bartosz _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[email protected]"
