On Fri, Oct 21, 2016 at 12:08:49AM -0700, Tony Lindgren wrote: > * Johan Hovold [161020 08:38]: > > Hi Tony, > > > > I'm getting the splat below when booting 4.9-rc1 on a BBB and > > tracked it down to 65b3f50ed6fa ("usb: musb: Add PM runtime support for > > MUSB DSPS glue layer") which added a synchronous RPM get in a timer > > callback: > > OK, sorry to hear about that. Care to email me your .config and how > to reproduce and what do you have connected like a hub? Also do > you use built-in gadgets or configure them via configfs? It happens even with no devices connected to the host port, and with no gadgets configured (or the peripheral port simply disabled). Whenever the glue timer fires and calls pm_runtime_get_sync() I get the splat. For some reason the might_sleep() in get_sync() does not trigger the first time, which means that I see this four seconds after probe, and then every other second when the timer fires. Attaching my defconfig. > > [ 6.466226] BUG: sleeping function called from invalid context at /home/johan/work/omicron/src/linux/drivers/base/power/runtime.c:955 > > [ 6.478850] in_atomic(): 1, irqs_disabled(): 0, pid: 59, name: grep > > [ 6.485434] 1 lock held by grep/59: > > [ 6.489102] #0: [ 6.490966] ( > > ((&glue->timer))[ 6.494206] ){+.-...} > > , at: [ 6.497194] [] call_timer_fn+0x0/0x41c > > [ 6.502048] Preemption disabled at:[ 6.505540] [] __do_softirq+0x80/0x594 > > [ 6.510393] > > [ 6.511974] CPU: 0 PID: 59 Comm: grep Not tainted 4.9.0-rc1 #46 > > [ 6.518190] Hardware name: Generic AM33XX (Flattened Device Tree) > > [ 6.524613] [] (unwind_backtrace) from [] (show_stack+0x20/0x24) > > [ 6.532753] [] (show_stack) from [] (dump_stack+0x24/0x28) > > [ 6.540351] [] (dump_stack) from [] (___might_sleep+0x1d8/0x2c4) > > [ 6.548486] [] (___might_sleep) from [] (__might_sleep+0x70/0xa8) > > [ 6.556720] [] (__might_sleep) from [] (__pm_runtime_resume+0x9c/0xa0) > > [ 6.565404] [] (__pm_runtime_resume) from [] (otg_timer+0x3c/0x254) > > [ 6.573813] [] (otg_timer) from [] (call_timer_fn+0xfc/0x41c) > > [ 6.581675] [] (call_timer_fn) from [] (expire_timers+0x120/0x210) > > [ 6.589990] [] (expire_timers) from [] (run_timer_softirq+0xa4/0xdc) > > [ 6.598487] [] (run_timer_softirq) from [] (__do_softirq+0x12c/0x594) > > [ 6.607079] [] (__do_softirq) from [] (irq_exit+0xf4/0x130) > > [ 6.614766] [] (irq_exit) from [] (__handle_domain_irq+0x84/0xec) > > [ 6.622991] [] (__handle_domain_irq) from [] (omap_intc_handle_irq+0x44/0xa0) > > [ 6.632306] [] (omap_intc_handle_irq) from [] (__irq_usr+0x58/0x80) > > [ 6.640716] Exception stack(0xcf669fb0 to 0xcf669ff8) > > [ 6.646028] 9fa0: b6fd5050 0012ebb0 b6e71058 b6e1c088 > > [ 6.654614] 9fc0: b6e07000 00000001 b6e1cb10 b6fd5000 00000001 00000000 b6fd38e8 bec32a54 > > [ 6.663198] 9fe0: b6e1c870 bec32990 b6fb0a20 b6fb9758 20030010 ffffffff > > > > Setting the irq_safe flag seems to do the trick, but not sure that's > > what you intended to do. > > That's what we want to avoid as it keep the parent device permanently > enabled. To avoid that we want to just queue things and deal with them > from pm_runtime_resume. I figured, so then that pm_runtime_get_sync() in the dsps timer callback needs to go. > > I saw you posted some regression fixes lately, but they did not look > > related to this at first glance at least. > > Yeah this seems different. Can you still try v4.9-rc + patches from > thread "[PATCH 0/2] Fixes for two more musb regressions"? As expected, those two fixes makes no difference. Thanks, Johan