Bug 12221 - thinkpad_ec fails to load, cannot claim ioports
Summary: thinkpad_ec fails to load, cannot claim ioports
Status: REJECTED WILL_NOT_FIX
Alias: None
Product: ACPI
Classification: Unclassified
Component: BIOS (show other bugs)
Hardware: All Linux
: P1 low
Assignee: ykzhao
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-12-14 07:52 UTC by Bart Polot
Modified: 2009-03-25 20:29 UTC (History)
5 users (show)

See Also:
Kernel Version: 2.6.27.8
Tree: Mainline
Regression: ---


Attachments
Kernel.log (48.57 KB, text/plain)
2008-12-14 07:54 UTC, Bart Polot
Details
output of dmidecode (13.43 KB, text/plain)
2008-12-14 07:56 UTC, Bart Polot
Details
acpidump output (281.26 KB, text/plain)
2008-12-14 15:59 UTC, Bart Polot
Details
try the custom DSDT, in which 0x1600-0x161b I/O port won't be resevered twice (453.90 KB, patch)
2008-12-14 20:43 UTC, ykzhao
Details | Diff

Description Bart Polot 2008-12-14 07:52:38 UTC
Latest working kernel version: None
Earliest failing kernel version: All
Distribution: [Ubuntu, Arch Linux]
Hardware Environment: Lenovo Thinkpads [T400, T500, X200s]
Software Environment: tp_smapi 0.39
Problem Description:
Cannot load HDAPS module from vanilla kernel or tp_smapi one, thinkpad_ec module fails to load with the following error:
- thinkpad_ec: cannot claim io ports 0x1600-0x161f
A linux-thinkpad developer asked to file a bug in the kernel bugzilla for someone to check it:
http://mailman.linux-thinkpad.org/pipermail/linux-thinkpad/2008-November/045358.html
Another person hacked the thinkpad_ec driver to ignore the error and it *seems* to work ok:
http://mailman.linux-thinkpad.org/pipermail/linux-thinkpad/2008-November/045426.html

Steps to reproduce:
Try to load thinkpad_ec or tp_smapi kernel
Comment 1 Bart Polot 2008-12-14 07:54:28 UTC
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.
Comment 2 Bart Polot 2008-12-14 07:56:43 UTC
Created attachment 19299 [details]
output of dmidecode

The linux-thinkpad developer asekd to include this one in the report.
Comment 3 Bart Polot 2008-12-14 15:59:14 UTC
Created attachment 19304 [details]
acpidump output

Also requested to post by the same guy @ linux-thinkpad.
Comment 4 ykzhao 2008-12-14 17:52:48 UTC
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/
    
Comment 5 Bart Polot 2008-12-14 17:59:14 UTC
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...
Comment 6 ykzhao 2008-12-14 19:19:50 UTC
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.
    
Comment 7 ykzhao 2008-12-14 19:20:54 UTC
Hi, Bart
    Will you please try the boot option of "pnpacpi=off" and see whether the tp_smapi module can be loaded successfully?
   thanks.
Comment 8 Bart Polot 2008-12-14 19:59:16 UTC
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?
Comment 9 ykzhao 2008-12-14 20:34:54 UTC
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.
Comment 10 ykzhao 2008-12-14 20:43:31 UTC
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
Comment 11 Henrique de Moraes Holschuh 2008-12-15 03:38:31 UTC
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.
Comment 12 ykzhao 2008-12-15 19:29:08 UTC
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.    
Comment 13 Henrique de Moraes Holschuh 2008-12-16 05:30:49 UTC
I will contact Lenovo and request a BIOS fix.  Let's see what happens.
Comment 14 Shem Multinymous 2008-12-16 07:16:47 UTC
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?
Comment 15 Henrique de Moraes Holschuh 2008-12-16 08:52:44 UTC
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.
Comment 16 ykzhao 2008-12-16 21:20:50 UTC
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.
Comment 17 ykzhao 2008-12-16 21:21:49 UTC
The bug will be moved to the category of BIOS.
Comment 18 Tim Riker 2009-02-20 14:52:31 UTC
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. :)
Comment 19 Henrique de Moraes Holschuh 2009-03-24 18:15:38 UTC
There are BIOS updates on the Lenovo site, at least for the T400...

The changelog is not conclusive.
Comment 20 Karsten König 2009-03-25 20:29:28 UTC
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 =)

Note You need to log in before you can comment on or make changes to this bug.