Fwd: [BUG] Bisected Gianfar not receiving any traffic

Fwd: [BUG] Bisected Gianfar not receiving any traffic

[Michael Guntsche]

Forwarded to the correct mailing list address.


---------- Forwarded message ----------
From: Michael Guntsche <michael.guntsche@it-loops.com>
Date: Sun, Jun 9, 2013 at 10:26 PM
Subject: [BUG] Bisected Gianfar not receiving any traffic
To: linux-netdev@vger.kernel.org
Cc: Claudiu Manoil <claudiu.manoil@freescale.com>


Good evening,

While testing one of my powerpc based embedded ports I noticed that
with any 3.10-rc kernel ethernet traffic was dead on my two gianfar
NICs. The strange thing was that apparetnly outbound broadcasts seemed
to work since avahi correctly registered the name of the board. I
bisected it to the following commit.

6be5ed3fef568 gianfar: Poll only active Rx queues

Reverting this commit on 3.10-rc4 made both gianfar devices work
again. This is a rather old board so it could be that the register
that's used here is just plain wrong in my case. A few years ago I had
a similar issue where the implementation on the board here apparently
did not work correctly.

http://marc.info/?l=linux-netdev&m=131297524825104&w=2

In that case a flag was bogus as well.
If you need more information or want me to test a patch please add me
as CC since I am not subscribed to the list.

Kind regards,
Michael Guntsche

Re: Fwd: [BUG] Bisected Gianfar not receiving any traffic

[Claudiu Manoil]

Hello,

Please provide the model of your board. Commit 6be5ed3fef568
relies on correct indication from H/W for Rx processing, so we
should check whether the right register/mask are being used for
that model or whether there's a missing errata.
One way to confirm this is by checking if Rx processing (and not Tx)
is entered with num_act_queues == 0 (the RXF indication set to 0).

Thanks,
Claudiu

On 6/9/2013 11:28 PM, Michael Guntsche wrote:
> Forwarded to the correct mailing list address.
>
>
> ---------- Forwarded message ----------
> From: Michael Guntsche <michael.guntsche@it-loops.com>
> Date: Sun, Jun 9, 2013 at 10:26 PM
> Subject: [BUG] Bisected Gianfar not receiving any traffic
> To: linux-netdev@vger.kernel.org
> Cc: Claudiu Manoil <claudiu.manoil@freescale.com>
>
>
> Good evening,
>
> While testing one of my powerpc based embedded ports I noticed that
> with any 3.10-rc kernel ethernet traffic was dead on my two gianfar
> NICs. The strange thing was that apparetnly outbound broadcasts seemed
> to work since avahi correctly registered the name of the board. I
> bisected it to the following commit.
>
> 6be5ed3fef568 gianfar: Poll only active Rx queues
>
> Reverting this commit on 3.10-rc4 made both gianfar devices work
> again. This is a rather old board so it could be that the register
> that's used here is just plain wrong in my case. A few years ago I had
> a similar issue where the implementation on the board here apparently
> did not work correctly.
>
> http://marc.info/?l=linux-netdev&m=131297524825104&w=2
>
> In that case a flag was bogus as well.
> If you need more information or want me to test a patch please add me
> as CC since I am not subscribed to the list.
>
> Kind regards,
> Michael Guntsche
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
>

Re: Fwd: [BUG] Bisected Gianfar not receiving any traffic

[Michael Guntsche]

Hello Claudiu,

The Board in question is a Mikrotik Routerboard RB600A, which is using
a MPC8343E.

/Michael

On Mon, Jun 10, 2013 at 10:29 AM, Claudiu Manoil
<claudiu.manoil@freescale.com> wrote:
> Hello,
>
> Please provide the model of your board. Commit 6be5ed3fef568
> relies on correct indication from H/W for Rx processing, so we
> should check whether the right register/mask are being used for
> that model or whether there's a missing errata.
> One way to confirm this is by checking if Rx processing (and not Tx)
> is entered with num_act_queues == 0 (the RXF indication set to 0).
>
> Thanks,
> Claudiu
>
>
> On 6/9/2013 11:28 PM, Michael Guntsche wrote:
>>
>> Forwarded to the correct mailing list address.
>>
>>
>> ---------- Forwarded message ----------
>> From: Michael Guntsche <michael.guntsche@it-loops.com>
>> Date: Sun, Jun 9, 2013 at 10:26 PM
>> Subject: [BUG] Bisected Gianfar not receiving any traffic
>> To: linux-netdev@vger.kernel.org
>> Cc: Claudiu Manoil <claudiu.manoil@freescale.com>
>>
>>
>> Good evening,
>>
>> While testing one of my powerpc based embedded ports I noticed that
>> with any 3.10-rc kernel ethernet traffic was dead on my two gianfar
>> NICs. The strange thing was that apparetnly outbound broadcasts seemed
>> to work since avahi correctly registered the name of the board. I
>> bisected it to the following commit.
>>
>> 6be5ed3fef568 gianfar: Poll only active Rx queues
>>
>> Reverting this commit on 3.10-rc4 made both gianfar devices work
>> again. This is a rather old board so it could be that the register
>> that's used here is just plain wrong in my case. A few years ago I had
>> a similar issue where the implementation on the board here apparently
>> did not work correctly.
>>
>> http://marc.info/?l=linux-netdev&m=131297524825104&w=2
>>
>> In that case a flag was bogus as well.
>> If you need more information or want me to test a patch please add me
>> as CC since I am not subscribed to the list.
>>
>> Kind regards,
>> Michael Guntsche
>> --
>> To unsubscribe from this list: send the line "unsubscribe netdev" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>
>>
>
>

Re: Fwd: [BUG] Bisected Gianfar not receiving any traffic

[Claudiu Manoil]

Ok, this is a TSEC controller (an old model indeed) and looks like
it doesn't have the frame receive indication (RXF) field in RSTAT.
I'll send fix for this case asap.
I think the real problem here is that the driver supports multiple
rings per interrupt line. With a single ring per interrupt / CPU,
we would get rid of the overhead and related issues of looking for
active rings in the napi poll routine.

Claudiu

On 6/10/2013 11:33 AM, Michael Guntsche wrote:
> Hello Claudiu,
>
> The Board in question is a Mikrotik Routerboard RB600A, which is
> using a MPC8343E.
>
> /Michael
>
> On Mon, Jun 10, 2013 at 10:29 AM, Claudiu Manoil
> <claudiu.manoil@freescale.com> wrote:
>> Hello,
>>
>> Please provide the model of your board. Commit 6be5ed3fef568 relies
>> on correct indication from H/W for Rx processing, so we should
>> check whether the right register/mask are being used for that model
>> or whether there's a missing errata. One way to confirm this is by
>> checking if Rx processing (and not Tx) is entered with
>> num_act_queues == 0 (the RXF indication set to 0).
>>
>> Thanks, Claudiu
>>
>>
>> On 6/9/2013 11:28 PM, Michael Guntsche wrote:
>>>
>>> Forwarded to the correct mailing list address.
>>>
>>>
>>> ---------- Forwarded message ---------- From: Michael Guntsche
>>> <michael.guntsche@it-loops.com> Date: Sun, Jun 9, 2013 at 10:26
>>> PM Subject: [BUG] Bisected Gianfar not receiving any traffic To:
>>> linux-netdev@vger.kernel.org Cc: Claudiu Manoil
>>> <claudiu.manoil@freescale.com>
>>>
>>>
>>> Good evening,
>>>
>>> While testing one of my powerpc based embedded ports I noticed
>>> that with any 3.10-rc kernel ethernet traffic was dead on my two
>>> gianfar NICs. The strange thing was that apparetnly outbound
>>> broadcasts seemed to work since avahi correctly registered the
>>> name of the board. I bisected it to the following commit.
>>>
>>> 6be5ed3fef568 gianfar: Poll only active Rx queues
>>>
>>> Reverting this commit on 3.10-rc4 made both gianfar devices work
>>> again. This is a rather old board so it could be that the
>>> register that's used here is just plain wrong in my case. A few
>>> years ago I had a similar issue where the implementation on the
>>> board here apparently did not work correctly.
>>>
>>> http://marc.info/?l=linux-netdev&m=131297524825104&w=2
>>>
>>> In that case a flag was bogus as well. If you need more
>>> information or want me to test a patch please add me as CC since
>>> I am not subscribed to the list.
>>>
>>> Kind regards, Michael Guntsche -- To unsubscribe from this list:
>>> send the line "unsubscribe netdev" in the body of a message to
>>> majordomo@vger.kernel.org More majordomo info at
>>> http://vger.kernel.org/majordomo-info.html
>>>
>>>
>>
>>
> -- To unsubscribe from this list: send the line "unsubscribe netdev"
> in the body of a message to majordomo@vger.kernel.org More majordomo
> info at  http://vger.kernel.org/majordomo-info.html
>
>

[PATCH][net-next] gianfar: Add backwards compatible Single Queue mode polling

[Claudiu Manoil]

Older Single Queue (SQ_SG_MODE) devices like TSEC (i.e. mpc83xx)
don't feature the frame receive indication bits (RXF) in RSTAT.
For these and for the rest of the SQ_SG_MODE devices, provide the
appropiate polling routine that handles a single pair of Rx/Tx
BD rings, removing the overhead incurred by the multiple queues/
multiple interrupt group devices (veTSEC/ eTSEC2.0 devices).
So this is primarily a fix for the TSEC devices.

Signed-off-by: Claudiu Manoil <claudiu.manoil@freescale.com>
---
 drivers/net/ethernet/freescale/gianfar.c | 51 ++++++++++++++++++++++++++++++--
 1 file changed, 49 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/freescale/gianfar.c b/drivers/net/ethernet/freescale/gianfar.c
index 96fbe35..ac9bb63 100644
--- a/drivers/net/ethernet/freescale/gianfar.c
+++ b/drivers/net/ethernet/freescale/gianfar.c
@@ -128,6 +128,7 @@ static void gfar_set_multi(struct net_device *dev);
 static void gfar_set_hash_for_addr(struct net_device *dev, u8 *addr);
 static void gfar_configure_serdes(struct net_device *dev);
 static int gfar_poll(struct napi_struct *napi, int budget);
+static int gfar_poll_sq(struct napi_struct *napi, int budget);
 #ifdef CONFIG_NET_POLL_CONTROLLER
 static void gfar_netpoll(struct net_device *dev);
 #endif
@@ -1038,9 +1039,13 @@ static int gfar_probe(struct platform_device *ofdev)
 	dev->ethtool_ops = &gfar_ethtool_ops;
 
 	/* Register for napi ...We are registering NAPI for each grp */
-	for (i = 0; i < priv->num_grps; i++)
-		netif_napi_add(dev, &priv->gfargrp[i].napi, gfar_poll,
+	if (priv->mode == SQ_SG_MODE)
+		netif_napi_add(dev, &priv->gfargrp[0].napi, gfar_poll_sq,
 			       GFAR_DEV_WEIGHT);
+	else
+		for (i = 0; i < priv->num_grps; i++)
+			netif_napi_add(dev, &priv->gfargrp[i].napi, gfar_poll,
+				       GFAR_DEV_WEIGHT);
 
 	if (priv->device_flags & FSL_GIANFAR_DEV_HAS_CSUM) {
 		dev->hw_features = NETIF_F_IP_CSUM | NETIF_F_SG |
@@ -2824,6 +2829,48 @@ int gfar_clean_rx_ring(struct gfar_priv_rx_q *rx_queue, int rx_work_limit)
 	return howmany;
 }
 
+static int gfar_poll_sq(struct napi_struct *napi, int budget)
+{
+	struct gfar_priv_grp *gfargrp =
+		container_of(napi, struct gfar_priv_grp, napi);
+	struct gfar __iomem *regs = gfargrp->regs;
+	struct gfar_priv_tx_q *tx_queue = gfargrp->priv->tx_queue[0];
+	struct gfar_priv_rx_q *rx_queue = gfargrp->priv->rx_queue[0];
+	int work_done = 0;
+
+	/* Clear IEVENT, so interrupts aren't called again
+	 * because of the packets that have already arrived
+	 */
+	gfar_write(&regs->ievent, IEVENT_RTX_MASK);
+
+	/* run Tx cleanup to completion */
+	if (tx_queue->tx_skbuff[tx_queue->skb_dirtytx])
+		gfar_clean_tx_ring(tx_queue);
+
+	work_done = gfar_clean_rx_ring(rx_queue, budget);
+
+	if (work_done < budget) {
+		napi_complete(napi);
+		/* Clear the halt bit in RSTAT */
+		gfar_write(&regs->rstat, gfargrp->rstat);
+
+		gfar_write(&regs->imask, IMASK_DEFAULT);
+
+		/* If we are coalescing interrupts, update the timer
+		 * Otherwise, clear it
+		 */
+		gfar_write(&regs->txic, 0);
+		if (likely(tx_queue->txcoalescing))
+			gfar_write(&regs->txic, tx_queue->txic);
+
+		gfar_write(&regs->rxic, 0);
+		if (unlikely(rx_queue->rxcoalescing))
+			gfar_write(&regs->rxic, rx_queue->rxic);
+	}
+
+	return work_done;
+}
+
 static int gfar_poll(struct napi_struct *napi, int budget)
 {
 	struct gfar_priv_grp *gfargrp =
-- 
1.7.11.3

Re: [PATCH][net-next] gianfar: Add backwards compatible Single Queue mode polling

[Michael Guntsche]

Hello Claudiu,

On Mon, Jun 10, 2013 at 7:19 PM, Claudiu Manoil
<claudiu.manoil@freescale.com> wrote:
> Older Single Queue (SQ_SG_MODE) devices like TSEC (i.e. mpc83xx)
> don't feature the frame receive indication bits (RXF) in RSTAT.
> For these and for the rest of the SQ_SG_MODE devices, provide the
> appropiate polling routine that handles a single pair of Rx/Tx
> BD rings, removing the overhead incurred by the multiple queues/
> multiple interrupt group devices (veTSEC/ eTSEC2.0 devices).
> So this is primarily a fix for the TSEC devices.
>
> Signed-off-by: Claudiu Manoil <claudiu.manoil@freescale.com>
> ---
>  drivers/net/ethernet/freescale/gianfar.c | 51 ++++++++++++++++++++++++++++++--
>  1 file changed, 49 insertions(+), 2 deletions(-)
>
<snip>
I can confirm that this fixes the problem for my TSEC based board.

/Mike

Re: [PATCH][net-next] gianfar: Add backwards compatible Single Queue mode polling

[David Miller]

From: Claudiu Manoil <claudiu.manoil@freescale.com>
Date: Mon, 10 Jun 2013 20:19:48 +0300

> Older Single Queue (SQ_SG_MODE) devices like TSEC (i.e. mpc83xx)
> don't feature the frame receive indication bits (RXF) in RSTAT.
> For these and for the rest of the SQ_SG_MODE devices, provide the
> appropiate polling routine that handles a single pair of Rx/Tx
> BD rings, removing the overhead incurred by the multiple queues/
> multiple interrupt group devices (veTSEC/ eTSEC2.0 devices).
> So this is primarily a fix for the TSEC devices.
> 
> Signed-off-by: Claudiu Manoil <claudiu.manoil@freescale.com>

Applied, thanks.

Re: [PATCH][net-next] gianfar: Add backwards compatible Single Queue mode polling

[Lutz Jaenicke]

On Mon, Jun 10, 2013 at 07:35:38PM +0200, Michael Guntsche wrote:
> Hello Claudiu,
> 
> On Mon, Jun 10, 2013 at 7:19 PM, Claudiu Manoil
> <claudiu.manoil@freescale.com> wrote:
> > Older Single Queue (SQ_SG_MODE) devices like TSEC (i.e. mpc83xx)
> > don't feature the frame receive indication bits (RXF) in RSTAT.
> > For these and for the rest of the SQ_SG_MODE devices, provide the
> > appropiate polling routine that handles a single pair of Rx/Tx
> > BD rings, removing the overhead incurred by the multiple queues/
> > multiple interrupt group devices (veTSEC/ eTSEC2.0 devices).
> > So this is primarily a fix for the TSEC devices.
> >
> > Signed-off-by: Claudiu Manoil <claudiu.manoil@freescale.com>
> > ---
> >  drivers/net/ethernet/freescale/gianfar.c | 51 ++++++++++++++++++++++++++++++--
> >  1 file changed, 49 insertions(+), 2 deletions(-)
> >
> <snip>
> I can confirm that this fixes the problem for my TSEC based board.

I need this fix for 3.10.7 as well, so this seems to be stable-stuff.

Best regards,
	Lutz
-- 
Dr.-Ing. Lutz Jänicke
CTO
Innominate Security Technologies AG  /protecting industrial networks/
tel: +49.30.921028-200
fax: +49.30.921028-020
Rudower Chaussee 13
D-12489 Berlin, Germany
www.innominate.com

Register Court: AG Charlottenburg, HR B 81603
Management Board: Dirk Seewald
Chairman of the Supervisory Board: Christoph Leifer