[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <C562D0E12CBDE44E8A0CCAB77060096705DE3B@AVMB1.qlogic.org>
Date: Wed, 23 Jan 2013 19:47:32 +0000
From: Rajesh Borundia <rajesh.borundia@...gic.com>
To: Eric Dumazet <eric.dumazet@...il.com>,
Ben Hutchings <bhutchings@...arflare.com>
CC: "christoph.paasch@...ouvain.be" <christoph.paasch@...ouvain.be>,
Ian Campbell <Ian.Campbell@...rix.com>,
Sony Chacko <sony.chacko@...gic.com>,
David Miller <davem@...emloft.net>,
netdev <netdev@...r.kernel.org>
Subject: RE: BUG in netxen_release_tx_buffers when TSO enabled on kernels >=
3.3 and <= 3.6
>-----Original Message-----
>From: Eric Dumazet [mailto:eric.dumazet@...il.com]
>Sent: Wednesday, January 23, 2013 1:30 AM
>To: Ben Hutchings
>Cc: christoph.paasch@...ouvain.be; Ian Campbell; Sony Chacko; Rajesh
>Borundia; David Miller; netdev
>Subject: Re: BUG in netxen_release_tx_buffers when TSO enabled on
>kernels >= 3.3 and <= 3.6
>
>On Tue, 2013-01-22 at 19:36 +0000, Ben Hutchings wrote:
>
>> There's another bug right here, which is that 0 is a valid DMA address
>> in some systems. The driver should be calling pci_dma_mapping_error()
>> to find out whether an address is valid or not. But it also wants to
>be
>> able to assign an invalid address to netxen_skb_frag::dma, and
>> unfortunately there is no way to do that in the current DMA API.
>>
>
>I guess we should only test ->frag_count then, and set it to 0 in TX
>completion path.
>
We will send a patch with the suggested fix.
Powered by blists - more mailing lists