[#5600] tcp checksum fails sometimes if WB data cache is enabled on bf527-ezkit

Document created by Aaronwu Employee on Sep 5, 2013
Version 1Show Document
  • View in full screen mode

[#5600] tcp checksum fails sometimes if WB data cache is enabled on bf527-ezkit

Submitted By: Sonic Zhang

Open Date

2009-10-13 03:32:43    


Medium     Assignee:

Sonic Zhang


Open     Fixed In Release:


Found In Release:

2009R1-RC6     Release:


N/A     Board:



BF527     Silicon Revision:

Is this bug repeatable?:

Yes     Resolution:

Assigned (Not Start)

Uboot version or rev.:

    Toolchain version or rev.:


App binary format:


Summary: tcp checksum fails sometimes if WB data cache is enabled on bf527-ezkit



tcp checksum fails sometimes if WB data cache is enabled. It disappears in WT data cache mode. hardware checksum is not used when calculating checksum. Could be a cache sync issue in bfin MAC driver.


See question in help forum:





--- Sonic Zhang                                              2009-10-15 03:10:12



Should invalid data cache for each new rx skb buffer once before it is link to

rx dma loop.


--- Sonic Zhang                                              2009-10-22 04:37:37

It looks the RX skb DMA buffer under WB cache is affected by dev_kfree_skb(skb)

in bfin mac xmit function.


In current desing, a TX skb is hooked to the TX DMA ring in xmit function. It

is not freed until its DMA is done and xmit is invoke for the next TX skb.


If the skb is freed immediately before exit xmit function. This bug disappears.

This is an possible walkaround. But, I can't find any clue on why freeing a TX

skb sometime later may corrupt a RX skb buffer under WB cache mode.



--- Sonic Zhang                                              2009-10-22 04:40:22

In addition, slab, slob or slub make no difference. TX/RX DMA rings in L1 or

SDRAM make no difference.



--- Sonic Zhang                                              2009-11-09 01:27:01

The skb buffers with wrong checksum are always at the same addresses if you ftp

a big file to board for several times. So, I recently attach a range watch

pointer to one skb buffer, which is confirmed to have wrong checksum at the

first ftp transfer. After ftp a big file again, the result shows no kernel

writing operation to this buffer although its checksum is wrong again.


So, I don't think this is a bug in kernel. Since the data cache of this buffer

is flushed and invalidated before it is hook to the DMA ring and no CPU writing

to it afterward, it looks the DMA operation get corrupted in the middle of a rx

transfer in WB data cache mode.


--- Sonic Zhang                                              2009-11-09 01:44:29

or FLUSHINV doesn't always do as expected in write back cache mode.


--- Stefan Wanja                                             2010-04-19 09:28:03

Just a hint for testing, we can reproduce it easyly within seconds using iperf

server on the ezkit and iperf with the -d (dual) option on a pc. Produces a lot

of data...


--- Stefan Wanja                                             2010-04-19 12:25:25

And another hint: I can see similar behaviour on a bf527 0.3 EZkit!


--- Stefan Wanja                                             2010-04-19 12:26:33

Sorry, bf537 is what I meant to write.


(And another hint: I can see similar behaviour on a bf537 0.3 EZkit!)


--- Stefan Wanja                                             2011-04-28 11:49:09

Hello, are there any news on this?


--- Sonic Zhang                                              2011-04-28 23:34:57

Not yet.












File Name     File Type     File Size     Posted By

No Files Were Found