Bikram, after changing of recvmbox size ( 8 ---> 20 !!! ) the problem seems disapper.... i tried to increase again a throughput, and i saw the problem agian.... but i had a breakpoint in my debugger in sys_arc_trypost error and debugger doesn't stop. After your post, i check lwip code:
as you said... it's possible that mbox had problem... because there are some calls: sys_mbox_post(mbox, &msg); this calls block forever.... i want to suggest to LWIP developer: change ALL calls to sys_mbox_post in sys_mbox_trypost if sys_mbox_trypost fails for a lot of time, caller drops all msgs in xxxx_mbox if you can, forward thi idea to lwip developer... i will continue to investigate bye, Piero 2008/3/7, Bikram Chatterjee <[EMAIL PROTECTED]>: > > I am not sure but some times back I ran into a similar problem. I > remember to trace it back to a deadlock due to small size of mbox. > > I doubt that it not recvmbox but it is mbox that is getting filled up > and posting new commands from application and driver are blocked up. > > But that might not be the case here, just though it might help, at to > be eliminated as a possibility. > > > On Fri, Mar 7, 2008 at 9:45 PM, Piero 74 <[EMAIL PROTECTED]> wrote: > > > > > > > > 2008/3/7, Bill Auerbach <[EMAIL PROTECTED]>: > > > > > > > > > > > > > > > > > Should receive have blocked at all since there is data in the > recv_mbox? Overflowing has no bearing on a thread waiting for data when > there is data already in the mbox. > > > > > > yes... it has blocked.... i tried to use a recv_mbox with more > elemets, and the problem dosn't happen... but i'm thinking something to > avoid this block... > > > > i don't know if can help you to understand the problem, but i saw: > > > > tcp fast timer was running and calling sys_mbox_trypost, but mbox was > full... so tcp_ip thread was running, but application task was blocked... in > think in sys_arch_mbox_fetch (called with timeout =0) in netconn_recv. > > > > Do you think could be usefull this: > > > > enable LWIP_SO_RCVTIMEO > > set SO_RCVTIMEO option for a socket > > > > i think (i hope) in this way sys_arch_mbox_fetch will never call with > timeout =0.... what do you think? > > > > bye > > Piero > > > > > > > > > > > > > > > > > > > > > > > > Bill > > > > > > > > > > > > > > > ________________________________ > > > > > > > From: [EMAIL PROTECTED] [mailto: > [EMAIL PROTECTED] On Behalf Of > Piero 74 > > > Sent: Friday, March 07, 2008 10:02 AM > > > To: Mailing list for lwIP users > > > Subject: [lwip-users] recv function BLOCK because recv_mbox is full: > can yougive me a solution? > > > > > > > > > > > > > > > Hi all > > > > > > this is my new problem: > > > > > > I have a task which calls lwip_recv with the flag MSG_DONTWAIT. > > > > > > I saw a strange situation: my recv_mbox is full, so sys_mbox_trypost > return ERR_MEM, so recv_tcp return ERR_MEM and tcp packet is dropped... but > recv remains BLOCKED! In this situation my code cannot check the problem and > close the socket! > > > > > > I can set size for recv_mbox using high value, but it's not a > solution.... can anyone explain how i can trap this problem? > > > > > > thanks, > > > Piero > > > _______________________________________________ > > > lwip-users mailing list > > > [email protected] > > > http://lists.nongnu.org/mailman/listinfo/lwip-users > > > > > > > > > _______________________________________________ > > lwip-users mailing list > > [email protected] > > http://lists.nongnu.org/mailman/listinfo/lwip-users > > > > > > > -- > Bikram Chatterjee > Senior Engineer > Alumnus Software Limited > Kolkata > > > > _______________________________________________ > lwip-users mailing list > [email protected] > http://lists.nongnu.org/mailman/listinfo/lwip-users >
_______________________________________________ lwip-users mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/lwip-users
