From owner-cvs-src-old@FreeBSD.ORG Sun Jun 26 13:53:39 2011 Return-Path: Delivered-To: cvs-src-old@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6F28F1065786 for ; Sun, 26 Jun 2011 13:53:39 +0000 (UTC) (envelope-from adrian@FreeBSD.org) Received: from repoman.freebsd.org (repoman.freebsd.org [IPv6:2001:4f8:fff6::29]) by mx1.freebsd.org (Postfix) with ESMTP id 5E7868FC13 for ; Sun, 26 Jun 2011 13:53:39 +0000 (UTC) Received: from repoman.freebsd.org (localhost [127.0.0.1]) by repoman.freebsd.org (8.14.4/8.14.4) with ESMTP id p5QDrdk6025994 for ; Sun, 26 Jun 2011 13:53:39 GMT (envelope-from adrian@repoman.freebsd.org) Received: (from svn2cvs@localhost) by repoman.freebsd.org (8.14.4/8.14.4/Submit) id p5QDrduC025993 for cvs-src-old@freebsd.org; Sun, 26 Jun 2011 13:53:39 GMT (envelope-from adrian@repoman.freebsd.org) Message-Id: <201106261353.p5QDrduC025993@repoman.freebsd.org> X-Authentication-Warning: repoman.freebsd.org: svn2cvs set sender to adrian@repoman.freebsd.org using -f From: Adrian Chadd Date: Sun, 26 Jun 2011 13:53:24 +0000 (UTC) To: cvs-src-old@freebsd.org X-FreeBSD-CVS-Branch: HEAD Subject: cvs commit: src/sys/dev/ath if_ath.c X-BeenThere: cvs-src-old@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: **OBSOLETE** CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jun 2011 13:53:39 -0000 adrian 2011-06-26 13:53:24 UTC FreeBSD src repository Modified files: sys/dev/ath if_ath.c Log: SVN rev 223568 on 2011-06-26 13:53:24Z by adrian Fix beacon transmission after a channel set. The DFS code was tickling the channel set directly whilst going through the state RUN -> CSA -> RUN. This only changed the channel; it didn't go via ath_reset(). However in this driver, a channel change always causes a chip reset, which resets the beacon timer configuration and interrupt setup. This meant that data would go out but as the beacon timers never fired, beacons would never be queued. The confusing part is that sometimes the state transition was RUN -> SCAN -> CAC -> RUN (with CSA being in there sometimes); going via SCAN would clear sc_beacons and thus the transition to RUN would reprogram beacon transmission. In case someone tries debugging why suspending a device currently beaconing (versus just RX'ing beacons which is what occurs in STA mode), add a silly comment which should hopefully land them at this commit message. The call to ath_hal_reset() will be clearing the beacon config and it may not be always reset. Revision Changes Path 1.328 +21 -0 src/sys/dev/ath/if_ath.c