From: Linus Torvalds <torvalds@linux-foundation.org>
To: Manuel Lauss <mano@roarinelk.homelinux.net>
Cc: "Rafael J. Wysocki" <rjw@sisk.pl>,
Matthew Wilcox <willy@linux.intel.com>,
LKML <linux-kernel@vger.kernel.org>,
Linux PCI <linux-pci@vger.kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
Andrew Patterson <andrew.patterson@hp.com>
Subject: Re: [Regression] PCI resources allocation problem on HP nx6325
Date: Wed, 5 Aug 2009 09:25:23 -0700 (PDT) [thread overview]
Message-ID: <alpine.LFD.2.01.0908050902300.3390@localhost.localdomain> (raw)
In-Reply-To: <20090805155102.GA31646@roarinelk.homelinux.net>
On Wed, 5 Aug 2009, Manuel Lauss wrote:
>
> On Tue, Aug 04, 2009 at 04:04:16PM -0700, Linus Torvalds wrote:
> >
> > So I _think_ that you actually are getting the same layout as with 2.6.30,
> > but with a warning that didn't exist in 2.6.30. Can you verify?
>
> You're absolutely correct: /proc/iomem on 2.6.30 and 31-rc5+ are identical,
> the only difference being 2.6.30 not complaining about any collisions.
Ok.
So this is not a regression per se.
The warning looks a bit annoying, but in fact I believe that the warning
is correct, and is showing us a real problem. Well, not "problem" exactly,
but an issue.
I think that what is happening is that pci_find_parent_resource() may be
in fact finding another parent resource than the one we strictly want (the
pre-existing one).
And I think it's brought on by the fact that this is a ROM resource.
I bet that what is happening is:
- the PCI bridge has a _prefetchable_ bus resource window at
ff600000-ff6fffff : PCI Bus 0000:02
- the PCI bridge is a transparent bridge
- the BIOS has set up the ROM (BAR 6) at
ff680000-ff69ffff : 0000:02:03.0
- We have for some reason marked the ROM as being non-prefetchable.
and what happens is:
- pci_find_parent_resource() refuses to use the ff600000-ff6fffff PCI
bridge resource, because it is marked IORESOURCE_PREFETCH, and the ROM
resource is not so marked.
- But because it's a transparent bridge, once we've iterated over the
bridge window resources, we have a couple of resources that point back
to the parent of the bridge - the PCI root resources.
So now pci_find_parent_resource() will return that instead
- request_resource() will (correctly) notice that the root resource
already has other resources at that address (the PCI brige window!) and
will refuse to insert it - leading us to re-allocating the
BIOS-provided resource later (to the non-prefetchable bus window)
- but when we for a short while (incorrectly) used 'insert_resource()' in
pci_claim_resource(), it would recurse back into the prefetchable
window, and everything would work - because a ROM resource is actually
perfectly happy to be in a prefetchable window.
So I think I understand the behavior on your box, and the warning was
actually correct and useful - our PCI layer is being stupid. We should
mark ROM resources as being prefetchable.
Hmm.. We do seem to _try_ do exactly that in pci_read_bases(). I wonder
what I'm missing, and where that bit is then cleared. Or whether we're
doing that ROM BAR probe somewhere else too..
Linus
next prev parent reply other threads:[~2009-08-05 16:27 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-08-02 14:19 Rafael J. Wysocki
2009-08-02 16:39 ` Linus Torvalds
2009-08-02 17:15 ` Matthew Wilcox
2009-08-02 17:19 ` Linus Torvalds
2009-08-02 17:25 ` Matthew Wilcox
2009-08-02 20:16 ` Rafael J. Wysocki
2009-08-02 21:14 ` Linus Torvalds
2009-08-03 3:10 ` Andrew Patterson
2009-08-03 21:14 ` Andrew Patterson
2009-08-03 16:59 ` Manuel Lauss
2009-08-04 23:04 ` Linus Torvalds
2009-08-05 15:51 ` Manuel Lauss
2009-08-05 16:25 ` Linus Torvalds [this message]
2009-08-05 16:38 ` Linus Torvalds
2009-08-05 17:09 ` Manuel Lauss
2009-08-07 18:15 ` Linus Torvalds
2009-08-07 18:40 ` Linus Torvalds
2009-08-11 16:47 ` Manuel Lauss
2009-08-13 18:16 ` Linus Torvalds
2009-08-13 19:28 ` Frans Pop
2009-08-13 19:46 ` Linus Torvalds
2009-08-13 20:35 ` Frans Pop
2009-08-14 1:40 ` PCI resources allocation problem on Toshiba Satellite A40 Frans Pop
2009-08-14 1:47 ` Linus Torvalds
2009-08-14 16:50 ` Frans Pop
2009-08-14 17:04 ` Linus Torvalds
2009-08-14 17:35 ` Frans Pop
2009-08-02 16:59 ` [Regression] PCI resources allocation problem on HP nx6325 Matthew Wilcox
2009-08-02 20:18 ` Rafael J. Wysocki
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.0908050902300.3390@localhost.localdomain \
--to=torvalds@linux-foundation.org \
--cc=akpm@linux-foundation.org \
--cc=andrew.patterson@hp.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=mano@roarinelk.homelinux.net \
--cc=rjw@sisk.pl \
--cc=willy@linux.intel.com \
/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
all inboxes | Powered by JetHome®