Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.bugs.dist > #1251700 > unrolled thread

Bug#1107479: util-linux: blkid hangs forever after inserting a DVD-RAM

Back to article view | Back to linux.debian.bugs.dist

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Bug#1107479: util-linux: blkid hangs forever after inserting a DVD-RAM Ben Hutchings <benh@debian.org> - 2025-07-03 01:20 +0200
    Bug#1107479: util-linux: blkid hangs forever after inserting a DVD-RAM Christoph Hellwig <hch@infradead.org> - 2025-07-03 12:20 +0200
    Bug#1107479: util-linux: blkid hangs forever after inserting a DVD-RAM Andy Shevchenko <andriy.shevchenko@intel.com> - 2025-07-08 13:50 +0200
      Bug#1107479: util-linux: blkid hangs forever after inserting a DVD-RAM Andy Shevchenko <andriy.shevchenko@intel.com> - 2025-07-09 11:10 +0200

#1251700 — Bug#1107479: util-linux: blkid hangs forever after inserting a DVD-RAM

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [next] | [standalone]

#1251727

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.

[toc] | [prev] | [next] | [standalone]

#1252149

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

[toc] | [prev] | [next] | [standalone]

#1252224

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

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.bugs.dist

csiph-web