Our policy is to keep unsupported code for a while in our releases in a best effort practice, at least while it seems to be working and does not bother us in our developments. The reality is that we do not further have any hardware nor specific funding to keep supporting this netmod.
Ok, got it.
2) netmod newmad has the same routing as mx (which calls assertion) but newmad is still in 3.2a2 => MPICH still has broken code unless something was fixed in subroutings?
Are you saying that you can reproduce the issue with the newmad netmod?
No.
Otherwise, similar code paths do not necessarily mean that we will be hitting the same bug.
I really hope so! The last assertion was called in sending, when the path had it way from user program's MPI_Send directly to the netmod's function 'send' and newmad and mx codes are almost identical on this way. I said, "unless something was fixed". May be it was fixed after 3.1.2 release, may be it is in MX netmod -- I don't know. Now I see that 3.2a2 version has new mxm netmod which also uses that routing which causes assertion. So I'll try to use the latest MPICH code and port MX to it and see if I hit the same assertion.
We do extensive automated testing in multiple netmods, architectures, compilers, and compiling configurations. Without being able to reproduce the problem in other than MX, we cannot conclude other than that the bug was specifically located in that netmod. In case you confirm you are reproducing the same bug in the newmad netmod, we will contact the external person who contributed and used to maintain it.
Ok. I tried newmad several months ago with MPICH (during very short time -- never tried to use it on these tests), but, unfortunately, I don't have time to resurrect it and try it on these tests. Anyway, thank you for conversation. It helped me to move on -- to the newest MPICH version! _______________________________________________ discuss mailing list [email protected] To manage subscription options or unsubscribe: https://lists.mpich.org/mailman/listinfo/discuss