Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!sdd.hp.com!elroy.jpl.nasa.gov!decwrl!world!ksr!jfw
From: jfw@ksr.com (John F. Woods)
Newsgroups: comp.unix.admin
Subject: Re: SVVS requires a panic? Was: Re: CRASH your TANDEM :
Keywords: panic that kernel
Message-ID: <2888@ksr.com>
Date: 28 Mar 91 11:20:38 EST
References: <6685@auspex.auspex.com>
Sender: news@ksr.com
Lines: 20

guy@auspex.auspex.com (Guy Harris) writes:
>>I talked to a couple of Tandem engineers after USENIX this January.  They
>>bragged that their systems failed the SVVS (requiring waivers)
>>because some tests to invoke PANIC messages didn't work; Tandem
>>UNIX doesn't crash under some of the conditions expected by AT&T.
>That's an interesting claim, but I'm rather skeptical of it.  AT&T has done
>some bogus things in the SVVS (e.g., requiring that "read()", as I remember,
>actually bump the system time returned by "times()"; this shafted Apollo,
>because the Domain/OS implementation of "read()" was all in user mode, so it
>bumped the user time but not the system time), but requiring that the system
>*panic* wasn't one of them, at least not in the version of the SVVS I've seen.

I don't know about SVVS 3, but SVVS 2 certainly didn't, and couldn't, require
a panic.  After all, it kept a journal about the results of each test, and it
could hardly expect that file to come out of a panic with a message correctly
describing the fact that the system crashed, now could it?

I could well believe that the SVVS required *error* returns from subroutines
which aren't required by the SVID, which a more careful implementation could
avoid.