Re: excessive TCP dulplicate acks revisted

From: Andre Oppermann <andre_at_freebsd.org>
Date: Sun, 11 Nov 2007 23:23:23 +0100
Gregory Wright wrote:
> 
> On Nov 10, 2007, at 10:28 AM, Andre Oppermann wrote:
> 
>> Gregory Wright wrote:
>>> (Note: long message)
>>> Hi,
>>> The tcp duplicate ACK attack is back.
>>> Last March, there was a thread on duplicate TCP acks in -CURRENT.
>>> I have been able to reproduce the problem on 7.0-BETA2 (amd64)
>>> and have some new information that might help locate the bug.
>>> Background:  I first noticed problems with tcp connections dropping
>>> when Bacula was running on our backup server.  The hardware was
>>> a dual Opteron 244, 2 GB RAM, running FreeBSD 6.2-RELEASE-p2.
>>> The ethernet NIC was a bge.
>>> We went through an extensive process to rule out hardware and cabling
>>> problems:  the server hardware was replaced with a single Opteron 270
>>> (dual core) on a Tyan S2882-D motherboard.  The memory was replaced
>>> as well.  The NICs are still bge.  This machine is "hardtack".
>>
>> This may be a TSO bug in the bge hardware.  Please repeat your tests in
>> the original setup with TSO disabled on the bge interfaces ("ifconfig 
>> bgeX -tso").
>> Second if you've got another network card with something else than bge
>> please put it into the same box and run the tests as well.
>>
>> --Andre
>>
> 
> Hi Andre,
> 
> I also took a look at the bge (4) driver in 7.0-BETA2.  As far as I can 
> tell,
> it does not support TSO (there is no ioctl supporting TSO enable/disable
> as there is for the em(4) driver).

OK.

> Might the chip --- a BCM5704_B0 --- not be completely initialized?  This
> might explain why the machine with the BCM5714_B3 chips works, while
> the other machine shows the duplicate ACK bug.

Perhaps.  Do you see the duplicate ACKs in a tcpdump on both the sender
and the receiver?  If you see it on the sender too, then it must be a
bug in our network stack or the driver (by requeuing the same packet
over and over again).

-- 
Andre
Received on Sun Nov 11 2007 - 21:23:27 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:21 UTC