Test tape device with a VAXstation 3100 running OpenVMS 7.2

[uweseimet]

This is a follow-up ticket for #100, dealing with issues found when testing the tape device. The OS reports "tape is not valid ANSI format" when trying to list files after a foreign mount operation.

[uweseimet]

These are the logs and scripts for this ticket.

• Content list test script, trying to read a block of 32 bytes from a tape with blocks of 4 bytes:

-i 3:0 -L trace
-c 12:00:00:00:ff:00
-c 00:00:00:00:00:00
-c 0a:00:00:00:04:00 -d 01:02:03:04 -o 90
-c 0a:00:00:00:04:00 -d 01:02:03:04 -o 90
-c 0a:00:00:00:04:00 -d 01:02:03:04 -o 90
-c 11:00:ff:ff:fe:00 -o 90
-n -c 08:00:00:00:20:00 -o 90
-c 03:00:00:00:ff:00

• Logfile when sending this script to s2p with s2ptool:
  mount_s2p.txt

• Logfile when sending this script to the Sony tape drive:
  mount.txt

@Pacjunk Please add whatever may be missing. The latest s2p log triggered by your foreign mount operation should be added I think.

[Pacjunk]

Correction: The mount/foreign works correctly. The error occurs when using the backup/list command to list the contents of the first saveset. If the tape is mounted normally (files11), then the first file can be copied from tape to disk and read successfully - which shows that the tape is formatted correctly, and the files are valid. Simh can read the same .tap file (although not emulating SCSI), and a physical SCSI tape drive also works correctly.

[uweseimet]

I sse, I confused the commands. s2p can also read the file, but it has to report a SCSI error because of the block mismatch. s2p does not have an issue with the file, but with the combination of block sizes in the file and the SCSI command to read these blocks. s2psimh does not know anything about this context but just lists the file structure/contents.
The read command sent by your OS tries to read 90 bytes from the current block position, but the first block at position 0 of the tape only has 80.
Can you please attach the s2p log that results in your OS complaining?

[Pacjunk]

This is the trace log for the mount/foreign command - which completes successfully.
mount.txt

This is the log for the backup/list (what I was calling foreignlist) - which fails and produces the error "tape is not valid ANSI format". This is because it attempts to read the label block and s2p signals an error because of block size mismatch.

list.txt

[uweseimet]

Just to ensure that the test scenario for this ticket is correct: First mount.txt has to be applied, then list.txt. With your drive this sequence of commands works fine, with s2p it results in an error. Please confirm or correct.

[Pacjunk]

Correct

[uweseimet]

Good, but these were only the logs. Can you please add the matching scripts generated by s2p for these logs?

[uweseimet]

A question regarding the ANSI format: The initial blocks in the .tap files we use for testing have 80 bytes.

Offset 0 ($0): Class 0, good data record, record length 80 ($50)
Offset 88 ($58): Class 0, good data record, record length 80 ($50)
Offset 176 ($b0): Class 0, good data record, record length 80 ($50)

This is the same for the .tap files from your download link as for a blank tap file that you have initialized.
Is this ANSI format? I am asking because your OS reports an ANSI-related error when trying to read 90 byte blocks from such a file. If the 80 bytes are ANSI format, trying to read 90 bytes can never succeed, also not with a real tape drive.

[Pacjunk]

Yes, that is ANSI.

I found some information on VMS 8.4 (quite a bit later, and not using this architecture, but tape formats havent changed for years). Link is https://community.hpe.com/t5/operating-system-openvms/openvms-8-4-backup-log-disk-test-mga0-test-bck-save-not-working/td-p/4830493. The person is getting the same error messages as me. One of the replies states the following:

backup sets up a 90-byte buffer for reading the VOL1 header and EXPLICITLY checks the IO status block for 80 bytes being returned from the QIO and returns BACKUP$_NOTANSI, if that check fails.
It contains the magic number "90". I know this is not a proper solution, but what would happen if when the request is for 90 bytes, s2p just returns the data in the block (80)?

[uweseimet]

Where would take s2p the additional data from? Note that your tape drive also does not return more data than available, but signals the mismatch in the response, in the same way s2p does. RQUEST SENSE then provides the details, with custom bytes at the end of the added by your drive.

[Pacjunk]

What additional data? The above statement says that the device just returns the 80 bytes (and I assume there is a length field somewhere indicating the length of the response?)

The tape drive must at some stage return the required data though, otherwise it wouldn't work.

[uweseimet]

The drive in its sense data provides the difference of requested vs. available data, and that's it. When the requested size is bigger than the block size it will not return any data from the block at all, not even the 80 bytes that exist. The spec says:

"If the SILI bit is zero and an incorrect-length logical block is read, CHECK CONDITION status shall be returned. The ILI and VALID bits shall be set to one in the sense data and the additional sense code shall be set to NO ADDITIONAL SENSE INFORMATION."
"If the FIXED bit is zero, the INFORMATION field shall be set to the requested transfer length minus the actual logical block length."

That is what both s2p and your drive do. This is an s2p log:

[warning] Device reported CHECK CONDITION (status code $02)
...
[trace] (ID:LUN 0:0) - GOOD: NO SENSE (Sense Key $00), NO ADDITIONAL SENSE INFORMATION (ASC $00), ASCQ $00, ILI: 1, INFORMATION: 10
...
00000000  f0:00:20:00:00:00:0a:0a:00:00:00:00:00:00:00:00  '.. ...@.........'
00000010  ca:00                                            '..'

This is my HP drive:

00000000  f0:00:20:00:00:00:0a:0b:00:00:00:00:00:00:00:00  '.. .............'
00000010  00:00:00                                         '...'

This is your drive:

[warning] Device reported CHECK CONDITION (status code $02)
...
00000000  f0:00:20:00:00:00:1c:12:00:00:00:00:00:00:00:00  '.. .............'
00000010  ca:00:00:00:00:00:00:1d:1e:3a                    '.........:'

The only difference is the number of mismatched bytes, because this test was run with 4 byte blocks and 32 bytes were requested. And we have the custom bytes at the end.

IMO the conclusion is that when your drive is connected, your OS never tries to read 90 bytes from the freshly initialized tape, which only has blocks of 80 bytes. Otherwise your drive would report the same error as s2p, except for the custom bytes.

If the custom bytes have no relevance, it means that something must have happened before, which caused your OS to do what is does in the s2p case, but do a different thing, i.e. NOT trying to read 90 byte blocks, when your drive is connected.

Would you agree on this conclusion?

I checked all commands in the logs again. There is one READ POSITION, which seems to ensure that the drive is at the beginning of the tape. s2p returns data that say that it is. I don't think anything is wrong with that. My tape drive returns the same data as s2p.
The MODE SENSE/MODE SELECT sequences your OS sends are more interesting, but refer to page 0, which is mostly vendor-specific. Your drive returns this for page 0:

00000000  0b:00:90:08:13:00:00:00:00:00:02:00              '............'

s2p says (page 0 default settings for tape devices):

00000000  0b:00:00:08:00:00:00:00:00:00:02:00              '............'

This is what my HP drive says:

00000000  0b:00:10:08:13:00:00:00:00:00:00:00              '............'

Since the contents of page 0 are vendor-specific, there are no general default values. Each device that provides these data may need its own set of values, but the first bytes are mentioned in the spec, but IMO a bit fuzzy.
Fortunately s2p supports fully customizable mode pages, see https://www.scsi2pi.net/en/properties.html. Please add this line to /etc/s2p.conf:

mode_page.0.SCSI2Pi:SCSI TAPE=0b:00:90:08:13:00:00:00:00:00:02:00

It tells s2p to return the specified data for page 0 for each device that matches the INQUIRY product data in the property key.
Please run your list test again after updating /etc/s2p.conf and provide the logs. Note that this test has to use the current sources in the issue_111 branch. Please run "git pull", "git checkout issue_111" before compiling.
Whatever the outcome is, please provide the logfile. In any case this setting eliminates a difference between s2p and your drive.

Regarding the mode pages more changes may be required, because your OS might change your drive's behavior by modifying vendor-specific data. You can see this in the commands sent by your OS, which are reflected by this script:

-L trace
-i 3:0 -c 00:00:00:00:00:00 # Clear the drive status
-i 3:0 -c 1a:00:00:00:ff:00 # Read mode page 0 data
-i 3:0 -c 1a:00:00:00:ff:00 # Again
-i 3:0 -c 15:00:00:00:0c:00 -d 00:00:10:08:00:00:00:00:00:00:00:00 # MODE SELECT for page 0
-i 3:0 -c 1a:00:00:00:ff:00 # Read data from page 0 again, maybe expecting a change
-i 3:0 -c 1a:00:10:00:ff:00 # Read device configuration page
-i 3:0 -c 1a:00:50:00:ff:00 # Read changeable values of device configuration page
-i 3:0 -c 08:00:00:00:5a:00 -o 90 # The offending READ command with the size mismatch

It reads mode page 0, then writes data for mode page 0, then reads mode page 0 again. Quite likely it assumes that after the MODE SELECT the page data have changed. In case of my HD drive nothing is changed by this command. The OS also checks which data of the device configuration page are changeable, but does not send any MODE SELECT to change them.
Please send the script above to your drive using s2pexec. There must be a tape in the drive, but no data are written.

[Pacjunk]

With the mode page stuff set, the only difference is the mount now reports that the tape is write locked.

mount.txt
list.txt

I will run the script soon...

[uweseimet]

OK, thanks a lot.

I may just have found something relevant while re-checking all logs. I still don't know why my streamer does not work with Linux and the Atari. When using s2pexec with it I can successfully run the init script and can read the data it writes. When doing this I noticed that in the mount log there is a difference in the error data returned when the first filemark is hit. The OS reads the first 3 blocks, then there is another read command. This one has to fail because after the third block there is a filemark. This raises an error (with your drive, with my drive, and with s2p), but s2p does not return the requested block size in the error message, whereas my drive does. The spec also says this has to be returned. I am in the process of updating s2p accordingly.

[Pacjunk]

I ran the script twice. The first time it produced a message "Error: UNIT ATTENTION (Sense Key $06), NOT READY TO READY TRANSITION (MEDIUM MAY HAVE CHANGED) (ASC $28), ASCQ $00". The second time, no such message.

output.txt
output2.txt

[uweseimet]

Wrt your first comment: I don't know what you mean with "mode page stuff set".
Edit: Now I know, but the mode page does/should not deal with write protection. Anyway, I will check.

Wrt to the next comment: The UNIT ATTENTION was expected, this is why there was a TEST UNIT READY at the beginning of the script, to clear the unit attention status. The second time you ran the script the status was already cleared, therefore no unit attention anymore.

[uweseimet]

Running the script on your drive has revealed what the MODE SELECT does. With the MODE SENSE before the MODE SELECT your drive says that it has a default block size of 512 bytes. The MODE SELECT changes this. After the MODE SELECT your drive return 0 as default block size with the next MODE SENSE. The spec says:
"The block length specifies the length in bytes of each logical block described by the block descriptor. For sequential-access devices, a block length of zero indicates that the logical block size written to the medium is specified by the transfer length field in the command descriptor block (see 10.2.4 and 10.2.14)"
This is not yet what s2p returns in its MODE SENSE data. I will change this.

[uweseimet]

The block size change works now. Can you please check if this already improves something after updating and re-compiling issue_111? Important: Remove the mode page line from /etc/s2p.conf.
Please provide the log from the list test after this test.

[Pacjunk]

The mount crashes s2p with floating point exception

mount.txt

[uweseimet]

I just committed a fix so that when hitting a filemark the requested length is returned. The exception is most likely also fixed in the very latest issue_111 sources. If not, please provide an up to date mount script with the commands that result in the exception. The mount operation also sends the MODE SELECT, this is why it is also affected by the MODE SELECT change.
Just in case. With the latest sources I mean commit Id 05ebbe9.

[Pacjunk]

Same floating point exception

mount.txt

[uweseimet]

I see, please provide the script, so that I can reproduce the issue with my setup.

[uweseimet]

I may have found what's wrong without a script (but would still like to have it). Please update once more and re-test with commit ID 408538d.

[Pacjunk]

That fixed the floating point exception. Logs for mount:
mount.txt
mount_script.txt

Backup/list still fails. Logs:
list.txt
list script.txt

[uweseimet]

Tthe sense data when hitting the filemark in the mount test are now correct.

Please configure a custom mode page 0 again, this time with a block size 0, by updating /etc/s2p.conf:

mode_page.0.SCSI2Pi:SCSI TAPE=0b:00:90:08:13:00:00:00:00:00:00:00

Then please run the list test and provide script and log.

[Pacjunk]

list.txt
list script.txt

I'm packing up for the night. I will check in tomorrow. Cheers,

[uweseimet]

Thank you, and good night. Two more issues have been fixed this time by comparing with real drive data. I will later evaluate the new logs.

[uweseimet]

Please update your sources and re-compile. From now on, please add "-L debug" at the beginning of each script you execute with s2pexec aginst your drive. Can you execute the attached mount script and right after it the attached list script against your drive and attach the resulting logs?

mount_script.txt
list_script.txt

The debug logs are easily comparable with the diff tool now.
These are the debug logs I get with my HP drive:

mount_hp_log.txt
list_hp_log.txt

These are the debug logs I get with s2ptool, when running the scripts against s2p on my PC:

mount_s2p_log.txt
list_s2p_log.txt

The s2p and HP logs are identical except for:

1. The device name (INQUIRY data). I have configured s2p to use the INQUIRY name of your Sony drive. The HP supports synchronous transfers, which the Pi cannot support.
2. The number of bytes returned by REQUEST SENSE. The HP returns one byte more, which is vendor-specific. Your Sony drive returns 6 or so more bytes, i.e. its response in the standard fields differs from the HP.
3. The mode page data of page 10 (device configuration data), especially the ones that are configurable, even though your OS does not try to configure them. Compared to s2p the HP drive says it buffers data, reports a non-default density, and reports setmarks, which your OS has not used in the commands it has sent. (SCSI levels newer then SCSI-2 do not support setmarks anymore.)
4. MODE SENSE also reports the different density code and reports that the drive is buffering.

Let's see how the respective logs will look like for your drive.

Please confirm that running the mount script and then the list script against a real tape that was initialized with the init script is, as far as we know, the same as your OS does when you run your tests. The init script creates 3 blocks with 80 bytes and none with 90 bytes.

Wrt to s2p, there have been minor changes since yesterday, but I don't think they are relevant. Nevertheless, give it a try.
Please also run a test with the two scripts (mount and list), without re-starting s2p in between. The block size change is a temporary one, not just for s2p but also for your streamer. The scripts always seem to exeucte this change at the beginning, but we should take no risk of losing temporay state. Re-starting s2p in between these two tests changes the test scenario, just as if you were switching your streamer off and on in between.

Please delete the mode_page line in /etc/s2p.conf before running further tests.

[Pacjunk]

I suppose it is the linux driver in the middle that is formatting it. Happy to test anything...

[uweseimet]

No, it is NOT the Linux driver, but also how the devices work. There is usually a certain level of SCSI compatibility, and with SATA optical drives they directly implement it. Just the hardware interface is different.
Trust me, I know well how this is working, after 30 years experience with SCSI drivers ;-).

If you have any doubts, just use google and browse the SCSI specifications on https://www.t10.org/.

Unfortunately, compatibility ends when NVMe is involved. NVMe is very different from SCSI, and this is why as far as I know you cannot map NVMe to SCSI.

One more thing: I have an LS-120 drive (ATAPI), which unfortunately is broken now. When it was still working, I could use exactly the same SCSI commands used by s2pformat to format LS-120 media and floppy disks in this drive. No Linux involved, just sending SCSI commands to the drive with the so-called packet writing protocol. This is the same protocol still supported by optical SATA drives.

[Pacjunk]

OK, I just find it incredible that a 20yo USB floppy drive knows SCSI even though it would almost never be used in this way.

I suppose the only way out in that case is to find a more modern USB drive that actually fills out the version field (if indeed that is the problem)

[Pacjunk]

Anyway, not really an issue as the workstation already has a floppy drive

[Pacjunk]

Maybe as a test you could look at the version field and if non zero just pass it through, otherwise set to something.

[uweseimet]

See my comment above, for my more than 20 years old LS-120 (ATAPI), which knows these commands.

I doubt that modern USB drives (my floppy disk drive is about 5-10 years old) handle this differently. The field in the INQUIRY DATA is supposed to signal full compatibility to a SCSI standard, not just partial compatibility. The highest number currently is 7 or so. If a drive is not fully compatible to SCSI-2, it must not signal SCSI-2 compatibility. This means that there are probably a lot of USB/SATA drives that set this field to 0, but nevertheless implement a subset of the SCSI command set.

A driver that is flexible and supports all kinds of SCSI-compatible devices would not insist on this field having a particular value. In the case of my software for the Atari, I just send the SCSI command I would like to use. Either the drive supports it, or it does not and returns INVALID COMMAND OPERATION CODE. In this case I can use a different approach. I don't look at the SCSI level field to decide which command I use.
This try-and-error approach is not uncommon. READ/WRITE(6) are not supported anymore with newer SCSI standards, but READ/WRITE(10) or (16) have to be used. My USB floppy disk drive indeed does not support READ/WRITE(6). My Atari driver detects this from the error message and automatically switches to using READ/WRITE(10). Other drivers very likely work in a similar way, if they do not use READ/WRITE(10) anyway.

Yes, in case manipulating the field turns out to help, I will only do that if required.

[uweseimet]

One more word about the SCSI specifications: The SCSI-2 specification still contains everything (SCSI hardware and software specification) in a single document. With newer standards the specification was split into several parts: Hardware-specific parts and device-specific parts. The latter do not deal with hardware specifications anymore, but only with the commands a particular SCSI device type has to implement. Therefore, these parts of the standard are hardware-independent, and while SCSI hardware is a thing of the past, the SCSI command specifications are still being developed further. This makes a lot of sense, because there was no need to reinvent the wheel.

[Pacjunk]

The joy of old, closed source operating systems! No way you're going to get an updated driver. Can't even get the code to fix yourself. As a last ditch, I might try V7.3 which was the last version released in 2001. Maybe they did something (probably not). Alpha might be different as it was supported much longer, but of course not compatible with this hardware.

My OS still used read/write(6) heavily, but can do 10 if required. The boot roms are a different story though. read/write(6) only!

Is SCSI hardware dead now? SAS drive were still a thing when I was last at work (6 years ago now)

[uweseimet]

Regarding the boot process and READ/WRITE(6), this is the same with the Atari: Its ROMs only know READ/WRITE(6), and thus can only boot from drives supporting these commands. Because this problem is quite common, the s2p SCSI-to-USB bridge deals with it and unconditionally converts any READ/WRITE(6) command to READ/WRITE(10). Otherwise my Atari (and most other old computers) would not be able to boot from a USB drive. As far as I know the native USB stack for the Atari (there are USB hardware extensions) does the same. The Linux SG driver, which maps USB drives to SCSI and is internally used by s2p, does not do this conversion, which also shows that Linux essentially passes everything through.

Later in the Atari boot process a full-fledged hard disk driver (there are several of them, by different vendors) is loaded, and then everything only depends on this driver's capabilities. This is not too bad, because this approach makes everything quite flexible. Very recently I extended my driver software with GPT (GUID Partition Table) support, and now the Atari can even boot from and use GPT-partitioned media and not just media with an MBR scheme.

According to Wikipedia SAS still exists and SAS-5 is currently in development. SAS-4 was released in 2017.

[Pacjunk]

No luck with V7.3 (which was mostly a rebrand release so Compaq could stick their name on it).

The OS error log reports (amongst other things) "Invalid inquiry data received". So yes, must be looking at that field.

The only issue with my workstation ROMs using 6, is that the boot drive has to be 1GB or less in size, as the LBNs get too large otherwise. Once the OS loads, that driver takes over and (10) is supported.

[uweseimet]

With the Atari it is similar, but here only the boot partition has to be in the 1 GB range. The drive capacity can be higher, and once a full-fledged driver has been loaded there are no capacity restrictions anymore.
Are you sure that that your boot drive cannot be bigger than 1 GB, as long as the data required for booting are located in the first GB?

[Pacjunk]

It is a well known issue with this model. You can boot off something larger, but risk corruption due to the way the indexes are laid out. Also crash dumps will write to a particular spot without regard for what is there. You might get lucky, or maybe not.

e.g. if you install a 2GB disk, then the primary indexes will be in the middle of that 2GB so you might find it difficult to find/update files! (during boot). Yes you can move the indexes to the beginning, but there is still a risk of corruption. The standard drives when this model was released were 100 and 200 MB (and 550MB if you had an expansion box), so not an issue at the time!

I booted back with a USB memory stick installed, and it reports "2" as the version. The OS reports it as online. So confirms that the OS looks at this field. When I try to access the USB stick, I get messages:
"Invalid mode sense data returned" and "too much optional or interrupt data specified"

Looks like I'm not going to get anywhere with this system. Oh well, gave it a go!

[uweseimet]

Anyway, I will later provide an s2p version that changes this field, even if it is just for a test. Regarding the mode page data, please provide a logfile. As already mentioned, I will not start modifying data returned by a drive (except maybe for the INQUIRY data, which are a special case), but the log might reveal something interesting. Maybe even a bug in s2p. Just the fact that you tried to use the bridge with your hardware has already helped, because otherwise I would have missed that lsscsi is not installed by default on the Pi.

[uweseimet]

The testing_usb_floppy branch signals SCSI-1-CCS compatibility for USB devices that do not report to comply with any standard. This is the same SCSI level reported by your SCSI floppy drive. Let's see whether this change is worth keeping or not.
I'd like to ask you for these things:

1. Please provide the s2p log for your USB stick (invalid mode sense data)
2. Run s2p from the testing_usb_floppy branch and again provide the logs, so that we can see whether something has changed. The result will probably be the same now as with the USB stick.

Testing the change with one of my SD cards (in a USB adapter) was a surprise: It reports compatibility with SPC-4, which is from 2014. So obviously newer devices actually do support newer standards.
With a different memory card model it also is SPC-4. I don't know whether it's the card or the USB adapter that decides the level of compatibility.
I wonder what you OS does in such a case: Would it accept devices with a SCSI level newer than SCSI-2, or would it reject them?

[Pacjunk]

Results from the USB stick:
usb.txt

I will do the floppy tests tomorrow (past midnight now!)

[uweseimet]

The USB log shows that your USB stick returns strange data for mode page 1. I checked what my USB/SD card adapter does: It reports INVALID FIELD IN CDB, i.e. it does not support mode page 1.
But the response of your USB stick has helped me to refine the SCSG status code handling a bit.

These are the INQUIRY and MODE SENSE data my USB/SD adapter returns:

>s2pdump -g /dev/sg7 -I
Checking device corresponding to Linux SG 3 driver device file '/dev/sg7'

INQUIRY product data:
Vendor:               'Generic '
Product:              'MassStorageClass'
Revision:             '2011'
Device Type:          Direct Access
SCSI Level:           SPC-4
Response Data Format: SCSI-2
Removable:            Yes

Device properties for s2p properties file:
device.0.type=SCRM
device.0.name=Generic:MassStorageClass:2011
device.0.mode_page.8=08:12:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00
device.0.mode_page.28=1c:0a:00:00:00:00:00:00:00:00:00:00

It's on the SCSI2Pi website and in the manpage, but if you do not know the -I option yet: It helps to fake a real device with s2p, because it shows you the properties to use for the device name and the mode pages. These data are meaningful for non-SCSG devices, of course. If you want to create a SCRM device with the same properties as my USB adapter/SD card, you would use these data as properties for this device. You can do the same with your tape drive, in order to not just fake its name, but also its mode pages.
Can you run the same (except most likely for the device file name) command with your USB stick? And can you also run it with your SCSI floppy disk drive? I would be interested in the mode pages it supports.

Regarding faking (or not) of the SCSG SCSI level, I have changed the approach: Instead of always replacing a level of 0 against a different level, it is better to make use of the already existing s2p "--scsi-level" option. This option has only been valid for non-SCSG devices, but now you can also use it with SCSG devices. It will always set the requested level, regardless of what the SCSG device reports. You can also "downgrade" a device, which may help if you have a driver that refuses to work with anything newer than SCSI-2.
You can use "s2pctl -s" to display the SCSI levels of all attached devices.

You appear to have a lot of old hardware. Do you have a SCSI printer, or a driver for such a printer? I am asking because I would like to know whether my SCSI-2 printer emulation also works with other computers than an Atari. The SCSI-2 specification is not very detailed when it is about printers, and such a printer most likely provides a lot of vendor-specific functionality. Newer specifications do not deal with SCSI printers anymore, probably because they have never been widely used.

[Pacjunk]

I set the SCSI level to1 for the floppy, and the OS now marks the drive as "online" - good start.

However, it gives an error when I try to mount the disk:
floppy2.txt

[Pacjunk]

I tried with a different USB key, but it is doing the same modesense6 & 10 stuff:
usb2.txt

I then tried a more modern (sandisk) USB key, and this reports as level 5! The OS doesn't like this, so I forced it back to 2. It still does not work, but does not appear to do the modesense(10)...
usb3.txt

[uweseimet]

No, none of your devices support the requested mode page 1. Either they do not support it at all or return strange data. There is nothing s2p can do about it. Your OS simply requires features that these device do not support.
Do you have an USB-to-SATA adapter, so that you can connect a SATA drive? These might offer more features. It was a SATA DVD drive that I used to successfully burn a DVD.

I have just merged --scsi-level support for SCSG into the develop branch and the release-5.0 branch. The next 5.0 RC will contain this change.

[Pacjunk]

I tried another USB floppy, still no go.

Found a USB-SATA adapter and plugged in a HDD. The Pi doesn't seem to have enough power to spin it up.
I connected a SSD to the same adapter, but it still checks for mode page 1 and generates an error, so maybe that SSD doesn't support it. I have a CD/DVD ROM drive somewhere, but haven't found it yet! May not work anyway as the OS requires 512 byte sectors.

Its not really an issue for me anyway as the workstation has a floppy drive, and instead of using a USB key, I would be using the SD card in the Pi.

Interesting experiment, but doesn't seem to work very well on my workstation.

Also I don't have any SCSI printers. Didn't know that was a thing.

[Pacjunk]

Looks like the inquiry strings are being generated by the adapter, rather than the drive connected.

[uweseimet]

Please see one of my comments above on how to display the available mode pages with s2pdump. Can you please run s2pdump on your floppy drive in order to see its mode pages?

With my adapters the INQUIRY strings are from the device. When I connect my SATA devices or USB adapters/sticks they all have different INQUIRY data. The SATA INQUIRY data are identical with the SATA device names returned by these drives when they are connected to a real SATA port and you use SATA/SCSI commands to query their names, which are different for each different device, just as expected.
Just accept that the SCSI commands are essentially passed through to the connected devices ;-). And when you connect a SATA drive to the USB adapter, the SCSI commands are passed through to the USB adapter, then to the SATA drive. And the results are passed through in the other direction.

When you connect a SCSI hard drive to your system, and this hard drive does not provide mode page 1, just like the USB drives you tested this SCSI drive will also not work. Fortunately other platforms are more flexible, so that you are not limited that much to the range of devices you can use.
Sometimes the platform needlessly requires certain device characteristics. Apple in the past forced users to buy expensive Apple hardware, by using custom firware with an Apple-specific modepage. This is why I created #118. Apple's mode page has no functionality, it just returns a text string that Apple used to check whether the device was an Apple-drive or not. You could connect other drives by patching Apple's drivers, but most users were not able to do that.

Regarding SCSI printers, at least Apple offered them. I guess that there were also other vendors, because the SCSI-2 specification deals with them. There even were SCSI scanners (not covered by the specs). These scanners, e.g. manufactured by Epson, in the distant past were quite often used with Atari computers for DTP purposes.

[Pacjunk]

Well my adapter just says "seagate expansion" for everything, including the samsung SSD. It was salvaged from a USB harddrive. A generic adapter would probably work like yours.

The floppy dump is as follows:

Checking device corresponding to Linux SG 3 driver device file '/dev/sg0'

INQUIRY product data:
Vendor:               'TEAC    '
Product:              'FD-05PUB        '
Revision:             '3000'
Device Type:          Direct Access
SCSI Level:           -
Response Data Format: SCSI-1-CCS
Removable:            Yes

Device properties for s2p properties file:
device.0.type=SCRM
device.0.name=TEAC:FD-05PUB:3000
Warning: No mode page data available, medium might be missing

There is a FAT format floppy in the drive, and I can access the files when I mount it in the Pi OS.

[uweseimet]

Yes, this sounds as if your adapter is not that flexible, because it is not generic. But even with my adapter and my USB devices your hardware would not work, because my devices also do not support mode page 1.
This may be a pity, but most likely not that relevant, because you do not really have a need/use for USB devices. Your OS simply has special requirements, and that's just the way it is. Other platforms are more flexible, and in such a case you can profit a lot from SCSG. Just the fact that with some hardware you can to burn CDs/DVDs is very interesting. This is something I had not even expected, because burning DVDs is more complicated than accessing hard drives. Playing audio CDs might also work. Ripping audio CDs works at least up to a certain extent, I have already tested this. But the quality was not that good, which may also have to do with the drive and the software I was using. And it is quite slow, which is not that surprising, with all this bridging of commands and data going on.

Regarding the floppy disk drive what I meant was running s2pdump on your SCSI floppy disk drive, when you connect the drive to the Pi, as mentioned in my previous comment.

[Pacjunk]

OK I'll have to rewire things as I'm currently using the floppy scsi cable to connect the RaSCSI board.

I went through a bag of USB keys and actually found one that had code page 1. Still doesnt work though...

lexar.txt

[Pacjunk]

I managed to rewire the machine to get the floppy and the Pi on the same bus (not a simple process!), and got the following:

rx33.txt

There is a floppy in the drive

[uweseimet]

Thank your for running s2pdump with your SCSI floppy drive. The floppy drive might not have any mode pages, and your OS might be aware of this somehow. Or your drive does not support getting all mode pages (with page code $3f, which is what s2pdump does), but just supports getting single page. But this is just a guess. Or maybe it makes a difference for your OS whether I drive is compliant with SCSi-2 or just with SCSI-1-CCS. Have you tried setting the SCSI level of one of your USB sticks or your USB floppy drive to 1 instead of 2? Maybe this makes a difference.
Regarding the USB key, your OS appears to expect not just mode page 1 to be present, but also certain data in it. Well, we have already seen that your OS has very special requirements.

[Pacjunk]

...and yet it will work with any SCSI hard drive I put in it! I don't think it's overly fussy, just that manufacturers of other devices are cutting corners and implementing the bare minimum. It was interesting going through the bag of USB keys with s2pdump. Some keys returned no code pages at all, some page 5, some page 28, and another I can't remember. The only one I found that supported page 1, also supported the other 3.

I have dumped the code pages for the workstation floppy using an OS utility. The utility just tries all sorts of pages, doesn't mean the drive supports it. Note that there is a converter board that converts a standard 1.44MB floppy into a SCSI drive. I would assume the board is doing most of the work. Certainly the vendor information is supplied by the board.

floppy.txt

[uweseimet]

Most hard drives support mode page 1 (and others), because for hard drives some of these pages are also listed in the SCSI specification. Not all of them are probably mandatory.

You are right, some manufacturers only implement the bare minimum, or not even that. Just like with SCSI drives in the past, prices of USB hardware differ, and this is not only because of hardware differences. The firmware also differs, and the development of a good firmware also costs money.
Most of my SCSI drives you can not format with a different sector size than 512 bytes, but some support sizes that are multiples of 4, because some exotic platforms require other sizes. Drives that offer this feature were more expensive, quite likely also in order to cover the development costs. And they may need bigger ROMs etc.

The "problem" with your hardware is that it expects a lot of SCSI/device/firmware features to be available, and some of them are not needed during normal operations. To expect a lot is not wrong, but it can limit the range of devices you can use.
The Sony tape drive is a interesting case in this context. Most likely there are a lot of platforms where this drives works fine. Otherwise Sony would have been aware of the bug and would have fixed it, or nobody would have bought this hardware.
If you just use tar with a tape drive, you hardly need any features. tar does not require filemarks, spacing or variable block sizes. Essentially, it just reads and writes sequences of fixed-sized blocks.