Bug 12376

Summary: ACPI I/O resource conflict with SMBus
Product: ACPI Reporter: Gergely Imreh (imrehg)
Component: OtherAssignee: ykzhao (yakui.zhao)
Status: CLOSED PATCH_ALREADY_AVAILABLE    
Severity: normal CC: acpi-bugzilla, carlo, clive, florian, jdelvare, jwrdegoede, klondike+kernel, lenb, liontos.aristotelis, rjw, rui.zhang, sitsofe, trenn, zmeyski
Priority: P1    
Hardware: All   
OS: Linux   
Kernel Version: 2.6.28 Subsystem:
Regression: No Bisected commit-id:
Attachments: dmesg log during boot-up up to the point of the reported conflict
PCI devices reported by lspci
dmidecode output
acpidump output
lspci -vxxx output for more detailed information
Output from acpidump
Output from dmidecode
Output from lspci -vxxx
Add the dmi check to make acpi_enforce_resources strict
[update] add the dmi check to make acpi_enforce_resources strict
dmidecode output for EeePC 900
the updated patch
patch
Output of dmesg
Output of acpidump
Output of lspci -vxxx
dmesg
lspci -v
ioports
acpidump

Description Gergely Imreh 2009-01-07 04:00:51 UTC
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....
Comment 1 Gergely Imreh 2009-01-07 04:02:02 UTC
Created attachment 19689 [details]
dmesg log during boot-up up to the point of the reported conflict
Comment 2 Gergely Imreh 2009-01-07 04:02:50 UTC
Created attachment 19690 [details]
PCI devices reported by lspci
Comment 3 Gergely Imreh 2009-01-07 04:07:00 UTC
Created attachment 19691 [details]
dmidecode output
Comment 4 Gergely Imreh 2009-01-07 04:11:07 UTC
Created attachment 19692 [details]
acpidump output
Comment 5 ykzhao 2009-01-07 17:25:44 UTC
Hi, Gergely
    Does this issue still exist if you don't load the eeepc-laptop driver?

    Please attach the output of lspci -vxxx.
    Thanks.
Comment 6 Gergely Imreh 2009-01-07 17:45:40 UTC
Hi,

  Yes, even if I don't load the eeepc-laptop module, the result is the same.
Comment 7 Gergely Imreh 2009-01-07 17:52:14 UTC
Created attachment 19711 [details]
lspci -vxxx output for more detailed information
Comment 8 ykzhao 2009-01-11 18:54:57 UTC
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.
    
Comment 9 Gergely Imreh 2009-01-12 17:25:33 UTC
(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
Comment 10 Clive Messer 2009-02-10 01:14:21 UTC
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]
Comment 11 Clive Messer 2009-02-10 01:15:26 UTC
Created attachment 20177 [details]
Output from acpidump
Comment 12 Clive Messer 2009-02-10 01:15:45 UTC
Created attachment 20178 [details]
Output from dmidecode
Comment 13 Clive Messer 2009-02-10 01:16:06 UTC
Created attachment 20179 [details]
Output from lspci -vxxx
Comment 14 Sitsofe Wheeler 2009-02-14 23:51:09 UTC
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...
Comment 15 Sitsofe Wheeler 2009-02-15 00:26:12 UTC
(Gary has informed me that only the ASSIGNEE can change the NEEDINFO state. My bad and apologies for the noise) 
Comment 16 Zhang Rui 2009-02-25 16:57:32 UTC
*** Bug 12541 has been marked as a duplicate of this bug. ***
Comment 17 Zhang Rui 2009-02-25 16:58:25 UTC
*** Bug 12706 has been marked as a duplicate of this bug. ***
Comment 18 ykzhao 2009-02-26 00:12:37 UTC
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.
Comment 19 Zhang Rui 2009-02-26 01:12:30 UTC
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?
Comment 20 Thomas Renninger 2009-02-27 02:37:09 UTC
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.
Comment 21 ykzhao 2009-03-04 23:26:17 UTC
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.
    
Comment 22 Jean Delvare 2009-03-05 00:53:17 UTC
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.
Comment 23 Jean Delvare 2009-03-05 00:55:55 UTC
(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.
Comment 24 ykzhao 2009-03-09 20:23:31 UTC
Created attachment 20476 [details]
Add the dmi check to make acpi_enforce_resources strict
Comment 25 Jean Delvare 2009-03-10 01:54:45 UTC
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.
Comment 26 Hans de Goede 2009-03-10 02:01:49 UTC
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.
Comment 27 ykzhao 2009-03-10 02:54:32 UTC
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.
Comment 28 Jean Delvare 2009-03-10 03:37:59 UTC
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.
Comment 29 Hans de Goede 2009-03-10 03:40:43 UTC
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.
Comment 30 ykzhao 2009-03-10 05:26:23 UTC
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.
Comment 31 Sitsofe Wheeler 2009-03-10 06:55:17 UTC
Created attachment 20483 [details]
dmidecode output for EeePC 900
Comment 32 ykzhao 2009-03-13 00:07:15 UTC
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.
Comment 33 Jean Delvare 2009-03-13 01:50:40 UTC
Who is pushing this patch upstream?
Comment 34 Len Brown 2009-03-15 12:48:10 UTC
patch in comment #31 applied to acpi-test tree
Comment 35 mlconsultant 2009-03-18 06:28:03 UTC
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?
Comment 36 Clive Messer 2009-03-18 06:37:00 UTC
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/
Comment 37 Jean Delvare 2009-03-18 06:45:21 UTC
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.
Comment 38 mlconsultant 2009-03-18 07:08:34 UTC
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.
Comment 39 ykzhao 2009-03-18 18:34:13 UTC
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.
    
Comment 40 Jean Delvare 2009-03-19 00:40:58 UTC
(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.
Comment 41 Len Brown 2009-04-02 04:43:39 UTC
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?
Comment 42 Hans de Goede 2009-04-02 07:39:14 UTC
(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.
Comment 43 Jean Delvare 2009-04-02 08:54:21 UTC
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.
Comment 44 Len Brown 2009-04-03 02:11:10 UTC
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.
Comment 45 Len Brown 2009-04-07 03:00:55 UTC
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
Comment 46 ykzhao 2009-04-15 13:04:54 UTC
*** Bug 13089 has been marked as a duplicate of this bug. ***
Comment 47 Carlo Wood 2010-12-14 17:29:28 UTC
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.
Comment 48 Carlo Wood 2010-12-14 17:37:12 UTC
Created attachment 40122 [details]
Output of dmesg

Added attachment 'dmesg.out', see comment of 14 December 2010.
Comment 49 Carlo Wood 2010-12-14 17:38:56 UTC
Created attachment 40132 [details]
Output of acpidump

Added attachment 'acpi.out', see comment of 14 December 2010.
Comment 50 Carlo Wood 2010-12-14 17:40:40 UTC
Created attachment 40152 [details]
Output of lspci -vxxx

Added attachment 'lspci.out', see comment of 14 December 2010.
Comment 51 Jean Delvare 2010-12-14 20:16:56 UTC
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.)
Comment 52 Len Brown 2011-01-11 08:32:05 UTC
*** Bug 26342 has been marked as a duplicate of this bug. ***
Comment 53 Florian Mickler 2011-01-22 12:42:32 UTC
commit 106d1a0ab2a354b97df3e232be7dedbfaf8e901d
Author: Thomas Renninger <trenn@suse.de>
Date:   Mon Dec 20 12:11:45 2010 +0100

    ACPI: fix resource check message
Comment 54 Liontos Aristotelis 2011-02-27 00:13:54 UTC
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
Comment 55 Liontos Aristotelis 2011-02-27 00:15:27 UTC
Created attachment 49342 [details]
dmesg
Comment 56 Liontos Aristotelis 2011-02-27 00:15:54 UTC
Created attachment 49352 [details]
lspci -v
Comment 57 Liontos Aristotelis 2011-02-27 00:17:41 UTC
Created attachment 49362 [details]
ioports
Comment 58 Liontos Aristotelis 2011-02-27 00:19:34 UTC
Created attachment 49372 [details]
acpidump
Comment 59 Hans de Goede 2011-02-27 08:51:30 UTC
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