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