Created attachment 289275 [details] DMesg of the hang with kernel-5.4.26-050426 Since I've moved from kernel 4.15 to kernel 5, the USB hub managed of my Thinkpad Dock doesn't seem to work well after some usage (unfortunately is quite hard to find a reproducer, as it "just happens", normally while writing). This seems to be mostly triggered by the usage of an USB keyboard, as when the USB traffic is limited to other devices, it doesn't seem to happen. [ +0,136020] Freezing of tasks failed after 20.006 seconds (2 tasks refusing to freeze, wq_busy=0): [ +0,000387] device poll D 0 22575 4818 0x00000004 [ +0,000006] Call Trace: [ +0,000014] __schedule+0x2e3/0x740 [ +0,000005] ? __switch_to_asm+0x40/0x70 [ +0,000003] ? __switch_to_asm+0x34/0x70 [ +0,000006] schedule+0x42/0xb0 [ +0,000005] schedule_preempt_disabled+0xe/0x10 [ +0,000005] __mutex_lock.isra.0+0x182/0x4f0 [ +0,000008] ? device_match_of_node+0x20/0x20 [ +0,000005] __mutex_lock_slowpath+0x13/0x20 [ +0,000005] mutex_lock+0x2e/0x40 [ +0,000007] usbdev_open+0xd9/0x240 [ +0,000007] chrdev_open+0xd3/0x1c0 [ +0,000006] ? cdev_default_release+0x20/0x20 [ +0,000006] do_dentry_open+0x143/0x3a0 [ +0,000006] vfs_open+0x2d/0x30 [ +0,000005] do_last+0x194/0x900 [ +0,000006] path_openat+0x8d/0x290 [ +0,000006] do_filp_open+0x91/0x100 [ +0,000006] ? __alloc_fd+0x46/0x150 [ +0,000006] do_sys_open+0x17f/0x230 [ +0,000007] __x64_sys_openat+0x20/0x30 [ +0,000006] do_syscall_64+0x57/0x190 [ +0,000004] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [ +0,000005] RIP: 0033:0x7f9942175d19 [ +0,000010] Code: Bad RIP value. [ +0,000003] RSP: 002b:00007f9940d2dab0 EFLAGS: 00000293 ORIG_RAX: 0000000000000101 [ +0,000005] RAX: ffffffffffffffda RBX: 00007f9930000bab RCX: 00007f9942175d19 [ +0,000002] RDX: 0000000000080000 RSI: 00007f9930010bf0 RDI: 00000000ffffff9c [ +0,000002] RBP: 0000000000080000 R08: 0000000000000000 R09: 0000000000000000 [ +0,000002] R10: 0000000000000000 R11: 0000000000000293 R12: 00007f9930010bf0 [ +0,000002] R13: 00007f9930010bf0 R14: 00007f9930000b20 R15: 000055ed68c60c60 [ +0,000094] colord-sane D 0 4630 3097 0x00000004 [ +0,000005] Call Trace: [ +0,000006] __schedule+0x2e3/0x740 [ +0,000004] ? __switch_to_asm+0x40/0x70 [ +0,000003] ? __switch_to_asm+0x34/0x70 [ +0,000005] schedule+0x42/0xb0 [ +0,000005] schedule_preempt_disabled+0xe/0x10 [ +0,000005] __mutex_lock.isra.0+0x182/0x4f0 [ +0,000006] ? device_match_of_node+0x20/0x20 [ +0,000006] __mutex_lock_slowpath+0x13/0x20 [ +0,000005] mutex_lock+0x2e/0x40 [ +0,000005] usbdev_open+0xd9/0x240 [ +0,000006] chrdev_open+0xd3/0x1c0 [ +0,000006] ? cdev_default_release+0x20/0x20 [ +0,000005] do_dentry_open+0x143/0x3a0 [ +0,000006] vfs_open+0x2d/0x30 [ +0,000004] do_last+0x194/0x900 [ +0,000006] path_openat+0x8d/0x290 [ +0,000005] ? do_anonymous_page+0x2e6/0x650 [ +0,000005] do_filp_open+0x91/0x100 [ +0,000005] ? __alloc_fd+0x46/0x150 [ +0,000006] do_sys_open+0x17f/0x230 [ +0,000006] __x64_sys_openat+0x20/0x30 [ +0,000006] do_syscall_64+0x57/0x190 [ +0,000004] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [ +0,000002] RIP: 0033:0x7f9e090a1dae [ +0,000006] Code: Bad RIP value. [ +0,000002] RSP: 002b:00007ffd77440af0 EFLAGS: 00000293 ORIG_RAX: 0000000000000101 [ +0,000004] RAX: ffffffffffffffda RBX: 00005608306a3450 RCX: 00007f9e090a1dae [ +0,000002] RDX: 0000000000000000 RSI: 00007ffd77441c10 RDI: 00000000ffffff9c [ +0,000002] RBP: 00000000ffffffff R08: 0000000000000000 R09: 000056083069373b [ +0,000002] R10: 0000000000000000 R11: 0000000000000293 R12: 00007f9df790a110 [ +0,000002] R13: 00005608306a3460 R14: 0000000000000000 R15: 00007ffd77441c10 [ +0,000010] OOM killer enabled. [ +0,000001] Restarting tasks ... done. [ +0,030746] thermal thermal_zone3: failed to read out thermal zone (-61) [ +0,059657] PM: suspend exit [ +0,000065] PM: suspend entry (s2idle) [ +0,014476] Filesystems sync: 0.014 seconds [ +0,000348] Freezing user space processes ... [ +0,397649] usb 2-4.2: reset SuperSpeed Gen 1 USB device number 13 using xhci_hcd
Created attachment 289277 [details] lsusb Attaching lsusb while hanging, to notice that even if I detach the laptop from the dock all the USB devices are still shown, although not working.
Not sure if this is totally related to the dock or more likely to an USB mechanical keyboard (both TEX Yoda II and TEX Shinobi - this one is also bluetooth when connected) that seems to behave differently. This is on kernel 5.4.0-42-generic (ubuntu) In the middle of using it I've got a: set 01 18:35:44 tricky kernel: usb 1-3.2.3: reset full-speed USB device number 33 using xhci_hcd set 01 18:36:11 tricky acpid[2940]: input device has been disconnected, fd 28 set 01 18:36:11 tricky acpid[2940]: input device has been disconnected, fd 29 set 01 18:36:13 tricky kernel: Bluetooth: hci0: advertising data len corrected set 01 18:36:16 tricky kernel: input: TEX-BLE-KB-1 Mouse as /devices/virtual/misc/uhid/0005:0000:0000.0038/input/input108 set 01 18:36:16 tricky kernel: input: TEX-BLE-KB-1 Keyboard as /devices/virtual/misc/uhid/0005:0000:0000.0038/input/input109 set 01 18:36:16 tricky kernel: input: TEX-BLE-KB-1 Consumer Control as /devices/virtual/misc/uhid/0005:0000:0000.0038/input/input110 set 01 18:36:16 tricky kernel: hid-generic 0005:0000:0000.0038: input,hidraw4: BLUETOOTH HID v0.00 Mouse [TEX-BLE-KB-1] on 44:85:00:64:22:b9 set 01 18:36:16 tricky systemd-logind[3018]: Watching system buttons on /dev/input/event26 (TEX-BLE-KB-1 Keyboard) set 01 18:38:11 tricky kernel: INFO: task kworker/u16:8:183192 blocked for more than 120 seconds. set 01 18:38:11 tricky kernel: Tainted: G C OE K 5.4.0-42-generic #46-Ubuntu set 01 18:38:11 tricky kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. set 01 18:38:11 tricky kernel: kworker/u16:8 D 0 183192 2 0x80004000 set 01 18:38:11 tricky kernel: Workqueue: scsi_tmf_4 scmd_eh_abort_handler set 01 18:38:11 tricky kernel: Call Trace: set 01 18:38:11 tricky kernel: __schedule+0x2e3/0x740 set 01 18:38:11 tricky kernel: schedule+0x42/0xb0 set 01 18:38:11 tricky kernel: schedule_timeout+0x203/0x2f0 set 01 18:38:11 tricky kernel: wait_for_completion+0xb1/0x120 set 01 18:38:11 tricky kernel: ? wake_up_q+0x70/0x70 set 01 18:38:11 tricky kernel: command_abort+0x60/0xa0 [usb_storage] set 01 18:38:11 tricky kernel: scmd_eh_abort_handler+0x8d/0x220 set 01 18:38:11 tricky kernel: process_one_work+0x1eb/0x3b0 set 01 18:38:11 tricky kernel: worker_thread+0x4d/0x400 set 01 18:38:11 tricky kernel: kthread+0x104/0x140 set 01 18:38:11 tricky kernel: ? process_one_work+0x3b0/0x3b0 set 01 18:38:11 tricky kernel: ? kthread_park+0x90/0x90 ... repeated various times ... Then when trying to reonnect: set 01 21:34:08 tricky kernel: usb 1-3: USB disconnect, device number 30 set 01 21:34:08 tricky kernel: usb 1-3.2: USB disconnect, device number 31 set 01 21:34:08 tricky kernel: usb 1-3.3: cannot submit urb (err = -19) set 01 21:34:08 tricky kernel: usb 1-3.3: cannot submit urb 0, error -19: no device set 01 21:34:08 tricky kernel: usb 2-4: USB disconnect, device number 10 set 01 21:34:08 tricky kernel: usb 2-4.2: USB disconnect, device number 11 Then it fails when trying to suspend: set 01 21:34:54 tricky kernel: PM: suspend entry (deep) set 01 21:34:54 tricky systemd-sleep[319991]: Suspending system... set 01 21:34:54 tricky kernel: Filesystems sync: 0.012 seconds set 01 21:35:14 tricky kernel: Freezing user space processes ... (elapsed 0.005 seconds) done. set 01 21:35:14 tricky kernel: OOM killer disabled. set 01 21:35:14 tricky kernel: Freezing remaining freezable tasks ... set 01 21:35:14 tricky kernel: Freezing of tasks failed after 20.008 seconds (0 tasks refusing to freeze, wq_busy=1): set 01 21:35:14 tricky kernel: Showing busy workqueues and worker pools: set 01 21:35:14 tricky kernel: workqueue events_freezable: flags=0x4 set 01 21:35:14 tricky kernel: pwq 0: cpus=0 node=0 flags=0x0 nice=0 active=0/0 refcnt=2 set 01 21:35:14 tricky kernel: delayed: pci_pme_list_scan set 01 21:35:14 tricky kernel: workqueue events_freezable_power_: flags=0x86 set 01 21:35:14 tricky kernel: pwq 16: cpus=0-7 flags=0x4 nice=0 active=1/0 refcnt=3 set 01 21:35:14 tricky kernel: in-flight: 255885:disk_events_workfn set 01 21:35:14 tricky kernel: workqueue usb_hub_wq: flags=0x4 set 01 21:35:14 tricky kernel: pwq 0: cpus=0 node=0 flags=0x0 nice=0 active=4/0 refcnt=5 set 01 21:35:14 tricky kernel: in-flight: 314094:hub_event hub_event, 279442:hub_event hub_event set 01 21:35:14 tricky kernel: workqueue scsi_tmf_4: flags=0x2000a set 01 21:35:14 tricky kernel: pwq 16: cpus=0-7 flags=0x4 nice=0 active=1/1 refcnt=3 set 01 21:35:14 tricky kernel: in-flight: 183192:scmd_eh_abort_handler set 01 21:35:14 tricky kernel: pool 0: cpus=0 node=0 flags=0x0 nice=0 hung=0s workers=5 idle: 319427 317598 319488 set 01 21:35:14 tricky kernel: pool 16: cpus=0-7 flags=0x4 nice=0 hung=1s workers=13 idle: 311397 312581 300348 280847 275132 317871 252113 305935 212775 279932 300931 set 01 21:35:14 tricky kernel: Restarting kernel threads ... done. set 01 21:35:14 tricky kernel: OOM killer enabled. set 01 21:35:14 tricky kernel: Restarting tasks ... done. Rebooting seems to be the only option.
Ah, the presence of storage in the logs may be due to the fact that the keyboard has an USB storage as well but that's enabled (at lest logically) via an HW jumper, that is normally off.
What happens if you remove the jumper, so as to disable the USB storage on the keyboard?
(In reply to Alan Stern from comment #4) > What happens if you remove the jumper, so as to disable the USB storage on > the keyboard? Sorry, I probably didn't explain this properly. The I always keep the jumper in "off" state (so there's no USB storage active), but I'm not sure if that's advertised anyways at HW level. This is lsusb -v output for one affected keyboard (TEX Yoda II), when the USB storage is OFF (at jumper level), but still I see that it notifies an "SCSI Mass Storage" interface, that might be the reason why we have such issue. Not sure if the keyboard enables it logically for few moments and that confuses the kernel or what... us 001 Device 006: ID 04d9:0163 Holtek Semiconductor, Inc. USB-HID Keyboard Couldn't open device, some information will be missing Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 1.10 bDeviceClass 0 bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 64 idVendor 0x04d9 Holtek Semiconductor, Inc. idProduct 0x0163 bcdDevice 11.01 iManufacturer 0 iProduct 1 iSerial 3 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 0x0072 bNumInterfaces 4 bConfigurationValue 1 iConfiguration 0 bmAttributes 0xa0 (Bus Powered) Remote Wakeup MaxPower 100mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 3 Human Interface Device bInterfaceSubClass 1 Boot Interface Subclass bInterfaceProtocol 1 Keyboard iInterface 0 HID Device Descriptor: bLength 9 bDescriptorType 33 bcdHID 1.11 bCountryCode 0 Not supported bNumDescriptors 1 bDescriptorType 34 Report wDescriptorLength 64 Report Descriptors: ** UNAVAILABLE ** Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0008 1x 8 bytes bInterval 1 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 1 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 3 Human Interface Device bInterfaceSubClass 0 bInterfaceProtocol 0 iInterface 2 HID Device Descriptor: bLength 9 bDescriptorType 33 bcdHID 1.11 bCountryCode 0 Not supported bNumDescriptors 1 bDescriptorType 34 Report wDescriptorLength 34 Report Descriptors: ** UNAVAILABLE ** Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x83 EP 3 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 1 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x04 EP 4 OUT bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 1 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 2 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 3 Human Interface Device bInterfaceSubClass 0 bInterfaceProtocol 0 iInterface 0 HID Device Descriptor: bLength 9 bDescriptorType 33 bcdHID 1.11 bCountryCode 0 Not supported bNumDescriptors 1 bDescriptorType 34 Report wDescriptorLength 170 Report Descriptors: ** UNAVAILABLE ** Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 1 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 3 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 8 Mass Storage bInterfaceSubClass 6 SCSI bInterfaceProtocol 80 Bulk-Only iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x86 EP 6 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x07 EP 7 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 0 PS: I also replicated this with kernel 5.6.0
Hello everyone, I have the same problem with a TeX Shinobi. On Kernel 5.11.7. Is there anything that could help to debug the issue? It is a bit hard because it seems to happen sporadic at some time. I also think it is weird that the kernel sees the Mass Storage Device even the jumper is inactive. Best regards, Johannes
And and I forget to mention that I use a different Hub. This is the information in lsusb: Bus 003 Device 004: ID 1a40:0201 Terminus Technology Inc. FE 2.1 7-port Hub
Suppose you install the jumper so that the mass-storage device is enabled. Does that help the problem? Marco's log suggests that the colord-sane program is somehow related to the problem. What happens if the program isn't running? Is the dock involved in the problem? WHat happens if you attach the keyboard without using the dock?
FWIW, I'm using kernel 5.6.0 now and with this I NEVER get the problem if the keyboard is connected to my laptop USB ports. Instead, it's happening all the times when using the dock's port. So I can be quite sure that the problem is more in the module handling the dock USB hub. Colord doesn't seem to have any role here, as just switching the port in use fixes the issue.
I also have this issue- TEX Shinobi connected through a USB3 hub to a Thinkpad X13 AMD Gen 1 (Fedora 33, kernel 5.11.11 but have experienced this back to at least 5.9). Previously, I had thought a USB Dock to also be at fault, but the issue also occurs with a usb 4-port hub. The last dmesg before the keyboard stops responding is a usb device reset: usb 6-2.4: reset full-speed USB device number 11 using xhci_hcd In my case, it also causes udisksd to block on IO which ultimately prevents a clean shutdown. I'm also interested in helping debug the issue but would need some guidance. Here are the things I'm going to try: Per Alan's suggestion in #8, enabling Mass Storage mode (DIP 6 = on, per the manual [https://tex.com.tw/pages/user-manual]). This shows a 448KB disk (as apposed to 'no media') and the keyboard continues to work. Move other devices to a different USB hub (just keyboard -> hub -> computer) Directly connect keyboard (expect the issue to not occur) Thanks and best regards, Jonathan
Still happening on Archlinux with Kernel 5.13.12.
But at least the Call-Trace looks a bit more helpful (mentions hub_event) and seems to hang in a mutex: [ +43.245062] INFO: task kworker/0:1:19 blocked for more than 245 seconds. [ +0.000014] Tainted: P OE 5.13.12-arch1-1 #1 [ +0.000005] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ +0.000004] task:kworker/0:1 state:D stack: 0 pid: 19 ppid: 2 flags:0x00004000 [ +0.000011] Workqueue: usb_hub_wq hub_event [ +0.000015] Call Trace: [ +0.000005] __schedule+0x310/0x930 [ +0.000013] schedule+0x5b/0xc0 [ +0.000007] schedule_preempt_disabled+0x11/0x20 [ +0.000008] __mutex_lock.constprop.0+0x2f8/0x4e0 [ +0.000011] hub_event+0x1a8/0x17f0 [ +0.000011] ? finish_task_switch.isra.0+0xaa/0x290 [ +0.000012] process_one_work+0x1e3/0x3b0 [ +0.000010] worker_thread+0x50/0x3b0 [ +0.000007] ? process_one_work+0x3b0/0x3b0 [ +0.000007] kthread+0x133/0x160 [ +0.000005] ? set_kthread_struct+0x40/0x40 [ +0.000006] ret_from_fork+0x22/0x30 [ +0.000022] INFO: task kworker/u8:2:84 blocked for more than 245 seconds. [ +0.000006] Tainted: P OE 5.13.12-arch1-1 #1 [ +0.000004] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ +0.000003] task:kworker/u8:2 state:D stack: 0 pid: 84 ppid: 2 flags:0x00004000 [ +0.000007] Workqueue: scsi_tmf_8 scmd_eh_abort_handler [ +0.000012] Call Trace: [ +0.000003] __schedule+0x310/0x930 [ +0.000008] schedule+0x5b/0xc0 [ +0.000007] schedule_timeout+0x11c/0x160 [ +0.000011] wait_for_completion+0xa3/0x100 [ +0.000011] command_abort+0x63/0x80 [usb_storage] [ +0.000013] scmd_eh_abort_handler+0x7e/0x230 [ +0.000009] process_one_work+0x1e3/0x3b0 [ +0.000008] worker_thread+0x50/0x3b0 [ +0.000007] ? process_one_work+0x3b0/0x3b0 [ +0.000007] kthread+0x133/0x160 [ +0.000005] ? set_kthread_struct+0x40/0x40 [ +0.000005] ret_from_fork+0x22/0x30 [ +0.000036] INFO: task udisksd:2185 blocked for more than 245 seconds. [ +0.000005] Tainted: P OE 5.13.12-arch1-1 #1 [ +0.000004] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ +0.000003] task:udisksd state:D stack: 0 pid: 2185 ppid: 1 flags:0x00000000 [ +0.000007] Call Trace: [ +0.000003] __schedule+0x310/0x930 [ +0.000008] schedule+0x5b/0xc0 [ +0.000007] schedule_timeout+0x11c/0x160 [ +0.000009] wait_for_completion+0xa3/0x100 [ +0.000008] __flush_work.isra.0+0x15b/0x210 [ +0.000008] ? flush_workqueue_prep_pwqs+0x130/0x130 [ +0.000008] __cancel_work_timer+0x12e/0x1c0 [ +0.000010] disk_block_events+0x6f/0x90 [ +0.000007] blkdev_get_by_dev+0xe5/0x220 [ +0.000008] ? blkdev_get_by_dev+0x220/0x220 [ +0.000006] blkdev_open+0x4c/0x90 [ +0.000006] do_dentry_open+0x14b/0x380 [ +0.000013] path_openat+0xb93/0x1000 [ +0.000010] ? _copy_to_iter+0xdb/0x7b0 [ +0.000008] do_filp_open+0xa5/0x150 [ +0.000014] do_sys_openat2+0xb0/0x160 [ +0.000006] __x64_sys_openat+0x53/0x90 [ +0.000006] do_syscall_64+0x61/0x80 [ +0.000008] ? exc_page_fault+0x78/0x180 [ +0.000009] entry_SYSCALL_64_after_hwframe+0x44/0xae [ +0.000012] RIP: 0033:0x7f7a234a5f04 [ +0.000006] RSP: 002b:00007ffc593edb50 EFLAGS: 00000293 ORIG_RAX: 0000000000000101 [ +0.000007] RAX: ffffffffffffffda RBX: 00007ffc593edc54 RCX: 00007f7a234a5f04 [ +0.000004] RDX: 0000000000000000 RSI: 000055a67b147e40 RDI: 00000000ffffff9c [ +0.000005] RBP: 000055a67b147e40 R08: 0000000000000000 R09: 463801417d483af5 [ +0.000003] R10: 0000000000000000 R11: 0000000000000293 R12: 0000000000000000 [ +0.000004] R13: 0000000000000000 R14: 000055a67b12b160 R15: 000055a67a59a828 [Aug25 18:36] INFO: task kworker/0:1:19 blocked for more than 368 seconds. [ +0.000014] Tainted: P OE 5.13.12-arch1-1 #1 [ +0.000005] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ +0.000004] task:kworker/0:1 state:D stack: 0 pid: 19 ppid: 2 flags:0x00004000 [ +0.000011] Workqueue: usb_hub_wq hub_event [ +0.000014] Call Trace: [ +0.000006] __schedule+0x310/0x930 [ +0.000012] schedule+0x5b/0xc0 [ +0.000007] schedule_preempt_disabled+0x11/0x20 [ +0.000007] __mutex_lock.constprop.0+0x2f8/0x4e0 [ +0.000011] hub_event+0x1a8/0x17f0 [ +0.000012] ? finish_task_switch.isra.0+0xaa/0x290 [ +0.000012] process_one_work+0x1e3/0x3b0 [ +0.000010] worker_thread+0x50/0x3b0 [ +0.000007] ? process_one_work+0x3b0/0x3b0 [ +0.000007] kthread+0x133/0x160 [ +0.000005] ? set_kthread_struct+0x40/0x40 [ +0.000006] ret_from_fork+0x22/0x30 [ +0.000021] INFO: task kworker/u8:2:84 blocked for more than 368 seconds. [ +0.000006] Tainted: P OE 5.13.12-arch1-1 #1 [ +0.000004] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ +0.000003] task:kworker/u8:2 state:D stack: 0 pid: 84 ppid: 2 flags:0x00004000 [ +0.000007] Workqueue: scsi_tmf_8 scmd_eh_abort_handler [ +0.000011] Call Trace: [ +0.000004] __schedule+0x310/0x930 [ +0.000008] schedule+0x5b/0xc0 [ +0.000007] schedule_timeout+0x11c/0x160 [ +0.000010] wait_for_completion+0xa3/0x100 [ +0.000011] command_abort+0x63/0x80 [usb_storage] [ +0.000014] scmd_eh_abort_handler+0x7e/0x230 [ +0.000009] process_one_work+0x1e3/0x3b0 [ +0.000008] worker_thread+0x50/0x3b0 [ +0.000006] ? process_one_work+0x3b0/0x3b0 [ +0.000008] kthread+0x133/0x160 [ +0.000004] ? set_kthread_struct+0x40/0x40 [ +0.000006] ret_from_fork+0x22/0x30
Created attachment 298469 [details] attachment-10123-0.html Vielen Dank für Ihre Nachricht. Bis voraussichtlich 31.08.2021 bin ich nicht zu erreichen. Ihre Nachrichten werden in dieser Zeit nicht bearbeitet. Bei Fragen zur Infrastruktur oder den IT-Diensten des FB Informatik wenden Sie sich bitte an Sergio Vergata ( sergio.vergata@h-da.de ). Freundliche Grüße S. Ruehl
Johannes, can you attach the complete dmesg log? If it's anything like Marco's log, the mass-storage device never worked (constant resets, at least once per second).
Created attachment 298487 [details] Kernel Log on 5.13.12 Hi Alan, here is the full kernel log. The keybaord stopped working around 18:30. I unplugged it and plugged it two times to another USB-Port of the computer. That is the reason you're seeing the events at 18:30:43 and 18:32:06. Cheers, Johannes
This looks like a problem with the xHCI host controller or driver. You can do two things to help debug it: Turn on dynamic debugging for the xhci-hcd driver: echo 'module xhci_hcd =p' >/sys/kernel/debug/dynamic_debug/control Collect a usbmon trace: cat /sys/kernel/debug/usb/usbmon/3u >mon3.txt & Kill the cat process after an error occurs. Let's see what the debugging messages and usbmon trace reveal.
(In reply to Marco Trevisan (Treviño) from comment #5) > (In reply to Alan Stern from comment #4) > > What happens if you remove the jumper, so as to disable the USB storage on > > the keyboard? > > Sorry, I probably didn't explain this properly. > The I always keep the jumper in "off" state (so there's no USB storage > active), but I'm not sure if that's advertised anyways at HW level. Just out of the blue, do you have pktcdvd module loaded?