[Simh] Raspberry Pi 3 with tun/tap causes XQ to fail

[Mark Pizzolato]

On Tuesday, November 14, 2017 at 12:10 AM, Jeremy Begg wrote:
> >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.
> 
> I think I have found the cause.  Yesterday Wilm pointed out that his
> configuration did NOT require the tap0 interface to be assigned an IP
> address by the host system, and Steve Mansfield-Device's blog is the
> only place I've found that suggested this requirement.
> 
> It occurred to me after I reported it was working that I had in fact made
> TWO changes: the successful boot did NOT connect the NVR.  Trying again
> just
> now, with no IP address assigned to "tap0" and no NVR configured, the VAX
> boots quite happily with a working network interface.
> 
> Mark, thank you for the detailed explanation about the failed selftest, but
> I fear it's in vain.  I suspect it's just a corrupt NVR file instead.  So I
> won't try the alternative ka655x.bin (unless you still think it might be
> helpful to do so).

The goal is to remove the possibility of having any self test errors.   Not having
an NVR attached merely starts things with a zeroed NVR.  This is a completely 
normal case and is exactly how I tested on my systems successfully hundreds 
of times.

PLEASE see if you can reproduce a failure and then see if the different ROM 
Image fixes it by following the steps I listed below.

Thanks.

- Mark


> >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