Hi Scott, Le Wednesday 17 September 2014 à 21:36 +0200, Scott Anderson a écrit : > > Sent: Wednesday, September 17, 2014 at 12:23 PM > > From: "Jean Delvare" <jdelvare@xxxxxxx> > > > > There is indeed a resource conflict for your SMBus controller. Please > > realize that it may mean that ACPI is accessing it and you shouldn't be. > > Of course it is also possible that the conflict is fake and can be > > ignored. To be (almost) sure, you would need to disassemble the DSDT > > table of your system and check if any function there is accessing ports > > 0x18e0-0x18ff. > > Is there another safe way to read/control the chips? My ACPI driver doesn't support temp/fan reading/control if I'm correct: > $ ls /proc/acpi/ > ac_adapter battery wakeup > $ acpi -t ACPI never gives you direct control of the fan, it's supposed to all work magically. /proc/acpi is mostly deprecated anyway, you'd rather look into /sys/class/thermal, but even there in most cases you only get a status, not the speed, and no control at all :( > > I disassembled the DSDT table[0] and I do see the 0x18e0-0x18ff range mentioned in the SBUS device (line 3523). It looks like it's being used in 3 places of which one is some sort of shutdown code, but I can't really tell if the other two places (BRTW and _L07 methods) can create a conflict. > > [0]: http://pastebin.com/6MewvGqV I don't know for sure either. What I'm sure of is that there are many references to methods operating over the SMBus I/O region, so it is potentially unsafe to access it from the OS. I think that's something SpeedFan completely ignores, so you get to decide what you want to do. > > (...) > > As a workaround, I would suggest that you reload the i2c-i801 driver > > with option disable_features=0x10. It will force the driver to use > > polling instead of interrupts. It's slower but at least it may work in > > your case. > > Loading the i2c-i801 driver with the option before running sensors-detect seems to do the trick. > Afterwards sensors-detect finds the correct chips. > > ## sensors-detect output: > > Next adapter: SMBus I801 adapter at 18e0 (i2c-7) > Do you want to scan it? (YES/no/selectively): y > Client found at address 0x2e > <...> > Probing for `SMSC DME1737'... Success! > (confidence 6, driver `dme1737') > <...> > Probing for `Maxim MAX1617'... Success! > (confidence 3, driver `adm1021') > Probing for `Maxim MAX1617A'... Success! > (confidence 7, driver `adm1021') > <...> > Driver `dme1737': > * Bus `SMBus I801 adapter at 18e0' > Busdriver `i2c_i801', I2C address 0x2e > Chip `SMSC DME1737' (confidence: 6) > > Driver `adm1021': > * Bus `SMBus I801 adapter at 18e0' > Busdriver `i2c_i801', I2C address 0x4c > Chip `Maxim MAX1617A' (confidence: 7) > * Bus `SMBus I801 adapter at 18e0' > Busdriver `i2c_i801', I2C address 0x4e > Chip `Maxim MAX1617A' (confidence: 7) > > Loading the detected drivers makes the sensors command work correctly. Indeed, looks much better. > > Two months ago I prepared a debug i2c-i801 driver for another user, you > > may want to give it a try too: > > http://jdelvare.nerim.net/devel/lm-sensors/drivers/i2c-i801_debug/ > > Instructions can be found at: > > http://jdelvare.nerim.net/devel/lm-sensors/drivers/INSTALL > > > > This version of the driver should revert to polling automatically if it > > can't get the interrupt to work, so you no longer need to pass the extra > > module parameter. > > That driver should do the same trick then, do you need me to test it? I would appreciate if you can test it, yes, as this will go upstream soon. > If this problem can't be solved otherwise I would suggest this should indeed be the default fall-back behavior. I agree. The driver as it exists today assumes that everything related to interrupts will always succeed, while it's not always true. I had never seen the specific problem you reported before, but other users have reported different issues with the interrupt-related code, so it definitely needs to cope better with unexpected situations. -- Jean Delvare SUSE L3 Support _______________________________________________ lm-sensors mailing list lm-sensors@xxxxxxxxxxxxxx http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
