On 01/29/2013 09:29 PM, Sujith Manoharan wrote:
Ben Greear wrote:
I hit this warning in ath9k. Shortly after the machine blew up elsewhere,
but not sure if this is to blame or not.
Code is slightly modified 3.7.5 (just a few patches, not my normal mass of hackings!)
The warning that hit is the one below:
bf = ath9k_beacon_generate(sc->hw, vif);
WARN_ON(!bf);
Test case is dual-core Atom system with ath9k NIC, 10 or so virtual stations,
two virtual APs. Two stations send traffic to each other once everything associates, but
not sure it got that far when this crash happened.
Are these patches in your tree ?
They were not. I see the second was queued to stable, should the first one
be a stable candidate as well?
Thanks,
Ben
commit 1381559ba48a04ca7c98f1b4c487bd44d0b75db5
Author: Felix Fietkau <nbd@xxxxxxxxxxx>
Date: Sun Jan 20 18:51:53 2013 +0100
ath9k: clean up processing of pending tx frames on reset
Dropping packets from aggregation sessions is usually not a good idea, as
it might upset the synchronization of the BlockAck receive window of the
remote node. The use of the retry_tx parameter to reset/tx-drain functions
also seemed a bit arbitrary.
This patch removes this parameter altogether and ensures that pending tx
frames are not dropped for no good reason.
Signed-off-by: Felix Fietkau <nbd@xxxxxxxxxxx>
Signed-off-by: John W. Linville <linville@xxxxxxxxxxxxx>
commit 3adcf20afb585993ffee24de36d1975f6b26b120
Author: Felix Fietkau <nbd@xxxxxxxxxxx>
Date: Wed Jan 9 16:16:54 2013 +0100
ath9k: remove the WARN_ON that triggers if generating a beacon fails
During teardown, mac80211 will not return a new beacon. This is normal and
handled properly in the driver, so there's no need to spam the user with a kernel
warning here.
Cc: stable@xxxxxxxxxxxxxxx
Signed-off-by: Felix Fietkau <nbd@xxxxxxxxxxx>
Signed-off-by: John W. Linville <linville@xxxxxxxxxxxxx>
Sujith
--
Ben Greear <greearb@xxxxxxxxxxxxxxx>
Candela Technologies Inc http://www.candelatech.com
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
