Re: Multipipe query

New Message Reply Date view Thread view Subject view Author view

Jim Helman (jimh++at++surreal)
Tue, 30 Nov 93 15:33:06 -0800


   Subject: -49- 1.1 Bug with Multipipe Onyx
   Date: 26 Oct 93 00:00:01 EST

   There is a bug in the 1.1 multipipe code. The symptom is a
   core dump and an error like:

      Performer Fatal (4):pfFree() pointer 0x9c9350 not from pfMalloc

   The workaround is to do the following after you've created
   a channel with pfNewChan:

      ((long**)chan)[3] = NULL;

> It appears that the .flt loader is unable to deal with multipipe/multi
> processing. I have broached the topic with Software Systems (who now
> support the loader), but have yet to hear back from them. I have
> also opened a service call to SGI directly.

Multipipe operation isn't a database loader issue. Hopefully, the
above initialization will fix your problem. The next most frequent
source of multipipe problems are application MP issues.

> Once the application is limping along with no catastrophic errors,
> is there an easy way to determine to what extent it is CPU-bound?
> Are we asking too much of our 2 processors (it looks like
> PFMP_APP_CULL_DRAW results in 7 processes)?

Yes. You have 7 active processes, actually 8 total processes (1 APP + 3
CULL + 3 DRAW + CLOCK), but the clock wrapper doesn't really count. If
you want to have a process feeding each graphics pipe all the time, you
need more CPUs. Also for solid realtime behavior, you need to isolate
processors and dedicate them to tasks (see sysmp(2)).

rgds,

-jim helman

jimh++at++surreal.asd.sgi.com
415/390-1151


New Message Reply Date view Thread view Subject view Author view

This archive was generated by hypermail 2.0b2 on Mon Aug 10 1998 - 17:50:06 PDT

This message has been cleansed for anti-spam protection. Replace '++at++' in any mail addresses with the '@' symbol.