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!gordondavid@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