Interrupts with the sync_cause AR_INTR_SYNC_HOST1_FATAL has to be handled using a chip reset. Otherwise a interrupt storm with unhandled interrupts will cause a hang or crash of the machine.
Signed-off-by: Sven Eckelmann <s...@narfation.org> --- I was informed that AR_INTR_SYNC_HOST1_PERR should not be handled this way because it can create system freezes after an adhoc interface was created. I really need some Atheros developer who can check the documentation to verify the interpretation of these flags. Otherwise this is just guessing and may lead to even bigger problems. drivers/net/wireless/ath/ath9k/ar9003_mac.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/drivers/net/wireless/ath/ath9k/ar9003_mac.c b/drivers/net/wireless/ath/ath9k/ar9003_mac.c index d5b2e0e..6031bdf 100644 --- a/drivers/net/wireless/ath/ath9k/ar9003_mac.c +++ b/drivers/net/wireless/ath/ath9k/ar9003_mac.c @@ -311,6 +311,11 @@ static bool ar9003_hw_get_isr(struct ath_hw *ah, enum ath9k_int *masked) if (sync_cause) { ath9k_debug_sync_cause(common, sync_cause); + if (sync_cause & AR_INTR_SYNC_HOST1_FATAL) { + ath_dbg(common, ANY, "received PCI FATAL interrupt\n"); + *masked |= ATH9K_INT_FATAL; + } + if (sync_cause & AR_INTR_SYNC_RADM_CPL_TIMEOUT) { REG_WRITE(ah, AR_RC, AR_RC_HOSTIF); REG_WRITE(ah, AR_RC, 0); -- 1.7.10.4 _______________________________________________ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel