Looks good. Open a bug at http://sourceforge.net/projects/openhpi and
attach your patch. We'll get it integrated.
--Renier.
[EMAIL PROTECTED] wrote on 04/06/2007 09:58:03
AM:
> Hello OpenHPI developers!
>
> We observe a possible problem in the function saHpiSensorThresholdsSet
> (OpenHPI version 2.8.0).
>
> The HPI spec (SAF_HPI_B.01.01) says that:
>
> "Thresholds are required to be set progressively in-order, so that Upper
> Critical >= Upper Major >= UpperMinor >= Lower Minor >= Lower Major >=
Lower
> Critical."
>
> This requirement is verified if multiple thresholds are set with a
single
> call to saHpiSensorThresholdsSet.
> However, if multiple calls to saHpiSensorThresholdsSet are issued, and
each
> call sets one specific threshold, this requirement is not verified. As a
> result, with multiple calls, it is possible to set thresholds out of
order,
> so that, for example a lower threshold will be greater than an upper
> threshold:
>
> For a sensor that has the following thresholds:
>
> Lower Minor Threshold -56.000
> Lower Major Threshold -56.000
> Lower Critical Threshold -56.000
> Upper Minor Threshold 40.000
> Upper Major Threshold 50.000
> Upper Critical Threshold 65.000
>
> We can use the following code to set just the Lower Minor Threshold:
>
> memset( &thresholds, 0, sizeof(thresholds) );
> thresholds.LowMinor.IsSupported = SAHPI_TRUE;
> thresholds.LowMinor.Type = SAHPI_SENSOR_READING_TYPE_FLOAT64;
> thresholds.LowMinor.Value.SensorFloat64 = 120.0;
> saHpiSensorThresholdsSet( session, resId, sensor, &thresholds );
>
> As a result we`ve got the following threshold values for this sensor:
>
> Lower Minor Threshold 120.000
> Lower Major Threshold -56.000
> Lower Critical Threshold -56.000
> Upper Minor Threshold 40.000
> Upper Major Threshold 50.000
> Upper Critical Threshold 65.000
>
> Do you think this is an issue in OpenHPI that needs to be fixed?
>
> If so, the only fix we can propose is to read the current values of
> thresholds via saHpiThresholdsGet in every call to
saHpiSensorThresholdsSet,
> and then merge the new and old thresholds together and verify the order.
The
> proposed diff is attached. However we have some concerns about potential
> performance implications of this change.
>
> What say?
>
> Thanks and regards,
> Serge Zhukov
> Project manager
> Pigeon Point Systems
>
> [attachment "safhpi.c.diff.txt" deleted by Renier
> Morales/Poughkeepsie/IBM]
>
-------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share
your
> opinions on IT & business topics through brief surveys-and earn cash
>
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Openhpi-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/openhpi-devel
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Openhpi-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/openhpi-devel
