uC/OS-II LWIP pbuf_free fail

We've also been esperiencing pbuf issues related to TCP.

Would you please post the changes to pbuf.c to fix the bug?

We would like to get the problem fixed ASAP for some

systems in the field.

Thanks,

ni0s_dude

I have the same problem, but I'm using lwIP version 1.1.0, distributed with NiosIDE/Quartus 5.01 release.

So I think the problem has not been solved with the patch mentioned by wlrm04 (admitted they found a patch).

Anybody knows how to solve this problem?

--- Quote Start ---

originally posted by stepozzi@Nov 29 2005, 06:32 PM

i have the same problem, but i'm using lwip version 1.1.0, distributed with nioside/quartus 5.01 release.

so i think the problem has not been solved with the patch mentioned by wlrm04 (admitted they found a patch).

anybody knows how to solve this problem?

<div align='right'><{post_snapback}> (index.php?act=findpost&pid=11238)

--- quote end ---

--- Quote End ---

We found it!

This is not a problem of the lwIp stack, but a problem in the nios ii data cache controller.

Yes, the data cache manager has a bug and Altera is working on it.

Under some unlucky circumstances (and the function pbuf_header has this "unlucky" sequence of instructions) the wrong location of RAM is written.

I think this will be fixed in the next release (or patch) of Quartus II.

Does anyone know if this bug is also present in NIOS-II 1.1?

In the lwIP support forum several posts relating to some not yet solved pbuff issues can be read, including at least one that could produce a "pbuf_free: p->ref > 0" assertion.

Working in an FTP client, based on lwIP + uC/OS-II, we found that several pbuff related issues could arise when deleting a connection while lwIP was still trying to send un-acked TCP packets. A network sniffer was a great help for detecting that this was the cause.

Waiting for all the packets (in the connection) being send and acked (or timed-out) was the work-around. The connection object has two fields that are not NULL when packets are still pending (waiting to be sent or acked).

--- Quote Start ---

originally posted by vlorenzo@Jan 4 2006, 04:56 PM

does anyone know if this bug is also present in nios-ii 1.1?

--- Quote End ---

No, I don&#39;t know. Sure it is present in NiosII 5.0 and 5.1.

But we have a little piece of code that can verify the problem:

#include <stdio.h># include <string.h># include <sys/alt_irq.h>
# define PATTERN_VAL     0xAAAAAAAA# define START_FILL_ADDR 0x01040000# define END_FILL_ADDR   0x011FFFFF# define DWORD_ADDR_1    0x010F1AB8 // 0x01XXXAA0-0x01XXXAB8# define DWORD_ADDR_2    0x01100ABC // Last dword of a cache line
int main()
{
 static unsigned long * pdw1=(unsigned long *) DWORD_ADDR_1;
 static unsigned long * pdw2=(unsigned long *) DWORD_ADDR_2;
 static unsigned long * pdwCur;
 // Disable interrupts
 alt_irq_disable_all();
 // Fill memory with pattern
 memset((void *) START_FILL_ADDR,PATTERN_VAL,END_FILL_ADDR-START_FILL_ADDR+1);
 while(1)
 {
  asm volatile
  (  
   "movi r2,0x5555;"
   "ldw  r3,(%);"
   "stw  zero,(%);"
   "stw  r2,(%);"
   :   "+r" (pdw1),
       "+r" (pdw2)
   :
   : "r2","r3"
  );
  // Check memory
  pdwCur=(unsigned long *) START_FILL_ADDR;
  while(pdwCur < (unsigned long *)(END_FILL_ADDR+1))
  {
   if(*pdwCur!=PATTERN_VAL && pdwCur!=pdw1 && pdwCur!=pdw2)
    while(1);
   pdwCur++;
  }
 }
 return 0;
}

If you execute this code on NiosII 5.0 and 5.1 with data cache enabled, it blocks on the while(1) cycle because of memory corruption.

If you execute this code on a core without data cache, all is ok.

I don&#39;t know if this code can run also on NiosII 1.1 (I don&#39;t know that version of the CPU).

<div class='quotetop'>QUOTE </div>

--- Quote Start ---

In the lwIP support forum several posts relating to some not yet solved pbuff issues can be read, including at least one that could produce a "pbuf_free: p->ref > 0" assertion.

Working in an FTP client, based on lwIP + uC/OS-II, we found that several pbuff related issues could arise when deleting a connection while lwIP was still trying to send un-acked TCP packets. A network sniffer was a great help for detecting that this was the cause.

Waiting for all the packets (in the connection) being send and acked (or timed-out) was the work-around. The connection object has two fields that are not NULL when packets are still pending (waiting to be sent or acked).

<div align='right'><{post_snapback}> (index.php?act=findpost&pid=11943)

--- Quote End ---

[/b]

--- Quote End ---

I agree with this patch. In fact we modified some time ago the function netconn_delete to wait for both conn->pcb.tcp->unsent and conn->pcb.tcp->unacked to be NULL before deleting the connection. We had a problem with a web server: sometimes not the whole queue was flushed and the html page was truncated.

However the assertion was still present.

Once modified the pbuf_header function in order to avoid the unlucky sequence of instruction that "fake" the cache controller (just add a dummy read operation before the return statement) we never got the error anymore.

Thanks for the piece of code, I&#39;ll test it with our NIOS-II 1.1.

Regarding netconn_delete, in some cases we could need to completely stop using a connection, do a real "delete", stop trying to send any pending packets. Is there any clean method for doing that?

Hi

Thanks, had a hard time with this as well.

I still have the pbuf_ref problem after I installed the Altera&#39;s patch. Do I have to re-generate the image or is it just a compilation problem ?

The dummy read mentioned, exactly what shall I put where ?

Best Regards

Jan Ulvesten

Sure, you have to re-generate the FPGA image, because the problem is in the CPU, not in the compiler or libraries.

--- Quote Start ---

originally posted by julveste@Mar 23 2006, 03:52 PM

hi

thanks, had a hard time with this as well.

i still have the pbuf_ref problem after i installed the altera&#39;s patch. do i have to re-generate the image or is it just a compilation problem ?

the dummy read mentioned, exactly what shall i put where ?

best regards

jan ulvesten

<div align='right'><{post_snapback}> (index.php?act=findpost&pid=13722)

--- quote end ---

--- Quote End ---