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
