dyer@spdcc.UUCP (Steve Dyer) (04/23/86)
I am not really expecting anyone to have an answer for this at hand,
though I hope it might tickle someone's memory, in case they've ever
seen anything like this before. I'm aware that this combination of
hardware and software is pretty new and immature, and problems might
be expected. I'll try to be brief (unlike my debugging session this
evening...)
1.) We've got a DMF-32 sync driver running successfully on a 750.
I'm not sure of its pedigree, but I think it's the sync driver
which has been passed around 4.2 sites in the past few years.
2.) In the process of upgrading the facilities, we plan to continue to
run the DMF-32 on a MicroVAX-II, hooked up to the other end of an
Able Qniverter. A TM-11 tape controller, for instance, has been working
just fine on the UNIBUS side of the Qniverter.
3.) The DMF sync driver has a number of busy loops in the open and close
routines which have always managed to break out within milli- or micro-
seconds on the 750. However, these bad coding practices have turned
into monsters on the MicroVAX! Briefly, the code fragments look something
like this:
dmfsaddr->dmfsmr = DMF_MR; /* 0x80 master reset */
while(dmfsaddr->dmfsmr & DMF_MR) DELAY(10);
The "master reset" bit is held high until the DMF sync line has finished
resetting. On the uVAX, the bit is never reset. We also tried variations
such as varying the arg to the DELAY macro (though who knows why they
bothered with DELAY in the 1st place) and explicitly repeating the
assignment within the body of the loop, which according to the DMF
manual if OK to do. Nothing matters. I note that the code loop does
contain an explicit reference to the device register; i.e., it hasn't
optimized into oblivion by being placed in a register.
4.) Replacing the busy loop with a sleep(&lbolt, PZERO+1) allowed us to
continue examining the world. Bizarrely, performing the following
command:
% adm -w /dev/kUmem
0x08xxxxx?w 0x80 (where 0x08xxxxx is the mapped "UNIBUS" address
of the DMF sync misc register above)
resets the device address, so that 0x80 is no longer held high.
In other words, if I get adb to do what the loop itself is doing,
the reset works fine, and the open code continues on until it hits the
*next* identical code fragment (which I can get by by repeating the
write.)
5.) Examination of the mem.c code for /dev/kUmem indicates that it's doing
nothing unusual; just a series of 16-bit writes, nothing much different
from the code generated for the assignment above, yet the adb works,
and the driver code doesn't!
Is this some weirdness with read/modify/write instructions which is
being unmasked by the use of a Qniverter? Anyone care (dare) to comment?
--
Steve Dyer
dyer@harvard.HARVARD.EDU
{bbncca,bbnccv,harvard,ima,ihnp4}!spdcc!dyerdyer@harvard.UUCP (Steve Dyer) (05/05/86)
In article <281@spdcc.UUCP>, dyer@spdcc.UUCP (Steve Dyer) writes: > 3.) The DMF sync driver has a number of busy loops in the open and close > routines which have always managed to break out within milli- or micro- > seconds on the 750. However, these bad coding practices have turned > into monsters on the MicroVAX! Briefly, the code fragments look something > like this: > dmfsaddr->dmfsmr = DMF_MR; /* 0x80 master reset */ > while(dmfsaddr->dmfsmr & DMF_MR) DELAY(10); > The "master reset" bit is held high until the DMF sync line has finished > resetting. On the uVAX, the bit is never reset. > % adm -w /dev/kUmem > 0x08xxxxx?w 0x80 (where 0x08xxxxx is the mapped "UNIBUS" address > of the DMF sync misc register above) > resets the device address, so that 0x80 is no longer held high. > Just in case anyone was losing sleep over this, and to clear the name of Able, the maker of the Qniverter II, I should mention that the problem ultimately was hardware--Unibus DMA boards placed in slots with NPR jumpers, and other non-DMA boards in those with the NPR jumpers removed. (Hey, I'm just the software person.) The Qniverter seems to have an isolating effect; placed after all the Qbus devices, it allowed for weird behavior as above, something you'd probably never see on a true UNIBUS machine. Placed before them, the Qbus, naturally, gets hung. As of right now, the Qniverter II is working fine with our UNIBUS peripherals on the mVAX-II. -- /Steve Dyer dyer@harvard.harvard.edu harvard!dyer