Resource conflict reported during boot recorded in dmesg: ACPI: I/O resource piix4_smbus [0xb00-0xb07] conflicts with ACPI region SOR1 [0xb00-0xb0f] followed by: ACPI: Device needs an ACPI driver piix4_smbus 0000:00:14.0: SMBus Host Controller at 0xb00, revision 0 Repeatable: always There is no known adverse affect. Entire string when searched in Google returns 479 hits with widely varying motherboards (Biostar, Asus, Gigabyte) all using AMD chipsets, notably RS770 and RS780 host bridge and SB600/700 USB controllers. Unresolved smbus resource conflict also reported in MS Windows with similar chipsets. It appears this is may be a chipset bug.
Andy, You are not supposed to use ACPI and direct access to SMBUS in this case.
Alexey, thanks for being so timely on this. How would one change something to NOT use ACPI and direct access to the SMBUS at the same time. There do not appear to be any related settings in the BIOS or kernel configuration. It seems like hundreds (probably thousands) of users are getting this wrong. BTW, here is the related lspci -v 00:14.0 SMBus: ATI Technologies Inc SBx00 SMBus Controller (rev 3a) Subsystem: Giga-byte Technology Device 4385 Flags: 66MHz, medium devsel Capabilities: <access denied> Kernel driver in use: piix4_smbus
Basically, you use whole hwmon infrastructure on your own risk. The conflict you see was added exactly to prevent users from shooting their feet. Without this check hwmon will try to use SMBUS and devices connected to it (most probably temperature control IC), thus making ACPI to read garbage from these same devices. If ACPI reads critical temperature (and it often does in such situation), it will simply shut machine down.
Success -- I think. I disabled the entire hwmon tree in the kernel, leaving i2c_piix4 as a module, which loaded automatically and produced the same error message. rmmod i2c_piix4 and then modprobe i2c_piix4 confirmed that that module alone is the apparent cause for the error message. After disabling i2c_piix4, subsequent boots are without error and without any apparent loss of functionality. Hopefully other users will find this thread and be able to resolve this issue in their own machines. THANK YOU.
> How would one change something to NOT use ACPI and direct access to the SMBUS > at the same time. This conflict is designed into the driver. Linux is simply recognizing that the BIOS AML is accessing the same resources and thus automatically dis-allowing the driver to load. If it is important that you run i2c_piix4, you can disable ACPI via BIOS SETUP or cmdline "acpi=off". You will likely lose more by disabling ACPI than you will by disabling i2c_piix4, but it is technically your choice... closing.
>>with widely varying motherboards (Biostar, Asus, Gigabyte) all >>using AMD chipsets, notably RS770 and RS780 host bridge and SB600/700 USB >>controllers. Well, I hit this many times on an Intel H/w with nehalem processor.