vjs@calcite.UUCP (Vernon Schryver) (12/12/88)
There seems to be some state in which Merge 1.1/System V 3.0e likes to
hang. After doing something with DOS (under Merge), either the 'dos' or
the 'dosexec' process likes to go to sleep and never awaken. The
nap occurs only when the DOS process tries to exit. Typing 'quit'
or ALT-SHIFT-DEL to a DOS console appears to have things hung. However, if
you switch to other consoles, you find the parent shell alive and happy.
The 'dos' process can be killed with SIGHUP, whereupon it gives up its
virtual console and evaporates. Once one process gets in this state, all
future DOS windows become such psuedo-zombies. That is, if you type 'dos',
wait for things to be quiet, and then type 'quit', you will have another
hung dos process. It seems about 50% of the time after rebooting the
system, `dos\n<pause>quit\n` will fail on the first attempt. The other 50%
of reboots produce a system which does not hang.
Running 'background' or non-interactive DOS jobs is similar. I've found
that at the end of such a job, there is often a stuck 'dosexec'. SIGHUP is
not sufficient to awaken such a dosexec; SIGKILL is required.
When 'dosexec' hangs, so does 'dos', and vice versa.
Crash(1) says the processes are in resume(), called from f86_slee(), called
from from86(), called from vm86_tra(), called from cmntrap. The wchan makes
no sense to me. Without source, I have no idea what's going on--or rather
what is not going on.
Does anyone know of a good work around? I'm tired of running out of
processes during series of PL/M compiles, as the 'dosexec' sleepers
accumulate.
I'm running an Everex 386/20 with 4MB, but that should be immaterial.
Vernon Schryver
{sgi,pyramid}!calcite!vjs