V9.2-2 Bugcheck code = 0000041C: UNXSIGNAL, Unexpected signal name in ACP

OpenVMS virtualization: OpenVMS on VirtualBox, VMWare, Hyper-V, KVM, and more.
Post Reply

Topic author
snadow
Contributor
Posts: 15
Joined: Fri Feb 14, 2020 11:10 am
Reputation: 0
Status: Offline

V9.2-2 Bugcheck code = 0000041C: UNXSIGNAL, Unexpected signal name in ACP

Post by snadow » Thu Mar 14, 2024 12:44 am

First things first: Community license, so this is undoubtedly VERY low priority to investigate. But I'm posting it here in the hope that if I've tripped over something important that it'll get to the right person.
I've got V9.2-2 installed, along with the recent PCSI and UPDATE ECOs installed. I've installed most (but not all) of the other software that's available to Community users too. All of this in VirtualBox Version 7.0.14 r161095 (Qt5.15.2), on Windows 10 Home version, on an old-ish HP laptop. Processor is Intel(R) Core(TM) i7-5500U CPU @ 2.40GHz, 2401 Mhz, 2 Core(s), 4 Logical Processor(s).

So: I started up the Logical Magtape software during boot. (@SYS$STARTUP:LM$STARTUP)
Created a 10,000,000 block "virtual tape" file on the system disk with LM CREATE.
Set the virtual tape file to NOT make it eligible for backing-up (SET FILE /NOBACKUP)
Connected the virtual tape with LM CONNECT. It created device LMA2:
Initialized it (INIT LMA2: BLANK)
Mounted it (MOUNT/FOREIGN LMA2: BLANK)
Did an image backup to it of my system disk. Used "interesting" qualifiers to try to make the saveset as small as possible (I had no idea how much space it would need.) /NOCRC /GROUP=0 /DATA_FORMAT=COMPRESS /BLOCK_SIZE=65535 /ZLIB_LEVEL=9.
Also did more "normal" qualifiers, such as /IGNORE=(INTERLOCK,LABEL_PROCESSING) /SAVE_SET /REWIND

And then I sat back and watched it run. It took a long time, but it did finish successfully (just under 3 hours) and gave me this feedback at the end:
%BACKUP-I-COMPSUMMARY, data compressed by 48%

While the backup had been running, I did Control-T occasionally to see how it was progressing. About 10 minutes before it had completed, it showed that it had saved 4.05 gigabytes. I don't know if that figure is before or after compression; if it's after, my sizing of the virtual tape file at 10,000,000 blocks looks like it was a lucky guess that was big enough but not by too large of a margin.

So then I decided to take a look at my virtual tape:

$ dismount/nounload lma2:
$ mount/nowrite/noassist/nounload lma2: backup
%MOUNT-I-MOUNTED, BACKUP mounted on _SASX86$LMA2:
$ dir/size/date lma2:

And at some point later (don't know if it was "immediate" or "several minutes"), *crash*.

Code: Select all

VSI Dump Kernel SYSBOOT Nov  9 2023 12:17:04


**** OpenVMS x86_64 Operating System V9.2-2   - BUGCHECK ****

** Bugcheck code = 0000041C: UNXSIGNAL, Unexpected signal name in ACP
** Crash Time:            12-MAR-2024 06:42:23.77
** Crash CPU: 00000000    Primary CPU: 00000000    Node Name: SASX86
** Highest CPU number:    00000001
** Active CPUs:           00000000.00000003
** Current Process:       "LMA2AACP"
** Current PSB ID:        00000001
** Image Name:            SASX86$DKA0:[SYS0.SYSCOMMON.][SYSEXE]MTAAACP.EXE

** Dumping error logs to the system disk (SASX86$DKA0:)
** Error logs dumped to SASX86$DKA0:[SYS0.SYSEXE]SYS$ERRLOG.DMP
** (used 52 out of 64 available blocks)
** Dumping memory to the system disk (SASX86$DKA0:)

**** Starting interleaved memory dump at 12-MAR-2024 06:42:29.43 ****
** Determining system configuration...

%SMP-I-CPUTRN, CPU #1 has joined the active set.

** 1 secondary CPU has been started
** 17 processes to be dumped (includes 5 key processes)
** Calculating dump size...
.0%..13%....35%..58%..96%..100%.
** Size of dump without any compression: 794576 blocks.
** Compressing and writing memory...
.0%...6%...13%.....................38%.......................66%.......75%......
..80%............85%.....90%..
** System space, key processes, and key global pages have been dumped.
** Now dumping remaining processes and global pages...
..100%.

%SMP-I-CPUTRN, CPU #1 was removed from the active set.

** Memory dumped to SASX86$DKA0:[SYS0.SYSEXE]SYSDUMP.DMP
** (used 139949 out of 16253136 available blocks)

**** Completed interleaved memory dump at 12-MAR-2024 06:43:07.16 ****
** Time to write memory dump:               37.73


Restarting the system...
If anyone wants CLUE info, or the dumpfile, or anything else - let me know.

P.S., The timestamps from VMS are way off. That's due to my laptop going into sleep mode earlier before I did all of this. I don't believe that any of that sleeping occurred during any of the steps I listed above. Again, since this is just "Community" stuff, I'm not being rigorous about preventing the laptop from "just being a normal laptop" too. VMS doesn't seem to have any trouble waking-up when the laptop wakes up, other than the time being wrong.

Scott

Added in 8 hours 46 minutes 59 seconds:
OK, I've simplified this a lot! The backup that I ran before isn't relevant.

Now:

Boot the system
Login at the console
Create a virtual tape file taking all defaults (size = 5,000 blocks)
Connect the virtual tape file
Initialize the virtual tape
Mount the virtual tape ("normal" not /foreign)
Attempt a directory of the virtual tape...immediate crash.

Code: Select all

%SET-I-INTSET, login interactive limit = 64, current interactive value = 0
%DECW$DEVICE-I-NODEVICE, no graphics devices found.
%RUN-S-PROC_ID, identification of created process is 00000424
%%%%%%%%%%%  OPCOM  14-MAR-2024 07:37:33.57  %%%%%%%%%%%
Message from user SYSTEM on SASX86
%SMHANDLER-S-STARTUP, server management event handler startup

%%%%%%%%%%%  OPCOM  14-MAR-2024 07:37:37.24  %%%%%%%%%%%
Message from user INTERnet on SASX86
%TCPIP-I-FSIPADDRUP, IE0 192.168.68.127 primary active on node SASX86, interface
 IE0

  SYSTEM       job terminated at 14-MAR-2024 07:37:37.67

  Accounting information:
  Buffered I/O count:               5752      Peak working set size:      13952
  Direct I/O count:                 2802      Peak virtual size:         300432
  Page faults:                      8495      Mounted volumes:                0
  Charged CPU time:        0 00:00:08.01      Elapsed time:       0 00:00:17.04

 Welcome to OpenVMS (TM) x86_64 Operating System, Version V9.2-2

Username: system
Password:
VMS Software, Inc. OpenVMS (TM) x86_64 Operating System, V9.2-2
    Last interactive login on Tuesday, 12-MAR-2024 10:05:27.65
    Last non-interactive login on Monday, 11-MAR-2024 23:38:28.52

$
$ lm create crasher
$ lm connect crasher
%LM-I-UNIT, Allocated device is SASX86$LMA1:
$ init lma1: blank
$ mount lma1: blank
%MOUNT-I-MOUNTED, BLANK mounted on _SASX86$LMA1:
$ dir lma1:



VSI Dump Kernel SYSBOOT Nov  9 2023 12:17:04


**** OpenVMS x86_64 Operating System V9.2-2   - BUGCHECK ****

** Bugcheck code = 0000041C: UNXSIGNAL, Unexpected signal name in ACP
** Crash Time:            14-MAR-2024 07:38:50.29
** Crash CPU: 00000000    Primary CPU: 00000000    Node Name: SASX86
** Highest CPU number:    00000001
** Active CPUs:           00000000.00000003
** Current Process:       "LMA1AACP"
** Current PSB ID:        00000001
** Image Name:            SASX86$DKA0:[SYS0.SYSCOMMON.][SYSEXE]MTAAACP.EXE
After the system rebooted, I connected and mounted the same virtual tape file again, this time mounting it /FOREIGN. Attempting a directory on it didn't crash, but it failed with the expected error message:

Code: Select all

$ dir lma1:
%DIRECT-E-OPENIN, error opening LMA1:[SYSMGR]*.*;* as input
-SYSTEM-F-NOTFILEDEV, device is not file structured
I then tried using the DUMP command on it, and it gave me the expected output as well: Three eighty-byte ANSI header records followed by a pair of end-of-file markers.

I then tried mounting my virtual tape from yesterday that contained the backup - I mounted it /FOREIGN also - and successfully did a BACKUP/LIST of it.

I then created a new virtual tape, initialized it, mounted it normally, and tried to copy SYSTARTUP_VMS.COM to it; immediate crash again. So something about using virtual tapes (LM driver and related code) works fine when mounted /FOREIGN but crashes when using it "non-foreign." Or maybe it's the MTAACP, but I'm way over my head at this point.

Scott


dgordon
VSI Expert
Active Contributor
Posts: 37
Joined: Tue May 09, 2023 7:57 am
Reputation: 1
Status: Offline

Re: V9.2-2 Bugcheck code = 0000041C: UNXSIGNAL, Unexpected signal name in ACP

Post by dgordon » Thu Mar 14, 2024 3:25 pm

I've opened a ticket in engineering.
Executive Vice President of InfoServer Engineering at VSI.

Post Reply