[EMAIL PROTECTED] wrote on 01/07/2008 12:52:50
AM:
> 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.
Is the x86 platform 64bit or 32bit? I ask because not resolving
differences between 32 and 64 bit architectures is a known bug in the
daemon.
--Renier
>
> 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:openhpi-
> [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:openhpi-
> [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:openhpi-
> [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:openhpi-
> [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
-------------------------------------------------------------------------
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
