lwip-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lwip-users] sporadic PCB corruption


From: address@hidden
Subject: Re: [lwip-users] sporadic PCB corruption
Date: Wed, 25 Jan 2017 21:57:46 +0100
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2

Sandra Gilge (ADATIS) wrote:
there is following line in cc.h:
extern u8_t memp_memory_PBUF_POOL_base[] __attribute__ ((aligned (32)));

I checked the address of memp_memory_PBUF_POOL_base it is 32byte aligned

That might not be enough. With this, you only have ensured the PBUF_POOL memory starts aligned (so cache operations don't influence memory *before* that pool).
However, you still have two possible problems:
a) normally you flush the cache before TX and invalidate it before RX. However, you do so on the *data* only. Now the PBUF_POOL contains memory where "struct pbuf" is directly followed by the data buffer. Since "struct pbuf" is 16 bytes, cache operations on the data will corrupt the struct (when 32 byte alignment is required). b) the last pbuf might not end on a 32 byte boundary, so flushing/invalidating it might corrupt the next pool.

You seriously should fix this! However, I'm not convinced this is the reason for the tcp pcb list corruption, as the PBUF_POOL memory normally should be quite far away from the TCP_PCB pool... (unless your linker places them near each other).

Being like that, I'd still favour the "threading violation" problem...

> But I agree it could be easier with something like:
> #define PBUF_ALIGNMENT 32

That's true. Someone should work on that ;-)


Simon



reply via email to

[Prev in Thread] Current Thread [Next in Thread]