On Tuesday, November 01, 2011, Linus Torvalds wrote: > On Tue, Nov 1, 2011 at 11:33 AM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > > > > And xHCI certainly shouldn't be affected by something happening to the > > Ethernet controller. > > So what about the PCI bridges? If the PME event makes it from the > device to the bridge (I have no idea what the signalling is), and the > *bridge* does the PME handling, we do that > > if (pci_dev->subordinate) > pci_pme_wakeup_bus(pci_dev->subordinate); > > thing. I didn't look how recursive it is and just what it does, but it > strikes me that depending on just how deep the PME event goes, it > might explain the "any PME event causes ehci issues". I don't think that's what the problem is, really. All of the devices in your box are PCI Express, aren't they? Which means that there are no _real_ bridges in there, only the fake ones representing ports. In which case they simply pass PME messages from devices to the root complex (the signaling is in-band in that case and should be transparent to the ports). > One thing that is special about the EHCI device is that we seem to use > ACPI to manage the D0/D3 transition for it. Don't ask me why, but > that's what the messages certainly imply. Maybe the "native PCI" stuff > is smart enough to know that "Hey, there's no event for me, so I'll > not do anything", but then the ehci/acpi interaction means that the > ehci controllers get woken up for everything. > > But what do I know? Certainly not PCI PM crud. For now I'm suspecting the BIOS. We'll see. :-) Thanks, Rafael -- 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
