Bug 12221

Created attachment 19298 [details]
Kernel.log

This is the kernel log, including boot process and errors from modules. In the removed part were only a lot of wlan0 assoc/auth messages.

Created attachment 19299 [details]
output of dmidecode

The linux-thinkpad developer asekd to include this one in the report.

Created attachment 19304 [details]
acpidump output

Also requested to post by the same guy @ linux-thinkpad.

Hi, Bart
    From the acpidump it seems that the 0x1600-0x1641 I/O ports is reserved by the PNP acpi driver for the \_SB.PCI0.LPC.SIO device (the device type is PNP0C02).
    But the thinkpad_ec in tp_smapi module will try to register the 0x1600-0x161F I/O port. As the port is already reserved, the following warning message will be complained.
   >ranger thinkpad_ec: cannot claim io ports 0x1600-0x161f
    
    I don't think that this is an ACPI bug. It is more appropriate that this is fixed in tp_smapi module.
    The tp_smapi module can be found in 
    >http://sourceforge.net/projects/tpctl/
    

Thanks for you answer.
From what I understood of the thread in the linux-thinkpad mailing list, someone thought that it may be a BIOS error, that the BIOS was claiming resources that it didnt need, is this possible?
This seems possible since ignoring the warning makes the module load and do its job...

Hi, Bart
    IMO it is not the BIOS error. BIOS only claims that the 0x1600-0x1641 will be reserved for the \_SB.PCI0.LPC.SIO device(the device type is PNP0C02). The SIO is not a physical device and it can be regarded as one slot of LPC bridge. If the device is connected with LPC brighe through SIO slot, it must confirm that the expected I/O port will fall into the I/O port range of SIO device. If it falls into the I/O port range, it can work well. Otherwise it can't work well.
    
   What you said is right. Maybe this issue can be fixed by that the warning message is ingnored in the tp_smapi module.
    

Hi, Bart
    Will you please try the boot option of "pnpacpi=off" and see whether the tp_smapi module can be loaded successfully?
   thanks.

Hi Yakui,

I booted with the parameter you said and tp_smapi loaded without any message. 

Dmesg:
thinkpad_ec: thinkpad_ec 0.39 loaded.
tp_smapi 0.39 loading...
tp_smapi successfully loaded (smapi_port=0xb2).
hdaps: initial mode latch is 0x05
hdaps: setting ec_rate=250, filter_order=2
hdaps: device successfully initialized.
input: ThinkPad HDAPS joystick emulation as /class/input/input8
input: ThinkPad HDAPS accelerometer data as /class/input/input9
hdaps: driver successfully loaded.

Would you like me to provide any other info?

Hi, Bart
    Thanks for the test. It seems that the tp_smapi module can be loaded successfully if the I/O port range is not reserved for \_SB.PCI0.LPC.SIO.
    From the acpidump it seems that the 0x1600-0x161b I/O port is reserved twice. 
    >ranger system 00:02: ioport range 0x1600-0x1641 has been reserved
    >ranger system 00:02: ioport range 0x1600-0x161b has been reserved
    Maybe this issue is related with that the 0x1600-0x161b is reserved twice.
    Will you please try the custom DSDT and see whether the tp_smapi module can be loaded successfully?
    Thanks.

Created attachment 19305 [details]
try the custom DSDT, in which 0x1600-0x161b I/O port won't be resevered twice

Hi, Bart
   Will you please try the custom DSDT and see whether the tp_smapi module can be loaded successfully?
   In the custom DSDT the 0x1600-0x161b won't be reserved twice again.
   
   How to use the custom DSDT can be found in
   http://www.lesswatts.org/projects/acpi/faq.php

Yakui,

Range 0x1600-0x161f is indeed a device sitting behind the LPC bridge.  It is a Renesas H8S microcontroller (this is the ACPI embedded controller, btw.  These ports are a third communication channel to it used for HDAPS, SBS battery queries, and who knows what else. The other two channels being the standard ACPI EC IO ports and the KDC IO ports to emulate a IBM-PC-style keyboard controller).

BTW, it really is 0x1600-0x161f, only 0x1600-0x161b would leave two very important ports for the communication protocol of the H8S outside of the reservation range.

Looks to me like the proper fix would be to be able to "connect" tp_smapi to the \_SB.PCI0.LPC.SIO bridge, so that it can request resources behind the bridge just like it is done on PCI bridges, etc.   Is that possible?  How?

Also, the BIOS might have incorrect information, that needs to be fixed if possible.  I can deliver ThinkPad BIOS error reports to Lenovo, but I don't know enough about PNP/ACPI resource reservation to prepare a proper report.  If there are any errors in the Lenovo BIOS, please point them out to me explicitly, and I will forward it to them.

Hi, Henrique
    Thanks for the detailed explanation.The 0x1600-0x161F is used by one device behind the LPC bridge. And it is connected with LPC bridge through \_SB.PCI0.LPC.SIO slot.
    
    From the acpidump it seems that this issue is also related with BIOS. The 0x1600-0x161b is declared twice under the scope of \_SB.PCI0.LPC.SIO.
    IO (Decode16,
         0x1600,             // Range Minimum
         0x1600,             // Range Maximum
         0x01,               // Alignment
         0x42,               // Length
        )
    // In such case the 0x1600-0x161b will be reserved twice. So the following should be deleted. Of course it will also be OK if 0x1C is changed to 0x20.
    IO (Decode16,
        0x1600,             // Range Minimum
        0x1600,             // Range Maximum
        0x01,               // Alignment
        0x1C,               // Length
       )

    When PNPacpi is enabled, the 0x1600-1641 & 0x1600-0x161b is reserved for SIO slot. But unfortunately the I/O port range of 0x1600-0x161b is reserved twice. In such case it will fail if the 0x1600-161f I/O port is requested by tp_smapi module. If the duplicated I/O port range can be eliminated in course of reserving I/O port, the issue can also be fixed. But it seems so complex and I have no idea how to fix it.(On this box it can be realized by checking whether the 0x1600-0x161b falls into the 0x1600-0x1641 range. But if 0x1600-0x161b appears before 0x1600-0x1641, it seems too complex.)

    So IMO the better solution is that this issue is fixed by BIOS upgrading. The duplicated I/O port definition had better be deleted in BIOS.

    thanks.    

I will contact Lenovo and request a BIOS fix.  Let's see what happens.

As an interim kludge, in tp_smapi v0.40 (released 2008-12-16), passing the "force_io=1" module parameter to thinkpad_ec will make it ignore a failure in reserving ports 0x1600-0x161f. (If you don't set force_io=1, a failure will printk a message suggesting you set force_io=1.)

Do we have a consensus on what's the best proper solution?

BIOS bugfix request sent to Lenovo.  Let's see what their reply will be.  I sure hope it is not going to be "we can't do it because it will break <something> in Windows"...

IMO, we should at least start detecting such suspect data in the tables and reporting them as warnings (ESPECIALLY in the firmware toolkit) even if nobody is using that IO region.  It always ends up coming back to bite us in the arse later, probably at a time the vendor is not actively developing that BIOS anymore and won't be able to release an update...

I am not in a position to know if we could/should do any sort of coalescing of these IO reservation regions, because I need to study what they are supposed to  mean, first.

Hi, Henrique
    Agree with what you have said. The issue had better be detected and reported as warnings. But it is difficult to realize in linux kernel.(We must sort the IO or mem resource for one PNP device).
    As this is a BIOS bug, it had better be fixed by BIOS upgrading. Of course that thinkpad_ec fails to be loaded can also fixed by the method suggested by Shem. 
    So the bug will be rejected and marked as "WILL_NOT_FIX". 
    Thanks.

The bug will be moved to the category of BIOS.

http://www-307.ibm.com/pc/support/site.wss/document.do?lndocid=MIGR-70353

does not show this bios fix for the T500. Has anyone heard back from Lenovo on it?

It would also be nice if they added 1680x1050 VESA modes in a bios update. Feel free to call them and request both of these. :)

There are BIOS updates on the Lenovo site, at least for the T400...

The changelog is not conclusive.

Bios v2.07 for T400 solved the problem for me, drivers page only mentions v2.03, but clicking the link leads to v2.07 released on 18.03.2009

I suggest T500 and X200 users to check the respective download pages for unmentioned bios updates =)