While doing some detective work, I found a serious problem. So, please hold these patches again. More about the reason below. > On 11. Dec 2024, at 23.57, John Meneghini <jmeneghi@xxxxxxxxxx> wrote: > > Sorry it has taken me so long to get back to this.... > > I've tested these patches with both my tape drive and with scsi_debug tape emulation. > > see: > > https://github.com/johnmeneghini/tape_tests > > All hardware tests are passing and everything is working as expected with the tape drive tests, but the power on reset behavior of the scsi_debug test is still showing the some strangeness. > > https://github.com/johnmeneghini/tape_tests/blob/master/tape_reset_debug.sh > > Specifically, every time you reload the scsi_debug driver the SCSI mid layer clears the POR UA. If I am not mistaken, your intention with adding the counters for ua_new_media_ctr and ua_por_ctr to the mid layer was to catch these events and report them to the upper layer driver. > Well, the counters work as designed. The st driver stores reference values when the driver probing the device. This means that the UAs before the probe are missed. I 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. I changed scsi_debug so that it reports SPC-4 (ANSI 6). After this change st received the POR UA. But I had 'mt stsetoptions' in my script and it failed! The problem is that no driver options for the device can be set before something has been done to clear the blocking. For instance, the stinit tool is a recommended method to set the options based on a configuration file, but it fails. Note that this problem has existed since commit 9604eea5bd3ae1fa3c098294f4fc29ad687141ea (for version 6.6) that added recognition of POR UA as an additional method to detect resets. Nobody seems to have noticed this problem in the "real world". (Using was_reset was not problematic because it caught only resets initiated by the midlevel.) A solution might be to add some more ioctls to the list of allowed commands. But I must think about this a little more.
