> Maybe we should just try that patch in > > https://bugzilla.kernel.org/show_bug.cgi?id=41622#c17 > > but it really needs to happen early in a merge window. We didn't do > that for 3.2, maybe we can do it for 3.6? The first problem is still that this machine doesn't get anywhere at all with ACPI enabled (https://bugzilla.kernel.org/show_bug.cgi?id=41722), so we only get to this transparent bridge issue with "acpi=off". I really think that it would be better to solve the ACPI issue first because it's too difficult to support an "acpi=off" config -- nobody else tests that and very few users will be sophisticated enough to even try it. Unfortunately, I don't have any good ideas about the ACPI issue other than the MTRR possibility Len suggested. If we just fiddle with transparent bridge sizing, we're making the problem go away, but we don't really know why, so I'm afraid of breaking some other machine or tripping over this somewhere else. My guess is that we hang because we moved a device on top of something else, and if we skip transparent bridge sizing, we avoid that device move. I do think it might be reasonable to avoid bridge sizing on the grounds that we shouldn't move things unless we have to. But right now, we don't even know the real effect of skipping the bridge sizing. Rogério, we might be able to at least identify a relevant difference if you collect the dmesg from the "working" case ("acpi=off" with the comment #17 patch), a video of the hanging case ("acpi=off" without the patch, possibly with "boot_delay=1000" to slow things down) that we can transcribe by hand, and the AIDA64 info from Windows that I mentioned in bug 41722. -- 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
