Re: BUG: scheduling while atomic from dwc2_hsotg_core_init_disconnected

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Dec 8, 2016 at 4:31 PM, John Youn <John.Youn@xxxxxxxxxxxx> wrote:
> On 12/8/2016 4:25 PM, John Stultz wrote:
>> On Thu, Dec 8, 2016 at 4:17 PM, John Youn <John.Youn@xxxxxxxxxxxx> wrote:
>>> On 12/8/2016 3:12 PM, John Stultz wrote:
>>>> Hey John,
>>>>   In my testing I've come across another issue in the dwc2 driver.
>>>>
>>>> Basically when plugging in various cables in different orders, I'm
>>>> occasionally seeing the following BUG splat:
>>>>
>>>> [   86.215403] BUG: scheduling while atomic: kworker/u16:2/53/0x00000002
>>>> [   86.219164] usb 1-1: USB disconnect, device number 9
>>>> [   86.226845] Preemption disabled at:[   86.230218]
>>>> [<ffffff8008673558>] dwc2_conn_id_status_change+0x120/0x250
>>>> [   86.236894] CPU: 0 PID: 53 Comm: kworker/u16:2 Tainted: G        W
>>>>      4.9.0-rc8-00051-gd5a7979-dirty #1702
>>>> [   86.246836] Hardware name: HiKey Development Board (DT)
>>>> [   86.252100] Workqueue: dwc2 dwc2_conn_id_status_change
>>>> [   86.257279] Call trace:
>>>> [   86.259771] [<ffffff8008087c28>] dump_backtrace+0x0/0x1a0
>>>> [   86.265210] [<ffffff8008087ddc>] show_stack+0x14/0x20
>>>> [   86.270308] [<ffffff80084343f0>] dump_stack+0x90/0xb0
>>>> [   86.275401] [<ffffff80080d8d94>] __schedule_bug+0x6c/0xb8
>>>> [   86.280841] [<ffffff8008a07220>] __schedule+0x4f8/0x5b0
>>>> [   86.286099] [<ffffff8008a073e8>] schedule+0x38/0xa0
>>>> [   86.291017] [<ffffff8008a0a6cc>] schedule_hrtimeout_range_clock+0x8c/0xf0
>>>> [   86.297846] [<ffffff8008a0a740>] schedule_hrtimeout_range+0x10/0x18
>>>> [   86.304150] [<ffffff8008a0a4a0>] usleep_range+0x50/0x58
>>>> [   86.309418] [<ffffff800866d8dc>] dwc2_wait_for_mode.isra.4+0x54/0xd0
>>>> [   86.315815] [<ffffff800866f058>] dwc2_core_reset+0xe0/0x168
>>>> [   86.321431] [<ffffff800867e364>] dwc2_hsotg_core_init_disconnected+0x2c/0x310
>>>> [   86.328602] [<ffffff8008673568>] dwc2_conn_id_status_change+0x130/0x250
>>>> [   86.335254] [<ffffff80080ccd48>] process_one_work+0x118/0x370
>>>> [   86.341035] [<ffffff80080ccfe8>] worker_thread+0x48/0x498
>>>> [   86.346473] [<ffffff80080d2eb0>] kthread+0xd0/0xe8
>>>> [   86.351299] [<ffffff8008082e80>] ret_from_fork+0x10/0x50
>>>>
>>>>
>>>> This seems to be caused by the dwc2_wait_for_mode() calling
>>>> usleep_range() while the hstog->lock spinlock is held, since we take
>>>> that before calling dwc2_hsotg_core_init_disconnected().
>>>>
>>>> I'm sort of surprised this hasn't been noticed before, since it seems
>>>> dwc2_hsotg_core_init_disconnected() is called from a number of places
>>>> with the spinlock held.
>>>
>>> I think it was uncovered by your peculiar ID pin behvaior :) But it
>>> could happen normally too, so that's good.
>>>
>>> dwc2_hsotg_core_init_disconnected() is only called as a B-device, so
>>> it shouldn't call dwc2_wait_for_mode() from within
>>> dwc2_core_reset(). The ID-pin must be going to A-device before we
>>> finish initialization of B-device, so we shouldn't depend on it being
>>> consistent after we call this.
>>>
>>> It should be enough to force dwc2_core_reset() to run atomically
>>
>> Sorry, force it to run atomically? As in add an extra argument for
>> this case, or are you thinking something different?
>
> Yes, and drop the wait entirely.

Ok. Let me scratch that out and I'll send it your way.

thanks
-john
--
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



[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux