Info

• Which version of Pi are you using: Zero W
• Which github revision of software: Release v22.05.02 or later
• Which board version: FullSpec
• Which computer is the RaSCSI connected to: VAXstation 3100

Note this is a continuation from and summarisation of #769

Background

The VAXstation 3100 uses ROM code to boot from SCSI devices. This ROM "driver" is used until the operating system driver is loaded at which point it takes over. There are known limitations with this ROM code, the main one being the use of 6 byte SCSI commands only which limits usable boot disk sizes.

At boot time, the system issues an inquiry command, to gather basic information.
If the inquiry returns a SCSI response code of:

1 : The server sends a modesense6 command, requesting page $3F and length $0C
2 : The server sends a modesense6 command, requesting page $00 and length $0C

RASCSI returns SCSI level 2 and response level 2, so the second option occurs.
The 12 bytes requested is enough to hold the mode parameter block, but no page code data.

Issue 1 - Page code 0 support

Up until release v22.05.02, page code 0 was accepted, the 12 bytes were returned and everything was happy.
After this release and, I believe, #699 page code 0 is now rejected, so the modesense6 command generates an error and the system will not boot. RASCSI will still function if the system is booted from a physical hard drive as the OS driver does not request page 0. The physical SCSI-2 hard drives that I have, return a SCSI response code of 2 but work correctly, so they must be responding to page code 0 - I believe this page is vendor specific.

Solution 1

As the page code 0 support cannot be reinstated, the only other option is to change the reported SCSI response code (and probably the level) back to 1. This means the system will issue a request for page code $3F which is supported.
In the short term, I have modified my local copy of the code to report response code 1.
In the longer term, RASCSI will probably have to provide support for emulating SCSI-1 devices by modifying the response to the inquiry command based on other settings/filenames/etc.

Issue 2 - Checking requested and returned length

Around the same time frame, the code was also changed to check the length of the modesense request against the actual data generated and produce an error message in case of mismatch. Page code $3F means to return all code pages and is a lot longer than the 12 byte mode parameter block that is requested. This caused another error to occur.

Solution 2

The RASCSI code has already been modified to truncate any data generated by the modesense command to the length requested.

Issue 3 - Use of return codes of 0 to flag an error

Solution 2 has revealed another issue. The function ModePageDevice::AddModePages has two exit points. If there are no pages returned due to an invalid code (such as 0!), then the function exits with a code of '0' - signalling an error, otherwise the function exits returning the number of bytes generated (and truncated by the solution to issue 2).

The problem with the VAXstation requesting only 12 bytes (and that being provided by the mode parameter block), is that the requested number of bytes from the page codes is effectively zero. When the function exits with a valid value of zero (not in error), the calling procedure mistakes this for an error condition.

Solution 3

The quick and dirty solution is to change the error flag to something else. I have used -1 as a quick fix. A bigger issue is that this error flag mechanism is used throughout the RASCSI code and has the potential to cause similar issues.
In the long term, there may need to be a better way of handling exceptions that avoids these issues.