Haswell systems & i801 i2c driver
Subsystems (2)
When loading the i801 i2c bus driver on an i5-46xx CPU, and this chipset
http://www.intel.com/content/dam/www/public/us/en/documents/datasheets/8-series-chipset-pch-datasheet.pdf
I see the following warning:
i801_smbus 0000:00:1f.3: PCI INT C -> GSI 18 (level, low) -> IRQ 18
ACPI: resource 0000:00:1f.3 [io 0xefa0-0xefbf] conflicts with ACPI region SMBI [io 0xefa0-0xefaf]
ACPI: This conflict may cause random problems and system instability
ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver
It seems like the BIOS/ACPI defines a region, SMBI, which is defined for the SMBus to use, but there is no ACPI driver available for the SMBus (at least AFAICT).
I'm using "acpi_enforce_resources=lax" as a kernel parameter to work around the issue but was wondering if there was a more robust fix planned for this problem? If not -- anyone want to point me in the right direction of a fix?
Thanks,
P.
A message that is not in the archive (sent off-list or not yet received): [email protected]
[+cc Rafael, Matthew, linux-acpi]
Hi Prarit,
Quoted 12 lines · Prarit Bhargava
When loading the i801 i2c bus driver on an i5-46xx CPU, and this chipset
http://www.intel.com/content/dam/www/public/us/en/documents/datasheets/8-series-chipset-pch-datasheet.pdfI see the following warning:
i801_smbus0000:00:1f.3: PCI INT C -> GSI 18 (level, low) -> IRQ 18
ACPI: resource 0000:00:1f.3 [io 0xefa0-0xefbf] conflicts with ACPI region SMBI [io 0xefa0-0xefaf]
ACPI: This conflict may cause random problems and system instability
ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver
Quoted 3 lines
It seems like the BIOS/ACPI defines a region, SMBI, which is defined for the SMBus to use, but there is no ACPI driver available for the SMBus (at least AFAICT).
Is this on a production BIOS? It seems like a BIOS bug to expose a PCI device with resources that are used by ACPI. The spec you pointed to does mention an "SMBus Disable" bit (sec 10.1.54) that claims to disable PCI config space for this device. Maybe the BIOS forgot to set that?
If we (the Linux PCI core) discovered this device (00:1f.3), we believe we own it and can assign a driver to it and potentially change the resources assigned to it.
Changing the [io 0xefa0-0xefbf] BAR would likely break the SMBI opregion because the AML using it wouldn't know about the change.
Assigning a driver, e.g., i801_smbus, seems likely to cause conflicts with the AML that uses the SMBI opregion. These could be difficult to reproduce and debug.
If this is on a shipping BIOS, we might need to figure out some way to handle it. I don't remember anything in the ACPI spec that talks about issues like this, but maybe we should add something in PCI that notices if there's an ACPI device with the same resources and marks the PCI device to keep us from moving it or assigning a driver (maybe the warning you're seeing already handles the driver part?)
Bjorn
Quoted 7 lines
If this is on a shipping BIOS, we might need to figure out some way to handle it. I don't remember anything in the ACPI spec that talks about issues like this, but maybe we should add something in PCI that notices if there's an ACPI device with the same resources and marks the PCI device to keep us from moving it or assigning a driver (maybe the warning you're seeing already handles the driver part?)
This is, sadly, pretty typical. SMBus devices are often exposed via PCI even though they're accessed directly via AML. The current behaviour seems about as good as it gets - we warn the user that this could cause problems, and they can pass a kernel parameter that allows them to do it anyway.
Signature · 1 line
Matthew Garrett <[email protected]>
Quoted 7 lines · Matthew Garrett
Quoted 6 lines
If this is on a shipping BIOS, we might need to figure out some way to handle it. I don't remember anything in the ACPI spec that talks about issues like this, but maybe we should add something in PCI that notices if there's an ACPI device with the same resources and marks the PCI device to keep us from moving it or assigning a driver (maybe the warning you're seeing already handles the driver part?)
Quoted 5 lines
This is, sadly, pretty typical. SMBus devices are often exposed via PCI even though they're accessed directly via AML. The current behaviour seems about as good as it gets - we warn the user that this could cause problems, and they can pass a kernel parameter that allows them to do it anyway.
The proper way to handle it at the BIOS level is to expose the SMBus to the OS by implementing the ACPI SMBus CMI as supported by the i2c-scmi driver. Unfortunately most BIOS do not bother implementing that interface, effectively locking the OS out of the SMBus controller and everything behind it. This has been a major pain for years :(
Signature · 2 lines
Jean Delvare SUSE L3 Support
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 14 lines · Jean Delvare
Quoted 7 lines · Matthew Garrett
Quoted 6 lines
If this is on a shipping BIOS, we might need to figure out some way to handle it. I don't remember anything in the ACPI spec that talks about issues like this, but maybe we should add something in PCI that notices if there's an ACPI device with the same resources and marks the PCI device to keep us from moving it or assigning a driver (maybe the warning you're seeing already handles the driver part?)
Quoted 5 lines
This is, sadly, pretty typical. SMBus devices are often exposed via PCI even though they're accessed directly via AML. The current behaviour seems about as good as it gets - we warn the user that this could cause problems, and they can pass a kernel parameter that allows them to do it anyway.
Quoted 5 lines
The proper way to handle it at the BIOS level is to expose the SMBus to the OS by implementing the ACPI SMBus CMI as supported by the i2c-scmi driver. Unfortunately most BIOS do not bother implementing that interface, effectively locking the OS out of the SMBus controller and everything behind it. This has been a major pain for years :(
Hey Jean, Thanks for the info.
I'm about to RFC an algorithm patch for the i801 ACPI SBUS. I dunno if it is really a good thing to do outside of Intel or if we should wait for a CMI. OTOH it seems to work and your comment that "This has been a major pain for years" worries me that we'll never see a solution.
P.
Quoted 1 line
Hi Prarit,
Quoted 17 lines
When loading the i801 i2c bus driver on an i5-46xx CPU, and this chipset
http://www.intel.com/content/dam/www/public/us/en/documents/datash
eets/8-series-chipset-pch-datasheet.pdfI see the following warning:
i801_smbus0000:00:1f.3: PCI INT C -> GSI 18 (level, low) -> IRQ 18
ACPI: resource 0000:00:1f.3 [io 0xefa0-0xefbf] conflicts with ACPI region SMBI [io 0xefa0-0xefaf]
ACPI: This conflict may cause random problems and system instability
ACPI: If an ACPI driver is available for this device, you should use it instead of the native driverIt seems like the BIOS/ACPI defines a region, SMBI, which is defined for the SMBus to use, but there is no ACPI driver available for the SMBus (at least AFAICT).
Quoted 6 lines
I'm using "acpi_enforce_resources=lax" as a kernel parameter to work around the issue but was wondering if there was a more robust fix planned for this problem? If not -- anyone want to point me in the right direction of a fix?
From what I understand (mostly from Jean), this is a BIOS issue that we work around with the
acpi_enforce_resourcesparameter. So if you want to drive an actual fix for it, it'll need to be lobbed at BIOS folks.
Regards,
Seth