On Friday, April 05, 2013 10:56:30 AM Bjorn Helgaas wrote: > >> If the problem is with config space access, not with the SCI, why > >> can't you just put the root port back in D0 before scanning its > >> secondary bus? That seems like a more direct fix. > > > > comment #4 patch does exactly like that. ALLurGroceries tried that patch and > > it works for him in comment #7. But in comment #14, ALLurGroceries reported > > that it does not work reliably enough. So I write comment #26 patch to fix the > > issue in a more conservative way, and it works reliable for ALLurGroceries. > > The comment #4 patch adds "pm_runtime_get_sync(&bridge->pci_dev->dev)" > before re-enumerating. If that is supposed to keep the bridge in D0 > but doesn't, we need to figure out why. I don't know how PM works, > but maybe Rafael will chime in. Quite frankly, this looks like unreliable hardware to me in the face of comment #14. It looks like with that patch applied the problem is randomly reproducible, which suggests that we probably don't wait for a sufficiently long time during the PCIe port resume. Or there's a race I'm not seeing at the moment. So it might be a good idea to repeat the experiment with a similar patch, but with increased timeouts (and the "put" part need not be "sync"). -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. -- 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
