QBone PDP-11/23 Mystery

[Jay Jaeger]

Background:  I have two Qbone Duals.  Both have been tested in a MicroVAX II providing MSCP disk support for MicroVax QuasiJarus (sp?) NetBSD 4.3 and reading data from a TK70 tape drive.  That NetBSD OS is not entirely stable, but I don't think that has anything to do with the QBones.  Both Qbones also do not interfere with booting and running VMS from a secondary MSCP controller (with a Fujitsu SMD drive no less.)

In my MicroPDP-11/23 it is a very different story.   All qbone tests were run with -aw 22 .

1) With NO Qbone in place (i.e., with an M9047 grant card in place of where the Qbone might be), I can start to boot DEC V7m from the RQDX1, but it will not complete the boot because there is no suitable clock - this is expected behavior.  (If the BEVENT clock is enabled, it dies with a panic as it receives an interrupt for which it is not yet prepared.)   I can boot and run RT11 from a real RL02 drive attached to an RLV12 controller. 

So that should elimnate CPU issues, most possible bus issues, RLV12 issues, RQDX1 issues, memory issues, ths disk image -- a whole bunch of things.

With *either* Qbone in place things change:

2) If I enable the device KW11 in the QBone, V7m boots and runs from the RQDX1

3) Even if the rl device is disabled on the QBone, I cannot boot from the real RLV12/RL02.  The drive light blinks, so the request is getting through, but no data shows up, and if I run the dl.lst program at 010000 it acts as though the drive is not ready.   If I use "break" to interrupt dl.lst, it halts at location 1006x/10070 and if I look at the RLV12 CSR, it is 112201 (Error, Header Not found (HNF), Drive 00, Controller Ready (CRDY), Noop/maint mode 000, Drive ready (DRDY).

4) If I try and boot the RT11V5.4 image from the boot monitor, it crashes -- location 177576 displayed, or just hangs.

5) If I remove the RLV12, then a Qbone RL02 device I can boot XXDP from the qbone image but a boot of a tested RT11 image of the aforementioned RL02 pack just hangs or dies.  (That image was also tested under SimH - was downloaded from the RL02 pack via PDP11GUI).

6) If I boot from a non-existent file (so that the Qbone creates one) I get "no boot block on volume".  This occurs with:  RLV12 removed booting emulated RL, or using emulated RX01 or RX02.   (I only have the one real RL02 pack).

The backplane is a H9278A (Q22 with CD slots on the right hand of the first three slots) with terminating resistor SIPs in place.

The arrangement is:

M8186 KDF11-A rev C CPU                   CD Empty

M8578 MRV11 Diag/Boot Roms          CD Empty

M8059-KC 128Kw MSV11-L                  CD Empty

M9047 Bus Grant or Qbone                   M9047 Bus Grant or QBone 

M9047 Bus Grant                                     M8047 MXV11-A Serial port (RAM, ROM Disabled)

                                      M8061 RLV12 (quad high)

                                      M8639 RQDX1 (quad high) [MUST BE LAST]

                                                       EMPTY

(I tried both of the Qbone duals in a couple of different slots.)

My *guess* is that this has something to do with differences in how interrupts or bus transactions are handled between the MicroVAX CPUs and the KDF11-AA (Rev C is supposed to be Q22 compatible).  I have no explanation or theories at all for why the RQDX1 works fine with the QBone in place, but not the RLV12.

I am pretty well puzzled about what to try next -- though I do keep thinking of things - like trying the rx01/rx02 just today. 

JRJ

[Jerry Weiss]

Hi,

I can't duplicate the exact environment you have, but I have dealt with flakey Q-Bus setups. When I get a problem like this, i.e. the parts are good in some OS'es, but not others,  I would usually do something like the following.

I minimize the number of controllers.  

        Do you need the MXV11A?  Can you just run serial and KWV11 from the Qbone?  

I try to change things that shouldn't make a difference.  

        Put the CPU, Memory and RLV12 close together, usually the memory before the RLV12.   You may need to remove RLV12 W1 and W2 if a CD slot is used.

        Try a manual bootstrap for the RL02.  Make sure all interrupts are blocked before hitting 1000g.   Some bootstraps do not do this early in the routine and the BEVENT interrupt compromises the bootstrap. A reset clears the PSW.

FYI - I believe XXDP+ does not require interrupts to run.

Things to check, just in case.

        Make sure that both the MSV-11 and RLV12 are set for 22 (or 18) bits.

I know that this may seem to be throwing things against a wall.  But something may pop up that will help focus your diagnosis further.

    Good Luck - Jerry

[Jay Jaeger]

"Do you need the MXV11A?  Can you just run serial and KWV11 from the Qbone?  "

"Put the CPU, Memory and RLV12 close together, usually the memory before the RLV12.   You may need to remove RLV12 W1 and W2 if a CD slot is used.

        Try a manual bootstrap for the RL02.  Make sure all interrupts are blocked before hitting 1000g.   Some bootstraps do not do this early in the routine and the BEVENT interrupt compromises the bootstrap. A reset clears the PSW."

" FYI - I believe XXDP+ does not require interrupts to run."

" Make sure that both the MSV-11 and RLV12 are set for 22 (or 18) bits."

On Sunday, July 13, 2025 at 11:31:28 PM UTC-5 j...@ieee.org wrote:

Thanks for taking the time to reply.  First, to answer your questions/suggestions:

Hi,

I can't duplicate the exact environment you have, but I have dealt with flakey Q-Bus setups. When I get a problem like this, i.e. the parts are good in some OS'es, but not others,  I would usually do something like the following.

I minimize the number of controllers.  

        Do you need the MXV11A?  Can you just run serial and KWV11 from the Qbone?  

I don't really want the system forever dependent upon the QBone.  So, yes, I want to leave some serial port in the system.  (I could also switch to a DLV11E if I had to).  The RLV12 is a bit of a different situation, though, because I only have the on pack for it, so I plan to eventually remove it.

 

I try to change things that shouldn't make a difference.  

        Put the CPU, Memory and RLV12 close together, usually the memory before the RLV12.   You may need to remove RLV12 W1 and W2 if a CD slot is used.

        Try a manual bootstrap for the RL02.  Make sure all interrupts are blocked before hitting 1000g.   Some bootstraps do not do this early in the routine and the BEVENT interrupt compromises the bootstrap. A reset clears the PSW.

The CPU and memory are already at the top.  The RLV12 is 2nd to last.  But remember, this thing works just fine without the QBone.

BEVENT is disabled (the little dip switch is on, grounding that pin on the backplane)  because v7m cannot tolerate it for the very reasons you point out.  I use the KW11 emulation in the QBone for a clock when I want to run V7m, though eventually I think I will build a card to just be a KW11.

FYI - I believe XXDP+ does not require interrupts to run.

Things to check, just in case.

        Make sure that both the MSV-11 and RLV12 are set for 22 (or 18) bits.

That is my understanding as well, which was a factor in my suspicion regarding interrupt issues.

The RLV12 was already set for 22 bits.  The MSV11-L memory was not, but is now (added jumper R-T), but that had no apparent effect.  (Remembering again that this system ran RT11 from a real RL02 just fine before I put in the QBone).  The MRV11-D ROM board was also set for 18 bits, but is now set for 22 bits.  It really should not matter as currently I am not using the QBone to extend memory except when I run v7m - which happily sees 4MB.   I also changed the MRV11-D to not respond (bus timeout) on a DATO (update memory) request as it is all ROM - no effect on these issues.  I also changed the PCR for the MR11-D to its default of 1777036 from 1777000 just because it made sense to do so.  

I know that this may seem to be throwing things against a wall.  But something may pop up that will help focus your diagnosis further.

Hey, I was absolutely in "brainstorming mode" so I appreciated the ideas. 

    Good Luck - Jerry

NOW, for some NEW data points (and probably the resolution).

The QBone RSX11m V4.1 image boots and seems to run OK in the same configuration that was misbehaving.

I ran the CPU diagnostic somewhere along the line (CJKDBD0) under XXDP and it failed.  So I swapped CPU cards -- no changes - same stuff still works or fails.  So I dug into the failure.  It was failing on test 376 (thanks, DEC for putting the test number in *r2 ;) ).  That test sets the CPU priority high, sets up the console output for an interrupt, and then lowers the CPU priority - and expects  that the interrupt will occur *immediately* thereafter.  If it doesn't, it TRAPs (gee, an error message might have been nice, though  ;) )

So, a light bult went off with respect to interrupts - I could see where the Qbone might take longer to pass along the request for the interrupt, so just now I swapped the positions of the Qbone and the MXV11, and voila, the diagnostic passes.  (I also rain memory tests from the Qbone along the way - all clean).

THAT SAME CHANGE ALSO FIXED UP RT11 running from that same RL02 image I made of my own pack Qbone.  I expect that it very well may clear up the issue with running the RLV12 with the Qbone in place as well - but it also might not.

My working theory is that the Qbone takes somewhat longer to pass along the request from down-bus (where the MXV11-CA was (with its RAM disabled, of course) for the interrupt.  That getting the Qbone out of that path cured the diagnostic was pretty much what I expected.  That it cured the issues with RT11 on the Qbone came as a pleasant surprise.  

I will see later to day what the RLV12 thinks of this arrangement - it could very easy be suffering from the same issue as the MXV11-CA was when it was sitting behind the Qbone on the bus.  My working theory is that the RQDX1 and associated software are not as picky for some reason or other, which is why it has been happy all along.

JRJ

[Jay Jaeger]

OK, probably the final installment in this saga.

I installed the real RLV12 in its location, in the second last slot.  RT-11 now buts and runs from the real RL02 disk - but ONLY if I use the real boot roms (this is the MXV11-B2 boot rom set installed in the MRV11 board).  If I try to use the Qbone dl.lst, it hangs, looping at location 10064, more or less.  I have not tried the much simpler "usual" DEC boot code but I am guessing that would work fine as well - I suspect that dl.lst is doing too much checking for its own good.  ;)  The *emulated* RL/RK/RY boot fine using their respective xx.lst programs, but not the real RLV12.

I can also now boot an RK emulation pack and RY emulation floppy, which did not work before.

So the conculsion I have come to is that for some reason RT-11 is sensitive to the same kind of interrupt issue as the diagnostic.

JRJ

[Jay Jaeger]

Well -- one more post on this.  After I got the Micro-11 running, I went back to one of my Micro VAXen to read some TKxx tapes.

I discovered that the Qbone *was* causing some problems on the MicroVAX too.  I hadn't noticed it under NetBSD 4.3 quasijaurus (sp?) other than some peculiar instability, which I had blamed on the OS itself, but under VMS I sure did notice a difference - and it had been stable aside from a bad SMD disk drive disk block here and there.  With the QBone in the bus before the DELQA and the Emulex MSCP/SMD controller, the Ethernet went up and down like a yoyo, and I had some very peculiar disk verification situations where VMS was upset about the SMD disk.  I moved the QBone to the end of the bus chain and all was stable again.

The instabilities in NetBSD4.3 had messages that related to missing interrupts on the DELQA and sometimes what it seemed to be describing as duplicate block I/O completions on the emulated disk controller.  It tended to crash, too, after a successful TKxx tape was read in.  I have not gone back and run NetBSD4.3 since I moved the QBone board to see if that made a difference there, but I expect it would.

JRJ