Patch for arch/ppc/8xx_io/fec.c

Patch for arch/ppc/8xx_io/fec.c

[Jean-Denis Boyer]

[-- Attachment #1: Type: text/plain, Size: 2845 bytes --]


Hello.

I've attached to this mail a patch for the FEC driver
on the Motorola MPC8xx embedded CPU.

This patch includes both a bug fix, and a new PHYter implementation.

 Symptom
---------
I was experiencing problems of "transmission timeout" when heavily
loading the network (throughput tests), particularly when the board
was wired to a 10MBits link (but I could also reproduce it on 100Mbits
using the packet sockets). The user process was then "held" by the IP
stack, I had no choice but to kill it.

 Bug description
-----------------
When, in rare cases, the ring buffer became full, the driver was stopping
the network queue, which is OK. But, it did not set a flag to restart
the queue in the transmission interrupt service routine.

 Bug fix
---------
I only had to set this flag, at the same time the network queue was stopped
(already wrapped in a spin lock).


Supplement:
 PHYter implementation
-----------------------
My board uses the NS chip model DP83843BVJE, for which I filled out the
needed structures.
However, I could not test the PHYter interrupt since it is not wired to the
PPC on our board
(but it is enabled in this patch). I had to code a polling routine (not
included in this patch).

It might be a good idea to move all these implementations outside of
"fec.c".
It might be also useful to choose the supported models through the kernel
configuration.
Perhaps I will work on that during the next weeks...

By the way, who is maintaining that part (MPC8xx, MPC82xx) of the kernel?


 Other issue 
-------------
I have another problem I will have to address. I'm experiencing a strange
behaviour
in the response time when I 'ping flood' my board.

Through the 10Mbits, everything works fine, the average response time is
468us,
with realist minimum and maximum values.

  > round-trip min/avg/max/mdev = 0.458/0.468/0.600/0.029 ms

But, through the 100Mbits, the response time ranges from 0.26ms to 10ms,
and an average of about 5ms, always different from test to test.

  > round-trip min/avg/max/mdev = 0.265/6.764/10.311/4.512 ms

Strangely, the board is not running anything but bash.
If a start 'top' with a refresh period of 1 second, I get a lower average,
but still the same min and max.

  > round-trip min/avg/max/mdev = 0.264/0.583/10.018/1.421 ms

If I start an NFS copy of a big file, the maximum gets down to 2ms.


The maximum of 10ms sounds like the timer tick.
Since it is working well in 10Mbps and not in 100Mbps,
can I suspect a problem with the Ethernet driver?


Thank you for your time.

--------------------------------------------
 Jean-Denis Boyer, B.Eng., Technical Leader
 Mediatrix Telecom Inc.
 4229 Garlock Street
 Sherbrooke (Québec)
 J1L 2C8  CANADA
--------------------------------------------


[-- Attachment #2: ppc.8xx_io.fec.c.patch.gz --]
[-- Type: application/octet-stream, Size: 1348 bytes --]

patch for arch/ppc/8xx_io/fec.c

[Thomas Lange]

[-- Attachment #1: Type: text/plain, Size: 642 bytes --]

Against bk:linuxppc_2_4

Use retry counter (RC) to detect collisions instead of
Defer (DEF).

>From Table 6-29: (MPC860T (Rev. D) Fast Ethernet Controller 0.8)

6 DEF Defer indication, written by FEC (valid if L = 1). Set when the
FEC had to defer while trying to
transmit a frame. This bit is not set if a collision occurs during
transmission.

10-13 RC Retry count, written by FEC (valid if L = 1). Counts retries
needed
to successfully send this frame. If RC = 0, the frame was sent correctly
the first time. If RC = 15, the frame was sent successfully while the
retry
count was at its maximum value. If RL = 1, RC has no meaning.

/Thomas

[-- Attachment #2: fec_collision_patch --]
[-- Type: text/plain, Size: 749 bytes --]

--- fec.c	2002-10-15 14:58:00.000000000 +0200
+++ fec_cfix.c	2002-10-24 20:59:20.000000000 +0200
@@ -502,11 +502,12 @@
 		if (bdp->cbd_sc & BD_ENET_TX_READY)
 			printk("HEY! Enet xmit interrupt and TX_READY.\n");
 #endif
-		/* Deferred means some collisions occurred during transmit,
-		 * but we eventually sent the packet OK.
-		 */
-		if (bdp->cbd_sc & BD_ENET_TX_DEF)
-			fep->stats.collisions++;
+		/* Check retry counter, i.e. collision counter */
+		/* Only valid if LAST is set, but it should always be. */
+		if (bdp->cbd_sc & BD_ENET_TX_RCMASK){
+			/* Note that counter cannot go higher than 15 */
+			fep->stats.collisions+=(bdp->cbd_sc & BD_ENET_TX_RCMASK)>>2;
+		}

 		/* Free the sk buffer associated with this last transmit.
 		 */