Message-ID: <8737be3ipn.fsf@fencepost.gnu.org>
Date:   Mon, 05 Jun 2017 11:08:20 +0200
From:   David Kastrup <dak@....org>
To:     linux-kernel@...r.kernel.org
Subject: What would cause /proc/ioports do be zeroed out?


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@...a:~$ 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@...a:~$ 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@...a:~$ 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

Powered by blists - more mailing lists