On Fri, May 24, 2013 at 11:13:41AM -0600, Bjorn Helgaas wrote: > On Thu, May 23, 2013 at 8:54 PM, Kevin Hao <haokexin@xxxxxxxxx> wrote: > > On Thu, May 23, 2013 at 02:22:58PM -0600, Bjorn Helgaas wrote: > >> On Sat, May 18, 2013 at 8:24 PM, Kevin Hao <haokexin@xxxxxxxxx> wrote: > >> > On Fri, May 17, 2013 at 10:51:20PM +0800, Liu Jiang wrote: <snip> > > Region 0: bus address at a0000000 (64-bit, non-prefetchable) [size=128] > > Your dmesg log show this: > > pci_bus 0000:00: root bus resource [mem 0xa0000000-0xbfffffff] (bus > address [0xe0000000-0xffffffff]) > pci 0000:01:00.0: reg 10: [mem 0xa0000000-0xa000007f 64bit] > > There are two ways this could happen: > > 1) The BAR contained 0xe0000000 and we translated it to a legal > resource value of 0xa0000000, or > 2) The BAR contained 0xa0000000, we found no matching host bridge > window, and we assumed an offset of zero and again translated it to a > resource value of 0xa0000000. > > There's no information to distinguish these (lspci shows resource > values, not bus addresses, by default), but in your case, it must be > 2), based on the fact that the device doesn't work unless we reassign > the BAR. When we reassign it, we apply the translation and compute a > BAR value in the [0xe0000000-0xffffffff] range, which *does* work. You are absolutely right. :-) > > We should be able to detect this problem even without assuming we know > about all the host bridge windows. The bus-to-resource conversion > should be invertible. In case 2), bus_to_resource(0xa0000000) gave us > 0xa0000000, but resource_to_bus(0xa0000000) will give us 0xe0000000, > so we won't get back what we started with. > > I think I'd rather use this strategy than changing > pcibios_bus_to_resource(). Sounds reasonable. I will respin a patch to use this method. > I would also put a note in dmesg about the > fact that we're throwing away the BAR value put there by firmware (and > why), just for future debugging efforts. Will add. > Would you mind also > splitting the "move the pcibios_bus_to_resource() call out of the > if/else wrap" change into its own tiny patch since it's a separate > logical change? Sure. Thanks, Kevin > > Bjorn > > > In the current kernel, the pci host bridge use the following address regions: > > pci_bus 0000:00: root bus resource [mem 0xa0000000-0xbfffffff] (bus address [0xe0000000-0xffffffff]) > > > > And no reassign for device 0000:01:00.0. > > > > With my fix, the device 0000:01:00.0 is reassigned with the correct bus address: > > pci_bus 0000:00: root bus resource [mem 0xa0000000-0xbfffffff] (bus address [0xe0000000-0xffffffff]) > > pci 0000:01:00.0: BAR 6: assigned [mem 0xa0000000-0xa007ffff pref] > > pci 0000:01:00.0: BAR 2: assigned [mem 0xa0080000-0xa0083fff 64bit] > > pci 0000:01:00.0: BAR 0: assigned [mem 0xa0084000-0xa008407f 64bit] > > > > As you can see in the current kernel the pci subsystem doesn't detect > > this wrong bus address and don't try a reassign what it should do. > > My patches is trying to fix this issue. > > > > Thanks, > > Kevin > >> > >> Bjorn
Attachment:
pgptM8ZLLQXfs.pgp
Description: PGP signature
