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: Fri, 7 Aug 2009 11:40:19 -0700 (PDT) [thread overview]
Message-ID: <alpine.LFD.2.01.0908071116520.3390@localhost.localdomain> (raw)
In-Reply-To: <alpine.LFD.2.01.0908071051300.3390@localhost.localdomain>
On Fri, 7 Aug 2009, Linus Torvalds wrote:
>
> Ok, this is your PCI-PCI bridge to Bus#2, and it has two memory windows:
>
> pci 0000:00:1e.0: transparent bridge
> pci 0000:00:1e.0: bridge io port: [0xd000-0xdfff]
> pci 0000:00:1e.0: bridge 32bit mmio: [0xff600000-0xff6fffff]
> pci 0000:00:1e.0: bridge 32bit mmio pref: [0xdea00000-0xdeafffff]
>
> so I was wrong - that 0xff600000-0xff6fffff is non-prefetchable.
>
> So I'm really not seeing why you then get that
>
> pci 0000:02:03.0: BAR 6: address space collision on of device [0xff680000-0xff69ffff]
>
> because while we've marked the ROM window prefetchable, it should fit
> perfectly fine into a non-prefetchable PCI bus window.
>
> Odd.
Oh, not odd at all.
Just after sending that email, I go "Duh!", and realize what's going on.
So because ROM resources are marked as being prefetchable, we have
pci_find_parent_resource() that _prefers_ a prefetchable window.
So what happens (and now I'm sure) is that
- we call 'pci_find_parent_resource()' with the ROM resource, and it does
see the parent resource that would match:
pci 0000:00:1e.0: bridge 32bit mmio: [0xff600000-0xff6fffff]
but because it's not an _exact_ match (the IORESOURCE_PREFETCH flag
doesn't match), it will just remember that bridge resource as being the
"best seen so far":
if ((res->flags & IORESOURCE_PREFETCH) && !(r->flags & IORESOURCE_PREFETCH))
best = r; /* Approximating prefetchable by non-prefetchable */
- and then, because the bus is transparent, at the end of the bus
resources we'll find the parent resources, which are the whole PCI
address space.
And now it will match things *again* - and set "best" to that
transparent parent resource, even if it's not really any better at all
(the PCI root resource won't be marked prefetchable either, afaik).
- so 'pci_find_parent_resource()' will instead of returning that MMIO
window (0xff600000-0xff6fffff), it will return the PCI root window.
Which technically is correct, since that _is_ a "better" window for
something like that.
- but now we can no longer actually insert the resource directly into
that PCI root window, because the existing address of the preferred ROM
base is already taken (by the PCI bridge window that we'd want to
insert it into!)
- Then, later on, we'll actually assign the ROM address to another area
which is prefetchable (well, except it's not really).
So it all actually makes sense. I see what's going on, and the PCI layer
actually technically does all the right things. Or at least there's not
really anything technically _wrong_ going on. We have multiple
'acceptable' resources, we just picked the wrong one.
Anyway, I think we can fix this by just picking the first 'best' resource.
That said, I suspect that we should actually make 'pci_claim_resource()'
do this loop over parents, so that if there are multiple acceptable
resources, we'd try them all rather than pick one - and then perhaps
failing.
So this patch is not something that I'm going to apply to my tree, but
it's worth testing out to just verify that yes, I finally understand
exactly what's going on. Because if I'm right, your warning will now go
away (and it could be replaced by _other_ issues, of course ;).
Linus
---
drivers/pci/pci.c | 8 ++++++--
1 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index dbd0f94..89efbb5 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -367,8 +367,12 @@ pci_find_parent_resource(const struct pci_dev *dev, struct resource *res)
continue; /* Wrong type */
if (!((res->flags ^ r->flags) & IORESOURCE_PREFETCH))
return r; /* Exact match */
- if ((res->flags & IORESOURCE_PREFETCH) && !(r->flags & IORESOURCE_PREFETCH))
- best = r; /* Approximating prefetchable by non-prefetchable */
+ /* We can't insert a non-prefetch resource inside a prefetchable parent .. */
+ if (r->flags & IORESOURCE_PREFETCH)
+ continue;
+ /* .. but we can put a prefetchable resource inside a non-prefetchable one */
+ if (!best)
+ best = r;
}
return best;
}
next prev parent reply other threads:[~2009-08-07 18:41 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-08-02 14:19 [Regression] PCI resources allocation problem on HP nx6325 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
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 [this message]
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.0908071116520.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;
as well as URLs for NNTP newsgroup(s).