[Avila] fatal ethernet error on gw2348-4

[Tim Harvey]

Tom,=0A=0ACould you please point us to the info regarding the GPL NPE drive=
rs.  I was aware of a project a while back that was abandoned and haven't s=
een anything since.=0A=0A(By the way, I have no issues bridging or with spu=
rious unhandled interrupts using 2.6.15-uc0 and NPEv1.4)=0A=0AThanks,=0A=0A=
Tim=0A=0A----- Original Message ----=0AFrom: Loft <Loft at nc.rr.com>=0ATo: Av=
ila <avila at lists.unixstudios.net>=0ASent: Thursday, November 2, 2006 10:09:=
52 AM=0ASubject: Re: [Avila] fatal ethernet error on gw2348-4=0A=0AGianluca=
 Mando' wrote:=0A=0AGianluca and others,=0A=0AThe following is all about th=
e Avila hardware platform (specifically the =0AGW2348).  Giant Shoulder, In=
c. received some of the very first GW2348's =0Aback in Q3 of '05.  There wa=
s a great visions for using the device as a =0ASOHO web server platform (Gi=
ant Shoulder, Inc.  sells the USB 2.0 =0Aoption).  While the market target =
was flawed, the software and hardware =0Awork very well.=0A=0AI'm putting f=
inal touches on a BSP for the upcoming 2.6.19 series.  I'm =0Arunning 2.6.1=
9-rc3 and 2.6.19-rc4 in both Big and Little Endian.  2.6.18 =0Awas done a l=
ittle while ago.  The 2.6.18 and .19-rc releases use the GPL =0A(non-Intel)=
 NPE drivers. There's no support for the crypto processing in =0Athe open d=
rivers yet, but I hear it's on the way.=0A=0AAfter over two years of runnin=
g the Intel NPE drivers on 2.6.x, I can =0Asay I don't miss them at all. Th=
e new driver can be statically link into =0Athe kernel and current patches =
pull the microcode from RedBoot.  NFS =0Abooting with the drivers staticall=
y linked in works.=0A=0AGenerally, bridging/netfilter work with eth0/eth1 a=
nd ath0..n as of =0A2.6.16.  I haven't done much bridging testing, but a cl=
ient of mine does =0Athat and is testing 2.6.18.   There are some corner ca=
ses and setup =0Aissues, but hey it's open source.  Most of the significant=
 changes will =0Awind up in the mainline kernel in the next few releases (m=
onths) after =0Abeing submitted to the Linux-ARM-Kernel mailing list.=0A=0A=
If you are interesting professional support, please feel free to contact me=
.=0A=0ABest regards,=0A=0ATom Billman=0AGiant Shoulder, Inc.=0A> David,=0A>=
=0A> did you find some solution to this heavy problem?=0A>=0A> We need to o=
perate the avila in bridge mode (it is the most important and basic=0A> fea=
ture of any commercial AP ...) and we have descovered that the ethernet=0A>=
 ports filter received frames, while it keeps to be able to transmit frames=
.=0A> This is a blocking issue for the development of our product.=0A>=0A> =
I think this is a "heavy" bug of the avila board (it cannot be used for=0A>=
 developing neither a simple access point). Gateworks guys providing suppor=
t for=0A> the board should say if it is a real problem (i.e. it is not caus=
ed by some=0A> misconfiguration of bridging feature, but we repeated the te=
st several times,=0A> using the classic bridging commands between eth0 and =
ath0) and should help us to=0A> provide a solution.=0A>=0A> Regards,=0A> Gi=
anluca=0A>=0A>=0A>=0A> Scrive David Acker <dacker at roinet.com>:=0A>=0A>   =
=0A>> devel wrote:=0A>>     =0A>>> ARGH!!! Its back again. I'm not seeing t=
he fatal error message on the=0A>>> console, but I still from time to time =
am not receiving on the eth0 port=0A>>> for some computers. I may increase =
the buffer number from 64 to=0A>>> something else, 128? I'm not sure what t=
hat could possibly do to the NPE=0A>>> driver. Any thoughts?=0A>>>=0A>>> Tr=
avis=0A>>>       =0A>> When I mistakenly created a broadcast loop by having=
 two routers=0A>> connected by both ethernet and a wireless connection I fo=
und that=0A>> eventually ethernet receive would fail again.  I need to rese=
arch this=0A>> more.  I believe the problem is related to having ethernet i=
n=0A>> promiscuous mode and lots of broadcast traffic.  Note this quote fro=
m=0A>> the intel source about the IX_ETHACC_NE_FILTERMASK flag:=0A>> "Certa=
in frames, which should normally be fully filtered by the NPE to=0A>> due t=
he destination MAC address being on the same segment as the Rx port=0A>> ar=
e still forwarded to the XScale (although the payload is invalid) in=0A>> o=
rder to learn the MAC address of the transmitting station, if this is=0A>> =
unknown.  Normally EthAcc will filter and recycle these framess=0A>> intern=
ally and no frames with the FILTER bit set will be received by the=0A>> cli=
ent."=0A>>=0A>>=0A>> I need to walk through this code more deeply.  The fir=
st time through I=0A>> was just focused on getting rid of the error message=
.  Now it seems=0A>> there is another problem.=0A>> -Ack=0A>>=0A>> --------=
-------------------------------------------------------------=0A>> To unsub=
scribe, e-mail: avila-unsubscribe at lists.unixstudios.net=0A>> For additional=
 commands, e-mail: avila-help at lists.unixstudios.net=0A>>=0A>>=0A>>     =0A>=
=0A>=0A>=0A>=0A> ----------------------------------------------------------=
------=0A> This message was sent using IMP, the Internet Messaging Program.=
=0A>=0A>=0A> --------------------------------------------------------------=
-------=0A> To unsubscribe, e-mail: avila-unsubscribe at lists.unixstudios.net=
=0A> For additional commands, e-mail: avila-help at lists.unixstudios.net=0A>=
=0A>   =0A=0A=0A-----------------------------------------------------------=
----------=0ATo unsubscribe, e-mail: avila-unsubscribe at lists.unixstudios.ne=
t=0AFor additional commands, e-mail: avila-help at lists.unixstudios.net=0A=0A=
=0A=0A