Open agn453 opened 2 years ago
I have seen this, but not been able to reproduce it in the context of trying to track it down.
The excessive numbers and negative instruction time suggest we've got some sort of overflow issue in the calibration computations.
I just got a new laptop which absolutely doesn't see this issue. It happened much more often on my older box.
I get the same issue when testing as well.
I have compiled under:
Visual Studio 2022 -- Windows 10 Pro 21H2
Visual C/C++ 2008 -- Windows 7 Pro 32-bit
Visual C/C++ 2008 -- Windows 7 Pro 84-bit
SIMH commit id is 370bfe00 for all three compiles. (Same commit id as Tony)
My VAX reboot's don't hang like Tony's but I always get the Infinite loop error:
Operator _GRISOM$OPA0: has been disabled, username SYSTEM
SYSTEM SHUTDOWN COMPLETE - use console to halt system
Infinite loop, PC: 9E4044D3 (BRB 9E4044D3)
sim>
So I went back to the last official release:
git commit id: 0912a927 git commit time: 2020-06-09T20:07:41-07:00
And I got the same error!
Tony, what date might you be putting in at the VMS Date/Time prompt???
Something like:
%WBM-I-WBMINFO Write Bitmap has successfully completed initialization.
PLEASE ENTER DATE AND TIME (DD-MMM-YYYY HH:MM) 27-JAN-2021 12:28
$! Copyright 2001 Compaq Computer Corporation.
Because the Hobbyist licenses expired at the end of last year?
Just a hunch...
My VAX reboot's don't hang like Tony's but I always get the Infinite loop error:
Operator _GRISOM$OPA0: has been disabled, username SYSTEM
SYSTEM SHUTDOWN COMPLETE - use console to halt system
Infinite loop, PC: 9E4044D3 (BRB 9E4044D3) sim>
What you're seeing here is not an error. It is expected behavior.
These systems didn't have a software means of powering off the system, so when you shut it down the shutdown logic displays the message you see and sits in an infinite loop awaiting the operator to turn off the computer. As it turns, out this infinite loop is easy to detect (it loops with all interrupts disabled) so the VAX simulator detects this now otherwise useless behavior and stops the simulation and returns to the sim> prompt. Even if they did have a software means of powering off the system, the result of a power off command would also return to the sim> prompt.
Makes perfect sense. That mean's I can't reproduce Tony's error either. Sorry I can't be of much help on this one.
My VAX reboot's don't hang like Tony's but I always get the Infinite loop error:
The infinite loop is normal and the way SIMH detects that the system has shutdown (it goes into a tight loop).
I might also add that if I choose the reboot option with OpenVMS's shutdown command, I don't see the issue. It's only when I do a second boot cpu
from the sim> prompt. Maybe since the clock calibration work for system idling was already done upon the first boot - it should be skipped for subsequent restarts.
In my case there had been a power failure overnight, so I had booted an alternative system disk to perform disk maintenance (an $ analy/disk/repair
), then shut this down and wanted to resume normal operation from the normal system disk (a shutdown reboot won't work here).
Tony, what date might you be putting in at the VMS Date/Time prompt???
My system is not using a hobbyist license.
I don't get prompted for or need to enter the date or time as I keep it running with regular reboots/disk image file backups once a month (co-inciding with the monthly Microsoft update regime for the host running SIMH).
For reference, I've just entered Ctrl-E on the running instance from yesterday to check the clock stats. This is what they look like -
Simulation stopped, PC: 827ADB3A (MOVAL 827B48B0[R0],R5)
sim> sh clock
Minimum Host Sleep Time: 1 ms (1000Hz)
Host Clock Resolution: 1 ms
Execution Rate: 6,237,600 instructions/sec
Idling: Enabled
Time before Idling starts: 0 seconds
Calibrated Timer: CLK
Pre-Calibration Estimated Rate: 10,288,065
Calibration: Always
Asynchronous Clocks: Available
MicroVAX 3900 clock device is CLK
Calibrated Timer 0:
Running at: 100 Hz
Tick Size: 10 msecs
Ticks in current second: 39
Seconds Running: 76,116 (21:08:36 hours)
Calibration Opportunities: 76,116
Instruction Time: 523604069866
Real Time: 87926798
Virtual Time: 87926759
Next Interval: 961
Base Tick Delay: 64,908
Initial Insts Per Tick: 5,000
Current Insts Per Tick: 62,376
Initializations: 3
Ticks: 7,608,944
Total Ticks: 7,611,639
Peak Clock Skew: 13.909151 seconds fast
Ticks Acked: 7,608,824
Tick Time: 21:08:09.439999 hours
Total Tick Time: 21:08:36.379999 hours
Initialize Base Time: 11:16:45.701
Tick Start Time: 11:16:45.852
Wall Clock Time Now: 08:24:57.407
Catchup Tick Time: 08:25:07.937
Catchup Base Time: 11:16:58.497
Total Time Idled: 18:40:17.735 hours
sim> g
I might also add that if I choose the reboot option with OpenVMS's shutdown command, I don't see the issue. It's only when I do a second boot cpu from the sim> prompt. Maybe since the clock calibration work for system idling was already done upon the first boot - it should be skipped for subsequent restarts.
That suggestion was already part of my thinking. I'm exploring where/how to do that specific thing. I'm sure that part of the problem here is that shutdown followed by a subsequent new boot runs the POST diagnostics and this code runs from ROM. Memory references running from ROM are specifically designed to get the CPU to run at about 1 MIP since there are timing loops in the diagnostics which assume a particular instruction execution rate relative to wall clock time. Running in this speed bounded mode will certainly produce wonky results relative to what was previously observed by the calibration logic when the system was running before the shutdown. Re-initializing the calibration parameters on a new boot is a good suggestion and probably a good fix, BUT such a change will mask the overflow behaviors we see now and which may come back at any time depending on other load on the host system. Finding and fixing this has a higher priority than a fix that masks it. :-(
I believe I'm seeing the same problem on a couple of my systems (both Linux systems, Debian and Arch, building with GCC 10.2.1 and 12.2.0, on fast processors -- Intel i9-9900K and i5-10600K), with the vax, vax780, and vax8600 simulators. If I run the simh boot
command a second time without quitting and starting simh again, each input character takes a long time to appear (it varies...sometimes it takes >10 seconds and sometimes it takes only 1 second or less).
I did notice that if I don't set SET CPU IDLE=VMS
in my configuration, it appears to avoid (or at least hide) the problem.
I believe I'm seeing the same problem on a couple of my systems (both Linux systems, Debian and Arch, building with GCC 10.2.1 and 12.2.0, on fast processors -- Intel i9-9900K and i5-10600K), with the vax, vax780, and vax8600 simulators. If I run the simh
boot
command a second time without quitting and starting simh again, each input character takes a long time to appear (it varies...sometimes it takes >10 seconds and sometimes it takes only 1 second or less).I did notice that if I don't set
SET CPU IDLE=VMS
in my configuration, it appears to avoid (or at least hide) the problem.
I found the same thing, but with a 4th Gen i5-4300U. Noidle seems to fix it. Happens on all PDP11 too and with other simh variants.
Context
Idling and clock calibration for OpenVMS VAX V7.3 using SIMH microvax3900 seem to go awry when a reboot is done without exiting and restarting the simulator. Just doing a
@sys$system:shutdown
gets to the sim> prompt as expected. If I do aboot cpu
again intending to reboot OpenVMS, the console becomes unresponsive following the test output. Even a Ctrl-E (to return to the sim> prompt) isn't acted upon for a few minutes.Examining the clock status (I suspect clock recalibration) shows the following.
Should the instruction time be a large negative number?
No reponse from typing the
b
command to the >>> prompt, so I enter a fewCtrl-E
and wait.After a minute or so, I get
the output of "sim> SHOW VERSION" while running the simulator which is having the issue
See above. Compiled last week using Visual Studio 2015 under Windows 10 Pro 21H2 and all recent Microsoft updates are installed.
My SIMH .ini file has
and I'm using the internal compiled-in CPU microcode.
Happy to provide more details should you not be able to reproduce these symptoms.
Tony