Discussion:
axpbox crashed when logged out.
Add Reply
Timothy Stark
2020-11-18 03:34:02 UTC
Reply
Permalink
Folks,



I discovered a bug in axpbox when I attempted to log out. Axpbox crashed
with messages:



Exception in SYM thread: Not implemented: pci0.1(sym53c810).disk0.4(file):
Unknown SCSI command 0x1b.

: /home/sword7/axpbox/src/src/Disk.cpp, line 1495.

Emulator Failure: Threading error: SYM thread has died:
/home/sword7/axpbox/src/src/Sym53C810.cpp, line 1501

Stop threads: cpu0 srl0 sym ali kbd

Freeing memory in use by system...

pci0.1(sym53c810).disk0.0(file): Closing file.



I checked SCSI reference for command 0x1B and it performs loading/unloading
or starting/stopping unit. I believe that logout routines attempted to
unload CD om DKA400 (53C810).

I was able reproduce errors at some chance when I attempted to log off.



Does anyone have any experience with that?



Tim
Stephen Hoffman
2020-11-18 15:05:29 UTC
Reply
Permalink
Post by Timothy Stark
I discovered a bug in axpbox when I attempted to log out. Axpbox
Unknown SCSI command 0x1b.
: /home/sword7/axpbox/src/src/Disk.cpp, line 1495.
/home/sword7/axpbox/src/src/Sym53C810.cpp, line 1501
Stop threads: cpu0 srl0 sym ali kbd
Freeing memory in use by system...
pci0.1(sym53c810).disk0.0(file): Closing file.
I checked SCSI reference for command 0x1B and it performs
loading/unloading or starting/stopping unit. I believe that logout
routines attempted to unload CD om DKA400 (53C810).
I was able reproduce errors at some chance when I attempted to log off.
Does anyone have any experience with that?
Any experience with emulated hardware issues, and with actual hardware
having issues? Sure. This case is basically buggy hardware.

Experience with SCSI issues? Absolutely. Lots.

With this particular emulator and this issue? No.

Check with the emulator maintainer. axpbox hasn't been getting all
that much traffic around here as yet, and I don't know that the
maintainer follows this usenet newsgroup or receives feedback from
postings here.

Or have a look at the emulator itself. At the emulator source code.
Solely from what you've posted and not having reviewed the source code,
this looks like a fairly reasonable setup within the emulator code.

SCSI 0x1b is start-stop and load-unload. Prolly a stop request, here.
An unload is possible and certainly easy to test, but OpenVMS doesn't
unload devices at shutdown, nor at logout. Start-stop and load-unload
are not really particularly relevant commands for an emulator, so it
can likely be ignored save for updating some internal device state
settings within the emulator. Pull down the emulator source code and
have a look at the Disk.cpp and Sym53C810.cpp source code, and at
whatever code parses the SCSI command packets and generates the SCSI
command responses.

Based on what the OpenVMS shutdown does and on what logout does and
what the emulator is reporting, I'd suspect this is a disk spindown
request.

SCSI is a command-response protocol, so OpenVMS drivers and some
user-written apps send SCSI commands at the SCSI controller or the SCSI
device, and the device then parses and processes the command request
and generates what the device considers an appropriate response. Part
of the "fun" of SCSI is the flexibility and variability of the
possible responses and of the timing of same. SCSI's gotten easier to
deal with in the last decade or two, but it's still possible to bump
into incompatibilities and unimplemented commands and unexpected
responses. SCSI weirdness was far more common in past years, and
OpenVMS SCSI processing itself has gotten better. V6.2 and V7.1 saw
substantial improvements, there.

In this case, the emulator doesn't recognize the SCSI command, and
crashes. SCSI hardware and particularly SCSI firmware does that
sometimes, too—crashes, lock-ups, hangs.

FWIW, USB is basically SCSI with random bus disconnects, and ATAPI is
basically SCSI operating atop IDE.

I'd probably add command packet dump to that crash code; a way to dump
the full SCSI command packet to the user. Longer-term, I'd usually just
write the above crash info and the command buffer to a logfile
somewhere or to a crash report that can be available to the maintainer,
and generate some benign description to the user; an I/O feature not
implemented by this version of the emulator, in this case. With where
to look for more data and/or how to report this error and/or seeking
permission to upload the related telemetry.
--
Pure Personal Opinion | HoffmanLabs LLC
Remy
2020-11-19 07:12:35 UTC
Reply
Permalink
Post by Stephen Hoffman
I discovered a bug in axpbox when I attempted to log out. Axpbox
Unknown SCSI command 0x1b.
: /home/sword7/axpbox/src/src/Disk.cpp, line 1495.
/home/sword7/axpbox/src/src/Sym53C810.cpp, line 1501
Stop threads: cpu0 srl0 sym ali kbd
Freeing memory in use by system...
pci0.1(sym53c810).disk0.0(file): Closing file.
I checked SCSI reference for command 0x1B and it performs
loading/unloading or starting/stopping unit. I believe that logout
routines attempted to unload CD om DKA400 (53C810).
I was able reproduce errors at some chance when I attempted to log off.
Does anyone have any experience with that?
Any experience with emulated hardware issues, and with actual hardware
having issues? Sure. This case is basically buggy hardware.
Experience with SCSI issues? Absolutely. Lots.
With this particular emulator and this issue? No.
Check with the emulator maintainer. axpbox hasn't been getting all
that much traffic around here as yet, and I don't know that the
maintainer follows this usenet newsgroup or receives feedback from
postings here.
Or have a look at the emulator itself. At the emulator source code.
Solely from what you've posted and not having reviewed the source code,
this looks like a fairly reasonable setup within the emulator code.
SCSI 0x1b is start-stop and load-unload. Prolly a stop request, here.
An unload is possible and certainly easy to test, but OpenVMS doesn't
unload devices at shutdown, nor at logout. Start-stop and load-unload
are not really particularly relevant commands for an emulator, so it
can likely be ignored save for updating some internal device state
settings within the emulator. Pull down the emulator source code and
have a look at the Disk.cpp and Sym53C810.cpp source code, and at
whatever code parses the SCSI command packets and generates the SCSI
command responses.
Based on what the OpenVMS shutdown does and on what logout does and
what the emulator is reporting, I'd suspect this is a disk spindown
request.
SCSI is a command-response protocol, so OpenVMS drivers and some
user-written apps send SCSI commands at the SCSI controller or the SCSI
device, and the device then parses and processes the command request
and generates what the device considers an appropriate response. Part
of the "fun" of SCSI is the flexibility and variability of the
possible responses and of the timing of same. SCSI's gotten easier to
deal with in the last decade or two, but it's still possible to bump
into incompatibilities and unimplemented commands and unexpected
responses. SCSI weirdness was far more common in past years, and
OpenVMS SCSI processing itself has gotten better. V6.2 and V7.1 saw
substantial improvements, there.
In this case, the emulator doesn't recognize the SCSI command, and
crashes. SCSI hardware and particularly SCSI firmware does that
sometimes, too—crashes, lock-ups, hangs.
FWIW, USB is basically SCSI with random bus disconnects, and ATAPI is
basically SCSI operating atop IDE.
I'd probably add command packet dump to that crash code; a way to dump
the full SCSI command packet to the user. Longer-term, I'd usually just
write the above crash info and the command buffer to a logfile
somewhere or to a crash report that can be available to the maintainer,
and generate some benign description to the user; an I/O feature not
implemented by this version of the emulator, in this case. With where
to look for more data and/or how to report this error and/or seeking
permission to upload the related telemetry.
--
Pure Personal Opinion | HoffmanLabs LLC
Thank you Stephen for your information. I've added it to the github issue Tim created: https://github.com/lenticularis39/axpbox/issues/36, should help in resolving it.

I think Tomáš is aware of this google group / mailing list but I'm not sure he follows it via email (just the website).
John E. Malmberg
2020-11-20 14:07:19 UTC
Reply
Permalink
Ideally any emulator would have a libvirt driver that can use it.

The libvirt API provides an interface for third-party management tools
to control the system.

It also provides its own GUI and command line tools for managing the
configuration of the emulated system.

The fastest route to this is to get the libvirt-lxc driver fixed to
support privileged containers again. (Or risk running Ubuntu 14.04, etc.)

Even if the KVM driver is used, it would be a big plus if the emulator
could use the libvirt APIs to read its configuration files.

This change makes the emulator immediately more useful in a cloud or
volume hosting environment.

I also noticed that the libvirt qemu emulator supports an Alpha
processor target. Has anyone tried to get OpenVMS running on such an
environment?

Regards,
-John
Tomáš Glozar
2020-11-20 17:03:26 UTC
Reply
Permalink
Post by John E. Malmberg
Ideally any emulator would have a libvirt driver that can use it.
The libvirt API provides an interface for third-party management tools
to control the system.
It also provides its own GUI and command line tools for managing the
configuration of the emulated system.
The fastest route to this is to get the libvirt-lxc driver fixed to
support privileged containers again. (Or risk running Ubuntu 14.04, etc.)
The only reason I can think of why the container has to be privileged is networking, and that could be solved using user mode networking like in QEMU.
Post by John E. Malmberg
Even if the KVM driver is used, it would be a big plus if the emulator
could use the libvirt APIs to read its configuration files.
This change makes the emulator immediately more useful in a cloud or
volume hosting environment.
That's a good point - I had the idea of creating a VirtualBox VM containing AXPbox inside, but integrating with libvirt sounds better considering the prevalent use of OpenVMS in server environments.
Post by John E. Malmberg
I also noticed that the libvirt qemu emulator supports an Alpha
processor target. Has anyone tried to get OpenVMS running on such an
environment?
QEMU's Alpha target doesn't have a BIOS capable of booting, only a Linux-compatibile PALcode with something that I suppose is a dummy console (see https://www.ewan.cc/?q=node/127) - it's supposed to be booting directly into a Linux kernel. I attempted to run the ES40 SRM in QEMU some time ago (probably not a very good idea, since the hardware is likely different), doing some hacking of the source code, with no success, so I forked es40 instead for the first time (the result being a mess resulting in me dropping the fork and starting over again, from which came AXPbox). Nevertheless investigating what could be done to change this would certainly be interesting.
John E. Malmberg
2020-11-20 21:33:34 UTC
Reply
Permalink
Post by Tomáš Glozar
Post by John E. Malmberg
Ideally any emulator would have a libvirt driver that can use it.
The libvirt API provides an interface for third-party management tools
to control the system.
It also provides its own GUI and command line tools for managing the
configuration of the emulated system.
The fastest route to this is to get the libvirt-lxc driver fixed to
support privileged containers again. (Or risk running Ubuntu 14.04, etc.)
The only reason I can think of why the container has to be
privileged is networking, and that could be solved using user mode
networking like in QEMU.
An emulator running OpenVMS needs to to be able to modify the MAC
address of the adapter.

I am not familiar with the user mode networking in QEMU to know if there
is a way to make it work with libvirt-lxc.

Regards,
-John
***@qsl.net_work
Jan-Erik Söderholm
2020-11-20 22:02:25 UTC
Reply
Permalink
Post by Tomáš Glozar
Post by John E. Malmberg
Ideally any emulator would have a libvirt driver that can use it.
The libvirt API provides an interface for third-party management tools
to control the system.
It also provides its own GUI and command line tools for managing the
configuration of the emulated system.
The fastest route to this is to get the libvirt-lxc driver fixed to
support privileged containers again. (Or risk running Ubuntu 14.04, etc.)
The only reason I can think of why the container has to be
privileged is networking, and that could be solved using user mode
networking like in QEMU.
An emulator running OpenVMS needs to to be able to modify the MAC address
of the adapter.
Even if you do not use DECnet?
I am not familiar with the user mode networking in QEMU to know if there is
a way to make it work with libvirt-lxc.
Regards,
-John
John E. Malmberg
2020-11-21 04:04:16 UTC
Reply
Permalink
Post by Jan-Erik Söderholm
Post by John E. Malmberg
Post by Tomáš Glozar
Post by John E. Malmberg
Ideally any emulator would have a libvirt driver that can use it.
The libvirt API provides an interface for third-party management tools
to control the system.
It also provides its own GUI and command line tools for managing the
configuration of the emulated system.
The fastest route to this is to get the libvirt-lxc driver fixed to
support privileged containers again. (Or risk running Ubuntu 14.04, etc.)
The only reason I can think of why the container has to be
privileged is networking, and that could be solved using user mode
networking like in QEMU.
An emulator running OpenVMS needs to to be able to modify the MAC
address of the adapter.
Even if you do not use DECnet?
Yes.

LAVC appears to use that feature.

I think the networking adapter has to be able to be accessed in
promiscuous mode in order to pick pick up the cluster traffic.

As I remember, SimH/VAX - Infoserver refused to start in the current
libvirt-lxc container.

It runs ok in a privileged lxd container.

Regards,
-John
Stephen Hoffman
2020-11-21 18:48:46 UTC
Reply
Permalink
Post by Jan-Erik Söderholm
Post by John E. Malmberg
An emulator running OpenVMS needs to to be able to modify the MAC
address of the adapter.
Even if you do not use DECnet?
DECnet Phase IV and Phase V operating in IV compatibility expect to
change the MAC, and select DECnet-compatible products (LAT, IIRC) can
offer to shift the MAC, but yes, it's quite possible to avoid that MAC
change with OpenVMS.

And DECnet V without configuring IV compatibility doesn't change the MAC.

The emulator will best want to respond with an appropriate error
message secondary to a denied attempt to change the MAC, should the
emulator not implement that. Folks will try to start DECnet, after all.
--
Pure Personal Opinion | HoffmanLabs LLC
Loading...