wt/lm-sensors
1
0 Fork 0
mirror of https://github.com/lm-sensors/lm-sensors.git synced 2026-10-31 13:10:30 +00:00
Code Issues Packages Projects Releases Wiki Activity

major rewrite to reflect current understanding and status

Browse Source 
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@1525 7894878c-1315-0410-8ee3-d5d059ff63e0
This commit is contained in:
Mark D. Studebaker committed 2002-09-14 15:57:27 +00:00
1 parent 320aee635c
commit 32476c8ba2
1 file changed
+91 -17
Download Patch File Download Diff File Expand all files Collapse all files
README.thinkpad
+91 -17
View File
@@ -1,25 +1,99 @@
**** WARNING: IBM Thinkpad users should not install I2C/Lm_sensors! ****
**** WARNING: IBM Thinkpad users should not install lm_sensors! ****
There have been some reports that the eeprom and/or firmware of IBM
Thinkpads have been corrupted after installing I2C/Lm_sensors. It's not
clear why and what specific action (most likely scanning/probing for chips)
causes the Thinkpad to corrupt it's eeprom. Unless you know otherwise, we
suggest that users avoid installing I2C/Lm_sensors support on IBM Thinkpads
until it becomes known what exactly is causing the corruption.
The eeprom of some IBM Thinkpads have been corrupted after installing
lm_sensors.
Though you may disagree about whose fault this is, fact is that seemingly
the Thinkpad can become corrupted even when only reading information from
the i2c/SMBus. Be assured that we never, ever write any information to
the bus while scanning(*), and that no halfway sane client implementation
should change its internal state, not to mention overwrite system-critical
information.
In our releases through 2.6.4, sensors-detect (our userspace detection script)
corrupts the Atmel 24RF08 eeprom. We have verified this in testing.
After the eeprom is corrupted, the checksum verification in the BIOS
will fail and the Thinkpad will not boot.
The 24RF08 is an 8K eeprom appearing at addresses 0x54 - 0x57 with
an additional "access protection page" at address 0x5c.
This is an unusual eeprom that contains a RFID (Radio Frequency ID)
port for wireless access, and elaborate access protection mechanisms.
The 24RF08 gets confused (presumably due to a state machine flaw) by
'quick write 0' (*) probes our package uses for detection.
This is in violation of the I2C specification. This corruption
mechanism has never been reported to us on any other eeprom,
Atmel or otherwise.
We have made several changes in release 2.6.5 to minimize the
chance of corruption:
1) Sensors-detect now accesses DMI information in the BIOS to identify
the system manufacturer. If the system manufacturer is IBM,
sensors-detect will print a message and exit.
2) The sequence of probes in sensors-detect has been changed so that
24RF08 eeproms are not corrupted. This *should* prevent corruption
of 24RF08 eeproms in any non-IBM systems in most cases.
3) The i2c-piix4 module (the bus driver that is used for Intel PIIX4-based
systems, including IBM Thinkpads) now accesses DMI information
in the BIOS to identify the system manufacturer. If the system
manufacturer is IBM, i2c-piix4 will print a message and exit.
As the 24RF08 is on the PIIX4 SMBus, this prevents access to
the 24RF08, even if sensors-detect is bypassed or sensors-detect
does not recognize the system as IBM.
4) The sequence of probes in the eeprom module (when loaded with
checksum=1) has been changed so that 24RF08 eeproms will
not be corrupted. This *should* prevent corruption of 24RF08
eeproms in non-IBM systems.
We do not have any reports of this corruption mechanism in releases
2.6.4 or earlier but have verified that it can happen.
There is no issue unless the eeprom
module is loaded with checksum=1, which is not the default.
Even with these changes, we still DO NOT RECOMMEND INSTALLING
lm_sensors 2.6.5 on IBM Thinkpads, because:
1) While these changes will dramatically reduce the chance of 24RF08
corruption, these changes have not been heavily tested.
2) lm_sensors won't run on IBM systems because of these changes.
3) IBM Thinkpads contain a proprietary Embedded Controller which
is used to access sensors. This controller is not on the SMBus,
and IBM will not release the programming interface to the
controller. So lm_sensors isn't useful on Thinkpads anyway.
As described above, our 2.6.5 release "blacklists" all IBM systems.
Our next step is to refine the system detection so that only
those models containing 24RF08's are blacklisted. We are working
with IBM on a method of querying the MTM (Machine Type and Model)
and comparing the MTM with a list of 24RF08-containing systems.
After this change (which will be documented in our CHANGES file
and this document), users of IBM systems without the
24RF08 and the proprietary Embedded Controller should be
able to safely use lm_sensors.
We do not have any reports of 24RF08 eeproms on non-IBM systems.
If there are any such systems with 24RF08 eeproms, these changes will
reduce the chances of corruption. However, there are
theoretical scenarios (involving multiple bus masters,
SMP systems, or simultaneous bus access) in which 24RF08's could
still be corrupted. If you know of any non-IBM systems which contain
these eeproms, please contact us.
Thanks to IBM, the Linux Thinkpad Mailing List, and Joe in Australia
for their assistance on this issue.
For more information, see:
http://www.linux-thinkpad.org/
The Linux Thinkpad Mailing List
http://www.bm-soft.com/~bm/tp_mailing.html
(*) Actually, we do write some information to the bus, but only as specified
in the i2c/SMBus protocol to select a certain chip address and to
start/stop i2c transactions.
Joe in Australia's Thinkpad Password Recovery Site
http://www.ja.olm.net/unlock
Atmel 24RF08 Datasheet
http://www.atmel.com/atmel/products/prod227.html
(*) 'Write Quick 0' is not an actual write and should never generate
a write operation to an eeprom location.