Red Hat Bugzilla – Bug 496355
lm_sensors crippled in fedora 11 beta
Last modified: 2015-03-04 20:20:23 EST
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):
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
3. almost no information printed
tiny subset of what is displayed on f10
same (or more) info than f10 provides
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
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:
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
Adapter: PCI adapter
Core0 Temp: +31.0°C
Core1 Temp: +34.0°C
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.