PowerMac7_2_PlatformPlugin.kext remark and questions (work around temperature/power sensor problem)
PowerMac7_2_PlatformPlugin.kext remark and questions (work around temperature/power sensor problem)
- Subject: PowerMac7_2_PlatformPlugin.kext remark and questions (work around temperature/power sensor problem)
- From: Jonas Maebe <email@hidden>
- Date: Mon, 23 Feb 2009 00:17:09 +0100
Hello,
PowerMac7_2_PlatformPlugin.kext is not open source since 10.3.4, the
first Mac OS X version to support the June 2004 G5's, of which I have
one (that's the PowerMac7,3 platform, but it uses the same kext as the
PowerMac7,2 for thermal control). My G5's cpu B fans are constantly
spinning at 300 rpm since a while, which is basically the "idle"
speed. As a result, cpu A's fans are working overtime (since cpu A is
above cpu B, it gets most of the extra heat).
I have installed Linux to be able to look at the values returned by
all sensors (the fans behave more or less the same there). By enabling
the debug statements in its platform driver (therm_pm72.c) and by
adding some more, it seems that most of the sensors for cpu B are off:
they consistently returns somewhat higher values than the one of cpu A
for the current, and lower ones for the temperature (cpu A is above
cpu B so it's logical that it gets hotter -- but note that the "raw
temperature" reading for cpu A and B is usually quite similar, but the
diode scaling factor and offset is different resulting in lower
calculated temperatures for cpu B).
As a result, the fan PID algorithm considers the temperature of cpu B
well within range all the time (higher power consumption -> higher
acceptable temperature), and does not spin up its fans. I have had the
cpu's temperature sensors recalibrated using an Apple Service
Diagnostic CD, but that did not help (it did not report any errors
either).
On Linux, I can work around it by simply setting the fan speeds for
cpu B equal to those of cpu A all the time. This may not be safe in
principle, but it certainly seems safer than locking the fans at 300
rpm (and it's less noisy too).
I'd like to also work around it in Mac OS X. As mentioned earlier, the
PowerMac7_2_PlatformPlugin.kext is not open source, hence I cannot
change that code. This kext however contains an Info.plist with many
tweakable settings. Unfortunately, they do not seem to be actually
taken into account. I've tried setting the output-min key for all cpu
fans in that file to 1600 instead of to 300, but after rebooting the
fans for both cpu A and B still dropped below that threshold. I've
also changed the SensorIDArray of the PowerMac7_3_CPUCoolingCtrlLoop
to reference cpu A's temperature and power sensors twice (rather than
first those of cpu A and then those of cpu B), and the same with the
SensorIDArray in the PM72-CP-ID-datasets, but that did not change
anything either.
Now, first a remark about the plist: the CtrlLoopArray key contains
PID datasets for cpu A (item 4 in the array) and cpu B (item 5 in the
array). However, for cpu A the PM72-CPU-PID-datasets property contains
settings for a 1.6GHz(90W), 1.8GHz(100W) and 3 variants of a 2GHz cpu
(90W, 100W, 110W), while for cpu B there are only settings for the
various 2GHz ones. My machine is a dual 1.8GHz, so I'm wondering
whether this may be an omission. Or maybe it's just another indication
that those settings are not used (I guess the settings are read/used
from the eeprom instead?)
Second, some questions:
a) where can I file a request for open sourcing
PowerMac7_2_PlatformPlugin.kext? Via a bug report, via contacting
ADC, ...?
b) Is there a way to modify the plist of
PowerMac7_2_PlatformPlugin.kext so that the PID loop for cpu B uses
the sensor readings of cpu A as input? (and also its temperature diode
scaling factor and threshold -- I guess this would be the sticker in
any case)
c) If b) or another change to Info.plist cannot solve the problem, can
any tell me the way to manually set the temperature and current diode
scaling factors in the eeprom? (since the Apple Service Diagnostic cd
can do it, there obviously is a way to do so)
d) There is still the AppleHWSensor project. This one is open source,
and with Bill Siegrist's kind help I've been able to build it.
However, while in theory it would allow intercepting the reads from
cpu B's sensors and redirect them to cpu A's (via the AD741x driver),
it would not help with the temperature diode scaling factors (I could
of course try to "pre-scale" them based on the fact that I know the
scaling/offset values of the "good" and the "bad" diodes -- but this
might trigger alarms elsewhere if this results in the returned values
being outside of the expected range).
e) Any other options? (besides having my cpu and/or motherboard
replaced -- which would probably cost more than getting a second hand
G5)
Thanks,
Jonas
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden