[Info-vax] The PWAIT tool.

[Jan-Erik Söderholm]

A short Saturday morning update...

Thank's to all that contributed to this thread.

Now, today (Saturday) I thought I'd try some of the
last sugestions for SDA commands, but the MWAIT process
is now gone. Something have got it to finish of by it
self. Just a few notes...

The process was a running a DCPS symbiont and setup
using "IP_LPD/<ip-address>".

I guess that all this started when the printer itself
for some reason was unaccessable for a moment. In
OPERATOR.LOG I can see a some "%DCPS-I-PRINTERSTALLED"
messages and then a number of "%DCPS-F-CONTERMINATED"
which probably comes from my routines to /stop/reset
and /start queues that are hanging in a "starting"
state (which seems to happens with some printers that
has gone into a "power-save" mode and DCPS can not
get it to wake up if I do not run a stop/start sequence
on the queue, but that it something else and usualy do
not get the symbiont to hang).

So, *something* on the net or in the printer got the
symbiont into this MWAIT state, and *somthing* (else?)
got it out of this sometimes between Thuseday evening
and saturday morning. I can see that the entries that
has been pending since two days back was printed from
05:00 saturday morning (that is the time when my queue
stop/start routine starts again after the night pause).

Well, since there is no process to look at anymore, there
isn't anything else then to close this case for the time
beeing.

This happens aprox once every 6 months so it's not a big
deal. And we will in a few weeks upgrade VMS 8.2 -> 8.3
and TCPIP 5.5 -> 5.6, so there is no reason to dig deaper
at the moment.

Thanks all...

Jan-Erik.




Volker Halle wrote:
> Jan-Erik,
> 
>> SDA> examine 824A7E00
>> FFFFFFFF.824A7E00:  FF67B470.FF67B470   "p´g.p´g."
> 
> this does NOT look like a valid MUTEX, it looks more like an entry in
> a self-relative queue.
> 
> Assuming this address is in nonpaged pool, you would need to examine
> the area of nonpaged pool around this address to try to find, which
> kind of packet this address lives in.
> 
> If you need to recover from this - and probably only a reboot would
> clear this - consider to force a crash, so that whoever is interested
> in solving this problem, may be able to look at the dump.
> 
> Volker.