Funny dmf-32 behavior
David Herron -- One of the vertebrae
david at ms.uky.edu
Mon Aug 1 14:04:19 AEST 1988
aaaaahh... dmf-32's ... one of my faa-aavo-orite serial boards! :-)
In article <sEhS+rC at far-side.sm.unisys.com> dinh at sm.unisys.com (Dinh Le) writes:
> When the dmf-32 entry in the configuration file for our VAX-750
>running 4.3bsd is configured as:
>
>device dmf0 at uba? csr 0160340 flags 0xfc
> vector dmfsrint dmfsxint dmfdaint dmfdbint dmfrint dmfxint dmflint
>device dmf1 at uba? csr 0160340 flags 0xfc
> vector dmfsrint dmfsxint dmfdaint dmfdbint dmfrint dmfxint dmflint
>
>it was able to communicate with 12 terminals hook up to the 12 appropriate
>dmf-32 ports.
Either configuration should be fine -- as reported by the person
running Ultrix. The only difference is how carrier detect
is interpreted. The real problem is at the end of this posting
however and has nothing to do with carrier detect.
>root 208 0.0 0.1 28 3 A4 I 0:00 - G ttyA4 (getty)
^^- On our dh's this would
indicate something wrong
with the device on the port
which was making the carrier
detect to always be "high".
Don't remember if this is also
true for dmf's, it's been a couple
of years since I dealt with one..
> One noticable difference between the kernel that run with the 0xfc
>flags from the one that run with the 0xff flags was one booting message:
>
> 0xfc has
>.asynch
> while 0xff has just
>.
> before dmf? at uba? csr 160??? vec ???, ipl ??
I hope "dmf?" has the ? replaced with a number -- it should be dmf0
or dmf1 or so on depending on which one is being configured.
But the real information is the difference between ".asynch" and ".".
The driver has a little section of code in the probe routine which
looks in the device registers to see which of the sub-devices are "active".
As I recall the active sub-devices are selected by DIP switches on the
distribution panel though maybe they're on the board(?).
--
<---- David Herron -- The E-Mail guy <david at ms.uky.edu>
<---- ska: David le casse\*' {rutgers,uunet}!ukma!david, david at UKMA.BITNET
<----
<---- Looking forward to a particularly blatant, talkative and period bikini ...
More information about the Comp.unix.questions
mailing list