Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!cs.utexas.edu!yale!mintaka!bloom-beacon!eru!luth!sunic!dkuug!freja.diku.dk!skinfaxe.diku.dk!thorinn
From: thorinn@skinfaxe.diku.dk (Lars Henrik Mathiesen)
Newsgroups: comp.unix.ultrix
Subject: Re: dmf (able dmz) controller on 780
Message-ID: <1990May8.132653.8121@diku.dk>
Date: 8 May 90 13:26:53 GMT
References: <469@sheoak.bcae.oz>
Sender: news@diku.dk (The Netnews System)
Organization: Department Of Computer Science, University Of Copenhagen
Lines: 31

brucer@sheoak.bcae (Bruce Rivendell) writes:
>We have just upgraded an 11/780 from VMS to ULTRIX, and are having
>trouble with the Able VMZ/32N controller (used to be OK with VMS).
>I changed the config file entries to 4 similar to:

>device   dmf0   at  uba0  csrXXXXXXX  flags 0xff  vector dmfrint  dmfxint

>without being sure that this was exactly the right entry. 
>At startup this doesn't produce any errors, but when we try to connect
>via our micom is gets nowhere after the CONNECTED message.

This is what we use -- unchanged from 4.2BSD through Mt. Xinu MORE/bsd
12/89 release. Are you sure that you have 32 lines on your VMZ/32N?
Ours only has 16 according to the manual.

# 1 VMZ/32N emulating 2 DMF/32s
# We do not need the carrier even though the vmz has it on all 16 lines
device          dmf2    at uba? csr 0160540      flags 0xff
        vector dmfsrint dmfsxint dmfdaint dmfdbint dmfrint dmfxint dmflint
device          dmf3    at uba? csr 0160600      flags 0xff
        vector dmfsrint dmfsxint dmfdaint dmfdbint dmfrint dmfxint dmflint

I think that the "flags 0xff" means that the driver should not look at
the carrier bit in the interface, but just act as if it is always on
(one bit for each line).
The many vectors are because our kernel also supports the line printer
and synchronous line interfaces (with dual buffer DMA).

--
Lars Mathiesen, DIKU, U of Copenhagen, Denmark      [uunet!]mcsun!diku!thorinn
Institute of Datalogy -- we're scientists, not engineers.      thorinn@diku.dk