From mboxrd@z Thu Jan 1 00:00:00 1970 From: Felipe Balbi Subject: Re: [PATCH] usb: dwc3: omap: Fix imprecise external abort and oops on boot Date: Thu, 08 Dec 2016 19:51:41 +0200 Message-ID: <87a8c6pavm.fsf@linux.intel.com> References: <20161208032108.21962-1-tony@atomide.com> <87lgvqkb6f.fsf@linux.intel.com> <20161208153734.GF4264@atomide.com> Mime-Version: 1.0 Content-Type: text/plain Return-path: In-Reply-To: <20161208153734.GF4264-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org> Sender: linux-usb-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Tony Lindgren Cc: Greg Kroah-Hartman , Grygorii Strashko , Roger Quadros , Sekhar Nori , linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-omap-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Nishanth Menon List-Id: linux-omap@vger.kernel.org Hi, Tony Lindgren writes: > * Felipe Balbi [161208 01:45]: >> >> Hi, >> >> Tony Lindgren writes: >> > Somehow starting with v4.9-rc7 there have been imprecise >> >> There's nothing touching dwc3 since v4.9-rc5. > > Right, nothing obvious has changed. I think it's just a slight timing > change in the code that started triggering it. could be >> > external aborts on omap5-uevm dwc3 controller. I have not been >> > able to bisect what exactly triggered this as it does not always >> > happen. It seems that something changed with probing that >> > now exposes the issue: >> > >> > Unhandled fault: imprecise external abort (0x1406) at 0x00000000 >> >> hmmm, clock disabled... dwc3-omap shouldn't have pm runtime at all. > > It does for the interconnect target module clkctrl register via PM > runtime. That's the "usb_otg_ss" module. but that's all hidden in omap_device.c, we don't touch it from driver perspective. >> > ... >> > PC is at dwc3_omap_interrupt_thread+0x20/0x80 >> > LR is at irq_thread_fn+0x1c/0x54 >> > ... >> > [] (dwc3_omap_interrupt_thread) from [] >> > (irq_thread_fn+0x1c/0x54) >> > [] (irq_thread_fn) from [] (irq_thread+0x12c/0x1f0) >> > [] (irq_thread) from [] (kthread+0xdc/0xf4) >> > [] (kthread) from [] (ret_from_fork+0x14/0x3c) >> > ... >> > >> > Unable to handle kernel paging request at virtual address ffffffec >> > ... >> > Internal error: Oops: 37 [#2] SMP ARM >> > PC is at kthread_data+0x4/0xc >> > LR is at irq_thread_dtor+0x28/0xd0 >> > ... >> > [] (kthread_data) from [] (irq_thread_dtor+0x28/0xd0) >> > [] (irq_thread_dtor) from [] (task_work_run+0xb8/0xdc) >> > [] (task_work_run) from [] (do_exit+0x314/0xa20) >> > [] (do_exit) from [] (die+0x410/0x474) >> > [] (die) from [] (do_DataAbort+0xb4/0xb8) >> > [] (do_DataAbort) from [] (__dabt_svc+0x58/0x80) >> > Exception stack(0xee777ec8 to 0xee777f10) >> > 7ec0: 0000014d ee6e6f10 00000034 fc020034 ee6e6f10 ee1eec00 >> > 7ee0: 00000000 00000000 ee6ec640 c038a4bc 00000000 00000000 00000000 ee777f18 >> > 7f00: c038a4d8 c0989fa8 60000013 ffffffff >> > [] (__dabt_svc) from [] (dwc3_omap_interrupt_thread+0x20/0x80) >> > [] (dwc3_omap_interrupt_thread) from [] (irq_thread_fn+0x1c/0x54) >> > [] (irq_thread_fn) from [] (irq_thread+0x12c/0x1f0) >> > [] (irq_thread) from [] (kthread+0xdc/0xf4) >> > [] (kthread) from [] (ret_from_fork+0x14/0x3c) >> > >> > Fix the issue by making sure the dwc3 interrupts are disabled >> > before we call devm_request_threaded_irq(). >> >> that should already be the case. Are you sure that register isn't zero >> in probe? > > Looks like irq0_status = 0 and irqmisc_status = 0x2121. Also just > clearing irqmisc with dwc3_omap_write_irqmisc_clr(omap, 0xffffffff) > stops the issue from happening. > > There is some deferred probing happening but irqmisc is always 0x2121. some spurious irq status from ROM code, perhaps? Are you not resetting usb_otg_ss hwmod? We shouldn't have any pending interrupts when we get to probe(), if we do have them, then we need an erratum for it. You could try making usb_otg_ss is reset by hwmod. It would also be good to check other OMAP-ish devices sporting dwc3 (DRA7x, AM437x, AM57x) if they have the same behavior. Adding Nishanth to the loop too for reference. -- balbi -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html