Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

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

28 views
Skip to first unread message

Justin Mattock

unread,
Jun 24, 2009, 1:30:18 PM6/24/09
to
(just pulled the latest git)
And am seeing this:


[ 0.696001] pci 0000:01:00.0: BAR 6: no parent found for of device
[0xfffe0000-0xffffffff]
[ 0.696010] pci 0000:02:00.0: BAR 6: no parent found for of device
[0xfffe0000-0xffffffff]
[ 0.696069] pci 0000:00:01.0: PCI bridge, secondary bus 0000:01
[ 0.696074] pci 0000:00:01.0: IO window: 0x3000-0x3fff
[ 0.696081] pci 0000:00:01.0: MEM window: 0x50300000-0x503fffff
[ 0.696087] pci 0000:00:01.0: PREFETCH window:
0x00000040000000-0x00000047ffffff
[ 0.696096] pci 0000:00:1c.0: PCI bridge, secondary bus 0000:02
[ 0.696102] pci 0000:00:1c.0: IO window: 0x2000-0x2fff
[ 0.696111] pci 0000:00:1c.0: MEM window: 0x50200000-0x502fffff
[ 0.696118] pci 0000:00:1c.0: PREFETCH window: 0x50500000-0x505fffff
[ 0.696126] pci 0000:00:1c.1: PCI bridge, secondary bus 0000:03
[ 0.696130] pci 0000:00:1c.1: IO window: disabled
[ 0.696138] pci 0000:00:1c.1: MEM window: 0x50100000-0x501fffff
[ 0.696145] pci 0000:00:1c.1: PREFETCH window: disabled
[ 0.696152] pci 0000:00:1c.2: PCI bridge, secondary bus 0000:04
[ 0.696158] pci 0000:00:1c.2: IO window: 0x1000-0x1fff
[ 0.696167] pci 0000:00:1c.2: MEM window: 0x4c100000-0x500fffff
[ 0.696174] pci 0000:00:1c.2: PREFETCH window:
0x00000048000000-0x0000004bffffff
[ 0.696186] pci 0000:00:1e.0: PCI bridge, secondary bus 0000:0c
[ 0.696190] pci 0000:00:1e.0: IO window: disabled
[ 0.696198] pci 0000:00:1e.0: MEM window: 0x4c000000-0x4c0fffff
[ 0.696205] pci 0000:00:1e.0: PREFETCH window: disabled
[ 0.696219] pci 0000:00:01.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
[ 0.696225] pci 0000:00:01.0: setting latency timer to 64
[ 0.696235] pci 0000:00:1c.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17
[ 0.696243] pci 0000:00:1c.0: setting latency timer to 64
[ 0.696254] pci 0000:00:1c.1: PCI INT B -> GSI 16 (level, low) -> IRQ 16
[ 0.696261] pci 0000:00:1c.1: setting latency timer to 64
[ 0.696273] pci 0000:00:1c.2: PCI INT C -> GSI 18 (level, low) -> IRQ 18
[ 0.696280] pci 0000:00:1c.2: setting latency timer to 64
[ 0.696437] pci 0000:00:1e.0: power state changed by ACPI to D0
[ 0.696446] pci 0000:00:1e.0: setting latency timer to 64


Is this good or bad?
(BAR 6: no parent found for of device)

--
Justin P. Mattock
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Rafael J. Wysocki

unread,
Jun 24, 2009, 3:40:11 PM6/24/09
to
(Adding CC to linux-pci)

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?

There may be devices without parents, although the message itself seems to be
broken.

Please send the output of lspci.

Best,
Rafael

Jesse Barnes

unread,
Jun 24, 2009, 3:40:10 PM6/24/09
to

There have been a few changes in this area recently, notably

commit 9e9f46c44e487af0a82eb61b624553e2f7118f5b
Author: Jesse Barnes <jba...@virtuousgeek.org>
Date: Thu Jun 11 10:58:28 2009 -0700

PCI: use ACPI _CRS data by default

and some related to

commit ff54250a0ebab7f90a5f848a0ba63f999830c872
Author: Linus Torvalds <torv...@linux-foundation.org>
Date: Sat Apr 18 21:44:24 2009 -0700

Remove 'recurse into child resources' logic from ...

The first you can control with the nocrs boot param, the other ones
will have to be bisected through though...

--
Jesse Barnes, Intel Open Source Technology Center

Justin Mattock

unread,
Jun 24, 2009, 3:50:07 PM6/24/09
to

output from lspci is:


01:00.0 VGA compatible controller: ATI Technologies Inc M56P [Radeon
Mobility X1600]
02:00.0 Ethernet controller: Marvell Technology Group Ltd. 88E8053
PCI-E Gigabit Ethernet Controller (rev 22)
(if I'm reading this correctly)

I can try nocrs to see if it hides this or fixes this message,
if not I can try the whole bisect thing(not sure If I can since
I just cloned the kernel a few days ago, and didn't put any good
or bad tags on the commit)

As for the system itself, seems fine(except for this
message) been streaming radio without any issues for
a while now.

--
Justin P. Mattock

Matthew Wilcox

unread,
Jun 24, 2009, 4:00:17 PM6/24/09
to
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 <wi...@linux.intel.com>

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",

--
Matthew Wilcox Intel Open Source Technology Centre
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours. We can't possibly take such
a retrograde step."

Jesse Barnes

unread,
Jun 24, 2009, 4:10:13 PM6/24/09
to
On Wed, 24 Jun 2009 13:50:30 -0600
Matthew Wilcox <mat...@wil.cx> 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

Justin Mattock

unread,
Jun 24, 2009, 4:50:16 PM6/24/09
to

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.

--
Justin P. Mattock

0 new messages