[Avila] Gateworks and the Intel NPEs

[Tim Harvey]

I would have to agree with Dave here as to where the problem is.  I have be=
en using the IAL (with npe_learning=3D0) for quite some time and I've never=
 run into this problem (at least that I know of).  Travis, do you have a si=
mple test case that shows this problem?  What other components are you usin=
g in your setup (madwifi/hostap/bridge?).=0A=0ADave, any target date for yo=
ur next BSP?=0A=0AI've been working on updating my kernel, however I use sn=
apgear for userland with glibc.  I've found that the glibc-2.25 that snapge=
ar uses is very outdated and has issues building with newer toolchains whic=
h are required to build the latest kernels.  Therefore, if your using snapg=
ear+glibc+linux-2.6.18+ you have to use a different toolchain for building =
the kernel as you do for snapgear userland (glibc specifically).  I'm not s=
ure how easy it is to update glibc in snapgear (I notice that snapgear 3.4.=
0 does not even include glibc).=0A=0ASo, what are you people using with you=
r newer kernels with regards to userland?  buildroot?=0A=0AThanks,=0A=0ATim=
=0A=0A----- Original Message ----=0AFrom: Dave G <daveg at unixstudios.net>=0A=
To: Avila <avila at lists.unixstudios.net>=0ASent: Friday, January 5, 2007 12:=
00:00 PM=0ASubject: Re: [Avila] Gateworks and the Intel NPEs=0A=0AHi Travis=
/List,=0A=0A=0AI can comment on the roadmap question. Our plans are to incl=
ude latest IAL =0Aas well as the GPL driver in our next BSP release so you =
can choose either =0Ato use.=0AWe currently don't have plans to dig into th=
e IAL code to do repair work, =0Ahowever if the next IAL release exhibits t=
he same issues previous releases =0Ahave we likely would dig into it to see=
 what we can find. As you all know =0Athe IAL code is developed and provide=
d by Intel and not by Gateworks.=0A=0A=0AMy own thoughts on the reported IA=
L/NPE issues are probably not shared by =0Amost. Because it seems that the =
reported IAL issues persist over different =0Aversions of the IAL and also =
since Intel has failed to acknowledge and/or =0Arepair the reported issues,=
 I suspect that there may not be any issues =0Awhatsoever in the IAL or if =
there are they may be very minor. I find it hard =0Ato believe that Intel w=
ould continue to release IAL versions which exhibit =0Athe same reported is=
sues without Intel doing anything about it if such =0Aissues indeed existed=
 and were validated by Intel. I realize that many of =0Athe IAL releases ar=
e just feature/cpu upgrades and not always fixes.=0A=0AIMHO I think that th=
e reported issues could very well be related to the =0Aenvironment or manne=
r in which many of us use the NPEs.=0A=0AFor example, the npe_learning=3D0 =
argument passed to the ixp400_eth module =0Aturns off MAC learning in the I=
AL/driver. This argument MUST be used if the =0ANPE is to be a part of a br=
idge where MAC learning is already being done =0A(Linux ethernet bridging).=
 Without turning off npe_learning in the IAL some =0Afunky things happen.=
=0ALooking at the various available microcode (the microcode loaded into th=
e =0ANPE) and the different features that each of them employ causes me to =
=0Asuspect that I might have a problem down the road because the IAL is doi=
ng =0Asomething like:=0A=0ANPEA_ETH_SPAN_MASK_FIREWALL_VLAN_QOS_HDR_CONV_EX=
TMIB=0ANPEA_ETH_SPAN_VLAN_QOS_HDR_CONV_EXTMIB=0ANPEA_ETH_LEARN_FILTER_SPAN_=
MASK_FIREWALL_VLAN_QOS_EXTMIB=0ANPEB_ETH_LEARN_FILTER_SPAN_FIREWALL_VLAN_QO=
S=0ANPEB_ETH_SPAN_FIREWALL_VLAN_QOS_HDR_CONV=0A=0Ayet I am planning on doin=
g some of the same in the kernel via iprout2, =0Aiptables, etc, etc.=0A=0AI=
 haven't looked deeply into even if the above features are actually being =
=0Aperformed in the NPE or how to control them, except that I know using =
=0Anpe_learning=3D0 absolutely cleans up the bridging issues I was experien=
cing =0Awhen ixp0/ixp1 was part of a bridge group. Additionally I haven't l=
ooked =0Aspecifically at the ramifications of the NPE microcode doing somet=
hing like =0AHDR_CONV while I am doing iptables -t mangle stuff.=0A=0AAnywa=
y, if we end up experiencing IAL/NPE issues after this next BSP release =0A=
I would suspect that we would begin looking in the above described areas.=
=0A=0A=0AThanks!=0A=0A=0A-Dave G=0A=0A=0A=0A=0A=0A=0A=0AHey list,=0A=0A    =
I am just wondering where Gateworks stands with the Intel NPEs. We've =0Aal=
l seen the posts about the receive buffer problems (in promiscuous mode) =
=0Asome of us have had with the Intel driver currently released with the BS=
Ps. =0ACurrently, we still have this issue and it remains a big problem for=
 us. =0AThis of course doesn't allow a confident Wi-fi access point.=0A=0A =
   I have seen that a lot of you are switching over to the open source NPE =
=0Adriver, NSLU2 correct? Is this the direction that everyone is going and =
does =0AGateworks have a roadmap to possibly solve the issue with the BSP r=
eleased =0ANPE driver? Or are they recommending everyone just use the open =
source =0Aversion?=0A=0A    Hopefully this ends up being an easy answer. I =
know a few of us have =0Alooked at this ourselves, in particular David Acke=
r. Some of the things =0ADavid had found ended up not working for both of u=
s. However, I have tried =0Awhat was last stated by David and Dave G on reg=
ards to the modprobe line:=0A=0A    modprobe ixp400=0A    cat /etc/IxNpeMic=
rocode.dat > /dev/ixNpe=0A    modprobe ixp400_eth npe_learning=3D0=0A=0A   =
 Even with adding the npe_learning=3D0 option for the modprobe of =0Aixp400=
_eth, we have still seen periods of dropped packets just as before. =0AAny =
thoughts would be greatly appreciated. Thanks.=0A=0A=0ATravis =0A=0A=0A----=
-----------------------------------------------------------------=0ATo unsu=
bscribe, e-mail: avila-unsubscribe at lists.unixstudios.net=0AFor additional c=
ommands, e-mail: avila-help at lists.unixstudios.net=0A=0A=0A=0A