Then the case where the marshaling is breaking is:
client is on a 32-bit x86 platform and the daemon is on a 32-bit arm
platform.
This would be a new bug in the marshaling code.
If you are working on this and can send a tested patch it would be most
appreciated. The marshaling code the daemon and client use is under the
marshal/ directory, and the files you probably want to look at are
connection.c and marshal.c
--Renier
[EMAIL PROTECTED] wrote on 01/07/2008 01:44:27
PM:
> The x86 platform is 32bit.
>
> Lisa
>
>
> From: [EMAIL PROTECTED] [mailto:openhpi-
> [EMAIL PROTECTED] On Behalf Of Renier Morales
> Sent: Monday, January 07, 2008 8:16 AM
> To: [email protected]
> Subject: Re: [Openhpi-devel] Porting to ARM
>
>
> [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 9999
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
>
-------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
>
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
> _______________________________________________
> Openhpi-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/openhpi-devel
-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
Openhpi-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/openhpi-devel
