Hi Jean, > Sent: Wednesday, September 17, 2014 at 11:08 PM > From: "Jean Delvare" <jdelvare@xxxxxxx> > > 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. Well, since this is the only option to control my fans the decision is already made. It's no critical machine, just a home server. > > > (...) > > > 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. I just loaded your debug version without the extra parameter and everything seems to be working fine. dmesg shows the info below, so it seems ok. Let me know if you need me to do any specific tests. [ 136.127376] i2c_i801: module verification failed: signature and/or required key missing - tainting kernel [ 136.131584] i801_smbus 0000:00:1f.3: can't derive routing for PCI INT C [ 136.131596] i801_smbus 0000:00:1f.3: PCI INT C: no GSI [ 136.131608] ACPI Warning: 0x000018e0-0x000018ff SystemIO conflicts with Region \_SB_.PCI0.SBUS.SMBI 1 (20131115/utaddress-251) [ 136.131623] ACPI: This conflict may cause random problems and system instability [ 136.131627] ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver [ 136.131655] i801_smbus 0000:00:1f.3: Failed to allocate irq 255: -22 [ 136.131799] i801_smbus 0000:00:1f.3: SMBus using polling > > 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. Your polling fall-back version seems to be a good improvement. Did you already see the lspci output in the post in the other thread-branch? It shows that pin C is routed to IRQ 255, seems related to me, but I've no idea what pin C means. > -- > Jean Delvare > SUSE L3 Support ~ Scott _______________________________________________ lm-sensors mailing list lm-sensors@xxxxxxxxxxxxxx http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
