How serious is this conflict? ACPI: I/O resource... conflicts with region SMBI
 

Maybe I'm not asking "google" the right questions but I haven't been able to get an understanding of what this means and what the potential ramifications are. I finally convinced my boss to go fully-Linux and of course, within hours I was flooded with "come take a look at my machine" calls.

Toshiba laptop A205 -> Debian "Lenny" - 2.6.32-backports kernel (about 2 yrs old)
Toshiba laptop L655 -> Debian "Squeeze" 2.6.32 stock kernel and 2.6.36 compiled kernel (brand new machine)
I've compiled 2.6.36 kernel with settings targeting this machine and just a generic compile of 2.6.36. Conflict remains.

Both have latest BIOS.

Both machines have this in "dmesg":

http://forum.soft32.com/linux/ACPI-r...ict479956.html

It is an acpi versus some other resource deal (may be same as above). It could cause a crash. The fix may be to look at the other device and acpi both in bios and in software drivers.

Thank you for the reply. I've seen that thread and I've tried to "register" there to get help but kept getting "connection to server timeout". After about 4 days of trying (cookies on/off, etc...), I decided to start this one.

lspci shows that resource as: SMBus: Intel Corp 5 series / 3400 Series Chipset SMBus Controler. The rest of the hardware also shows "Intel Corp 5 Series / 3400 Series... PCI express controller, USB controller, SATA controller, etc..." . So is that all controlled by one driver or do I need to find the "SMBus" driver specifically. And I'm not sure what to do about it / look for in BIOS.

I just found something else: dmesg | grep ACPI . There is a line saying "If ACPI driver is available... you should use it instead of the native driver"

lspci -nnk - lists various "kernel drivers in use" but SMBus doesn't list a driver. But then "PCI bridge" doesn't list any drivers in use either but there are no errors for that hardware. Am I at least looking it the right place? Thank you.

Well, lets do some tests then. How about we boot to some other live cd and see what happens. Use maybe Fedora.

My guess is many bios will allow some changes. Don't just yet until we see how fedora see's them.

That's actually the first thing I did, is to see how other distros/kernels see it and update all BIOS. So... (all latest stable releases)

Fedora -> same conflict
OpenSuse -> same conflict and more
Kubuntu -> same conflict

Plus I just found 2 more laptops (different models) with same conflict. All Toshibas and all same "resource" 0000:00:1f.3 conflict. I really appreciate you trying to help.

Hi - a few more links that might help:

http://seehuhn.de/pages/toshiba

http://lkml.indiana.edu/hypermail/li...3.3/00014.html

http://tldp.org/HOWTO/ACPI-HOWTO/

http://www.spinics.net/lists/linux-acpi/msg30207.html

Q: Is this warning actually causing any problems, or are you just worried about it?

Q: Have you considered building your generic kernel with this option:
"acpi_enforce_resources=lax"

Also look at bios choices. Do they offer acpi versions? Does it allow any resources to be changed?

I now have 11 office machines (all Toshibas) with this exact error. No other errors. Reports of "issues" are:

1) Login manager fails to start and drops to a shell. Reboot and it's fine. Sometimes, it drops to a shell 2-3 consecutive times, reboot and then fine.

2) Once logged in, lots of crashes (although I believe these are KDE issues (example: can watch "youtube" in the small window but clicking the "full screen" button locks up the system. Reproducible every time. Unable to "kill" processes, ctrl+alt+bckspace no longer logs out (KDE4),etc...). So they do a hard power-off

3) Several reports of empty folders disapearing on next login. I've tested it. Make 3 folders, put files into one and reboot. The two empty are gone. Re-create the other two, put files into second one, reboot and third (empty) folder is gone. This happened on several machines. Unable to reproduce at will, though. Sometimes it's fine.

So... everyone blames it on the ACPI conflict issue (and me :( ).


I've read a bunch on this option and most of the threads are by kernel developers and beyond my understanding. What, exactly are the ramifications of building a kernel with this option?

The systems have a plane-jane Phoenix BIOS and unless I'm missing something, or not looking at the right items, there isn't much to be changed in there.

I have, however, confirmed that this hardware (0000:00:1f.3) conflict is regarding the i801_smbus. And I have run into a system which HAS the i801_smbus but DOES NOT have the conflict.

Where would I start looking to see why this one system does not have the conflict so I can maybe apply it to all the rest that do?

Thank you for the help

Well, seems that the OS knows there is a problem to begin with. I would suspect that some problem may exist but from other posts they say no.

"This error message means that the kernel has automatically resolved the
conflict by preventing the i801_smbus (native) driver from using the
IO-ports which are also used by the BIOS. So far as I can see, no
damage will be done."

From here http://www.linuxquestions.org/questi...nflict-841730/

Thank you so much for the info and that link. paulsm4 make it clear (in... umm... no uncertain terms :) ) that the message is "benign".