All of lore.kernel.org
 help / color / mirror / Atom feed
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;
 }

  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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.