Description of problem: In my fedora 10 boot partition lm_sensors can detect vastly greater amounts of information about the sensors on my system. In fedora 11, almost nothing shows up in the sensors output. Version-Release number of selected component (if applicable): lm_sensors-3.1.0-1.fc11.x86_64 kernel-2.6.29.1-70.fc11.x86_64 How reproducible: I tried sensors-detect a couple of times with the same results. Steps to Reproduce: 1. sensors-detect, answer yes to all, start lm_sensors 2. sensors 3. almost no information printed Actual results: tiny subset of what is displayed on f10 Expected results: same (or more) info than f10 provides Additional info: I'll attach transcripts comparing f10 to f11 on same hardware.
Created attachment 340117 [details] transcript from sensors-detect and sensors on fedora 11
Created attachment 340118 [details] comparison transcript from fedora 10 on same machine
Ok, You are probably being hit by a change in how the kernel handles resource conflicts between hwmon drivers and the BIOS acpi code. If you do (as root): modprobe it87, you will probably see it fail like this: FATAL: Error inserting it87 (/lib/modules/2.6.29-15.fc11.x86_64/kernel/drivers/hwmon/it87.ko): Device or resource busy If you then do: dmesg And look at the last few lines you will probably see something like this: it87: Found IT8716F chip at 0x290, revision 0 it87: in3 is VCC (+5V) it87: in7 is VCCH (+5V Stand-By) ACPI: I/O resource it87 [0x295-0x296] conflicts with ACPI region IP__ [0x295-0x296] ACPI: Device needs an ACPI driver In the passed hwmon drivers used to drive IO ranges which were potentially used by the ACPI code (which lives inside the BIOS), we now explicitly check for this and if the ACPI code claims the IO-ports used by the hwmon IC, we no longer allow the hwmon driver to load as it is very dangerous to have 2 pieces of software talking to the same IC at the same time. If you want to restore the old behaviour (which might be dangerous) add: acpi_enforce_resources=lax to the kernel cmdline when booting (or add it in grub.conf to make this permanent).
Yep, the kernel parameter seems to have mostly fixed it, but I see it seems to have lost all the information it formerly had about what each signal might be and how to scale the values. Here's the sensors output I now get which is not as interesting as the one from fedora 10 :-). [root@zooty ~]# sensors k8temp-pci-00c3 Adapter: PCI adapter Core0 Temp: +31.0°C Core1 Temp: +34.0°C it8712-isa-0290 Adapter: ISA adapter in0: +1.10 V (min = +0.00 V, max = +4.08 V) in1: +1.52 V (min = +0.00 V, max = +4.08 V) in2: +3.30 V (min = +0.00 V, max = +4.08 V) in3: +2.86 V (min = +0.00 V, max = +4.08 V) in4: +3.01 V (min = +0.00 V, max = +4.08 V) in5: +3.73 V (min = +0.00 V, max = +4.08 V) in6: +3.20 V (min = +0.00 V, max = +4.08 V) in7: +2.90 V (min = +0.00 V, max = +4.08 V) Vbat: +3.02 V fan1: 815 RPM (min = 811 RPM, div = 8) ALARM fan2: 0 RPM (min = 0 RPM, div = 8) temp1: +127.0°C (low = +127.0°C, high = +77.0°C) ALARM sensor = thermistor temp2: +127.0°C (low = +127.0°C, high = +77.0°C) ALARM sensor = thermistor temp3: +33.0°C (low = +127.0°C, high = +77.0°C) sensor = thermal diode cpu0_vid: +1.550 V
Copying the sensors3.conf file from my f10 partition fixed that problem.