On Thu, Mar 23, 2017 at 08:51:21AM -0400, Jarod Wilson wrote: > Not sure if it's intentional, but in my adventure of the past day or two to > get rdma-core v13 building across all the arches I need to build it for, I > discovered that the mlx5 bits silently don't build on s390x. No build > failure, they just aren't attempted, so far as I can see. The only sign of > failure was when rpm %files globs failed to locate mlx5 bits. I don't expect anything except mlx4 to *work* on s390 - fixing that would require making a common IOMEM accessor system. However, AFAIK, they should build.. > I noted that mlx4 has some s390x-specific trickery in providers/mlx4/mmio.h, > and wondered if something similar was required for mlx5, or if "does not > work on s390x and isn't expected to" is the norm. Currently, my builds are > excluding mlx5 support on s390x due to the current state. It would be nice if you could post logs for these various failures.. My guess is that none of the DMA providers were compiled for S390, which happens if the system cannot compile util/udma_barrier.h. Perhaps this test is wrong? #elif defined(__sparc__) || defined(__s390x__) Maybe it should be #elif defined(__sparc__) || defined(__s390x__) || defined(__s390__) ?? Also, you should expect mlx5 not to be built on ARM32 and in other places where we do not support user DMA. Can you accommodate this in the rpm spec file? Debian has the same issue too... You can simulate this on x86-64 by patching util/udma_barrier.h to always fail to compile. Jason -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
