Anyone else experienced this:
I have a nice modern LG WH16NS40 Blu-ray rewriter, and a nice modern computer case with zero drive bays, so I got an OWC external drive case with sata -> usb3 to hold the drive.
Everything I've tried works like a champ on this drive except trying to rip a DVD. It hangs at open as long as I care to wait. (Blu-ray, no problem, cdrom, no problem, writing Blu-ray, no problem). The strace looks like:
stat("/dev/sr0", {st_mode=S_IFBLK|0660, st_rdev=makedev(0xb, 0), ...}) = 0 openat(AT_FDCWD, "/dev/sr0", O_RDONLY <-- never finishes till I unplug it
If I put the drive in another computer that does have an internal drive bay, it reads DVDs just fine with a direct sata connection.
Meanwhile an old small portable USB powered pioneer drive can read DVDs just fine.
Just curious if there is some kind of known bug out there. I guess my work-around is to always use the pioneer for DVDs.
Hi,
Tom Horsley wrote:
I have a nice modern LG WH16NS40 Blu-ray rewriter [...] trying to rip a DVD [...] openat(AT_FDCWD, "/dev/sr0", O_RDONLY <-- never finishes till I unplug it
That's not usual. I have a BH16NS40 in a USB box from DeLOCK. No problems to open it with any medium.
In general it is strange that open(2) or openat(2) make a difference between BD and DVD media. At that time the computer has no clue what's in the drive. It might be about using option O_NDELAY. In libburn's source code i have this comment from 2007: Switched to O_NDELAY for LKML statement 2007/4/11/141 by Alan Cox: "open() has side effects. The CD layer allows you to open with O_NDELAY if you want to avoid them." (IIRC it was about accessing a drive that is busy with burning and takes offense already from open(2).)
What program do you use for ripping ?
If not yet dd, what do you get from this:
image_file=...path.where.to.store.data...
dd if=/dev/sr0 bs=1M of="$image_file"
or
dd if=/dev/sr0 bs=1M iflag=nonblock of="$image_file"
What would a burn program say about the DVD ? E.g. one of these runs:
dvd+rw-mediainfo /dev/sr0
xorriso -outdev /dev/sr0 -toc
Have a nice day :)
Thomas
On Thu, 09 Apr 2020 09:29:01 +0200 Thomas Schmitt wrote:
That's not usual. I have a BH16NS40 in a USB box from DeLOCK. No problems to open it with any medium.
My current theory is that it has something to do with the phase II region protection (which is supposed to be hardware rather than software), but I did try to set the region with regionset and it still doesn't work. I'll try setting the region in a windows box and see if it does a better job.
It doesn't really matter what program I use, everything hangs as soon as it tries to do the first open.
Hi,
Tom Horsley wrote:
My current theory is that it has something to do with the phase II region protection (which is supposed to be hardware rather than software)
That would be plausible.
But letting the drive hang on open with the need for power-off seems to be a drastic reaction.
It doesn't really matter what program I use, everything hangs as soon as it tries to do the first open.
Even dvd+rw-mediainfo and xorriso ?
I would be interested to see the very verbous output of
xorriso -scsi_log on -outdev /dev/sr0 -toc 2>&1 | tee -i /tmp/xorriso.log
It will be quite short if already open(2) fails. But in case of region resctrictions, i'd expect it to refuse on the first READ command. Maybe the SCSI error codes can tell when it bails out and whether it becomes incommunicado then.
If /tmp/xorriso.log is long (one or two dozen KB) then send it to my mail address directly. I will then report what it tells me. If it is short, please post it here.
Have a nice day :)
Thomas
On Thu, 09 Apr 2020 15:33:38 +0200 Thomas Schmitt wrote:
If /tmp/xorriso.log is long (one or two dozen KB) then send it to my mail address directly. I will then report what it tells me. If it is short, please post it here.
It sat here for about three minutes till I got bored:
zooty> xorriso -scsi_log on -outdev /dev/sr0 -toc 2>&1 | tee -i /tmp/xorriso.log xorriso 1.5.2 : RockRidge filesystem manipulator, libburnia project.
Then I powered off the drive, and the rest came out:
139255322 us [ 180481085 ]
INQUIRY 12 00 00 00 24 00 From drive: 36b 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 25 us [ 180481551 ] --- SG_IO: host_status= 0x7 SG_ERR_DID_ERROR (Internal error detected in the host adapter) --- SG_IO: Gave up connection to drive libburn : FAILURE : SCSI command 12h yielded host problem: 0x7 SG_ERR_DID_ERROR (Internal error detected in the host adapter) libburn : FAILURE : Command: INQUIRY : 12 00 00 00 24 00 : dxfer_len= 36 libburn : FATAL : Lost connection to drive xorriso : FAILURE : Cannot acquire drive '/dev/sr0' xorriso : aborting : -abort_on 'FAILURE' encountered 'FATAL'
If I run it under strace, it is by golly hanging at open:
stat("/dev/sr0", {st_mode=S_IFBLK|0660, st_rdev=makedev(0xb, 0), ...}) = 0 openat(AT_FDCWD, "/dev/sr0", O_RDWR|O_EXCL|O_NONBLOCK
But wait! After thirty second or so the open finally worked (returned 3) and it hangs in a new place:
ioctl(3, HDIO_GET_IDENTITY, 0x7fffd76decd0) = -1 EINVAL (Invalid argument) ioctl(3, SG_GET_SCSI_ID, 0x7fffd76dee80) = -1 EINVAL (Invalid argument) ioctl(3, SG_IO, {interface_id='S', dxfer_direction=SG_DXFER_NONE, cmd_len=6, cmdp="\x00\x00\x00\x00\x00\x00", mx_sb_len=0, iovec_count=0, dxfer_len=0, timeout=12345, flags=0
That one hangs long enough for me to decide to turn off the drive again.
Hi,
139255322 us [ 180481085 ]
This says that the run already lasted 180 seconds and the SCSI command to which this line belongs lasted 139 seconds. (Your patience is in good shape.)
INQUIRY
There are only two of these commands in the course of normal drive examination by libburn. So the long running command was probably START/STOP UNIT.
Whatever, open(2) worked. Else there would be no SCSI transactions.
12 00 0dd0 00 24 00 From drive: 36b 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 25 us [ 180481551 ] --- SG_IO: host_status= 0x7 SG_ERR_DID_ERROR (Internal error detected in the host adapter)
This is an error reported by the Linux kernel, not by the drive.
https://www.tldp.org/HOWTO/SCSI-Generic-HOWTO/x291.html says "SG_ERR_DID_ERROR [0x07] Internal error detected in the host adapter. This may not be fatal (and the command may have succeeded). The aic7xxx and sym53c8xx adapter drivers sometimes report this for data underruns or overruns. [1] [...] [1] In some cases the sym53cxx driver reports a DID_ERROR when it internally rounds up an odd transfer length by 1. This is an example of a "non-error".
Well, those drivers seem to be for parallel SCSI which the cool guys had instead of parallel ATA back 20 years. I doubt that USB drivers report SG_ERR_DID_ERROR if no error happened. The reply of 36 0-bytes is not what a drive should send. It should rather tell its manufacturer name, model name, and firmware revision.
--- SG_IO: Gave up connection to drive
That's a decision of libburn. Thus the misery ends for this run.
If I run it under strace, it is by golly hanging at open: openat(AT_FDCWD, "/dev/sr0", O_RDWR|O_EXCL|O_NONBLOCK
Hrmpf. strace reports "openat(2)" where libburn calls open(2).
But wait! After thirty second or so the open finally worked (returned 3)
So far so good. Although very suspicious by the long time.
and it hangs in a new place: ioctl(3, SG_IO, {interface_id='S', dxfer_direction=SG_DXFER_NONE, cmd_len=6, cmdp="\x00\x00\x00\x00\x00\x00", mx_sb_len=0, iovec_count=0, dxfer_len=0, timeout=12345, flags=0
That's one of the SCSI command transaction where the kernel as messenger between userland and drive. cmdp tells that the command is TEST UNIT READY, the most harmless of all. It just asks the drive whether it is ok to request access to the medium or to ask for info about the medium. If the answer is "not yet", then libburn will repeat to send the command until the drive reports "ready" or "finally not ready".
Above Linux SG_ERR_DID_ERROR happened after at least one such TEST UNIT READY command. The drive had already returned from a START/STOP UNIT command which told it to load the tray and to speed up the disc.
------------------------------------------------------------------
This does not really look like region resctrictions. Much more like controller or cable problems.
If this was a slim drive in a fancy flat USB box i'd ask whether it gets its electrical power via USB cable. There have been cases that drives fell unconscious while speeding up the disc because the computer did not deliver stable voltage.
But WH16NS40 is a 5.25 inch drive. Matching boxes usually have an own power supply (which wastes energy by staying warm).
What model of OWC box exactly do you have ?
Have a nice day :)
Thomas
On Thu, Apr 9, 2020 at 9:29 AM Thomas Schmitt scdbackup@gmx.net wrote:
Hrmpf. strace reports "openat(2)" where libburn calls open(2).
strace reports the name of the Linux system call, which is indeed openat. The open(2) and openat(2) functions (and open64(2) and openat64(2) on some systems) are C library functions that invoke the openat system call.
On Thu, 09 Apr 2020 17:29:46 +0200 Thomas Schmitt wrote:
If this was a slim drive in a fancy flat USB box i'd ask whether it gets its electrical power via USB cable. There have been cases that drives fell unconscious while speeding up the disc because the computer did not deliver stable voltage.
My pioneer USB powered slim drive actually works flawlessly. I can use dvdbackup (as an example) to read and decrypt a dvd with that drive. So I guess my algorithm is to always use the pioneer for DVD and the LG/OWC box for everything else.
But WH16NS40 is a 5.25 inch drive. Matching boxes usually have an own power supply (which wastes energy by staying warm).
What model of OWC box exactly do you have ?
This one bought via amazon:
https://www.amazon.com/gp/product/B06XRCCV44/ref=ppx_yo_dt_b_search_asin_tit...
With this LG drive installed:
https://www.amazon.com/gp/product/B00E7B08MS/ref=ppx_yo_dt_b_asin_title_o02_...
Hi,
139255322 us [ 180481085 ]
This says that the run already lasted 180 seconds and the SCSI command to which this line belongs lasted 139 seconds. (Your patience is in good shape.)
INQUIRY
There are only two of these commands in the course of normal drive examination by libburn. So the long running command was probably START/STOP UNIT.
Whatever, open(2) worked. Else there would be no SCSI transactions.
12 00 0dd0 00 24 00 From drive: 36b 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 25 us [ 180481551 ] --- SG_IO: host_status= 0x7 SG_ERR_DID_ERROR (Internal error detected in the host adapter)
This is an error reported by the Linux kernel, not by the drive.
https://www.tldp.org/HOWTO/SCSI-Generic-HOWTO/x291.html says "SG_ERR_DID_ERROR [0x07] Internal error detected in the host adapter. This may not be fatal (and the command may have succeeded). The aic7xxx and sym53c8xx adapter drivers sometimes report this for data underruns or overruns. [1] [...] [1] In some cases the sym53cxx driver reports a DID_ERROR when it internally rounds up an odd transfer length by 1. This is an example of a "non-error".
Well, those drivers seem to be for parallel SCSI which the cool guys had instead of parallel ATA back 20 years. I doubt that USB drivers report SG_ERR_DID_ERROR if no error happened. The reply of 36 0-bytes is not what a drive should send. It should rather tell its manufacturer name, model name, and firmware revision.
--- SG_IO: Gave up connection to drive
That's a decision of libburn. Thus the misery ends for this run.
If I run it under strace, it is by golly hanging at open: openat(AT_FDCWD, "/dev/sr0", O_RDWR|O_EXCL|O_NONBLOCK
Hrmpf. strace reports "openat(2)" where libburn calls open(2).
But wait! After thirty second or so the open finally worked (returned 3)
So far so good. Although very suspicious by the long time.
and it hangs in a new place: ioctl(3, SG_IO, {interface_id='S', dxfer_direction=SG_DXFER_NONE, cmd_len=6, cmdp="\x00\x00\x00\x00\x00\x00", mx_sb_len=0, iovec_count=0, dxfer_len=0, timeout=12345, flags=0
That's one of the SCSI command transaction where the kernel as messenger between userland and drive. cmdp tells that the command is TEST UNIT READY, the most harmless of all. It just asks the drive whether it is ok to request access to the medium or to ask for info about the medium. If the answer is "not yet", then libburn will repeat to send the command until the drive reports "ready" or "finally not ready".
Above Linux SG_ERR_DID_ERROR happened after at least one such TEST UNIT READY command. The drive had already returned from a START/STOP UNIT command which told it to load the tray and to speed up the disc.
------------------------------------------------------------------
This does not really look like region resctrictions. Much more like controller or cable problems.
If this was a slim drive in a fancy flat USB box i'd ask whether it gets its electrical power via USB cable. There have been cases that drives fell unconscious while speeding up the disc because the computer did not deliver stable voltage.
But WH16NS40 is a 5.25 inch drive. Matching boxes usually have an own power supply (which wastes energy by staying warm).
What model of OWC box exactly do you have ?
Have a nice day :)
Thomas
On Wed, 8 Apr 2020 at 22:21, Tom Horsley horsley1953@gmail.com wrote:
Anyone else experienced this:
I have a nice modern LG WH16NS40 Blu-ray rewriter, and a nice modern computer case with zero drive bays, so I got an OWC external drive case with sata -> usb3 to hold the drive.
Everything I've tried works like a champ on this drive except trying to rip a DVD. It hangs at open as long as I care to wait. (Blu-ray, no problem, cdrom, no problem, writing Blu-ray, no problem). The strace looks like:
stat("/dev/sr0", {st_mode=S_IFBLK|0660, st_rdev=makedev(0xb, 0), ...}) = 0 openat(AT_FDCWD, "/dev/sr0", O_RDONLY <-- never finishes till I unplug it
External USB cases often work well for simple use cases, but each model has
issues with off-label use cases. I had 2 of the same model from the same vendor have different issues.
OWC has been better than the average low-priced Amazon kit. Have you contacted them?
If I put the drive in another computer that does have an internal drive
bay, it reads DVDs just fine with a direct sata connection.
Meanwhile an old small portable USB powered pioneer drive can read DVDs just fine.
Just curious if there is some kind of known bug out there. I guess my work-around is to always use the pioneer for DVDs.
The bug may only appear for certain combinations of drive and USB chipset. Check for firmware updates for the drive.
On Thu, 9 Apr 2020 11:48:30 -0300 George N. White III wrote:
The bug may only appear for certain combinations of drive and USB chipset. Check for firmware updates for the drive.
Yep. I'm thinking it has something to do with the chipset. I believe I did read about some usb problem some chips have (but it was a while back and I don't remember where I saw it). This is a GIGABYTE Z390 AORUS Ultra in the machine I'm trying to use. The drive is brand new and came with the latest firmware (though lots of people go to a lot of trouble to install old firmware in this drive to get UHD Blu-ray ripping to work :-).
Anyway, all I need to do is remember to use the little pioneer drive when I want to rip a dvd and I'm OK. I guess there are some things man is not meant to understand.
One more piece of mysterious info for the record:
VLC on Windows 10 can play a DVD just fine with the USB drive (the exact same one that hangs on two different linux systems I've now tried).
VLC on linux hangs just like everything else.
I think I'll now give up completely trying to understand what is going on :-).
On Thu, 9 Apr 2020 15:46:55 -0400 Tom Horsley wrote:
I think I'll now give up completely trying to understand what is going on :-).
I lied :-).
I tried one more experiment which led to this bugzilla:
https://bugzilla.redhat.com/show_bug.cgi?id=1822948
When the drive in the USB enclosure worked flawlessly in Windows 10, I booted the same Windows 10 box from a fedora live image, and the hang was back. Seems like a kernel bug to me.
-
George N. White III -
Jerry James -
Thomas Schmitt -
Tom Horsley