#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: | assigned → waiting |
---|
comment:2 Changed on 06/22/05 at 20:32:00 by Eric Norum
Status: | waiting → closed |
---|
State-Changed-From-To: feedback->closed
State-Changed-Why: Realignment code now seems to work properly (and avoids copying entire
mbuf contents, too!)