I actually noticed the problem when I used hpithres.
The thresholds should be:
Lower Critical Threshold(lc): 8.000
Lower Major Threshold: 16.000
Lower Minor Threshold(li): 20.000
Upper Critical Threshold(uc): 55.000
Upper Major Threshold(ua): 50.000
Upper Minor Threshold(ui): 45.000
Instead they are showing as:
Lower Critical Threshold(lc): 0.000
Lower Major Threshold: 0.000
Lower Minor Threshold(li): 0.000
Upper Critical Threshold(uc): 0.000
Upper Major Threshold(ua): 0.000
Upper Minor Threshold(ui): 0.000
The Range Max, Min, Nominal, Normal Max, and Normal Min are also
incorrect, as well as accuracy.
Accuracy (correct): 0.030000
Accuracy (instead shows as):
-86792237893069920186182824980496282019471161..... (it's a really long
number)
I am using the ipmidirect plugin.
Thanks,
Lisa
________________________________
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Renier
Morales
Sent: Friday, January 04, 2008 10:26 AM
To: [email protected]
Subject: Re: [Openhpi-devel] Porting to ARM
[EMAIL PROTECTED] wrote on 01/02/2008 04:06:35
PM:
> Hi,
>
> I'm trying to port OpenHPI to ARM. I am having problems when I use
> the hpi_shell (or any of the HPI clients) on a x86 architecture.
> Threshold values are displayed as all zeroes. When I use hpi_shell
> on the ARM processor, the threshold values are displayed correctly.
>
> Upon further investigation, it looks like the word ordering on the
> 64-bit floating values is different on the two platforms.
>
To start eliminating variables, post the set of commands you are using
with hpi_shell and the plugin you are using.
--Renier
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Openhpi-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/openhpi-devel
