[mc1322x] Fragmented packets: could not allocate a queuebuf

[Daniel Berenguer]

Thanks Jon and Mar.

You seem to be right (again :-( ) The process yields frequently but
there is a singularity, with regard to the udp-client example, that
seems to be causing the problem:

My application, formed by a single process, is creating two different
udp connections: the first connection listens for a "download" command
on a given port. The second connection is devoted to the TFTP client.
The process first waits for a "download" command on the first udp
connection and, once received, the TFTP udp connection is created and
the transfer is done. Well, removing the use of the first connection
makes the problem disappear. I must now look into the proper way of
combining different udp connections within a single process... or
maybe separate the two connections into two different processes.
Anyway, I'm happy to know that this is not a contiki-related problem
:-)

Thanks again guys for your help.

Daniel.


On 21 July 2010 18:03, Mariano Alvira <mar at devl.org> wrote:
> On Wed, Jul 21, 2010 at 05:34:17PM +0200, Daniel Berenguer wrote:
>> Doing QUEUEBUF_CONF_NUM = 32 does not solve the problem. I've also
>> tried enabling BLOCKING_TX but no luck. Anyway, packet fragmentation
>> is not extrictly necessary for my application (tftp client) so I'll
>> revert to the old "uni-packet" config and will try to move ahead a bit
>> before looking into this issue again.
>
> Hi Daniel,
>
> I just tested the rpl-udp/udp-client.c with larger packets --- I'm
> sending around 482 bytes. I'm sending one every 2 seconds. I am not
> having any problems with the queuebuf.
>
> Is is possible that your code is blocking for a while and not yeilding
> to contiki frequently enough?
>
> -Mar.
>
>