search

PiSCSI / piscsi

PiSCSI allows a Raspberry Pi to function as emulated SCSI devices (hard disk, CD-ROM, and others) for vintage SCSI-based computers and devices. This is a fork of the RaSCSI project by GIMONS.
https://piscsi.org
BSD 3-Clause "New" or "Revised" License
537 stars 82 forks source link

OpenVMS/VAX Compatibility #1117

Closed Pacjunk closed 1 year ago

Pacjunk commented 1 year ago

Info

Describe the issue

I have discovered an issue with older versions of OpenVMS/VAX on versions 7.0 and earlier where the OS loses connection to the disk and waits forever (aka mount verification). I have tested on my fork of Bluescsi and also PiSCSI and both emulators show the fault. The simh emulator, however, works fine. So after some trial and error with my bluescsi fork, I have found that some extra flags are required in the modesense "read-write error recovery" page.

Code snippet from simh:

if ((pc == 0x1) || (pc == 0x3F)) {
    bus->buf[bus->buf_b++] = 0x1;                       /* R/W error recovery page */
    bus->buf[bus->buf_b++] = 0xA;                       /* page length */
    bus->buf[bus->buf_b++] = 0x26;                      /* TB, PER, DTE */

I have tested the various flags and all three flags must be set or it won't work.

I have tracked this down in PiSCSI to the Disk::AddErrorPage function in disk.cpp

Now as my C++ skills are rather poor and I don't really understand the arrays and vectors used in this section of code, I was hoping that someone would be able to make the change of just adding the 0x26 flags to the beginning of the code page.

Of course this will change will need to be tested on Macs and maybe other machines that I don't have. I have tested on the VAXstation with my fork of bluescsi and it works fine. I suspect a lot of machines will ignore these flags (as does VMS 7.1 or later).

Thanks,

nsafran1217 commented 1 year ago

Adding those parameters to the read-write error recovery mode page did fix my problems booting an image I have of OpenVMS 6.2 on my VAXstation. I've been wanting to see what was on this image for a while.

I didn't add byte 0 (page code) because I forgot about it, only bytes 1 and 2, and it still worked. Here's the changes I made: https://github.com/nsafran1217/piscsi/commit/0c53148615f18851211b1f1a3c9555a870acd734 Sometime this week I'll try this version on a Sun with Solaris and one with SunOS and see what happens.

Also, this question is for someone more knowledgeable about SCSI: Is this lying about PiSCSI's capabilities to the host machine? And if it is, should PiSCSI be lying?

Pacjunk commented 1 year ago

Thanks for testing that. As I say, my C++ skills aren't great so I was wanting one of the gurus to code this in the accepted style. As to what PiSCSI should do, since the aim of it is to support retro systems, I believe that it must cater to some of the peculiarities of those systems. We can't just go and modify the drivers of 30+ year old systems to suit a perfect specification. If the code owners believe differently, then there will be several systems that will never be supported (unless we fork our own versions of course).

The VMS situation is interesting - there are no errors being generated. The drivers (pre 7.1) are just checking for those 3 bits being set, and throw a mount verification if they aren't! For 7.1 or greater those bits are ignored. The developers must have run into later hard drives that didn't set those bits as was required, and had to modify the driver to suit.

Cheers,

uweseimet commented 1 year ago

We can't just go and modify the drivers of 30+ year old systems to suit a perfect specification. >If the code owners believe differently, then there will be several systems that will never be >supported (unless we fork our own versions of course).

Any issues with other systems should be addressed when they pop up. As long as a fix for them does not contradict the SCSI specs it is unlikely to cause (new) issues. What appears to be a peculiarity of a particular system can be something completely normal from a specification perspective.

When you look at the old rascsi code from 2 years ago you will find quite a lot of of work-arounds/special cases which effectively prevented using rascsi with many platforms/configurations instead of improving compatibility. The approach in the original rascsi sources appeared to be: Just add some kind of work-around without reading the specs and without analyzing the problem and finding the core issue. This approach does not resolve problems but causes them.

I will have a closer look at the change suggested in this ticket in the next couple of days.

uweseimet commented 1 year ago

There is a fix_issue_1117 branch now, which is supposed to contain the required changes:

void Disk::AddErrorPage(map<int, vector<byte>>& pages, bool) const
{
    // Retry count is 0, limit time uses internal default value
    vector<byte> buf(12);

    // TB, PER, DTE
    buf[2] = (byte)0x26;

    pages[1] = buf;
}

There is no need to set the page code (0x01) and length (0x0a) in this method because PiSCSI automatically sets these values for all pages. The only effective change compared to before is setting TB, PER and DTE (0x26). I don't expect any compatibility issues with other platforms. Regarding lying about capabitilies: We were already lying before. Now we are just telling a slightly different lie ;-).

@Pacjunk @nsafran1217 Can you please test this branch?

nsafran1217 commented 1 year ago

Working great for me. I can boot OpenVMS 6.2 on a VAXstationn, 7.3 still boots correctly, and my Sun IPX still boots SunOS correctly. Thanks!

Pacjunk commented 1 year ago

@uweseimet Yep, works fine for me too. Booted 5.5-2H4, 7.2 and 7.3. All work correctly.

Thanks for that.

uweseimet commented 1 year ago

@Pacjunk @nsafran1217 Thank you for testing. I am going to create a PR.

jbglaw commented 1 year ago

Thanks for this work!

I just fetched two VAXstations (a 4000/90 and a 4000/96) from storage to do some NetBSD testing. My goal here is a fully automated installation on real hardware, starting with a fresh NetBSD src checkout.

jbglaw commented 1 year ago

The VAXstation (4000/90) is cleaned and wired up. I'm a first-time PiSCSI user, so I may have things wrong, but I tried to simulate a SCSI HDD and a RRD42 CD-ROM drive. Fresh, empty HDD image and a NetBSD installation ISO for the CD drive:

>>> sh dev

  VMS/VMB      ADDR      DEVTYPE    NUMBYTES     RM/FX    WP    DEVNAM      REV
  -------      ----      -------    --------     -----    --    ------      ---
  EZA0         08-00-2B-35-5D-DF
  DKA100       A/1/0     DISK         2.10GB      FX            RZ28M       0568
  DKA500       A/5/0     RODISK     370.80MB      RM      WP    RRD42       4.5d
 ..HostID..    A/6       INITR

However, booting off the CD-ROM doesn't work:

>>> b dka5

%VMB-F-ERR, PC = 00001340
%VMB-I-STS, R0 = 000001A4

While I see some debug output for sh dev:

Jun 26 19:45:39 piscsi PISCSI[1595]: [2023-06-26 19:45:39.181] [debug] (ID 1) - Controller is executing Inquiry, CDB $12000000ff00
Jun 26 19:45:39 piscsi PISCSI[1595]: [2023-06-26 19:45:39.182] [debug] (ID:LUN 1:0) - Device is executing Inquiry ($12)
Jun 26 19:45:39 piscsi PISCSI[1595]: [2023-06-26 19:45:39.233] [debug] (ID 1) - Controller is executing StartStop, CDB $1b0000000100
Jun 26 19:45:39 piscsi PISCSI[1595]: [2023-06-26 19:45:39.233] [debug] (ID:LUN 1:0) - Device is executing StartStop ($1b)
Jun 26 19:45:39 piscsi PISCSI[1595]: [2023-06-26 19:45:39.241] [debug] (ID 1) - Controller is executing ReadCapacity10, CDB $25000000000000000000
Jun 26 19:45:39 piscsi PISCSI[1595]: [2023-06-26 19:45:39.241] [debug] (ID:LUN 1:0) - Device is executing ReadCapacity10 ($25)
Jun 26 19:45:40 piscsi PISCSI[1595]: [2023-06-26 19:45:40.258] [debug] (ID 1) - Controller is executing Inquiry, CDB $12000000ff00
Jun 26 19:45:40 piscsi PISCSI[1595]: [2023-06-26 19:45:40.258] [debug] (ID:LUN 1:0) - Device is executing Inquiry ($12)
Jun 26 19:45:40 piscsi PISCSI[1595]: [2023-06-26 19:45:40.310] [debug] (ID 1) - Controller is executing Inquiry, CDB $12000000ff00
Jun 26 19:45:40 piscsi PISCSI[1595]: [2023-06-26 19:45:40.310] [debug] (ID:LUN 1:0) - Device is executing Inquiry ($12)
Jun 26 19:45:40 piscsi PISCSI[1595]: [2023-06-26 19:45:40.362] [debug] (ID 1) - Controller is executing Inquiry, CDB $12000000ff00
Jun 26 19:45:40 piscsi PISCSI[1595]: [2023-06-26 19:45:40.362] [debug] (ID:LUN 1:0) - Device is executing Inquiry ($12)
Jun 26 19:45:40 piscsi PISCSI[1595]: [2023-06-26 19:45:40.413] [debug] (ID 1) - Controller is executing Inquiry, CDB $12000000ff00
Jun 26 19:45:40 piscsi PISCSI[1595]: [2023-06-26 19:45:40.413] [debug] (ID:LUN 1:0) - Device is executing Inquiry ($12)
Jun 26 19:45:40 piscsi PISCSI[1595]: [2023-06-26 19:45:40.465] [debug] (ID 1) - Controller is executing Inquiry, CDB $12000000ff00
Jun 26 19:45:40 piscsi PISCSI[1595]: [2023-06-26 19:45:40.465] [debug] (ID:LUN 1:0) - Device is executing Inquiry ($12)
Jun 26 19:45:40 piscsi PISCSI[1595]: [2023-06-26 19:45:40.517] [debug] (ID 1) - Controller is executing Inquiry, CDB $12000000ff00
Jun 26 19:45:40 piscsi PISCSI[1595]: [2023-06-26 19:45:40.517] [debug] (ID:LUN 1:0) - Device is executing Inquiry ($12)
Jun 26 19:45:40 piscsi PISCSI[1595]: [2023-06-26 19:45:40.568] [debug] (ID 1) - Controller is executing Inquiry, CDB $12000000ff00
Jun 26 19:45:40 piscsi PISCSI[1595]: [2023-06-26 19:45:40.568] [debug] (ID:LUN 1:0) - Device is executing Inquiry ($12)
Jun 26 19:45:41 piscsi PISCSI[1595]: [2023-06-26 19:45:41.380] [debug] (ID 5) - Controller is executing Inquiry, CDB $12000000ff00
Jun 26 19:45:41 piscsi PISCSI[1595]: [2023-06-26 19:45:41.380] [debug] (ID:LUN 5:0) - Device is executing Inquiry ($12)
Jun 26 19:45:41 piscsi PISCSI[1595]: [2023-06-26 19:45:41.432] [debug] (ID 5) - Controller is executing ReadCapacity10, CDB $25000000000000000000
Jun 26 19:45:41 piscsi PISCSI[1595]: [2023-06-26 19:45:41.432] [debug] (ID:LUN 5:0) - Device is executing ReadCapacity10 ($25)
Jun 26 19:45:42 piscsi PISCSI[1595]: [2023-06-26 19:45:42.449] [debug] (ID 5) - Controller is executing Inquiry, CDB $12000000ff00
Jun 26 19:45:42 piscsi PISCSI[1595]: [2023-06-26 19:45:42.450] [debug] (ID:LUN 5:0) - Device is executing Inquiry ($12)
Jun 26 19:45:42 piscsi PISCSI[1595]: [2023-06-26 19:45:42.501] [debug] (ID 5) - Controller is executing Inquiry, CDB $12000000ff00
Jun 26 19:45:42 piscsi PISCSI[1595]: [2023-06-26 19:45:42.501] [debug] (ID:LUN 5:0) - Device is executing Inquiry ($12)
Jun 26 19:45:42 piscsi PISCSI[1595]: [2023-06-26 19:45:42.553] [debug] (ID 5) - Controller is executing Inquiry, CDB $12000000ff00
Jun 26 19:45:42 piscsi PISCSI[1595]: [2023-06-26 19:45:42.553] [debug] (ID:LUN 5:0) - Device is executing Inquiry ($12)
Jun 26 19:45:42 piscsi PISCSI[1595]: [2023-06-26 19:45:42.604] [debug] (ID 5) - Controller is executing Inquiry, CDB $12000000ff00
Jun 26 19:45:42 piscsi PISCSI[1595]: [2023-06-26 19:45:42.605] [debug] (ID:LUN 5:0) - Device is executing Inquiry ($12)
Jun 26 19:45:42 piscsi PISCSI[1595]: [2023-06-26 19:45:42.656] [debug] (ID 5) - Controller is executing Inquiry, CDB $12000000ff00
Jun 26 19:45:42 piscsi PISCSI[1595]: [2023-06-26 19:45:42.656] [debug] (ID:LUN 5:0) - Device is executing Inquiry ($12)
Jun 26 19:45:42 piscsi PISCSI[1595]: [2023-06-26 19:45:42.708] [debug] (ID 5) - Controller is executing Inquiry, CDB $12000000ff00
Jun 26 19:45:42 piscsi PISCSI[1595]: [2023-06-26 19:45:42.708] [debug] (ID:LUN 5:0) - Device is executing Inquiry ($12)
Jun 26 19:45:42 piscsi PISCSI[1595]: [2023-06-26 19:45:42.759] [debug] (ID 5) - Controller is executing Inquiry, CDB $12000000ff00
Jun 26 19:45:42 piscsi PISCSI[1595]: [2023-06-26 19:45:42.760] [debug] (ID:LUN 5:0) - Device is executing Inquiry ($12)

...no further output is generated for the b dka5 command. Switching over to trace level, no actual transfers are done, just these three messages (repeated several times) are logged:

Jun 26 19:50:19 piscsi PISCSI[2020]: [2023-06-26 19:50:19.094] [trace] static bool SBC_Version::IsBananaPi()
Jun 26 19:50:19 piscsi PISCSI[2020]: [2023-06-26 19:50:19.094] [trace] virtual bool GPIOBUS::PollSelectEvent()
Jun 26 19:50:19 piscsi PISCSI[2020]: [2023-06-26 19:50:19.094] [trace] static bool SBC_Version::IsBananaPi()
uweseimet commented 1 year ago

@akuker As far as I can tell this is yet another ticket where a potential issue with the BananaPi code is logged:

Jun 26 19:50:19 piscsi PISCSI[2020]: [2023-06-26 19:50:19.094] [trace] static bool SBC_Version::IsBananaPi()
Jun 26 19:50:19 piscsi PISCSI[2020]: [2023-06-26 19:50:19.094] [trace] virtual bool GPIOBUS::PollSelectEvent()
Jun 26 19:50:19 piscsi PISCSI[2020]: [2023-06-26 19:50:19.094] [trace] static bool SBC_Version::IsBananaPi()

The others are https://github.com/PiSCSI/piscsi/issues/1133 and https://github.com/PiSCSI/piscsi/issues/1125.

jbglaw commented 1 year ago

It works. Notice that the CD-ROM ist listed as DKA500, while I did a boot dka5. Usually, that works, but this specifc VAX firmware version required b dka500. I don't know if the test for the BananaPi is of any relevance here. I'm running the April 2023 release (aarch64) and it seems to just work (with a correct boot command on the VAXstation.)