K312240@AEARN.BITNET (Klaus Kusche) (03/15/90)
Dear Mailing List: We had another problem with the Inmos Occam toolset, but I'm not sure this time if it's a software bug, a hardware problem, or something else. We have a truly parallel Occam program (two seperately compiled tasks combined with "iconf"). The program is clean (compiled in halt mode, with all compile-time checkings enabled, and without any low-level code except for OutputOrFail.t and InputOrFail.t) and runs with no problem when configured for a single transputer. On all multi-transputer configurations we tried, the versions compiled with combined vector space (/v) work fine, whereas the default (seperate vector space) versions crash on some configurations and work on others. They just hang at unreproducible stages, no error flag set... Now the question is: Is this a software problem, ie. is it possible that '/v' makes a difference, or is it more likely a hardware problem? I've tested links and memory, they seem to be ok. (it is also not due to lack of memory...). Can a transputer crash on overload (the program is completely trivial, it just pumps data at highest possible speed on all links from one end of the machine to the other...)? I just want to know if I have to investigate a software problem, or if I can defer the problem to the hardware people. Thanks for any experience! ************************************************************************ * Klaus Kusche * * Research Institute for Symbolic Computation * * Johannes Kepler University Tel: +43 7236 3231 67 * * A-4040 Linz Telex: (Austria) 22323 uni li a * * Austria (Europe) Fax: +43 7236 3231 30 * * * * Bitnet: K312240@AEARN * * Arpa/CS/Internet: K312240%AEARN.BITNET@CUNYVM.CUNY.EDU * * UUCP: mcvax!aearn.bitnet!K312240 * * Janet: k312240@earn.aearn or k312240%aearn@earn-relay * ************************************************************************