mapper "assertion failed...(!routeTable)" error => don't -remove-deadlocks!

Using gm-1.4, with 21 LANai7-equipped (+ 1 LANai4) PCs
(linux 2.4.4 x86) plugged into a single 32-port M2M-OCT-SW8 Myrinet
2000 switch, the mapper kept reporting the following puzzling error:

    starting to map. My clock says Thu Oct 18 22:23:47 2001
    map time was 644284 lanai ticks, which is 322 millisecs.
    found 21 hosts and 8 switches (29 nodes)
    configuring
    assertion failed. mt/simple/sc_Calculator.c:106 (!routeTable)
    route computation took 0 milliseconds
    configuration took 20 milliseconds

    not all nodes have been configured
    :-(

So the mapper never assigned node IDs, and the network was unusable.
Running e.g. gm_allsizes fails for lack of node IDs, IP doesn't
get through, etc.  However, "mapper.map" did contain a
reasonable-looking network map, listing everybody.

Finally found the trouble.  I'm posting this in case it helps
someone else, and in hopes someone can explain why it breaks this
way on this network.  (I'll send a separate note with the same
material to [email protected].)

gdb'ing the mapper showed that it called some deadlock-detection
routine before re-calling the route table calculator.
So, noticed the option in the example "binary/sbin/active.args" for

  -remove-deadlocks

It's enabled by default.  The same active.args works fine on two
other myrinet networks nearby, one of 7 and one of 21 nodes,
though neither uses Myrinet 2000 switches.

Just commenting out ``-remove-deadlocks'' avoided the problem --
the network works fine now.

But anyone installing gm-1.4 out-of-the-box would run into the same
problem.  I didn't find any hint of this error in any of the documentation.

(Other things I wasted several hours trying:
  - need to run mapper from LANai7-equipped vs LANai4-equipped host?
  - oddball LANai4 attached to network?  Does it need LANai7's only?
  - IP turned on before mapper starts?
  - CONFIG_HIGHMEM?
  - 2.4.4 SMP vs 2.4.4 uniproc vs 2.4.2 uniproc kernel?
  - switch needs powercycling?
  - compiler/stdc++ problems?
	Botched downgrade from RH71's gcc-2.96 => 2.95.3?
)

Any idea why this setup behaves this way?  Does anybody else's?
Is there some FM I forgot to read?

   Stuart Levy, [email protected]