OK. I would suspect a problem with ARM and x86 endianness being different
then. Renier, any idea?
_____
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Lisa Yuan
Sent: Saturday, January 05, 2008 23:37
To: [email protected]
Subject: Re: [Openhpi-devel] Porting to ARM
Yes that is correct. Sorry I was clearer in my initial email.
If both the daemon and client is ran on the ARM platform, then the
thresholds are correct. If both the daemon and client is ran on the x86
platform, the thresholds are also correct. There's only a problem when the
daemon is running on the ARM platform and the client on the x86 platform.
Lisa
_____
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Pierre
Sangouard
Sent: Saturday, January 05, 2008 2:05 AM
To: [email protected]
Subject: Re: [Openhpi-devel] Porting to ARM
See answer below.
Pierre
_____
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Renier
Morales
Sent: Friday, January 04, 2008 21:27
To: [email protected]
Cc: Pierre Sangouard
Subject: Re: [Openhpi-devel] Porting to ARM
[EMAIL PROTECTED] wrote on 01/04/2008 02:54:42 PM:
> 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.
>
I tested on the x86 platform with the simulator plugin and the threshold
values come out fine. So must be something at the plugin level.
Maybe Pierre can shed some light on this after you provide specifics of your
hardware.
--Renier
[Pierre] What we would need to know is for both configurations where is the
dameon running and where is the client running. I have the impression that
the daemon is running on the ARM platform and that the failure occurs when
commands are run remotely on an x86 platform. Is that the case ?
>
>
> From: [EMAIL PROTECTED] [mailto:openhpi-
> [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
-------------------------------------------------------------------------
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
