Please note: This project is no longer active. The website is kept online for historic purposes only.
If you´re looking for a Linux driver for your Atheros WLAN device, you should continue here .

Ticket #1209 (new defect)

Opened 15 years ago

Adhoc freezes occasionally

Reported by: sven-ola@gmx.de Assigned to:
Priority: major Milestone:
Component: madwifi: HAL Version: v0.9.3
Keywords: adhoc freezes Cc:
Patch is attached: 0 Pending:

Description

We extensively use adhoc (aka ibss) in our freifunk mesh networks. While stumbling across the freeze on MIPS (kernel 2.4.20) first, this is also true on i386 (kernel 2.6.15-28-386). Traffic pattern: 5-15 packets per second as broadcast (...the OLSR mesh routing hellos) with "iwconfig ath0 mode ad-hoc channel 10 rts 250 essid olsr.freifunk.net" as well as an "iwconfig ath0 ap 02:ca:ff:ee:ba:be" to use a fixed BSSID because IBSS merge/TSF handling is normally damn buggy (not only in madwifi).

Madwifi simply stops sending packets. Here's an old but nevertheless functioning workaround. Talked with nbd (from openwrt) about this. He expressed something like "can be a real hardware bug and I don't find it while poking trough the HAL".

Workaround patch:

diff -Nur trunk.orig/ath/if_ath.c trunk/ath/if_ath.c
--- trunk.orig/ath/if_ath.c	2006-05-20 11:09:21.000000000 +0200
+++ trunk/ath/if_ath.c	2006-05-28 08:38:20.000000000 +0200
@@ -1576,6 +1576,19 @@
 }
 
 /*
+ * On MIPS/Meshcubes with Atheros AR5213A-00 MiniPCI cards the TX interrupt
+ * every ~5 mins stops working. All other ints are OK. No error code, no status
+ * sign but stacking up packets for some minutes until some internal watchdog
+ * reinits. Visible with "athstats ast_tx_discard". Did not find the reason
+ * (RTS with 10 seconds!?) and this is not showing up everywhere in Berlin. 
+ * Interrupt programming and semaphores seems to be OK. Wifi settings are: 
+ * ad-hoc channel 10 rts 250 frag off key off, iwconfig ap 02:caff:ee:ba:be
+ */
+ 
+static long sven_jiffies = 0;
+static long sven_tx_intr = 0;
+
+/*
  * Interrupt handler.  Most of the actual processing is deferred.
  */
 irqreturn_t
@@ -1673,6 +1686,7 @@
 			} 
 #endif
 			ATH_SCHEDULE_TQUEUE(&sc->sc_txtq, &needmark);
+			sven_tx_intr = 0;
 		}
 		if (status & HAL_INT_BMISS) {
 			sc->sc_stats.ast_bmiss++;
@@ -2224,6 +2238,16 @@
 		txq->axq_link = &lastds->ds_link;
 		ath_hal_txstart(ah, txq->axq_qnum);
 		sc->sc_dev->trans_start = jiffies;
+		if (0 == sven_tx_intr) {
+			sven_tx_intr = 1;
+			sven_jiffies = jiffies;
+		}
+		else if (jiffies - sven_jiffies > 100) {
+			printk("sven_jiffies=%ld, jiffies=%lud\n", sven_jiffies, jiffies);
+			// More than 200 jiffies since last tx interrup
+			ath_reset(sc->sc_dev);
+			sven_jiffies = jiffies;
+		}
 	}
 	ATH_TXQ_UNLOCK(txq);
 
@@ -5305,6 +5329,12 @@
 		    vap->iv_state == IEEE80211_S_RUN) {
 			u_int64_t tsf = ath_extend_tsf(sc->sc_ah, rstamp);
 			/*
+			 * Sven-Ola: It does not hurt to wait for a time diff
+			 * of 0.1 seconds until IBSS merge. Otherwise the debug
+			 * output will show up too often. Therefore: tsf + 100000
+			 */
+			tsf += 100000;
+			/*
 			 * Handle ibss merge as needed; check the tsf on the
 			 * frame before attempting the merge.  The 802.11 spec
 			 * says the station should change it's bssid to match