Most recent kernel where this bug did *NOT* occur: 2.6.11 Distribution: Debian 4.0 (Etch) Hardware Environment: Motherboard Asus P4B533 Software Environment: Problem Description: The Intel SMBus controller is no longer recognised by Etch. Steps to reproduce: A Debian 4.0 "Etch" have been installed on a Desktop PC (Motherboard Asus P4B533) which previously ran on Debian 3.1. The mbmon hardware monitor program didn't suceed to access to the sensors, despite the fact that it worked perfectly on Sarge : # mbmon -d No Hardware Monitor found!! InitMBInfo: Success The system was rebooted on a knoppix 3.8.1 live-CD (kernel 2.6.11), and here mbmon works : # mbmon -d Using SMBus access method[Intel8XX(ICH/ICH2/ICH3/ICH4/ICH5/ICH6)]!! Asus chip ASB100(Bach) found If I do lspci with the knoppix live CD I've got the lines : ... 0000:00:1f.1 IDE interface: Intel Corp. 82801DB/DBL (ICH4/ICH4-L) UltraATA-100 IDE Controller (rev 01) 0000:00:1f.3 SMBus: Intel Corp. 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) SMBus Controller (rev 01) 0000:01:00.0 VGA compatible controller: nVidia Corporation: Unknown device 00f1 (rev a2) ... We can see here the Intel SMBus controller. If I do lspci under Debian Etch don't have any SMBus line, and no other peripheral at address 00:1f.3 : # lspci -M -s 00:1f 00:1f.0 ISA bridge: Intel Corporation 82801DB/DBL (ICH4/ICH4-L) LPC Interface Bridge (rev 01) 00:1f.1 IDE interface: Intel Corporation 82801DB (ICH4) IDE Controller (rev 01) pcilib: Cannot open /sys/bus/pci/devices/0000:00:1f.2/config pcilib: Cannot open /sys/bus/pci/devices/0000:00:1f.3/config pcilib: Cannot open /sys/bus/pci/devices/0000:00:1f.4/config ... The fact that the Intel SMbus controller is undetected prevents monitoring programs like mbmon to access the temperature and voltage sensors of the motherboard. All the Best Pierre
Asus is hiding the SMBus on many of their boards. The kernel has to unhide it, otherwise the hardware monitoring chip connected to the SMBus cannot be used. Around kernel 2.6.16, it was noticed that this operation wasn't properly handled when suspend/resume cycles were performed on the affected systems, with potentially dangerous effects on some systems. So we decided to play it safe and disabled the feature altogether when suspend support is enabled in the kernel. This happened in kernel 2.6.17, and was backported to 2.6.16.y too. Since then, Alan Cox fixed the problem, so using the SMBus unhiding quirk should be safe even when suspend/resume is used. Alan's fix went into 2.6.20: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=1597cacbe39802d86656d1f2e6329895bd2ef531 So, from 2.6.16 to 2.6.19, you have to choose between hardware monitoring and suspend support on these Asus boards. Typically, distribution kernels will have suspend support enabled, so no hardware monitoring support for the affected boards. This is what's happening on your Debian Etch. So, you have to either recompile your kernel without suspend support, or upgrade to kernel 2.6.20.
Alternatively, if upgrading or recompiling your kernel isn't an option, you could temporarily use the unhide_ICH_SMBus script from the lm_sensors source package. Please make sure to read the documentation carefully.
Thanks for the fast answers. I didn't find the the unhide_ICH_SMBus script in the debian lm_sensors source package. So i've installed the debian kernel image linux-image-2.6.20-1-686 and the SMBus is now recognized, and mbmon works perfectly. But now the nvidia video driver compiled for 2.6.18 no longer works and I need to install the linux-headers-2.6.20-1-686 to compile another driver. Unfortunately, for dependencies reasons related to linux-kbuild-2.6.20 and libc6, apt-get tell me to remove util-linux, which will cause my system to be unusable. I will be glad to receive any tips about this new issue, but as this is no longer related to the kernel, please use directly my address p.brial@orange.fr
unhide_ICH_SMBus is new in lm_sensors 2.10.3, and isn't installed by default.
Thanks The unhide_ICH_SMBus scripts works perfectly on my system. So I find safer to keep 2.6.18 kernel and use the script when needed. Thank you all for the quick fix. Keep up the good work. Regards Pierre