Re: [Bugme-new] [Bug 38102] New: BUG kmalloc-2048: Poison overwritten

[Eric Dumazet <eric.dumazet@gmail.com>]

Le mardi 05 juillet 2011 à 22:02 +0200, Eric Dumazet a écrit :
> Le mardi 05 juillet 2011 à 15:53 -0400, Neil Horman a écrit :
> > I think this is a goo idea, at least for testing.  It seems odd to me that we
> > have the B44_DMARX_PTR value which indicates (ostensibly) the pointer to the
> > descriptor to be processed next (the documentation isnt' very verbose on the
> > subject), along with the EOT bit on a descriptor.  It seems like both the
> > register and the bit are capable of conveying the same (or at least overlapping)
> > information.
> > 
> > I think what I'm having the most trouble with is understanding when the hw looks
> > at the EOT bit in the descriptor.  If it completes a DMA and sees the EOT bit
> > set, does the next DMA occur to the descriptor pointed to by the DMARX_ADDR
> > register?  Of does it stall until such time as the DMARX_PTR register is rotated
> > around?  What if it doesn't see the EOT bit set?  Does it just keep going with
> > the next descriptor?  

Since there is no OWN bit (at least not on the online doc I got : it
says the rx_ring is read only by the NIC), I would say we really need to
advance DMARX_PTR to signal NIC a new entry is available for following
incoming frames.

This is the reason rx_pending max value is B44_RX_RING_SIZE - 1, or else
chip could loop on a circular rx_ring.