We have those bug reports on RH bugzilla, and various other iwlwifi problems, but those have some common scenario: https://bugzilla.redhat.com/show_bug.cgi?id=979873 https://bugzilla.redhat.com/show_bug.cgi?id=990536 https://bugzilla.redhat.com/show_bug.cgi?id=994322 https://bugzilla.redhat.com/show_bug.cgi?id=996502 https://bugzilla.redhat.com/show_bug.cgi?id=969610 https://bugzilla.redhat.com/show_bug.cgi?id=999053 First there is Microcode error or other firmware problem, what make we do iwl_trans_stop_device() which set trans->state to IWL_TRANS_NO_FW. If mac80211 has some pending works/timers i.e. ieee80211_sta_work(), it calls drv and we trigger on of those warnings WARN_ONCE(trans->state != IWL_TRANS_FW_ALIVE, "%s bad state = %d", __func__, trans->state); on some trans operation. I think this can be fixed by first do quiesce on mac80211 (for example by ieee80211_sta_quiesce() procedure, which I removed but can be added back) and then do iwlagn_prepare_restart() & ieee80211_restart_hw(). Though I'm not sure if it's worth to do this since those warnings are indicator for malfunctioning iwlwifi firmware (or driver not correctly communicating with firmware), which will be unnoticed if not reported automatically by tool like ABRT. But perhaps we could add WARN_ONCE on Microcode error condition ? Additionally I wonder if there is good way to debug those microcode problems (I mean root of the problem), since most of them happen at random after hours or days uptime? Thoughts? Stanislaw -- 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
