Bug 15731
Summary: | lm_sensors + kernel 2.6.31 => it87 fails | ||
---|---|---|---|
Product: | ACPI | Reporter: | ccancellieri (ccancellieri) |
Component: | Power-Thermal | Assignee: | acpi_power-thermal |
Status: | CLOSED DOCUMENTED | ||
Severity: | normal | CC: | ccancellieri, lenb, mjg59-kernel, rui.zhang, zmeyski |
Priority: | P1 | ||
Hardware: | All | ||
OS: | Linux | ||
Kernel Version: | 2.6.3x | Subsystem: | |
Regression: | No | Bisected commit-id: | |
Attachments: | my .config file |
Description
ccancellieri
2010-04-08 21:24:37 UTC
This isn't a bug. Your platform reserves the region used by the it87 chip and doesn't provide any alternative access method. acpi_enforce_resources=lax will restore the previous behaviour, but may result in racy access to the chip between the kernel and the firmware and potentially incorrect temperature eradings or system damage. Thank you Matthew for your replace. It's not clear... > Your platform reserves the region used by the it87 chip If so, it's a BIOS related problem? If no, why the it87 still exists into the kernel? >If an ACPI driver is available for this device, > you should use it instead of the native driver So... The solution is to use an hypothetical missing driver?!? If I've understand, the only solution to solve this: - change the Bios - change the MB - write an ACPI driver for this MB. Your ACPI tables or system management code access the it87. Since there's no locking between the operating system and the firmware in this case, there's the potential for simultaneous access and corresponding failure. Other machines may not do this, which means that the it87 remains available. The list of potential solutions seems correct. Alternatively, you can pass the kernel option - this provides behaviour equivalent to the older kernel and is no more dangerous than things were originally. |