ACPI - I/O resource ... conflicts with ACPI ...

[TaoTePuh]

I have problems with ACPI on 2 notebooks. As far as I can remember, these problems came with the installation of the extensions Xorg-7.5 and Xorg-7.5-3d.

I get the following error messages during startup :

Toshiba Satellite M60-139 :

Code: [Select]

ACPI: I/O resource 0000:00:1f.3 [0x20a0-0x20bf] conflicts with ACPI region SMBI [0x20a0-0x20af]
Acer Travelmate 739tl:

Code: [Select]

ACPI: I/O resource piix4_smbus [0xf100-0xf107] conflicts with ACPI region SMB6 [0xf106-0xf106]
As a result, the notebooks are unstable (e.g. networking, samba shares).

Since the error messages telling me nothing, I have set the bootcode "acpi=off". This setting allows the computer to run stable - but I miss the ACPI functionality ...

[TaoTePuh]

No one can help me solve the problem?

[Rich]

Hi TaoTePuh
Maybe  acpi_enforce_resources=lax  might help?

[TaoTePuh]

This has unfortunately not helped :

Code: [Select]

ACPI: I/O resource 0000:00:1f.3 [0x20a0-0x20bf] conflicts with ACPI region SMBI [0x20a0-0x20af]
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


[Rich]

Hi TaoTePuh
I did a little bit of googling and probably found the same stuff as you. Threads on other newsgroups
marked solved by saying it's a harmless warning, and talk about buggy DSDT's. Unless you want to try
playing with the 2 dozen ACPI boot codes I think you might just have to settle for stable with no ACPI.

[TaoTePuh]

Thanks, Rich, for taking the (google-)time.

I tested some ACPI boot codes before this thread. Unfortunately, all without success.

But now, I have news ...

I have drawn my attention to the line before the error message :

Code: [Select]

i801_smbus 0000:00:1f.3: PCI INT B -> GSI 19 (level, low) -> IRQ 19

I found out, that this is generated when loading the i2c_i801 kernel module. After blacklisting this module by boot code (blacklist=i2c_i801), the error is gone.

Okay, but now I am faced with the choice: ACPI or i2c_i801?

Frankly, I do not know both ...

I've read, that you need i2c for e.g. lm_sensors - but anyway lm_sensors finds no sensors in my notebook:

Code: [Select]

tc@box:~$ sudo sensors-detect
...
...
...
Sorry, no sensors were detected.
This is relatively common on laptops, where thermal management is handled by ACPI rather than the OS.
I do not even know if there is a i2c bus is in my notebook ... but I'm assuming that the module is loaded only if there is such a bus ...

On the other hand, I can not turn off (remotely) the notebook without ACPI.

Therefore I tend to turn i2c off. Is this dangerous?

[Rich]

Hi TaoTePuh
Read this link, it look like the same problem, the cause, and the cure if you are comfortable changing
the ACPI DSDT.
http://www.debianhelp.org/node/6761

[EDIT]: If you decide to attempt to modify your ACPI DSDT the iasl.tcz and dmidecode.tcz packages
           may come in handy.

[curaga]

Therefore I tend to turn i2c off. Is this dangerous?

Nope. You just won't have sensor & fan readings and the like; since sensors-detect doesn't detect any, it's no loss. Keep in mind that the i2c modules aren't included in the base, and we haven't had a single exploding laptop or dead hamster yet.

[TaoTePuh]

... hahaha ... Okay, I give up ...

Hi TaoTePuh
Read this link, it look like the same problem, the cause, and the cure if you are comfortable changing
the ACPI DSDT.
http://www.debianhelp.org/node/6761

I have read a lot and learned, then I followed the instructions in http://forums.gentoo.org/viewtopic.php?t=122145 .

After dumping the current DSDT, disassembling, editing and recompiling - I now have a new DSDT, but I do not feel able to integrate this into TC. As far as I understand it, I have to patch the kernel and recompile ... this is too much for me.

I will probably have to live with a system without i2c ...

But anyway: Thanks for the tips and greetings to the hamsters!

[tinypoodle]

In the past I had noticed (not particular to TC) that with some configurations poweroff would work fine when avoiding to boot in framebuffer mode.

[TaoTePuh]

The completeness sake, these are the steps to check your own DSDT (Differentiated System Description Table) for ACPI Problems. It takes less than 1 min and is completely safe, because nothing is changed.

Overview (details below) :

• Dump the current DSDT to a file.
• Disassemble the DSDT.
• Recompile the DSDT.

If your DSDT is buggy, then you'll see some errors and/or warnings when you recompile.

These are the steps in detail :

Code: [Select]

# Load the iasl extension (Intel asl compiler)
tce-load -wi iasl.tcz

# Create a temp dir and change to it.
mkdir /tmp/dsdt
cd /tmp/dsdt

# Dump the current DSDT to a file.
sudo cat /proc/acpi/dsdt > dsdt.dat

# Disassemble the DSDT.
# This creates the file dsdt.dsl
iasl -d dsdt.dat

# At this point you can edit your DSDT (dsdt.dsl)
# ...

# Recompile the DSDT.
# This creates the files dsdt.aml and dsdt.hex
# If your DSDT is buggy, then you'll see some errors
# and/or warnings when you recompile.
iasl -tc dsdt.dsl


I e.g. have 2 errors:

Code: [Select]

tc@box:/tmp/dsdt$ iasl -tc dsdt.dsl

Intel ACPI Component Architecture
ASL Optimizing Compiler version 20090903 [Sep 29 2009]
Copyright (C) 2000 - 2009 Intel Corporation
Supports ACPI Specification Revision 4.0

dsdt.dsl  3964:                     Field (ECRM, AnyAcc, Lock, Preserve)
Error    4075 -                               ^ Host Operation Region requires ByteAcc access

dsdt.dsl  4192:                         Return (Local1)
Error    4050 -                                      ^ Method local variable is not initialized (Local1)

ASL Input:  dsdt.dsl - 5533 lines, 189400 bytes, 2070 keywords
Compilation complete. 2 Errors, 0 Warnings, 0 Remarks, 676 Optimizations

After fixing them in dsdt.dsl and recompiling again:

Code: [Select]

tc@box:/tmp/dsdt$ iasl -tc dsdt.dsl

Intel ACPI Component Architecture
ASL Optimizing Compiler version 20090903 [Sep 29 2009]
Copyright (C) 2000 - 2009 Intel Corporation
Supports ACPI Specification Revision 4.0

ASL Input:  dsdt.dsl - 5534 lines, 189446 bytes, 2071 keywords
AML Output: dsdt.aml - 18455 bytes, 559 named objects, 1512 executable opcodes

Compilation complete. 0 Errors, 0 Warnings, 0 Remarks, 677 Optimizations

I get the two new DSDT files (.aml and .hex).

Unfortunately, it is very difficult to make these new DSDT known to the system ... see above ...

[TaoTePuh]

Another Review :

DSDT
After I read more I know:
Nowadays it is unusual to edit the DSDT (there is a risk to damage the hardware). Relying instead on the kernel can deal with a buggy DSDT. Therefore, it is cumbersome to insert a new DSDT to the system (you have to create for each new DSDT a new kernel). I've tried that and it will work, but actually it has not helped me (the ACPI problems on my system are obviously too large).

Those who want to know more (Overriding a DSDT), I recommend the following:

• Kernel documentation (Documentation/acpi)
• http://www.lesswatts.org/projects/acpi/overridingDSDT.php

A new approach: kernel configuration
I have built several kernel and found, that there is one (ACPI) option which influence the function of my system: CONFIG_ACPI_PROCESSOR. An original TC kernel without this Option, works fine for me.

As described above, i had problems with networking (e.g. I had errors and drops when copying from/to a share) if ACPI was on. With the new kernel, this problems are gone.

So I'm happy now!

But I wonder why this (processor) option impacts on the networking ...

[tinypoodle]

In this case perhaps current

Code: [Select]

CONFIG_ACPI_PROCESSOR=ycould then be considered to be changed to 'm' for config of future kernels, so a module could be blacklisted in case of issues.

[TaoTePuh]

In this case perhaps current

Code: [Select]

CONFIG_ACPI_PROCESSOR=ycould then be considered to be changed to 'm' for config of future kernels, so a module could be blacklisted in case of issues.

I have just tried this. As expected, I had the same errors with this kernel when I tried networking. But if I boot this kernel with "blacklist=processor", I get no (network) errors.

[tinypoodle]

QED