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 _______________________________________________ users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@xxxxxxxxxxxxxxxxxxxxxxx
