Re: DME1737 not recognized

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 09/17/2014 03:23 AM, Jean Delvare wrote:
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.

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.

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.

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.

Looks suspiciously like a bad (uninitialized ?) interrupt number to me.

Guenter


_______________________________________________
lm-sensors mailing list
lm-sensors@xxxxxxxxxxxxxx
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors





[Index of Archives]     [Linux Kernel]     [Linux Hardware Monitoring]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]

  Powered by Linux