"Bob Copeland" <me@xxxxxxxxxxxxxxx> wrote: > On Wed, Oct 1, 2008 at 5:10 PM, Elias Oltmanns <eo@xxxxxxxxxxxxxx> wrote: >> Toralf Förster <toralf.foerster@xxxxxx> wrote: > >>> Hello, >>> >>> the issue (initially reported in August 2008) still remains in the current >>> kernel at my ThinkPad T41, a screen shot is attached. The steps to reproduce >>> are : >>> >>> 1. modprobe it >>> 2. suspend the system to ram >>> 3. wake it up >>> 4. rmmod the driver >> >> Yes, I have run into this problem too. The patch below (applies to >> 2.6.27-rc8) fixes the problem, but since I'm not a wireless hacker, >> developers might prefer a different approach. Please let me know if I >> should change anything. Perhaps I should split this into two separate >> patches? > > Thanks for the patch. I do think a different approach is probably > warranted, though. ath5k_init() is supposed to be able to be called from > resume. Do you have a better idea of why calib_tim isn't cleaned up > properly by ath5k_stop_hw? Oh, but it is cleaned up by ath5k_stop_hw(). The issue is a different one here: ath5k_init() == ->start() ath5k_stop_hw() == ->stop() Since the mac80211 layer never opened a device, it won't close it either. Thus, ath5k_stop_hw() does not get called on module unload. By calling ath5k_init() on resume, the driver has effectively started the device when it was not supposed to do so and this event is not being tracked by the higher layers. > > I'm not near my laptop to test -- does the issue ever happen if you do > NOT suspend? If you don't do a suspend / resume cycle but simply load and unload the module, this is not an issue because ath5k_init() never gets called unless the mac80211 layer tells the driver to do so. Regards, Elias -- 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
