Re: [PATCH 2/3] net: stmmac: Always use the number of configured TX queues

On Tue, Mar 28, 2017 at 04:10:43PM +0200, Niklas Cassel wrote:

On 03/28/2017 03:57 PM, Thierry Reding wrote:

quoted

From: Thierry Reding <redacted>

Even if hardware supports multiple queues, software can choose to only
use a subset of them. Make sure we never try to access uninitialized
queues.

Signed-off-by: Thierry Reding <redacted>
---
 drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 106ace3781b3..ec5bba85c529 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c

@@ -3423,7 +3423,7 @@ static int stmmac_poll(struct napi_struct *napi, int budget)
 	struct stmmac_rx_queue *rx_q =
 		container_of(napi, struct stmmac_rx_queue, napi);
 	struct stmmac_priv *priv = rx_q->priv_data;
-	u32 tx_count = priv->dma_cap.number_tx_queues;
+	u32 tx_count = priv->plat->tx_queues_to_use;
 	u32 chan = rx_q->queue_index;
 	u32 work_done = 0;
 	u32 queue = 0;

Thanks Thierry,
but this look like an equivalent patch to Joao's
"net: stmmac: fix number of tx queues in stmmac_poll"
which I already used during bisecting to avoid random
crashes in stmmac_tx_clean.

Yeah, patch 3/3 is the important one in this batch. I just sent out the
complete set of 3 because it's what I use on top of linux-next to make
stmmac work again on my setup.

Have you noticed random RX brokenness after boot in
recent linux-next tags?

Yes, I was seeing about 8 in 10 bad boots and 2 in 10 good ones.

It feels like it might trigger more often after a
cold boot, but that could just be my brain seeing
patterns that aren't really there :)

It'd be good if you could try applying patch 3/3 since that got me back
to 10/10 successful boots. It's somewhat surprising because I had gone
through the code looking for uninitialized data that would explain why
kcalloc() instead of kmalloc_array() would fix things but didn't find
anything.

Still, that patch works for me, so maybe I was just overlooking
something.

Thierry