Hi all,
The problem has been solved by adding a constraint of alignment in the
structure rt_proc_call :
struct rt_proc_call {
struct list_head list_entry;
int processed;
rtpc_proc proc;
int result;
atomic_t ref_count;
wait_queue_head_t call_wq;
rtpc_cleanup_proc cleanup_handler;
char priv_data[0] __attribute__((aligned(8)));
};
priv_data is the address of the structure ipv4_cmd which was not aligned in
my case.
Thanks for all,
Best regards,
Cyril
2010/7/19 Gilles Chanteperdrix <gilles.chanteperd...@xenomai.org>
> Cyril Wallois wrote:
> > Hi Gilles,
> >
> > I verify the problem comes from the aligment, do you know if there is a
> > better way rather than to cast the 64 bits types in two 32 bits. For
> > example an option in the ABI to align the struct.
>
> You should work to get the struct aligned by construction, you will then
> get optimal performances. The only requirement to get this is on the
> allocator.
>
> The way I see it, alloc_rtskb returns pointer which are correctly
> aligned. The ethernet + offset usual trickery offsets the pointer by 16.
> So, it should be still aligned.
>
> The reason for the buffer being non aligned may well be some memory
> corruption issue. So, you should work and understand why this buffer is
> not aligned.
>
> --
> Gilles.
>
------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________
RTnet-users mailing list
RTnet-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rtnet-users
