Bluray drive in external USB 3.0 enclosure hangs on some disks on Ubuntu 20.04 but not on AntiX 19.1

Hi all,

I have a Vantec NST-536S3-BK USB 3.0 5.25-inch drive enclosure with a ASUS ASUS BW-16D1HT bluray drive that is hanging with certain CD-ROMs and DVD-ROMs, but seemingly only on Ubuntu 20.04 LTS (kernel version 5.4.0-70) and Ubuntu 18.04 LTS (kernel version 4.15-something, I upgraded the OS to see if that would solve the problem, it did not) on my Dell Poweredge T30 workstation. An old Core 2 Duo HP workstation running AntiX Linux 19.1 (kernel version 4.9-something) with the drive and enclosure plugged into the USB 2.0 ports worked fine and read all the disks I threw at it, although the problem disks did have to be manually mounted with:

mount -t iso9660 /dev/sr1 /media/cdrom

I tried to mount them manually on the Ubuntu system, and the mount command hanged. I ran:

journalctl -f

Here is the pertinent output (from when it was attached to a USB 2.0 port, the USB 3.0 attempt resulted in mostly the same), it is the same for all the problem CD-ROMs (also some of the firewall information has been redacted for security purposes):

Apr 06 18:40:48 dreamprism kernel: usb 1-8: reset high-speed USB device number 20 using xhci_hcd
Apr 06 18:40:48 dreamprism kernel: sr 5:0:0:0: [sr1] tag#0 FAILED Result: hostbyte=DID_TIME_OUT driverbyte=DRIVER_OK
Apr 06 18:40:48 dreamprism kernel: sr 5:0:0:0: [sr1] tag#0 CDB: Read(10) 28 00 00 00 04 00 00 00 02 00
Apr 06 18:40:48 dreamprism kernel: blk_update_request: I/O error, dev sr1, sector 4096 op 0x0:(READ) flags 0x80700 phys_seg 1 prio class 0
Apr 06 18:41:14 dreamprism systemd-udevd[486]: sr1: Worker [5923] processing SEQNUM=9163 is taking a long time
Apr 06 18:41:17 dreamprism rtkit-daemon[3493]: Supervising 6 threads of 2 processes of 1 users.
Apr 06 18:41:17 dreamprism rtkit-daemon[3493]: Supervising 6 threads of 2 processes of 1 users.
Apr 06 18:41:19 dreamprism kernel: usb 1-8: reset high-speed USB device number 20 using xhci_hcd
Apr 06 18:43:14 dreamprism systemd-udevd[486]: sr1: Worker [5923] processing SEQNUM=9163 killed
Apr 06 18:43:40 dreamprism kernel: INFO: task usb-storage:5024 blocked for more than 120 seconds.
Apr 06 18:43:40 dreamprism kernel:       Tainted: G           OE     5.4.0-70-generic #78-Ubuntu
Apr 06 18:43:40 dreamprism kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
Apr 06 18:43:40 dreamprism kernel: usb-storage     D    0  5024      2 0x80004000
Apr 06 18:43:40 dreamprism kernel: Call Trace:
Apr 06 18:43:40 dreamprism kernel:  __schedule+0x2e3/0x740
Apr 06 18:43:40 dreamprism kernel:  schedule+0x42/0xb0
Apr 06 18:43:40 dreamprism kernel:  schedule_timeout+0x10e/0x160
Apr 06 18:43:40 dreamprism kernel:  wait_for_completion+0xb1/0x120
Apr 06 18:43:40 dreamprism kernel:  ? wake_up_q+0x70/0x70
Apr 06 18:43:40 dreamprism kernel:  usb_sg_wait+0xea/0x170
Apr 06 18:43:40 dreamprism kernel:  usb_stor_bulk_transfer_sglist.part.0+0x6c/0xd0 [usb_storage]
Apr 06 18:43:40 dreamprism kernel:  usb_stor_bulk_srb+0x4b/0x80 [usb_storage]
Apr 06 18:43:40 dreamprism kernel:  usb_stor_Bulk_transport+0x177/0x410 [usb_storage]
Apr 06 18:43:40 dreamprism kernel:  usb_stor_invoke_transport+0x3e/0x520 [usb_storage]
Apr 06 18:43:40 dreamprism kernel:  ? wake_up_process+0x15/0x20
Apr 06 18:43:40 dreamprism kernel:  ? raise_softirq_irqoff+0x8c/0xa0
Apr 06 18:43:40 dreamprism kernel:  ? wait_for_completion_interruptible+0xb8/0x160
Apr 06 18:43:40 dreamprism kernel:  usb_stor_transparent_scsi_command+0xe/0x10 [usb_storage]
Apr 06 18:43:40 dreamprism kernel:  usb_stor_control_thread+0x19b/0x2a0 [usb_storage]
Apr 06 18:43:40 dreamprism kernel:  kthread+0x104/0x140
Apr 06 18:43:40 dreamprism kernel:  ? storage_probe+0x2b0/0x2b0 [usb_storage]
Apr 06 18:43:40 dreamprism kernel:  ? kthread_park+0x90/0x90
Apr 06 18:43:40 dreamprism kernel:  ret_from_fork+0x35/0x40

I have tried using a USB 2.0 port and disabling UAS on the drive to no avail.

An interesting sidenote is that when I run the Linux version of MakeMKV (have it because I thought that using the Libredrive firmware on the drive might help, it did not), the GUI sees the disk spinning, and the title of the disk is read by MakeMKV. lsblk also gives the amount of data on the disk.

I'm really at a total loss here, I don't know if this is a kernel bug or what, or that maybe it has something to do with systemd, since Ubuntu has this and AntiX does not. When it was plugged into a USB 3.0 port, it did spit some systemd-udevd messages, but they don't seem to have much to do with the problem, if at all. I will post them if needed.

I would rather say it is an incompatible driver. There is no [good] CD-ROM support in the new linux distros (in general).

If this is only certain blurays then it likely is the updated bluray security.

I use makeMKV and can copy (rip) some blurays to mkv files but others will not do so and I think it has to do with the changed security on the disks recently. Older blurays work and newer ones don't. MakeMKV can see the disks and the content but cannot rip them.

In fact I have a friend who recently had to purchase a newer player since it was impossible to update the bios in his old one to allow playing the newer disks.

If it is doing the same on CDs then I really have no clue except possibly the region coding of them. The drives are coded for the region where they work as are the disks. Mismatched coding can cause the hangs. I have seen that more on videos than audio CDs though.

I ran across this thread while researching a somewhat similar problem. Posted my solution in another forum here: https://askubuntu.com/a/1336836/792137. Thought I'd let OP know in case this is helpful.

So it turns out that it was the 5.25" enclosure that was responsible for the hang after all. It had nothing to do with the drive itself whatsoever. I bought a big old-style external drive enclosure (like the old IDE and SCSI ones, but for SATA drives with USB 2.0 and eSATA) to replace the Vantec, this one: http://www.datland.com/sata-to-usb-e...5-25-hh-black/. The odd part is that older kernels seem to tolerate the Vantec, while newer kernels do not. Either the older kernels are too tolerant of misbehaving USB devices or the newer kernels lost some device support.

Also, I have read that the Linux USB subsystem has a lot of underlying security issues that are being worked on. This could be more in the vein of older kernels being too tolerant, and would make sense because this "issue" has stuck around since down to about kernel version 4.9.101 or some such, none previous to that. This makes me think it's more of a "fix" than a "bug."

Anyways, the new enclosure works beautifully with all kernels, and while it has a bigger footprint it's built like a tank and has a fan. I paired it with a Pioneer Bluray burner instead of the ASUS (Pioneer drives seem to have more longevity according to many), so it should last a long time too.

Thank you all for your help!

Originally Posted by CapnThudd I ran across this thread while researching a somewhat similar problem. Posted my solution in another forum here: https://askubuntu.com/a/1336836/792137. Thought I'd let OP know in case this is helpful.

That's really interesting. blkid could be causing mischief, but then, why does my new enclosure work just fine with the same media (both the Pioneer and the ASUS did not work in the Vantec)? Both the Vantec and the enclosure I have now do indeed both spit out blkid errors, but the new enclosure mounts and reads the media, unlike in the Vantec. The chipset in the enclosure I have is very different from the Vantec, which is based on an ASMedia ASM1153E (which is also in the OWC Mercury Pro I believe). The chipset in the one I have now is based on a Quantum QNTM USB2 to SATA, which is undoubtedly older. I don't plan on trying to use the Vantec again, but I might try modifying the udev rule files to get rid of the superfluous error messages until they fix blkid (or the kernel). Odd though too... blkid isn't part of the kernel. Maybe it's the overall interaction of different crap going on and blkid was the straw that broke the camel's back. I dunno.

You said the new enclosure is USB2 and the bad one was USB3.
Since the bluray drive can't stream data faster than USB2 data rates I think that is a better choice anyway. The USB2 devices have been around longer and likely have all the bugs already ironed out so you get good service.

I had actually gone a bit further and instead of the big and bulky drive that fits in a drive bay I decided to get a slim, usb powered, external blueray drive (not much larger than a bluray case) and have never looked back. It just works and is not bulky so I can carry it around with my laptop wherever I go.