> Holger, > > By all means it should adhere to the spec, but I'm confused as to how this > 11b value got introduced, when it should have been correct when read from > the vendor-supplied SDRs? [Liebig, Holger] Andy, This value is set in our default SDR for almost any system of the past few years :( It's a shame that it never came up earlier in any review, but the situation is now as it is and I'm trying to convince Albert to include my patch as a vendor specific workaround.
For non-native speakers it's sometimes difficult to get the full meaning and people tend to read what they want to read. If you split the wording in the spec into two sentences you get: Fixed, unreadable, thresholds. and Which thresholds are supported is reflected by the Reading Mask. The threshold value fields report the values that are ‘hard-coded’ in the sensor. The second part makes only limited sense if the thresholds were really unreadable, or where the difference to the read only thresholds really is. If you read only the first part and skip the second part you end up with 'unreadable' and might wonder what "Which thresholds are supported is reflected ..." refers to. Maybe the value was first set in the SDR's when support for the optional Get Sensor Thresholds cmd was not yet available in the firmware, or by mistake. Nobody I asked can remember why it is set this way and many applications check only the Threshold Reading / Threshold Writing Mask in the SDR without the capabilities bits. Again, my hope is that Albert includes the patch as vendor specific workaround. Thanks for your comments, Holger _______________________________________________ Freeipmi-devel mailing list Freeipmi-devel@gnu.org https://lists.gnu.org/mailman/listinfo/freeipmi-devel
