Re: Fintek f71882fg ACPI conflict

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 06/28/2012 07:27 AM, Jean Delvare wrote:
On Thu, 28 Jun 2012 13:53:49 +0100, Michael Zintakis wrote:
In the meantime, considering the specifics of my particular case and the
memory regions involved (again, I think they are 0x290-0x297, a total of
8 bytes in length according to the driver, though if someone more
knowledgeable in the f71882fg driver specifics know otherwise, please
feel free to correct this if that assumption is wrong), would it be
possible to manually hack into the ACPI code and forcefully prevent it
from claiming those memory regions and not get involved in "managing"
that particular device?

Not that I know of. That would rather be a question for the ACPI
people, but I'm afraid the answer is that ACPI is supposed to be the
best thing since sliced bread and you should just let it do its stuff
and not ask questions :( I too would love to be able to tell ACPI to
let my hardware monitoring chip (and/or SMBus controller) alone.

The ACPI conflict gets triggered when the BIOS AML code creates an operation region to access the same device that the driver is trying to bind to. There apparently are some BIOSes that do this and yet don't use it to actually access the hardware monitoring chip. In this case there is no true conflict and the acpi_enforce_resources=lax option is safe to use. Unfortunately there's really no way for the kernel to tell whether or not this is the case.

In this case, however, where the BIOS does in fact expose an ACPI thermal zone and relies on AML code to perform fan control, etc. then it seems quite likely that it's not safe to access the same hardware monitoring controller while AML code may be doing so at the same time. The only way I can see that you could make ACPI "leave the hardware monitoring chip alone" is to either have the kernel block its accesses (quite likely breaking all fan/temperature control) or disable ACPI entirely (in this case the BIOS likely either leaves the fan control in "run at max speed always" mode or uses SMIs to gain control where needed to adjust fan speeds, which causes the same concurrent access problem).

_______________________________________________
lm-sensors mailing list
lm-sensors@xxxxxxxxxxxxxx
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors


[Index of Archives]     [Linux Kernel]     [Linux Hardware Monitoring]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]

  Powered by Linux