On Sat, Oct 27, 2012 at 12:28 AM, Bjorn Helgaas <bhelgaas@xxxxxxxxxx> wrote: > On Fri, Oct 26, 2012 at 8:08 AM, Chris Metcalf <cmetcalf@xxxxxxxxxx> wrote: > >> Cyberman: it seems like your bias hack is working for you. But, as Bjorn >> says, this sounds like a driver bug. What happens if you just revert your >> changes, but then in mvsas.c change the "if (!res_start || !res_len)" to >> just say "if (!res_len)"? That seems like the true error test. If that >> works, you should submit that change to the community. > > I don't *think* that is going to be enough, even with the kernel that > has some I/O space support, because both devices are assigned > identical resources: > > pci 0000:01:00.0: BAR 2: assigned [io 0x0000-0x007f] > pci 0001:01:00.0: BAR 2: assigned [io 0x0000-0x007f] > > The I/O space support that's there is broken because we think the same > I/O range is available on both root buses, which is probably not the > case: > > pci_bus 0000:00: resource 0 [io 0x0000-0xffffffff] > pci_bus 0001:00: resource 0 [io 0x0000-0xffffffff] > That's the problem I want to confirm what I've changed is correct. I've split the two RootComplex using separate I/O range, it seems works on our device, but since I'm not very clear about Linux kernel, I want some some to check it. For mvsas, I've already modified it some thing like Chris said when I began using MDE-4.0.0 GA release. I bring it out to see if there have some ideas about that issue. > If mvsas really doesn't need the I/O BAR, I think it's likely that > making it use pci_enable_device_mem() will make both devices work even > without I/O space support in the kernel. > >> Bjorn et al: does it seem reasonable to add a bias to the mappings so that >> we never report a zero value as valid? This may be sufficiently defensive >> programming that it's just the right thing to do regardless of whether >> drivers are technically at fault or not. If so, what's a good bias? (I'm >> inclined to think 64K rather than 4K.) > > I/O space is very limited to begin with (many architectures only > *have* 64K), so I hesitate to add a bias in the PCI core. But we do > something similar in arch_remove_reservations(), and I think you could > implement it that way if you wanted to. > > Bjorn -- Cyberman Wu -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
