On Sun, Aug 28, 2016 at 08:15:02PM +0200, Clemens Gruber wrote: > On Sat, Aug 27, 2016 at 01:21:52AM +0800, Peter Chen wrote: > > The gadget triggers UI interrupt due to host sends packet. > > > > I really can't understand that, why host does not send bus reset > > before sending packet (eg, GET_DESCRIPTOR)? It violates USB spec. > > > > Are you sure the first interrupt is UI when the vbus from off to on? > > Yes, if the error is present, the first interrupt is intr=0x1 (USBi_UI) > and then the NULL pointer dereference would occur. > (Also: Checking for ci->status == NULL and avoiding the dereference does > not make the gadget work. It just avoids the kernel panic.) > > But I also observed a situation where the first interrupt is intr=0x100 > (USBi_SLI) followed by 0x40 (USBi_URI), 0x4 (USBi_PCI) and three times > 0x1 (USBi_UI). > After this "g_ether gadget: suspend" appears and the sequence repeats, > starting again with intr=0x100, followed by 0x40, ... until three times > 0x1 and the g_ether gadget: suspend message. > On the host, every 500ms a new message with incrementing device number > appears: > usb 1-4: new high-speed USB device number 41 using xhci_hcd > usb 1-4: new high-speed USB device number 42 using xhci_hcd > ... > > In the case where everything works, it looks like this: > intr=0x100 (USBi_SLI) > intr=0x40 (USBi_URI) > intr=0x4 (USBi_PCI) > intr=0x1 (USBi_UI) > intr=0x1 (USBi_UI) > ci_hdrc ci_hdrc.0: freeing queued_request > intr=0x41 (USBi_URI + USBi_UI) > intr=0x4 (USBi_PCI) > intr=0x1 (USBi_UI) <-- appears 17 times > g_ether gadget: high-speed config #1: CDC Ethernet (EEM) > intr=0x1 (USBi_UI) <-- appears 5 times > IPv6: ADDRCONF(NETDEV_CHANGE): usb0: link becomes ready > > -- > > Do you think this could be a hardware problem? We used the same method > as in the MCIMX6Q-SDB schematics (SPF-27516_C5.pdf) to avoid any current > flow through OTG VBUS to the inside when the board is powered off but a > host PC is still connected via OTG. > So we not just pass the VBUS signal through, there are two MOSFETs, > which prevent that (if the internal 3.3V is low). > Mostly the same logic as in said document on page 11 (top-left area). > > Another possibility, I am investigating now, is a ground loop and a > main-supply voltage-dependency, although the whole USB OTG part is > on a completely different supply rail, the GNDs are shared. > > I am investigating in all directions at the moment ;-) > Would you please measure the voltage of vbus within 1s at below two conditions: - Just connect cable - Just disconnect cable > > I also switched to CDC/EEM to make sure it has nothing to do with RNDIS, > and the problem is still present. So the error must be on a lower level. > > -- > > You could try to reproduce it with a MCIMX6Q-SDB and varying the main > supply voltage between minimum and maximum allowed voltage levels. For > example: Plug OTG in once at the minimum and once at the maximum level, > see if it behaves differently. > But this is just one of my desperate theories at the moment.. > Sorry, I have no equipment which can change the voltage of main supplier now. -- Best Regards, Peter Chen -- 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
