Hi there, libibmad-1.1.6/src/dump.c:_dump_fields() does not always work correctly for big endian machines.
Example: 'smpquery portinfo' to a Mellanox ConnectX from a big endian machine prints a number of values incorrectly as zero. (e.g. RespTimeVal:.....................0, when RespTimeVal is actually 16) >From what I can tell, this is an issue between how _get_field() is used in mad_decode_field and how mad_dump_field uses functions like mad_dump_uint........ mad.c:mad_decode_field() sets *(uint32_t *)val = _get_field(), while _get_field() always returns a host-endian uint32_t of the value of the field. This means that on little endian machines, val[0] contains the value of a byte-length field. On big endian machines, val[3] contains this value. mad_dump_field calls, for example, dump.c:mad_dump_uint(). This will check the size (in rounded-up bytes) of the field. For a single byte, it will print *(uint8_t *)val, which is val[0]. This works on little endian, but prints zero on big endian. Possible solution: In the mad_dump_* functions, for cases 1, 2, 3, and 4 in the switch statement, always print *(uint32_t *)val. I believe the dump functions are always fed by _get_field (or get_field64), and thus for values of size 1-4 bytes, any unused bytes will always be zeroed out by _get_field(). I don't want to go around writing patches or filing bug reports all willy-nilly, so I thought it best to just report this and see if what I've come up with makes sense. :) -Joe _______________________________________________ general mailing list [email protected] http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
