bce0: Error mapping mbuf into TX chain!

[David (Controller AE) Christensen]

> On Mon, Aug 07, 2006 at 01:48:09PM -0700, David (Controller 
> AE) Christensen wrote:
>  > Scott,
>  > 
>  > What are you doing when this problem occurs?  Is it something I can
>  > easily duplicate here?  When I tested the fix on -CURRENT 
> I used the
>  > following command suggested by Doug to bring out the 
> failure quickly:
>  > 
>  > ssh <bad machine> "dd if=/dev/zero bs=1" > /dev/null
>  > 
>  > Does this same command fail for you too?
>  > 
> 
> Since BCE_MAX_SEGMENTS is too small I guess it will happen on highly
> fragmented packets under heavy loads. To simulate the situation
> you can use m_fragment(9) to fragment the frame in bce_tx_encap().
> With m_fragment(9), "ping -f -s 65507 x.x.x.x" may trigger it.
> 

I didn't know about m_fragment before.  I'll write a note to myself
and look at how to add it to the debug path for a future driver
revision.

> Btw, I've never seen this small number of Tx DMA segments support( 
> BCE_MAX_SEGMENTS == 8) on GigE. Is this hardware limitation?
> 

The real value for BCE_MAX_SEGMENTS should be 16, not 8.  I chose 8 as a
reasonable value to start with.  If the number of fragments exceeds 16 
then we would expect to see performance drop and it is probably faster
to
have the OS defragment the packet rather than try to perform so many
DMAs.

>  > > > Hmm... I can see several bus_dma(9) related bugs in bce(4).
>  > > > For architectures that have IOMMU hardware it may have 
> corrupted DMA
>  > > > mapping and I'm pretty sure it wouldn't work on sparc64.
>  > > > When it has to handle many fragmented frame or has insufficient
>  > > > number of free Tx descriptors it would show unexpected results.
>  > > > Unfortunately I don't have hardwares supported by bce(4) and
>  > > > fixing requiries a working hardware. :-(
>  > > >
>  > > 

If I were able to get you a 5706 (PCI-X) or 5708 (PCI-Express) NIC would
you be willing to put some time into helping sort out any bus_dma
related
issues?  I have the opposite problem and don't have any Sparc64 system
to
use for testing, plenty of NICs though ;-)