Re: [PATCH v2 0/4] scsi: st: scsi_error: More reset patches

[John Meneghini <jmeneghi@redhat.com>]

On 12/13/24 10:09, John Meneghini wrote:
>>  previously suspected that the first POR UA is caught by scsi scanning when it issues
>> MAINTENANCE_IN to get the supported opcodes. This happens when scanning calls
>> scsi_cdl_check(). However, this function does not do anything if Scsi level is less than
>> SPC-5 (ANSi 7). Scsi_debug claims SPC-5 and so scsi_cdl_check() gets the UA
>> before the st device exists. Your drive probably is reporting a level less than SPC-5
>> and so the UA is not received by the scanning code.
> 
> No, I don't have a problem with the tape drive. Everything works correctly with the tape drive.  You can see the test results 
> log for my latest test with the tape drive at:

Sorry, I misunderstood your comment.  Yes, the tape device I am using for testing is reporting SPC-3.

[root@to-be-determined tape_tests]# sg_inq /dev/nst0
standard INQUIRY:
   PQual=0  PDT=1  RMB=1  LU_CONG=0  hot_pluggable=0  version=0x05  [SPC-3]
   [AERC=0]  [TrmTsk=0]  NormACA=0  HiSUP=0  Resp_data_format=2
   SCCS=0  ACC=0  TPGS=1  3PC=0  Protect=0  [BQue=0]
   EncServ=0  MultiP=1 (VS=0)  [MChngr=0]  [ACKREQQ=0]  Addr16=0
   [RelAdr=0]  WBus16=0  Sync=0  [Linked=0]  [TranDis=0]  CmdQue=1
   [SPI: Clocking=0x0  QAS=0  IUS=0]
     length=96 (0x60)   Peripheral device type: tape
  Vendor identification: QUANTUM
  Product identification: ULTRIUM 4
  Product revision level: U53F

So you are saying this this issue of the mid layer not reporting the first POR UA would be seen if my tape drive were in SPC-5 
device.

/John