[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[lwip-users] Porting to 0.6.2
From: |
Robert |
Subject: |
[lwip-users] Porting to 0.6.2 |
Date: |
Tue, 3 Jun 2003 21:32:36 -0400 (EDT) |
I am upgrading my eZ80 port to 0.6.2. Is there an interest in bug
reports on this version? I have found a few things, some documentation
related, some appear to be bugs in the code. I am going on the assumption
that version 0.6.2 is the "stable" version, and the CVS source is the
experimental version. So I assume that bugs reports on the CVS code has
more interest, but I am asking so I can understand the intent.
At this point I have resolved many of the issues, but there is more to do.
In the routine pbuf_alloc() in the case of PBUF_POOL, we are allocating a
pbuf chain with a certain length. The field "tot_len" is set in the first
pbuf, but not set in the 2nd or later pbufs. The effect of this is that
the Assertion on line 759 fails. I believe this to be a bug.
It looks as if it can be repaired with the following one line (starting at
line 304):
/* set length of this pbuf */
q->len = rem_len > PBUF_POOL_BUFSIZE? PBUF_POOL_BUFSIZE: rem_len;
q->tot_len = rem_len; // <------NEW LINE HERE
q->flags = PBUF_FLAG_POOL;
q->payload = (void *)((u8_t *)q + sizeof(struct pbuf));
LWIP_ASSERT("pbuf_alloc: pbuf q->payload properly aligned",
((u32_t)q->payload % MEM_ALIGNMENT) == 0);
q->ref = 1;
Adding this line does make the assertion succeed, but since my port is
still being converted, I cannot report that the fix is completely correct.
I know there has been a lot of effort in the pbuf area, so perhaps I am
missing something. Or perhaps it is the intend that the caller fill in
the tot_len field.
--
Best Regards,
Robert
- [lwip-users] Porting to 0.6.2,
Robert <=