Am Samstag, den 10.05.2008, 18:40 +0200 schrieb Jean Delvare: > Hi Achim, > > On Fri, 09 May 2008 19:31:44 +0200, achim wrote: > > Am Freitag, den 09.05.2008, 19:05 +0200 schrieb Jean Delvare: > > > > > > > Afterward i tried it with only 0x4c excluded and the smbus chip still > > > > works. With no exclusions lm75 detection hangs at 0x4c and 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. > > > > > 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. Hi Jean, I just tried your patch, and sensors-detect works fine without breaking the smbus now. I attached the log. Now without breaking at 0x4c the chip at 0x4e is detected as an overclock controller. 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 0x90 and 0x91 are 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. 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. > > 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, -------------- next part -------------- A non-text attachment was scrubbed... Name: detect.log Type: text/x-log Size: 8308 bytes Desc: not available Url : http://lists.lm-sensors.org/pipermail/lm-sensors/attachments/20080511/217e6b03/attachment.bin
