Several complaints

[Mike Muuss]

I recently had two irritations when using new SGI 4D machines.

1)  On the 4D/20, we did not detect that this was a "GT"-style machine.
(The whole method for determining configuration that SGI provides is
hokey right now).  When we forced the GT versions to be used, the
wireframe support worked, but 24-bit pixel access didn't.  Alas,
the machine was only available to me for 2 hours, and I was not able
to hunt this down.  We should be getting a 4D/20 to run further tests
on, soon.

2)  On the 4D GTX 2-processor system, I have been completely unable
to run in parallel and write pixels at the same time, using RT.
RT on one processor writes pixels fine, RT on multiple processors writes
image *files* fine.  RT on two processors dies on the first entry to
the graphics library that is done after multi-processing starts.
In this case, a call to zdraw(TRUE).  If anybody can give me some hints
on how to proceed, I would be most appreciative.  I know that some of
the SGI demos (like the nifty toy ray-tracer) can use both CPUs
and also make graphics.

More details:

multi-processing locks are established like this:

	if (lockstuff == 0) {
		mktemp(lockfile);
		lockstuff = usinit(lockfile);
		if (lockstuff == 0) {
			fprintf(stderr, "unable to allocate lock space\n");
			exit(2);
		}
	}
	ltp = usnewlock(lockstuff);

multi-processing itself is established (with seemingly identical failures)
either by:

		if( taskcreate( "worker", func, 0 ) == -1 )
			rt_log("machine.c/rt_parallel(): taskcreate failed\n");

or by:

		/*
		 *  Start a share-group process, sharing ALL resources.
		 *  The sharing is necessary to keep libfb
		 *  (actually, SGI's libgl) happy.
		 *  This direct sys-call can be used because none of the
		 *  task-management services of, eg, taskcreate() are needed.
		 *  ALAS, this does not help.
		 */
		if( (new = sproc( func, PR_SALL, 0 )) < 0 )
			rt_log("machine.c/rt_parallel(): sproc failed\n");

The trace that I get from DBX when things die (with a segmentation fault):

(dbx) where
>  0 gl_zdraw(0x0, 0x0, 0x0, 0x453d6c, 0x0, 0x44a5d4) ["modes.c":314, 0x44fd0c]
   1 zdraw(0x0, 0x32, 0x0, 0x7bffec48, 0x0, 0x0) [0x44e560]
   2 gt_bwrite(0x7bffee28, 0x0, 0x0, 0xf, 0x80, 0x47315c) ["../libfb/if_gt.c":1099, 0x44a5d0]
   3 stk_bwrite(0x10011ba0, 0x10014680, 0x10031498, 0x100314b0, 0x80, 0x0) ["../libfb/if_stack.c":226, 0x44c4f0]
   4 view_pixel(0x0, 0x0, 0x0, 0x0, 0x0, 0x0) ["../rt/view.c":276, 0x405de8]
   5 worker.worker(0x0, 0x0, 0x0, 0x0, 0x0, 0x0) ["../rt/worker.c":261, 0x403b6c]
   6 sproc.sproc(0x0, 0x0, 0x0, 0x0, 0x0, 0x0) [0x477064]

The code fragment looks like this.  Note that this routine is ONLY called
when an exclusive lock has been acquired, so that at most one process of
the share group is using the graphics library.

_LOCAL_ int
gt_bwrite( ifp, xmem, ymem, pixelp, count )
register FBIO	*ifp;
register int	xmem, ymem;
RGBpixel *pixelp;
register int	count;
{
	if( qtest() )
		mpw_inqueue(ifp);	/* calls qtest(), qread(), reshapeviewport(), gt_repaint() */
	if( xmem < 0 || xmem > ifp->if_width ||
	    ymem < 0 || ymem > ifp->if_height)
		return(-1);
	zdraw(TRUE);
	/* BOOM, segmentation fault */

Can anyone shed any light on this, or even suggest things that I should
read, try, print, etc?  I'm foxed!

	Thanks,
	 -Mike