[comp.unix.i386] Probs with WIN/TCP for 386 Streams on AT&T V/386 3.2.2

aland@infmx.UUCP (Dr. Scump) (03/21/90)

In article <12706@ulysses.att.com> lee@ulysses.att.com (Lee Begeja[cwc]) writes:
>
>I am not familiar with the WIN/TCP software but your use of interrupt
>2 raises a flag with me.  Since the interrupt 2 slot is actually wired to
>interrupt 9 on the bus the software must correctly identify the interrupt...
>Here is where I get hazy and maybe someone with more familiarity could
>explain the whole situation better...
>
>So check the mdevice file and see if the software is set to use interrupt 2
>and if it is change that to interrupt 9 .
>
>At worst it couldn't hurt...
>Lee Begeja  AT&T Bell Labs  ulysses!lee


Conor Cahill was also kind enough to point this out.  I was somewhat 
aware of this, but when I discovered that it worked to reference it
as interrupt 2 to PC-NFS, I figured it was a card issue.  Conor
explained that DOS is intelligent enough to re-map the interrupt but
UNIX isn't (very roughly paraphrased; apologies to Conor if I blew it).

The thing that concerns me is that the card is an 8-bit card, and
as far as I know, the edge contact for INT 9 is in the 16-bit portion.
This may be a non-issue, but I'm stumped otherwise.  Changing the
interrupt field in mdevice from 2 to 9 didn't help.  (3COM does list
interrupt 9 in their "supported interrupt" table for AT-bus, but they 
say no more about it elsewhere). Per Wollongong's
Tech Support, I tried re-installing and specifying interrupt 9, but
the idbuild failed because they include interrupt vectors for int 2
thru 5 only.  The vectors for interrupts 2-5 are 0x10, 0x20, 0x40, and
0x80, respectively, but I'm not confident that the pattern holds for
higher interrupts.  Anybody know fer sure?  BTW, ints 3 thru 5 are 
already used: 3 for COM2, 4 for COM1, and 5 for the streaming tape 
drive.  I could disable COM2 or COM1, but then I'd have to give up 
alternate or remote console operation, both of which I need.  Yuck.

Anyway, Wollongong support is looking into this, but in the meantime,
does anybody else have any bright ideas?  This is version 3.0.1 of
WIN/TCP for 386 Streams, which I have just learned is somewhat old.
The distributor was supposed to ship the latest version, and they're
looking into that as well.

As an alternative, does anybody know of any 16-bit ethernet cards
that are supported by both Wollongong and Sun PC-NFS?  It would
be great if the AT&T cards worked with PC-NFS, but they don't, so
I'm stuck.  (Or, if the WD8003E can work with other available
interrupts).

Another related question: since the last column in the sdevice entries
for Wollongong's card drivers all have -1, is it safe to assume that
WIN/TCP does not use DMA on these cards?  I have enough DMA problems
as it is (can you say "DMAABLEBUF" and "DMAEXCL", boys and girls?)

--
Alan S. Denney # Informix # aland@informix.com # {pyramid|uunet}!infmx!aland

 "The driver says, 'One more cup of coffee and I'll be all right...'
  'Pop a Bennie, another Bennie'..."                - The Bobs, "Bus Plunge"

nelson@sun.soe.clarkson.edu (Russ Nelson) (03/22/90)

In article <3665@infmx.UUCP> aland@infmx.UUCP (Dr. Scump) writes:

   As an alternative, does anybody know of any 16-bit ethernet cards
   that are supported by both Wollongong and Sun PC-NFS?  It would
   be great if the AT&T cards worked with PC-NFS, but they don't, so
   I'm stuck.  (Or, if the WD8003E can work with other available
   interrupts).

You may wish to use the AT&T driver in the upcoming release 6.x of the
packet drivers, along with Geoff's packet driver support for PC-NFS.
Release 6.x will be out by the end of March...
-russ
--
--russ (nelson@clutx [.bitnet | .clarkson.edu])  Russ.Nelson@$315.268.6667
Violence never solves problems, it just changes them into more subtle problems