> On 15. Nov 2024, at 17.34, John Meneghini <jmeneghi@xxxxxxxxxx> wrote: > ... >> Now, st does allow zero retries. In addition to this, the requests use either REQ_OP_DRV_IN >> or REQ_OP_DRV_OUT and these requests are not retried. So, now POR UAs reach >> st (as the experiments have indicated). > > Yes, the only time I've see the POR UA not get passed to the st driver is with scsi_debug, when > the driver first loads. > > [tape_tests]# modprobe -r scsi_debug > [tape_tests]# modprobe scsi_debug ptype=1 max_luns=1 dev_size_mb=10000 > [Fri Nov 15 09:28:51 2024] scsi_debug:sdebug_driver_probe: scsi_debug: trim poll_queues to 0. poll_q/nr_hw = (0/1) > [Fri Nov 15 09:28:51 2024] scsi host8: scsi_debug: version 0191 [20210520] > dev_size_mb=10000, opts=0x0, submit_queues=1, statistics=0 > [Fri Nov 15 09:28:51 2024] scsi 8:0:0:0: Sequential-Access Linux scsi_debug 0191 PQ: 0 ANSI: 7 > [Fri Nov 15 09:28:51 2024] scsi 8:0:0:0: Power-on or device reset occurred > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > The sg driver is clearing the UA here. I enabled some SCSI debug logging (0x3001). It shows that the UA is received as response to a 'Report supported operation codes' command. I looked at the code and it seems that scsi_add_lun() in scsi_scan.c uses this operation. So, the UA is not cleared by any ULD. ... > I have no idea whey the scsi_debug driver doesn't support READ BLOCK LIMITS. > scsi_debug does not support any "tape-specific" commands. This includes READ BLOCK LIMITS, WRITE FILEMARKS, REWIND, etc. Additionally the CDB definition for tapes is special for reads and writes. REWIND is implemented in scsi_debug, but it is buggy. MODE SENSE and MODE SELECT without any page (i.e., interested only in block descriptor) are not allowed in scsi_debug. St is designed to work with minimal command support. READ BLOCK LIMITS is not needed. I have fixed REWIND and MODE SENSE/SELECT for my tests. Using fake_rw I can "read" tape, but writing does not work because WRITE FILEMARKS is missing. ... > Another problem with using scsi_debug is: > > [tape_tests]# sg_reset --target /dev/sg3 > > This does nothing. I have to use the /dev/st device to reset. This is not true if you have a real tape device. In my tests, resets using both /dev/nstx and /dev/sgx have been working. However, you should note that when using /dev/nstx, the device is opened using st driver, whereas if /dev/sgx is used, it is opened using the sg driver. Digging deeper reveals that SG_SCSI_RESET through st does not go through sg at all. (Both end up to scsi_ioctl_reset() in scsi_error.c, but in a different way.) (And if you use, /dev/stx, the tape is rewound.) > [tape_tests]# sg_reset --target /dev/nst1 > [Fri Nov 15 09:37:18 2024] st 8:0:0:0: [st1] check_tape: 1064: pos_unknown 0 was_reset 1 ready 0 > [Fri Nov 15 09:37:18 2024] st 8:0:0:0: Power-on or device reset occurred > [Fri Nov 15 09:37:18 2024] st 8:0:0:0: [st1] Error: 2, cmd: 0 0 0 0 0 0 > [Fri Nov 15 09:37:18 2024] st 8:0:0:0: [st1] Sense Key : Unit Attention [current] > [Fri Nov 15 09:37:18 2024] st 8:0:0:0: [st1] Add. Sense: Scsi bus reset occurred > [Fri Nov 15 09:37:18 2024] st 8:0:0:0: [st1] st_chk_result: 421: pos_unknown 1 was_reset 1 ready 0, result 2 > ^^^^^^^^^^^^^^^^^^ > Now we've set pos_unkown. If you use /dev/sgx, you are not supposed to see any output. The next operation sent to /dev/nstx (e.g., mt status) sets pos_unknown. In the example above, you probably have used sg_reset -target /dev/sg1 previously and it is opening /dev/nst1 the the next sg_reset that catches the previous reset. ... > > Please try my latest version of the tape_reset_debug.sh script. I looked at the script. It tries to write to tape and that is not implemented in the scsi_debug I have
