Re: ARP Queueing memory leak

lwip-users-bounces+christiaan.simons=axon.tv@... wrote
on 30-11-2005
13:07:07:

>
> After getting the latest revision in CVS, the inet.c (line 75) file is
> updated with "dataptr = ((char*)dataptr+2);" is replaced with line "(void
> *)((u16_t *)dataptr + 1);"
>
> This seems to be a bug or?
>

We've noticed this may be bug.

I was just fiddling to get it in
a workable state for the 16 bit c16x mcu.

The void pointer increment was clearly wrong,
the u16_t increment is only correct for aligned
input data.

The "two char" increment looks more correct,
but the routine will still fail for the c16x.

I'm a bit lost on how to get the checksumming
right for all architectures, both little-
an big-endian, 16-bit aligned and unaligned access.

The best thing you can do is stick with the lwip

inet.c bug

Oops, seems that I posted the message below with wrong heading - sorry.

My question below is still open.

Regards,

Kjell-Erik

  _____  

From: Kjell-Erik Klevan [mailto:kek@...] 
Sent: Wednesday, November 30, 2005 1:07 PM
To: 'Mailing list for lwIP users'
Subject: ARP Queueing memory leak

Hi!

After getting the latest revision in CVS, the inet.c (line 75) file is
updated with "dataptr = ((char*)dataptr+2);" is replaced with line "(void
*)((u16_t *)dataptr + 1);"

This seems to be a bug or?

Regards,

Kjell-Erik

(Continue reading)

Re: help! performance of lwip?

On 11/16/05, Cedric VINCENT <cedric.vincent@...> wrote:
> On 11/15/05, wang youramulet <wzroom@...> wrote:
> > hi,
> >
> > Is there anybody know lwip reasonable range of speed, such as send and
> > receive udp pakets? With and without the os, such as psos or ucosII.
>
> For instance, I reach up
> to 600 kBytes/s (receiving UDP packets) with current Xilinx drivers (on
> PPC 405   <at>  350 MHz, without OS),

When I-cache and D-cache are enabled, the target can receive (UDP) up
to 2 MBytes/s.

Regards,
Cedric.

--
------------------------------------------
http://cedric.vincent.perso.free.fr/
------------------------------------------

RE: PPP without an OS

Hi Karl,

Thank you for your reply, I would not used SLIP because the remote peer is not
windows and supports only PPP with authentication. I'll modify PPP to support
NO-OS version of lwIP.

Rémy

Hi Rémy,

I also looked at using PPP without an OS and changed my mind after
finding out that Windows supports SLIP. I don't need the authentication
and security.

I have a version of a SLIP driver that I could share, although it's
probably not public release ready.

Karl

Hello,

I'am trying to use the PPP stack for lwIP without an OS.
The ppp stack assumes that you use a multithreaded OS.

1) I'am wondering if someone has already used the PPP stack without an
OS.
2) I guess I have to rewrite the pppMain() function.
3) It seems that the sio_xxx functions are blocking functions, am I
right?
4) Is there a PPP port on win32 using the serial communication ports?

RE: PPP without an OS

Rémy,

  I attempted to do this and could get a PPP connection established with my
windows xp system (COM1 <-> COM2), I think I got it connecting over GPRS PPP
as well. I had some trouble with serving up all items of the test web page.
Ping worked fine. I haven't done any more work on this since early this
year.

  I built starting with the ports/msvc6 code base, adding in the ppp code
and opened up the while loop in
pppMain() so it becomes a function that is called repetitively like the
other tcp calls rather than the main() function of a process.

  Other work has to be done with the sys functionality which isn't too bad.
I set NO_SYS
and created the following functions:
dotimeouts function that handles struct sys_timeouts
Sys_arch_block function that busy waits.

And basic do nothing versions of:
sys_mbox_new, sys_mbox_free, sys_mbox_post, sys_arch_mbox_fetch,
sys_sem_new, sys_arch_sem_wait, sys_sem_signal, sys_sem_free, sys_init,
sys_arch_timeouts, sys_thread_new.

Regards
Mike

Re: PPP without an OS

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

Re: help! where can I get the latest and detailed document about lwip!

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

Re: LCP Termination Request missing

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

NIOS II port: Request for memory alignement macro to be included in lwip source

Hi

In Alteras uCOS II port of lwIP for NIOS II, 3 source files have been
changed.

__attribute__ ((aligned (MEM_ALIGNMENT))) is added to a few defs (5) to
control the memory alignment (gnu C syntax).

Patching the standard code base is by no mean the preferred method of
targeting alignment. I suppose that an array is always aligned at an
even boundary, but the 4-byte alignment is only achieved using
__attribute__ ((aligned (4))). 

It could easily be avoided adding a macro the defs below, e.g.:

#define MEM_ALIGMENT_ATTR __attribute__ ((aligned (MEM_ALIGNMENT)))

- or -

#define MEM_ALIGMENT_ATTR

The definition could then be:

static u8_t ram[MEM_SIZE + sizeof(struct mem) + MEM_ALIGNMENT]
MEM_ALIGMENT_ATTR;

Altera changes:

------------------------------------------------------------------------
----
mem.c                 
static u8_t ram[MEM_SIZE + sizeof(struct mem) + MEM_ALIGNMENT]
__attribute__ ((aligned (MEM_ALIGNMENT)));

------------------------------------------------------------------------
----ipfrag.c:
static u8_t ip_reassbuf[IP_HLEN + IP_REASS_BUFSIZE] __attribute__
((aligned (MEM_ALIGNMENT)));

static u8_t ip_reassbitmap[IP_REASS_BUFSIZE / (8 * 8)] __attribute__
((aligned (MEM_ALIGNMENT)));

static u8_t ip_reassbuf[IP_HLEN + IP_REASS_BUFSIZE] __attribute__
((aligned (MEM_ALIGNMENT)));

------------------------------------------------------------------------
----pbuf.c
static u8_t pbuf_pool_memory[(PBUF_POOL_SIZE *
MEM_ALIGN_SIZE(PBUF_POOL_BUFSIZE + sizeof(struct pbuf)))] __attribute__
((aligned (MEM_ALIGNMENT)));

------------------------------------------------------------------------
----

+ in dhcp.h a 
#if LWIP_DHCP==1 could be used to avoid defining protos when DHCP is
disabled.

Jan Ulvesten
SICOM

Re: NIOS II port: Request for memory alignement macro to be included in lwip source

Jan Ulvesten wrote:
>In Alteras uCOS II port of lwIP for NIOS II, 3 source files have been
>changed.
>
>__attribute__ ((aligned (MEM_ALIGNMENT))) is added to a few defs (5) to
>control the memory alignment (gnu C syntax).
>
>Patching the standard code base is by no mean the preferred method of
>targeting alignment. I suppose that an array is always aligned at an
>even boundary, but the 4-byte alignment is only achieved using
>__attribute__ ((aligned (4))). 
>
>It could easily be avoided adding a macro the defs below, e.g.:
>
>#define MEM_ALIGMENT_ATTR __attribute__ ((aligned (MEM_ALIGNMENT)))
>
>- or -
>
>#define MEM_ALIGMENT_ATTR
>
>The definition could then be:
>
>static u8_t ram[MEM_SIZE + sizeof(struct mem) + MEM_ALIGNMENT]
>MEM_ALIGMENT_ATTR;

That works well for those who have the problem and use gcc, but it
doesn't help those with the same problem who are not using gcc. I
don't think the solution requires the use of extensions, anyhow. If
the user can determine a data type with the greatest alignment
requirements, the compiler can do the dirty work -- in an ANSI-C
manner to boot.

For the code below, assume that in "cc.h" there is a typedef named
'max_align_t' that defines a data type that has the maximum alignment
requirements of the data types in the system.

>
>
>Altera changes:
>
>------------------------------------------------------------------------
>----
>mem.c                 
>static u8_t ram[MEM_SIZE + sizeof(struct mem) + MEM_ALIGNMENT]
>__attribute__ ((aligned (MEM_ALIGNMENT)));
>
Use max_align_t to ensure the RAM buffer is maximally aligned:

static union {
    max_align_t m; /* Guarantees this union has maximum alignment */
    u8_t ram[MEM_SIZE + sizeof(struct mem) + MEM_ALIGNMENT];
} rambuf;

static u8_t * const ram = rambuf.ram;

>------------------------------------------------------------------------
>----ipfrag.c:
>static u8_t ip_reassbuf[IP_HLEN + IP_REASS_BUFSIZE] __attribute__
>((aligned (MEM_ALIGNMENT)));
>
>static u8_t ip_reassbitmap[IP_REASS_BUFSIZE / (8 * 8)] __attribute__
>((aligned (MEM_ALIGNMENT)));
>
>static u8_t ip_reassbuf[IP_HLEN + IP_REASS_BUFSIZE] __attribute__
>((aligned (MEM_ALIGNMENT)));
>
Use struct ip_hdr to ensure that &ip_reassbuf[0] is a validly aligned
address for a struct ip_hdr object.

static union {
    struct ip_hdr h; /* Guarantees this union has proper alignment */
    u8_t buf[IP_HLEN + IP_REASS_BUFSIZE];
} ip_reass;

static u8_t * const ip_reassbuf = ip_reass.buf;

I don't think reassbitmap needs to be aligned since it appears to be
always accessed as a character array (although I may have missed some
code where it isn't). 

>------------------------------------------------------------------------
>----pbuf.c
>static u8_t pbuf_pool_memory[(PBUF_POOL_SIZE *
>MEM_ALIGN_SIZE(PBUF_POOL_BUFSIZE + sizeof(struct pbuf)))] __attribute__
>((aligned (MEM_ALIGNMENT)));
>
>------------------------------------------------------------------------
>----

As above, this object could be created as a union containing
max_align_t to ensure the buffer is properly aligned. This module
would probably benefit more from a replacing the u8_t array with just
an array of structures. They do not appear to be used in any other
way.

Just my suggestion for trying to keep the solution within hailing
distance of ANSI-C.

--

-- 
Derek Guerdon