Re: chipidea: udc: kernel panic in isr_setup_status_phase

[Clemens Gruber <clemens.gruber@pqgruber.com>]

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 ;-)

--

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..

Regards,
Clemens