Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!apple!ames!rex!mgse!marks
From: marks@mgse.UUCP (Mark Seiffert)
Newsgroups: comp.unix.xenix
Subject: problems with Xenix
Keywords: panic timeout table sco
Message-ID: <248@mgse.UUCP>
Date: 27 Jun 89 23:04:57 GMT
Organization: mgse
Lines: 76


Help! i am having some problems with my system, and my softcare
support from SCO is worthless.

I have a clone 286 with a Wyse 995 multiport card.
i am running SCO Xenix 286 re. 2.2.1. The Wyse drivers are 1.19.

At one time i had the number to a Wyse Tech. in Texas. He sent me a
revision B rom, and the 1.19 drivers, along with a 3 page list of
other known bugs.

I had Softcare level ii support, it just ran out the other day. Before
it did run out, i called SCO with a list of problems. To say they were
less than helpful would be a out-right lie. And they want me to pay
them another $600+ for another year of support! (IMHO i could get
better support from a jock strap than from them.)

I am having two problems with the async. ports, they may be related, i
don't know.

The first problem is rather strange. Sometimes when someone calls my
system, the modems will connect, and the system will lock up. the
system has to be rebooted and fsck'd. Some times when you enable a
port the system will lock up. I forgot to put this on my list of
problems for SCO, so it was not discussed.

The second problem is a little strange as well. Sometimes when someone
calls in the modems connect, and sometimes when nothing is happening
the system will panic with a timeout table overflow. Sometimes it is
one panic message, sometimes two with a stack fault or overflow. This
has started happening within the last month. sometimes it won't happen
all week, sometimes it will do it twice within an hour of each other.
The kernal has not been modified for sometime before it started. I have
checked the manual page (messages.M), and it was not too helpful.

From the man page (/usr/man/cat.M/messages.M.z)

	  panic: Timeout table overflow
	       The timeout table is full.  Timeout requests are
	       generated by device drivers, there should usually be
	       room for	one entry per system serial line plus ten more
	       for other usages.  Use configure(C) to raise the	number
	       of timeout table	entries.

I have eight serial lines, plus the extra ten they recommend means
i should set NCALL to 18. I went in to configure and NCALL was already
set to 70. I changed it to 80, and am still having the problem. Since
the problem still persisted i sent in a problem report to SCO. The
tech. talked to (barbh@sco) was not very helpful, basically she said
"well ... uh .. gee ... something is wrong. find out what it is." She
has no idea what, other than the  kernal drivers, but she was able to
suggest i try running configure and raising the timeout table limit.
I feel she did not have any idea what she was talking about (on any
of the problems), but she was not so concerned that she would check
with someone. 
So far i have only lost log files that were open at the time of the
panic, but it is only a matter of time before the panic occurs with
lots of data cached ot during a write. One time it paniced it must
have been during a read, the HDU access light was lit up after the
panic.

Any help the net can provide would be appreceated. At this time i 
have no intent to renew my softcare with SCO, while they were able
to get me out of some jams before, since they ave become so big,
thier service has gone down hill. This of course is my own opinion.

Marks.

"When you want to get a cow pregnent, you get a bull to service here,
SCO services there customers well."

-- 
Mark Seiffert,  Metairie, LA.
uucp:           rex!mgse!marks
bitnet:         marks%mgse@REX.CS.TULANE.EDU
internet:       marks%mgse@rex.cs.tulane.edu