Description of problem: Upon updating to the latest kernel (2.6.16-1.2122_FC5) & rebooting I find that I no longer have lmsensors. /var/log/messages gives this in the suspect area: ========== . . . May 22 11:42:42 localhost kernel: i2c_adapter i2c-0: SMBus Quick command not supported, can't probe for chips May 22 11:42:42 localhost kernel: i2c_adapter i2c-1: SMBus Quick command not supported, can't probe for chips May 22 11:42:42 localhost kernel: i2c_adapter i2c-2: SMBus Quick command not supported, can't probe for chips . . . ========= rebooted using previous kernel (kernel-2.6.16-1.2111_FC5) & lmsensors is present & accounted for. Version-Release number of selected component (if applicable): 2.6.16-1.2122_FC5 How reproducible: can reproduce. Steps to Reproduce: 1. install kernel 2.6.16-1.2122_FC5 2. reboot, temp & fan speeds missing from gkrellm (see error message above) 3. reboot but using kernel kernel-devel-2.6.16-1.2111_FC5, fan speeds + temps available. Actual results: no fan speeds or temps Expected results: fan speeds + temps as with all prior kernels Additional info: using Asus motherboard P4B533
edit: same issue with kernel 2.6.16-1.2133_FC5
http://www.kernel.org/git/?p=linux/kernel/git/stable/linux-2.6.16.y.git;a=commit;h=a9cacd682ed7c031fa05b1d1367a3b3221813932 That patch was introduced in 2.6.16.17 which was the basis for 2.6.16-1.2122_FC5. It seems like this patch is responsible for lm_sensors no longer working on ASUS boards. It's a fix for http://bugzilla.kernel.org/show_bug.cgi?id=6449 and therefore also found it's way into 2.6.17.
additional: same issue with kernel 2.6.17-1.2139_FC5
OUTPUT FROM sensors-detect (if it is helpful): To load everything that is needed, add this to some /etc/rc* file: #----cut here---- # I2C adapter drivers # modprobe unknown adapter NVIDIA I2C Device # modprobe unknown adapter NVIDIA I2C Device # modprobe unknown adapter NVIDIA I2C Device # I2C chip drivers modprobe eeprom # sleep 2 # optional /usr/bin/sensors -s # recommended #----cut here----
additional: same issue with kernel 2.6.17-1.2145_FC5
same issue with kernel 2.6.17-1.2157_FC5
Same problem occurs on HP nc6000 laptop. lspci for kernel-2.6.16-1.2111_FC5 gives: 00:00.0 Host bridge: Intel Corporation 82855PM Processor to I/O Controller (rev 03) 00:01.0 PCI bridge: Intel Corporation 82855PM Processor to AGP Controller (rev 03) 00:1d.0 USB Controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #1 (rev 03) 00:1d.1 USB Controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #2 (rev 03) 00:1d.2 USB Controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #3 (rev 03) 00:1d.7 USB Controller: Intel Corporation 82801DB/DBM (ICH4/ICH4-M) USB2 EHCI Controller (rev 03) 00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev 83) 00:1f.0 ISA bridge: Intel Corporation 82801DBM (ICH4-M) LPC Interface Bridge (rev 03) 00:1f.1 IDE interface: Intel Corporation 82801DBM (ICH4-M) IDE Controller (rev 03) 00:1f.3 SMBus: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) SMBus Controller (rev 03) 00:1f.5 Multimedia audio controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) AC'97 Audio Controller (rev 03) 00:1f.6 Modem: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) AC'97 Modem Controller (rev 03) 01:00.0 VGA compatible controller: ATI Technologies Inc RV350 [Mobility Radeon 9600 M10] 02:04.0 Ethernet controller: Atheros Communications, Inc. AR5212 802.11abg NIC (rev 01) 02:06.0 CardBus bridge: O2 Micro, Inc. OZ711M3/MC3 4-in-1 MemoryCardBus Controller 02:06.1 CardBus bridge: O2 Micro, Inc. OZ711M3/MC3 4-in-1 MemoryCardBus Controller 02:06.2 System peripheral: O2 Micro, Inc. OZ711Mx 4-in-1 MemoryCardBus Accelerator 02:06.3 CardBus bridge: O2 Micro, Inc. OZ711M3/MC3 4-in-1 MemoryCardBus Controller 02:0e.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5705M_2 Gigabit Ethernet (rev 03) Note that the SMBus line is missing on newer kernels.
here is lspci for kernel 2.6.17-1.2157_FC5 for my Asus P4B533 motherboard: 00:00.0 Host bridge: Intel Corporation 82845 845 (Brookdale) Chipset Host Bridge (rev 11) 00:01.0 PCI bridge: Intel Corporation 82845 845 (Brookdale) Chipset AGP Bridge (rev 11) 00:1d.0 USB Controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #1 (rev 01) 00:1d.1 USB Controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #2 (rev 01) 00:1d.2 USB Controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #3 (rev 01) 00:1d.7 USB Controller: Intel Corporation 82801DB/DBM (ICH4/ICH4-M) USB2 EHCI Controller (rev 01) 00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev 81) 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) 01:00.0 VGA compatible controller: nVidia Corporation NV43 [GeForce 6600/GeForce 6600 GT] (rev a2) 02:03.0 Multimedia audio controller: C-Media Electronics Inc CM8738 (rev 10) 02:0a.0 Ethernet controller: 3Com Corporation 3c905C-TX/TX-M [Tornado] (rev 78) 02:0b.0 Ethernet controller: Linksys NC100 Network Everywhere Fast Ethernet 10/100 (rev 11) 02:0c.0 Multimedia audio controller: Creative Labs SB Live! EMU10k1 (rev 0a) 02:0c.1 Input device controller: Creative Labs SB Live! MIDI/Game Port (rev 0a)
(In reply to comment #2) > http://www.kernel.org/git/?p=linux/kernel/git/stable/linux-2.6.16.y.git;a=commit;h=a9cacd682ed7c031fa05b1d1367a3b3221813932 > > That patch was introduced in 2.6.16.17 which was the basis for > 2.6.16-1.2122_FC5. It seems like this patch is responsible for lm_sensors no > longer working on ASUS boards. > > It's a fix for http://bugzilla.kernel.org/show_bug.cgi?id=6449 and therefore > also found it's way into 2.6.17. This is a bit confusing to me: will this "fix" be fixed and if so, by whom? I commented on the kernel bugzilla as well, but there's no reaction yet. Should I stay on the Red Hat bugzilla or should I keep trying at the kernel bugzilla?
(In reply to comment #9) > > This is a bit confusing to me: will this "fix" be fixed and if so, by whom? I > commented on the kernel bugzilla as well, but there's no reaction yet. Should I > stay on the Red Hat bugzilla or should I keep trying at the kernel bugzilla? I don't know. I'm neither working on the kernel nor am I working for Red Hat. I merely tracked down the patch to provide additional information. Best thing would be to fix this in the vanilla kernel. If there is no reaction on the kernel bugzilla, maybe you should write an email to LKML.
I've managed to work around the issue using ACPI (for reading temperatures). AFAIK, there's nobody working on a patch, so this problem may persist for a while.
Congradulations. Is the ACPI work-around something a mere mortal could understand?
I'm using gnome-applet-sensors-1.6-3.fc5, which can use /proc/acpi/thermal_zone for its input. Also, cpuspeed uses /proc/acpi/thermal_zone for CPU scaling during overheating, so I don't need lm_sensors anymore. I simply switched off lm_sensors in the services panel. Fan speed monitoring doesn't work for me: I can only see if it's at setting 0, 1, 2, 3 or 4 through /proc/acpi/fan.
no luck for me on this M/B (P4B533). updated my bios & checked my /proc/acpi/dsdt table for errors - no errors. Still no joy on fan or temps. I guess this will not work for some of us.
A new kernel update has been released (Version: 2.6.18-1.2200.fc5) based upon a new upstream kernel release. Please retest against this new kernel, as a large number of patches go into each upstream release, possibly including changes that may address this problem. This bug has been placed in NEEDINFO state. Due to the large volume of inactive bugs in bugzilla, if this bug is still in this state in two weeks time, it will be closed. Should this bug still be relevant after this period, the reporter can reopen the bug at any time. Any other users on the Cc: list of this bug can request that the bug be reopened by adding a comment to the bug. In the last few updates, some users upgrading from FC4->FC5 have reported that installing a kernel update has left their systems unbootable. If you have been affected by this problem please check you only have one version of device-mapper & lvm2 installed. See bug 207474 for further details. If this bug is a problem preventing you from installing the release this version is filed against, please see bug 169613. If this bug has been fixed, but you are now experiencing a different problem, please file a separate bug for the new problem. Thank you.
On FC5, P4B533 motherboard, kernel 2.6.18-1.2200.fc5 from /var/log/messages (dont know if related to problem): =================== Oct 16 23:32:52 localhost kernel: i2c_adapter i2c-0: SMBus Quick command not supported, can't probe for chips Oct 16 23:32:52 localhost kernel: i2c_adapter i2c-1: SMBus Quick command not supported, can't probe for chips Oct 16 23:32:52 localhost kernel: i2c_adapter i2c-2: SMBus Quick command not supported, can't probe for chips =================== Get this when attempting to start lm_sensors: Starting lm_sensors: No sensors found! Same story, different kernel. lm_sensors worked fine prior to 2.6.16-1.2122_FC5 kernel release.
The three "SMBus Quick command not supported" error messages in the logs come from the proprietary nvidia graphics driver. They are not related with the missing sensors in any way, but feel free to report the bug to nvidia. The missing sensors are caused by this patch: http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=ce007ea59729d627f62bb5fa8c1a81e25653a0ad This patch was backported in 2.6.16.17. Also see: https://bugzilla.novell.com/show_bug.cgi?id=190925 Long story short: * Asus hides the SMBus on many Intel-based motherboards and laptops. * We have to use a PCI quirk to enable SMBus access on these systems. * When resuming from suspend-to-ram, quirks are not replayed, so SMBus isn't restored, and Bad Things Happen (TM). So, it order to be safe, the SMBus unhiding quirk has been disabled when the kernel is compiled with suspend support. This is a regression for users of these systems who care about sensors and don't care about suspend, but this was the only quick fix to make things safe. Possible improvements: * Get Asus to no more hide the SMBus in their BIOS. * Make disabling the SMBus unhiding a run time decision, rather than compilation time decision, so that users have a chance to disable suspend on the boot command line if they care more about sensors. * Make it possible to replay PCI quirks on resume.
Thank you, I believe you have it exactly right. As you can guess I dont have a laptop that is running FC5 so I dont care about "resume". Other folks apparently do. I feel blind compared to past times w/o sensor outputs. I wish I could get acpi working fully so I could use that approach.
* Make it possible to replay PCI quirks on resume. Hmm, I thought we actually did this. If not, this seems like the most practical way to please everyone no ?
As far as I know, we currently replay PCI quirks when resuming from disk but not when resuming from RAM. I don't know why it is done this way, there might be a reason. I agree it would be the best solution here.
I think Alan was looking at doing this recently.
Submitted a proposed patch today.
Sorted upstream
Thanks a lot Alan, this issue was being reported over and over again, and it's really great that you could fix it upstream :)