On Mon, 2005-08-29 at 22:03 -0700, Linus Torvalds wrote:
>
> On Tue, 30 Aug 2005, Benjamin Herrenschmidt wrote:
> >
> > So what about fixing pci_map_rom() to call pcibios_resource_to_bus() and
> > then write the resource back to the BAR ? I'm still a bit annoyed that
> > we re-allocate the address while the original one was perfectly good
> > (though not enabled) but the above would work.
>
> I just sent you a patch to try.
>
> Btw, as to the re-allocation of an existing address: most of the PCI layer
> really does try to avoid re-allocating known good addresses. In fact, I
> thought we did so for ROM resources too: at least pci_read_bases() does
> read the ROM base, and saves it off into the resource structure.
>
> We'll end up re-assigning that saved-off-address if there were resource
> clashes, though. And bugs always happen, especially since that code
> doesn't get much testing on x86 (there are almost never any interesting
> rom resources for _any_ device, and apparently the video device which is
> one of the few interesting ones always ends up using the shadow rom thing
> on x86 for the primary card).
>From my experience, we tend to re-allocate a lot more than necessary.
afaik, as soon as we hit a p2p bridge, we just blindly re-allocate
everything in my experience.
I have a lot of cases on ppc64 where calling
pci_assign_unassigned_resources() will simply screw everything up and
lead with a bus in a completely unuseable state, with things half
relocated, conflicting bits, etc... Ok, that was about 2.6.12 timeframe,
I never had time to fully debug that. Part of the problem was some
assumptions about the existence of a prefetchable range in a given
position in the resource array, or the kernel having a different idea
than the firmware on where such things should go.
I'll try to go back to it sooner or later. The problem on macs for
example is that we can't afford to have some devices moved at all (like
the Apple ASIC that contains the interrupt controller etc...). Those
bits are probed & the drivers are setup before we touch the PCI bus,
based on the open firmware device-tree. If we move them around, we are
screwed. There are other issues with the fact that the PCI probe will
temporarily cut access to thsoe devices during BAR sizing or bus
numbering, thus if you take an interrupt at the wrong time, you are
toast.
Finally, on ppc64, we also have the case of partitioned machines where
we aren't allowed to touch some busses at all (and the kernel really
tries to reconfigure p2p bridges all the time).
> If you find the thing that causes us to re-assign the address, holler.
I'll try to find out.
> (See drivers/pci/probe.c: pci_read_bases() for the code that probes the
> old address and saves it into the resource struct. It's called by
> pci_setup_device() from the device scanning routines).
Yes I know that part, I'm not sure yet why it gets reallocated.
I suppose paulus and I need to spend again some serious time on the PCI
code. We have to anyway with the pending merge of ppc32 and ppc64 so it
might be a good opportunity to try again getting the common code in
drivers/pci/setup-* working for us.
Ben.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
| |
 |