[#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

Priority:

Medium Assignee:

Sonic Zhang

Status:

Open Fixed In Release:

N/A

Found In Release:

2009R1-RC6 Release:

Category:

N/A Board:

N/A

Processor:

BF527 Silicon Revision:

Is this bug repeatable?:

Yes Resolution:

Assigned (Not Start)

Uboot version or rev.:

Toolchain version or rev.:

2009R1

App binary format:

N/A

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

Details:

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:

http://blackfin.uclinux.org/gf/project/uclinux-dist/forum/?_forum_action=ForumMessageBrowse&thread_id=36477&action=ForumBrowse

Follow-ups

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

Fixed.

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.

Files

Changes

Commits

Dependencies

Duplicates

Associations