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
> <[EMAIL PROTECTED]>
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
_______________________________________________
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
