[Info-vax] Bizarro crash... where to begin...

John Reagan johnrreagan at earthlink.net
Fri Oct 14 14:11:54 EDT 2011


<VAXman- @SendSpamHere.ORG> wrote in message 
news:00AB6DF3.89D5BD0B at SendSpamHere.ORG...
> In article <m96dnVnpZZagwwXTnZ2dnUVZ_rmdnZ2d at earthlink.com>, "John Reagan" 
> <johnrreagan at earthlink.net> writes:
>>
>><VAXman- @SendSpamHere.ORG> wrote in message
>>news:00AB6DE3.E77AF456 at SendSpamHere.ORG...
>>> Threaded application running along swimmingly coughed up a phlegm ball:
>>>
>>>
>>> Failing Instruction:
>>> SYS$PAL_MTPR_IPL_C:              alloc       r35 = ar.pfs, 05, 03, 00
>>>
>>
>>alloc's only fail for strange reasons like register backing store full or
>>somebody garbled the registers that point to the backing store.
>
> Yeah, I've been rereading the ARM sections on this.  What I need now it to
> figure out what the blood stains in the crash dump are telling me.
>
> FWIW, this was from a stress test.  12 multi-threaded processes banging at
> the same time.  It could be a register backing store full but shouldn't 
> the
> RSE handle this???
>

The RSE is only setup to auto-expand for user-mode I believe.

The whole register backing store is quite elaborate inside of SWIS.  I 
remember one of Burns' talks discussion how interrupts partially save state 
in user mode and in kernel mode.

For kernel threads, there is probably more magic to get the correct backing 
store in place for each thread.  I have no idea how that stuff works (never 
did).

John 





More information about the Info-vax mailing list