[Info-vax] Error using fibre channel target on FreeBSD from OpenVMS

[John Wallace]

On Thursday, 28 April 2022 at 10:02:56 UTC+1, Matthew R. Wilson wrote:
> Progress!!! 
> 
> After looking at the data from Volker's system, the most obvious 
> difference in the initial standard INQUIRY response is that his DGA 
> device was reporting SCSI version 2. FreeBSD's SCSI target 
> implementation reports SPC5. SPC5 appears to be too new for OpenVMS to 
> accept. I built a new kernel which reports an older version (after 
> experimentation, I don't need to go all the way down to SCSI 2, I just 
> need to go down one version to SPC4) and... the device shows as 'Online' 
> in OpenVMS! 
> 
> After that, the SCSI_INFO output appears largely similar to Volker's -- 
> all of the data for the various sense pages is listed out. 
> 
> Hurdles remain, though: when I try to initialize the volume, I get the 
> error: %INIT-F-MEDOFL, medium is offline 
> 
> BUT... I see in the logs on the FreeBSD side that VMS was repeatedly 
> issuing READ LONG(10) commands (operation code 0x3e), and it looks like 
> FreeBSD hasn't implemented that command. In the source, I see it's just 
> stubbed out to always return an illegal request check condition. 
> 
> At least the problem is clear. I'll have to look into what it takes to 
> implement support for the READ LONG(10) command, and see what 
> command(s), if any, it gets stuck on next. 
> 
> Thanks for everyone's input thus far. Now that I'm past the problem of 
> OpenVMS being willing to even TRY to work with the device, it looks like 
> at this point it will just be a SCSI command troubleshooting and 
> implementation exercise. That could take time as I'm entirely unfamiliar 
> with this FreeBSD codebase, but I'm optimistic it may be possible when I 
> have some time I can dedicate to it. 
> 
> Thanks, 
> Matthew

READL (aka "read long") and the equivalent write command are important parts of VMS volume shadowing - so important they're even mentioned in the Software Product Description. Have a read (if you haven't already done so), see if it helps you work out what's going on, and whether it matters for your needs or not.

E.g. this is one snippet from the VSIVMS Volume Shadowing Guide at e.g. https://vmssoftware.com/docs/VSI_VOLUME_SHAD_GD.pdf section 1.3.2 Supported Devices:

"SCSI disks that do not implement READL and WRITEL have limited support because these
disks do not provide for shadowing data repair (disk bad block errors) features. Such disks can
cause members to be removed from the shadow set, if certain error conditions arise that cannot
be corrected. See Section 4.11.5.1 for how to determine if a SCSI disk supports READL and
WRITEL commands."

There are other potentially relevant references in that manual too e.g. MOUNT /OVERRIDE=NO_FORCED_ERROR.

Have a lot of fun.