Hi, Borden wrote: > There may be a problem with whatever controls /dev/sr0,
That's the layers of SCSI drivers in the kernel. https://github.com/torvalds/linux/tree/master/drivers/scsi sr.[ch] sg.[ch] They are not overly verbose. Expect to see error messages from the DVD drive or timeout messages from the driver layers in the output of dmesg. The messages will begin by "sr" like this harmless startup message [ 1.604031] sr 1:0:0:0: Attached scsi CD-ROM sr0 > When the drive hits a bad sector or something, all activity on the drive > halts, and it refuses to read anything until I cut the power to the drive > and power it back on. Did you wait for about 200 seconds after the reading program ended ? That's usually the timeout for stuck SCSI commands. > Sometimes, I can eject the DVD, but other times it > refuses to do that, too. Tray locking against manual ejection is controlled by SCSI commands. Can program "eject" or a burn program access the drive and then eject the tray ? eject /dev/sr0 xorriso -outdev /dev/sr0 -eject out (It may be that xorriso reports the drive being in use after some time of waiting for it to get accessible.) > Obviously, even if the firmware is bugged, Linux should have a more graceful > way of recovering that doesn't require me power cycling the drive every few > minutes. If not the drive has gone mad, then Linux should recover from stuck states by its timeouts. A reliable way to make a drive incommunicado was to start a CD burn run and then having the burn program crash without telling the drive that the writing was aborted. Then the drive waits for the SCSI commands for writing or ending and no software is willing to emit the end commands without having succeeded with burn preparations first. But the drive will not accept burn preparations while still burning. > But aside from repeated kernel errors that there is a problem > reading from /dev/sr0, it's not clear whether the kernel or drive are at > fault. What exactly do these error messages say ? > Again, I'm trying to isolate the problem that's causing my DVD/BD drive to > lock up and refuse to accept any other commands so I can file a more useful > bug than "My drive stops working on damaged media". You can avoid the higher SCSI driver layers of Linux by letting xorriso read the DVD. Maybe you get better error messages. In general it is easier to abort xorriso than it is to abort a kernel read thread. (xorriso uses libburn which uses the sg driver level of Linux.) xorriso -outdev /dev/sr0 -check_media use=outdev what=disc -- The run will report the medium type, medium status, and pacifier messages: Media current: DVD+RW Media status : is written , is appendable Media summary: 4 sessions, 1416644 data blocks, 2767m data, 1716m free xorriso : UPDATE : 32 of 2295104 blocks read in 3 s , 0.0xD xorriso : UPDATE : 2752 of 2295104 blocks read in 4 s , 4.0xD xorriso : UPDATE : 5664 of 2295104 blocks read in 5 s , 4.3xD ... xorriso : UPDATE : 2293856 of 2295104 blocks read in 470 s , 10.3xD xorriso : UPDATE : 2295104 of 2295104 blocks read in 470 s = 7.2xD Media checks : lba , size , quality Media region : 0 , 2295104 , + good Because of -check_media option "what=disc" not only the detected size of the ISO 9660 filesystem is read but reading ends only at the end of the DVD medium (which is fully formatted in my example). You may let xorriso collect the read block in a data file: file=$HOME/data_from_sr0.img xorriso -outdev /dev/sr0 -check_media use=outdev what=disc data_to="$file" -- The various options of xorriso command -check_media are documented in man xorriso at command -check_media_defaults. If a data chunk (DVD ECC block = 16 disc blocks) is bad and the drive does not get stuck, then xorriso will go on with trying to read the next chunk. If the xorriso run shall be aborted (e.g. because it seems futile to go on trying) then it is preferrable to touch the abort file /var/opt/xorriso/do_abort_check_media rather than pressing Ctrl+C. The end of the run will be more orderly and the final summary will be put out. The end of the xorriso run will have to wait for the pending SCSI command transaction to end. So at least 200 seconds of patience are advised before power-cycling the drive. Have a nice day :) Thomas
