[Kernel-packages] [Bug 1557172] Re: khubd/usbhid deadlock(?) creates processes in state D
Hi, we have the same problem with an old Celeron PC running Debian 8.8, is there a workaround? -- 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] [] flush_work+0x29/0x40 [198047.573605] [] ? start_worker+0x40/0x40 [198047.573609] [] __cancel_work_timer+0x9c/0x1b0 [198047.573623] [] cancel_work_sync+0x10/0x20 [198047.573632] [] hid_cancel_delayed_stuff+0x29/0x30 [usbhid] [198047.573640] [] usbhid_close+0xcc/0x110 [usbhid] [198047.573650] [] hidinput_close+0x22/0x30 [hid] [198047.573659] [] input_close_device+0x61/0x90 [198047.573663] [] evdev_cleanup+0xbf/0xd0 [198047.573670] [] evdev_disconnect+0x36/0x70 [198047.573674] []
[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
[Kernel-packages] [Bug 1557172] Re: khubd/usbhid deadlock(?) creates processes in state D
Looks like nobody cares about this issue?! -- 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] [] flush_work+0x29/0x40 [198047.573605] [] ? start_worker+0x40/0x40 [198047.573609] [] __cancel_work_timer+0x9c/0x1b0 [198047.573623] [] cancel_work_sync+0x10/0x20 [198047.573632] [] hid_cancel_delayed_stuff+0x29/0x30 [usbhid] [198047.573640] [] usbhid_close+0xcc/0x110 [usbhid] [198047.573650] [] hidinput_close+0x22/0x30 [hid] [198047.573659] [] input_close_device+0x61/0x90 [198047.573663] [] evdev_cleanup+0xbf/0xd0 [198047.573670] [] evdev_disconnect+0x36/0x70 [198047.573674] [] __input_unregister_device+0xc5/0x1a0 [198047.573678] []
[Kernel-packages] [Bug 1557172] Re: khubd/usbhid deadlock(?) creates processes in state D
I have the same problem with a Dell PowerEdge R210 II, with Dell DRAC under Ubuntu Server 14.04 LTS and 3.13 kernel: Process khubd will block in state D too. => need to do a hard reboot Screenshot of htop: https://lafibre.info/serveur-linux/load- average/msg372058/#msg372058 The "dmesg" data corresponding ; [11273834.551052] type=1400 audit(1473524094.532:28): apparmor="STATUS" operation="profile_replace" profile="unconfined" name="/sbin/dhclient" pid=22297 comm="apparmor_parser" [11273834.551236] type=1400 audit(1473524094.532:29): apparmor="STATUS" operation="profile_replace" profile="unconfined" name="/usr/lib/NetworkManager/nm-dhcp-client.action" pid=22297 comm="apparmor_parser" [11273834.551388] type=1400 audit(1473524094.532:30): apparmor="STATUS" operation="profile_replace" profile="unconfined" name="/usr/lib/connman/scripts/dhclient-script" pid=22297 comm="apparmor_parser" [11359185.861753] usb 1-1.1: reset full-speed USB device number 3 using ehci-pci [11359190.938076] usb 1-1.1: device descriptor read/64, error -32 [11359191.114227] usb 1-1.1: device descriptor read/64, error -32 [11359191.290375] usb 1-1.1: reset full-speed USB device number 3 using ehci-pci [11359191.362427] usb 1-1.1: device descriptor read/64, error -32 [11359191.538586] usb 1-1.1: device descriptor read/64, error -32 [11359191.714748] usb 1-1.1: reset full-speed USB device number 3 using ehci-pci [11359192.123084] usb 1-1.1: device not accepting address 3, error -32 [11359192.195140] usb 1-1.1: reset full-speed USB device number 3 using ehci-pci [11359192.603502] usb 1-1.1: device not accepting address 3, error -32 [11359192.604316] usb 1-1.1: USB disconnect, device number 3 [11359384.590873] INFO: task khubd:71 blocked for more than 120 seconds. [11359384.591241] Not tainted 3.13.0-85-generic #129-Ubuntu [11359384.591574] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [11359384.592047] khubd D 88043fc93180 071 2 0x [11359384.592052] 880428cd7c80 0046 8804293d6000 880428cd7fd8 [11359384.592057] 00013180 00013180 8804293d6000 880428c290e8 [11359384.592061] 880428c290ec 8804293d6000 880428c290f0 [11359384.592065] Call Trace: [11359384.592074] [] schedule_preempt_disabled+0x29/0x70 [11359384.592078] [] __mutex_lock_slowpath+0x135/0x1b0 [11359384.592082] [] mutex_lock+0x1f/0x2f [11359384.592088] [] usb_disconnect+0x64/0x200 [11359384.592091] [] hub_port_connect_change+0xd3/0xb20 [11359384.592096] [] ? hub_port_status+0xdd/0x120 [11359384.592099] [] hub_events+0x4d4/0xa20 [11359384.592102] [] hub_thread+0x35/0x160 [11359384.592106] [] ? prepare_to_wait_event+0x100/0x100 [11359384.592109] [] ? hub_events+0xa20/0xa20 [11359384.592113] [] kthread+0xd2/0xf0 [11359384.592117] [] ? kthread_create_on_node+0x1c0/0x1c0 [11359384.592121] [] ret_from_fork+0x58/0x90 [11359384.592125] [] ? kthread_create_on_node+0x1c0/0x1c0 [11359384.592133] INFO: task kworker/4:2:18579 blocked for more than 120 seconds. [11359384.592544] Not tainted 3.13.0-85-generic #129-Ubuntu [11359384.592869] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [11359384.593321] kworker/4:2 D 88043fd13180 0 18579 2 0x [11359384.593336] Workqueue: events hid_reset [usbhid] [11359384.593338] 8803f27af850 0046 8800badb9800 8803f27affd8 [11359384.593341] 00013180 00013180 8800badb9800 8803f27af998 [11359384.593345] 8803f27af9a0 7fff 8800badb9800 8800badb9800 [11359384.593348] Call Trace: [11359384.593352] [] schedule+0x29/0x70 [11359384.593355] [] schedule_timeout+0x279/0x320 [11359384.593359] [] ? __enqueue_entity+0x78/0x80 [11359384.593364] [] ? enqueue_entity+0x2ad/0xc00 [11359384.593367] [] wait_for_completion+0xa6/0x160 [11359384.593372] [] ? wake_up_state+0x20/0x20 [11359384.593377] [] flush_work+0xed/0x1b0 [11359384.593381] [] ? wake_up_worker+0x30/0x30 [11359384.593385] [] __cancel_work_timer+0x92/0x1a0 [11359384.593390] [] ? lock_timer_base.isra.35+0x2b/0x50 [11359384.593394] [] cancel_work_sync+0x10/0x20 [11359384.593400] [] usbhid_close+0xbc/0x100 [usbhid] [11359384.593407] [] hidinput_close+0x22/0x30 [hid] [11359384.593412] [] input_close_device+0x4a/0x70 [11359384.593417] [] evdev_cleanup+0xbf/0xd0 [11359384.593421] [] evdev_disconnect+0x2b/0x60 [11359384.593425] [] __input_unregister_device+0xc5/0x1b0 [11359384.593429] [] input_unregister_device+0x4d/0x80 [11359384.593436] [] hidinput_disconnect+0x96/0xc0 [hid] [11359384.593442] [] hid_disconnect+0x60/0x70 [hid] [11359384.593447] [] hid_device_remove+0xbd/0xd0 [hid] [11359384.593453] [] __device_release_driver+0x7f/0xf0 [11359384.593457] [] device_release_driver+0x23/0x30 [11359384.593461] [] bus_remove_device+0x108/0x180 [11359384.593464] [] device_del+0x129/0x1c0
[Kernel-packages] [Bug 1557172] Re: khubd/usbhid deadlock(?) creates processes in state D
[Expired for linux (Ubuntu) because there has been no activity for 60 days.] ** Changed in: linux (Ubuntu) Status: Incomplete => Expired -- 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: Expired 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] [] flush_work+0x29/0x40 [198047.573605] [] ? start_worker+0x40/0x40 [198047.573609] [] __cancel_work_timer+0x9c/0x1b0 [198047.573623] [] cancel_work_sync+0x10/0x20 [198047.573632] [] hid_cancel_delayed_stuff+0x29/0x30 [usbhid] [198047.573640] [] usbhid_close+0xcc/0x110 [usbhid] [198047.573650] [] hidinput_close+0x22/0x30 [hid] [198047.573659] [] input_close_device+0x61/0x90 [198047.573663] [] evdev_cleanup+0xbf/0xd0 [198047.573670] []
[Kernel-packages] [Bug 1557172] Re: khubd/usbhid deadlock(?) creates processes in state D
** Tags added: patch -- 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: Incomplete 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] [] flush_work+0x29/0x40 [198047.573605] [] ? start_worker+0x40/0x40 [198047.573609] [] __cancel_work_timer+0x9c/0x1b0 [198047.573623] [] cancel_work_sync+0x10/0x20 [198047.573632] [] hid_cancel_delayed_stuff+0x29/0x30 [usbhid] [198047.573640] [] usbhid_close+0xcc/0x110 [usbhid] [198047.573650] [] hidinput_close+0x22/0x30 [hid] [198047.573659] [] input_close_device+0x61/0x90 [198047.573663] [] evdev_cleanup+0xbf/0xd0 [198047.573670] [] evdev_disconnect+0x36/0x70 [198047.573674] [] __input_unregister_device+0xc5/0x1a0 [198047.573678] []
[Kernel-packages] [Bug 1557172] Re: khubd/usbhid deadlock(?) creates processes in state D
Made it a valid patch file (for Debian stable): amd64:/usr/src/linux-3.16.35# cd /usr/src/linux-3.16.35 amd64:/usr/src/linux-3.16.35# patch -p1 --dry-run https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1557172/+attachment/4673143/+files/hid-core.c-3.16-to-4.5.diff ** Patch added: "Difference between Debian 3.16 and 4.5 hid-core.c" https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1557172/+attachment/4673144/+files/hid-core.c-3.16-to-4.5.diff -- 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: Incomplete 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] [] flush_work+0x29/0x40 [198047.573605] [] ? start_worker+0x40/0x40 [198047.573609] [] __cancel_work_timer+0x9c/0x1b0 [198047.573623] []
[Kernel-packages] [Bug 1557172] Re: khubd/usbhid deadlock(?) creates processes in state D
I'm running Debian stable with the 4.5 kernel for 8 days without restart, now. First I did some 5 suspend/resumes without any error. Then I used it as my desktop machine, doing at least one suspend/resume every day. I'm convinced the issue I had is fixed in the 4.5 kernel. Attached the difference between the Debian 3.16 and 4.5 hid-core.c (hid-core.c-3.16-to-4.5.diff). It's quite a bit more than a one-line fix. ** Patch added: "Difference between Debian 3.16 and 4.5 hid-core.c" https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1557172/+attachment/4673143/+files/hid-core.c-3.16-to-4.5.diff -- 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: Incomplete 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
Maybe this patch "HID: usbhid: fix recursive deadlock" fixes the Ubuntu problem: https://lists.ubuntu.com/archives/kernel- team/2016-February/071250.html But that fix is in my Debian kernel: https://tracker.debian.org/media/packages/l/linux/changelog-3.16.7-ckt25-2 Maybe it did not fix all or it enabled another path to the same dead- lock. On my machine I got the same dead-lock after a few suspends or hibernates. I'm running the Debian/testing kernel (4.5.4-1) now: linux-image-4.5.0-2-amd64 With the 3.16 kernel it happened quite often, every 3 to 5 suspends or hibernates. -- 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: Incomplete 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] [] flush_work+0x29/0x40
[Kernel-packages] [Bug 1557172] Re: khubd/usbhid deadlock(?) creates processes in state D
For a few weeks I have the same bug in Debian/stable: linux-image-3.16.0-4-amd64 That kernel image is from 9th March. I upgraded on April 4. dpkg log says 3.16.7-ckt20-1+deb8u4 3.16.7-ckt25-1 -- 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: Incomplete 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] [] flush_work+0x29/0x40 [198047.573605] [] ? start_worker+0x40/0x40 [198047.573609] [] __cancel_work_timer+0x9c/0x1b0 [198047.573623] [] cancel_work_sync+0x10/0x20 [198047.573632] [] hid_cancel_delayed_stuff+0x29/0x30 [usbhid] [198047.573640] [] usbhid_close+0xcc/0x110 [usbhid] [198047.573650] [] hidinput_close+0x22/0x30 [hid] [198047.573659] [] input_close_device+0x61/0x90 [198047.573663] []
[Kernel-packages] [Bug 1557172] Re: khubd/usbhid deadlock(?) creates processes in state D
Anybody knows who is maintainer of khubd? -- 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: Incomplete 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] [] flush_work+0x29/0x40 [198047.573605] [] ? start_worker+0x40/0x40 [198047.573609] [] __cancel_work_timer+0x9c/0x1b0 [198047.573623] [] cancel_work_sync+0x10/0x20 [198047.573632] [] hid_cancel_delayed_stuff+0x29/0x30 [usbhid] [198047.573640] [] usbhid_close+0xcc/0x110 [usbhid] [198047.573650] [] hidinput_close+0x22/0x30 [hid] [198047.573659] [] input_close_device+0x61/0x90 [198047.573663] [] evdev_cleanup+0xbf/0xd0 [198047.573670] [] evdev_disconnect+0x36/0x70 [198047.573674] [] __input_unregister_device+0xc5/0x1a0 [198047.573678] []
[Kernel-packages] [Bug 1557172] Re: khubd/usbhid deadlock(?) creates processes in state D
All problems disappeared when I disconnected malfunctioning USB hub model EL-UDON-77151 (monitor stand). The issue appeared in kernels version 3.13 and 3.16. -- 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: Incomplete 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] [] flush_work+0x29/0x40 [198047.573605] [] ? start_worker+0x40/0x40 [198047.573609] [] __cancel_work_timer+0x9c/0x1b0 [198047.573623] [] cancel_work_sync+0x10/0x20 [198047.573632] [] hid_cancel_delayed_stuff+0x29/0x30 [usbhid] [198047.573640] [] usbhid_close+0xcc/0x110 [usbhid] [198047.573650] [] hidinput_close+0x22/0x30 [hid] [198047.573659] [] input_close_device+0x61/0x90 [198047.573663] [] evdev_cleanup+0xbf/0xd0 [198047.573670]
[Kernel-packages] [Bug 1557172] Re: khubd/usbhid deadlock(?) creates processes in state D
Hi, sorry for the lack of update. In the meantime I've seen reports of a few cases of this on actual desktops and laptops, so the workaround of disabling the usbhid dirver via udev isn't really an option there :) Our setup relies on a handful of out-of-tree modules that don't seem to build on 4.5.2, and since this tends to only happen after about a week of use I don't think I'll be able to find anyone who'd be able to test the 4.5.2 mainline kernel. I do know that these modules compile on the wily kernel, though. Would it be helpful to test against that? I'll start trying to get some machines trying to reproduce this on the wily kernel, but let me know if there's anything else I can do that might help to debug this. -- 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: Incomplete 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]
[Kernel-packages] [Bug 1557172] Re: khubd/usbhid deadlock(?) creates processes in state D
Hi, can you look please at http://ubuntuforums.org/showthread.php?t=2321068 it appears pretty close to described issue. I can provide more details upon request. ** Attachment added: "Call trace" https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1557172/+attachment/4640610/+files/k.txt.gz -- 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: Incomplete 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] [] flush_work+0x29/0x40 [198047.573605] [] ? start_worker+0x40/0x40 [198047.573609] [] __cancel_work_timer+0x9c/0x1b0 [198047.573623] [] cancel_work_sync+0x10/0x20 [198047.573632] [] hid_cancel_delayed_stuff+0x29/0x30 [usbhid] [198047.573640] [] usbhid_close+0xcc/0x110 [usbhid] [198047.573650] []
[Kernel-packages] [Bug 1557172] Re: khubd/usbhid deadlock(?) creates processes in state D
Hi Joseph I'll see if I can nab some extra hardware to try it out. Keep in mind that I haven't found a way to reproduce this reliably yet, with our usual setup it can take a few weeks before it happens. Basically we have a cron job that periodically exports the state of our machines, which includes calling lsusb. Eventually this bug happens, all future calls to the job get stuck in D, and the machine eventually runs out of resources, requiring it to be rebooted. I did browse kernel sources upstream and didn't notice anything that would appear to fix this issue, but I'm certainly no kernel-guru. -- 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: Incomplete 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
Would it be possible for you to test the latest upstream kernel? Refer to https://wiki.ubuntu.com/KernelMainlineBuilds . Please test the latest v4.5 kernel[0]. If this bug is fixed in the mainline kernel, please add the following tag 'kernel-fixed-upstream'. If the mainline kernel does not fix this bug, please add the tag: 'kernel-bug-exists-upstream'. Once testing of the upstream kernel is complete, please mark this bug as "Confirmed". Thanks in advance. [0] http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.5-wily/ ** Changed in: linux (Ubuntu) Importance: Undecided => Medium ** Changed in: linux (Ubuntu) Status: Confirmed => Incomplete ** Tags added: kernel-da-key -- 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: Incomplete 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
[Kernel-packages] [Bug 1557172] Re: khubd/usbhid deadlock(?) creates processes in state D
Sorry, I'm not super familiar with apport (our security folks make us disable it because they get upset for reasons I don't quite grasp). I tried to install apport and python-apport, but no dice on actually running apport-collect. $ apport-collect 1557172 Traceback (most recent call last): File "/usr/bin/apport-cli", line 370, in if not app.run_argv(): File "/usr/lib/python2.7/dist-packages/apport/ui.py", line 653, in run_argv return self.run_update_report() File "/usr/lib/python2.7/dist-packages/apport/ui.py", line 525, in run_update_report pkgs = self.crashdb.get_affected_packages(self.options.update_report) File "/usr/lib/python2.7/dist-packages/apport/crashdb_impl/memory.py", line 79, in get_affected_packages return [self.reports[id]['report']['SourcePackage']] IndexError: list index out of range Is there some other way for me to get the info you need? ** Changed in: linux (Ubuntu) Status: Incomplete => Confirmed -- 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
