ACPI Thermal Control on HP DC7600

Hi All,

Seem to be having thermal control issues. No matter what we do/try we can find nothing that indicates FreeBSD knows anything about thermal control on these systems. Work the living daylights out of the systems and the fan(s) stay(s) at idle, under other os's they vary according to work load ... We are trying to get rid of them other OS's, we want them gone!

I suspect it's the fault of HP/COMPAQ not nessesarly following the rules! (acpi specs)

We have searched and failed to find an answer that works or gives any resolution of the issue, most wind up being about laptops and saving power, we are concerned about heat, not power at this point in time.

We are stumped and in need of assistance.

FreeBSD:
Code:
FreeBSD 8.2-RELEASE #0: Fri Feb 18 02:24:46 UTC 2011
    root@almeida.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386

Systems:
Code:
HP DC7600 CMT

BIOS:
Code:
Version: 1.61 (Current)

We have many of these systems with two different MB's, for this thread our concern is with:
Code:
Mainboard Manufacture: Hewlett-Packard
Model: 09F0h
OMAHA & UTAH PCB REV. A

With either a P4-3.2Mhz or PD-3.4Mhz CPU.

They have the same:
Code:
ACPI APIC Table: <COMPAQ LAKEPORT>

There are a couple of errors in dmesg:
Code:
acpi0: reservation of 0, a0000 (3) failed
acpi0: reservation of 100000, cff00000 (3) failed

I've read the first one is mem < VGA
The second one is Option ROM's
And both can be safely ignored.

Then on the:
Code:
CPU: Intel(R) Pentium(R) 4 CPU 3.20GHz (3189.79-MHz 686-class CPU)
  Origin = "GenuineIntel"  Id = 0xf4a  Family = f  Model = 4  Stepping = 10
  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=0x649d<SSE3,DTES64,MON,DS_CPL,EST,CNXT-ID,CX16,xTPR>
  AMD Features=0x20100000<NX,LM>
  AMD Features2=0x1<LAHF>
  TSC: P-state invariant

Systems there is this in dmesg:
Code:
vga0: <Generic ISA VGA> at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0
acpi_perf0: <ACPI CPU Frequency Control> on cpu0
acpi_perf0: failed in PERF_STATUS attach
device_attach: acpi_perf0 attach returned 6
acpi_perf1: <ACPI CPU Frequency Control> on cpu1
acpi_perf1: failed in PERF_STATUS attach
device_attach: acpi_perf1 attach returned 6
acpi_perf0: <ACPI CPU Frequency Control> on cpu0
acpi_perf0: failed in PERF_STATUS attach
device_attach: acpi_perf0 attach returned 6
est0: <Enhanced SpeedStep Frequency Control> on cpu0
est: CPU supports Enhanced Speedstep, but is not recognized.
est: cpu_vendor GenuineIntel, msr 102d0000102d
device_attach: est0 attach returned 6
p4tcc0: <CPU Frequency Thermal Control> on cpu0
acpi_perf1: <ACPI CPU Frequency Control> on cpu1
acpi_perf1: failed in PERF_STATUS attach
device_attach: acpi_perf1 attach returned 6
est1: <Enhanced SpeedStep Frequency Control> on cpu1
est: CPU supports Enhanced Speedstep, but is not recognized.
est: cpu_vendor GenuineIntel, msr 102d0000102d
device_attach: est1 attach returned 6
p4tcc1: <CPU Frequency Thermal Control> on cpu1
Timecounters tick every 1.000 msec

Yet on the:
Code:
CPU: Intel(R) Pentium(R) D CPU 3.40GHz (3389.15-MHz 686-class CPU)
  Origin = "GenuineIntel"  Id = 0xf64  Family = f  Model = 6  Stepping = 4
  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=0xe4bd<SSE3,DTES64,MON,DS_CPL,VMX,EST,CNXT-ID,CX16,xTPR,PDCM>
  AMD Features=0x20100000<NX,LM>
  AMD Features2=0x1<LAHF>
  TSC: P-state invariant

Systems it does not fail! ??
Code:
vga0: <Generic ISA VGA> at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0
est0: <Enhanced SpeedStep Frequency Control> on cpu0
p4tcc0: <CPU Frequency Thermal Control> on cpu0
est1: <Enhanced SpeedStep Frequency Control> on cpu1
p4tcc1: <CPU Frequency Thermal Control> on cpu1
Timecounters tick every 1.000 msec

However, Under hw.acpi on ALL systems, there are no thermal/temp(erature) entries.
Code:
# sysctl hw.acpi
hw.acpi.supported_sleep_state: S1 S3 S4 S5
hw.acpi.power_button_state: S5
hw.acpi.sleep_button_state: S1
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

Code:
sysctl -a | grep tempe
Returns nothing.

According to the HP spec sheet they are acpi thermal capable.

And doing:
Code:
acpidump -dt
Though I don't know ASL, It appears the functionality is there.

What's up? What are we missing? What's our next step towards a resolution?

We tried mbmon and others without success.

Thanks

-Enjoy
fh : )_~
 
Work the living daylights out of the systems and the fan(s) stay(s) at idle, under other os's they vary according to work load ...

This is very strange, normally the OS doesn't control the fan speed, the BIOS takes care of it (although the OS *may* adjust it). I've run BSD on *many* different systems, including HP workstations and P4/P4D systems, and never experienced this kind of issue.

I don't know how desperate you want FreeBSD on these systems, but you can probably set the fan to "always on" in the BIOS (may be loud...) or construct something with a custom cooling, for example if you get a good CPU cooler for ~20-30 euro, you probably can just leave the 120mm running at a constant speed at 7V without too much heat problems or noise...
It sounds like you're in a business environment, getting different systems may be more cost efficient ...
 
I agree, It is strange, but unfortunate fact!

Business no, Organization yes, The cost is volunteer time!

Replacements ????, these systems were loaned/donated to the cause. We had a couple hundred of these systems donated and not all of the same models have this issue, it's got to be either MB or CPU issue and the other OS seems able to deal with it! Under FreeBSD I am unable to control the fans, or retrieve the temperatures on any of the HPDC7600's, this I believe is the fault of HP/Compaq not following the ACPI rules they themselves in part defined!

It's looking like the common is the 3.2GHz 640 CPU prior to rev 5, though I have not yet had the time to check/test them all. According to Intel's site/specs it should work on all the 640 CPU's except one, it apparently has a bug and is a 1.8GHz IIRC. (maybe 2.8GHz)

We don't actually own the hardware, I have the OK to call the donor at a specific time today to try and get approval to swap a CPU from a system that works fine onto a MB of one that doesn't to determine if it is the CPU. If it's a hardware issue, the donor may swap them out with us, it's not like they don't have plenty of them!

If worse comes to worse, I do have positions that I can use these systems where the fan set on high in the BIOS won't affect the human operator. There are times when the hearing impaired have the advantage! :)

Thanks

-Enjoy
fh : )_~
 
Back
Top