Bug 13508

Summary:	ACPI I/O resource conflict between piix4_smbus and ACPI region SOR1
Product:	ACPI	Reporter:	Andy Figueroa (andy.figueroa)
Component:	EC	Assignee:	acpi_ec
Status:	CLOSED DOCUMENTED
Severity:	normal	CC:	andy.figueroa, astarikovskiy, lenb, sajij
Priority:	P1
Hardware:	All
OS:	Linux
Kernel Version:	2.6.29-gentoo-r5 and many other flavors	Subsystem:
Regression:	No	Bisected commit-id:

Description Andy Figueroa 2009-06-11 16:55:19 UTC

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.

Comment 1 Alexey Starikovskiy 2009-06-11 17:05:03 UTC

Andy,
You are not supposed to use ACPI and direct access to SMBUS in this case.

Comment 2 Andy Figueroa 2009-06-11 18:13:32 UTC

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

Comment 3 Alexey Starikovskiy 2009-06-11 18:23:38 UTC

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.

Comment 4 Andy Figueroa 2009-06-11 21:00:05 UTC

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.

Comment 5 Len Brown 2009-08-29 19:14:24 UTC

> 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.

Comment 6 Saji 2010-04-18 00:08:25 UTC

>>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.