Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site spdcc.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!think!harvard!spdcc!dyer
From: dyer@spdcc.UUCP (Steve Dyer)
Newsgroups: net.unix-wizards
Subject: weirdness with DMF-32 sync, Qniverter, and uVAX-II...
Message-ID: <281@spdcc.UUCP>
Date: Wed, 23-Apr-86 01:00:26 EST
Article-I.D.: spdcc.281
Posted: Wed Apr 23 01:00:26 1986
Date-Received: Thu, 24-Apr-86 06:34:14 EST
Organization: S.P. Dyer Computer Consulting, Cambridge MA
Lines: 55
Keywords: adb -w /dev/kUmem; the twilight zone

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