Date: Sun, 23 Jun 2002 08:52:28 -0700 (PDT) From: paleph@pacbell.net To: freebsd-hackers@freebsd.org Cc: freebsd-net@freebsd.org Subject: Re: Re: bge driver issue Message-ID: <200206231552.g5NFqS002122@pacbell.net>
next in thread | raw e-mail | index | archive | help
John. Thanks for the tip. I changed ETHER_ALIGN to 0 and the driver started to work. I am not sure about the performance since I seem to get only 50 Mbit over a 100 Mbit line. However this is much better than the timeout warnings... Thanks for the input. It is really appreciated. Do you need any other experiments done? We're going to ship the 2650 back to Dell for other reasons (form factor and noise). Paul Fronberg paleph@pacbell.net >In article <200206182206.g5IM6P003388@pacbell.net>, > <paleph@pacbell.net> wrote: >> We have a Dell poweredge 2650 (successor to 2550). >> >> We also saw the same problem with 4.5. I tried the current bge driver from 4.6> without success. The problem seems to be a size problem. When we ftp a small >> file, things work fine. However, when we try a 18 Megabyte file, the ftp >> hands and we see the problem descriped below. The linux system that came >> with the hardware (from dell) worked fine. > >On the 2650 or any other x86 PCI-X system, please try the following >simple experiment. Edit "src/sys/dev/bge/if_bgereg.h". Find this >line: > > #define ETHER_ALIGN 2 > >Change the "2" to "0". Build and install a new kernel. See whether >it solves the problem. > >Here is the reasoning behind the experiment. The bge driver sets >things up so that the NIC DMAs received packets into mbuf clusters >starting ETHER_ALIGN bytes from the beginning of the buffer. That is >done so the payload after the 14- or 18-byte Ethernet header will be >aligned in memory at a 4-byte boundary. The Linux driver from 3Com >for the 3c996B-T does the same thing. However, on PCI-X busses only, >that driver disables the 2-byte offsetting and stores received packets >at the very beginning of the buffer in memory. It is reasonable to >assume that they went to all that trouble for a reason -- for example, >a chip bug. > >This change will impact performance on the x86 architecture, and it >will flat-out break Alphas and most other architectures. The actual >fix would have to be more intelligent, but this is just an experiment. > >Please report back after you have tried this change. I know two >people who have reported that it solved the problems they were having >with BCM5701 chips in PCI-X systems. > >John >-- > John Polstra > John D. Polstra & Co., Inc. Seattle, Washington USA > "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200206231552.g5NFqS002122>