Date: Mon, 12 Nov 2007 12:45:43 -0500 From: Gregory Wright <gwright@antiope.com> To: Andre Oppermann <andre@freebsd.org> Cc: freebsd-current@freebsd.org Subject: Re: excessive TCP dulplicate acks revisted Message-ID: <17995F62-7E9B-42E3-A7FA-30143C704C34@antiope.com> In-Reply-To: <473780DB.2040705@freebsd.org> References: <46B41421-3112-40C6-84D9-094FA771F93E@antiope.com> <4735CE3A.7020905@freebsd.org> <C621C4E4-4230-4658-B668-A0612B632565@antiope.com> <473780DB.2040705@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Nov 11, 2007, at 5:23 PM, Andre Oppermann wrote: > Gregory Wright wrote: >> On Nov 10, 2007, at 10:28 AM, Andre Oppermann wrote: >>> >> 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). > >> 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 The logs show that the duplicate ACKs are generated only by the receiver. I suspect a bug in the driver, perhaps the ACK packet is not being removed from the TX buffer ring. Examining the transmitted packets should be enough to rule out a network stack problem. Is there any debugging infrastructure I can use or do I just have to hack in on my own? Greg
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?17995F62-7E9B-42E3-A7FA-30143C704C34>