pdb@sei.cmu.edu (Patrick Barron) (07/14/88)
I'm trying to run the CMU/Tektronix TCP/IP package (V6.3) on MicroVAXen with DEQNAs. On most of them it starts and runs fine. However, on a couple of them, the IPACP starts, and then exits right away with "XE read error, RC=00000A00". Going through the sources reveals that return code to be equivalent to XM$M_STS_ACTIVE|XM$M_STS_TIMO. The XM$M_STS_ACTIVE is OK; the XM$M_STS_TIMO is what it is objecting to. The I/O user's guide says that this return means something like "a DEUNA/DEQNA timeout has occurred". I'm not sure what that means, and I can't find any further explaination. What is timing out? Is my hardware broken? Thanks, --Pat.
cetron@utah-cs.UUCP (Edward J Cetron) (07/14/88)
In article <2946@ci.sei.cmu.edu> pdb@sei.cmu.edu (Patrick Barron) writes: > >I'm trying to run the CMU/Tektronix TCP/IP package (V6.3) on MicroVAXen >with DEQNAs. On most of them it starts and runs fine. However, on >a couple of them, the IPACP starts, and then exits right away with >"XE read error, RC=00000A00". > Known error, change all occurences of %0FF to %0FD in order to mask out the timout bit. This most often happens on LAVC clusters. This timeout bit is a hold over from the DMC code from which it was derive (notice the XM$...). -ed cetron cetron@cs.utah.edu
info-vax-RELAY@KL.SRI.COM (07/21/88)
In article <2946@ci.sei.cmu.edu>sei!pdb@pt.cs.cmu.edu (Patrick Barron) writes: >I'm trying to run the CMU/Tektronix TCP/IP package (V6.3) on MicroVAXen >with DEQNAs. On most of them it starts and runs fine. However, on >a couple of them, the IPACP starts, and then exits right away with >"XE read error, RC=00000A00". >Going through the sources reveals that return code to be equivalent >to XM$M_STS_ACTIVE|XM$M_STS_TIMO. The XM$M_STS_ACTIVE is OK; the >XM$M_STS_TIMO is what it is objecting to. >The I/O user's guide says that this return means something like "a >DEUNA/DEQNA timeout has occurred". I'm not sure what that means, and >I can't find any further explaination. What is timing out? Is my >hardware broken? In a word, probably! Your problems with the DEQNA's are most likely due to their not having a required FCO. Without the FCO, DEQNA's are brain dead, with the ECO they are merely brain damaged. DEQNA's at revision level D or earlier will need FCO DEQNA-R-001. DEQNA,s tend to fail under heavy load. The FCO upgrades them somewhat but does not correct the problem completely. DEC's new Ethernet controller for the Q-BUS, the DELQA, is supposed to work much better There is a mailing list for CMU/TEK TCP/IP users. The list is cmu-tek-tcp@c.cs.cmu.edu. The request address is cmu-tek-tcp-request....
gil@limbic.UUCP (Gil Kloepfer Jr.) (07/29/88)
In article <8807271158.AA05174@ucbvax.berkeley.edu> dragon@NSCVAX.PRINCETON.EDU writes: |>>The I/O user's guide says that this return means something like "a |>>DEUNA/DEQNA timeout has occurred". I'm not sure what that means, and |>>I can't find any further explaination. What is timing out? Is my |>>hardware broken? |> |> In a word, probably! Your problems with the DEQNA's are most likely |>due to their not having a required FCO. Without the FCO, DEQNA's are |>brain dead, with the ECO they are merely brain damaged. DEQNA's at |>revision level D or earlier will need FCO DEQNA-R-001. Even worse than being brain damaged, DEQNA's won't be supported by VMS in about a year, according to the VMS 5.0 release notes! Right now, you are supposed to enable software error detection on DEQNA's (especially in LAVC environments) by setting a sysgen parameter. My suggestion would be to upgrade to the DELQA as soon as possible rather than bringing the DEQNA up to FCO. +------------------------------------+----------------------------------------+ | Gil Kloepfer, Jr. | Net-Address: | | ICUS Software Systems | {boulder,talcott}!icus!limbic!gil | | P.O. Box 1 | Voice-net: (516) 968-6860 | | Islip Terrace, New York 11752 | Othernet: gil@limbic.UUCP | +------------------------------------+----------------------------------------+