[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <15531494-BB50-49B3-B2A8-7E51AB3DDBF9@kernel.crashing.org>
Date: Mon, 11 Sep 2006 15:54:24 +0200
From: Segher Boessenkool <segher@...nel.crashing.org>
To: Benjamin Herrenschmidt <benh@...nel.crashing.org>
Cc: Michael Chan <mchan@...adcom.com>, netdev@...r.kernel.org,
"David S. Miller" <davem@...emloft.net>,
Linux Kernel list <linux-kernel@...r.kernel.org>
Subject: Re: TG3 data corruption (TSO ?)
>>> #define tw32_rx_mbox(reg, val) do { wmb();
>> tp->write32_rx_mbox(tp, reg, val); } while(0)
>>> #define tw32_tx_mbox(reg, val) do { wmb();
>> tp->write32_tx_mbox(tp, reg, val); } while(0)
>>>
>>
>> That should do it.
>>
>> I think we need those tcpdump after all. Can you send it to me?
>
> Looks like adding a sync to writel does fix it though... I'm trying to
> figure out which specific writel in the driver makes a difference.
> I'll
> then look into slicing those tcpdumps.
Adding a PowerPC "sync" to every writel() will slow down things by
so much that it could well just hide the problem, not solve it...
Michael, we see this problem only with TSO on, and then the failure
we see is bad data being sent out, with the correct header (but the
header is constructed by the tg3 in this case, so no surprise).
I'm theorizing that this same failure can happen with TSO off as well,
but the header sent on the wire will be bogus as well as the data,
so the receiving NIC won't pick it up. tcpdump probably won't see
it either... will need a low-level ethernet analyser.
Segher
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists