Re: PCI ROM resource allocation issue with 2.6.17-rc2

[Linus Torvalds]

On Sun, 23 Apr 2006, Andrew Morton wrote:
>
> Matthew Reppert <arashi@xxxxxxxxxxxxxx> wrote:
> >
> > I've been running 2.6.12-rc2-mm3 for a long time.  Recently I upgraded
> > a bunch of OS packages (Debian unstable), so I thought I may as well
> > upgrade the kernel, too.  I've got a dual-head setup driven by a Radeon
> > 9200 and a Radeon 7000.  When I booted 2.6.17-rc2, X never came up; I
> > got "RADEON: Cannot read V_BIOS" and "RADEON: VIdeo BIOS not detected
> > in PCI space!" for the RADEON 7000, and it eventually gets in a loop of
> > spitting out "RADEON: Idle timed out, resetting engine ... " messages
> > in Xorg.log.  Doing a diff of working and broken logs uncovered that the
> > Radeon 7000's PCI ROM resource area had moved from ff8c000 to c6900000.
> > Once I removed the Radeon 7000 screen from the Xorg config, X came up fine
> > on the one head.  Adding stupid amounts of printks to the PCI subsystem in
> > .17-rc2 uncovered that at some point, the ROM area is discovered to be
> > at ff8c0000, but is later reallocated to c6900000.

The relocation sounds strange (and isn't visible in your dmesg that I can 
see). But it _should_ be perfectly fine: it's moving the ROM from the 
non-prefetchable region of the 00:1e.0 bridge into the prefetchable one. 

I don't see quite why it would do it (yes, ROM's are prefetchable, but the 
old location was _valid_, and I don't see why we didn't re-use it), but it 
_really_ shouldn't matter. 

I would expect some silly interaction with X, as usual. It would be nice 
to see the whole dmesg, especially with the debugging messages - I suspect 
the remapping of the ROM happens only when X starts up, and that your 
dmesg is from just the kernel boot from before that?

But it might be that I just missed it (or that we don't have good debug 
output for that case).

> > I've also got a Promise PDC20268 whose expansion ROM seems to have made a
> > similar move (from ff8f8000 to c6920000), but the ATA devices attached to
> > that controller seem to work fine under 2.6.17-rc2.

Exactly the same deal. It's moved from non-prefetchable to prefetchable.

That said, the PDC202xx driver doesn't even _use_ the ROM resource, so I 
don't see why it bothers to enable it.

You can try this stupid patch to see if it moves the ROM resource back 
into the non-prefetchable region. Maybe it matters even if it shouldn't.

		Linus
---
diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
index a10ed9d..7af4610 100644
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -217,7 +217,7 @@ #endif
 			sz = pci_size(l, sz, (u32)PCI_ROM_ADDRESS_MASK);
 			if (sz) {
 				res->flags = (l & IORESOURCE_ROM_ENABLE) |
-				  IORESOURCE_MEM | IORESOURCE_PREFETCH |
+				  IORESOURCE_MEM | /* IORESOURCE_PREFETCH | */
 				  IORESOURCE_READONLY | IORESOURCE_CACHEABLE;
 				res->start = l & PCI_ROM_ADDRESS_MASK;
 				res->end = res->start + (unsigned long) sz;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/