Comment 4 for bug 37773

No lockups as of yet. The errors were undeterministic, and I HAVE had lock up-free days, but hardly this many in a row, so I'd say the bug is fixed. I've had to rebuild wpasupplicant to work with madwifi-ng and I have yet to teach NetworkManager to make sure that the ath0 device is in UP state before asking it to do a scan (this is apparantly behaviour by design in madwifi-ng), but that shouldn't be too hard.

I realise that substituting madwifi for madwifi-ng is quite intrusive in this part of the process, so the optimal solution would of course be to locate the error in madwifi (the "old" version) and fix it. If it can't be found in a short period of time, I really do think we should consider madwifi-ng in place of madwifi. The IBM Thinkpad X40 is by no means an uncommon laptop and the wifi card in it is by no means an uncommon one either, so I think this particular bug will affect quite a few people. For me, it has caused data loss too (due to xfs in combination with laptop-mode holds off disk syncing for quite a while and when this crash happens, anything not synced is lost).