pci 0000:01:00.0: BAR 6: no parent found for of device [0xfffe0000-0xffffffff]

Commit Message

Matthew Wilcox June 24, 2009, 7:50 p.m. UTC

On Wed, Jun 24, 2009 at 09:30:07PM +0200, Rafael J. Wysocki wrote:
> (Adding CC to linux-pci)

Thanks Rafael.

> On Wednesday 24 June 2009, Justin Mattock wrote:
> > (just pulled the latest git)
> > And am seeing this:
> 
> Where pci 0000:01:00.0 and 0000:02:00.0 are what?
> 
> > [    0.696001] pci 0000:01:00.0: BAR 6: no parent found for of device
> > [0xfffe0000-0xffffffff]

So the message is coming from pci_claim_resource, and
if you bother to bisect, you'll track it back to my commit
a76117dfd687ec4be0a9a05214f3009cc5f73a42 .  What's going on here, since
this is BAR 6, is we have a ROM which has been mapped high, and then
not unmapped.  The BAR doesn't fit in the parent's window, so the code
is rightly declining to allocate the BAR.

Before my patch, we silently didn't allocate the BARs.  Now we print
a message.  I wonder what to do ... we could silence this warning in
pci_claim_resource (patch below).  Or we could declare this to be a bug,
and fix it by disabling the ROM BAR (by clearing bit 0).

I'm agnostic ... anyone have any preferences?

----

Silence spurious warning about ROM BARs

We shouldn't warn about not being able to allocate ROM BARs.  They are
often deliberately mapped outside the range of parent windows in order
to disable them.

Also fix the message to delete the spurious 'of'.

Signed-off-by: Matthew Wilcox <[e-mail]>

Comments

Jesse Barnes June 24, 2009, 8:04 p.m. UTC | #1

On Wed, 24 Jun 2009 13:50:30 -0600
Matthew Wilcox <[e-mail]> wrote:

> On Wed, Jun 24, 2009 at 09:30:07PM +0200, Rafael J. Wysocki wrote:
> > (Adding CC to linux-pci)
> 
> Thanks Rafael.
> 
> > On Wednesday 24 June 2009, Justin Mattock wrote:
> > > (just pulled the latest git)
> > > And am seeing this:
> > 
> > Where pci 0000:01:00.0 and 0000:02:00.0 are what?
> > 
> > > [    0.696001] pci 0000:01:00.0: BAR 6: no parent found for of
> > > device [0xfffe0000-0xffffffff]
> 
> So the message is coming from pci_claim_resource, and
> if you bother to bisect, you'll track it back to my commit
> a76117dfd687ec4be0a9a05214f3009cc5f73a42 .  What's going on here,
> since this is BAR 6, is we have a ROM which has been mapped high, and
> then not unmapped.  The BAR doesn't fit in the parent's window, so
> the code is rightly declining to allocate the BAR.
> 
> Before my patch, we silently didn't allocate the BARs.  Now we print
> a message.  I wonder what to do ... we could silence this warning in
> pci_claim_resource (patch below).  Or we could declare this to be a
> bug, and fix it by disabling the ROM BAR (by clearing bit 0).
> 
> I'm agnostic ... anyone have any preferences?

Well, given that sometimes the ROM is important, it seems like an
error.  Really we should be smarter about re-allocating things as
necessary...

Justin P. Mattock June 24, 2009, 8:41 p.m. UTC | #2

On Wed, Jun 24, 2009 at 1:04 PM, Jesse Barnes<[e-mail]> wrote:
> On Wed, 24 Jun 2009 13:50:30 -0600
> Matthew Wilcox <[e-mail]> wrote:
>
>> On Wed, Jun 24, 2009 at 09:30:07PM +0200, Rafael J. Wysocki wrote:
>> > (Adding CC to linux-pci)
>>
>> Thanks Rafael.
>>
>> > On Wednesday 24 June 2009, Justin Mattock wrote:
>> > > (just pulled the latest git)
>> > > And am seeing this:
>> >
>> > Where pci 0000:01:00.0 and 0000:02:00.0 are what?
>> >
>> > > [    0.696001] pci 0000:01:00.0: BAR 6: no parent found for of
>> > > device [0xfffe0000-0xffffffff]
>>
>> So the message is coming from pci_claim_resource, and
>> if you bother to bisect, you'll track it back to my commit
>> a76117dfd687ec4be0a9a05214f3009cc5f73a42 .  What's going on here,
>> since this is BAR 6, is we have a ROM which has been mapped high, and
>> then not unmapped.  The BAR doesn't fit in the parent's window, so
>> the code is rightly declining to allocate the BAR.
>>
>> Before my patch, we silently didn't allocate the BARs.  Now we print
>> a message.  I wonder what to do ... we could silence this warning in
>> pci_claim_resource (patch below).  Or we could declare this to be a
>> bug, and fix it by disabling the ROM BAR (by clearing bit 0).
>>
>> I'm agnostic ... anyone have any preferences?
>
> Well, given that sometimes the ROM is important, it seems like an
> error.  Really we should be smarter about re-allocating things as
> necessary...
>
> --
> Jesse Barnes, Intel Open Source Technology Center
>

I guess the easiest would be to silence the problem,
(but personally I don work that way)
So I opt for the second choice:
we could declare this to be a
bug, and fix it by disabling the ROM BAR (by clearing bit 0).

So If and when, I can test out a patch.

Patch

diff --git a/drivers/pci/setup-res.c b/drivers/pci/setup-res.c
index 1240351..d1b980c 100644
--- a/drivers/pci/setup-res.c
+++ b/drivers/pci/setup-res.c
@@ -109,8 +109,8 @@  int pci_claim_resource(struct pci_dev *dev, int resource)
 	if (root != NULL)
 		err = insert_resource(root, res);
 
-	if (err) {
-		dev_err(&dev->dev, "BAR %d: %s of %s %pR\n",
+	if (err && (resource != 6)) {
+		dev_err(&dev->dev, "BAR %d: %s %s %pR\n",
 			resource,
 			root ? "address space collision on" :
 				"no parent found for",