Re: [lwip-users] sys_timeout firing too often.

[Piero 74]

Hi

If can help, i attached my sys_arch for freertos running above lpc2366 microcontroller.

Bye

Piero

2008/9/8 address@hidden <address@hidden>

Nick Thomas wrote:

Nick, could you tell us which version of lwIP you are using? I think I
remember the calls to sys_mbox_fetch in api_lib.c being changed to
sys_arch_mbox_fetch in 1.3.0, so you might be using an old, pre-1.3.0
version?
   

Hi, this is a version for OS20, for ST chips. I don't know what version it
is - I just inheritted it.
 

Too bad. But if you want to use it in a production environment, I'd strongly suggest to update to the latest version possible! (which currently would be 1.3.0, unless you want to use CVS head).

As to the actual problem: your port must have something seriously messed
up: I could imagine either sys_arch_timeouts() returning the same struct
sys_timeouts* for all tasks (which is an error!) or your system time
(used in sys_arch_mbox_fetch) is somehow calculated wrong... (the return
value of sys_arch_mbox_fetch should indicate how long you have been
waiting). I suspect the first, though.
   

I think the first, I found this sys_arch.c:

[...]

This looks like the smoking gun.
 

Yep, defenitley wrong :-)

Looks like I have quite a lot of work to do :(
 

Not at all that much: if you want, you can copy the code from CVS: the win32 port does just the same - it has an array of task structs; each entry holds the thread ID (or handle or whatever you can use to detect the currently running thread). You then loop through this array until the ID matches and return the struct sys_timeouts of the matching array entry: take a look at http://cvs.savannah.gnu.org/viewvc/contrib/ports/win32/sys_arch.c?revision=1.8&root=lwip&view=markup

However, the 'fix' you suggested is NOT a good solution since this could
lead to a deadlock: image one thread is waiting on the receive-mbox of a
netconn (which waits forever): tcpip_thread would block forever and
couldn't process new packets! You really should check the two things
described above!
   

I didn't sugggest a 'fix' fix at all.

Sorry, just quoting your mail:

> So, this fix causes more problems than it fixes!

Just so you know: apart from calling raw API functions, this is one of the things users/porters do wrong most often (even though it is documented :)

Simon

_______________________________________________
lwip-users mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/lwip-users

sys_arch.c
Description: Binary data