On Wednesday, November 15, 2017 at 4:57 AM, Paul Hardy wrote: > I did some quick tests on my Raspberry Pi 3 SimH today. This was giving > repeatable 53 errors in the startup self-tests. > > 1) Switching to the KA655_test.bin made no difference. > 2) commenting out the nvram attach then prompted for language, and on > entering 4 (UK) then ran through the tests without failure. > 3) leaving attach in, but renaming away the existing nvram file, did exactly > the > same - no error. > 4) after (3), I exited to SimH with CTRL/E and exited SimH with quit. This > created a new nvram file. Restarting SimH gave same 53 error as original. > > Mark, I can send you the nvram file if you want? > > My Intel/Windows SimH doesn't seem to giving 53 errors at present, although > I'm sure I had them intermittently in the past.
Well, there's a significant difference between the Windows and Linux environments you're working in. The one affecting this behavior relates to the terminal emulator which is interacting with the boot ROM. On Linux it is likely the xterm (or related terminal window) you're running the simulator from. The earliest part of the ROM's startup logic looks in the NVR to see if It knows the terminal type AND language preference, if the terminal type seems reasonable (after a couple escape sequence probes), if it doesn't yet know the language preference it will prompt for it. In my Windows testing, in a command prompt window AND with a Console connected via PuTTY, I don't see a prompt for language preference. I do see such a prompt on Linux. In any case, attaching a new file to the NVR device before booting starts with an unknown terminal type and an unset language preference. With that knowledge, I've actually been able to see a failure here now. Thanks. Now, all I've got to do is reproduce the failure with enough detailed debugging enabled to understand the problem. Of course, since this is a timing issue, the slower behavior induced by the debug I/O will have Heisenberg effects, and the problem might not happen. :-) Thanks for the digging so far. - Mark > -----Original Message----- > From: Mark Pizzolato [mailto:[email protected]] > Sent: 13 November 2017 19:18 > To: Jeremy Begg <[email protected]>; [email protected] > Cc: 'Wilm Boerhout' <[email protected]>; [email protected] > Subject: RE: [Simh] Raspberry Pi 3 with tun/tap causes XQ to fail > > On Monday, November 13, 2017 at 2:04 AM, Jeremy Begg wrote: > > I am trying to get SIMH up and running on the ethernet interface of a > > Raspberry Pi 3. I have followed the intructions in > > 0readme_ethernet.txt, installing the libpcap-dev, bridge-utils and > > uml-utilities packages before building SIMH itself. I just ran 'make > > vax' and let it go, and the build to completion. > > > > My problem is that I just can't get networking going. To cut to the > > chase, if I run the simulator without first setting up the br0 and > > tap0 interfaces, and don't attempt to attach the XQ device, it works > > fine -- albeit without any networking (as expected). > > > > If I configure SIMH to attach XQ directly to the Pi's eth0 interface > > (without configuring br0/tap0) it works on the first run but fails > > selftest > > 53 on the next run. If I reboot the Pi and start the br0/tap0 > > interfaces and then run the simulator the VAX console fails selftest 53 > > again. > > Hmm... I've been trying to track down the 53 test failure, which I can't > reproduce here. > In general this should not have anything to do with the networking details > you've got setup, but there might be some influence. > > A little background explanation is warranted here. Long ago, when the > extended memory was added to the MicroVAX 3900 simulator (extending > from 64MB to 512MB), I had observed that boot ROM self test interval timer > test intermittently failed (1 out of 10 times). At the time, I attributed the > failures to competing load on the host system while the timer test was > running. To avoid potential problem reports from users the interval timer > tests were disabled with a patch to the ROM image. The resulting KA655x.bin > image was unmodified until this past January. At that time, the timer related > plumbing in simh was significantly reworked and it seemed like the ROM self > tests should now pass without the need to side step them. I re-enabled the > tests and, in my testing I've run many hundreds of tests without failure, > meanwhile there have been some reports like yours... :-( > > Since you've got a somewhat reproducible test 53 failure, will you please: > > 1) send me the configuration file you're loading > 2) send me the ka655x.bin or ka655.bin file you may be loading in your > configuration file > 3) explicitly load the attached ka655x.bin file prior to booting the > simulator in > your configuration file with: > sim> load -r ka655x_test.bin > sim> BOOT (or BOOT CPU) > 4) let me know if you still can observe the self test problems you had > previously seen. > > If the problem is completely solved, then I'll revise the packaged (and > internal) > ka655x.bin ROM image and these problems should be behind us. If the > problem persists, then I'll have to look for other ways to address it. > > Thanks. > > - Mark > _______________________________________________ Simh mailing list [email protected] http://mailman.trailing-edge.com/mailman/listinfo/simh
