James wrote:
On 7/10/07, Tom Judge <[EMAIL PROTECTED]> wrote:
Ok so I think I have fix the problem with the rx_bd tracking. I
have ported rboyer's patch to NetBSD's bnx driver to FreeBSD (patch
attached). The patch seems to get rid of two problems:
1) Unexpected mbuf in rx_bd
2) Too many free rx_bd's
Hi Tom. Thanks much for your work with this problem. I'm
effected by major bce problems as well. Right now I'd be happy to
get it working properly with an MTU of 1500. To that end I'm
unable to get your patch to apply cleanly to my FreeBSD 6.2 tree.
Most likely I've lost track of what patches in this thread to
apply before your patch.
If you have time, would you be so kind to cook a diff against a
vanilla FreeBSD 6.2 tree or let me know which patches to apply
first?
Thanks!
A full patch against RELENG_6_2 (p5) is avaliable here:
http://www.tomjudge.com/tmp/bce-patch-full-10-7-2007.gz
You will also require this patch to sys/net/if_media.h that adds the
2.5Gb/s media definitions:
http://www.tomjudge.com/tmp/if_media.h-patch-10-7-2007.gz
These patches should be applied in /usr/src/sys/dev/bce and
/usr/src/sys/net respectively. (e.g: cd /usr/src/sys/dev/bce; patch <
/path/to/patch)
This patch includes:
* The latest driver from RELENG_6 (See
http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/bce/if_bce.c?only_with_tag=RELENG_6
for details ). NOTE: This does not include MSI support as 6.2 does not
have MSI support.
* David's patch to enable dumping the first 128 bytes of a bad packet
* Stepherosa's patch which attempts to fix problems in the rx buffer
(de)allocation during bce_rx_intr.
* My patch from NetBSD that completely rewrites the way that the rx
buffers are (de)allocated. Rather than allocate them on the fly in
bce_rx_intr. Try to pre allocate as many as possible, and then allocate
more during the bce_tick routine.
Please let me know if you have any problems applying this patch, as this
patch was generated from my subversion repository.
On a side note, I have some systems (Dell PE2950's) running the
vanilla 6.2 driver which are stable, they have a standard 1500 byte MTU.
However these systems are not running such network intensive tasks as
the ones with a 8192 byte MTU.
On another side note it seems that OpenBSD removed Jumbo frame support
from their driver 4 months ago as it was causing panics under high load
however FreeBSD and NetBSD both have Jumbo frame support enabled.
Tom
_______________________________________________
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
