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

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

Scenario:

   machine:  AT&T 6386E/33 WGS    24MB memory
   o/s:      AT&T UNIX System V/386 Release 3.2.2  (Maint update 2)
             Basic Networking installed.
   software: Wollongong WIN/TCP for 386 Streams, version 3.0
   board:    3Com 3C503, jumpers at default.  (using thinnet cabling)

   WIN/TCP installed fine with no error messages.  Installed using 
   interrupt 2 (instead of the default of 3) because interrupt 3 is
   in use by COM2.  There were no references to interrupt 2 in mdevice.

   The Release Notes state that the space.c file for 3c503 needed
   a change when thinnet cabling in use -- made requested change 
   and ran idbuild per instructions.  (The last access time of the
   space.c file did change during idbuild, so I assume the change
   was picked up properly.)

   
Problem:

   machine *hangs* with no messages, anywhere from immediately upon
   coming up to 5 minutes or so after coming up.  Booting a copy of
   the prior kernel runs into no such problems.

   certain operations can make it hang right away, e.g. trying to 
   telnet into a remote host.

   I have eliminated (I think) the card, network, and cabling as
   factors.  I run PC-NFS on the same card, machine, and cabling
   (and using the same parameters, e.g. interrupt 2 and DMA channel
   3) with no problems whatsoever.  WIN/TCP installation does not ask
   about DMA channel, but I'm guessing that it doesn't use DMA anyway,
   since the last column of the mdevice entry is -1.  (The default DMA
   channel for the card is 1, but the cartridge drive uses channel 1.
   I don't use the cartridge drive, but WIN/TCP hangs regardless.)

Ideas, anyone?  I'm going to try calling Wollongong and/or the 
distributor, but if anyone has any ideas, I'd love to hear them.

Followups to comp.unix.i386 (maybe tcp-ip would be a better choice,
but this is UNIX-specific...).

Thanks in advance.

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

cpcahil@virtech.uucp (Conor P. Cahill) (03/20/90)

In article <3642@infmx.UUCP> aland@infmx.UUCP (alan denney) writes:
>   WIN/TCP installed fine with no error messages.  Installed using 
>   interrupt 2 (instead of the default of 3) because interrupt 3 is
>   in use by COM2.  There were no references to interrupt 2 in mdevice.

Leave the card configured as is, but configure it as interrupt 9 in UNIX.

There is no interrupt 2 on an AT bus because that interrupt line is used
to cascade the second interrupt controller onto the first controller.
If you configure a card to use interrupt 2, it actually appears as interrupt
9 to the system.

MS-DOS software knows about this and does the remapping as appropriate. 

In UNIX you have to say it like it is.  


-- 
Conor P. Cahill            (703)430-9247        Virtual Technologies, Inc.,
uunet!virtech!cpcahil                           46030 Manekin Plaza, Suite 160
                                                Sterling, VA 22170 

lee@ulysses.att.com (Lee Begeja[cwc]) (03/21/90)

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