* Peter Ujfalusi <peter.ujfalusi@xxxxxx> [170405 00:15]: > Tony, > > On 2017-04-05 03:36, Tony Lindgren wrote: > > * Tony Lindgren <tony@xxxxxxxxxxx> [170404 07:06]: > > > * Bin Liu <b-liu@xxxxxx> [170404 05:30]: > > > > On Tue, Apr 04, 2017 at 10:09:50AM +0300, Peter Ujfalusi wrote: > > > > > Tony, > > > > > > > > > > since 4.9 (4.8 was fine) I can not boot omap4-panda-es if the musb > > > > > is compiled in. The kernel will stuck printing: > > > > > > > > > > ** 206 printk messages dropped ** [ 8.926727] musb_bus_suspend > > > > > 2584: trying to suspend as a_idle while active > > > > > > OK so compiled in. Do you have something connected also when > > > booting? > > > > > > > Does it sound a similar issue to > > > > http://marc.info/?l=linux-usb&m=149036531809506&w=2 > > > > > > Yup. > > > > > > > > The bisect (log is [1]) points to: > > > > > d8e5f0eca1e8 usb: musb: Fix hardirq-safe hardirq-unsafe lock order error > > > > > > > > > > and reverting the d8e5f0eca1e8 makes the board to boot up fine > > > > > (Linux 4.11-rc5 and next-20170331). > > > > > > OK thanks for bisecting it. > > > > > > > > any idea on how to fix this w/o reverting the commit? > > > > > > I'll take a look. > > > > OK I was able to reproduce this with loadable modules by reloading > > the modules while having OTG-A cable inserted with a hub and USB > > drive connected. > > > > Peter, care to check if the following fixes the problem for you? > > There should no longer be much any musb core tinkering happening > > in the glue layers.. > > I had similar hunch first, but did not worked. I have tested this patch and > did not helped. > > To be precise this is what I have tried: > - boot w/o cable connected > - boot w/ board connected to PC (device mode) > - boot w/ OTG-A cable with USB keyboard > - boot w/ OTG-A cable connected to powered USB hub and the same keyboard > > w/ and w/o this patch I have the same flood of prints in all cases. OK interesting that it also happens with nothing connected. > Fwiw I have checked where the is_active is set - which causes the prints: > musb_core.c:musb_start() > > if (musb->port_mode != MUSB_PORT_MODE_HOST && > musb->xceiv->otg->state != OTG_STATE_A_WAIT_BCON && > (devctl & MUSB_DEVCTL_VBUS) == MUSB_DEVCTL_VBUS) { > musb->is_active = 1; > } else { > devctl |= MUSB_DEVCTL_SESSION; > } > > this was the only place where the is_active was set to 1. That seems normal in musb_start(). Will try with your .config here. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
