Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/5/84; site dalcs.UUCP
Path: utzoo!utcsri!dalcs!forceten
From: forceten@dalcs.UUCP (ForceTen Enterprises)
Newsgroups: net.unix-wizards,net.micro.pc
Subject: Re: Xenix panic (easy to do) Comment and an alternate method.
Message-ID: <1535@dalcs.UUCP>
Date: Tue, 16-Jul-85 15:58:52 EDT
Article-I.D.: dalcs.1535
Posted: Tue Jul 16 15:58:52 1985
Date-Received: Wed, 17-Jul-85 01:57:59 EDT
References: <181@medstar.UUCP>
Organization: Dalhousie University, Halifax, N.S., Canada
Lines: 45

][b

In article 181@medstar, Robin Cutshaw writes:

> Here is a quick way to panic the IBM Xenix kernel (both original and updated).
> This works for both the small and medium models. (use cc shr.c -o shr -lx).
> 

... Code leading up to

> sdenter(share, SD_WRITE);
> (void )getcwd(pnbuf,100);	/* THIS IS THE KILLER LINE */
> sdleave(share);
> 
> sdfree(share);

	Although the crash is tragic, I would guess that removing the
cast to (void) would cause the code to work correctly. Microsoft
documents this behaviour in some obscure place (does the same on both
XT and AT versions of the compiler) in the Xenix manuals. A similar
piece of code crashes my XT, and causes the AT to segment fault.

	On the AT, a simpler means of instantly halting my machine
without so much as a panic (power cycle to reboot)

	$ cat > /dev/monochrome

	I use an AT w 1 Meg memory, Paradise Systems Multidisplay Card.
Has anyone encountered this on a system with a standard IBM colour adaptor?

||!][b

---------------------
Neil S Erskine			decvax!dartvax!dalcs!force10!erskine
ForceTen Enterprises Inc.
3845 Dutch Village Rd.
Halifax, N.S.
(902) 453-0040
-- 

Neil S Erskine			decvax!dartvax!dalcs!force10!erskine
ForceTen Enterprises Inc.
3845 Dutch Village Rd.
Halifax, N.S.
(902) 453-0040