Date: Mon, 26 Jan 2004 00:28:41 -0500 From: Stephan Uphoff <ups@tree.com> To: Matthew Dillon <dillon@apollo.backplane.com> Cc: Robert Watson <rwatson@freebsd.org> Subject: Re: XL driver checksum producing corrupted but checksum-correct packets Message-ID: <200401260528.AAA32688@stups.com> In-Reply-To: Message from Matthew Dillon <dillon@apollo.backplane.com> <200401251936.i0PJaYXt043844@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Matthew Dillon wrote: > > When I turn off transmit checksums on the client side, the problem does > not occur. However, I do not know whether that is because the server is > now rejecting the packet as having a bad checksum due to the packet > data being corrupted by the XL card as it is being sent, or whether it > is because the client is no longer sending a corrupt packet. > > -Matt > Matthew Dillon > <dillon@backplane.com> Hi, this behavior could be explained by a small xl driver bug. xl_start_90xB() puts packages on the transmit queue. The dma engine loads the packages and marks the related queue entry as complete. xl_txeof_90xB() looks for entries marked complete and m_freem()'s the related buffer. Transmit errors cause xl_txeoc() to be called. On some errors xl_txeoc() resets the queue pointer for the dma engine to entries already marked as complete. (and also does not stop the dma engine) Since transmit and the download engine are fairly independent a dma completion status interrupt can be generated after a transmit error interrupt. The transmit error can reset the dma engine to already completed entries and an already pending dma completion can then free the associated mbufs before they are successfully uploaded a second time. => data corruption. Solution: Someone with a good set of manuals and 3com cards should look how to stop the dma engine on serious transmit errors and then either remove all DMA completed entries from the queue or reset their completion marker bits. Unfortunately I have neither manuals nor cards. Stephan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200401260528.AAA32688>