On Tuesday, November 01, 2011, Linus Torvalds wrote: > On Tue, Nov 1, 2011 at 10:50 AM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > > > > Pardon me for being slow, but I don't see how this is related to the > > problem Linus reported. Namely, that _every_ PM event caused both of > > the EHCI controllers to be resumed, even if they had nothing to do with > > the event in question. > > > > Could some user program be responsible for this? > > I think there's some interrupt hooked up to the PME events, and that > interrupt is then shared with the EHCI driver. > > When I unplug and replug the device in the xhci port, the interrupt > count in /proc/interrupts for ehci goes up. > > Is ehci tied together with xhci somehow? I know there's this unholy > uhci->ehci tie-in - but I was assuming that xhci was separate, > especially since my xhci controller is a separate chip made by a > totally different manufacturer. > > More likely, I suspect some kind of PME even thing *is* happening, and > is just tied up completely wrong on the board (or crap irq tables). > > But if the ehci controller is suspended, should we even unsuspend it > if the PME bit isn't on? Maybe some check like is missing, and then > badly routed - or just shared - interrupts cause all this crap? It _looks_ like the BIOS supplies a GPE-handling method that contains a bunch of Notify() calls for multiple devices _except_ for the xHCI. This method is likely hooked up to a single GPE which triggers on wakeup events for any of those devices and is supposed to Notify() all of them. I've seen something like this already in one BIOS, so it's not unlikely at all, but it only is a theory at this point. 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
