phaedrus@eneevax.UUCP (Praveen Kumar) (12/05/86)
Thanks to everyone for the information. I got so much information from
so many people, I can't respond individually. I really appreciate it.
pk
--
ARPA: phaedrus@eneevax.umd.edu
UUCP: {seismo,allegra}!umcp-cs!eneevax!phaedrusajohnson@killer.UUCP (Andy Johnson) (01/11/88)
I have been running Microport's Unix V2.2 for about 7 months now
and have encountered the messages:
tss fault
double panic tss fault
I have contacted Microport on more than one occasion and asked them
about this. Their answer was, it shouldn't happen, but they never
could/would tell me what it is. I would appreciate it if any netlanders
that are sufficiently versed in unix internals and know the answer to this
question would reply, either in mail or on the net.
Andy Johnson
inhp4!codas!killer!ajohnson
or
inhp4!codas!novavax!pinn!sysopdave@sdeggo.UUCP (David L. Smith) (01/12/88)
In article <2788@killer.UUCP>, ajohnson@killer.UUCP (Andy Johnson) writes: > I have been running Microport's Unix V2.2 for about 7 months now > and have encountered the messages: > tss fault > double panic tss fault > > I have contacted Microport on more than one occasion and asked them > about this. Their answer was, it shouldn't happen, but they never > could/would tell me what it is. I would appreciate it if any netlanders > that are sufficiently versed in unix internals and know the answer to this > question would reply, either in mail or on the net. This is the infamous serial port bug. Apparently they are not masking out their interrupts properly and there is some kind of a race condition that gets set up. This is a known and acknowledged bug. They thought they had fixed it in 2.3, but apparently there is still a chance that this might come up. It seems to be caused by running the serial ports at speeds above 2400 baud. -- David L. Smith {sdcsvax!jack,ihnp4!jack, hp-sdd!crash, pyramid}!sdeggo!dave sdeggo!dave@amos.ling.edu Sinners can repent, but stupid is forever.
richardh@killer.UUCP (Richard Hargrove) (01/12/88)
In article <2788@killer.UUCP>, ajohnson@killer.UUCP (Andy Johnson) writes: > I have been running Microport's Unix V2.2 for about 7 months now > and have encountered the messages: > tss fault > double panic tss fault > > could/would tell me what it is. I would appreciate it if any netlanders > that are sufficiently versed in unix internals and know the answer to this > question would reply, either in mail or on the net. > These are hardware exceptions generated by the 80286. The first is the invalid task state segment fault (a task's TSS is an area of memory that the os uses to initialize architectural elements supporting the task). The hardware exception handling is then generating a second hardware fault (it looks like a new invalid TSS fault is occurring, this time for the TSS for the exception handler), thus generating a double-fault. Fortunately the cpu is not then generating a third fault. It enters a shutdown mode if it does. This looks like a uPort problem. The user is not supposed to be able to access such things as TSS's (particularly the TSS for an exception handler) in a protected execution environment. In weak defence of uPort, there's not much you can do in the face of a double fault except force the user to reboot. If you're really curious about details, see _80286 and 80287 Programmer's Reference Manual_, chapter 9, published by Intel. regards, richard hargrove ...!killer!richardh -------------------
manes@dasys1.UUCP (Steve Manes) (01/18/88)
In article <2788@killer.UUCP> ajohnson@killer.UUCP (Andy Johnson) writes: >I have been running Microport's Unix V2.2 for about 7 months now >and have encountered the messages: > tss fault > double panic tss fault > >I have contacted Microport on more than one occasion and asked them >about this. Their answer was, it shouldn't happen, but they never >could/would tell me what it is. They're right -- it shouldn't happen. But I ran a multiuser BBS and had fairly heavy UUCP traffic running on my V/AT and suffered panic attacks at least once a week. The last time, on Jan 2nd, fsstat completely trashed my root file system on reboot and I'm still trying to liberate files on /usr. The problem seems to be in Microport's serial driver, or at least it was rare to see tss faults unless I had a tty process active. Microport knows about the problem and is working on it. For instance, you could, in 2.2, expect a tss fault if you attempted to force a steady-stream upload at 9.6 kbaud into a serial port. 2.3 seems to have reduced the liklihood of a complete system crash but it still won't buy a 9.6 kbaud upload with large block file protocol like Ymodem (and Xenix won't reliably do better than 4.8k either). Experience indicates that Microport chokes on too many IRQ requests, which also means that running something like 'doscp' with a tty user online is risky at best. -- +----------------------------------------------------------------------- + Steve Manes Roxy Recorders, Inc. NYC + decvax!philabs!cmcl2!hombre!magpie!manes Magpie BBS: 212-420-0527 + SmartMail: manes@magpie.MASA.COM
greg@xios.XIOS.UUCP (Greg Franks) (01/18/88)
In article <169@sdeggo.UUCP> dave@sdeggo.UUCP (David L. Smith) writes: # In article <2788@killer.UUCP>, ajohnson@killer.UUCP (Andy Johnson) writes: # > I have been running Microport's Unix V2.2 for about 7 months now # > and have encountered the messages: # > tss fault # > double panic tss fault # This is the infamous serial port bug. Apparently they are not masking #out their interrupts properly and there is some kind of a race condition that #gets set up. This is a known and acknowledged bug. They thought they had #fixed it in 2.3, but apparently there is still a chance that this might #come up. It seems to be caused by running the serial ports at speeds above #2400 baud. The *real* reason for this scenario is kernel stack overrun. (You were likely doing console I/O at the time of the crash). We increased the size of the kernel stack (to 6k) which cured this fault in 2.2. The most likely cause of stack overrun in 2.2 systems is faulty interrupt priority processing (recursive interrupts - fun wow!). Interrupt priorities have been fixed in 2.3. Disclaimer: We're at the opposite end of the continent from microport systems. :-). We do have source though. -- Greg Franks XIOS Systems Corporation, 1600 Carling Avenue, (613) 725-5411 Ottawa, Ontario, Canada, K1Z 8R8 utzoo!dciem!nrcaer!xios!greg "There's so much to sea in Nova Scotia"
jmsully@uport.UUCP (John M. Sully) (01/22/88)
In article <2788@killer.UUCP> ajohnson@killer.UUCP (Andy Johnson) writes: >I have been running Microport's Unix V2.2 for about 7 months now >and have encountered the messages: > tss fault > double panic tss fault I don't know who you talked to, but it couldn't have been anyone in the technical support department. We are aware of a problem in the 2.2 kernel which can result in an overflow of the TSS stack due to too many interrupts occuring quickly. Usually this is caused by high speed serial i/o -- a UUCP connection at 9600 baud can cause this -- and the problem has been fixed in version 2.3. John M. Sully Microport Systems Technical Support -- John M. Sully UUCP: ...!{sun | ucbvax | ihnp4}!amdcad!uport!techs Microport Systems ARPA: uport!techs@ucscc.UCSC.EDU Technical Support
henry@jtsv16.UUCP (Joe H. Pinski) (10/13/88)
I'm running 4.3 Unix on an Integrated Solutions hardware. Every now and then a message appears on the console as follows: -- System Page Fault -- there is no core dump, and the system seems to recover from it by itself. I would appreciate to hear comments from anyone who has experienced a similar problem.
rja@edison.GE.COM (rja) (12/05/88)
( The article I'm reponding to appeared in ~wizards but seemed
more appropriate here so I've changed the posting location.)
AT&T is selling UNIX System V/386 release 3.2 NOW and it provides
full support for XENIX binaries. When Microport/Interactive/et. al.
start selling rel 3.2 for the 386 theirs will also support XENIX
binaries. I believe that all will be selling that release shortly
if they aren't already.
HDB is widely available for Microport/Interactive/et.al. ports
of UNIX V/286 and UNIX V/386 and by now may well be the standard
offering. I believe that it comes with AT&T's offering.
The '286 compilers seem to have had problems with bugs beyond what
I'd consider normal (both Xenix and the Sys V crowd), but the
'386 compilers reportedly are working well.
A number of people I know are buying the AT&T UNIX V for
PCs that aren't AT&T. I'm looking into doing the same.
______________________________________________________________________________
rja@edison.GE.COM or ...uunet!virginia!edison!rja
via Internet (preferable) via uucp (if you must)
______________________________________________________________________________louis@auvax.UUCP (Louis Schmittroth) (12/09/88)
In article <1729@edison.GE.COM>, rja@edison.GE.COM (rja) writes: > AT&T is selling UNIX System V/386 release 3.2 NOW and it provides > full support for XENIX binaries. When Microport/Interactive/et. al. > start selling rel 3.2 for the 386 theirs will also support XENIX > binaries. I believe that all will be selling that release shortly > if they aren't already. > A number of people I know are buying the AT&T UNIX V for > PCs that aren't AT&T. I'm looking into doing the same. > I have finally installed AT&T 386 UNIX on a Televideo 386, which is and (almost) AT clone. Make sure that the hard drive is in the drive table. At least Rel 3.1 doesn't let you set the drive parameters at the first menu like Xenix 2.3 does. -- There may be work arounds if the drive is not in the drive table. The Tele 386 came with an AT style keybd, which worked fine with both DOS and Xenix, but not with AT&T UNIX. As a last resort I took the keyboard off this old IBM XT and moved it over, and UNIX proceeded. I have since gotten a keyboard with an XT - AT switch, and if I have to boot DOS only, I move it to the XT position. If I run SimulTAsk this is not necessary. I am hoping that Rel 3.2 will cure this???? -- Louis Schmittroth, Computer Science, Athabasca University auvax!louis