[Kernel-packages] [Bug 1557172] Re: khubd/usbhid deadlock(?) creates processes in state D
Mike: I did read that from the original post. Just that preventing the iDRAC from working would prevent remote access to the terminal which is sometimes required at our end - typically contingencies when there is some issue with network, we use the iDRAC for remote access. Unlike your situation, this bug affects all our servers with iDRAC (R410 & R610) running Ubuntu 14.05.1. Can you help me with the command which can be run if iDRAC access is required? I know this might create the hung process again but for us we use iDRAC in contingency scenarios only & would not mind restarting once things are restored. -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1557172 Title: khubd/usbhid deadlock(?) creates processes in state D Status in linux package in Ubuntu: Confirmed Bug description: (Note that the attached logs are not a machine exhibiting the issue) I've observed this issue specifically on Dell's PowerEdge R410 with its DRAC. I manage quite a few other machines with DRACs and haven't seen this issue so it may be limited to the R410. I've seen cases of this both with the precise and trusty kernel. Basically, what happens is that things that read any info about the DRAC's usbhid device will block in an uninterruptible state. A quick way to do this is with "cat /sys/devices/pci:00/:00:1d.0/usb5/5-2/manufacturer". This means that commands like lspci will block as well. The thing is that it doesn't happen every time, but once it happens the first time all future reads on the device will block in state D too. This is also associated with the following from the kernel (first from a precise machine): [197852.595820] usb 5-2: reset full-speed USB device number 2 using uhci_hcd [197857.716899] usb 5-2: device descriptor read/64, error -71 [197857.944966] usb 5-2: device descriptor read/64, error -71 [197858.165020] usb 5-2: reset full-speed USB device number 2 using uhci_hcd [197858.285090] usb 5-2: device descriptor read/64, error -71 [197858.513108] usb 5-2: device descriptor read/64, error -71 [197858.733154] usb 5-2: reset full-speed USB device number 2 using uhci_hcd [197859.145214] usb 5-2: device not accepting address 2, error -71 [197859.261234] usb 5-2: reset full-speed USB device number 2 using uhci_hcd [197859.669322] usb 5-2: device not accepting address 2, error -71 [197859.675357] usb 5-2: USB disconnect, device number 2 [198047.530714] INFO: task khubd:203 blocked for more than 120 seconds. [198047.537147] Not tainted 3.13.0-74-generic #118~precise1-Ubuntu [198047.543691] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [198047.551792] khubd D 880803fe18a0 0 203 2 0x [198047.551803] 8810036b1c18 0046 88102fc53180 8810036b1fd8 [198047.551809] 00013180 00013180 881003f7c800 880804634800 [198047.551814] 8810036b1c38 8810020908e8 8810020908ec [198047.551819] Call Trace: [198047.551828] [] schedule+0x29/0x70 [198047.551833] [] schedule_preempt_disabled+0xe/0x10 [198047.551837] [] __mutex_lock_slowpath+0x114/0x1b0 [198047.551845] [] ? usb_alloc_urb+0x1e/0x50 [198047.551848] [] mutex_lock+0x23/0x37 [198047.551852] [] usb_disconnect+0x5a/0x210 [198047.551857] [] ? usb_control_msg+0xea/0x110 [198047.551860] [] hub_port_connect_change+0xcf/0x9c0 [198047.551864] [] ? hub_port_status+0xd5/0x120 [198047.551868] [] hub_events+0x464/0x8c0 [198047.551871] [] ? __schedule+0x38e/0x700 [198047.551875] [] hub_thread+0x35/0x150 [198047.551881] [] ? __wake_up_sync+0x20/0x20 [198047.551885] [] ? hub_events+0x8c0/0x8c0 [198047.551890] [] kthread+0xc9/0xe0 [198047.551893] [] ? flush_kthread_worker+0xb0/0xb0 [198047.551898] [] ret_from_fork+0x58/0x90 [198047.551902] [] ? flush_kthread_worker+0xb0/0xb0 [198047.551908] INFO: task kworker/9:1:246 blocked for more than 120 seconds. [198047.558892] Not tainted 3.13.0-74-generic #118~precise1-Ubuntu [198047.565491] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [198047.573524] kworker/9:1 D 880803fe18a0 0 246 2 0x [198047.573547] Workqueue: events hid_reset [usbhid] [198047.573550] 8808011f9788 0046 88080fc93180 8808011f9fd8 [198047.573555] 00013180 00013180 881003f94800 8808011f [198047.573559] 8808011f9798 8808011f98d8 7fff 7fff [198047.573564] Call Trace: [198047.573579] [] schedule+0x29/0x70 [198047.573582] [] schedule_timeout+0x1e5/0x250 [198047.573587] [] ? wake_affine+0x16d/0x2d0 [198047.573591] [] wait_for_completion+0xa7/0x160 [198047.573596] [] ? try_to_wake_up+0x210/0x210 [198047.573602] []
[Kernel-packages] [Bug 1557172] Re: khubd/usbhid deadlock(?) creates processes in state D
Mike - checking if you have found a workaround or any temporary fix for this issue ? I have faced the same problem on an R410 with iDRAC running trusty kernel. Following are the logs from my server: [3903494.645100] usb 5-2: reset full-speed USB device number 2 using uhci_hcd [3903499.760216] usb 5-2: device descriptor read/64, error -110 [3903499.984358] usb 5-2: device descriptor read/64, error -71 [3903500.200497] usb 5-2: reset full-speed USB device number 2 using uhci_hcd [3903500.320567] usb 5-2: device descriptor read/64, error -71 [3903500.544709] usb 5-2: device descriptor read/64, error -71 [3903500.760848] usb 5-2: reset full-speed USB device number 2 using uhci_hcd [3903501.169123] usb 5-2: device not accepting address 2, error -71 [3903501.281153] usb 5-2: reset full-speed USB device number 2 using uhci_hcd [3903501.689411] usb 5-2: device not accepting address 2, error -71 [3903501.689842] usb 5-2: USB disconnect, device number 2 [3903717.219659] INFO: task khubd:119 blocked for more than 120 seconds. [3903717.220045] Not tainted 3.13.0-100-generic #147-Ubuntu [3903717.220441] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [3903717.220975] khubd D 88012b293180 0 119 2 0x [3903717.220980] 880128f85c80 0046 880128ece000 00013180 [3903717.220984] 880128f85fd8 00013180 880128ece000 8801253da0e8 [3903717.220988] 8801253da0ec 880128ece000 8801253da0f0 [3903717.220992] Call Trace: [3903717.221002] [] schedule_preempt_disabled+0x29/0x70 [3903717.221006] [] __mutex_lock_slowpath+0x135/0x1b0 [3903717.221010] [] mutex_lock+0x1f/0x2f [3903717.221016] [] usb_disconnect+0x64/0x200 [3903717.221019] [] hub_port_connect_change+0xd3/0xb30 [3903717.221023] [] ? hub_port_status+0xdd/0x120 [3903717.221026] [] hub_events+0x4d4/0xa20 [3903717.221030] [] hub_thread+0x35/0x150 [3903717.221034] [] ? prepare_to_wait_event+0x100/0x100 [3903717.221037] [] ? hub_events+0xa20/0xa20 [3903717.221041] [] kthread+0xc9/0xe0 [3903717.221045] [] ? kthread_create_on_node+0x1c0/0x1c0 [3903717.221050] [] ret_from_fork+0x58/0x90 [3903717.221053] [] ? kthread_create_on_node+0x1c0/0x1c0 [3903717.221064] INFO: task kworker/2:1:12543 blocked for more than 120 seconds. [3903717.221495] Not tainted 3.13.0-100-generic #147-Ubuntu [3903717.221828] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [3903717.85] kworker/2:1 D 88012b253180 0 12543 2 0x [3903717.99] Workqueue: events hid_reset [usbhid] [3903717.222301] 880036091850 0046 8800c4c4 00013180 [3903717.222304] 880036091fd8 00013180 8800c4c4 880036091998 [3903717.222308] 8800360919a0 7fff 8800c4c4 8800c4c4 [3903717.222312] Call Trace: [3903717.222315] [] schedule+0x29/0x70 [3903717.222318] [] schedule_timeout+0x279/0x310 [3903717.222323] [] ? __enqueue_entity+0x78/0x80 [3903717.222327] [] ? enqueue_entity+0x2ad/0xc00 [3903717.222331] [] wait_for_completion+0xa6/0x150 [3903717.222336] [] ? wake_up_state+0x20/0x20 ... ... -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1557172 Title: khubd/usbhid deadlock(?) creates processes in state D Status in linux package in Ubuntu: Confirmed Bug description: (Note that the attached logs are not a machine exhibiting the issue) I've observed this issue specifically on Dell's PowerEdge R410 with its DRAC. I manage quite a few other machines with DRACs and haven't seen this issue so it may be limited to the R410. I've seen cases of this both with the precise and trusty kernel. Basically, what happens is that things that read any info about the DRAC's usbhid device will block in an uninterruptible state. A quick way to do this is with "cat /sys/devices/pci:00/:00:1d.0/usb5/5-2/manufacturer". This means that commands like lspci will block as well. The thing is that it doesn't happen every time, but once it happens the first time all future reads on the device will block in state D too. This is also associated with the following from the kernel (first from a precise machine): [197852.595820] usb 5-2: reset full-speed USB device number 2 using uhci_hcd [197857.716899] usb 5-2: device descriptor read/64, error -71 [197857.944966] usb 5-2: device descriptor read/64, error -71 [197858.165020] usb 5-2: reset full-speed USB device number 2 using uhci_hcd [197858.285090] usb 5-2: device descriptor read/64, error -71 [197858.513108] usb 5-2: device descriptor read/64, error -71 [197858.733154] usb 5-2: reset full-speed USB device number 2 using uhci_hcd [197859.145214] usb 5-2: device not accepting address 2, error -71 [197859.261234] usb 5-2: reset full-speed USB
