Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

OpenVMS/VAX Compatibility #1117

Closed
Pacjunk opened this issue Mar 4, 2023 · 11 comments · Fixed by #1123
Closed

OpenVMS/VAX Compatibility #1117

Pacjunk opened this issue Mar 4, 2023 · 11 comments · Fixed by #1123
Assignees
@akuker
Labels
compatibility Compatibility with particular computing platforms

Comments

@Pacjunk
Copy link
Contributor

Pacjunk commented Mar 4, 2023

Info

  • Which version of Pi are you using: ZeroW
  • Which github revision of software: Latest/Develop
  • Which board version: Fullspec
  • Which computer is the PiSCSI connected to: VAXstation 3100

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
Copy link
Contributor

nsafran1217 commented Mar 9, 2023 •
edited
Loading

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: nsafran1217@0c53148
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
Copy link
Contributor Author

Pacjunk commented Mar 9, 2023

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
Copy link
Contributor

uweseimet commented Mar 9, 2023 •
edited
Loading

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 uweseimet self-assigned this Mar 9, 2023
@uweseimet
Copy link
Contributor

uweseimet commented Mar 11, 2023 •
edited
Loading

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?

@uweseimet uweseimet added the compatibility Compatibility with particular computing platforms label Mar 11, 2023
@nsafran1217
Copy link
Contributor

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
Copy link
Contributor Author

Pacjunk commented Mar 12, 2023

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

Thanks for that.

@uweseimet
Copy link
Contributor

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

@uweseimet uweseimet linked a pull request Mar 12, 2023 that will close this issue
Improve OpenVMS/VAX compatibility (issue #1117) #1123
Merged
uweseimet added a commit that referenced this issue Mar 15, 2023
@uweseimet
Improve OpenVMS/VAX compatibility (issue #1117) (#1123)
ef6cd97 
* Set TB, PER and DTE bits in read/write error recovery page

* Fixed typo

* Added unit test

* Comment update
@jbglaw
Copy link

jbglaw commented Jun 24, 2023

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
Copy link

jbglaw commented Jun 26, 2023

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
Copy link
Contributor

uweseimet commented Jun 27, 2023 •
edited
Loading

@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 #1133 and #1125.

@uweseimet uweseimet assigned akuker and unassigned uweseimet Jun 27, 2023
@jbglaw
Copy link

jbglaw commented Jun 27, 2023

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.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@akuker akuker

Labels
compatibility Compatibility with particular computing platforms
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Improve OpenVMS/VAX compatibility (issue #1117) PiSCSI/piscsi
5 participants
@jbglaw @akuker @uweseimet @nsafran1217 @Pacjunk