From owner-freebsd-wireless@FreeBSD.ORG Sun May 26 20:51:01 2013 Return-Path: Delivered-To: freebsd-wireless@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 67351E71; Sun, 26 May 2013 20:51:01 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 40012D64; Sun, 26 May 2013 20:51:01 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r4QKp1WO043594; Sun, 26 May 2013 20:51:01 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r4QKp1Hk043593; Sun, 26 May 2013 20:51:01 GMT (envelope-from linimon) Date: Sun, 26 May 2013 20:51:01 GMT Message-Id: <201305262051.r4QKp1Hk043593@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-wireless@FreeBSD.org From: linimon@FreeBSD.org Subject: Re: kern/178986: [ath] Change mac address of ath(4) is not reflected when wlan is brought up X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Discussions of 802.11 stack, tools device driver development." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 May 2013 20:51:01 -0000 Old Synopsis: Change mac address of ath(4) is not reflected when wlan is brought up New Synopsis: [ath] Change mac address of ath(4) is not reflected when wlan is brought up Responsible-Changed-From-To: freebsd-bugs->freebsd-wireless Responsible-Changed-By: linimon Responsible-Changed-When: Sun May 26 20:50:44 UTC 2013 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=178986 From owner-freebsd-wireless@FreeBSD.ORG Sun May 26 22:33:44 2013 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id D28B113F for ; Sun, 26 May 2013 22:33:44 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-qa0-x234.google.com (mail-qa0-x234.google.com [IPv6:2607:f8b0:400d:c00::234]) by mx1.freebsd.org (Postfix) with ESMTP id 9A705FE0 for ; Sun, 26 May 2013 22:33:44 +0000 (UTC) Received: by mail-qa0-f52.google.com with SMTP id bv4so715281qab.18 for ; Sun, 26 May 2013 15:33:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=EOWw6iaaXmyW4zwhITJ+SAodFpQBVpmAz/bJGUsqTHs=; b=kMbojzyHBMRN2m5Mrpa3ZOmjfxw/7crurNi1B7YVHRWBCgRhE5I8vvfwfk1DJ4prIf zPbP+B4qmKJSQ2WKP1zO3IhAmCMbiD4cBrtGc6tAf40ZbeLg/eV9XPLBEdpBembuUOOF CVBgwjgdSo4S1XqN5BxNJiskUHrwb+D6zst4fh+bUcOgDrKKp92twVMLoEcHEApZM4l0 R61QjTOtMaTMZrVl44C/zDT4wUOIL9FnpK00dWEGrTPFcNjibhVpqlK3zrRQEmIZ4VVb wNoSNpD7HNBSgY+Vi/jynpNUkKIxBy8g9+oVE+AAdsl4+wQ9zjVYJExwvHmuLsvdHp5l IWdw== MIME-Version: 1.0 X-Received: by 10.49.35.49 with SMTP id e17mr29351491qej.61.1369607622714; Sun, 26 May 2013 15:33:42 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.199.66 with HTTP; Sun, 26 May 2013 15:33:42 -0700 (PDT) In-Reply-To: <201305262223.r4QMNefL003583@svn.freebsd.org> References: <201305262223.r4QMNefL003583@svn.freebsd.org> Date: Sun, 26 May 2013 15:33:42 -0700 X-Google-Sender-Auth: oK8-W5UNKqAYVqON9MD-GtNAtdc Message-ID: Subject: Fwd: svn commit: r251014 - head/sys/dev/ath From: Adrian Chadd To: freebsd-wireless@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Discussions of 802.11 stack, tools device driver development." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 May 2013 22:33:44 -0000 Hi, Please test out the current state of -HEAD with this patch. It shouldn't have made anything much worse than before. The main issues here I'm trying to resolve are: * migrating ath to using if_transmit, and debugging all of that; * beginning to fix fragment transmission. Fragment transmission is still a little odd but it at least now will -transmit- fragments without just leaking mbufs everywhere (and not transmitting fragments!) I'm going to keep tidying up the transmit path and code over the next couple of weeks and this'll include fixing up the fragment transmission path so it at least makes mostly-sensible fragment transmission decisions. Thanks, Adrian ---------- Forwarded message ---------- From: Adrian Chadd Date: 26 May 2013 15:23 Subject: svn commit: r251014 - head/sys/dev/ath To: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Author: adrian Date: Sun May 26 22:23:39 2013 New Revision: 251014 URL: http://svnweb.freebsd.org/changeset/base/251014 Log: Migrate ath(4) to now use if_transmit instead of the legacy if_start and if queue mechanism; also fix up (non-11n) TX fragment handling. This may result in a bit of a performance drop for now but I plan on debugging and resolving this at a later stage. Whilst here, fix the transmit path so fragment transmission works. The TX fragmentation handling is a bit more special. In order to correctly transmit TX fragments, there's a bunch of corner cases that need to be handled: * They must be transmitted back to back, in the same order.. * .. ie, you need to hold the TX lock whilst transmitting this set of fragments rather than interleaving it with other MSDUs destined to other nodes; * The length of the next fragment is required when transmitting, in order to correctly set the NAV field in the current frame to the length of the next frame; which requires .. * .. that we know the transmit duration of the next frame, which .. * .. requires us to set the rate of all fragments to the same length, or make the decision up-front, etc. To facilitate this, I've added a new ath_buf field to describe the length of the next fragment. This avoids having to keep the mbuf chain together. This used to work before my 11n TX path work because the ath_tx_start() routine would be handed a single mbuf with m_nextpkt pointing to the next frame, and that would be maintained all the way up to when the duration calculation was done. This doesn't hold true any longer - the actual queuing may occur at any point in the future (think ath_node TID software queuing) so this information needs to be maintained. Right now this does work for non-11n frames but it doesn't at all enforce the same rate control decision for all frames in the fragment. I plan on fixing this in a followup commit. RTS/CTS has the same issue, I'll look at fixing this in a subsequent commit. Finaly, 11n fragment support requires the driver to have fully decided what the rate scenario setup is - including 20/40MHz, short/long GI, STBC, LDPC, number of streams, etc. Right now that decision is (currently) made _after_ the NAV field value is updated. I'll fix all of this in subsequent commits. Tested: * AR5416, STA, transmitting 11abg fragments * AR5416, STA, 11n fragments work but the NAV field is incorrect for the reasons above. TODO: * It would be nice to be able to queue mbufs per-node and per-TID so we can only queue ath_buf entries when it's time to assemble frames to send to the hardware. But honestly, we should just do that level of software queue management in net80211 rather than ath(4), so I'm going to leave this alone for now. * More thorough AP, mesh and adhoc testing. * Ensure that net80211 doesn't hand us fragmented frames when A-MPDU has been negotiated, as we can't do software retransmission of fragments. * .. set CLRDMASK when transmitting fragments, just to ensure. Modified: head/sys/dev/ath/if_ath.c head/sys/dev/ath/if_ath_misc.h head/sys/dev/ath/if_ath_tx.c head/sys/dev/ath/if_athvar.h Modified: head/sys/dev/ath/if_ath.c ============================================================================== --- head/sys/dev/ath/if_ath.c Sun May 26 22:11:13 2013 (r251013) +++ head/sys/dev/ath/if_ath.c Sun May 26 22:23:39 2013 (r251014) @@ -152,7 +152,8 @@ static void ath_init(void *); static void ath_stop_locked(struct ifnet *); static void ath_stop(struct ifnet *); static int ath_reset_vap(struct ieee80211vap *, u_long); -static void ath_start_queue(struct ifnet *ifp); +static int ath_transmit(struct ifnet *ifp, struct mbuf *m); +static void ath_qflush(struct ifnet *ifp); static int ath_media_change(struct ifnet *); static void ath_watchdog(void *); static int ath_ioctl(struct ifnet *, u_long, caddr_t); @@ -437,9 +438,6 @@ ath_attach(u_int16_t devid, struct ath_s TASK_INIT(&sc->sc_txqtask, 0, ath_txq_sched_tasklet, sc); TASK_INIT(&sc->sc_fataltask, 0, ath_fatal_proc, sc); - /* XXX make this a higher priority taskqueue? */ - TASK_INIT(&sc->sc_txpkttask, 0, ath_start_task, sc); - /* * Allocate hardware transmit queues: one queue for * beacon frames and one data queue for each QoS @@ -558,7 +556,8 @@ ath_attach(u_int16_t devid, struct ath_s ifp->if_softc = sc; ifp->if_flags = IFF_SIMPLEX | IFF_BROADCAST | IFF_MULTICAST; - ifp->if_start = ath_start_queue; + ifp->if_transmit = ath_transmit; + ifp->if_qflush = ath_qflush; ifp->if_ioctl = ath_ioctl; ifp->if_init = ath_init; IFQ_SET_MAXLEN(&ifp->if_snd, ifqmaxlen); @@ -2645,43 +2644,32 @@ ath_getbuf(struct ath_softc *sc, ath_buf } static void -ath_start_queue(struct ifnet *ifp) +ath_qflush(struct ifnet *ifp) { - struct ath_softc *sc = ifp->if_softc; - - ATH_PCU_LOCK(sc); - if (sc->sc_inreset_cnt > 0) { - device_printf(sc->sc_dev, - "%s: sc_inreset_cnt > 0; bailing\n", __func__); - ATH_PCU_UNLOCK(sc); - IF_LOCK(&ifp->if_snd); - sc->sc_stats.ast_tx_qstop++; - ifp->if_drv_flags |= IFF_DRV_OACTIVE; - IF_UNLOCK(&ifp->if_snd); - ATH_KTR(sc, ATH_KTR_TX, 0, "ath_start_task: OACTIVE, finish"); - return; - } - sc->sc_txstart_cnt++; - ATH_PCU_UNLOCK(sc); - ATH_KTR(sc, ATH_KTR_TX, 0, "ath_start_queue: start"); - ath_tx_kick(sc); - ATH_KTR(sc, ATH_KTR_TX, 0, "ath_start_queue: finished"); - - ATH_PCU_LOCK(sc); - sc->sc_txstart_cnt--; - ATH_PCU_UNLOCK(sc); + /* XXX TODO */ } -void -ath_start_task(void *arg, int npending) +/* + * Transmit a single frame. + * + * net80211 will free the node reference if the transmit + * fails, so don't free the node reference here. + */ +static int +ath_transmit(struct ifnet *ifp, struct mbuf *m) { - struct ath_softc *sc = (struct ath_softc *) arg; - struct ifnet *ifp = sc->sc_ifp; - - ATH_KTR(sc, ATH_KTR_TX, 0, "ath_start_task: start"); + struct ieee80211com *ic = ifp->if_l2com; + struct ath_softc *sc = ic->ic_ifp->if_softc; + struct ieee80211_node *ni; + struct mbuf *next; + struct ath_buf *bf; + ath_bufhead frags; + int retval = 0; - /* XXX is it ok to hold the ATH_LOCK here? */ + /* + * Tell the reset path that we're currently transmitting. + */ ATH_PCU_LOCK(sc); if (sc->sc_inreset_cnt > 0) { device_printf(sc->sc_dev, @@ -2692,211 +2680,249 @@ ath_start_task(void *arg, int npending) ifp->if_drv_flags |= IFF_DRV_OACTIVE; IF_UNLOCK(&ifp->if_snd); ATH_KTR(sc, ATH_KTR_TX, 0, "ath_start_task: OACTIVE, finish"); - return; + return (ENOBUFS); /* XXX should be EINVAL or? */ } sc->sc_txstart_cnt++; ATH_PCU_UNLOCK(sc); + ATH_KTR(sc, ATH_KTR_TX, 0, "ath_transmit: start"); + /* + * Grab the TX lock - it's ok to do this here; we haven't + * yet started transmitting. + */ ATH_TX_LOCK(sc); - ath_start(sc->sc_ifp); - ATH_TX_UNLOCK(sc); - - ATH_PCU_LOCK(sc); - sc->sc_txstart_cnt--; - ATH_PCU_UNLOCK(sc); - ATH_KTR(sc, ATH_KTR_TX, 0, "ath_start_task: finished"); -} -void -ath_start(struct ifnet *ifp) -{ - struct ath_softc *sc = ifp->if_softc; - struct ieee80211_node *ni; - struct ath_buf *bf; - struct mbuf *m, *next; - ath_bufhead frags; - int npkts = 0; + /* + * Node reference, if there's one. + */ + ni = (struct ieee80211_node *) m->m_pkthdr.rcvif; - if ((ifp->if_drv_flags & IFF_DRV_RUNNING) == 0 || sc->sc_invalid) - return; + /* + * Enforce how deep a node queue can get. + * + * XXX it would be nicer if we kept an mbuf queue per + * node and only whacked them into ath_bufs when we + * are ready to schedule some traffic from them. + * .. that may come later. + * + * XXX we should also track the per-node hardware queue + * depth so it is easy to limit the _SUM_ of the swq and + * hwq frames. Since we only schedule two HWQ frames + * at a time, this should be OK for now. + */ + if ((!(m->m_flags & M_EAPOL)) && + (ATH_NODE(ni)->an_swq_depth > sc->sc_txq_node_maxdepth)) { + sc->sc_stats.ast_tx_nodeq_overflow++; + m_freem(m); + m = NULL; + retval = ENOBUFS; + goto finish; + } - ATH_TX_LOCK_ASSERT(sc); + /* + * Check how many TX buffers are available. + * + * If this is for non-EAPOL traffic, just leave some + * space free in order for buffer cloning and raw + * frame transmission to occur. + * + * If it's for EAPOL traffic, ignore this for now. + * Management traffic will be sent via the raw transmit + * method which bypasses this check. + * + * This is needed to ensure that EAPOL frames during + * (re) keying have a chance to go out. + * + * See kern/138379 for more information. + */ + if ((!(m->m_flags & M_EAPOL)) && + (sc->sc_txbuf_cnt <= sc->sc_txq_data_minfree)) { + sc->sc_stats.ast_tx_nobuf++; + m_freem(m); + m = NULL; + retval = ENOBUFS; + goto finish; + } - ATH_KTR(sc, ATH_KTR_TX, 0, "ath_start: called"); + /* + * Grab a TX buffer and associated resources. + * + * If it's an EAPOL frame, allocate a MGMT ath_buf. + * That way even with temporary buffer exhaustion due to + * the data path doesn't leave us without the ability + * to transmit management frames. + * + * Otherwise allocate a normal buffer. + */ + if (m->m_flags & M_EAPOL) + bf = ath_getbuf(sc, ATH_BUFTYPE_MGMT); + else + bf = ath_getbuf(sc, ATH_BUFTYPE_NORMAL); - for (;;) { + if (bf == NULL) { /* - * Grab the frame that we're going to try and transmit. + * If we failed to allocate a buffer, fail. + * + * We shouldn't fail normally, due to the check + * above. */ - IFQ_DEQUEUE(&ifp->if_snd, m); - if (m == NULL) - break; - ni = (struct ieee80211_node *) m->m_pkthdr.rcvif; + sc->sc_stats.ast_tx_nobuf++; + IF_LOCK(&ifp->if_snd); + ifp->if_drv_flags |= IFF_DRV_OACTIVE; + IF_UNLOCK(&ifp->if_snd); + m_freem(m); + m = NULL; + retval = ENOBUFS; + goto finish; + } - /* - * Enforce how deep a node queue can get. - * - * XXX it would be nicer if we kept an mbuf queue per - * node and only whacked them into ath_bufs when we - * are ready to schedule some traffic from them. - * .. that may come later. - * - * XXX we should also track the per-node hardware queue - * depth so it is easy to limit the _SUM_ of the swq and - * hwq frames. Since we only schedule two HWQ frames - * at a time, this should be OK for now. - */ - if ((!(m->m_flags & M_EAPOL)) && - (ATH_NODE(ni)->an_swq_depth > sc->sc_txq_node_maxdepth)) { - sc->sc_stats.ast_tx_nodeq_overflow++; - if (ni != NULL) - ieee80211_free_node(ni); - m_freem(m); - m = NULL; - continue; - } + /* + * At this point we have a buffer; so we need to free it + * if we hit any error conditions. + */ + + /* + * Check for fragmentation. If this frame + * has been broken up verify we have enough + * buffers to send all the fragments so all + * go out or none... + */ + TAILQ_INIT(&frags); + if ((m->m_flags & M_FRAG) && + !ath_txfrag_setup(sc, &frags, m, ni)) { + DPRINTF(sc, ATH_DEBUG_XMIT, + "%s: out of txfrag buffers\n", __func__); + sc->sc_stats.ast_tx_nofrag++; + ifp->if_oerrors++; + ath_freetx(m); + goto bad; + } + + /* + * At this point if we have any TX fragments, then we will + * have bumped the node reference once for each of those. + */ + + /* + * XXX Is there anything actually _enforcing_ that the + * fragments are being transmitted in one hit, rather than + * being interleaved with other transmissions on that + * hardware queue? + * + * The ATH TX output lock is the only thing serialising this + * right now. + */ + + /* + * Calculate the "next fragment" length field in ath_buf + * in order to let the transmit path know enough about + * what to next write to the hardware. + */ + if (m->m_flags & M_FRAG) { + struct ath_buf *fbf = bf; + struct ath_buf *n_fbf = NULL; + struct mbuf *fm = m->m_nextpkt; /* - * Check how many TX buffers are available. - * - * If this is for non-EAPOL traffic, just leave some - * space free in order for buffer cloning and raw - * frame transmission to occur. - * - * If it's for EAPOL traffic, ignore this for now. - * Management traffic will be sent via the raw transmit - * method which bypasses this check. - * - * This is needed to ensure that EAPOL frames during - * (re) keying have a chance to go out. - * - * See kern/138379 for more information. + * We need to walk the list of fragments and set + * the next size to the following buffer. + * However, the first buffer isn't in the frag + * list, so we have to do some gymnastics here. */ - if ((!(m->m_flags & M_EAPOL)) && - (sc->sc_txbuf_cnt <= sc->sc_txq_data_minfree)) { - sc->sc_stats.ast_tx_nobuf++; - IF_LOCK(&ifp->if_snd); - _IF_PREPEND(&ifp->if_snd, m); - ifp->if_drv_flags |= IFF_DRV_OACTIVE; - IF_UNLOCK(&ifp->if_snd); - m = NULL; - break; + TAILQ_FOREACH(n_fbf, &frags, bf_list) { + fbf->bf_nextfraglen = fm->m_pkthdr.len; + fbf = n_fbf; + fm = fm->m_nextpkt; } + } + /* + * Bump the ifp output counter. + * + * XXX should use atomics? + */ + ifp->if_opackets++; +nextfrag: + /* + * Pass the frame to the h/w for transmission. + * Fragmented frames have each frag chained together + * with m_nextpkt. We know there are sufficient ath_buf's + * to send all the frags because of work done by + * ath_txfrag_setup. We leave m_nextpkt set while + * calling ath_tx_start so it can use it to extend the + * the tx duration to cover the subsequent frag and + * so it can reclaim all the mbufs in case of an error; + * ath_tx_start clears m_nextpkt once it commits to + * handing the frame to the hardware. + * + * Note: if this fails, then the mbufs are freed but + * not the node reference. + */ + next = m->m_nextpkt; + if (ath_tx_start(sc, ni, bf, m)) { +bad: + ifp->if_oerrors++; +reclaim: + bf->bf_m = NULL; + bf->bf_node = NULL; + ATH_TXBUF_LOCK(sc); + ath_returnbuf_head(sc, bf); /* - * Grab a TX buffer and associated resources. - * - * If it's an EAPOL frame, allocate a MGMT ath_buf. - * That way even with temporary buffer exhaustion due to - * the data path doesn't leave us without the ability - * to transmit management frames. - * - * Otherwise allocate a normal buffer. + * Free the rest of the node references and + * buffers for the fragment list. */ - if (m->m_flags & M_EAPOL) - bf = ath_getbuf(sc, ATH_BUFTYPE_MGMT); - else - bf = ath_getbuf(sc, ATH_BUFTYPE_NORMAL); - - if (bf == NULL) { - /* - * If we failed to allocate a buffer, prepend it - * and continue. - * - * We shouldn't fail normally, due to the check - * above. - */ - sc->sc_stats.ast_tx_nobuf++; - IF_LOCK(&ifp->if_snd); - _IF_PREPEND(&ifp->if_snd, m); - ifp->if_drv_flags |= IFF_DRV_OACTIVE; - IF_UNLOCK(&ifp->if_snd); - m = NULL; - break; - } + ath_txfrag_cleanup(sc, &frags, ni); + ATH_TXBUF_UNLOCK(sc); + retval = ENOBUFS; + goto finish; + } - npkts ++; + /* + * Check here if the node is in power save state. + */ + ath_tx_update_tim(sc, ni, 1); + if (next != NULL) { /* - * Check for fragmentation. If this frame - * has been broken up verify we have enough - * buffers to send all the fragments so all - * go out or none... + * Beware of state changing between frags. + * XXX check sta power-save state? */ - TAILQ_INIT(&frags); - if ((m->m_flags & M_FRAG) && - !ath_txfrag_setup(sc, &frags, m, ni)) { + if (ni->ni_vap->iv_state != IEEE80211_S_RUN) { DPRINTF(sc, ATH_DEBUG_XMIT, - "%s: out of txfrag buffers\n", __func__); - sc->sc_stats.ast_tx_nofrag++; - ifp->if_oerrors++; - ath_freetx(m); - goto bad; - } - ifp->if_opackets++; - nextfrag: - /* - * Pass the frame to the h/w for transmission. - * Fragmented frames have each frag chained together - * with m_nextpkt. We know there are sufficient ath_buf's - * to send all the frags because of work done by - * ath_txfrag_setup. We leave m_nextpkt set while - * calling ath_tx_start so it can use it to extend the - * the tx duration to cover the subsequent frag and - * so it can reclaim all the mbufs in case of an error; - * ath_tx_start clears m_nextpkt once it commits to - * handing the frame to the hardware. - */ - next = m->m_nextpkt; - if (ath_tx_start(sc, ni, bf, m)) { - bad: - ifp->if_oerrors++; - reclaim: - bf->bf_m = NULL; - bf->bf_node = NULL; - ATH_TXBUF_LOCK(sc); - ath_returnbuf_head(sc, bf); - ath_txfrag_cleanup(sc, &frags, ni); - ATH_TXBUF_UNLOCK(sc); - /* - * XXX todo, free the node outside of - * the TX lock context! - */ - if (ni != NULL) - ieee80211_free_node(ni); - continue; + "%s: flush fragmented packet, state %s\n", + __func__, + ieee80211_state_name[ni->ni_vap->iv_state]); + /* XXX dmamap */ + ath_freetx(next); + goto reclaim; } + m = next; + bf = TAILQ_FIRST(&frags); + KASSERT(bf != NULL, ("no buf for txfrag")); + TAILQ_REMOVE(&frags, bf, bf_list); + goto nextfrag; + } - /* - * Check here if the node is in power save state. - */ - ath_tx_update_tim(sc, ni, 1); + /* + * Bump watchdog timer. + */ + sc->sc_wd_timer = 5; - if (next != NULL) { - /* - * Beware of state changing between frags. - * XXX check sta power-save state? - */ - if (ni->ni_vap->iv_state != IEEE80211_S_RUN) { - DPRINTF(sc, ATH_DEBUG_XMIT, - "%s: flush fragmented packet, state %s\n", - __func__, - ieee80211_state_name[ni->ni_vap->iv_state]); - /* XXX dmamap */ - ath_freetx(next); - goto reclaim; - } - m = next; - bf = TAILQ_FIRST(&frags); - KASSERT(bf != NULL, ("no buf for txfrag")); - TAILQ_REMOVE(&frags, bf, bf_list); - goto nextfrag; - } +finish: + ATH_TX_UNLOCK(sc); - sc->sc_wd_timer = 5; - } - ATH_KTR(sc, ATH_KTR_TX, 1, "ath_start: finished; npkts=%d", npkts); + /* + * Finished transmitting! + */ + ATH_PCU_LOCK(sc); + sc->sc_txstart_cnt--; + ATH_PCU_UNLOCK(sc); + + ATH_KTR(sc, ATH_KTR_TX, 0, "ath_transmit: finished"); + + return (retval); } + static int ath_media_change(struct ifnet *ifp) { Modified: head/sys/dev/ath/if_ath_misc.h ============================================================================== --- head/sys/dev/ath/if_ath_misc.h Sun May 26 22:11:13 2013 (r251013) +++ head/sys/dev/ath/if_ath_misc.h Sun May 26 22:23:39 2013 (r251014) @@ -134,9 +134,7 @@ static inline void ath_tx_kick(struct ath_softc *sc) { - ATH_TX_LOCK(sc); - ath_start(sc->sc_ifp); - ATH_TX_UNLOCK(sc); + /* XXX NULL for now */ } /* Modified: head/sys/dev/ath/if_ath_tx.c ============================================================================== --- head/sys/dev/ath/if_ath_tx.c Sun May 26 22:11:13 2013 (r251013) +++ head/sys/dev/ath/if_ath_tx.c Sun May 26 22:23:39 2013 (r251014) @@ -1154,7 +1154,6 @@ ath_tx_calc_duration(struct ath_softc *s dur = rt->info[rix].lpAckDuration; if (wh->i_fc[1] & IEEE80211_FC1_MORE_FRAG) { dur += dur; /* additional SIFS+ACK */ - KASSERT(bf->bf_m->m_nextpkt != NULL, ("no fragment")); /* * Include the size of next fragment so NAV is * updated properly. The last fragment uses only @@ -1164,9 +1163,10 @@ ath_tx_calc_duration(struct ath_softc *s * fragment is the same as the rate used by the * first fragment! */ - dur += ath_hal_computetxtime(ah, rt, - bf->bf_m->m_nextpkt->m_pkthdr.len, - rix, shortPreamble); + dur += ath_hal_computetxtime(ah, + rt, + bf->bf_nextfraglen, + rix, shortPreamble); } if (isfrag) { /* Modified: head/sys/dev/ath/if_athvar.h ============================================================================== --- head/sys/dev/ath/if_athvar.h Sun May 26 22:11:13 2013 (r251013) +++ head/sys/dev/ath/if_athvar.h Sun May 26 22:23:39 2013 (r251014) @@ -225,6 +225,7 @@ struct ath_buf { bus_size_t bf_mapsize; #define ATH_MAX_SCATTER ATH_TXDESC /* max(tx,rx,beacon) desc's */ bus_dma_segment_t bf_segs[ATH_MAX_SCATTER]; + uint32_t bf_nextfraglen; /* length of next fragment */ /* Completion function to call on TX complete (fail or not) */ /* @@ -733,7 +734,6 @@ struct ath_softc { struct ath_txq *sc_ac2q[5]; /* WME AC -> h/w q map */ struct task sc_txtask; /* tx int processing */ struct task sc_txqtask; /* tx proc processing */ - struct task sc_txpkttask; /* tx frame processing */ struct ath_descdma sc_txcompdma; /* TX EDMA completion */ struct mtx sc_txcomplock; /* TX EDMA completion lock */ From owner-freebsd-wireless@FreeBSD.ORG Mon May 27 07:29:31 2013 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 035D7B54; Mon, 27 May 2013 07:29:31 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-qc0-x230.google.com (mail-qc0-x230.google.com [IPv6:2607:f8b0:400d:c01::230]) by mx1.freebsd.org (Postfix) with ESMTP id 9F73C956; Mon, 27 May 2013 07:29:30 +0000 (UTC) Received: by mail-qc0-f176.google.com with SMTP id o10so3369054qcv.35 for ; Mon, 27 May 2013 00:29:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=2ryA+yiUJ4ao86yRhzzlHT/c7z0jNQeKam7NqjOdsis=; b=y4yNo1nKfzuDSXUsJ3eyAC8PisBtP6PyQdsnt1BC2P/1XpVLOig40VgtyepcNbaNnJ uDJov0o45zVeHT32Zq9cdUAZ4G2rq3/ino7k5CAYySUqzPU3wBPuSENX7oFIUMIG/9np gy7vJ3xNehssOqix50PppVUY/YgN35TC+Z8+D055SeEQ7y8hBmuTfy714EoFtbhRjGrH 2oDS2DW7eVQZnVAvLXNu41T1e3RdsVMumWnabWBOUqforyDVstarhlgc33TCrXfkA1eU 2NtXMtM2MkY/Td7wYTgi4LTAv5VHyFNGOpcHRveYa4y1/9vz45zwZgnMdtYW4iIua8w/ ASgg== MIME-Version: 1.0 X-Received: by 10.229.157.134 with SMTP id b6mr7491159qcx.143.1369639769244; Mon, 27 May 2013 00:29:29 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.199.66 with HTTP; Mon, 27 May 2013 00:29:29 -0700 (PDT) In-Reply-To: <456290883.20130520124616@serebryakov.spb.ru> References: <372806514.20130519141024@serebryakov.spb.ru> <1106213329.20130519193856@serebryakov.spb.ru> <1377052407.20130519195416@serebryakov.spb.ru> <5931014.20130519213437@serebryakov.spb.ru> <1596494929.20130519223744@serebryakov.spb.ru> <456290883.20130520124616@serebryakov.spb.ru> Date: Mon, 27 May 2013 00:29:29 -0700 X-Google-Sender-Auth: hMj1mLB7HwH6ErjDeNNFNGjdGFs Message-ID: Subject: Re: [rft] please test -HEAD ath; lots of TX changes From: Adrian Chadd To: Lev Serebryakov Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-wireless@freebsd.org X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Discussions of 802.11 stack, tools device driver development." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 May 2013 07:29:31 -0000 Hi, Would you mind re-testing with what's now in -HEAD? I have some rate control fixes to go in soon but other than that I'd just like to concentrate on tidying up loose ends and improving stability. I'm glad that we're now not seeing any "stuff hangs" issues; but now we need to sit down and fix the "rekeying fails" problems you're seeing. I'd also like to get to the root cause of your general performance issues. Thanks! Adrian From owner-freebsd-wireless@FreeBSD.ORG Mon May 27 11:06:56 2013 Return-Path: Delivered-To: freebsd-wireless@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 81C48399 for ; Mon, 27 May 2013 11:06:56 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 6D0426E0 for ; Mon, 27 May 2013 11:06:56 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r4RB6u3q016218 for ; Mon, 27 May 2013 11:06:56 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r4RB6uMC016216 for freebsd-wireless@FreeBSD.org; Mon, 27 May 2013 11:06:56 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 27 May 2013 11:06:56 GMT Message-Id: <201305271106.r4RB6uMC016216@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-wireless@FreeBSD.org Subject: Current problem reports assigned to freebsd-wireless@FreeBSD.org X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Discussions of 802.11 stack, tools device driver development." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 May 2013 11:06:56 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/178986 wireless [ath] Change mac address of ath(4) is not reflected wh o kern/178492 wireless [ath] ath0 (AR9287) panic o kern/178491 wireless [ath] ath0 (AR9287) stuck beacon o kern/178477 wireless [ath] missed beacon / soft reset in STA mode results i o kern/178470 wireless [panic][ath] bss vap can and does change o kern/178411 wireless [ral] [panic] FreeBSD kernel crash in rt2860 o kern/178379 wireless [net80211] [ath] WPA rekey on the STA side fails when o kern/178378 wireless [net80211] crypto state isn't reset during a reassocia o kern/178263 wireless [ath] review the use of ic_freq / ic_ieee / ic_flags / o kern/177847 wireless [ath] With TPC enabled, TX power values aren't clamped o kern/177846 wireless [ath] [net80211] net80211 TX power limit isn't correct o conf/177688 wireless WiFi regodmains information is inconsistent between "e o kern/177530 wireless [ath] ath driver isn't 32 bit int clean o kern/177465 wireless [iwn] 20%-100% packet loss with iwn driver o kern/177451 wireless [ieee80211] page fault in ieee80211_tx_mgt_timeout o kern/176238 wireless [ath] [patch] Correct buffer size calculation and simp o kern/176201 wireless [net80211] [patch] 11n station includes unrelated ht p o kern/176104 wireless [iwn] iwn0: iwn_intr: fatal firmware error o kern/175870 wireless [iwn] /etc/rc.d/netif restart cause system crash o kern/175722 wireless [ath]lot of bad seriesx hwrate in kernel messages o kern/175446 wireless [ath] high volumes of PHY errors lead to BB/MAC hangs o kern/175227 wireless [ath] beacon timers aren't necessarily reprogrammed af o kern/175183 wireless [iwn] iwn(4) becomes unresponsive during initial confi o kern/175053 wireless [iwn] iwn firmware error on 9-stable with Ultimate-N 6 o kern/174891 wireless [ieee80211] struct ieee80211_node is freed during acti o kern/174722 wireless [wlan] can't use channel 12 and 13 (14) with my wifi i o kern/174661 wireless [wlan] lost alias on wlan interface o kern/174283 wireless [net80211] panics in ieee80211_ff_age() and ieee80211_ o kern/174276 wireless [ath] if_ath memory modified after free o kern/174273 wireless [net80211] taking down a net80211 node with active fas o kern/173917 wireless [iwn] wpa-supplicant issues on iwn o kern/173898 wireless [iwn] [patch] iwn(4) DOES support 6235 chip. o kern/173883 wireless [ath] ath0: unable to attach - pci issue? o kern/173711 wireless [ath] powerd kills ath on the Asus EeePC 1005HA o kern/173342 wireless PS-Poll isn't working o kern/173336 wireless [ath] Atheros card improper device poweroff handling o o kern/172955 wireless [ath] 11n does not work in adhoc mode o kern/172706 wireless [wpi] wpi0 fails to load firmware when using country o kern/172672 wireless [ubt] Bluetooth device recognised but not working o kern/172661 wireless hostapd(8) securing wireless adapter in HostAP mode is o kern/172338 wireless [ath] [net80211] CCMP IV transmit counters are not cor o kern/171598 wireless [ath] TP-Link TL-WN951N W-LAN PCI Adapter 300 MBit stu o kern/171235 wireless [ath] ath loses connection, system freezes on netif re o kern/170889 wireless [ath] ath driver uses some uninitilized memory o kern/170620 wireless [ath] LOR and deadlock when multiple vaps are used o kern/170573 wireless [iwi] Intel 2200BG iwi NIC hangs with need multicast c o kern/170513 wireless [ath] ath logs: ath_tx_aggr_comp_aggr: AR5416 bug: o kern/170433 wireless [ath] TX hang after a stuck beacon message with active o kern/170397 wireless [ath] [patch] Uninitialized variables in ah_eeprom_928 o kern/170302 wireless [ath] 802.11n frames are not being transmitted with mu o kern/170281 wireless [ath] 802.11n locks up on aggregation setup (ampdutx) o kern/170098 wireless [ath] [net80211] VAPs (Virtual access points) with Ath o kern/170066 wireless [ral] ral(4) rt61pci Linksys freezes the machine as so o kern/169432 wireless [ath] BAR TX hang when aggregation session is reset du p kern/169362 wireless [ath] AR5416: radar pulse PHY errors sometimes include o kern/169336 wireless [ath] ANI isn't triggering in a busy/noisy environment o kern/169199 wireless [ath] Cannot set up static ip addresses for wireless w o kern/169084 wireless [ath] suspend/resume doesn't cause a rescan; the assoc o kern/168530 wireless [ath] Broken WEP probably o kern/168393 wireless AR9285: suspend/resume sometimes fails o kern/168170 wireless [net80211] ieee80211_send_bar() doesn't complete corre o kern/167870 wireless [ath] adhoc wifi client does not join an existing IBSS o kern/167834 wireless [ath] kickpcu; 'handled 0 packets' o kern/167828 wireless [iwn] iwn(4) doesn't recover automatically after firmw o kern/167798 wireless ifconfig(8): problem with "ifconfig list scan" command o kern/167491 wireless [ath] TID != hardware queue TID in ath_tx_aggr_comp_ag o kern/167113 wireless [ath] AR5210: "stuck" TX seems to be occuring, without o kern/167080 wireless [ath] channel switch on another VAP break channel setu o kern/166684 wireless [ath] [net80211] mgmtrate/mcastrate isn't updated base p kern/166642 wireless [ieee80211] [patch] in 802.11n mode for FreeBSD AP, ha o kern/166641 wireless [ieee80211] [patch] mbuf/cluster leak in AP mode in 80 p kern/166357 wireless [ath] 802.11n TX stall when the first frame in the BAW o kern/166286 wireless [net80211] [ath] initial switch to HT40 isn't causing p kern/166190 wireless [ath] TX hangs and frames stuck in TX queue o kern/166086 wireless [Patch][ath] Reflect state of rfkill switch in a sysct o kern/165969 wireless [ath] Slower performance in adhoc mode vs Client/AP mo o kern/165966 wireless [ath] ath0: device timeout on SMP machines due to race o kern/165895 wireless [ath] overly busy cabq can tie up all tx buffers o kern/165870 wireless [bwn] bwn driver does not attach on HP Pavilion dv9420 o kern/165866 wireless [ath] TX hangs, requiring a "scan" to properly reset t o kern/165849 wireless [ath] [hang] network ath driver freeze o kern/165595 wireless [ipw] ipw(4): Can't load firmare for ipw2200bg o kern/165543 wireless [ath] ath0 endless scanning of channels without connec o kern/165517 wireless [net80211] bgscan isn't triggered when invalid beacons o kern/165475 wireless [ath] operational mode change doesn't poke the underly o kern/165382 wireless [kernel] taskqueue_unblock doesn't unblock currently q o kern/165306 wireless [ath] race conditions between scanning and beacon time o kern/165220 wireless [ath] "ath_rx_tasklet: sc_inreset_cnt > 0; skipping" m o kern/165214 wireless [ieee80211] Kernel panic in ieee80211_output.c:2505 o kern/165212 wireless [ath] No WiFi on Acer Aspire One 751h (Atheros AR5BHB6 o kern/165149 wireless [ath] [net80211] Ping with data length more than iv_fr o kern/165146 wireless [net80211] Net802.11 Fragment number is assigned 1 (sh o kern/165060 wireless [ath] vap->iv_bss race conditions causing crashes insi o kern/165021 wireless [ath] ath device timeout during scan/attach, if wlan_c o kern/164721 wireless [ath] ath device timeouts o kern/164499 wireless [wi] [patch] if_wi needs fix for big endian architectu o kern/164382 wireless [ath] crash when down/deleting a vap - inside ieee8021 o kern/164365 wireless [iwi] iwi0: UP/DOWN in o bin/164102 wireless hostapd not configured for 802.11n o kern/163759 wireless [ath] ath(4) "stops working" in hostap mode o kern/163724 wireless [mwl] [patch] NULL check before dereference o kern/163719 wireless [ath] ath interface do not receive multicast o kern/163689 wireless [ath] TX timeouts when sending probe/mgmt frames durin o kern/163574 wireless [net80211] overly-frequent HT occupancy changes o kern/163573 wireless [ath] hostap mode TX buffer hang o kern/163559 wireless [ath] kernel panic AH_DEBUG o kern/163318 wireless [ath] ath(4) stops working p kern/163312 wireless [panic] [ath driver] kernel panic: page fault with ath o kern/163237 wireless [ath] AR5416 as HostAP. Delays among clients when a cl o kern/163082 wireless [ath] ar9285 diversity fixes o kern/162648 wireless [ath] AR9227 ADC DC calibration failure o kern/162647 wireless [ath] 11n TX aggregation session / TX hang o kern/161293 wireless [iwn] hang at startup when starting network o kern/161035 wireless [ieee80211] Incorrect number describing 11ng MCS rate o kern/160391 wireless [ieee80211] [patch] Panic in mesh mode o kern/160296 wireless [zyd] [panic] 802.11 usb device reboots system on 'ifc o misc/160176 wireless [mips] [panic] Kernel panic on AR7161 platform with AR o kern/157449 wireless [ath] MAC address conflict causes system to freeze o kern/157243 wireless [ath] investigate beacon TX (AP) / RX (STA) when under o kern/156904 wireless [ath] AR9285 antenna diversity algorithm is buggy and o kern/156884 wireless [ath] ath instablity o kern/156327 wireless [bwn] bwn driver causes 20%-50% packet loss o kern/156322 wireless [wpi] no ahdemo support for if_wpi o kern/156321 wireless [ath] ahdemo doesn't work with if_ath o kern/155498 wireless [ral] ral(4) needs to be resynced with OpenBSD's to ga o kern/155100 wireless [ath] ath driver on busy channel: "stuck beacon" p kern/154598 wireless [ath] Atheros 5424/2424 can't connect to WPA network o kern/154567 wireless [ath] ath(4) lot of bad series(0) o kern/154327 wireless [ath] AR5416 in station mode hangs when transmitting f o kern/154284 wireless [ath] Modern ath wifi cards (such as AR9285) have miss o kern/154153 wireless [ath] AR5213 + MIPS + WPA group key packet corruption o kern/153594 wireless [wlan] netif/devd race o kern/153448 wireless [ath] ath networking device loses association after a o kern/152750 wireless [ath] ath0 lot of bad series hwrate o kern/151198 wireless [ath] ath/5416 fails bgscan with "ath0: ath_chan_set: o kern/149786 wireless [bwn] bwn on Dell Inspiron 1150: connections stall o kern/149516 wireless [ath] ath(4) hostap with fake MAC/BSSID results in sta o kern/149373 wireless [realtek/atheros]: None of my network card working o kern/148322 wireless [ath] Triggering atheros wifi beacon misses in hostap o kern/148317 wireless [ath] FreeBSD 7.x hostap memory leak in net80211 or At o kern/148078 wireless [ath] wireless networking stops functioning o kern/146426 wireless [mwl] 802.11n rates not possible on mwl o kern/146425 wireless [mwl] mwl dropping all packets during and after high u o kern/145826 wireless [panic] [ath] Unable to configure adhoc mode on ath0/w o kern/144987 wireless [wpi] [panic] injecting packets with wlaninject using o kern/144755 wireless [wlan] netif/devd race o bin/144109 wireless hostapd(8) uses the MAC of the wireless interface, but o conf/143079 wireless hostapd(8) startup missing multi wlan functionality p kern/140567 wireless [ath] [patch] ath is not worked on my notebook PC o kern/140245 wireless [ath] [panic] Kernel panic during network activity on o kern/137592 wireless [ath] panic - 7-STABLE (Aug 7, 2009 UTC) crashes on ne o kern/136943 wireless [wpi] [lor] wpi0_com_lock / wpi0 o kern/136836 wireless [ath] atheros card stops functioning after about 12 ho o kern/132722 wireless [ath] Wifi ath0 associates fine with AP, but DHCP or I o bin/131549 wireless ifconfig(8) can't clear 'monitor' mode on the wireless o kern/126475 wireless [ath] [panic] ath pcmcia card inevitably panics under o kern/125721 wireless [ath] Terrible throughput/high ping latency with Ubiqu o kern/125617 wireless [ath] [panic] ath(4) related panic o kern/125501 wireless [ath] atheros cardbus driver hangs o kern/125332 wireless [ath] [panic] crash under any non-tiny networking unde o kern/124767 wireless [iwi] Wireless connection using iwi0 driver (Intel 220 o kern/124753 wireless [ieee80211] net80211 discards power-save queue packets o kern/121061 wireless [ath] [panic] panic while ejecting ath(4)-adapter duri o docs/120456 wireless ath(4) needs to specify requirement on wlan_scan_sta o kern/119513 wireless [ath] [irq] inserting dlink dwl-g630 wireless card res o kern/116747 wireless [ndis] FreeBSD 7.0-CURRENT crash with Dell TrueMobile f kern/105348 wireless [ath] ath device stopps TX 167 problems total. From owner-freebsd-wireless@FreeBSD.ORG Mon May 27 13:39:25 2013 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 24312F60; Mon, 27 May 2013 13:39:25 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [46.4.40.135]) by mx1.freebsd.org (Postfix) with ESMTP id D6C012C6; Mon, 27 May 2013 13:39:24 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:bd1b:cc3:22ae:789f]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPSA id 055C14AC57; Mon, 27 May 2013 17:39:12 +0400 (MSK) Date: Mon, 27 May 2013 17:39:10 +0400 From: Lev Serebryakov Organization: FreeBSD Project X-Priority: 3 (Normal) Message-ID: <1266905855.20130527173910@serebryakov.spb.ru> To: Adrian Chadd Subject: Re: [rft] please test -HEAD ath; lots of TX changes In-Reply-To: References: <372806514.20130519141024@serebryakov.spb.ru> <1106213329.20130519193856@serebryakov.spb.ru> <1377052407.20130519195416@serebryakov.spb.ru> <5931014.20130519213437@serebryakov.spb.ru> <1596494929.20130519223744@serebryakov.spb.ru> <456290883.20130520124616@serebryakov.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: quoted-printable Cc: freebsd-wireless@freebsd.org X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: lev@FreeBSD.org List-Id: "Discussions of 802.11 stack, tools device driver development." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 May 2013 13:39:25 -0000 Hello, Adrian. You wrote 27 =EC=E0=FF 2013 =E3., 11:29:29: AC> Would you mind re-testing with what's now in -HEAD? I've built new "firmware" already and I'll give it try tonight :) AC> I'm glad that we're now not seeing any "stuff hangs" issues; but now AC> we need to sit down and fix the "rekeying fails" problems you're AC> seeing. Thank you for all your work :) --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-wireless@FreeBSD.ORG Mon May 27 21:02:20 2013 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 2ACEF7B4; Mon, 27 May 2013 21:02:20 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [IPv6:2a01:4f8:131:60a2::2]) by mx1.freebsd.org (Postfix) with ESMTP id E019BD04; Mon, 27 May 2013 21:02:19 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:bd1b:cc3:22ae:789f]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPSA id 261104AC1C; Tue, 28 May 2013 01:02:14 +0400 (MSK) Date: Tue, 28 May 2013 01:02:12 +0400 From: Lev Serebryakov X-Priority: 3 (Normal) Message-ID: <711055633.20130528010212@serebryakov.spb.ru> To: Adrian Chadd Subject: Re: [rft] please test -HEAD ath; lots of TX changes In-Reply-To: References: <372806514.20130519141024@serebryakov.spb.ru> <1106213329.20130519193856@serebryakov.spb.ru> <1377052407.20130519195416@serebryakov.spb.ru> <5931014.20130519213437@serebryakov.spb.ru> <1596494929.20130519223744@serebryakov.spb.ru> <456290883.20130520124616@serebryakov.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-wireless@freebsd.org X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Discussions of 802.11 stack, tools device driver development." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 May 2013 21:02:20 -0000 Hello, Adrian. You wrote 27 =D0=BC=D0=B0=D1=8F 2013 =D0=B3., 11:29:29: AC> Would you mind re-testing with what's now in -HEAD? Ok, now I can not "force" connection NOT TO PICK UP n-rates (without disabling N on sever or client). Performance is better, than usual (150-180Mbit/s UDP), and SOMETIMES here are such messages: May 28 00:40:51 gateway kernel: ath0: ath_tx_tid_bar_suspend: tid=3D0, bar_= wait=3D0, bar_tx=3D0, called May 28 00:40:51 gateway kernel: ath0: ath_tx_tid_bar_tx_ready: c4:85:08:3f:= 9e:c2: TID=3D0, bar ready May 28 00:40:51 gateway kernel: ath0: ath_tx_tid_bar_tx: c4:85:08:3f:9e:c2:= TID=3D0, called May 28 00:40:51 gateway kernel: ath0: ath_tx_tid_bar_tx: c4:85:08:3f:9e:c2:= TID=3D0, new BAW left edge=3D186 May 28 00:40:51 gateway kernel: ath0: ath_bar_response: c4:85:08:3f:9e:c2: = called; txa_tid=3D0, atid->tid=3D0, status=3D0, attempts=3D1 May 28 00:40:51 gateway kernel: ath0: ath_tx_tid_bar_unsuspend: c4:85:08:3f= :9e:c2: TID=3D0, called May 28 00:40:52 gateway kernel: ath0: ath_tx_tid_bar_suspend: tid=3D0, bar_= wait=3D0, bar_tx=3D0, called May 28 00:40:52 gateway kernel: ath0: ath_tx_tid_bar_tx_ready: c4:85:08:3f:= 9e:c2: TID=3D0, bar ready May 28 00:40:52 gateway kernel: ath0: ath_tx_tid_bar_tx: c4:85:08:3f:9e:c2:= TID=3D0, called May 28 00:40:52 gateway kernel: ath0: ath_tx_tid_bar_tx: c4:85:08:3f:9e:c2:= TID=3D0, new BAW left edge=3D3517 May 28 00:40:52 gateway kernel: ath0: ath_bar_response: c4:85:08:3f:9e:c2: = called; txa_tid=3D0, atid->tid=3D0, status=3D0, attempts=3D1 May 28 00:40:52 gateway kernel: ath0: ath_tx_tid_bar_unsuspend: c4:85:08:3f= :9e:c2: TID=3D0, called Which correlates with dropping of bandwidth to 90Mbit/s for one second. But no re-association problems, no "20-30Mbit/s" problem. And I've tried to power-cycle client and AP, it still pick up N rates from first packet now! When I disable N on client, it shows stable 30Mbit/s (no 54m though :)), but still no de/re-association problems for 600 seconds. But, I stress this out: there was NO way to get non-N rates when N was enabled on both ends, there was NO auth/association problems for several 600-seconds runs. And, yes, in my previous experiments, auth/association problems were only in situation when two N-enabled parties used non-N rates. --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-wireless@FreeBSD.ORG Mon May 27 21:10:43 2013 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 8FEA3908; Mon, 27 May 2013 21:10:43 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-ie0-x22f.google.com (mail-ie0-x22f.google.com [IPv6:2607:f8b0:4001:c03::22f]) by mx1.freebsd.org (Postfix) with ESMTP id 4C99BD69; Mon, 27 May 2013 21:10:43 +0000 (UTC) Received: by mail-ie0-f175.google.com with SMTP id tp5so2718976ieb.20 for ; Mon, 27 May 2013 14:10:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:to:cc:reply-to:subject:in-reply-to:x-mailer :mime-version:content-type; bh=EoQL0Y7TdMOayswCC3J0RTCGkXDJ0SxZeLsz4rREeR0=; b=spmrFDyWqJAeVTcY+XQD9Oc5rvF/ov8NpFpRK19YN81sBDn/yHFqlpHQbkM64IzwGM EX3wVGFoRLHEVztP/pN+cJHemr/r0IGKIk7qV/tUwZDxuUc6uUiovRRBWf/mTQwOCe5H mEadehyFUkdMRF3DXvZwJkzwr/yw9qBl5iKcc4S4a3b7x9Ql0J0bQNasgSYk86bQrD0E pqhKYU5yGAOVnWKa8E7Kq5+GQsSg0D8dc1P9CA2YLE8WML/J4f53Os8Bx+kEG5+UK7oG iJJ03OKDI/VNnLQeaZwq3PLoOedV3qYaxAIzMQJbmzDvFKeeP6L99XYhJQdDxq35MojR uuXw== X-Received: by 10.50.109.231 with SMTP id hv7mr5775436igb.103.1369689042022; Mon, 27 May 2013 14:10:42 -0700 (PDT) Received: from www.palm.com ([32.137.95.175]) by mx.google.com with ESMTPSA id uv10sm14903538igb.3.2013.05.27.14.10.37 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 27 May 2013 14:10:40 -0700 (PDT) Message-ID: <51a3cbd0.2a98320a.4098.28c1@mx.google.com> Date: Mon, 27 May 2013 17:10:33 -0400 From: "Adrian Chadd" To: "Lev Serebryakov" , "Adrian Chadd" Subject: Re: [rft] please test -HEAD ath; lots of TX changes In-Reply-To: <711055633.20130528010212@serebryakov.spb.ru> X-Mailer: Palm webOS v1.0.1 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: "freebsd-wireless@freebsd.org" X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Adrian Chadd List-Id: "Discussions of 802.11 stack, tools device driver development." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 May 2013 21:10:43 -0000 Sweet. I think the problem getting n rates here are likely due to buffer st= arvation when queuing the addba request or response frames. So I still have to properly fix that. But it'll happen. Cool, keep testing! Adrian Sent from my Palm Pre on AT&T On May 27, 2013 5:02 PM, Lev Serebryakov <lev@freebsd.org> wrote:=20 Hello, Adrian. You wrote 27 =D0=BC=D0=B0=D1=8F 2013 =D0=B3., 11:29:29: AC> Would you mind re-testing with what's now in -HEAD? Ok, now I can not "force" connection NOT TO PICK UP n-rates (without disabling N on sever or client). Performance is better, than usual (150-180Mbit/s UDP), and SOMETIMES here are such messages: May 28 00:40:51 gateway kernel: ath0: ath_tx_tid_bar_suspend: tid=3D0, bar_= wait=3D0, bar_tx=3D0, called May 28 00:40:51 gateway kernel: ath0: ath_tx_tid_bar_tx_ready: c4:85:08:3f:= 9e:c2: TID=3D0, bar ready May 28 00:40:51 gateway kernel: ath0: ath_tx_tid_bar_tx: c4:85:08:3f:9e:c2:= TID=3D0, called May 28 00:40:51 gateway kernel: ath0: ath_tx_tid_bar_tx: c4:85:08:3f:9e:c2:= TID=3D0, new BAW left edge=3D186 May 28 00:40:51 gateway kernel: ath0: ath_bar_response: c4:85:08:3f:9e:c2:= called; txa_tid=3D0, atid->tid=3D0, status=3D0, attempts=3D1 May 28 00:40:51 gateway kernel: ath0: ath_tx_tid_bar_unsuspend: c4:85:08:3f= :9e:c2: TID=3D0, called May 28 00:40:52 gateway kernel: ath0: ath_tx_tid_bar_suspend: tid=3D0, bar_= wait=3D0, bar_tx=3D0, called May 28 00:40:52 gateway kernel: ath0: ath_tx_tid_bar_tx_ready: c4:85:08:3f:= 9e:c2: TID=3D0, bar ready May 28 00:40:52 gateway kernel: ath0: ath_tx_tid_bar_tx: c4:85:08:3f:9e:c2:= TID=3D0, called May 28 00:40:52 gateway kernel: ath0: ath_tx_tid_bar_tx: c4:85:08:3f:9e:c2:= TID=3D0, new BAW left edge=3D3517 May 28 00:40:52 gateway kernel: ath0: ath_bar_response: c4:85:08:3f:9e:c2:= called; txa_tid=3D0, atid->tid=3D0, status=3D0, attempts=3D1 May 28 00:40:52 gateway kernel: ath0: ath_tx_tid_bar_unsuspend: c4:85:08:3f= :9e:c2: TID=3D0, called Which correlates with dropping of bandwidth to 90Mbit/s for one second. But no re-association problems, no "20-30Mbit/s" problem. And I've tried to power-cycle client and AP, it still pick up N rates from first packet now! When I disable N on client, it shows stable 30Mbit/s (no 54m though :)), but still no de/re-association problems for 600 seconds. But, I stress this out: there was NO way to get non-N rates when N was enabled on both ends, there was NO auth/association problems for several 600-seconds runs. And, yes, in my previous experiments, auth/association problems were only in situation when two N-enabled parties used non-N rates. --=20 // Black Lion AKA Lev Serebryakov <lev@FreeBSD.org> From owner-freebsd-wireless@FreeBSD.ORG Mon May 27 21:22:19 2013 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 9A323D35; Mon, 27 May 2013 21:22:19 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [46.4.40.135]) by mx1.freebsd.org (Postfix) with ESMTP id 5E42CE1B; Mon, 27 May 2013 21:22:19 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:bd1b:cc3:22ae:789f]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPSA id CA3E04AC1C; Tue, 28 May 2013 01:22:14 +0400 (MSK) Date: Tue, 28 May 2013 01:22:12 +0400 From: Lev Serebryakov Organization: FreeBSD Project X-Priority: 3 (Normal) Message-ID: <281253146.20130528012212@serebryakov.spb.ru> To: "Adrian Chadd" Subject: Re: [rft] please test -HEAD ath; lots of TX changes In-Reply-To: <51a3cbd0.2a98320a.4098.28c1@mx.google.com> References: <711055633.20130528010212@serebryakov.spb.ru> <51a3cbd0.2a98320a.4098.28c1@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: "freebsd-wireless@freebsd.org" X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: lev@FreeBSD.org List-Id: "Discussions of 802.11 stack, tools device driver development." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 May 2013 21:22:19 -0000 Hello, Adrian. You wrote 28 =D0=BC=D0=B0=D1=8F 2013 =D0=B3., 1:10:33: AC> Sweet. I think the problem getting n rates here are likely due to AC> buffer starvation when queuing the addba request or response frames. AC> So I still have to properly fix that. But it'll happen. Cool! It is not show-stopper and could be due to noise environment. We could not now for sure, is it bug or objective reality, that it could not go faster :) Absence of n-ratets and, of course, de-associations WERE bugs, but I could not repeat them anymore. --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-wireless@FreeBSD.ORG Mon May 27 21:53:54 2013 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 6B8947DF; Mon, 27 May 2013 21:53:54 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-qa0-x234.google.com (mail-qa0-x234.google.com [IPv6:2607:f8b0:400d:c00::234]) by mx1.freebsd.org (Postfix) with ESMTP id 11B9EF94; Mon, 27 May 2013 21:53:53 +0000 (UTC) Received: by mail-qa0-f52.google.com with SMTP id bv4so1167687qab.18 for ; Mon, 27 May 2013 14:53:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=TZxOTQqUFzKuaFKs0Bnq/lUh+6PDlaIFan2er9Cqqjc=; b=0zz8GctrD7UVmeWkphmax5HcX8WnWeaB7soVhru3GHdHoqLkb7lfmaw5FN4gKtbog1 IsByJBPDQWKPgQqCRF0VKYtBEg8crKzByGlk9ttCa42EjwUBqZbv1MSyJq/ke8oXQEAY H97wSX0t+ASIE7jDUf03DGCe5w4c/xfFUbNjN5cnjbErHQK38g/nm3vwGI/BeMxfTZL4 TGFDdz2hUufDaWczJkMCfepdS/vy7dabPNRrsKFPPZEljSHpnx4auIgGXlFcAJPmPEej ax9CMYBRWhf7yp1XT388CwUM0Mde59dW15QtvrvTXtJx4pem46Js6Wn5DFcFZu3cLe2G uMjA== MIME-Version: 1.0 X-Received: by 10.224.107.5 with SMTP id z5mr444654qao.82.1369691632631; Mon, 27 May 2013 14:53:52 -0700 (PDT) Received: by 10.224.199.66 with HTTP; Mon, 27 May 2013 14:53:52 -0700 (PDT) In-Reply-To: <281253146.20130528012212@serebryakov.spb.ru> References: <711055633.20130528010212@serebryakov.spb.ru> <51a3cbd0.2a98320a.4098.28c1@mx.google.com> <281253146.20130528012212@serebryakov.spb.ru> Date: Mon, 27 May 2013 14:53:52 -0700 Message-ID: Subject: Re: [rft] please test -HEAD ath; lots of TX changes From: Adrian Chadd To: lev@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "freebsd-wireless@freebsd.org" X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Discussions of 802.11 stack, tools device driver development." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 May 2013 21:53:54 -0000 On 27 May 2013 14:22, Lev Serebryakov wrote: > Hello, Adrian. > You wrote 28 =D0=BC=D0=B0=D1=8F 2013 =D0=B3., 1:10:33: > > AC> Sweet. I think the problem getting n rates here are likely due to > AC> buffer starvation when queuing the addba request or response frames. > AC> So I still have to properly fix that. But it'll happen. > Cool! It is not show-stopper and could be due to noise environment. > We could not now for sure, is it bug or objective reality, that it > could not go faster :) Well, there are still a lot of things to fix there. Right now if frames are filtered due to the node going into power save, the driver will treat them as a failed software retransmit. Too many of those will equate to a dropped frame, and the TX is paused whilst the BAR is sent out. I bet I can fix that a bit. :-) So I may end up being able to improve performance > Absence of n-ratets and, of course, de-associations WERE bugs, but I > could not repeat them anymore. I still have to track down that and make sure those frames are properly treated as a management queue frame in the ath(4) driver. anyway, gotta catch a plane, bbl. Adrian From owner-freebsd-wireless@FreeBSD.ORG Mon May 27 22:15:39 2013 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id D5381E56; Mon, 27 May 2013 22:15:39 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-ie0-x229.google.com (mail-ie0-x229.google.com [IPv6:2607:f8b0:4001:c03::229]) by mx1.freebsd.org (Postfix) with ESMTP id 95A86BA; Mon, 27 May 2013 22:15:39 +0000 (UTC) Received: by mail-ie0-f169.google.com with SMTP id u16so19874659iet.28 for ; Mon, 27 May 2013 15:15:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:to:cc:reply-to:subject:in-reply-to:x-mailer :mime-version:content-type; bh=Nij00GiqNWtbZXfnotS+ddIavdbaqGONmKwz6hjt6BA=; b=BWvuPqRllNRz/yNtudpodS+bjq/XrHbquUrcsW6Lbgq1DcZfedu120Vl/yM/EB7Id5 n78ygAHbSXBFkkbQMzktHxrbS3UC7aW5egSeR+PmtBGGYLabV2HItKbE2UO7DiQ4ITPw 86P4cVOB9j+qsM8g5SjObbBZJ7VhkRsxp5Pxl+PGSMWm6dz+4u883YYMgH5+JpoogEaR OT++hC+JrRBteVjieuBHO2SUuzhRUExyPWfQa+JRnHz/SmzanCytlJnCaRM6+jK5Gr9o zS/UkM0g5HbBS4lJZU87Ug+S6tZ2dp92GG0TmxlAEfPT/0APFxx8HCy0fBh2nFGageTL KKOg== X-Received: by 10.50.85.101 with SMTP id g5mr5679995igz.26.1369692938275; Mon, 27 May 2013 15:15:38 -0700 (PDT) Received: from www.palm.com ([32.137.95.175]) by mx.google.com with ESMTPSA id ij6sm15177417igb.1.2013.05.27.15.15.34 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 27 May 2013 15:15:37 -0700 (PDT) Message-ID: <51a3db09.a66f320a.699a.31bd@mx.google.com> Date: Mon, 27 May 2013 18:15:28 -0400 From: "Adrian Chadd" To: "lev@freebsd.org" Subject: Re: [rft] please test -HEAD ath; lots of TX changes In-Reply-To: <281253146.20130528012212@serebryakov.spb.ru> X-Mailer: Palm webOS v1.0.1 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: "freebsd-wireless@freebsd.org" X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Adrian Chadd List-Id: "Discussions of 802.11 stack, tools device driver development." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 May 2013 22:15:39 -0000 And as always, please keep retesting whenever you csn. I'm going to spend some time now tidying up the tx path, fixing lock deadlo= cks in various places, fixing rate control and some other ancilliary stuff.= So nows the time to properly thrash things. Now, we should try to get even more users onboard! Adrian Sent from my Palm Pre on AT&T On May 27, 2013 5:22 PM, Lev Serebryakov <lev@freebsd.org> wrote:=20 Hello, Adrian. You wrote 28 =D0=BC=D0=B0=D1=8F 2013 =D0=B3., 1:10:33: AC> Sweet. I think the problem getting n rates here are likely due to AC> buffer starvation when queuing the addba request or response frames. AC> So I still have to properly fix that. But it'll happen. Cool! It is not show-stopper and could be due to noise environment. We could not now for sure, is it bug or objective reality, that it could not go faster :) Absence of n-ratets and, of course, de-associations WERE bugs, but I could not repeat them anymore. --=20 // Black Lion AKA Lev Serebryakov <lev@FreeBSD.org> From owner-freebsd-wireless@FreeBSD.ORG Tue May 28 06:33:56 2013 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 447A66C7 for ; Tue, 28 May 2013 06:33:56 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [IPv6:2a01:4f8:131:60a2::2]) by mx1.freebsd.org (Postfix) with ESMTP id 0D3C8C04 for ; Tue, 28 May 2013 06:33:56 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:bd1b:cc3:22ae:789f]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPSA id 803AB4AC1C; Tue, 28 May 2013 10:33:53 +0400 (MSK) Date: Tue, 28 May 2013 10:33:50 +0400 From: Lev Serebryakov X-Priority: 3 (Normal) Message-ID: <956654349.20130528103350@serebryakov.spb.ru> To: "Adrian Chadd" Subject: Re: [rft] please test -HEAD ath; lots of TX changes In-Reply-To: <51a3db09.a66f320a.699a.31bd@mx.google.com> References: <281253146.20130528012212@serebryakov.spb.ru> <51a3db09.a66f320a.699a.31bd@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: "freebsd-wireless@freebsd.org" X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Discussions of 802.11 stack, tools device driver development." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 May 2013 06:33:56 -0000 Hello, Adrian. You wrote 28 =D0=BC=D0=B0=D1=8F 2013 =D0=B3., 2:15:28: AC> And as always, please keep retesting whenever you csn. I'm trying to test every bunch of changes in ath (I do daily "svn up" and watch for changes in ath*), but no more often than 1 per day, and sometimes don't spent my time at computer on weekends, especially in Summer :) So, of course, I'll test all future changes. You do great and very hard work for long time, and these tests is my little contribution to you and your very valuable work! AC> Now, we should try to get even more users onboard! If (oh, that "if") I be able to start my own business, I'll start to order semi-custom made Atheros platforms from China and sell them as SOHO routers / APs with FreeBSD-based totally open FreeBSD-based firmware :) And, of course, I'll become bankrupt shortly due to bad advertisement and marketing, when market is devided between D-Link, ZyXel, TP-Link, NetGear, Linksys and others :) Yes, I'm pessimist (I prefer think about myself as "realist", though). --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-wireless@FreeBSD.ORG Tue May 28 11:55:32 2013 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id B79CF907 for ; Tue, 28 May 2013 11:55:32 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (m209-73.dsl.rawbw.com [198.144.209.73]) by mx1.freebsd.org (Postfix) with ESMTP id 78734237 for ; Tue, 28 May 2013 11:55:31 +0000 (UTC) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.14.7/8.14.7) with ESMTP id r4SBtVoj018398 for ; Tue, 28 May 2013 04:55:31 -0700 (PDT) (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.14.7/8.14.7/Submit) id r4SBtVMl018397 for freebsd-wireless@freebsd.org; Tue, 28 May 2013 04:55:31 -0700 (PDT) (envelope-from david) Date: Tue, 28 May 2013 04:55:31 -0700 From: David Wolfskill To: freebsd-wireless@freebsd.org Subject: iwn(4) link down/up cycling Message-ID: <20130528115531.GO1334@albert.catwhisker.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Zvl510+jvRFHh8wJ" Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: David Wolfskill , freebsd-wireless@freebsd.org List-Id: "Discussions of 802.11 stack, tools device driver development." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 May 2013 11:55:32 -0000 --Zvl510+jvRFHh8wJ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable The laptop I've had for some time has an iwn(4) device that has generally been working well. I recently acquired a laptop which I've set up for my spouse to use; its wireless NIC is also detected as iwn(4). However, even when rather little is going on (as in, she's not using it, because she's off doing Something Else), I find that its IP address (and thus, its hostname) has changed. Here's what "pciconf -lv" has to say about them -- first mine, then the "new" one: iwn0@pci0:12:0:0: class=3D0x028000 card=3D0x11218086 chip=3D0x4235808= 6 rev=3D0x00 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D 'Ultimate N WiFi Link 5300' class =3D network iwn0@pci0:3:0:0: class=3D0x028000 card=3D0x12118086 chip=3D0x4237808= 6 rev=3D0x00 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D 'PRO/Wireless 5100 AGN [Shiloh] Network Connection' class =3D network And here are some representative log entries for the latter: May 28 00:00:00 g1-241 kernel: wlan0: link state changed to DOWN May 28 00:00:03 g1-241 kernel: wlan0: link state changed to UP May 28 04:31:22 g1-241 kernel: wlan0: link state changed to DOWN May 28 04:31:23 g1-241 kernel: wlan0: link state changed to UP Have I done something avoidable to encourage this behavior? Thanks.... Peace, david --=20 David H. Wolfskill david@catwhisker.org Taliban: Evil men with guns afraid of truth from a 14-year old girl. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --Zvl510+jvRFHh8wJ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (FreeBSD) iEYEARECAAYFAlGkmzIACgkQmprOCmdXAD0+DgCdExMeh+K/pyUdAdogyLbRRaht 57UAn1FAGVxYXDQo89kjXpwTKpqlsTWi =0x4a -----END PGP SIGNATURE----- --Zvl510+jvRFHh8wJ-- From owner-freebsd-wireless@FreeBSD.ORG Tue May 28 16:21:49 2013 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id E182F2DC for ; Tue, 28 May 2013 16:21:49 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-qc0-x235.google.com (mail-qc0-x235.google.com [IPv6:2607:f8b0:400d:c01::235]) by mx1.freebsd.org (Postfix) with ESMTP id A9D00780 for ; Tue, 28 May 2013 16:21:49 +0000 (UTC) Received: by mail-qc0-f181.google.com with SMTP id u11so4115276qcx.40 for ; Tue, 28 May 2013 09:21:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=9+4CY9ATtK3NngLc+/nocgB8iJ9IwwgT5jUXgxbPmgc=; b=AHcm1gTPJGpkMbMCRHmiQYpM1qMUXjZf002QpNptkyI45SC5J+TlXIqkdrU3gmNQhu ifl2HORgv2z6GdLlkKBPSz3ZXOpKrCNE68Cpg5C2AQczbS/y+algsCsMrif6+Fbf45OV doUVXUcZJpu3NsMNHhLWn4HBKcAvRB0UPaJfqzRx2IKsM69GLZ9CENMrCrqn9b89a7Xo 3UxkQhATewlG9HhQdwtN/OXR2qGe5P0CKgwE1+MdA3SS0/1UHRXUE5PNcDA8a7o2eA9r 42UdURpxrXDnb3yesGQYf55Ks7S2P0D2GQMJI/JLY4dpCHKgqs2X44E6itIigaXyJ9jc I/bw== MIME-Version: 1.0 X-Received: by 10.49.5.202 with SMTP id u10mr37135356qeu.45.1369758109148; Tue, 28 May 2013 09:21:49 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.199.66 with HTTP; Tue, 28 May 2013 09:21:49 -0700 (PDT) In-Reply-To: <20130528115531.GO1334@albert.catwhisker.org> References: <20130528115531.GO1334@albert.catwhisker.org> Date: Tue, 28 May 2013 09:21:49 -0700 X-Google-Sender-Auth: Nlzqt1Qu3Lvejp1tGrbjf-n_VLM Message-ID: Subject: Re: iwn(4) link down/up cycling From: Adrian Chadd To: David Wolfskill , freebsd-wireless@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Discussions of 802.11 stack, tools device driver development." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 May 2013 16:21:49 -0000 You'll want to enable wpa_supplicant debugging and see what that says. It's your first hint to figuring out why the interface is flapping. It may be that the AP is disconnecting you for being idle too long. Try setting up a background ping. adrian On 28 May 2013 04:55, David Wolfskill wrote: > The laptop I've had for some time has an iwn(4) device that has > generally been working well. > > I recently acquired a laptop which I've set up for my spouse to use; its > wireless NIC is also detected as iwn(4). However, even when rather > little is going on (as in, she's not using it, because she's off doing > Something Else), I find that its IP address (and thus, its hostname) has > changed. Here's what "pciconf -lv" has to say about them -- first mine, > then the "new" one: > > iwn0@pci0:12:0:0: class=0x028000 card=0x11218086 chip=0x42358086 rev=0x00 hdr=0x00 > vendor = 'Intel Corporation' > device = 'Ultimate N WiFi Link 5300' > class = network > > > iwn0@pci0:3:0:0: class=0x028000 card=0x12118086 chip=0x42378086 rev=0x00 hdr=0x00 > vendor = 'Intel Corporation' > device = 'PRO/Wireless 5100 AGN [Shiloh] Network Connection' > class = network > > And here are some representative log entries for the latter: > > May 28 00:00:00 g1-241 kernel: wlan0: link state changed to DOWN > May 28 00:00:03 g1-241 kernel: wlan0: link state changed to UP > > May 28 04:31:22 g1-241 kernel: wlan0: link state changed to DOWN > May 28 04:31:23 g1-241 kernel: wlan0: link state changed to UP > > > Have I done something avoidable to encourage this behavior? > > Thanks.... > > Peace, > david > -- > David H. Wolfskill david@catwhisker.org > Taliban: Evil men with guns afraid of truth from a 14-year old girl. > > See http://www.catwhisker.org/~david/publickey.gpg for my public key. From owner-freebsd-wireless@FreeBSD.ORG Wed May 29 16:55:08 2013 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 959471A9 for ; Wed, 29 May 2013 16:55:08 +0000 (UTC) (envelope-from jhs@berklix.com) Received: from flat.berklix.org (flat.berklix.org [83.236.223.115]) by mx1.freebsd.org (Postfix) with ESMTP id 2AEEF995 for ; Wed, 29 May 2013 16:55:07 +0000 (UTC) Received: from mart.js.berklix.net (p5DCBCDDA.dip0.t-ipconnect.de [93.203.205.218]) (authenticated bits=128) by flat.berklix.org (8.14.5/8.14.5) with ESMTP id r4TGsdsM007120; Wed, 29 May 2013 18:54:41 +0200 (CEST) (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (fire.js.berklix.net [192.168.91.41]) by mart.js.berklix.net (8.14.3/8.14.3) with ESMTP id r4TGt2oJ035379; Wed, 29 May 2013 18:55:02 +0200 (CEST) (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (localhost [127.0.0.1]) by fire.js.berklix.net (8.14.4/8.14.4) with ESMTP id r4TGse3C070284; Wed, 29 May 2013 18:54:57 +0200 (CEST) (envelope-from jhs@fire.js.berklix.net) Message-Id: <201305291654.r4TGse3C070284@fire.js.berklix.net> To: David Wolfskill , freebsd-wireless@freebsd.org Subject: Re: iwn(4) link down/up cycling From: "Julian H. Stacey" Organization: http://berklix.com BSD Unix Linux Consultancy, Munich Germany User-agent: EXMH on FreeBSD http://berklix.com/free/ X-URL: http://www.berklix.com In-reply-to: Your message "Tue, 28 May 2013 04:55:31 PDT." <20130528115531.GO1334@albert.catwhisker.org> Date: Wed, 29 May 2013 18:54:40 +0200 Sender: jhs@berklix.com X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Discussions of 802.11 stack, tools device driver development." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 May 2013 16:55:08 -0000 David Wolfskill wrote: > And here are some representative log entries for the latter: > May 28 00:00:00 g1-241 kernel: wlan0: link state changed to DOWN > May 28 00:00:03 g1-241 kernel: wlan0: link state changed to UP > > May 28 04:31:22 g1-241 kernel: wlan0: link state changed to DOWN > May 28 04:31:23 g1-241 kernel: wlan0: link state changed to UP > > > Have I done something avoidable to encourage this behavior? Might this be a USB device coming & going ? ie might it be USB bus at fault ? Cheers, Julian -- Julian Stacey, BSD Unix Linux C Sys Eng Consultant, Munich http://berklix.com Reply below not above, like a play script. Indent old text with "> ". Send plain text. No quoted-printable, HTML, base64, multipart/alternative. From owner-freebsd-wireless@FreeBSD.ORG Thu May 30 02:30:57 2013 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id DF7DC1199 for ; Thu, 30 May 2013 02:30:57 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (m209-73.dsl.rawbw.com [198.144.209.73]) by mx1.freebsd.org (Postfix) with ESMTP id C03C616A for ; Thu, 30 May 2013 02:30:56 +0000 (UTC) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.14.7/8.14.7) with ESMTP id r4U2Uq81033584; Wed, 29 May 2013 19:30:52 -0700 (PDT) (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.14.7/8.14.7/Submit) id r4U2UpxR033583; Wed, 29 May 2013 19:30:51 -0700 (PDT) (envelope-from david) Date: Wed, 29 May 2013 19:30:51 -0700 From: David Wolfskill To: "Julian H. Stacey" Subject: Re: iwn(4) link down/up cycling Message-ID: <20130530023051.GJ1334@albert.catwhisker.org> References: <20130528115531.GO1334@albert.catwhisker.org> <201305291654.r4TGse3C070284@fire.js.berklix.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="YtWd7p+F4osuzCU+" Content-Disposition: inline In-Reply-To: <201305291654.r4TGse3C070284@fire.js.berklix.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-wireless@freebsd.org X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Discussions of 802.11 stack, tools device driver development." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 May 2013 02:30:57 -0000 --YtWd7p+F4osuzCU+ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, May 29, 2013 at 06:54:40PM +0200, Julian H. Stacey wrote: > David Wolfskill wrote: > ... > > Have I done something avoidable to encourage this behavior? >=20 > Might this be a USB device coming & going ? ie might it be USB bus at fau= lt ? > ... I admit that hardware is not one of my stronger points, but I would think that the fact that the iwn0 device shows up in the output of "pciconf -vl": iwn0@pci0:3:0:0: class=3D0x028000 card=3D0x12118086 chip=3D0x4237808= 6 rev=3D0x00 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D 'PRO/Wireless 5100 AGN [Shiloh] Network Connection' class =3D network gives reason to believe that the device is attached via PCI, rather than USB. I hope. :-} But I appreciate the suggestion. Peace, david --=20 David H. Wolfskill david@catwhisker.org Taliban: Evil men with guns afraid of truth from a 14-year old girl. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --YtWd7p+F4osuzCU+ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (FreeBSD) iEYEARECAAYFAlGmudoACgkQmprOCmdXAD1W8wCeJhIVwZnlGXYYzarBUZJkUhtz bnwAn0agPDJV0SYwT6f/DBfvVt5oFo9m =wvAC -----END PGP SIGNATURE----- --YtWd7p+F4osuzCU+-- From owner-freebsd-wireless@FreeBSD.ORG Fri May 31 00:25:23 2013 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 00ADBB89 for ; Fri, 31 May 2013 00:25:22 +0000 (UTC) (envelope-from jhs@berklix.com) Received: from flat.berklix.org (flat.berklix.org [83.236.223.115]) by mx1.freebsd.org (Postfix) with ESMTP id 8B53980E for ; Fri, 31 May 2013 00:25:21 +0000 (UTC) Received: from mart.js.berklix.net (p5DCBC3D7.dip0.t-ipconnect.de [93.203.195.215]) (authenticated bits=128) by flat.berklix.org (8.14.5/8.14.5) with ESMTP id r4V0Od94013252; Fri, 31 May 2013 02:24:39 +0200 (CEST) (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (fire.js.berklix.net [192.168.91.41]) by mart.js.berklix.net (8.14.3/8.14.3) with ESMTP id r4V0P5Du043520; Fri, 31 May 2013 02:25:05 +0200 (CEST) (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (localhost [127.0.0.1]) by fire.js.berklix.net (8.14.4/8.14.4) with ESMTP id r4V0OhpY017628; Fri, 31 May 2013 02:25:00 +0200 (CEST) (envelope-from jhs@fire.js.berklix.net) Message-Id: <201305310025.r4V0OhpY017628@fire.js.berklix.net> To: David Wolfskill Subject: Re: iwn(4) link down/up cycling From: "Julian H. Stacey" Organization: http://berklix.com BSD Unix Linux Consultancy, Munich Germany User-agent: EXMH on FreeBSD http://berklix.com/free/ X-URL: http://www.berklix.com In-reply-to: Your message "Wed, 29 May 2013 19:30:51 PDT." <20130530023051.GJ1334@albert.catwhisker.org> Date: Fri, 31 May 2013 02:24:43 +0200 Sender: jhs@berklix.com Cc: freebsd-wireless@freebsd.org X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Discussions of 802.11 stack, tools device driver development." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 May 2013 00:25:23 -0000 David Wolfskill wrote: > On Wed, May 29, 2013 at 06:54:40PM +0200, Julian H. Stacey wrote: > > David Wolfskill wrote: > > ... > > > Have I done something avoidable to encourage this behavior? > >=20 > > Might this be a USB device coming & going ? ie might it be USB bus at fau= > lt ? > > ... > > I admit that hardware is not one of my stronger points, but I would Me either, on modern stuff :-) > think that the fact that the iwn0 device shows up in the output of > "pciconf -vl": > > iwn0@pci0:3:0:0: class=3D0x028000 card=3D0x12118086 chip=3D0x4237808= > 6 rev=3D0x00 hdr=3D0x00 > vendor =3D 'Intel Corporation' > device =3D 'PRO/Wireless 5100 AGN [Shiloh] Network Connection' > class =3D network > > gives reason to believe that the device is attached via PCI, rather > than USB. I hope. :-} Yes, I just plugged in a USB wireless run0 device & it made no difference to pciconf -lv output. > > But I appreciate the suggestion. Yup, sorry, was a long shot, & off target. Cheers, Julian -- Julian Stacey, BSD Unix Linux C Sys Eng Consultant, Munich http://berklix.com Reply below not above, like a play script. Indent old text with "> ". Send plain text. No quoted-printable, HTML, base64, multipart/alternative. From owner-freebsd-wireless@FreeBSD.ORG Fri May 31 01:13:34 2013 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 7C5E380A for ; Fri, 31 May 2013 01:13:34 +0000 (UTC) (envelope-from jhs@berklix.com) Received: from flat.berklix.org (flat.berklix.org [83.236.223.115]) by mx1.freebsd.org (Postfix) with ESMTP id 13C91AB7 for ; Fri, 31 May 2013 01:13:33 +0000 (UTC) Received: from mart.js.berklix.net (pD9FBEA7D.dip0.t-ipconnect.de [217.251.234.125]) (authenticated bits=128) by flat.berklix.org (8.14.5/8.14.5) with ESMTP id r4V1DW8l013519 for ; Fri, 31 May 2013 03:13:33 +0200 (CEST) (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (fire.js.berklix.net [192.168.91.41]) by mart.js.berklix.net (8.14.3/8.14.3) with ESMTP id r4V1DRiF043941 for ; Fri, 31 May 2013 03:13:29 +0200 (CEST) (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (localhost [127.0.0.1]) by fire.js.berklix.net (8.14.4/8.14.4) with ESMTP id r4V1DQid018804 for ; Fri, 31 May 2013 03:13:31 +0200 (CEST) (envelope-from jhs@fire.js.berklix.net) Message-Id: <201305310113.r4V1DQid018804@fire.js.berklix.net> To: freebsd-wireless@freebsd.org Subject: BCM43225 802.11b/g/n support ? From: "Julian H. Stacey" Organization: http://berklix.com BSD Linux Unix Consultancy, Munich Germany User-agent: EXMH on FreeBSD http://www.berklix.com/free/ X-URL: http://www.berklix.com/~jhs/cv/ Date: Fri, 31 May 2013 03:13:25 +0200 Sender: jhs@berklix.com X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Discussions of 802.11 stack, tools device driver development." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 May 2013 01:13:34 -0000 Hi freebsd-wireless@freebsd.org Anyone known of code [to test] for [native] support on 9.1-RELEASE (or current) for (from pciconf -lv ) none3@pci0:2:0:0: class=0x028000 card=0xe021105b chip=0x435714e4 rev=0x01 hdr=0x00 vendor = 'Broadcom Corporation' device = 'BCM43225 802.11b/g/n' class = network I did a seach, some clues: http://forums.freebsd.org/showthread.php?t=29839 http://www.nvnews.net/vbulletin/showthread.php?p=2431079 http://forums.freebsd.org/showthread.php?p=201805#post201805 http://forums.pcbsd.org/showthread.php?t=15901 Is NDIS the way to go ? (or an external USB run0: I also have ?) My notes on my laptop: Acer Aspire 5741 http://www.berklix.com/~jhs/hardware/laptops/acer/aspire/5741/ Cheers, Julian - -- Julian Stacey, BSD Unix Linux C Sys Eng Consultant, Munich http://berklix.com Reply below not above, like a play script. Indent old text with "> ". Send plain text. No quoted-printable, HTML, base64, multipart/alternative. From owner-freebsd-wireless@FreeBSD.ORG Fri May 31 01:27:33 2013 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 56CA1A21 for ; Fri, 31 May 2013 01:27:33 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-qe0-f53.google.com (mail-qe0-f53.google.com [209.85.128.53]) by mx1.freebsd.org (Postfix) with ESMTP id 2034AB6E for ; Fri, 31 May 2013 01:27:32 +0000 (UTC) Received: by mail-qe0-f53.google.com with SMTP id s14so579020qeb.40 for ; Thu, 30 May 2013 18:27:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=3TInzn+Fa9FFSEeauf51rR5r2qcctiyEyhT09+DQVSY=; b=nxb92jFEpBC28zjmI4Ji12RBkmWbTishWjpERArMIMtaXd9XmL4vQZZiUYDLwZBlmQ Kb3Eyvvuydm/5WVw8Pj6W1sSwrC/rIrG3uNX/4OGq7wbY9uwmmflyOjq+hscMXkdu6pj ZdD0tULO6KW5goRZFs0ezLn+wfkFkECvSy/MrE92T0mSusiqWcBQJpeEk7CCreUexugy nD3oMUhVUmf32QMF3opgHLJgogMZdMWdAkejvzQxl9iA1jEmUQoeqz3O6XMV4YM/J7+h 8mcWLRrpWl71LgkU1ICCwljftSOPVUJmmaRAnjKjADaAjb6IqpO/VphwYkpznFqHOFRU UBcA== MIME-Version: 1.0 X-Received: by 10.49.61.129 with SMTP id p1mr8958723qer.28.1369963652150; Thu, 30 May 2013 18:27:32 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.5.65 with HTTP; Thu, 30 May 2013 18:27:32 -0700 (PDT) In-Reply-To: <201305310113.r4V1DQid018804@fire.js.berklix.net> References: <201305310113.r4V1DQid018804@fire.js.berklix.net> Date: Thu, 30 May 2013 18:27:32 -0700 X-Google-Sender-Auth: qUqgKIO_pg5o_idh059i8UTalwM Message-ID: Subject: Re: BCM43225 802.11b/g/n support ? From: Adrian Chadd To: "Julian H. Stacey" Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-wireless@freebsd.org X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Discussions of 802.11 stack, tools device driver development." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 May 2013 01:27:33 -0000 Hi, There's no support fror this AFAIK. sorry On 30 May 2013 18:13, Julian H. Stacey wrote: > Hi freebsd-wireless@freebsd.org > Anyone known of code [to test] for [native] support > on 9.1-RELEASE (or current) for > > (from pciconf -lv ) > none3@pci0:2:0:0: class=0x028000 card=0xe021105b chip=0x435714e4 rev=0x01 hdr=0x00 > vendor = 'Broadcom Corporation' > device = 'BCM43225 802.11b/g/n' > class = network > > I did a seach, some clues: > http://forums.freebsd.org/showthread.php?t=29839 > http://www.nvnews.net/vbulletin/showthread.php?p=2431079 > http://forums.freebsd.org/showthread.php?p=201805#post201805 > http://forums.pcbsd.org/showthread.php?t=15901 > > Is NDIS the way to go ? (or an external USB run0: I also have ?) > > My notes on my laptop: Acer Aspire 5741 > http://www.berklix.com/~jhs/hardware/laptops/acer/aspire/5741/ > > Cheers, > Julian > - -- > Julian Stacey, BSD Unix Linux C Sys Eng Consultant, Munich http://berklix.com > Reply below not above, like a play script. Indent old text with "> ". > Send plain text. No quoted-printable, HTML, base64, multipart/alternative. > _______________________________________________ > freebsd-wireless@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-wireless > To unsubscribe, send any mail to "freebsd-wireless-unsubscribe@freebsd.org" From owner-freebsd-wireless@FreeBSD.ORG Fri May 31 07:04:44 2013 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 98859C04 for ; Fri, 31 May 2013 07:04:44 +0000 (UTC) (envelope-from allen.versfeld@gmail.com) Received: from mail-we0-x22c.google.com (mail-we0-x22c.google.com [IPv6:2a00:1450:400c:c03::22c]) by mx1.freebsd.org (Postfix) with ESMTP id 323AF902 for ; Fri, 31 May 2013 07:04:44 +0000 (UTC) Received: by mail-we0-f172.google.com with SMTP id w62so952142wes.31 for ; Fri, 31 May 2013 00:04:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:to:subject:references:date:mime-version :content-transfer-encoding:from:organization:message-id:in-reply-to :user-agent; bh=r/y8bsB+bgbg5P84hnBZB6AELBQesNsWFL5okDxu5CU=; b=ihnK5asZqAGbHYHBC2XGh8QxWmBx1MgWYBLvFPLpqjXM0Yw1qQfzsjya9BijYHxa4s 4pjJzycrF4xJJqRJQT2KHSK9vD8piHW8INZOD3gZTFYLpc8kwUxS8gHkhBU5oPNqb0ga E76HAWmMPmNaCucD4nNs7qexhEvNnqDGelMcom+EnxWQubSea5VSkoh6W1XgGwV4stxD V6nrxAJL1/2zys7szbYeo2moMSkBKelzSt7HbEbLnj2o9IEMqlFrdjpR7n0B0njHVIGS T6433AXShXc8JZ4ySgsoph4IcE61buGS9GXUYkIJe2udnlAvGxXkV9DBj9VAK57qJpEQ M+Pg== X-Received: by 10.181.13.112 with SMTP id ex16mr1896759wid.28.1369983883251; Fri, 31 May 2013 00:04:43 -0700 (PDT) Received: from pta-allenv-06.africa.enterprise.root ([165.233.47.163]) by mx.google.com with ESMTPSA id fu14sm1873433wic.0.2013.05.31.00.04.41 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 31 May 2013 00:04:42 -0700 (PDT) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes To: freebsd-wireless@freebsd.org Subject: Re: BCM43225 802.11b/g/n support ? References: <201305310113.r4V1DQid018804@fire.js.berklix.net> Date: Fri, 31 May 2013 09:04:37 +0200 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Allen Versfeld" Organization: Urban Astronomer Message-ID: In-Reply-To: <201305310113.r4V1DQid018804@fire.js.berklix.net> User-Agent: Opera Mail/12.15 (FreeBSD) X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Discussions of 802.11 stack, tools device driver development." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 May 2013 07:04:44 -0000 Hi Julian I'm running a BCM43228 chip -- not so different from yours -- in an HP ProBook 6570b. NDIS is the only option and it does mostly work, if you can tolerate unexpected restarts. I can usually get a few hours work in before it goes wrong. Disappointing but there apparently just isn't anybody available to work on support for these chips at the moment so we have to live with it! Regards Allen Versfeld On Fri, 31 May 2013 03:13:25 +0200, Julian H. Stacey wrote: > Hi freebsd-wireless@freebsd.org > Anyone known of code [to test] for [native] support > on 9.1-RELEASE (or current) for > > (from pciconf -lv ) > none3@pci0:2:0:0: class=0x028000 card=0xe021105b chip=0x435714e4 > rev=0x01 hdr=0x00 > vendor = 'Broadcom Corporation' > device = 'BCM43225 802.11b/g/n' > class = network > > I did a seach, some clues: > http://forums.freebsd.org/showthread.php?t=29839 > http://www.nvnews.net/vbulletin/showthread.php?p=2431079 > http://forums.freebsd.org/showthread.php?p=201805#post201805 > http://forums.pcbsd.org/showthread.php?t=15901 > > Is NDIS the way to go ? (or an external USB run0: I also have ?) > > My notes on my laptop: Acer Aspire 5741 > http://www.berklix.com/~jhs/hardware/laptops/acer/aspire/5741/ > > Cheers, > Julian > - -- > Julian Stacey, BSD Unix Linux C Sys Eng Consultant, Munich > http://berklix.com > Reply below not above, like a play script. Indent old text with "> ". > Send plain text. No quoted-printable, HTML, base64, > multipart/alternative. > _______________________________________________ > freebsd-wireless@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-wireless > To unsubscribe, send any mail to > "freebsd-wireless-unsubscribe@freebsd.org" -- Using Opera's mail client: http://www.opera.com/mail/ From owner-freebsd-wireless@FreeBSD.ORG Sat Jun 1 11:52:40 2013 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id C2CF3DD5; Sat, 1 Jun 2013 11:52:40 +0000 (UTC) (envelope-from jhs@berklix.com) Received: from flat.berklix.org (flat.berklix.org [83.236.223.115]) by mx1.freebsd.org (Postfix) with ESMTP id 5952CCE7; Sat, 1 Jun 2013 11:52:40 +0000 (UTC) Received: from mart.js.berklix.net (p5DCBD4D7.dip0.t-ipconnect.de [93.203.212.215]) (authenticated bits=128) by flat.berklix.org (8.14.5/8.14.5) with ESMTP id r51BqVJd006361; Sat, 1 Jun 2013 13:52:31 +0200 (CEST) (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (fire.js.berklix.net [192.168.91.41]) by mart.js.berklix.net (8.14.3/8.14.3) with ESMTP id r51BqXcT052988; Sat, 1 Jun 2013 13:52:33 +0200 (CEST) (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (localhost [127.0.0.1]) by fire.js.berklix.net (8.14.4/8.14.4) with ESMTP id r51BqNTK011604; Sat, 1 Jun 2013 13:52:28 +0200 (CEST) (envelope-from jhs@fire.js.berklix.net) Message-Id: <201306011152.r51BqNTK011604@fire.js.berklix.net> To: Adrian Chadd , "Allen Versfeld" Subject: Re: BCM43225 802.11b/g/n support ? From: "Julian H. Stacey" Organization: http://berklix.com BSD Unix Linux Consultancy, Munich Germany User-agent: EXMH on FreeBSD http://berklix.com/free/ X-URL: http://www.berklix.com In-reply-to: Your message "Fri, 31 May 2013 09:04:37 +0200." Date: Sat, 01 Jun 2013 13:52:23 +0200 Sender: jhs@berklix.com Cc: freebsd-wireless@freebsd.org X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Discussions of 802.11 stack, tools device driver development." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Jun 2013 11:52:40 -0000 > > vendor = 'Broadcom Corporation' > > device = 'BCM43225 802.11b/g/n' OK, Thanks Adrian & Allen. Cheers, Julian -- Julian Stacey, BSD Unix Linux C Sys Eng Consultant, Munich http://berklix.com Reply below not above, like a play script. Indent old text with "> ". Send plain text. No quoted-printable, HTML, base64, multipart/alternative.