* Re: [lm-sensors] sensors-detect: testers wanted!
2008-12-03 17:22 [lm-sensors] sensors-detect: testers wanted! Jean Delvare
@ 2008-12-03 18:25 ` Jean-Marc Spaggiari
2008-12-03 19:18 ` Jean Delvare
` (7 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: Jean-Marc Spaggiari @ 2008-12-03 18:25 UTC (permalink / raw)
To: lm-sensors
2008/12/3 Jean Delvare <khali@linux-fr.org>:
> Hi all,
>
> Over the past few days, I have been working a lot on sensors-detect. I
> implemented ideas I had exposed months ago but did not have the time to
> implement back then:
>
> id summary
> 2322 The probe order in sensors-detect doesn't make sense
> 2325 sensors-detect: Drop support for Linux 2.4
> 2327 sensors-detect: Fix the bus numbering prediction magic
> 2328 sensors-detect: Get the bus driver names from the kernel
> 2329 sensors-detect: Unload drivers which we loaded ourselves
>
> I also made a huge amount of cleanups (including a complete
> reindentation of the source code), reducing the size of the
> sensors-detect script from 185 kB to roughly 145 kB.
>
> With so many changes, both in functionality and implementation, I
> expect some fallouts. I tested my work on several machines already, but
> there are so many possible combinations of devices that it is rather
> unlikely that I managed to get everything right.
>
> So, I would like users to give a try to the latest version of
> sensors-detect and report if it works fine for them or not. You can get
> the latest version of sensors-detect using the following svn command:
>
> svn export http://lm-sensors.org/svn/lm-sensors/branches/lm-sensors-3.0.0/prog/detect/sensors-detect
>
> Alternatively, you can get a copy from trac:
> http://www.lm-sensors.org/browser/lm-sensors/branches/lm-sensors-3.0.0/prog/detect/sensors-detect?format=txt
>
> The behavior should be essentially the same as before, with the
> difference that probes are done in reverse order (CPU, Super I/O, ISA,
> SMBus), and ISA and SMBus probes default to no if a working Super I/O
> was found (as was discussed on the list before [1].)
>
> [1] http://lists.lm-sensors.org/pipermail/lm-sensors/2008-May/023056.html
>
> Thanks,
> --
> Jean Delvare
>
> _______________________________________________
> lm-sensors mailing list
> lm-sensors@lm-sensors.org
> http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
>
Hi Jean,
Here is what I have with your version:
Driver `it87':
* ISA bus, address 0xe80
Chip `ITE IT8720F Super IO Sensors' (confidence: 9)
Driver `to-be-written':
* Chip `AMD K10 thermal sensors' (confidence: 9)
And here is what I had with the previous one:
Driver `it87' (should be inserted):
Detects correctly:
* ISA bus, address 0xe80
Chip `ITE IT8720 Super IO Sensors' (confidence: 9)
Driver `k8temp' (should be inserted):
Detects correctly:
* Chip `AMD K10 thermal sensors' (confidence: 9)
I'm not 100% sur why I had a K8 before and a K10 with this new
version. I remember that I have apply a patch in the kernel to handle
Phenom internal sensors, but since this is kernel related, I think it
should have no impact on the sensors-detect script. I will try to
install and compile a brand next 2.6.27.7 kernel and retest.
JM
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply [flat|nested] 10+ messages in thread* Re: [lm-sensors] sensors-detect: testers wanted!
2008-12-03 17:22 [lm-sensors] sensors-detect: testers wanted! Jean Delvare
2008-12-03 18:25 ` Jean-Marc Spaggiari
@ 2008-12-03 19:18 ` Jean Delvare
2008-12-03 21:55 ` Matt Roberds
` (6 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: Jean Delvare @ 2008-12-03 19:18 UTC (permalink / raw)
To: lm-sensors
Hi Jean-Marc,
Thanks for testing and reporting.
On Wed, 3 Dec 2008 13:25:10 -0500, Jean-Marc Spaggiari wrote:
> Here is what I have with your version:
>
> Driver `it87':
> * ISA bus, address 0xe80
> Chip `ITE IT8720F Super IO Sensors' (confidence: 9)
>
> Driver `to-be-written':
> * Chip `AMD K10 thermal sensors' (confidence: 9)
>
>
> And here is what I had with the previous one:
>
> Driver `it87' (should be inserted):
> Detects correctly:
> * ISA bus, address 0xe80
> Chip `ITE IT8720 Super IO Sensors' (confidence: 9)
>
> Driver `k8temp' (should be inserted):
> Detects correctly:
> * Chip `AMD K10 thermal sensors' (confidence: 9)
>
>
> I'm not 100% sur why I had a K8 before and a K10 with this new
> version. I remember that I have apply a patch in the kernel to handle
> Phenom internal sensors, but since this is kernel related, I think it
> should have no impact on the sensors-detect script. I will try to
> install and compile a brand next 2.6.27.7 kernel and retest.
You have a K10 (actually: family 10h) in both cases. What changed is
the device->driver mapping. At some point we thought that family 10h
support could be added to the k8temp driver, but now it seems that we
will have a separate driver for the family 10h CPUs. So this change is
expected.
--
Jean Delvare
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply [flat|nested] 10+ messages in thread* Re: [lm-sensors] sensors-detect: testers wanted!
2008-12-03 17:22 [lm-sensors] sensors-detect: testers wanted! Jean Delvare
2008-12-03 18:25 ` Jean-Marc Spaggiari
2008-12-03 19:18 ` Jean Delvare
@ 2008-12-03 21:55 ` Matt Roberds
2008-12-03 22:25 ` Jean Delvare
` (5 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: Matt Roberds @ 2008-12-03 21:55 UTC (permalink / raw)
To: lm-sensors
On Wed, 3 Dec 2008, Jean Delvare wrote:
> So, I would like users to give a try to the latest version of
> sensors-detect and report if it works fine for them or not.
Short version: Nothing blew up, but the new version didn't find
something that the old version did, until I gave different options to
the new version.
Long version: I unloaded the relevant kernel modules to simulate running
sensors-detect on a system that hasn't had lm_sensors set up before. I
didn't use any command-line arguments to sensors-detect, and I took all
the defaults by hitting "enter" at each prompt. I did this for both the
version from lm_sensors 3.0.3 (sensors-detect version 5337) and the
latest version. This is on a system with an Asus M2N-SLI Deluxe
motherboard.
The results from version 5337 (shipped with 3.0.3):
---
Driver `to-be-written' (should be inserted):
Detects correctly:
* Bus `SMBus nForce2 adapter at 1c40'
Busdriver `i2c-nforce2', I2C address 0x2e
Chip `Analog Devices ADT7475' (confidence: 5)
Driver `it87' (should be inserted):
Detects correctly:
* ISA bus, address 0x290
Chip `ITE IT8716F Super IO Sensors' (confidence: 9)
Driver `k8temp' (should be inserted):
Detects correctly:
* Chip `AMD K8 thermal sensors' (confidence: 9)
Do you want to generate /etc/sysconfig/lm_sensors? (yes/NO):
To load everything that is needed, add this to one of the system
initialization scripts (e.g. /etc/rc.d/rc.local):
#----cut here----
# I2C adapter drivers
modprobe i2c-nforce2
# Chip drivers
# no driver for Analog Devices ADT7475 yet
modprobe it87
modprobe k8temp
/usr/local/bin/sensors -s
#----cut here----
---
The results from the first run of the new version, taking all defaults:
---
Driver `it87':
* ISA bus, address 0x290
Chip `ITE IT8716F Super IO Sensors' (confidence: 9)
Driver `k8temp':
* Chip `AMD K8 thermal sensors' (confidence: 9)
Do you want to generate /etc/sysconfig/lm_sensors? (yes/NO):
To load everything that is needed, add this to one of the system
initialization scripts (e.g. /etc/rc.d/rc.local):
#----cut here----
# Chip drivers
modprobe it87
modprobe k8temp
/usr/local/bin/sensors -s
#----cut here----
---
The difference is that it didn't find the adt7475. I re-ran the new
version of sensors-detect, supplying non-default answers, in an attempt
to get it to find the adt7475. Here are the places where I gave
non-default answers, and the results.
---
Some hardware monitoring chips are accessible through the ISA I/O ports.
We have to write to arbitrary I/O ports to probe them. This is usually
safe though. Yes, you do have ISA I/O ports even if you do not have any
ISA slots! Do you want to scan the ISA I/O ports? (yes/no/IPMI ONLY): yes
Probing for `National Semiconductor LM78' at 0x290... No
Probing for `National Semiconductor LM79' at 0x290... No
Probing for `Winbond W83781D' at 0x290... No
Probing for `Winbond W83782D' at 0x290... No
Probing for `IPMI BMC KCS' at 0xca0... No
Probing for `IPMI BMC SMIC' at 0xca8... No
Next adapter: SMBus nForce2 adapter at 1c00 (i2c-4)
Do you want to scan it? (yes/NO/selectively): yes
Client at address 0x50 can not be probed - unload all client drivers first!
Client at address 0x51 can not be probed - unload all client drivers first!
Next adapter: SMBus nForce2 adapter at 1c40 (i2c-5)
Do you want to scan it? (yes/NO/selectively): yes
Client found at address 0x2e
Probing for `Myson MTP008'... No
Probing for `National Semiconductor LM78'... No
Probing for `National Semiconductor LM79'... No
Probing for `National Semiconductor LM80'... No
Probing for `National Semiconductor LM85'... No
Probing for `National Semiconductor LM96000 or PC8374L'... No
Probing for `Analog Devices ADM1027'... No
Probing for `Analog Devices ADT7460 or ADT7463'... No
Probing for `SMSC EMC6D100 or EMC6D101'... No
Probing for `SMSC EMC6D102'... No
Probing for `SMSC EMC6D103'... No
Probing for `Analog Devices ADT7467 or ADT7468'... No
Probing for `Analog Devices ADT7470'... No
Probing for `Analog Devices ADT7473'... No
Probing for `Analog Devices ADT7475'... Success!
(confidence 5, driver `to-be-written')
Probing for `Analog Devices ADT7476'... No
Probing for `Andigilog aSC7611'... No
Probing for `Andigilog aSC7621'... No
Probing for `National Semiconductor LM87'... No
Probing for `Analog Devices ADM1024'... No
Probing for `National Semiconductor LM93'... No
Probing for `Winbond W83781D'... No
Probing for `Winbond W83782D'... No
Probing for `Winbond W83791D'... No
Probing for `Winbond W83792D'... No
Probing for `Winbond W83793R/G'... No
Probing for `Winbond W83627HF'... No
Probing for `Winbond W83627EHF'... No
Probing for `Winbond W83627DHG'... No
Probing for `Asus AS99127F (rev.1)'... No
Probing for `Asus AS99127F (rev.2)'... No
Probing for `Asus ASB100 Bach'... No
Probing for `Winbond W83L786NR/NG/R/G'... No
Probing for `Winbond W83L785TS-S'... No
Probing for `Analog Devices ADM9240'... No
Probing for `Dallas Semiconductor DS1780'... No
Probing for `National Semiconductor LM81'... No
Probing for `Analog Devices ADM1026'... No
Probing for `Analog Devices ADM1025'... No
Probing for `Analog Devices ADM1029'... No
Probing for `Analog Devices ADM1030'... No
Probing for `Analog Devices ADM1031'... No
Probing for `Analog Devices ADM1022'... No
Probing for `Texas Instruments THMC50'... No
Probing for `Analog Devices ADM1028'... No
Probing for `Texas Instruments THMC51'... No
Probing for `ITE IT8712F'... No
Probing for `SMSC DME1737'... No
Probing for `SMSC SCH5027D-NW'... No
Probing for `Fintek F75373S/SG'... No
Probing for `Fintek F75375S/SP'... No
Probing for `Fintek F75387SG/RG'... No
Probing for `Winbond W83791SD'... No
Now follows a summary of the probes I have just done.
Just press ENTER to continue:
Driver `it87':
* ISA bus, address 0x290
Chip `ITE IT8716F Super IO Sensors' (confidence: 9)
Driver `to-be-written':
* Bus `SMBus nForce2 adapter at 1c40'
Busdriver `i2c-nforce2', I2C address 0x2e
Chip `Analog Devices ADT7475' (confidence: 5)
Driver `k8temp':
* Chip `AMD K8 thermal sensors' (confidence: 9)
Do you want to generate /etc/sysconfig/lm_sensors? (yes/NO):
To load everything that is needed, add this to one of the system
initialization scripts (e.g. /etc/rc.d/rc.local):
#----cut here----
# Chip drivers
modprobe it87
# no driver for Analog Devices ADT7475 yet
modprobe k8temp
/usr/local/bin/sensors -s
#----cut here----
---
Finally, here are some general comments on the new script.
> sensors-detect revision $Revision$
I assume this fixes itself when the script goes through the normal
release process.
> Some hardware monitoring chips are accessible through the ISA I/O ports.
> We have to write to arbitrary I/O ports to probe them. This is usually
> safe though. Yes, you do have ISA I/O ports even if you do not have any
> ISA slots! Do you want to scan the ISA I/O ports? (yes/no/IPMI ONLY):
You should include a few words in the help text about what IPMI ONLY
does and why you would want to choose it or not choose it. Will the
script behave with options that have spaces in them?
I hope this helps!
Matt Roberds
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply [flat|nested] 10+ messages in thread* Re: [lm-sensors] sensors-detect: testers wanted!
2008-12-03 17:22 [lm-sensors] sensors-detect: testers wanted! Jean Delvare
` (2 preceding siblings ...)
2008-12-03 21:55 ` Matt Roberds
@ 2008-12-03 22:25 ` Jean Delvare
2008-12-03 23:29 ` Matt Roberds
` (4 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: Jean Delvare @ 2008-12-03 22:25 UTC (permalink / raw)
To: lm-sensors
Hi Matt,
On Wed, 3 Dec 2008 15:55:12 -0600 (CST), Matt Roberds wrote:
> On Wed, 3 Dec 2008, Jean Delvare wrote:
> > So, I would like users to give a try to the latest version of
> > sensors-detect and report if it works fine for them or not.
>
> Short version: Nothing blew up, but the new version didn't find
> something that the old version did, until I gave different options to
> the new version.
>
> Long version: I unloaded the relevant kernel modules to simulate running
> sensors-detect on a system that hasn't had lm_sensors set up before. I
> didn't use any command-line arguments to sensors-detect, and I took all
> the defaults by hitting "enter" at each prompt. I did this for both the
> version from lm_sensors 3.0.3 (sensors-detect version 5337) and the
> latest version. This is on a system with an Asus M2N-SLI Deluxe
> motherboard.
>
> The results from version 5337 (shipped with 3.0.3):
>
> ---
> Driver `to-be-written' (should be inserted):
> Detects correctly:
> * Bus `SMBus nForce2 adapter at 1c40'
> Busdriver `i2c-nforce2', I2C address 0x2e
> Chip `Analog Devices ADT7475' (confidence: 5)
>
> Driver `it87' (should be inserted):
> Detects correctly:
> * ISA bus, address 0x290
> Chip `ITE IT8716F Super IO Sensors' (confidence: 9)
>
> Driver `k8temp' (should be inserted):
> Detects correctly:
> * Chip `AMD K8 thermal sensors' (confidence: 9)
>
> Do you want to generate /etc/sysconfig/lm_sensors? (yes/NO):
> To load everything that is needed, add this to one of the system
> initialization scripts (e.g. /etc/rc.d/rc.local):
>
> #----cut here----
> # I2C adapter drivers
> modprobe i2c-nforce2
> # Chip drivers
> # no driver for Analog Devices ADT7475 yet
> modprobe it87
> modprobe k8temp
> /usr/local/bin/sensors -s
> #----cut here----
> ---
>
> The results from the first run of the new version, taking all defaults:
>
> ---
> Driver `it87':
> * ISA bus, address 0x290
> Chip `ITE IT8716F Super IO Sensors' (confidence: 9)
>
> Driver `k8temp':
> * Chip `AMD K8 thermal sensors' (confidence: 9)
>
> Do you want to generate /etc/sysconfig/lm_sensors? (yes/NO):
> To load everything that is needed, add this to one of the system
> initialization scripts (e.g. /etc/rc.d/rc.local):
>
> #----cut here----
> # Chip drivers
> modprobe it87
> modprobe k8temp
> /usr/local/bin/sensors -s
> #----cut here----
> ---
>
> The difference is that it didn't find the adt7475. I re-ran the new
> version of sensors-detect, supplying non-default answers, in an attempt
> to get it to find the adt7475. Here are the places where I gave
> non-default answers, and the results.
Yes, this is by design. One of the goals of the new probing logic is to
skip probes which aren't expected to work by default. The idea behind
this choice is that we want to limit SMBus probing because it has
caused trouble in the past. As the script found a full-featured Super
I/O chip, it doesn't expect an additional chip on the SMBus. This
heuristic happens to be incorrect in your case, where the board
manufacturer decided to use both the Super I/O sensors and an
additional chip on the SMBus.
I seem to remember that Asus has done a lot of boards on that model
lately. So one possibility to work around this issue is to tweak the
probing logic based on the motherboard vendor. We can get the vendor
string from either /sys/class/dmi/id/board_vendor or "dmidecode -s
baseboard-manufacturer". For Asus (and Tyan) we would keep probing the
SMBus even in the presence of an enabled Super I/O.
> ---
> Some hardware monitoring chips are accessible through the ISA I/O ports.
> We have to write to arbitrary I/O ports to probe them. This is usually
> safe though. Yes, you do have ISA I/O ports even if you do not have any
> ISA slots! Do you want to scan the ISA I/O ports? (yes/no/IPMI ONLY): yes
> Probing for `National Semiconductor LM78' at 0x290... No
> Probing for `National Semiconductor LM79' at 0x290... No
> Probing for `Winbond W83781D' at 0x290... No
> Probing for `Winbond W83782D' at 0x290... No
> Probing for `IPMI BMC KCS' at 0xca0... No
> Probing for `IPMI BMC SMIC' at 0xca8... No
>
> Next adapter: SMBus nForce2 adapter at 1c00 (i2c-4)
> Do you want to scan it? (yes/NO/selectively): yes
> Client at address 0x50 can not be probed - unload all client drivers first!
> Client at address 0x51 can not be probed - unload all client drivers first!
>
> Next adapter: SMBus nForce2 adapter at 1c40 (i2c-5)
> Do you want to scan it? (yes/NO/selectively): yes
> Client found at address 0x2e
> Probing for `Myson MTP008'... No
> Probing for `National Semiconductor LM78'... No
> Probing for `National Semiconductor LM79'... No
> Probing for `National Semiconductor LM80'... No
> Probing for `National Semiconductor LM85'... No
> Probing for `National Semiconductor LM96000 or PC8374L'... No
> Probing for `Analog Devices ADM1027'... No
> Probing for `Analog Devices ADT7460 or ADT7463'... No
> Probing for `SMSC EMC6D100 or EMC6D101'... No
> Probing for `SMSC EMC6D102'... No
> Probing for `SMSC EMC6D103'... No
> Probing for `Analog Devices ADT7467 or ADT7468'... No
> Probing for `Analog Devices ADT7470'... No
> Probing for `Analog Devices ADT7473'... No
> Probing for `Analog Devices ADT7475'... Success!
> (confidence 5, driver `to-be-written')
> Probing for `Analog Devices ADT7476'... No
> Probing for `Andigilog aSC7611'... No
> Probing for `Andigilog aSC7621'... No
> Probing for `National Semiconductor LM87'... No
> Probing for `Analog Devices ADM1024'... No
> Probing for `National Semiconductor LM93'... No
> Probing for `Winbond W83781D'... No
> Probing for `Winbond W83782D'... No
> Probing for `Winbond W83791D'... No
> Probing for `Winbond W83792D'... No
> Probing for `Winbond W83793R/G'... No
> Probing for `Winbond W83627HF'... No
> Probing for `Winbond W83627EHF'... No
> Probing for `Winbond W83627DHG'... No
> Probing for `Asus AS99127F (rev.1)'... No
> Probing for `Asus AS99127F (rev.2)'... No
> Probing for `Asus ASB100 Bach'... No
> Probing for `Winbond W83L786NR/NG/R/G'... No
> Probing for `Winbond W83L785TS-S'... No
> Probing for `Analog Devices ADM9240'... No
> Probing for `Dallas Semiconductor DS1780'... No
> Probing for `National Semiconductor LM81'... No
> Probing for `Analog Devices ADM1026'... No
> Probing for `Analog Devices ADM1025'... No
> Probing for `Analog Devices ADM1029'... No
> Probing for `Analog Devices ADM1030'... No
> Probing for `Analog Devices ADM1031'... No
> Probing for `Analog Devices ADM1022'... No
> Probing for `Texas Instruments THMC50'... No
> Probing for `Analog Devices ADM1028'... No
> Probing for `Texas Instruments THMC51'... No
> Probing for `ITE IT8712F'... No
> Probing for `SMSC DME1737'... No
> Probing for `SMSC SCH5027D-NW'... No
> Probing for `Fintek F75373S/SG'... No
> Probing for `Fintek F75375S/SP'... No
> Probing for `Fintek F75387SG/RG'... No
> Probing for `Winbond W83791SD'... No
>
> Now follows a summary of the probes I have just done.
> Just press ENTER to continue:
>
> Driver `it87':
> * ISA bus, address 0x290
> Chip `ITE IT8716F Super IO Sensors' (confidence: 9)
>
> Driver `to-be-written':
> * Bus `SMBus nForce2 adapter at 1c40'
> Busdriver `i2c-nforce2', I2C address 0x2e
> Chip `Analog Devices ADT7475' (confidence: 5)
>
> Driver `k8temp':
> * Chip `AMD K8 thermal sensors' (confidence: 9)
>
> Do you want to generate /etc/sysconfig/lm_sensors? (yes/NO):
> To load everything that is needed, add this to one of the system
> initialization scripts (e.g. /etc/rc.d/rc.local):
>
> #----cut here----
> # Chip drivers
> modprobe it87
> # no driver for Analog Devices ADT7475 yet
> modprobe k8temp
> /usr/local/bin/sensors -s
> #----cut here----
> ---
>
> Finally, here are some general comments on the new script.
>
> > sensors-detect revision $Revision$
>
> I assume this fixes itself when the script goes through the normal
> release process.
Yes it would. Blame it on trac, it really should do the keyword
substitution when one asks for a file through the web interface, but it
doesn't. I really hope it gets fixed someday. That's the reason why I
gave the svn command to retrieve the file - you get keyword
substitution that way.
> > Some hardware monitoring chips are accessible through the ISA I/O ports.
> > We have to write to arbitrary I/O ports to probe them. This is usually
> > safe though. Yes, you do have ISA I/O ports even if you do not have any
> > ISA slots! Do you want to scan the ISA I/O ports? (yes/no/IPMI ONLY):
>
> You should include a few words in the help text about what IPMI ONLY
> does and why you would want to choose it or not choose it. Will the
> script behave with options that have spaces in them?
Yes, the script simply matches the 1st letter of each option, so spaces
aren't an issue. But that's also pretty fragile. I didn't invent it,
the script was written that way originally. But I agree that there is
room for improvement.
The reasons for probing only for IPMI devices on the ISA bus are: IPMI
can be found on all systems while ISA hardware monitoring chips are
only found on old systems, and IPMI probing is read-only while we need
to write to I/O ports for the other chips. I wanted to keep things as
simple as possible, assuming that most users would just go with the
default answer, but you are more curious than I expected ;)
An alternative would be to simply split IPMI interface probing to its own
section, as these are fundamentally different from legacy ISA chips.
I'll think about it. I am curious what others think about this idea.
I didn't want to explain everything in detail in the script, again to
not frighten the user with long explanations, when most users should be
able to just hit "Return" and be done with it. But maybe I am too
optimistic and the lack of information is what will frighten the
users ;)
I'm not sure how to add more information without making sensors-detect
painful to use in the main case. Maybe we can add all the detailed
information to the manual page? Or maybe something like make oldconfig
in the kernel, that is, answering "?" to any question displays a help
text and asks the question again? Suggestions welcome.
> I hope this helps!
Yes it does. I am certainly not the best person to get the user
interface of sensors-detect right, as I am way too familiar with it. So
having feedback from users is very valuable.
Thanks,
--
Jean Delvare
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply [flat|nested] 10+ messages in thread* Re: [lm-sensors] sensors-detect: testers wanted!
2008-12-03 17:22 [lm-sensors] sensors-detect: testers wanted! Jean Delvare
` (3 preceding siblings ...)
2008-12-03 22:25 ` Jean Delvare
@ 2008-12-03 23:29 ` Matt Roberds
2008-12-05 11:00 ` Jean Delvare
` (3 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: Matt Roberds @ 2008-12-03 23:29 UTC (permalink / raw)
To: lm-sensors
On Wed, 3 Dec 2008, Jean Delvare wrote:
> On Wed, 3 Dec 2008 15:55:12 -0600 (CST), Matt Roberds wrote:
>> The difference is that it didn't find the adt7475.
>
> Yes, this is by design. One of the goals of the new probing logic is
> to skip probes which aren't expected to work by default.
I remember the discussion about this a few months ago, yes.
> For Asus (and Tyan) we would keep probing the SMBus even in the
> presence of an enabled Super I/O.
This is probably helpful, as long as these boards are also known not to
blow up too badly when you do probes that have to write to the hardware.
I would suggest that you keep the heuristic in sensors-detect pretty
broad; going by manufacturer and possibly by top-level CPU type (AMD,
Intel, or other) is probably as fine as you want to go in
sensors-detect. Otherwise you end up having to maintain all kinds of
special-case stuff in sensors-detect, instead of actually working on the
hardware drivers etc.
>>> Do you want to scan the ISA I/O ports? (yes/no/IPMI ONLY):
>>
>> You should include a few words in the help text about what IPMI ONLY
>> does and why you would want to choose it or not choose it.
>
> I wanted to keep things as simple as possible, assuming that most
> users would just go with the default answer, but you are more curious
> than I expected ;)
I don't know how much you should tune to me, because I am probably not a
typical end-user. In general, there are limits, but I don't mind having
a few choices, as long as I have some idea of what the different choices
do, or a pointer to documentation. (The kernel configuration has lots
of things like "If you have an Acme 100, say "Y" here and read
Documentation/acme-100.txt.") Just having the "IPMI ONLY" option pop up
with no further discussion in the prompt text is a little jarring IMHO.
> An alternative would be to simply split IPMI interface probing to its
> own section, as these are fundamentally different from legacy ISA
> chips.
I think this might be useful. That might let you spend a sentence or
two explaining IPMI and why you might want to probe it or not before
asking the user for a choice.
> I didn't want to explain everything in detail in the script, again to
> not frighten the user with long explanations, when most users should be
> able to just hit "Return" and be done with it.
This is a useful goal. But also, most users are only going to run
sensors-detect once or a small number of times while they are getting
things set up, and then they don't have to deal with it again for quite
a while. IMHO it's OK to be a little more wordy in this case; I think
it tends to help people make better choices the first time through,
which means they are more likely to end up with a working configuration.
> I'm not sure how to add more information without making sensors-detect
> painful to use in the main case.
Links to the man page might be a good idea. ("See the MICROCHANNEL
heading on the sensors-detect man page.") Maybe URLs, if you are
prepared to fight URL rot.
Matt Roberds
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply [flat|nested] 10+ messages in thread* Re: [lm-sensors] sensors-detect: testers wanted!
2008-12-03 17:22 [lm-sensors] sensors-detect: testers wanted! Jean Delvare
` (4 preceding siblings ...)
2008-12-03 23:29 ` Matt Roberds
@ 2008-12-05 11:00 ` Jean Delvare
2008-12-05 23:44 ` Matt Roberds
` (2 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: Jean Delvare @ 2008-12-05 11:00 UTC (permalink / raw)
To: lm-sensors
Hi Matt,
On Wed, 3 Dec 2008 17:29:50 -0600 (CST), Matt Roberds wrote:
> On Wed, 3 Dec 2008, Jean Delvare wrote:
> > For Asus (and Tyan) we would keep probing the SMBus even in the
> > presence of an enabled Super I/O.
>
> This is probably helpful, as long as these boards are also known not to
> blow up too badly when you do probes that have to write to the hardware.
I can't remember such problems with Asus nor Tyan boards so far.
This is done now. And now that I think of it, we can probably add
SuperMicro to the list, they too tend to add hardware monitoring chips
even when the Super-I/O embeds sensors.
> I would suggest that you keep the heuristic in sensors-detect pretty
> broad; going by manufacturer and possibly by top-level CPU type (AMD,
> Intel, or other) is probably as fine as you want to go in
> sensors-detect. Otherwise you end up having to maintain all kinds of
> special-case stuff in sensors-detect, instead of actually working on the
> hardware drivers etc.
I totally agree. I have gone the vendor-white-listing way because I
think it will work fine without too much extra work, but if it doesn't
then we're back to the more simple and safer heuristic, even if this
means more work for some users.
> > (...)
> > An alternative would be to simply split IPMI interface probing to its
> > own section, as these are fundamentally different from legacy ISA
> > chips.
>
> I think this might be useful. That might let you spend a sentence or
> two explaining IPMI and why you might want to probe it or not before
> asking the user for a choice.
This is done now. Please note though that I am by far no IPMI expert,
so my wording may not be the best. If anyone has suggestions on how to
improve it, please speak up and make proposals.
> > I didn't want to explain everything in detail in the script, again to
> > not frighten the user with long explanations, when most users should be
> > able to just hit "Return" and be done with it.
>
> This is a useful goal. But also, most users are only going to run
> sensors-detect once or a small number of times while they are getting
> things set up, and then they don't have to deal with it again for quite
> a while. IMHO it's OK to be a little more wordy in this case; I think
> it tends to help people make better choices the first time through,
> which means they are more likely to end up with a working configuration.
You're certainly right. I didn't have the time to write more
documentation though, and I probably won't have the time in an
immediate future. I've spend many many hours on sensors-detect in the
past 10 days, while there are many other issues which need my attention.
Maybe I'll just wait for users to complain about the unclear parts,
then I know exactly what needs documenting.
Meanwhile, patches to sensors-detect.8 are obviously welcome.
> > I'm not sure how to add more information without making sensors-detect
> > painful to use in the main case.
>
> Links to the man page might be a good idea. ("See the MICROCHANNEL
> heading on the sensors-detect man page.")
I was more thinking about a general hint right when you start
sensors-detect: "See the manual page for extra information before you
give a non-default answer to any question." If we are going to add a
custom link before every question then we might as well include the
help in sensors-detect directly.
> Maybe URLs, if you are prepared to fight URL rot.
No, I do not want to refer to URLs. Administrators running
sensors-detect in a text-only environment won't enjoy it, and I don't
want to maintain a web page with extra documentation. This isn't always
the case, but in this specific case it is clear to me that we want the
documentation to be available on the user's system directly.
Can you please fetch sensors-detect again from SVN and give it a try? I
think I have addressed most of your points now, so it should work fine
on your system.
Thanks,
--
Jean Delvare
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply [flat|nested] 10+ messages in thread* Re: [lm-sensors] sensors-detect: testers wanted!
2008-12-03 17:22 [lm-sensors] sensors-detect: testers wanted! Jean Delvare
` (5 preceding siblings ...)
2008-12-05 11:00 ` Jean Delvare
@ 2008-12-05 23:44 ` Matt Roberds
2008-12-06 9:22 ` Jean Delvare
2008-12-11 8:50 ` Jean Delvare
8 siblings, 0 replies; 10+ messages in thread
From: Matt Roberds @ 2008-12-05 23:44 UTC (permalink / raw)
To: lm-sensors
On Fri, 5 Dec 2008, Jean Delvare wrote:
> [IPMI probe in its own section] This is done now.
The words look good to me. This is a lot better than suddenly having
the "IPMI Only" option appear in the ISA probing question IMHO.
> No, I do not want to refer to URLs. Administrators running
> sensors-detect in a text-only environment won't enjoy it, and I don't
> want to maintain a web page with extra documentation.
The second half is understandable, but the first half: I guess nobody
used the Web before GUIs were widely available. :) (I know: judging by
the numbers, this is almost true.) But I can understand it: if you have
some huge package like a database, or a big end-user-oriented GUI
program like Gimp or OpenOffice or something, it's OK for some of the
docs to be on the Web. If you are installing a relatively small
package, maybe on a headless server or one on which you haven't set up
the networking yet, having the documentation locally is preferable.
> Can you please fetch sensors-detect again from SVN and give it a try?
Done.
Short version: Nothing blew up, *and* the new version found everything
that the old (released with 3.0.3) version did. I didn't have to give
any non-default answers to the new version.
Long version: I unloaded the relevant kernel modules to simulate running
sensors-detect on a system that hasn't had lm_sensors set up before. I
didn't use any command-line arguments to sensors-detect, and I took all
the defaults by hitting "enter" at each prompt. I did this for both the
version from lm_sensors 3.0.3 (sensors-detect version 5337) and the
latest version (sensors-detect version 5530). This is on a system with
an Asus M2N-SLI Deluxe motherboard.
The results from version 5337 (shipped with 3.0.3):
---
Driver `to-be-written' (should be inserted):
Detects correctly:
* Bus `SMBus nForce2 adapter at 1c40'
Busdriver `i2c-nforce2', I2C address 0x2e
Chip `Analog Devices ADT7475' (confidence: 5)
Driver `it87' (should be inserted):
Detects correctly:
* ISA bus, address 0x290
Chip `ITE IT8716F Super IO Sensors' (confidence: 9)
Driver `k8temp' (should be inserted):
Detects correctly:
* Chip `AMD K8 thermal sensors' (confidence: 9)
Do you want to generate /etc/sysconfig/lm_sensors? (yes/NO):
To load everything that is needed, add this to one of the system
initialization scripts (e.g. /etc/rc.d/rc.local):
#----cut here----
# I2C adapter drivers
modprobe i2c-nforce2
# Chip drivers
# no driver for Analog Devices ADT7475 yet
modprobe it87
modprobe k8temp
/usr/local/bin/sensors -s
#----cut here----
---
The results from version 5530:
---
Driver `it87':
* ISA bus, address 0x290
Chip `ITE IT8716F Super IO Sensors' (confidence: 9)
Driver `to-be-written':
* Bus `SMBus nForce2 adapter at 1c40'
Busdriver `i2c-nforce2', I2C address 0x2e
Chip `Analog Devices ADT7475' (confidence: 5)
Driver `k8temp':
* Chip `AMD K8 thermal sensors' (confidence: 9)
Do you want to generate /etc/sysconfig/lm_sensors? (yes/NO):
To load everything that is needed, add this to one of the system
initialization scripts (e.g. /etc/rc.d/rc.local):
#----cut here----
# Chip drivers
modprobe it87
# no driver for Analog Devices ADT7475 yet
modprobe k8temp
/usr/local/bin/sensors -s
#----cut here----
---
The probe order with 5530 was:
southbridge/CPU/memory
super I/O
IPMI
ISA
SMBus
I got the new script via svn this time, so the $Revision$ was replaced
with the actual version number.
Matt Roberds
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply [flat|nested] 10+ messages in thread* Re: [lm-sensors] sensors-detect: testers wanted!
2008-12-03 17:22 [lm-sensors] sensors-detect: testers wanted! Jean Delvare
` (6 preceding siblings ...)
2008-12-05 23:44 ` Matt Roberds
@ 2008-12-06 9:22 ` Jean Delvare
2008-12-11 8:50 ` Jean Delvare
8 siblings, 0 replies; 10+ messages in thread
From: Jean Delvare @ 2008-12-06 9:22 UTC (permalink / raw)
To: lm-sensors
Hi Matt,
On Fri, 5 Dec 2008 17:44:15 -0600 (CST), Matt Roberds wrote:
> Short version: Nothing blew up, *and* the new version found everything
> that the old (released with 3.0.3) version did. I didn't have to give
> any non-default answers to the new version.
>
> Long version: I unloaded the relevant kernel modules to simulate running
> sensors-detect on a system that hasn't had lm_sensors set up before. I
> didn't use any command-line arguments to sensors-detect, and I took all
> the defaults by hitting "enter" at each prompt. I did this for both the
> version from lm_sensors 3.0.3 (sensors-detect version 5337) and the
> latest version (sensors-detect version 5530). This is on a system with
> an Asus M2N-SLI Deluxe motherboard.
>
> The results from version 5337 (shipped with 3.0.3):
>
> ---
> Driver `to-be-written' (should be inserted):
> Detects correctly:
> * Bus `SMBus nForce2 adapter at 1c40'
> Busdriver `i2c-nforce2', I2C address 0x2e
> Chip `Analog Devices ADT7475' (confidence: 5)
>
> Driver `it87' (should be inserted):
> Detects correctly:
> * ISA bus, address 0x290
> Chip `ITE IT8716F Super IO Sensors' (confidence: 9)
>
> Driver `k8temp' (should be inserted):
> Detects correctly:
> * Chip `AMD K8 thermal sensors' (confidence: 9)
>
> Do you want to generate /etc/sysconfig/lm_sensors? (yes/NO):
> To load everything that is needed, add this to one of the system
> initialization scripts (e.g. /etc/rc.d/rc.local):
>
> #----cut here----
> # I2C adapter drivers
> modprobe i2c-nforce2
> # Chip drivers
> # no driver for Analog Devices ADT7475 yet
> modprobe it87
> modprobe k8temp
> /usr/local/bin/sensors -s
> #----cut here----
> ---
>
> The results from version 5530:
>
> ---
> Driver `it87':
> * ISA bus, address 0x290
> Chip `ITE IT8716F Super IO Sensors' (confidence: 9)
>
> Driver `to-be-written':
> * Bus `SMBus nForce2 adapter at 1c40'
> Busdriver `i2c-nforce2', I2C address 0x2e
> Chip `Analog Devices ADT7475' (confidence: 5)
>
> Driver `k8temp':
> * Chip `AMD K8 thermal sensors' (confidence: 9)
>
> Do you want to generate /etc/sysconfig/lm_sensors? (yes/NO):
> To load everything that is needed, add this to one of the system
> initialization scripts (e.g. /etc/rc.d/rc.local):
>
> #----cut here----
> # Chip drivers
> modprobe it87
> # no driver for Analog Devices ADT7475 yet
> modprobe k8temp
> /usr/local/bin/sensors -s
> #----cut here----
> ---
>
> The probe order with 5530 was:
>
> southbridge/CPU/memory
> super I/O
> IPMI
> ISA
> SMBus
>
> I got the new script via svn this time, so the $Revision$ was replaced
> with the actual version number.
Looks good, thanks for reporting and thanks for your helpful
suggestions!
--
Jean Delvare
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply [flat|nested] 10+ messages in thread* Re: [lm-sensors] sensors-detect: testers wanted!
2008-12-03 17:22 [lm-sensors] sensors-detect: testers wanted! Jean Delvare
` (7 preceding siblings ...)
2008-12-06 9:22 ` Jean Delvare
@ 2008-12-11 8:50 ` Jean Delvare
8 siblings, 0 replies; 10+ messages in thread
From: Jean Delvare @ 2008-12-11 8:50 UTC (permalink / raw)
To: lm-sensors
Hi Ludovic,
On Wed, 10 Dec 2008 23:24:05 +0100, Ludovic Lebègue wrote:
> Hi Jean,
>
> Here is the result of my latest tests with f8000 on a 2.6.27 kernel.
>
> - Compilation OK :
> - insmod OK : kernel trace
> Dec 10 23:16:57 xxx kernel: [88516.594275] f8000: Found F8000 chip at 0xa00
> Dec 10 23:16:57 xxx kernel: [88516.595009] f8000 f8000.2560: Fan
> monitoring is enabled
> Dec 10 23:16:57 xxx kernel: [88516.595667] f8000 f8000.2560:
> Temperature and voltage monitoring is enabled
> - "sensors" output
> f8000-isa-0a00
> Adapter: ISA adapter
> in0: +3.36 V
> in1: +3.34 V
> in2: +3.28 V
> fan1: 1466 RPM
> fan2: 909 RPM
> fan3: 0 RPM
> fan4: 0 RPM
> temp1: +46.0°C (high = +60.0°C, crit = +70.0°C)
> temp2: +41.0°C (high = +85.0°C, crit = +100.0°C)
> temp3: +40.0°C (high = +85.0°C, crit = +100.0°C)
>
> It all seems OK to me.
Looks indeed alright to me. You can add the following
to /etc/sensors3.conf to get labels for the voltage inputs:
# Asus/Fintek F8000
chip "f8000-*"
# All 3 voltages are internal, so scaling is done by the driver and
# labels are always correct
label in0 "+3.3V"
label in1 "3VSB"
label in2 "Vbat"
I've just added this to the default configuration file.
Please note that, after discussion with Hans de Goede (Cc'd), we
decided that it was better to add support for the F8000 to an existing
driver (f71882fg) than writing a new driver as I did, because there
would be a lot of duplicated code otherwise. So Hans will probably ask
you to do more testing once he is done with the code.
Thanks,
--
Jean Delvare
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply [flat|nested] 10+ messages in thread