Arch Linux

Please read this before reporting a bug:
https://wiki.archlinux.org/title/Bug_reporting_guidelines

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

FS#79861 - udev-worker task blocked after rapid USB connect/disconnect

Attached to Project: Arch Linux
Opened by Eric Buddington (ebuddington) - Thursday, 05 October 2023, 14:04 GMT
Last edited by Toolybird (Toolybird) - Thursday, 05 October 2023, 23:09 GMT
Task Type Bug Report
Category Kernel
Status Closed
Assigned To No-one
Architecture x86_64
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Description:

Kernel 6.5.3-arch1-1

I got a blocked udev-worker thread while programming a Pico. This involves fairly rapid disconnect/reconnect of the device, alternating as a storage/serial USB device.

At this point, 'lsusb' shows some other devices, but then hangs here:

openat(AT_FDCWD, "/sys/bus/usb/devices/1-1.4/manufacturer", O_RDONLY) = 8
read(8,

Unplugging and replugging the offending device does not help. The 'lsusb' hang is the same whether or not the device is plugged in.
Other USB devices continue to function normally.

This has only happened once. I don't know if it's repeatable.

Here's the stack trace:

[Thu Oct 5 02:34:33 2023] INFO: task (udev-worker):3921600 blocked for more than 614 seconds.
[Thu Oct 5 02:34:33 2023] Not tainted 6.5.3-arch1-1 #1
[Thu Oct 5 02:34:33 2023] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[Thu Oct 5 02:34:33 2023] task:(udev-worker) state:D stack:0 pid:3921600 ppid:238 flags:0x00004006
[Thu Oct 5 02:34:33 2023] Call Trace:
[Thu Oct 5 02:34:33 2023] <TASK>
[Thu Oct 5 02:34:33 2023] __schedule+0x3e8/0x1410
[Thu Oct 5 02:34:33 2023] ? chacha_block_generic+0x73/0xb0
[Thu Oct 5 02:34:33 2023] schedule+0x5e/0xd0
[Thu Oct 5 02:34:33 2023] blk_queue_enter+0x16b/0x230
[Thu Oct 5 02:34:33 2023] ? __pfx_autoremove_wake_function+0x10/0x10
[Thu Oct 5 02:34:33 2023] blk_mq_alloc_request+0x12d/0x280
[Thu Oct 5 02:34:33 2023] ? locks_dispose_list+0x54/0x70
[Thu Oct 5 02:34:33 2023] scsi_execute_cmd+0x6f/0x2d0
[Thu Oct 5 02:34:33 2023] ioctl_internal_command.constprop.0+0x8a/0x200
[Thu Oct 5 02:34:33 2023] scsi_set_medium_removal+0x7c/0xb0
[Thu Oct 5 02:34:33 2023] sd_release+0x56/0xa0
[Thu Oct 5 02:34:33 2023] blkdev_put+0x104/0x1d0
[Thu Oct 5 02:34:33 2023] blkdev_release+0x2b/0x40
[Thu Oct 5 02:34:33 2023] __fput+0xed/0x290
[Thu Oct 5 02:34:33 2023] task_work_run+0x5d/0x90
[Thu Oct 5 02:34:33 2023] exit_to_user_mode_prepare+0x1d9/0x1e0
[Thu Oct 5 02:34:33 2023] syscall_exit_to_user_mode+0x1b/0x40
[Thu Oct 5 02:34:33 2023] do_syscall_64+0x6c/0x90
[Thu Oct 5 02:34:33 2023] ? syscall_exit_to_user_mode+0x2b/0x40
[Thu Oct 5 02:34:33 2023] ? do_syscall_64+0x6c/0x90
[Thu Oct 5 02:34:33 2023] ? do_syscall_64+0x6c/0x90
[Thu Oct 5 02:34:33 2023] entry_SYSCALL_64_after_hwframe+0x6e/0xd8
[Thu Oct 5 02:34:33 2023] RIP: 0033:0x7f04b80ff0c4
[Thu Oct 5 02:34:33 2023] RSP: 002b:00007ffcda2b3e28 EFLAGS: 00000202 ORIG_RAX: 0000000000000003
[Thu Oct 5 02:34:33 2023] RAX: 0000000000000000 RBX: 0000000000000010 RCX: 00007f04b80ff0c4
[Thu Oct 5 02:34:33 2023] RDX: 00007ffcda2b3e1c RSI: 000056337a083592 RDI: 0000000000000010
[Thu Oct 5 02:34:33 2023] RBP: 00007f04b87d2310 R08: 0000000000000064 R09: 0000000000000000
[Thu Oct 5 02:34:33 2023] R10: 0000000000000000 R11: 0000000000000202 R12: 000056337b40c660
[Thu Oct 5 02:34:33 2023] R13: 0000000000000000 R14: 00007ffcda2b3fd0 R15: 000056337a08c222
[Thu Oct 5 02:34:33 2023] </TASK>
This task depends upon

Closed by  Toolybird (Toolybird)
Thursday, 05 October 2023, 23:09 GMT
Reason for closing:  Upstream
Additional comments about closing:  See comments
Comment by Eric Buddington (ebuddington) - Thursday, 05 October 2023, 16:44 GMT
Just noting that this is indeed reproducible.
Comment by loqs (loqs) - Thursday, 05 October 2023, 17:23 GMT
Is this a regression? What package do you believe is responsible for the issue? Is there an upstream bug report?
Comment by Eric Buddington (ebuddington) - Thursday, 05 October 2023, 17:37 GMT
I believe this is a kernel issue, but the kernel bugzilla is clear that problems that occur on a distro should be reported on the distro's bug tracker.

I have no information on whether this is a regression; it's a new setup.

Comment by Eric Buddington (ebuddington) - Thursday, 05 October 2023, 17:42 GMT
Reproduced on kernel 6.5.5-arch1-1.

When the problem occurs, new USB devices plugged in do not show up in /dev and generate no dmesg messages.
Comment by loqs (loqs) - Thursday, 05 October 2023, 17:46 GMT
You can use linux-mainline from AUR [1] also available prebuilt [2] to test the latest mainline release candidate with no patches applied.
I would also suggest you use the Arch support channels to investigate the issue further.

[1] https://aur.archlinux.org/packages/linux-mainline
[2] https://wiki.archlinux.org/title/Unofficial_user_repositories#miffe
Comment by Toolybird (Toolybird) - Thursday, 05 October 2023, 23:09 GMT
It appears to be an upstream kernel issue. You can report this upstream, but please first follow up in the support channels (e.g. Forum) as recommended by @loqs.

Loading...