[TEST] The lwIP 1.4.1 thread

[Giovanni]

Hi,

I integrated lwIP and the suggestions made in the following threads:

viewtopic.php?f=2&t=844
viewtopic.php?f=2&t=846

The demos work but there are is a problems: In socket.c lwIP calls sys_sem_signal() within a lock, this is not possible in ChibiOS and the state checker would complain. This is only a problem if you use the sockets API. In order to workaround this more hacks would be required in sys_arch.c.

Any help is welcome.

Giovanni

[doceme]

Hey Giovanni,

I was curious if you have looked into the sys_sem_signal() lock problem anymore. I understand you have lots to do and this is probably a lower priority, so I understand if the answer is no.

I got the basic HTTP server working with lwIP 1.4.1 using an STM32F107 board I got from Ebay. I am trying to port the mongoose web server to work with ChibiOS and lwIP 1.4.1. It uses the sockets API to support multiple connections on the same port, so I'm sure I'll run into this problem.

I looked at the sockets.c code and I see what you're talking about with sys_sem_signal() beging call within a lock. I was wondering what kind of hack you were thinking about in sys_arch.c to get around this. I will try to implement something, but thought I would see what you had in mind before I take a stab at it. Let me know if you'd like me to try something.

[Giovanni]

Hi,

The problem is that the kernel does not keep track of its state (locked/unlocked) when the debug options are turned off.

The solution would be to call chSemSignal(); if outside a lock or chSemSignalI();chSchRescheduleS(); if inside the lock. The problem is to determine the current status. There are two possible solutions:

1) Keep the state checker ON: unacceptable because performance, it adds overhead and is meant for development only.
2) Check the interrupt status: more efficient because the check would be only in that specific point but not portable (the status is in the internal register BASEPRIO, you need some inline assembler).

In the kernel 3.0 I will add an API to the port layer to check the interrupt status, currently this is missing.

Giovanni

[gfortaine]

Hello,

There is now an alternative to lwIP as lightweight Open Source TCP/IP Stack, CycloneTCP :

http://www.oryx-embedded.com/cyclone_tc ... sourceCode

CycloneTCP is a dual IPv4/IPv6 stack dedicated to embedded applications. CycloneTCP conforms to RFC standards and offers seamless interoperability with existing TCP/IP systems. By supporting IPv6, CycloneTCP eases deployment of next-generation Internet. The stack is distributed as a full ANSI C and highly maintainable source code.

Best Regards,

Guillaume FORTAINE

[Giovanni]

Hi Guillaume,

It looks interesting but it is GPL-only so it is incompatible with the ChibiOS exception. Putting together the two things would nullify the exception making the combined work a pure GPL licensed system.

Giovanni

[skute]

Hi Giovanni,

Could you explain with a bit more detail as to what the problem is? I've mentioned elsewhere that I have a wrapper around ChibiOS and I'm wondering if I'm handling this correctly. Is the problem with the fact that nested chSysLock() calls aren't supported which will cause a context switch when it shouldn't?

My wrapper keeps track of the whether or not the system is running an ISR (chSysLock() calls, other than the chSysLockFromIsr(), aren't allowed in an ISR and "I" class functions are used) and also supports nested chSysLock() calls from thread contexts. I'm wondering why chSchRescheduleS() needs to be called after chSemSignalI() when "inside a lock" because if you are inside an ISR-Lock (chSysLockFromIsr()), then the reschedule will happen automatically when the ISR exits. Also, with nested locking supported, calling chSemSignal should do the right thing correct?

[Giovanni]

Hi,

if you call a non S or I class API from within a lock the called function will re-enable the interrupts prematurely (and the state checker will trigger an error).

The effect depends from what you have between the function and chSysUnlock(), it that code is assumed to be not-interruptable then you have a problem.

Example:

Code: Select all

  chSysLock();
  /* interrupts disabled */
  chSysLock();
  /* interrupts still disabled */
  chSysUnlock();
  /* interrupts prematurely enabled, this is the critical part */
  chSysUnlock();
  /* interrupts enbled again */

Note that this kind of errors are caught by the state checker, so if you debugged using that option then you don't have problems of this kind.

Giovanni

[skute]

So allowing nested locks does solve the problem. Perhaps this is a simple solution; if you want to use lwIP you have to enable nested chSysLock(). This was previously supported in chibiOS and I based my wrapper on this.

[Giovanni]

Nested locks were supported up to 2.2.x at cost of performance and code size. Since 2.4.0 nested locks are no more supported.

lwIP only needs a nested lock in the socket API, you could consider using the other API, that would save a lot of code/RAM space too. Note that nested locks are now threated as errors by the state checker.

Giovanni

[Giovanni]

Note that an easy fix could be implemented in lwIP by making it call an alternate function from that single point. Fix that point and lwIP would be come entirely non reliant on nested locks, probably its developers would also be interested in that.

Giovanni