mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Linus Torvalds <torvalds@linux-foundation.org>
To: Frans Pop <elendil@planet.nl>
Cc: linux-kernel@vger.kernel.org, Yinghai Lu <yinghai@kernel.org>,
	Jesse Barnes <jbarnes@virtuousgeek.org>
Subject: Re: Linux 2.6.31-rc4: strange change in iomem allocation
Date: Thu, 23 Jul 2009 09:12:32 -0700 (PDT)	[thread overview]
Message-ID: <alpine.LFD.2.01.0907230905360.21520@localhost.localdomain> (raw)
In-Reply-To: <200907231653.48933.elendil@planet.nl>



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.
> >
> > The change is also visible in /proc/iomem:
> >  fec00000-fec00fff : IOAPIC 0
> >    fec00000-fec00fff : reserved
> > -    fec00000-fec000ff : pnp 00:0c
> >
> > I somewhat suspect 857fdc53a0a90c3ba7fcf5b1fb4c7a62ae03cf82:
> >     x86/pci: insert ioapic resource before assigning unassigned resources
> 
> Reverting that commit did indeed restore the old situation.

Don't worry about the new warning. 

It is in fact _normal_ to see a number of warnings about PnP resources 
"could not be reserved", because there are a number of sources of 
resources that we trust more than the PnP stuff, so we make the IO 
reservations based on those other sources of information. And then the PnP 
layer comes along, and can't reserve things any more because they are 
already reserved.

So the only thing that changed is that now we moved the APIC reservation 
earlier, exactly because we trust our knowledge of the hardware "more" 
than some other things.

You can google for "could not be reserved" (quotes needed to make it get 
anything relevant, of course), and you'll see a lot of dmesg's. The 
warning is interesting in the sense that _if_ there are any PCI resource 
issues, it hints about the fact that we got resource information from 
different places and they overlapped, so I wouldn't want to remove it.

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.

		Linus

  reply	other threads:[~2009-07-23 16:14 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 [this message]
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       ` [PATCH?] Re: Linux 2.6.31-rc4: strange change in iomem allocation Frans Pop
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=alpine.LFD.2.01.0907230905360.21520@localhost.localdomain \
    --to=torvalds@linux-foundation.org \
    --cc=elendil@planet.nl \
    --cc=jbarnes@virtuousgeek.org \
    --cc=linux-kernel@vger.kernel.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

Powered by JetHome