On Mon, 5 Aug 2013, Huang Rui wrote: > Hi Alan, > > On Thu, Jul 11, 2013 at 02:58:04PM -0400, Alan Stern wrote: > > The hub driver was recently changed to use "global" suspend for system > > suspend transitions on non-SuperSpeed buses. This means that we don't > > suspend devices individually by setting the suspend feature on the > > upstream hub port; instead devices all go into suspend automatically > > when the root hub stops transmitting packets. The idea was to save > > time and to avoid certain kinds of wakeup races. > > > > Now it turns out that many hubs are buggy; they don't relay wakeup > > requests from a downstream port to their upstream port if the > > downstream port's suspend feature is not set (depending on the speed > > of the downstream port, whether or not the hub is enabled for remote > > wakeup, and possibly other factors). > > > > Could you explain that how can you make sure the root cause is unable > to relay wakup requests from downstream port to upstream port if > downstream port's suspend feature is not set? The OS is unable wakeup > from S3 at that time. We can't fetch dmesg log and serial port is > suspend either at that time. Did you use any other tools to trace this > issue? Could you teach me? Actually, I was encoutered this issue > either. It was simple. I ran two tests. They were exactly the same, except that the suspend feature was set in the first test and was not set in the second test. Remote wakeup worked in the first test and not in the second. 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
