From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932558AbcH2CYR (ORCPT ); Sun, 28 Aug 2016 22:24:17 -0400 Received: from mail-pf0-f174.google.com ([209.85.192.174]:33769 "EHLO mail-pf0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756222AbcH2CYP (ORCPT ); Sun, 28 Aug 2016 22:24:15 -0400 Date: Mon, 29 Aug 2016 18:24:03 +0800 From: Peter Chen To: Clemens Gruber Cc: linux-usb@vger.kernel.org, Greg Kroah-Hartman , linux-kernel@vger.kernel.org Subject: Re: chipidea: udc: kernel panic in isr_setup_status_phase Message-ID: <20160829102402.GA3736@b29397-desktop> References: <20160823003630.GA3052@archie.localdomain> <20160824081102.GA27233@shlinux2> <20160825234740.GA12850@archie.localdomain> <20160826172151.GA21360@b29397-desktop> <20160828181502.GA7785@archie.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160828181502.GA7785@archie.localdomain> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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