This is a discussion on Re: excessive TCP dulplicate acks revisted - FreeBSD ; Gregory Wright wrote: > > 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 ...
Gregory Wright wrote:
> 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).
> 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?
We don't have an infrastructure to deal with this kind of driver
problems. You have to instrument the driver code to report stuck
firstname.lastname@example.org mailing list
To unsubscribe, send any mail to "email@example.com"