Well, problem is not solved after all. Had total of 5 crashes on overnight run, must have
all been before midnight, because that is the earliest logs I see (journald was not configured
to use enough space...fixed for next time) and no crashes since then.
Still, it is at least no worse.
I wonder if similar wb() is needed in the firmware somewhere?
Thanks,
Ben
On 01/09/2015 04:36 PM, Ben Greear wrote:
I added this to my tree (and a bunch more debug stuff to track
CE transport-ids), and I've done about 4500 station reconnects over
the last 2 hours and no tx-credits hang issue so far.
Could be my debugging code or that I'm getting lucky, but I'm hopeful
that your patch actually fixed the problem I was seeing!
Thanks,
Ben
On 01/09/2015 09:19 AM, Vasanthakumar Thiagarajan wrote:
When replenishing Rx buffers driver updates the address of the
buffer and the index of rx buffer in rx ring to the firmware.
Change in order by CPU can cause rx ring corruption. Add memory
barrier before updating rx buffer index to guarantee the order.
This could fix some instances of rx ring corruption due to done
bit in rx attention flag not set.
Signed-off-by: Vasanthakumar Thiagarajan <vthiagar@xxxxxxxxxxxxxxxx>
---
drivers/net/wireless/ath/ath10k/htt_rx.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/net/wireless/ath/ath10k/htt_rx.c b/drivers/net/wireless/ath/ath10k/htt_rx.c
index 9c782a4..baa1c44 100644
--- a/drivers/net/wireless/ath/ath10k/htt_rx.c
+++ b/drivers/net/wireless/ath/ath10k/htt_rx.c
@@ -97,6 +97,11 @@ static int __ath10k_htt_rx_ring_fill_n(struct ath10k_htt *htt, int num)
}
fail:
+ /*
+ * Make sure the rx buffer is updated before available buffer
+ * index to avoid any potential rx ring corruption.
+ */
+ mb();
*htt->rx_ring.alloc_idx.vaddr = __cpu_to_le32(idx);
return ret;
}
--
Ben Greear <greearb@xxxxxxxxxxxxxxx>
Candela Technologies Inc http://www.candelatech.com
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
