rpinder@phad.hsc.usc.edu (Rich Pinder) (04/02/91)
(sorry for the earlier version of this question - while picking up a copy
of what I had originally mailed to the sco-list, I mistakingly
'wrote-file' rather than 'wrote-region', so I put up the whole bloody
thing. Again, sorry!)
I've been having problems getting tcp/ip to work. I'd like to know
if anyone has had similar problems. Heres the setup:
NCR S486/MC33 microchannel 486 server
WD EtherCard Plus/A microchannel 16 bit card
SCO 3.2.2
card params:
irq 10
I/O base 280
RAM buffer 16k
Base Add D8000
Card passes the WD diagnostics as setup. We've deleted and installed the
drivers and mkdev'd tcp several times to verify all our settings. Tested
on a wide area net as well as a single run between this machine and a pc -
no luck. Right after installation, pinging localhost works fine, and
netstat looks good. Then, over night (with no other processes running) I
run netstat -i again, and nothing. (command actually hangs). And pinging
localhost does not work.
thanks for any ideas.
Rich Pinder
USC School of Medicine
(213) 342-1640
rpinder@usc.edu
||||||||||||||||||||||||||||||||||||||||||||||||||swan@pws.bulL.com (Joel Swan) (04/02/91)
rpinder@phad.hsc.usc.edu (Rich Pinder) writes: >Card passes the WD diagnostics as setup. We've deleted and installed the >drivers and mkdev'd tcp several times to verify all our settings. Tested >on a wide area net as well as a single run between this machine and a pc - >no luck. Right after installation, pinging localhost works fine, and >netstat looks good. Then, over night (with no other processes running) I >run netstat -i again, and nothing. (command actually hangs). And pinging >localhost does not work. We ran into a similiar problem awhile back. You should contact SCO to get the latest WD driver. The version you have sounds like a problem that was fixed a few months ago. Descriptions of SCO's fixes to the driver follow: Essentially, both are software workarounds for hardware problems. In the first, under very heavy receive load, the WD card can lose an xmit interrupt. Since there is only a single xmit buffer, the loss of this interrupt hangs the xmit side of the driver. We put in a watchdog timer to check for the condition, reset the board, and get things going again. The second problem was that in very rare conditions, the board can put a bogus value into the nxtpg field tof the packet header it delivers to the driver. The driver contains a validity check on this field, but the test was insufficient, and even if it did find something wrong, the recovery code was incorrect. Hope it works for you. Good luck. -- Joel M. Swan Bull Worldwide Information Systems, Inc. swan@pws.bull.com 900 Middlesex Turnpike - Building 2 phone (508) 294-7125 Billerica, MA 01821 fax (508) 294-7419