Re:
> > large amount of I/Os (writes).  Below is a listing from SOS of the
> > stack trace of one of the pins (Pin #61).  The other pins have the
> > NM  3) SP=41644430 RP=a.001a8d80 receive_from_port+$7a4
> > NM  4) SP=416443b0 RP=a.0035d7e4 extend_receive+$494
> > NM  5) SP=416441b0 RP=a.0031a640 freeze_tim+$5e8
> > NM  6) SP=41644070 RP=a.0028bcc8 xm_freeze+$98
> > NM  7) SP=41643d70 RP=a.002bcb8c notify_dispatcher.block_current_process+$318
> > NM  8) SP=41643cf0 RP=a.002bf03c notify_dispatcher+$264
> > NM  9) SP=41643c70 RP=a.001a7e90 wait_for_active_port+$ec

Bill writes:
> The oddity in the trace above is from level 7 upwards. I've never seen DEBUG,
> assuming SOS calls DEBUG, catch an overlapping trace in quite this way.
> Notify_dispatcher does not call xm_freeze. So the trace above is actually a snapshot
> of the process state changing quite rapidly. I've just never seen that occur in quite that
> way so I thought I'd point that out.  Not a problem, just sort of odd.

I assume that SOS uses DEBUG to do the stack trace ... and what
we see here is probably that the process being traced got some
CPU between the start of the trace and the end of the trace.  Thus,
it moved on ... rendering the stack trace "odd".

Remember, in Debug "PIN #61; tr, i, d" simply takes a snapshot
of the registers, and then does the trace ... but that trace is
being done from the SOS process stack.  If SOS has lower priority
than PIN 63, or if there's more than one CPU, it isn't surprising to
see the stack change.  Now, if we only had a Debug command
like "pintrace #61, i, d" which would prevent the process from
being dispatched until the trace finished...

Stan Sieler                                           [log in to unmask]
www.allegro.com/sieler/wanted/index.html          www.allegro.com/sieler