[rt2x00-users] rt2800pci: hang on module unload (SoC) and possible fix

Helmut Schaa helmut.schaa at googlemail.com
Wed Apr 21 16:02:13 UTC 2010


when using rt2800pci on the 305x SoC board it hangs sometimes when taking
the interface
down (everytime if at least one frame has been transmitted). It seems like
the device gets
stuck somehow and hangs the whole system. Yeah, that's the advantage of
using a SoC ;)

Is anybody aware of similar issues on pci cards?

Nevertheless I've managed to find the cause of the hang  but I'm unsure on
howto fix this
in a nice and clean way. In order to disable the tx queues I had to disable
TX DMA first, to
be precise, before disabling the first queue already.

Using the patch below (disable TX DMA just before killing the tx queues)
works just fine
but is more like a hack.

What would be a clean way of fixing this issue?
1) Introduce a new callback disable_dma which would be called before calling
   kill_tx_queue for every queue (from rt2x00 code)?
2) Just use the patch below as the code is only run from disable_radio which
   disable DMA anyway (later)?
3) just do nothing in rt2800_kill_tx_queue as I couldn't find any reference
to similar
   code in the ralink drivers?
4) Any other ideas?


Signed-off-by: Helmut Schaa <helmut.schaa at googlemail.com>
 drivers/net/wireless/rt2x00/rt2800pci.c |    4 ++++
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/drivers/net/wireless/rt2x00/rt2800pci.c
index 0e52f17..f96fa8a 100644
--- a/drivers/net/wireless/rt2x00/rt2800pci.c
+++ b/drivers/net/wireless/rt2x00/rt2800pci.c
@@ -806,6 +806,10 @@ static void rt2800pci_kill_tx_queue(struct rt2x00_dev
         rt2800_register_write(rt2x00dev, BCN_TIME_CFG, 0);
+    rt2800_register_read(rt2x00dev, WPDMA_GLO_CFG, &reg);
+    rt2x00_set_field32(&reg, WPDMA_GLO_CFG_ENABLE_TX_DMA, 0);
+    rt2800_register_write(rt2x00dev, WPDMA_GLO_CFG, reg);

     rt2800_register_read(rt2x00dev, WPDMA_RST_IDX, &reg);
     rt2x00_set_field32(&reg, WPDMA_RST_IDX_DTX_IDX0, (qid == QID_AC_BE));
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rt2x00.serialmonkey.com/pipermail/users_rt2x00.serialmonkey.com/attachments/20100421/dd59b815/attachment.html>

More information about the users mailing list