On 20-11-17 18:30:34, Neuenschwander, Bowe wrote: > Thanks for your quick reply. I think your ping test/example tells me quite a > bit about the expected behavior. I do have concerns though on what this would > do to TCP connections. Could that cause quite a bit of packet build up as > the connection attempts to re-transmit packets that were not ACKed (but still > sitting in the queue)? In the case that the suspend is long (say 10-60 min), > it seems this could cause quite a lot of packet build up, though I assume its > TX queue will fill up pretty quickly and send will start returning failure). > > The issue we are seeing is when USB is physically disconnected, the suspend > hooks are called, but the disconnect hooks are not. The device side of the > USB link (the one configured with Gadget EEM) is externally powered and has > a hub as well. The host is disconnected from the hub, but the link between > the hub and Gadget EEM remains intact, so the Gadget EEM processor does not > see VUSB go low. See below for a crude diagram (monospaced font needed): > ____________________________ > | Device | > | ________ ________ | ________ > | | | | | | | | > | | USB | | USB | | | USB | > | | Gadget |-----| HUB |--|---X---| Host | > | | EEM | | | | | | > | |________| |________| | |________| > | | > |____________________________| > > Therefore, it stays in that suspend state until USB is reconnected, at which > point the disconnect hook gets called and the connection is reset and set back > up. See below for dmesg (note that the USB Gadget EEM interface is vis0): > > USB Disconnected: > [ 4047.888922] g_ether gadget: suspend > [ 4048.442846] vis0: stop stats: rx/tx 13079/13406, errs 0/0 > [ 4048.442967] vis0: host still using in/out endpoints > > USB Reconnected: > [ 4054.891454] g_ether gadget: reset config > [ 4054.891487] g_ether gadget: eem deactivated > [ 4054.891500] vis0: gether_disconnect > [ 4054.897743] g_ether gadget: suspend > [ 4055.273258] g_ether gadget: suspend > [ 4055.662466] g_ether gadget: high-speed config #1: CDC Ethernet (EEM) > [ 4055.668899] g_ether gadget: reset eem > [ 4055.668912] vis0: gether_disconnect > [ 4055.668924] g_ether gadget: init eem > [ 4055.668934] g_ether gadget: activate eem > [ 4055.668974] vis0: qlen 10 > [ 4055.674126] g_ether gadget: reset eem > [ 4055.674161] vis0: gether_disconnect > [ 4055.674219] g_ether gadget: init eem > [ 4055.674230] g_ether gadget: activate eem > [ 4055.674267] vis0: qlen 10 > [ 4055.847697] vis0: eth_open > [ 4055.847729] vis0: eth_start > > The problem we have is when it goes into that suspend state, that interface > remains up but cannot actually send/receive. There is a process (for which > we do not have source code available) that starts consuming a large portion > of the CPU (according to top/htop), which in turn causes other issues. We > have have a little daemon to detect when USB gets disconnected and bring down > that interface (ifdown), and we have tried adjusting the offending process's > nice value, but these do not fix the issue (they help, but do not elminate > it). The only fix we have found so far to eliminate this issue is something > similar to the patch I previously sent; but again, I have questions of if it > is acceptable handling for USB suspend. Since suspend is one of USB bus state, the USB host may suspend the device at some situations, it seems it is your HUB's issue that does not disconnect its downstream ports that the host disconnects it. Could your daemon poll suspend state for gadget through /sys/class/udc/<YOUR UDC NAME>/state and bring down the interface? You need below change at kernel for that. diff --git a/drivers/usb/gadget/composite.c b/drivers/usb/gadget/composite.c index c6d455f2bb92..bf11488de93b 100644 --- a/drivers/usb/gadget/composite.c +++ b/drivers/usb/gadget/composite.c @@ -2330,6 +2330,7 @@ void composite_suspend(struct usb_gadget *gadget) usb_gadget_set_selfpowered(gadget); usb_gadget_vbus_draw(gadget, 2); + usb_gadget_set_state(gadget, USB_STATE_SUSPENDED); } void composite_resume(struct usb_gadget *gadget) -- Thanks, Peter Chen
