From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751357AbdFESoa (ORCPT ); Mon, 5 Jun 2017 14:44:30 -0400 Received: from eggs.gnu.org ([208.118.235.92]:44243 "EHLO eggs.gnu.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751077AbdFESo2 (ORCPT ); Mon, 5 Jun 2017 14:44:28 -0400 From: David Kastrup To: Randy Dunlap Cc: linux-kernel@vger.kernel.org Subject: Re: What would cause /proc/ioports do be zeroed out? References: <8737be3ipn.fsf@fencepost.gnu.org> Date: Mon, 05 Jun 2017 20:44:18 +0200 In-Reply-To: (Randy Dunlap's message of "Mon, 5 Jun 2017 11:25:00 -0700") Message-ID: <87mv9m1dh9.fsf@fencepost.gnu.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Randy Dunlap 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