Date: Tue, 8 Aug 2006 11:28:05 -0700 From: "David (Controller AE) Christensen" <davidch@broadcom.com> To: pyunyh@gmail.com Cc: stable@freebsd.org, Scott Wilson <scott.wilson@gmail.com>, davidch@freebsd.org, Eric Hodel <drbrain@segment7.net> Subject: RE: Re: Re: bce0: Error mapping mbuf into TX chain! Message-ID: <09BFF2FA5EAB4A45B6655E151BBDD90301AB72BF@NT-IRVA-0750.brcm.ad.broadcom.com> In-Reply-To: <20060808003404.GA5411@cdnetworks.co.kr>
next in thread | previous in thread | raw e-mail | index | archive | help
> On Mon, Aug 07, 2006 at 01:48:09PM -0700, David (Controller=20 > AE) Christensen wrote: > > Scott, > >=20 > > What are you doing when this problem occurs? Is it something I can > > easily duplicate here? When I tested the fix on -CURRENT=20 > I used the > > following command suggested by Doug to bring out the=20 > failure quickly: > >=20 > > ssh <bad machine> "dd if=3D/dev/zero bs=3D1" > /dev/null > >=20 > > Does this same command fail for you too? > >=20 >=20 > 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. >=20 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(=20 > BCE_MAX_SEGMENTS =3D=3D 8) on GigE. Is this hardware limitation? >=20 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=20 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=20 > 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. :-( > > > > > > >=20 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 ;-)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?09BFF2FA5EAB4A45B6655E151BBDD90301AB72BF>