[comp.bugs.4bsd] Funny dmf-32 behavior

dinh@sm.unisys.com (Dinh Le) (07/29/88)

Dear wizards,

	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.

	However, when I change the flags to 0xff, our VAX was not able
to communicate with any terminals hook up to all 16 dmf-32 ports (no
login prompts what so ever).  Doing 'ps agux' reveals that all ports 
are up and running (???).

root       211  0.0  0.1   28    3 A0 I     0:00 - G ttyA0 (getty)
root       210  0.0  0.1   28    3 A1 I     0:00 - G ttyA1 (getty)
root       209  0.0  0.1   28    3 A2 I     0:00 - G ttyA2 (getty)
root       213  0.0  0.1   28    3 A3 I     0:00 - G ttyA3 (getty)
root       208  0.0  0.1   28    3 A4 I     0:00 - G ttyA4 (getty)
root       214  0.0  0.1   28    3 A5 I     0:00 - G ttyA5 (getty)
root       212  0.0  0.2   28    7 A6 I     0:00 - G ttyA6 (getty)
root       218  0.0  0.1   28    3 A7 I     0:00 - G ttyA7 (getty)
root       190  0.0  0.2   28    6 B0 I     0:00 - G ttyB0 (getty)
root       223  0.0  0.1   28    3 B1 I     0:00 - G ttyB1 (getty)
root       221  0.0  0.1   28    3 B2 I     0:00 - G ttyB2 (getty)
root       220  0.0  0.2   28    4 B3 I     0:00 - G ttyB3 (getty)
root       217  0.0  0.1   28    3 B4 I     0:00 - G ttyB4 (getty)
root       189  0.0  0.2   28    8 B5 I     0:00 - G ttyB5 (getty)
root       185  0.0  0.2   28    5 B6 I     0:00 - G ttyB6 (getty)
root       191  0.0  0.2   28    8 B7 I     0:00 - G ttyB7 (getty)

	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 ??

	Has anyone ever run into this kind of problems?  Appreciate any
pointers.

				'Dinh Le
				ARPA: dinh@sm.unisys.com
				UUCP: sdcrdcf!dinh

gordon@prls.UUCP (Gordon Vickers) (07/29/88)

In article <sEhS+rC@far-side.sm.unisys.com> dinh@sm.unisys.com (Dinh Le) writes:
->Dear wizards,
->	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.
->	However, when I change the flags to 0xff, our VAX was not able
->to communicate with any terminals hook up to all 16 dmf-32 ports (no
->login prompts what so ever).  Doing 'ps agux' reveals that all ports 
->are up and running (???).
->
->				'Dinh Le
->				ARPA: dinh@sm.unisys.com
->				UUCP: sdcrdcf!dinh

    I'm certainly no wizzard but, I too have a VAX 11/750 with a dmf32.
    Though I don't run 4.3bsd, I do run its' closest reletive, Ultrix.
       With-in the last year, I have built kernals using both 0xfc and
    0xff flags but have not experianced your problem.  The only differance
    between these two flags (supposedly anyway), is 0xfc specifies that
    ports zero and one on the device will use modem control, 0xff =
    no modem control.
       I know this doesn't really help you, but thought I'd pass it along.
    Could something else have changed between the test ?

 Gordon P. Vickers
 {mips, pyramid, philabs}!prls!gordon

david@ms.uky.edu (David Herron -- One of the vertebrae) (08/01/88)

aaaaahh... dmf-32's ... one of my faa-aavo-orite serial boards! :-)


In article <sEhS+rC@far-side.sm.unisys.com> dinh@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@ms.uky.edu>
<---- ska: David le casse\*'      {rutgers,uunet}!ukma!david, david@UKMA.BITNET
<----
<---- Looking forward to a particularly blatant, talkative and period bikini ...

chris@mimsy.UUCP (Chris Torek) (08/01/88)

[Followups have been redirected to comp.unix.wizards only]

>In article <sEhS+rC@far-side.sm.unisys.com> dinh@sm.unisys.com (Dinh Le)
>writes:
>>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

(Why are both csr addresses set to 0160340?  Presumably the second dmf
is at one of the standard alternative addresses, so this is not
critical, but it is rather sloppy.  Anyway...)

>>[after changing `flags' and rebuilding the kernel, things broke]

In article <10103@g.ms.uky.edu> david@ms.uky.edu (David Herron --
One of the vertebrae) writes:
[ I thought Heron were family Ardeidae, not Vertebrae :-) ]

>... 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(?).

I have no idea where the enables are, but:

The DMF-32 provides four (!) interfaces, namely, a DR-11-like parallel
port, a synchronous port, a Centronics-compatible line-printer port,
and an 8-line asynchronous `port' (really 8 ports).  Of those eight
async lines, only two have modem control; this is an utter botch, but I
suppose they ran out of space on the board.  The lack of modem control
on the 6 lines explains the `flags 0xfc'; however, the firmware on the
DMF-32 pretends that the modem signals are always active, so the flags
are in fact unnecessary.  (I think.)

At any rate, the DMF register set is defined such that any (or even
all) of those interfaces may be omitted.  This is in fact useful, since
to support all those interfaces, the DMF-32 uses up 7 interrupt vectors
(out of 128); if only the async port is present, a clever
autoconfiguration sequence can adjust things so as to take only 2.
(This is more significant than it might seem; while floor(128/7)
indicates that you could run 18 DMF-32s, if you have other devices
you may have specific chunks of the vector space preallocated and
thus not usable.)

All of this is merely background information, intended to support
Dave Herron's description.  The probe code in the DMF driver tests
each of the bits for `interface present', and for each that is,
prints its name.  Hence, with everything:

	dmf0: parallel printer synch asynch.
	dmf0 at uba0 csr 160340 vec 740, ipl 15

If you have (e.g.) an Emulex or Able emulator with only the async
interface:

	dmf0: asynch.
	dmf0 at uba0 csr 160340 vec 764, ipl 15

But if you see the device as

	dmf0: .
	dmf0 at uba0 csr 160340 vec 740, ipl 15

then nothing is enabled on it, and it is not going to be useful.
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain:	chris@mimsy.umd.edu	Path:	uunet!mimsy!chris