> Sent: Wednesday, September 17, 2014 at 12:23 PM > From: "Jean Delvare" <jdelvare@xxxxxxx> > > Hi Scott, > > Le Tuesday 16 September 2014 à 21:22 +0200, Scott Anderson a écrit : > > Hi, > > > > I have a SIMATIC BOX PC 627[0] on which I'm trying to control my fans. The machine is running an updated ubuntu 14.04 server installation. > > I can't get lm-sensors working correctly. sensors-detect doesn't really seem to fully detect the chips. > > When I run windows on the machine I am able to control the fans using speedfan. Speedfan shows that there is a DME1737 chip present on the board to read some temperatures and control a few fans. Next to that there is also a MAX1617A available for some more temperatures. > > > > As far as I can see the DME1737 should be supported. > > It indeed is. > > > Manually loading the DME1737 driver and/or the driver suggested by sensors-detect doesn't show any info. > > All (linux related) info added below is with the acpi_enforce_resources=lax kernel option added. > > 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 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 > > Does anybody see what I'm missing? > > First note: the DS75 detection is most likely a false positive, so I > suggest you do NOT load the lm75 driver, it's not going to help. > > Your problem is that the SMBus is never probed by sensors-detect so it > can't find the DMS1737 hardware monitoring block, nor the MAX1617A > chips. > > sensors-detect sees the PCI device and loads the i2c-i801 driver. I am > surprised that the driver wasn't already loaded, normally udev + the > i2c-i801 module aliases should get the driver loaded automatically. But > the real problem is that even after loading the i2c-i801 driver, > sensors-detect doesn't see the SMBus. > > Looking at the kernel logs, it turns out that the device fails to > initialize with error: > > > [ 411.607004] i801_smbus 0000:00:1f.3: Failed to allocate irq 255: -22 > > [ 411.607126] i801_smbus: probe of 0000:00:1f.3 failed with error -22 > > This is the first time I see this error. Error 22 is EINVAL. The error > comes from request_irq. There can be several reasons for that, and > unfortunately the function doesn't log error messages so it's hard to > guess what happened. One thing for sure is that 255 as the IRQ number > looks rather suspicious. > > 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. > 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? If this problem can't be solved otherwise I would suggest this should indeed be the default fall-back behavior. > For a better long-term solution, I need to check if irq = 255 is any > special, maybe it means that interrupt is not available or something and > we shouldn't even try to request it. > > -- > Jean Delvare > http://jdelvare.nerim.net/wishlist.html ~ Scott _______________________________________________ lm-sensors mailing list lm-sensors@xxxxxxxxxxxxxx http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
