Date: Wed, 11 Sep 2002 09:11:11 -0700 (PDT) From: John Polstra <jdp@polstra.com> To: hackers@freebsd.org Cc: birger@takatukaland.de Subject: Re: bge problems (was: gigabit NIC of choice?) Message-ID: <200209111611.g8BGBBFT031897@vashon.polstra.com> In-Reply-To: <20020910105105.GA2863@lomin.exp-math.uni-essen.de> References: <20020910105105.GA2863@lomin.exp-math.uni-essen.de>
next in thread | previous in thread | raw e-mail | index | archive | help
In article <20020910105105.GA2863@lomin.exp-math.uni-essen.de>,
Birger Toedtmann <birger@takatukaland.de> wrote:
>
> just as this comes up, I have a question. Has anyone had experiences
> with the bge driver and related cards? We had some weird problems here
> lately:
>
> - bought two 3com 996-SX (fiber) cards and plugged them into
> ASUS A7M266-D boards with AMD Athlon 1.8GHz CPUs,
>
> - brought up FBSD 4.6 and tried some networking
>
> -->> All packets (to and fro) that where bigger than total IP length
> of 214 bytes were garbled. To be more specific, it seemed to
> us that some 8 byte regions haven't been copied correctly from
> the cards at some point when the packets were larger.
>
>
> (The boards worked fine with normal 100Mbit cards, BTW.)
>
>
> To make matters more interesting, we then put the (Gbit) cards into
> AMD-Duron-700MHz-Systems with 32bit bus only - as apposed to the A7M266-D
> which had a 64bit bus:
>
> -->> The cards worked just fine with all sorts (and sizes) of packets,
> but performance was - surpise, surprise - limited to 0.25 Gbit.
>
>
> So it seems there is some problem with the bge driver/card/64bit bus.
I use the 3c996B-T cards without any problems on a 64-bit bus. It's
an Intel-based machine (Dell 1550) rather than an Athlon, though.
It's possible that the problems you're seeing have something to do
with the chipset rather than with the width of the PCI bus.
All of the documentation and errata for the BCM570x chips are
protected by NDA, just like every other gigabit MAC in current
production. That makes it very difficult for us to maintain a working
driver. The only information we have is obtained by staring at
the Linux driver (which originates from Broadcom), making educated
guesses, and trying experiments. For example, in the Linux driver
obtained from the 3com web site, I see that there is a function
LM_DmaTest() which transfers a known data pattern using DMA and checks
for data corruption. This code might be present in the driver to
detect exactly the problem you've reported -- or maybe not. The only
way to find out is to try it.
It looks like if LM_DmaTest() finds corruption, it works around it by
putting a certain value into certain bits of a certain register.
You could try the equivalent in our driver and see if it works. In
if_bge.c, find the last occurrance of BGE_PCI_DMA_RW_CTL in
bge_chipinit():
#ifdef __brokenalpha__
/*
* Must insure that we do not cross an 8K (bytes) boundary
* for DMA reads. Our highest limit is 1K bytes. This is a
* restriction on some ALPHA platforms with early revision
* 21174 PCI chipsets, such as the AlphaPC 164lx
*/
PCI_SETBIT(sc, BGE_PCI_DMA_RW_CTL, BGE_PCI_READ_BNDRY_1024, 4);
#endif
After that, add this code (untested):
{ /* XXX experiment */
u_int32_t r;
r = CSR_READ_4(sc, BGE_PCI_DMA_RW_CTL);
r = (r & ~BGE_PCIDMARWCTL_WRADDR_BNDRY) | BGE_PCI_WRITE_BNDRY_16BYTES;
CSR_WRITE_4(sc, BGE_PCI_DMA_RW_CTL, r);
}
Who knows? Maybe you'll get lucky. :-)
If you want a gigabit interface that is likely to keep working in
FreeBSD, your only option is to use the Intel chips and the "em"
driver. It's our only gigabit driver that's maintained by somebody
who has unrestricted access to the documentation and errata.
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?200209111611.g8BGBBFT031897>