On Tue, 11 Dec 2012, Lan Tianyu wrote: > Hi Alan&Greg: > Since 3.1, Alan enabled usb device wakeup default, there are > a lot of problem that immediately resume when enter into s2ram/s2disk. > I have traced some these bugs. Most of these bugs are related usb1.1 > device which attached to OHCI/UHCI. If disable the hc wakeup or no device > attached, it will work again. Not all usb1.1 devices will cause this issue. What if the device is disabled for wakeup? That's the right solution if the device is buggy. > From enabe/disable hc wakeup side, I check what is done in the ACPI. > When system is entering into s3/s4, ACPI will check all the device which has > wakeup resource(there is a gpe interrupt for these devices). If their > wakeup was > enabled, ACPI will enable their gpe interrupt . If there was a signal of gpe > during s3, the system would be resumed. That's the right thing to do. > Normally, usb hc will have gpe to wakeup system. This issue caused by > hc with some usb1.1 devices triggering wakeup signal just after > entering into s3/s4. Does the HC turn on the GPE even when the device does not send a remote wakeup request? Does the device send a remote wakeup request even when it is disabled for remote wakeup? > System resumes immediately. Since the signal is triggered after system entering > into s3/s4, it's hard to debug what hc does during this procedure(This > comes from > my analyse, I have no such machine to debug). > So can we add a blacklist which contains devices causing such > issue and disable > these devices' remote wakeup when system suspend to avoid such > problems? Well, we can create blacklist entries for malfunctioning USB devices. I don't know about malfunctioning host controllers, though. Maybe. > Or you > have some new debug measures, they are welcome. If something I said is > wrong, please > help me correct it. Thanks. We really need to know which component is bad: the host controller or the device. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
