Comment 7 for bug 90243

OK, I managed to get a traceback of the soft lockup on my system, but unfortunately I screwed up and it didn't get captured like I thought it was. So I don't have the traceback, and I didn't read it that closely before I rebooted, since I thought I had it saved to study later.

However, I did look at it enough to get the idea that some "MlmeXXX" function was calling del_timer_sync() from a timer callback (which is of course an instant deadlock).

And indeed, the first del_timer_sync() call I check shows the following problem. MlmeAssocReqAction() (which is called from the STATE_MACHINE obfuscation) does

       del_timer_sync(&pAd->MlmeAux.AssocTimer);

and AssocTimer runs AssocTimeout(), which calls MlmeHandler(), which runs the STATE_MACHINE crap. So the AssocTimer callback can deadlock easily.

Based on this, rt61 seems utterly broken by design and prone to deadlocking if anything times out. Aside from this deadlock problem, the source is bloated and unreadable, so I think the best thing to do would be to throw it away once and for all. The rt61pci driver seems a lot saner to me, and indeed a complete rewrite like that seems to be the only way to salvage this driver. I don't know what the problems with rt61pci are, but I don't see how rt61pci could be worse than rt61.

If I get a chance I may try (out of morbid curiousity) to get the exact traceback that's deadlocking my system, but I don't have any hope that the issue will be fixable without a driver rewrite.