sensors-detect: Check for 1-register-only
PATCH 1/1 sensors-detect: Check for 1-register-only
Hi all,
A few days ago, Achim Gottinger reported severe hardware problems when running sensors-detect on his Sapphire AM2RD790 motherboard [1]. The system was freezing, and one CPU even died (even though I still have some doubt about the direct responsibility of sensors-detect in this tragedy.) Investigations taught us that the problematic chip is a memory voltage controller which lives at address 0x2e (unfortunately a popular address for hardware monitoring chips.) This device uses SMBus receive byte and SMBus send byte transactions, i.e. short reads and writes. When sensors-detect uses SMBus read byte transactions to attempt to identify I2C/SMBus chips, the device in question sees a write followed by a read. So in practice, sensors-detect is writing random values to the voltage controller, resulting in hardware trouble. Not good.
This is a fundamental weakness of I2C and SMBus that this kind of problem can happen, and there's not that much we can do about it, short of stopping SMBus probing altogether. But still, it would be great if we could prevent the users from accidentally freezing their system or frying their hardware by just running sensors-detect. I've already made a proposal in that direction some days ago [2], and I am back with a new one.
[1] http://lists.lm-sensors.org/pipermail/lm-sensors/2008-May/023020.html
[2] http://lists.lm-sensors.org/pipermail/lm-sensors/2008-May/023056.html
This time, my idea is to let sensors-detect attempt to figure out when it is about to probe an I2C address where such a 1-register-only device lives, and skip that probe. It's not easy, but I have come up with a heuristic which I think should work in most cases, and should be reasonably safe.
The idea is to start with two SMBus receive byte transactions. This should give us the value of the single register - if what we have is a 1-register-only device. Then we'd send the same byte, and read again. In theory this should still return the same value. Then we write the same value with LSB inverted. Reading again should return the same value with LSB inverted. If all the tests pass, we write one last time the original register value, and leave the device alone. If at some point a test fails, then it means that the device is probably not a 1-register-only device and must instead be a regular device which understand SMBus read byte, so sensors-detect can keep probing it.
The trick is that the above can be implemented using only SMBus "read" transactions (receive byte and read byte.) We were already doing random SMBus read byte transactions so there is no change there. My hope is that adding SMBus receive byte transactions at the beginning should do no harm. But of course only testing will tell.
Here's the patch I have come up with:
--- prog/detect/sensors-detect | 40 ++++++++++++++++++++++++++++++++++++++++ 1 file changed, 40 insertions(+)
prog/detect/sensors-detect +40 -0
@@ -2743,6 +2743,42 @@ sub i2c_probe($$$) } } +# $_[0]: Reference to an opened file handle +# Returns: 1 if the device is safe to access, 0 else. +# This function is meant to prevent access to 1-register-only devices, +# which are designed to be access with SMBus receive byte and SMBus send +# byte transactions (i.e. short reads and short writes) and treat SMBus +# read byte as a real write followed by a read. The device detection +# routines would write random values to the chip with possibly very nasty +# results for the hardware. Note that this function won't catch all such +# chips, as it assumes that reads and writes relate to the same register, +# but that's the best we can do. +sub i2c_safety_check +{ + my ($file) = @_; + my $data; + + # First we receive a byte from the chip, and remember it. + $data = i2c_smbus_read_byte($file); + + # We receive a byte again; very likely to be the same for + # 1-register-only devices. + return 1 if (i2c_smbus_read_byte($file) != $data); + + # Then we try a standard byte read, with a register offset equal to + # the byte we received; we should receive the same byte value in return. + return 1 if (i2c_smbus_read_byte_data($file, $data) != $data); + + # Then we try a standard byte read, with a slightly different register + # offset; we should again receive the same byte value in return. + return 1 if (i2c_smbus_read_byte_data($file, $data ^ 1) != ($data ^ 1)); + + # Apprently this is a 1-register-only device, restore the original register + # value and leave it alone. + i2c_smbus_read_byte_data($file, $data); + return 0; +} + #################### # ADAPTER SCANNING # ####################
@@ -3087,6 +3123,10 @@ sub scan_adapter next unless i2c_probe(\*FILE, $addr, $funcs); printf "Client found at address 0x%02x\n",$addr; + if (!i2c_safety_check(\*FILE)) { + print "Seems to be a 1-register-only device, skipping.\n"; + next; + } $| = 1; foreach $chip (@chip_ids) {
I've tested it on ADM1032, LM75, LM78 and LM87 chips, as well as EEPROMs, and it didn't cause any problem (i.e. they are all properly identified as they were before.) I would appreciate more testers, both on regular chips (to make sure there is no regression), and on 1-register-only devices (to see if they are detected or not) for those of you who have access to such chips. The PCF8574 GPIO chip is one of these. Keep in mind before doing the test though, that the LSB of the device will be briefly switched, so make sure that it won't cause unwanted effects.
If anyone is worried about this LSB switching, please realize that it's still a lot safer than what we were doing so far, where _all_ bits of the register could be switched, and additionally they wouldn't be restored afterwards.
Disclaimer: as with any experimental I2C code, it is very hard to predict the results on all devices, so if you don't feel like taking any risk, don't do the test.
I've made a patched version of sensors-detect directly available at:
http://jdelvare.pck.nerim.net/sensors/sensors-detect
to make testing easier.
I am very interested in opinions about this heuristic, and in test results. Ideally I'd like to have this committed quickly so that it makes it in lm-sensors 3.0.2. But I can only do that if I get enough positive test results in the next few days.
Thanks,
Signature · 6 lines
Jean Delvare _______________________________________________ lm-sensors mailing list [email protected] http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
Quoted 2 lines · Jean Delvare
Hi all,
<intro snipped>
Quoted 18 lines
This time, my idea is to let sensors-detect attempt to figure out when it is about to probe an I2C address where such a 1-register-only device lives, and skip that probe. It's not easy, but I have come up with a heuristic which I think should work in most cases, and should be reasonably safe.
The idea is to start with two SMBus receive byte transactions. This should give us the value of the single register - if what we have is a 1-register-only device. Then we'd send the same byte, and read again. In theory this should still return the same value. Then we write the same value with LSB inverted. Reading again should return the same value with LSB inverted. If all the tests pass, we write one last time the original register value, and leave the device alone. If at some point a test fails, then it means that the device is probably not a 1-register-only device and must instead be a regular device which understand SMBus read byte, so sensors-detect can keep probing it.
Quoted 6 lines
The trick is that the above can be implemented using only SMBus "read" transactions (receive byte and read byte.) We were already doing random SMBus read byte transactions so there is no change there. My hope is that adding SMBus receive byte transactions at the beginning should do no harm. But of course only testing will tell.
Perhaps it would be an idea to try to do an i2c (*) read transfer of more then 1 byte, it would be interesting to see how this specific 1 register device responds to this, maybe it will stop acking after the first byte is transfered because it has only one byte to send.
OTOH I have no idea how regular smbus devices which normally do write reg address, then read transactions respond to larger then 1 byte reads.
* Calling it i2c here to make clear I mean an low level read, not an smbus read transaction where first the register to read gets written.
---
About the potential for doing an i2c read of 1 byte from a device which expects a write reg address to read, then read 1 byte style transactions, causing problems, I don't think this will cause issues, normally these kind of devices are implemented using a read ptr, which tells the device where to start reading in its internal memory map when an i2c read transaction is done. With the write addr, then read cycle, the write sets that read ptr, so reading without the write would give one the contents of a random register address and should not be a problem otherwise.
Some devices may have additional checks build in though, and only accept a read if there was a write before it within the same transaction (so in i2c terms:
{ start, write register address, repeated-start, read register contents, stop }
I've seen devices which wouldn't work if the repeated-start above was a { stop, start } (dallas ds1621 temp sensor) Note: 1 this is not an smbus device, 2 I don't remember how it failed.
But given that some smbus devices may be like the ds1621 and demand an address write before a read in one transaction (so seperated by a repeated start), it could be that the initial read in this proposed patch fails in that case with an error because the sensor at 0x2e refuses the read and thus does not ack when it gets addressed for the read transfer.
Regards,
Hans
_______________________________________________
lm-sensors mailing list
[email protected]
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
Hans de Goede wrote:
<snip>
Quoted 18 lines
About the potential for doing an i2c read of 1 byte from a device which expects a write reg address to read, then read 1 byte style transactions, causing problems, I don't think this will cause issues, normally these kind of devices are implemented using a read ptr, which tells the device where to start reading in its internal memory map when an i2c read transaction is done. With the write addr, then read cycle, the write sets that read ptr, so reading without the write would give one the contents of a random register address and should not be a problem otherwise.
Some devices may have additional checks build in though, and only accept a read if there was a write before it within the same transaction (so in i2c terms:
{ start, write register address, repeated-start, read register contents, stop }I've seen devices which wouldn't work if the repeated-start above was a { stop, start } (dallas ds1621 temp sensor) Note: 1 this is not an smbus device, 2 I don't remember how it failed.
Quoted 6 lines
But given that some smbus devices may be like the ds1621 and demand an address write before a read in one transaction (so seperated by a repeated start), it could be that the initial read in this proposed patch fails in that case with an error because the sensor at
0x2erefuses the read and thus does not ack when it gets addressed for the read transfer.
And the point I was trying to make here but didn't is that I thus believe that the first 1 byte read in the new detection code should have error handling added, because it might fail (due to no ack) in which case we clearly do not have a 1 reg device.
Regards,
Hans
_______________________________________________
lm-sensors mailing list
[email protected]
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
Quoted 7 lines · Jean Delvare
Hi all,
I am very interested in opinions about this heuristic, and in test results. Ideally I'd like to have this committed quickly so that it makes it in lm-sensors 3.0.2. But I can only do that if I get enough positive test results in the next few days.
I've tested the patch on a machine with a Siemens fscher hwmon ic and on an Asus motherboard with in adt 7475, both are still detected correctly with this patch.
Regards,
Hans
_______________________________________________
lm-sensors mailing list
[email protected]
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
Hi Hans,
Quoted 4 lines · Hans de Goede
Perhaps it would be an idea to try to do an i2c (*) read transfer of more then 1 byte, it would be interesting to see how this specific 1 register device responds to this, maybe it will stop acking after the first byte is transfered because it has only one byte to send.
In master-receiver, slave-transmitter mode, it's the master who sets the ack bit, depending on whether it will ask for more bytes after that one (ack) or not (nack). The slave doesn't have its say. All the slave can do is send zero or maybe random bytes if it doesn't have data to send. Slaves which know how to stretch the SCL pulses could hold SCL low as a reprisal, too, temporarily or permanently, but that's about it.
Quoted 2 lines
OTOH I have no idea how regular smbus devices which normally do write reg address, then read transactions respond to larger then 1 byte reads.
I don't know either, but I fear that the answer is: it depends. And the answer is probably the same for 1-register-only devices. Note for example, that any SMBus device supporting PEC would be perfectly happy to send a second byte, which would be the PEC byte. So, I don't think that the method you proposed can be used to differentiate between the two families of devices.
Quoted 2 lines
* Calling it i2c here to make clear I mean an low level read, not an smbus read transaction where first the register to read gets written.
Thanks,
Signature · 6 lines
Jean Delvare _______________________________________________ lm-sensors mailing list [email protected] http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
Quoted 8 lines · Jean Delvare
Hi Hans,
Quoted 4 lines · Hans de Goede
Perhaps it would be an idea to try to do an i2c (*) read transfer of more then 1 byte, it would be interesting to see how this specific 1 register device responds to this, maybe it will stop acking after the first byte is transfered because it has only one byte to send.
Quoted 5 lines
In master-receiver, slave-transmitter mode, it's the master who sets the ack bit, depending on whether it will ask for more bytes after that one (ack) or not (nack). The slave doesn't have its say. All the slave can do is send zero or maybe random bytes if it doesn't have data to send.
You're right, I didn't think about that.
Regards,
Hans
_______________________________________________
lm-sensors mailing list
[email protected]
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
Hi Jean,
I tried the patch here. The 1-register chips got detected. There still seem to be other chips causing the smbus master to stop working after the sensors-detect run. I tried to exclude the chips I could not i2cdump correct (0x47 (some oncpu device) ,0x6e (pcie) and 0x70(sensors chip?) ) and also added 0x52, 0x53 amd 0x57 but still no luck. After the sensors-detect i can not i2dump chips till a new cold start.
The detection program hangs for a few (2-3) seconds at the LM75 probing line on chip at 0x4e (cpu's thermal interface).
A sidenote about my dead chip. When phenoms came out end last year, a few of the early steppings stopped working after a short time if the cpu's northbridge ran at low voltage (~1.2V) and the memory ran at relative high voltage (>2.2V). So the onchip IMC seems to be affected by high memory voltages.
Also the mayority of phenoms dying during overclocking die while running low io accessing applications like everest, sandra or speedfan. Not many really die from too high voltages or temperatures. Unfortunately all those applications are closed source, but i expect they use similar probing methods or smbus/i2c devices whom might cause voltage or frequency peaks which harm the cpu's more than the higher frequencies and voltages we apply during overclocking.
BTW: I still got no response from Sapphire support about the device at 0x2e, maybe i should tell em. :)
debian-9850:/home/achim/sensors-patch# i2cdetect 0
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- 2e -- 30: -- -- -- -- -- -- -- -- 38 -- -- -- -- -- -- -- 40: -- -- -- -- -- -- -- 47 -- -- -- -- 4c -- 4e -- 50: -- -- 52 53 -- -- -- 57 -- -- -- -- -- -- -- -- 60: -- -- -- -- -- -- -- -- -- 69 -- -- -- -- 6e -- 70: 70 -- -- -- -- -- -- --
debian-9850:/home/achim/sensors-patch# sensors-detect
# sensors-detect revision 5108 (2008-01-22 13:22:47 +0100)
This program will help you determine which kernel modules you need to load to use lm_sensors most effectively. It is generally safe and recommended to accept the default answers to all questions, unless you know what you're doing.
We can start with probing for (PCI) I2C or SMBus adapters. Do you want to probe now? (YES/no):
Probing for PCI bus adapters...
Use driver `i2c-piix4' for device 0000:00:14.0: ATI Technologies Inc SB600 SMBus
We will now try to load each adapter module in turn. Module `i2c-piix4' already loaded.
If you have undetectable or unsupported adapters, you can have them scanned by manually loading the modules before running this script.
We are now going to do the I2C/SMBus adapter probings. Some chips may be double detected; we choose the one with the highest confidence value in that case.
If you found that the adapter hung after probing a certain address, you can specify that address to remain unprobed.
Next adapter: SMBus PIIX4 adapter at 0b00 (i2c-0)
Do you want to scan it? (YES/no/selectively): selectively Please enter one or more addresses not to scan. Separate them with comma's.
You can specify a range by using dashes. Addresses may be decimal (like
54)
or hexadecimal (like 0x33).
Addresses: 0x47,0x57,0x6e,0x70,0x52,0x53
Client found at address 0x2e
Seems to be a 1-register-only device, skipping.
Client found at address 0x4c
Probing for `National Semiconductor LM75'... No Probing for `Dallas Semiconductor DS75'... No Probing for `Analog Devices ADT7466'... No Probing for `Andigilog aSC7511'... No Probing for `Dallas Semiconductor DS1621'... No Probing for `Analog Devices ADM1021'... No Probing for `Analog Devices ADM1021A/ADM1023'... No Probing for `Maxim MAX1617'... No Probing for `Maxim MAX1617A'... No Probing for `Maxim MAX1668'... No Probing for `Maxim MAX1805'... No Probing for `Maxim MAX1989'... No Probing for `Maxim MAX6655/MAX6656'... No Probing for `TI THMC10'... No Probing for `National Semiconductor LM84'... No Probing for `Genesys Logic GL523SM'... No Probing for `Onsemi MC1066'... No Probing for `Maxim MAX1619'... No Probing for `National Semiconductor LM82/LM83'... No Probing for `National Semiconductor LM90'... No Probing for `National Semiconductor LM89/LM99'... No Probing for `National Semiconductor LM86'... No Probing for `Analog Devices ADM1032'... No Probing for `Maxim MAX6657/MAX6658/MAX6659'... No Probing for `Maxim MAX6648/MAX6692'... No Probing for `Maxim MAX6680/MAX6681'... No Probing for `Winbond W83L771W/G'... No Probing for `Texas Instruments TMP401'... No Probing for `National Semiconductor LM63'... No Probing for `Fintek F75363SG'... No Probing for `Maxim MAX6633/MAX6634/MAX6635'... No Probing for `Analog Devices ADT7461'... No Probing for `Fintek F75383S/M'... No
Some chips are also 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):
Probing for `National Semiconductor LM78' at 0x290... No Probing for `National Semiconductor LM78-J' 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 `Silicon Integrated Systems SIS5595'... No Probing for `VIA VT82C686 Integrated Sensors'... No Probing for `VIA VT8231 Integrated Sensors'... No Probing for `IPMI BMC KCS' at 0xca0... No Probing for `IPMI BMC SMIC' at 0xca8... No
Some Super I/O chips may also contain sensors. We have to write to standard I/O ports to probe them. This is usually safe. Do you want to scan for Super I/O sensors? (YES/no):
Probing for Super-I/O at 0x2e/0x2f
Trying family `National Semiconductor'... No
Trying family `SMSC'... No
Trying family `VIA/Winbond/Fintek'... No
Trying family `ITE'... Yes
Found `ITE IT8716F Super IO Sensors' Success!
(address 0x228, driver `it87')
Probing for Super-I/O at 0x4e/0x4f
Trying family `National Semiconductor'... No
Trying family `SMSC'... No
Trying family `VIA/Winbond/Fintek'... No
Trying family `ITE'... NoSome CPUs or memory controllers may also contain embedded sensors. Do you want to scan for them? (YES/no):
AMD K8 thermal sensors... No
AMD K10 thermal sensors... Success!
(driver `to-be-written')
Intel Core family thermal sensor... No
Intel AMB FB-DIMM thermal sensor... No
Now follows a summary of the probes I have just done. Just press ENTER to continue:
Driver `it87' (should be inserted):
Detects correctly:
* ISA bus, address 0x228
Chip `ITE IT8716F Super IO Sensors' (confidence: 9)
Driver `to-be-written' (should be inserted):
Detects correctly:
* Chip `AMD K10 thermal sensors' (confidence: 9)
I will now generate the commands needed to load the required modules. Just press ENTER to continue:
To load everything that is needed, add this to /etc/modules:
#----cut here----
# Chip drivers
it87
# no driver for AMD K10 thermal sensors yet #----cut here----
Do you want to add these lines automatically? (yes/NO)
debian-9850:/home/achim/sensors-patch# i2cdump 0 0x38
No size specified (using byte-data access)
WARNING! This program can confuse your I2C bus, cause data loss and
worse!
I will probe file /dev/i2c-0, address 0x38, mode byte
Continue? [Y/n]
0 1 2 3 4 5 6 7 8 9 a b c d e f 0123456789abcdef
00: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
10: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
20: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
30: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
40: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
50: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
60: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
70: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
80: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
90: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
a0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
b0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
c0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
d0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
e0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
f0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX_______________________________________________
lm-sensors mailing list
[email protected]
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
Hi Achim,
Quoted 1 line · achim
I tried the patch here. The 1-register chips got detected.
Great! Thanks for testing :)
Quoted 6 lines
There still seem to be other chips causing the smbus master to stop working after the sensors-detect run. I tried to exclude the chips I could not i2cdump correct (
0x47(some oncpu device) ,0x6e (pcie) and 0x70(sensors chip?) ) and also added0x52,0x53amd0x57but still no luck. After the sensors-detect i can not i2dump chips till a new cold start.
For 0x47 you can apply this patch which is already in SVN:
http://www.lm-sensors.org/changeset/5235
Quoted 2 lines
The detection program hangs for a few (2-3) seconds at the LM75 probing line on chip at
0x4e(cpu's thermal interface).
The LM75 detection is complex because the LM75 has no identification register so we have to use a costly heuristic to identify it reliably. So I am not surprised that it takes some time and it appears to hang for a few seconds.
I don't know what device on the SMBus is causing the problem. Can you please try excluding _all_ the addresses which i2cdetect shows as used?
Note that i2cdump, by default, uses byte transactions, while some detections in sensors-detect make use of word transactions. It could be that one of your chips is happy with byte transactions but chokes on word transactions and then keeps the bus in a busy state. You could use the "w" mode of i2cdump to test this theory.
Thanks,
Signature · 6 lines
Jean Delvare _______________________________________________ lm-sensors mailing list [email protected] http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
Hi Achim,
Quoted 9 lines · achim
For sake of completenes here's the result of the dump test. (...)
0x38: passed b and w dump0x47: b,w and s result in no reply and if i cancle it i get XX's for dumps afterwards
(...)0x6e: only likes s dumps others stop at address0x91and result in XX's. The datasheet for that chip is available so it might be possible to at least detect this chip.
We don't much care about 0x6e at the moment, there is no known hardware monitoring chip living at this address so it is never probed. Same for 0x38 and, since a few days, 0x47.
(Thanks for the info, though.)
Signature · 6 lines
Jean Delvare _______________________________________________ lm-sensors mailing list [email protected] http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
Quoted 10 lines · achim
Am Freitag, den 09.05.2008, 17:24 +0200 schrieb Jean Delvare:
Quoted 9 lines
Hi Achim,
I see this, and I think I understand why. The address exclusion logic assumes that the original list contains _all_ addresses. This is no longer the case. When I restricted sensors-detect to only probe addresses where are least one hardware monitoring chip is known, I forgot about this optimization which turned into a bug. Thanks for reporting. This patch should fix it:
Quoted 6 lines
Quoted 3 lines
Can you please test it?
Thanks,
Yeah, the patch works. I tested sensors-detect with all known adresses of the board excluded and it did not messup the smbus chip.
OK, good. I'll commit this patch later today then.
Quoted 3 lines
Afterward i tried it with only
0x4cexcluded and the smbus chip still works. With no exclusions lm75 detection hangs at0x4cand afterwards i only get XX's from dumps.
By "hangs" you mean it takes several seconds, or does it really stop? Are you certain that it's the LM75 detection causing problem? We check for no less than 33 different devices at address 0x4c...
Anyway, most certainly the problem is with word transactions on this device you have at 0x4c. That won't be easy to work around, but I'll take a look anyway, maybe I'll have an idea. If I do, I'll ask you - again - to help with testing. Thanks *a lot* for all the help you are providing in this respect.
Signature · 6 lines
Jean Delvare _______________________________________________ lm-sensors mailing list [email protected] http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
Am Freitag, den 09.05.2008, 19:05 +0200 schrieb Jean Delvare:
Quoted 9 lines
Quoted 4 lines
Afterward i tried it with only
0x4cexcluded and the smbus chip still works. With no exclusions lm75 detection hangs at0x4cand afterwards i only get XX's from dumps.By "hangs" you mean it takes several seconds, or does it really stop? Are you certain that it's the LM75 detection causing problem? We check for no less than 33 different devices at address
0x4c...
-------------------------------------------------
Client found at address 0x4c
Probing for `National Semiconductor LM75'...
-------------------------------------------------
This is where it stops for a few seconds.
i2cdump 0 0x4c w hangs in a way that i must cancle it with Ctrl-C and afterwards i need a reboot to get correct dumps.
Quoted 4 lines
Anyway, most certainly the problem is with word transactions on this device you have at
0x4c. That won't be easy to work around, but I'll take a look anyway, maybe I'll have an idea. If I do, I'll ask you - again - to help with testing.
As i noted in an other mail the interface can be accessed via the pci registers F3x1E80 (address) and F3x1EC0 (data).
Bit 3 of pci register F3x1E40 indicates that this way of access is possible if unset (0b). But those addresses can not be accessed via /proc/bus/pci atm.
Quoted 3 lines
Thanks *a lot* for all the help you are
providing in this respect.
Glad I can help. I was curious for a long time how this i2c/smbus stuff works in detail, so that is a good situation to find out more about.
_______________________________________________
lm-sensors mailing list
[email protected]
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
Hi Hans,
Quoted 9 lines · Hans de Goede
Quoted 8 lines · Hans de Goede
About the potential for doing an i2c read of 1 byte from a device which expects a write reg address to read, then read 1 byte style transactions, causing problems, I don't think this will cause issues, normally these kind of devices are implemented using a read ptr, which tells the device where to start reading in its internal memory map when an i2c read transaction is done. With the write addr, then read cycle, the write sets that read ptr, so reading without the write would give one the contents of a random register address and should not be a problem otherwise.
This is what I hope and expect, yes.
Quoted 7 lines
Quoted 7 lines
Some devices may have additional checks build in though, and only accept a read if there was a write before it within the same transaction (so in i2c terms:
{ start, write register address, repeated-start, read register contents, stop }I've seen devices which wouldn't work if the repeated-start above was a { stop, start } (dallas ds1621 temp sensor) Note: 1 this is not an smbus device, 2 I don't remember how it failed.
I happen to have a DS1621 at hand so I did the test. SMBus receive byte returns value 0x09 all the time, but it doesn't hang the device nor the bus. I have no idea what this value is supposed to mean, it doesn't correspond to any register value as far as I can see.
I have also tested my modified sensors-detect script on it and it is still detected successfully. Good news.
I agree that it is possible that some devices don't like being read from before being written to. I simply hope that they will just ignore the request and won't hang themselves nor the bus. The only way to know if I am right, is by testing on more systems.
Quoted 10 lines
Quoted 5 lines
But given that some smbus devices may be like the ds1621 and demand an address write before a read in one transaction (so seperated by a repeated start), it could be that the initial read in this proposed patch fails in that case with an error because the sensor at
0x2erefuses the read and thus does not ack when it gets addressed for the read transfer.And the point I was trying to make here but didn't is that I thus believe that the first 1 byte read in the new detection code should have error handling added, because it might fail (due to no ack) in which case we clearly do not have a 1 reg device.
It could still be a 1-register-only device, but write-only. But your point is valid anyway, my heuristic won't work for such chips, so I'd rather handle the error cleanly.
I've just uploaded an updated script at:
http://jdelvare.pck.nerim.net/sensors/sensors-detect
Thank you,
Signature · 6 lines
Jean Delvare _______________________________________________ lm-sensors mailing list [email protected] http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
Hi all
On Fri, May 9, 2008 at 12:00 PM, <[email protected]> wrote:
I successfully tested this new sensor-detect, here is the result :
# sensors-detect revision 5243 (2008-05-09 19:59:51 +0200)
This program will help you determine which kernel modules you need to load to use lm_sensors most effectively. It is generally safe and recommended to accept the default answers to all questions, unless you know what you're doing.
We can start with probing for (PCI) I2C or SMBus adapters. Do you want to probe now? (YES/no):
Probing for PCI bus adapters...
Use driver `i2c-i801' for device 0000:00:1f.3: Intel ICH9
We will now try to load each adapter module in turn.
Load `i2c-i801' (say NO if built into your kernel)? (YES/no):
Module loaded successfully.
If you have undetectable or unsupported I2C/SMBus adapters, you can have them scanned by manually loading the modules before running this script.
To continue, we need module i2c-dev' to be loaded. Do you want to load i2c-dev' now? (YES/no):
Module loaded successfully.
We are now going to do the I2C/SMBus adapter probings. Some chips may be double detected; we choose the one with the highest confidence value in that case.
If you found that the adapter hung after probing a certain address, you can specify that address to remain unprobed.
Next adapter: NVIDIA i2c adapter (i2c-0)
Do you want to scan it? (YES/no/selectively):
Client found at address 0x50
Probing for `Analog Devices ADM1033'... No Probing for `Analog Devices ADM1034'... No Probing for `SPD EEPROM'... No Probing for `EDID EEPROM'... Yes
(confidence 8, not a hardware monitoring chip)
Next adapter: NVIDIA i2c adapter (i2c-1)
Do you want to scan it? (YES/no/selectively):
Next adapter: NVIDIA i2c adapter (i2c-2)
Do you want to scan it? (YES/no/selectively):
Next adapter: SMBus I801 adapter at 0400 (i2c-3)
Do you want to scan it? (YES/no/selectively):
Client found at address 0x50
Probing for `Analog Devices ADM1033'... No
Probing for `Analog Devices ADM1034'... No
Probing for `SPD EEPROM'... Yes
(confidence 8, not a hardware monitoring chip)
Probing for `EDID EEPROM'... No
Client found at address 0x51
Probing for `Analog Devices ADM1033'... No
Probing for `Analog Devices ADM1034'... No
Probing for `SPD EEPROM'... Yes
(confidence 8, not a hardware monitoring chip)
Probing for `EDID EEPROM'... No
Client found at address 0x52
Probing for `Analog Devices ADM1033'... No
Probing for `Analog Devices ADM1034'... No
Probing for `SPD EEPROM'... Yes
(confidence 8, not a hardware monitoring chip)
Probing for `EDID EEPROM'... No
Client found at address 0x53
Probing for `Analog Devices ADM1033'... No
Probing for `Analog Devices ADM1034'... No
Probing for `SPD EEPROM'... Yes (confidence 8, not a hardware monitoring chip)
Probing for `EDID EEPROM'... No
Some chips are also 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):
Probing for `National Semiconductor LM78' at 0x290... No Probing for `National Semiconductor LM78-J' 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
Some Super I/O chips may also contain sensors. We have to write to standard I/O ports to probe them. This is usually safe. Do you want to scan for Super I/O sensors? (YES/no):
Probing for Super-I/O at 0x2e/0x2f
Trying family `National Semiconductor'... No
Trying family `SMSC'... No
Trying family `VIA/Winbond/Fintek'... Yes
Found `Asus F8000 Super IO' Success!
(address 0xa00, driver `f8000')
Probing for Super-I/O at 0x4e/0x4f
Trying family `National Semiconductor'... No
Trying family `SMSC'... No
Trying family `VIA/Winbond/Fintek'... No
Trying family `ITE'... NoSome south bridges, CPUs or memory controllers may also contain embedded sensors. Do you want to scan for them? (YES/no):
Silicon Integrated Systems SIS5595... No VIA VT82C686 Integrated Sensors... No VIA VT8231 Integrated Sensors... No AMD K8 thermal sensors... No AMD K10 thermal sensors... No Intel Core family thermal sensor... Success!
(driver `coretemp')
Intel AMB FB-DIMM thermal sensor... No
Now follows a summary of the probes I have just done. Just press ENTER to continue:
Driver `f8000' (should be inserted):
Detects correctly:
* ISA bus, address 0xa00
Chip `Asus F8000 Super IO' (confidence: 9)
Driver `coretemp' (should be inserted):
Detects correctly:
* Chip `Intel Core family thermal sensor' (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
# Warning: the required module f8000 is not currently installed
# on your system. For status of 2.6 kernel ports check # http://www.lm-sensors.org/wiki/Devices. If driver is built # into the kernel, or unavailable, comment out the following line. modprobe f8000 modprobe coretemp /usr/bin/sensors -s #----cut here----
If you have some drivers built into your kernel, the list above will contain too many modules. Skip the appropriate ones! You really should try these commands right now to make sure everything is working properly. Monitoring programs won't work until the needed modules are loaded.
_______________________________________________
lm-sensors mailing list
[email protected]
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
Hi Achim,
Quoted 10 lines · achim
Am Freitag, den 09.05.2008, 19:05 +0200 schrieb Jean Delvare:
Quoted 9 lines
Quoted 4 lines
Afterward i tried it with only
0x4cexcluded and the smbus chip still works. With no exclusions lm75 detection hangs at0x4cand afterwards i only get XX's from dumps.By "hangs" you mean it takes several seconds, or does it really stop? Are you certain that it's the LM75 detection causing problem? We check for no less than 33 different devices at address
0x4c...
Quoted 12 lines
-------------------------------------------------
Client found at address0x4c
Probing for `National Semiconductor LM75'...
-------------------------------------------------
This is where it stops for a few seconds.
i2cdump 00x4cw hangs in a way that i must cancle it with Ctrl-C and afterwards i need a reboot to get correct dumps.Quoted 4 lines
Anyway, most certainly the problem is with word transactions on this device you have at
0x4c. That won't be easy to work around, but I'll take a look anyway, maybe I'll have an idea. If I do, I'll ask you - again - to help with testing.
OK, I have come up with something. There are not that many detection routines using SMBus read word transactions, we only use them for the following devices in the 0x48-0x4f address range: LM75, DS75, LM77, LM92, LM76, MAX663x and DS1621. So I have changed the detection of all these devices to do as much as possible with read byte transactions, and only use read word transactions at the end when we are already almost certain that we have identified the device.
Here's the patch:
--- prog/detect/sensors-detect | 163 +++++++++++++++++++++++++++----------------- 1 file changed, 102 insertions(+), 61 deletions(-)
prog/detect/sensors-detect +102 -61
@@ -2724,6 +2724,10 @@ sub i2c_smbus_read_byte_data # $_[0]: Reference to an opened filehandle # $_[1]: Command byte (usually register number) # Returns: -1 on failure, the read word on success. +# Use this function with care, some devices don't like word reads, +# so you should do as much detection as possible using byte reads, +# and only start using word reads when there is a good chance that +# the detection will succeed. # Note: some devices use the wrong endiannes; use swap_bytes to correct for # this. sub i2c_smbus_read_word_data
@@ -3587,46 +3591,42 @@ sub lm78_alias_detect # The DS75 is a bit different, it doesn't cycle over 8-byte boundaries, and # all register addresses from 0x04 to 0x0f behave like 0x04-0x07 do for # the LM75. +# Not all devices enjoy SMBus read word transactions, so we use read byte +# transactions even for the 16-bit registers. The low bits aren't very +# useful for detection anyway. sub lm75_detect { my $i; my ($chip, $file, $addr) = @_; - my $cur = i2c_smbus_read_word_data($file,0x00); + my $cur = i2c_smbus_read_byte_data($file, 0x00); my $conf = i2c_smbus_read_byte_data($file,0x01); - my $hyst = i2c_smbus_read_word_data($file,0x02); + my $hyst = i2c_smbus_read_byte_data($file, 0x02); my $maxreg = $chip = 1 ? 0x0f : 0x07; for $i (0x04 .. $maxreg) { - return if i2c_smbus_read_word_data($file, $i) != $hyst; + return if i2c_smbus_read_byte_data($file, $i) != $hyst; } - my $os = i2c_smbus_read_word_data($file,0x03); + my $os = i2c_smbus_read_byte_data($file, 0x03); for $i (0x04 .. $maxreg) { - return if i2c_smbus_read_word_data($file, $i) != $os; + return if i2c_smbus_read_byte_data($file, $i) != $os; } if ($chip = 0) { for ($i = 8; $i <= 248; $i += 40) { return if i2c_smbus_read_byte_data($file, $i + 0x01) != $conf - or i2c_smbus_read_word_data($file, $i + 0x02) != $hyst - or i2c_smbus_read_word_data($file, $i + 0x03) != $os; + or i2c_smbus_read_byte_data($file, $i + 0x02) != $hyst + or i2c_smbus_read_byte_data($file, $i + 0x03) != $os; } } # All registers hold the same value, obviously a misdetection - return if $conf = ($cur & 0xff) and $cur = $hyst - and $cur = $os; + return if $conf = $cur and $cur = $hyst and $cur = $os; - $cur = swap_bytes($cur); - $hyst = swap_bytes($hyst); - $os = swap_bytes($os); # Unused bits return if $chip = 0 and ($conf & 0xe0); return if $chip = 1 and ($conf & 0x80); - $cur = $cur >> 8; - $hyst = $hyst >> 8; - $os = $os >> 8; # Most probable value ranges return 6 if $cur <= 100 and ($hyst >= 10 && $hyst <= 125) and ($os >= 20 && $os <= 127) and $hyst < $os;
@@ -3645,54 +3645,65 @@ sub lm75_detect # 0x03: Overtemperature Shutdown # 0x04: Low limit # 0x05: High limit -# 0x04-0x07: No registers +# 0x06-0x07: No registers # The first detection step is based on the fact that the LM77 has only # six registers, and cycles addresses over 8-byte boundaries. We use the # 0x06-0x07 addresses (unused) to improve the reliability. These are not # real registers and will always return the last returned value. This isn't # documented. # Note that register 0x00 may change, so we can't use the modulo trick on it. +# Not all devices enjoy SMBus read word transactions, so we use read byte +# transactions even for the 16-bit registers at first. We only use read word +# transactions in the end when we are already almost certain that we have an +# LM77 chip. sub lm77_detect { my $i; my ($file,$addr) = @_; - my $cur = i2c_smbus_read_word_data($file,0x00); + my $cur = i2c_smbus_read_byte_data($file, 0x00); my $conf = i2c_smbus_read_byte_data($file,0x01); - my $hyst = i2c_smbus_read_word_data($file,0x02); - my $os = i2c_smbus_read_word_data($file,0x03); + my $hyst = i2c_smbus_read_byte_data($file, 0x02); + my $os = i2c_smbus_read_byte_data($file, 0x03); - my $low = i2c_smbus_read_word_data($file,0x04); - return if i2c_smbus_read_word_data($file,0x06) != $low; - return if i2c_smbus_read_word_data($file,0x07) != $low; - - my $high = i2c_smbus_read_word_data($file,0x05); - return if i2c_smbus_read_word_data($file,0x06) != $high; - return if i2c_smbus_read_word_data($file,0x07) != $high; + my $low = i2c_smbus_read_byte_data($file, 0x04); + return if i2c_smbus_read_byte_data($file, 0x06) != $low; + return if i2c_smbus_read_byte_data($file, 0x07) != $low; + + my $high = i2c_smbus_read_byte_data($file, 0x05); + return if i2c_smbus_read_byte_data($file, 0x06) != $high; + return if i2c_smbus_read_byte_data($file, 0x07) != $high; for ($i = 8; $i <= 248; $i += 40) { return if i2c_smbus_read_byte_data($file, $i + 0x01) != $conf; - return if i2c_smbus_read_word_data($file, $i + 0x02) != $hyst; - return if i2c_smbus_read_word_data($file, $i + 0x03) != $os; - return if i2c_smbus_read_word_data($file, $i + 0x04) != $low; - return if i2c_smbus_read_word_data($file, $i + 0x05) != $high; + return if i2c_smbus_read_byte_data($file, $i + 0x02) != $hyst; + return if i2c_smbus_read_byte_data($file, $i + 0x03) != $os; + return if i2c_smbus_read_byte_data($file, $i + 0x04) != $low; + return if i2c_smbus_read_byte_data($file, $i + 0x05) != $high; } # All registers hold the same value, obviously a misdetection - return if $conf = ($cur & 0xff) and $cur = $hyst + return if $conf = $cur and $cur = $hyst and $cur = $os and $cur = $low and $cur = $high; - $cur = swap_bytes($cur); - $os = swap_bytes($os); - $hyst = swap_bytes($hyst); - $low = swap_bytes($low); - $high = swap_bytes($high); # Unused bits return if ($conf & 0xe0) - or (($cur >> 12) != 0 && ($cur >> 12) != 0xf) - or (($hyst >> 12) != 0 && ($hyst >> 12) != 0xf) - or (($os >> 12) != 0 && ($os >> 12) != 0xf) - or (($low >> 12) != 0 && ($low >> 12) != 0xf) - or (($high >> 12) != 0 && ($high >> 12) != 0xf); + or (($cur >> 4) != 0 && ($cur >> 4) != 0xf) + or (($hyst >> 4) != 0 && ($hyst >> 4) != 0xf) + or (($os >> 4) != 0 && ($os >> 4) != 0xf) + or (($low >> 4) != 0 && ($low >> 4) != 0xf) + or (($high >> 4) != 0 && ($high >> 4) != 0xf); + + # Make sure the chip supports SMBus read word transactions + $cur = i2c_smbus_read_word_data($file, 0x00); + return if $cur < 0; + $hyst = i2c_smbus_read_word_data($file, 0x02); + return if $hyst < 0; + $os = i2c_smbus_read_word_data($file, 0x03); + return if $os < 0; + $low = i2c_smbus_read_word_data($file, 0x04); + return if $low < 0; + $high = i2c_smbus_read_word_data($file, 0x05); + return if $high < 0; $cur /= 16; $hyst /= 16;
@@ -3720,33 +3731,48 @@ sub lm77_detect # One detection step is based on the fact that the LM92 and clones have a # limited number of registers, which cycle modulo 16 address values. # Note that register 0x00 may change, so we can't use the modulo trick on it. +# Not all devices enjoy SMBus read word transactions, so we use read byte +# transactions even for the 16-bit registers at first. We only use read +# word transactions in the end when we are already almost certain that we +# have an LM92 chip or compatible. sub lm92_detect { my ($chip, $file, $addr) = @_; my $conf = i2c_smbus_read_byte_data($file, 0x01); - my $hyst = i2c_smbus_read_word_data($file, 0x02); - my $crit = i2c_smbus_read_word_data($file, 0x03); - my $low = i2c_smbus_read_word_data($file, 0x04); - my $high = i2c_smbus_read_word_data($file, 0x05); + my $hyst = i2c_smbus_read_byte_data($file, 0x02); + my $crit = i2c_smbus_read_byte_data($file, 0x03); + my $low = i2c_smbus_read_byte_data($file, 0x04); + my $high = i2c_smbus_read_byte_data($file, 0x05); return if $conf = 0 and $hyst = 0 and $crit = 0 and $low = 0 and $high = 0; - return if $chip = 0 - and i2c_smbus_read_word_data($file, 0x07) != 0x0180; - + # Unused bits return if ($chip = 0 || $chip = 1) and ($conf & 0xE0); - for (my $i = 0; $i < 8; $i++) { - return if i2c_smbus_read_byte_data($file, $i*16+0x01) != $conf; - return if i2c_smbus_read_word_data($file, $i*16+0x02) != $hyst; - return if i2c_smbus_read_word_data($file, $i*16+0x03) != $crit; - return if i2c_smbus_read_word_data($file, $i*16+0x04) != $low; - return if i2c_smbus_read_word_data($file, $i*16+0x05) != $high; + for (my $i = 0; $i <= 240; $i += 16) { + return if i2c_smbus_read_byte_data($file, $i + 0x01) != $conf; + return if i2c_smbus_read_byte_data($file, $i + 0x02) != $hyst; + return if i2c_smbus_read_byte_data($file, $i + 0x03) != $crit; + return if i2c_smbus_read_byte_data($file, $i + 0x04) != $low; + return if i2c_smbus_read_byte_data($file, $i + 0x05) != $high; } + return if $chip = 0 + and i2c_smbus_read_word_data($file, 0x07) != 0x0180; + + # Make sure the chip supports SMBus read word transactions + $hyst = i2c_smbus_read_word_data($file, 0x02); + return if $hyst < 0; + $crit = i2c_smbus_read_word_data($file, 0x03); + return if $crit < 0; + $low = i2c_smbus_read_word_data($file, 0x04); + return if $low < 0; + $high = i2c_smbus_read_word_data($file, 0x05); + return if $high < 0; + foreach my $temp ($hyst, $crit, $low, $high) { return if $chip = 2 and ($temp & 0x7F00); return if $chip != 2 and ($temp & 0x0700);
@@ -3763,23 +3789,38 @@ sub lm92_detect # 0xAA: Temperature # 0xA1: High limit # 0xA2: Low limit +# 0xA8: Counter +# 0xA9: Slope # 0xAC: Configuration # Detection is weak. We check if bit 4 (NVB) is clear, because it is # unlikely to be set (would mean that EEPROM is currently being accessed). -# Temperature checkings will hopefully prevent LM75 or other chips from -# being detected as a DS1621. +# We also check the value of the counter and slope registers, the datasheet +# doesn't mention the possible values but the conversion formula together +# with experimental evidence suggest possible sanity checks. +# Not all devices enjoy SMBus read word transactions, so we do as much as +# possible with read byte transactions first, and only use read word +# transactions second. sub ds1621_detect { - my $i; my ($file,$addr) = @_; + + my $conf = i2c_smbus_read_byte_data($file, 0xAC); + return if ($conf & 0x10); + + my $counter = i2c_smbus_read_byte_data($file, 0xA8); + my $slope = i2c_smbus_read_byte_data($file, 0xA9); + return if ($slope != 0x10 || $counter > $slope); + my $temp = i2c_smbus_read_word_data($file,0xAA); + return if $temp < 0 || ($temp & 0x7f00); my $high = i2c_smbus_read_word_data($file,0xA1); + return if $high < 0 || ($high & 0x7f00); my $low = i2c_smbus_read_word_data($file,0xA2); - return if ($temp | $high | $low) & 0x7F00; - my $conf = i2c_smbus_read_byte_data($file,0xAC); + return if $low < 0 || ($low & 0x7f00); + return if ($temp = 0 && $high = 0 && $low = 0 && $conf = 0); - return 3 if ($conf & 0x10) = 0x00; - return; + + return 3; } # $_[0]: A reference to the file descriptor to access this chip.
Please give it a try, I believe that it should _not_ do any word transaction on your chip at 0x4c (all detections should fail before that) and thus sensors-detect should no longer break your SMBus.
I have also updated the test script at:
http://jdelvare.pck.nerim.net/sensors/sensors-detect
It includes the detection of 1-register-only devices, and the patch above.
I would appreciate as much testing of this patch as possible, in particular from people having any of the devices those detection routines changed (LM75, DS75, LM77, LM92, LM76, MAX663x and DS1621) but more generally from anyone having an I2C/SMBus device in address range 0x48-0x4f. I want to make sure that I didn't add false positives with the changes.
Thanks,
Signature · 6 lines
Jean Delvare _______________________________________________ lm-sensors mailing list [email protected] http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
Hi Achim,
Quoted 9 lines · achim
Am Samstag, den 10.05.2008, 18:40 +0200 schrieb Jean Delvare:
Quoted 7 lines
OK, I have come up with something. There are not that many detection routines using SMBus read word transactions, we only use them for the following devices in the 0x48-0x4f address range: LM75, DS75, LM77, LM92, LM76, MAX663x and DS1621. So I have changed the detection of all these devices to do as much as possible with read byte transactions, and only use read word transactions at the end when we are already almost certain that we have identified the device.
Quoted 4 lines
I just tried your patch, and sensors-detect works fine without breaking the smbus now.
I attached the log.
Excellent, thanks for testing. It looks very good. I am going to commit my two patches to SVN now, just in time for 3.0.2.
Quoted 2 lines
Now without breaking at 0x4c the chip at 0x4e isdetected as an overclock controller.
Aha, interesting :) I am curious if this chip is also the one answering at 0x2e. The datasheet doesn't suggest so, but as we saw several boards with this overclocking chip and the mysterious chip at 0x2e, I start wondering if it could be the same chip...
Quoted 18 lines
I'm currently working on a module for the clockgenerator chip. I started with the lm75 module and modified it in a way that it reads out the ref HT speed. I want to extend it to read out the onboard gpu and pcie frequency also.
The registers at
0x90and0x91are responsible for the ref HT frequency.m=0x91[0:7]*4+0x90[6:7]
n=0x90[0:5]ref HT = 50MHz * m/n
It is also possible to change the ref HT on the fly by writing to those registers but that needs further inspection because the datasheet lacks the info what divider n is suitable. Also I only tested this with spread spectrum disabled, otherwise i'd need a few tables for the spectrum registers whom are also not covered by the datasheet.
Quoted 3 lines
Would such a module fit into the lm-sensors project? On the one hand it monitors motherboard frequencies on the other it's not a sensor chip i'm utilising.
Well, we have the atxp1 driver under drivers/hwmon already... But I don't think it should be there. Anything related to overclocking should be clearly labelled so and moved to a dedicated subsystem with a separate maintainer. The target audience of these chips is clearly different.
As for libsensors, no, I would rather not add the features of overclocking chips to it. Better write a separate library if needed. Again, separate audience.
We have the detection of these overclocking chips in sensors-detect simply because they happen to live at an address which is frequently used by thermal sensor chips. If they were living at different addresses, we wouldn't care about them at all.
Signature · 6 lines
Jean Delvare _______________________________________________ lm-sensors mailing list [email protected] http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
I agree, perfect timeframe. :) You mentioned two patches so i assume the third patch (address issue with typo) is already in SVN.
Quoted 9 lines
Quoted 3 lines
Now without breaking at 0x4c the chip at 0x4e isdetected as an overclock controller.
Aha, interesting :) I am curious if this chip is also the one answering at
0x2e. The datasheet doesn't suggest so, but as we saw several boards with this overclocking chip and the mysterious chip at0x2e, I start wondering if it could be the same chip...
Also grabbed the datasheet and inspected that chip. Seems it is only used as a watchdog here.
The value of address 0x00 is 0x02 after i boot. Bit 2 indicates " New CPU". I can change that value
if i eighter write 0x00 or 0x04 (clear new cpu) to 0x00. Both writes result in the value 0x00.
The VID modification part seems to be unused. Also i can not enable it setting bit 2 or bit 2 and 4.
None of the vid related registers can be modified.
The chip must be located below the heatpipes or it is part of another chip.
Quoted 11 lines
Quoted 11 lines
Well, we have the atxp1 driver under
drivers/hwmonalready... But I don't think it should be there. Anything related to overclocking should be clearly labelled so and moved to a dedicated subsystem with a separate maintainer. The target audience of these chips is clearly different.As for libsensors, no, I would rather not add the features of overclocking chips to it. Better write a separate library if needed. Again, separate audience.
Quoted 6 lines
Quoted 6 lines
We have the detection of these overclocking chips in sensors-detect simply because they happen to live at an address which is frequently used by thermal sensor chips. If they were living at different addresses, we wouldn't care about them at all.
Yeah, that different audience argument is a point. :)
So for a different subsystem i can simply use hwmon.c as a basis i guess. Supported chips would be all types of voltage regulators, overclocking controllers and clock generators and cpu's. Overall i'm more interested in underclocking and energy saving than in overclocking but both areas require good controll over above mentioned chips.
Gotta consider if i can donate an presumably huge amount of time into getting this project going. :)
_______________________________________________
lm-sensors mailing list
[email protected]
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors