axpbox
axpbox copied to clipboard
lenticularis39
SCSI command 0x1B not implemented (53c810).
When I logged out of system, axpbox immediately crashed with unknown SCSI command 0x1B. I was able reproduce errors at some chance when I attempted to log off.
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.
Update:
I checked SCSI command reference and learned that system attempted to unload CD during logout command with SCSI command 1B (load/unload or start/stop unit).
Thanks, Tim
Cross-posting Hoffman's information from the google group for reference:
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
I tested some more and confirmed that unimplemented SCSI 0x1B crash during dismount and logout commands sent packet to RDD42 CDROM drive to eject CD image. Also I recommend to implement SCSI 0x1B command on AXPbox emulator so that it will not crash and adding prompt handler (separating from CPU thread) to handle attach/detach commands like in SIMH emulator without shutting system down each time.
With working around solution, I suggest to use mount/system so that it will not crash until SCSI 0x1B command is implemented.
Username: system Password: Welcome to OpenVMS (TM) Alpha Operating System, Version V8.4-2L1 Last interactive login on Tuesday, 17-NOV-2020 23:03:28.09 $ $ $ mount/over=id dka400: %MOUNT-I-WRITELOCK, volume is write locked %MOUNT-I-MOUNTED, AVMS842L2LP1 mounted on _TSAXP1$DKA400: $ dismount dka400: Connection closed by foreign host. sword7@tsux1vm:~/axpbox/data$
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. sword7@tsux1vm:~/axpbox/data$
Username: system Password: Welcome to OpenVMS (TM) Alpha Operating System, Version V8.4-2L1 Last interactive login on Friday, 20-NOV-2020 02:26:41.28 $ $ $ $ mount/over=id dka400: %MOUNT-I-WRITELOCK, volume is write locked %MOUNT-I-MOUNTED, AVMS842L2LP1 mounted on _TSAXP1$DKA400: $ dismount dka400:/nounload $ mount/system/over=id dka400: %MOUNT-F-CONFQUAL, conflicting qualifiers $ mount/system dka400: _Label: avms842l2lp1 _Log name: %MOUNT-I-WRITELOCK, volume is write locked %MOUNT-I-MOUNTED, AVMS842L2LP1 mounted on _TSAXP1$DKA400: $ logout SYSTEM logged out at 20-NOV-2020 02:33:40.87
Welcome to OpenVMS (TM) Alpha Operating System, Version V8.4-2L1
Username: system Password: Welcome to OpenVMS (TM) Alpha Operating System, Version V8.4-2L1 Last interactive login on Friday, 20-NOV-2020 02:32:11.59 $ sh dev dka400:
Device Device Error Volume Free Trans Mnt Name Status Count Label Blocks Count Cnt TSAXP1$DKA400: Mounted wrtlck 2 AVMS842L2LP1 272 1 1 $ sh dev dka400:/full
Disk TSAXP1$DKA400:, device type RRD42, is online, mounted, software write- locked, file-oriented device, shareable, available to cluster, error logging is enabled.
Error count 2 Operations completed 31
Owner process "" Owner UIC [SYSTEM]
Owner process ID 00000000 Dev Prot S:RWPL,O:RWPL,G:R,W
Reference count 1 Default buffer size 512
Total blocks 973000 Sectors per track 4
Total cylinders 40542 Tracks per cylinder 6
Logical Volume Size 973000 Expansion Size Limit 2031616
Volume label "AVMS842L2LP1" Relative volume number 0
Cluster size 16 Transaction count 1
Free blocks 272 Maximum files allowed 35294
Extend quantity 5 Mount count 1
Mount status System Cache name "_TSAXP1$DKA0:XQPCACHE"
Extent cache size 64 Max blocks in extent cache 27
File ID cache size 64 Blocks in extent cache 0
Quota cache size 0 Maximum buffers in FCP cache 1034
Volume owner UIC [1,1] Vol Prot S:RWCD,O:RWCD,G:RWCD,W:RWCD
Volume Status: ODS-2, subject to mount verification, allocation inhibited because of error on bitmap, file high-water marking, write-through XFC caching enabled, write-back XQP caching enabled.
$ sh cpu
System: TSAXP1, AlphaServer ES40
CPU ownership sets: Active 0 Configure 0
CPU state sets: Potential 0 Autostart 0-3 Powered Down None Not Present 1-3 Hard Excluded None Failover None $
Also I recommend [....] and adding prompt handler (separating from CPU thread) to handle attach/detach commands like in SIMH emulator without shutting system down each time.
This could be an enhancement to issue #12
The proper solution to this comprises of two different tasks:
- Implement a management console (like the QEMU monitor) where one can attach images to removable drives (among other things).
- Actually implement the SCSI command.
I'm working on this right now (in order). As a workaround adding 0x1b to ignored commands in Sym53C810.cpp would probably work.
