Hi Jean, Jean Delvare wrote: > OK, great :) The /usr/local variants should always be before the /usr > variants in $PATH, but depending on the distribution and/or the user, > it might not actually be the case. > Suse 10.0 in my case > You may have noticed that I have been committing the user-space part of > the W83687THF support to CVS already. I hadn't, but now that you mention it, I see that now in the Changes File. I notice that the version number has changed from 2.9.3 to 2.10.0. As an aside, I also notice that the projected release date for 2.10.0 is incorrect ;) > I also modified the Linux 2.4 w83627hf driver to fully support the W83687THF chip. I still need to > rework the 2.6 patch based on what I found in the datasheet, and then > we'll have to work on a sample configuration file for the chip. I hope > to get all this done by the end of the week. Stay tuned! :) > Sounds good pretty good to me! :) > Steven Karatnyk wrote: > > >> Anyways, here's the successful output: >> (...) >> w83687thf-isa-0290 >> Adapter: ISA adapter >> in0: +1.10 V (min = +0.70 V, max = +1.87 V) >> > > Most probably your CPU Core voltage. Is it correct? What's your CPU? > Yes, that looks right. Its an A64 3000. I believe its Kpowersave that is controlling the dynamic CPU throttling (multiplier and voltage), and that its default idle values are 5x200 @1.1V (which is, I believe, the AMD C'n'Q defaults). Eventually I will look more closely into this as I would like to provide my own throttling config settings [given under Windows I can user define, with the user app/driver Crystalcpuid, a 5x200 @ 0.9V idle values no problem .... in my case, trying to drop the multiplier or V any further completely freezes the system .... although I know someone who can drop to 4x200 on the same chip ]. > >> in1: +1.52 V (min = +2.54 V, max = +2.11 V) ALARM >> > > I'd guess this is the AGP voltage (nominal is +1.5V). > I agree. >> in2: +3.30 V (min = +2.86 V, max = +1.66 V) ALARM >> > > And this could be +3.3V. > Agree. >> in3: +2.99 V (min = +2.05 V, max = +3.36 V) >> in4: +2.59 V (min = +3.49 V, max = +2.14 V) ALARM >> in7: +2.94 V (min = +0.16 V, max = +0.42 V) ALARM >> > > These ones are probably greater voltages (+5V, +12V...) scaled down. Or > in4 may be Vdimm. > I think in4 is the Vdimm. IIRC, I have it set at 2.6V in the BIOS. Will have to check, but think its a safe bet. >> in8: +3.30 V (min = +0.38 V, max = +3.14 V) ALARM >> > > I'd guess 3VSB (same as +3.3V but when your system is in standby mode.) > Sounds reasonable. >> fan1: 1328 RPM (min = 9375 RPM, div = 8) ALARM >> fan2: 1339 RPM (min = 1016 RPM, div = 8) >> fan3: 0 RPM (min = 6136 RPM, div = 2) ALARM >> > > If you only have these two slow fans in the box, that looks OK. > Yes, CPU fan and an exhaust. RPM's are correct. There is a third fan (PSU) but it lacks monitoring capability ... although I imagine a modification could correct that, but I'm not certain if there is a 3rd fan header on the mobo... would have to check manual. >> temp1: +39?C (high = -122?C, hyst = -41?C) sensor = diode ALARM >> temp2: +39.0?C (high = +80?C, hyst = +75?C) sensor = diode >> temp3: +59.0?C (high = +80?C, hyst = +75?C) sensor = diode >> > > May be OK too. You should set temp1's limits to something more > reasonable though. > Temp3 is definitely CPU, but it looks a bit off .... I suspect the lm90 output (CPU Temp: +54.4?C) is closer to accurate. Temp2 looks to be the Mobo, but it too is a bit off ... again, I suspect the lm90 output (M/B Temp: +37?C) is closer to the true value I'm a little uncertain about temp1 (i.e what it actually is) or why its limits are like that (I did do a sensors -s first.....haven't touched the etc/sensors.conf file yet though). I'm wondering if its a bogus sensor....although the "diode Alarm " makes me wonder if its actually tied to the BIOS alarm temp setting in anyway. >> vid: +0.275 V (VRM Version 9.0) >> > > Bogus, and this is expected as the W83687THF needs completely different > code for VID, which my initial patch didn't have. I've implemented > that now, a new patch is available here: > > http://jdelvare.net2.nerim.net/sensors/hwmon-w83627hf-add-w83687thf-support.patch > > Note that it only applies to Linus' git tree (or any recent mm tree), > not 2.6.15 - unless you fix the few rejects manually. > ... > If you happen to test the patch linked above, please > report the result. Awesome. I'll look into that. Will report back. Sounds good. > As the chip is quite rare, It does indeed appear that way - when I was googling for information about it last week, I found reference to it in conjunction with only a few boards (Epox, Albatron, Soltek, and, IIRC, one from PC Chips or similar). > Also, I'd like to work on a sample configuration > file for this chip....maybe we can simply write a configuration file for your board. Can you please visit the > BIOS setup screens of your system and report all the hardware > monitoring items listed there, in order, with value? Then I'll provide > a configuration file for you to test. > Will do. Thanks, Steven
