>Has this shown up with other USB device controller drivers, or just the >DWC (DesignWare)? UDC driver? Yes Michal Nazarewicz has seen this on a S3C UDC, heres his stack trace: WARNING: at kernel/softirq.c:143 local_bh_enable_ip+0x44/0xc0() [...] [<c0049024>] (local_bh_enable_ip+0x44/0xc0) from [<c025ef18>] (dev_txq_stats_fold+0xac/0x108) [<c025ef18>] (dev_txq_stats_fold+0xac/0x108) from [<c025f018>] (dev_get_stats+0xa4/0xac) [<c025f018>] (dev_get_stats+0xa4/0xac) from [<c01f72bc>] (gen_ndis_query_resp+0x4c/0x43c) [<c01f72bc>] (gen_ndis_query_resp+0x4c/0x43c) from [<c01f784c>] (rndis_msg_parser+0x1a0/0x32c) [<c01f784c>] (rndis_msg_parser+0x1a0/0x32c) from [<c01f79f8>] (rndis_command_complete+0x20/0x4c) [<c01f79f8>] (rndis_command_complete+0x20/0x4c) from [<c01f3278>] (done+0x5c/0x70) [<c01f3278>] (done+0x5c/0x70) from [<c01f3c60>] (complete_tx+0xf0/0x1a8) [<c01f3c60>] (complete_tx+0xf0/0x1a8) from [<c01f3d8c>] (process_ep_in_intr+0x74/0x14c) [<c01f3d8c>] (process_ep_in_intr+0x74/0x14c) from [<c01f470c>] (s3c_udc_irq+0x2c8/0x3f4) [<c01f470c>] (s3c_udc_irq+0x2c8/0x3f4) from [<c006dfd0>] (handle_IRQ_event+0x24/0xe4) [<c006dfd0>] (handle_IRQ_event+0x24/0xe4) from [<c006fe40>] (handle_level_irq+0xb0/0x12c) [<c006fe40>] (handle_level_irq+0xb0/0x12c) from [<c0027074>] (asm_do_IRQ+0x74/0x98) [<c0027074>] (asm_do_IRQ+0x74/0x98) from [<c0027ca4>] (__irq_usr+0x44/0xc0) (taken from Michal's original patch here: <https://patchwork.kernel.org/patch/195562/>) Neil On Sun, Dec 26, 2010 at 11:49 PM, David Brownell <david-b@xxxxxxxxxxx> wrote: > On Wed, 2010-12-08 at 15:11 +0000, Neil Jones wrote: >> >> Im getting another lockdep warning when using the RNDIS gadget: > > > > Probably this is either > > > Â(a) a recent regression, maybe caused by a change ISTR in the network > layer stats handling ... which broke another USB + NET driver in much > the same way, wish I remembered details of which driver, the fix > there was simple and maybe a good model for fixing this one. > > or (b) Â... maybe a > DWC-specific USB device controller driver oddity. Â(Seemed less likely > to me when I glanced at the stackdumps below. > > Has this shown up with other USB device controller drivers, or just the > DWC (DesignWare)? UDC driver? > > I'll say I'm not keen on adding a thread to the driver. ÂIt's worked > fine without one for many years, even running lockdep. ÂWhatever change > (network stack or using DWC) caused the locking issue can be fixed > without a new thread. > > - Dave > > > > The first thing I noticed was that very little of the dumped stack > context was part of the RNDIS gadget ... often a sign that the issue > is in the call down to the code dumping its stack (or its context). > > (Or if my recollection is right ... that there was an incompatible > change in a network statistics call, and whoever changed that didn't > update all affected callers. Â(ergo breakage here and in another driver. >> >> ÂWARNING: at kernel/softirq.c:98 ___local_bh_disable+0xc4/0xd0() >> ÂModules linked in: g_ether >> >> ÂCall trace: >> Â[<40003bf8>] _show_stack+0x68/0x7c >> Â[<40003c20>] _dump_stack+0x14/0x28 >> Â[<40013c3c>] _warn_slowpath_common+0x5c/0x7c >> Â[<40013c74>] _warn_slowpath_null+0x18/0x2c >> Â[<4001b17c>] ___local_bh_disable+0xc0/0xd0 >> Â[<4001b1a0>] _local_bh_disable+0x14/0x28 >> Â[<402e57f8>] __raw_spin_lock_bh+0x18/0x54 >> Â[<40257f4c>] _dev_txq_stats_fold+0x7c/0x13c >> Â[<402580c4>] _dev_get_stats+0xb8/0xc0 >> Â[<781d4e60>] _rndis_msg_parser+0x288/0xa04 [g_ether] >> Â[<781d5600>] _rndis_command_complete+0x24/0x70 [g_ether] >> Â[<401d66fc>] _dwc_otg_request_done+0xd8/0x220 >> Â[<401d928c>] _ep0_complete_request+0x3f4/0x578 >> Â[<401d95bc>] _handle_ep0+0x1ac/0x146c >> Â[<401daf7c>] _dwc_otg_pcd_handle_in_ep_intr+0x1c0/0x8bc >> Â[<401db8dc>] _dwc_otg_pcd_handle_intr+0x264/0x294 >> Â[<401d6288>] _dwc_otg_pcd_irq+0x10/0x30 >> Â[<40054cf4>] _handle_IRQ_event+0x4c/0x184 >> Â[<40057b4c>] _handle_level_irq+0xac/0x15c >> Â[<4000b204>] _metag_soc_irq_demux+0xac/0xb4 >> Â[<40002dd4>] _do_IRQ+0x4c/0x78 >> Â[<40004000>] _trigger_handler+0x38/0xac >> Â[<40000b18>] ___TBIBoingVec+0xc/0x10 >> Â[<40003588>] _cpu_idle+0x54/0x78 >> >> Âno locks held by swapper/0. >> Â---[ end trace 77ac3cfee0ae5b25 ]--- >> >> It looks like we are calling spin_lock_bh in the completion function >> which is running in hard_irq, I think the driver should defer handling >> this msg (and maybe all requests) to a workqueue? >> >> Cheers >> >> Neil >> >> >> >> On Wed, Dec 8, 2010 at 3:03 PM, Neil Jones <neiljay@xxxxxxxxx> wrote: >> > Hi, >> > >> > Im getting another lockdep warning when using the RNDIS gadget: >> > >> > ÂWARNING: at kernel/softirq.c:98 ___local_bh_disable+0xc4/0xd0() >> > ÂModules linked in: g_ether >> > >> > ÂCall trace: >> > Â[<40003bf8>] _show_stack+0x68/0x7c >> > Â[<40003c20>] _dump_stack+0x14/0x28 >> > Â[<40013c3c>] _warn_slowpath_common+0x5c/0x7c >> > Â[<40013c74>] _warn_slowpath_null+0x18/0x2c >> > Â[<4001b17c>] ___local_bh_disable+0xc0/0xd0 >> > Â[<4001b1a0>] _local_bh_disable+0x14/0x28 >> > Â[<402e57f8>] __raw_spin_lock_bh+0x18/0x54 >> > Â[<40257f4c>] _dev_txq_stats_fold+0x7c/0x13c >> > Â[<402580c4>] _dev_get_stats+0xb8/0xc0 >> > Â[<781d4e60>] _rndis_msg_parser+0x288/0xa04 [g_ether] >> > Â[<781d5600>] _rndis_command_complete+0x24/0x70 [g_ether] >> > Â[<401d66fc>] _dwc_otg_request_done+0xd8/0x220 >> > Â[<401d928c>] _ep0_complete_request+0x3f4/0x578 >> > Â[<401d95bc>] _handle_ep0+0x1ac/0x146c >> > Â[<401daf7c>] _dwc_otg_pcd_handle_in_ep_intr+0x1c0/0x8bc >> > Â[<401db8dc>] _dwc_otg_pcd_handle_intr+0x264/0x294 >> > Â[<401d6288>] _dwc_otg_pcd_irq+0x10/0x30 >> > Â[<40054cf4>] _handle_IRQ_event+0x4c/0x184 >> > Â[<40057b4c>] _handle_level_irq+0xac/0x15c >> > Â[<4000b204>] _metag_soc_irq_demux+0xac/0xb4 >> > Â[<40002dd4>] _do_IRQ+0x4c/0x78 >> > Â[<40004000>] _trigger_handler+0x38/0xac >> > Â[<40000b18>] ___TBIBoingVec+0xc/0x10 >> > Â[<40003588>] _cpu_idle+0x54/0x78 >> > >> > Âno locks held by swapper/0. >> > Â---[ end trace 77ac3cfee0ae5b25 ]--- >> > >> > It >> > >> -- >> To unsubscribe from this list: send the line "unsubscribe linux-usb" in >> the body of a message to majordomo@xxxxxxxxxxxxxxx >> More majordomo info at Âhttp://vger.kernel.org/majordomo-info.html > > > > -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
