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