1
0
mirror of https://git.FreeBSD.org/src.git synced 2024-12-17 10:26:15 +00:00

[iwn] Don't try to seamlessly recover from a firmware panic; just restart

the interface.

I know this may be unpopular, but iwn is not yet completely ready for
a transparent firmware restart.  I have this thing panic my laptop
reliably because 11n state isn't kept in sync and the TX completion
path ends up trying to free a null node reference.
This commit is contained in:
Adrian Chadd 2016-04-03 23:39:58 +00:00
parent 2b1e924b69
commit 598003be2d
Notes: svn2git 2020-12-20 02:59:44 +00:00
svn path=/head/; revision=297531

View File

@ -8701,7 +8701,9 @@ iwn_panicked(void *arg0, int pending)
struct iwn_softc *sc = arg0;
struct ieee80211com *ic = &sc->sc_ic;
struct ieee80211vap *vap = TAILQ_FIRST(&ic->ic_vaps);
#if 0
int error;
#endif
if (vap == NULL) {
printf("%s: null vap\n", __func__);
@ -8709,8 +8711,18 @@ iwn_panicked(void *arg0, int pending)
}
device_printf(sc->sc_dev, "%s: controller panicked, iv_state = %d; "
"resetting...\n", __func__, vap->iv_state);
"restarting\n", __func__, vap->iv_state);
/*
* This is not enough work. We need to also reinitialise
* the correct transmit state for aggregation enabled queues,
* which has a very specific requirement of
* ring index = 802.11 seqno % 256. If we don't do this (which
* we definitely don't!) then the firmware will just panic again.
*/
#if 1
ieee80211_restart_all(ic);
#else
IWN_LOCK(sc);
iwn_stop_locked(sc);
@ -8727,6 +8739,7 @@ iwn_panicked(void *arg0, int pending)
}
IWN_UNLOCK(sc);
#endif
}
static void