sg_ses: order of low_crit and low_warn thresholds is mixed for `--get` command

[kseniadumpling]

trafficstars

Hi! Thanks for writing this SES utility.

Currently we found an issue with --get command for voltage thresholds. It seems the order for low_crit and low_warn is mixed up.

First thing, the raw output for page 5 (Threshold In):

# sg_ses --page=5 /dev/sg24 --raw
00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00  00 00 00 00 87 84 14 14
50 4d 14 14 50 4d 14 14  50 4d 14 14 50 4d 14 14
00 00 00 00 19 14 14 19  19 14 14 19 00 00 00 00
00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00

Here we are interested in VoltageSense01 bytes, that are 19 14 14 19 (aka 25 20 20 25 in decimal). In SES-3 standard the order of threshold status element is high_crit -> high_warn -> low_warn -> low_crit

Hence, I assume that VoltageSense01.low_warn = 14h and VoltageSense01.low_crit = 19h (based on raw data)

However, on a system I got these results:

# sg_ses --descriptor=VoltageSense01 --get=low_warn /dev/sg24
25
# sg_ses --descriptor=VoltageSense01 --get=low_crit /dev/sg24
20

I took a quick look at the code and guess the problem might be hidden here:

/* These are for the Threshold in/out diagnostic page */
static const struct acronym2tuple th_a2t_arr[] = {
    {"high_crit", -1, 0, 7, 8, NULL},
    {"high_warn", -1, 1, 7, 8, NULL},
    {"low_crit", -1, 2, 7, 8, NULL},
    {"low_warn", -1, 3, 7, 8, NULL},
    {NULL, 0, 0, 0, 0, NULL},
};

start_byte (third parameter) for low_crit is higher than low_warn