Re: XL driver checksum producing corrupted but checksum-correct packets

From: Stephan Uphoff (ups_at_tree.com)
Date: 01/26/04

  • Next message: Poul-Henning Kamp: "Re: code compatibility between normal and geom methods for accessingdisk devices" 
    To: Matthew Dillon <dillon@apollo.backplane.com>
Date: Mon, 26 Jan 2004 00:28:41 -0500

    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

    _______________________________________________
    freebsd-hackers@freebsd.org mailing list
    http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
    To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"

  • Next message: Poul-Henning Kamp: "Re: code compatibility between normal and geom methods for accessingdisk devices"