Hi!
I'm new to the Linux world, but with the help of a friend and countless Google requests, I managed to set it up properly to be used by me.
However, I've now stumpled upon a problem I can't seem to solve by myself.

I am using a Lenovo IdeaPad S300 with a Panther Point chipset and an Ivy Bridge i3 CPU and after managing to configure CPU frequency scaling, I wanted to enable fan control. I followed this guide.
After activating all the modules mentioned in there and running sensors-detect, the only sensor that is actually detected is coretemp. I proceeded to remove the seemingly unneeded modules and ran pwmconfig:

Code:

/usr/sbin/pwmconfig: There are no pwm-capable sensor modules installed

This driver is in the main tree of the kernel. This means you should be able to load it by modprobing it,
provided you have this module included/compiled into your kernel.
Run
`modprobe -l | grep i801` as root and expect following line:

Quote:

kernel/drivers/i2c/busses/i2c-i801.ko

Then schedule this module to autoload with /etc/conf.d/modules
Also, have you run sensors-detect?
It would detected the required module automatically and schedule it to autoload.
Have you enabled lm_sensors service?

~ # pwmconfig
# pwmconfig revision 5857 (2010-08-22)
This program will search your sensors for pulse width modulation (pwm)
controls, and test each one to see if it controls a fan on
your motherboard. Note that many motherboards do not have pwm
circuitry installed, even if your sensor chip supports pwm.

We will attempt to briefly stop each fan using the pwm controls.
The program will attempt to restore each fan to full speed
after testing. However, it is ** very important ** that you
physically verify that the fans have been to full speed
after the program has completed.

/usr/sbin/pwmconfig: There are no pwm-capable sensor modules installed

On my thinkpad T60 the proper way to get reasonable output from sensors was to *first* load the module and then run sensors-detect, allowing it
to scan I2C/SMBus. Please load i801 driver, and then run sensors_detect, yesing all questions, and post the output here.

Btw, what is this pwmconfig? It is not even in portage? Are you sure it is not outdated?

This program will help you determine which kernel modules you need
to load to use lm_sensors most effectively. It is generally safe
and recommended to accept the default answers to all questions,
unless you know what you're doing.

Some Super I/O chips contain embedded sensors. We have to write to
standard I/O ports to probe them. This is usually safe.
Do you want to scan for Super I/O sensors? (YES/no): y
Probing for Super-I/O at 0x2e/0x2f
Trying family `National Semiconductor/ITE'... No
Trying family `SMSC'... No
Trying family `VIA/Winbond/Nuvoton/Fintek'... No
Trying family `ITE'... No
Probing for Super-I/O at 0x4e/0x4f
Trying family `National Semiconductor/ITE'... No
Trying family `SMSC'... No
Trying family `VIA/Winbond/Nuvoton/Fintek'... No
Trying family `ITE'... No

Some hardware monitoring chips are accessible through the ISA I/O ports.
We have to write to arbitrary I/O ports to probe them. This is usually
safe though. Yes, you do have ISA I/O ports even if you do not have any
ISA slots! Do you want to scan the ISA I/O ports? (YES/no): y
Probing for `National Semiconductor LM78' at 0x290... No
Probing for `National Semiconductor LM79' at 0x290... No
Probing for `Winbond W83781D' at 0x290... No
Probing for `Winbond W83782D' at 0x290... No

Lastly, we can probe the I2C/SMBus adapters for connected hardware
monitoring devices. This is the most risky part, and while it works
reasonably well on most systems, it has been reported to cause trouble
on some systems.
Do you want to probe the I2C/SMBus adapters now? (YES/no): y
Found unknown SMBus adapter 8086:1e22 at 0000:00:1f.3.
Sorry, no supported PCI bus adapters found.
Module i2c-dev loaded successfully.

Next adapter: i915 gmbus panel (i2c-2)
Do you want to scan it? (YES/no/selectively): y
Client found at address 0x4f
Probing for `National Semiconductor LM75'... No
Probing for `National Semiconductor LM75A'... No
Probing for `Dallas Semiconductor DS75'... No
Probing for `Dallas Semiconductor DS1621/DS1631'... No
Probing for `Maxim MAX6642'... No
Probing for `Texas Instruments TMP421'... No
Probing for `Texas Instruments TMP422'... No
Probing for `Maxim MAX6633/MAX6634/MAX6635'... No
Probing for `NXP/Philips SA56004'... No
Client found at address 0x50
Probing for `Analog Devices ADM1033'... No
Probing for `Analog Devices ADM1034'... No
Probing for `SPD EEPROM'... No
Probing for `EDID EEPROM'... Yes
(confidence 8, not a hardware monitoring chip)

This program will help you determine which kernel modules you need
to load to use lm_sensors most effectively. It is generally safe
and recommended to accept the default answers to all questions,
unless you know what you're doing.

Some Super I/O chips contain embedded sensors. We have to write to
standard I/O ports to probe them. This is usually safe.
Do you want to scan for Super I/O sensors? (YES/no): yes
Probing for Super-I/O at 0x2e/0x2f
Trying family `National Semiconductor/ITE'... No
Trying family `SMSC'... No
Trying family `VIA/Winbond/Nuvoton/Fintek'... No
Trying family `ITE'... No
Probing for Super-I/O at 0x4e/0x4f
Trying family `National Semiconductor/ITE'... No
Trying family `SMSC'... No
Trying family `VIA/Winbond/Nuvoton/Fintek'... No
Trying family `ITE'... No

Some hardware monitoring chips are accessible through the ISA I/O ports.
We have to write to arbitrary I/O ports to probe them. This is usually
safe though. Yes, you do have ISA I/O ports even if you do not have any
ISA slots! Do you want to scan the ISA I/O ports? (YES/no): yes
Probing for `National Semiconductor LM78' at 0x290... No
Probing for `National Semiconductor LM79' at 0x290... No
Probing for `Winbond W83781D' at 0x290... No
Probing for `Winbond W83782D' at 0x290... No

Lastly, we can probe the I2C/SMBus adapters for connected hardware
monitoring devices. This is the most risky part, and while it works
reasonably well on most systems, it has been reported to cause trouble
on some systems.
Do you want to probe the I2C/SMBus adapters now? (YES/no): yes

To be frank I did not know of its existence. This program is just AWESOME.
Finally I will get rid of /proc/acpi/ibm/fan home grown scripts manipulation

On topic, I do not know what is the cause of this weird behaviour.
You could check your BIOS settings. Later I will look if we could manually find
addresses for your chip and shove it down the sensors throat. Unfortunately today I am out of time.

Last edited by roravun on Thu Jan 03, 2013 8:33 pm; edited 1 time in total

Only verbose mode will give you information whether your chip is really under control of the module.
Unless you have already verified that.

As a side note:
if you like you can build the driver as a module. I compiled it into my kernel since I stick to the policy that
if something is unpluggable piece of hardware that is always used it makes no sense to compile it as a module.
I2c chip certainly fulfills these conditions.

Your I2C chip is not under the control of any driver. No wonder sensors cant find anything.
I think you should build the i801 driver as a module and manually load after your system is up. Or better, build
everything I2C related as modules, that way it can be easily verified that at least modules are working.

And you are correct as to the fact you have this chip. What is funny, I just noticed my chip has the same path as yours

Here: http://bpaste.net/show/68180/ you can find amended version of your kernel configuration.
I have removed tons of unnecessary stuff as well as disabled some ACPI sensors to be sure they do not cause the conflict
we have discovered. Please compile it and try to run it.

NOTE: before you compile, please run `make oldconfig`, to convert config from x86-32 to x86-64.

IMPORTANT: be sure to backup your current working kernel configuration first,
and provide grub entry for it. I can not guarantee you will be able to boot with newly compiled kernel.
Although I did not change any 'mount' critical parts of your configuration.

If somebody is curious, or has the same problem, in this case
there is a resource conflict that prevents the i2c_i801 driver from taking control over the chip:

Code:

ACPI Warning: 0x0000000000003040-0x000000000000305f SystemIO conflicts with Region \_SB_.PCI0.SBUS.SMBI 1 (20120711/utaddress-251)
ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver