From: Frans Pop <elendil@planet.nl>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: linux-kernel@vger.kernel.org, Yinghai Lu <yinghai@kernel.org>,
Jesse Barnes <jbarnes@virtuousgeek.org>
Subject: [PATCH?] Re: Linux 2.6.31-rc4: strange change in iomem allocation
Date: Fri, 24 Jul 2009 09:53:47 +0200 [thread overview]
Message-ID: <200907240953.48297.elendil@planet.nl> (raw)
In-Reply-To: <alpine.LFD.2.01.0907230905360.21520@localhost.localdomain>
On Thursday 23 July 2009, Linus Torvalds wrote:
> On Thu, 23 Jul 2009, Frans Pop wrote:
> > On Thursday 23 July 2009, Frans Pop wrote:
> > > I'm seeing the following change in dmesg between -rc3 and -rc4:
> > > -system 00:0c: iomem range 0xfec00000-0xfec000ff has been reserved
> > > +system 00:0c: iomem range 0xfec00000-0xfec000ff could not be reserved
> > >
> > > There is nothing in the earlier part of dmesg that would explain
> > > this change.
> >
> > Reverting that commit did indeed restore the old situation.
>
> So think of it this way: the difference between "has been reserved" and
> "could not be reserved" is _not_ a "good" vs "bad" situation. They are
> both purely informational. They're not good-or-bad, they are
> information we leave around in case bad things happen later.
Yeah, I suspected that might be the case (which is why I used "restores old
situation" rather than "fixes regression" :-). My message was triggered by
the fact that it's still a somewhat unusual change, so I was mainly looking
for confirmation that it was intended.
Still, failure messages can be confusing for users. The source code documents
that reservation failures are expected, but most users don't read source...
So, also looking at David John's message, would something like the patch
below be an option? The result is as follows on my system:
pnp: PnP ACPI init
ACPI: bus type pnp registered
pnp: PnP ACPI: found 14 devices
ACPI: ACPI bus type pnp unregistered
system 00:00: iomem range 0x0-0x9ffff could not be reserved
(The fact that a range could not be reserved is generally harmless.)
system 00:00: iomem range 0xe0000-0xfffff could not be reserved
system 00:00: iomem range 0x100000-0x7e7fffff could not be reserved
system 00:0a: ioport range 0x500-0x55f has been reserved
---
From: Frans Pop <elendil@planet.nl>
Subject: PNP: make explicit that range allocation failures are generally harmless
Signed-off-by: Frans Pop <elendil@planet.nl>
diff --git a/drivers/pnp/system.c b/drivers/pnp/system.c
index 59b9092..72de2a7 100644
--- a/drivers/pnp/system.c
+++ b/drivers/pnp/system.c
@@ -52,6 +52,10 @@ static void reserve_range(struct pnp_dev *dev, resource_size_t
start,
port ? "ioport" : "iomem",
(unsigned long long) start, (unsigned long long) end,
res ? "has been" : "could not be");
+ if (!res)
+ printk_once(KERN_INFO
+ "(The fact that a range could not be reserved "
+ "is generally harmless.)\n");
}
static void reserve_resources_of_dev(struct pnp_dev *dev)
next prev parent reply other threads:[~2009-07-24 5:55 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-07-23 2:44 Linux 2.6.31-rc4 Linus Torvalds
2009-07-23 14:14 ` Linux 2.6.31-rc4: strange change in iomem allocation Frans Pop
2009-07-23 14:42 ` Yinghai Lu
2009-07-23 15:57 ` Jesse Barnes
2009-07-23 14:53 ` Frans Pop
2009-07-23 16:12 ` Linus Torvalds
2009-07-23 16:29 ` Linus Torvalds
2009-07-24 4:34 ` David John
2009-07-24 5:51 ` Kind of like the following. Apply if you feel it is ok to _not_ David John
2009-07-24 7:53 ` Frans Pop [this message]
2009-07-24 6:11 ` [PATCH] Remove Spurious PnP Memory Reserved Warning David John
2009-07-25 7:12 ` David John
2009-07-28 4:06 ` [PATCH v2] " David John
2009-07-28 16:31 ` Jesse Barnes
2009-07-29 6:42 ` David John
2009-08-01 10:56 ` Frans Pop
2009-08-06 21:41 ` Jesse Barnes
2009-07-23 17:21 ` Linux 2.6.31-rc4 Krzysztof Olędzki
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200907240953.48297.elendil@planet.nl \
--to=elendil@planet.nl \
--cc=jbarnes@virtuousgeek.org \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@linux-foundation.org \
--cc=yinghai@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox