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.
--
[rt61] Lockups running Feisty on x86-64
https://launchpad.net/bugs/90243
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
