net: stmmac: adding multiple buffers and routing
Subsystems (5)
v2 cover net: stmmac: adding multiple buffers and routing
As agreed with David Miller, this patch-set is the third and last to enable multiple queues in stmmac.
This third one focuses on:
a) Enable multiple buffering to the driver and queue independent data
b) Configuration of RX and TX queues' priority
c) Configuration of RX queues' routing
Joao Pinto (3):
net: stmmac: enable multiple buffers
net: stmmac: TX and RX queue priority configuration
net: stmmac: RX queue routing configuration
Documentation/devicetree/bindings/net/stmmac.txt | 11 + drivers/net/ethernet/stmicro/stmmac/chain_mode.c | 45 +- drivers/net/ethernet/stmicro/stmmac/common.h | 21 + drivers/net/ethernet/stmicro/stmmac/dwmac4.h | 29 + drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c | 71 + drivers/net/ethernet/stmicro/stmmac/ring_mode.c | 46 +- drivers/net/ethernet/stmicro/stmmac/stmmac.h | 49 +- drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 1379 ++++++++++++++------ drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c | 7 + .../net/ethernet/stmicro/stmmac/stmmac_platform.c | 30 + include/linux/stmmac.h | 5 + 11 files changed, 1220 insertions(+), 473 deletions(-)
Signature · 1 line
2.9.3
PATCH v2 1/3 net: stmmac: enable multiple buffers
This patch creates 2 new structures (stmmac_tx_queue and stmmac_rx_queue) in include/linux/stmmac.h, enabling that each RX and TX queue has its own buffers and data.
---
changes v1->v2:
- just to keep up version
drivers/net/ethernet/stmicro/stmmac/chain_mode.c | 45 +- drivers/net/ethernet/stmicro/stmmac/ring_mode.c | 46 +- drivers/net/ethernet/stmicro/stmmac/stmmac.h | 49 +- drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 1306 ++++++++++++++------- 4 files changed, 973 insertions(+), 473 deletions(-)
drivers/net/ethernet/stmicro/stmmac/chain_mode.c +25 -20
@@ -26,12 +26,15 @@static int stmmac_jumbo_frm (void *p,struct sk_buff *skb,int csum) { -struct stmmac_priv *priv = (struct stmmac_priv *)p; -unsigned int entry = priv->cur_tx; -struct dma_desc *desc = priv->dma_tx + entry; +struct stmmac_tx_queue *tx_q = (struct stmmac_tx_queue *)p;unsigned int nopaged_len =skb_headlen (skb); +struct stmmac_priv *priv = tx_q->priv_data; +unsigned int entry = tx_q->cur_tx;unsigned int bmax, des2;unsigned int i =1 , len; +struct dma_desc *desc; + + desc = tx_q->dma_tx + entry;if (priv->plat->enh_desc) bmax = BUF_SIZE_8KiB;
@@ -45,16 +48,16 @@ static int stmmac_jumbo_frm(void *p, struct sk_buff *skb, int csum) desc->des2 =cpu_to_le32 (des2);if (dma_mapping_error (priv->device, des2))return -1 ; - priv->tx_skbuff_dma[entry].buf = des2; - priv->tx_skbuff_dma[entry].len = bmax; + tx_q->tx_skbuff_dma[entry].buf = des2; + tx_q->tx_skbuff_dma[entry].len = bmax;/* do not close the descriptor and do not set own bit */ priv->hw->desc->prepare_tx_desc (desc,1 , bmax, csum,STMMAC_CHAIN_MODE ,0 , false);while (len !=0 ) { - priv->tx_skbuff[entry] =NULL ; + tx_q->tx_skbuff[entry] =NULL ; entry =STMMAC_GET_ENTRY (entry,DMA_TX_SIZE ); - desc = priv->dma_tx + entry; + desc = tx_q->dma_tx + entry;if (len > bmax) { des2 = dma_map_single(priv->device,
@@ -63,8 +66,8 @@ static int stmmac_jumbo_frm(void *p, struct sk_buff *skb, int csum) desc->des2 =cpu_to_le32 (des2);if (dma_mapping_error (priv->device, des2))return -1 ; - priv->tx_skbuff_dma[entry].buf = des2; - priv->tx_skbuff_dma[entry].len = bmax; + tx_q->tx_skbuff_dma[entry].buf = des2; + tx_q->tx_skbuff_dma[entry].len = bmax; priv->hw->desc->prepare_tx_desc (desc,0 , bmax, csum,STMMAC_CHAIN_MODE ,1 , false);
@@ -77,8 +80,8 @@ static int stmmac_jumbo_frm(void *p, struct sk_buff *skb, int csum) desc->des2 =cpu_to_le32 (des2);if (dma_mapping_error (priv->device, des2))return -1 ; - priv->tx_skbuff_dma[entry].buf = des2; - priv->tx_skbuff_dma[entry].len = len; + tx_q->tx_skbuff_dma[entry].buf = des2; + tx_q->tx_skbuff_dma[entry].len = len;/* last descriptor can be set now */ priv->hw->desc->prepare_tx_desc(desc, 0, len, csum, STMMAC_CHAIN_MODE, 1,
@@ -87,7 +90,7 @@ static int stmmac_jumbo_frm(void *p, struct sk_buff *skb, int csum) } } - priv->cur_tx = entry; + tx_q->cur_tx = entry;return entry; }
@@ -136,32 +139,34 @@ static void stmmac_init_dma_chain(void *des, dma_addr_t phy_addr,static void stmmac_refill_desc3 (void *priv_ptr,struct dma_desc *p) { -struct stmmac_priv *priv = (struct stmmac_priv *)priv_ptr; +struct stmmac_rx_queue *rx_q = (struct stmmac_rx_queue *)priv_ptr; +struct stmmac_priv *priv = rx_q->priv_data;if (priv->hwts_rx_en && !priv->extend_desc)/* NOTE: Device will overwrite des3 with timestamp value if * 1588-2002 time stamping is enabled, hence reinitialize it * to keep explicit chaining in the descriptor. */ - p->des3 =cpu_to_le32 ((unsigned int )(priv->dma_rx_phy + - (((priv->dirty_rx) +1 ) % + p->des3 =cpu_to_le32 ((unsigned int )(rx_q->dma_rx_phy + + (((rx_q->dirty_rx) +1 ) %DMA_RX_SIZE ) *sizeof (struct dma_desc ))); }static void stmmac_clean_desc3 (void *priv_ptr,struct dma_desc *p) { -struct stmmac_priv *priv = (struct stmmac_priv *)priv_ptr; -unsigned int entry = priv->dirty_tx; +struct stmmac_tx_queue *tx_q = (struct stmmac_tx_queue *)priv_ptr; +struct stmmac_priv *priv = tx_q->priv_data; +unsigned int entry = tx_q->dirty_tx; -if (priv->tx_skbuff_dma[entry].last_segment && !priv->extend_desc && +if (tx_q->tx_skbuff_dma[entry].last_segment && !priv->extend_desc && priv->hwts_tx_en)/* NOTE: Device will overwrite des3 with timestamp value if * 1588-2002 time stamping is enabled, hence reinitialize it * to keep explicit chaining in the descriptor. */ - p->des3 =cpu_to_le32 ((unsigned int )((priv->dma_tx_phy + - ((priv->dirty_tx +1 ) %DMA_TX_SIZE )) + p->des3 =cpu_to_le32 ((unsigned int )((tx_q->dma_tx_phy + + ((tx_q->dirty_tx +1 ) %DMA_TX_SIZE )) *sizeof (struct dma_desc ))); }
drivers/net/ethernet/stmicro/stmmac/ring_mode.c +24 -22
96 lines not on this page · raw message
drivers/net/ethernet/stmicro/stmmac/stmmac.h +35 -14
77 lines not on this page · raw message
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c +889 -417
2,058 lines not on this page · raw message
Signature · 1 line
2.9.3
Re: [v2,net-next,1/3] net: stmmac: enable multiple buffers
Quoted 9 lines · Joao Pinto
This patch creates 2 new structures (
stmmac_tx_queueandstmmac_rx_queue) ininclude/linux/stmmac.h, enabling that each RX and TX queue has its own buffers and data.Signed-off-by Joao Pinto <[email protected]>---
changesv1->v2:
- just to keep up version
Quoted 5 lines
drivers/net/ethernet/stmicro/stmmac/chain_mode.c | 45 +- drivers/net/ethernet/stmicro/stmmac/ring_mode.c | 46 +- drivers/net/ethernet/stmicro/stmmac/stmmac.h | 49 +- drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 1306 ++++++++++++++------- 4 files changed, 973 insertions(+), 473 deletions(-)
Hi Joao,
This seems to break support on Tegra186 again. I've gone through this patch multiple times and I can't figure out what could be causing it. Any ideas?
What I'm seeing is that the transmit queue 0 times out:
[ 101.121774] Sending DHCP requests ... [ 111.841763] NETDEV WATCHDOG: eth0 (dwc-eth-dwmac): transmit queue 0 timed out
and then I also see this:
[ 112.252024] dwc-eth-dwmac 2490000.ethernet: DMA-API: device driver tries to free DMA memory it has not allocated [device address=0x0000000057ac6e9d] [size=0 bytes] [ 112.266606] ------------[ cut here ]------------ [ 112.271220] WARNING: CPU: 0 PID: 0 at /home/thierry.reding/src/kernel/linux-tegra.git/lib/dma-debug.c:1106 check_unmap+0x7b0/0x930 [ 112.282934] Modules linked in: [ 112.285985] [ 112.287474] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G S W 4.11.0-rc3-next-20170323-00060-g2eab4557749b-dirty #400 [ 112.298581] Hardware name: NVIDIA Tegra186 P2771-0000 Development Board (DT) [ 112.305615] task: ffff000008f87b00 task.stack: ffff000008f70000 [ 112.311523] PC is at check_unmap+0x7b0/0x930 [ 112.315785] LR is at check_unmap+0x7b0/0x930 [ 112.320046] pc : [<ffff0000083d75f0>] lr : [<ffff0000083d75f0>] pstate: 60000145 [ 112.327426] sp : ffff8001f5e50c50 [ 112.330733] x29: ffff8001f5e50c50 x28: ffff000008f75180 [ 112.336042] x27: ffff000008f87b00 x26: 0000000000000020 [ 112.341351] x25: 0000000000000140 x24: ffff000008f81000 [ 112.346660] x23: ffff8001ec4b0810 x22: 0000000057ac6e9d [ 112.351969] x21: 0000000057ac6e9d x20: ffff8001f5e50cb0 [ 112.357277] x19: ffff8001ec4b0810 x18: 0000000000000010 [ 112.362586] x17: 00000000262ea01f x16: 000000000f48bf67 [ 112.367895] x15: 0000000000000006 x14: 5d64396536636137 [ 112.373203] x13: 3530303030303030 x12: 3078303d73736572 [ 112.378511] x11: 6464612065636976 x10: 65645b2064657461 [ 112.383819] x9 : ffff00000852c238 x8 : 00000000000001fb [ 112.389126] x7 : 0000000000000000 x6 : ffff00000810ad58 [ 112.394434] x5 : 0000000000000000 x4 : 0000000000000000 [ 112.399743] x3 : ffffffffffffffff x2 : ffff000008f99258 [ 112.405050] x1 : ffff000008f87b00 x0 : 0000000000000097 [ 112.410358] [ 112.411846] ---[ end trace 48028f96a0e990fb ]--- [ 112.416453] Call trace: [ 112.418895] Exception stack(0xffff8001f5e50a80 to 0xffff8001f5e50bb0) [ 112.425324] 0a80: ffff8001ec4b0810 0001000000000000 ffff8001f5e50c50 ffff0000083d75f0 [ 112.433139] 0aa0: 00000000000001c0 0000000000000000 0000000000000000 ffff000008d1c0c0 [ 112.440954] 0ac0: ffff8001f5e50c50 ffff8001f5e50c50 ffff8001f5e50c10 00000000ffffffc8 [ 112.448769] 0ae0: ffff8001f5e50b10 ffff00000810c3a8 ffff8001f5e50c50 ffff8001f5e50c50 [ 112.456585] 0b00: ffff8001f5e50c10 00000000ffffffc8 ffff8001f5e50bc0 ffff000008178388 [ 112.464399] 0b20: 0000000000000097 ffff000008f87b00 ffff000008f99258 ffffffffffffffff [ 112.472215] 0b40: 0000000000000000 0000000000000000 ffff00000810ad58 0000000000000000 [ 112.480030] 0b60: 00000000000001fb ffff00000852c238 65645b2064657461 6464612065636976 [ 112.487845] 0b80: 3078303d73736572 3530303030303030 5d64396536636137 0000000000000006 [ 112.495659] 0ba0: 000000000f48bf67 00000000262ea01f [ 112.500528] [<ffff0000083d75f0>] check_unmap+0x7b0/0x930 [ 112.505830] [<ffff0000083d77d8>] debug_dma_unmap_page+0x68/0x70 [ 112.511744] [<ffff0000086a9654>] stmmac_free_tx_buffers.isra.1+0x114/0x198 [ 112.518604] [<ffff0000086a9754>] stmmac_tx_err+0x7c/0x160 [ 112.523993] [<ffff0000086a986c>] stmmac_tx_timeout+0x34/0x50 [ 112.529642] [<ffff0000088a1938>] dev_watchdog+0x270/0x2a8 [ 112.535032] [<ffff000008120774>] call_timer_fn+0x64/0xd0 [ 112.540334] [<ffff000008120890>] expire_timers+0xb0/0xc0 [ 112.545636] [<ffff0000081209f8>] run_timer_softirq+0x80/0xc0 [ 112.551284] [<ffff0000080c517c>] __do_softirq+0x10c/0x218 [ 112.556673] [<ffff0000080c55b0>] irq_exit+0xc8/0x118 [ 112.561629] [<ffff00000810cc50>] __handle_domain_irq+0x60/0xb8 [ 112.567450] [<ffff00000808154c>] gic_handle_irq+0x54/0xa8 [ 112.572837] Exception stack(0xffff000008f73dd0 to 0xffff000008f73f00) [ 112.579264] 3dc0: 0000000000000000 0000000000000000 [ 112.587079] 3de0: 0000000000000001 0000000000000000 ffffffffffffea60 ffff000008f73f00 [ 112.594894] 3e00: 00000000000000c0 0000000000000000 0000000000000028 ffff000008f73e40 [ 112.602709] 3e20: 0000000000001130 00000000fa83b2da ffff000008a313a0 0000000000000001 [ 112.610524] 3e40: 0000000000000000 00000019ebd06fc0 000000000f48bf67 00000000262ea01f [ 112.618338] 3e60: 0000000000000010 ffff000008f2b000 ffff000008f7eb58 ffff000008f7e000 [ 112.626152] 3e80: ffff000008f371a0 0000000000000000 0000000000000000 ffff000008f87b00 [ 112.633967] 3ea0: 00000000eff9cf10 0000000000000000 0000000080e60018 ffff000008f73f00 [ 112.641782] 3ec0: ffff00000808524c ffff000008f73f00 ffff000008085250 0000000000000045 [ 112.649597] 3ee0: ffff000008f73f00 00000000ffff47c0 ffffffffffffffff 7fffffffffffffff [ 112.657411] [<ffff0000080827f4>] el1_irq+0xb4/0x128 [ 112.662280] [<ffff000008085250>] arch_cpu_idle+0x10/0x18 [ 112.667581] [<ffff0000080fbbdc>] do_idle+0x10c/0x1f0 [ 112.672537] [<ffff0000080fbeb8>] cpu_startup_entry+0x20/0x28 [ 112.678185] [<ffff000008a0aa64>] rest_init+0xbc/0xc8 [ 112.683140] [<ffff000008e60b4c>] start_kernel+0x384/0x398 [ 112.688528] [<ffff000008e601e0>] __primary_switched+0x64/0x6c
And finally this:
[ 112.694283] Unable to handle kernel paging request at virtual address ffff000008061000 [ 112.702184] pgd = ffff000009ae2000 [ 112.705577] [ffff000008061000] *pgd=0000000275f0e003, *pud=0000000275f0d003, *pmd=0000000275f0c003, *pte=0000000000000000 [ 112.716532] Internal error: Oops: 96000047 [#1] PREEMPT SMP [ 112.722092] Modules linked in: [ 112.725143] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G S W 4.11.0-rc3-next-20170323-00060-g2eab4557749b-dirty #400 [ 112.736248] Hardware name: NVIDIA Tegra186 P2771-0000 Development Board (DT) [ 112.743281] task: ffff000008f87b00 task.stack: ffff000008f70000 [ 112.749189] PC is at dwmac4_rd_init_tx_desc+0x0/0x10 [ 112.754142] LR is at stmmac_tx_err+0xe4/0x160 [ 112.758488] pc : [<ffff0000086b4790>] lr : [<ffff0000086a97bc>] pstate: 80000145 [ 112.765866] sp : ffff8001f5e50d80 [ 112.769171] x29: ffff8001f5e50d80 x28: ffff000008f75180 [ 112.774476] x27: ffff000008f87b00 x26: 0000000000000020 [ 112.779780] x25: 00000000ffffffff x24: 0000000000000000 [ 112.785086] x23: ffff8001eccbaac0 x22: 0000000000000000 [ 112.790389] x21: ffff8001e946a900 x20: ffff8001eccbaa00 [ 112.795694] x19: 0000000000000001 x18: 0000000000000010 [ 112.800998] x17: 00000000262ea01f x16: 000000000f48bf67 [ 112.806303] x15: 0000000000000006 x14: 5d64396536636137 [ 112.811608] x13: 3530303030303030 x12: 3078303d73736572 [ 112.816913] x11: 6464612065636976 x10: 65645b2064657461 [ 112.822218] x9 : ffff00000852c238 x8 : 0000000040000000 [ 112.827523] x7 : 0000000000210d00 x6 : ffff0000083d7038 [ 112.832828] x5 : ffff000008865ed8 x4 : 0000000000000080 [ 112.838133] x3 : ffff0000086b4790 x2 : 0000000000000000 [ 112.843438] x1 : 0000000000000000 x0 : ffff000008061000 [ 112.848743] [ 112.850229] Process swapper/0 (pid: 0, stack limit = 0xffff000008f70000) [ 112.856916] Stack: (0xffff8001f5e50d80 to 0xffff000008f74000) [ 112.862647] Call trace: [ 112.865087] Exception stack(0xffff8001f5e50bb0 to 0xffff8001f5e50ce0) [ 112.871513] 0ba0: 0000000000000001 0001000000000000 [ 112.879326] 0bc0: ffff8001f5e50d80 ffff0000086b4790 ffff000008f87b00 000000000001bbc0 [ 112.887139] 0be0: ffff000008f87b00 0000000000000020 ffff000008f87b00 ffff000008f75180 [ 112.894952] 0c00: ffff000008fb8000 ffff000008f87b00 ffff000008f87b00 ffff000008a117fc [ 112.902766] 0c20: ffff8001e9721f00 ffff0000081d8684 ffff7e0007b12300 ffff8001ec48d800 [ 112.910579] 0c40: ffff000008866308 000000018010000e ffff000008061000 0000000000000000 [ 112.918392] 0c60: 0000000000000000 ffff0000086b4790 0000000000000080 ffff000008865ed8 [ 112.926206] 0c80: ffff0000083d7038 0000000000210d00 0000000040000000 ffff00000852c238 [ 112.934018] 0ca0: 65645b2064657461 6464612065636976 3078303d73736572 3530303030303030 [ 112.941831] 0cc0: 5d64396536636137 0000000000000006 000000000f48bf67 00000000262ea01f [ 112.949645] [<ffff0000086b4790>] dwmac4_rd_init_tx_desc+0x0/0x10 [ 112.955638] [<ffff0000086a986c>] stmmac_tx_timeout+0x34/0x50 [ 112.961285] [<ffff0000088a1938>] dev_watchdog+0x270/0x2a8 [ 112.966672] [<ffff000008120774>] call_timer_fn+0x64/0xd0 [ 112.971973] [<ffff000008120890>] expire_timers+0xb0/0xc0 [ 112.977274] [<ffff0000081209f8>] run_timer_softirq+0x80/0xc0 [ 112.982920] [<ffff0000080c517c>] __do_softirq+0x10c/0x218 [ 112.988307] [<ffff0000080c55b0>] irq_exit+0xc8/0x118 [ 112.993262] [<ffff00000810cc50>] __handle_domain_irq+0x60/0xb8 [ 112.999081] [<ffff00000808154c>] gic_handle_irq+0x54/0xa8 [ 113.004468] Exception stack(0xffff000008f73dd0 to 0xffff000008f73f00) [ 113.010893] 3dc0: 0000000000000000 0000000000000000 [ 113.018706] 3de0: 0000000000000001 0000000000000000 ffffffffffffea60 ffff000008f73f00 [ 113.026520] 3e00: 00000000000000c0 0000000000000000 0000000000000028 ffff000008f73e40 [ 113.034335] 3e20: 0000000000001130 00000000fa83b2da ffff000008a313a0 0000000000000001 [ 113.042148] 3e40: 0000000000000000 00000019ebd06fc0 000000000f48bf67 00000000262ea01f [ 113.049961] 3e60: 0000000000000010 ffff000008f2b000 ffff000008f7eb58 ffff000008f7e000 [ 113.057775] 3e80: ffff000008f371a0 0000000000000000 0000000000000000 ffff000008f87b00 [ 113.065590] 3ea0: 00000000eff9cf10 0000000000000000 0000000080e60018 ffff000008f73f00 [ 113.073404] 3ec0: ffff00000808524c ffff000008f73f00 ffff000008085250 0000000000000045 [ 113.081217] 3ee0: ffff000008f73f00 00000000ffff47c0 ffffffffffffffff 7fffffffffffffff [ 113.089030] [<ffff0000080827f4>] el1_irq+0xb4/0x128 [ 113.093897] [<ffff000008085250>] arch_cpu_idle+0x10/0x18 [ 113.099197] [<ffff0000080fbbdc>] do_idle+0x10c/0x1f0 [ 113.104150] [<ffff0000080fbeb8>] cpu_startup_entry+0x20/0x28 [ 113.109798] [<ffff000008a0aa64>] rest_init+0xbc/0xc8 [ 113.114751] [<ffff000008e60b4c>] start_kernel+0x384/0x398 [ 113.120139] [<ffff000008e601e0>] __primary_switched+0x64/0x6c [ 113.125874] Code: 7100003f 1a831042 b9000c02 d65f03c0 (29007c1f) [ 113.131962] ---[ end trace 48028f96a0e990fc ]---
The above is with one small change already applied, which seemed like it would be significant, but it didn't have much effect. See below...
Quoted 1 line
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c +0
-0
[...]
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c static int stmmac_rx(struct stmmac_priv *priv, int limit) · line 3362
Quoted 11 lines
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c +4
-3@@ -2977,14 +3356,22 @@ static int stmmac_rx(struct stmmac_priv *priv, int limit)*/ static int stmmac_poll (struct napi_struct *napi,int budget) { - struct stmmac_priv *priv = container_of(napi, struct stmmac_priv, napi); -int work_done =0 ; -u32 chan =STMMAC_CHAN0 ; +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;
I changed this to priv->plat->tx_queues_to_use as used elsewhere to make sure we don't try to clean up non-initialized TX queues. This seems to solve an issue that would occasionally happen after the TX queue timed out, but the fundamental issue is still there.
Thierry
Re: [v2,net-next,1/3] net: stmmac: enable multiple buffers
Hi Thierry,
Às 5:17 PM de 3/23/2017, Thierry Reding escreveu:
Quoted 18 lines · Joao Pinto
Quoted 9 lines
This patch creates 2 new structures (
stmmac_tx_queueandstmmac_rx_queue) ininclude/linux/stmmac.h, enabling that each RX and TX queue has its own buffers and data.Signed-off-by Joao Pinto <[email protected]>---
changesv1->v2:
- just to keep up versionQuoted 5 lines
drivers/net/ethernet/stmicro/stmmac/chain_mode.c | 45 +- drivers/net/ethernet/stmicro/stmmac/ring_mode.c | 46 +- drivers/net/ethernet/stmicro/stmmac/stmmac.h | 49 +- drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 1306 ++++++++++++++------- 4 files changed, 973 insertions(+), 473 deletions(-)Hi Joao,
Quoted 8 lines
This seems to break support on Tegra186 again. I've gone through this patch multiple times and I can't figure out what could be causing it. Any ideas?
What I'm seeing is that the transmit queue 0 times out:
[ 101.121774] Sending DHCP requests ... [ 111.841763] NETDEV WATCHDOG: eth0 (dwc-eth-dwmac): transmit queue 0 timed out
You are using a GMAC or GMAC4 aka QoS?
Quoted 4 lines
and then I also see this:
[ 112.252024] dwc-eth-dwmac 2490000.ethernet: DMA-API: device driver tries to free DMA memory it has not allocated [device address=0x0000000057ac6e9d] [size=0 bytes]
Humm... Something in stmmac_free_tx_buffers... I'll need to check.
Quoted 72 lines
[ 112.266606] ------------[ cut here ]------------ [ 112.271220] WARNING: CPU: 0 PID: 0 at /home/thierry.reding/src/kernel/linux-tegra.git/lib/dma-debug.c:1106 check_unmap+0x7b0/0x930 [ 112.282934] Modules linked in: [ 112.285985] [ 112.287474] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G S W 4.11.0-rc3-next-20170323-00060-g2eab4557749b-dirty #400 [ 112.298581] Hardware name: NVIDIA Tegra186 P2771-0000 Development Board (DT) [ 112.305615] task: ffff000008f87b00 task.stack: ffff000008f70000 [ 112.311523] PC is at check_unmap+0x7b0/0x930 [ 112.315785] LR is at check_unmap+0x7b0/0x930 [ 112.320046] pc : [<ffff0000083d75f0>] lr : [<ffff0000083d75f0>] pstate: 60000145 [ 112.327426] sp : ffff8001f5e50c50 [ 112.330733] x29: ffff8001f5e50c50 x28: ffff000008f75180 [ 112.336042] x27: ffff000008f87b00 x26: 0000000000000020 [ 112.341351] x25: 0000000000000140 x24: ffff000008f81000 [ 112.346660] x23: ffff8001ec4b0810 x22: 0000000057ac6e9d [ 112.351969] x21: 0000000057ac6e9d x20: ffff8001f5e50cb0 [ 112.357277] x19: ffff8001ec4b0810 x18: 0000000000000010 [ 112.362586] x17: 00000000262ea01f x16: 000000000f48bf67 [ 112.367895] x15: 0000000000000006 x14: 5d64396536636137 [ 112.373203] x13: 3530303030303030 x12: 3078303d73736572 [ 112.378511] x11: 6464612065636976 x10: 65645b2064657461 [ 112.383819] x9 : ffff00000852c238 x8 : 00000000000001fb [ 112.389126] x7 : 0000000000000000 x6 : ffff00000810ad58 [ 112.394434] x5 : 0000000000000000 x4 : 0000000000000000 [ 112.399743] x3 : ffffffffffffffff x2 : ffff000008f99258 [ 112.405050] x1 : ffff000008f87b00 x0 : 0000000000000097 [ 112.410358] [ 112.411846] ---[ end trace 48028f96a0e990fb ]--- [ 112.416453] Call trace: [ 112.418895] Exception stack(0xffff8001f5e50a80 to 0xffff8001f5e50bb0) [ 112.425324] 0a80: ffff8001ec4b0810 0001000000000000 ffff8001f5e50c50 ffff0000083d75f0 [ 112.433139] 0aa0: 00000000000001c0 0000000000000000 0000000000000000 ffff000008d1c0c0 [ 112.440954] 0ac0: ffff8001f5e50c50 ffff8001f5e50c50 ffff8001f5e50c10 00000000ffffffc8 [ 112.448769] 0ae0: ffff8001f5e50b10 ffff00000810c3a8 ffff8001f5e50c50 ffff8001f5e50c50 [ 112.456585] 0b00: ffff8001f5e50c10 00000000ffffffc8 ffff8001f5e50bc0 ffff000008178388 [ 112.464399] 0b20: 0000000000000097 ffff000008f87b00 ffff000008f99258 ffffffffffffffff [ 112.472215] 0b40: 0000000000000000 0000000000000000 ffff00000810ad58 0000000000000000 [ 112.480030] 0b60: 00000000000001fb ffff00000852c238 65645b2064657461 6464612065636976 [ 112.487845] 0b80: 3078303d73736572 3530303030303030 5d64396536636137 0000000000000006 [ 112.495659] 0ba0: 000000000f48bf67 00000000262ea01f [ 112.500528] [<ffff0000083d75f0>] check_unmap+0x7b0/0x930 [ 112.505830] [<ffff0000083d77d8>] debug_dma_unmap_page+0x68/0x70 [ 112.511744] [<ffff0000086a9654>] stmmac_free_tx_buffers.isra.1+0x114/0x198 [ 112.518604] [<ffff0000086a9754>] stmmac_tx_err+0x7c/0x160 [ 112.523993] [<ffff0000086a986c>] stmmac_tx_timeout+0x34/0x50 [ 112.529642] [<ffff0000088a1938>] dev_watchdog+0x270/0x2a8 [ 112.535032] [<ffff000008120774>] call_timer_fn+0x64/0xd0 [ 112.540334] [<ffff000008120890>] expire_timers+0xb0/0xc0 [ 112.545636] [<ffff0000081209f8>] run_timer_softirq+0x80/0xc0 [ 112.551284] [<ffff0000080c517c>] __do_softirq+0x10c/0x218 [ 112.556673] [<ffff0000080c55b0>] irq_exit+0xc8/0x118 [ 112.561629] [<ffff00000810cc50>] __handle_domain_irq+0x60/0xb8 [ 112.567450] [<ffff00000808154c>] gic_handle_irq+0x54/0xa8 [ 112.572837] Exception stack(0xffff000008f73dd0 to 0xffff000008f73f00) [ 112.579264] 3dc0: 0000000000000000 0000000000000000 [ 112.587079] 3de0: 0000000000000001 0000000000000000 ffffffffffffea60 ffff000008f73f00 [ 112.594894] 3e00: 00000000000000c0 0000000000000000 0000000000000028 ffff000008f73e40 [ 112.602709] 3e20: 0000000000001130 00000000fa83b2da ffff000008a313a0 0000000000000001 [ 112.610524] 3e40: 0000000000000000 00000019ebd06fc0 000000000f48bf67 00000000262ea01f [ 112.618338] 3e60: 0000000000000010 ffff000008f2b000 ffff000008f7eb58 ffff000008f7e000 [ 112.626152] 3e80: ffff000008f371a0 0000000000000000 0000000000000000 ffff000008f87b00 [ 112.633967] 3ea0: 00000000eff9cf10 0000000000000000 0000000080e60018 ffff000008f73f00 [ 112.641782] 3ec0: ffff00000808524c ffff000008f73f00 ffff000008085250 0000000000000045 [ 112.649597] 3ee0: ffff000008f73f00 00000000ffff47c0 ffffffffffffffff 7fffffffffffffff [ 112.657411] [<ffff0000080827f4>] el1_irq+0xb4/0x128 [ 112.662280] [<ffff000008085250>] arch_cpu_idle+0x10/0x18 [ 112.667581] [<ffff0000080fbbdc>] do_idle+0x10c/0x1f0 [ 112.672537] [<ffff0000080fbeb8>] cpu_startup_entry+0x20/0x28 [ 112.678185] [<ffff000008a0aa64>] rest_init+0xbc/0xc8 [ 112.683140] [<ffff000008e60b4c>] start_kernel+0x384/0x398 [ 112.688528] [<ffff000008e601e0>] __primary_switched+0x64/0x6c
Quoted 1 line
And finally this:
Here it tries to access the descriptors when apparently they don't exist anymore.
Quoted 24 lines
[ 112.843438] x1 : 0000000000000000 x0 : ffff000008061000 [ 112.848743] [ 112.850229] Process swapper/0 (pid: 0, stack limit = 0xffff000008f70000) [ 112.856916] Stack: (0xffff8001f5e50d80 to 0xffff000008f74000) [ 112.862647] Call trace: [ 112.918392] 0c60: 0000000000000000 ffff0000086b4790 0000000000000080 ffff000008865ed8 [ 112.926206] 0c80: ffff0000083d7038 0000000000210d00 0000000040000000 ffff00000852c238 [ 112.934018] 0ca0: 65645b2064657461 6464612065636976 3078303d73736572 3530303030303030 [ 112.941831] 0cc0: 5d64396536636137 0000000000000006 000000000f48bf67 00000000262ea01f [ 112.949645] [<ffff0000086b4790>] dwmac4_rd_init_tx_desc+0x0/0x10 [ 112.955638] [<ffff0000086a986c>] stmmac_tx_timeout+0x34/0x50 [ 112.961285] [<ffff0000088a1938>] dev_watchdog+0x270/0x2a8 [ 112.966672] [<ffff000008120774>] call_timer_fn+0x64/0xd0 [ 112.971973] [<ffff000008120890>] expire_timers+0xb0/0xc0 [ 112.977274] [<ffff0000081209f8>] run_timer_softirq+0x80/0xc0 [ 112.982920] [<ffff0000080c517c>] __do_softirq+0x10c/0x218 [ 112.988307] [<ffff0000080c55b0>] irq_exit+0xc8/0x118The above is with one small change already applied, which seemed like it would be significant, but it didn't have much effect. See below...
Quoted 1 line
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c +0
-0[...]
Quoted 16 lines
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c static int stmmac_rx(struct stmmac_priv *priv, int limit) · line 3362
Quoted 11 lines
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c +4
-3@@ -2977,14 +3356,22 @@ static int stmmac_rx(struct stmmac_priv *priv, int limit)*/ static int stmmac_poll (struct napi_struct *napi,int budget) { - struct stmmac_priv *priv = container_of(napi, struct stmmac_priv, napi); -int work_done =0 ; -u32 chan =STMMAC_CHAN0 ; +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;I changed this to
priv->plat->tx_queues_to_useas used elsewhere to make sure we don't try to clean up non-initialized TX queues. This seems to solve an issue that would occasionally happen after the TX queue timed out, but the fundamental issue is still there.
Yes, you are correct. It should be priv->plat->tx_queues_to_use instead of "u32 tx_count = priv->dma_cap.number_tx_queues;"... sorry for that, but in my setup is the same value. Could you please make a patch for it?
Tahnks!
Quoted 3 lines
Thierry
Re: [v2,net-next,1/3] net: stmmac: enable multiple buffers
Quoted 25 lines · Joao Pinto
Hi Thierry,
Às 5:17 PM de 3/23/2017, Thierry Reding escreveu:
Quoted 22 lines · Joao Pinto
Quoted 9 lines
This patch creates 2 new structures (
stmmac_tx_queueandstmmac_rx_queue) ininclude/linux/stmmac.h, enabling that each RX and TX queue has its own buffers and data.Signed-off-by Joao Pinto <[email protected]>---
changesv1->v2:
- just to keep up versionQuoted 5 lines
drivers/net/ethernet/stmicro/stmmac/chain_mode.c | 45 +- drivers/net/ethernet/stmicro/stmmac/ring_mode.c | 46 +- drivers/net/ethernet/stmicro/stmmac/stmmac.h | 49 +- drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 1306 ++++++++++++++------- 4 files changed, 973 insertions(+), 473 deletions(-)Hi Joao,
This seems to break support on Tegra186 again. I've gone through this patch multiple times and I can't figure out what could be causing it. Any ideas?
Quoted 6 lines
Quoted 4 lines
What I'm seeing is that the transmit queue 0 times out:
[ 101.121774] Sending DHCP requests ... [ 111.841763] NETDEV WATCHDOG: eth0 (dwc-eth-dwmac): transmit queue 0 timed outYou are using a GMAC or GMAC4 aka QoS?
Yes. It's called EQOS (or EAVB) on Tegra186.
Quoted 123 lines
Quoted 3 lines
and then I also see this:
[ 112.252024] dwc-eth-dwmac 2490000.ethernet: DMA-API: device driver tries to free DMA memory it has not allocated [device address=0x0000000057ac6e9d] [size=0 bytes]Humm... Something in
stmmac_free_tx_buffers... I'll need to check.Quoted 72 lines
[ 112.266606] ------------[ cut here ]------------ [ 112.271220] WARNING: CPU: 0 PID: 0 at /home/thierry.reding/src/kernel/linux-tegra.git/lib/dma-debug.c:1106 check_unmap+0x7b0/0x930 [ 112.282934] Modules linked in: [ 112.285985] [ 112.287474] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G S W 4.11.0-rc3-next-20170323-00060-g2eab4557749b-dirty #400 [ 112.298581] Hardware name: NVIDIA Tegra186 P2771-0000 Development Board (DT) [ 112.305615] task: ffff000008f87b00 task.stack: ffff000008f70000 [ 112.311523] PC is at check_unmap+0x7b0/0x930 [ 112.315785] LR is at check_unmap+0x7b0/0x930 [ 112.320046] pc : [<ffff0000083d75f0>] lr : [<ffff0000083d75f0>] pstate: 60000145 [ 112.327426] sp : ffff8001f5e50c50 [ 112.330733] x29: ffff8001f5e50c50 x28: ffff000008f75180 [ 112.336042] x27: ffff000008f87b00 x26: 0000000000000020 [ 112.341351] x25: 0000000000000140 x24: ffff000008f81000 [ 112.346660] x23: ffff8001ec4b0810 x22: 0000000057ac6e9d [ 112.351969] x21: 0000000057ac6e9d x20: ffff8001f5e50cb0 [ 112.357277] x19: ffff8001ec4b0810 x18: 0000000000000010 [ 112.362586] x17: 00000000262ea01f x16: 000000000f48bf67 [ 112.367895] x15: 0000000000000006 x14: 5d64396536636137 [ 112.373203] x13: 3530303030303030 x12: 3078303d73736572 [ 112.378511] x11: 6464612065636976 x10: 65645b2064657461 [ 112.383819] x9 : ffff00000852c238 x8 : 00000000000001fb [ 112.389126] x7 : 0000000000000000 x6 : ffff00000810ad58 [ 112.394434] x5 : 0000000000000000 x4 : 0000000000000000 [ 112.399743] x3 : ffffffffffffffff x2 : ffff000008f99258 [ 112.405050] x1 : ffff000008f87b00 x0 : 0000000000000097 [ 112.410358] [ 112.411846] ---[ end trace 48028f96a0e990fb ]--- [ 112.416453] Call trace: [ 112.418895] Exception stack(0xffff8001f5e50a80 to 0xffff8001f5e50bb0) [ 112.425324] 0a80: ffff8001ec4b0810 0001000000000000 ffff8001f5e50c50 ffff0000083d75f0 [ 112.433139] 0aa0: 00000000000001c0 0000000000000000 0000000000000000 ffff000008d1c0c0 [ 112.440954] 0ac0: ffff8001f5e50c50 ffff8001f5e50c50 ffff8001f5e50c10 00000000ffffffc8 [ 112.448769] 0ae0: ffff8001f5e50b10 ffff00000810c3a8 ffff8001f5e50c50 ffff8001f5e50c50 [ 112.456585] 0b00: ffff8001f5e50c10 00000000ffffffc8 ffff8001f5e50bc0 ffff000008178388 [ 112.464399] 0b20: 0000000000000097 ffff000008f87b00 ffff000008f99258 ffffffffffffffff [ 112.472215] 0b40: 0000000000000000 0000000000000000 ffff00000810ad58 0000000000000000 [ 112.480030] 0b60: 00000000000001fb ffff00000852c238 65645b2064657461 6464612065636976 [ 112.487845] 0b80: 3078303d73736572 3530303030303030 5d64396536636137 0000000000000006 [ 112.495659] 0ba0: 000000000f48bf67 00000000262ea01f [ 112.500528] [<ffff0000083d75f0>] check_unmap+0x7b0/0x930 [ 112.505830] [<ffff0000083d77d8>] debug_dma_unmap_page+0x68/0x70 [ 112.511744] [<ffff0000086a9654>] stmmac_free_tx_buffers.isra.1+0x114/0x198 [ 112.518604] [<ffff0000086a9754>] stmmac_tx_err+0x7c/0x160 [ 112.523993] [<ffff0000086a986c>] stmmac_tx_timeout+0x34/0x50 [ 112.529642] [<ffff0000088a1938>] dev_watchdog+0x270/0x2a8 [ 112.535032] [<ffff000008120774>] call_timer_fn+0x64/0xd0 [ 112.540334] [<ffff000008120890>] expire_timers+0xb0/0xc0 [ 112.545636] [<ffff0000081209f8>] run_timer_softirq+0x80/0xc0 [ 112.551284] [<ffff0000080c517c>] __do_softirq+0x10c/0x218 [ 112.556673] [<ffff0000080c55b0>] irq_exit+0xc8/0x118 [ 112.561629] [<ffff00000810cc50>] __handle_domain_irq+0x60/0xb8 [ 112.567450] [<ffff00000808154c>] gic_handle_irq+0x54/0xa8 [ 112.572837] Exception stack(0xffff000008f73dd0 to 0xffff000008f73f00) [ 112.579264] 3dc0: 0000000000000000 0000000000000000 [ 112.587079] 3de0: 0000000000000001 0000000000000000 ffffffffffffea60 ffff000008f73f00 [ 112.594894] 3e00: 00000000000000c0 0000000000000000 0000000000000028 ffff000008f73e40 [ 112.602709] 3e20: 0000000000001130 00000000fa83b2da ffff000008a313a0 0000000000000001 [ 112.610524] 3e40: 0000000000000000 00000019ebd06fc0 000000000f48bf67 00000000262ea01f [ 112.618338] 3e60: 0000000000000010 ffff000008f2b000 ffff000008f7eb58 ffff000008f7e000 [ 112.626152] 3e80: ffff000008f371a0 0000000000000000 0000000000000000 ffff000008f87b00 [ 112.633967] 3ea0: 00000000eff9cf10 0000000000000000 0000000080e60018 ffff000008f73f00 [ 112.641782] 3ec0: ffff00000808524c ffff000008f73f00 ffff000008085250 0000000000000045 [ 112.649597] 3ee0: ffff000008f73f00 00000000ffff47c0 ffffffffffffffff 7fffffffffffffff [ 112.657411] [<ffff0000080827f4>] el1_irq+0xb4/0x128 [ 112.662280] [<ffff000008085250>] arch_cpu_idle+0x10/0x18 [ 112.667581] [<ffff0000080fbbdc>] do_idle+0x10c/0x1f0 [ 112.672537] [<ffff0000080fbeb8>] cpu_startup_entry+0x20/0x28 [ 112.678185] [<ffff000008a0aa64>] rest_init+0xbc/0xc8 [ 112.683140] [<ffff000008e60b4c>] start_kernel+0x384/0x398 [ 112.688528] [<ffff000008e601e0>] __primary_switched+0x64/0x6cQuoted 1 line
And finally this:
Here it tries to access the descriptors when apparently they don't exist anymore.
Quoted 24 lines
[ 112.843438] x1 : 0000000000000000 x0 : ffff000008061000 [ 112.848743] [ 112.850229] Process swapper/0 (pid: 0, stack limit = 0xffff000008f70000) [ 112.856916] Stack: (0xffff8001f5e50d80 to 0xffff000008f74000) [ 112.862647] Call trace: [ 112.918392] 0c60: 0000000000000000 ffff0000086b4790 0000000000000080 ffff000008865ed8 [ 112.926206] 0c80: ffff0000083d7038 0000000000210d00 0000000040000000 ffff00000852c238 [ 112.934018] 0ca0: 65645b2064657461 6464612065636976 3078303d73736572 3530303030303030 [ 112.941831] 0cc0: 5d64396536636137 0000000000000006 000000000f48bf67 00000000262ea01f [ 112.949645] [<ffff0000086b4790>] dwmac4_rd_init_tx_desc+0x0/0x10 [ 112.955638] [<ffff0000086a986c>] stmmac_tx_timeout+0x34/0x50 [ 112.961285] [<ffff0000088a1938>] dev_watchdog+0x270/0x2a8 [ 112.966672] [<ffff000008120774>] call_timer_fn+0x64/0xd0 [ 112.971973] [<ffff000008120890>] expire_timers+0xb0/0xc0 [ 112.977274] [<ffff0000081209f8>] run_timer_softirq+0x80/0xc0 [ 112.982920] [<ffff0000080c517c>] __do_softirq+0x10c/0x218 [ 112.988307] [<ffff0000080c55b0>] irq_exit+0xc8/0x118The above is with one small change already applied, which seemed like it would be significant, but it didn't have much effect. See below...
Quoted 1 line
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c +0
-0[...]
Quoted 16 lines
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c static int stmmac_rx(struct stmmac_priv *priv, int limit) · line 3362
Quoted 11 lines
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c +4
-3@@ -2977,14 +3356,22 @@ static int stmmac_rx(struct stmmac_priv *priv, int limit)*/ static int stmmac_poll (struct napi_struct *napi,int budget) { - struct stmmac_priv *priv = container_of(napi, struct stmmac_priv, napi); -int work_done =0 ; -u32 chan =STMMAC_CHAN0 ; +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;I changed this to
priv->plat->tx_queues_to_useas used elsewhere to make sure we don't try to clean up non-initialized TX queues. This seems to solve an issue that would occasionally happen after the TX queue timed out, but the fundamental issue is still there.
Quoted 3 lines
Yes, you are correct. It should be
priv->plat->tx_queues_to_useinstead of "u32tx_count=priv->dma_cap.number_tx_queues;"... sorry for that, but in my setup is the same value. Could you please make a patch for it?
Yes, I can submit a patch for that.
After some more testing I did get a couple (roughly 2 out of 10) successful boots (I'm booting over NFS using the EQOS), and given that this pointed towards something related to uninitialized data, I changed all occurrences of kmalloc_array() with kcalloc() and that I've gotten 10 successful reboots out of 10.
I still can't pinpoint why this is now necessary since previously the kmalloc_array() was working just fine. The only thing I can think of is that we're not properly initializing all fields of the new queue structures, since that's the only thing that's changed with this commit.
I haven't investigated in detail yet, but from nothing so far has jumped out at me.
Thierry
Re: [v2,net-next,1/3] net: stmmac: enable multiple buffers
Quoted 175 lines · Thierry Reding
Quoted 25 lines · Joao Pinto
Hi Thierry,
Às 5:17 PM de 3/23/2017, Thierry Reding escreveu:
Quoted 22 lines · Joao Pinto
Quoted 9 lines
This patch creates 2 new structures (
stmmac_tx_queueandstmmac_rx_queue) ininclude/linux/stmmac.h, enabling that each RX and TX queue has its own buffers and data.Signed-off-by Joao Pinto <[email protected]>---
changesv1->v2:
- just to keep up versionQuoted 5 lines
drivers/net/ethernet/stmicro/stmmac/chain_mode.c | 45 +- drivers/net/ethernet/stmicro/stmmac/ring_mode.c | 46 +- drivers/net/ethernet/stmicro/stmmac/stmmac.h | 49 +- drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 1306 ++++++++++++++------- 4 files changed, 973 insertions(+), 473 deletions(-)Hi Joao,
This seems to break support on Tegra186 again. I've gone through this patch multiple times and I can't figure out what could be causing it. Any ideas?
Quoted 6 lines
Quoted 4 lines
What I'm seeing is that the transmit queue 0 times out:
[ 101.121774] Sending DHCP requests ... [ 111.841763] NETDEV WATCHDOG: eth0 (dwc-eth-dwmac): transmit queue 0 timed outYou are using a GMAC or GMAC4 aka QoS?
Yes. It's called EQOS (or EAVB) on Tegra186.
Quoted 123 lines
Quoted 3 lines
and then I also see this:
[ 112.252024] dwc-eth-dwmac 2490000.ethernet: DMA-API: device driver tries to free DMA memory it has not allocated [device address=0x0000000057ac6e9d] [size=0 bytes]Humm... Something in
stmmac_free_tx_buffers... I'll need to check.Quoted 72 lines
[ 112.266606] ------------[ cut here ]------------ [ 112.271220] WARNING: CPU: 0 PID: 0 at /home/thierry.reding/src/kernel/linux-tegra.git/lib/dma-debug.c:1106 check_unmap+0x7b0/0x930 [ 112.282934] Modules linked in: [ 112.285985] [ 112.287474] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G S W 4.11.0-rc3-next-20170323-00060-g2eab4557749b-dirty #400 [ 112.298581] Hardware name: NVIDIA Tegra186 P2771-0000 Development Board (DT) [ 112.305615] task: ffff000008f87b00 task.stack: ffff000008f70000 [ 112.311523] PC is at check_unmap+0x7b0/0x930 [ 112.315785] LR is at check_unmap+0x7b0/0x930 [ 112.320046] pc : [<ffff0000083d75f0>] lr : [<ffff0000083d75f0>] pstate: 60000145 [ 112.327426] sp : ffff8001f5e50c50 [ 112.330733] x29: ffff8001f5e50c50 x28: ffff000008f75180 [ 112.336042] x27: ffff000008f87b00 x26: 0000000000000020 [ 112.341351] x25: 0000000000000140 x24: ffff000008f81000 [ 112.346660] x23: ffff8001ec4b0810 x22: 0000000057ac6e9d [ 112.351969] x21: 0000000057ac6e9d x20: ffff8001f5e50cb0 [ 112.357277] x19: ffff8001ec4b0810 x18: 0000000000000010 [ 112.362586] x17: 00000000262ea01f x16: 000000000f48bf67 [ 112.367895] x15: 0000000000000006 x14: 5d64396536636137 [ 112.373203] x13: 3530303030303030 x12: 3078303d73736572 [ 112.378511] x11: 6464612065636976 x10: 65645b2064657461 [ 112.383819] x9 : ffff00000852c238 x8 : 00000000000001fb [ 112.389126] x7 : 0000000000000000 x6 : ffff00000810ad58 [ 112.394434] x5 : 0000000000000000 x4 : 0000000000000000 [ 112.399743] x3 : ffffffffffffffff x2 : ffff000008f99258 [ 112.405050] x1 : ffff000008f87b00 x0 : 0000000000000097 [ 112.410358] [ 112.411846] ---[ end trace 48028f96a0e990fb ]--- [ 112.416453] Call trace: [ 112.418895] Exception stack(0xffff8001f5e50a80 to 0xffff8001f5e50bb0) [ 112.425324] 0a80: ffff8001ec4b0810 0001000000000000 ffff8001f5e50c50 ffff0000083d75f0 [ 112.433139] 0aa0: 00000000000001c0 0000000000000000 0000000000000000 ffff000008d1c0c0 [ 112.440954] 0ac0: ffff8001f5e50c50 ffff8001f5e50c50 ffff8001f5e50c10 00000000ffffffc8 [ 112.448769] 0ae0: ffff8001f5e50b10 ffff00000810c3a8 ffff8001f5e50c50 ffff8001f5e50c50 [ 112.456585] 0b00: ffff8001f5e50c10 00000000ffffffc8 ffff8001f5e50bc0 ffff000008178388 [ 112.464399] 0b20: 0000000000000097 ffff000008f87b00 ffff000008f99258 ffffffffffffffff [ 112.472215] 0b40: 0000000000000000 0000000000000000 ffff00000810ad58 0000000000000000 [ 112.480030] 0b60: 00000000000001fb ffff00000852c238 65645b2064657461 6464612065636976 [ 112.487845] 0b80: 3078303d73736572 3530303030303030 5d64396536636137 0000000000000006 [ 112.495659] 0ba0: 000000000f48bf67 00000000262ea01f [ 112.500528] [<ffff0000083d75f0>] check_unmap+0x7b0/0x930 [ 112.505830] [<ffff0000083d77d8>] debug_dma_unmap_page+0x68/0x70 [ 112.511744] [<ffff0000086a9654>] stmmac_free_tx_buffers.isra.1+0x114/0x198 [ 112.518604] [<ffff0000086a9754>] stmmac_tx_err+0x7c/0x160 [ 112.523993] [<ffff0000086a986c>] stmmac_tx_timeout+0x34/0x50 [ 112.529642] [<ffff0000088a1938>] dev_watchdog+0x270/0x2a8 [ 112.535032] [<ffff000008120774>] call_timer_fn+0x64/0xd0 [ 112.540334] [<ffff000008120890>] expire_timers+0xb0/0xc0 [ 112.545636] [<ffff0000081209f8>] run_timer_softirq+0x80/0xc0 [ 112.551284] [<ffff0000080c517c>] __do_softirq+0x10c/0x218 [ 112.556673] [<ffff0000080c55b0>] irq_exit+0xc8/0x118 [ 112.561629] [<ffff00000810cc50>] __handle_domain_irq+0x60/0xb8 [ 112.567450] [<ffff00000808154c>] gic_handle_irq+0x54/0xa8 [ 112.572837] Exception stack(0xffff000008f73dd0 to 0xffff000008f73f00) [ 112.579264] 3dc0: 0000000000000000 0000000000000000 [ 112.587079] 3de0: 0000000000000001 0000000000000000 ffffffffffffea60 ffff000008f73f00 [ 112.594894] 3e00: 00000000000000c0 0000000000000000 0000000000000028 ffff000008f73e40 [ 112.602709] 3e20: 0000000000001130 00000000fa83b2da ffff000008a313a0 0000000000000001 [ 112.610524] 3e40: 0000000000000000 00000019ebd06fc0 000000000f48bf67 00000000262ea01f [ 112.618338] 3e60: 0000000000000010 ffff000008f2b000 ffff000008f7eb58 ffff000008f7e000 [ 112.626152] 3e80: ffff000008f371a0 0000000000000000 0000000000000000 ffff000008f87b00 [ 112.633967] 3ea0: 00000000eff9cf10 0000000000000000 0000000080e60018 ffff000008f73f00 [ 112.641782] 3ec0: ffff00000808524c ffff000008f73f00 ffff000008085250 0000000000000045 [ 112.649597] 3ee0: ffff000008f73f00 00000000ffff47c0 ffffffffffffffff 7fffffffffffffff [ 112.657411] [<ffff0000080827f4>] el1_irq+0xb4/0x128 [ 112.662280] [<ffff000008085250>] arch_cpu_idle+0x10/0x18 [ 112.667581] [<ffff0000080fbbdc>] do_idle+0x10c/0x1f0 [ 112.672537] [<ffff0000080fbeb8>] cpu_startup_entry+0x20/0x28 [ 112.678185] [<ffff000008a0aa64>] rest_init+0xbc/0xc8 [ 112.683140] [<ffff000008e60b4c>] start_kernel+0x384/0x398 [ 112.688528] [<ffff000008e601e0>] __primary_switched+0x64/0x6cQuoted 1 line
And finally this:
Here it tries to access the descriptors when apparently they don't exist anymore.
Quoted 24 lines
[ 112.843438] x1 : 0000000000000000 x0 : ffff000008061000 [ 112.848743] [ 112.850229] Process swapper/0 (pid: 0, stack limit = 0xffff000008f70000) [ 112.856916] Stack: (0xffff8001f5e50d80 to 0xffff000008f74000) [ 112.862647] Call trace: [ 112.918392] 0c60: 0000000000000000 ffff0000086b4790 0000000000000080 ffff000008865ed8 [ 112.926206] 0c80: ffff0000083d7038 0000000000210d00 0000000040000000 ffff00000852c238 [ 112.934018] 0ca0: 65645b2064657461 6464612065636976 3078303d73736572 3530303030303030 [ 112.941831] 0cc0: 5d64396536636137 0000000000000006 000000000f48bf67 00000000262ea01f [ 112.949645] [<ffff0000086b4790>] dwmac4_rd_init_tx_desc+0x0/0x10 [ 112.955638] [<ffff0000086a986c>] stmmac_tx_timeout+0x34/0x50 [ 112.961285] [<ffff0000088a1938>] dev_watchdog+0x270/0x2a8 [ 112.966672] [<ffff000008120774>] call_timer_fn+0x64/0xd0 [ 112.971973] [<ffff000008120890>] expire_timers+0xb0/0xc0 [ 112.977274] [<ffff0000081209f8>] run_timer_softirq+0x80/0xc0 [ 112.982920] [<ffff0000080c517c>] __do_softirq+0x10c/0x218 [ 112.988307] [<ffff0000080c55b0>] irq_exit+0xc8/0x118The above is with one small change already applied, which seemed like it would be significant, but it didn't have much effect. See below...
Quoted 1 line
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c +0
-0[...]
Quoted 16 lines
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c static int stmmac_rx(struct stmmac_priv *priv, int limit) · line 3362
Quoted 11 lines
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c +4
-3@@ -2977,14 +3356,22 @@ static int stmmac_rx(struct stmmac_priv *priv, int limit)*/ static int stmmac_poll (struct napi_struct *napi,int budget) { - struct stmmac_priv *priv = container_of(napi, struct stmmac_priv, napi); -int work_done =0 ; -u32 chan =STMMAC_CHAN0 ; +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;I changed this to
priv->plat->tx_queues_to_useas used elsewhere to make sure we don't try to clean up non-initialized TX queues. This seems to solve an issue that would occasionally happen after the TX queue timed out, but the fundamental issue is still there.Quoted 3 lines
Yes, you are correct. It should be
priv->plat->tx_queues_to_useinstead of "u32tx_count=priv->dma_cap.number_tx_queues;"... sorry for that, but in my setup is the same value. Could you please make a patch for it?Yes, I can submit a patch for that.
After some more testing I did get a couple (roughly 2 out of 10) successful boots (I'm booting over NFS using the EQOS), and given that this pointed towards something related to uninitialized data, I changed all occurrences of
kmalloc_array()withkcalloc()and that I've gotten 10 successful reboots out of 10.I still can't pinpoint why this is now necessary since previously the
kmalloc_array()was working just fine. The only thing I can think of is that we're not properly initializing all fields of the new queue structures, since that's the only thing that's changed with this commit.
Quoted 4 lines
I haven't investigated in detail yet, but from nothing so far has jumped out at me.
Thierry
I have tried this change, but it made the situation worse on dwmac-sunxi (no network at all).
Joao, perhaps it's time to revert the faulty (and very huge) patch and rework it by splitting at least in two:
- adding RX queue / adding TX queue
And more if possible (like just adding an unused queue parameter) or a patch just for adding stmmac_free_tx_buffers() for example. I think it will help to find where the problem is.
And this time I will test them before applying:)
Regards
Corentin Labbe
Re: [v2,net-next,1/3] net: stmmac: enable multiple buffers
Às 2:09 PM de 3/24/2017, Corentin Labbe escreveu:
Quoted 30 lines · Thierry Reding
Quoted 17 lines · Joao Pinto
Quoted 2 lines
Hi Thierry,
Yes, I can submit a patch for that.
After some more testing I did get a couple (roughly 2 out of 10) successful boots (I'm booting over NFS using the EQOS), and given that this pointed towards something related to uninitialized data, I changed all occurrences of
kmalloc_array()withkcalloc()and that I've gotten 10 successful reboots out of 10.I still can't pinpoint why this is now necessary since previously the
kmalloc_array()was working just fine. The only thing I can think of is that we're not properly initializing all fields of the new queue structures, since that's the only thing that's changed with this commit.Quoted 4 lines
I haven't investigated in detail yet, but from nothing so far has jumped out at me.
Thierry
I have tried this change, but it made the situation worse on dwmac-sunxi (no network at all).
Joao, perhaps it's time to revert the faulty (and very huge) patch and rework it by splitting at least in two:
- adding RX queue / adding TX queue
And more if possible (like just adding an unused queue parameter) or a patch just for addingstmmac_free_tx_buffers()for example. I think it will help to find where the problem is.
Quoted 5 lines
And this time I will test them before applying:)
Regards
Corentin Labbe
Yes, I agree, it is better to revert and leave the tree functional for all.
@David Miller:
The multiple-buffer patch introduced some problems in some setups that are being hard to debug, so Corentin gave the idea of reverting the until commit 7bac4e1ec3ca2342929a39638d615c6b672c27a0 (net: stmmac: stmmac interrupt treatment prepared for multiple queues), which I fully agree.
In my setup is ok, but the idea is to have everyone's setup working :), so lets break them into smaller pieces, and let's only apply them when everyone confirms that is working ok in your setups, agree?
What is the typical mechanism for this? I send a patch reverting them?
Thanks,
Joao
Fwd: Re: [v2,net-next,1/3] net: stmmac: enable multiple buffers
Sorry, sending again with David Miller in TO: instead of CC.
Às 2:09 PM de 3/24/2017, Corentin Labbe escreveu:
Quoted 30 lines · Thierry Reding
Quoted 17 lines · Joao Pinto
Quoted 2 lines
Hi Thierry,
Yes, I can submit a patch for that.
After some more testing I did get a couple (roughly 2 out of 10) successful boots (I'm booting over NFS using the EQOS), and given that this pointed towards something related to uninitialized data, I changed all occurrences of
kmalloc_array()withkcalloc()and that I've gotten 10 successful reboots out of 10.I still can't pinpoint why this is now necessary since previously the
kmalloc_array()was working just fine. The only thing I can think of is that we're not properly initializing all fields of the new queue structures, since that's the only thing that's changed with this commit.Quoted 4 lines
I haven't investigated in detail yet, but from nothing so far has jumped out at me.
Thierry
I have tried this change, but it made the situation worse on dwmac-sunxi (no network at all).
Joao, perhaps it's time to revert the faulty (and very huge) patch and rework it by splitting at least in two:
- adding RX queue / adding TX queue
And more if possible (like just adding an unused queue parameter) or a patch just for addingstmmac_free_tx_buffers()for example. I think it will help to find where the problem is.
Quoted 5 lines
And this time I will test them before applying:)
Regards
Corentin Labbe
Yes, I agree, it is better to revert and leave the tree functional for all.
@David Miller:
The multiple-buffer patch introduced some problems in some setups that are being hard to debug, so Corentin gave the idea of reverting the until commit 7bac4e1ec3ca2342929a39638d615c6b672c27a0 (net: stmmac: stmmac interrupt treatment prepared for multiple queues), which I fully agree.
In my setup is ok, but the idea is to have everyone's setup working :), so lets break them into smaller pieces, and let's only apply them when everyone confirms that is working ok in your setups, agree?
What is the typical mechanism for this? I send a patch reverting them?
Thanks,
Joao
David Miller
maintainerRe: [v2,net-next,1/3] net: stmmac: enable multiple buffers
From: Joao Pinto <[email protected]>
Date: Fri, 24 Mar 2017 15:02:27 +0000
Quoted 8 lines
Yes, I agree, it is better to revert and leave the tree functional for all.
@David Miller:
The multiple-buffer patch introduced some problems in some setups that are being hard to debug, so Corentin gave the idea of reverting the until commit7bac4e1ec3ca2342929a39638d615c6b672c27a0(net: stmmac: stmmac interrupt treatment prepared for multiple queues), which I fully agree.
Quoted 5 lines
In my setup is ok, but the idea is to have everyone's setup working :), so lets break them into smaller pieces, and let's only apply them when everyone confirms that is working ok in your setups, agree?
What is the typical mechanism for this? I send a patch reverting them?
If you can compose a single "git revert" command to achieve this, just tell me what it is and I'll do it.
Otherwise send a patch that does the revert.
Thanks.
Re: [v2,net-next,1/3] net: stmmac: enable multiple buffers
Às 5:17 PM de 3/24/2017, David Miller escreveu:
Quoted 15 lines
From: Joao Pinto <[email protected]>
Date: Fri, 24 Mar 2017 15:02:27 +0000Quoted 12 lines
Yes, I agree, it is better to revert and leave the tree functional for all.
@David Miller:
The multiple-buffer patch introduced some problems in some setups that are being hard to debug, so Corentin gave the idea of reverting the until commit7bac4e1ec3ca2342929a39638d615c6b672c27a0(net: stmmac: stmmac interrupt treatment prepared for multiple queues), which I fully agree.In my setup is ok, but the idea is to have everyone's setup working :), so lets break them into smaller pieces, and let's only apply them when everyone confirms that is working ok in your setups, agree?
Quoted 6 lines
Quoted 1 line
What is the typical mechanism for this? I send a patch reverting them?
If you can compose a single "git revert" command to achieve this, just tell me what it is and I'll do it.
Otherwise send a patch that does the revert.
Ok, I sent 2 patches with fixes. Let's see if you get some happy clients. If not, I will inform the commit id to revert.
Thanks David.
Quoted 3 lines
Thanks.
Re: [v2,net-next,1/3] net: stmmac: enable multiple buffers
In reply to Joao PintoQuoted 3 lines · Joao Pinto
Yes, you are correct. It should be
priv->plat->tx_queues_to_useinstead of "u32tx_count=priv->dma_cap.number_tx_queues;"... sorry for that, but in my setup is the same value. Could you please make a patch for it?
Hi Joao
As the new maintainer, don't you think you should be testing on multiple systems? There are SoC vendor reference design boards you can buy, and set up a test farm. You can then ensure your new features don't break stuff, or add performance regressions.
Andrew
Re: [v2,net-next,1/3] net: stmmac: enable multiple buffers
Hi Andrew,
Às 7:42 AM de 3/24/2017, Andrew Lunn escreveu:
Quoted 6 lines · Joao Pinto
Quoted 4 lines
Yes, you are correct. It should be
priv->plat->tx_queues_to_useinstead of "u32tx_count=priv->dma_cap.number_tx_queues;"... sorry for that, but in my setup is the same value. Could you please make a patch for it?
Quoted 9 lines
Hi Joao
As the new maintainer, don't you think you should be testing on multiple systems? There are SoC vendor reference design boards you can buy, and set up a test farm. You can then ensure your new features don't break stuff, or add performance regressions.
Andrew
I am not the maintainer of stmmac :), I am just developing on it like everyone else, just glad to help improving it and adding new features to it. Of course if the current maintainers invite me to be, I will honored to do so.
Yes it would be fantastic to have a set of boards, but I rarely see this in any maintainer :). I think it would be nice to have a farm like Linaro has with a farm of boards donated by each company, enabling tests for everyone in the project. I have talked with the Prototyping team and I will have an AXI based design, which will emulate the SoC environment making possible to test the platform driver scope.
I try as hard as I can to network with people and try to minimize this situations, but when there is so many different setups using a driver with diff configurations, situations like this can happen, but I am here to help debugging and solving them.
Joao
Re: [v2,net-next,1/3] net: stmmac: enable multiple buffers
Quoted 2 lines
Yes it would be fantastic to have a set of boards, but I rarely see this in any maintainer :).
Being a Marvell SoC and switch maintainer, i have around a dozen boards. Some i got some simply by asking the manufacture, others i purchased. I don't think i'm in the minority here. Without having access to a number of different hardwares, i don't feel i would be doing my work properly.
Quoted 4 lines
I try as hard as I can to network with people and try to minimize this situations, but when there is so many different setups using a driver with diff configurations, situations like this can happen, but I am here to help debugging and solving them.
You made a move to rename stmmac to synopsys not long ago. It gave the impression that synopsis wants to take over this driver. If there are a number of different configurations, who better than synopsys to actually properly test these configurations? If you ask around, i'm sure people will send you hardware.
Andrew
Re: [v2,net-next,1/3] net: stmmac: enable multiple buffers
Às 11:17 AM de 3/24/2017, Andrew Lunn escreveu:
Quoted 14 lines
Quoted 2 lines
Yes it would be fantastic to have a set of boards, but I rarely see this in any maintainer :).
Being a Marvell SoC and switch maintainer, i have around a dozen boards. Some i got some simply by asking the manufacture, others i purchased. I don't think i'm in the minority here. Without having access to a number of different hardwares, i don't feel i would be doing my work properly.
Quoted 4 lines
I try as hard as I can to network with people and try to minimize this situations, but when there is so many different setups using a driver with diff configurations, situations like this can happen, but I am here to help debugging and solving them.
Quoted 5 lines
You made a move to rename stmmac to synopsys not long ago. It gave the impression that synopsis wants to take over this driver. If there are a number of different configurations, who better than synopsys to actually properly test these configurations? If you ask around, i'm sure people will send you hardware.
If the stmmac community wishes that I become the maintainer and are available to send me their ref hardware, I am available and I can build a farm in my site to make all necessary tests to all the patches made by me and the ones that I receive.
Quoted 3 lines
Andrew
Joao
David Miller
maintainerRe: [v2,net-next,1/3] net: stmmac: enable multiple buffers
In reply to Andrew LunnFrom: Andrew Lunn <[email protected]>
Date: Fri, 24 Mar 2017 12:17:36 +0100
Quoted 14 lines
Quoted 2 lines
Yes it would be fantastic to have a set of boards, but I rarely see this in any maintainer :).
Being a Marvell SoC and switch maintainer, i have around a dozen boards. Some i got some simply by asking the manufacture, others i purchased. I don't think i'm in the minority here. Without having access to a number of different hardwares, i don't feel i would be doing my work properly.
Quoted 4 lines
I try as hard as I can to network with people and try to minimize this situations, but when there is so many different setups using a driver with diff configurations, situations like this can happen, but I am here to help debugging and solving them.
Quoted 5 lines
You made a move to rename stmmac to synopsys not long ago. It gave the impression that synopsis wants to take over this driver. If there are a number of different configurations, who better than synopsys to actually properly test these configurations? If you ask around, i'm sure people will send you hardware.
I completely agree with everything Andrew is saying here.
Re: [v2,net-next,1/3] net: stmmac: enable multiple buffers
Hello David,
Às 5:05 PM de 3/24/2017, David Miller escreveu:
Quoted 17 lines
From: Andrew Lunn <[email protected]>
Date: Fri, 24 Mar 2017 12:17:36 +0100Quoted 14 lines
Quoted 2 lines
Yes it would be fantastic to have a set of boards, but I rarely see this in any maintainer :).
Being a Marvell SoC and switch maintainer, i have around a dozen boards. Some i got some simply by asking the manufacture, others i purchased. I don't think i'm in the minority here. Without having access to a number of different hardwares, i don't feel i would be doing my work properly.
Quoted 4 lines
I try as hard as I can to network with people and try to minimize this situations, but when there is so many different setups using a driver with diff configurations, situations like this can happen, but I am here to help debugging and solving them.
Quoted 8 lines
Quoted 5 lines
You made a move to rename stmmac to synopsys not long ago. It gave the impression that synopsis wants to take over this driver. If there are a number of different configurations, who better than synopsys to actually properly test these configurations? If you ask around, i'm sure people will send you hardware.
I completely agree with everything Andrew is saying here.
I'll maintain the driver if everyone agrees with it, no problem, mas I would like to hear from Peppe and Alex, since they are the current maintainers.
HW testing would be nice, but hard to justify investing in one shot, so it would be great to receive hardware to make tests if the companies wish it.
About the problems in the last patch I am going to send a 2 patch set with 2 fixes, lets see if stuff gets better.
Thnaks
Joao
Re: [v2,net-next,1/3] net: stmmac: enable multiple buffers
Hi Joao
Quoted 27 lines · Joao Pinto
Hello David,
Às 5:05 PM de 3/24/2017, David Miller escreveu:
Quoted 23 lines
From: Andrew Lunn <[email protected]>
Date: Fri, 24 Mar 2017 12:17:36 +0100Quoted 19 lines
Quoted 2 lines
Yes it would be fantastic to have a set of boards, but I rarely see this in any maintainer :).
Being a Marvell SoC and switch maintainer, i have around a dozen boards. Some i got some simply by asking the manufacture, others i purchased. I don't think i'm in the minority here. Without having access to a number of different hardwares, i don't feel i would be doing my work properly.
Quoted 4 lines
I try as hard as I can to network with people and try to minimize this situations, but when there is so many different setups using a driver with diff configurations, situations like this can happen, but I am here to help debugging and solving them.
You made a move to rename stmmac to synopsys not long ago. It gave the impression that synopsis wants to take over this driver. If there are a number of different configurations, who better than synopsys to actually properly test these configurations? If you ask around, i'm sure people will send you hardware.
Quoted 5 lines
Quoted 2 lines
I completely agree with everything Andrew is saying here.
I'll maintain the driver if everyone agrees with it, no problem, mas I would like to hear from Peppe and Alex, since they are the current maintainers.
I agree with this proposition. As you can see (and unfortunately) I have currently no time for reviewing (I'm busy on another subsystem). You are close to new GMAC evolution and very active (I hope for a long time). For sure you need boards with old GMAC Ips. I will send you an STM32 with GMAC IP 3.5. Don't hesitate to contact us if you have question about historic content of stmmac driver.
Thanks!
Alex
Quoted 10 lines
HW testing would be nice, but hard to justify investing in one shot, so it would be great to receive hardware to make tests if the companies wish it.
About the problems in the last patch I am going to send a 2 patch set with 2 fixes, lets see if stuff gets better.
Thnaks
Joao
Re: [v2,net-next,1/3] net: stmmac: enable multiple buffers
Às 10:28 AM de 3/27/2017, Alexandre Torgue escreveu:
Quoted 39 lines
Hi Joao
Quoted 30 lines · Joao Pinto
Hello David,
Às 5:05 PM de 3/24/2017, David Miller escreveu:
Quoted 26 lines
From: Andrew Lunn <[email protected]>
Date: Fri, 24 Mar 2017 12:17:36 +0100Quoted 22 lines
Quoted 3 lines
Yes it would be fantastic to have a set of boards, but I rarely see this in any
maintainer :).Being a Marvell SoC and switch maintainer, i have around a dozen boards. Some i got some simply by asking the manufacture, others i purchased. I don't think i'm in the minority here. Without having access to a number of different hardwares, i don't feel i would be doing my work properly.
Quoted 6 lines
I try as hard as I can to network with people and try to minimize this situations, but when there is so many different setups using a driver with diff
configurations, situations like this can happen, but I am here to help debugging
and solving them.You made a move to rename stmmac to synopsys not long ago. It gave the impression that synopsis wants to take over this driver. If there are a number of different configurations, who better than synopsys to actually properly test these configurations? If you ask around, i'm sure people will send you hardware.
Quoted 5 lines
Quoted 2 lines
I completely agree with everything Andrew is saying here.
I'll maintain the driver if everyone agrees with it, no problem, mas I would like to hear from Peppe and Alex, since they are the current maintainers.
Quoted 6 lines
I agree with this proposition. As you can see (and unfortunately) I have currently no time for reviewing (I'm busy on another subsystem). You are close to new GMAC evolution and very active (I hope for a long time).
For sure you need boards with old GMAC Ips. I will send you an STM32 with GMAC IP 3.5. Don't hesitate to contact us if you have question about historic content of stmmac driver.
Thanks Alex, I will do my best to maintain it! That would be great to have a board with an older IP to test. I will send you my office address soon. Thanks!
@ Peppe: Are you ok with it?
Thanks.
Quoted 17 lines
Thanks!
Alex
Quoted 10 lines
HW testing would be nice, but hard to justify investing in one shot, so it would be great to receive hardware to make tests if the companies wish it.
About the problems in the last patch I am going to send a 2 patch set with 2 fixes, lets see if stuff gets better.
Thnaks
Joao
PATCH v2 2/3 net: stmmac: TX and RX queue priority configuration
In reply to Joao PintoThis patch adds the configuration of RX and TX queues' priority.
---
changes v1->v2:
- added range value info in the DT bindings
Documentation/devicetree/bindings/net/stmmac.txt | 5 +++ drivers/net/ethernet/stmicro/stmmac/common.h | 4 ++ drivers/net/ethernet/stmicro/stmmac/dwmac4.h | 13 ++++++ drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c | 37 +++++++++++++++++ drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 48 ++++++++++++++++++++++ drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c | 4 ++ .../net/ethernet/stmicro/stmmac/stmmac_platform.c | 16 ++++++++ include/linux/stmmac.h | 4 ++ 8 files changed, 131 insertions(+)
Documentation/devicetree/bindings/net/stmmac.txt +5 -0
@@ -83,6 +83,7 @@ Optional properties: - snps,dcb-algorithm: Queue to be enabled as DCB - snps,avb-algorithm: Queue to be enabled as AVB - snps,map-to-dma-channel: Channel to map + - snps,priority: RX queue priority (Range: 0x0 to 0xF) - Multiple TX Queues parameters: below the list of all the parameters to configure the multiple TX queues: - snps,tx-queues-to-use: number of TX queues to be used in the driver
@@ -101,6 +102,7 @@ Optional properties: - snps,idle_slope: unlock on WoL - snps,high_credit: max write outstanding req. limit - snps,low_credit: max read outstanding req. limit + - snps,priority: TX queue priority (Range: 0x0 to 0xF) Examples: stmmac_axi_setup: stmmac-axi-config {
@@ -115,6 +117,7 @@ Examples: queue0 { snps,dcb-algorithm; snps,map-to-dma-channel = <0x0>; + snps,priority = <0x0>; }; };
@@ -124,6 +127,7 @@ Examples: queue0 { snps,weight = <0x10>; snps,dcb-algorithm; + snps,priority = <0x0>; }; queue1 {
@@ -132,6 +136,7 @@ Examples: snps,idle_slope = <0x1000>; snps,high_credit = <0x3E800>; snps,low_credit = <0xFFC18000>; + snps,priority = <0x1>; }; };
drivers/net/ethernet/stmicro/stmmac/common.h +4 -0
@@ -469,6 +469,10 @@ struct stmmac_ops {int (*rx_ipc)(struct mac_device_info *hw);/* Enable RX Queues */ void (*rx_queue_enable)(struct mac_device_info *hw,u8 mode,u32 queue); +/* RX Queues Priority */ +void (*rx_queue_prio)(struct mac_device_info *hw,u32 prio,u32 queue); +/* TX Queues Priority */ +void (*tx_queue_prio)(struct mac_device_info *hw,u32 prio,u32 queue);/* Program RX Algorithms */ void (*prog_mtl_rx_algorithms)(struct mac_device_info *hw,u32 rx_alg);/* Program TX Algorithms */
drivers/net/ethernet/stmicro/stmmac/dwmac4.h +13 -0
@@ -22,7 +22,12 @@#define GMAC_HASH_TAB_32_63 0x00000014#define GMAC_RX_FLOW_CTRL 0x00000090#define GMAC_QX_TX_FLOW_CTRL (x) (0x70 + x * 4) +#define GMAC_TXQ_PRTY_MAP0 0x98 +#define GMAC_TXQ_PRTY_MAP1 0x9C#define GMAC_RXQ_CTRL0 0x000000a0 +#define GMAC_RXQ_CTRL1 0x000000a4 +#define GMAC_RXQ_CTRL2 0x000000a8 +#define GMAC_RXQ_CTRL3 0x000000ac#define GMAC_INT_STATUS 0x000000b0#define GMAC_INT_EN 0x000000b4#define GMAC_1US_TIC_COUNTER 0x000000dc
@@ -54,6 +59,14 @@/* MAC Flow Control RX */ #define GMAC_RX_FLOW_CTRL_RFE BIT(0) +/* RX Queues Priorities */ +#define GMAC_RXQCTRL_PSRQX_MASK (x) GENMASK(7 + ((x) * 8), 0 + ((x) * 8)) +#define GMAC_RXQCTRL_PSRQX_SHIFT (x) ((x) * 8) + +/* TX Queues Priorities */ +#define GMAC_TXQCTRL_PSTQX_MASK (x) GENMASK(7 + ((x) * 8), 0 + ((x) * 8)) +#define GMAC_TXQCTRL_PSTQX_SHIFT (x) ((x) * 8) +/* MAC Flow Control TX */ #define GMAC_TX_FLOW_CTRL_TFE BIT(1)#define GMAC_TX_FLOW_CTRL_PT_SHIFT 16
drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c +37 -0
@@ -74,6 +74,41 @@ static void dwmac4_rx_queue_enable(struct mac_device_info *hw,writel (value, ioaddr +GMAC_RXQ_CTRL0 ); } +static void dwmac4_rx_queue_priority (struct mac_device_info *hw, +u32 prio,u32 queue) +{ +void __iomem *ioaddr = hw->pcsr; +u32 base_register; +u32 value; + + base_register = (queue <4 ) ?GMAC_RXQ_CTRL2 :GMAC_RXQ_CTRL3 ; + + value =readl (ioaddr + base_register); + + value &= ~GMAC_RXQCTRL_PSRQX_MASK (queue); + value |= (prio <<GMAC_RXQCTRL_PSRQX_SHIFT (queue)) & +GMAC_RXQCTRL_PSRQX_MASK (queue); +writel (value, ioaddr + base_register); +} + +static void dwmac4_tx_queue_priority (struct mac_device_info *hw, +u32 prio,u32 queue) +{ +void __iomem *ioaddr = hw->pcsr; +u32 base_register; +u32 value; + + base_register = (queue <4 ) ?GMAC_TXQ_PRTY_MAP0 :GMAC_TXQ_PRTY_MAP1 ; + + value =readl (ioaddr + base_register); + + value &= ~GMAC_TXQCTRL_PSTQX_MASK (queue); + value |= (prio <<GMAC_TXQCTRL_PSTQX_SHIFT (queue)) & +GMAC_TXQCTRL_PSTQX_MASK (queue); + +writel (value, ioaddr + base_register); +} +static void dwmac4_prog_mtl_rx_algorithms (struct mac_device_info *hw,u32 rx_alg) {
@@ -603,6 +638,8 @@ static const struct stmmac_ops dwmac4_ops = { .core_init = dwmac4_core_init, .rx_ipc = dwmac4_rx_ipc_enable, .rx_queue_enable = dwmac4_rx_queue_enable, + .rx_queue_prio = dwmac4_rx_queue_priority, + .tx_queue_prio = dwmac4_tx_queue_priority, .prog_mtl_rx_algorithms = dwmac4_prog_mtl_rx_algorithms, .prog_mtl_tx_algorithms = dwmac4_prog_mtl_tx_algorithms, .set_mtl_tx_queue_weight = dwmac4_set_mtl_tx_queue_weight,
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c +48 -0
60 lines not on this page · raw message
drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c +4 -0
@@ -92,6 +92,10 @@ static void stmmac_default_data(struct plat_stmmacenet_data *plat)/* Set default number of RX and TX queues to use */ plat->tx_queues_to_use =1 ; plat->rx_queues_to_use =1 ; + +/* Disable Priority config by default */ + plat->tx_queues_cfg[0 ].use_prio = false; + plat->rx_queues_cfg[0 ].use_prio = false; } static int quark_default_data(struct plat_stmmacenet_data *plat,
drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c +16 -0
@@ -182,6 +182,14 @@ static void stmmac_mtl_setup(struct platform_device *pdev, plat->rx_queues_cfg[queue].chan = queue;/* TODO: Dynamic mapping to be included in the future */ +if (of_property_read_u32 (q_node,"snps,priority" , + &plat->rx_queues_cfg[queue].prio)) { + plat->rx_queues_cfg[queue].prio =0 ; + plat->rx_queues_cfg[queue].use_prio = false; + }else { + plat->rx_queues_cfg[queue].use_prio = true; + } + queue++; }
@@ -235,6 +243,14 @@ static void stmmac_mtl_setup(struct platform_device *pdev, plat->tx_queues_cfg[queue].mode_to_use =MTL_QUEUE_DCB ; } +if (of_property_read_u32 (q_node,"snps,priority" , + &plat->tx_queues_cfg[queue].prio)) { + plat->tx_queues_cfg[queue].prio =0 ; + plat->tx_queues_cfg[queue].use_prio = false; + }else { + plat->tx_queues_cfg[queue].use_prio = true; + } + queue++; }
include/linux/stmmac.h +4 -0
@@ -127,6 +127,8 @@ struct stmmac_axi {struct stmmac_rxq_cfg {u8 mode_to_use;u8 chan; +bool use_prio; +u32 prio; };struct stmmac_txq_cfg {
@@ -137,6 +139,8 @@ struct stmmac_txq_cfg {u32 idle_slope;u32 high_credit;u32 low_credit; +bool use_prio; +u32 prio; };struct plat_stmmacenet_data {
Signature · 1 line
2.9.3
PATCH v2 3/3 net: stmmac: RX queue routing configuration
In reply to Joao PintoThis patch adds the configuration of RX queues' routing.
---
changes v1->v2:
- DT bindings were changed to bool
- DT parsing was simplified, improving routing parameter scalability
Documentation/devicetree/bindings/net/stmmac.txt | 6 ++++ drivers/net/ethernet/stmicro/stmmac/common.h | 17 +++++++++++ drivers/net/ethernet/stmicro/stmmac/dwmac4.h | 16 ++++++++++ drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c | 34 ++++++++++++++++++++++ drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 25 ++++++++++++++++ drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c | 3 ++ .../net/ethernet/stmicro/stmmac/stmmac_platform.c | 14 +++++++++ include/linux/stmmac.h | 1 + 8 files changed, 116 insertions(+)
Documentation/devicetree/bindings/net/stmmac.txt +6 -0
@@ -83,6 +83,12 @@ Optional properties: - snps,dcb-algorithm: Queue to be enabled as DCB - snps,avb-algorithm: Queue to be enabled as AVB - snps,map-to-dma-channel: Channel to map + - Specifiy specific packet routing: + - snps,route-avcp: AV Untagged Control packets + - snps,route-ptp: PTP Packets + - snps,route-dcbcp: DCB Control Packets + - snps,route-up: Untagged Packets + - snps,route-multi-broad: Multicast & Broadcast Packets - snps,priority: RX queue priority (Range: 0x0 to 0xF) - Multiple TX Queues parameters: below the list of all the parameters to configure the multiple TX queues:
drivers/net/ethernet/stmicro/stmmac/common.h +17 -0
@@ -246,6 +246,15 @@ struct stmmac_extra_stats {#define STMMAC_TX_MAX_FRAMES 256#define STMMAC_TX_FRAMES 64 +/* Packets types */ +enum packets_types { +PACKET_AVCPQ =0x1 ,/* AV Untagged Control packets */ +PACKET_PTPQ =0x2 ,/* PTP Packets */ +PACKET_DCBCPQ =0x3 ,/* DCB Control Packets */ +PACKET_UPQ =0x4 ,/* Untagged Packets */ +PACKET_MCBCQ =0x5 ,/* Multicast & Broadcast Packets */ +}; +/* Rx IPC status */ enum rx_frame_status { good_frame =0x0 ,
@@ -473,6 +482,9 @@ struct stmmac_ops {void (*rx_queue_prio)(struct mac_device_info *hw,u32 prio,u32 queue);/* TX Queues Priority */ void (*tx_queue_prio)(struct mac_device_info *hw,u32 prio,u32 queue); +/* RX Queues Routing */ +void (*rx_queue_routing)(struct mac_device_info *hw,u8 packet, +u32 queue);/* Program RX Algorithms */ void (*prog_mtl_rx_algorithms)(struct mac_device_info *hw,u32 rx_alg);/* Program TX Algorithms */
@@ -581,6 +593,11 @@ struct mac_device_info {unsigned int ps; }; +struct stmmac_rx_routing { +u32 reg_mask; +u32 reg_shift; +}; +struct mac_device_info *dwmac1000_setup (void __iomem *ioaddr,int mcbins,int perfect_uc_entries,int *synopsys_id);
drivers/net/ethernet/stmicro/stmmac/dwmac4.h +16 -0
@@ -44,6 +44,22 @@#define GMAC_ADDR_HIGH (reg) (0x300 + reg * 8)#define GMAC_ADDR_LOW (reg) (0x304 + reg * 8) +/* RX Queues Routing */ +#define GMAC_RXQCTRL_AVCPQ_MASK GENMASK(2, 0) +#define GMAC_RXQCTRL_AVCPQ_SHIFT 0 +#define GMAC_RXQCTRL_PTPQ_MASK GENMASK(6, 4) +#define GMAC_RXQCTRL_PTPQ_SHIFT 4 +#define GMAC_RXQCTRL_DCBCPQ_MASK GENMASK(10, 8) +#define GMAC_RXQCTRL_DCBCPQ_SHIFT 8 +#define GMAC_RXQCTRL_UPQ_MASK GENMASK(14, 12) +#define GMAC_RXQCTRL_UPQ_SHIFT 12 +#define GMAC_RXQCTRL_MCBCQ_MASK GENMASK(18, 16) +#define GMAC_RXQCTRL_MCBCQ_SHIFT 16 +#define GMAC_RXQCTRL_MCBCQEN BIT(20) +#define GMAC_RXQCTRL_MCBCQEN_SHIFT 20 +#define GMAC_RXQCTRL_TACPQE BIT(21) +#define GMAC_RXQCTRL_TACPQE_SHIFT 21 +/* MAC Packet Filtering */ #define GMAC_PACKET_FILTER_PR BIT(0)#define GMAC_PACKET_FILTER_HMC BIT(2)
drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c +34 -0
@@ -109,6 +109,39 @@ static void dwmac4_tx_queue_priority(struct mac_device_info *hw,writel (value, ioaddr + base_register); } +static void dwmac4_tx_queue_routing (struct mac_device_info *hw, +u8 packet,u32 queue) +{ +void __iomem *ioaddr = hw->pcsr; +u32 value; + +const struct stmmac_rx_routing route_possibilities[] = { + {GMAC_RXQCTRL_AVCPQ_MASK ,GMAC_RXQCTRL_AVCPQ_SHIFT }, + {GMAC_RXQCTRL_PTPQ_MASK ,GMAC_RXQCTRL_PTPQ_SHIFT }, + {GMAC_RXQCTRL_DCBCPQ_MASK ,GMAC_RXQCTRL_DCBCPQ_SHIFT }, + {GMAC_RXQCTRL_UPQ_MASK ,GMAC_RXQCTRL_UPQ_SHIFT }, + {GMAC_RXQCTRL_MCBCQ_MASK ,GMAC_RXQCTRL_MCBCQ_SHIFT }, + }; + + value =readl (ioaddr +GMAC_RXQ_CTRL1 ); + +/* routing configuration */ + value &= ~route_possibilities[packet -1 ].reg_mask; + value |= (queue << route_possibilities[packet-1 ].reg_shift) & + route_possibilities[packet -1 ].reg_mask; + +/* some packets require extra ops */ +if (packet ==PACKET_AVCPQ ) { + value &= ~GMAC_RXQCTRL_TACPQE ; + value |=0x1 <<GMAC_RXQCTRL_TACPQE_SHIFT ; + }else if (packet ==PACKET_MCBCQ ) { + value &= ~GMAC_RXQCTRL_MCBCQEN ; + value |=0x1 <<GMAC_RXQCTRL_MCBCQEN_SHIFT ; + } + +writel (value, ioaddr +GMAC_RXQ_CTRL1 ); +} +static void dwmac4_prog_mtl_rx_algorithms (struct mac_device_info *hw,u32 rx_alg) {
@@ -640,6 +673,7 @@ static const struct stmmac_ops dwmac4_ops = { .rx_queue_enable = dwmac4_rx_queue_enable, .rx_queue_prio = dwmac4_rx_queue_priority, .tx_queue_prio = dwmac4_tx_queue_priority, + .rx_queue_routing = dwmac4_tx_queue_routing, .prog_mtl_rx_algorithms = dwmac4_prog_mtl_rx_algorithms, .prog_mtl_tx_algorithms = dwmac4_prog_mtl_tx_algorithms, .set_mtl_tx_queue_weight = dwmac4_set_mtl_tx_queue_weight,
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c +25 -0
@@ -2333,6 +2333,27 @@ static void stmmac_mac_config_tx_queues_prio(struct stmmac_priv *priv) }/** +* stmmac_mac_config_rx_queues_routing - Configure RX Queue Routing +* @priv: driver private structure +* Description: It is used for configuring the RX queue routing +*/ +static void stmmac_mac_config_rx_queues_routing (struct stmmac_priv *priv) +{ +u32 rx_queues_count = priv->plat->rx_queues_to_use; +u32 queue; +u8 packet; + +for (queue =0 ; queue < rx_queues_count; queue++) { +/* no specific packet type routing specified for the queue */ +if (priv->plat->rx_queues_cfg[queue].pkt_route ==0x0 ) +continue ; + + packet = priv->plat->rx_queues_cfg[queue].pkt_route; + priv->hw->mac->rx_queue_prio (priv->hw, packet, queue); + } +} + +/** * stmmac_mtl_configuration - Configure MTL * @priv: driver private structure * Description: It is used for configurring MTL
@@ -2377,6 +2398,10 @@ static void stmmac_mtl_configuration(struct stmmac_priv *priv)/* Set TX priorities */ if (tx_queues_count >1 && priv->hw->mac->tx_queue_prio)stmmac_mac_config_tx_queues_prio (priv); + +/* Set RX routing */ +if (rx_queues_count >1 && priv->hw->mac->rx_queue_routing) +stmmac_mac_config_rx_queues_routing (priv); }/**
drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c +3 -0
@@ -96,6 +96,9 @@ static void stmmac_default_data(struct plat_stmmacenet_data *plat)/* Disable Priority config by default */ plat->tx_queues_cfg[0 ].use_prio = false; plat->rx_queues_cfg[0 ].use_prio = false; + +/* Disable RX queues routing by default */ + plat->rx_queues_cfg[0 ].pkt_route =0x0 ; } static int quark_default_data(struct plat_stmmacenet_data *plat,
drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c +14 -0
@@ -190,6 +190,20 @@ static void stmmac_mtl_setup(struct platform_device *pdev, plat->rx_queues_cfg[queue].use_prio = true; } +/* RX queue specific packet type routing */ +if (of_property_read_bool (q_node,"snps,route-avcp" )) + plat->rx_queues_cfg[queue].pkt_route =PACKET_AVCPQ ; +else if (of_property_read_bool (q_node,"snps,route-ptp" )) + plat->rx_queues_cfg[queue].pkt_route =PACKET_PTPQ ; +else if (of_property_read_bool (q_node,"snps,route-dcbcp" )) + plat->rx_queues_cfg[queue].pkt_route =PACKET_DCBCPQ ; +else if (of_property_read_bool (q_node,"snps,route-up" )) + plat->rx_queues_cfg[queue].pkt_route =PACKET_UPQ ; +else if (of_property_read_bool (q_node,"snps,route-multi-broad" )) + plat->rx_queues_cfg[queue].pkt_route =PACKET_MCBCQ ; +else + plat->rx_queues_cfg[queue].pkt_route =0x0 ; + queue++; }
include/linux/stmmac.h +1 -0
@@ -127,6 +127,7 @@ struct stmmac_axi {struct stmmac_rxq_cfg {u8 mode_to_use;u8 chan; +u8 pkt_route;bool use_prio;u32 prio; };
Signature · 1 line
2.9.3
David Miller
maintainerFrom: Joao Pinto <[email protected]>
Date: Fri, 17 Mar 2017 16:11:04 +0000
Quoted 8 lines
As agreed with David Miller, this patch-set is the third and last to enable multiple queues in stmmac.
This third one focuses on:
a) Enable multiple buffering to the driver and queue independent data
b) Configuration of RX and TX queues' priority
c) Configuration of RX queues' routing
Series applied, thanks.