On Sat, 2010-02-20 at 21:18 +0900, Yoichi Yuasa wrote: > Hi Ralf, > > On Sat, 20 Feb 2010 12:31:34 +0100 > Ralf Baechle <ralf@xxxxxxxxxxxxxx> wrote: > > > Below 9f7670e4ddd940d95e48997c2da51614e5fde2cf, an old hack which I > > committed in December '07 I think mostly for Cobalt machines. This is > > now getting in the way - in fact the whole loop in > > pcibios_fixup_device_resources() may have to go. So I wonder if this > > old hack is still necessary. Only testing can answer so I'm going to > > put a patch to revert this into the -queue tree for 2.6.34. > > It is still necessary for Cobalt. > I got the following IDE resource errors. > > pata_via 0000:00:09.1: BAR 0: can't reserve [io 0xf00001f0-0xf00001f7] > pata_via 0000:00:09.1: failed to request/iomap BARs for port 0 (errno=-16) > pata_via 0000:00:09.1: BAR 2: can't reserve [io 0xf0000170-0xf0000177] > pata_via 0000:00:09.1: failed to request/iomap BARs for port 1 (errno=-16) > pata_via 0000:00:09.1: no available native port Thanks for trying that out. I'd like to understand the PCI architecture of Cobalt better. Would you mind turning on CONFIG_PCI_DEBUG and posting the dmesg log? The purpose of IORESOURCE_PCI_FIXED is to say that we shouldn't reassign the device resources. But the pcibios_fixup_device_resources() loop isn't *moving* devices, it's merely converting PCI bus addresses to CPU addresses. So I suspect that the IORESOURCE_PCI_FIXED test there is merely covering up another bug. For example, maybe 00:09.1 is an internal device that's behind a different host bridge that does no address conversion, or maybe the host bridge just handles that device specially. If something like that is happening, pcibios_bus_to_resource() should be broken for that device, and fixing that should allow us to remove the IORESOURCE_PCI_FIXED test. Bjorn
