| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 221.1 | Press the RESET button | SWIFT::BYRNE | We apologise for the inconvenience | Tue Mar 25 1986 09:56 | 12 |
| RWAST means that the process is waiting for a resource whose
availability MAY be made known via an AST. Find out what the
process is waiting for and supply it. It is probably due to
the exhaustion of a process quota so find out which one and
increase it.
$STOP/ID is delivered via a kernel-mode AST so the process
will wait for that instead.
The only way out that I know is to reboot the machine.
Ciaran Byrne.
|
| 221.2 | | CADLAC::WONG | | Tue Mar 25 1986 12:02 | 6 |
| I got stuck with this situation a couple of times.
REBOOT!
B.
|
| 221.3 | Can't WHAT Stop It? | VAXUUM::DYER | Brewer - Patriot | Tue Mar 25 1986 15:38 | 7 |
| Why reboot when you can hack? Throw random bits into it and
see what happens . . .
.-----.
/ o o \
\ \___/ /
`-----'
<_Jym_>
|
| 221.4 | | POTARU::QUODLING | It works for me.... | Tue Mar 25 1986 17:45 | 7 |
| I found notes-11 doing this to me in the past sometime back.
Check back through the Notes-11 Notesfile (not conference :-))
and see what solutions were offered. I think with careful use
of SDA you can find out why it is playing up and fix it.
q
|
| 221.5 | try *poking* around | SQUAM::WELLS | Phil Wells | Tue Mar 25 1986 20:43 | 13 |
| I once looked into a system where some DECmail processes were in
RWAST. The operator had already done a STOP on the processes, so
they were marked in the PCB. This makes it difficult to use the nice
SDA commands to see what is wrong.
I then wrote a small program that cleared the bit in the PCB that
said 'process is being deleted'. I also used a BITC with a $V_
symbol, or some such that produced an exception. As this was a
_hack_, I had not bothered to establish a handler.
Moral: If you don't want to reboot - maybe you can crash it :-)
-phil
|
| 221.6 | Bolting stable doors | SWIFT::BYRNE | We apologise for the inconvenience | Wed Mar 26 1986 04:10 | 6 |
| Provided that you haven't done a $STOP/ID then you can use SDA
to find out what the process is waiting for but it is usually
too late to supply it. ^P then H on the console usually does the
trick.
Ciaran Byrne.
|
| 221.7 | Thanks. | SUBSYS::LAWLER | | Wed Mar 26 1986 07:44 | 7 |
| Thanks to all... As fate would have it, we just started
getting a bunch of memory errors, and field service coming
gives me an excuse to reboot the machine...
I appreciate the help.
al
|
| 221.8 | Use Force | KLOV02::BROWN | | Wed Apr 02 1986 13:02 | 4 |
|
Sometimes a FORCEX does the trick.
_sb:
|
| 221.9 | | ERIS::CALLAS | Jon Callas | Wed Apr 02 1986 14:31 | 6 |
| Forcex will never work when a delete process won't. Forcex uses
a user mode AST, while delete process uses a kernel AST. If the
process is so wedged that a kernel AST can't get through, you can
bet your bottom dollar that a user mode AST won't.
Jon
|
| 221.10 | Rebooting worked. | SUBSYS::LAWLER | | Thu Apr 03 1986 09:14 | 5 |
|
Rebooting worked fine...
(I just missed dinner one evening...)
-a
|
| 221.11 | Heard of BUGCHECK.MEM? | GVA03::JRS | John SHADE | Mon Apr 07 1986 07:31 | 10 |
| Rebooting is the easy (sometimes only) way out. You should at least
try and determine what the resource wait is for - sometimes it's
possible to use DELTA to patch global locations, at the risk of
crashing the system.
I successfully got rid of a process that was stuck in RSN$_BRKTHRU
- by using SDA, DELTA and, of vital importance, a copy of BUGCHECK.MEM
which can be copied from VAXWRK (sys$notes the last time I looked).
John
|