Dave,

One more for 2.6.27 -- a fix for a possible interrupt storm.  There is
even a link in the commit log to a youtube video of the storm in
progress. :-)

Let me know if there are problems!

John

---

Individual patch is available here:

	http://www.kernel.org/pub/linux/kernel/people/linville/wireless-2.6/

---

The following changes since commit 4c07ab0fe4b4eaa0fc31f640ca65da7c173f5043:
  David S. Miller (1):
        Merge branch 'master' of git://git.kernel.org/.../linville/wireless-2.6

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git master

Luis R. Rodriguez (1):
      ath9k: disable MIB interrupts to fix interrupt storm

 drivers/net/wireless/ath9k/core.c |    7 +++++++
 1 files changed, 7 insertions(+), 0 deletions(-)

diff --git a/drivers/net/wireless/ath9k/core.c b/drivers/net/wireless/ath9k/core.c
index c049593..87e37bc 100644
--- a/drivers/net/wireless/ath9k/core.c
+++ b/drivers/net/wireless/ath9k/core.c
@@ -795,6 +795,12 @@ int ath_open(struct ath_softc *sc, struct ath9k_channel *initial_chan)
 	if (ah->ah_caps.hw_caps & ATH9K_HW_CAP_HT)
 		sc->sc_imask |= ATH9K_INT_CST;
 
+	/* Note: We disable MIB interrupts for now as we don't yet
+	 * handle processing ANI, otherwise you will get an interrupt
+	 * storm after about 7 hours of usage making the system unusable
+	 * with huge latency. Once we do have ANI processing included
+	 * we can re-enable this interrupt. */
+#if 0
 	/*
 	 * Enable MIB interrupts when there are hardware phy counters.
 	 * Note we only do this (at the moment) for station mode.
@@ -802,6 +808,7 @@ int ath_open(struct ath_softc *sc, struct ath9k_channel *initial_chan)
 	if (ath9k_hw_phycounters(ah) &&
 	    ((sc->sc_opmode == ATH9K_M_STA) || (sc->sc_opmode == ATH9K_M_IBSS)))
 		sc->sc_imask |= ATH9K_INT_MIB;
+#endif
 	/*
 	 * Some hardware processes the TIM IE and fires an
 	 * interrupt when the TIM bit is set.  For hardware
-- 
John W. ...
[ message continues ]

From: "John W. Linville" <linville@tuxdriver.com>

Pulled, thanks John.
--

[ message continues ]

Can you also add this one? It doesn't panic the kernel when a frame from
firmware is invalid.

http://marc.info/?l=linux-wireless&m=122219037706528&w=2

Thanks,
-yi

--

[ message continues ]

Is there an open bug report for that anywhere?  Is this something
that real users (no offense to Johannes) are likely to hit?

John
-- 
John W. Linville		Linux should be at the core
linville@tuxdriver.com			of your literate lifestyle.
--

[ message continues ]

Actually, I now think that we don't want the patch. It appears that when
this situation happens, the hardware has scribbled over memory elsewhere
(most likely because of wrong DMA programming) and in that case I
suppose we'd rather fail than corrupt disk buffers et. al.

johannes
[ message continues ]

On Thu, Sep 25, 2008 at 2:41 PM, John W. Linville

I'm just exporting the major bugs from our internal database to
buzilla, 5000 is new so
we are hitting the problems during testing  before users report them.

Now I don't know if it was good idea to push the driver upstream same
time as it hits the market.
Tomas
--

[ message continues ]

You're right -- pushing it sooner rather than sitting on it internally
probably would have helped to give it more visibility sooner.

John
-- 
John W. Linville		Linux should be at the core
linville@tuxdriver.com			of your literate lifestyle.
--

[ message continues ]

On Thu, Sep 25, 2008 at 6:47 PM, John W. Linville

 I think it was pushed on time it would not bring the fixes sooner.
But we are getting again to the same arguments
Tomas
--

[ message continues ]

I was hitting this one a frequent basis on a 64-bit Linux running on an
off-the-shelf X61.

Regards

Marcel


--

[ message continues ]