I ran some more tests:
Using the floating point value of 0.1, the ARM daemon sends the data to
the x86 client as 99 99 b9 3f 9a 99 99 99.
With the daemon and client on the x86, the value is 9a 99 99 99 99 99 b9
3f.
As far as I can tell, it looks like the two dwords are swapped.
Running this same test with the daemon and client on the ARM, the data
is the same in the first case. Since both the daemon and client are
interpreting data the same way, there are no problems display the
correct threshold value.
Lisa
________________________________
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Pierre
Sangouard
Sent: Sunday, January 06, 2008 5:21 AM
To: [email protected]
Subject: Re: [Openhpi-devel] Porting to ARM
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
