Bug#1107479: util-linux: blkid hangs forever after inserting a DVD-RAM
On Tue, Jul 08, 2025 at 09:32:19AM -0600, Jens Axboe wrote:
> On 7/8/25 5:35 AM, Andy Shevchenko wrote:
> > On Wed, Jul 02, 2025 at 05:13:45PM -0600, Jens Axboe wrote:
> >> On 7/2/25 5:08 PM, Ben Hutchings wrote:
> >>> On Sun, 2025-06-29 at 12:26 +0200, Uwe Kleine-K?nig wrote:
> On Sun, Jun 29, 2025 at 11:46:00AM +0200, Roland Sommer wrote:
>
> Huh, how did I manage that (rhetorical question)? Thanks
>
> >> Ahh, now that makes sense. pktsetup calls `/sbin/modprobe pktcdvd`
> >> explicitly, the blacklist entry doesn't help for that. Without the
> >> kernel module renamed, does the 2nd DVD-RAM result in the blocking
> >> behaviour?
> >
> > Yes.
>
> OK, that makes sense. So udev does in this order:
>
> - auto-load the module (which is suppressed with the backlist entry)
> - call blkid (which blocks if the module is loaded)
> - call pktsetup (which loads the module even in presence of the
> blacklist entry).
> >>> [...]
> >>>
> >>> I tested with a CD-RW, and the behaviour was slightly different:
> >>>
> >>> - Nothing automtically created a pktcdvd device, so blkid initially
> >>> worked with a CD-RW inserted and the pktcdvd modules loaded.
> >>> - After running pktsetup to create the block device /dev/pktcdvd/0,
> >>> blkid and any other program attempting to open that device hung.
> >>>
> >>> My conslusion is that pktcdvd is eqaully broken for CD-RWs.
> >>
> >> Not surprising. Maybe we should take another stab at killing it
> >> from the kernel.
> >
> > In the commit 4b83e99ee709 ("Revert "pktcdvd: remove driver."") you
> > wrote that we would wait for better user space solution is developed.
> > Any news there?
> >
> > Just asking (I'm in favour to kill the old fart) as you haven't
> > mentioned that in a new attempt.
>
> No work has been done there, to my knowledge. But as the current driver
> is totally broken and people aren't even complaining about that (outside
> of running into that for unrelated reasons), I don't think there's any
> reason for keeping the driver in-tree.
Sure, thanks for clarifications!
--
With Best Regards,
Andy Shevchenko
Bug#1107479: util-linux: blkid hangs forever after inserting a DVD-RAM
On 7/8/25 5:35 AM, Andy Shevchenko wrote:
> On Wed, Jul 02, 2025 at 05:13:45PM -0600, Jens Axboe wrote:
>> On 7/2/25 5:08 PM, Ben Hutchings wrote:
>>> On Sun, 2025-06-29 at 12:26 +0200, Uwe Kleine-K?nig wrote:
On Sun, Jun 29, 2025 at 11:46:00AM +0200, Roland Sommer wrote:
Huh, how did I manage that (rhetorical question)? Thanks
>> Ahh, now that makes sense. pktsetup calls `/sbin/modprobe pktcdvd`
>> explicitly, the blacklist entry doesn't help for that. Without the
>> kernel module renamed, does the 2nd DVD-RAM result in the blocking
>> behaviour?
>
> Yes.
OK, that makes sense. So udev does in this order:
- auto-load the module (which is suppressed with the backlist entry)
- call blkid (which blocks if the module is loaded)
- call pktsetup (which loads the module even in presence of the
blacklist entry).
>>> [...]
>>>
>>> I tested with a CD-RW, and the behaviour was slightly different:
>>>
>>> - Nothing automtically created a pktcdvd device, so blkid initially
>>> worked with a CD-RW inserted and the pktcdvd modules loaded.
>>> - After running pktsetup to create the block device /dev/pktcdvd/0,
>>> blkid and any other program attempting to open that device hung.
>>>
>>> My conslusion is that pktcdvd is eqaully broken for CD-RWs.
>>
>> Not surprising. Maybe we should take another stab at killing it
>> from the kernel.
>
> In the commit 4b83e99ee709 ("Revert "pktcdvd: remove driver."") you
> wrote that we would wait for better user space solution is developed.
> Any news there?
>
> Just asking (I'm in favour to kill the old fart) as you haven't
> mentioned that in a new attempt.
No work has been done there, to my knowledge. But as the current driver
is totally broken and people aren't even complaining about that (outside
of running into that for unrelated reasons), I don't think there's any
reason for keeping the driver in-tree.
--
Jens Axboe
Bug#1107479: util-linux: blkid hangs forever after inserting a DVD-RAM
On Wed, Jul 02, 2025 at 05:13:45PM -0600, Jens Axboe wrote:
> On 7/2/25 5:08 PM, Ben Hutchings wrote:
> > On Sun, 2025-06-29 at 12:26 +0200, Uwe Kleine-König wrote:
> >> On Sun, Jun 29, 2025 at 11:46:00AM +0200, Roland Sommer wrote:
> >>
> >> Huh, how did I manage that (rhetorical question)? Thanks
> >>
> Ahh, now that makes sense. pktsetup calls `/sbin/modprobe pktcdvd`
> explicitly, the blacklist entry doesn't help for that. Without the
> kernel module renamed, does the 2nd DVD-RAM result in the blocking
> behaviour?
> >>>
> >>> Yes.
> >>
> >> OK, that makes sense. So udev does in this order:
> >>
> >> - auto-load the module (which is suppressed with the backlist entry)
> >> - call blkid (which blocks if the module is loaded)
> >> - call pktsetup (which loads the module even in presence of the
> >>blacklist entry).
> > [...]
> >
> > I tested with a CD-RW, and the behaviour was slightly different:
> >
> > - Nothing automtically created a pktcdvd device, so blkid initially
> > worked with a CD-RW inserted and the pktcdvd modules loaded.
> > - After running pktsetup to create the block device /dev/pktcdvd/0,
> > blkid and any other program attempting to open that device hung.
> >
> > My conslusion is that pktcdvd is eqaully broken for CD-RWs.
>
> Not surprising. Maybe we should take another stab at killing it
> from the kernel.
In the commit 4b83e99ee709 ("Revert "pktcdvd: remove driver."") you wrote
that we would wait for better user space solution is developed. Any news there?
Just asking (I'm in favour to kill the old fart) as you haven't mentioned that
in a new attempt.
--
With Best Regards,
Andy Shevchenko
Bug#1107479: util-linux: blkid hangs forever after inserting a DVD-RAM
On Wed, Jul 02, 2025 at 05:13:45PM -0600, Jens Axboe wrote: > > My conslusion is that pktcdvd is eqaully broken for CD-RWs. > > Not surprising. Maybe we should take another stab at killing it > from the kernel. Yes, please. I don't mind having this support, but it needs an active maintainer. And even if it was actively maintained it'd probably do better by being integrated into sr and the generic cdrom layer than this stacked design.
Bug#1107479: util-linux: blkid hangs forever after inserting a DVD-RAM
Hello, On Wed, Jul 02, 2025 at 05:13:45PM -0600, Jens Axboe wrote: > On 7/2/25 5:08 PM, Ben Hutchings wrote: > > My conslusion is that pktcdvd is eqaully broken for CD-RWs. > > Not surprising. Maybe we should take another stab at killing it > from the kernel. Sounds reasonable. With Ben's and Roland's user experience it seems there can be noone left who has a benefit from that module. Best regards Uwe signature.asc Description: PGP signature
Bug#1107479: util-linux: blkid hangs forever after inserting a DVD-RAM
On 7/2/25 5:08 PM, Ben Hutchings wrote: > On Sun, 2025-06-29 at 12:26 +0200, Uwe Kleine-König wrote: >> Hello Roland, >> >> On Sun, Jun 29, 2025 at 11:46:00AM +0200, Roland Sommer wrote: >>> [correcting CC recipients] >> >> Huh, how did I manage that (rhetorical question)? Thanks >> Ahh, now that makes sense. pktsetup calls `/sbin/modprobe pktcdvd` explicitly, the blacklist entry doesn't help for that. Without the kernel module renamed, does the 2nd DVD-RAM result in the blocking behaviour? >>> >>> Yes. >> >> OK, that makes sense. So udev does in this order: >> >> - auto-load the module (which is suppressed with the backlist entry) >> - call blkid (which blocks if the module is loaded) >> - call pktsetup (which loads the module even in presence of the >>blacklist entry). > [...] > > I tested with a CD-RW, and the behaviour was slightly different: > > - Nothing automtically created a pktcdvd device, so blkid initially > worked with a CD-RW inserted and the pktcdvd modules loaded. > - After running pktsetup to create the block device /dev/pktcdvd/0, > blkid and any other program attempting to open that device hung. > > My conslusion is that pktcdvd is eqaully broken for CD-RWs. Not surprising. Maybe we should take another stab at killing it from the kernel. -- Jens Axboe
Bug#1107479: util-linux: blkid hangs forever after inserting a DVD-RAM
On Sun, 2025-06-29 at 12:26 +0200, Uwe Kleine-König wrote: > Hello Roland, > > On Sun, Jun 29, 2025 at 11:46:00AM +0200, Roland Sommer wrote: > > [correcting CC recipients] > > Huh, how did I manage that (rhetorical question)? Thanks > > > > Ahh, now that makes sense. pktsetup calls `/sbin/modprobe pktcdvd` > > > explicitly, the blacklist entry doesn't help for that. Without the > > > kernel module renamed, does the 2nd DVD-RAM result in the blocking > > > behaviour? > > > > Yes. > > OK, that makes sense. So udev does in this order: > > - auto-load the module (which is suppressed with the backlist entry) > - call blkid (which blocks if the module is loaded) > - call pktsetup (which loads the module even in presence of the >blacklist entry). [...] I tested with a CD-RW, and the behaviour was slightly different: - Nothing automtically created a pktcdvd device, so blkid initially worked with a CD-RW inserted and the pktcdvd modules loaded. - After running pktsetup to create the block device /dev/pktcdvd/0, blkid and any other program attempting to open that device hung. My conslusion is that pktcdvd is eqaully broken for CD-RWs. Ben. -- Ben Hutchings - Debian developer, member of kernel, installer and LTS teams signature.asc Description: This is a digitally signed message part
Bug#1107479: util-linux: blkid hangs forever after inserting a DVD-RAM
On 6/29/25 4:26 AM, Uwe Kleine-K?nig wrote: > Hello Roland, > > On Sun, Jun 29, 2025 at 11:46:00AM +0200, Roland Sommer wrote: >> [correcting CC recipients] > > Huh, how did I manage that (rhetorical question)? Thanks > >>> Ahh, now that makes sense. pktsetup calls `/sbin/modprobe pktcdvd` >>> explicitly, the blacklist entry doesn't help for that. Without the >>> kernel module renamed, does the 2nd DVD-RAM result in the blocking >>> behaviour? >> >> Yes. > > OK, that makes sense. So udev does in this order: > > - auto-load the module (which is suppressed with the backlist entry) > - call blkid (which blocks if the module is loaded) > - call pktsetup (which loads the module even in presence of the >blacklist entry). > >>> Thanks for your report and helpful testing, >> >> You're welcome. This is the way how OSS should be treated (at least in >> my opinion). > > I fully agree, still this looks different in practise more often that > not :-\ > > I created > https://salsa.debian.org/kernel-team/linux/-/merge_requests/1564 now. I tried removing pktcdvd not that long ago, but someone claimed they used it still... I haven't worked on it in decades. The original intent of it was to support the 32k packet writing devices. DVD-RAM doesn't need it, it was for cd-rw devices. IMHO it should just be killed with fire. -- Jens Axboe
Bug#1107479: util-linux: blkid hangs forever after inserting a DVD-RAM
Hello Roland, On Sun, Jun 29, 2025 at 11:46:00AM +0200, Roland Sommer wrote: > [correcting CC recipients] Huh, how did I manage that (rhetorical question)? Thanks > > Ahh, now that makes sense. pktsetup calls `/sbin/modprobe pktcdvd` > > explicitly, the blacklist entry doesn't help for that. Without the > > kernel module renamed, does the 2nd DVD-RAM result in the blocking > > behaviour? > > Yes. OK, that makes sense. So udev does in this order: - auto-load the module (which is suppressed with the backlist entry) - call blkid (which blocks if the module is loaded) - call pktsetup (which loads the module even in presence of the blacklist entry). > > Thanks for your report and helpful testing, > > You're welcome. This is the way how OSS should be treated (at least in > my opinion). I fully agree, still this looks different in practise more often that not :-\ I created https://salsa.debian.org/kernel-team/linux/-/merge_requests/1564 now. Best regards Uwe signature.asc Description: PGP signature
Bug#1107479: util-linux: blkid hangs forever after inserting a DVD-RAM
Hello Uwe, [correcting CC recipients] > Ahh, now that makes sense. pktsetup calls `/sbin/modprobe pktcdvd` > explicitly, the blacklist entry doesn't help for that. Without the > kernel module renamed, does the 2nd DVD-RAM result in the blocking > behaviour? Yes. > Thanks for your report and helpful testing, You're welcome. This is the way how OSS should be treated (at least in my opinion). Best regards, Roland
Bug#1107479: util-linux: blkid hangs forever after inserting a DVD-RAM
Hello Roland, [adding upstream to Cc: so adding some context first:] In Debian bug #1107479 you report that inserting a DVD-RAM reliably makes blkid (which is triggered by udev) result in a process hang. On Thu, Jun 19, 2025 at 05:05:07PM +0200, Roland Sommer wrote: > > Can you easily tell if this happens for several DVD-RAMs or just a > > single one? (That might affect how good this is reproducible for > > upstream.) > > I've tested 3 different DVD-RAMs, thus, 3 traces below. > > > Usually only the first one is interesting. After that the state of the > > system is broken and the info from later traces is unreliable. > > > > So yes, please provide (at least) the first trace output. > > [ 330.049632] pktcdvd: pktcdvd0: writer mapped to sr0 > [...] > [ 484.389280] Translating the addresses here to line numbers yields: [ 330.049632] pktcdvd: pktcdvd0: writer mapped to sr0 [ 330.074390] sr0: detected capacity change from 8946816 to 8946812 [ 484.388532] INFO: task blkid:1979 blocked for more than 120 seconds. [ 484.388562] Tainted: G I6.1.0-37-amd64 #1 Debian 6.1.140-1 [ 484.388577] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 484.388585] task:blkid state:D stack:0 pid:1979 ppid:1768 flags:0x4002 [ 484.388610] Call Trace: [ 484.388618] [ 484.388634] __schedule (kernel/sched/core.c:5244 kernel/sched/core.c:6561) [ 484.388682] schedule (arch/x86/include/asm/bitops.h:207 (discriminator 1) arch/x86/include/asm/bitops.h:239 (discriminator 1) include/asm-generic/bitops/instrumented-non-atomic.h:142 (discriminator 1) include/linux/thread_info.h:118 (discriminator 1) include/linux/sched.h:2230 (discriminator 1) kernel/sched/core.c:6639 (discriminator 1)) [ 484.388706] schedule_preempt_disabled (arch/x86/include/asm/preempt.h:80 kernel/sched/core.c:6697) [ 484.388728] __mutex_lock.constprop.0 (kernel/locking/mutex.c:197 kernel/locking/mutex.c:681 kernel/locking/mutex.c:747) [ 484.388761] pkt_ioctl (drivers/block/pktcdvd.c:2590) pktcdvd [ 484.388813] pkt_ioctl (drivers/block/pktcdvd.c:2610) pktcdvd [ 484.388853] ? tomoyo_init_request_info (security/tomoyo/util.c:1026) [ 484.388876] blkdev_ioctl (block/ioctl.c:620) [ 484.388896] __x64_sys_ioctl (fs/ioctl.c:51 fs/ioctl.c:870 fs/ioctl.c:856 fs/ioctl.c:856) [ 484.388920] do_syscall_64 (arch/x86/entry/common.c:51 arch/x86/entry/common.c:81) [ 484.388947] ? mutex_lock (arch/x86/include/asm/atomic64_64.h:190 include/linux/atomic/atomic-long.h:443 include/linux/atomic/atomic-instrumented.h:1781 kernel/locking/mutex.c:171 kernel/locking/mutex.c:285) [ 484.388969] ? pkt_ioctl (drivers/block/pktcdvd.c:2619) pktcdvd [ 484.389013] ? blkdev_ioctl (block/ioctl.c:620) [ 484.389030] ? exit_to_user_mode_prepare (arch/x86/include/asm/entry-common.h:57 kernel/entry/common.c:212) [ 484.389053] ? syscall_exit_to_user_mode (kernel/entry/common.c:306) [ 484.389067] ? do_syscall_64 (arch/x86/entry/common.c:88) [ 484.389089] ? handle_mm_fault (mm/memory.c:5295) [ 484.389117] ? do_user_addr_fault (arch/x86/mm/fault.c:1369) [ 484.389141] ? exit_to_user_mode_prepare (arch/x86/include/asm/entry-common.h:57 kernel/entry/common.c:212) [ 484.389161] entry_SYSCALL_64_after_hwframe (/build/reproducible-path/linux-6.1.140/arch/x86/entry/entry_64.S:121) [ 484.389181] RIP: 0033:0x7fce32c8ed1b [ 484.389196] RSP: 002b:7ffd2857ee10 EFLAGS: 0246 ORIG_RAX: 0010 [ 484.389215] RAX: ffda RBX: 557da4646b40 RCX: 7fce32c8ed1b [ 484.389226] RDX: 7ffd2857ee90 RSI: 5395 RDI: 0006 [ 484.389235] RBP: 0006 R08: 0007 R09: 557da4646a50 [ 484.389245] R10: 525ee8f48e4e6f05 R11: 0246 R12: [ 484.389255] R13: R14: R15: 800068541db5 [ 484.389280] blkdev_ioctl calls: bdev->bd_disk->fops->ioctl(bdev, mode, cmd, arg); Obviously we have bdev->bd_disk->fops->ioctl == pkt_ioctl and this function then calls itself in line 2610 with: ret = bdev->bd_disk->fops->ioctl(bdev, mode, cmd, arg); So this explains the hang as the second instance of pkt_ioctl wants to grab the mutex that the first is already holding. A quick look over the commits since 6.1 to current mainline shows no change that looks relevant. In current linus/master (5c8013ae2e86) both functions still have these calls, so I assume newer kernels are affected in the same way. Best regards Uwe signature.asc Description: PGP signature
Bug#1107479: util-linux: blkid hangs forever after inserting a DVD-RAM
Hello Uwe, > Can you easily tell if this happens for several DVD-RAMs or just a > single one? (That might affect how good this is reproducible for > upstream.) I've tested 3 different DVD-RAMs, thus, 3 traces below. > Usually only the first one is interesting. After that the state of the > system is broken and the info from later traces is unreliable. > > So yes, please provide (at least) the first trace output. [ 330.049632] pktcdvd: pktcdvd0: writer mapped to sr0 [ 330.074390] sr0: detected capacity change from 8946816 to 8946812 [ 484.388532] INFO: task blkid:1979 blocked for more than 120 seconds. [ 484.388562] Tainted: G I6.1.0-37-amd64 #1 Debian 6.1.140-1 [ 484.388577] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 484.388585] task:blkid state:D stack:0 pid:1979 ppid:1768 flags:0x4002 [ 484.388610] Call Trace: [ 484.388618] [ 484.388634] __schedule+0x34d/0x9e0 [ 484.388682] schedule+0x5a/0xd0 [ 484.388706] schedule_preempt_disabled+0x11/0x20 [ 484.388728] __mutex_lock.constprop.0+0x399/0x700 [ 484.388761] pkt_ioctl+0x42/0x120 [pktcdvd] [ 484.388813] pkt_ioctl+0xcb/0x120 [pktcdvd] [ 484.388853] ? tomoyo_init_request_info+0x95/0xc0 [ 484.388876] blkdev_ioctl+0x130/0x270 [ 484.388896] __x64_sys_ioctl+0x8d/0xd0 [ 484.388920] do_syscall_64+0x55/0xb0 [ 484.388947] ? mutex_lock+0xe/0x30 [ 484.388969] ? pkt_ioctl+0x74/0x120 [pktcdvd] [ 484.389013] ? blkdev_ioctl+0x130/0x270 [ 484.389030] ? exit_to_user_mode_prepare+0x40/0x1e0 [ 484.389053] ? syscall_exit_to_user_mode+0x1e/0x40 [ 484.389067] ? do_syscall_64+0x61/0xb0 [ 484.389089] ? handle_mm_fault+0xdb/0x2d0 [ 484.389117] ? do_user_addr_fault+0x1b0/0x550 [ 484.389141] ? exit_to_user_mode_prepare+0x40/0x1e0 [ 484.389161] entry_SYSCALL_64_after_hwframe+0x6e/0xd8 [ 484.389181] RIP: 0033:0x7fce32c8ed1b [ 484.389196] RSP: 002b:7ffd2857ee10 EFLAGS: 0246 ORIG_RAX: 0010 [ 484.389215] RAX: ffda RBX: 557da4646b40 RCX: 7fce32c8ed1b [ 484.389226] RDX: 7ffd2857ee90 RSI: 5395 RDI: 0006 [ 484.389235] RBP: 0006 R08: 0007 R09: 557da4646a50 [ 484.389245] R10: 525ee8f48e4e6f05 R11: 0246 R12: [ 484.389255] R13: R14: R15: 800068541db5 [ 484.389280] [ 287.772621] pktcdvd: pktcdvd0: writer mapped to sr0 [ 287.821877] sr0: detected capacity change from 8946816 to 8946812 [ 484.386374] INFO: task blkid:1846 blocked for more than 120 seconds. [ 484.386404] Tainted: G I6.1.0-37-amd64 #1 Debian 6.1.140-1 [ 484.386418] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 484.386426] task:blkid state:D stack:0 pid:1846 ppid:1320 flags:0x0002 [ 484.386451] Call Trace: [ 484.386459] [ 484.386475] __schedule+0x34d/0x9e0 [ 484.386522] schedule+0x5a/0xd0 [ 484.386546] schedule_preempt_disabled+0x11/0x20 [ 484.386568] __mutex_lock.constprop.0+0x399/0x700 [ 484.386601] pkt_ioctl+0x42/0x120 [pktcdvd] [ 484.386654] pkt_ioctl+0xcb/0x120 [pktcdvd] [ 484.386699] blkdev_ioctl+0x130/0x270 [ 484.386720] __x64_sys_ioctl+0x8d/0xd0 [ 484.386745] do_syscall_64+0x55/0xb0 [ 484.386784] ? mutex_lock+0xe/0x30 [ 484.386807] ? pkt_ioctl+0x74/0x120 [pktcdvd] [ 484.386851] ? blkdev_ioctl+0x130/0x270 [ 484.386868] ? exit_to_user_mode_prepare+0x40/0x1e0 [ 484.386891] ? syscall_exit_to_user_mode+0x1e/0x40 [ 484.386904] ? do_syscall_64+0x61/0xb0 [ 484.386923] ? exit_to_user_mode_prepare+0x40/0x1e0 [ 484.386942] ? syscall_exit_to_user_mode+0x1e/0x40 [ 484.386953] ? do_syscall_64+0x61/0xb0 [ 484.386986] ? handle_mm_fault+0xdb/0x2d0 [ 484.387013] ? do_user_addr_fault+0x1b0/0x550 [ 484.387038] ? exit_to_user_mode_prepare+0x40/0x1e0 [ 484.387057] entry_SYSCALL_64_after_hwframe+0x6e/0xd8 [ 484.387078] RIP: 0033:0x7f4474200d1b [ 484.387093] RSP: 002b:7ffd88c45490 EFLAGS: 0246 ORIG_RAX: 0010 [ 484.387112] RAX: ffda RBX: 558f91d7bb40 RCX: 7f4474200d1b [ 484.387123] RDX: 7ffd88c45510 RSI: 5395 RDI: 0006 [ 484.387133] RBP: 0006 R08: 0007 R09: 558f91d7ba50 [ 484.387142] R10: 498a16647597596d R11: 0246 R12: [ 484.387152] R13: R14: R15: 800068541fe5 [ 484.387176] [ 55.310426] pktcdvd: pktcdvd0: writer mapped to sr0 [ 55.339455] sr0: detected capacity change from 8946816 to 8946812 [ 242.724737] INFO: task blkid:1743 blocked for more than 120 seconds. [ 242.724768] Tainted: G I6.1.0-37-amd64 #1 Debian 6.1.140-1 [ 242.724783] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 242.724792] task:blkid state:D stack:0 pid:1743 ppid:1303 flags:0x4002 [ 242.724817] C
Bug#1107479: util-linux: blkid hangs forever after inserting a DVD-RAM
Hello Roland, On Thu, Jun 12, 2025 at 10:51:48AM +0200, Roland Sommer wrote: > > Can you reproduce the problem without the nvidia module? > > Yes, I have exactly the same behaviour with an Fujitsu Lifebook E756. Can you easily tell if this happens for several DVD-RAMs or just a single one? (That might affect how good this is reproducible for upstream.) > > Does the problem happen always when you insert a DVD RAM? > > Yes This is good (for debugging the problem). > > Does the hang generate more dmesg output? > > Yes and no. A trace is reported 10 times which looks quite the same for > me. But I could send a full report if you want to. Usually only the first one is interesting. After that the state of the system is broken and the info from later traces is unreliable. So yes, please provide (at least) the first trace output. Best regards Uwe signature.asc Description: PGP signature
Bug#1107479: util-linux: blkid hangs forever after inserting a DVD-RAM
Hello, > Yes, pasting without eating the \n characters would have been nice. I > invested some time to reformat the paste: I'm very sorry for bad formatting my last mail. > Can you reproduce the problem without the nvidia module? Yes, I have exactly the same behaviour with an Fujitsu Lifebook E756. > Does the problem happen always when you insert a DVD RAM? Yes > Does the hang generate more dmesg output? Yes and no. A trace is reported 10 times which looks quite the same for me. But I could send a full report if you want to. Best regards, Roland
Bug#1107479: util-linux: blkid hangs forever after inserting a DVD-RAM
Control: tag -1 + moreinfo Hello, On Mon, Jun 09, 2025 at 12:16:13PM +0200, Roland Sommer wrote: > > Please provide as well as full boot log up to when triggering the > > issue so we can see more context. > > I hope you wanted me to paste the complete dmesg output: Yes, pasting without eating the \n characters would have been nice. I invested some time to reformat the paste: > [0.00] Linux version 6.1.0-37-amd64 ([email protected]) > (gcc-12 (Debian 12.2.0-14+deb12u1) 12.2.0, GNU ld (GNU Binutils for Debian) > 2.40) #1 SMP PREEMPT_DYNAMIC Debian 6.1.140-1 (2025-05-22) > [0.00] Command line: BOOT_IMAGE=/boot/vmlinuz-6.1.0-37-amd64 > root=UUID=a69a5304-91ba-4e55-89af-c48a103c39b0 ro nomodeset ipv6.disable=1 > quiet > [0.00] BIOS-provided physical RAM map: > [0.00] BIOS-e820: [mem 0x-0x0009c7ff] usable > [0.00] BIOS-e820: [mem 0x0009c800-0x0009] > reserved > [0.00] BIOS-e820: [mem 0x000d-0x000d3fff] > reserved > [0.00] BIOS-e820: [mem 0x000e4000-0x000f] > reserved > [0.00] BIOS-e820: [mem 0x0010-0xbfea] usable > [0.00] BIOS-e820: [mem 0xbfeb-0xbfec4fff] ACPI > data > [0.00] BIOS-e820: [mem 0xbfec5000-0xbfec7fff] ACPI > NVS > [0.00] BIOS-e820: [mem 0xbfec8000-0xbfff] > reserved > [0.00] BIOS-e820: [mem 0xf800-0xfbff] > reserved > [0.00] BIOS-e820: [mem 0xfec0-0xfec0] > reserved > [0.00] BIOS-e820: [mem 0xfee0-0xfee00fff] > reserved > [0.00] BIOS-e820: [mem 0xffb0-0x] > reserved > [0.00] BIOS-e820: [mem 0x0001-0x00042fff] usable > [0.00] NX (Execute Disable) protection: active > [0.00] SMBIOS 2.5 present. > [0.00] DMI: FUJITSU ESPRIMO P7936 /D3012-A1, BIOS > 6.00 R1.06.3012.A1 04/21/2011 > [0.00] tsc: Fast TSC calibration using PIT > [0.00] tsc: Detected 2833.306 MHz processor > [0.002693] e820: update [mem 0x-0x0fff] usable ==> reserved > [0.002696] e820: remove [mem 0x000a-0x000f] usable > [0.002703] last_pfn = 0x43 max_arch_pfn = 0x4 > [0.003455] x86/PAT: Configuration [0-7]: WB WC UC- UC WB WP UC- WT > [0.003807] e820: update [mem 0xbff0-0x] usable ==> reserved > [0.003818] last_pfn = 0xbfeb0 max_arch_pfn = 0x4 > [0.012117] found SMP MP-table at [mem 0x000f8fc0-0x000f8fcf] > [0.012746] RAMDISK: [mem 0x31667000-0x34b2afff] > [0.012752] ACPI: Early table checksum verification disabled > [0.012756] ACPI: RSDP 0x000F8EC0 24 (v02 PTLTD ) > [0.012761] ACPI: XSDT 0xBFEBF8C1 74 (v01 FSCPC > 0006 LTP ) > [0.012768] ACPI: FACP 0xBFEC4AC1 F4 (v03 FSCPC > 0006 000F4240) > [0.012773] ACPI BIOS Warning (bug): 32/64X length mismatch in > FADT/Pm1aControlBlock: 16/32 (20220331/tbfadt-564) > [0.012777] ACPI BIOS Warning (bug): 32/64X length mismatch in > FADT/PmTimerBlock: 32/24 (20220331/tbfadt-564) > [0.012779] ACPI BIOS Warning (bug): 32/64X length mismatch in > FADT/Gpe0Block: 128/32 (20220331/tbfadt-564) > [0.012782] ACPI BIOS Warning (bug): Invalid length for > FADT/Pm1aControlBlock: 32, using default 16 (20220331/tbfadt-669) > [0.012785] ACPI BIOS Warning (bug): Invalid length for FADT/PmTimerBlock: > 24, using default 32 (20220331/tbfadt-669) > [0.012789] ACPI: DSDT 0xBFEBF935 005118 (v01 FSCD3012/A1 > 0006 MSFT 0301) > [0.012793] ACPI: FACS 0xBFEC7FC0 40 > [0.012796] ACPI: FACS 0xBFEC7FC0 40 > [0.012800] ACPI: TCPA 0xBFEC4BB5 32 (v01 Phoeni x > 0006 TL ) > [0.012804] ACPI: DMAR 0xBFEC4BE7 B0 (v01 Intel OEMDMAR > 0006 LOHR 0001) > [0.012807] ACPI: SPCR 0xBFEC4C97 50 (v01 PTLTD $UCRTBL$ > 0006 PTL 0001) > [0.012811] ACPI: SLIC 0xBFEC4CE7 000176 (v01 FSCPC > 0006 LTP ) > [0.012815] ACPI: MCFG 0xBFEC4E5D 3C (v01 PTLTDMCFG > 0006 LTP ) > [0.012819] ACPI: HPET 0xBFEC4E99 38 (v01 PTLTD HPETTBL > 0006 LTP 0001) > [0.012823] ACPI: APIC 0xBFEC4ED1 84 (v01 PTLTD ? APIC > 0006 LTP ) > [0.012827] ACPI: BOOT 0xBFEC4F55 28 (v01 PTLTD $SBFTBL$ > 0006 LTP 0001) > [0.012831] ACPI: ASF! 0xBFEC4F7D 83 (v16 CETP CETP > 0006 PTL 0001) > [0.012834] ACPI: Reserving FACP table memory at [mem > 0xbfec4ac1-0xbfec4bb4] > [0.012836] ACPI: Reserving DSDT table m
Bug#1107479: util-linux: blkid hangs forever after inserting a DVD-RAM
Hi Salvatore, > Please provide as well as full boot log up to when triggering the > issue so we can see more context. I hope you wanted me to paste the complete dmesg output: [0.00] Linux version 6.1.0-37-amd64 ([email protected]) (gcc-12 (Debian 12.2.0-14+deb12u1) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40) #1 SMP PREEMPT_DYNAMIC Debian 6.1.140-1 (2025-05-22) [0.00] Command line: BOOT_IMAGE=/boot/vmlinuz-6.1.0-37-amd64 root=UUID=a69a5304-91ba-4e55-89af-c48a103c39b0 ro nomodeset ipv6.disable=1 quiet [0.00] BIOS-provided physical RAM map: [ 0.00] BIOS-e820: [mem 0x-0x0009c7ff] usable [0.00] BIOS-e820: [mem 0x0009c800-0x0009] reserved [0.00] BIOS-e820: [mem 0x000d-0x000d3fff] reserved [ 0.00] BIOS-e820: [mem 0x000e4000-0x000f] reserved [0.00] BIOS-e820: [mem 0x0010-0xbfea] usable [0.00] BIOS-e820: [mem 0xbfeb-0xbfec4fff] ACPI data [0.00] BIOS-e820: [mem 0xbfec5000-0xbfec7fff] ACPI NVS [ 0.00] BIOS-e820: [mem 0xbfec8000-0xbfff] reserved [0.00] BIOS-e820: [mem 0xf800-0xfbff] reserved [0.00] BIOS-e820: [mem 0xfec0-0xfec0] reserved [ 0.00] BIOS-e820: [mem 0xfee0-0xfee00fff] reserved [0.00] BIOS-e820: [mem 0xffb0-0x] reserved [0.00] BIOS-e820: [mem 0x0001-0x00042fff] usable [ 0.00] NX (Execute Disable) protection: active [0.00] SMBIOS 2.5 present. [0.00] DMI: FUJITSU ESPRIMO P7936 /D3012-A1, BIOS 6.00 R1.06.3012.A1 04/21/2011 [0.00] tsc: Fast TSC calibration using PIT [ 0.00] tsc: Detected 2833.306 MHz processor [0.002693] e820: update [mem 0x-0x0fff] usable ==> reserved [0.002696] e820: remove [mem 0x000a-0x000f] usable [0.002703] last_pfn = 0x43 max_arch_pfn = 0x4 [0.003455] x86/PAT: Configuration [0-7]: WB WC UC- UC WB WP UC- WT [0.003807] e820: update [mem 0xbff0-0x] usable ==> reserved [ 0.003818] last_pfn = 0xbfeb0 max_arch_pfn = 0x4 [0.012117] found SMP MP-table at [mem 0x000f8fc0-0x000f8fcf] [0.012746] RAMDISK: [mem 0x31667000-0x34b2afff] [0.012752] ACPI: Early table checksum verification disabled [0.012756] ACPI: RSDP 0x000F8EC0 24 (v02 PTLTD ) [0.012761] ACPI: XSDT 0xBFEBF8C1 74 (v01 FSCPC 0006 LTP ) [0.012768] ACPI: FACP 0xBFEC4AC1 F4 (v03 FSCPC 0006 000F4240) [0.012773] ACPI BIOS Warning (bug): 32/64X length mismatch in FADT/Pm1aControlBlock: 16/32 (20220331/tbfadt-564) [ 0.012777] ACPI BIOS Warning (bug): 32/64X length mismatch in FADT/PmTimerBlock: 32/24 (20220331/tbfadt-564) [0.012779] ACPI BIOS Warning (bug): 32/64X length mismatch in FADT/Gpe0Block: 128/32 (20220331/tbfadt-564) [0.012782] ACPI BIOS Warning (bug): Invalid length for FADT/Pm1aControlBlock: 32, using default 16 (20220331/tbfadt-669) [0.012785] ACPI BIOS Warning (bug): Invalid length for FADT/PmTimerBlock: 24, using default 32 (20220331/tbfadt-669) [0.012789] ACPI: DSDT 0xBFEBF935 005118 (v01 FSCD3012/A1 0006 MSFT 0301) [0.012793] ACPI: FACS 0xBFEC7FC0 40 [0.012796] ACPI: FACS 0xBFEC7FC0 40 [0.012800] ACPI: TCPA 0xBFEC4BB5 32 (v01 Phoeni x0006 TL ) [0.012804] ACPI: DMAR 0xBFEC4BE7 B0 (v01 Intel OEMDMAR 0006 LOHR 0001) [0.012807] ACPI: SPCR 0xBFEC4C97 50 (v01 PTLTD $UCRTBL$ 0006 PTL 0001) [0.012811] ACPI: SLIC 0xBFEC4CE7 000176 (v01 FSCPC 0006 LTP ) [0.012815] ACPI: MCFG 0xBFEC4E5D 3C (v01 PTLTDMCFG 0006 LTP ) [0.012819] ACPI: HPET 0xBFEC4E99 38 (v01 PTLTD HPETTBL 0006 LTP 0001) [0.012823] ACPI: APIC 0xBFEC4ED1 84 (v01 PTLTD ? APIC 0006 LTP ) [0.012827] ACPI: BOOT 0xBFEC4F55 28 (v01 PTLTD $SBFTBL$ 0006 LTP 0001) [0.012831] ACPI: ASF! 0xBFEC4F7D 83 (v16 CETP CETP 0006 PTL 0001) [0.012834] ACPI: Reserving FACP table memory at [mem 0xbfec4ac1-0xbfec4bb4] [0.012836] ACPI: Reserving DSDT table memory at [mem 0xbfebf935-0xbfec4a4c] [0.012837] ACPI: Reserving FACS table memory at [mem 0xbfec7fc0-0xbfec7fff] [0.012838] ACPI: Reserving FACS table memory at [mem 0xbfec7fc0-0xbfec7fff] [ 0.012839] ACPI: Reserving TCPA table memory at [mem 0xbfec4bb5-0xbfec4be6] [0.012841] ACPI: Reserving DMAR table memory at [mem 0xbfec4be7-0xbfec4c96] [0.012842] ACPI: Reserving SPCR table memory at [mem 0xbfec4c97-0xbfec4ce6] [0.012843] ACPI: Reserving SLIC ta
Bug#1107479: util-linux: blkid hangs forever after inserting a DVD-RAM
Control: tags -1 + moreinfo Hi Roland, On Sun, Jun 08, 2025 at 01:24:55PM +0200, Chris Hofstaedtler wrote: > Control: reassign -1 src:linux > > On Sun, Jun 08, 2025 at 08:59:22AM +0200, Roland Sommer wrote: > > blkid works all the time as expected but hangs forever after inserting any > > DVD- > > RAM in the drive. dmesg then reports every approx. 120s (up to 10 times): > > > > [ 363.635218] INFO: task blkid:2224 blocked for more than 120 seconds. > > [ 363.635232] Tainted: P OE 6.1.0-37-amd64 #1 Debian > > 6.1.140-1 > > [ 363.635235] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables > > this > > message. > > [ 363.635238] task:blkid state:D stack:0 pid:2224 ppid:2216 > > flags:0x4002 > > [ 363.635245] Call Trace: > > [ 363.635247] > > [ 363.635252] __schedule+0x34d/0x9e0 > > [ 363.635266] schedule+0x5a/0xd0 > > [ 363.635271] schedule_preempt_disabled+0x11/0x20 > > [ 363.635276] __mutex_lock.constprop.0+0x399/0x700 > > [ 363.635283] pkt_ioctl+0x42/0x120 [pktcdvd] > > [ 363.635294] pkt_ioctl+0xce/0x120 [pktcdvd] > > [ 363.635302] ? do_syscall_64+0x61/0xb0 > > [ 363.635308] ? do_filp_open+0xaf/0x160 > > [ 363.635313] blkdev_ioctl+0x133/0x270 > > Looks like pktcdvd isn't returning to userspace. Reassigning to the > kernel, as blkid won't be able to do anything about that. Might also > be a hardware issue if it works elsewhere? Please provide as well as full boot log up to when triggering the issue so we can see more context. Regards, Salvatore
Bug#1107479: util-linux: blkid hangs forever after inserting a DVD-RAM
Control: reassign -1 src:linux On Sun, Jun 08, 2025 at 08:59:22AM +0200, Roland Sommer wrote: > blkid works all the time as expected but hangs forever after inserting any > DVD- > RAM in the drive. dmesg then reports every approx. 120s (up to 10 times): > > [ 363.635218] INFO: task blkid:2224 blocked for more than 120 seconds. > [ 363.635232] Tainted: P OE 6.1.0-37-amd64 #1 Debian > 6.1.140-1 > [ 363.635235] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables > this > message. > [ 363.635238] task:blkid state:D stack:0 pid:2224 ppid:2216 > flags:0x4002 > [ 363.635245] Call Trace: > [ 363.635247] > [ 363.635252] __schedule+0x34d/0x9e0 > [ 363.635266] schedule+0x5a/0xd0 > [ 363.635271] schedule_preempt_disabled+0x11/0x20 > [ 363.635276] __mutex_lock.constprop.0+0x399/0x700 > [ 363.635283] pkt_ioctl+0x42/0x120 [pktcdvd] > [ 363.635294] pkt_ioctl+0xce/0x120 [pktcdvd] > [ 363.635302] ? do_syscall_64+0x61/0xb0 > [ 363.635308] ? do_filp_open+0xaf/0x160 > [ 363.635313] blkdev_ioctl+0x133/0x270 Looks like pktcdvd isn't returning to userspace. Reassigning to the kernel, as blkid won't be able to do anything about that. Might also be a hardware issue if it works elsewhere? Chris
Bug#1107479: util-linux: blkid hangs forever after inserting a DVD-RAM
Package: util-linux Version: 2.38.1-5+deb12u3 Severity: normal X-Debbugs-Cc: [email protected] Dear Maintainer, blkid works all the time as expected but hangs forever after inserting any DVD- RAM in the drive. dmesg then reports every approx. 120s (up to 10 times): [ 363.635218] INFO: task blkid:2224 blocked for more than 120 seconds. [ 363.635232] Tainted: P OE 6.1.0-37-amd64 #1 Debian 6.1.140-1 [ 363.635235] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 363.635238] task:blkid state:D stack:0 pid:2224 ppid:2216 flags:0x4002 [ 363.635245] Call Trace: [ 363.635247] [ 363.635252] __schedule+0x34d/0x9e0 [ 363.635266] schedule+0x5a/0xd0 [ 363.635271] schedule_preempt_disabled+0x11/0x20 [ 363.635276] __mutex_lock.constprop.0+0x399/0x700 [ 363.635283] pkt_ioctl+0x42/0x120 [pktcdvd] [ 363.635294] pkt_ioctl+0xce/0x120 [pktcdvd] [ 363.635302] ? do_syscall_64+0x61/0xb0 [ 363.635308] ? do_filp_open+0xaf/0x160 [ 363.635313] blkdev_ioctl+0x133/0x270 [ 363.635318] __x64_sys_ioctl+0x90/0xd0 [ 363.635324] do_syscall_64+0x55/0xb0 [ 363.635328] ? kmem_cache_free+0x15/0x310 [ 363.635336] ? __rseq_handle_notify_resume+0xa9/0x4a0 [ 363.635341] ? mntput_no_expire+0x4a/0x250 [ 363.635345] ? exit_to_user_mode_prepare+0x40/0x1e0 [ 363.635351] ? syscall_exit_to_user_mode+0x1e/0x40 [ 363.635354] ? do_syscall_64+0x61/0xb0 [ 363.635369] ? handle_mm_fault+0xdb/0x2d0 [ 363.635379] ? do_user_addr_fault+0x1b0/0x550 [ 363.635384] ? exit_to_user_mode_prepare+0x40/0x1e0 [ 363.635387] entry_SYSCALL_64_after_hwframe+0x6e/0xd8 [ 363.635391] RIP: 0033:0x7fdb30633d1b [ 363.635394] RSP: 002b:7ffda9123850 EFLAGS: 0246 ORIG_RAX: 0010 [ 363.635397] RAX: ffda RBX: 561da2fd0830 RCX: 7fdb30633d1b [ 363.635399] RDX: 7ffda91238d0 RSI: 5395 RDI: 0006 [ 363.635400] RBP: 0006 R08: 0007 R09: 561da2fe3290 [ 363.635402] R10: 8044f69e8533263d R11: 0246 R12: [ 363.635403] R13: R14: R15: 80006845269f [ 363.635406] ... [ 484.469750] INFO: task blkid:2224 blocked for more than 241 seconds. ... The DVD-RAM can then no longer be accessed nor mounted nor formatted. STRG-C does not help and the process cannot be killed at all. Only reboot (which takes more than 5min. due to some timeouts) eliminates this issue. I've tried it on another machine (almost same package versions) and blkid works as expected until udftools (2.3-1) is installed and a DVD-RAM is inserted. -- System Information: Debian Release: 12.11 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'proposed-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.1.0-37-amd64 (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages util-linux depends on: ii libblkid1 2.38.1-5+deb12u3 ii libc6 2.36-9+deb12u12 ii libcap-ng00.8.3-1+b3 ii libcrypt1 1:4.4.33-2 ii libmount1 2.38.1-5+deb12u3 ii libpam0g 1.5.2-6+deb12u1 ii libselinux1 3.4-1+b6 ii libsmartcols1 2.38.1-5+deb12u3 ii libsystemd0 254.26-1~bpo12+1 ii libtinfo6 6.4-4 ii libudev1 254.26-1~bpo12+1 ii libuuid1 2.38.1-5+deb12u3 ii util-linux-extra 2.38.1-5+deb12u3 ii zlib1g1:1.2.13.dfsg-1 Versions of packages util-linux recommends: ii sensible-utils 0.0.17+nmu1 Versions of packages util-linux suggests: ii dosfstools 4.2-1 ii kbd 2.5.1-1+b1 pn util-linux-locales -- no debconf information
