mirror of
https://github.com/lm-sensors/lm-sensors.git
synced 2026-10-23 11:54:33 +00:00
sensors-detect.8: editorial fixes
Submitted by Bjarni Ingi Gislason <bjarniig@simnet.is> via the Debian BTS, bug #1051123.
This commit is contained in:
1 parent
7d098e6af0
commit
ed0ff3d18c
1 file changed
+58
-39
@@ -1,19 +1,21 @@
|
||||
.TH SENSORS-DETECT 8 "September 2013" "lm-sensors 3"
|
||||
.SH NAME
|
||||
sensors-detect \- detect hardware monitoring chips
|
||||
|
||||
.
|
||||
.SH SYNOPSIS
|
||||
.B sensors-detect [
|
||||
.I --auto
|
||||
.B ]
|
||||
|
||||
.BR sensors-detect " ["
|
||||
.BR \-\-auto " ]"
|
||||
.
|
||||
.SH DESCRIPTION
|
||||
sensors-detect is an interactive program that will walk you through the
|
||||
.B sensors-detect
|
||||
is an interactive program that will walk you through the
|
||||
process of scanning your system for various hardware monitoring chips,
|
||||
or sensors, supported by libsensors(3), or more generally by the lm_sensors
|
||||
tool suite.
|
||||
or sensors, supported by
|
||||
.BR libsensors (3),
|
||||
or more generally by the lm_sensors tool suite.
|
||||
|
||||
sensors-detect will look for the following devices, in order:
|
||||
.B sensors-detect
|
||||
will look for the following devices, in order:
|
||||
.IP \(bu
|
||||
Sensors embedded in CPUs, south bridges and memory controllers.
|
||||
.IP \(bu
|
||||
@@ -24,40 +26,57 @@ Hardware monitoring chips accessed through ISA I/O ports.
|
||||
Hardware monitoring chips reachable over the SMBus or more generally
|
||||
any I2C bus on your system.
|
||||
.PP
|
||||
As the last two detection steps can cause trouble on some systems, they
|
||||
are normally not attempted if the second detection step led to the
|
||||
discovery of a Super I/O chip with complete hardware monitoring features.
|
||||
However, the user is always free to ask for all detection steps if so is
|
||||
his/her wish. This can be useful if a given system has more than one
|
||||
hardware monitoring chip. Some vendors are known to do this, most notably
|
||||
Asus and Tyan.
|
||||
|
||||
As the last two detection steps can cause trouble on some systems,
|
||||
they are normally not attempted
|
||||
if the second detection step led to the discovery of a Super I/O chip
|
||||
with complete hardware monitoring features.
|
||||
However,
|
||||
the user is always free to ask for all detection steps
|
||||
if so is his/her wish.
|
||||
This can be useful
|
||||
if a given system has more than one hardware monitoring chip.
|
||||
Some vendors are known to do this,
|
||||
most notably Asus and Tyan.
|
||||
.
|
||||
.SH OPTIONS
|
||||
.IP "--auto"
|
||||
Run in automatic, non-interactive mode. Assume default answers to all
|
||||
questions. Note that this isn't necessarily safe as the internal logic may
|
||||
lead to potentially dangerous probes being attempted. See the WARNING section
|
||||
below.
|
||||
.IP "--stat"
|
||||
.IP \-\-auto
|
||||
Run in automatic, non-interactive mode.
|
||||
Assume default answers to all questions.
|
||||
Note that this isn't necessarily safe
|
||||
as the internal logic may lead to potentially dangerous probes being attempted.
|
||||
See the WARNING section below.
|
||||
.IP \-\-stat
|
||||
Display I2C address statistics.
|
||||
|
||||
.
|
||||
.SH WARNING
|
||||
sensors-detect needs to access the hardware for most of the chip detections.
|
||||
By definition, it doesn't know which chips are there before it manages to
|
||||
identify them. This means that it can access chips in a way these chips do
|
||||
not like, causing problems ranging from SMBus lockup to permanent hardware
|
||||
damage (a rare case, thankfully.)
|
||||
|
||||
The authors made their best to make the detection as safe as possible, and
|
||||
it turns out to work just fine in most cases, however it is impossible to
|
||||
guarantee that sensors-detect will not lock or kill a specific system. So,
|
||||
as a rule of thumb, you should not run sensors-detect on production servers,
|
||||
and you should not run sensors-detect if can't afford replacing a random
|
||||
part of your system. Also, it is recommended to not force a detection step
|
||||
which would have been skipped by default, unless you know what you are doing.
|
||||
.B sensors-detect
|
||||
needs to access the hardware for most of the chip detections.
|
||||
By definition,
|
||||
it doesn't know which chips are there
|
||||
before it manages to identify them.
|
||||
This means that it can access chips in a way these chips do not like,
|
||||
causing problems ranging from SMBus lockup to permanent hardware damage
|
||||
(a rare case, thankfully.)
|
||||
|
||||
The authors made their best to make the detection as safe as possible,
|
||||
and it turns out to work just fine in most cases,
|
||||
however it is impossible to guarantee that
|
||||
.B sensors-detect
|
||||
will not lock or kill a specific system.
|
||||
So, as a rule of thumb,
|
||||
you should not run
|
||||
.B sensors-detect
|
||||
on production servers,
|
||||
and you should not run
|
||||
.B sensors-detect
|
||||
if you can't afford replacing a random part of your system.
|
||||
Also, it is recommended to not force a detection step
|
||||
which would have been skipped by default,
|
||||
unless you know what you are doing.
|
||||
.
|
||||
.SH SEE ALSO
|
||||
sensors(1), libsensors(3)
|
||||
|
||||
.BR sensors (1),
|
||||
.BR libsensors (3)
|
||||
.
|
||||
.SH AUTHOR
|
||||
Frodo Looijaard and Jean Delvare
|
||||
Reference in new issue
Block a user