[lm-sensors] seeking a W83687THF patch for 2.6.15 (re: ticket 1944)

[lm-sensors] seeking a W83687THF patch for 2.6.15 (re: ticket 1944)

[Steven Karatnyk]

Hi Jean,

I have the misfortune of having the Windbond W83687THF Super I/O IC on 
my Soltek motherboard (SL-B9D-FGR). 

I tried manually patching the w83627hf.c file contained in the 2.6.15 
sources with the changes outlined in the experimental patch for 
2.6.13-rc3 found on the lm_sensors drivers page.  There were a few 
differences in line numbers but thats about it (i.e. it was pretty 
straightforward what to change).  Unfortunately, it didn't work for me 
(sensors-detect didn't detect...didn't even probe for this chip).  This 
was probably predictable, as I'm not at all familiar with what was 
required and what all else would have needed to have been changed (i.e. 
I was just taking a stab in the dark in hopes that I might get it right). 

Which brings me to my question: how do I go about applying the 
experimental code/patch in order to gain support for my board' w83687thf ?

Thanks, CK

[lm-sensors] seeking a W83687THF patch for 2.6.15 (re: ticket

[Jim Cromie]

Steven Karatnyk wrote:

>Hi Jean,
>
>I have the misfortune of having the Windbond W83687THF Super I/O IC on 
>my Soltek motherboard (SL-B9D-FGR). 
>
>I tried manually patching the w83627hf.c file contained in the 2.6.15 
>sources with the changes outlined in the experimental patch for 
>2.6.13-rc3 found on the lm_sensors drivers page.  There were a few 
>differences in line numbers but thats about it (i.e. it was pretty 
>straightforward what to change).  Unfortunately, it didn't work for me 
>(sensors-detect didn't detect...didn't even probe for this chip).  This 
>was probably predictable, as I'm not at all familiar with what was 
>required and what all else would have needed to have been changed (i.e. 
>I was just taking a stab in the dark in hopes that I might get it right). 
>
>Which brings me to my question: how do I go about applying the 
>experimental code/patch in order to gain support for my board' w83687thf ?
>
>Thanks, CK
>
>
>_______________________________________________
>lm-sensors mailing list
>lm-sensors at lm-sensors.org
>http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
>
>  
>
for sensors support:
http://lm-sensors.org/wiki/Main_Page
http://lm-sensors.org/trac/
read the FAQs there.

if you can build a kernel, and can apply a patch,
then you can get the ones ready for 2.6.16 here.
http://khali.linux-fr.org/devel/i2c/linux-2.6/

If you cant do that, try http://kernelnewbies.org/
Im sure theyve got some info that will help.

the series file in there lists the patches in the order you need to 
apply them.
to a 2.6.15 tree
Theyre slated for inclusion in 16, and some of them are *thf patches.
You *could* try just the *thf patches, you should know by compiling
whether you need others.

theres also 2 tars, might save you some hassle.

BTW - youd do well to drop the *misfortunate* posture.
I cant speak for that chip, but Winbond is supporting their product,
one or more of them is on-list here, and they appear to 
play-nice-with-others.

Remember what used to happen to the sissys and whiners on the school
playground ?   We may be more grown up now, but human nature is what it is.

[lm-sensors] seeking a W83687THF patch for 2.6.15 (re:

[Ymu]

Hello,

> >
> >I have the misfortune of having the Windbond W83687THF Super I/O IC
on
> >my Soltek motherboard (SL-B9D-FGR).
> >
> >I tried manually patching the w83627hf.c file contained in the 2.6.15
> >sources with the changes outlined in the experimental patch for
> >2.6.13-rc3 found on the lm_sensors drivers page.  There were a few
> >differences in line numbers but thats about it (i.e. it was pretty
> >straightforward what to change).  Unfortunately, it didn't work for
me
> >(sensors-detect didn't detect...didn't even probe for this chip).
This
> >was probably predictable, as I'm not at all familiar with what was
> >required and what all else would have needed to have been changed
(i.e.
> >I was just taking a stab in the dark in hopes that I might get it
right).
> >
> >Which brings me to my question: how do I go about applying the
> >experimental code/patch in order to gain support for my board'
w83687thf ?


Sorry I have not read the w83687thf spec before, It seems a similar chip
to w83627thf, so I would like to give a patch to try make the driver
work first. I'm not sure if it can work but I'm sure there should be a
better solution.

I would like to suggest you to download lm_sensors2 from the website,
Install the user space tools, run sensors-detect and do what it suggest.
Then patch your w83627hf.c with the patch attached.
You can try using this w83627hf driver now.

Quoting Jim: 
> BTW - youd do well to drop the *misfortunate* posture.
I will try to tell my HW colleagues your dissatisfaction...
Thank you Jim ;) 

Best Regards
Yuan Mu



==============================================The privileged confidential information contained in this email is intended for use only by the addressees as indicated by the original sender of this email. If you are not the addressee indicated in this email or are not responsible for delivery of the email to such  a person, please kindly reply to the sender indicating this fact and delete all copies of it from your computer and network server immediately. Your cooperation is highly appreciated. It is advised that any unauthorized use of confidential information of Winbond is strictly prohibited; and any information in this email irrelevant to the official business of Winbond shall be deemed as neither given nor endorsed by Winbond.
==============================================If your computer is unable to decode Chinese font, please ignore the following message.It essentially repeats the statement in English given above.本信件內所含華邦電子的財產性機密性資訊, 僅授權原發信人指定之收信人取閱\之用. 假使您並非被指定之收信人或因任何原因在未經授權的情形之下收到本信件, 請您告知原發信人並立即將信件從電腦與網路伺服器中予以消除. 對於您的合作, 我們先此致謝. 特此提醒, 任何未經授權擅自使用華邦電子的機密資訊的行為是被嚴格禁止的. 信件與華邦電子營業無關之內容,不得視為華邦電子之立場或意見.
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch4w83687thf.txt
Url: http://lists.lm-sensors.org/pipermail/lm-sensors/attachments/20060106/9f2bd242/patch4w83687thf.txt

[lm-sensors] seeking a W83687THF patch for 2.6.15 (re: ticket

[Jean Delvare]

Hi Steven,

> I have the misfortune of having the Windbond W83687THF Super I/O IC on 
> my Soltek motherboard (SL-B9D-FGR).

Nothing to worry about. Sure we don't support this chip right now, but
given the good relationship that exists between the lm_sensors group
and Winbond, I am certain we should be able to come up with a solution
fast.

> I tried manually patching the w83627hf.c file contained in the 2.6.15 
> sources with the changes outlined in the experimental patch for 
> 2.6.13-rc3 found on the lm_sensors drivers page.  There were a few 
> differences in line numbers but thats about it (i.e. it was pretty 
> straightforward what to change).  Unfortunately, it didn't work for me 
> (sensors-detect didn't detect...didn't even probe for this chip).  This 
> was probably predictable, as I'm not at all familiar with what was 
> required and what all else would have needed to have been changed (i.e. 
> I was just taking a stab in the dark in hopes that I might get it right). 

Which version of lm_sensors (user-space) are you using? The W83687THF
detection was added in version 2.9.2, so you need at least this
version. Please note also that the detection code was written without
the benefit of a datasheet, so it might simply be incomplete.

You could provide the output of "isadump -k 0x87,0x87 0x2e 0x2f 0x0b"
so that I compare the ID of your chip with what is believed to the the
W83687THF chip ID. Note that you need isadump from lm_sensors 2.9.2 for
it to work.

> Which brings me to my question: how do I go about applying the 
> experimental code/patch in order to gain support for my board' w83687thf ?

I just updated the patch for Linux 2.6.15:
http://jdelvare.net2.nerim.net/sensors/linux-2.6.15-hwmon-w83687thf.diff

But this shouldn't be fundamentally different from what you had
starting from the 2.6.13-rc3 patch, if you fixed it properly.

Please also keep in mind that for user-space support you need to apply
the following patch to the lm_sensors sources:
  http://jdelvare.net2.nerim.net/sensors/CVS-w83687thf.diff
I checked it and it still applies to CVS with some offset.

-- 
Jean Delvare

[lm-sensors] seeking a W83687THF patch for 2.6.15 (re:

[Jean Delvare]

Hi Yuan,

> Sorry I have not read the w83687thf spec before, It seems a similar chip
> to w83627thf, so I would like to give a patch to try make the driver
> work first. I'm not sure if it can work but I'm sure there should be a
> better solution.

So you do have a datasheet for this chip? I asked Chunhao Huang about
it when he was working with us, but back then he didn't have the
datasheet:

http://lists.lm-sensors.org/pipermail/lm-sensors/2005-June/012754.html

The main reason why we do not support this chip at the moment is simply
the lack of datasheet. If you can publish it on Winbond's site and/or
send it to me, we should be able to start working on proper support. I
made the same assumption you did about the W83687THF chip: that it was
probably similar to the W83627THF, given the similar names and release
dates. If this is true, adding support to the w83627hf driver should be
straightforward. The experimental patch I wrote several months ago may
even be almost sufficient, at least to start with.

> Quoting Jim: 
> > BTW - youd do well to drop the *misfortunate* posture.
> I will try to tell my HW colleagues your dissatisfaction...
> Thank you Jim ;) 

It really has nothing to do with the hardware itself. It's simply a
matter of getting documentation about the chip. I can easily understand
Steven's original position, it's always a bit worrying when you realize
that your precious hardware lacks support, and he couldn't know how
helpful Winbond is. Now that he knows, I'm sure he'll see the life in
a much more positive way :)

-- 
Jean Delvare

[lm-sensors] seeking a W83687THF patch for 2.6.15 (re: ticket

[Steven Karatnyk]

Jim Cromie wrote:
> if you can build a kernel, and can apply a patch,
> then you can get the ones ready for 2.6.16 here.
> http://khali.linux-fr.org/devel/i2c/linux-2.6/
>
> ......
>
> the series file in there lists the patches in the order you need to 
> apply them.
> to a 2.6.15 tree
> Theyre slated for inclusion in 16, and some of them are *thf patches.
> You *could* try just the *thf patches, you should know by compiling
> whether you need others.
>
> theres also 2 tars, might save you some hassle.

That's what I'm seeking. Thanks.


> BTW - youd do well to drop the *misfortunate* posture.
> I cant speak for that chip, but Winbond is supporting their product,
> one or more of them is on-list here, and they appear to 
> play-nice-with-others.

a) If you are unfamiliar with the story behind that chip, as conveyed 
from the information found on the drivers page, then you have completely 
missed the context of my use of misfortune "posturing".   If you review 
those sources you will find that it is stated as being a "rare chip, not 
listed on Winbond's site, we have no datasheet for it, this explains why 
we don't support it".   Of course the second thread continues to reveal 
how experimental patches were developed.  However, those patches are now 
quite dated in terms of kernels to which they are to be applied.  There 
is no indication of any further change on the situation -- either on the 
driver page or in the changes file.  As an end-user trying to determine 
the status of the w83687thf (and one who spent some time poking around 
lm_sensors website and google),  I was disappointed to find no further 
developments.   Assimilating that information with the fact that I 
(unsuccessfully) tried applying the existing, but dated, patches on my 
own prior to bugging anyone on the list about it, I have no problem 
standing by my earlier statement that "I have the misfortune of having 
the Winbond W83687THF Super I/O IC on my Soltek motherboard 
(SL-B9D-FGR)".  Is that context clear enough?


b) You appear to have made the faulty assumption that my usage of 
"misfortune" was a slight against Winbond.  It was not, and should in no 
way be construed as such.


c) As an end-user not intimately involved in the lm_sensors project, I 
was unaware that Winbond is actively supporting their product(s).  From 
my observations (as outlined in point (a)), the w83687thf remains 
unsupported.  Indeed, there remains only a brief press release about 
this chip on Winbond's website.  You could probably find the pdf from 
their downloads section, but I, nor likely you or anyone else, has the 
time to play guess the magic xxxx number  
(http://www.winbond.com/c-winbondhtm/partner/PDFresult.asp?Pname=xxxx).


d) Lastly, despite the fact that your advice was mis-directed, it 
remains a bit perplexing to me -- Is the relationship between lm_sensors 
and Winbond so tenuous that end users must avoid writing anything that 
might appear in a negative light about the vendor?  Is Winbond going to 
get offended by the slightest knock, pick up their ball and go home?  
Personally, if I have anything deservingly negative to say about a 
company, don't count on me tip-toeing around the issue or holding back 
on the matter.  However, in this case, I reiterate that dissatisfaction 
with Winbond was never a point of issue in my posting to the list.

>
> Remember what used to happen to the sissys and whiners on the school
> playground ?   We may be more grown up now, but human nature is what 
> it is.
>
At first I wasn't sure if it was directed at me, as it makes no sense 
(other then perhaps being a follow on to your "posturing" commentary). I 
considered that perhaps it was a signature included in all of your 
posts.  Yet, glancing at a few of your prior posts on the list quickly 
extinguished that notion and reaffirmed that it was indeed directed at 
me.    My reply is this:

While I thank you for the useful information you provided early in your 
reply, I have no idea what point you are trying to make here.  As I have 
already addressed in detail your prior misdirected commentary, I will 
only add that this last comment bears little value to any 
conversation.   It strikes me that you have become too deeply involved 
with the project.  Take a step back and try to envision where uninvolved 
end users are coming from.  If I had over looked clear and concise 
information sources, then an admonishment from you would have been in 
order.  However, that was not the case, and your "advice" only spills 
over as arrogant badgering.

Thanks for your time.  Steve.

[lm-sensors] seeking a W83687THF patch for 2.6.15 (re:

[Steven Karatnyk]

Hello Yuan,

Ymu at Winbond.com.tw wrote:
> Quoting Jim: 
>   
>> BTW - youd do well to drop the *misfortunate* posture.
>>     
> I will try to tell my HW colleagues your dissatisfaction...
> Thank you Jim ;) 
>
>   

There seems to be some sort of misunderstanding being perpetuated here.  
Let me correct it now -- when I stated "I have the misfortune of having 
the Windbond W83687THF Super I/O IC on my Soltek motherboard 
(SL-B9D-FGR)" it was never my intention to indicate dissatisfaction with 
Winbond.  That is simply not the case .  For the record, I have 
absolutely NO dissatisfaction with Winbond, and no offense was intended 
in my prior post.   I outlined in my response to Jim why I stated what I 
did, but to cut to the chase, it amounts to being little more then a 
statement of disappointment of not having native kernel level support 
for the chip. 

Now then, with any mis-understandings aside ;) :


> Sorry I have not read the w83687thf spec before, It seems a similar chip
> to w83627thf,
Yes, that is what I gathered from the earlier thread found here: 
http://lists.lm-sensors.org/pipermail/lm-sensors/2005-June/012752.html


>  so I would like to give a patch to try make the driver
> work first. I'm not sure if it can work but I'm sure there should be a
> better solution.
>
> I would like to suggest you to download lm_sensors2 from the website,
> Install the user space tools, run sensors-detect and do what it suggest.
> Then patch your w83627hf.c with the patch attached.
> You can try using this w83627hf driver now.
>   

Thank you.  I will give it, and the info Jim provided,  a go over the 
weekend. 

Regards, SK

[lm-sensors] seeking a W83687THF patch for 2.6.15 (re:

[Steven Karatnyk]

Hi Jean,

I just saw your message right now, after replying to Yuan myself. I'm in 
a bit of a rush and just heading out the door, but will be able try out 
the patch and reply in detail tomorrow. Thanks again!

Steven

[lm-sensors] seeking a W83687THF patch for 2.6.15 (re: ticket

[Jim Cromie]

Steven Karatnyk wrote:

> Jim Cromie wrote:
>
>> BTW - youd do well to drop the *misfortunate* posture.
>> I cant speak for that chip, but Winbond is supporting their product,
>> one or more of them is on-list here, and they appear to 
>> play-nice-with-others.
>
>

Everyone,  including Steve,

Sorry for that peek of petulance in public. 
I havent earned that right.
Please allow that I said it so *you* dont have to (for those that have 
thought it before).

As to what set me off, Ive worked with Yuan
(sent him a compile-only patch - I dont have the hardware)
He took it happily, and is finishing / has finished it.
I felt a certain loyalty.

hope that clears the air,
jimc

--------------------------
open windows let in fresh air

[lm-sensors] seeking a W83687THF patch for 2.6.15 (re: ticket

[Steven Karatnyk]

Hi all,

Jim Cromie wrote:
> Everyone,  including Steve,
>
> Sorry for that peek of petulance in public. I havent earned that right.
> Please allow that I said it so *you* dont have to (for those that have 
> thought it before).
>
> As to what set me off, Ive worked with Yuan
> (sent him a compile-only patch - I dont have the hardware)
> He took it happily, and is finishing / has finished it.
> I felt a certain loyalty.
>
> hope that clears the air,
> jimc
>
> --------------------------
> open windows let in fresh air
>

I just wanted to take a second to thank Jim for both the public and 
private letters of apology, as they were appreciated.  It goes without 
saying, that its all water under the bridge and the air is indeed clear  :)

As for the patch, I haven't attempted it yet.  I do, however, and 
ashamedly, have to admit to committing user error in my previous 
endeavor.  After reading Jean's first reply, I clued in that I had not 
updated the user space tools to v2.92, but had attempted to detect with 
the older v2.91.  Booooo to me.

Anyways, I'll update soon.

Thanks, Steven

[lm-sensors] seeking a W83687THF patch for 2.6.15 (re: ticket

[Steven Karatnyk]

Hi Jean / list,

Jean Delvare wrote:
> Which version of lm_sensors (user-space) are you using? The W83687THF
> detection was added in version 2.9.2, so you need at least this
> version. 
>   
My  problem was that 2.9.1 user-space tools were still in 
/usr/[bin;sbin] and these were being utilized instead of the >2.9.2 
versions located /usr/local/[bin;sbin].  After I got that straightened 
out, sensors-detect did indeed find the chip.

As an aside, the 2.9.2 version generated several errors during "make 
user" (sorry, can't recall what was stated, and a quick google search 
didn't illuminate for me what may have been generating the problem(s)).  
However, I grabbed the CVS version (which provides sensors-detect 
revision 1.405 (2005/12/09 19:44:49) ) and it worked without problem.   
[Let me know if you're interested in what the errors were for my "make 
user" attempt with the 2.9.2 d/l and I will revisit that issue].

> You could provide the output of "isadump -k 0x87,0x87 0x2e 0x2f 0x0b"
> so that I compare the ID of your chip with what is believed to the the
> W83687THF chip ID. Note that you need isadump from lm_sensors 2.9.2 for
> it to work.
>   

isadump -k 0x87,0x87 0x2e 0x2f 0x0b
WARNING! Running this program can cause system crashes, data loss and worse!
I will probe address register 0x2e and data register 0x2f.
Probing bank 11 using bank register 0x07.
Continue? [Y/n] y
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00: ff ff ff ff ff ff ff 0b ff ff ff ff ff ff ff ff
10: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
20: 85 42 ff 00 44 00 00 ff 50 03 f0 02 00 00 00 00
30: 01 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
40: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
50: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
60: 02 90 ff ff ff ff ff ff ff ff ff ff ff ff ff ff
70: 00 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
90: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
f0: 11 3f ff ff ff ff ff ff ff ff ff ff ff ff ff ff

In case an"isadump 0x295 0x296" is also of assistance, it yields:
WARNING! Running this program can cause system crashes, data loss and worse!
I will probe address register 0x295 and data register 0x296.
Continue? [Y/n] y
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00: 01 70 01 5f 17 2d 3c 11 70 5f 01 01 3c 3c 01 01
10: 01 00 31 00 00 01 01 3c 43 00 ff ff 24 32 00 c9
20: 54 5f ce bb a2 9d 10 27 7f 7b ff f0 00 84 9b 48
30: b3 d2 00 02 da 60 ad 07 6a 02 d5 12 a6 60 00 00
40: 01 d6 09 de ff 00 00 f0 2d 02 01 44 10 15 01 a3
50: 27 00 00 4b 00 50 00 ff ff ff ff ff ff ff ff ff
60: 54 5f ce bb a2 9d 10 27 7f 7b ff f0 00 84 9b 48
70: b3 d2 00 02 da 60 ad 07 6a 02 d5 12 a6 60 00 00
80: 01 70 01 5f 17 2d 3c 11 70 5f 01 01 3c 3c 01 01
90: 01 00 31 00 00 01 01 3c 43 00 ff ff 24 32 00 cb
a0: 54 5f ce bb a2 9d 10 27 7f 7b ff f0 00 84 9b 48
b0: b3 d2 00 02 da 60 ad 07 6a 02 d5 12 a6 60 00 00
c0: 01 00 00 de ff 00 00 f0 2d 02 01 44 10 15 01 a3
d0: 27 00 00 4b 00 50 00 ff ff ff ff ff ff ff ff ff
e0: 54 5f ce bb a2 9d 10 27 7f 7b ff f0 00 84 9b 48
f0: b3 d2 00 02 da 60 ad 07 6a 02 d5 12 a6 60 00 00

> I just updated the patch for Linux 2.6.15:
> http://jdelvare.net2.nerim.net/sensors/linux-2.6.15-hwmon-w83687thf.diff
>
> But this shouldn't be fundamentally different from what you had
> starting from the 2.6.13-rc3 patch, if you fixed it properly.
>   

Yes.  Doesn't appear to have been any problems there.  It was using the 
v2.9.1 user tools that tripped me up.


> Please also keep in mind that for user-space support you need to apply
> the following patch to the lm_sensors sources:
>   http://jdelvare.net2.nerim.net/sensors/CVS-w83687thf.diff
> I checked it and it still applies to CVS with some offset.
>   

It Applied without issue, but your wording ("it still applies with some 
offset") makes me think I may have missed something or done something 
wrong here.  And indeed, although sensors-detect now detects the IC, I 
haven't succeeded with getting the support implemented yet.  I will 
re-look at this later tonight, time permitting.


> Nothing to worry about. Sure we don't support this chip right now, but
> given the good relationship that exists between the lm_sensors group
> and Winbond, I am certain we should be able to come up with a solution
> fast.

And I would like to thank Yuan who, once made aware of this issue, 
expedited the delivery of the data sheet.  Much obliged for your help. :)

Thanks, Steven

[lm-sensors] seeking a W83687THF patch for 2.6.15 (re: ticket

[CityK]

Steven Karatnyk wrote:
Jean Delvare wrote:

>> Please also keep in mind that for user-space support you need to apply
>> the following patch to the lm_sensors sources:
>>   http://jdelvare.net2.nerim.net/sensors/CVS-w83687thf.diff
>> I checked it and it still applies to CVS with some offset.
>>   
>>     
>
> It Applied without issue, but your wording ("it still applies with some 
> offset") makes me think I may have missed something or done something 
> wrong here.  And indeed, although sensors-detect now detects the IC, I 
> haven't succeeded with getting the support implemented yet.  I will 
> re-look at this later tonight, time permitting.
>
>   

Ummmm, lets just say I'm a monkey (i.e. I hadn't modprobe w83627hf ).

Anyways, here's the successful output:

# sensors
lm90-i2c-0-4c
Adapter: SMBus Via Pro adapter at 5000

M/B Temp: +37?C (low = +0?C, high = +70?C)
CPU Temp: +54.4?C (low = +0.0?C, high = +70.0?C)
M/B Crit: +85?C (hyst = +75?C)
CPU Crit: +85?C (hyst = +75?C)

w83687thf-isa-0290
Adapter: ISA adapter
in0: +1.10 V (min = +0.70 V, max = +1.87 V)
in1: +1.52 V (min = +2.54 V, max = +2.11 V) ALARM
in2: +3.30 V (min = +2.86 V, max = +1.66 V) ALARM
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
in8: +3.30 V (min = +0.38 V, max = +3.14 V) ALARM
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
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
vid: +0.275 V (VRM Version 9.0)
alarms:
beep_enable:
Sound alarm enabled


Pretty happy camper here! Thanks so much guys.

Looking back to what Hugo also reported with the experimental code 
(http://lists.lm-sensors.org/pipermail/lm-sensors/2005-June/012769.html), 
on a glance it seems like I get pretty similar results.

Anyways, definitely count me in for testing any revised/changed code as 
the result of info gleaned from the data sheet. Looking forward to it!

Thanks, Steven

[lm-sensors] seeking a W83687THF patch for 2.6.15 (re: ticket 1944)

[Steven Karatnyk]

Steven Karatnyk wrote:
      Jean Delvare wrote:

>> Please also keep in mind that for user-space support you need to apply
>> the following patch to the lm_sensors sources:
>>   http://jdelvare.net2.nerim.net/sensors/CVS-w83687thf.diff
>> I checked it and it still applies to CVS with some offset.
>>       
>
> It Applied without issue, but your wording ("it still applies with 
> some offset") makes me think I may have missed something or done 
> something wrong here.  And indeed, although sensors-detect now detects 
> the IC, I haven't succeeded with getting the support implemented yet.  
> I will re-look at this later tonight, time permitting.
>
>   

Ummmm, lets just say I'm a monkey (i.e. I hadn't modprobe w83627hf ).

Anyways, here's the successful output:

# sensors
lm90-i2c-0-4c
Adapter: SMBus Via Pro adapter at 5000

M/B Temp: +37?C (low = +0?C, high = +70?C)
CPU Temp: +54.4?C (low = +0.0?C, high = +70.0?C)
M/B Crit: +85?C (hyst = +75?C)
CPU Crit: +85?C (hyst = +75?C)

w83687thf-isa-0290
Adapter: ISA adapter
in0: +1.10 V (min = +0.70 V, max = +1.87 V)
in1: +1.52 V (min = +2.54 V, max = +2.11 V) ALARM
in2: +3.30 V (min = +2.86 V, max = +1.66 V) ALARM
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
in8: +3.30 V (min = +0.38 V, max = +3.14 V) ALARM
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
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
vid: +0.275 V (VRM Version 9.0)
alarms:
beep_enable:
Sound alarm enabled


Pretty happy camper here! Thanks so much guys.

Looking back to what Hugo also reported with the experimental code 
(http://lists.lm-sensors.org/pipermail/lm-sensors/2005-June/012769.html), 
on a glance it seems like I get pretty similar results.

Anyways, definitely count me in for testing any revised/changed code as 
the result of info gleaned from the data sheet. Looking forward to it!

Thanks, Steven

Sorry - probably a duplicate message...replied from one of my other 
accounts (CK) by mistake.

[lm-sensors] seeking a W83687THF patch for 2.6.15 (re: ticket

[Jean Delvare]

Hi Steven,

> My  problem was that 2.9.1 user-space tools were still in 
> /usr/[bin;sbin] and these were being utilized instead of the >2.9.2 
> versions located /usr/local/[bin;sbin].  After I got that straightened 
> out, sensors-detect did indeed find the chip.

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.

> As an aside, the 2.9.2 version generated several errors during "make 
> user" (sorry, can't recall what was stated, and a quick google search 
> didn't illuminate for me what may have been generating the problem(s)).  
> However, I grabbed the CVS version (which provides sensors-detect 
> revision 1.405 (2005/12/09 19:44:49) ) and it worked without problem.   
> [Let me know if you're interested in what the errors were for my "make 
> user" attempt with the 2.9.2 d/l and I will revisit that issue].

If this is fixed in CVS already, don't bother. There's nothing more
we'll be able to do, can't kill a bug that's already dead ;)

> isadump -k 0x87,0x87 0x2e 0x2f 0x0b
> (...)
> In case an"isadump 0x295 0x296" is also of assistance, it yields:

Thanks for the dumps, I've stored them in my personal collection, this
might come in handy to answer future support requests.

You may have noticed that I have been committing the user-space part of
the W83687THF support to CVS already. 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! :)

-- 
Jean Delvare

[lm-sensors] seeking a W83687THF patch for 2.6.15 (re: ticket

[Jean Delvare]

Hi Steven,

> 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?

> 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).

> in2: +3.30 V (min = +2.86 V, max = +1.66 V) ALARM

And this could be +3.3V.

> 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.

> 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.)

> 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.

> 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.

> 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.

> Pretty happy camper here! Thanks so much guys.
> (...)
> Anyways, definitely count me in for testing any revised/changed code as 
> the result of info gleaned from the data sheet. Looking forward to it!

You're welcome. If you happen to test the patch linked above, please
report the result. Also, I'd like to work on a sample configuration
file for this chip. As the chip is quite rare, 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.

-- 
Jean Delvare

[lm-sensors] seeking a W83687THF patch for 2.6.15 (re: ticket

[Steven Karatnyk]

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

[lm-sensors] seeking a W83687THF patch for 2.6.15 (re: ticket

[Steven Karatnyk]

Hi Jean,

>>> 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.
>


Indeed, in4 is Vdimm.  I bumped the value in the BIOS up to 2.70V and 
sensors now reports in4 at 2.72V.  

Interestingly  enough, in the process of confirming the relation of the 
in4 setting, I discovered a bug in the BIOS:  After testing, I returned 
the Vdimm value in the BIOS to default (2.60V).  After the boot, Sensors 
then reported in4 still at 2.72V.  I rebooted back into the BIOS, and 
its own monitoring display confirmed the same value for Vdimm.  I 
switched the Vdimm setting from default to a manual setting of 2.60V.  
Sensors again reports 2.72V,  and rebooting again confirms this in the 
BIOS reading.  I'll check later on after a cold boot, if things are 
different.  Anyways, I digress.


>>> 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.

Interesting, I'm noticing the limits for temp1 are fluctuating on their 
own. For example,

$ sensors
lm90-i2c-0-4c
Adapter: SMBus Via Pro adapter at 5000

M/B Temp:    +38?C  (low  =    +0?C, high =   +70?C)
CPU Temp:  +55.9?C  (low  =  +0.0?C, high = +70.0?C)
M/B Crit:    +85?C  (hyst =   +75?C)
CPU Crit:    +85?C  (hyst =   +75?C)

w83687thf-isa-0290
Adapter: ISA adapter
in0:       +1.09 V  (min =  +0.00 V, max =  +3.84 V)
in1:       +1.50 V  (min =  +2.48 V, max =  +2.11 V)       ALARM
in2:       +3.33 V  (min =  +2.86 V, max =  +1.15 V)       ALARM
in3:       +2.99 V  (min =  +2.05 V, max =  +3.36 V)
in4:       +2.72 V  (min =  +3.49 V, max =  +0.03 V)       ALARM
in7:       +2.94 V  (min =  +0.16 V, max =  +0.42 V)       ALARM
in8:       +3.30 V  (min =  +0.38 V, max =  +3.14 V)       ALARM
fan1:     1339 RPM  (min = 9375 RPM, div = 8)              ALARM
fan2:     1394 RPM  (min = 1016 RPM, div = 8)
fan3:        0 RPM  (min = 6367 RPM, div = 2)              ALARM
temp1:       +43?C  (high =    +6?C, hyst =   -43?C)   sensor = diode   
ALARM
temp2:     +44.5?C  (high =   +80?C, hyst =   +75?C)   sensor = diode
temp3:     +59.5?C  (high =   +80?C, hyst =   +75?C)   sensor = diode
vid:      -1.200 V  (VRM Version 8.2)
alarms:
beep_enable:
          Sound alarm enabled


>> 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.

Haven't tried the patch yet - been busy tracking down some other 
problems.   Will probably hold off till 2.6.15.1 comes out and then 
manually make the changes then.

>> 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.

There is a "SmartDoc Anti-Burn Shield" Menu in my BIOS that can be seen 
here: http://www.silentpcreview.com/files/images/soltek3901/Fan-control.jpg
However, I just noticed that the user adjustable "Shutdown Temperature" 
in the BIOS version I'm running has been removed (although , as 
illustrated in the pic above, it was available in earlier revisions of 
the BIOS!).  Anyways, when I had a look at my BIOS settings,  I recorded 
the following:

CPU Internal Temp.    43C
CPU External Temp   51C
System Temp                 41C
Fan1 Speed                  1394 RPM
Fan2 Speed                  1360RPM
Vcore                             1.40V
+1.5V                              1.50V
+3.3V                              3.29V
VDIMM                         2.59V       ....... although, of course, 
its now at 2.72V, as described above
+5V                                 5.04V
VBAT                              3.29V
5VSB                              4.96V

Smart Fan1 Temperature 60C
Fan1 Tolerance Value [1]
Smart Fan2 Temperature 45C
Fan2 Tolerance Value [1]

- Interesting that there is no +12V reading
- Of course, only the bottom Smart Fan stuff is user adjustable

In the " Frequency / Voltage Control " BIOS menu, there are relevant 
entries for:

CPU Vcore Select
AGP Voltage Select
DIMM Voltage Select

All of which I have set on "Default"


Let me know if you need anything else, or clarification of anything.

Thanks, Steven

[lm-sensors] seeking a W83687THF patch for 2.6.15 (re: ticket

[Jean Delvare]

Hi Steven,

> Interesting, I'm noticing the limits for temp1 are fluctuating on their 
> own. For example,

That's really weird. These registers are not supposed to change values
unless you ask for a change. Please see if you can refine your
observations as to when and how these values change.

> > 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.
> 
> Haven't tried the patch yet - been busy tracking down some other 
> problems.   Will probably hold off till 2.6.15.1 comes out and then 
> manually make the changes then.

2.6.15.1 is out now. I've generated a patch which will apply properly
on top of it:
http://jdelvare.net2.nerim.net/sensors/linux-2.6.15.1-hwmon-w83687thf.diff

> (...) Anyways, when I had a look at my BIOS settings,  I recorded 
> the following:
> 
> CPU Internal Temp.    43C
> CPU External Temp   51C

It's odd that the external temperature is higher than the internal
temperature. The picture you pointed us to above is much more logical
(internal temperature is higher).

It's really hard to guess which temperature sensors correspond to which
BIOS measurement. I guess that the motherboard manufacturer wouldn't
have added a secondary monitoring chip (the LM90) if not to monitor the
CPU temperature more accurately, so my guess is that "CPU External
Temp" is lm90 temp2. "CPU Internal Temp" may be w83687thf temp2 or
temp3.

> System Temp                 41C

And this would be w83687thf temp1. This is really only a guess at this
point though. A BIOS disassembly and/or additional information from DFI
would be needed here.

You may also put the CPU under load under Linux (with some compilation
or compression work, or by using cpuburn) and see which temperatures
raise quickly.

> Fan1 Speed                  1394 RPM
> Fan2 Speed                  1360RPM

Both values are similar so it'll be hard to say which is which. You may
try to physically slow down either fan to differenciate between them.

> Vcore                             1.40V

in0

> +1.5V                              1.50V

in1

> +3.3V                              3.29V

in2

> VDIMM                         2.59V       ....... although, of course, 
> its now at 2.72V, as described above

in4

> +5V                                 5.04V

most probably in3

> VBAT                              3.29V

in8

> 5VSB                              4.96V

most probably in7

> Smart Fan1 Temperature 60C
> Fan1 Tolerance Value [1]
> Smart Fan2 Temperature 45C
> Fan2 Tolerance Value [1]

These must correspond to the "thermal cruise" mode. We don't support it
for now.

> - Interesting that there is no +12V reading

True, that's unusual, but not unseen.

> Let me know if you need anything else, or clarification of anything.

Well, any additional information you can get regarding the temperature
sensors is welcome. For now, please find attached a sample
configuration file which should be suitable for your motherboard. Copy
it to /etc/sensors.conf and give it a try, please.

This is really only a first short, voltages should be OK, but fans and
temperatures will need more work to find out the appropriate labels.

-- 
Jean Delvare
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: sensors-Soltek-B9D-FGR.conf
Url: http://lists.lm-sensors.org/pipermail/lm-sensors/attachments/20060115/a0096a26/sensors-Soltek-B9D-FGR.pl

[lm-sensors] seeking a W83687THF patch for 2.6.15 (re: ticket

[Jean Delvare]

Hi Steven,

> > 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

I just installed Suse 10.0 on one of my systems yesterday, and I do
have /usr/local/bin before /usr/bin as expected. Maybe you have some
custom configuration on your own account.

That being said, there still is a problem when you have the same
library installed under /usr/lib and /usr/local/lib, regardless of
$PATH.

> 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 ;)

This is just a planned name for the future release. We change that line
(and especially the date) when we do the real release. I changed from
2.9.3 to 2.10.0 this time because I think that's how we'll number the
next release, but this hasn't been publicly discussed yet AFAIR.

Anyway, this version is better refered to as "CVS".

-- 
Jean Delvare

[lm-sensors] seeking a W83687THF patch for 2.6.15 (re: ticket

[Steven Karatnyk]

Hi Jean,

Steven Karatnyk wrote:
> I'm not certain if there is a 3rd 
> fan header on the mobo... would have to check manual.
>   

Checked and there is indeed a 3rd header

> Interestingly  enough, in the process of confirming the relation of the 
> in4 setting, I discovered a bug in the BIOS:  After testing, I returned 
> the Vdimm value in the BIOS to default (2.60V).  After the boot, Sensors 
> then reported in4 still at 2.72V.  I rebooted back into the BIOS, and 
> its own monitoring display confirmed the same value for Vdimm.  I 
> switched the Vdimm setting from default to a manual setting of 2.60V.  
> Sensors again reports 2.72V,  and rebooting again confirms this in the 
> BIOS reading.  I'll check later on after a cold boot, if things are 
> different.  Anyways, I digress.
>   

Just for posterity, after a cold boot the Vdimm value did revert to its 
proper value (as set in the BIOS). 


Jean Delvare wrote:
>> Interesting, I'm noticing the limits for temp1 are fluctuating on their 
>> own. For example,
>>     
>
> That's really weird. These registers are not supposed to change values
> unless you ask for a change. Please see if you can refine your
> observations as to when and how these values change.
>   

Will try, but I haven't observed any correlation yet as to why it 
changes.  I should, however, clarify that "fluctuating" was an 
inappropriate label. 
The values will remain steady for a good long while, even across days.  
But then, without apparent reason, "sensors" will unveil that they have 
changed.  For example, I'm now seeing:
temp1:       +38?C  (high =    +2?C, hyst =   +52?C)   sensor = diode

> 2.6.15.1 is out now. I've generated a patch which will apply properly
> on top of it:
> http://jdelvare.net2.nerim.net/sensors/linux-2.6.15.1-hwmon-w83687thf.diff
>   

Thanks.  Applied no problem.

>> (...) Anyways, when I had a look at my BIOS settings,  I recorded 
>> the following:
>>
>> CPU Internal Temp.    43C
>> CPU External Temp   51C
>>     
>
> It's odd that the external temperature is higher than the internal
> temperature. The picture you pointed us to above is much more logical
> (internal temperature is higher).

I hadn't thought twice about this until I read your comment.  I 
rechecked the BIOS and this is indeed the reported situation.  I think 
that, in the case of my BIOS revision, the Soltek BIOS programmer 
probably just incorrectly/accedently associated the internal temp with 
the wrong label....of course this is only my working theory.

> It's really hard to guess which temperature sensors correspond to which
> BIOS measurement. I guess that the motherboard manufacturer wouldn't
> have added a secondary monitoring chip (the LM90) if not to monitor the
> CPU temperature more accurately, so my guess is that "CPU External
> Temp" is lm90 temp2. "CPU Internal Temp" may be w83687thf temp2 or
> temp3.
>
>   
>> System Temp                 41C
>>     
>
> And this would be w83687thf temp1. This is really only a guess at this
> point though. A BIOS disassembly and/or additional information from DFI
> would be needed here.
>
> You may also put the CPU under load under Linux (with some compilation
> or compression work, or by using cpuburn) and see which temperatures
> raise quickly.
>   

I set up some Ksysguard panels with the LM90 and Winbond Temps and then 
monitored the system under load.

LM90_CPU_Temp: 75C    LM90_M/B_Temp: 43
Temp1: 42                 Temp2: 61.5            Temp3: 71.5

It looks like:
- the internal CPU temp is measured by the w83687's Temp3 and the LM90's 
CPU Temp...which corresponds to the BIOS' "CPU Internal Temp" is another 
question, but I believe its the Winbond IC (* will explain in the 
discussion about the Fans below)
- the external CPU temp is measured by the w83687's Temp2
- the system/motherboard temp is measured by the w83687's Temp1 and the 
LM90's M/B Temp


>   
>> Fan1 Speed                  1394 RPM
>> Fan2 Speed                  1360RPM
>>     
>
> Both values are similar so it'll be hard to say which is which. You may
> try to physically slow down either fan to differenciate between them.
>   
I opened up the case and unplugged the exhaust fan (not necessarily a 
trivial task when dealing with a SFF case).
The CPU Fan corresponds to the BIOS' "Fan1 Speed".  It, however, maps to 
the Winbond's Fan2 sensor.

>> Smart Fan1 Temperature 60C
>> Fan1 Tolerance Value [1]
>> Smart Fan2 Temperature 45C
>> Fan2 Tolerance Value [1]
>>     
>
> These must correspond to the "thermal cruise" mode. 

Yes, precisely (pg.30 of the datasheet). 

> We don't support it for now.
>   

It still works.  Although my experiences more or less mirror that 
described in http://www.silentpcreview.com/article235-page5.html (from 
the "BIOS Fan Control" section on pg.5 through to the end of "FAN 
(MIS)BEHAVIOUR" section on pg.6).  Buggy BIOS programming seems to 
plaque its effectiveness too (more on this in a second).

Anyways, while placing the system under load, it appeared that the 
trigger for the SmartFan1 (throttling of the CPU fan) was the Winbond 
temp3.  Seemingly, if that sensor's reading breached >66C for more then 
two occasions in a row, the cpu fan ramped up (The LM90's CPU temp was 
already bouncing around in low 70s and seemed to play no part).  * This 
is why I stated earlier that I believe the BIOS' "CPU Internal Temp" 
corresponds to the Winbond IC and not the LM90.

It's interesting to note that the threshold observed for the fan 
throttling (both ramping up and decelerating) occurred at 5C more then 
the trigger value I set in the BIOS ("Smart Fan1 Temperature 60C" and a 
"Fan1 Tolerance Value [1]") !   This is not the first time I've observed 
a 5C discrepency that has plagued the effectiveness of the "SmartFan" 
feature.  Last year,  I developed a good line of dialogue with Soltek's 
rep Lydia because I was observing some sort of misbehaviour between the 
BIOS and the sensor values.  It is hard for me to both remember 
accurately and explain in few words **, but essentially, IIRC, coming 
out of S3 the fans were at full speed because the trigger on the 
SpeedFan was being shifted down 5C irregardless of the temperatures.  
Similarly, I would observe the trigger being shifted up 5C during normal 
operation.  Lydia passed my commentary off to their BIOS engineer, and 
then provided me with a beta BIOS to test (it also contained some other 
features I was seeking).  It seemed, for the most part, to correct the 
5C speedfan trigger shifting behaviour.   I later updated to the most 
recent official BIOS release.  Unfortunately, several of the changes 
that were in the beta BIOS were no longer in the official release - 
including correct fan control coming out of S3 (this from testing within 
Windows, as I don't currently have S3 working with this system in 
Linux).  It was the very testing performed today which has revealed to 
me that the 5C shift up bug also found its way back into the current 
BIOS.  Sadly, Soltek has appeared to have abandoned the motherboard 
market, and Lydia was released quite a while back.  I doubt they're 
providing BIOS support still too, as nothing new has been released for a 
good long while.  

I also wonder if there is a connection somehow with this misbehaviour 
and the changing temp1 limit values I'm observing.

** If needed or if it might help in anyway (in relation to the current 
discussion or perhaps even for assisting future efforts to support for 
the "thermal cruise" mode),  I can find and provide links to the 
discussion I had with Lydia and they would provide a more detailed 
description of my observations about the wonky SpeedFan behaviour.


>> Vcore                             1.40V
>>     
>
> in0
>
>   
>> +1.5V                              1.50V
>>     
>
> in1
>
>   
>> +3.3V                              3.29V
>>     
>
> in2
>
>   
>> VDIMM                         2.59V       ....... although, of course, 
>> its now at 2.72V, as described above
>>     
>
> in4
>
>   
>> +5V                                 5.04V
>>     
>
> most probably in3
>
>   
>> VBAT                              3.29V
>>     
>
> in8
>
>   
>> 5VSB                              4.96V
>>     
>
> most probably in7
>
>   
Looks good.


>> - Interesting that there is no +12V reading   
> True, that's unusual, but not unseen.  

Would this be strictly a BIOS limitation of not exposing such monitoring? 

>> Let me know if you need anything else, or clarification of anything.
>>     
>
> Well, any additional information you can get regarding the temperature
> sensors is welcome. For now, please find attached a sample
> configuration file which should be suitable for your motherboard. Copy
> it to /etc/sensors.conf and give it a try, please.
>
> This is really only a first short, voltages should be OK, but fans and
> temperatures will need more work to find out the appropriate labels.
>   

Have done.  Without integrating any of the info I mentioned above into 
the /etc/sensors.conf, the following is observed:

$ sensors
lm90-i2c-0-4c
Adapter: SMBus Via Pro adapter at 5000

M/B Temp:    +36?C  (low  =   +10?C, high =   +50?C)
CPU Temp:  +52.8?C  (low  = +10.0?C, high = +70.0?C)
M/B Crit:    +70?C  (hyst =   +65?C)
CPU Crit:    +80?C  (hyst =   +75?C)

w83687thf-isa-0290
Adapter: ISA adapter
Vcore:     +1.09 V  (min =  +1.04 V, max =  +1.47 V)
+1.5V:     +1.52 V  (min =  +1.42 V, max =  +1.57 V)
+3.3V:     +3.30 V  (min =  +3.14 V, max =  +3.47 V)
+5V:       +5.03 V  (min =  +4.76 V, max =  +5.24 V)
Vdimm:     +2.59 V  (min =  +2.46 V, max =  +2.74 V)
5VSB:      +4.95 V  (min =  +4.76 V, max =  +5.24 V)
Vbat:      +3.30 V  (min =  +2.85 V, max =  +3.47 V)
fan1:        0 RPM  (min = 1102 RPM, div = 8)              ALARM
fan2:     1394 RPM  (min = 1102 RPM, div = 8)
temp1:       +39?C  (high =    +2?C, hyst =   +52?C)   sensor = diode
temp2:     +38.0?C  (high =   +80?C, hyst =   +52?C)   sensor = diode
temp3:     +56.0?C  (high =   +80?C, hyst =   +65?C)   sensor = diode
vid:      -4.825 V  (VRM Version 2.4)
alarms:
beep_enable:
          Sound alarm enabled


Notes:
- fan1 is, of course, the exhaust fan which is currently unplugged and 
sitting on my desk.
- vid is obviously incorrect

Thanks, Steven

[lm-sensors] seeking a W83687THF patch for 2.6.15 (re: ticket

[Steven Karatnyk]

Jean Delvare wrote:
> Hi Steven,
>
>   
>>> 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
>>     
>
> I just installed Suse 10.0 on one of my systems yesterday, and I do
> have /usr/local/bin before /usr/bin as expected. Maybe you have some
> custom configuration on your own account.
>   
Not that I know of. Given I'm still very much a rookie when it comes to 
Linux, its most likely that the problem existed behind my keyboard.

> That being said, there still is a problem when you have the same
> library installed under /usr/lib and /usr/local/lib, regardless of
> $PATH.
>   

Looking in /usr/lib I notice only one library: libsensors.a (which is 
from Sept 12th/05 ... marking it as being from v2.9.1)

Looking in /usr/local/lib reveals 4 files (all of which dated Jan 9th/06):
libsensors.a
libsensors.so ... which is a link to libsensors.so.3
libsensors.so.3 .... which is a link to libsensors.so.3.0.9
libsensors.so.3.0.9

Should I just copy the libsensors.a and libsensors.so.3.0.9 into /usr/lib ?

Any potential for error if the the wrong library is being read?

Thanks, Steven

[lm-sensors] seeking a W83687THF patch for 2.6.15 (re: ticket

[Jean Delvare]

Hi Steven,

Thanks for your detailed answer.

> Will try, but I haven't observed any correlation yet as to why it 
> changes.  I should, however, clarify that "fluctuating" was an 
> inappropriate label. 
> The values will remain steady for a good long while, even across days.  
> But then, without apparent reason, "sensors" will unveil that they have 
> changed.  For example, I'm now seeing:
> temp1:       +38?C  (high =    +2?C, hyst =   +52?C)   sensor = diode

When does the values change? If on reboot or deep sleep, it might just
mean that these registers have no default power-up value. If on the
other hand the values change during the regular system use, I'd
diagnose a chip failure - it shouldn't lose the register values that
way. Or something (BIOS?) is writing crap to these registers. Not much
we can do in either case, I fear.

If you can observe anything more detailed (e.g. how or when exactly the
values change), please let us know. Also, please confirm that the limit
values are always correct right after running "sensors -s && sleep 3 &&
sensors".

> Anyways, while placing the system under load, it appeared that the 
> trigger for the SmartFan1 (throttling of the CPU fan) was the Winbond 
> temp3.  Seemingly, if that sensor's reading breached >66C for more then 
> two occasions in a row, the cpu fan ramped up (The LM90's CPU temp was 
> already bouncing around in low 70s and seemed to play no part).  * This 
> is why I stated earlier that I believe the BIOS' "CPU Internal Temp" 
> corresponds to the Winbond IC and not the LM90.

As a side note, these are quite high temperatures you have here. I know
that modern CPUs are supposed to support such high temperatures, but
I'm not sure all components of your system will have a long life at
this temperature. You may consider a superior cooling system.

> ** If needed or if it might help in anyway (in relation to the current 
> discussion or perhaps even for assisting future efforts to support for 
> the "thermal cruise" mode),  I can find and provide links to the 
> discussion I had with Lydia and they would provide a more detailed 
> description of my observations about the wonky SpeedFan behaviour.

Well if that's a BIOS bug there's not much we can do. What we should
offer OTOH is a full interface to the chip to tweak the automatic fan
speed in a much more detailed (and accurate, in your case) way than the
BIOS offers. There's a patch flaoting around, but nobody (counting me)
had the time to actually merge it. Shame on us.

> > > - Interesting that there is no +12V reading
> >
> > True, that's unusual, but not unseen.
>
> Would this be strictly a BIOS limitation of not exposing such monitoring?

No. As you can see, "sensors" doesn't show the value either. +12V is
simply not wired to the monitoring chip on your board. That's a
physical issue.

> $ sensors
> lm90-i2c-0-4c
> Adapter: SMBus Via Pro adapter at 5000
> M/B Temp:    +36?C  (low  =   +10?C, high =   +50?C)
> CPU Temp:  +52.8?C  (low  = +10.0?C, high = +70.0?C)
> M/B Crit:    +70?C  (hyst =   +65?C)
> CPU Crit:    +80?C  (hyst =   +75?C)
> 
> w83687thf-isa-0290
> Adapter: ISA adapter
> Vcore:     +1.09 V  (min =  +1.04 V, max =  +1.47 V)
> +1.5V:     +1.52 V  (min =  +1.42 V, max =  +1.57 V)
> +3.3V:     +3.30 V  (min =  +3.14 V, max =  +3.47 V)
> +5V:       +5.03 V  (min =  +4.76 V, max =  +5.24 V)
> Vdimm:     +2.59 V  (min =  +2.46 V, max =  +2.74 V)
> 5VSB:      +4.95 V  (min =  +4.76 V, max =  +5.24 V)
> Vbat:      +3.30 V  (min =  +2.85 V, max =  +3.47 V)
> fan1:        0 RPM  (min = 1102 RPM, div = 8)              ALARM
> fan2:     1394 RPM  (min = 1102 RPM, div = 8)
> temp1:       +39?C  (high =    +2?C, hyst =   +52?C)   sensor = diode
> temp2:     +38.0?C  (high =   +80?C, hyst =   +52?C)   sensor = diode
> temp3:     +56.0?C  (high =   +80?C, hyst =   +65?C)   sensor = diode
> vid:      -4.825 V  (VRM Version 2.4)
> alarms:
> beep_enable:
>           Sound alarm enabled

Looks rather good already.

> Notes:
> - fan1 is, of course, the exhaust fan which is currently unplugged and 
> sitting on my desk.
> - vid is obviously incorrect

Looks like on your system, the VID pins are used for an alternative
function (game port/MIDI) so you wouldn't have a valid reading anyway.
That left apart, the bug (vid shouldn't show at all in this case) is
fixed in later versions of the kernel already. For now you can simply
ignore this value.

Attached is an updated version of the configuration file. Everything
should look OK now.

-- 
Jean Delvare
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: sensors-Soltek-B9D-FGR.conf
Url: http://lists.lm-sensors.org/pipermail/lm-sensors/attachments/20060116/b5c66a12/sensors-Soltek-B9D-FGR-0001.pl

[lm-sensors] seeking a W83687THF patch for 2.6.15 (re: ticket

[Jean Delvare]

Hi Steven,

> Looking in /usr/lib I notice only one library: libsensors.a (which is 
> from Sept 12th/05 ... marking it as being from v2.9.1)
> 
> Looking in /usr/local/lib reveals 4 files (all of which dated Jan 9th/06):
> libsensors.a
> libsensors.so ... which is a link to libsensors.so.3
> libsensors.so.3 .... which is a link to libsensors.so.3.0.9
> libsensors.so.3.0.9
> 
> Should I just copy the libsensors.a and libsensors.so.3.0.9 into /usr/lib ?

No! Don't touch anything. Static libraries (.a files) shouldn't cause
any trouble, they are not even used by "sensors". So you have a single
dynamic library (libsensors.so.3.0.9 under /usr/local/lib) and that's
alright that way. If it ain't broken, don't fix it! :)

> Any potential for error if the the wrong library is being read?

You would miss the improvements brought by the newer version if this
was happening to you. Additionally you might enounter missing symbol
errors. It's quite frequent that people install lm_sensors CVS
in /usr/local and still have lm_sensors from their distribution
in /usr. Usually they will run the right (new) version of "sensors" (if
their PATH is correct, that is) but that version of sensors may link
dynamically with libsensors from /usr/lib - the old version.

Our installation process tries to detect the case and should warn about
it, but it might not always work and not everyone pays attention to the
warnings, unfortunately.

-- 
Jean Delvare

[lm-sensors] seeking a W83687THF patch for 2.6.15 (re: ticket

[Mark M. Hoffman]

Hi:

* Steven Karatnyk <stevenkaratnyk at rogers.com> [2006-01-16 15:11:03 -0500]:
> > Any potential for error if the the wrong library is being read?

* Jean Delvare <khali at linux-fr.org> [2006-01-16 23:27:03 +0100]:
> You would miss the improvements brought by the newer version if this
> was happening to you. Additionally you might enounter missing symbol
> errors. It's quite frequent that people install lm_sensors CVS
> in /usr/local and still have lm_sensors from their distribution
> in /usr. Usually they will run the right (new) version of "sensors" (if
> their PATH is correct, that is) but that version of sensors may link
> dynamically with libsensors from /usr/lib - the old version.
> 
> Our installation process tries to detect the case and should warn about
> it, but it might not always work and not everyone pays attention to the
> warnings, unfortunately.

Steven, you can use the following command to see which libraries would be
used by sensors:

	$ ldd `which sensors`

E.g., mine says this:

	$ ldd `which sensors`
        	linux-gate.so.1 =>  (0xffffe000)
        	libsensors.so.3 => /usr/local/lib/libsensors.so.3 (0xb7f65000)
        	libc.so.6 => /lib/tls/libc.so.6 (0xb7e22000)
        	libm.so.6 => /lib/tls/libm.so.6 (0xb7dff000)
        	libsysfs.so.1 => /usr/lib/libsysfs.so.1 (0xb7df5000)
        	/lib/ld-linux.so.2 (0xb7f9f000)

Regards,

-- 
Mark M. Hoffman
mhoffman at lightlink.com

[lm-sensors] seeking a W83687THF patch for 2.6.15 (re: ticket

[Steven Karatnyk]

Hi Jean,

Sorry for the delay in replying.

Jean Delvare wrote:
> When does the values change? If on reboot or deep sleep, it might just
> mean that these registers have no default power-up value. If on the
> other hand the values change during the regular system use, I'd
> diagnose a chip failure - it shouldn't lose the register values that
> way. Or something (BIOS?) is writing crap to these registers. Not much
> we can do in either case, I fear.
>
> If you can observe anything more detailed (e.g. how or when exactly the
> values change), please let us know. Also, please confirm that the limit
> values are always correct right after running "sensors -s && sleep 3 &&
> sensors".
>   
I'm pretty sure that its occurring (randomly) after a cold boot -- I say 
randomly because I still haven't detected a pattern and because not 
every cold boot generates a change (even those after over night down 
time).   However, I wouldn't rule out the BIOS though either.

Actually, another thing I've noticed is that since the time I added the 
initial configuration settings to sensors.conf, its only been the "high" 
(or temp1_max) value that I've now seen change .  The "hysteresis" value 
has been constant at 52C.

Running "sensors -s && sleep 3 && sensors" hasn't affected a change to 
the values.  However, it does generate some errors:

# sensors -s && sleep 3 && sensors
Error: Line 2437: Unknown feature name
Error: Line 2439: Unknown feature name
Error: Line 2441: Unknown feature name
w83687thf-isa-0290: No such feature known
lm90-i2c-0-4c
Adapter: SMBus Via Pro adapter at 5000

M/B Temp:    +37?C  (low  =   +10?C, high =   +50?C)
CPU Temp:  +55.4?C  (low  = +10.0?C, high = +70.0?C)
M/B Crit:    +70?C  (hyst =   +65?C)
CPU Crit:    +80?C  (hyst =   +75?C)

w83687thf-isa-0290
Adapter: ISA adapter
Vcore:     +1.10 V  (min =  +1.05 V, max =  +1.47 V)
+1.5V:     +1.52 V  (min =  +1.42 V, max =  +1.57 V)
+3.3V:     +3.30 V  (min =  +3.14 V, max =  +3.47 V)
+5V:       +5.03 V  (min =  +4.76 V, max =  +5.24 V)
Vdimm:     +2.59 V  (min =  +2.46 V, max =  +2.74 V)
5VSB:      +4.95 V  (min =  +4.76 V, max =  +5.24 V)
Vbat:      +3.30 V  (min =  +2.85 V, max =  +3.47 V)
Case Fan: 1339 RPM  (min = 1102 RPM, div = 8)
CPU Fan:  1406 RPM  (min = 1102 RPM, div = 8)
M/B Temp:    +40?C  (high =    +6?C, hyst =   +52?C)   sensor = diode
CPU Ext:   +40.5?C  (high =   +80?C, hyst =   +52?C)   sensor = diode
CPU Int:   +60.0?C  (high =   +80?C, hyst =   +65?C)   sensor = diode
alarms:
beep_enable:
          Sound alarm enabled


> As a side note, these are quite high temperatures you have here. I know
> that modern CPUs are supposed to support such high temperatures, but
> I'm not sure all components of your system will have a long life at
> this temperature. You may consider a superior cooling system.
>   
Cooling for SFF systems, given the tight quarters, is problematic to 
begin with, but this case's internal design seems to only compound that 
issue....and although my results (with the stock cooling system) are 
consistent with those reported by other users, I find that of little 
consolation, as the temps I have reported are indeed pretty unimpressive.

The exhaust fan (which is essentially similar to a pci slot blower fan) 
is pitifully ineffective -- it makes only a marginal amount of 
difference, but certainly adds to the noise profile.  The CPU cooler and 
the PSU fan also are in direct competition for air flow ... and speaking 
of airflow, its pretty poor.

I would love to make some modifications, but given the internal layout, 
it would require a good deal of thought and time to come up with 
something that can overcome the present deficiencies.  And time is 
probably the biggest factor working against making such an effort.

> Well if that's a BIOS bug there's not much we can do. What we should
> offer OTOH is a full interface to the chip to tweak the automatic fan
> speed in a much more detailed (and accurate, in your case) way than the
> BIOS offers. There's a patch flaoting around, but nobody (counting me)
> had the time to actually merge it. Shame on us.
>   
Do tell.  Is this patch specific to Winbond's thermal cruise?  In the 
meantime I'll google for it.

>>>> - Interesting that there is no +12V reading
>>>>         
>>> True, that's unusual, but not unseen.
>>>       
>> Would this be strictly a BIOS limitation of not exposing such monitoring?
>>     
>
> No. As you can see, "sensors" doesn't show the value either. +12V is
> simply not wired to the monitoring chip on your board. That's a
> physical issue.
>   

Ah, I see.   Any rationale behind that decision of board makers that you 
know of?

>> vid:      -4.825 V  (VRM Version 2.4)
> Looks like on your system, the VID pins are used for an alternative
> function (game port/MIDI) so you wouldn't have a valid reading anyway.
> That left apart, the bug (vid shouldn't show at all in this case) is
> fixed in later versions of the kernel already. For now you can simply
> ignore this value.
>
> Attached is an updated version of the configuration file. Everything
> should look OK now.
>   

Indeed it does (see above for output).  Much appreciation.

Thanks, Steven

[lm-sensors] seeking a W83687THF patch for 2.6.15 (re: ticket

[Steven Karatnyk]

Jean Delvare wrote:
>> Looking in /usr/lib I notice only one library: libsensors.a (which is 
>> from Sept 12th/05 ... marking it as being from v2.9.1)
>>
>> Looking in /usr/local/lib reveals 4 files (all of which dated Jan 9th/06):
>> libsensors.a
>> libsensors.so ... which is a link to libsensors.so.3
>> libsensors.so.3 .... which is a link to libsensors.so.3.0.9
>> libsensors.so.3.0.9
>>
>> Should I just copy the libsensors.a and libsensors.so.3.0.9 into /usr/lib ?
>>     
>
> No! Don't touch anything. Static libraries (.a files) shouldn't cause
> any trouble, they are not even used by "sensors". So you have a single
> dynamic library (libsensors.so.3.0.9 under /usr/local/lib) and that's
> alright that way. If it ain't broken, don't fix it! :)
>
>   
>> Any potential for error if the the wrong library is being read?
>>     
>
> You would miss the improvements brought by the newer version if this
> was happening to you. Additionally you might enounter missing symbol
> errors. It's quite frequent that people install lm_sensors CVS
> in /usr/local and still have lm_sensors from their distribution
> in /usr. Usually they will run the right (new) version of "sensors" (if
> their PATH is correct, that is) but that version of sensors may link
> dynamically with libsensors from /usr/lib - the old version.
>   
Thanks for explaining.

> Our installation process tries to detect the case and should warn about
> it, but it might not always work and not everyone pays attention to the
> warnings, unfortunately.

I do remember such a message. I also remember there was also a step 
which was going to copy something over to something else, and I wasn't 
sure if that had automagically resolved any problems/conflicts or 
not.....and I didn't follow this up .... I was probably too lost in 
thought debating whether I had made the right choice of ISA or smbus ;)

Regards, Steven

[lm-sensors] seeking a W83687THF patch for 2.6.15 (re: ticket

[Steven Karatnyk]

Hi Mark,

Mark M. Hoffman wrote:
> Steven, you can use the following command to see which libraries would be
> used by sensors:
>
> 	$ ldd `which sensors`
>
> E.g., mine says this:
>
> 	$ ldd `which sensors`
>         	linux-gate.so.1 =>  (0xffffe000)
>         	libsensors.so.3 => /usr/local/lib/libsensors.so.3 (0xb7f65000)
>         	libc.so.6 => /lib/tls/libc.so.6 (0xb7e22000)
>         	libm.so.6 => /lib/tls/libm.so.6 (0xb7dff000)
>         	libsysfs.so.1 => /usr/lib/libsysfs.so.1 (0xb7df5000)
>         	/lib/ld-linux.so.2 (0xb7f9f000)

Now there's a neat trick :)

As user I get:

$ ldd `which sensors`
linux-gate.so.1 => (0xffffe000)
libsensors.so.3 => /usr/local/lib/libsensors.so.3 (0x40017000)
libc.so.6 => /lib/tls/libc.so.6 (0x40065000)
libm.so.6 => /lib/tls/libm.so.6 (0x40184000)
libsysfs.so.1 => /lib/libsysfs.so.1 (0x401aa000)
/lib/ld-linux.so.2 (0x40000000)

As root, there is a slight difference (libsensors.so.3):

# ldd `which sensors`
linux-gate.so.1 => (0xffffe000)
libsensors.so.3 => /usr/local/lib/libsensors.so.3 (0x40018000)
libc.so.6 => /lib/tls/libc.so.6 (0x40065000)
libm.so.6 => /lib/tls/libm.so.6 (0x40184000)
libsysfs.so.1 => /lib/libsysfs.so.1 (0x401aa000)
/lib/ld-linux.so.2 (0x40000000)

Thanks, Steven

[lm-sensors] seeking a W83687THF patch for 2.6.15 (re: ticket

[Jean Delvare]

Hi Steven,

> > If you can observe anything more detailed (e.g. how or when exactly the
> > values change), please let us know. Also, please confirm that the limit
> > values are always correct right after running "sensors -s && sleep 3 &&
> > sensors".
>
> I'm pretty sure that its occurring (randomly) after a cold boot -- I say 
> randomly because I still haven't detected a pattern and because not 
> every cold boot generates a change (even those after over night down 
> time).   However, I wouldn't rule out the BIOS though either.

If it is changing on boot only, it could be explained by the chip not
having well-defined power-up default values for these registers.

> Actually, another thing I've noticed is that since the time I added the 
> initial configuration settings to sensors.conf, its only been the "high" 
> (or temp1_max) value that I've now seen change .  The "hysteresis" value 
> has been constant at 52C.

Related to an error of mine, see right below.

> Running "sensors -s && sleep 3 && sensors" hasn't affected a change to 
> the values.  However, it does generate some errors:
> 
> # sensors -s && sleep 3 && sensors
> Error: Line 2437: Unknown feature name
> Error: Line 2439: Unknown feature name
> Error: Line 2441: Unknown feature name
> w83687thf-isa-0290: No such feature known

Hm, this is bad, and my bad. The sample configuration file I sent to
you had some mistakes. Attached is a fixed version, which should fix
these errors. "sensors -s" should now properly set high temperature
limits.

If any limit changes unexpectedly after that again, please report.

> lm90-i2c-0-4c
> Adapter: SMBus Via Pro adapter at 5000
> 
> M/B Temp:    +37?C  (low  =   +10?C, high =   +50?C)
> CPU Temp:  +55.4?C  (low  = +10.0?C, high = +70.0?C)
> M/B Crit:    +70?C  (hyst =   +65?C)
> CPU Crit:    +80?C  (hyst =   +75?C)
> 
> w83687thf-isa-0290
> Adapter: ISA adapter
> Vcore:     +1.10 V  (min =  +1.05 V, max =  +1.47 V)
> +1.5V:     +1.52 V  (min =  +1.42 V, max =  +1.57 V)
> +3.3V:     +3.30 V  (min =  +3.14 V, max =  +3.47 V)
> +5V:       +5.03 V  (min =  +4.76 V, max =  +5.24 V)
> Vdimm:     +2.59 V  (min =  +2.46 V, max =  +2.74 V)
> 5VSB:      +4.95 V  (min =  +4.76 V, max =  +5.24 V)
> Vbat:      +3.30 V  (min =  +2.85 V, max =  +3.47 V)
> Case Fan: 1339 RPM  (min = 1102 RPM, div = 8)
> CPU Fan:  1406 RPM  (min = 1102 RPM, div = 8)
> M/B Temp:    +40?C  (high =    +6?C, hyst =   +52?C)   sensor = diode
> CPU Ext:   +40.5?C  (high =   +80?C, hyst =   +52?C)   sensor = diode
> CPU Int:   +60.0?C  (high =   +80?C, hyst =   +65?C)   sensor = diode
> alarms:
> beep_enable:
>           Sound alarm enabled

Everything else looks quite good here :)

> > Well if that's a BIOS bug there's not much we can do. What we should
> > offer OTOH is a full interface to the chip to tweak the automatic fan
> > speed in a much more detailed (and accurate, in your case) way than the
> > BIOS offers. There's a patch flaoting around, but nobody (counting me)
> > had the time to actually merge it. Shame on us.
>
> Do tell.  Is this patch specific to Winbond's thermal cruise?  In the 
> meantime I'll google for it.

The patch is even more specific than this. It is specific to the
Winbond W83627THF. Getting it to work with the W83687THF should be
possible as both chips seem to share most of their features, but this
would need to be checked carefully.

> > No. As you can see, "sensors" doesn't show the value either. +12V is
> > simply not wired to the monitoring chip on your board. That's a
> > physical issue.
> 
> Ah, I see.   Any rationale behind that decision of board makers that you 
> know of?

Every manufacturer is free to monitor whatever they want on every
single board the design. There are no rules. Given that the W83687THF
can monitor "only" 7 voltage inputs, and a regular system usually has
10 these days, Soltek had to make a choice. They discarded -5V, -12V
and +12V. That's not a bad choice if you want my opinion. Negative
voltages are unused in modern systems as far as I know, and pretty much
every single recent board we've had a report for did not monitor them
anymore.

+12V probably tends to be less and less used too, as lower
voltages are used in recent designs. CPUs were powered with 3.5V tens
years ago, and now most are in the 1.0-1.6V range. The AGP voltage is
as low as 1.5V. Recent chips are powered with +3.3V instead of +5V, and
Winbond even dropped their 16mV LSB ADC for a 8mV LSB ADC in one of
their most recent chips (W83627EHF), so you can monitor raw voltages in
the 0-2.04V range instead of 0-4.08V range. See, all voltages are
slowly getting lower. As far as I know, +12V is only used for drive
motors in our computers now - or to derive lower voltages.

-- 
Jean Delvare
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: sensors-Soltek-B9D-FGR.conf
Url: http://lists.lm-sensors.org/pipermail/lm-sensors/attachments/20060120/0019ca04/sensors-Soltek-B9D-FGR.pl

[lm-sensors] seeking a W83687THF patch for 2.6.15 (re: ticket

[Steven Karatnyk]

Hi Jean,

Thanks for the explanations in the last message.  Things are, for the 
most part, running very well -- I do have a few things I wanted to 
follow up on though.   I would have done so earlier, but I've felt 
pretty run down over the last couple of days and so limited my leisure 
time computer activities to just a few other areas.  I'll try to 
formulate these questions and thoughts up in the next day or so.  As a 
teaser, I think I may have an idea as to what that VID sensor is 
actually monitoring, but I'll have to do some investigation to firm up 
my suspicions (which, of course, could be entirely wrong anyways).