[Info-vax] Error using fibre channel target on FreeBSD from OpenVMS
Matthew R. Wilson
mwilson at mattwilson.org
Fri Apr 29 16:03:26 EDT 2022
On 2022-04-28, Matthew R. Wilson <mwilson at mattwilson.org> wrote:
> 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.
After further experimentation, I think the READ LONG exceptions are red
herrings.
I think VMS is issuing the READ LONG commands to determine if the target
supports the command, and if so, what the correct byte transfer length
value is. I don't think the fact that all the commands fail is fatal.
After going through that process, the flags in the SDA SHOW DEVICE
command include "nofe", which the Volume Shadowing guide tells us means
the device doesn't support the READ/WRITE LONG commands.
After all those commands fail during the attempt to initialize the
device, VMS issues a few 1-block read and write commands. Then it pauses
for a bit, cancels all requests and says the medium is offline.
So... I don't think it's the READ LONG stuff that's fatal, I think
there's some other mystery problem I need to figure out. It almost seems
like the last READ it sends is timing out, but that doesn't really seem
possible. If I issue the same READ myself against the target, it returns
right away, just as the previous reads did. I need to look more closely
and see if there was an earlier SENSE command or something that wasn't
being satisfied.
In any case... I understand READ/WRITE LONG is critical for proper
operation of Volume Shadowing, but I don't think it's what's preventing
OpenVMS from working with a fibre channel target.
Thanks,
Matthew
More information about the Info-vax
mailing list