Re: mbuff in 2.2.14 rtlinux-2.2

[Fred Proctor <frederick.proctor-at-nist.gov>]

Ray wrote:

> After exiting the EMC, mbuff seems to get captured by another
> process.  Then when I start EMC again it seems to share mbuff and after
> a few starts and stops it doesn't run properly at all.  The sysmptoms are
> a very slow start of emc and there are big delays in the mouse functions
> when using tkemc.

I have noticed similar problems, and in my case the emctask process
(e.g., bridgeporttask) didn't terminate and the next time I ran I had
two of these. Needless to say this caused problems.

If this happens again, verify that everything shut down from the
previous run with "ps ax". This shows a list of all the processes. You
shouldn't see any of the bridgeporttask, bridgeportio, emcsh, emcsvr
processes. If you do it means they didn't shut down properly.

I don't know why they fail to shut down. You can kill them with "kill
-KILL <pid>", where <pid> is the process ID reported by "ps ax".
"killall -KILL bridgeporttask" also works, as Will replied. With no
argument, or with -INT, killall sends signal SIGINT, which the task
controller traps. If it's running properly, the task controller just
does a nice quit after the current cycle. If it's hung up, this won't
work and the process will still be running. With "killall -KILL", the
process will be terminated with extreme prejudice.

The generic.run script runs "killall -INT", which is what we want to do
for safe shutdown. The script could be supplemented with a series of
"killall -KILL" statements at the bitter end, just to make sure
everything is cleared away.

Ray, you can modify the generic.run script (or your copy of it) and
replace the -INT with -KILL and see if this fixes your problems. The
shutdown won't be as clean (NML channels may be left around, it won't go
into ESTOP before quitting, etc.) but the processes will be cleared out.
If this eliminates your slow-execution symptoms, then adding the
"killall -KILL" at the end may be the solution.

--Fred