Messages in this thread Patch in this message | | | Date | Mon, 24 Apr 2006 10:01:59 -0700 (PDT) | From | Linus Torvalds <> | Subject | Re: PCI ROM resource allocation issue with 2.6.17-rc2 |
| |
On Sun, 23 Apr 2006, Andrew Morton wrote: > > Matthew Reppert <arashi@sacredchao.net> 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |