#806 closed defect (fixed)

Non-32bit-aligned MBUFs cause data corruption with uC5282 network driver

Reported by: Kolja Waschk Owned by: Eric Norum
Priority: highest Milestone: 2
Component: network/legacy Version: unknown
Severity: critical Keywords:
Cc: bugs@… Blocked By:
Blocking:

Description

The fec_sendpacket code in c/src/lib/libbsp/m68k/uC5282/network/network.c assures that data is aligned on 32 bit boundaries by moving it forward if necessary (i.e. towards a lower address, up to 3 bytes distance). The alignment is a requirement of the Ethernet controller integrated in the MCF5282.

A comment says "Given the way that mbuf's are layed out it should be safe to shuffle the data down like this.....".
However, this isn't true. I configured the webserver and asked it to serve me a file of about 2300 bytes in size, resulting in two Ethernet packets to be transmitted. And the first packet that I received (looking at it with tcpdump) had the last two bytes somehow replaced by the first to bytes of the second packet.

I rewrote the code so that data is moved towards higher addresses and that fixed the problem; both packets contained all correct data. But this is IMHO not a correct fix because at the higher address data might be overwritten by later packets. A correct solution would be to either allocate another, better aligned MBUF and copy the data there, or to assure the correct alignment beforehand in the network stack - that's why I initially set the category to 'Networking', not 'BSP'.

I'm currently trying to come up with a better fix soon.

Release:
CVS

Environment:
Target is a MCF5282 based board, BSP is a uC5282 derivative with no changes in network driver. Development host is x86 Linux with m68k-rtems-gcc 3.4.3. Other BSPs that use the same network driver are probably affected as well.

Change History (2)

comment:1 Changed on 06/20/05 at 19:51:12 by Eric Norum

Status: assignedwaiting

comment:2 Changed on 06/22/05 at 20:32:00 by Eric Norum

Status: waitingclosed

State-Changed-From-To: feedback->closed
State-Changed-Why: Realignment code now seems to work properly (and avoids copying entire
mbuf contents, too!)

Note: See TracTickets for help on using tickets.