What would cause /proc/ioports do be zeroed out?

What would cause /proc/ioports do be zeroed out?

[David Kastrup]

Hi,

I am trying to pinpoint a problem I am having with current Ubuntu
Artful, likely after some recent attempts of getting rid of some package
incompatibilities.  More likely than not the ultimate culprit is
somewhere in the Debian package management, however I am really puzzled
at figuring out where exactly things go wrong and since my current
configuration is "valid" according to the package manager, it might help
in other situations if I manage to get the problem located.

The current symptom is that I cannot load some ACPI modules (compiled
via DKMS for x86_64 architecture) without io_force option, with the
kernel stating:

[  248.145348] thinkpad_ec: cannot claim IO ports 0x1600-0x161f... 
[  248.145350] consider using force_io=1.

Now here is the really fishy thing:

cat /proc/ioports
0000-0000 : PCI Bus 0000:00
  0000-0000 : dma1
  0000-0000 : pic1
  0000-0000 : timer0
  0000-0000 : smapi
  0000-0000 : timer1
  0000-0000 : keyboard
  0000-0000 : PNP0800:00
  0000-0000 : PNP0C09:00
    0000-0000 : EC data
  0000-0000 : keyboard
  0000-0000 : PNP0C09:00
    0000-0000 : EC cmd

[...]

  0000-0000 : PCI Bus 0000:0d
  0000-0000 : PCI Bus 0000:15
    0000-0000 : PCI CardBus 0000:16
    0000-0000 : PCI CardBus 0000:16

Cough, cough.  Now I am somewhat sure that my problem is related to a
combination of 32 and 64 bit environments: I am working mainly with an
i386 userland (which saves disk space and is what I am mostly compiling
and testing for) while running a 64 bit kernel (in order to have the
possibility of compiling and running and debugging 64 bit executables).

As a consequence, my normal apt-get architecture is i386.

My current setup involves the packages

dak@lola:~$ dpkg -l linux-image-lowlatency linux-tools-lowlatency
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name                                   Version                  Architecture             Description
+++-======================================-========================-========================-=================================================================================
ii  linux-image-lowlatency:amd64           4.10.0.22.24             amd64                    lowlatency Linux kernel image
ii  linux-tools-lowlatency                 4.10.0.22.24             i386                     lowlatency Linux kernel tools

I strongly suspect this combination to be involved.  However, replacing
linux-tools-lowlatency with an amd64 version (which I think I had a
month ago or so) would appear to come with lots of trouble:

dak@lola:~$ sudo apt-get install linux-tools-lowlatency:amd64
[sudo] password for dak: 
Reading package lists... Done
Building dependency tree       
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 linux-tools-lowlatency:amd64 : Depends: linux-tools-4.10.0-22-lowlatency:amd64 but it is not going to be installed
E: Unable to correct problems, you have held broken packages.

If I now add all of the "is not going to be installed" problems, I
arrive at

dak@lola:~$ sudo apt-get install linux-tools-lowlatency:amd64 linux-tools-4.10.0-22-lowlatency:amd64 linux-tools-4.10.0-22:amd64 binutils:amd64
Reading package lists... Done
Building dependency tree       
Reading state information... Done
The following packages were automatically installed and are no longer required:
  cpp-5 fakeroot gcc-5-doc intltool-debian lib64asan2 lib64asan3 lib64atomic1 lib64cilkrts5 lib64gcc-5-dev lib64gcc-6-dev lib64gomp1 lib64itm1 lib64mpx0 lib64mpx2
  lib64quadmath0 lib64stdc++-5-dev lib64stdc++-6-dev lib64ubsan0 libapt-pkg-perl libarchive-zip-perl libautodie-perl libc6-dev-amd64 libc6-dev-x32 libclang-common-3.8-dev
  libclang-common-3.9-dev libclang1-3.8 libclang1-3.9 libdatrie-dev libexporter-tiny-perl libfakeroot libfile-stripnondeterminism-perl libgfortran-5-dev libio-pty-perl
  libipc-run-perl libjsoncpp1 liblist-moreutils-perl libllvm3.8 libllvm3.9 libmodule-pluggable-perl libperlio-gzip-perl libtext-levenshtein-perl libthai-dev libx32asan2
  libx32asan3 libx32atomic1 libx32cilkrts5 libx32gcc-5-dev libx32gcc-6-dev libx32gomp1 libx32itm1 libx32quadmath0 libx32stdc++-5-dev libx32stdc++-6-dev libx32ubsan0 llvm-4.0
  llvm-4.0-dev llvm-4.0-runtime module-assistant patchutils po-debconf
Use 'sudo apt autoremove' to remove them.
The following additional packages will be installed:
  libunwind8:amd64
Suggested packages:
  binutils-doc:amd64
The following packages will be REMOVED:
  binutils binutils-multiarch clang clang-3.8 clang-3.9 clang-4.0 debhelper dh-autoreconf dh-strip-nondeterminism dkms dpkg-dev equivs g++ g++-5 g++-5-multilib g++-6
  g++-6-multilib g++-multilib gcc gcc-5 gcc-5-multilib gcc-6 gcc-6-multilib gcc-multilib gfortran-5 libalien-wxwidgets-perl libm17n-dev libtool libunwind8 libwx-perl lintian
  linux-tools-4.10.0-21 linux-tools-4.10.0-21-lowlatency linux-tools-4.10.0-22 linux-tools-4.10.0-22-lowlatency linux-tools-lowlatency tp-smapi-dkms tp-smapi-source
  unifont-bin
The following NEW packages will be installed:
  binutils:amd64 libunwind8:amd64 linux-tools-4.10.0-22:amd64 linux-tools-4.10.0-22-lowlatency:amd64 linux-tools-lowlatency:amd64
0 upgraded, 5 newly installed, 39 to remove and 0 not upgraded.
Need to get 3,513 kB of archives.
After this operation, 633 MB disk space will be freed.
Do you want to continue? [Y/n] 

This seems way overkill.  I likely can reinstall all of the removed
packages as amd64 executables but that seems a bit overdoing it.  In
addition, the current setup is not flagged as bad in any way but seems
to suffer from not being able to recognize used IO ports properly, via
some kernel tools and/or /proc/ioports .

I suspect the problem to not actually be right in kernel category but a
proper diagnosis likely requires some knowhow of how the kernel and the
tools around it manage talking about IO ports.

Thanks for any pointers for how to go from here.

-- 
David Kastrup

Re: What would cause /proc/ioports do be zeroed out?

[Randy Dunlap]

On 06/05/17 02:08, David Kastrup wrote:
> 
> Hi,
> 
> I am trying to pinpoint a problem I am having with current Ubuntu
> Artful, likely after some recent attempts of getting rid of some package
> incompatibilities.  More likely than not the ultimate culprit is
> somewhere in the Debian package management, however I am really puzzled
> at figuring out where exactly things go wrong and since my current
> configuration is "valid" according to the package manager, it might help
> in other situations if I manage to get the problem located.
> 
> The current symptom is that I cannot load some ACPI modules (compiled
> via DKMS for x86_64 architecture) without io_force option, with the
> kernel stating:
> 
> [  248.145348] thinkpad_ec: cannot claim IO ports 0x1600-0x161f... 
> [  248.145350] consider using force_io=1.
> 
> Now here is the really fishy thing:
> 
> cat /proc/ioports
> 0000-0000 : PCI Bus 0000:00
>   0000-0000 : dma1
>   0000-0000 : pic1
>   0000-0000 : timer0
>   0000-0000 : smapi
>   0000-0000 : timer1
>   0000-0000 : keyboard
>   0000-0000 : PNP0800:00
>   0000-0000 : PNP0C09:00
>     0000-0000 : EC data
>   0000-0000 : keyboard
>   0000-0000 : PNP0C09:00
>     0000-0000 : EC cmd
> 
> [...]
> 
>   0000-0000 : PCI Bus 0000:0d
>   0000-0000 : PCI Bus 0000:15
>     0000-0000 : PCI CardBus 0000:16
>     0000-0000 : PCI CardBus 0000:16

Hi,

Does /proc/iomem show the same thing (i.e., zeros)?

How about if you do the test while logged in as root?


-- 
~Randy

Re: What would cause /proc/ioports do be zeroed out?

[David Kastrup]

Randy Dunlap <rdunlap@infradead.org> writes:

> On 06/05/17 02:08, David Kastrup wrote:
>> 
>> Hi,
>> 
>> I am trying to pinpoint a problem I am having with current Ubuntu
>> Artful, likely after some recent attempts of getting rid of some package
>> incompatibilities.  More likely than not the ultimate culprit is
>> somewhere in the Debian package management, however I am really puzzled
>> at figuring out where exactly things go wrong and since my current
>> configuration is "valid" according to the package manager, it might help
>> in other situations if I manage to get the problem located.
>> 
>> The current symptom is that I cannot load some ACPI modules (compiled
>> via DKMS for x86_64 architecture) without io_force option, with the
>> kernel stating:
>> 
>> [  248.145348] thinkpad_ec: cannot claim IO ports 0x1600-0x161f... 
>> [  248.145350] consider using force_io=1.
>> 
>> Now here is the really fishy thing:
>> 
>> cat /proc/ioports
>> 0000-0000 : PCI Bus 0000:00
>>   0000-0000 : dma1
>>   0000-0000 : pic1
>>   0000-0000 : timer0
>>   0000-0000 : smapi
>>   0000-0000 : timer1
>>   0000-0000 : keyboard
>>   0000-0000 : PNP0800:00
>>   0000-0000 : PNP0C09:00
>>     0000-0000 : EC data
>>   0000-0000 : keyboard
>>   0000-0000 : PNP0C09:00
>>     0000-0000 : EC cmd
>> 
>> [...]
>> 
>>   0000-0000 : PCI Bus 0000:0d
>>   0000-0000 : PCI Bus 0000:15
>>     0000-0000 : PCI CardBus 0000:16
>>     0000-0000 : PCI CardBus 0000:16
>
> Hi,
>
> Does /proc/iomem show the same thing (i.e., zeros)?

Yes.

> How about if you do the test while logged in as root?

Darn it.  Everything looks normal then in either case.  So the /proc
thing likely is a red herring: something else regarding the io ports is
problematic with loading the thinkpad_ec module.  Sorry for that bit: I
remember the information being valid even for normal users.

I have another computer with a Mate 17.04 distribution that is complete
64bit including userland.  It also masks the ioports like this as
non-root user and does not have the thinkpad_ec loading problem.

So yes: /proc is a red herring.  That already helps.

The kernel versions on both computers are different, but yet I really
suspect that the recent "normalization" of linux-tools (which were
pinned to a non-upgradable amd64 version previously) and binutils to the
32bit versions may be involved.

I may have to install a whole lot of toolchain as amd64 to check for
this angle.  Which is unpretty since it makes the system less
representative for 32bit development.

-- 
David Kastrup

Re: What would cause /proc/ioports do be zeroed out?

[David Kastrup]

David Kastrup <dak@gnu.org> writes:

> Randy Dunlap <rdunlap@infradead.org> writes:
>
>> On 06/05/17 02:08, David Kastrup wrote:
>>> 
>>> The current symptom is that I cannot load some ACPI modules (compiled
>>> via DKMS for x86_64 architecture) without io_force option, with the
>>> kernel stating:
>>> 
>>> [  248.145348] thinkpad_ec: cannot claim IO ports 0x1600-0x161f... 
>>> [  248.145350] consider using force_io=1.
>>> 
>>> Now here is the really fishy thing:
>>> 
>>> cat /proc/ioports
>>> 0000-0000 : PCI Bus 0000:00
>>>   0000-0000 : dma1
>>
>> Does /proc/iomem show the same thing (i.e., zeros)?
>
> Yes.
>
>> How about if you do the test while logged in as root?
>
> Darn it.  Everything looks normal then in either case.  So the /proc
> thing likely is a red herring:

> I have another computer with a Mate 17.04 distribution that is
> complete 64bit including userland.  It also masks the ioports like
> this as non-root user and does not have the thinkpad_ec loading
> problem.

Bah.  Once I can see the assigned ports, the ports complained about are
for the acceleration sensors.  And once I install hdapsd (the daemon
acting on acceleration sensors) on that second computer, the same error
occurs.  So it has nothing at all to do with package management or 64/32
bits.

And uninstalling hdapsd on my primary computer also solves the problem
(as does setting the force_io option in
/etc/modprobe.d/thinkpad_ec.conf).

So lots of red herrings here.  I just don't know why I started seeing
this problem recently.  But I am not likely to find out.

So I removed the hdapsd package.  Not sure whether the thinkpad_ec
module from tp-smapi-dkms replaces it: at least it accesses the same
ports.

So it's really some problem specific to modules and functionality tied
into my hardware rather than some general kernel functionality.

Sorry for the noise.

-- 
David Kastrup