Discussion:
Greater than approx 16GB disk leads to UNXSIGNAL crash
(too old to reply)
arca...@gmail.com
2021-05-25 23:37:55 UTC
Permalink
I wanted a 100GB disk (using SIMH) under OpenVMS VAX V7.2.

That seems to be fine until I try to create a file. Admittedly I've only tried to create a file either using FTP or BACKUP, but as they're so disconnected, I assume that it's actually XQP (or something in the file system) that gets upset.

I backed off my disk size and even 20GB triggers the crash. 16GB seems to be OK.

Now OpenVMS beyond V5.5-2 supports single volumes of 1TB, so I'm surprised that a 16GB volume causes a crash.

Does anyone have a real VAX with a real disk (> 16GB) successfully hanging off it? I do have some SCA-80 36GB disks but I've never successfully got them working on either a VS4000-96 or a VS4000-60, so I'm not in a position to try this out myself.

The crash is below for those who enjoy that sort of thing!

Antonio

**** Fatal BUG CHECK, version = V7.2 UNXSIGNAL, Unexpected signal name in ACP

Crash CPU: 00 Primary CPU: 00

Active/available CPU masks: 00000001/00000001

Current process = UCX$FTPC_1

Register dump

R0 = 7FF6E0D8
R1 = 7FF6EAFC
R2 = 7FF6E4C0
R3 = 7FF6E4AC
R4 = 7FF6E4D0
R5 = 7FF6E4A8
R6 = 7FF6E588
R7 = 00000000
R8 = 00000001
R9 = 7FF6E4C0
R10= 7FF6E564
R11= 00000357
AP = 7FF6E088
FP = 7FF6E060
SP = 7FF6E050
PC = 833CAABC
PSL= 00000000

Kernel/interrupt/boot stack

7FF6E058 7FF6E684
7FF6E05C 7FF6E630
7FF6E060 00000000
7FF6E064 243C0000
7FF6E068 7FF6E0B4
7FF6E06C 7FF6E09C
7FF6E070 833CAA59
7FF6E074 83ABE9BC
7FF6E078 83ABE880
7FF6E07C 00000000
7FF6E080 000000C0
7FF6E084 7FF6E564
7FF6E088 00000003
7FF6E08C 7FF6E0D8
7FF6E090 7FF6E0C0
7FF6E094 7FF6E098
7FF6E098 00000000
Stephen Hoffman
2021-05-26 02:55:50 UTC
Permalink
Post by ***@gmail.com
I wanted a 100GB disk (using SIMH) under OpenVMS VAX V7.2.
That seems to be fine until I try to create a file. Admittedly I've
only tried to create a file either using FTP or BACKUP, but as they're
so disconnected, I assume that it's actually XQP (or something in the
file system) that gets upset.
I backed off my disk size and even 20GB triggers the crash. 16GB seems to be OK.
Now OpenVMS beyond V5.5-2 supports single volumes of 1TB, so I'm
surprised that a 16GB volume causes a crash.
Does anyone have a real VAX with a real disk (> 16GB) successfully
hanging off it? I do have some SCA-80 36GB disks but I've never
successfully got them working on either a VS4000-96 or a VS4000-60, so
I'm not in a position to try this out myself.
You're retro-computing. For this case, you're trying more recent sizes
and limits than were typical ~three architectures back.

Theoretical limit for ODS-2 is 2 TB and was effectively 1 TB prior to
V8.4 due to some signed usage and that's all still ~busted in DCL to
this day.

Driver-permitted and console-permitted addressing was less, depending
on the hardware.

Old SCSI-2 was slightly past 8 GB up until V6.2 IIRC when IBM decided
to use an adjacent field to allow larger capacity addressing and that
then got standardized into SCSI-2, and PATA was limited to 24-bit on
OpenVMS, and VAXstation 3100 consoles do stupid things with storage on
boot devices larger than 1.073 GB.

Limits? 100 GB was ~ginormous in the era of OpenVMS VAX V7.2. SCSI was
flaky back then too, and you're on an emulated server just to add a
little more hardware complexity.

Somewhere back in this same V7.x range of versions, patches became
available only to support customers, too. Wouldn't surprise me that
you're missing a TCP/IP Services patch or three, as well as mandatory
OpenVMS VAX patches.

I'd suggest smaller devices and contemporary capacities, or the use of
rather newer OpenVMS versions if you want to work with OpenVMS and not
chase older hardware limits and older bugs, depending on your
retro-computing goals.
--
Pure Personal Opinion | HoffmanLabs LLC
arca...@gmail.com
2021-05-26 08:40:50 UTC
Permalink
You're retro-computing. For this case, you're trying more recent sizes and limits than were typical ~three architectures back.
The system from which I'm recovering data would have had RZ29 disks (4GB) back then, so I do realise that I'm going slightly beyond the original hardware :-) But the documented limits were much higher and I would have though that they would have been tested. Naturally there were precisely zero 100GB+ drives in the days of V6 but a hacked version of LDDRIVER that did sparse allocation and claimed to be a 32GB disk would have found this pretty quickly. Assuming it's an OpenVMS issue and not a SIMH issue.
Somewhere back in this same V7.x range of versions, patches became available only to support customers, too. Wouldn't surprise me that you're missing a TCP/IP Services patch or three, as well as mandatory OpenVMS VAX patches.
FTP was where I hit this first. So then I FTP'd the first saveset to a smaller disk (and also having misread UNXSIGNAL as UCXSIGNAL in my head :-)) I then decided to expand the first saveset onto the 100GB drive ... it blew up in exactly the same way. So I can't blame UCX :-(
I'd suggest smaller devices and contemporary capacities, or the use of rather newer OpenVMS versions if you want to work with OpenVMS and not chase older hardware limits and older bugs, depending on your retro-computing goals.
Turns out that the savesets are all /IMAGE backups so, unless I want to see more "invalid related NAM block", I'm better off with a series of 2GB-4GB volumes anyway, at least for the targets when I expand the savesets.


Thanks


Antonio
--
Antonio Carlini
Stephen Hoffman
2021-05-26 15:33:51 UTC
Permalink
Post by ***@gmail.com
Post by Stephen Hoffman
You're retro-computing. For this case, you're trying more recent sizes
and limits than were typical ~three architectures back.
The system from which I'm recovering data would have had RZ29 disks
(4GB) back then, so I do realise that I'm going slightly beyond the
original hardware :-) But the documented limits were much higher and I
would have though that they would have been tested. Naturally there
were precisely zero 100GB+ drives in the days of V6 but a hacked
version of LDDRIVER that did sparse allocation and claimed to be a 32GB
disk would have found this pretty quickly. Assuming it's an OpenVMS
issue and not a SIMH issue.
If this is a production project, stop looking for other issues, ~mirror
the existing hardware environment for the existing code, and get the
source code ported to Linux, BSD, Windows, or OpenVMS V8.4+; with
wherever you're going with this app or this data.

As for your testing assumptions, ~nobody back then was looking for
these sorts of issues, as you're off in what was then unavailable or
unsupported territories, and—more problematically—you're also working
with a veritable dearth of patches installed.

There have been a number of retro-computing folks posting around here
that wanted "the experience", of course. Many have subsequently gotten
clobbered by their more modern assumptions, and/or by the lack of
patches, and/or by emulator or flaky hardware bugs.

This isn't new. OpenVMS has serious gaps now—not the least of which is
the now-less-than-theoretical though rather-better-tested 2 TiB
addressing limit, and a file system itself designed for hard disk
drives—and which will be even more striking given the benefit of ten or
twenty years' hindsight, and hardware and software advances. I'm
loading now-small 10 TB HDD spindles into NAS arrays. One of these
HDDs is as much or more than many VAX configurations had in aggregate.
A shelf of these now-small HDDs is more array storage than many
production AlphaServer configurations featured. With your data-access
project, you're back nearly a quarter century. That's a long time in
the IT business.

If this is a hobbyist data-recovery project, have at. I'd still
recommend Alpha or Alpha emulation here (reports here that AXPbox works
reasonably well, IDE bugs aside), as Alpha has the advantage of a
couple of decades of updates that your OpenVMS VAX configuration lacks.

And here, I'd wonder if this is a TCP/IP Services bug. TCP/IP Services
prior to V5 (UCX$) wasn't entirely stable, and V5 (TCPIP$) and later
has had and has its issues. DEC sought OSI, and OpenVMS IP support
never recovered.
--
Pure Personal Opinion | HoffmanLabs LLC
arca...@gmail.com
2021-05-26 18:38:06 UTC
Permalink
Post by Stephen Hoffman
If this is a production project,
If this is production, then I'm doing something illegal ... or maybe OpenVMS licensing has moved on. I'm not aware of any way to legally run OpenVMS on SIMH. I guess HP *could* issue a commercial licence for SIMH, but I'd be pretty surprised if they ever had!
Post by Stephen Hoffman
As for your testing assumptions, ~nobody back then was looking for
these sorts of issues,
I'm just surprised that the size was supported without any testing at all. 4GB was common back then and 8GB existed. Just one further doubling would have come close to hitting this issue (assuming it is real and not just something sent to try me).
Post by Stephen Hoffman
production AlphaServer configurations featured. With your data-access
project, you're back nearly a quarter century. That's a long time in
the IT business.
I know.
Post by Stephen Hoffman
If this is a hobbyist data-recovery project, have at.
It is, and rest assured I will :-)
Post by Stephen Hoffman
recommend Alpha or Alpha emulation here (reports here that AXPbox works
reasonably well, IDE bugs aside), as Alpha has the advantage of a
couple of decades of updates that your OpenVMS VAX configuration lacks.
I will have to give AXPbox a spin some time. However, my set of Alpha OS releases is even more limited (only V6.2 ... donations gratefully accepted :-)) so I'd actually be going backwards in time.
Post by Stephen Hoffman
And here, I'd wonder if this is a TCP/IP Services bug. TCP/IP Services
prior to V5 (UCX$) wasn't entirely stable,
Sadly the crashes have dropped off my my terminal's scrollback buffer so I can't currently offer any evidence. My first assumption was to blame UCX's FTP too. But then I did the equivalent of:

$ BACKUP DUA2:[000000]FOO.BCK/SAV DUA1:[FOO...] ! DUA1 is ~100GB at this point

and instantly hit exactly the same crash.

I rather suspect that:
$ copy tt: dua1:[000000]test.txt
hi
^Z

will do exactly the same ...
Post by Stephen Hoffman
and V5 (TCPIP$) and later
has had and has its issues. DEC sought OSI, and OpenVMS IP support
never recovered.
True. But DECnet VAX Extensions/DECnet OSI/DECnet Plus (or at least the PSI/WANDD bits thereof) kept me in REO for a while and that would probably never have happened if IP had ruled the roost in DEC. So I'm not complaining :-)

Antonio
Simon Clubley
2021-05-26 18:58:12 UTC
Permalink
Post by ***@gmail.com
Post by Stephen Hoffman
If this is a production project,
If this is production, then I'm doing something illegal ... or maybe OpenVMS licensing has moved on. I'm not aware of any way to legally run OpenVMS on SIMH. I guess HP *could* issue a commercial licence for SIMH, but I'd be pretty surprised if they ever had!
You can legally transfer a normal commercial licence from a physical
system to one of the commercial emulators for a fee. I don't know if
SimH is covered by that however.

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
Stephen Hoffman
2021-05-26 20:59:50 UTC
Permalink
Post by ***@gmail.com
Post by Stephen Hoffman
If this is a production project,
If this is production, then I'm doing something illegal ... or maybe
OpenVMS licensing has moved on. I'm not aware of any way to legally run
OpenVMS on SIMH. I guess HP *could* issue a commercial licence for
SIMH, but I'd be pretty surprised if they ever had!
OpenVMS licensing moved on most of twenty years ago, and emulators can
be licensed for production, and have been. I'm aware of both VAX and
Alpha emulators in production, fully licensed.

For an early announcement of this:
https://groups.google.com/g/comp.os.vms/c/hjBdPuum290/m/mTre9M-FO1oJ
Post by ***@gmail.com
Post by Stephen Hoffman
As for your testing assumptions, ~nobody back then was looking for
these sorts of issues,
I'm just surprised that the size was supported without any testing at
all. 4GB was common back then and 8GB existed. Just one further
doubling would have come close to hitting this issue (assuming it is
real and not just something sent to try me).
I'm just surprised you think the 100 GB size was supported back then.
It's certainly within the theoretical range for the ODS-2 design, but
the HDD device support back then was a whole lot less than 100 GB.

IDE/ATAPI/PATA device support hasn't gotten anywhere near 1 TiB or 2
TiB, either. DQDRIVER—other than a test driver I'd reworked and
prototyped—was still using 24-bit addressing when last I checked.
--
Pure Personal Opinion | HoffmanLabs LLC
arca...@gmail.com
2021-05-27 10:35:45 UTC
Permalink
Post by Stephen Hoffman
I'm just surprised you think the 100 GB size was supported back then.
It's certainly within the theoretical range for the ODS-2 design, but
the HDD device support back then was a whole lot less than 100 GB.
IDE/ATAPI/PATA device support hasn't gotten anywhere near 1 TiB or 2
TiB, either. DQDRIVER—other than a test driver I'd reworked and
prototyped—was still using 24-bit addressing when last I checked.
--
The nearest I can find to a statement is the FAQ: https://www.digiater.nl/openvms/freeware/v70/vmsfaq/vmsfaq_012.html.

I can't find a V6.0 SPD/New features/Release Notes anywhere (either on the web or here). The last time I looked they were still up at HP but right now I can't find them. I'm sure they're somwhere in archive.org but without even a dead link to follow, I'm not able to get any further. Oh well.

Antonio
Stephen Hoffman
2021-05-27 16:31:05 UTC
Permalink
Post by ***@gmail.com
Post by Stephen Hoffman
I'm just surprised you think the 100 GB size was supported back then.
It's certainly within the theoretical range for the ODS-2 design, but
the HDD device support back then was a whole lot less than 100 GB.
IDE/ATAPI/PATA device support hasn't gotten anywhere near 1 TiB or 2
TiB, either. DQDRIVER—other than a test driver I'd reworked and
prototyped—was still using 24-bit addressing when last I checked.
https://www.digiater.nl/openvms/freeware/v70/vmsfaq/vmsfaq_012.html.
That FAQ entry was a result of trying to stave off the questions, and
the problems when folks hit one of the limits.

Also check "the fine print" section at the top of the OpenVMS FAQ.

Most device drivers can now support 2 TiB, as quaint as that limit has
become. AFAIK, IDE/ATAPI/PATA/DQ and the (undocumented) FAT file system
implementation for the console are among the remaining exceptions to
storage addressing, if not the only.
Post by ***@gmail.com
I can't find a V6.0 SPD/New features/Release Notes anywhere (either on
the web or here). The last time I looked they were still up at HP but
right now I can't find them. I'm sure they're somwhere in archive.org
but without even a dead link to follow, I'm not able to get any
further. Oh well.
Had a number of discussions with the product managers about the
contents of the SPDs. The PMs (and eventually, in the hardware support
database—trying to keep this list on paper is ~doomed) listed supported
devices. The various PMs weren't big on listing theoretical limits.
Limits that they didn't (at the time) have a good way of testing. I'm
also the "guilty party" that caused a number of VAX boxes to marked as
officially unsupported, with most of those retirements due to
required-memory increases, or due to bootable media deprecations.

I know this is c.o.v. and we're not supposed to discuss search engines,
but a DDG or Chocolate Factory search for the following might get you
closer to your quest: openvms vax software product description
site:archive.org
--
Pure Personal Opinion | HoffmanLabs LLC
Tad Winters
2021-05-26 03:48:15 UTC
Permalink
Post by ***@gmail.com
I wanted a 100GB disk (using SIMH) under OpenVMS VAX V7.2.
That seems to be fine until I try to create a file. Admittedly I've only tried to create a file either using FTP or BACKUP, but as they're so disconnected, I assume that it's actually XQP (or something in the file system) that gets upset.
I backed off my disk size and even 20GB triggers the crash. 16GB seems to be OK.
Now OpenVMS beyond V5.5-2 supports single volumes of 1TB, so I'm surprised that a 16GB volume causes a crash.
Does anyone have a real VAX with a real disk (> 16GB) successfully hanging off it? I do have some SCA-80 36GB disks but I've never successfully got them working on either a VS4000-96 or a VS4000-60, so I'm not in a position to try this out myself.
Get the latest SIMH and use the MicroVAX 3900 emulation. I boot my V7.3
from a 1.5 GB disk and have about a 22 GB data disk and another 4 GB
disk. I'm sure I've had simulations with larger drives. This was just
one I put together to stick on a flash drive to show some coworkers.

I seem to recall a customer running V7.1 on a VAX 4000-105 with a bit
larger boot drive and certainly a 20 GB data drive.
arca...@gmail.com
2021-05-26 08:44:29 UTC
Permalink
Post by Tad Winters
Get the latest SIMH and use the MicroVAX 3900 emulation.
SIMH was freshly built from the repo and it is the microvax3900 emulator.
Post by Tad Winters
I boot my V7.3
from a 1.5 GB disk and have about a 22 GB data disk and another 4 GB
disk. I'm sure I've had simulations with larger drives.
OK, thanks. So maybe V7.3 would have helped. Unfortunately my CDROM stash only goes as far as V7.2.

Antonio
Volker Halle
2021-05-26 05:39:27 UTC
Permalink
Antonio,

does this OpenVMS VAX V7.2 system have a SYSDUMP.DMP file ? If so, is there a CLUE$COLLECT:CLUE$node_ddmmyy_hhmm.LIS file ? Could you post the contents of that file - at least the CANASTA parameters section, the first 30 lines of the kernel stack and the insturction stream ?

If the CLUE file does not contain the crash footprint anymore, you can re-create it using:

$ CLUE:==$CLUE
$ CLUE/OUT=SYS$DISK:[]clue.lis SYS$SYSTEM:SYSDUMP.DMP

Volker.
arca...@gmail.com
2021-05-26 09:07:49 UTC
Permalink
Post by Volker Halle
Antonio,
does this OpenVMS VAX V7.2 system have a SYSDUMP.DMP file ? If so, is there a CLUE$COLLECT:CLUE$node_ddmmyy_hhmm.LIS file ?
There is a CLUE$LAST_VAX072.LIS in SYS$MANAGER but it just records the last shutdown. I can (I think) recreate the crash at will so I can do that once I've finished the current FTP session (although that will probably take most of today ... 30GB is a lot to transfer on an emulated VAX!).

I can probably scrounge up a listings CD and BUGCHECK.MEM and see if I can remember how to walk a VAX stack, but I'm not sure where to go from there. I don't think HP will be interested and they almost certainly don't have anyone left who remembers how to generate an ECO for OpenVMS VAX. Even if they did, they wouldn't let me have it for free :-)

Antonio
Volker Halle
2021-05-26 09:41:41 UTC
Permalink
Antonio,

you could also use the CLUE history file to obtain the CLUE crash footprint - while waiting for the FTP copy to finish ;-)

$ CLUE:==$CLUE ! define CLUE as foreign command
$ CLUE/DISPLAY ! display list of crashes
CLUE> SHOW n ! n = crash number from column 1 (#)
CLUE> EXTRACT/OUT=crash.lis n

Volker.
arca...@gmail.com
2021-05-26 18:22:26 UTC
Permalink
Post by Volker Halle
you could also use the CLUE history file to obtain the CLUE crash footprint - while waiting for the FTP copy to finish ;-)
$ CLUE:==$CLUE ! define CLUE as foreign command
$ CLUE/DISPLAY ! display list of crashes
Seemingly not:

$ CLUE:==$CLUE
$ CLUE/DISPLAY
%CLUE_F_FATAL CLUE$OUTPUT:CLUE$HISTORY.DATA, Illegal format: @ 1:0B4
$

Just because I can, when I reach a convenient point, I'll crash it and see if I can dig out some info for you.

I'll expect a patch by return though :-)

Antonio
arca...@gmail.com
2021-05-27 21:24:41 UTC
Permalink
Post by Volker Halle
Antonio,
There is a CLUE history problem in V7.2 !
I may not be able of offer a patch, but maybe a workaround...
I think the workaround is either "don't do that" or "use V7.3"!

The bug is just the XQP getting upset. COPY is enough to make it happen, so I expect that anything that creates a file (and maybe writes to it) is enough to trigger the bug.
I have the V7.1 listings but not the V7.2 listings. Things have changed enough between the two that I can't find the DIVL3 (which looked rare enough that there wouldn't be a huge number of hits, or at least fewer than UNXSIGNAL!).
I don't really feel like going through the process of installing V7.1 just to pin this one down, so that's as far as I'm going to go.

I've included the crash and the CLUE output for posterity :-)

(Apologies for the length ...)

Antonio


$ sh dev dud3

Device Device Error Volume Free Trans Mnt
Name Status Count Label Blocks Count Cnt
VAX072$DUD3: Mounted 0 TEST 59999144 1 1
$ set def dud3:[000000]
$ copy tt: test.txt
test


**** Fatal BUG CHECK, version = V7.2 UNXSIGNAL, Unexpected signal name in ACP

Crash CPU: 00 Primary CPU: 00

Active/available CPU masks: 00000001/00000001

Current process = SYSTEM

Register dump

R0 = 7FF6E0D8
R1 = 7FF6EAFC
R2 = 7FF6E4C0
R3 = 7FF6E4AC
R4 = 7FF6E4D0
R5 = 7FF6E4A8
R6 = 7FF6E588
R7 = 00000000
R8 = 00000003
R9 = 7FF6E4C0
R10= 7FF6E564
R11= 00000357
AP = 7FF6E088
FP = 7FF6E060
SP = 7FF6E050
PC = 833CAABC
PSL= 00000000


Then more with CLUE:

$ ty SYS$MANAGER:clue.lis
CLUE Version: V1.9 Date: 27-MAY-2021 21:43:33.37

CLUE /OUT=SYS$MANAGER:CLUE.LIS SYS$SYSTEM:SYSDUMP.DMP

Dump File: SYS$SYSROOT:[SYSEXE]SYSDUMP.DMP;1

Full Memory Dump: Dump Flags = 020400C0
Current Process Name = SYSTEM
Current IPL = 0
Dump file version = 0530
# memory pages in dump = 130944 Physical memory = 64 MB
SID = 0A000006
Crash time = 27-MAY-2021 21:35:53.61
Current Access mode = KERNEL
Node Name = VAX072 Clustered
Crash CPU/Primary CPU = 0 / 0
CPU 0 Crash Code 41C,Crash Type = UNXSIGNAL
Bitmask of CPUs available = 1
Bitmask of CPUs active = 1
CPU Bitmask completing bugcheck = 1
Current image: = VAX072$DUA0:[SYS0.SYSCOMMON.][SYSEXE]COPY.EXE
CPU Type = VAXserver 3900 Series
VMS Version = V7.2

Symbol Value Contents

EXE$GL_MCHKERRS -> 800044F0 = 00000000
EXE$GL_MEMERRS -> 800044F4 = 00000000
EXE$GL_STATE -> 80008490 = 00003FFE
EXE$GQ_BOOTTIME -> 80004460 = 27-MAY-2021 21:30:03.46
EXE$GL_FLAGS -> 800042F0 = 02416865
IO$GL_UBA_INT0 -> 800044F8 = 00000000
MPW$GB_IOLIM -> 800080AA = 00040404
PMS$GL_NPAGDYNEXPF -> 80004700 = 00000000
PMS$GL_NPAGDYNF -> 8000491C = 00000000
PMS$GL_NPAGDYNFPAGES -> 80004920 = 00000000
PMS$GL_NPAGDYNREQF -> 8000492C = 00000000
PMS$GL_PAGDYNF -> 80004704 = 00000000
PMS$GL_PAGDYNFPAGES -> 80004924 = 00000000
PMS$GL_PAGDYNREQF -> 80004934 = 00000000
SCH$GL_FREECNT -> 80004018 = 00017AF9
SCH$GL_PFRATL -> 800080C4 = 00000000

SBR 03E98400 SLR 00055F00

Processor Information for Crash CPU 0 (Hex)

R0 7FF6E0D8 R1 7FF6EAFC R2 7FF6E4C0 R3 7FF6E4AC R4 7FF6E4D0
R5 7FF6E4A8 R6 7FF6E588 R7 00000000 R8 00000003 R9 7FF6E4C0
R10 7FF6E564 R11 00000357 AP 7FF6E088 FP 7FF6E060 SP 7FF6E058
PC 833CAABC PSL 00000000 KSP 7FF6E058 ESP 7FFE971C SSP 7FFECA44
USP 7FEC70F8 ISP 8464F600 P0BR 84734A00 P1BR 83F84A00 P0LR 000005BD
P1LR 001FF625 PCBB 037CDA20 SCBB 03E91800 SISR 00000000

ASTLVL = 00000001
ICCS = 00000040

CPU Dependent Registers:

# Regs = 0D (Hex)
5BA6B25E
000000FC
00000000
00000000
00000001
00000000
00000020
00000000
00001000
00FFFFFF
80000017
00000050
00000004

Spinlocks owned by CPU 00 (Hex) (CRASH CPU) NONE










































Summary of System at time of Crash:

PCB State CPU Process Name Username EPID Pri PHD Wkset

8347DBA0 HIB SWAPPER 20200201 16 8347DA00 0
83AC4440 HIB CLUSTER_SERVER SYSTEM 20200206 12 847EB600 311
VAX072$DUA0:[SYS0.SYSCOMMON.][SYSEXE]CSP.EXE;1
83AC4640 HIB CONFIGURE SYSTEM 20200207 10 84784A00 180
VAX072$DUA0:[SYS0.SYSCOMMON.][SYSEXE]CONFIGURE.EXE;1
83AC4840 HIB LANACP SYSTEM 20200208 13 84852200 516
VAX072$DUA0:[SYS0.SYSCOMMON.][SYSEXE]LANACP.EXE;1
83AC4C40 HIB IPCACP SYSTEM 2020020A 10 84650600 177
VAX072$DUA0:[SYS0.SYSCOMMON.][SYSEXE]IPCACP.EXE;1
83AC4E40 HIB ERRFMT SYSTEM 2020020B 8 848B8E00 211
VAX072$DUA0:[SYS0.SYSCOMMON.][SYSEXE]ERRFMT.EXE;1
83AC5040 HIB CACHE_SERVER SYSTEM 2020020C 16 8491FA00 134
VAX072$DUA0:[SYS0.SYSCOMMON.][SYSEXE]FILESERV.EXE;1
83AC5240 HIB OPCOM SYSTEM 2020020D 9 84986600 257
VAX072$DUA0:[SYS0.SYSCOMMON.][SYSEXE]OPCOM.EXE;1
83AC5440 HIB AUDIT_SERVER AUDIT$SERVER 2020020E 9 849ED200 516
VAX072$DUA0:[SYS0.SYSCOMMON.][SYSEXE]AUDIT_SERVER.EXE;1
83AC5640 HIB JOB_CONTROL SYSTEM 2020020F 10 84A53E00 403
VAX072$DUA0:[SYS0.SYSCOMMON.][SYSEXE]JBC$JOB_CONTROL.EXE;1
83AC5840 HIB QUEUE_MANAGER SYSTEM 20200210 9 84ABAA00 1020
VAX072$DUA0:[SYS0.SYSCOMMON.][SYSEXE]QMAN$QUEUE_MANAGER.EXE;1
83AC5A40 HIB SECURITY_SERVER SYSTEM 20200211 10 84B21600 1370
VAX072$DUA0:[SYS0.SYSCOMMON.][SYSEXE]SECURITY_SERVER.EXE;1
83AC5C40 HIB SMISERVER SYSTEM 20200212 9 84B88200 592
VAX072$DUA0:[SYS0.SYSCOMMON.][SYSEXE]SMISERVER.EXE;1
83AC5E40 HIB TP_SERVER SYSTEM 20200213 9 84BEEE00 317
VAX072$DUA0:[SYS0.SYSCOMMON.][SYSEXE]TPSERV.EXE;1
83AC6240 HIB NETACP DECNET 20200215 10 84C55A00 377
VAX072$DUA0:[SYS0.SYSCOMMON.][SYSEXE]NETACP.EXE;1
83AC6440 HIB EVL DECNET 20200216 6 84CBC600 554
VAX072$DUA0:[SYS0.SYSCOMMON.][SYSEXE]EVL.EXE
83AC4240 HIB REMACP SYSTEM 20200217 8 84D23200 56
VAX072$DUA0:[SYS0.SYSCOMMON.][SYSEXE]REMACP.EXE;1
839DC140 HIB UCX$INET_ACP INTERnet 20200218 10 846B7200 175
VAX072$DUA0:[SYS0.SYSCOMMON.][SYSEXE]UCX$INETACP.EXE;1
83AC79C0 LEF UCX$INET_ROUTED INTERnet 20200219 6 84D89E00 504
VAX072$DUA0:[SYS0.SYSCOMMON.][SYSEXE]UCX$INET_ROUTING.EXE;1
83AC4040 CUR 0 SYSTEM SYSTEM 2020021A 9 8471DE00 542
VAX072$DUA0:[SYS0.SYSCOMMON.][SYSEXE]COPY.EXE





















Code Modules:

Module Name Address Length

UCX$INTERNET_SERVICES 82F4D000 00015800
SYSMSG 832C5200 00045200
SYSLDR_DYN 834FA200 00002000
DDIF$RMS_EXTENSION 834FC600 00001200
RECOVERY_UNIT_SERVICES 834FDA00 00000800
RMS 8330A600 0002C400
SYS$NTA 8337F600 00000200
VAXCLUSTER_CACHE 8337FC00 00004A00
SYS$NETWORK_SERVICES 83384C00 00000200
SYS$UTC_SERVICES 83385400 00000E00
SYS$TRANSACTION_SERVICES 83386800 0000DE00
SYS$IPC_SERVICES 83394A00 0001DC00
CPULOA 833B2800 00005400
LMF$GROUP_TABLE 833BA000 00001A00
SYSLICENSE 833BBE00 00003200
F11BXQP 833BF400 0001F600
SNAPSHOT_SERVICES 833DF200 00000C00
SYSGETSYI 833E0400 00002000
SYSDEVICE 833E2800 00002A00
MESSAGE_ROUTINES 833E5800 00006200
EXCEPTION 833FC000 0000A800
LOGICAL_NAMES 83407000 00023800
SECURITY 8342B200 00009A00
LOCKING 83435400 00006C00
PAGE_MANAGEMENT 8343CA00 00009E00
WORKING_SET_MANAGEMENT 8345B600 00005E00
IMAGE_MANAGEMENT 83461E00 00003600
EVENT_FLAGS_AND_ASTS 83465A00 00002200
IO_ROUTINES 83468600 0000CA00
PROCESS_MANAGEMENT 83476A00 0000C400
ERRORLOG 834EC400 00000C00
PRIMITIVE_IO 834ED600 00001200
SYSTEM_SYNCHRONIZATION_UNI 834EEC00 00004400
SYSTEM_PRIMITIVES_MIN 834F3600 00003E00
BUGCHECK_CODE_OVERLAY 82F4D000 00003964
TNDRIVER 83B21200 000034C0
UCX$BGDRIVE 83AC6640 00000240
RTTDRIVER 83AEE5C0 00000B80
CTDRIVER 83B1D7C0 00002980
NDDRIVER 83AEAEC0 00000AC0
NETDRIVER 83B0F2C0 00005140
PIPEDRIVER 83AD10C0 00000580
FTDRIVER 83AE7280 000009C0
YFDRIVER 83B01800 00001140
DZDRIVER 83AF3A80 00000D40
PEDRIVER 839F0B00 0000B2C0
XQDRIVER 839DE340 000091C0
DUDRIVER 83C33700 00005F90
PUDRIVER 83C30240 0000349A
TTDRIVER 83C2A4C0 00005D7D
OPERATOR 834F5C00 0000056C
NLDRIVER 833E2883 0000019B
MBDRIVER 833E2800 000019A0
CLIMAGE 7FF50400 0001CDFF
CLUSTRLOA 83C125C0 0000F8FF
SYSLOA 83C22EC0 000047C8
F11BXQP 00000000 00000000
F11BXQP_IMPURE 7FF6D200 80092E00
CTL$GQ_DBGAREA 7FFF0000 0000FFFF
P1SYSVECTORS 7FFEDE00 000009FF
FPEMUL 83C0C480 00002ABC
VAXEMUL 83C0EF40 0000367F
MSCP 83A17780 00003FA0
SCSLOA 83C276C0 00002DEF
PAGED_POOL 8377CE00 002415FF
NONPAGED_POOL 839BE400 00283000
ALLOCATABLE_S0 8000AF84 034F867B
COPY 00000200 0000DDFF

























































Contents of KERNEL Stack:

7FF6E038 7FF6E4C0
7FF6E03C 7FF6E564
7FF6E040 00000357
7FF6E044 7FF6E088
7FF6E048 7FF6E060
7FF6E04C 7FF6E050
7FF6E050 833CAABC <= PC F11BXQP+B6BC
7FF6E054 00000000

7FF6E058 7FF6E684 <= SP
7FF6E05C 7FF6E630
7FF6E060 00000000 <= FP
7FF6E064 243C0000 <= Mask/PSW (CALLS)
7FF6E068 7FF6E0B4 <= Saved AP
7FF6E06C 7FF6E09C <= Saved FP
7FF6E070 833CAA59 <= Saved PC F11BXQP+B659
7FF6E074 83ACA0BC <= R2 NONPAGED_POOL+10BCBC
7FF6E078 83AC9F80 <= R3 NONPAGED_POOL+10BB80
7FF6E07C 00000000 <= R4
7FF6E080 0000003A <= R5
7FF6E084 7FF6E564 <= R10
7FF6E088 00000003 <= AP
7FF6E08C 7FF6E0D8 <= Argument # 1
7FF6E090 7FF6E0C0
7FF6E094 7FF6E098
7FF6E098 00000000
7FF6E09C 00000000 <= FP
7FF6E0A0 00000000 <= Mask/PSW (CALLG)
7FF6E0A4 7FF6E144 <= Saved AP
7FF6E0A8 7FF6E10C <= Saved FP
7FF6E0AC 80000014 <= Saved PC EXE$QIOW_3+4
7FF6E0B0 833FEA63 EXCEPTION+2A63 EXE$SRCHANDLER+76
7FF6E0B4 00000002
7FF6E0B8 7FF6E0D8
7FF6E0BC 7FF6E0C0
7FF6E0C0 00000004
7FF6E0C4 7FF6E464
7FF6E0C8 00000004
7FF6E0CC 00000357
7FF6E0D0 83AC84C0 NONPAGED_POOL+10A0C0
7FF6E0D4 03000001
7FF6E0D8 00000003 <= Signal Array Argument Count
7FF6E0DC 00000484 <= SS$_INTDIV, Integer divide by zero
7FF6E0E0 833C4D70 <= Exception PC F11BXQP+5970
7FF6E0E4 00000002 <= Exception PSL
7FF6E0E8 7FF6E4D8
7FF6E0EC 7FF6E4D4
7FF6E0F0 00000003
7FF6E0F4 039383A8
7FF6E0F8 00000000
7FF6E0FC 00020001
7FF6E100 00000000
7FF6E104 000000B9
7FF6E108 00000000
7FF6E10C 00000000 <= FP
7FF6E110 2BFC0000 <= Mask/PSW (CALLS)
7FF6E114 7FF6E1AC <= Saved AP
7FF6E118 7FF6E174 <= Saved FP
7FF6E11C 833C446B <= Saved PC F11BXQP+506B
7FF6E120 83ACA0BC <= R2 NONPAGED_POOL+10BCBC
7FF6E124 83AC9F80 <= R3 NONPAGED_POOL+10BB80
7FF6E128 00000002 <= R4
7FF6E12C 00000000 <= R5
7FF6E130 7FF6E9CC <= R6
7FF6E134 7FF6E4D8 <= R7
7FF6E138 7FF6E4A8 <= R8
7FF6E13C 7FF6E5DC <= R9
7FF6E140 7FF6E588 <= R11
7FF6E144 00000005 <= Argument Count
7FF6E148 7FF6E9CC <= Arg. # 1
7FF6E14C 00000080 <= Arg. # 2
7FF6E150 7FF6E214 <= Arg. # 3
7FF6E154 7FF6E210 <= Arg. # 4
7FF6E158 00000000 <= Arg. # 5
7FF6E15C 7FF6E4D4
7FF6E160 7FF6E564
7FF6E164 7FF6E4F8
7FF6E168 7FF6E4C0
7FF6E16C 00000000
7FF6E170 00000000
7FF6E174 00000000 <= FP
7FF6E178 2BFC0000 <= Mask/PSW (CALLS)
7FF6E17C 7FF6E250 <= Saved AP
7FF6E180 7FF6E218 <= Saved FP
7FF6E184 833C7462 <= Saved PC F11BXQP+8062
7FF6E188 00000001 <= R2
7FF6E18C 837EECC8 <= R3 PAGED_POOL+71EC8
7FF6E190 00000000 <= R4
7FF6E194 83AB0A70 <= R5 NONPAGED_POOL+F2670
7FF6E198 7FF6E9CC <= R6
7FF6E19C 837EEC00 <= R7 PAGED_POOL+71E00
7FF6E1A0 837EECC8 <= R8 PAGED_POOL+71EC8
7FF6E1A4 837EECC8 <= R9 PAGED_POOL+71EC8
7FF6E1A8 7FF6E9CC <= R11
7FF6E1AC 00000004 <= Argument Count
7FF6E1B0 7FF6E9CC <= Arg. # 1
7FF6E1B4 00000080 <= Arg. # 2
7FF6E1B8 7FF6E214 <= Arg. # 3
7FF6E1BC 7FF6E210 <= Arg. # 4
7FF6E1C0 7FF6D24C
7FF6E1C4 7FF6E594
7FF6E1C8 7FF6E590
7FF6E1CC 7FF6E58C
7FF6E1D0 7FF6E588
7FF6E1D4 7FF6E584
7FF6E1D8 7FF6E574
7FF6E1DC 7FF6E570
7FF6E1E0 7FF6E564
7FF6E1E4 7FF6E4E0
7FF6E1E8 7FF6E4D8
7FF6E1EC 7FF6E4C0
7FF6E1F0 837EEC00 PAGED_POOL+71E00
7FF6E1F4 83AB0A00 NONPAGED_POOL+F2600
7FF6E1F8 7FF6E57C
7FF6E1FC 7FF6E56C
7FF6E200 00000000
7FF6E204 00000080
7FF6E208 00000000
7FF6E20C 00000000
7FF6E210 00000000
7FF6E214 00040004
7FF6E218 00000000 <= FP
7FF6E21C 2BFC0000 <= Mask/PSW (CALLS)
7FF6E220 7FF6E3CC <= Saved AP
7FF6E224 7FF6E394 <= Saved FP
7FF6E228 833CCCCF <= Saved PC F11BXQP+D8CF
7FF6E22C 00000000 <= R2
7FF6E230 7FF6E4D4 <= R3
7FF6E234 7FF6D264 <= R4
7FF6E238 83AB0A70 <= R5 NONPAGED_POOL+F2670
7FF6E23C 7FF6E9CC <= R6
7FF6E240 837EEC00 <= R7 PAGED_POOL+71E00
7FF6E244 83AB0A00 <= R8 NONPAGED_POOL+F2600
7FF6E248 7FF6E4DC <= R9
7FF6E24C 7FF6E4D8 <= R11
7FF6E250 00000003 <= Argument Count
7FF6E254 7FF6E9CC <= Arg. # 1
7FF6E258 837EEC00 <= Arg. # 2 PAGED_POOL+71E00
7FF6E25C 00000000 <= Arg. # 3
7FF6E260 83AA698C NONPAGED_POOL+E858C
7FF6E264 83AC4040 NONPAGED_POOL+105C40
7FF6E268 7FF6EAD4
7FF6E26C 7FF6EAA0
7FF6E270 7FF6E574
7FF6E274 7FF6E570
7FF6E278 7FF6E56C
7FF6E27C 7FF6E564
7FF6E280 7FF6E4D0
7FF6E284 00000007
7FF6E288 00000000
7FF6E28C 00000000
7FF6E290 00000000
7FF6E294 7FF6E29C
7FF6E298 00000000
7FF6E29C 00000000
7FF6E2A0 00000002
7FF6E2A4 00000002
7FF6E2A8 00000002
7FF6E2AC 00000001
7FF6E2B0 00000000
7FF6E2B4 00000000
7FF6E2B8 00000000
7FF6E2BC 00000000
7FF6E2C0 7FF6E310
7FF6E2C4 7FF6E2D4
7FF6E2C8 833FC460 EXCEPTION+460 EXE$EXCEPTION+228
7FF6E2CC 7FFEE3CE P1SYSVECTORS+5CE SYS$DEQ+6
7FF6E2D0 00000000
7FF6E2D4 00000000
7FF6E2D8 2FFC0000
7FF6E2DC 7FF6E384
7FF6E2E0 7FF6E34C
7FF6E2E4 833CFD02 F11BXQP+10902
7FF6E2E8 7FF6E4D8
7FF6E2EC 7FF6E5DC
7FF6E2F0 00000000
7FF6E2F4 7FF6EAEC
7FF6E2F8 7FF6E4A8
7FF6E2FC 7FF6E57C
7FF6E300 7FF6E5F8
7FF6E304 7FF6E684
7FF6E308 7FF6E64C
7FF6E30C 7FF6E5F8
7FF6E310 7FF6E4FC
7FF6E314 7FF6E4E4
7FF6E318 7FF6E33C
7FF6E31C 00000000
7FF6E320 00000000
7FF6E324 0001001A
7FF6E328 00000001
7FF6E32C 7FF6F828
7FF6E330 7FF6D3A4
7FF6E334 7FF6D298
7FF6E338 00000000
7FF6E33C 2BFC0000
7FF6E340 7FF6E3CC
7FF6E344 7FF6E394
7FF6E348 833C8ECB F11BXQP+9ACB
7FF6E34C 7FF6E574
7FF6E350 7FF6EA94
7FF6E354 7FF6EA90
7FF6E358 7FF6EA8C
7FF6E35C 83A7F980 NONPAGED_POOL+C1580
7FF6E360 7FF6EA98
7FF6E364 7FF6EAA0
7FF6E368 7FF6E4EC
7FF6E36C 00000000
7FF6E370 FFFFFFFF
7FF6E374 83780310 PAGED_POOL+3510
7FF6E378 83780300 PAGED_POOL+3500
7FF6E37C 833D20CD F11BXQP+12CCD F11X$INIT_XQP+DBD
7FF6E380 7FF6E4D0
7FF6E384 00000001
7FF6E388 00000002
7FF6E38C 00000004
7FF6E390 00000001
7FF6E394 00000000 <= FP
7FF6E398 2BFC0000 <= Mask/PSW (CALLS)
7FF6E39C 7FF6E49C <= Saved AP
7FF6E3A0 7FF6E464 <= Saved FP
7FF6E3A4 833CA7C8 <= Saved PC F11BXQP+B3C8
7FF6E3A8 00000000 <= R2
7FF6E3AC 7FF6D2A2 <= R3
7FF6E3B0 00000000 <= R4
7FF6E3B4 00000000 <= R5
7FF6E3B8 7FF6E9CC <= R6
7FF6E3BC 7FF6D200 <= R7
7FF6E3C0 7FF6E4D0 <= R8
7FF6E3C4 833DD7C8 <= R9 F11BXQP+1E3C8
7FF6E3C8 7FF6D288 <= R11
7FF6E3CC 00000000 <= Argument Count
7FF6E3D0 7FF6D298
7FF6E3D4 7FF6D27C
7FF6E3D8 7FF6D278
7FF6E3DC 7FF6D274
7FF6E3E0 7FF6D270
7FF6E3E4 7FF6D264
7FF6E3E8 7FF6D254
7FF6E3EC 7FF6D250
7FF6E3F0 7FF6D248
7FF6E3F4 7FF6D23C
7FF6E3F8 7FF6D224
7FF6E3FC 7FF70DF4
7FF6E400 7FF6EC94
7FF6E404 7FF6EAF0
7FF6E408 7FF6EAD8
7FF6E40C 7FF6E578
7FF6E410 7FF6E574
7FF6E414 7FF6E56C
7FF6E418 7FF6E564
7FF6E41C 7FF6E50C
7FF6E420 7FF6E4EC
7FF6E424 7FF6E4E8
7FF6E428 7FF6E4DC
7FF6E42C 7FF6E4D8
7FF6E430 7FF6E4D4
7FF6E434 7FF6E4C0
7FF6E438 7FF6E4B0
7FF6E43C 7FF6E4A8
7FF6E440 7FF6E4A0
7FF6E444 833DD678 F11BXQP+1E278
7FF6E448 00000036
7FF6E44C 00000001
7FF6E450 00000000
7FF6E454 00000001
7FF6E458 7FF6E4A0
7FF6E45C 00000000
7FF6E460 00000000
7FF6E464 833CAA48 <= FP F11BXQP+B648
7FF6E468 2BFC0000 <= Mask/PSW (CALLS)
7FF6E46C 7FFE7794 <= Saved AP CTL$GL_KSTKBAS+594
7FF6E470 00000000 <= Saved FP
7FF6E474 833CA38E <= Saved PC F11BXQP+AF8E
7FF6E478 7FF6D224 <= R2
7FF6E47C 7FF6E4B0 <= R3
7FF6E480 833CA3A4 <= R4 F11BXQP+AFA4
7FF6E484 7FF6D23C <= R5
7FF6E488 7FF6D238 <= R6
7FF6E48C 7FF70DF8 <= R7
7FF6E490 7FF6E4A8 <= R8
7FF6E494 7FF6E4B8 <= R9
7FF6E498 7FFEFF90 <= R11 CTL$GL_F11BXQP
7FF6E49C 00000000 <= Argument Count


































Instruction at PC 833C4D70

F11BXQP+5970 833C4D70 TSTL (R6)

Instructions around PC 833C4D70

F11BXQP+5948 833C4D48 MOVF #3C,3E(R0)
Invalid opcode 57 @833C4D4C
F11BXQP+594D 833C4D4D ASHL #0C,R7,R7
F11BXQP+5951 833C4D51 MOVL R7,10(SP)
F11BXQP+5955 833C4D55 MOVL @04(SP),R0
F11BXQP+5959 833C4D59 MOVZBL 50(R0),R1
F11BXQP+595D 833C4D5D MOVZBL 51(R0),R0
F11BXQP+5961 833C4D61 MULL2 R1,R0
F11BXQP+5964 833C4D64 MOVL @00(SP),R1
F11BXQP+5968 833C4D68 MOVZBL 56(R1),R11
F11BXQP+596C 833C4D6C DIVL3 R11,R0,R11
F11BXQP+5970 PC>833C4D70 TSTL (R6)
F11BXQP+5972 833C4D72 BEQL F11BXQP+59AF
F11BXQP+5974 833C4D74 MOVL @00(SP),R0
F11BXQP+5978 833C4D78 MOVZWL 40(R0),R1
F11BXQP+597C 833C4D7C DIVL3 R1,(R6),R1
F11BXQP+5980 833C4D80 DIVL2 #00001000,R1


Failing PC is 833C4D70 F11BXQP+5970






































Canasta Parameters:

VMS Version : 7.2
Crash Type : UNXSIGNAL
Current Process : SYSTEM
Current Image : COPY
CPU Type : 3900
SID : 0A000006
Signal Array cnt: 3
Exception par #1: 00000484
Exception par #2: FFFFFFFF
Exception par #3: FFFFFFFF
Exception PC : 833C4D70
Exception PSL : 00000002
Failing Inst : TSTL
Code Module : F11BXQP
Offset : 5970

27-MAY-2021 21:43:34.13
Volker Halle
2021-05-28 11:07:55 UTC
Permalink
Antonio,

this was a 'known problem' at it's time - mostly V6.2.

There even was/is a CANASTA rule describing this problem and a workaround...

CANASTA was the automatic Crashdump Analysis Tool, which I maintained for about a decade while at Digital/Compaq/HP. I still claim to be the person, which has seen more OpenVMS crash footprints than anyone else ;-)

The problem itself seems to be in MOUNT, when setting up the geometry of the disk. Solutions i.e. patches may exist in the V7.2 remedial stream or higher.

WORKAROUND:

Configure a smaller disk on the controller. After configuring the smaller
disk, mount the disk and do a $ SHOW DEVICE/FULL. Perform the following
calculation using the numbers from the $ SHOW DEVICE/FULL output.

sectors per track * tracks per cylinder * total cylinders = total blocks.

If the calculation works, the disk is OK to use.

With ANALYZE/SYSTEM:

SDA> READ SYS$SYSTEM:SYSDEF
SDA> SHOW DEV DKcnnn
...
SDA> exa ucb+ucb$l_maxblock
UCB+000C4: 021EB1B0 "°±.."
SDA> eva (@(ucb+ucb$b_sectors)&FF)*(@(ucb+ucb$b_tracks)&FF)*(@(ucb+ucb$w_cylinders)&FFFF)
Hex = 0020B32C Decimal = 2143020

This crash has also been seen on a CHARON-VAX (Stromasys commercial VAX emulator) and could be prevented by using the geometry statement to set a 'valid' geometry, e.g.

SET DKA geometry[200] = "125/16/17783" ! s=sectors t=tracks c=cylinders (disk size about 18 GB)

Don't know if simh supports setting the disk geometry.

Volker.
arca...@gmail.com
2021-05-28 13:52:58 UTC
Permalink
Post by Volker Halle
CANASTA was the automatic Crashdump Analysis Tool, which I maintained for about a decade while at Digital/Compaq/HP. I still claim to be the person, which has seen more OpenVMS crash footprints than anyone else ;-)
Ah, now I see why you wanted the CLU output :-)
Post by Volker Halle
The problem itself seems to be in MOUNT, when setting up the geometry of the disk. Solutions i.e. patches may exist in the V7.2 remedial stream or higher.
OK, thanks for that.
Post by Volker Halle
Don't know if simh supports setting the disk geometry.
Not that I can see.

But I'm OK with configuring a bunch of smaller disks. Then I can archive "clean" copies of the original SIMH .dsk containers somewhere and work through the data on the emulated system.

Antonio
Stephen Hoffman
2021-05-28 15:00:24 UTC
Permalink
Post by Volker Halle
The problem itself seems to be in MOUNT, when setting up the geometry
of the disk. Solutions i.e. patches may exist in the V7.2 remedial
stream or higher.
There was an easily-reproduceable bug in a related area of MOUNT.

Load a blank CD into an optical drive, and MOUNT it.

Kernel loop.

Using MOUNT with a blank CD (unsurprisingly) got somewhat odd responses
from the device, and the drivers and MOUNT then mis-handled it, leading
to an un-deletable process looping in kernel mode.

Only fix was a reboot, after dropping the process priority of the
looping process to let it tussle with null until the reboot was
feasible.

IIRC, both MOUNT and the related device drivers got fixes as a result
of that particular case. And IIRC, it was a bug in the MOUNT code
intended to find the home block / alternate home block.

ps: CANASTA/CCAT/etc was handy to have around. Unfortunately, it
usually just left me with a pile of gnarly crashes, after having used
it to eliminate all the known crashes.
--
Pure Personal Opinion | HoffmanLabs LLC
Stephen Hoffman
2021-05-26 16:11:04 UTC
Permalink
... 30GB is a lot to transfer on an emulated VAX!...
Transfer it to the host via scp or sftp or ftp or whatever, and mount
the image from the emulation? IIRC, there are virtual tape bits for
simh, too. And for unpacking savesets, vmsbackup (usually) works on
macOS and Linux.
--
Pure Personal Opinion | HoffmanLabs LLC
gah4
2021-05-28 08:04:27 UTC
Permalink
Post by ***@gmail.com
I wanted a 100GB disk (using SIMH) under OpenVMS VAX V7.2.
That seems to be fine until I try to create a file.
Admittedly I've only tried to create a file either using FTP or BACKUP,
but as they're so disconnected, I assume that it's actually XQP
(or something in the file system) that gets upset.
Just wondering, does it know about NFS?

I think NFS mostly gets around disk size problems, as the client OS doesn't really
need to know about it. I do find that disk available reports sometimes do 32 bit
math, and get the wrong value, but that doesn't affect actual disk use.

A few years ago, I had a Sun3 NFS boot off a 3TB disk, which it didn't
mind at all. The last release of SunOS 4.1.1 was in 1991, so I am pretty
sure didn't know about 3TB disks.

Also, and this might apply to VMS, NFS disks tend to remove file name length
restrictions of the client OS. Years ago, we had a version of HP-UX that had
a short (I believe 17 character) restriction on its native file system, but
not for NFS.
chris
2021-06-01 16:48:44 UTC
Permalink
Post by gah4
Post by ***@gmail.com
I wanted a 100GB disk (using SIMH) under OpenVMS VAX V7.2.
That seems to be fine until I try to create a file.
Admittedly I've only tried to create a file either using FTP or BACKUP,
but as they're so disconnected, I assume that it's actually XQP
(or something in the file system) that gets upset.
Just wondering, does it know about NFS?
I think NFS mostly gets around disk size problems, as the client OS doesn't really
need to know about it. I do find that disk available reports sometimes do 32 bit
math, and get the wrong value, but that doesn't affect actual disk use.
A few years ago, I had a Sun3 NFS boot off a 3TB disk, which it didn't
mind at all. The last release of SunOS 4.1.1 was in 1991, so I am pretty
sure didn't know about 3TB disks.
Also, and this might apply to VMS, NFS disks tend to remove file name length
restrictions of the client OS. Years ago, we had a version of HP-UX that had
a short (I believe 17 character) restriction on its native file system, but
not for NFS.
Sun 3 SunOs was 32 bit and a signed number described the partition
block count. For a boot partition, the limit was 1 Gbyte, from
memory.

The way we used to get round disk sizes for RT11, was to declare a
set of logical drives across a single drive, which worked very well.
I would think vms would have similar facilities...

of logical drives, which
Stephen Hoffman
2021-06-01 17:24:54 UTC
Permalink
Post by chris
The way we used to get round disk sizes for RT11, was to declare a
set of logical drives across a single drive, which worked very well.
I would think vms would have similar facilities...
of logical drives, which
OpenVMS Development never prioritized the addition of partitioning
support. That, and this case involves a very old and under-patched and
buggy OpenVMS VAX version. Retro-computing almost inherently involves
revisiting old bugs.

More recent OpenVMS has a hideously ugly partitioning hack commonly
found on OpenVMS I64 and specifically for Itanium EFI support, and that
hack is solely intended to present what OpenVMS expects (one big
volume) and what EFI expects (GPT partitioning) and without allowing
partition-aware tools to easily corrupt the OpenVMS one-big-volume view
of the storage. Silent console-triggered corruptions were once
possible here with older EFI firmware too, when the expectations of the
firmware and of OpenVMS diverged.

Back closer to the same era as the OpenVMS VAX version that started off
this discussion, VAXstation 3100 had 6-byte SCSI commands which limited
volume capacity support, so some folks took to placing the boot files
and crash files within the first ~gigabyte, which worked great right up
until an upgrade moved a file above the address of doom, or the dump
file got re-sized above the address of doom. Wrappage-triggered badness
often then ensued. Some folks placed a big file at the end of the
volume, which blocked upgrades from accessing that storage. I'd expect
some later used that as an LD device, though LD wasn't nearly as
commonly used back in the era when vast herds of VAXstation 3100 roamed
the earth. Yes, I'm here ignoring VD driver, and whatever that
pseudo-device latent in STABACKIT was named.
--
Pure Personal Opinion | HoffmanLabs LLC
Simon Clubley
2021-06-01 17:45:33 UTC
Permalink
Post by Stephen Hoffman
OpenVMS Development never prioritized the addition of partitioning
support. That, and this case involves a very old and under-patched and
buggy OpenVMS VAX version. Retro-computing almost inherently involves
revisiting old bugs.
It would be nice to have proper partition support on VMS, with multiple
bootable partitions as well.
Post by Stephen Hoffman
More recent OpenVMS has a hideously ugly partitioning hack commonly
found on OpenVMS I64 and specifically for Itanium EFI support, and that
hack is solely intended to present what OpenVMS expects (one big
volume) and what EFI expects (GPT partitioning) and without allowing
partition-aware tools to easily corrupt the OpenVMS one-big-volume view
of the storage. Silent console-triggered corruptions were once
possible here with older EFI firmware too, when the expectations of the
firmware and of OpenVMS diverged.
I wonder if we are heading towards a modern version of the various
WRITEBOOT issues and "fun" that sometimes happened in the old days... :-)

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
abrsvc
2021-06-01 18:34:54 UTC
Permalink
I find these discussions interesting. Why would anyone expect software written 20 or more years ago to support (without change) hardware that wasn't even a concept at the time? Saying that this may result in similar issues to the "writeboot" issues of the past seems a bit much too. Take a snapshot of the state of the software today and come back in 30 years with new hardware and see what happens. I would expect to see similar "problems".
arca...@gmail.com
2021-06-01 19:12:29 UTC
Permalink
I find these discussions interesting. Why would anyone expect software written 20 or more years ago to support (without change) hardware that wasn't even a concept at the time?
Well I've known a few people involved with OpenVMS over the years, so I know they have high standards :-)

Really I was mildly surprised by the crash and just wanted to check that I hadn't made a silly mistake.

Anyway, I've checked V7.3 and it's fine. I'll go back and check V6.2 when I get a chance.

Antonio
Simon Clubley
2021-06-02 12:05:12 UTC
Permalink
Post by abrsvc
I find these discussions interesting. Why would anyone expect software written 20 or more years ago to support (without change) hardware that wasn't even a concept at the time? Saying that this may result in similar issues to the "writeboot" issues of the past seems a bit much too. Take a snapshot of the state of the software today and come back in 30 years with new hardware and see what happens. I would expect to see similar "problems".
You should read what I wrote more carefully Dan.

My WRITEBOOT comment had nothing to do with old hardware but with
future systems.

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
arca...@gmail.com
2021-06-01 19:08:20 UTC
Permalink
Post by Simon Clubley
It would be nice to have proper partition support on VMS, with multiple
bootable partitions as well.
If you mean booting out of the equivalent of an LDDRIVER image, yes. (Except that would be hard).

If you mean Unix style partitioning, what would you gain? You have to fix the size at partition time (or trust "interesting" tools to rejig stuff for you).

On SIMH, you can just throw another device at it and "B DUAn" for a suitable value of n.

Antonio
Stephen Hoffman
2021-06-01 20:32:26 UTC
Permalink
Post by ***@gmail.com
If you mean Unix style partitioning, what would you gain? You have to
fix the size at partition time (or trust "interesting" tools to rejig
stuff for you).
Storage partitioning is the typical solution here, and GPT partitioning
is expected by the Itanium EFI and x86-64 UEFI consoles.
--
Pure Personal Opinion | HoffmanLabs LLC
Stephen Hoffman
2021-06-01 20:48:53 UTC
Permalink
Post by Simon Clubley
Post by Stephen Hoffman
OpenVMS Development never prioritized the addition of partitioning
support. That, and this case involves a very old and under-patched and
buggy OpenVMS VAX version. Retro-computing almost inherently involves
revisiting old bugs.
It would be nice to have proper partition support on VMS, with multiple
bootable partitions as well.
Yes, it would. That was discussed before, and it'll undoubtedly be
discussed again.

The work here mostly touches the storage device drivers, SET BOOTBLOCK,
BACKUP, and a few other tools.

The common OpenVMS tools and ~all customer apps won't notice
partitioning, though.
Post by Simon Clubley
Post by Stephen Hoffman
More recent OpenVMS has a hideously ugly partitioning hack commonly
found on OpenVMS I64 and specifically for Itanium EFI support, and that
hack is solely intended to present what OpenVMS expects (one big
volume) and what EFI expects (GPT partitioning) and without allowing
partition-aware tools to easily corrupt the OpenVMS one-big-volume view
of the storage. Silent console-triggered corruptions were once
possible here with older EFI firmware too, when the expectations of the
firmware and of OpenVMS diverged.
I wonder if we are heading towards a modern version of the various
WRITEBOOT issues and "fun" that sometimes happened in the old days... :-)
There are always issues in this area. VSI is using a "creative" scheme
in support of booting and crashing on x86-64, too.

There's a separate and unchanging OpenVMS installation being kept
around particularly for assistance when crashing on x86-64.

Coincidentally, the same developer that created the ugly partitioning
hack for OpenVMS I64 re-wrote WRITEBOOT for V8.0, too.

SET BOOTBLOCK / sys$setboot as a foreign command or when RUN / and the
sys$setbootshr API.

SET BOOTBLOCK was intended to be necessary only for Itanium, but works
correctly with Alpha and VAX boot devices.

The tool can also correctly "sniff" and detect a bootable VAX, Alpha,
or Itanium storage device, among other features.

BACKUP calls into sys$setbootshr for various processing.

SET BOOTBLOCK necessarily knows all about the ugly hack for OpenVMS I64
and EFI, too.
--
Pure Personal Opinion | HoffmanLabs LLC
arca...@gmail.com
2021-06-01 19:05:04 UTC
Permalink
On Tuesday, 1 June 2021 at 18:24:57 UTC+1, Stephen Hoffman wrote: I'd expect
Post by Stephen Hoffman
some later used that as an LD device, though LD wasn't nearly as
commonly used back in the era when vast herds of VAXstation 3100 roamed
the earth.
A few years later than that is when I first used LDDRIVER seriously to build CDROMs that worked on both OpenVMS VAX/Alpha and PCs.
(For TXT/PDF/HTMK/maybe ZIP only).
Post by Stephen Hoffman
Yes, I'm here ignoring VD driver, and whatever that
pseudo-device latent in STABACKIT was named.
I've never never needed to look at STABACKIT ... something to note for a rainy day! Thanks :-)

Antonio
Loading...