Latest working kernel version: ? Earliest failing kernel version: 2.6.27.10 failed as well... Distribution: ArchLinux, but self-compiled kernel Hardware Environment: Asus EeePC 8G (702), all standard, except upgraded wlan and memory. Problem Description: According to dmesg, during the boot process there is an I/O resource conflict as: ACPI: I/O resource 0000:00:1f.3 [0x400-0x41f] conflicts with ACPI region SMRG [0x400-0x40f] acpitool reports temperatures/battery properly, but xmbmon doesn't find any hardware monitor. Not totally sure where else would it show up in actual operation. Steps to reproduce: Boot....
Created attachment 19689 [details] dmesg log during boot-up up to the point of the reported conflict
Created attachment 19690 [details] PCI devices reported by lspci
Created attachment 19691 [details] dmidecode output
Created attachment 19692 [details] acpidump output
Hi, Gergely Does this issue still exist if you don't load the eeepc-laptop driver? Please attach the output of lspci -vxxx. Thanks.
Hi, Yes, even if I don't load the eeepc-laptop module, the result is the same.
Created attachment 19711 [details] lspci -vxxx output for more detailed information
Hi, Gergely Sorry for the late response. From the acpidump/lspci it seems that the SMbus I/O port(0x400-0x41f) is used by ACPI AML code. And the I/O port of SMbus PCI device is 0x400-0x41f. The hardware sensor driver depends the driver of i2c-i801.c. In such case if i2c-i801 driver is still loaded, there exists the synchronous issue between ACPI and OS kernel. So the i2c-i801 driver had better not be loaded for the SMbus PCI device. From the acpidump it seems that the SMBus I/O port is accessed in the ACPI AML code related with the driver of eeepc-laptop. Will you please double check it again? (Try the 2.6.26 kernel or disable the eeepc-laptop driver in the 2.6.27.10 kernel). Thanks.
(In reply to comment #8) > So the i2c-i801 driver had better not be loaded for the SMbus PCI device. > > From the acpidump it seems that the SMBus I/O port is accessed in the > ACPI > AML code related with the driver of eeepc-laptop. > Will you please double check it again? (Try the 2.6.26 kernel or disable > the eeepc-laptop driver in the 2.6.27.10 kernel). > Thanks. Hi, I tried some combinations of the i2c-i801 and eeepc-laptop driver in the 2.6.28 and 2.6.27.10 kernels I've been using. With both kernel versions: i2c-i801 + eeepc-laptop: conflict i2c-i801 alone: conflict eeepc-laptop alone: normal (no conflict) I looked around for other hardware monitor software a bit, and tried the XFCE4 Sensor Plugin. It can see a sensor with the type of "ACPI" (power, temperature), one with "acpitz-0" (temperature), and if the eeepc-laptop is loaded, then "eeepc-laptop" (fan rpm), and all of them read the same way regardless of the conflict... What kind of effect I should see depending on the conflict? I filed this bug because any such conflict can be the sign of underlying trouble, just need some direction to see what parts of the system would be affected by it. Let me know what kind of other info you'd need. I'm compiling the 2.6.26.8 kernel now to check it out with that one. Cheers, Greg
Same conflict with kernel 2.6.29rc4. Plus, additional conflict with w83627ehf hwmon driver. (Intel Core i7 and Asus P6T Deluxe X58 motherbaord). i801_smbus 0000:00:1f.3: PCI INT C -> GSI 18 (level, low) -> IRQ 18 ACPI: I/O resource 0000:00:1f.3 [0x400-0x41f] conflicts with ACPI region SMRG [0x400-0x40f] w83627ehf: Found W83667HG chip at 0x290 ACPI: I/O resource w83627ehf [0x295-0x296] conflicts with ACPI region HWRE [0x290-0x299]
Created attachment 20177 [details] Output from acpidump
Created attachment 20178 [details] Output from dmidecode
Created attachment 20179 [details] Output from lspci -vxxx
I see this problem too on my EeePC 900 with 2.6.29-rc (in my case I started building i2c-i801 into the kernel for the first time). Gergely Imreh: Is it possible for you to push this bug state from NEEDINFO back to ASSIGNED (but ONLY if you don't have to assign it to yourself)? The information requested has been provided...
(Gary has informed me that only the ASSIGNEE can change the NEEDINFO state. My bad and apologies for the noise)
*** Bug 12541 has been marked as a duplicate of this bug. ***
*** Bug 12706 has been marked as a duplicate of this bug. ***
From the info in bug 12706#c25 we know that the box can work well after adding the boot option of "acpi_enforce_resources=strict" although the following warning message is complained and the i2c-i801 driver can't be loaded. >ACPI: I/O resource 0000:00:1f.3 [0x400-0x41f] conflicts with ACPI region SMRG [0x400-0x40f] But in fact the problem is related with the BIOS. The SMbus I/O port will be accessed in ACPI AML code.If the i2c-i801 driver is still loaded for the SMBUS PCI device, there is no synchronization between OS driver and ACPI AML driver. And we don't know what will happen. So it is correct that the following message is complained. It will be safe that the boot option of acpi_enforce_resources=strict is added for such box. Thanks.
this conflict warning seems harmless on this laptop, but it does indicate a problem on an eeepc901, please refer to bug #12706. I'm still wondering, as bug #12706 is a regression, is acpi_enforce_resources=strict the right fix for this bug? or do we still need to find out the commit which introduce this regression?
Weren't there patches to hide or make the SMBus visible again? Maybe this could be related? I could imagine hiding SMBus and thus make some hwmon drivers not loading, could replace acpi_enforce_resource=strict in some cases and could be a more proper way? But I don't know enough about that..., just a guess.
It is a good idea to hide the SMbus device. In such case the i2c-i801 driver won't be loaded for the SMbus PCi controller, which can avoid the conflict between ACPI AML and i2c-i801 driver. But on some Asus boxes when OS detects that the SMbus device is hidden, it will try to make it visible again(this is done in the pci quirks function). Thanks.
The unhiding quirk is only applied for machines on which we know it is safe (that is, neither ACPI nor SMM are accessing the SMBus.) So this isn't related to the resource conflict. We could add a _hiding_ quirk for machines on which the SMBus _is_ used by ACPI or SMM and the BIOS didn't hide the SMBus already, as was suggested by Thomas in comment #20. This has the advantage that it can be implemented immediately and it is very fine-grained. However, this would only work on Intel ICH-based boards (and not even all of them) so this won't solve the problem completely. It also has the drawback that the blacklist could grow quickly, possibly beyond the size of the current whitelist.
(In reply to comment #19) > I'm still wondering, as bug #12706 is a regression, > is acpi_enforce_resources=strict the right fix for this bug? > or do we still need to find out the commit which introduce this regression? I don't think there is any point if searching for the patch which "introduced the regression". I don't think this is a regression per se, more likely things were working only by chance until then. Best to just use acpi_enforce_resources=strict on this machine.
Created attachment 20476 [details] Add the dmi check to make acpi_enforce_resources strict
Err, please don't close this bug before the fix has been reviewed, tested and has made it into mainline. Not to mention that PATCH_ALREADY_AVAILABLE for a patch you just wrote is dishonest - you should use CODE_FIX as the resolution. Review of the patch: __cpuinitdata doesn't sound right for acpi_resources_dmi_table, it should be __initdata. Please use proper C99-style structure initialization for acpi_resources_dmi_table (that is, including member names.) DMI_MATCH(DMI_PRODUCT_NAME, "901") seems a little fragile... and incorrect if I read the DMI data properly. You should use DMI_MATCH(DMI_BOARD_NAME, "901") if I am not mistaken. And I would also check for DMI_MATCH(DMI_PRODUCT_NAME, "Eee PC") to make the test more robust. Why do you test for 901 while the reporter of this bug has an Eee PC 702? I am curious if we should blacklist all Eee PC models maybe. You moved the definition of acpi_enforce_resources but you didn't move the comments that explain its possible values. This makes the code harder to read. Please move the comment together with the code it refers to.
IIRC, we had agreed up on changing the default for acpi_enforce_resources to strict in general? Atleast that is what seemed to be the consensus after a discussion about this on the ACPI list. In that case the proposed patch isn't needed, only a very simple patch changing the default.
Hi, Jean Sorry that I don't attach the updated patch(In the updated patch the __cpuinitdata is already changed to __initdata). There is an EEEPC-901 in my hand. So I add it to the dmi check table and test it. In fact there exists this issue on several boxes.(For example: 702, 901, Asus P6T Deluxe X58 motherbaord). Maybe the Hans's suggestion is a good choice. The default value for acpi_enforce_resources is changed to strict. If so, the dmi blacklist is redundant. Thanks.
Hans, I have no objection to changing the default to strict in general. However rc7 seems a little late for such a big change. Also I think we agreed that the atk0110 driver should be merged first, and it hasn't happened yet. So I'd rather schedule both the driver addition and the change of default for 2.6.30. In the meantime, there are _actual_ problems with the Eee PC and possibly a few other machines out there, which should be fixed in 2.6.29 because they are regressions. So starting with a small DMI-based blacklist for 2.6.29 adressing these regressions seems alright to me. It's not like it's a huge amount of intrusive code... it can be reverted pretty easily for 2.6.30 when we have a more global solution. At any rate, I am certainly not willing to discourage any attempt to fix bugs in this area in the name of an hypothetical alternative solution. The issue has been pending for too long already, so whoever spends time on solving it is in its own right by definition.
Jean, I didn't know there were issues which needed fixing for 2.6.29, I agree then that a blacklist if a good (temporary) solution for 2.6.29, and then we can change the default (and merge the atk0110 driver) for 2.6.30.
Created attachment 20482 [details] [update] add the dmi check to make acpi_enforce_resources strict The attached is updated patch. The following boxes are added to the dmi check table. > eeepc 702 > eeepc 901 > dell studio 1537 > asus P6T deluxe Thanks.
Created attachment 20483 [details] dmidecode output for EeePC 900
Created attachment 20514 [details] the updated patch The attached is the updated patch. The Asus EEEPC 900 is also added to DMI check table. Now the following are included in the DMI check table: a. Asus EEEPC 900/702/901 b. Asus P6T deluxe c. Dell 1537 I test it on the Asus EEEPC 901 and the i2c-i801 driver won't be loaded again. Thanks.
Who is pushing this patch upstream?
patch in comment #31 applied to acpi-test tree
I have the same conflict here with 2.6.28.7 on Asus P5Q SE Plus. I was just wondering why this seems to happen mostly on Asus motherboard, and does this means until 2.6.30 is released there is no need to build i2c support in the kernel for those with this issue, or just not build the i2c-801? Also does this means until atk0110 is merged there will be no voltage/fan/... sensor support for those motherboard?
If the P5Q uses the same chip as the P6T - w83667hg - patches are available for native rather than atk0110 support .... ftp://ftp.kernel.org/pub/linux/kernel/people/jdelvare/linux-2.6/jdelvare-hwmon/
You should not disable I2C support altogether. A lot of things need I2C (framebuffer drivers, TV and DVB drivers...) which you could miss. You may disable the i2c-i801 driver if it is the driver that conflicts. However which driver conflicts depends on the mainboard model. It might as well be w83627ehf or it87 and not i2c-i801. Anyway there is no good reason to disable any diver, just boot with acpi_enforce_resources=strict (until this becomes the default) and you're done.
Thank you for your comments, I believe it is the i2c-i801 conflicting, after adding the acpi_enforce_resources=strict boot option i get the dmesg below and the i2c-i801 module is then not loaded. [ 0.881441] i801_smbus 0000:00:1f.3: PCI INT C -> GSI 18 (level, low) -> IRQ 18 [ 0.881441] ACPI: I/O resource 0000:00:1f.3 [0x400-0x41f] conflicts with ACPI region SMRG [0x400-0x40f] [ 0.881441] ACPI: Device needs an ACPI driver [ 0.881441] i801_smbus: probe of 0000:00:1f.3 failed with error -16 Not that it seem to cause any problem and/or delay without this option before.
After the boot option of acpi_enforce_resources=strict is added, the i2c-i801 driver won't be loaded for the smbus PCI device again when the conflict is detected. The following only complains that the i801_smbus driver can't be loaded. It is what we expected. >[ 0.881441] i801_smbus: probe of 0000:00:1f.3 failed with error -16 In fact this issue also exists on other vendor's motherboards.(For example: on one box based on nvidia chipset). This issue is mainly caused by the BIOS. The PCI SMbus device is accessed by AML code. For example: Read the thermal temperature. In such case the PCI smbus had better be hidden and can't be enumerated by PCI scanning. As there is no synchronization between AML code and driver, there will exist the potential issue if the driver is loaded for the PCI SMbus device. So the better solution is to hide the SMbus PCI device. But how to hide it depends on the chipset. Another reasonable solution is that the i2c_smbus driver won't be loaded for smbus device when the conflict is detected. Thanks.
(In reply to comment #39) > So the better solution is to hide the SMbus PCI device. But how to hide > it > depends on the chipset. Actually not all SMBus devices can be hidden than way, so it can't be considered a generic solution. > Another reasonable solution is that the i2c_smbus > driver won't be loaded for smbus device when the conflict is detected. Which is what we have already implemented with the acpi_enforce_resources parameter.
um, so we have the patch in comment #31 staged for 2.6.30... but shouldn't we be changing the default to ENFORCE_RESOURCES_STRICT in 2.6.30?
(In reply to comment #41) > um, so we have the patch in comment #31 staged for 2.6.30... > > but shouldn't we be changing the default to ENFORCE_RESOURCES_STRICT > in 2.6.30? AFAIk that is the plan yes, Luca Tettamanti has recently send a patch for this to the acpi list and that has been reviewed and acked by 2 people. Also we (hwmon people) should then be merging Luca's atk0110 patch, Jean ? Jean: note I have a version of the atk0110 patch from Luca which has adjustments for some of the 2.6.29 acpi changes, which I've been using in the Fedora kernels. Not sure if he send that to the list too, I shall forward it to you.
Len, the patch in comment #32 was meant as a temporary fix for 2.6.29, it wasn't meant for 2.6.30, but as far as I can see it was never applied in 2.6.29 so that kernel version is still affected by this bug. For 2.6.30 we have Luca's patch: http://marc.info/?l=linux-acpi&m=123836410926774 Please apply it. Hans, I didn't have the time to look at Luca's code, but if you did review it, I trust you. Please post the latest version with your Signed-off-by and I'll add it to my hwmon tree.
Created attachment 20785 [details] patch Luca Tettamanti's patch, as applied to the 2.6.29-based acpi tree, to set acpi_enforce_resource=strict by default. This obsoletes the previous DMI patch, which has been dropped from the acpi tree.
shipped in 2.6..30 merge window (2.6.29-git14) closed. commit 7e90560c50f754d65884e251e94c1efa2a4b5784 Author: Luca Tettamanti <kronos.it@gmail.com> Date: Mon Mar 30 00:01:27 2009 +0200 ACPI: acpi_enforce_resource=strict by default
*** Bug 13089 has been marked as a duplicate of this bug. ***
Hello. While the above is dated March-April 2009 and I am already running kernel 2.6.32, I am still suffering from this problem. While most of the above discussion is over my head, I think there might still be a bug. Is it possible to reopen this issue? Distribution: Debian squeeze/sid (almost everything being squeeze, the current 'testing') Kernel version: Linux hikaru 2.6.32-5-amd64 #1 SMP Fri Dec 10 15:35:08 UTC 2010 x86_64 GNU/Linux Hardware: ASUS P5B DeLuxe motherboard During boot I get the errors: ACPI: I/O resource 0000:00:1f.3 [0x400-0x41f] conflicts with ACPI region SMRG [0x400-0x40f] ... ACPI: I/O resource w83627ehf [0x295-0x296] conflicts with ACPI region HWRE [0x290-0x299] while I don't seem to need the w83627ehf module (and it isn't loaded), lsmod DOES show the i2c_i801 being loaded and I'm not sure what it does, what functionality I'd lose if I disabled it somehow. I'd prefer not to get the above errors at all in my logs ;). I'll attach the output of the following commands: dmesg (up till the point of reported conflict) lspci -vxxx acpidump Please let me know if more data is needed.
Created attachment 40122 [details] Output of dmesg Added attachment 'dmesg.out', see comment of 14 December 2010.
Created attachment 40132 [details] Output of acpidump Added attachment 'acpi.out', see comment of 14 December 2010.
Created attachment 40152 [details] Output of lspci -vxxx Added attachment 'lspci.out', see comment of 14 December 2010.
On Asus desktop boards, you must use the asus_atk0110 driver for hardware monitoring. The warning messages are harmless, just ignore them. If you really want to get rid of them, blacklist the i2c-i801 driver, and stop loading the w83627ehf driver (that one doesn't autoload, so you must be loading it manually, otherwise you wouldn't get the warning message.)
*** Bug 26342 has been marked as a duplicate of this bug. ***
commit 106d1a0ab2a354b97df3e232be7dedbfaf8e901d Author: Thomas Renninger <trenn@suse.de> Date: Mon Dec 20 12:11:45 2010 +0100 ACPI: fix resource check message
Kernel Version: Linux ananias 2.6.37.2.uvesafb.nvidia #1 SMP PREEMPT Sun Feb 27 00:11:07 CET 2011 x86_64 GNU/Linux Distribution: Debian GNU/Linux wheezy/sid Motherboard: Tyan Thunder K8W S2885 Hi i reported the Bug 13089 back in 2009 which was marked as the duplicate of this bug. I still get this errors: [ 7.354614] ACPI: resource amd756_smbus [io 0x10e0-0x10ef] conflicts with ACPI region PMIO [io 0x1000-0x10fe 64bit disabled] [ 7.354621] ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver [ 7.365045] ACPI: resource 0000:00:07.2 [io 0xcc00-0xcc1f] conflicts with ACPI region ECIO [io 0xcc00-0xcc1f pref disabled] [ 7.365052] ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver thnx in advance for any info
Created attachment 49342 [details] dmesg
Created attachment 49352 [details] lspci -v
Created attachment 49362 [details] ioports
Created attachment 49372 [details] acpidump
Hi, (In reply to comment #54) > Kernel Version: > Linux ananias 2.6.37.2.uvesafb.nvidia #1 SMP PREEMPT Sun Feb 27 00:11:07 CET > 2011 x86_64 GNU/Linux > > Distribution: > Debian GNU/Linux wheezy/sid > > Motherboard: > Tyan Thunder K8W S2885 > > Hi i reported the Bug 13089 back in 2009 which was marked as the duplicate of > this bug. > I still get this errors: > > [ 7.354614] ACPI: resource amd756_smbus [io 0x10e0-0x10ef] conflicts with > ACPI region PMIO [io 0x1000-0x10fe 64bit disabled] > [ 7.354621] ACPI: If an ACPI driver is available for this device, you > should > use it instead of the native driver > [ 7.365045] ACPI: resource 0000:00:07.2 [io 0xcc00-0xcc1f] conflicts with > ACPI region ECIO [io 0xcc00-0xcc1f pref disabled] > [ 7.365052] ACPI: If an ACPI driver is available for this device, you > should > use it instead of the native driver > > thnx in advance for any info Those are not errors but "normal" informational messages indicating that since your BIOS' ACPI code is using it, the hwmon ic on your motherboard cannot be accessed by Linux, see: http://www.lm-sensors.org/wiki/FAQ/Chapter3#Mysensorshavestoppedworkinginkernel2.6.31 http://hansdegoede.livejournal.com/7932.html Regards, Hans