mpc52xx: Correct calculation of FEC RX errors???

Hi

We are showing figures of more than 4 billion error frames in our=20
ethernet interfaces. We have tested that the problem is in a=20
substraction (the number of errors decrements with the number of =
frames).

So... looking in the fec driver (fec.c) for the calculations we have=20
seen that the number of multicast packets is added to the number of=20
correct frames in order to get the frame errors...

But the interesting thing is that we have checked that this calculation=20
is something that we have added with a patch by Grzegorz Bernacki in=20
this list.

So... The funny thing is... Why a patch that solves the problem for=20
Grzegorz produces "the same problem" for us?

And... by the way... I have seen IEEE802.3, and when they talk about=20
aFramesReceivedOK (which I suppose is the ieee_r_frame_ok in the=20
driver), and they do not say a word about not including multicast=20
packets in it...

Any comment will be appreciate.

Miguel =C1ngel =C1lvarez
**=20
=20
----------------------------------------- PLEASE NOTE =
-------------------------------------------
This message, along with any attachments, may be confidential or legally =
privileged.=20
It is intended only for the named person(s), who is/are the only =
authorized recipients.
If this message has reached you in error, kindly destroy it without =
review and notify the sender immediately.
Thank you for your help.
ZIV uses virus scanning software but excludes any liability for viruses =
contained in any attachment.
=20
------------------------------------ ROGAMOS LEA ESTE TEXTO =
-------------------------------
Este mensaje y sus anexos pueden contener informaci=F3n confidencial y/o =
con derecho legal.=20
Est=E1 dirigido =FAnicamente a la/s persona/s o entidad/es rese=F1adas =
como =FAnico destinatario autorizado.
Si este mensaje le hubiera llegado por error, por favor elim=EDnelo sin =
revisarlo ni reenviarlo y notif=EDquelo inmediatamente al remitente. =
Gracias por su colaboraci=F3n. =20
ZIV utiliza software antivirus, pero no se hace responsable de los virus =
contenidos en los ficheros anexos.

Hi

We are showing figures of more than 4 billion error frames in our
ethernet interfaces. We have tested that the problem is in a
substraction (the number of errors decrements with the number of frames).

So... looking in the fec driver (fec.c) for the calculations we have
seen that the number of multicast packets is added to the number of
correct frames in order to get the frame errors...

But the interesting thing is that we have checked that this
calculation is something that we have added with a patch by Grzegorz
Bernacki in this list.

So... The funny thing is... Why a patch that solves the problem for
Grzegorz produces "the same problem" for us?

And... by the way... I have seen IEEE802.3, and when they talk about
aFramesReceivedOK (which I suppose is the ieee_r_frame_ok in the
driver), and they do not say a word about not including multicast
packets in it...

Any comment will be appreciate.

The only comment I have, is that yes, the computation are flawed.
And that's not very high in my priority list.

I don't think the path posted on the list fully fix the issue but I
really don't want to spend hours trying to figure out exactly what
values are reported in all those counters. You're welcome to do so if
you have some free time ...

There are other stuff wrong in this driver (try ifconfig eth0 down, then
send some broad cast traffic on the network .... you'll see some fifo
error popping up ) ...


Sylvain