On Thu, May 23, 2013 at 11:17 AM, Yinghai Lu <yinghai@xxxxxxxxxx> wrote: > On Thu, May 23, 2013 at 10:12 AM, Bjorn Helgaas <bhelgaas@xxxxxxxxxx> wrote: >> On Thu, May 23, 2013 at 11:08 AM, Yinghai Lu <yinghai@xxxxxxxxxx> wrote: >>> >>> Good, will resend this as complete form to Bjorn for v3.10. >> >> I haven't seen anything this actually fixes yet, except that maybe it >> removes some "can't assign" messages. That doesn't sound like v3.10 >> material. > > io port "can't assign" still there. The "can't assign io" message is harmless. The host bridge doesn't support I/O port space, so we'll *never* be able to assign IO space. The best we can do for this part of the problem is to get rid of the message, and that's not urgent for v3.10. Actually, I don't think we *should* get rid of the message; if we can't assign IO space to an IO BAR, I want to know about it. Maybe the message should be clearer or less alarming, but it should be there. > the problem that it fixed: don't fallback wrongly for mmio when ioport > fails with must+optional. > > because if it fall back to mmio must-only, later extending to cover > optional will > not find extra space as mmio range and mmio-pref range in the bridge > is connected > together. I know that we retry when we don't need to. If the retry results in MEM assignments that are *worse* than the original ones, that might be a problem we should fix. But that problem should have nothing to do with I/O port space. Conceptually, if we retry because IO assignment failed, the MEM assignments should not change. I could probably grope through your logs and figure out whether this is happening, but it's your job to do that legwork and convince me that a change is necessary. Bjorn -- 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
