From owner-freebsd-wireless@FreeBSD.ORG Sun Mar 18 09:40:12 2012 Return-Path: Delivered-To: freebsd-wireless@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 14CF7106564A for ; Sun, 18 Mar 2012 09:40:12 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 044528FC12 for ; Sun, 18 Mar 2012 09:40:12 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q2I9eBSW084421 for ; Sun, 18 Mar 2012 09:40:11 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q2I9eBF2084420; Sun, 18 Mar 2012 09:40:11 GMT (envelope-from gnats) Date: Sun, 18 Mar 2012 09:40:11 GMT Message-Id: <201203180940.q2I9eBF2084420@freefall.freebsd.org> To: freebsd-wireless@FreeBSD.org From: Mark Linimon Cc: Subject: Re: kern/165870: bwn driver does not attach on HP Pavilion dv9420us X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Mark Linimon 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, 18 Mar 2012 09:40:12 -0000 The following reply was made to PR kern/165870; it has been noted by GNATS. From: Mark Linimon To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/165870: bwn driver does not attach on HP Pavilion dv9420us Date: Sun, 18 Mar 2012 04:37:13 -0500 ----- Forwarded message from John Merryweather Cooper ----- Date: Sat, 17 Mar 2012 10:05:53 -0500 From: John Merryweather Cooper To: freebsd-bugs@freebsd.org Subject: Re: kern/165870: bwn driver does not attach on HP Pavilion dv9420us User-Agent: KMail/1.13.7 (FreeBSD/9.0-STABLE; KDE/4.7.4; amd64; ; ) Another data point. I get the same log messages, but the bwn driver now works for me on 9-STABLE. All I need to do was follow the upgrade steps. I note that I was rebuilding the firmware module (and it's dependencies) with 8.3-PRERELEASE with no effect. -- John M. Cooper ----- End forwarded message ----- From owner-freebsd-wireless@FreeBSD.ORG Sun Mar 18 16:04:02 2012 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 92FB11065674; Sun, 18 Mar 2012 16:04:02 +0000 (UTC) (envelope-from iwasaki@jp.FreeBSD.org) Received: from locore.org (ns01.locore.org [218.45.21.227]) by mx1.freebsd.org (Postfix) with ESMTP id 1F7028FC20; Sun, 18 Mar 2012 16:04:01 +0000 (UTC) Received: from localhost (celeron.v4.locore.org [192.168.0.10]) by locore.org (8.14.5/8.14.5/iwasaki) with ESMTP/inet id q2IG3rVE081994; Mon, 19 Mar 2012 01:03:53 +0900 (JST) (envelope-from iwasaki@jp.FreeBSD.org) Date: Mon, 19 Mar 2012 01:03:52 +0900 (JST) Message-Id: <20120319.010352.124006046.iwasaki@jp.FreeBSD.org> To: bschmidt@freebsd.org From: Mitsuru IWASAKI In-Reply-To: <201203171232.42515.bschmidt@freebsd.org> References: <20120316.230547.41627417.iwasaki@jp.FreeBSD.org> <201203171232.42515.bschmidt@freebsd.org> X-Mailer: Mew version 3.3 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-wireless@freebsd.org Subject: Re: [patch] iwi(4) suspend/resume broken X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.5 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, 18 Mar 2012 16:04:02 -0000 Hi, > I'd really prefer calling ieee80211_stop/init() in the suspend/resume > functions, while the driver is not holding the lock (net80211 might > call into the driver again). > > I roughly checked a few things and I even think that calling > ieee80211_stop_all() might be enough. Still playing around though. OK, then I wouldn't commit my patches, I would wait for your patches to test here. Or may I try to hack ieee80211 layer to fix suspend/resume problem? Thanks! From owner-freebsd-wireless@FreeBSD.ORG Sun Mar 18 17:25:14 2012 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 36024106566B for ; Sun, 18 Mar 2012 17:25:14 +0000 (UTC) (envelope-from bschmidt@techwires.net) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by mx1.freebsd.org (Postfix) with ESMTP id A8E328FC15 for ; Sun, 18 Mar 2012 17:25:13 +0000 (UTC) Received: by wibhj6 with SMTP id hj6so2265721wib.13 for ; Sun, 18 Mar 2012 10:25:12 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:message-id:x-gm-message-state; bh=U8F/vB4KXmsE77kiVGny37GiukHAF3S4w7tA7/8NK/0=; b=IV89nIo75AO3l+IIqPvOPJ/+erZpU/nT9lvSIboA30QEfaYAmYlFMIUhDF/Fa/pMo6 I2u162TlUFFICupctaW4JOaQH5dF8CAWU2M7yYNALp2poZ/OvqYiAQ8TCI9CEiEfEgvk 0xH62hI/ZlufuCCkLz1eWV1gHpeZXxKKtSfCatGrxJVhGpU4ubGxnz8zWl03gZwYwUGU FeWVj086h3cMTdnZP89nLBqdJXYdnPzXgPl2h/NZZvgzZXG8tt0hONCsrHYafj62TKO5 3ABc4KS7fFefdufx677t/0VnY3RJLDV8W7ZzXHg3o98W0SBf/xOSLSP9MtfGpKjaNbmf A5hw== Received: by 10.180.95.74 with SMTP id di10mr22795270wib.1.1332091512498; Sun, 18 Mar 2012 10:25:12 -0700 (PDT) Received: from amy.lab.techwires.net (dslb-178-002-172-042.pools.arcor-ip.net. [178.2.172.42]) by mx.google.com with ESMTPS id n8sm29500720wix.10.2012.03.18.10.25.09 (version=SSLv3 cipher=OTHER); Sun, 18 Mar 2012 10:25:11 -0700 (PDT) Sender: Bernhard Schmidt From: Bernhard Schmidt To: Mitsuru IWASAKI Date: Sun, 18 Mar 2012 18:25:25 +0100 User-Agent: KMail/1.13.7 (FreeBSD/9.0-STABLE; KDE/4.7.4; amd64; ; ) References: <201203171232.42515.bschmidt@freebsd.org> <20120319.010352.124006046.iwasaki@jp.FreeBSD.org> In-Reply-To: <20120319.010352.124006046.iwasaki@jp.FreeBSD.org> MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="Boundary-00=_FqhZPFMxtAg2aQz" Message-Id: <201203181825.25124.bschmidt@freebsd.org> X-Gm-Message-State: ALoCoQmnVt00er5e9w1e6PMxkFf0ZVcz/Wd5XI9Yw5db+TwOfgtOnL3Lu8ha9PcqJRq1hTqfknLV Cc: freebsd-wireless@freebsd.org Subject: Re: [patch] iwi(4) suspend/resume broken X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.5 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, 18 Mar 2012 17:25:14 -0000 --Boundary-00=_FqhZPFMxtAg2aQz Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit On Sunday 18 March 2012 17:03:52 Mitsuru IWASAKI wrote: > Hi, > > > I'd really prefer calling ieee80211_stop/init() in the suspend/resume > > functions, while the driver is not holding the lock (net80211 might > > call into the driver again). > > > > I roughly checked a few things and I even think that calling > > ieee80211_stop_all() might be enough. Still playing around though. > > OK, then I wouldn't commit my patches, I would wait for your patches to > test here. > Or may I try to hack ieee80211 layer to fix suspend/resume problem? > > Thanks! Well, I came up with attached diff. It works fine on iwn and wpi too basically, wpi has a bit of an issue with the scan after resume, I see probe resquest/response on air but the device doesn't pick em up sometimes.. still debugging. Anyways, I'm pretty sure that if you are doing the same for ipw/iwi it will just work fine. The ieee80211_resume_all/suspend_all calls will ensure that the appropriate stop/init driver functions are called. -- Bernhard --Boundary-00=_FqhZPFMxtAg2aQz Content-Type: text/x-patch; charset="ISO-8859-1"; name="suspend.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="suspend.diff" Index: sys/dev/iwn/if_iwn.c =================================================================== --- sys/dev/iwn/if_iwn.c (revision 233092) +++ sys/dev/iwn/if_iwn.c (working copy) @@ -945,13 +945,9 @@ static int iwn_suspend(device_t dev) { struct iwn_softc *sc = device_get_softc(dev); - struct ifnet *ifp = sc->sc_ifp; - struct ieee80211com *ic = ifp->if_l2com; - struct ieee80211vap *vap = TAILQ_FIRST(&ic->ic_vaps); + struct ieee80211com *ic = sc->sc_ifp->if_l2com; - iwn_stop(sc); - if (vap != NULL) - ieee80211_stop(vap); + ieee80211_suspend_all(ic); return 0; } @@ -959,20 +955,12 @@ static int iwn_resume(device_t dev) { struct iwn_softc *sc = device_get_softc(dev); - struct ifnet *ifp = sc->sc_ifp; - struct ieee80211com *ic = ifp->if_l2com; - struct ieee80211vap *vap = TAILQ_FIRST(&ic->ic_vaps); + struct ieee80211com *ic = sc->sc_ifp->if_l2com; /* Clear device-specific "PCI retry timeout" register (41h). */ pci_write_config(dev, 0x41, 0, 1); - if (ifp->if_flags & IFF_UP) { - iwn_init(sc); - if (vap != NULL) - ieee80211_init(vap); - if (ifp->if_drv_flags & IFF_DRV_RUNNING) - iwn_start(ifp); - } + ieee80211_resume_all(ic); return 0; } Index: sys/dev/wpi/if_wpi.c =================================================================== --- sys/dev/wpi/if_wpi.c (revision 233092) +++ sys/dev/wpi/if_wpi.c (working copy) @@ -1218,8 +1218,9 @@ static int wpi_suspend(device_t dev) { struct wpi_softc *sc = device_get_softc(dev); + struct ieee80211com *ic = sc->sc_ifp->if_l2com; - wpi_stop(sc); + ieee80211_suspend_all(ic); return 0; } @@ -1227,15 +1228,11 @@ static int wpi_resume(device_t dev) { struct wpi_softc *sc = device_get_softc(dev); - struct ifnet *ifp = sc->sc_ifp; + struct ieee80211com *ic = sc->sc_ifp->if_l2com; pci_write_config(dev, 0x41, 0, 1); - if (ifp->if_flags & IFF_UP) { - wpi_init(ifp->if_softc); - if (ifp->if_drv_flags & IFF_DRV_RUNNING) - wpi_start(ifp); - } + ieee80211_resume_all(ic); return 0; } --Boundary-00=_FqhZPFMxtAg2aQz-- From owner-freebsd-wireless@FreeBSD.ORG Sun Mar 18 19:22:55 2012 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 93629106566B; Sun, 18 Mar 2012 19:22:55 +0000 (UTC) (envelope-from iwasaki@jp.FreeBSD.org) Received: from locore.org (ns01.locore.org [218.45.21.227]) by mx1.freebsd.org (Postfix) with ESMTP id 447108FC0C; Sun, 18 Mar 2012 19:22:54 +0000 (UTC) Received: from localhost (celeron.v4.locore.org [192.168.0.10]) by locore.org (8.14.5/8.14.5/iwasaki) with ESMTP/inet id q2IJMqXr083056; Mon, 19 Mar 2012 04:22:52 +0900 (JST) (envelope-from iwasaki@jp.FreeBSD.org) Date: Mon, 19 Mar 2012 04:22:50 +0900 (JST) Message-Id: <20120319.042250.74754884.iwasaki@jp.FreeBSD.org> To: bschmidt@freebsd.org From: Mitsuru IWASAKI In-Reply-To: <201203181825.25124.bschmidt@freebsd.org> References: <201203171232.42515.bschmidt@freebsd.org> <20120319.010352.124006046.iwasaki@jp.FreeBSD.org> <201203181825.25124.bschmidt@freebsd.org> X-Mailer: Mew version 3.3 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Multipart/Mixed; boundary="--Next_Part(Mon_Mar_19_04:22:50_2012_364)--" Content-Transfer-Encoding: 7bit Cc: freebsd-wireless@freebsd.org Subject: Re: [patch] iwi(4) suspend/resume broken X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.5 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, 18 Mar 2012 19:22:55 -0000 ----Next_Part(Mon_Mar_19_04:22:50_2012_364)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, From: Bernhard Schmidt > Well, I came up with attached diff. It works fine on iwn and wpi > too basically, wpi has a bit of an issue with the scan after resume, > I see probe resquest/response on air but the device doesn't pick > em up sometimes.. still debugging. > > Anyways, I'm pretty sure that if you are doing the same for ipw/iwi > it will just work fine. The ieee80211_resume_all/suspend_all calls > will ensure that the appropriate stop/init driver functions are called. Great! I did the same thing for iwi(4), tested several times and it works just fine. Please commit the attached patches if you like it. Thanks! ----Next_Part(Mon_Mar_19_04:22:50_2012_364)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="iwi-suspend.diff" Index: if_iwi.c =================================================================== RCS file: /home/ncvs/src/sys/dev/iwi/if_iwi.c,v retrieving revision 1.81 diff -u -r1.81 if_iwi.c --- if_iwi.c 10 Mar 2012 17:08:57 -0000 1.81 +++ if_iwi.c 18 Mar 2012 19:02:42 -0000 @@ -863,8 +863,10 @@ iwi_suspend(device_t dev) { struct iwi_softc *sc = device_get_softc(dev); + struct ifnet *ifp = sc->sc_ifp; + struct ieee80211com *ic = ifp->if_l2com; - iwi_stop(sc); + ieee80211_suspend_all(ic); return 0; } @@ -874,11 +876,11 @@ { struct iwi_softc *sc = device_get_softc(dev); struct ifnet *ifp = sc->sc_ifp; + struct ieee80211com *ic = ifp->if_l2com; pci_write_config(dev, 0x41, 0, 1); - if (ifp->if_flags & IFF_UP) - iwi_init(sc); + ieee80211_resume_all(ic); return 0; } ----Next_Part(Mon_Mar_19_04:22:50_2012_364)---- From owner-freebsd-wireless@FreeBSD.ORG Sun Mar 18 20:42:23 2012 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DFD5D106564A; Sun, 18 Mar 2012 20:42:23 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by mx1.freebsd.org (Postfix) with ESMTP id 444CC8FC0A; Sun, 18 Mar 2012 20:42:22 +0000 (UTC) Received: by wibhq7 with SMTP id hq7so2394928wib.13 for ; Sun, 18 Mar 2012 13:42:22 -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=Ex2aBPTuQmXGSxxmQA1nHr48rcvyL+sRQm4wR3BFlAU=; b=kQWPiIijnWnfQTGUqukhjHJ2j30xWKeUneHHkKmG6ze5Um4HVzto+nfqG2C9qe9wRC CtaI+IawmWd4s9z0w4BXax/9H+VsTjslInOQO5M+fwkxOFCWL1iZI0KefYvtth2vCvy0 o3jq/KJkDbbY1E0f3M6aof+s3qI25TznGS+IHso3LusewJ2z51b2qMOl7vsYW/Lu0eNe +LiZMfzZD2PNlDrlfHjDLbg349FOV5aFStMy6/BBITXTXYNqupkthAQc+HY6JJ8fG8AY qEHA62FSTm0S5MeQq2btq6iQLK2MZX39q7BMTi/0yb+R+75Qd8EE+fA+M2x5xNFQns7/ oMUg== MIME-Version: 1.0 Received: by 10.180.95.197 with SMTP id dm5mr14291961wib.20.1332103342215; Sun, 18 Mar 2012 13:42:22 -0700 (PDT) Received: by 10.223.143.3 with HTTP; Sun, 18 Mar 2012 13:42:22 -0700 (PDT) In-Reply-To: <20120319.042250.74754884.iwasaki@jp.FreeBSD.org> References: <201203171232.42515.bschmidt@freebsd.org> <20120319.010352.124006046.iwasaki@jp.FreeBSD.org> <201203181825.25124.bschmidt@freebsd.org> <20120319.042250.74754884.iwasaki@jp.FreeBSD.org> Date: Sun, 18 Mar 2012 13:42:22 -0700 Message-ID: From: Kevin Oberman To: Mitsuru IWASAKI Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-wireless@freebsd.org, bschmidt@freebsd.org Subject: Re: [patch] iwi(4) suspend/resume broken X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.5 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, 18 Mar 2012 20:42:24 -0000 On Sun, Mar 18, 2012 at 12:22 PM, Mitsuru IWASAKI wrote: > Hi, > > From: Bernhard Schmidt >> Well, I came up with attached diff. It works fine on iwn and wpi >> too basically, wpi has a bit of an issue with the scan after resume, >> I see probe resquest/response on air but the device doesn't pick >> em up sometimes.. still debugging. >> >> Anyways, I'm pretty sure that if you are doing the same for ipw/iwi >> it will just work fine. The ieee80211_resume_all/suspend_all calls >> will ensure that the appropriate stop/init driver functions are called. > > Great! =A0I did the same thing for iwi(4), tested several times and it > works just fine. > > Please commit the attached patches if you like it. And the patch for iwn. (I don't have a wpi, but I assume that one, as well. I'd hope it's MFCed for 9.1. I'm beginning to feel a tiny bit hopeful that I'll be able to susped and resume my laptop again someday soon. --=20 R. Kevin Oberman, Network Engineer E-mail: kob6558@gmail.com From owner-freebsd-wireless@FreeBSD.ORG Mon Mar 19 00:10:05 2012 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0C20C106566C; Mon, 19 Mar 2012 00:10:05 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id C4B748FC0C; Mon, 19 Mar 2012 00:10:04 +0000 (UTC) Received: by pbcwz17 with SMTP id wz17so937950pbc.13 for ; Sun, 18 Mar 2012 17:10:04 -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=Ev58C5BFInt2lZpne50Uv4sL8F5HNiIO71l4DOFAFNw=; b=sm4ZBXizZVqrOaR11LVmjMtFNOJo3lqh/WKjzibRxz9bTyrpvsLdP5y5OWDJo/hm20 w3cifBmTA+x+I5C/2YmIFLOiaDwfLnOfbNijutxcDU1jkppx/FzLhBhLdoICqrzbAAAv /VZiSaEkrbbGsN4gnsRIQfbdfUazgKxEVvRj6CQyw5qQvdiJKfHoinbDbIur6xNYUL5l DfwCqovHH9rA/FA4lyo7JWT8l6pwiAXnQDW3jpDknz6laDXoDNNx3u5P7Zu8x32oIs81 xY2x5otNGxY/K9Cz2SJiHSf7nYowt2rMxOWdaauQslmuNFe7yiXsKz2/LhlslrAIV24i bNeg== MIME-Version: 1.0 Received: by 10.68.234.195 with SMTP id ug3mr35525553pbc.4.1332115804296; Sun, 18 Mar 2012 17:10:04 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.143.33.5 with HTTP; Sun, 18 Mar 2012 17:10:04 -0700 (PDT) In-Reply-To: <201203170440.q2H4esnb099802@freefall.freebsd.org> References: <201203170440.q2H4esnb099802@freefall.freebsd.org> Date: Sun, 18 Mar 2012 17:10:04 -0700 X-Google-Sender-Auth: 5nZiGSP7i4SZM_Qe0pVIw9xcTkY Message-ID: From: Adrian Chadd To: bug-followup@freebsd.org, Vincent Hoffman Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-wireless@freebsd.org Subject: Re: kern/166190: [ath] TX hangs and frames stuck in TX queue X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.5 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, 19 Mar 2012 00:10:05 -0000 I think I understand what's going on here. It turns out that multiple instances of the TX code (via if_start()) were running at the same time. These were processing frames from the input queue and assigning them sequence numbers. This seems to be occuring: * thread A would allocate sequence number 5 * thread B would concurrency allocate sequence number 6 * thread B would then "win" the race to add it to the BAW, as the sequence numbers were allocated early but it wouldn't be added to the queue until much later * then thread A would try adding its frame to the BAW, but since the BAW left edge is now 6, 5 is now "out of window". I have a local patch here which I'm going to test tonight/tomorrow. It delays the sequence number allocation until _right before_ the frame may be added to the BAW. This is done inside the same lock, so there's no chance that it'll race with another concurrent thread. I won't commit it until I have committed some verification code to -HEAD to complain loudly when a frame _before_ the BAW is trying to be queued. Since that shouldn't happen in reality, I'm going to guess that it'll pop up in my testing and Vincents use. Once I've verified that (a) my sanity checking code is firing as I expect it to, (b) Vincent also sees the same, and (c) this is fixed by my patch, I'll look at committing it. Vincent - thanks so very much for persisting with this bug! I'd not have really found it at all if you didn't point the odd behaviour out to me. Now - yes, the solution would also be "serialise the whole TX queue damnit." Yes, that'd solve it, but as I'm seeing 802.11ac around the corner, I'd like to actually debug, diagnose and document how a multi-threaded TX/RX path could work. Serialising the driver TX path isn't going to help me do that. :-) Adrian From owner-freebsd-wireless@FreeBSD.ORG Mon Mar 19 00:10:14 2012 Return-Path: Delivered-To: freebsd-wireless@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 901971065670 for ; Mon, 19 Mar 2012 00:10:14 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 629C18FC15 for ; Mon, 19 Mar 2012 00:10:14 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q2J0AEDe089621 for ; Mon, 19 Mar 2012 00:10:14 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q2J0AElW089620; Mon, 19 Mar 2012 00:10:14 GMT (envelope-from gnats) Date: Mon, 19 Mar 2012 00:10:14 GMT Message-Id: <201203190010.q2J0AElW089620@freefall.freebsd.org> To: freebsd-wireless@FreeBSD.org From: Adrian Chadd Cc: Subject: Re: kern/166190: [ath] TX hangs and frames stuck in TX queue X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.5 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, 19 Mar 2012 00:10:14 -0000 The following reply was made to PR kern/166190; it has been noted by GNATS. From: Adrian Chadd To: bug-followup@freebsd.org, Vincent Hoffman Cc: freebsd-wireless@freebsd.org Subject: Re: kern/166190: [ath] TX hangs and frames stuck in TX queue Date: Sun, 18 Mar 2012 17:10:04 -0700 I think I understand what's going on here. It turns out that multiple instances of the TX code (via if_start()) were running at the same time. These were processing frames from the input queue and assigning them sequence numbers. This seems to be occuring: * thread A would allocate sequence number 5 * thread B would concurrency allocate sequence number 6 * thread B would then "win" the race to add it to the BAW, as the sequence numbers were allocated early but it wouldn't be added to the queue until much later * then thread A would try adding its frame to the BAW, but since the BAW left edge is now 6, 5 is now "out of window". I have a local patch here which I'm going to test tonight/tomorrow. It delays the sequence number allocation until _right before_ the frame may be added to the BAW. This is done inside the same lock, so there's no chance that it'll race with another concurrent thread. I won't commit it until I have committed some verification code to -HEAD to complain loudly when a frame _before_ the BAW is trying to be queued. Since that shouldn't happen in reality, I'm going to guess that it'll pop up in my testing and Vincents use. Once I've verified that (a) my sanity checking code is firing as I expect it to, (b) Vincent also sees the same, and (c) this is fixed by my patch, I'll look at committing it. Vincent - thanks so very much for persisting with this bug! I'd not have really found it at all if you didn't point the odd behaviour out to me. Now - yes, the solution would also be "serialise the whole TX queue damnit." Yes, that'd solve it, but as I'm seeing 802.11ac around the corner, I'd like to actually debug, diagnose and document how a multi-threaded TX/RX path could work. Serialising the driver TX path isn't going to help me do that. :-) Adrian From owner-freebsd-wireless@FreeBSD.ORG Mon Mar 19 05:27:43 2012 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9151E106564A; Mon, 19 Mar 2012 05:27:43 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by mx1.freebsd.org (Postfix) with ESMTP id 56B4E8FC08; Mon, 19 Mar 2012 05:27:43 +0000 (UTC) Received: by dakl33 with SMTP id l33so11599721dak.17 for ; Sun, 18 Mar 2012 22:27:43 -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=PHA8PrpuUf92mwbPpRvnCiWTBPx1p/gxsWoaVBsv88s=; b=lWgfR+RKIcSlHLSAfM0gwU1qkOANU/onmZ6n2zFPjCIOAaLR2U9oz6WHAkeBEZLv2H dR0iUftLevNtWZ3NMZi6jCJ7NorbwQOcPqTA/THINKfuMYAXmA4fvJKcmeSweZa2/3SM v6GBXK9AokGJOToXrwmEFG5ylRQqiUALzR2VUeO6CKHxT+Zx+rhkzjef/xYxp1ib5ETh IWX4+/BRma+OP/usDVAjLs9ddA5Y6MCeU+TwqiiGC1nA9QX55LVNmA/YBULMJM7lbJF4 hGy4v/8D3V3kSg31BRL5GVZQmy0Ct3BLPDQLNcmbhC2zaNXSB4H6KnIGw1H0fFLAAuqD V1sA== MIME-Version: 1.0 Received: by 10.68.234.195 with SMTP id ug3mr37400891pbc.4.1332134863060; Sun, 18 Mar 2012 22:27:43 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.143.33.5 with HTTP; Sun, 18 Mar 2012 22:27:43 -0700 (PDT) In-Reply-To: References: <201203170440.q2H4esnb099802@freefall.freebsd.org> Date: Sun, 18 Mar 2012 22:27:43 -0700 X-Google-Sender-Auth: 6DEVTKUT3m_AvwuUPqW7w_gmGPk Message-ID: From: Adrian Chadd To: bug-followup@freebsd.org, Vincent Hoffman Content-Type: multipart/mixed; boundary=047d7b33c9fe4e3ed604bb91d101 Cc: freebsd-wireless@freebsd.org Subject: Re: kern/166190: [ath] TX hangs and frames stuck in TX queue X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.5 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, 19 Mar 2012 05:27:43 -0000 --047d7b33c9fe4e3ed604bb91d101 Content-Type: text/plain; charset=ISO-8859-1 Hi Vincent, Please try this patch and let me know how it behaves. Thanks, Adrian --047d7b33c9fe4e3ed604bb91d101 Content-Type: text/x-patch; charset=US-ASCII; name="kern-166190-baw.diff" Content-Disposition: attachment; filename="kern-166190-baw.diff" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gzz2qutw0 SW5kZXg6IHN5cy9kZXYvYXRoL2lmX2F0aF9kZWJ1Zy5jCj09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIHN5cy9kZXYv YXRoL2lmX2F0aF9kZWJ1Zy5jCShyZXZpc2lvbiAyMzMwODkpCisrKyBzeXMvZGV2L2F0aC9pZl9h dGhfZGVidWcuYwkod29ya2luZyBjb3B5KQpAQCAtMTM1LDE5ICsxMzUsMjMgQEAKIAlwcmludGYo IlEldVslM3VdIiwgcW51bSwgaXgpOwogCXdoaWxlIChiZiAhPSBOVUxMKSB7CiAJCWZvciAoaSA9 IDAsIGRzID0gYmYtPmJmX2Rlc2M7IGkgPCBiZi0+YmZfbnNlZzsgaSsrLCBkcysrKSB7Ci0JCQlw cmludGYoIiAoRFMuVjolcCBEUy5QOiVwKSBMOiUwOHggRDolMDh4IEY6JTA0eCVzXG4iCi0JCQkg ICAgICAgIiAgICAgICAgVFhGOiAlMDR4IFNlcTogJWQgc3d0cnk6ICVkIEFEREJBVz86ICVkIERP QkFXPzogJWRcbiIKLQkJCSAgICAgICAiICAgICAgICAlMDh4ICUwOHggJTA4eCAlMDh4ICUwOHgg JTA4eFxuIiwKKwkJCXByaW50ZigiIChEUy5WOiVwIERTLlA6JXApIEw6JTA4eCBEOiUwOHggRjol MDR4JXNcbiIsCiAJCQkgICAgZHMsIChjb25zdCBzdHJ1Y3QgYXRoX2Rlc2MgKiliZi0+YmZfZGFk ZHIgKyBpLAogCQkJICAgIGRzLT5kc19saW5rLCBkcy0+ZHNfZGF0YSwgYmYtPmJmX3R4ZmxhZ3Ms Ci0JCQkgICAgIWRvbmUgPyAiIiA6ICh0cy0+dHNfc3RhdHVzID09IDApID8gIiAqIiA6ICIgISIs CisJCQkgICAgIWRvbmUgPyAiIiA6ICh0cy0+dHNfc3RhdHVzID09IDApID8gIiAqIiA6ICIgISIp OworCQkJcHJpbnRmKCIgICAgICAgIFRYRjogJTA0eCBTZXE6ICVkIHN3dHJ5OiAlZCBBRERCQVc/ OiAlZCBET0JBVz86ICVkXG4iLAogCQkJICAgIGJmLT5iZl9zdGF0ZS5iZnNfZmxhZ3MsCiAJCQkg ICAgYmYtPmJmX3N0YXRlLmJmc19zZXFubywKIAkJCSAgICBiZi0+YmZfc3RhdGUuYmZzX3JldHJp ZXMsCiAJCQkgICAgYmYtPmJmX3N0YXRlLmJmc19hZGRlZGJhdywKLQkJCSAgICBiZi0+YmZfc3Rh dGUuYmZzX2RvYmF3LAorCQkJICAgIGJmLT5iZl9zdGF0ZS5iZnNfZG9iYXcpOworCQkJcHJpbnRm KCIgICAgICAgIFNFUU5PX0FTU0lHTkVEOiAlZCwgTkVFRF9TRVFOTzogJWRcbiIsCisJCQkgICAg YmYtPmJmX3N0YXRlLmJmc19zZXFub19hc3NpZ25lZCwKKwkJCSAgICBiZi0+YmZfc3RhdGUuYmZz X25lZWRfc2Vxbm8pOworCQkJcHJpbnRmKCIgICAgICAgICUwOHggJTA4eCAlMDh4ICUwOHggJTA4 eCAlMDh4XG4iLAogCQkJICAgIGRzLT5kc19jdGwwLCBkcy0+ZHNfY3RsMSwKLQkJCSAgICBkcy0+ ZHNfaHdbMF0sIGRzLT5kc19od1sxXSwgZHMtPmRzX2h3WzJdLCBkcy0+ZHNfaHdbM10pOworCQkJ ICAgIGRzLT5kc19od1swXSwgZHMtPmRzX2h3WzFdLAorCQkJICAgIGRzLT5kc19od1syXSwgZHMt PmRzX2h3WzNdKTsKIAkJCWlmIChhaC0+YWhfbWFnaWMgPT0gMHgyMDA2NTQxNikgewogCQkJCXBy aW50ZigiICAgICAgICAlMDh4ICUwOHggJTA4eCAlMDh4ICUwOHggJTA4eCAlMDh4ICUwOHhcbiIs CiAJCQkJICAgIGRzLT5kc19od1s0XSwgZHMtPmRzX2h3WzVdLCBkcy0+ZHNfaHdbNl0sCkluZGV4 OiBzeXMvZGV2L2F0aC9pZl9hdGh2YXIuaAo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBzeXMvZGV2L2F0aC9pZl9h dGh2YXIuaAkocmV2aXNpb24gMjMzMDg5KQorKysgc3lzL2Rldi9hdGgvaWZfYXRodmFyLmgJKHdv cmtpbmcgY29weSkKQEAgLTIxNSw2ICsyMTUsOCBAQAogCQlpbnQgYmZzX2lzbXJyOjE7CS8qIGRv IG11bHRpLXJhdGUgVFggcmV0cnkgKi8KIAkJaW50IGJmc19kb3Byb3Q6MTsJLyogZG8gUlRTL0NU UyBiYXNlZCBwcm90ZWN0aW9uICovCiAJCWludCBiZnNfZG9yYXRlbG9va3VwOjE7CS8qIGRvIHJh dGUgbG9va3VwIGJlZm9yZSBlYWNoIFRYICovCisJCWludCBiZnNfbmVlZF9zZXFubzoxOwkvKiBu ZWVkIHRvIGFzc2lnbiBhIHNlcW5vIGZvciBhZ2dyZWdhdGlvbiAqLworCQlpbnQgYmZzX3NlcW5v X2Fzc2lnbmVkOjE7CS8qIHNlcW5vIGhhcyBiZWVuIGFzc2lnbmVkICovCiAJCWludCBiZnNfbmZs OwkJLyogbmV4dCBmcmFnbWVudCBsZW5ndGggKi8KIAogCQkvKgpJbmRleDogc3lzL2Rldi9hdGgv aWZfYXRoX3R4X2h0LmMKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gc3lzL2Rldi9hdGgvaWZfYXRoX3R4X2h0LmMJ KHJldmlzaW9uIDIzMzA4OSkKKysrIHN5cy9kZXYvYXRoL2lmX2F0aF90eF9odC5jCSh3b3JraW5n IGNvcHkpCkBAIC02NDQsNyArNjQ0LDcgQEAKIGF0aF90eF9mb3JtX2FnZ3Ioc3RydWN0IGF0aF9z b2Z0YyAqc2MsIHN0cnVjdCBhdGhfbm9kZSAqYW4sIHN0cnVjdCBhdGhfdGlkICp0aWQsCiAgICAg YXRoX2J1ZmhlYWQgKmJmX3EpCiB7Ci0JLy9zdHJ1Y3QgaWVlZTgwMjExX25vZGUgKm5pID0gJmFu LT5hbl9ub2RlOworCXN0cnVjdCBpZWVlODAyMTFfbm9kZSAqbmkgPSAmYW4tPmFuX25vZGU7CiAJ c3RydWN0IGF0aF9idWYgKmJmLCAqYmZfZmlyc3QgPSBOVUxMLCAqYmZfcHJldiA9IE5VTEw7CiAJ aW50IG5mcmFtZXMgPSAwOwogCXVpbnQxNl90IGFnZ3JfbGltaXQgPSAwLCBhbCA9IDAsIGJwYWQg PSAwLCBhbF9kZWx0YSwgaF9iYXc7CkBAIC02NTIsNiArNjUyLDcgQEAKIAlpbnQgc3RhdHVzID0g QVRIX0FHR1JfRE9ORTsKIAlpbnQgcHJldl9mcmFtZXMgPSAwOwkvKiBYWFggZm9yIEFSNTQxNiBi dXJzdCwgbm90IGRvbmUgaGVyZSAqLwogCWludCBwcmV2X2FsID0gMDsJLyogWFhYIGFsc28gZm9y IEFSNTQxNiBidXJzdCAqLworCWludCBzZXFubzsKIAogCUFUSF9UWFFfTE9DS19BU1NFUlQoc2Mt PnNjX2FjMnFbdGlkLT5hY10pOwogCkBAIC03MDcsMTYgKzcwOCw2IEBACiAJCSAqLwogCiAJCS8q Ci0JCSAqIElmIHRoZSBwYWNrZXQgaGFzIGEgc2VxdWVuY2UgbnVtYmVyLCBkbyBub3QKLQkJICog c3RlcCBvdXRzaWRlIG9mIHRoZSBibG9jay1hY2sgd2luZG93LgotCQkgKi8KLQkJaWYgKCEgQkFX X1dJVEhJTih0YXAtPnR4YV9zdGFydCwgdGFwLT50eGFfd25kLAotCQkgICAgU0VRTk8oYmYtPmJm X3N0YXRlLmJmc19zZXFubykpKSB7Ci0JCSAgICBzdGF0dXMgPSBBVEhfQUdHUl9CQVdfQ0xPU0VE OwotCQkgICAgYnJlYWs7Ci0JCX0KLQotCQkvKgogCQkgKiBYWFggVE9ETzogQVI1NDE2IGhhcyBh biA4SyBhZ2dyZWdhdGlvbiBzaXplIGxpbWl0CiAJCSAqIHdoZW4gUlRTIGlzIGVuYWJsZWQsIGFu ZCBSVFMgaXMgcmVxdWlyZWQgZm9yIGR1YWwtc3RyZWFtCiAJCSAqIHJhdGVzLgpAQCAtNzQ0LDYg KzczNSw1OCBAQAogCQl9CiAKIAkJLyoKKwkJICogVE9ETzogSWYgaXQncyBfYmVmb3JlXyB0aGUg QkFXIGxlZnQgZWRnZSwgY29tcGxhaW4gdmVyeSBsb3VkbHkuCisJCSAqIFRoaXMgbWVhbnMgc29t ZXRoaW5nIChlbHNlKSBoYXMgc2xpZCB0aGUgbGVmdCBlZGdlIGFsb25nCisJCSAqIGJlZm9yZSB3 ZSBnb3QgYSBjaGFuY2UgdG8gYmUgVFhlZC4KKwkJICovCisKKwkJLyoKKwkJICogQ2hlY2sgaWYg d2UgaGF2ZSBzcGFjZSBpbiB0aGUgQkFXIGZvciB0aGlzIGZyYW1lIGJlZm9yZQorCQkgKiB3ZSBh ZGQgaXQuCisJCSAqCisJCSAqIHNlZSBhdGhfdHhfeG1pdF9hZ2dyKCkgZm9yIG1vcmUgaW5mby4K KwkJICovCisJCWlmIChiZi0+YmZfc3RhdGUuYmZzX2RvYmF3KSB7CisJCQlpZiAoISBCQVdfV0lU SElOKHRhcC0+dHhhX3N0YXJ0LCB0YXAtPnR4YV93bmQsCisJCQkgICAgbmktPm5pX3R4c2Vxc1ti Zi0+YmZfc3RhdGUuYmZzX3RpZF0pKSB7CisJCQkJc3RhdHVzID0gQVRIX0FHR1JfQkFXX0NMT1NF RDsKKwkJCQlicmVhazsKKwkJCX0KKwkJCS8qIFhYWCBjaGVjayBmb3IgYmZzX25lZWRfc2Vxbm8/ ICovCisJCQlpZiAoISBiZi0+YmZfc3RhdGUuYmZzX3NlcW5vX2Fzc2lnbmVkKSB7CisJCQkJc2Vx bm8gPSBhdGhfdHhfdGlkX3NlcW5vX2Fzc2lnbihzYywgbmksIGJmLCBiZi0+YmZfbSk7CisJCQkJ aWYgKHNlcW5vIDwgMCkgeworCQkJCQlkZXZpY2VfcHJpbnRmKHNjLT5zY19kZXYsCisJCQkJCSAg ICAiJXM6IGJmPSVwLCBodWgsIHNlcW5vPS0xP1xuIiwKKwkJCQkJICAgIF9fZnVuY19fLAorCQkJ CQkgICAgYmYpOworCQkJCQkvKiBYWFggd2hhdCBjYW4gd2UgZXZlbiBkbyBoZXJlPyAqLworCQkJ CX0KKwkJCQkvKiBGbHVzaCBzZXFubyB1cGRhdGUgdG8gUkFNICovCisJCQkJLyoKKwkJCQkgKiBY WFggVGhpcyBpcyByZXF1aXJlZCBiZWNhdXNlIHRoZSBkbWFzZXR1cAorCQkJCSAqIFhYWCBpcyBk b25lIGVhcmx5IHJhdGhlciB0aGFuIGF0IGRpc3BhdGNoCisJCQkJICogWFhYIHRpbWUuIEV3LCB3 ZSBzaG91bGQgZml4IHRoaXMhCisJCQkJICovCisJCQkJYnVzX2RtYW1hcF9zeW5jKHNjLT5zY19k bWF0LCBiZi0+YmZfZG1hbWFwLAorCQkJCSAgICBCVVNfRE1BU1lOQ19QUkVXUklURSk7CisJCQl9 CisJCX0KKworCQkvKgorCQkgKiBJZiB0aGUgcGFja2V0IGhhcyBhIHNlcXVlbmNlIG51bWJlciwg ZG8gbm90CisJCSAqIHN0ZXAgb3V0c2lkZSBvZiB0aGUgYmxvY2stYWNrIHdpbmRvdy4KKwkJICov CisJCWlmICghIEJBV19XSVRISU4odGFwLT50eGFfc3RhcnQsIHRhcC0+dHhhX3duZCwKKwkJICAg IFNFUU5PKGJmLT5iZl9zdGF0ZS5iZnNfc2Vxbm8pKSkgeworCQkJZGV2aWNlX3ByaW50ZihzYy0+ c2NfZGV2LAorCQkJICAgICIlczogYmY9JXAsIHNlcW5vPSVkLCBvdXRzaWRlPyFcbiIsCisJCQkg ICAgX19mdW5jX18sIGJmLCBTRVFOTyhiZi0+YmZfc3RhdGUuYmZzX3NlcW5vKSk7CisJCQlzdGF0 dXMgPSBBVEhfQUdHUl9CQVdfQ0xPU0VEOworCQkJYnJlYWs7CisJCX0KKworCQkvKgogCQkgKiB0 aGlzIHBhY2tldCBpcyBwYXJ0IG9mIGFuIGFnZ3JlZ2F0ZS4KIAkJICovCiAJCUFUSF9UWFFfUkVN T1ZFKHRpZCwgYmYsIGJmX2xpc3QpOwpJbmRleDogc3lzL2Rldi9hdGgvaWZfYXRoX3R4LmMKPT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PQotLS0gc3lzL2Rldi9hdGgvaWZfYXRoX3R4LmMJKHJldmlzaW9uIDIzMzA4OSkKKysr IHN5cy9kZXYvYXRoL2lmX2F0aF90eC5jCSh3b3JraW5nIGNvcHkpCkBAIC0xMDksOCArMTA5LDYg QEAKICAgICBpbnQgdGlkKTsKIHN0YXRpYyBpbnQgYXRoX3R4X2FtcGR1X3J1bm5pbmcoc3RydWN0 IGF0aF9zb2Z0YyAqc2MsIHN0cnVjdCBhdGhfbm9kZSAqYW4sCiAgICAgaW50IHRpZCk7Ci1zdGF0 aWMgaWVlZTgwMjExX3NlcSBhdGhfdHhfdGlkX3NlcW5vX2Fzc2lnbihzdHJ1Y3QgYXRoX3NvZnRj ICpzYywKLSAgICBzdHJ1Y3QgaWVlZTgwMjExX25vZGUgKm5pLCBzdHJ1Y3QgYXRoX2J1ZiAqYmYs IHN0cnVjdCBtYnVmICptMCk7CiBzdGF0aWMgaW50IGF0aF90eF9hY3Rpb25fZnJhbWVfb3ZlcnJp ZGVfcXVldWUoc3RydWN0IGF0aF9zb2Z0YyAqc2MsCiAgICAgc3RydWN0IGllZWU4MDIxMV9ub2Rl ICpuaSwgc3RydWN0IG1idWYgKm0wLCBpbnQgKnRpZCk7CiAKQEAgLTEzNzYsNyArMTM3NCw3IEBA CiAJaW50IGlzbWNhc3Q7CiAJY29uc3Qgc3RydWN0IGllZWU4MDIxMV9mcmFtZSAqd2g7CiAJaW50 IGlzX2FtcGR1LCBpc19hbXBkdV90eCwgaXNfYW1wZHVfcGVuZGluZzsKLQlpZWVlODAyMTFfc2Vx IHNlcW5vOworCS8vaWVlZTgwMjExX3NlcSBzZXFubzsKIAl1aW50OF90IHR5cGUsIHN1YnR5cGU7 CiAKIAkvKgpAQCAtMTQyOCw4ICsxNDI2LDkgQEAKIAlpc19hbXBkdV9wZW5kaW5nID0gYXRoX3R4 X2FtcGR1X3BlbmRpbmcoc2MsIEFUSF9OT0RFKG5pKSwgdGlkKTsKIAlpc19hbXBkdSA9IGlzX2Ft cGR1X3R4IHwgaXNfYW1wZHVfcGVuZGluZzsKIAotCURQUklOVEYoc2MsIEFUSF9ERUJVR19TV19U WCwgIiVzOiB0aWQ9JWQsIGFjPSVkLCBpc19hbXBkdT0lZFxuIiwKLQkgICAgX19mdW5jX18sIHRp ZCwgcHJpLCBpc19hbXBkdSk7CisJRFBSSU5URihzYywgQVRIX0RFQlVHX1NXX1RYLAorCSAgICAi JXM6IGJmPSVwLCB0aWQ9JWQsIGFjPSVkLCBpc19hbXBkdT0lZFxuIiwKKwkgICAgX19mdW5jX18s IGJmLCB0aWQsIHByaSwgaXNfYW1wZHUpOwogCiAJLyogTXVsdGljYXN0IGZyYW1lcyBnbyBvbnRv IHRoZSBzb2Z0d2FyZSBtdWx0aWNhc3QgcXVldWUgKi8KIAlpZiAoaXNtY2FzdCkKQEAgLTE0NDcs NiArMTQ0Niw5IEBACiAJLyogRG8gdGhlIGdlbmVyaWMgZnJhbWUgc2V0dXAgKi8KIAkvKiBYWFgg c2hvdWxkIGp1c3QgYnplcm8gdGhlIGJmX3N0YXRlPyAqLwogCWJmLT5iZl9zdGF0ZS5iZnNfZG9i YXcgPSAwOworCWJmLT5iZl9zdGF0ZS5iZnNfc2Vxbm9fYXNzaWduZWQgPSAwOworCWJmLT5iZl9z dGF0ZS5iZnNfbmVlZF9zZXFubyA9IDA7CisJYmYtPmJmX3N0YXRlLmJmc19zZXFubyA9IC0xOwkv KiBYWFggZGVidWdnaW5nICovCiAKIAkvKiBBLU1QRFUgVFg/IE1hbnVhbGx5IHNldCBzZXF1ZW5j ZSBudW1iZXIgKi8KIAkvKiBEb24ndCBkbyBpdCB3aGlsc3QgcGVuZGluZzsgdGhlIG5ldDgwMjEx IGxheWVyIHN0aWxsIGFzc2lnbnMgdGhlbSAqLwpAQCAtMTQ1OSwxOSArMTQ2MSwyNyBAQAogCQkg KiBkb24ndCBnZXQgYSBzZXF1ZW5jZSBudW1iZXIgZnJvbSB0aGUgY3VycmVudAogCQkgKiBUSUQg YW5kIHRodXMgbWVzcyB3aXRoIHRoZSBCQVcuCiAJCSAqLwotCQlzZXFubyA9IGF0aF90eF90aWRf c2Vxbm9fYXNzaWduKHNjLCBuaSwgYmYsIG0wKTsKKwkJLy9zZXFubyA9IGF0aF90eF90aWRfc2Vx bm9fYXNzaWduKHNjLCBuaSwgYmYsIG0wKTsKIAkJaWYgKElFRUU4MDIxMV9RT1NfSEFTX1NFUSh3 aCkgJiYKIAkJICAgIHN1YnR5cGUgIT0gSUVFRTgwMjExX0ZDMF9TVUJUWVBFX1FPU19OVUxMKSB7 CiAJCQliZi0+YmZfc3RhdGUuYmZzX2RvYmF3ID0gMTsKKwkJCWJmLT5iZl9zdGF0ZS5iZnNfbmVl ZF9zZXFubyA9IDE7CiAJCX0KIAkJQVRIX1RYUV9VTkxPQ0sodHhxKTsKKwl9IGVsc2UgeworCQkv KiBObyBBTVBEVSBUWCwgd2UndmUgYmVlbiBhc3NpZ25lZCBhIHNlcXVlbmNlIG51bWJlci4gKi8K KwkJaWYgKElFRUU4MDIxMV9RT1NfSEFTX1NFUSh3aCkpIHsKKwkJCWJmLT5iZl9zdGF0ZS5iZnNf c2Vxbm9fYXNzaWduZWQgPSAxOworCQkJYmYtPmJmX3N0YXRlLmJmc19zZXFubyA9CisJCQkgICAg TV9TRVFOT19HRVQobTApIDw8IElFRUU4MDIxMV9TRVFfU0VRX1NISUZUOworCQl9CiAJfQogCiAJ LyoKIAkgKiBJZiBuZWVkZWQsIHRoZSBzZXF1ZW5jZSBudW1iZXIgaGFzIGJlZW4gYXNzaWduZWQu CiAJICogU3F1aXJyZWwgaXQgYXdheSBzb21ld2hlcmUgZWFzeSB0byBnZXQgdG8uCiAJICovCi0J YmYtPmJmX3N0YXRlLmJmc19zZXFubyA9IE1fU0VRTk9fR0VUKG0wKSA8PCBJRUVFODAyMTFfU0VR X1NFUV9TSElGVDsKKwkvL2JmLT5iZl9zdGF0ZS5iZnNfc2Vxbm8gPSBNX1NFUU5PX0dFVChtMCkg PDwgSUVFRTgwMjExX1NFUV9TRVFfU0hJRlQ7CiAKIAkvKiBJcyBhbXBkdSBwZW5kaW5nPyBmZXRj aCB0aGUgc2Vxbm8gYW5kIHByaW50IGl0IG91dCAqLwogCWlmIChpc19hbXBkdV9wZW5kaW5nKQpA QCAtMTQ4OCw2ICsxNDk4LDEwIEBACiAJLyogQXQgdGhpcyBwb2ludCBtMCBjb3VsZCBoYXZlIGNo YW5nZWQhICovCiAJbTAgPSBiZi0+YmZfbTsKIAorCURQUklOVEYoc2MsIEFUSF9ERUJVR19TV19U WCwKKwkgICAgIiVzOiBET05FOiBiZj0lcCwgdGlkPSVkLCBhYz0lZCwgaXNfYW1wZHU9JWQsIGRv YmF3PSVkLCBzZXFubz0lZFxuIiwKKwkgICAgX19mdW5jX18sIGJmLCB0aWQsIHByaSwgaXNfYW1w ZHUsIGJmLT5iZl9zdGF0ZS5iZnNfZG9iYXcsIE1fU0VRTk9fR0VUKG0wKSk7CisKICNpZiAxCiAJ LyoKIAkgKiBJZiBpdCdzIGEgbXVsdGljYXN0IGZyYW1lLCBkbyBhIGRpcmVjdC1kaXNwYXRjaCB0 byB0aGUKQEAgLTE1MDYsNiArMTUyMCw4IEBACiAJICogcmVhY2hlZC4pCiAJICovCiAJaWYgKHR4 cSA9PSAmYXZwLT5hdl9tY2FzdHEpIHsKKwkJRFBSSU5URihzYywgQVRIX0RFQlVHX1NXX1RYX0NU UkwsCisJCSAgICAiJXM6IGJmPSVwOiBtY2FzdHE6IFRYJ2luZ1xuIiwgX19mdW5jX18sIGJmKTsK IAkJQVRIX1RYUV9MT0NLKHR4cSk7CiAJCWF0aF90eF94bWl0X25vcm1hbChzYywgdHhxLCBiZik7 CiAJCUFUSF9UWFFfVU5MT0NLKHR4cSk7CkBAIC0xNTE4LDYgKzE1MzQsOCBAQAogCQlBVEhfVFhR X1VOTE9DSyh0eHEpOwogCX0gZWxzZSB7CiAJCS8qIGFkZCB0byBzb2Z0d2FyZSBxdWV1ZSAqLwor CQlEUFJJTlRGKHNjLCBBVEhfREVCVUdfU1dfVFhfQ1RSTCwKKwkJICAgICIlczogYmY9JXA6IHN3 cTogVFgnaW5nXG4iLCBfX2Z1bmNfXywgYmYpOwogCQlhdGhfdHhfc3dxKHNjLCBuaSwgdHhxLCBi Zik7CiAJfQogI2Vsc2UKQEAgLTE5NjYsMjYgKzE5ODQsNTEgQEAKIAlpZiAoYmYtPmJmX3N0YXRl LmJmc19pc3JldHJpZWQpCiAJCXJldHVybjsKIAorCS8qCisJICogSWYgdGhpcyBvY2N1cnMgd2Un cmUgaW4gYSBsb3Qgb2YgdHJvdWJsZS4gIFdlIHNob3VsZCB0cnkgdG8KKwkgKiByZWNvdmVyIGZy b20gdGhpcyB3aXRob3V0IHRoZSBzZXNzaW9uIGhhbmdpbmc/CisJICovCisJaWYgKCEgYmYtPmJm X3N0YXRlLmJmc19zZXFub19hc3NpZ25lZCkgeworCQlkZXZpY2VfcHJpbnRmKHNjLT5zY19kZXYs CisJCSAgICAiJXM6IGJmPSVwLCBzZXFub19hc3NpZ25lZCBpcyAwPyFcbiIsIF9fZnVuY19fLCBi Zik7CisJCXJldHVybjsKKwl9CisKIAl0YXAgPSBhdGhfdHhfZ2V0X3R4X3RpZChhbiwgdGlkLT50 aWQpOwogCiAJaWYgKGJmLT5iZl9zdGF0ZS5iZnNfYWRkZWRiYXcpCiAJCWRldmljZV9wcmludGYo c2MtPnNjX2RldiwKLQkJICAgICIlczogcmUtYWRkZWQ/IHRpZD0lZCwgc2Vxbm8gJWQ7IHdpbmRv dyAlZDolZDsgIgorCQkgICAgIiVzOiByZS1hZGRlZD8gYmY9JXAsIHRpZD0lZCwgc2Vxbm8gJWQ7 IHdpbmRvdyAlZDolZDsgIgogCQkgICAgImJhdyBoZWFkPSVkIHRhaWw9JWRcbiIsCi0JCSAgICBf X2Z1bmNfXywgdGlkLT50aWQsIFNFUU5PKGJmLT5iZl9zdGF0ZS5iZnNfc2Vxbm8pLAorCQkgICAg X19mdW5jX18sIGJmLCB0aWQtPnRpZCwgU0VRTk8oYmYtPmJmX3N0YXRlLmJmc19zZXFubyksCiAJ CSAgICB0YXAtPnR4YV9zdGFydCwgdGFwLT50eGFfd25kLCB0aWQtPmJhd19oZWFkLAogCQkgICAg dGlkLT5iYXdfdGFpbCk7CiAKIAkvKgorCSAqIFZlcmlmeSB0aGF0IHRoZSBnaXZlbiBzZXF1ZW5j ZSBudW1iZXIgaXMgbm90IG91dHNpZGUgb2YgdGhlCisJICogQkFXLiAgQ29tcGxhaW4gbG91ZGx5 IGlmIHRoYXQncyB0aGUgY2FzZS4KKwkgKi8KKwlpZiAoISBCQVdfV0lUSElOKHRhcC0+dHhhX3N0 YXJ0LCB0YXAtPnR4YV93bmQsCisJICAgIFNFUU5PKGJmLT5iZl9zdGF0ZS5iZnNfc2Vxbm8pKSkg eworCQlkZXZpY2VfcHJpbnRmKHNjLT5zY19kZXYsCisJCSAgICAiJXM6IGJmPSVwOiBvdXRzaWRl IG9mIEJBVz8/IHRpZD0lZCwgc2Vxbm8gJWQ7IHdpbmRvdyAlZDolZDsgIgorCQkgICAgImJhdyBo ZWFkPSVkIHRhaWw9JWRcbiIsCisJCSAgICBfX2Z1bmNfXywgYmYsIHRpZC0+dGlkLCBTRVFOTyhi Zi0+YmZfc3RhdGUuYmZzX3NlcW5vKSwKKwkJICAgIHRhcC0+dHhhX3N0YXJ0LCB0YXAtPnR4YV93 bmQsIHRpZC0+YmF3X2hlYWQsCisJCSAgICB0aWQtPmJhd190YWlsKTsKKworCX0KKworCS8qCiAJ ICogbmktPm5pX3R4c2Vxc1tdIGlzIHRoZSBjdXJyZW50bHkgYWxsb2NhdGVkIHNlcW5vLgogCSAq IHRoZSB0eGEgc3RhdGUgY29udGFpbnMgdGhlIGN1cnJlbnQgYmF3IHN0YXJ0LgogCSAqLwogCWlu ZGV4ICA9IEFUSF9CQV9JTkRFWCh0YXAtPnR4YV9zdGFydCwgU0VRTk8oYmYtPmJmX3N0YXRlLmJm c19zZXFubykpOwogCWNpbmRleCA9ICh0aWQtPmJhd19oZWFkICsgaW5kZXgpICYgKEFUSF9USURf TUFYX0JVRlMgLSAxKTsKIAlEUFJJTlRGKHNjLCBBVEhfREVCVUdfU1dfVFhfQkFXLAotCSAgICAi JXM6IHRpZD0lZCwgc2Vxbm8gJWQ7IHdpbmRvdyAlZDolZDsgaW5kZXg9JWQgY2luZGV4PSVkICIK KwkgICAgIiVzOiBiZj0lcCwgdGlkPSVkLCBzZXFubyAlZDsgd2luZG93ICVkOiVkOyBpbmRleD0l ZCBjaW5kZXg9JWQgIgogCSAgICAiYmF3IGhlYWQ9JWQgdGFpbD0lZFxuIiwKLQkgICAgX19mdW5j X18sIHRpZC0+dGlkLCBTRVFOTyhiZi0+YmZfc3RhdGUuYmZzX3NlcW5vKSwKKwkgICAgX19mdW5j X18sIGJmLCB0aWQtPnRpZCwgU0VRTk8oYmYtPmJmX3N0YXRlLmJmc19zZXFubyksCiAJICAgIHRh cC0+dHhhX3N0YXJ0LCB0YXAtPnR4YV93bmQsIGluZGV4LCBjaW5kZXgsIHRpZC0+YmF3X2hlYWQs CiAJICAgIHRpZC0+YmF3X3RhaWwpOwogCkBAIC0yMDg4LDkgKzIxMzEsOSBAQAogCWNpbmRleCA9 ICh0aWQtPmJhd19oZWFkICsgaW5kZXgpICYgKEFUSF9USURfTUFYX0JVRlMgLSAxKTsKIAogCURQ UklOVEYoc2MsIEFUSF9ERUJVR19TV19UWF9CQVcsCi0JICAgICIlczogdGlkPSVkLCBiYXc9JWQ6 JWQsIHNlcW5vPSVkLCBpbmRleD0lZCwgY2luZGV4PSVkLCAiCisJICAgICIlczogYmY9JXA6IHRp ZD0lZCwgYmF3PSVkOiVkLCBzZXFubz0lZCwgaW5kZXg9JWQsIGNpbmRleD0lZCwgIgogCSAgICAi YmF3IGhlYWQ9JWQsIHRhaWw9JWRcbiIsCi0JICAgIF9fZnVuY19fLCB0aWQtPnRpZCwgdGFwLT50 eGFfc3RhcnQsIHRhcC0+dHhhX3duZCwgc2Vxbm8sIGluZGV4LAorCSAgICBfX2Z1bmNfXywgYmYs IHRpZC0+dGlkLCB0YXAtPnR4YV9zdGFydCwgdGFwLT50eGFfd25kLCBzZXFubywgaW5kZXgsCiAJ ICAgIGNpbmRleCwgdGlkLT5iYXdfaGVhZCwgdGlkLT5iYXdfdGFpbCk7CiAKIAkvKgpAQCAtMjE3 MSwxMSArMjIxNCw0MiBAQAogfQogCiAvKgorICogUmV0dXJuIHdoZXRoZXIgYSBzZXF1ZW5jZSBu dW1iZXIgaXMgYWN0dWFsbHkgcmVxdWlyZWQuCisgKgorICogQSBzZXF1ZW5jZSBudW1iZXIgbXVz dCBvbmx5IGJlIGFsbG9jYXRlZCBhdCB0aGUgdGltZSB0aGF0IGEgZnJhbWUKKyAqIGlzIGNvbnNp ZGVyZWQgZm9yIGFkZGl0aW9uIHRvIHRoZSBCQVcvYWdncmVnYXRlIGFuZCBiZWluZyBUWGVkLgor ICogVGhlIHNlcXVlbmNlIG51bWJlciBtdXN0IG5vdCBiZSBhbGxvY2F0ZWQgYmVmb3JlIHRoZSBm cmFtZQorICogaXMgYWRkZWQgdG8gdGhlIEJBVyAocHJvdGVjdGVkIGJ5IHRoZSBzYW1lIGxvY2sg aW5zdGFuY2UpCisgKiBvdGhlcndpc2UgYSB0aGUgbXVsdGktZW50cmFudCBUWCBwYXRoIG1heSBy ZXN1bHQgaW4gYSBsYXRlciBzZXFubworICogYmVpbmcgYWRkZWQgdG8gdGhlIEJBVyBmaXJzdC4g IFRoZSBzdWJzZXF1ZW50IGFkZGl0aW9uIG9mIHRoZQorICogZWFybGllciBzZXFubyB3b3VsZCB0 aGVuIG5vdCBnbyBpbnRvIHRoZSBCQVcgYXMgaXQncyBub3cgb3V0c2lkZQorICogb2Ygc2FpZCBC QVcuCisgKgorICogVGhpcyByb3V0aW5lIGlzIHVzZWQgYnkgYXRoX3R4X3N0YXJ0KCkgdG8gbWFy ayB3aGV0aGVyIHRoZSBmcmFtZQorICogc2hvdWxkIGdldCBhIHNlcXVlbmNlIG51bWJlciBiZWZv cmUgYWRkaW5nIGl0IHRvIHRoZSBCQVcuCisgKgorICogVGhlbiB0aGUgYWN0dWFsIGFnZ3JlZ2F0 ZSBUWCByb3V0aW5lcyB3aWxsIGNoZWNrIHdoZXRoZXIgdGhpcworICogZmxhZyBpcyBzZXQgYW5k IGlmIHRoZSBmcmFtZSBuZWVkcyB0byBnbyBpbnRvIHRoZSBCQVcsIGl0J2xsCisgKiBoYXZlIGEg c2VxdWVuY2UgbnVtYmVyIGFsbG9jYXRlZCBmb3IgaXQuCisgKi8KKyNpZiAwCitzdGF0aWMgaW50 CithdGhfdHhfc2Vxbm9fcmVxdWlyZWQoc3RydWN0IGF0aF9zb2Z0YyAqc2MsIHN0cnVjdCBpZWVl ODAyMTFfbm9kZSAqbmksCisgICAgc3RydWN0IGF0aF9idWYgKmJmLCBzdHJ1Y3QgbWJ1ZiAqbTAp Cit7Cit9CisjZW5kaWYKKworLyoKICAqIEFzc2lnbiBhIHNlcXVlbmNlIG51bWJlciBtYW51YWxs eSB0byB0aGUgZ2l2ZW4gZnJhbWUuCiAgKgogICogVGhpcyBzaG91bGQgb25seSBiZSBjYWxsZWQg Zm9yIEEtTVBEVSBUWCBmcmFtZXMuCisgKgorICogSWYgdGhpcyBpcyBjYWxsZWQgYWZ0ZXIgdGhl IGluaXRpYWwgZnJhbWUgc2V0dXAsIG1ha2Ugc3VyZSB5b3UndmUgZmx1c2hlZAorICogdGhlIERN QSBtYXAgb3IgeW91J2xsIHJpc2sgc2VuZGluZyBzdGFsZSBkYXRhIHRvIHRoZSBOSUMuICBUaGlz IHJvdXRpbmUKKyAqIHVwZGF0ZXMgdGhlIGFjdHVhbCBmcmFtZSBjb250ZW50cyB3aXRoIHRoZSBy ZWxldmFudCBzZXFuby4KICAqLwotc3RhdGljIGllZWU4MDIxMV9zZXEKK2ludAogYXRoX3R4X3Rp ZF9zZXFub19hc3NpZ24oc3RydWN0IGF0aF9zb2Z0YyAqc2MsIHN0cnVjdCBpZWVlODAyMTFfbm9k ZSAqbmksCiAgICAgc3RydWN0IGF0aF9idWYgKmJmLCBzdHJ1Y3QgbWJ1ZiAqbTApCiB7CkBAIC0y MTg4LDkgKzIyNjIsMjMgQEAKIAl3aCA9IG10b2QobTAsIHN0cnVjdCBpZWVlODAyMTFfZnJhbWUg Kik7CiAJcHJpID0gTV9XTUVfR0VUQUMobTApOwkJCS8qIGhvbm9yIGNsYXNzaWZpY2F0aW9uICov CiAJdGlkID0gV01FX0FDX1RPX1RJRChwcmkpOwotCURQUklOVEYoc2MsIEFUSF9ERUJVR19TV19U WCwgIiVzOiBwcmk9JWQsIHRpZD0lZCwgcW9zIGhhcyBzZXE9JWRcbiIsCi0JICAgIF9fZnVuY19f LCBwcmksIHRpZCwgSUVFRTgwMjExX1FPU19IQVNfU0VRKHdoKSk7CisJRFBSSU5URihzYywgQVRI X0RFQlVHX1NXX1RYLAorCSAgICAiJXM6IGJmPSVwLCBwcmk9JWQsIHRpZD0lZCwgcW9zIGhhcyBz ZXE9JWRcbiIsCisJICAgIF9fZnVuY19fLCBiZiwgcHJpLCB0aWQsIElFRUU4MDIxMV9RT1NfSEFT X1NFUSh3aCkpOwogCisJaWYgKCEgYmYtPmJmX3N0YXRlLmJmc19uZWVkX3NlcW5vKSB7CisJCWRl dmljZV9wcmludGYoc2MtPnNjX2RldiwgIiVzOiBiZj0lcDogbmVlZF9zZXFubyBub3Qgc2V0PyFc biIsCisJCSAgICBfX2Z1bmNfXywgYmYpOworCQlyZXR1cm4gLTE7CisJfQorCS8qIFhYWCBjaGVj ayBmb3IgYmZzX25lZWRfc2Vxbm8/ICovCisJaWYgKGJmLT5iZl9zdGF0ZS5iZnNfc2Vxbm9fYXNz aWduZWQpIHsKKwkJZGV2aWNlX3ByaW50ZihzYy0+c2NfZGV2LAorCQkgICAgIiVzOiBiZj0lcDog c2Vxbm8gYWxyZWFkeSBhc3NpZ25lZCAoJWQpPyFcbiIsCisJCSAgICBfX2Z1bmNfXywgYmYsIFNF UU5PKGJmLT5iZl9zdGF0ZS5iZnNfc2Vxbm8pKTsKKwkJcmV0dXJuIGJmLT5iZl9zdGF0ZS5iZnNf c2Vxbm8gPj4gSUVFRTgwMjExX1NFUV9TRVFfU0hJRlQ7CisJfQorCiAJLyogWFhYIElzIGl0IGEg Y29udHJvbCBmcmFtZT8gSWdub3JlICovCiAKIAkvKiBEb2VzIHRoZSBwYWNrZXQgcmVxdWlyZSBh IHNlcXVlbmNlIG51bWJlcj8gKi8KQEAgLTIyMTcsOSArMjMwNSwxNCBAQAogCX0KIAkqKHVpbnQx Nl90ICopJndoLT5pX3NlcVswXSA9IGh0b2xlMTYoc2Vxbm8gPDwgSUVFRTgwMjExX1NFUV9TRVFf U0hJRlQpOwogCU1fU0VRTk9fU0VUKG0wLCBzZXFubyk7CisJYmYtPmJmX3N0YXRlLmJmc19zZXFu byA9IHNlcW5vIDw8IElFRUU4MDIxMV9TRVFfU0VRX1NISUZUOworCWJmLT5iZl9zdGF0ZS5iZnNf c2Vxbm9fYXNzaWduZWQgPSAxOwogCiAJLyogUmV0dXJuIHNvIGNhbGxlciBjYW4gZG8gc29tZXRo aW5nIHdpdGggaXQgaWYgbmVlZGVkICovCi0JRFBSSU5URihzYywgQVRIX0RFQlVHX1NXX1RYLCAi JXM6ICAtPiBzZXFubz0lZFxuIiwgX19mdW5jX18sIHNlcW5vKTsKKwlEUFJJTlRGKHNjLCBBVEhf REVCVUdfU1dfVFgsICIlczogYmY9JXA6ICAtPiBzZXFubz0lZFxuIiwKKwkgICAgX19mdW5jX18s CisJICAgIGJmLAorCSAgICBzZXFubyk7CiAJcmV0dXJuIHNlcW5vOwogfQogCkBAIC0yMjMxLDkg KzIzMjQsMTEgQEAKIHN0YXRpYyB2b2lkCiBhdGhfdHhfeG1pdF9hZ2dyKHN0cnVjdCBhdGhfc29m dGMgKnNjLCBzdHJ1Y3QgYXRoX25vZGUgKmFuLCBzdHJ1Y3QgYXRoX2J1ZiAqYmYpCiB7CisJc3Ry dWN0IGllZWU4MDIxMV9ub2RlICpuaSA9ICZhbi0+YW5fbm9kZTsKIAlzdHJ1Y3QgYXRoX3RpZCAq dGlkID0gJmFuLT5hbl90aWRbYmYtPmJmX3N0YXRlLmJmc190aWRdOwogCXN0cnVjdCBhdGhfdHhx ICp0eHEgPSBiZi0+YmZfc3RhdGUuYmZzX3R4cTsKIAlzdHJ1Y3QgaWVlZTgwMjExX3R4X2FtcGR1 ICp0YXA7CisJaW50IHNlcW5vOwogCiAJQVRIX1RYUV9MT0NLX0FTU0VSVCh0eHEpOwogCkBAIC0y MjQ1LDEwICsyMzQwLDYzIEBACiAJCXJldHVybjsKIAl9CiAKKwkvKgorCSAqIFRPRE86IElmIGl0 J3MgX2JlZm9yZV8gdGhlIEJBVyBsZWZ0IGVkZ2UsIGNvbXBsYWluIHZlcnkgbG91ZGx5LgorCSAq IFRoaXMgbWVhbnMgc29tZXRoaW5nIChlbHNlKSBoYXMgc2xpZCB0aGUgbGVmdCBlZGdlIGFsb25n CisJICogYmVmb3JlIHdlIGdvdCBhIGNoYW5jZSB0byBiZSBUWGVkLgorCSAqLworCisJLyoKKwkg KiBJcyB0aGVyZSBzcGFjZSBpbiB0aGlzIEJBVyBmb3IgYW5vdGhlciBmcmFtZT8KKwkgKiBJZiBu b3QsIGRvbid0IGJvdGhlciB0cnlpbmcgdG8gc2NoZWR1bGUgaXQ7IGp1c3QKKwkgKiB0aHJvdyBp dCBiYWNrIG9uIHRoZSBxdWV1ZS4KKwkgKgorCSAqIElmIHdlIGFsbG9jYXRlIHRoZSBzZXF1ZW5j ZSBudW1iZXIgYmVmb3JlIHdlIGFkZAorCSAqIGl0IHRvIHRoZSBCQVcsIHdlIHJpc2sgcmFjaW5n IHdpdGggYW5vdGhlciBUWAorCSAqIHRocmVhZCB0aGF0IGdldHMgaW4gYSBmcmFtZSBpbnRvIHRo ZSBCQVcgd2l0aAorCSAqIHNlcW5vIGdyZWF0ZXIgdGhhbiBvdXJzLiAgV2UnZCB0aGVuIGZhaWwg dGhlCisJICogYmVsb3cgY2hlY2sgYW5kIHRocm93IHRoZSBmcmFtZSBvbiB0aGUgdGFpbCBvZgor CSAqIHRoZSBxdWV1ZS4gIFRoZSBzZW5kZXIgd291bGQgdGhlbiBoYXZlIGEgaG9sZS4KKwkgKgor CSAqIFhYWCBhZ2Fpbiwgd2UncmUgcHJvdGVjdGluZyBuaS0+bmlfdHhzZXFzW3RpZF0KKwkgKiBi ZWhpbmQgdGhpcyBoYXJkd2FyZSBUWFEgbG9jaywgbGlrZSB0aGUgcmVzdCBvZgorCSAqIHRoZSBU SURzIHRoYXQgbWFwIHRvIGl0LiAgVWdoLgorCSAqLworCWlmIChiZi0+YmZfc3RhdGUuYmZzX2Rv YmF3KSB7CisJCWlmICghIEJBV19XSVRISU4odGFwLT50eGFfc3RhcnQsIHRhcC0+dHhhX3duZCwK KwkJICAgIG5pLT5uaV90eHNlcXNbYmYtPmJmX3N0YXRlLmJmc190aWRdKSkgeworCQkJQVRIX1RY UV9JTlNFUlRfVEFJTCh0aWQsIGJmLCBiZl9saXN0KTsKKwkJCWF0aF90eF90aWRfc2NoZWQoc2Ms IHRpZCk7CisJCQlyZXR1cm47CisJCX0KKwkJaWYgKCEgYmYtPmJmX3N0YXRlLmJmc19zZXFub19h c3NpZ25lZCkgeworCQkJc2Vxbm8gPSBhdGhfdHhfdGlkX3NlcW5vX2Fzc2lnbihzYywgbmksIGJm LCBiZi0+YmZfbSk7CisJCQlpZiAoc2Vxbm8gPCAwKSB7CisJCQkJZGV2aWNlX3ByaW50ZihzYy0+ c2NfZGV2LAorCQkJCSAgICAiJXM6IGJmPSVwLCBodWgsIHNlcW5vPS0xP1xuIiwKKwkJCQkgICAg X19mdW5jX18sCisJCQkJICAgIGJmKTsKKwkJCQkvKiBYWFggd2hhdCBjYW4gd2UgZXZlbiBkbyBo ZXJlPyAqLworCQkJfQorCQkJLyogRmx1c2ggc2Vxbm8gdXBkYXRlIHRvIFJBTSAqLworCQkJLyoK KwkJCSAqIFhYWCBUaGlzIGlzIHJlcXVpcmVkIGJlY2F1c2UgdGhlIGRtYXNldHVwCisJCQkgKiBY WFggaXMgZG9uZSBlYXJseSByYXRoZXIgdGhhbiBhdCBkaXNwYXRjaAorCQkJICogWFhYIHRpbWUu IEV3LCB3ZSBzaG91bGQgZml4IHRoaXMhCisJCQkgKi8KKwkJCWJ1c19kbWFtYXBfc3luYyhzYy0+ c2NfZG1hdCwgYmYtPmJmX2RtYW1hcCwKKwkJCSAgICBCVVNfRE1BU1lOQ19QUkVXUklURSk7CisJ CX0KKwl9CisKIAkvKiBvdXRzaWRlIGJhdz8gcXVldWUgKi8KIAlpZiAoYmYtPmJmX3N0YXRlLmJm c19kb2JhdyAmJgogCSAgICAoISBCQVdfV0lUSElOKHRhcC0+dHhhX3N0YXJ0LCB0YXAtPnR4YV93 bmQsCiAJICAgIFNFUU5PKGJmLT5iZl9zdGF0ZS5iZnNfc2Vxbm8pKSkpIHsKKwkJZGV2aWNlX3By aW50ZihzYy0+c2NfZGV2LAorCQkgICAgIiVzOiBiZj0lcCwgc2hvdWxkbid0IGJlIG91dHNpZGUg QkFXIG5vdz8hXG4iLAorCQkgICAgX19mdW5jX18sCisJCSAgICBiZik7CiAJCUFUSF9UWFFfSU5T RVJUX1RBSUwodGlkLCBiZiwgYmZfbGlzdCk7CiAJCWF0aF90eF90aWRfc2NoZWQoc2MsIHRpZCk7 CiAJCXJldHVybjsKQEAgLTIzMDMsOCArMjQ1MSw4IEBACiAJdGlkID0gYXRoX3R4X2dldHRpZChz YywgbTApOwogCWF0aWQgPSAmYW4tPmFuX3RpZFt0aWRdOwogCi0JRFBSSU5URihzYywgQVRIX0RF QlVHX1NXX1RYLCAiJXM6IGJmPSVwLCBwcmk9JWQsIHRpZD0lZCwgcW9zPSVkXG4iLAotCSAgICBf X2Z1bmNfXywgYmYsIHByaSwgdGlkLCBJRUVFODAyMTFfUU9TX0hBU19TRVEod2gpKTsKKwlEUFJJ TlRGKHNjLCBBVEhfREVCVUdfU1dfVFgsICIlczogYmY9JXAsIHByaT0lZCwgdGlkPSVkLCBxb3M9 JWQsIHNlcW5vPSVkXG4iLAorCSAgICBfX2Z1bmNfXywgYmYsIHByaSwgdGlkLCBJRUVFODAyMTFf UU9TX0hBU19TRVEod2gpLCBTRVFOTyhiZi0+YmZfc3RhdGUuYmZzX3NlcW5vKSk7CiAKIAkvKiBT ZXQgbG9jYWwgcGFja2V0IHN0YXRlLCB1c2VkIHRvIHF1ZXVlIHBhY2tldHMgdG8gaGFyZHdhcmUg Ki8KIAliZi0+YmZfc3RhdGUuYmZzX3RpZCA9IHRpZDsKQEAgLTIzMjAsMzQgKzI0NjgsMzQgQEAK IAlBVEhfVFhRX0xPQ0sodHhxKTsKIAlpZiAoYXRpZC0+cGF1c2VkKSB7CiAJCS8qIFRJRCBpcyBw YXVzZWQsIHF1ZXVlICovCi0JCURQUklOVEYoc2MsIEFUSF9ERUJVR19TV19UWCwgIiVzOiBwYXVz ZWRcbiIsIF9fZnVuY19fKTsKKwkJRFBSSU5URihzYywgQVRIX0RFQlVHX1NXX1RYLCAiJXM6IGJm PSVwOiBwYXVzZWRcbiIsIF9fZnVuY19fLCBiZik7CiAJCUFUSF9UWFFfSU5TRVJUX1RBSUwoYXRp ZCwgYmYsIGJmX2xpc3QpOwogCX0gZWxzZSBpZiAoYXRoX3R4X2FtcGR1X3BlbmRpbmcoc2MsIGFu LCB0aWQpKSB7CiAJCS8qIEFNUERVIHBlbmRpbmc7IHF1ZXVlICovCi0JCURQUklOVEYoc2MsIEFU SF9ERUJVR19TV19UWCwgIiVzOiBwZW5kaW5nXG4iLCBfX2Z1bmNfXyk7CisJCURQUklOVEYoc2Ms IEFUSF9ERUJVR19TV19UWCwgIiVzOiBiZj0lcDogcGVuZGluZ1xuIiwgX19mdW5jX18sIGJmKTsK IAkJQVRIX1RYUV9JTlNFUlRfVEFJTChhdGlkLCBiZiwgYmZfbGlzdCk7CiAJCS8qIFhYWCBzY2hl ZD8gKi8KIAl9IGVsc2UgaWYgKGF0aF90eF9hbXBkdV9ydW5uaW5nKHNjLCBhbiwgdGlkKSkgewog CQkvKiBBTVBEVSBydW5uaW5nLCBhdHRlbXB0IGRpcmVjdCBkaXNwYXRjaCBpZiBwb3NzaWJsZSAq LwogCQlpZiAodHhxLT5heHFfZGVwdGggPCBzYy0+c2NfaHdxX2xpbWl0KSB7CisJCQlEUFJJTlRG KHNjLCBBVEhfREVCVUdfU1dfVFgsCisJCQkgICAgIiVzOiBiZj0lcDogeG1pdF9hZ2dyXG4iLAor CQkJICAgIF9fZnVuY19fLCBiZik7CiAJCQlhdGhfdHhfeG1pdF9hZ2dyKHNjLCBhbiwgYmYpOwot CQkJRFBSSU5URihzYywgQVRIX0RFQlVHX1NXX1RYLAotCQkJICAgICIlczogeG1pdF9hZ2dyXG4i LAotCQkJICAgIF9fZnVuY19fKTsKIAkJfSBlbHNlIHsKIAkJCURQUklOVEYoc2MsIEFUSF9ERUJV R19TV19UWCwKLQkJCSAgICAiJXM6IGFtcGR1OyBzd3EnaW5nXG4iLAotCQkJICAgIF9fZnVuY19f KTsKKwkJCSAgICAiJXM6IGJmPSVwOiBhbXBkdTsgc3dxJ2luZ1xuIiwKKwkJCSAgICBfX2Z1bmNf XywgYmYpOwogCQkJQVRIX1RYUV9JTlNFUlRfVEFJTChhdGlkLCBiZiwgYmZfbGlzdCk7CiAJCQlh dGhfdHhfdGlkX3NjaGVkKHNjLCBhdGlkKTsKIAkJfQogCX0gZWxzZSBpZiAodHhxLT5heHFfZGVw dGggPCBzYy0+c2NfaHdxX2xpbWl0KSB7CiAJCS8qIEFNUERVIG5vdCBydW5uaW5nLCBhdHRlbXB0 IGRpcmVjdCBkaXNwYXRjaCAqLwotCQlEUFJJTlRGKHNjLCBBVEhfREVCVUdfU1dfVFgsICIlczog eG1pdF9ub3JtYWxcbiIsIF9fZnVuY19fKTsKKwkJRFBSSU5URihzYywgQVRIX0RFQlVHX1NXX1RY LCAiJXM6IGJmPSVwOiB4bWl0X25vcm1hbFxuIiwgX19mdW5jX18sIGJmKTsKIAkJYXRoX3R4X3ht aXRfbm9ybWFsKHNjLCB0eHEsIGJmKTsKIAl9IGVsc2UgewogCQkvKiBCdXN5OyBxdWV1ZSAqLwot CQlEUFJJTlRGKHNjLCBBVEhfREVCVUdfU1dfVFgsICIlczogc3dxJ2luZ1xuIiwgX19mdW5jX18p OworCQlEUFJJTlRGKHNjLCBBVEhfREVCVUdfU1dfVFgsICIlczogYmY9JXA6IHN3cSdpbmdcbiIs IF9fZnVuY19fLCBiZik7CiAJCUFUSF9UWFFfSU5TRVJUX1RBSUwoYXRpZCwgYmYsIGJmX2xpc3Qp OwogCQlhdGhfdHhfdGlkX3NjaGVkKHNjLCBhdGlkKTsKIAl9CkBAIC0yNDc4LDExICsyNjI2LDEx IEBACiAKIAkJaWYgKHQgPT0gMCkgewogCQkJZGV2aWNlX3ByaW50ZihzYy0+c2NfZGV2LAotCQkJ ICAgICIlczogbm9kZSAlcDogdGlkICVkOiB0eHFfZGVwdGg9JWQsICIKKwkJCSAgICAiJXM6IG5v ZGUgJXA6IGJmPSVwOiB0aWQgJWQ6IHR4cV9kZXB0aD0lZCwgIgogCQkJICAgICJ0eHFfYWdncl9k ZXB0aD0lZCwgc2NoZWQ9JWQsIHBhdXNlZD0lZCwgIgogCQkJICAgICJod3FfZGVwdGg9JWQsIGlu Y29tcD0lZCwgYmF3X2hlYWQ9JWQsICIKIAkJCSAgICAiYmF3X3RhaWw9JWQgdHhhX3N0YXJ0PSVk LCBuaV90eHNlcXM9JWRcbiIsCi0JCQkgICAgIF9fZnVuY19fLCBuaSwgdGlkLT50aWQsIHR4cS0+ YXhxX2RlcHRoLAorCQkJICAgICBfX2Z1bmNfXywgbmksIGJmLCB0aWQtPnRpZCwgdHhxLT5heHFf ZGVwdGgsCiAJCQkgICAgIHR4cS0+YXhxX2FnZ3JfZGVwdGgsIHRpZC0+c2NoZWQsIHRpZC0+cGF1 c2VkLAogCQkJICAgICB0aWQtPmh3cV9kZXB0aCwgdGlkLT5pbmNvbXAsIHRpZC0+YmF3X2hlYWQs CiAJCQkgICAgIHRpZC0+YmF3X3RhaWwsIHRhcCA9PSBOVUxMID8gLTEgOiB0YXAtPnR4YV9zdGFy dCwKQEAgLTI0OTMsNyArMjY0MSw3IEBACiAJCQkgICAgbXRvZChiZi0+YmZfbSwgY29uc3QgdWlu dDhfdCAqKSwKIAkJCSAgICBiZi0+YmZfbS0+bV9sZW4sIDAsIC0xKTsKIAotCQkJdCA9IDE7CisJ CQkvL3QgPSAxOwogCQl9CiAKIApJbmRleDogc3lzL2Rldi9hdGgvaWZfYXRoX3R4LmgKPT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PQotLS0gc3lzL2Rldi9hdGgvaWZfYXRoX3R4LmgJKHJldmlzaW9uIDIzMzA4OSkKKysrIHN5 cy9kZXYvYXRoL2lmX2F0aF90eC5oCSh3b3JraW5nIGNvcHkpCkBAIC0xMDksNiArMTA5LDggQEAK ICAgICBzdHJ1Y3QgYXRoX3RpZCAqdGlkLCBzdHJ1Y3QgYXRoX2J1ZiAqYmYpOwogZXh0ZXJuIHN0 cnVjdCBpZWVlODAyMTFfdHhfYW1wZHUgKiBhdGhfdHhfZ2V0X3R4X3RpZChzdHJ1Y3QgYXRoX25v ZGUgKmFuLAogICAgIGludCB0aWQpOworZXh0ZXJuIGludCBhdGhfdHhfdGlkX3NlcW5vX2Fzc2ln bihzdHJ1Y3QgYXRoX3NvZnRjICpzYywKKyAgICBzdHJ1Y3QgaWVlZTgwMjExX25vZGUgKm5pLCBz dHJ1Y3QgYXRoX2J1ZiAqYmYsIHN0cnVjdCBtYnVmICptMCk7CiAKIC8qIFRYIGFkZGJhIGhhbmRs aW5nICovCiBleHRlcm4JaW50IGF0aF9hZGRiYV9yZXF1ZXN0KHN0cnVjdCBpZWVlODAyMTFfbm9k ZSAqbmksCg== --047d7b33c9fe4e3ed604bb91d101-- From owner-freebsd-wireless@FreeBSD.ORG Mon Mar 19 05:30:19 2012 Return-Path: Delivered-To: freebsd-wireless@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1D679106564A for ; Mon, 19 Mar 2012 05:30:19 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 08E6A8FC0A for ; Mon, 19 Mar 2012 05:30:19 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q2J5UITP085931 for ; Mon, 19 Mar 2012 05:30:19 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q2J5UI0x085928; Mon, 19 Mar 2012 05:30:18 GMT (envelope-from gnats) Date: Mon, 19 Mar 2012 05:30:18 GMT Message-Id: <201203190530.q2J5UI0x085928@freefall.freebsd.org> To: freebsd-wireless@FreeBSD.org From: Adrian Chadd Cc: Subject: Re: kern/166190: [ath] TX hangs and frames stuck in TX queue X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.5 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, 19 Mar 2012 05:30:19 -0000 The following reply was made to PR kern/166190; it has been noted by GNATS. From: Adrian Chadd To: bug-followup@freebsd.org, Vincent Hoffman Cc: freebsd-wireless@freebsd.org Subject: Re: kern/166190: [ath] TX hangs and frames stuck in TX queue Date: Sun, 18 Mar 2012 22:27:43 -0700 --047d7b33c9fe4e3ed604bb91d101 Content-Type: text/plain; charset=ISO-8859-1 Hi Vincent, Please try this patch and let me know how it behaves. Thanks, Adrian --047d7b33c9fe4e3ed604bb91d101 Content-Type: text/x-patch; charset=US-ASCII; name="kern-166190-baw.diff" Content-Disposition: attachment; filename="kern-166190-baw.diff" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gzz2qutw0 SW5kZXg6IHN5cy9kZXYvYXRoL2lmX2F0aF9kZWJ1Zy5jCj09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIHN5cy9kZXYv YXRoL2lmX2F0aF9kZWJ1Zy5jCShyZXZpc2lvbiAyMzMwODkpCisrKyBzeXMvZGV2L2F0aC9pZl9h dGhfZGVidWcuYwkod29ya2luZyBjb3B5KQpAQCAtMTM1LDE5ICsxMzUsMjMgQEAKIAlwcmludGYo IlEldVslM3VdIiwgcW51bSwgaXgpOwogCXdoaWxlIChiZiAhPSBOVUxMKSB7CiAJCWZvciAoaSA9 IDAsIGRzID0gYmYtPmJmX2Rlc2M7IGkgPCBiZi0+YmZfbnNlZzsgaSsrLCBkcysrKSB7Ci0JCQlw cmludGYoIiAoRFMuVjolcCBEUy5QOiVwKSBMOiUwOHggRDolMDh4IEY6JTA0eCVzXG4iCi0JCQkg ICAgICAgIiAgICAgICAgVFhGOiAlMDR4IFNlcTogJWQgc3d0cnk6ICVkIEFEREJBVz86ICVkIERP QkFXPzogJWRcbiIKLQkJCSAgICAgICAiICAgICAgICAlMDh4ICUwOHggJTA4eCAlMDh4ICUwOHgg JTA4eFxuIiwKKwkJCXByaW50ZigiIChEUy5WOiVwIERTLlA6JXApIEw6JTA4eCBEOiUwOHggRjol MDR4JXNcbiIsCiAJCQkgICAgZHMsIChjb25zdCBzdHJ1Y3QgYXRoX2Rlc2MgKiliZi0+YmZfZGFk ZHIgKyBpLAogCQkJICAgIGRzLT5kc19saW5rLCBkcy0+ZHNfZGF0YSwgYmYtPmJmX3R4ZmxhZ3Ms Ci0JCQkgICAgIWRvbmUgPyAiIiA6ICh0cy0+dHNfc3RhdHVzID09IDApID8gIiAqIiA6ICIgISIs CisJCQkgICAgIWRvbmUgPyAiIiA6ICh0cy0+dHNfc3RhdHVzID09IDApID8gIiAqIiA6ICIgISIp OworCQkJcHJpbnRmKCIgICAgICAgIFRYRjogJTA0eCBTZXE6ICVkIHN3dHJ5OiAlZCBBRERCQVc/ OiAlZCBET0JBVz86ICVkXG4iLAogCQkJICAgIGJmLT5iZl9zdGF0ZS5iZnNfZmxhZ3MsCiAJCQkg ICAgYmYtPmJmX3N0YXRlLmJmc19zZXFubywKIAkJCSAgICBiZi0+YmZfc3RhdGUuYmZzX3JldHJp ZXMsCiAJCQkgICAgYmYtPmJmX3N0YXRlLmJmc19hZGRlZGJhdywKLQkJCSAgICBiZi0+YmZfc3Rh dGUuYmZzX2RvYmF3LAorCQkJICAgIGJmLT5iZl9zdGF0ZS5iZnNfZG9iYXcpOworCQkJcHJpbnRm KCIgICAgICAgIFNFUU5PX0FTU0lHTkVEOiAlZCwgTkVFRF9TRVFOTzogJWRcbiIsCisJCQkgICAg YmYtPmJmX3N0YXRlLmJmc19zZXFub19hc3NpZ25lZCwKKwkJCSAgICBiZi0+YmZfc3RhdGUuYmZz X25lZWRfc2Vxbm8pOworCQkJcHJpbnRmKCIgICAgICAgICUwOHggJTA4eCAlMDh4ICUwOHggJTA4 eCAlMDh4XG4iLAogCQkJICAgIGRzLT5kc19jdGwwLCBkcy0+ZHNfY3RsMSwKLQkJCSAgICBkcy0+ ZHNfaHdbMF0sIGRzLT5kc19od1sxXSwgZHMtPmRzX2h3WzJdLCBkcy0+ZHNfaHdbM10pOworCQkJ ICAgIGRzLT5kc19od1swXSwgZHMtPmRzX2h3WzFdLAorCQkJICAgIGRzLT5kc19od1syXSwgZHMt PmRzX2h3WzNdKTsKIAkJCWlmIChhaC0+YWhfbWFnaWMgPT0gMHgyMDA2NTQxNikgewogCQkJCXBy aW50ZigiICAgICAgICAlMDh4ICUwOHggJTA4eCAlMDh4ICUwOHggJTA4eCAlMDh4ICUwOHhcbiIs CiAJCQkJICAgIGRzLT5kc19od1s0XSwgZHMtPmRzX2h3WzVdLCBkcy0+ZHNfaHdbNl0sCkluZGV4 OiBzeXMvZGV2L2F0aC9pZl9hdGh2YXIuaAo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBzeXMvZGV2L2F0aC9pZl9h dGh2YXIuaAkocmV2aXNpb24gMjMzMDg5KQorKysgc3lzL2Rldi9hdGgvaWZfYXRodmFyLmgJKHdv cmtpbmcgY29weSkKQEAgLTIxNSw2ICsyMTUsOCBAQAogCQlpbnQgYmZzX2lzbXJyOjE7CS8qIGRv IG11bHRpLXJhdGUgVFggcmV0cnkgKi8KIAkJaW50IGJmc19kb3Byb3Q6MTsJLyogZG8gUlRTL0NU UyBiYXNlZCBwcm90ZWN0aW9uICovCiAJCWludCBiZnNfZG9yYXRlbG9va3VwOjE7CS8qIGRvIHJh dGUgbG9va3VwIGJlZm9yZSBlYWNoIFRYICovCisJCWludCBiZnNfbmVlZF9zZXFubzoxOwkvKiBu ZWVkIHRvIGFzc2lnbiBhIHNlcW5vIGZvciBhZ2dyZWdhdGlvbiAqLworCQlpbnQgYmZzX3NlcW5v X2Fzc2lnbmVkOjE7CS8qIHNlcW5vIGhhcyBiZWVuIGFzc2lnbmVkICovCiAJCWludCBiZnNfbmZs OwkJLyogbmV4dCBmcmFnbWVudCBsZW5ndGggKi8KIAogCQkvKgpJbmRleDogc3lzL2Rldi9hdGgv aWZfYXRoX3R4X2h0LmMKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gc3lzL2Rldi9hdGgvaWZfYXRoX3R4X2h0LmMJ KHJldmlzaW9uIDIzMzA4OSkKKysrIHN5cy9kZXYvYXRoL2lmX2F0aF90eF9odC5jCSh3b3JraW5n IGNvcHkpCkBAIC02NDQsNyArNjQ0LDcgQEAKIGF0aF90eF9mb3JtX2FnZ3Ioc3RydWN0IGF0aF9z b2Z0YyAqc2MsIHN0cnVjdCBhdGhfbm9kZSAqYW4sIHN0cnVjdCBhdGhfdGlkICp0aWQsCiAgICAg YXRoX2J1ZmhlYWQgKmJmX3EpCiB7Ci0JLy9zdHJ1Y3QgaWVlZTgwMjExX25vZGUgKm5pID0gJmFu LT5hbl9ub2RlOworCXN0cnVjdCBpZWVlODAyMTFfbm9kZSAqbmkgPSAmYW4tPmFuX25vZGU7CiAJ c3RydWN0IGF0aF9idWYgKmJmLCAqYmZfZmlyc3QgPSBOVUxMLCAqYmZfcHJldiA9IE5VTEw7CiAJ aW50IG5mcmFtZXMgPSAwOwogCXVpbnQxNl90IGFnZ3JfbGltaXQgPSAwLCBhbCA9IDAsIGJwYWQg PSAwLCBhbF9kZWx0YSwgaF9iYXc7CkBAIC02NTIsNiArNjUyLDcgQEAKIAlpbnQgc3RhdHVzID0g QVRIX0FHR1JfRE9ORTsKIAlpbnQgcHJldl9mcmFtZXMgPSAwOwkvKiBYWFggZm9yIEFSNTQxNiBi dXJzdCwgbm90IGRvbmUgaGVyZSAqLwogCWludCBwcmV2X2FsID0gMDsJLyogWFhYIGFsc28gZm9y IEFSNTQxNiBidXJzdCAqLworCWludCBzZXFubzsKIAogCUFUSF9UWFFfTE9DS19BU1NFUlQoc2Mt PnNjX2FjMnFbdGlkLT5hY10pOwogCkBAIC03MDcsMTYgKzcwOCw2IEBACiAJCSAqLwogCiAJCS8q Ci0JCSAqIElmIHRoZSBwYWNrZXQgaGFzIGEgc2VxdWVuY2UgbnVtYmVyLCBkbyBub3QKLQkJICog c3RlcCBvdXRzaWRlIG9mIHRoZSBibG9jay1hY2sgd2luZG93LgotCQkgKi8KLQkJaWYgKCEgQkFX X1dJVEhJTih0YXAtPnR4YV9zdGFydCwgdGFwLT50eGFfd25kLAotCQkgICAgU0VRTk8oYmYtPmJm X3N0YXRlLmJmc19zZXFubykpKSB7Ci0JCSAgICBzdGF0dXMgPSBBVEhfQUdHUl9CQVdfQ0xPU0VE OwotCQkgICAgYnJlYWs7Ci0JCX0KLQotCQkvKgogCQkgKiBYWFggVE9ETzogQVI1NDE2IGhhcyBh biA4SyBhZ2dyZWdhdGlvbiBzaXplIGxpbWl0CiAJCSAqIHdoZW4gUlRTIGlzIGVuYWJsZWQsIGFu ZCBSVFMgaXMgcmVxdWlyZWQgZm9yIGR1YWwtc3RyZWFtCiAJCSAqIHJhdGVzLgpAQCAtNzQ0LDYg KzczNSw1OCBAQAogCQl9CiAKIAkJLyoKKwkJICogVE9ETzogSWYgaXQncyBfYmVmb3JlXyB0aGUg QkFXIGxlZnQgZWRnZSwgY29tcGxhaW4gdmVyeSBsb3VkbHkuCisJCSAqIFRoaXMgbWVhbnMgc29t ZXRoaW5nIChlbHNlKSBoYXMgc2xpZCB0aGUgbGVmdCBlZGdlIGFsb25nCisJCSAqIGJlZm9yZSB3 ZSBnb3QgYSBjaGFuY2UgdG8gYmUgVFhlZC4KKwkJICovCisKKwkJLyoKKwkJICogQ2hlY2sgaWYg d2UgaGF2ZSBzcGFjZSBpbiB0aGUgQkFXIGZvciB0aGlzIGZyYW1lIGJlZm9yZQorCQkgKiB3ZSBh ZGQgaXQuCisJCSAqCisJCSAqIHNlZSBhdGhfdHhfeG1pdF9hZ2dyKCkgZm9yIG1vcmUgaW5mby4K KwkJICovCisJCWlmIChiZi0+YmZfc3RhdGUuYmZzX2RvYmF3KSB7CisJCQlpZiAoISBCQVdfV0lU SElOKHRhcC0+dHhhX3N0YXJ0LCB0YXAtPnR4YV93bmQsCisJCQkgICAgbmktPm5pX3R4c2Vxc1ti Zi0+YmZfc3RhdGUuYmZzX3RpZF0pKSB7CisJCQkJc3RhdHVzID0gQVRIX0FHR1JfQkFXX0NMT1NF RDsKKwkJCQlicmVhazsKKwkJCX0KKwkJCS8qIFhYWCBjaGVjayBmb3IgYmZzX25lZWRfc2Vxbm8/ ICovCisJCQlpZiAoISBiZi0+YmZfc3RhdGUuYmZzX3NlcW5vX2Fzc2lnbmVkKSB7CisJCQkJc2Vx bm8gPSBhdGhfdHhfdGlkX3NlcW5vX2Fzc2lnbihzYywgbmksIGJmLCBiZi0+YmZfbSk7CisJCQkJ aWYgKHNlcW5vIDwgMCkgeworCQkJCQlkZXZpY2VfcHJpbnRmKHNjLT5zY19kZXYsCisJCQkJCSAg ICAiJXM6IGJmPSVwLCBodWgsIHNlcW5vPS0xP1xuIiwKKwkJCQkJICAgIF9fZnVuY19fLAorCQkJ CQkgICAgYmYpOworCQkJCQkvKiBYWFggd2hhdCBjYW4gd2UgZXZlbiBkbyBoZXJlPyAqLworCQkJ CX0KKwkJCQkvKiBGbHVzaCBzZXFubyB1cGRhdGUgdG8gUkFNICovCisJCQkJLyoKKwkJCQkgKiBY WFggVGhpcyBpcyByZXF1aXJlZCBiZWNhdXNlIHRoZSBkbWFzZXR1cAorCQkJCSAqIFhYWCBpcyBk b25lIGVhcmx5IHJhdGhlciB0aGFuIGF0IGRpc3BhdGNoCisJCQkJICogWFhYIHRpbWUuIEV3LCB3 ZSBzaG91bGQgZml4IHRoaXMhCisJCQkJICovCisJCQkJYnVzX2RtYW1hcF9zeW5jKHNjLT5zY19k bWF0LCBiZi0+YmZfZG1hbWFwLAorCQkJCSAgICBCVVNfRE1BU1lOQ19QUkVXUklURSk7CisJCQl9 CisJCX0KKworCQkvKgorCQkgKiBJZiB0aGUgcGFja2V0IGhhcyBhIHNlcXVlbmNlIG51bWJlciwg ZG8gbm90CisJCSAqIHN0ZXAgb3V0c2lkZSBvZiB0aGUgYmxvY2stYWNrIHdpbmRvdy4KKwkJICov CisJCWlmICghIEJBV19XSVRISU4odGFwLT50eGFfc3RhcnQsIHRhcC0+dHhhX3duZCwKKwkJICAg IFNFUU5PKGJmLT5iZl9zdGF0ZS5iZnNfc2Vxbm8pKSkgeworCQkJZGV2aWNlX3ByaW50ZihzYy0+ c2NfZGV2LAorCQkJICAgICIlczogYmY9JXAsIHNlcW5vPSVkLCBvdXRzaWRlPyFcbiIsCisJCQkg ICAgX19mdW5jX18sIGJmLCBTRVFOTyhiZi0+YmZfc3RhdGUuYmZzX3NlcW5vKSk7CisJCQlzdGF0 dXMgPSBBVEhfQUdHUl9CQVdfQ0xPU0VEOworCQkJYnJlYWs7CisJCX0KKworCQkvKgogCQkgKiB0 aGlzIHBhY2tldCBpcyBwYXJ0IG9mIGFuIGFnZ3JlZ2F0ZS4KIAkJICovCiAJCUFUSF9UWFFfUkVN T1ZFKHRpZCwgYmYsIGJmX2xpc3QpOwpJbmRleDogc3lzL2Rldi9hdGgvaWZfYXRoX3R4LmMKPT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PQotLS0gc3lzL2Rldi9hdGgvaWZfYXRoX3R4LmMJKHJldmlzaW9uIDIzMzA4OSkKKysr IHN5cy9kZXYvYXRoL2lmX2F0aF90eC5jCSh3b3JraW5nIGNvcHkpCkBAIC0xMDksOCArMTA5LDYg QEAKICAgICBpbnQgdGlkKTsKIHN0YXRpYyBpbnQgYXRoX3R4X2FtcGR1X3J1bm5pbmcoc3RydWN0 IGF0aF9zb2Z0YyAqc2MsIHN0cnVjdCBhdGhfbm9kZSAqYW4sCiAgICAgaW50IHRpZCk7Ci1zdGF0 aWMgaWVlZTgwMjExX3NlcSBhdGhfdHhfdGlkX3NlcW5vX2Fzc2lnbihzdHJ1Y3QgYXRoX3NvZnRj ICpzYywKLSAgICBzdHJ1Y3QgaWVlZTgwMjExX25vZGUgKm5pLCBzdHJ1Y3QgYXRoX2J1ZiAqYmYs IHN0cnVjdCBtYnVmICptMCk7CiBzdGF0aWMgaW50IGF0aF90eF9hY3Rpb25fZnJhbWVfb3ZlcnJp ZGVfcXVldWUoc3RydWN0IGF0aF9zb2Z0YyAqc2MsCiAgICAgc3RydWN0IGllZWU4MDIxMV9ub2Rl ICpuaSwgc3RydWN0IG1idWYgKm0wLCBpbnQgKnRpZCk7CiAKQEAgLTEzNzYsNyArMTM3NCw3IEBA CiAJaW50IGlzbWNhc3Q7CiAJY29uc3Qgc3RydWN0IGllZWU4MDIxMV9mcmFtZSAqd2g7CiAJaW50 IGlzX2FtcGR1LCBpc19hbXBkdV90eCwgaXNfYW1wZHVfcGVuZGluZzsKLQlpZWVlODAyMTFfc2Vx IHNlcW5vOworCS8vaWVlZTgwMjExX3NlcSBzZXFubzsKIAl1aW50OF90IHR5cGUsIHN1YnR5cGU7 CiAKIAkvKgpAQCAtMTQyOCw4ICsxNDI2LDkgQEAKIAlpc19hbXBkdV9wZW5kaW5nID0gYXRoX3R4 X2FtcGR1X3BlbmRpbmcoc2MsIEFUSF9OT0RFKG5pKSwgdGlkKTsKIAlpc19hbXBkdSA9IGlzX2Ft cGR1X3R4IHwgaXNfYW1wZHVfcGVuZGluZzsKIAotCURQUklOVEYoc2MsIEFUSF9ERUJVR19TV19U WCwgIiVzOiB0aWQ9JWQsIGFjPSVkLCBpc19hbXBkdT0lZFxuIiwKLQkgICAgX19mdW5jX18sIHRp ZCwgcHJpLCBpc19hbXBkdSk7CisJRFBSSU5URihzYywgQVRIX0RFQlVHX1NXX1RYLAorCSAgICAi JXM6IGJmPSVwLCB0aWQ9JWQsIGFjPSVkLCBpc19hbXBkdT0lZFxuIiwKKwkgICAgX19mdW5jX18s IGJmLCB0aWQsIHByaSwgaXNfYW1wZHUpOwogCiAJLyogTXVsdGljYXN0IGZyYW1lcyBnbyBvbnRv IHRoZSBzb2Z0d2FyZSBtdWx0aWNhc3QgcXVldWUgKi8KIAlpZiAoaXNtY2FzdCkKQEAgLTE0NDcs NiArMTQ0Niw5IEBACiAJLyogRG8gdGhlIGdlbmVyaWMgZnJhbWUgc2V0dXAgKi8KIAkvKiBYWFgg c2hvdWxkIGp1c3QgYnplcm8gdGhlIGJmX3N0YXRlPyAqLwogCWJmLT5iZl9zdGF0ZS5iZnNfZG9i YXcgPSAwOworCWJmLT5iZl9zdGF0ZS5iZnNfc2Vxbm9fYXNzaWduZWQgPSAwOworCWJmLT5iZl9z dGF0ZS5iZnNfbmVlZF9zZXFubyA9IDA7CisJYmYtPmJmX3N0YXRlLmJmc19zZXFubyA9IC0xOwkv KiBYWFggZGVidWdnaW5nICovCiAKIAkvKiBBLU1QRFUgVFg/IE1hbnVhbGx5IHNldCBzZXF1ZW5j ZSBudW1iZXIgKi8KIAkvKiBEb24ndCBkbyBpdCB3aGlsc3QgcGVuZGluZzsgdGhlIG5ldDgwMjEx IGxheWVyIHN0aWxsIGFzc2lnbnMgdGhlbSAqLwpAQCAtMTQ1OSwxOSArMTQ2MSwyNyBAQAogCQkg KiBkb24ndCBnZXQgYSBzZXF1ZW5jZSBudW1iZXIgZnJvbSB0aGUgY3VycmVudAogCQkgKiBUSUQg YW5kIHRodXMgbWVzcyB3aXRoIHRoZSBCQVcuCiAJCSAqLwotCQlzZXFubyA9IGF0aF90eF90aWRf c2Vxbm9fYXNzaWduKHNjLCBuaSwgYmYsIG0wKTsKKwkJLy9zZXFubyA9IGF0aF90eF90aWRfc2Vx bm9fYXNzaWduKHNjLCBuaSwgYmYsIG0wKTsKIAkJaWYgKElFRUU4MDIxMV9RT1NfSEFTX1NFUSh3 aCkgJiYKIAkJICAgIHN1YnR5cGUgIT0gSUVFRTgwMjExX0ZDMF9TVUJUWVBFX1FPU19OVUxMKSB7 CiAJCQliZi0+YmZfc3RhdGUuYmZzX2RvYmF3ID0gMTsKKwkJCWJmLT5iZl9zdGF0ZS5iZnNfbmVl ZF9zZXFubyA9IDE7CiAJCX0KIAkJQVRIX1RYUV9VTkxPQ0sodHhxKTsKKwl9IGVsc2UgeworCQkv KiBObyBBTVBEVSBUWCwgd2UndmUgYmVlbiBhc3NpZ25lZCBhIHNlcXVlbmNlIG51bWJlci4gKi8K KwkJaWYgKElFRUU4MDIxMV9RT1NfSEFTX1NFUSh3aCkpIHsKKwkJCWJmLT5iZl9zdGF0ZS5iZnNf c2Vxbm9fYXNzaWduZWQgPSAxOworCQkJYmYtPmJmX3N0YXRlLmJmc19zZXFubyA9CisJCQkgICAg TV9TRVFOT19HRVQobTApIDw8IElFRUU4MDIxMV9TRVFfU0VRX1NISUZUOworCQl9CiAJfQogCiAJ LyoKIAkgKiBJZiBuZWVkZWQsIHRoZSBzZXF1ZW5jZSBudW1iZXIgaGFzIGJlZW4gYXNzaWduZWQu CiAJICogU3F1aXJyZWwgaXQgYXdheSBzb21ld2hlcmUgZWFzeSB0byBnZXQgdG8uCiAJICovCi0J YmYtPmJmX3N0YXRlLmJmc19zZXFubyA9IE1fU0VRTk9fR0VUKG0wKSA8PCBJRUVFODAyMTFfU0VR X1NFUV9TSElGVDsKKwkvL2JmLT5iZl9zdGF0ZS5iZnNfc2Vxbm8gPSBNX1NFUU5PX0dFVChtMCkg PDwgSUVFRTgwMjExX1NFUV9TRVFfU0hJRlQ7CiAKIAkvKiBJcyBhbXBkdSBwZW5kaW5nPyBmZXRj aCB0aGUgc2Vxbm8gYW5kIHByaW50IGl0IG91dCAqLwogCWlmIChpc19hbXBkdV9wZW5kaW5nKQpA QCAtMTQ4OCw2ICsxNDk4LDEwIEBACiAJLyogQXQgdGhpcyBwb2ludCBtMCBjb3VsZCBoYXZlIGNo YW5nZWQhICovCiAJbTAgPSBiZi0+YmZfbTsKIAorCURQUklOVEYoc2MsIEFUSF9ERUJVR19TV19U WCwKKwkgICAgIiVzOiBET05FOiBiZj0lcCwgdGlkPSVkLCBhYz0lZCwgaXNfYW1wZHU9JWQsIGRv YmF3PSVkLCBzZXFubz0lZFxuIiwKKwkgICAgX19mdW5jX18sIGJmLCB0aWQsIHByaSwgaXNfYW1w ZHUsIGJmLT5iZl9zdGF0ZS5iZnNfZG9iYXcsIE1fU0VRTk9fR0VUKG0wKSk7CisKICNpZiAxCiAJ LyoKIAkgKiBJZiBpdCdzIGEgbXVsdGljYXN0IGZyYW1lLCBkbyBhIGRpcmVjdC1kaXNwYXRjaCB0 byB0aGUKQEAgLTE1MDYsNiArMTUyMCw4IEBACiAJICogcmVhY2hlZC4pCiAJICovCiAJaWYgKHR4 cSA9PSAmYXZwLT5hdl9tY2FzdHEpIHsKKwkJRFBSSU5URihzYywgQVRIX0RFQlVHX1NXX1RYX0NU UkwsCisJCSAgICAiJXM6IGJmPSVwOiBtY2FzdHE6IFRYJ2luZ1xuIiwgX19mdW5jX18sIGJmKTsK IAkJQVRIX1RYUV9MT0NLKHR4cSk7CiAJCWF0aF90eF94bWl0X25vcm1hbChzYywgdHhxLCBiZik7 CiAJCUFUSF9UWFFfVU5MT0NLKHR4cSk7CkBAIC0xNTE4LDYgKzE1MzQsOCBAQAogCQlBVEhfVFhR X1VOTE9DSyh0eHEpOwogCX0gZWxzZSB7CiAJCS8qIGFkZCB0byBzb2Z0d2FyZSBxdWV1ZSAqLwor CQlEUFJJTlRGKHNjLCBBVEhfREVCVUdfU1dfVFhfQ1RSTCwKKwkJICAgICIlczogYmY9JXA6IHN3 cTogVFgnaW5nXG4iLCBfX2Z1bmNfXywgYmYpOwogCQlhdGhfdHhfc3dxKHNjLCBuaSwgdHhxLCBi Zik7CiAJfQogI2Vsc2UKQEAgLTE5NjYsMjYgKzE5ODQsNTEgQEAKIAlpZiAoYmYtPmJmX3N0YXRl LmJmc19pc3JldHJpZWQpCiAJCXJldHVybjsKIAorCS8qCisJICogSWYgdGhpcyBvY2N1cnMgd2Un cmUgaW4gYSBsb3Qgb2YgdHJvdWJsZS4gIFdlIHNob3VsZCB0cnkgdG8KKwkgKiByZWNvdmVyIGZy b20gdGhpcyB3aXRob3V0IHRoZSBzZXNzaW9uIGhhbmdpbmc/CisJICovCisJaWYgKCEgYmYtPmJm X3N0YXRlLmJmc19zZXFub19hc3NpZ25lZCkgeworCQlkZXZpY2VfcHJpbnRmKHNjLT5zY19kZXYs CisJCSAgICAiJXM6IGJmPSVwLCBzZXFub19hc3NpZ25lZCBpcyAwPyFcbiIsIF9fZnVuY19fLCBi Zik7CisJCXJldHVybjsKKwl9CisKIAl0YXAgPSBhdGhfdHhfZ2V0X3R4X3RpZChhbiwgdGlkLT50 aWQpOwogCiAJaWYgKGJmLT5iZl9zdGF0ZS5iZnNfYWRkZWRiYXcpCiAJCWRldmljZV9wcmludGYo c2MtPnNjX2RldiwKLQkJICAgICIlczogcmUtYWRkZWQ/IHRpZD0lZCwgc2Vxbm8gJWQ7IHdpbmRv dyAlZDolZDsgIgorCQkgICAgIiVzOiByZS1hZGRlZD8gYmY9JXAsIHRpZD0lZCwgc2Vxbm8gJWQ7 IHdpbmRvdyAlZDolZDsgIgogCQkgICAgImJhdyBoZWFkPSVkIHRhaWw9JWRcbiIsCi0JCSAgICBf X2Z1bmNfXywgdGlkLT50aWQsIFNFUU5PKGJmLT5iZl9zdGF0ZS5iZnNfc2Vxbm8pLAorCQkgICAg X19mdW5jX18sIGJmLCB0aWQtPnRpZCwgU0VRTk8oYmYtPmJmX3N0YXRlLmJmc19zZXFubyksCiAJ CSAgICB0YXAtPnR4YV9zdGFydCwgdGFwLT50eGFfd25kLCB0aWQtPmJhd19oZWFkLAogCQkgICAg dGlkLT5iYXdfdGFpbCk7CiAKIAkvKgorCSAqIFZlcmlmeSB0aGF0IHRoZSBnaXZlbiBzZXF1ZW5j ZSBudW1iZXIgaXMgbm90IG91dHNpZGUgb2YgdGhlCisJICogQkFXLiAgQ29tcGxhaW4gbG91ZGx5 IGlmIHRoYXQncyB0aGUgY2FzZS4KKwkgKi8KKwlpZiAoISBCQVdfV0lUSElOKHRhcC0+dHhhX3N0 YXJ0LCB0YXAtPnR4YV93bmQsCisJICAgIFNFUU5PKGJmLT5iZl9zdGF0ZS5iZnNfc2Vxbm8pKSkg eworCQlkZXZpY2VfcHJpbnRmKHNjLT5zY19kZXYsCisJCSAgICAiJXM6IGJmPSVwOiBvdXRzaWRl IG9mIEJBVz8/IHRpZD0lZCwgc2Vxbm8gJWQ7IHdpbmRvdyAlZDolZDsgIgorCQkgICAgImJhdyBo ZWFkPSVkIHRhaWw9JWRcbiIsCisJCSAgICBfX2Z1bmNfXywgYmYsIHRpZC0+dGlkLCBTRVFOTyhi Zi0+YmZfc3RhdGUuYmZzX3NlcW5vKSwKKwkJICAgIHRhcC0+dHhhX3N0YXJ0LCB0YXAtPnR4YV93 bmQsIHRpZC0+YmF3X2hlYWQsCisJCSAgICB0aWQtPmJhd190YWlsKTsKKworCX0KKworCS8qCiAJ ICogbmktPm5pX3R4c2Vxc1tdIGlzIHRoZSBjdXJyZW50bHkgYWxsb2NhdGVkIHNlcW5vLgogCSAq IHRoZSB0eGEgc3RhdGUgY29udGFpbnMgdGhlIGN1cnJlbnQgYmF3IHN0YXJ0LgogCSAqLwogCWlu ZGV4ICA9IEFUSF9CQV9JTkRFWCh0YXAtPnR4YV9zdGFydCwgU0VRTk8oYmYtPmJmX3N0YXRlLmJm c19zZXFubykpOwogCWNpbmRleCA9ICh0aWQtPmJhd19oZWFkICsgaW5kZXgpICYgKEFUSF9USURf TUFYX0JVRlMgLSAxKTsKIAlEUFJJTlRGKHNjLCBBVEhfREVCVUdfU1dfVFhfQkFXLAotCSAgICAi JXM6IHRpZD0lZCwgc2Vxbm8gJWQ7IHdpbmRvdyAlZDolZDsgaW5kZXg9JWQgY2luZGV4PSVkICIK KwkgICAgIiVzOiBiZj0lcCwgdGlkPSVkLCBzZXFubyAlZDsgd2luZG93ICVkOiVkOyBpbmRleD0l ZCBjaW5kZXg9JWQgIgogCSAgICAiYmF3IGhlYWQ9JWQgdGFpbD0lZFxuIiwKLQkgICAgX19mdW5j X18sIHRpZC0+dGlkLCBTRVFOTyhiZi0+YmZfc3RhdGUuYmZzX3NlcW5vKSwKKwkgICAgX19mdW5j X18sIGJmLCB0aWQtPnRpZCwgU0VRTk8oYmYtPmJmX3N0YXRlLmJmc19zZXFubyksCiAJICAgIHRh cC0+dHhhX3N0YXJ0LCB0YXAtPnR4YV93bmQsIGluZGV4LCBjaW5kZXgsIHRpZC0+YmF3X2hlYWQs CiAJICAgIHRpZC0+YmF3X3RhaWwpOwogCkBAIC0yMDg4LDkgKzIxMzEsOSBAQAogCWNpbmRleCA9 ICh0aWQtPmJhd19oZWFkICsgaW5kZXgpICYgKEFUSF9USURfTUFYX0JVRlMgLSAxKTsKIAogCURQ UklOVEYoc2MsIEFUSF9ERUJVR19TV19UWF9CQVcsCi0JICAgICIlczogdGlkPSVkLCBiYXc9JWQ6 JWQsIHNlcW5vPSVkLCBpbmRleD0lZCwgY2luZGV4PSVkLCAiCisJICAgICIlczogYmY9JXA6IHRp ZD0lZCwgYmF3PSVkOiVkLCBzZXFubz0lZCwgaW5kZXg9JWQsIGNpbmRleD0lZCwgIgogCSAgICAi YmF3IGhlYWQ9JWQsIHRhaWw9JWRcbiIsCi0JICAgIF9fZnVuY19fLCB0aWQtPnRpZCwgdGFwLT50 eGFfc3RhcnQsIHRhcC0+dHhhX3duZCwgc2Vxbm8sIGluZGV4LAorCSAgICBfX2Z1bmNfXywgYmYs IHRpZC0+dGlkLCB0YXAtPnR4YV9zdGFydCwgdGFwLT50eGFfd25kLCBzZXFubywgaW5kZXgsCiAJ ICAgIGNpbmRleCwgdGlkLT5iYXdfaGVhZCwgdGlkLT5iYXdfdGFpbCk7CiAKIAkvKgpAQCAtMjE3 MSwxMSArMjIxNCw0MiBAQAogfQogCiAvKgorICogUmV0dXJuIHdoZXRoZXIgYSBzZXF1ZW5jZSBu dW1iZXIgaXMgYWN0dWFsbHkgcmVxdWlyZWQuCisgKgorICogQSBzZXF1ZW5jZSBudW1iZXIgbXVz dCBvbmx5IGJlIGFsbG9jYXRlZCBhdCB0aGUgdGltZSB0aGF0IGEgZnJhbWUKKyAqIGlzIGNvbnNp ZGVyZWQgZm9yIGFkZGl0aW9uIHRvIHRoZSBCQVcvYWdncmVnYXRlIGFuZCBiZWluZyBUWGVkLgor ICogVGhlIHNlcXVlbmNlIG51bWJlciBtdXN0IG5vdCBiZSBhbGxvY2F0ZWQgYmVmb3JlIHRoZSBm cmFtZQorICogaXMgYWRkZWQgdG8gdGhlIEJBVyAocHJvdGVjdGVkIGJ5IHRoZSBzYW1lIGxvY2sg aW5zdGFuY2UpCisgKiBvdGhlcndpc2UgYSB0aGUgbXVsdGktZW50cmFudCBUWCBwYXRoIG1heSBy ZXN1bHQgaW4gYSBsYXRlciBzZXFubworICogYmVpbmcgYWRkZWQgdG8gdGhlIEJBVyBmaXJzdC4g IFRoZSBzdWJzZXF1ZW50IGFkZGl0aW9uIG9mIHRoZQorICogZWFybGllciBzZXFubyB3b3VsZCB0 aGVuIG5vdCBnbyBpbnRvIHRoZSBCQVcgYXMgaXQncyBub3cgb3V0c2lkZQorICogb2Ygc2FpZCBC QVcuCisgKgorICogVGhpcyByb3V0aW5lIGlzIHVzZWQgYnkgYXRoX3R4X3N0YXJ0KCkgdG8gbWFy ayB3aGV0aGVyIHRoZSBmcmFtZQorICogc2hvdWxkIGdldCBhIHNlcXVlbmNlIG51bWJlciBiZWZv cmUgYWRkaW5nIGl0IHRvIHRoZSBCQVcuCisgKgorICogVGhlbiB0aGUgYWN0dWFsIGFnZ3JlZ2F0 ZSBUWCByb3V0aW5lcyB3aWxsIGNoZWNrIHdoZXRoZXIgdGhpcworICogZmxhZyBpcyBzZXQgYW5k IGlmIHRoZSBmcmFtZSBuZWVkcyB0byBnbyBpbnRvIHRoZSBCQVcsIGl0J2xsCisgKiBoYXZlIGEg c2VxdWVuY2UgbnVtYmVyIGFsbG9jYXRlZCBmb3IgaXQuCisgKi8KKyNpZiAwCitzdGF0aWMgaW50 CithdGhfdHhfc2Vxbm9fcmVxdWlyZWQoc3RydWN0IGF0aF9zb2Z0YyAqc2MsIHN0cnVjdCBpZWVl ODAyMTFfbm9kZSAqbmksCisgICAgc3RydWN0IGF0aF9idWYgKmJmLCBzdHJ1Y3QgbWJ1ZiAqbTAp Cit7Cit9CisjZW5kaWYKKworLyoKICAqIEFzc2lnbiBhIHNlcXVlbmNlIG51bWJlciBtYW51YWxs eSB0byB0aGUgZ2l2ZW4gZnJhbWUuCiAgKgogICogVGhpcyBzaG91bGQgb25seSBiZSBjYWxsZWQg Zm9yIEEtTVBEVSBUWCBmcmFtZXMuCisgKgorICogSWYgdGhpcyBpcyBjYWxsZWQgYWZ0ZXIgdGhl IGluaXRpYWwgZnJhbWUgc2V0dXAsIG1ha2Ugc3VyZSB5b3UndmUgZmx1c2hlZAorICogdGhlIERN QSBtYXAgb3IgeW91J2xsIHJpc2sgc2VuZGluZyBzdGFsZSBkYXRhIHRvIHRoZSBOSUMuICBUaGlz IHJvdXRpbmUKKyAqIHVwZGF0ZXMgdGhlIGFjdHVhbCBmcmFtZSBjb250ZW50cyB3aXRoIHRoZSBy ZWxldmFudCBzZXFuby4KICAqLwotc3RhdGljIGllZWU4MDIxMV9zZXEKK2ludAogYXRoX3R4X3Rp ZF9zZXFub19hc3NpZ24oc3RydWN0IGF0aF9zb2Z0YyAqc2MsIHN0cnVjdCBpZWVlODAyMTFfbm9k ZSAqbmksCiAgICAgc3RydWN0IGF0aF9idWYgKmJmLCBzdHJ1Y3QgbWJ1ZiAqbTApCiB7CkBAIC0y MTg4LDkgKzIyNjIsMjMgQEAKIAl3aCA9IG10b2QobTAsIHN0cnVjdCBpZWVlODAyMTFfZnJhbWUg Kik7CiAJcHJpID0gTV9XTUVfR0VUQUMobTApOwkJCS8qIGhvbm9yIGNsYXNzaWZpY2F0aW9uICov CiAJdGlkID0gV01FX0FDX1RPX1RJRChwcmkpOwotCURQUklOVEYoc2MsIEFUSF9ERUJVR19TV19U WCwgIiVzOiBwcmk9JWQsIHRpZD0lZCwgcW9zIGhhcyBzZXE9JWRcbiIsCi0JICAgIF9fZnVuY19f LCBwcmksIHRpZCwgSUVFRTgwMjExX1FPU19IQVNfU0VRKHdoKSk7CisJRFBSSU5URihzYywgQVRI X0RFQlVHX1NXX1RYLAorCSAgICAiJXM6IGJmPSVwLCBwcmk9JWQsIHRpZD0lZCwgcW9zIGhhcyBz ZXE9JWRcbiIsCisJICAgIF9fZnVuY19fLCBiZiwgcHJpLCB0aWQsIElFRUU4MDIxMV9RT1NfSEFT X1NFUSh3aCkpOwogCisJaWYgKCEgYmYtPmJmX3N0YXRlLmJmc19uZWVkX3NlcW5vKSB7CisJCWRl dmljZV9wcmludGYoc2MtPnNjX2RldiwgIiVzOiBiZj0lcDogbmVlZF9zZXFubyBub3Qgc2V0PyFc biIsCisJCSAgICBfX2Z1bmNfXywgYmYpOworCQlyZXR1cm4gLTE7CisJfQorCS8qIFhYWCBjaGVj ayBmb3IgYmZzX25lZWRfc2Vxbm8/ICovCisJaWYgKGJmLT5iZl9zdGF0ZS5iZnNfc2Vxbm9fYXNz aWduZWQpIHsKKwkJZGV2aWNlX3ByaW50ZihzYy0+c2NfZGV2LAorCQkgICAgIiVzOiBiZj0lcDog c2Vxbm8gYWxyZWFkeSBhc3NpZ25lZCAoJWQpPyFcbiIsCisJCSAgICBfX2Z1bmNfXywgYmYsIFNF UU5PKGJmLT5iZl9zdGF0ZS5iZnNfc2Vxbm8pKTsKKwkJcmV0dXJuIGJmLT5iZl9zdGF0ZS5iZnNf c2Vxbm8gPj4gSUVFRTgwMjExX1NFUV9TRVFfU0hJRlQ7CisJfQorCiAJLyogWFhYIElzIGl0IGEg Y29udHJvbCBmcmFtZT8gSWdub3JlICovCiAKIAkvKiBEb2VzIHRoZSBwYWNrZXQgcmVxdWlyZSBh IHNlcXVlbmNlIG51bWJlcj8gKi8KQEAgLTIyMTcsOSArMjMwNSwxNCBAQAogCX0KIAkqKHVpbnQx Nl90ICopJndoLT5pX3NlcVswXSA9IGh0b2xlMTYoc2Vxbm8gPDwgSUVFRTgwMjExX1NFUV9TRVFf U0hJRlQpOwogCU1fU0VRTk9fU0VUKG0wLCBzZXFubyk7CisJYmYtPmJmX3N0YXRlLmJmc19zZXFu byA9IHNlcW5vIDw8IElFRUU4MDIxMV9TRVFfU0VRX1NISUZUOworCWJmLT5iZl9zdGF0ZS5iZnNf c2Vxbm9fYXNzaWduZWQgPSAxOwogCiAJLyogUmV0dXJuIHNvIGNhbGxlciBjYW4gZG8gc29tZXRo aW5nIHdpdGggaXQgaWYgbmVlZGVkICovCi0JRFBSSU5URihzYywgQVRIX0RFQlVHX1NXX1RYLCAi JXM6ICAtPiBzZXFubz0lZFxuIiwgX19mdW5jX18sIHNlcW5vKTsKKwlEUFJJTlRGKHNjLCBBVEhf REVCVUdfU1dfVFgsICIlczogYmY9JXA6ICAtPiBzZXFubz0lZFxuIiwKKwkgICAgX19mdW5jX18s CisJICAgIGJmLAorCSAgICBzZXFubyk7CiAJcmV0dXJuIHNlcW5vOwogfQogCkBAIC0yMjMxLDkg KzIzMjQsMTEgQEAKIHN0YXRpYyB2b2lkCiBhdGhfdHhfeG1pdF9hZ2dyKHN0cnVjdCBhdGhfc29m dGMgKnNjLCBzdHJ1Y3QgYXRoX25vZGUgKmFuLCBzdHJ1Y3QgYXRoX2J1ZiAqYmYpCiB7CisJc3Ry dWN0IGllZWU4MDIxMV9ub2RlICpuaSA9ICZhbi0+YW5fbm9kZTsKIAlzdHJ1Y3QgYXRoX3RpZCAq dGlkID0gJmFuLT5hbl90aWRbYmYtPmJmX3N0YXRlLmJmc190aWRdOwogCXN0cnVjdCBhdGhfdHhx ICp0eHEgPSBiZi0+YmZfc3RhdGUuYmZzX3R4cTsKIAlzdHJ1Y3QgaWVlZTgwMjExX3R4X2FtcGR1 ICp0YXA7CisJaW50IHNlcW5vOwogCiAJQVRIX1RYUV9MT0NLX0FTU0VSVCh0eHEpOwogCkBAIC0y MjQ1LDEwICsyMzQwLDYzIEBACiAJCXJldHVybjsKIAl9CiAKKwkvKgorCSAqIFRPRE86IElmIGl0 J3MgX2JlZm9yZV8gdGhlIEJBVyBsZWZ0IGVkZ2UsIGNvbXBsYWluIHZlcnkgbG91ZGx5LgorCSAq IFRoaXMgbWVhbnMgc29tZXRoaW5nIChlbHNlKSBoYXMgc2xpZCB0aGUgbGVmdCBlZGdlIGFsb25n CisJICogYmVmb3JlIHdlIGdvdCBhIGNoYW5jZSB0byBiZSBUWGVkLgorCSAqLworCisJLyoKKwkg KiBJcyB0aGVyZSBzcGFjZSBpbiB0aGlzIEJBVyBmb3IgYW5vdGhlciBmcmFtZT8KKwkgKiBJZiBu b3QsIGRvbid0IGJvdGhlciB0cnlpbmcgdG8gc2NoZWR1bGUgaXQ7IGp1c3QKKwkgKiB0aHJvdyBp dCBiYWNrIG9uIHRoZSBxdWV1ZS4KKwkgKgorCSAqIElmIHdlIGFsbG9jYXRlIHRoZSBzZXF1ZW5j ZSBudW1iZXIgYmVmb3JlIHdlIGFkZAorCSAqIGl0IHRvIHRoZSBCQVcsIHdlIHJpc2sgcmFjaW5n IHdpdGggYW5vdGhlciBUWAorCSAqIHRocmVhZCB0aGF0IGdldHMgaW4gYSBmcmFtZSBpbnRvIHRo ZSBCQVcgd2l0aAorCSAqIHNlcW5vIGdyZWF0ZXIgdGhhbiBvdXJzLiAgV2UnZCB0aGVuIGZhaWwg dGhlCisJICogYmVsb3cgY2hlY2sgYW5kIHRocm93IHRoZSBmcmFtZSBvbiB0aGUgdGFpbCBvZgor CSAqIHRoZSBxdWV1ZS4gIFRoZSBzZW5kZXIgd291bGQgdGhlbiBoYXZlIGEgaG9sZS4KKwkgKgor CSAqIFhYWCBhZ2Fpbiwgd2UncmUgcHJvdGVjdGluZyBuaS0+bmlfdHhzZXFzW3RpZF0KKwkgKiBi ZWhpbmQgdGhpcyBoYXJkd2FyZSBUWFEgbG9jaywgbGlrZSB0aGUgcmVzdCBvZgorCSAqIHRoZSBU SURzIHRoYXQgbWFwIHRvIGl0LiAgVWdoLgorCSAqLworCWlmIChiZi0+YmZfc3RhdGUuYmZzX2Rv YmF3KSB7CisJCWlmICghIEJBV19XSVRISU4odGFwLT50eGFfc3RhcnQsIHRhcC0+dHhhX3duZCwK KwkJICAgIG5pLT5uaV90eHNlcXNbYmYtPmJmX3N0YXRlLmJmc190aWRdKSkgeworCQkJQVRIX1RY UV9JTlNFUlRfVEFJTCh0aWQsIGJmLCBiZl9saXN0KTsKKwkJCWF0aF90eF90aWRfc2NoZWQoc2Ms IHRpZCk7CisJCQlyZXR1cm47CisJCX0KKwkJaWYgKCEgYmYtPmJmX3N0YXRlLmJmc19zZXFub19h c3NpZ25lZCkgeworCQkJc2Vxbm8gPSBhdGhfdHhfdGlkX3NlcW5vX2Fzc2lnbihzYywgbmksIGJm LCBiZi0+YmZfbSk7CisJCQlpZiAoc2Vxbm8gPCAwKSB7CisJCQkJZGV2aWNlX3ByaW50ZihzYy0+ c2NfZGV2LAorCQkJCSAgICAiJXM6IGJmPSVwLCBodWgsIHNlcW5vPS0xP1xuIiwKKwkJCQkgICAg X19mdW5jX18sCisJCQkJICAgIGJmKTsKKwkJCQkvKiBYWFggd2hhdCBjYW4gd2UgZXZlbiBkbyBo ZXJlPyAqLworCQkJfQorCQkJLyogRmx1c2ggc2Vxbm8gdXBkYXRlIHRvIFJBTSAqLworCQkJLyoK KwkJCSAqIFhYWCBUaGlzIGlzIHJlcXVpcmVkIGJlY2F1c2UgdGhlIGRtYXNldHVwCisJCQkgKiBY WFggaXMgZG9uZSBlYXJseSByYXRoZXIgdGhhbiBhdCBkaXNwYXRjaAorCQkJICogWFhYIHRpbWUu IEV3LCB3ZSBzaG91bGQgZml4IHRoaXMhCisJCQkgKi8KKwkJCWJ1c19kbWFtYXBfc3luYyhzYy0+ c2NfZG1hdCwgYmYtPmJmX2RtYW1hcCwKKwkJCSAgICBCVVNfRE1BU1lOQ19QUkVXUklURSk7CisJ CX0KKwl9CisKIAkvKiBvdXRzaWRlIGJhdz8gcXVldWUgKi8KIAlpZiAoYmYtPmJmX3N0YXRlLmJm c19kb2JhdyAmJgogCSAgICAoISBCQVdfV0lUSElOKHRhcC0+dHhhX3N0YXJ0LCB0YXAtPnR4YV93 bmQsCiAJICAgIFNFUU5PKGJmLT5iZl9zdGF0ZS5iZnNfc2Vxbm8pKSkpIHsKKwkJZGV2aWNlX3By aW50ZihzYy0+c2NfZGV2LAorCQkgICAgIiVzOiBiZj0lcCwgc2hvdWxkbid0IGJlIG91dHNpZGUg QkFXIG5vdz8hXG4iLAorCQkgICAgX19mdW5jX18sCisJCSAgICBiZik7CiAJCUFUSF9UWFFfSU5T RVJUX1RBSUwodGlkLCBiZiwgYmZfbGlzdCk7CiAJCWF0aF90eF90aWRfc2NoZWQoc2MsIHRpZCk7 CiAJCXJldHVybjsKQEAgLTIzMDMsOCArMjQ1MSw4IEBACiAJdGlkID0gYXRoX3R4X2dldHRpZChz YywgbTApOwogCWF0aWQgPSAmYW4tPmFuX3RpZFt0aWRdOwogCi0JRFBSSU5URihzYywgQVRIX0RF QlVHX1NXX1RYLCAiJXM6IGJmPSVwLCBwcmk9JWQsIHRpZD0lZCwgcW9zPSVkXG4iLAotCSAgICBf X2Z1bmNfXywgYmYsIHByaSwgdGlkLCBJRUVFODAyMTFfUU9TX0hBU19TRVEod2gpKTsKKwlEUFJJ TlRGKHNjLCBBVEhfREVCVUdfU1dfVFgsICIlczogYmY9JXAsIHByaT0lZCwgdGlkPSVkLCBxb3M9 JWQsIHNlcW5vPSVkXG4iLAorCSAgICBfX2Z1bmNfXywgYmYsIHByaSwgdGlkLCBJRUVFODAyMTFf UU9TX0hBU19TRVEod2gpLCBTRVFOTyhiZi0+YmZfc3RhdGUuYmZzX3NlcW5vKSk7CiAKIAkvKiBT ZXQgbG9jYWwgcGFja2V0IHN0YXRlLCB1c2VkIHRvIHF1ZXVlIHBhY2tldHMgdG8gaGFyZHdhcmUg Ki8KIAliZi0+YmZfc3RhdGUuYmZzX3RpZCA9IHRpZDsKQEAgLTIzMjAsMzQgKzI0NjgsMzQgQEAK IAlBVEhfVFhRX0xPQ0sodHhxKTsKIAlpZiAoYXRpZC0+cGF1c2VkKSB7CiAJCS8qIFRJRCBpcyBw YXVzZWQsIHF1ZXVlICovCi0JCURQUklOVEYoc2MsIEFUSF9ERUJVR19TV19UWCwgIiVzOiBwYXVz ZWRcbiIsIF9fZnVuY19fKTsKKwkJRFBSSU5URihzYywgQVRIX0RFQlVHX1NXX1RYLCAiJXM6IGJm PSVwOiBwYXVzZWRcbiIsIF9fZnVuY19fLCBiZik7CiAJCUFUSF9UWFFfSU5TRVJUX1RBSUwoYXRp ZCwgYmYsIGJmX2xpc3QpOwogCX0gZWxzZSBpZiAoYXRoX3R4X2FtcGR1X3BlbmRpbmcoc2MsIGFu LCB0aWQpKSB7CiAJCS8qIEFNUERVIHBlbmRpbmc7IHF1ZXVlICovCi0JCURQUklOVEYoc2MsIEFU SF9ERUJVR19TV19UWCwgIiVzOiBwZW5kaW5nXG4iLCBfX2Z1bmNfXyk7CisJCURQUklOVEYoc2Ms IEFUSF9ERUJVR19TV19UWCwgIiVzOiBiZj0lcDogcGVuZGluZ1xuIiwgX19mdW5jX18sIGJmKTsK IAkJQVRIX1RYUV9JTlNFUlRfVEFJTChhdGlkLCBiZiwgYmZfbGlzdCk7CiAJCS8qIFhYWCBzY2hl ZD8gKi8KIAl9IGVsc2UgaWYgKGF0aF90eF9hbXBkdV9ydW5uaW5nKHNjLCBhbiwgdGlkKSkgewog CQkvKiBBTVBEVSBydW5uaW5nLCBhdHRlbXB0IGRpcmVjdCBkaXNwYXRjaCBpZiBwb3NzaWJsZSAq LwogCQlpZiAodHhxLT5heHFfZGVwdGggPCBzYy0+c2NfaHdxX2xpbWl0KSB7CisJCQlEUFJJTlRG KHNjLCBBVEhfREVCVUdfU1dfVFgsCisJCQkgICAgIiVzOiBiZj0lcDogeG1pdF9hZ2dyXG4iLAor CQkJICAgIF9fZnVuY19fLCBiZik7CiAJCQlhdGhfdHhfeG1pdF9hZ2dyKHNjLCBhbiwgYmYpOwot CQkJRFBSSU5URihzYywgQVRIX0RFQlVHX1NXX1RYLAotCQkJICAgICIlczogeG1pdF9hZ2dyXG4i LAotCQkJICAgIF9fZnVuY19fKTsKIAkJfSBlbHNlIHsKIAkJCURQUklOVEYoc2MsIEFUSF9ERUJV R19TV19UWCwKLQkJCSAgICAiJXM6IGFtcGR1OyBzd3EnaW5nXG4iLAotCQkJICAgIF9fZnVuY19f KTsKKwkJCSAgICAiJXM6IGJmPSVwOiBhbXBkdTsgc3dxJ2luZ1xuIiwKKwkJCSAgICBfX2Z1bmNf XywgYmYpOwogCQkJQVRIX1RYUV9JTlNFUlRfVEFJTChhdGlkLCBiZiwgYmZfbGlzdCk7CiAJCQlh dGhfdHhfdGlkX3NjaGVkKHNjLCBhdGlkKTsKIAkJfQogCX0gZWxzZSBpZiAodHhxLT5heHFfZGVw dGggPCBzYy0+c2NfaHdxX2xpbWl0KSB7CiAJCS8qIEFNUERVIG5vdCBydW5uaW5nLCBhdHRlbXB0 IGRpcmVjdCBkaXNwYXRjaCAqLwotCQlEUFJJTlRGKHNjLCBBVEhfREVCVUdfU1dfVFgsICIlczog eG1pdF9ub3JtYWxcbiIsIF9fZnVuY19fKTsKKwkJRFBSSU5URihzYywgQVRIX0RFQlVHX1NXX1RY LCAiJXM6IGJmPSVwOiB4bWl0X25vcm1hbFxuIiwgX19mdW5jX18sIGJmKTsKIAkJYXRoX3R4X3ht aXRfbm9ybWFsKHNjLCB0eHEsIGJmKTsKIAl9IGVsc2UgewogCQkvKiBCdXN5OyBxdWV1ZSAqLwot CQlEUFJJTlRGKHNjLCBBVEhfREVCVUdfU1dfVFgsICIlczogc3dxJ2luZ1xuIiwgX19mdW5jX18p OworCQlEUFJJTlRGKHNjLCBBVEhfREVCVUdfU1dfVFgsICIlczogYmY9JXA6IHN3cSdpbmdcbiIs IF9fZnVuY19fLCBiZik7CiAJCUFUSF9UWFFfSU5TRVJUX1RBSUwoYXRpZCwgYmYsIGJmX2xpc3Qp OwogCQlhdGhfdHhfdGlkX3NjaGVkKHNjLCBhdGlkKTsKIAl9CkBAIC0yNDc4LDExICsyNjI2LDEx IEBACiAKIAkJaWYgKHQgPT0gMCkgewogCQkJZGV2aWNlX3ByaW50ZihzYy0+c2NfZGV2LAotCQkJ ICAgICIlczogbm9kZSAlcDogdGlkICVkOiB0eHFfZGVwdGg9JWQsICIKKwkJCSAgICAiJXM6IG5v ZGUgJXA6IGJmPSVwOiB0aWQgJWQ6IHR4cV9kZXB0aD0lZCwgIgogCQkJICAgICJ0eHFfYWdncl9k ZXB0aD0lZCwgc2NoZWQ9JWQsIHBhdXNlZD0lZCwgIgogCQkJICAgICJod3FfZGVwdGg9JWQsIGlu Y29tcD0lZCwgYmF3X2hlYWQ9JWQsICIKIAkJCSAgICAiYmF3X3RhaWw9JWQgdHhhX3N0YXJ0PSVk LCBuaV90eHNlcXM9JWRcbiIsCi0JCQkgICAgIF9fZnVuY19fLCBuaSwgdGlkLT50aWQsIHR4cS0+ YXhxX2RlcHRoLAorCQkJICAgICBfX2Z1bmNfXywgbmksIGJmLCB0aWQtPnRpZCwgdHhxLT5heHFf ZGVwdGgsCiAJCQkgICAgIHR4cS0+YXhxX2FnZ3JfZGVwdGgsIHRpZC0+c2NoZWQsIHRpZC0+cGF1 c2VkLAogCQkJICAgICB0aWQtPmh3cV9kZXB0aCwgdGlkLT5pbmNvbXAsIHRpZC0+YmF3X2hlYWQs CiAJCQkgICAgIHRpZC0+YmF3X3RhaWwsIHRhcCA9PSBOVUxMID8gLTEgOiB0YXAtPnR4YV9zdGFy dCwKQEAgLTI0OTMsNyArMjY0MSw3IEBACiAJCQkgICAgbXRvZChiZi0+YmZfbSwgY29uc3QgdWlu dDhfdCAqKSwKIAkJCSAgICBiZi0+YmZfbS0+bV9sZW4sIDAsIC0xKTsKIAotCQkJdCA9IDE7CisJ CQkvL3QgPSAxOwogCQl9CiAKIApJbmRleDogc3lzL2Rldi9hdGgvaWZfYXRoX3R4LmgKPT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PQotLS0gc3lzL2Rldi9hdGgvaWZfYXRoX3R4LmgJKHJldmlzaW9uIDIzMzA4OSkKKysrIHN5 cy9kZXYvYXRoL2lmX2F0aF90eC5oCSh3b3JraW5nIGNvcHkpCkBAIC0xMDksNiArMTA5LDggQEAK ICAgICBzdHJ1Y3QgYXRoX3RpZCAqdGlkLCBzdHJ1Y3QgYXRoX2J1ZiAqYmYpOwogZXh0ZXJuIHN0 cnVjdCBpZWVlODAyMTFfdHhfYW1wZHUgKiBhdGhfdHhfZ2V0X3R4X3RpZChzdHJ1Y3QgYXRoX25v ZGUgKmFuLAogICAgIGludCB0aWQpOworZXh0ZXJuIGludCBhdGhfdHhfdGlkX3NlcW5vX2Fzc2ln bihzdHJ1Y3QgYXRoX3NvZnRjICpzYywKKyAgICBzdHJ1Y3QgaWVlZTgwMjExX25vZGUgKm5pLCBz dHJ1Y3QgYXRoX2J1ZiAqYmYsIHN0cnVjdCBtYnVmICptMCk7CiAKIC8qIFRYIGFkZGJhIGhhbmRs aW5nICovCiBleHRlcm4JaW50IGF0aF9hZGRiYV9yZXF1ZXN0KHN0cnVjdCBpZWVlODAyMTFfbm9k ZSAqbmksCg== --047d7b33c9fe4e3ed604bb91d101-- From owner-freebsd-wireless@FreeBSD.ORG Mon Mar 19 05:35:11 2012 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 84669106564A for ; Mon, 19 Mar 2012 05:35:11 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by mx1.freebsd.org (Postfix) with ESMTP id 122698FC14 for ; Mon, 19 Mar 2012 05:35:10 +0000 (UTC) Received: by dakl33 with SMTP id l33so11629756dak.17 for ; Sun, 18 Mar 2012 22:35:10 -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=+2UP5QeK4zngSojV5RQd4SS8IRNe9YyBryVjmgFrPXU=; b=MYfew7h110bQMikWKFLEJ0PqHlgqJs/tuCWZEOiq8UKa6KB2m7zWOn9NDOEYKr05SM KgMcmpHwjMKLKM4zjmM3vyW9cMCCUW7eXpyhMZAKsbDQcj9zawKp7OiSKV6N80H45vY4 EH2XPtBZbikVffa5tkh3oAEEGJExSGYh3UO90ZTOSZBNj995osxhGpyPYwZvZZiUiv10 rYxEn6w/fGmQ3PNPZwrUNS1X1T+nh6xjvsEBC7KCw982hmLfD86zVRn0ZyOytKLD4V01 Qe0uNMxZ3THJZY1DVOPlvwBQe3BvCvI9Lo4JwvJD+hx3x3AWQ+TGRxDdW3ddZZT7z3Qw XFLA== MIME-Version: 1.0 Received: by 10.68.130.6 with SMTP id oa6mr36510279pbb.96.1332135310687; Sun, 18 Mar 2012 22:35:10 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.143.33.5 with HTTP; Sun, 18 Mar 2012 22:35:10 -0700 (PDT) In-Reply-To: <4F5C0302.8090403@unsane.co.uk> References: <4F59DD98.8080905@unsane.co.uk> <4F5AA149.8000904@unsane.co.uk> <4F5BDF3C.8070605@unsane.co.uk> <4F5C0302.8090403@unsane.co.uk> Date: Sun, 18 Mar 2012 22:35:10 -0700 X-Google-Sender-Auth: cTIRMeL0srHz320fAeR2Fpl5XWM Message-ID: From: Adrian Chadd To: Vincent Hoffman Content-Type: multipart/mixed; boundary=e89a8ffbaecbfc7ee204bb91ebe8 Cc: freebsd-wireless@freebsd.org Subject: Re: ath0 timeout was "Re: (more) bugs fixed in -HEAD, AP mode is now mostly (again) stable!" X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.5 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, 19 Mar 2012 05:35:11 -0000 --e89a8ffbaecbfc7ee204bb91ebe8 Content-Type: text/plain; charset=ISO-8859-1 Hi, Please try this patch: Adrian --e89a8ffbaecbfc7ee204bb91ebe8 Content-Type: text/x-patch; charset=US-ASCII; name="kern-166190-baw.diff" Content-Disposition: attachment; filename="kern-166190-baw.diff" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gzz30muo0 SW5kZXg6IHN5cy9kZXYvYXRoL2lmX2F0aF9kZWJ1Zy5jCj09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIHN5cy9kZXYv YXRoL2lmX2F0aF9kZWJ1Zy5jCShyZXZpc2lvbiAyMzMwODkpCisrKyBzeXMvZGV2L2F0aC9pZl9h dGhfZGVidWcuYwkod29ya2luZyBjb3B5KQpAQCAtMTM1LDE5ICsxMzUsMjMgQEAKIAlwcmludGYo IlEldVslM3VdIiwgcW51bSwgaXgpOwogCXdoaWxlIChiZiAhPSBOVUxMKSB7CiAJCWZvciAoaSA9 IDAsIGRzID0gYmYtPmJmX2Rlc2M7IGkgPCBiZi0+YmZfbnNlZzsgaSsrLCBkcysrKSB7Ci0JCQlw cmludGYoIiAoRFMuVjolcCBEUy5QOiVwKSBMOiUwOHggRDolMDh4IEY6JTA0eCVzXG4iCi0JCQkg ICAgICAgIiAgICAgICAgVFhGOiAlMDR4IFNlcTogJWQgc3d0cnk6ICVkIEFEREJBVz86ICVkIERP QkFXPzogJWRcbiIKLQkJCSAgICAgICAiICAgICAgICAlMDh4ICUwOHggJTA4eCAlMDh4ICUwOHgg JTA4eFxuIiwKKwkJCXByaW50ZigiIChEUy5WOiVwIERTLlA6JXApIEw6JTA4eCBEOiUwOHggRjol MDR4JXNcbiIsCiAJCQkgICAgZHMsIChjb25zdCBzdHJ1Y3QgYXRoX2Rlc2MgKiliZi0+YmZfZGFk ZHIgKyBpLAogCQkJICAgIGRzLT5kc19saW5rLCBkcy0+ZHNfZGF0YSwgYmYtPmJmX3R4ZmxhZ3Ms Ci0JCQkgICAgIWRvbmUgPyAiIiA6ICh0cy0+dHNfc3RhdHVzID09IDApID8gIiAqIiA6ICIgISIs CisJCQkgICAgIWRvbmUgPyAiIiA6ICh0cy0+dHNfc3RhdHVzID09IDApID8gIiAqIiA6ICIgISIp OworCQkJcHJpbnRmKCIgICAgICAgIFRYRjogJTA0eCBTZXE6ICVkIHN3dHJ5OiAlZCBBRERCQVc/ OiAlZCBET0JBVz86ICVkXG4iLAogCQkJICAgIGJmLT5iZl9zdGF0ZS5iZnNfZmxhZ3MsCiAJCQkg ICAgYmYtPmJmX3N0YXRlLmJmc19zZXFubywKIAkJCSAgICBiZi0+YmZfc3RhdGUuYmZzX3JldHJp ZXMsCiAJCQkgICAgYmYtPmJmX3N0YXRlLmJmc19hZGRlZGJhdywKLQkJCSAgICBiZi0+YmZfc3Rh dGUuYmZzX2RvYmF3LAorCQkJICAgIGJmLT5iZl9zdGF0ZS5iZnNfZG9iYXcpOworCQkJcHJpbnRm KCIgICAgICAgIFNFUU5PX0FTU0lHTkVEOiAlZCwgTkVFRF9TRVFOTzogJWRcbiIsCisJCQkgICAg YmYtPmJmX3N0YXRlLmJmc19zZXFub19hc3NpZ25lZCwKKwkJCSAgICBiZi0+YmZfc3RhdGUuYmZz X25lZWRfc2Vxbm8pOworCQkJcHJpbnRmKCIgICAgICAgICUwOHggJTA4eCAlMDh4ICUwOHggJTA4 eCAlMDh4XG4iLAogCQkJICAgIGRzLT5kc19jdGwwLCBkcy0+ZHNfY3RsMSwKLQkJCSAgICBkcy0+ ZHNfaHdbMF0sIGRzLT5kc19od1sxXSwgZHMtPmRzX2h3WzJdLCBkcy0+ZHNfaHdbM10pOworCQkJ ICAgIGRzLT5kc19od1swXSwgZHMtPmRzX2h3WzFdLAorCQkJICAgIGRzLT5kc19od1syXSwgZHMt PmRzX2h3WzNdKTsKIAkJCWlmIChhaC0+YWhfbWFnaWMgPT0gMHgyMDA2NTQxNikgewogCQkJCXBy aW50ZigiICAgICAgICAlMDh4ICUwOHggJTA4eCAlMDh4ICUwOHggJTA4eCAlMDh4ICUwOHhcbiIs CiAJCQkJICAgIGRzLT5kc19od1s0XSwgZHMtPmRzX2h3WzVdLCBkcy0+ZHNfaHdbNl0sCkluZGV4 OiBzeXMvZGV2L2F0aC9pZl9hdGh2YXIuaAo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBzeXMvZGV2L2F0aC9pZl9h dGh2YXIuaAkocmV2aXNpb24gMjMzMDg5KQorKysgc3lzL2Rldi9hdGgvaWZfYXRodmFyLmgJKHdv cmtpbmcgY29weSkKQEAgLTIxNSw2ICsyMTUsOCBAQAogCQlpbnQgYmZzX2lzbXJyOjE7CS8qIGRv IG11bHRpLXJhdGUgVFggcmV0cnkgKi8KIAkJaW50IGJmc19kb3Byb3Q6MTsJLyogZG8gUlRTL0NU UyBiYXNlZCBwcm90ZWN0aW9uICovCiAJCWludCBiZnNfZG9yYXRlbG9va3VwOjE7CS8qIGRvIHJh dGUgbG9va3VwIGJlZm9yZSBlYWNoIFRYICovCisJCWludCBiZnNfbmVlZF9zZXFubzoxOwkvKiBu ZWVkIHRvIGFzc2lnbiBhIHNlcW5vIGZvciBhZ2dyZWdhdGlvbiAqLworCQlpbnQgYmZzX3NlcW5v X2Fzc2lnbmVkOjE7CS8qIHNlcW5vIGhhcyBiZWVuIGFzc2lnbmVkICovCiAJCWludCBiZnNfbmZs OwkJLyogbmV4dCBmcmFnbWVudCBsZW5ndGggKi8KIAogCQkvKgpJbmRleDogc3lzL2Rldi9hdGgv aWZfYXRoX3R4X2h0LmMKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gc3lzL2Rldi9hdGgvaWZfYXRoX3R4X2h0LmMJ KHJldmlzaW9uIDIzMzA4OSkKKysrIHN5cy9kZXYvYXRoL2lmX2F0aF90eF9odC5jCSh3b3JraW5n IGNvcHkpCkBAIC02NDQsNyArNjQ0LDcgQEAKIGF0aF90eF9mb3JtX2FnZ3Ioc3RydWN0IGF0aF9z b2Z0YyAqc2MsIHN0cnVjdCBhdGhfbm9kZSAqYW4sIHN0cnVjdCBhdGhfdGlkICp0aWQsCiAgICAg YXRoX2J1ZmhlYWQgKmJmX3EpCiB7Ci0JLy9zdHJ1Y3QgaWVlZTgwMjExX25vZGUgKm5pID0gJmFu LT5hbl9ub2RlOworCXN0cnVjdCBpZWVlODAyMTFfbm9kZSAqbmkgPSAmYW4tPmFuX25vZGU7CiAJ c3RydWN0IGF0aF9idWYgKmJmLCAqYmZfZmlyc3QgPSBOVUxMLCAqYmZfcHJldiA9IE5VTEw7CiAJ aW50IG5mcmFtZXMgPSAwOwogCXVpbnQxNl90IGFnZ3JfbGltaXQgPSAwLCBhbCA9IDAsIGJwYWQg PSAwLCBhbF9kZWx0YSwgaF9iYXc7CkBAIC02NTIsNiArNjUyLDcgQEAKIAlpbnQgc3RhdHVzID0g QVRIX0FHR1JfRE9ORTsKIAlpbnQgcHJldl9mcmFtZXMgPSAwOwkvKiBYWFggZm9yIEFSNTQxNiBi dXJzdCwgbm90IGRvbmUgaGVyZSAqLwogCWludCBwcmV2X2FsID0gMDsJLyogWFhYIGFsc28gZm9y IEFSNTQxNiBidXJzdCAqLworCWludCBzZXFubzsKIAogCUFUSF9UWFFfTE9DS19BU1NFUlQoc2Mt PnNjX2FjMnFbdGlkLT5hY10pOwogCkBAIC03MDcsMTYgKzcwOCw2IEBACiAJCSAqLwogCiAJCS8q Ci0JCSAqIElmIHRoZSBwYWNrZXQgaGFzIGEgc2VxdWVuY2UgbnVtYmVyLCBkbyBub3QKLQkJICog c3RlcCBvdXRzaWRlIG9mIHRoZSBibG9jay1hY2sgd2luZG93LgotCQkgKi8KLQkJaWYgKCEgQkFX X1dJVEhJTih0YXAtPnR4YV9zdGFydCwgdGFwLT50eGFfd25kLAotCQkgICAgU0VRTk8oYmYtPmJm X3N0YXRlLmJmc19zZXFubykpKSB7Ci0JCSAgICBzdGF0dXMgPSBBVEhfQUdHUl9CQVdfQ0xPU0VE OwotCQkgICAgYnJlYWs7Ci0JCX0KLQotCQkvKgogCQkgKiBYWFggVE9ETzogQVI1NDE2IGhhcyBh biA4SyBhZ2dyZWdhdGlvbiBzaXplIGxpbWl0CiAJCSAqIHdoZW4gUlRTIGlzIGVuYWJsZWQsIGFu ZCBSVFMgaXMgcmVxdWlyZWQgZm9yIGR1YWwtc3RyZWFtCiAJCSAqIHJhdGVzLgpAQCAtNzQ0LDYg KzczNSw1OCBAQAogCQl9CiAKIAkJLyoKKwkJICogVE9ETzogSWYgaXQncyBfYmVmb3JlXyB0aGUg QkFXIGxlZnQgZWRnZSwgY29tcGxhaW4gdmVyeSBsb3VkbHkuCisJCSAqIFRoaXMgbWVhbnMgc29t ZXRoaW5nIChlbHNlKSBoYXMgc2xpZCB0aGUgbGVmdCBlZGdlIGFsb25nCisJCSAqIGJlZm9yZSB3 ZSBnb3QgYSBjaGFuY2UgdG8gYmUgVFhlZC4KKwkJICovCisKKwkJLyoKKwkJICogQ2hlY2sgaWYg d2UgaGF2ZSBzcGFjZSBpbiB0aGUgQkFXIGZvciB0aGlzIGZyYW1lIGJlZm9yZQorCQkgKiB3ZSBh ZGQgaXQuCisJCSAqCisJCSAqIHNlZSBhdGhfdHhfeG1pdF9hZ2dyKCkgZm9yIG1vcmUgaW5mby4K KwkJICovCisJCWlmIChiZi0+YmZfc3RhdGUuYmZzX2RvYmF3KSB7CisJCQlpZiAoISBCQVdfV0lU SElOKHRhcC0+dHhhX3N0YXJ0LCB0YXAtPnR4YV93bmQsCisJCQkgICAgbmktPm5pX3R4c2Vxc1ti Zi0+YmZfc3RhdGUuYmZzX3RpZF0pKSB7CisJCQkJc3RhdHVzID0gQVRIX0FHR1JfQkFXX0NMT1NF RDsKKwkJCQlicmVhazsKKwkJCX0KKwkJCS8qIFhYWCBjaGVjayBmb3IgYmZzX25lZWRfc2Vxbm8/ ICovCisJCQlpZiAoISBiZi0+YmZfc3RhdGUuYmZzX3NlcW5vX2Fzc2lnbmVkKSB7CisJCQkJc2Vx bm8gPSBhdGhfdHhfdGlkX3NlcW5vX2Fzc2lnbihzYywgbmksIGJmLCBiZi0+YmZfbSk7CisJCQkJ aWYgKHNlcW5vIDwgMCkgeworCQkJCQlkZXZpY2VfcHJpbnRmKHNjLT5zY19kZXYsCisJCQkJCSAg ICAiJXM6IGJmPSVwLCBodWgsIHNlcW5vPS0xP1xuIiwKKwkJCQkJICAgIF9fZnVuY19fLAorCQkJ CQkgICAgYmYpOworCQkJCQkvKiBYWFggd2hhdCBjYW4gd2UgZXZlbiBkbyBoZXJlPyAqLworCQkJ CX0KKwkJCQkvKiBGbHVzaCBzZXFubyB1cGRhdGUgdG8gUkFNICovCisJCQkJLyoKKwkJCQkgKiBY WFggVGhpcyBpcyByZXF1aXJlZCBiZWNhdXNlIHRoZSBkbWFzZXR1cAorCQkJCSAqIFhYWCBpcyBk b25lIGVhcmx5IHJhdGhlciB0aGFuIGF0IGRpc3BhdGNoCisJCQkJICogWFhYIHRpbWUuIEV3LCB3 ZSBzaG91bGQgZml4IHRoaXMhCisJCQkJICovCisJCQkJYnVzX2RtYW1hcF9zeW5jKHNjLT5zY19k bWF0LCBiZi0+YmZfZG1hbWFwLAorCQkJCSAgICBCVVNfRE1BU1lOQ19QUkVXUklURSk7CisJCQl9 CisJCX0KKworCQkvKgorCQkgKiBJZiB0aGUgcGFja2V0IGhhcyBhIHNlcXVlbmNlIG51bWJlciwg ZG8gbm90CisJCSAqIHN0ZXAgb3V0c2lkZSBvZiB0aGUgYmxvY2stYWNrIHdpbmRvdy4KKwkJICov CisJCWlmICghIEJBV19XSVRISU4odGFwLT50eGFfc3RhcnQsIHRhcC0+dHhhX3duZCwKKwkJICAg IFNFUU5PKGJmLT5iZl9zdGF0ZS5iZnNfc2Vxbm8pKSkgeworCQkJZGV2aWNlX3ByaW50ZihzYy0+ c2NfZGV2LAorCQkJICAgICIlczogYmY9JXAsIHNlcW5vPSVkLCBvdXRzaWRlPyFcbiIsCisJCQkg ICAgX19mdW5jX18sIGJmLCBTRVFOTyhiZi0+YmZfc3RhdGUuYmZzX3NlcW5vKSk7CisJCQlzdGF0 dXMgPSBBVEhfQUdHUl9CQVdfQ0xPU0VEOworCQkJYnJlYWs7CisJCX0KKworCQkvKgogCQkgKiB0 aGlzIHBhY2tldCBpcyBwYXJ0IG9mIGFuIGFnZ3JlZ2F0ZS4KIAkJICovCiAJCUFUSF9UWFFfUkVN T1ZFKHRpZCwgYmYsIGJmX2xpc3QpOwpJbmRleDogc3lzL2Rldi9hdGgvaWZfYXRoX3R4LmMKPT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PQotLS0gc3lzL2Rldi9hdGgvaWZfYXRoX3R4LmMJKHJldmlzaW9uIDIzMzA4OSkKKysr IHN5cy9kZXYvYXRoL2lmX2F0aF90eC5jCSh3b3JraW5nIGNvcHkpCkBAIC0xMDksOCArMTA5LDYg QEAKICAgICBpbnQgdGlkKTsKIHN0YXRpYyBpbnQgYXRoX3R4X2FtcGR1X3J1bm5pbmcoc3RydWN0 IGF0aF9zb2Z0YyAqc2MsIHN0cnVjdCBhdGhfbm9kZSAqYW4sCiAgICAgaW50IHRpZCk7Ci1zdGF0 aWMgaWVlZTgwMjExX3NlcSBhdGhfdHhfdGlkX3NlcW5vX2Fzc2lnbihzdHJ1Y3QgYXRoX3NvZnRj ICpzYywKLSAgICBzdHJ1Y3QgaWVlZTgwMjExX25vZGUgKm5pLCBzdHJ1Y3QgYXRoX2J1ZiAqYmYs IHN0cnVjdCBtYnVmICptMCk7CiBzdGF0aWMgaW50IGF0aF90eF9hY3Rpb25fZnJhbWVfb3ZlcnJp ZGVfcXVldWUoc3RydWN0IGF0aF9zb2Z0YyAqc2MsCiAgICAgc3RydWN0IGllZWU4MDIxMV9ub2Rl ICpuaSwgc3RydWN0IG1idWYgKm0wLCBpbnQgKnRpZCk7CiAKQEAgLTEzNzYsNyArMTM3NCw3IEBA CiAJaW50IGlzbWNhc3Q7CiAJY29uc3Qgc3RydWN0IGllZWU4MDIxMV9mcmFtZSAqd2g7CiAJaW50 IGlzX2FtcGR1LCBpc19hbXBkdV90eCwgaXNfYW1wZHVfcGVuZGluZzsKLQlpZWVlODAyMTFfc2Vx IHNlcW5vOworCS8vaWVlZTgwMjExX3NlcSBzZXFubzsKIAl1aW50OF90IHR5cGUsIHN1YnR5cGU7 CiAKIAkvKgpAQCAtMTQyOCw4ICsxNDI2LDkgQEAKIAlpc19hbXBkdV9wZW5kaW5nID0gYXRoX3R4 X2FtcGR1X3BlbmRpbmcoc2MsIEFUSF9OT0RFKG5pKSwgdGlkKTsKIAlpc19hbXBkdSA9IGlzX2Ft cGR1X3R4IHwgaXNfYW1wZHVfcGVuZGluZzsKIAotCURQUklOVEYoc2MsIEFUSF9ERUJVR19TV19U WCwgIiVzOiB0aWQ9JWQsIGFjPSVkLCBpc19hbXBkdT0lZFxuIiwKLQkgICAgX19mdW5jX18sIHRp ZCwgcHJpLCBpc19hbXBkdSk7CisJRFBSSU5URihzYywgQVRIX0RFQlVHX1NXX1RYLAorCSAgICAi JXM6IGJmPSVwLCB0aWQ9JWQsIGFjPSVkLCBpc19hbXBkdT0lZFxuIiwKKwkgICAgX19mdW5jX18s IGJmLCB0aWQsIHByaSwgaXNfYW1wZHUpOwogCiAJLyogTXVsdGljYXN0IGZyYW1lcyBnbyBvbnRv IHRoZSBzb2Z0d2FyZSBtdWx0aWNhc3QgcXVldWUgKi8KIAlpZiAoaXNtY2FzdCkKQEAgLTE0NDcs NiArMTQ0Niw5IEBACiAJLyogRG8gdGhlIGdlbmVyaWMgZnJhbWUgc2V0dXAgKi8KIAkvKiBYWFgg c2hvdWxkIGp1c3QgYnplcm8gdGhlIGJmX3N0YXRlPyAqLwogCWJmLT5iZl9zdGF0ZS5iZnNfZG9i YXcgPSAwOworCWJmLT5iZl9zdGF0ZS5iZnNfc2Vxbm9fYXNzaWduZWQgPSAwOworCWJmLT5iZl9z dGF0ZS5iZnNfbmVlZF9zZXFubyA9IDA7CisJYmYtPmJmX3N0YXRlLmJmc19zZXFubyA9IC0xOwkv KiBYWFggZGVidWdnaW5nICovCiAKIAkvKiBBLU1QRFUgVFg/IE1hbnVhbGx5IHNldCBzZXF1ZW5j ZSBudW1iZXIgKi8KIAkvKiBEb24ndCBkbyBpdCB3aGlsc3QgcGVuZGluZzsgdGhlIG5ldDgwMjEx IGxheWVyIHN0aWxsIGFzc2lnbnMgdGhlbSAqLwpAQCAtMTQ1OSwxOSArMTQ2MSwyNyBAQAogCQkg KiBkb24ndCBnZXQgYSBzZXF1ZW5jZSBudW1iZXIgZnJvbSB0aGUgY3VycmVudAogCQkgKiBUSUQg YW5kIHRodXMgbWVzcyB3aXRoIHRoZSBCQVcuCiAJCSAqLwotCQlzZXFubyA9IGF0aF90eF90aWRf c2Vxbm9fYXNzaWduKHNjLCBuaSwgYmYsIG0wKTsKKwkJLy9zZXFubyA9IGF0aF90eF90aWRfc2Vx bm9fYXNzaWduKHNjLCBuaSwgYmYsIG0wKTsKIAkJaWYgKElFRUU4MDIxMV9RT1NfSEFTX1NFUSh3 aCkgJiYKIAkJICAgIHN1YnR5cGUgIT0gSUVFRTgwMjExX0ZDMF9TVUJUWVBFX1FPU19OVUxMKSB7 CiAJCQliZi0+YmZfc3RhdGUuYmZzX2RvYmF3ID0gMTsKKwkJCWJmLT5iZl9zdGF0ZS5iZnNfbmVl ZF9zZXFubyA9IDE7CiAJCX0KIAkJQVRIX1RYUV9VTkxPQ0sodHhxKTsKKwl9IGVsc2UgeworCQkv KiBObyBBTVBEVSBUWCwgd2UndmUgYmVlbiBhc3NpZ25lZCBhIHNlcXVlbmNlIG51bWJlci4gKi8K KwkJaWYgKElFRUU4MDIxMV9RT1NfSEFTX1NFUSh3aCkpIHsKKwkJCWJmLT5iZl9zdGF0ZS5iZnNf c2Vxbm9fYXNzaWduZWQgPSAxOworCQkJYmYtPmJmX3N0YXRlLmJmc19zZXFubyA9CisJCQkgICAg TV9TRVFOT19HRVQobTApIDw8IElFRUU4MDIxMV9TRVFfU0VRX1NISUZUOworCQl9CiAJfQogCiAJ LyoKIAkgKiBJZiBuZWVkZWQsIHRoZSBzZXF1ZW5jZSBudW1iZXIgaGFzIGJlZW4gYXNzaWduZWQu CiAJICogU3F1aXJyZWwgaXQgYXdheSBzb21ld2hlcmUgZWFzeSB0byBnZXQgdG8uCiAJICovCi0J YmYtPmJmX3N0YXRlLmJmc19zZXFubyA9IE1fU0VRTk9fR0VUKG0wKSA8PCBJRUVFODAyMTFfU0VR X1NFUV9TSElGVDsKKwkvL2JmLT5iZl9zdGF0ZS5iZnNfc2Vxbm8gPSBNX1NFUU5PX0dFVChtMCkg PDwgSUVFRTgwMjExX1NFUV9TRVFfU0hJRlQ7CiAKIAkvKiBJcyBhbXBkdSBwZW5kaW5nPyBmZXRj aCB0aGUgc2Vxbm8gYW5kIHByaW50IGl0IG91dCAqLwogCWlmIChpc19hbXBkdV9wZW5kaW5nKQpA QCAtMTQ4OCw2ICsxNDk4LDEwIEBACiAJLyogQXQgdGhpcyBwb2ludCBtMCBjb3VsZCBoYXZlIGNo YW5nZWQhICovCiAJbTAgPSBiZi0+YmZfbTsKIAorCURQUklOVEYoc2MsIEFUSF9ERUJVR19TV19U WCwKKwkgICAgIiVzOiBET05FOiBiZj0lcCwgdGlkPSVkLCBhYz0lZCwgaXNfYW1wZHU9JWQsIGRv YmF3PSVkLCBzZXFubz0lZFxuIiwKKwkgICAgX19mdW5jX18sIGJmLCB0aWQsIHByaSwgaXNfYW1w ZHUsIGJmLT5iZl9zdGF0ZS5iZnNfZG9iYXcsIE1fU0VRTk9fR0VUKG0wKSk7CisKICNpZiAxCiAJ LyoKIAkgKiBJZiBpdCdzIGEgbXVsdGljYXN0IGZyYW1lLCBkbyBhIGRpcmVjdC1kaXNwYXRjaCB0 byB0aGUKQEAgLTE1MDYsNiArMTUyMCw4IEBACiAJICogcmVhY2hlZC4pCiAJICovCiAJaWYgKHR4 cSA9PSAmYXZwLT5hdl9tY2FzdHEpIHsKKwkJRFBSSU5URihzYywgQVRIX0RFQlVHX1NXX1RYX0NU UkwsCisJCSAgICAiJXM6IGJmPSVwOiBtY2FzdHE6IFRYJ2luZ1xuIiwgX19mdW5jX18sIGJmKTsK IAkJQVRIX1RYUV9MT0NLKHR4cSk7CiAJCWF0aF90eF94bWl0X25vcm1hbChzYywgdHhxLCBiZik7 CiAJCUFUSF9UWFFfVU5MT0NLKHR4cSk7CkBAIC0xNTE4LDYgKzE1MzQsOCBAQAogCQlBVEhfVFhR X1VOTE9DSyh0eHEpOwogCX0gZWxzZSB7CiAJCS8qIGFkZCB0byBzb2Z0d2FyZSBxdWV1ZSAqLwor CQlEUFJJTlRGKHNjLCBBVEhfREVCVUdfU1dfVFhfQ1RSTCwKKwkJICAgICIlczogYmY9JXA6IHN3 cTogVFgnaW5nXG4iLCBfX2Z1bmNfXywgYmYpOwogCQlhdGhfdHhfc3dxKHNjLCBuaSwgdHhxLCBi Zik7CiAJfQogI2Vsc2UKQEAgLTE5NjYsMjYgKzE5ODQsNTEgQEAKIAlpZiAoYmYtPmJmX3N0YXRl LmJmc19pc3JldHJpZWQpCiAJCXJldHVybjsKIAorCS8qCisJICogSWYgdGhpcyBvY2N1cnMgd2Un cmUgaW4gYSBsb3Qgb2YgdHJvdWJsZS4gIFdlIHNob3VsZCB0cnkgdG8KKwkgKiByZWNvdmVyIGZy b20gdGhpcyB3aXRob3V0IHRoZSBzZXNzaW9uIGhhbmdpbmc/CisJICovCisJaWYgKCEgYmYtPmJm X3N0YXRlLmJmc19zZXFub19hc3NpZ25lZCkgeworCQlkZXZpY2VfcHJpbnRmKHNjLT5zY19kZXYs CisJCSAgICAiJXM6IGJmPSVwLCBzZXFub19hc3NpZ25lZCBpcyAwPyFcbiIsIF9fZnVuY19fLCBi Zik7CisJCXJldHVybjsKKwl9CisKIAl0YXAgPSBhdGhfdHhfZ2V0X3R4X3RpZChhbiwgdGlkLT50 aWQpOwogCiAJaWYgKGJmLT5iZl9zdGF0ZS5iZnNfYWRkZWRiYXcpCiAJCWRldmljZV9wcmludGYo c2MtPnNjX2RldiwKLQkJICAgICIlczogcmUtYWRkZWQ/IHRpZD0lZCwgc2Vxbm8gJWQ7IHdpbmRv dyAlZDolZDsgIgorCQkgICAgIiVzOiByZS1hZGRlZD8gYmY9JXAsIHRpZD0lZCwgc2Vxbm8gJWQ7 IHdpbmRvdyAlZDolZDsgIgogCQkgICAgImJhdyBoZWFkPSVkIHRhaWw9JWRcbiIsCi0JCSAgICBf X2Z1bmNfXywgdGlkLT50aWQsIFNFUU5PKGJmLT5iZl9zdGF0ZS5iZnNfc2Vxbm8pLAorCQkgICAg X19mdW5jX18sIGJmLCB0aWQtPnRpZCwgU0VRTk8oYmYtPmJmX3N0YXRlLmJmc19zZXFubyksCiAJ CSAgICB0YXAtPnR4YV9zdGFydCwgdGFwLT50eGFfd25kLCB0aWQtPmJhd19oZWFkLAogCQkgICAg dGlkLT5iYXdfdGFpbCk7CiAKIAkvKgorCSAqIFZlcmlmeSB0aGF0IHRoZSBnaXZlbiBzZXF1ZW5j ZSBudW1iZXIgaXMgbm90IG91dHNpZGUgb2YgdGhlCisJICogQkFXLiAgQ29tcGxhaW4gbG91ZGx5 IGlmIHRoYXQncyB0aGUgY2FzZS4KKwkgKi8KKwlpZiAoISBCQVdfV0lUSElOKHRhcC0+dHhhX3N0 YXJ0LCB0YXAtPnR4YV93bmQsCisJICAgIFNFUU5PKGJmLT5iZl9zdGF0ZS5iZnNfc2Vxbm8pKSkg eworCQlkZXZpY2VfcHJpbnRmKHNjLT5zY19kZXYsCisJCSAgICAiJXM6IGJmPSVwOiBvdXRzaWRl IG9mIEJBVz8/IHRpZD0lZCwgc2Vxbm8gJWQ7IHdpbmRvdyAlZDolZDsgIgorCQkgICAgImJhdyBo ZWFkPSVkIHRhaWw9JWRcbiIsCisJCSAgICBfX2Z1bmNfXywgYmYsIHRpZC0+dGlkLCBTRVFOTyhi Zi0+YmZfc3RhdGUuYmZzX3NlcW5vKSwKKwkJICAgIHRhcC0+dHhhX3N0YXJ0LCB0YXAtPnR4YV93 bmQsIHRpZC0+YmF3X2hlYWQsCisJCSAgICB0aWQtPmJhd190YWlsKTsKKworCX0KKworCS8qCiAJ ICogbmktPm5pX3R4c2Vxc1tdIGlzIHRoZSBjdXJyZW50bHkgYWxsb2NhdGVkIHNlcW5vLgogCSAq IHRoZSB0eGEgc3RhdGUgY29udGFpbnMgdGhlIGN1cnJlbnQgYmF3IHN0YXJ0LgogCSAqLwogCWlu ZGV4ICA9IEFUSF9CQV9JTkRFWCh0YXAtPnR4YV9zdGFydCwgU0VRTk8oYmYtPmJmX3N0YXRlLmJm c19zZXFubykpOwogCWNpbmRleCA9ICh0aWQtPmJhd19oZWFkICsgaW5kZXgpICYgKEFUSF9USURf TUFYX0JVRlMgLSAxKTsKIAlEUFJJTlRGKHNjLCBBVEhfREVCVUdfU1dfVFhfQkFXLAotCSAgICAi JXM6IHRpZD0lZCwgc2Vxbm8gJWQ7IHdpbmRvdyAlZDolZDsgaW5kZXg9JWQgY2luZGV4PSVkICIK KwkgICAgIiVzOiBiZj0lcCwgdGlkPSVkLCBzZXFubyAlZDsgd2luZG93ICVkOiVkOyBpbmRleD0l ZCBjaW5kZXg9JWQgIgogCSAgICAiYmF3IGhlYWQ9JWQgdGFpbD0lZFxuIiwKLQkgICAgX19mdW5j X18sIHRpZC0+dGlkLCBTRVFOTyhiZi0+YmZfc3RhdGUuYmZzX3NlcW5vKSwKKwkgICAgX19mdW5j X18sIGJmLCB0aWQtPnRpZCwgU0VRTk8oYmYtPmJmX3N0YXRlLmJmc19zZXFubyksCiAJICAgIHRh cC0+dHhhX3N0YXJ0LCB0YXAtPnR4YV93bmQsIGluZGV4LCBjaW5kZXgsIHRpZC0+YmF3X2hlYWQs CiAJICAgIHRpZC0+YmF3X3RhaWwpOwogCkBAIC0yMDg4LDkgKzIxMzEsOSBAQAogCWNpbmRleCA9 ICh0aWQtPmJhd19oZWFkICsgaW5kZXgpICYgKEFUSF9USURfTUFYX0JVRlMgLSAxKTsKIAogCURQ UklOVEYoc2MsIEFUSF9ERUJVR19TV19UWF9CQVcsCi0JICAgICIlczogdGlkPSVkLCBiYXc9JWQ6 JWQsIHNlcW5vPSVkLCBpbmRleD0lZCwgY2luZGV4PSVkLCAiCisJICAgICIlczogYmY9JXA6IHRp ZD0lZCwgYmF3PSVkOiVkLCBzZXFubz0lZCwgaW5kZXg9JWQsIGNpbmRleD0lZCwgIgogCSAgICAi YmF3IGhlYWQ9JWQsIHRhaWw9JWRcbiIsCi0JICAgIF9fZnVuY19fLCB0aWQtPnRpZCwgdGFwLT50 eGFfc3RhcnQsIHRhcC0+dHhhX3duZCwgc2Vxbm8sIGluZGV4LAorCSAgICBfX2Z1bmNfXywgYmYs IHRpZC0+dGlkLCB0YXAtPnR4YV9zdGFydCwgdGFwLT50eGFfd25kLCBzZXFubywgaW5kZXgsCiAJ ICAgIGNpbmRleCwgdGlkLT5iYXdfaGVhZCwgdGlkLT5iYXdfdGFpbCk7CiAKIAkvKgpAQCAtMjE3 MSwxMSArMjIxNCw0MiBAQAogfQogCiAvKgorICogUmV0dXJuIHdoZXRoZXIgYSBzZXF1ZW5jZSBu dW1iZXIgaXMgYWN0dWFsbHkgcmVxdWlyZWQuCisgKgorICogQSBzZXF1ZW5jZSBudW1iZXIgbXVz dCBvbmx5IGJlIGFsbG9jYXRlZCBhdCB0aGUgdGltZSB0aGF0IGEgZnJhbWUKKyAqIGlzIGNvbnNp ZGVyZWQgZm9yIGFkZGl0aW9uIHRvIHRoZSBCQVcvYWdncmVnYXRlIGFuZCBiZWluZyBUWGVkLgor ICogVGhlIHNlcXVlbmNlIG51bWJlciBtdXN0IG5vdCBiZSBhbGxvY2F0ZWQgYmVmb3JlIHRoZSBm cmFtZQorICogaXMgYWRkZWQgdG8gdGhlIEJBVyAocHJvdGVjdGVkIGJ5IHRoZSBzYW1lIGxvY2sg aW5zdGFuY2UpCisgKiBvdGhlcndpc2UgYSB0aGUgbXVsdGktZW50cmFudCBUWCBwYXRoIG1heSBy ZXN1bHQgaW4gYSBsYXRlciBzZXFubworICogYmVpbmcgYWRkZWQgdG8gdGhlIEJBVyBmaXJzdC4g IFRoZSBzdWJzZXF1ZW50IGFkZGl0aW9uIG9mIHRoZQorICogZWFybGllciBzZXFubyB3b3VsZCB0 aGVuIG5vdCBnbyBpbnRvIHRoZSBCQVcgYXMgaXQncyBub3cgb3V0c2lkZQorICogb2Ygc2FpZCBC QVcuCisgKgorICogVGhpcyByb3V0aW5lIGlzIHVzZWQgYnkgYXRoX3R4X3N0YXJ0KCkgdG8gbWFy ayB3aGV0aGVyIHRoZSBmcmFtZQorICogc2hvdWxkIGdldCBhIHNlcXVlbmNlIG51bWJlciBiZWZv cmUgYWRkaW5nIGl0IHRvIHRoZSBCQVcuCisgKgorICogVGhlbiB0aGUgYWN0dWFsIGFnZ3JlZ2F0 ZSBUWCByb3V0aW5lcyB3aWxsIGNoZWNrIHdoZXRoZXIgdGhpcworICogZmxhZyBpcyBzZXQgYW5k IGlmIHRoZSBmcmFtZSBuZWVkcyB0byBnbyBpbnRvIHRoZSBCQVcsIGl0J2xsCisgKiBoYXZlIGEg c2VxdWVuY2UgbnVtYmVyIGFsbG9jYXRlZCBmb3IgaXQuCisgKi8KKyNpZiAwCitzdGF0aWMgaW50 CithdGhfdHhfc2Vxbm9fcmVxdWlyZWQoc3RydWN0IGF0aF9zb2Z0YyAqc2MsIHN0cnVjdCBpZWVl ODAyMTFfbm9kZSAqbmksCisgICAgc3RydWN0IGF0aF9idWYgKmJmLCBzdHJ1Y3QgbWJ1ZiAqbTAp Cit7Cit9CisjZW5kaWYKKworLyoKICAqIEFzc2lnbiBhIHNlcXVlbmNlIG51bWJlciBtYW51YWxs eSB0byB0aGUgZ2l2ZW4gZnJhbWUuCiAgKgogICogVGhpcyBzaG91bGQgb25seSBiZSBjYWxsZWQg Zm9yIEEtTVBEVSBUWCBmcmFtZXMuCisgKgorICogSWYgdGhpcyBpcyBjYWxsZWQgYWZ0ZXIgdGhl IGluaXRpYWwgZnJhbWUgc2V0dXAsIG1ha2Ugc3VyZSB5b3UndmUgZmx1c2hlZAorICogdGhlIERN QSBtYXAgb3IgeW91J2xsIHJpc2sgc2VuZGluZyBzdGFsZSBkYXRhIHRvIHRoZSBOSUMuICBUaGlz IHJvdXRpbmUKKyAqIHVwZGF0ZXMgdGhlIGFjdHVhbCBmcmFtZSBjb250ZW50cyB3aXRoIHRoZSBy ZWxldmFudCBzZXFuby4KICAqLwotc3RhdGljIGllZWU4MDIxMV9zZXEKK2ludAogYXRoX3R4X3Rp ZF9zZXFub19hc3NpZ24oc3RydWN0IGF0aF9zb2Z0YyAqc2MsIHN0cnVjdCBpZWVlODAyMTFfbm9k ZSAqbmksCiAgICAgc3RydWN0IGF0aF9idWYgKmJmLCBzdHJ1Y3QgbWJ1ZiAqbTApCiB7CkBAIC0y MTg4LDkgKzIyNjIsMjMgQEAKIAl3aCA9IG10b2QobTAsIHN0cnVjdCBpZWVlODAyMTFfZnJhbWUg Kik7CiAJcHJpID0gTV9XTUVfR0VUQUMobTApOwkJCS8qIGhvbm9yIGNsYXNzaWZpY2F0aW9uICov CiAJdGlkID0gV01FX0FDX1RPX1RJRChwcmkpOwotCURQUklOVEYoc2MsIEFUSF9ERUJVR19TV19U WCwgIiVzOiBwcmk9JWQsIHRpZD0lZCwgcW9zIGhhcyBzZXE9JWRcbiIsCi0JICAgIF9fZnVuY19f LCBwcmksIHRpZCwgSUVFRTgwMjExX1FPU19IQVNfU0VRKHdoKSk7CisJRFBSSU5URihzYywgQVRI X0RFQlVHX1NXX1RYLAorCSAgICAiJXM6IGJmPSVwLCBwcmk9JWQsIHRpZD0lZCwgcW9zIGhhcyBz ZXE9JWRcbiIsCisJICAgIF9fZnVuY19fLCBiZiwgcHJpLCB0aWQsIElFRUU4MDIxMV9RT1NfSEFT X1NFUSh3aCkpOwogCisJaWYgKCEgYmYtPmJmX3N0YXRlLmJmc19uZWVkX3NlcW5vKSB7CisJCWRl dmljZV9wcmludGYoc2MtPnNjX2RldiwgIiVzOiBiZj0lcDogbmVlZF9zZXFubyBub3Qgc2V0PyFc biIsCisJCSAgICBfX2Z1bmNfXywgYmYpOworCQlyZXR1cm4gLTE7CisJfQorCS8qIFhYWCBjaGVj ayBmb3IgYmZzX25lZWRfc2Vxbm8/ICovCisJaWYgKGJmLT5iZl9zdGF0ZS5iZnNfc2Vxbm9fYXNz aWduZWQpIHsKKwkJZGV2aWNlX3ByaW50ZihzYy0+c2NfZGV2LAorCQkgICAgIiVzOiBiZj0lcDog c2Vxbm8gYWxyZWFkeSBhc3NpZ25lZCAoJWQpPyFcbiIsCisJCSAgICBfX2Z1bmNfXywgYmYsIFNF UU5PKGJmLT5iZl9zdGF0ZS5iZnNfc2Vxbm8pKTsKKwkJcmV0dXJuIGJmLT5iZl9zdGF0ZS5iZnNf c2Vxbm8gPj4gSUVFRTgwMjExX1NFUV9TRVFfU0hJRlQ7CisJfQorCiAJLyogWFhYIElzIGl0IGEg Y29udHJvbCBmcmFtZT8gSWdub3JlICovCiAKIAkvKiBEb2VzIHRoZSBwYWNrZXQgcmVxdWlyZSBh IHNlcXVlbmNlIG51bWJlcj8gKi8KQEAgLTIyMTcsOSArMjMwNSwxNCBAQAogCX0KIAkqKHVpbnQx Nl90ICopJndoLT5pX3NlcVswXSA9IGh0b2xlMTYoc2Vxbm8gPDwgSUVFRTgwMjExX1NFUV9TRVFf U0hJRlQpOwogCU1fU0VRTk9fU0VUKG0wLCBzZXFubyk7CisJYmYtPmJmX3N0YXRlLmJmc19zZXFu byA9IHNlcW5vIDw8IElFRUU4MDIxMV9TRVFfU0VRX1NISUZUOworCWJmLT5iZl9zdGF0ZS5iZnNf c2Vxbm9fYXNzaWduZWQgPSAxOwogCiAJLyogUmV0dXJuIHNvIGNhbGxlciBjYW4gZG8gc29tZXRo aW5nIHdpdGggaXQgaWYgbmVlZGVkICovCi0JRFBSSU5URihzYywgQVRIX0RFQlVHX1NXX1RYLCAi JXM6ICAtPiBzZXFubz0lZFxuIiwgX19mdW5jX18sIHNlcW5vKTsKKwlEUFJJTlRGKHNjLCBBVEhf REVCVUdfU1dfVFgsICIlczogYmY9JXA6ICAtPiBzZXFubz0lZFxuIiwKKwkgICAgX19mdW5jX18s CisJICAgIGJmLAorCSAgICBzZXFubyk7CiAJcmV0dXJuIHNlcW5vOwogfQogCkBAIC0yMjMxLDkg KzIzMjQsMTEgQEAKIHN0YXRpYyB2b2lkCiBhdGhfdHhfeG1pdF9hZ2dyKHN0cnVjdCBhdGhfc29m dGMgKnNjLCBzdHJ1Y3QgYXRoX25vZGUgKmFuLCBzdHJ1Y3QgYXRoX2J1ZiAqYmYpCiB7CisJc3Ry dWN0IGllZWU4MDIxMV9ub2RlICpuaSA9ICZhbi0+YW5fbm9kZTsKIAlzdHJ1Y3QgYXRoX3RpZCAq dGlkID0gJmFuLT5hbl90aWRbYmYtPmJmX3N0YXRlLmJmc190aWRdOwogCXN0cnVjdCBhdGhfdHhx ICp0eHEgPSBiZi0+YmZfc3RhdGUuYmZzX3R4cTsKIAlzdHJ1Y3QgaWVlZTgwMjExX3R4X2FtcGR1 ICp0YXA7CisJaW50IHNlcW5vOwogCiAJQVRIX1RYUV9MT0NLX0FTU0VSVCh0eHEpOwogCkBAIC0y MjQ1LDEwICsyMzQwLDYzIEBACiAJCXJldHVybjsKIAl9CiAKKwkvKgorCSAqIFRPRE86IElmIGl0 J3MgX2JlZm9yZV8gdGhlIEJBVyBsZWZ0IGVkZ2UsIGNvbXBsYWluIHZlcnkgbG91ZGx5LgorCSAq IFRoaXMgbWVhbnMgc29tZXRoaW5nIChlbHNlKSBoYXMgc2xpZCB0aGUgbGVmdCBlZGdlIGFsb25n CisJICogYmVmb3JlIHdlIGdvdCBhIGNoYW5jZSB0byBiZSBUWGVkLgorCSAqLworCisJLyoKKwkg KiBJcyB0aGVyZSBzcGFjZSBpbiB0aGlzIEJBVyBmb3IgYW5vdGhlciBmcmFtZT8KKwkgKiBJZiBu b3QsIGRvbid0IGJvdGhlciB0cnlpbmcgdG8gc2NoZWR1bGUgaXQ7IGp1c3QKKwkgKiB0aHJvdyBp dCBiYWNrIG9uIHRoZSBxdWV1ZS4KKwkgKgorCSAqIElmIHdlIGFsbG9jYXRlIHRoZSBzZXF1ZW5j ZSBudW1iZXIgYmVmb3JlIHdlIGFkZAorCSAqIGl0IHRvIHRoZSBCQVcsIHdlIHJpc2sgcmFjaW5n IHdpdGggYW5vdGhlciBUWAorCSAqIHRocmVhZCB0aGF0IGdldHMgaW4gYSBmcmFtZSBpbnRvIHRo ZSBCQVcgd2l0aAorCSAqIHNlcW5vIGdyZWF0ZXIgdGhhbiBvdXJzLiAgV2UnZCB0aGVuIGZhaWwg dGhlCisJICogYmVsb3cgY2hlY2sgYW5kIHRocm93IHRoZSBmcmFtZSBvbiB0aGUgdGFpbCBvZgor CSAqIHRoZSBxdWV1ZS4gIFRoZSBzZW5kZXIgd291bGQgdGhlbiBoYXZlIGEgaG9sZS4KKwkgKgor CSAqIFhYWCBhZ2Fpbiwgd2UncmUgcHJvdGVjdGluZyBuaS0+bmlfdHhzZXFzW3RpZF0KKwkgKiBi ZWhpbmQgdGhpcyBoYXJkd2FyZSBUWFEgbG9jaywgbGlrZSB0aGUgcmVzdCBvZgorCSAqIHRoZSBU SURzIHRoYXQgbWFwIHRvIGl0LiAgVWdoLgorCSAqLworCWlmIChiZi0+YmZfc3RhdGUuYmZzX2Rv YmF3KSB7CisJCWlmICghIEJBV19XSVRISU4odGFwLT50eGFfc3RhcnQsIHRhcC0+dHhhX3duZCwK KwkJICAgIG5pLT5uaV90eHNlcXNbYmYtPmJmX3N0YXRlLmJmc190aWRdKSkgeworCQkJQVRIX1RY UV9JTlNFUlRfVEFJTCh0aWQsIGJmLCBiZl9saXN0KTsKKwkJCWF0aF90eF90aWRfc2NoZWQoc2Ms IHRpZCk7CisJCQlyZXR1cm47CisJCX0KKwkJaWYgKCEgYmYtPmJmX3N0YXRlLmJmc19zZXFub19h c3NpZ25lZCkgeworCQkJc2Vxbm8gPSBhdGhfdHhfdGlkX3NlcW5vX2Fzc2lnbihzYywgbmksIGJm LCBiZi0+YmZfbSk7CisJCQlpZiAoc2Vxbm8gPCAwKSB7CisJCQkJZGV2aWNlX3ByaW50ZihzYy0+ c2NfZGV2LAorCQkJCSAgICAiJXM6IGJmPSVwLCBodWgsIHNlcW5vPS0xP1xuIiwKKwkJCQkgICAg X19mdW5jX18sCisJCQkJICAgIGJmKTsKKwkJCQkvKiBYWFggd2hhdCBjYW4gd2UgZXZlbiBkbyBo ZXJlPyAqLworCQkJfQorCQkJLyogRmx1c2ggc2Vxbm8gdXBkYXRlIHRvIFJBTSAqLworCQkJLyoK KwkJCSAqIFhYWCBUaGlzIGlzIHJlcXVpcmVkIGJlY2F1c2UgdGhlIGRtYXNldHVwCisJCQkgKiBY WFggaXMgZG9uZSBlYXJseSByYXRoZXIgdGhhbiBhdCBkaXNwYXRjaAorCQkJICogWFhYIHRpbWUu IEV3LCB3ZSBzaG91bGQgZml4IHRoaXMhCisJCQkgKi8KKwkJCWJ1c19kbWFtYXBfc3luYyhzYy0+ c2NfZG1hdCwgYmYtPmJmX2RtYW1hcCwKKwkJCSAgICBCVVNfRE1BU1lOQ19QUkVXUklURSk7CisJ CX0KKwl9CisKIAkvKiBvdXRzaWRlIGJhdz8gcXVldWUgKi8KIAlpZiAoYmYtPmJmX3N0YXRlLmJm c19kb2JhdyAmJgogCSAgICAoISBCQVdfV0lUSElOKHRhcC0+dHhhX3N0YXJ0LCB0YXAtPnR4YV93 bmQsCiAJICAgIFNFUU5PKGJmLT5iZl9zdGF0ZS5iZnNfc2Vxbm8pKSkpIHsKKwkJZGV2aWNlX3By aW50ZihzYy0+c2NfZGV2LAorCQkgICAgIiVzOiBiZj0lcCwgc2hvdWxkbid0IGJlIG91dHNpZGUg QkFXIG5vdz8hXG4iLAorCQkgICAgX19mdW5jX18sCisJCSAgICBiZik7CiAJCUFUSF9UWFFfSU5T RVJUX1RBSUwodGlkLCBiZiwgYmZfbGlzdCk7CiAJCWF0aF90eF90aWRfc2NoZWQoc2MsIHRpZCk7 CiAJCXJldHVybjsKQEAgLTIzMDMsOCArMjQ1MSw4IEBACiAJdGlkID0gYXRoX3R4X2dldHRpZChz YywgbTApOwogCWF0aWQgPSAmYW4tPmFuX3RpZFt0aWRdOwogCi0JRFBSSU5URihzYywgQVRIX0RF QlVHX1NXX1RYLCAiJXM6IGJmPSVwLCBwcmk9JWQsIHRpZD0lZCwgcW9zPSVkXG4iLAotCSAgICBf X2Z1bmNfXywgYmYsIHByaSwgdGlkLCBJRUVFODAyMTFfUU9TX0hBU19TRVEod2gpKTsKKwlEUFJJ TlRGKHNjLCBBVEhfREVCVUdfU1dfVFgsICIlczogYmY9JXAsIHByaT0lZCwgdGlkPSVkLCBxb3M9 JWQsIHNlcW5vPSVkXG4iLAorCSAgICBfX2Z1bmNfXywgYmYsIHByaSwgdGlkLCBJRUVFODAyMTFf UU9TX0hBU19TRVEod2gpLCBTRVFOTyhiZi0+YmZfc3RhdGUuYmZzX3NlcW5vKSk7CiAKIAkvKiBT ZXQgbG9jYWwgcGFja2V0IHN0YXRlLCB1c2VkIHRvIHF1ZXVlIHBhY2tldHMgdG8gaGFyZHdhcmUg Ki8KIAliZi0+YmZfc3RhdGUuYmZzX3RpZCA9IHRpZDsKQEAgLTIzMjAsMzQgKzI0NjgsMzQgQEAK IAlBVEhfVFhRX0xPQ0sodHhxKTsKIAlpZiAoYXRpZC0+cGF1c2VkKSB7CiAJCS8qIFRJRCBpcyBw YXVzZWQsIHF1ZXVlICovCi0JCURQUklOVEYoc2MsIEFUSF9ERUJVR19TV19UWCwgIiVzOiBwYXVz ZWRcbiIsIF9fZnVuY19fKTsKKwkJRFBSSU5URihzYywgQVRIX0RFQlVHX1NXX1RYLCAiJXM6IGJm PSVwOiBwYXVzZWRcbiIsIF9fZnVuY19fLCBiZik7CiAJCUFUSF9UWFFfSU5TRVJUX1RBSUwoYXRp ZCwgYmYsIGJmX2xpc3QpOwogCX0gZWxzZSBpZiAoYXRoX3R4X2FtcGR1X3BlbmRpbmcoc2MsIGFu LCB0aWQpKSB7CiAJCS8qIEFNUERVIHBlbmRpbmc7IHF1ZXVlICovCi0JCURQUklOVEYoc2MsIEFU SF9ERUJVR19TV19UWCwgIiVzOiBwZW5kaW5nXG4iLCBfX2Z1bmNfXyk7CisJCURQUklOVEYoc2Ms IEFUSF9ERUJVR19TV19UWCwgIiVzOiBiZj0lcDogcGVuZGluZ1xuIiwgX19mdW5jX18sIGJmKTsK IAkJQVRIX1RYUV9JTlNFUlRfVEFJTChhdGlkLCBiZiwgYmZfbGlzdCk7CiAJCS8qIFhYWCBzY2hl ZD8gKi8KIAl9IGVsc2UgaWYgKGF0aF90eF9hbXBkdV9ydW5uaW5nKHNjLCBhbiwgdGlkKSkgewog CQkvKiBBTVBEVSBydW5uaW5nLCBhdHRlbXB0IGRpcmVjdCBkaXNwYXRjaCBpZiBwb3NzaWJsZSAq LwogCQlpZiAodHhxLT5heHFfZGVwdGggPCBzYy0+c2NfaHdxX2xpbWl0KSB7CisJCQlEUFJJTlRG KHNjLCBBVEhfREVCVUdfU1dfVFgsCisJCQkgICAgIiVzOiBiZj0lcDogeG1pdF9hZ2dyXG4iLAor CQkJICAgIF9fZnVuY19fLCBiZik7CiAJCQlhdGhfdHhfeG1pdF9hZ2dyKHNjLCBhbiwgYmYpOwot CQkJRFBSSU5URihzYywgQVRIX0RFQlVHX1NXX1RYLAotCQkJICAgICIlczogeG1pdF9hZ2dyXG4i LAotCQkJICAgIF9fZnVuY19fKTsKIAkJfSBlbHNlIHsKIAkJCURQUklOVEYoc2MsIEFUSF9ERUJV R19TV19UWCwKLQkJCSAgICAiJXM6IGFtcGR1OyBzd3EnaW5nXG4iLAotCQkJICAgIF9fZnVuY19f KTsKKwkJCSAgICAiJXM6IGJmPSVwOiBhbXBkdTsgc3dxJ2luZ1xuIiwKKwkJCSAgICBfX2Z1bmNf XywgYmYpOwogCQkJQVRIX1RYUV9JTlNFUlRfVEFJTChhdGlkLCBiZiwgYmZfbGlzdCk7CiAJCQlh dGhfdHhfdGlkX3NjaGVkKHNjLCBhdGlkKTsKIAkJfQogCX0gZWxzZSBpZiAodHhxLT5heHFfZGVw dGggPCBzYy0+c2NfaHdxX2xpbWl0KSB7CiAJCS8qIEFNUERVIG5vdCBydW5uaW5nLCBhdHRlbXB0 IGRpcmVjdCBkaXNwYXRjaCAqLwotCQlEUFJJTlRGKHNjLCBBVEhfREVCVUdfU1dfVFgsICIlczog eG1pdF9ub3JtYWxcbiIsIF9fZnVuY19fKTsKKwkJRFBSSU5URihzYywgQVRIX0RFQlVHX1NXX1RY LCAiJXM6IGJmPSVwOiB4bWl0X25vcm1hbFxuIiwgX19mdW5jX18sIGJmKTsKIAkJYXRoX3R4X3ht aXRfbm9ybWFsKHNjLCB0eHEsIGJmKTsKIAl9IGVsc2UgewogCQkvKiBCdXN5OyBxdWV1ZSAqLwot CQlEUFJJTlRGKHNjLCBBVEhfREVCVUdfU1dfVFgsICIlczogc3dxJ2luZ1xuIiwgX19mdW5jX18p OworCQlEUFJJTlRGKHNjLCBBVEhfREVCVUdfU1dfVFgsICIlczogYmY9JXA6IHN3cSdpbmdcbiIs IF9fZnVuY19fLCBiZik7CiAJCUFUSF9UWFFfSU5TRVJUX1RBSUwoYXRpZCwgYmYsIGJmX2xpc3Qp OwogCQlhdGhfdHhfdGlkX3NjaGVkKHNjLCBhdGlkKTsKIAl9CkBAIC0yNDc4LDExICsyNjI2LDEx IEBACiAKIAkJaWYgKHQgPT0gMCkgewogCQkJZGV2aWNlX3ByaW50ZihzYy0+c2NfZGV2LAotCQkJ ICAgICIlczogbm9kZSAlcDogdGlkICVkOiB0eHFfZGVwdGg9JWQsICIKKwkJCSAgICAiJXM6IG5v ZGUgJXA6IGJmPSVwOiB0aWQgJWQ6IHR4cV9kZXB0aD0lZCwgIgogCQkJICAgICJ0eHFfYWdncl9k ZXB0aD0lZCwgc2NoZWQ9JWQsIHBhdXNlZD0lZCwgIgogCQkJICAgICJod3FfZGVwdGg9JWQsIGlu Y29tcD0lZCwgYmF3X2hlYWQ9JWQsICIKIAkJCSAgICAiYmF3X3RhaWw9JWQgdHhhX3N0YXJ0PSVk LCBuaV90eHNlcXM9JWRcbiIsCi0JCQkgICAgIF9fZnVuY19fLCBuaSwgdGlkLT50aWQsIHR4cS0+ YXhxX2RlcHRoLAorCQkJICAgICBfX2Z1bmNfXywgbmksIGJmLCB0aWQtPnRpZCwgdHhxLT5heHFf ZGVwdGgsCiAJCQkgICAgIHR4cS0+YXhxX2FnZ3JfZGVwdGgsIHRpZC0+c2NoZWQsIHRpZC0+cGF1 c2VkLAogCQkJICAgICB0aWQtPmh3cV9kZXB0aCwgdGlkLT5pbmNvbXAsIHRpZC0+YmF3X2hlYWQs CiAJCQkgICAgIHRpZC0+YmF3X3RhaWwsIHRhcCA9PSBOVUxMID8gLTEgOiB0YXAtPnR4YV9zdGFy dCwKQEAgLTI0OTMsNyArMjY0MSw3IEBACiAJCQkgICAgbXRvZChiZi0+YmZfbSwgY29uc3QgdWlu dDhfdCAqKSwKIAkJCSAgICBiZi0+YmZfbS0+bV9sZW4sIDAsIC0xKTsKIAotCQkJdCA9IDE7CisJ CQkvL3QgPSAxOwogCQl9CiAKIApJbmRleDogc3lzL2Rldi9hdGgvaWZfYXRoX3R4LmgKPT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PQotLS0gc3lzL2Rldi9hdGgvaWZfYXRoX3R4LmgJKHJldmlzaW9uIDIzMzA4OSkKKysrIHN5 cy9kZXYvYXRoL2lmX2F0aF90eC5oCSh3b3JraW5nIGNvcHkpCkBAIC0xMDksNiArMTA5LDggQEAK ICAgICBzdHJ1Y3QgYXRoX3RpZCAqdGlkLCBzdHJ1Y3QgYXRoX2J1ZiAqYmYpOwogZXh0ZXJuIHN0 cnVjdCBpZWVlODAyMTFfdHhfYW1wZHUgKiBhdGhfdHhfZ2V0X3R4X3RpZChzdHJ1Y3QgYXRoX25v ZGUgKmFuLAogICAgIGludCB0aWQpOworZXh0ZXJuIGludCBhdGhfdHhfdGlkX3NlcW5vX2Fzc2ln bihzdHJ1Y3QgYXRoX3NvZnRjICpzYywKKyAgICBzdHJ1Y3QgaWVlZTgwMjExX25vZGUgKm5pLCBz dHJ1Y3QgYXRoX2J1ZiAqYmYsIHN0cnVjdCBtYnVmICptMCk7CiAKIC8qIFRYIGFkZGJhIGhhbmRs aW5nICovCiBleHRlcm4JaW50IGF0aF9hZGRiYV9yZXF1ZXN0KHN0cnVjdCBpZWVlODAyMTFfbm9k ZSAqbmksCg== --e89a8ffbaecbfc7ee204bb91ebe8-- From owner-freebsd-wireless@FreeBSD.ORG Mon Mar 19 10:34:28 2012 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C9346106564A; Mon, 19 Mar 2012 10:34:28 +0000 (UTC) (envelope-from vince@unsane.co.uk) Received: from unsane.co.uk (unsane-pt.tunnel.tserv5.lon1.ipv6.he.net [IPv6:2001:470:1f08:110::2]) by mx1.freebsd.org (Postfix) with ESMTP id 532DC8FC12; Mon, 19 Mar 2012 10:34:28 +0000 (UTC) Received: from vhoffman.lon.namesco.net (lon.namesco.net [195.7.254.102]) (authenticated bits=0) by unsane.co.uk (8.14.5/8.14.5) with ESMTP id q2JAYQOk064312 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 19 Mar 2012 10:34:27 GMT (envelope-from vince@unsane.co.uk) Message-ID: <4F670BB2.6030708@unsane.co.uk> Date: Mon, 19 Mar 2012 10:34:26 +0000 From: Vincent Hoffman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Adrian Chadd References: <4F59DD98.8080905@unsane.co.uk> <4F5AA149.8000904@unsane.co.uk> <4F5BDF3C.8070605@unsane.co.uk> <4F5C0302.8090403@unsane.co.uk> In-Reply-To: X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-wireless@freebsd.org Subject: Re: ath0 timeout was "Re: (more) bugs fixed in -HEAD, AP mode is now mostly (again) stable!" X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.5 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, 19 Mar 2012 10:34:28 -0000 On 19/03/2012 05:35, Adrian Chadd wrote: > Hi, > > Please try this patch: > > > > Adrian I'll give it a try once I've finished updating world ;) Thanks, Vince From owner-freebsd-wireless@FreeBSD.ORG Mon Mar 19 11:07:25 2012 Return-Path: Delivered-To: freebsd-wireless@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id F2D51106564A for ; Mon, 19 Mar 2012 11:07:25 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id DC5558FC20 for ; Mon, 19 Mar 2012 11:07:25 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q2JB7Pbm033762 for ; Mon, 19 Mar 2012 11:07:25 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q2JB7PIH033760 for freebsd-wireless@FreeBSD.org; Mon, 19 Mar 2012 11:07:25 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 19 Mar 2012 11:07:25 GMT Message-Id: <201203191107.q2JB7PIH033760@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 Cc: Subject: Current problem reports assigned to freebsd-wireless@FreeBSD.org X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.5 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, 19 Mar 2012 11:07:26 -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/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/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/145826 wireless [panic] [ath] Unable to configure adhoc mode on ath0/w o kern/144987 wireless [wpi] [panic] injecting packets with wlaninject using 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 p bin/137484 wireless [patch] Integer overflow in wpa_supplicant(8) base64 e 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 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 90 problems total. From owner-freebsd-wireless@FreeBSD.ORG Mon Mar 19 18:19:48 2012 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5F55210656D2 for ; Mon, 19 Mar 2012 18:19:48 +0000 (UTC) (envelope-from bschmidt@techwires.net) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id CF2298FC18 for ; Mon, 19 Mar 2012 18:19:47 +0000 (UTC) Received: by mail-bk0-f54.google.com with SMTP id jc3so6319869bkc.13 for ; Mon, 19 Mar 2012 11:19:47 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id :x-gm-message-state; bh=0mPQ8KXLMGvGDvU8iFhp7dMpcwCQwfr1BbqgC6/aoQw=; b=bfc8R+DSVdZmINB5y/AdGnUDTOOv6xZleYve7568UHVWO9bjHKRQrVVitZJK8HU0iE SZj3S9d+zXwxBPd8nfdBFbE6zCURvX9eyDuQk9QfuwB+EccWQRGgLAoonD3N7N5XwLrL 1AOtEOpFvWuAfZHzTWORL+UG0pNCld3uLSEHuRvIGtKf/nfSvZIfWh4XD2qfoUNbblnK gcavn6UQxCofGELHEybmnTCySiyOyXTyG0QBaxqW1zjHgrbyMtikKAFSNi0R4UXRO9O5 2x35dznd7hpnRnbNK7m/UFKw5L0JA+sDEBr5RBjxteafbfDwtNvscMEapjsNhqb5AFM0 TgNw== Received: by 10.204.157.21 with SMTP id z21mr1754886bkw.51.1332181187299; Mon, 19 Mar 2012 11:19:47 -0700 (PDT) Received: from amy.lab.techwires.net (dslb-088-067-222-211.pools.arcor-ip.net. [88.67.222.211]) by mx.google.com with ESMTPS id f6sm27266748bkg.10.2012.03.19.11.19.45 (version=SSLv3 cipher=OTHER); Mon, 19 Mar 2012 11:19:46 -0700 (PDT) Sender: Bernhard Schmidt From: Bernhard Schmidt To: Mitsuru IWASAKI Date: Mon, 19 Mar 2012 19:20:00 +0100 User-Agent: KMail/1.13.7 (FreeBSD/9.0-STABLE; KDE/4.7.4; amd64; ; ) References: <201203171232.42515.bschmidt@freebsd.org> <201203181825.25124.bschmidt@freebsd.org> <20120319.042250.74754884.iwasaki@jp.FreeBSD.org> In-Reply-To: <20120319.042250.74754884.iwasaki@jp.FreeBSD.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201203191920.00734.bschmidt@freebsd.org> X-Gm-Message-State: ALoCoQkRFAKmYcy/y2u4/Vh0/2czweNj0JABgek1ITXwMoQX2u9bd9x9j3M3/pnwCaFNvG97Xy3F Cc: freebsd-wireless@freebsd.org Subject: Re: [patch] iwi(4) suspend/resume broken X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.5 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, 19 Mar 2012 18:19:48 -0000 On Sunday 18 March 2012 20:22:50 Mitsuru IWASAKI wrote: > Hi, > > From: Bernhard Schmidt > > Well, I came up with attached diff. It works fine on iwn and wpi > > too basically, wpi has a bit of an issue with the scan after resume, > > I see probe resquest/response on air but the device doesn't pick > > em up sometimes.. still debugging. > > > > Anyways, I'm pretty sure that if you are doing the same for ipw/iwi > > it will just work fine. The ieee80211_resume_all/suspend_all calls > > will ensure that the appropriate stop/init driver functions are called. > > Great! I did the same thing for iwi(4), tested several times and it > works just fine. > > Please commit the attached patches if you like it. Thanks! I will commit that after a bit more testing. -- Bernhard From owner-freebsd-wireless@FreeBSD.ORG Mon Mar 19 18:22:32 2012 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EDED91065675 for ; Mon, 19 Mar 2012 18:22:32 +0000 (UTC) (envelope-from bschmidt@techwires.net) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 701468FC16 for ; Mon, 19 Mar 2012 18:22:32 +0000 (UTC) Received: by bkcjc3 with SMTP id jc3so6323606bkc.13 for ; Mon, 19 Mar 2012 11:22:31 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id :x-gm-message-state; bh=nSl7Z9iuF4eabJFGTMbDG4Flc3OopQYj+nRNk/tqOF0=; b=phfbXHvDIKfy/7KDcxZ49SQ7NWBWXT+ve9NuaFi9PcrX10w25bypCIlF7vlbujtDh6 CL2iZ4V6zn/ta0NYkAeKfM1ku9Khi/+FO+VA2CV8fr9JgbTvbhs4xPruleh4KYg5jR3E xUlBot7ibXPluqvfGfkXSyZGWUMzaL74LIZyhFqJajFi2Rfva710ObkGGjU3seyopis8 7k136XCKhWy2X01VErMkrmxsCeX3Dfhj1O3h5xLcnQBXejenDT2VScRN6eyW5/AhJ+3x RGdJCnSerHWq9ztkVVLrk+rakBWxj6heJQdqHVxfHVvPJcJfGZ+9vboScryJRPGeXlA1 537w== Received: by 10.204.136.200 with SMTP id s8mr4794402bkt.97.1332181351177; Mon, 19 Mar 2012 11:22:31 -0700 (PDT) Received: from amy.lab.techwires.net (dslb-088-067-222-211.pools.arcor-ip.net. [88.67.222.211]) by mx.google.com with ESMTPS id u14sm27339457bkp.2.2012.03.19.11.22.29 (version=SSLv3 cipher=OTHER); Mon, 19 Mar 2012 11:22:30 -0700 (PDT) Sender: Bernhard Schmidt From: Bernhard Schmidt To: Kevin Oberman Date: Mon, 19 Mar 2012 19:22:44 +0100 User-Agent: KMail/1.13.7 (FreeBSD/9.0-STABLE; KDE/4.7.4; amd64; ; ) References: <201203171232.42515.bschmidt@freebsd.org> <20120319.042250.74754884.iwasaki@jp.FreeBSD.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201203191922.44628.bschmidt@freebsd.org> X-Gm-Message-State: ALoCoQk1eaCOA6evR7yadE2HD+bLK88rOSyqMnMs+5fkrN/HGL+/5hIWp3fxjK7lSEkRWhUQXOso Cc: freebsd-wireless@freebsd.org Subject: Re: [patch] iwi(4) suspend/resume broken X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.5 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, 19 Mar 2012 18:22:33 -0000 On Sunday 18 March 2012 21:42:22 Kevin Oberman wrote: > On Sun, Mar 18, 2012 at 12:22 PM, Mitsuru IWASAKI > wrote: > > Hi, > > > > From: Bernhard Schmidt > >> Well, I came up with attached diff. It works fine on iwn and wpi > >> too basically, wpi has a bit of an issue with the scan after resume, > >> I see probe resquest/response on air but the device doesn't pick > >> em up sometimes.. still debugging. > >> > >> Anyways, I'm pretty sure that if you are doing the same for ipw/iwi > >> it will just work fine. The ieee80211_resume_all/suspend_all calls > >> will ensure that the appropriate stop/init driver functions are called. > > > > Great! I did the same thing for iwi(4), tested several times and it > > works just fine. > > > > Please commit the attached patches if you like it. > > And the patch for iwn. (I don't have a wpi, but I assume that one, as > well. I'd hope it's MFCed for 9.1. I'm beginning to feel a tiny bit > hopeful that I'll be able to susped and resume my laptop again someday > soon. Are there any issue swith suspend/resume on iwn currently? The diff does pretty much the same as what is already in the tree, just the timing/call graph is slightly different. If you're saying that there is an issue then it's just hidden with diff applied. -- Bernhard From owner-freebsd-wireless@FreeBSD.ORG Mon Mar 19 21:26:48 2012 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 116F6106566B; Mon, 19 Mar 2012 21:26:48 +0000 (UTC) (envelope-from vince@unsane.co.uk) Received: from unsane.co.uk (unsane-pt.tunnel.tserv5.lon1.ipv6.he.net [IPv6:2001:470:1f08:110::2]) by mx1.freebsd.org (Postfix) with ESMTP id 82A508FC0C; Mon, 19 Mar 2012 21:26:47 +0000 (UTC) Received: from vincemacbook.unsane.co.uk (vincemacbook.unsane.co.uk [10.10.10.20]) (authenticated bits=0) by unsane.co.uk (8.14.5/8.14.5) with ESMTP id q2JLQiJf005439 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 19 Mar 2012 21:26:45 GMT (envelope-from vince@unsane.co.uk) Message-ID: <4F67A493.9030903@unsane.co.uk> Date: Mon, 19 Mar 2012 21:26:43 +0000 From: Vincent Hoffman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Adrian Chadd References: <4F59DD98.8080905@unsane.co.uk> <4F5AA149.8000904@unsane.co.uk> <4F5BDF3C.8070605@unsane.co.uk> <4F5C0302.8090403@unsane.co.uk> In-Reply-To: X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-wireless@freebsd.org Subject: Re: ath0 timeout was "Re: (more) bugs fixed in -HEAD, AP mode is now mostly (again) stable!" X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.5 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, 19 Mar 2012 21:26:48 -0000 On 19/03/2012 05:35, Adrian Chadd wrote: > Hi, > > Please try this patch: > > > > Adrian Well its not a scientific test but its survived iperf traffic and rsync traffic that was causing hangs before. I'll put it back in usage as it was with a SMP kernel and let you know if i do see any hangs in the future. Thanks for your work on this. Vince From owner-freebsd-wireless@FreeBSD.ORG Mon Mar 19 21:38:00 2012 Return-Path: Delivered-To: freebsd-wireless@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 691D3106564A; Mon, 19 Mar 2012 21:38:00 +0000 (UTC) (envelope-from vince@unsane.co.uk) Received: from unsane.co.uk (unsane-pt.tunnel.tserv5.lon1.ipv6.he.net [IPv6:2001:470:1f08:110::2]) by mx1.freebsd.org (Postfix) with ESMTP id 40E658FC0C; Mon, 19 Mar 2012 21:37:59 +0000 (UTC) Received: from vincemacbook.unsane.co.uk (vincemacbook.unsane.co.uk [10.10.10.20]) (authenticated bits=0) by unsane.co.uk (8.14.5/8.14.5) with ESMTP id q2JLbuKf005892 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 19 Mar 2012 21:37:57 GMT (envelope-from vince@unsane.co.uk) Message-ID: <4F67A734.40805@unsane.co.uk> Date: Mon, 19 Mar 2012 21:37:56 +0000 From: Vincent Hoffman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: bug-followup@FreeBSD.org, adrian@FreeBSD.org X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-wireless@FreeBSD.org Subject: Re: kern/166190: [ath] TX hangs and frames stuck in TX queue X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.5 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, 19 Mar 2012 21:38:00 -0000 Hi Adrian, This patch is looking good as yet, I've repeated tests that were previously causing timeouts and as yet not been able cause a timeout after applying this patch. Its not definitive but so far it appears to have resolved this issue for me. Regards, Vince Hoffman From owner-freebsd-wireless@FreeBSD.ORG Mon Mar 19 21:40:13 2012 Return-Path: Delivered-To: freebsd-wireless@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E7D461065689 for ; Mon, 19 Mar 2012 21:40:13 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id B666A8FC15 for ; Mon, 19 Mar 2012 21:40:13 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q2JLeDgQ023138 for ; Mon, 19 Mar 2012 21:40:13 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q2JLeDc4023136; Mon, 19 Mar 2012 21:40:13 GMT (envelope-from gnats) Date: Mon, 19 Mar 2012 21:40:13 GMT Message-Id: <201203192140.q2JLeDc4023136@freefall.freebsd.org> To: freebsd-wireless@FreeBSD.org From: Vincent Hoffman Cc: Subject: Re: kern/166190: [ath] TX hangs and frames stuck in TX queue X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Vincent Hoffman 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, 19 Mar 2012 21:40:14 -0000 The following reply was made to PR kern/166190; it has been noted by GNATS. From: Vincent Hoffman To: bug-followup@FreeBSD.org, adrian@FreeBSD.org Cc: freebsd-wireless@FreeBSD.org Subject: Re: kern/166190: [ath] TX hangs and frames stuck in TX queue Date: Mon, 19 Mar 2012 21:37:56 +0000 Hi Adrian, This patch is looking good as yet, I've repeated tests that were previously causing timeouts and as yet not been able cause a timeout after applying this patch. Its not definitive but so far it appears to have resolved this issue for me. Regards, Vince Hoffman From owner-freebsd-wireless@FreeBSD.ORG Mon Mar 19 21:46:35 2012 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E95091065670 for ; Mon, 19 Mar 2012 21:46:34 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id B68AA8FC12 for ; Mon, 19 Mar 2012 21:46:34 +0000 (UTC) Received: by pbcwz17 with SMTP id wz17so1504373pbc.13 for ; Mon, 19 Mar 2012 14:46:34 -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=IbvErTjoVcf/fetkxUzU0KnGDpjCf+TO6T+7YcLxpAE=; b=F7LRvyjez8KSWdWZGoV2Wtr2scAI6PLoyVDc2+mzvNsSmBkwfmtWJwcGZbpqLU5NSh RHJaWwUmsr/i18GeyTzpx96akAzoHuHtsyy5cuBeQ+hGaiT3tfTBRHshQRanjFpdCldw bE4hL0vhVFwIuGXJZQTQqqN8dn2Fc0ok2y8SaftxrlGRXzG0ElyNlxV1JJDWbzRGVadp zZN8Erd3R/JbE6VkShSH9T81BdlYOTRvotv5GRlQlXJnRN87+yTIaIs1mu9+ZpXO3KJR CvxK0mHGoIU9ZBsGqu1KD3KIljaNtJUZfOVE26P/jWqyBcxbHGS7LXRfxSksdXptmfb7 lh2w== Received: by 10.68.134.136 with SMTP id pk8mr33354542pbb.120.1332193594442; Mon, 19 Mar 2012 14:46:34 -0700 (PDT) Received: from www.palm.com ([166.135.124.178]) by mx.google.com with ESMTPS id d6sm12150781pbi.23.2012.03.19.14.46.29 (version=SSLv3 cipher=OTHER); Mon, 19 Mar 2012 14:46:33 -0700 (PDT) Message-ID: <4f67a939.e61f440a.4abb.ffffee38@mx.google.com> Date: Mon, 19 Mar 2012 14:46:29 -0700 From: "Adrian Chadd" To: "Vincent Hoffman" In-Reply-To: <4F67A493.9030903@unsane.co.uk> 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.5 Cc: "freebsd-wireless@freebsd.org" Subject: Re: ath0 timeout was "Re: (more) bugs fixed in -HEAD, AP mode is now mostly (again) stable!" X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.5 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, 19 Mar 2012 21:46:35 -0000 Oh, thankyou for reporting it! I'm glad you pointed this out to me. It really does highlight the need for better (any) driver/stack debugging= and tracing code. Doing this with printf() and a lot of study is .. Not sc= alable. Let me know how iperf goes! Adrian Sent from my Palm Pre on AT&T On Mar 19, 2012 2:26 PM, Vincent Hoffman <vince@unsane.co.uk> wrote:= On 19/03/2012 05:35, Adrian Chadd wrote: > Hi, > > Please try this patch: > > > > Adrian Well its not a scientific test but its survived iperf traffic and rsync traffic that was causing hangs before. I'll put it back in usage as it was with a SMP kernel and let you know if i do see any hangs in the future. Thanks for your work on this. Vince From owner-freebsd-wireless@FreeBSD.ORG Mon Mar 19 21:50:13 2012 Return-Path: Delivered-To: freebsd-wireless@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 619BB106564A for ; Mon, 19 Mar 2012 21:50:13 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 338948FC1C for ; Mon, 19 Mar 2012 21:50:13 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q2JLoDa5032062 for ; Mon, 19 Mar 2012 21:50:13 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q2JLoDNk032061; Mon, 19 Mar 2012 21:50:13 GMT (envelope-from gnats) Date: Mon, 19 Mar 2012 21:50:13 GMT Message-Id: <201203192150.q2JLoDNk032061@freefall.freebsd.org> To: freebsd-wireless@FreeBSD.org From: "Adrian Chadd" Cc: Subject: Re: kern/166190: [ath] TX hangs and frames stuck in TX queue X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.5 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, 19 Mar 2012 21:50:13 -0000 The following reply was made to PR kern/166190; it has been noted by GNATS. From: "Adrian Chadd" To: "Vincent Hoffman" , "bug-followup@freebsd.org" Cc: Subject: Re: kern/166190: [ath] TX hangs and frames stuck in TX queue Date: Mon, 19 Mar 2012 14:49:28 -0700 --Alternative__boundary__1332193773950 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Just check the txagg sysctl and mae sure your buffer count stays up around= 512. I want to make sure that buffers aren't being leaked. Thanks again! Sent from my Palm Pre on AT&T On Mar 19, 2012 2:38 PM, Vincent Hoffman <vince@unsane.co.uk> wrote:= Hi Adrian, This patch is looking good as yet, I've repeated tests that were previously causing timeouts and as yet not been able cause a timeout after applying this patch. Its not definitive but so far it appears to have resolved this issue for me. Regards, Vince Hoffman --Alternative__boundary__1332193773950 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Just check the txagg sysctl and mae sure your buffer count stays up around= 512.

I want to make sure that buffers aren't being leaked.

T= hanks again!

Sent from my Palm Pre on AT&a= mp;T

On Mar 19, 2012 2:38= PM, Vincent Hoffman <vince@unsane.co.uk> wrote:

Hi Adrian,


This patch is looking good as yet, I've repeated tests that were
previously causing timeouts and as yet not been able cause a timeout
after applying this patch.

Its not definitive but so far it appears to have resolved this issue
for me.


Regards,
Vince Hoffman
--Alternative__boundary__1332193773950-- From owner-freebsd-wireless@FreeBSD.ORG Mon Mar 19 22:18:39 2012 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8E020106566B for ; Mon, 19 Mar 2012 22:18:39 +0000 (UTC) (envelope-from vince@unsane.co.uk) Received: from unsane.co.uk (unsane-pt.tunnel.tserv5.lon1.ipv6.he.net [IPv6:2001:470:1f08:110::2]) by mx1.freebsd.org (Postfix) with ESMTP id F1B768FC0A for ; Mon, 19 Mar 2012 22:18:38 +0000 (UTC) Received: from vincemacbook.unsane.co.uk (vincemacbook.unsane.co.uk [10.10.10.20]) (authenticated bits=0) by unsane.co.uk (8.14.5/8.14.5) with ESMTP id q2JMHgiO095968 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 19 Mar 2012 22:18:28 GMT (envelope-from vince@unsane.co.uk) Message-ID: <4F67B086.6050104@unsane.co.uk> Date: Mon, 19 Mar 2012 22:17:42 +0000 From: Vincent Hoffman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Adrian Chadd References: <4f67a939.e61f440a.4abb.ffffee38@mx.google.com> In-Reply-To: <4f67a939.e61f440a.4abb.ffffee38@mx.google.com> X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: "freebsd-wireless@freebsd.org" Subject: Re: ath0 timeout was "Re: (more) bugs fixed in -HEAD, AP mode is now mostly (again) stable!" X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.5 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, 19 Mar 2012 22:18:39 -0000 On 19/03/2012 21:46, Adrian Chadd wrote: > Oh, thankyou for reporting it! I'm glad you pointed this out to me. > > It really does highlight the need for better (any) driver/stack > debugging and tracing code. Doing this with printf() and a lot of > study is .. Not scalable. > > Let me know how iperf goes! > Sending from my FreeBSD server to my OSX laptop jhary@ostracod $ iperf -c 10.10.10.242 -t 60 ------------------------------------------------------------ Client connecting to 10.10.10.242, TCP port 5001 TCP window size: 32.5 KByte (default) ------------------------------------------------------------ [ 3] local 10.10.10.1 port 57369 connected with 10.10.10.242 port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0-60.0 sec 154 MBytes 21.4 Mbits/sec >From my laptop to the server vhoffman@macbook (22:14:45 <~>) 0 $ iperf -c 10.10.10.1 -t 60 ------------------------------------------------------------ Client connecting to 10.10.10.1, TCP port 5001 TCP window size: 129 KByte (default) ------------------------------------------------------------ [ 3] local 10.10.10.20 port 53111 connected with 10.10.10.1 port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0-60.1 sec 125 MBytes 17.4 Mbits/sec I'm not sure sort of speed would be expected, I'll benchmark my laptop against a server at work Vince > > Adrian > > > > Sent from my Palm Pre on AT&T > > ------------------------------------------------------------------------ > On Mar 19, 2012 2:26 PM, Vincent Hoffman wrote: > > On 19/03/2012 05:35, Adrian Chadd wrote: > > Hi, > > > > Please try this patch: > > > > > > > > Adrian > Well its not a scientific test but its survived iperf traffic and rsync > traffic that was causing hangs before. > I'll put it back in usage as it was with a SMP kernel and let you know > if i do see any hangs in the future. > > > Thanks for your work on this. > > Vince From owner-freebsd-wireless@FreeBSD.ORG Mon Mar 19 22:20:14 2012 Return-Path: Delivered-To: freebsd-wireless@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E0615106564A for ; Mon, 19 Mar 2012 22:20:14 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id CA10A8FC16 for ; Mon, 19 Mar 2012 22:20:14 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q2JMKEsn059190 for ; Mon, 19 Mar 2012 22:20:14 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q2JMKECm059189; Mon, 19 Mar 2012 22:20:14 GMT (envelope-from gnats) Date: Mon, 19 Mar 2012 22:20:14 GMT Message-Id: <201203192220.q2JMKECm059189@freefall.freebsd.org> To: freebsd-wireless@FreeBSD.org From: Vincent Hoffman Cc: Subject: Re: kern/166190: [ath] TX hangs and frames stuck in TX queue X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Vincent Hoffman 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, 19 Mar 2012 22:20:15 -0000 The following reply was made to PR kern/166190; it has been noted by GNATS. From: Vincent Hoffman To: Adrian Chadd Cc: "bug-followup@freebsd.org" Subject: Re: kern/166190: [ath] TX hangs and frames stuck in TX queue Date: Mon, 19 Mar 2012 22:10:57 +0000 This is a multi-part message in MIME format. --------------070001010500040909030800 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit During an iperf test Total TX buffers went from 512 -> 356) iperf output (tcp, sending form freebsd machine to osx laptop [ 4] 0.0-60.2 sec 154 MBytes 21.4 Mbits/sec) dmesg output: no tx bufs (empty list): 0 no tx bufs (was busy): 0 aggr single packet: 14372 aggr single packet w/ BAW closed: 0 aggr non-baw packet: 1 aggr aggregate packet: 119987 aggr single packet low hwq: 641424 aggr sched, no work: 15333 0: 0 1: 0 2: 7811 3: 5690 4: 5077 5: 4509 6: 4675 7: 4546 8: 5255 9: 5061 10: 4796 11: 9393 12: 3094 13: 2604 14: 2647 15: 2301 16: 4372 17: 2440 18: 4558 19: 8300 20: 6962 21: 4679 22: 2404 23: 1270 24: 1076 25: 929 26: 866 27: 856 28: 835 29: 895 30: 1033 31: 1016 32: 10037 33: 0 34: 0 35: 0 36: 0 37: 0 38: 0 39: 0 40: 0 41: 0 42: 0 43: 0 44: 0 45: 0 46: 0 47: 0 48: 0 49: 0 50: 0 51: 0 52: 0 53: 0 54: 0 55: 0 56: 0 57: 0 58: 0 59: 0 60: 0 61: 0 62: 0 63: 0 HW TXQ 0: axq_depth=0, axq_aggr_depth=0 HW TXQ 1: axq_depth=0, axq_aggr_depth=0 HW TXQ 2: axq_depth=0, axq_aggr_depth=0 HW TXQ 3: axq_depth=0, axq_aggr_depth=0 HW TXQ 8: axq_depth=0, axq_aggr_depth=0 Total TX buffers: 512; Total TX buffers busy: 0 no tx bufs (empty list): 0 no tx bufs (was busy): 0 aggr single packet: 14553 aggr single packet w/ BAW closed: 0 aggr non-baw packet: 1 aggr aggregate packet: 121203 aggr single packet low hwq: 643315 aggr sched, no work: 15414 0: 0 1: 0 2: 7931 3: 5744 4: 5116 5: 4554 6: 4716 7: 4577 8: 5284 9: 5097 10: 4822 11: 9425 12: 3123 13: 2628 14: 2671 15: 2322 16: 5036 17: 2442 18: 4558 19: 8300 20: 6962 21: 4679 22: 2404 23: 1270 24: 1076 25: 929 26: 866 27: 856 28: 835 29: 895 30: 1033 31: 1016 32: 10037 33: 0 34: 0 35: 0 36: 0 37: 0 38: 0 39: 0 40: 0 41: 0 42: 0 43: 0 44: 0 45: 0 46: 0 47: 0 48: 0 49: 0 50: 0 51: 0 52: 0 53: 0 54: 0 55: 0 56: 0 57: 0 58: 0 59: 0 60: 0 61: 0 62: 0 63: 0 HW TXQ 0: axq_depth=0, axq_aggr_depth=0 HW TXQ 1: axq_depth=2, axq_aggr_depth=2 HW TXQ 2: axq_depth=0, axq_aggr_depth=0 HW TXQ 3: axq_depth=0, axq_aggr_depth=0 HW TXQ 8: axq_depth=0, axq_aggr_depth=0 Total TX buffers: 481; Total TX buffers busy: 0 no tx bufs (empty list): 0 no tx bufs (was busy): 0 aggr single packet: 14928 aggr single packet w/ BAW closed: 0 aggr non-baw packet: 1 aggr aggregate packet: 125149 aggr single packet low hwq: 645085 aggr sched, no work: 15673 0: 0 1: 0 2: 8187 3: 5884 4: 5230 5: 4653 6: 4801 7: 4649 8: 5347 9: 5168 10: 4891 11: 9496 12: 3305 13: 2715 14: 2753 15: 2399 16: 7473 17: 2464 18: 4565 19: 8304 20: 6966 21: 4681 22: 2405 23: 1270 24: 1077 25: 929 26: 866 27: 856 28: 835 29: 895 30: 1033 31: 1016 32: 10037 33: 0 34: 0 35: 0 36: 0 37: 0 38: 0 39: 0 40: 0 41: 0 42: 0 43: 0 44: 0 45: 0 46: 0 47: 0 48: 0 49: 0 50: 0 51: 0 52: 0 53: 0 54: 0 55: 0 56: 0 57: 0 58: 0 59: 0 60: 0 61: 0 62: 0 63: 0 HW TXQ 0: axq_depth=0, axq_aggr_depth=0 HW TXQ 1: axq_depth=2, axq_aggr_depth=1 HW TXQ 2: axq_depth=0, axq_aggr_depth=0 HW TXQ 3: axq_depth=0, axq_aggr_depth=0 HW TXQ 8: axq_depth=0, axq_aggr_depth=0 Total TX buffers: 502; Total TX buffers busy: 0 no tx bufs (empty list): 0 no tx bufs (was busy): 0 aggr single packet: 15237 aggr single packet w/ BAW closed: 0 aggr non-baw packet: 1 aggr aggregate packet: 127403 aggr single packet low hwq: 646324 aggr sched, no work: 15851 0: 0 1: 0 2: 8360 3: 5998 4: 5304 5: 4703 6: 4846 7: 4701 8: 5377 9: 5216 10: 4935 11: 9544 12: 3383 13: 2753 14: 2811 15: 2441 16: 8822 17: 2474 18: 4566 19: 8304 20: 6966 21: 4681 22: 2406 23: 1270 24: 1077 25: 929 26: 866 27: 856 28: 835 29: 895 30: 1033 31: 1016 32: 10037 33: 0 34: 0 35: 0 36: 0 37: 0 38: 0 39: 0 40: 0 41: 0 42: 0 43: 0 44: 0 45: 0 46: 0 47: 0 48: 0 49: 0 50: 0 51: 0 52: 0 53: 0 54: 0 55: 0 56: 0 57: 0 58: 0 59: 0 60: 0 61: 0 62: 0 63: 0 HW TXQ 0: axq_depth=0, axq_aggr_depth=0 HW TXQ 1: axq_depth=2, axq_aggr_depth=2 HW TXQ 2: axq_depth=0, axq_aggr_depth=0 HW TXQ 3: axq_depth=0, axq_aggr_depth=0 HW TXQ 8: axq_depth=0, axq_aggr_depth=0 Total TX buffers: 356; Total TX buffers busy: 0 On 19/03/2012 21:49, Adrian Chadd wrote: > Just check the txagg sysctl and mae sure your buffer count stays up > around 512. > > I want to make sure that buffers aren't being leaked. > > Thanks again! > > > > Sent from my Palm Pre on AT&T > > ------------------------------------------------------------------------ > On Mar 19, 2012 2:38 PM, Vincent Hoffman wrote: > > Hi Adrian, > > > This patch is looking good as yet, I've repeated tests that were > previously causing timeouts and as yet not been able cause a timeout > after applying this patch. > > Its not definitive but so far it appears to have resolved this issue > for me. > > > Regards, > Vince Hoffman --------------070001010500040909030800 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit During an iperf test
Total TX buffers went from  512 -> 356)

iperf output (tcp, sending form freebsd machine to osx laptop [  4]  0.0-60.2 sec   154 MBytes  21.4 Mbits/sec)

dmesg output:

no tx bufs (empty list): 0
no tx bufs (was busy): 0
aggr single packet: 14372
aggr single packet w/ BAW closed: 0
aggr non-baw packet: 1
aggr aggregate packet: 119987
aggr single packet low hwq: 641424
aggr sched, no work: 15333
 0:          0  1:          0  2:       7811  3:       5690
 4:       5077  5:       4509  6:       4675  7:       4546
 8:       5255  9:       5061 10:       4796 11:       9393
12:       3094 13:       2604 14:       2647 15:       2301
16:       4372 17:       2440 18:       4558 19:       8300
20:       6962 21:       4679 22:       2404 23:       1270
24:       1076 25:        929 26:        866 27:        856
28:        835 29:        895 30:       1033 31:       1016
32:      10037 33:          0 34:          0 35:          0
36:          0 37:          0 38:          0 39:          0
40:          0 41:          0 42:          0 43:          0
44:          0 45:          0 46:          0 47:          0
48:          0 49:          0 50:          0 51:          0
52:          0 53:          0 54:          0 55:          0
56:          0 57:          0 58:          0 59:          0
60:          0 61:          0 62:          0 63:          0

HW TXQ 0: axq_depth=0, axq_aggr_depth=0
HW TXQ 1: axq_depth=0, axq_aggr_depth=0
HW TXQ 2: axq_depth=0, axq_aggr_depth=0
HW TXQ 3: axq_depth=0, axq_aggr_depth=0
HW TXQ 8: axq_depth=0, axq_aggr_depth=0
Total TX buffers: 512; Total TX buffers busy: 0
no tx bufs (empty list): 0
no tx bufs (was busy): 0
aggr single packet: 14553
aggr single packet w/ BAW closed: 0
aggr non-baw packet: 1
aggr aggregate packet: 121203
aggr single packet low hwq: 643315
aggr sched, no work: 15414
 0:          0  1:          0  2:       7931  3:       5744
 4:       5116  5:       4554  6:       4716  7:       4577
 8:       5284  9:       5097 10:       4822 11:       9425
12:       3123 13:       2628 14:       2671 15:       2322
16:       5036 17:       2442 18:       4558 19:       8300
20:       6962 21:       4679 22:       2404 23:       1270
24:       1076 25:        929 26:        866 27:        856
28:        835 29:        895 30:       1033 31:       1016
32:      10037 33:          0 34:          0 35:          0
36:          0 37:          0 38:          0 39:          0
40:          0 41:          0 42:          0 43:          0
44:          0 45:          0 46:          0 47:          0
48:          0 49:          0 50:          0 51:          0
52:          0 53:          0 54:          0 55:          0
56:          0 57:          0 58:          0 59:          0
60:          0 61:          0 62:          0 63:          0

HW TXQ 0: axq_depth=0, axq_aggr_depth=0
HW TXQ 1: axq_depth=2, axq_aggr_depth=2
HW TXQ 2: axq_depth=0, axq_aggr_depth=0
HW TXQ 3: axq_depth=0, axq_aggr_depth=0
HW TXQ 8: axq_depth=0, axq_aggr_depth=0
Total TX buffers: 481; Total TX buffers busy: 0
no tx bufs (empty list): 0
no tx bufs (was busy): 0
aggr single packet: 14928
aggr single packet w/ BAW closed: 0
aggr non-baw packet: 1
aggr aggregate packet: 125149
aggr single packet low hwq: 645085
aggr sched, no work: 15673
 0:          0  1:          0  2:       8187  3:       5884
 4:       5230  5:       4653  6:       4801  7:       4649
 8:       5347  9:       5168 10:       4891 11:       9496
12:       3305 13:       2715 14:       2753 15:       2399
16:       7473 17:       2464 18:       4565 19:       8304
20:       6966 21:       4681 22:       2405 23:       1270
24:       1077 25:        929 26:        866 27:        856
28:        835 29:        895 30:       1033 31:       1016
32:      10037 33:          0 34:          0 35:          0
36:          0 37:          0 38:          0 39:          0
40:          0 41:          0 42:          0 43:          0
44:          0 45:          0 46:          0 47:          0
48:          0 49:          0 50:          0 51:          0
52:          0 53:          0 54:          0 55:          0
56:          0 57:          0 58:          0 59:          0
60:          0 61:          0 62:          0 63:          0

HW TXQ 0: axq_depth=0, axq_aggr_depth=0
HW TXQ 1: axq_depth=2, axq_aggr_depth=1
HW TXQ 2: axq_depth=0, axq_aggr_depth=0
HW TXQ 3: axq_depth=0, axq_aggr_depth=0
HW TXQ 8: axq_depth=0, axq_aggr_depth=0
Total TX buffers: 502; Total TX buffers busy: 0
no tx bufs (empty list): 0
no tx bufs (was busy): 0
aggr single packet: 15237
aggr single packet w/ BAW closed: 0
aggr non-baw packet: 1
aggr aggregate packet: 127403
aggr single packet low hwq: 646324
aggr sched, no work: 15851
 0:          0  1:          0  2:       8360  3:       5998
 4:       5304  5:       4703  6:       4846  7:       4701
 8:       5377  9:       5216 10:       4935 11:       9544
12:       3383 13:       2753 14:       2811 15:       2441
16:       8822 17:       2474 18:       4566 19:       8304
20:       6966 21:       4681 22:       2406 23:       1270
24:       1077 25:        929 26:        866 27:        856
28:        835 29:        895 30:       1033 31:       1016
32:      10037 33:          0 34:          0 35:          0
36:          0 37:          0 38:          0 39:          0
40:          0 41:          0 42:          0 43:          0
44:          0 45:          0 46:          0 47:          0
48:          0 49:          0 50:          0 51:          0
52:          0 53:          0 54:          0 55:          0
56:          0 57:          0 58:          0 59:          0
60:          0 61:          0 62:          0 63:          0

HW TXQ 0: axq_depth=0, axq_aggr_depth=0
HW TXQ 1: axq_depth=2, axq_aggr_depth=2
HW TXQ 2: axq_depth=0, axq_aggr_depth=0
HW TXQ 3: axq_depth=0, axq_aggr_depth=0
HW TXQ 8: axq_depth=0, axq_aggr_depth=0
Total TX buffers: 356; Total TX buffers busy: 0


On 19/03/2012 21:49, Adrian Chadd wrote:
Just check the txagg sysctl and mae sure your buffer count stays up around 512.

I want to make sure that buffers aren't being leaked.

Thanks again!
Sent from my Palm Pre on AT&T
On Mar 19, 2012 2:38 PM, Vincent Hoffman <vince@unsane.co.uk> wrote:

Hi Adrian,


This patch is looking good as yet, I've repeated tests that were
previously causing timeouts and as yet not been able cause a timeout
after applying this patch.

Its not definitive but so far it appears to have resolved this issue
for me.


Regards,
Vince Hoffman

--------------070001010500040909030800-- From owner-freebsd-wireless@FreeBSD.ORG Mon Mar 19 23:10:13 2012 Return-Path: Delivered-To: freebsd-wireless@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 37B831065678 for ; Mon, 19 Mar 2012 23:10:13 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 1FAD28FC17 for ; Mon, 19 Mar 2012 23:10:13 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q2JNADGq004147 for ; Mon, 19 Mar 2012 23:10:13 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q2JNADJX004144; Mon, 19 Mar 2012 23:10:13 GMT (envelope-from gnats) Date: Mon, 19 Mar 2012 23:10:13 GMT Message-Id: <201203192310.q2JNADJX004144@freefall.freebsd.org> To: freebsd-wireless@FreeBSD.org From: "Adrian Chadd" Cc: Subject: Re: kern/166190: [ath] TX hangs and frames stuck in TX queue X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.5 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, 19 Mar 2012 23:10:13 -0000 The following reply was made to PR kern/166190; it has been noted by GNATS. From: "Adrian Chadd" To: "Vincent Hoffman" Cc: "bug-followup@freebsd.org" Subject: Re: kern/166190: [ath] TX hangs and frames stuck in TX queue Date: Mon, 19 Mar 2012 16:09:05 -0700 --Alternative__boundary__1332198551683 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Then they returned to 512, right? Adrian Sent from my Palm Pre on AT&T On Mar 19, 2012 3:11 PM, Vincent Hoffman <vince@unsane.co.uk> wrote:= During an iperf test Total TX buffers went from  512 -> 356) =20 iperf output (tcp, sending form freebsd machine to osx laptop [ = 4]  0.0-60.2 sec   154 MBytes  21.4 Mbits/sec) =20 dmesg output: =20 no tx bufs (empty list): 0 no tx bufs (was busy): 0 aggr single packet: 14372 aggr single packet w/ BAW closed: 0 aggr non-baw packet: 1 aggr aggregate packet: 119987 aggr single packet low hwq: 641424 aggr sched, no work: 15333  0:          0 = 1:          0  2: &= nbsp;     7811  3:     &n= bsp; 5690=20  4:       5077  5:  &= nbsp;    4509  6:      = 4675  7:       4546=20  8:       5255  9:  &= nbsp;    5061 10:       4796= 11:       9393=20 12:       3094 13:    = ;   2604 14:       2647 15: &n= bsp;     2301=20 16:       4372 17:    = ;   2440 18:       4558 19: &n= bsp;     8300=20 20:       6962 21:    = ;   4679 22:       2404 23: &n= bsp;     1270=20 24:       1076 25:    = ;    929 26:        866= 27:        856=20 28:        835 29:   =      895 30:       1033= 31:       1016=20 32:      10037 33:    &nbs= p;     0 34:       &= nbsp;  0 35:          0=20 36:          0 37: &n= bsp;        0 38:    = ;      0 39:      &n= bsp;   0=20 40:          0 41: &n= bsp;        0 42:    = ;      0 43:      &n= bsp;   0=20 44:          0 45: &n= bsp;        0 46:    = ;      0 47:      &n= bsp;   0=20 48:          0 49: &n= bsp;        0 50:    = ;      0 51:      &n= bsp;   0=20 52:          0 53: &n= bsp;        0 54:    = ;      0 55:      &n= bsp;   0=20 56:          0 57: &n= bsp;        0 58:    = ;      0 59:      &n= bsp;   0=20 60:          0 61: &n= bsp;        0 62:    = ;      0 63:      &n= bsp;   0=20 =20 HW TXQ 0: axq_depth=3D0, axq_aggr_depth=3D0 HW TXQ 1: axq_depth=3D0, axq_aggr_depth=3D0 HW TXQ 2: axq_depth=3D0, axq_aggr_depth=3D0 HW TXQ 3: axq_depth=3D0, axq_aggr_depth=3D0 HW TXQ 8: axq_depth=3D0, axq_aggr_depth=3D0 Total TX buffers: 512; Total TX buffers busy: 0 no tx bufs (empty list): 0 no tx bufs (was busy): 0 aggr single packet: 14553 aggr single packet w/ BAW closed: 0 aggr non-baw packet: 1 aggr aggregate packet: 121203 aggr single packet low hwq: 643315 aggr sched, no work: 15414  0:          0 = 1:          0  2: &= nbsp;     7931  3:     &n= bsp; 5744=20  4:       5116  5:  &= nbsp;    4554  6:      = 4716  7:       4577=20  8:       5284  9:  &= nbsp;    5097 10:       4822= 11:       9425=20 12:       3123 13:    = ;   2628 14:       2671 15: &n= bsp;     2322=20 16:       5036 17:    = ;   2442 18:       4558 19: &n= bsp;     8300=20 20:       6962 21:    = ;   4679 22:       2404 23: &n= bsp;     1270=20 24:       1076 25:    = ;    929 26:        866= 27:        856=20 28:        835 29:   =      895 30:       1033= 31:       1016=20 32:      10037 33:    &nbs= p;     0 34:       &= nbsp;  0 35:          0=20 36:          0 37: &n= bsp;        0 38:    = ;      0 39:      &n= bsp;   0=20 40:          0 41: &n= bsp;        0 42:    = ;      0 43:      &n= bsp;   0=20 44:          0 45: &n= bsp;        0 46:    = ;      0 47:      &n= bsp;   0=20 48:          0 49: &n= bsp;        0 50:    = ;      0 51:      &n= bsp;   0=20 52:          0 53: &n= bsp;        0 54:    = ;      0 55:      &n= bsp;   0=20 56:          0 57: &n= bsp;        0 58:    = ;      0 59:      &n= bsp;   0=20 60:          0 61: &n= bsp;        0 62:    = ;      0 63:      &n= bsp;   0=20 =20 HW TXQ 0: axq_depth=3D0, axq_aggr_depth=3D0 HW TXQ 1: axq_depth=3D2, axq_aggr_depth=3D2 HW TXQ 2: axq_depth=3D0, axq_aggr_depth=3D0 HW TXQ 3: axq_depth=3D0, axq_aggr_depth=3D0 HW TXQ 8: axq_depth=3D0, axq_aggr_depth=3D0 Total TX buffers: 481; Total TX buffers busy: 0 no tx bufs (empty list): 0 no tx bufs (was busy): 0 aggr single packet: 14928 aggr single packet w/ BAW closed: 0 aggr non-baw packet: 1 aggr aggregate packet: 125149 aggr single packet low hwq: 645085 aggr sched, no work: 15673  0:          0 = 1:          0  2: &= nbsp;     8187  3:     &n= bsp; 5884=20  4:       5230  5:  &= nbsp;    4653  6:      = 4801  7:       4649=20  8:       5347  9:  &= nbsp;    5168 10:       4891= 11:       9496=20 12:       3305 13:    = ;   2715 14:       2753 15: &n= bsp;     2399=20 16:       7473 17:    = ;   2464 18:       4565 19: &n= bsp;     8304=20 20:       6966 21:    = ;   4681 22:       2405 23: &n= bsp;     1270=20 24:       1077 25:    = ;    929 26:        866= 27:        856=20 28:        835 29:   =      895 30:       1033= 31:       1016=20 32:      10037 33:    &nbs= p;     0 34:       &= nbsp;  0 35:          0=20 36:          0 37: &n= bsp;        0 38:    = ;      0 39:      &n= bsp;   0=20 40:          0 41: &n= bsp;        0 42:    = ;      0 43:      &n= bsp;   0=20 44:          0 45: &n= bsp;        0 46:    = ;      0 47:      &n= bsp;   0=20 48:          0 49: &n= bsp;        0 50:    = ;      0 51:      &n= bsp;   0=20 52:          0 53: &n= bsp;        0 54:    = ;      0 55:      &n= bsp;   0=20 56:          0 57: &n= bsp;        0 58:    = ;      0 59:      &n= bsp;   0=20 60:          0 61: &n= bsp;        0 62:    = ;      0 63:      &n= bsp;   0=20 =20 HW TXQ 0: axq_depth=3D0, axq_aggr_depth=3D0 HW TXQ 1: axq_depth=3D2, axq_aggr_depth=3D1 HW TXQ 2: axq_depth=3D0, axq_aggr_depth=3D0 HW TXQ 3: axq_depth=3D0, axq_aggr_depth=3D0 HW TXQ 8: axq_depth=3D0, axq_aggr_depth=3D0 Total TX buffers: 502; Total TX buffers busy: 0 no tx bufs (empty list): 0 no tx bufs (was busy): 0 aggr single packet: 15237 aggr single packet w/ BAW closed: 0 aggr non-baw packet: 1 aggr aggregate packet: 127403 aggr single packet low hwq: 646324 aggr sched, no work: 15851  0:          0 = 1:          0  2: &= nbsp;     8360  3:     &n= bsp; 5998=20  4:       5304  5:  &= nbsp;    4703  6:      = 4846  7:       4701=20  8:       5377  9:  &= nbsp;    5216 10:       4935= 11:       9544=20 12:       3383 13:    = ;   2753 14:       2811 15: &n= bsp;     2441=20 16:       8822 17:    = ;   2474 18:       4566 19: &n= bsp;     8304=20 20:       6966 21:    = ;   4681 22:       2406 23: &n= bsp;     1270=20 24:       1077 25:    = ;    929 26:        866= 27:        856=20 28:        835 29:   =      895 30:       1033= 31:       1016=20 32:      10037 33:    &nbs= p;     0 34:       &= nbsp;  0 35:          0=20 36:          0 37: &n= bsp;        0 38:    = ;      0 39:      &n= bsp;   0=20 40:          0 41: &n= bsp;        0 42:    = ;      0 43:      &n= bsp;   0=20 44:          0 45: &n= bsp;        0 46:    = ;      0 47:      &n= bsp;   0=20 48:          0 49: &n= bsp;        0 50:    = ;      0 51:      &n= bsp;   0=20 52:          0 53: &n= bsp;        0 54:    = ;      0 55:      &n= bsp;   0=20 56:          0 57: &n= bsp;        0 58:    = ;      0 59:      &n= bsp;   0=20 60:          0 61: &n= bsp;        0 62:    = ;      0 63:      &n= bsp;   0=20 =20 HW TXQ 0: axq_depth=3D0, axq_aggr_depth=3D0 HW TXQ 1: axq_depth=3D2, axq_aggr_depth=3D2 HW TXQ 2: axq_depth=3D0, axq_aggr_depth=3D0 HW TXQ 3: axq_depth=3D0, axq_aggr_depth=3D0 HW TXQ 8: axq_depth=3D0, axq_aggr_depth=3D0 Total TX buffers: 356; Total TX buffers busy: 0 =20 =20 On 19/03/2012 21:49, Adrian Chadd wrote: Just check the txagg sysctl and mae sure your buffer count stays up around 512. =20 I want to make sure that buffers aren't being leaked. =20 Thanks again! =20 =20 =20 =20 Sent from my Palm Pre on AT&T =20 =20 On Mar 19, 2012 2:38 PM, Vincent Hoffman <vince@unsane.co.uk> wrote:=20 =20 Hi Adrian, =20 =20 =20 This patch is looking good as yet, I've repeated tests that were =20 previously causing timeouts and as yet not been able cause a timeout =20 after applying this patch. =20 =20 Its not definitive but so far it appears to have resolved this issue =20 for me. =20 =20 =20 Regards, =20 Vince Hoffman =20 =20 =20 =20 =20 --Alternative__boundary__1332198551683 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Then they returned to 512, right?


Adrian



Sent from my Palm Pre on AT&T

On Mar 19, 2012 3:11 PM, Vincent Hoffman <vince@unsane.= co.uk> wrote:

During an iperf test
Total TX buffers went from  512 -> 356)

iperf output (tcp, sending form freebsd machine to osx laptop [ = 4]  0.0-60.2 sec   154 MBytes  21.4 Mbits/sec)

dmesg output:

no tx bufs (empty list): 0
no tx bufs (was busy): 0
aggr single packet: 14372
aggr single packet w/ BAW closed: 0
aggr non-baw packet: 1
aggr aggregate packet: 119987
aggr single packet low hwq: 641424
aggr sched, no work: 15333
 0:          0 = 1:          0  2: &= nbsp;     7811  3:     &n= bsp; 5690
 4:       5077  5:  &= nbsp;    4509  6:      = 4675  7:       4546
 8:       5255  9:  &= nbsp;    5061 10:       4796= 11:       9393
12:       3094 13:    = ;   2604 14:       2647 15: &n= bsp;     2301
16:       4372 17:    = ;   2440 18:       4558 19: &n= bsp;     8300
20:       6962 21:    = ;   4679 22:       2404 23: &n= bsp;     1270
24:       1076 25:    = ;    929 26:        866= 27:        856
28:        835 29:   =      895 30:       1033= 31:       1016
32:      10037 33:    &nbs= p;     0 34:       &= nbsp;  0 35:          0=
36:          0 37: &n= bsp;        0 38:    = ;      0 39:      &n= bsp;   0
40:          0 41: &n= bsp;        0 42:    = ;      0 43:      &n= bsp;   0
44:          0 45: &n= bsp;        0 46:    = ;      0 47:      &n= bsp;   0
48:          0 49: &n= bsp;        0 50:    = ;      0 51:      &n= bsp;   0
52:          0 53: &n= bsp;        0 54:    = ;      0 55:      &n= bsp;   0
56:          0 57: &n= bsp;        0 58:    = ;      0 59:      &n= bsp;   0
60:          0 61: &n= bsp;        0 62:    = ;      0 63:      &n= bsp;   0

HW TXQ 0: axq_depth=3D0, axq_aggr_depth=3D0
HW TXQ 1: axq_depth=3D0, axq_aggr_depth=3D0
HW TXQ 2: axq_depth=3D0, axq_aggr_depth=3D0
HW TXQ 3: axq_depth=3D0, axq_aggr_depth=3D0
HW TXQ 8: axq_depth=3D0, axq_aggr_depth=3D0
Total TX buffers: 512; Total TX buffers busy: 0
no tx bufs (empty list): 0
no tx bufs (was busy): 0
aggr single packet: 14553
aggr single packet w/ BAW closed: 0
aggr non-baw packet: 1
aggr aggregate packet: 121203
aggr single packet low hwq: 643315
aggr sched, no work: 15414
 0:          0 = 1:          0  2: &= nbsp;     7931  3:     &n= bsp; 5744
 4:       5116  5:  &= nbsp;    4554  6:      = 4716  7:       4577
 8:       5284  9:  &= nbsp;    5097 10:       4822= 11:       9425
12:       3123 13:    = ;   2628 14:       2671 15: &n= bsp;     2322
16:       5036 17:    = ;   2442 18:       4558 19: &n= bsp;     8300
20:       6962 21:    = ;   4679 22:       2404 23: &n= bsp;     1270
24:       1076 25:    = ;    929 26:        866= 27:        856
28:        835 29:   =      895 30:       1033= 31:       1016
32:      10037 33:    &nbs= p;     0 34:       &= nbsp;  0 35:          0=
36:          0 37: &n= bsp;        0 38:    = ;      0 39:      &n= bsp;   0
40:          0 41: &n= bsp;        0 42:    = ;      0 43:      &n= bsp;   0
44:          0 45: &n= bsp;        0 46:    = ;      0 47:      &n= bsp;   0
48:          0 49: &n= bsp;        0 50:    = ;      0 51:      &n= bsp;   0
52:          0 53: &n= bsp;        0 54:    = ;      0 55:      &n= bsp;   0
56:          0 57: &n= bsp;        0 58:    = ;      0 59:      &n= bsp;   0
60:          0 61: &n= bsp;        0 62:    = ;      0 63:      &n= bsp;   0

HW TXQ 0: axq_depth=3D0, axq_aggr_depth=3D0
HW TXQ 1: axq_depth=3D2, axq_aggr_depth=3D2
HW TXQ 2: axq_depth=3D0, axq_aggr_depth=3D0
HW TXQ 3: axq_depth=3D0, axq_aggr_depth=3D0
HW TXQ 8: axq_depth=3D0, axq_aggr_depth=3D0
Total TX buffers: 481; Total TX buffers busy: 0
no tx bufs (empty list): 0
no tx bufs (was busy): 0
aggr single packet: 14928
aggr single packet w/ BAW closed: 0
aggr non-baw packet: 1
aggr aggregate packet: 125149
aggr single packet low hwq: 645085
aggr sched, no work: 15673
 0:          0 = 1:          0  2: &= nbsp;     8187  3:     &n= bsp; 5884
 4:       5230  5:  &= nbsp;    4653  6:      = 4801  7:       4649
 8:       5347  9:  &= nbsp;    5168 10:       4891= 11:       9496
12:       3305 13:    = ;   2715 14:       2753 15: &n= bsp;     2399
16:       7473 17:    = ;   2464 18:       4565 19: &n= bsp;     8304
20:       6966 21:    = ;   4681 22:       2405 23: &n= bsp;     1270
24:       1077 25:    = ;    929 26:        866= 27:        856
28:        835 29:   =      895 30:       1033= 31:       1016
32:      10037 33:    &nbs= p;     0 34:       &= nbsp;  0 35:          0=
36:          0 37: &n= bsp;        0 38:    = ;      0 39:      &n= bsp;   0
40:          0 41: &n= bsp;        0 42:    = ;      0 43:      &n= bsp;   0
44:          0 45: &n= bsp;        0 46:    = ;      0 47:      &n= bsp;   0
48:          0 49: &n= bsp;        0 50:    = ;      0 51:      &n= bsp;   0
52:          0 53: &n= bsp;        0 54:    = ;      0 55:      &n= bsp;   0
56:          0 57: &n= bsp;        0 58:    = ;      0 59:      &n= bsp;   0
60:          0 61: &n= bsp;        0 62:    = ;      0 63:      &n= bsp;   0

HW TXQ 0: axq_depth=3D0, axq_aggr_depth=3D0
HW TXQ 1: axq_depth=3D2, axq_aggr_depth=3D1
HW TXQ 2: axq_depth=3D0, axq_aggr_depth=3D0
HW TXQ 3: axq_depth=3D0, axq_aggr_depth=3D0
HW TXQ 8: axq_depth=3D0, axq_aggr_depth=3D0
Total TX buffers: 502; Total TX buffers busy: 0
no tx bufs (empty list): 0
no tx bufs (was busy): 0
aggr single packet: 15237
aggr single packet w/ BAW closed: 0
aggr non-baw packet: 1
aggr aggregate packet: 127403
aggr single packet low hwq: 646324
aggr sched, no work: 15851
 0:          0 = 1:          0  2: &= nbsp;     8360  3:     &n= bsp; 5998
 4:       5304  5:  &= nbsp;    4703  6:      = 4846  7:       4701
 8:       5377  9:  &= nbsp;    5216 10:       4935= 11:       9544
12:       3383 13:    = ;   2753 14:       2811 15: &n= bsp;     2441
16:       8822 17:    = ;   2474 18:       4566 19: &n= bsp;     8304
20:       6966 21:    = ;   4681 22:       2406 23: &n= bsp;     1270
24:       1077 25:    = ;    929 26:        866= 27:        856
28:        835 29:   =      895 30:       1033= 31:       1016
32:      10037 33:    &nbs= p;     0 34:       &= nbsp;  0 35:          0=
36:          0 37: &n= bsp;        0 38:    = ;      0 39:      &n= bsp;   0
40:          0 41: &n= bsp;        0 42:    = ;      0 43:      &n= bsp;   0
44:          0 45: &n= bsp;        0 46:    = ;      0 47:      &n= bsp;   0
48:          0 49: &n= bsp;        0 50:    = ;      0 51:      &n= bsp;   0
52:          0 53: &n= bsp;        0 54:    = ;      0 55:      &n= bsp;   0
56:          0 57: &n= bsp;        0 58:    = ;      0 59:      &n= bsp;   0
60:          0 61: &n= bsp;        0 62:    = ;      0 63:      &n= bsp;   0

HW TXQ 0: axq_depth=3D0, axq_aggr_depth=3D0
HW TXQ 1: axq_depth=3D2, axq_aggr_depth=3D2
HW TXQ 2: axq_depth=3D0, axq_aggr_depth=3D0
HW TXQ 3: axq_depth=3D0, axq_aggr_depth=3D0
HW TXQ 8: axq_depth=3D0, axq_aggr_depth=3D0
Total TX buffers: 356; Total TX buffers busy: 0


On 19/03/2012 21:49, Adrian Chadd wrote:
Just check the txagg sysctl and mae sure your buffer count stays up around 512.

I want to make sure that buffers aren't being leaked.

Thanks again!
Sent from my Palm Pre on AT&T
On Mar 19, 2012 2:38 PM, Vincent Hoffman <vince@unsane.co.uk> wrote:

Hi Adrian,


This patch is looking good as yet, I've repeated tests that were
previously causing timeouts and as yet not been able cause a timeout
after applying this patch.

Its not definitive but so far it appears to have resolved this issue
for me.


Regards,
Vince Hoffman

=20 --Alternative__boundary__1332198551683-- From owner-freebsd-wireless@FreeBSD.ORG Mon Mar 19 23:20:13 2012 Return-Path: Delivered-To: freebsd-wireless@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CF543106566C for ; Mon, 19 Mar 2012 23:20:13 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id B91978FC0C for ; Mon, 19 Mar 2012 23:20:13 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q2JNKD1U014173 for ; Mon, 19 Mar 2012 23:20:13 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q2JNKDeD014172; Mon, 19 Mar 2012 23:20:13 GMT (envelope-from gnats) Date: Mon, 19 Mar 2012 23:20:13 GMT Message-Id: <201203192320.q2JNKDeD014172@freefall.freebsd.org> To: freebsd-wireless@FreeBSD.org From: Vincent Hoffman Cc: Subject: Re: kern/166190: [ath] TX hangs and frames stuck in TX queue X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Vincent Hoffman 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, 19 Mar 2012 23:20:13 -0000 The following reply was made to PR kern/166190; it has been noted by GNATS. From: Vincent Hoffman To: Adrian Chadd Cc: "bug-followup@freebsd.org" Subject: Re: kern/166190: [ath] TX hangs and frames stuck in TX queue Date: Mon, 19 Mar 2012 23:12:42 +0000 This is a multi-part message in MIME format. --------------060900020802060605060409 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Oops sorry missed the important bit off. Yes then they returned to 512 and have continued returning to 512. Vince On 19/03/2012 23:09, Adrian Chadd wrote: > Then they returned to 512, right? > > > Adrian > > > > Sent from my Palm Pre on AT&T > > ------------------------------------------------------------------------ > On Mar 19, 2012 3:11 PM, Vincent Hoffman wrote: > > During an iperf test > Total TX buffers went from 512 -> 356) > > iperf output (tcp, sending form freebsd machine to osx laptop [ 4] > 0.0-60.2 sec 154 MBytes 21.4 Mbits/sec) > > dmesg output: > > no tx bufs (empty list): 0 > no tx bufs (was busy): 0 > aggr single packet: 14372 > aggr single packet w/ BAW closed: 0 > aggr non-baw packet: 1 > aggr aggregate packet: 119987 > aggr single packet low hwq: 641424 > aggr sched, no work: 15333 > 0: 0 1: 0 2: 7811 3: 5690 > 4: 5077 5: 4509 6: 4675 7: 4546 > 8: 5255 9: 5061 10: 4796 11: 9393 > 12: 3094 13: 2604 14: 2647 15: 2301 > 16: 4372 17: 2440 18: 4558 19: 8300 > 20: 6962 21: 4679 22: 2404 23: 1270 > 24: 1076 25: 929 26: 866 27: 856 > 28: 835 29: 895 30: 1033 31: 1016 > 32: 10037 33: 0 34: 0 35: 0 > 36: 0 37: 0 38: 0 39: 0 > 40: 0 41: 0 42: 0 43: 0 > 44: 0 45: 0 46: 0 47: 0 > 48: 0 49: 0 50: 0 51: 0 > 52: 0 53: 0 54: 0 55: 0 > 56: 0 57: 0 58: 0 59: 0 > 60: 0 61: 0 62: 0 63: 0 > > HW TXQ 0: axq_depth=0, axq_aggr_depth=0 > HW TXQ 1: axq_depth=0, axq_aggr_depth=0 > HW TXQ 2: axq_depth=0, axq_aggr_depth=0 > HW TXQ 3: axq_depth=0, axq_aggr_depth=0 > HW TXQ 8: axq_depth=0, axq_aggr_depth=0 > Total TX buffers: 512; Total TX buffers busy: 0 > no tx bufs (empty list): 0 > no tx bufs (was busy): 0 > aggr single packet: 14553 > aggr single packet w/ BAW closed: 0 > aggr non-baw packet: 1 > aggr aggregate packet: 121203 > aggr single packet low hwq: 643315 > aggr sched, no work: 15414 > 0: 0 1: 0 2: 7931 3: 5744 > 4: 5116 5: 4554 6: 4716 7: 4577 > 8: 5284 9: 5097 10: 4822 11: 9425 > 12: 3123 13: 2628 14: 2671 15: 2322 > 16: 5036 17: 2442 18: 4558 19: 8300 > 20: 6962 21: 4679 22: 2404 23: 1270 > 24: 1076 25: 929 26: 866 27: 856 > 28: 835 29: 895 30: 1033 31: 1016 > 32: 10037 33: 0 34: 0 35: 0 > 36: 0 37: 0 38: 0 39: 0 > 40: 0 41: 0 42: 0 43: 0 > 44: 0 45: 0 46: 0 47: 0 > 48: 0 49: 0 50: 0 51: 0 > 52: 0 53: 0 54: 0 55: 0 > 56: 0 57: 0 58: 0 59: 0 > 60: 0 61: 0 62: 0 63: 0 > > HW TXQ 0: axq_depth=0, axq_aggr_depth=0 > HW TXQ 1: axq_depth=2, axq_aggr_depth=2 > HW TXQ 2: axq_depth=0, axq_aggr_depth=0 > HW TXQ 3: axq_depth=0, axq_aggr_depth=0 > HW TXQ 8: axq_depth=0, axq_aggr_depth=0 > Total TX buffers: 481; Total TX buffers busy: 0 > no tx bufs (empty list): 0 > no tx bufs (was busy): 0 > aggr single packet: 14928 > aggr single packet w/ BAW closed: 0 > aggr non-baw packet: 1 > aggr aggregate packet: 125149 > aggr single packet low hwq: 645085 > aggr sched, no work: 15673 > 0: 0 1: 0 2: 8187 3: 5884 > 4: 5230 5: 4653 6: 4801 7: 4649 > 8: 5347 9: 5168 10: 4891 11: 9496 > 12: 3305 13: 2715 14: 2753 15: 2399 > 16: 7473 17: 2464 18: 4565 19: 8304 > 20: 6966 21: 4681 22: 2405 23: 1270 > 24: 1077 25: 929 26: 866 27: 856 > 28: 835 29: 895 30: 1033 31: 1016 > 32: 10037 33: 0 34: 0 35: 0 > 36: 0 37: 0 38: 0 39: 0 > 40: 0 41: 0 42: 0 43: 0 > 44: 0 45: 0 46: 0 47: 0 > 48: 0 49: 0 50: 0 51: 0 > 52: 0 53: 0 54: 0 55: 0 > 56: 0 57: 0 58: 0 59: 0 > 60: 0 61: 0 62: 0 63: 0 > > HW TXQ 0: axq_depth=0, axq_aggr_depth=0 > HW TXQ 1: axq_depth=2, axq_aggr_depth=1 > HW TXQ 2: axq_depth=0, axq_aggr_depth=0 > HW TXQ 3: axq_depth=0, axq_aggr_depth=0 > HW TXQ 8: axq_depth=0, axq_aggr_depth=0 > Total TX buffers: 502; Total TX buffers busy: 0 > no tx bufs (empty list): 0 > no tx bufs (was busy): 0 > aggr single packet: 15237 > aggr single packet w/ BAW closed: 0 > aggr non-baw packet: 1 > aggr aggregate packet: 127403 > aggr single packet low hwq: 646324 > aggr sched, no work: 15851 > 0: 0 1: 0 2: 8360 3: 5998 > 4: 5304 5: 4703 6: 4846 7: 4701 > 8: 5377 9: 5216 10: 4935 11: 9544 > 12: 3383 13: 2753 14: 2811 15: 2441 > 16: 8822 17: 2474 18: 4566 19: 8304 > 20: 6966 21: 4681 22: 2406 23: 1270 > 24: 1077 25: 929 26: 866 27: 856 > 28: 835 29: 895 30: 1033 31: 1016 > 32: 10037 33: 0 34: 0 35: 0 > 36: 0 37: 0 38: 0 39: 0 > 40: 0 41: 0 42: 0 43: 0 > 44: 0 45: 0 46: 0 47: 0 > 48: 0 49: 0 50: 0 51: 0 > 52: 0 53: 0 54: 0 55: 0 > 56: 0 57: 0 58: 0 59: 0 > 60: 0 61: 0 62: 0 63: 0 > > HW TXQ 0: axq_depth=0, axq_aggr_depth=0 > HW TXQ 1: axq_depth=2, axq_aggr_depth=2 > HW TXQ 2: axq_depth=0, axq_aggr_depth=0 > HW TXQ 3: axq_depth=0, axq_aggr_depth=0 > HW TXQ 8: axq_depth=0, axq_aggr_depth=0 > Total TX buffers: 356; Total TX buffers busy: 0 > > > On 19/03/2012 21:49, Adrian Chadd wrote: >> Just check the txagg sysctl and mae sure your buffer count stays up >> around 512. >> >> I want to make sure that buffers aren't being leaked. >> >> Thanks again! >> >> >> >> Sent from my Palm Pre on AT&T >> >> ------------------------------------------------------------------------ >> On Mar 19, 2012 2:38 PM, Vincent Hoffman wrote: >> >> Hi Adrian, >> >> >> This patch is looking good as yet, I've repeated tests that were >> previously causing timeouts and as yet not been able cause a timeout >> after applying this patch. >> >> Its not definitive but so far it appears to have resolved this issue >> for me. >> >> >> Regards, >> Vince Hoffman > --------------060900020802060605060409 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit Oops sorry missed the important bit off. Yes then they returned to 512 and have continued returning to 512.

Vince

On 19/03/2012 23:09, Adrian Chadd wrote:
Then they returned to 512, right?


Adrian
Sent from my Palm Pre on AT&T
On Mar 19, 2012 3:11 PM, Vincent Hoffman <vince@unsane.co.uk> wrote:

During an iperf test
Total TX buffers went from  512 -> 356)

iperf output (tcp, sending form freebsd machine to osx laptop [  4]  0.0-60.2 sec   154 MBytes  21.4 Mbits/sec)

dmesg output:

no tx bufs (empty list): 0
no tx bufs (was busy): 0
aggr single packet: 14372
aggr single packet w/ BAW closed: 0
aggr non-baw packet: 1
aggr aggregate packet: 119987
aggr single packet low hwq: 641424
aggr sched, no work: 15333
 0:          0  1:          0  2:       7811  3:       5690
 4:       5077  5:       4509  6:       4675  7:       4546
 8:       5255  9:       5061 10:       4796 11:       9393
12:       3094 13:       2604 14:       2647 15:       2301
16:       4372 17:       2440 18:       4558 19:       8300
20:       6962 21:       4679 22:       2404 23:       1270
24:       1076 25:        929 26:        866 27:        856
28:        835 29:        895 30:       1033 31:       1016
32:      10037 33:          0 34:          0 35:          0
36:          0 37:          0 38:          0 39:          0
40:          0 41:          0 42:          0 43:          0
44:          0 45:          0 46:          0 47:          0
48:          0 49:          0 50:          0 51:          0
52:          0 53:          0 54:          0 55:          0
56:          0 57:          0 58:          0 59:          0
60:          0 61:          0 62:          0 63:          0

HW TXQ 0: axq_depth=0, axq_aggr_depth=0
HW TXQ 1: axq_depth=0, axq_aggr_depth=0
HW TXQ 2: axq_depth=0, axq_aggr_depth=0
HW TXQ 3: axq_depth=0, axq_aggr_depth=0
HW TXQ 8: axq_depth=0, axq_aggr_depth=0
Total TX buffers: 512; Total TX buffers busy: 0
no tx bufs (empty list): 0
no tx bufs (was busy): 0
aggr single packet: 14553
aggr single packet w/ BAW closed: 0
aggr non-baw packet: 1
aggr aggregate packet: 121203
aggr single packet low hwq: 643315
aggr sched, no work: 15414
 0:          0  1:          0  2:       7931  3:       5744
 4:       5116  5:       4554  6:       4716  7:       4577
 8:       5284  9:       5097 10:       4822 11:       9425
12:       3123 13:       2628 14:       2671 15:       2322
16:       5036 17:       2442 18:       4558 19:       8300
20:       6962 21:       4679 22:       2404 23:       1270
24:       1076 25:        929 26:        866 27:        856
28:        835 29:        895 30:       1033 31:       1016
32:      10037 33:          0 34:          0 35:          0
36:          0 37:          0 38:          0 39:          0
40:          0 41:          0 42:          0 43:          0
44:          0 45:          0 46:          0 47:          0
48:          0 49:          0 50:          0 51:          0
52:          0 53:          0 54:          0 55:          0
56:          0 57:          0 58:          0 59:          0
60:          0 61:          0 62:          0 63:          0

HW TXQ 0: axq_depth=0, axq_aggr_depth=0
HW TXQ 1: axq_depth=2, axq_aggr_depth=2
HW TXQ 2: axq_depth=0, axq_aggr_depth=0
HW TXQ 3: axq_depth=0, axq_aggr_depth=0
HW TXQ 8: axq_depth=0, axq_aggr_depth=0
Total TX buffers: 481; Total TX buffers busy: 0
no tx bufs (empty list): 0
no tx bufs (was busy): 0
aggr single packet: 14928
aggr single packet w/ BAW closed: 0
aggr non-baw packet: 1
aggr aggregate packet: 125149
aggr single packet low hwq: 645085
aggr sched, no work: 15673
 0:          0  1:          0  2:       8187  3:       5884
 4:       5230  5:       4653  6:       4801  7:       4649
 8:       5347  9:       5168 10:       4891 11:       9496
12:       3305 13:       2715 14:       2753 15:       2399
16:       7473 17:       2464 18:       4565 19:       8304
20:       6966 21:       4681 22:       2405 23:       1270
24:       1077 25:        929 26:        866 27:        856
28:        835 29:        895 30:       1033 31:       1016
32:      10037 33:          0 34:          0 35:          0
36:          0 37:          0 38:          0 39:          0
40:          0 41:          0 42:          0 43:          0
44:          0 45:          0 46:          0 47:          0
48:          0 49:          0 50:          0 51:          0
52:          0 53:          0 54:          0 55:          0
56:          0 57:          0 58:          0 59:          0
60:          0 61:          0 62:          0 63:          0

HW TXQ 0: axq_depth=0, axq_aggr_depth=0
HW TXQ 1: axq_depth=2, axq_aggr_depth=1
HW TXQ 2: axq_depth=0, axq_aggr_depth=0
HW TXQ 3: axq_depth=0, axq_aggr_depth=0
HW TXQ 8: axq_depth=0, axq_aggr_depth=0
Total TX buffers: 502; Total TX buffers busy: 0
no tx bufs (empty list): 0
no tx bufs (was busy): 0
aggr single packet: 15237
aggr single packet w/ BAW closed: 0
aggr non-baw packet: 1
aggr aggregate packet: 127403
aggr single packet low hwq: 646324
aggr sched, no work: 15851
 0:          0  1:          0  2:       8360  3:       5998
 4:       5304  5:       4703  6:       4846  7:       4701
 8:       5377  9:       5216 10:       4935 11:       9544
12:       3383 13:       2753 14:       2811 15:       2441
16:       8822 17:       2474 18:       4566 19:       8304
20:       6966 21:       4681 22:       2406 23:       1270
24:       1077 25:        929 26:        866 27:        856
28:        835 29:        895 30:       1033 31:       1016
32:      10037 33:          0 34:          0 35:          0
36:          0 37:          0 38:          0 39:          0
40:          0 41:          0 42:          0 43:          0
44:          0 45:          0 46:          0 47:          0
48:          0 49:          0 50:          0 51:          0
52:          0 53:          0 54:          0 55:          0
56:          0 57:          0 58:          0 59:          0
60:          0 61:          0 62:          0 63:          0

HW TXQ 0: axq_depth=0, axq_aggr_depth=0
HW TXQ 1: axq_depth=2, axq_aggr_depth=2
HW TXQ 2: axq_depth=0, axq_aggr_depth=0
HW TXQ 3: axq_depth=0, axq_aggr_depth=0
HW TXQ 8: axq_depth=0, axq_aggr_depth=0
Total TX buffers: 356; Total TX buffers busy: 0


On 19/03/2012 21:49, Adrian Chadd wrote:
Just check the txagg sysctl and mae sure your buffer count stays up around 512.

I want to make sure that buffers aren't being leaked.

Thanks again!
Sent from my Palm Pre on AT&T
On Mar 19, 2012 2:38 PM, Vincent Hoffman <vince@unsane.co.uk> wrote:

Hi Adrian,


This patch is looking good as yet, I've repeated tests that were
previously causing timeouts and as yet not been able cause a timeout
after applying this patch.

Its not definitive but so far it appears to have resolved this issue
for me.


Regards,
Vince Hoffman


--------------060900020802060605060409-- From owner-freebsd-wireless@FreeBSD.ORG Tue Mar 20 03:30:07 2012 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9D06C106564A; Tue, 20 Mar 2012 03:30:07 +0000 (UTC) (envelope-from erichfreebsdlist@ovitrap.com) Received: from alogreentechnologies.com (alogreentechnologies.com [67.212.226.44]) by mx1.freebsd.org (Postfix) with ESMTP id 61E308FC12; Tue, 20 Mar 2012 03:30:07 +0000 (UTC) Received: from amd620.ovitrap.com ([49.128.188.2]) (authenticated bits=0) by alogreentechnologies.com (8.13.1/8.13.1) with ESMTP id q2K36A3Y007539; Mon, 19 Mar 2012 21:06:12 -0600 From: Erich Dollansky To: PseudoCylon Date: Tue, 20 Mar 2012 10:06:22 +0700 User-Agent: KMail/1.13.7 (FreeBSD/8.3-PRERELEASE; KDE/4.7.4; amd64; ; ) References: <201112171258.56891.erichfreebsdlist@ovitrap.com> <201112180759.03722.erichfreebsdlist@ovitrap.com> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201203201006.22954.erichfreebsdlist@ovitrap.com> Cc: freebsd-wireless@freebsd.org, Bernhard Schmidt Subject: Regression 8.2 --> 8.3 PRERELEASE Re: Zyxel NWD210N not accepted at boot time but after plugging it in again X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.5 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, 20 Mar 2012 03:30:07 -0000 Hi, I have upgraded the machine recently and the interface was not seen at boot time as before. AMD620:///home/erich (root) > uname -a FreeBSD AMD620.ovitrap.com 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #31: Thu Mar 8 18:29:47 WIT 2012 erich@AMD620.ovitrap.com:/usr/obj/usr/src/sys/AsusAMD620 amd64 I am not able to tell when the problem came up again as I use this stick only when I am at the client's side. Erich On Sunday 18 December 2011 12:32:46 PseudoCylon wrote: > On Sat, Dec 17, 2011 at 5:59 PM, Erich Dollansky > wrote: > > Hi, > > > > On Sunday 18 December 2011 06:45:18 PseudoCylon wrote: > >> On Sat, Dec 17, 2011 at 6:11 AM, Bernhard Schmidt wrote: > >> > On Saturday 17 December 2011 06:58:56 Erich Dollansky wrote: > >> > > >> > run(4) tries to load the firmware on attach at which point the root > >> > filesystem isn't yet mounted. Actually I think the prefered behaviour > >> > is to load it during init, not sure this is possible for run(4) > >> > though. Someone should check this. :) > >> > > >> mmm... It seems "someone" is me. > >> > >> At the quick look, the firmware could be loaded during the init. Give > >> me a few days, I will try to change. > >> > > if you need more information, just ask me. Please do not wonder if you do not get them at the spot. I am in a very remote location where electricity is cut off during the day. > > > Actually, it was quite straight forward. The patch follows. > > Also, a tarball is attached which include patch to man.4/run.4 and new > firmware. I don't know what has been changed, but I'd appreciate if > you try new firmware out. > > > AK > > ## begin patch ## > > diff --git a/dev/usb/wlan/if_run.c b/dev/usb/wlan/if_run.c > index b2c3c19..ef7c62c 100644 > --- a/dev/usb/wlan/if_run.c > +++ b/dev/usb/wlan/if_run.c > @@ -17,7 +17,7 @@ > */ > > #include > -__FBSDID("$FreeBSD: src/sys/dev/usb/wlan/if_run.c,v 1.29 2011/12/17 > 10:23:17 bschmidt Exp $"); > +__FBSDID("$FreeBSD$"); > > /*- > * Ralink Technology RT2700U/RT2800U/RT3000U chipset driver. > @@ -600,12 +600,6 @@ run_attach(device_t self) > sc->mac_ver, sc->mac_rev, run_get_rf(sc->rf_rev), > sc->ntxchains, sc->nrxchains, ether_sprintf(sc->sc_bssid)); > > - if ((error = run_load_microcode(sc)) != 0) { > - device_printf(sc->sc_dev, "could not load 8051 microcode\n"); > - RUN_UNLOCK(sc); > - goto detach; > - } > - > RUN_UNLOCK(sc); > > ifp = sc->sc_ifp = if_alloc(IFT_IEEE80211); > @@ -1050,8 +1044,9 @@ run_load_microcode(struct run_softc *sc) > error = ETIMEDOUT; > goto fail; > } > - device_printf(sc->sc_dev, "firmware %s loaded\n", > - (base == fw->data) ? "RT2870" : "RT3071"); > + device_printf(sc->sc_dev, "firmware %s ver. %u.%u loaded\n", > + (base == fw->data) ? "RT2870" : "RT3071", > + *(base + 4092), *(base + 4093)); > > fail: > firmware_put(fw, FIRMWARE_UNLOAD); > @@ -4677,6 +4672,11 @@ run_init_locked(struct run_softc *sc) > > run_stop(sc); > > + if (run_load_microcode(sc) != 0) { > + device_printf(sc->sc_dev, "could not load 8051 microcode\n"); > + goto fail; > + } > + > for (ntries = 0; ntries < 100; ntries++) { > if (run_read(sc, RT2860_ASIC_VER_ID, &tmp) != 0) > goto fail; > From owner-freebsd-wireless@FreeBSD.ORG Tue Mar 20 04:57:05 2012 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 20C6D106566B for ; Tue, 20 Mar 2012 04:57:05 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by mx1.freebsd.org (Postfix) with ESMTP id E91BC8FC0C for ; Tue, 20 Mar 2012 04:57:04 +0000 (UTC) Received: by dald2 with SMTP id d2so11850080dal.13 for ; Mon, 19 Mar 2012 21:57:04 -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; bh=WUOJxZIGRQ6FP6J6eb5oQIy44ltSnRD46n3y5u7upzw=; b=foHCIYDTm3LGL5kFHOk1X10szBmIgg4eC/EIkDkKLpmRuuvYMl6RDJqcF1ohSXn2vh 4zBOjKMlwXwud9RDggMef8PmZi0CfkGM3wS4YXuuLGWddkrDUteavHGkxbLHggHD/YYI 6K5xERR06FVmc9Ka47wZh7l49H91YU3PNXTcoVqULPPEU+0iPiNuNdfyX+6IjTQpmSBI L0yTv3zCA60IF5ofRB1fSLwM1AXUD5cwjEEAT/zM5gW80c3Ql0fHtseiX+tsxi7nwOc7 +eoTOnJXF7p5aDGRS7sg7gQZZoD6f0sNXGnnlvTwatgEhF6Q29gk6lK2ATr+bjjGLSue VgmQ== MIME-Version: 1.0 Received: by 10.68.130.6 with SMTP id oa6mr46114744pbb.96.1332219424782; Mon, 19 Mar 2012 21:57:04 -0700 (PDT) Received: by 10.143.33.5 with HTTP; Mon, 19 Mar 2012 21:57:04 -0700 (PDT) In-Reply-To: <4F67B086.6050104@unsane.co.uk> References: <4f67a939.e61f440a.4abb.ffffee38@mx.google.com> <4F67B086.6050104@unsane.co.uk> Date: Mon, 19 Mar 2012 21:57:04 -0700 Message-ID: From: Adrian Chadd To: Vincent Hoffman Content-Type: text/plain; charset=ISO-8859-1 Cc: "freebsd-wireless@freebsd.org" Subject: Re: ath0 timeout was "Re: (more) bugs fixed in -HEAD, AP mode is now mostly (again) stable!" X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.5 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, 20 Mar 2012 04:57:05 -0000 Hi, I've committed this to -HEAD. I'd appreciate it if all people testing ath(4) 802.11n support would update to this and try things out. I'll test hostap/sta out at home a bit more and report any issues I find. Adrian From owner-freebsd-wireless@FreeBSD.ORG Tue Mar 20 05:00:26 2012 Return-Path: Delivered-To: freebsd-wireless@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 17962106566C for ; Tue, 20 Mar 2012 05:00:25 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id DE3EA8FC15 for ; Tue, 20 Mar 2012 05:00:25 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q2K50Pgi034784 for ; Tue, 20 Mar 2012 05:00:25 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q2K50PMW034783; Tue, 20 Mar 2012 05:00:25 GMT (envelope-from gnats) Date: Tue, 20 Mar 2012 05:00:25 GMT Message-Id: <201203200500.q2K50PMW034783@freefall.freebsd.org> To: freebsd-wireless@FreeBSD.org From: dfilter@FreeBSD.ORG (dfilter service) Cc: Subject: Re: kern/166190: commit references a PR X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dfilter service 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, 20 Mar 2012 05:00:26 -0000 The following reply was made to PR kern/166190; it has been noted by GNATS. From: dfilter@FreeBSD.ORG (dfilter service) To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/166190: commit references a PR Date: Tue, 20 Mar 2012 04:50:36 +0000 (UTC) Author: adrian Date: Tue Mar 20 04:50:25 2012 New Revision: 233227 URL: http://svn.freebsd.org/changeset/base/233227 Log: Delay sequence number allocation for A-MPDU until just before the frame is queued to the hardware. Because multiple concurrent paths can execute ath_start(), multiple concurrent paths can push frames into the software/hardware TX queue and since preemption/interrupting can occur, there's the possibility that a gap in time will occur between allocating the sequence number and queuing it to the hardware. Because of this, it's possible that a thread will have allocated a sequence number and then be preempted by another thread doing the same. If the second thread sneaks the frame into the BAW, the (earlier) sequence number of the first frame will be now outside the BAW and will result in the frame being constantly re-added to the tail of the queue. There it will live until the sequence numbers cycle around again. This also creates a hole in the RX BAW tracking which can also cause issues. This patch delays the sequence number allocation to occur only just before the frame is going to be added to the BAW. I've been wanting to do this anyway as part of a general code tidyup but I've not gotten around to it. This fixes the PR. However, it still makes it quite difficult to try and ensure in-order queuing and dequeuing of frames. Since multiple copies of ath_start() can be run at the same time (eg one TXing process thread, one TX completion task/one RX task) the driver may end up having frames dequeued and pushed into the hardware slightly/occasionally out of order. And, to make matters more annoying, net80211 may have the same behaviour - in the non-aggregation case, the TX code allocates sequence numbers before it's thrown to the driver. I'll open another PR to investigate this and potentially introduce some kind of final-pass TX serialisation before frames are thrown to the hardware. It's also very likely worthwhile adding some debugging code into ath(4) and net80211 to catch when/if this does occur. PR: kern/166190 Modified: head/sys/dev/ath/if_ath_debug.c head/sys/dev/ath/if_ath_tx.c head/sys/dev/ath/if_ath_tx.h head/sys/dev/ath/if_ath_tx_ht.c head/sys/dev/ath/if_athvar.h Modified: head/sys/dev/ath/if_ath_debug.c ============================================================================== --- head/sys/dev/ath/if_ath_debug.c Mon Mar 19 23:28:13 2012 (r233226) +++ head/sys/dev/ath/if_ath_debug.c Tue Mar 20 04:50:25 2012 (r233227) @@ -135,19 +135,23 @@ ath_printtxbuf(struct ath_softc *sc, con printf("Q%u[%3u]", qnum, ix); while (bf != NULL) { for (i = 0, ds = bf->bf_desc; i < bf->bf_nseg; i++, ds++) { - printf(" (DS.V:%p DS.P:%p) L:%08x D:%08x F:%04x%s\n" - " TXF: %04x Seq: %d swtry: %d ADDBAW?: %d DOBAW?: %d\n" - " %08x %08x %08x %08x %08x %08x\n", + printf(" (DS.V:%p DS.P:%p) L:%08x D:%08x F:%04x%s\n", ds, (const struct ath_desc *)bf->bf_daddr + i, ds->ds_link, ds->ds_data, bf->bf_txflags, - !done ? "" : (ts->ts_status == 0) ? " *" : " !", + !done ? "" : (ts->ts_status == 0) ? " *" : " !"); + printf(" TXF: %04x Seq: %d swtry: %d ADDBAW?: %d DOBAW?: %d\n", bf->bf_state.bfs_flags, bf->bf_state.bfs_seqno, bf->bf_state.bfs_retries, bf->bf_state.bfs_addedbaw, - bf->bf_state.bfs_dobaw, + bf->bf_state.bfs_dobaw); + printf(" SEQNO_ASSIGNED: %d, NEED_SEQNO: %d\n", + bf->bf_state.bfs_seqno_assigned, + bf->bf_state.bfs_need_seqno); + printf(" %08x %08x %08x %08x %08x %08x\n", ds->ds_ctl0, ds->ds_ctl1, - ds->ds_hw[0], ds->ds_hw[1], ds->ds_hw[2], ds->ds_hw[3]); + ds->ds_hw[0], ds->ds_hw[1], + ds->ds_hw[2], ds->ds_hw[3]); if (ah->ah_magic == 0x20065416) { printf(" %08x %08x %08x %08x %08x %08x %08x %08x\n", ds->ds_hw[4], ds->ds_hw[5], ds->ds_hw[6], Modified: head/sys/dev/ath/if_ath_tx.c ============================================================================== --- head/sys/dev/ath/if_ath_tx.c Mon Mar 19 23:28:13 2012 (r233226) +++ head/sys/dev/ath/if_ath_tx.c Tue Mar 20 04:50:25 2012 (r233227) @@ -109,10 +109,10 @@ static int ath_tx_ampdu_pending(struct a int tid); static int ath_tx_ampdu_running(struct ath_softc *sc, struct ath_node *an, int tid); -static ieee80211_seq ath_tx_tid_seqno_assign(struct ath_softc *sc, - struct ieee80211_node *ni, struct ath_buf *bf, struct mbuf *m0); static int ath_tx_action_frame_override_queue(struct ath_softc *sc, struct ieee80211_node *ni, struct mbuf *m0, int *tid); +static int ath_tx_seqno_required(struct ath_softc *sc, + struct ieee80211_node *ni, struct ath_buf *bf, struct mbuf *m0); /* * Whether to use the 11n rate scenario functions or not @@ -1376,7 +1376,7 @@ ath_tx_start(struct ath_softc *sc, struc int ismcast; const struct ieee80211_frame *wh; int is_ampdu, is_ampdu_tx, is_ampdu_pending; - ieee80211_seq seqno; + //ieee80211_seq seqno; uint8_t type, subtype; /* @@ -1428,8 +1428,9 @@ ath_tx_start(struct ath_softc *sc, struc is_ampdu_pending = ath_tx_ampdu_pending(sc, ATH_NODE(ni), tid); is_ampdu = is_ampdu_tx | is_ampdu_pending; - DPRINTF(sc, ATH_DEBUG_SW_TX, "%s: tid=%d, ac=%d, is_ampdu=%d\n", - __func__, tid, pri, is_ampdu); + DPRINTF(sc, ATH_DEBUG_SW_TX, + "%s: bf=%p, tid=%d, ac=%d, is_ampdu=%d\n", + __func__, bf, tid, pri, is_ampdu); /* Multicast frames go onto the software multicast queue */ if (ismcast) @@ -1447,6 +1448,9 @@ ath_tx_start(struct ath_softc *sc, struc /* Do the generic frame setup */ /* XXX should just bzero the bf_state? */ bf->bf_state.bfs_dobaw = 0; + bf->bf_state.bfs_seqno_assigned = 0; + bf->bf_state.bfs_need_seqno = 0; + bf->bf_state.bfs_seqno = -1; /* XXX debugging */ /* A-MPDU TX? Manually set sequence number */ /* Don't do it whilst pending; the net80211 layer still assigns them */ @@ -1459,19 +1463,26 @@ ath_tx_start(struct ath_softc *sc, struc * don't get a sequence number from the current * TID and thus mess with the BAW. */ - seqno = ath_tx_tid_seqno_assign(sc, ni, bf, m0); - if (IEEE80211_QOS_HAS_SEQ(wh) && - subtype != IEEE80211_FC0_SUBTYPE_QOS_NULL) { + //seqno = ath_tx_tid_seqno_assign(sc, ni, bf, m0); + if (ath_tx_seqno_required(sc, ni, bf, m0)) { bf->bf_state.bfs_dobaw = 1; + bf->bf_state.bfs_need_seqno = 1; } ATH_TXQ_UNLOCK(txq); + } else { + /* No AMPDU TX, we've been assigned a sequence number. */ + if (IEEE80211_QOS_HAS_SEQ(wh)) { + bf->bf_state.bfs_seqno_assigned = 1; + bf->bf_state.bfs_seqno = + M_SEQNO_GET(m0) << IEEE80211_SEQ_SEQ_SHIFT; + } } /* * If needed, the sequence number has been assigned. * Squirrel it away somewhere easy to get to. */ - bf->bf_state.bfs_seqno = M_SEQNO_GET(m0) << IEEE80211_SEQ_SEQ_SHIFT; + //bf->bf_state.bfs_seqno = M_SEQNO_GET(m0) << IEEE80211_SEQ_SEQ_SHIFT; /* Is ampdu pending? fetch the seqno and print it out */ if (is_ampdu_pending) @@ -1488,6 +1499,10 @@ ath_tx_start(struct ath_softc *sc, struc /* At this point m0 could have changed! */ m0 = bf->bf_m; + DPRINTF(sc, ATH_DEBUG_SW_TX, + "%s: DONE: bf=%p, tid=%d, ac=%d, is_ampdu=%d, dobaw=%d, seqno=%d\n", + __func__, bf, tid, pri, is_ampdu, bf->bf_state.bfs_dobaw, M_SEQNO_GET(m0)); + #if 1 /* * If it's a multicast frame, do a direct-dispatch to the @@ -1506,6 +1521,8 @@ ath_tx_start(struct ath_softc *sc, struc * reached.) */ if (txq == &avp->av_mcastq) { + DPRINTF(sc, ATH_DEBUG_SW_TX_CTRL, + "%s: bf=%p: mcastq: TX'ing\n", __func__, bf); ATH_TXQ_LOCK(txq); ath_tx_xmit_normal(sc, txq, bf); ATH_TXQ_UNLOCK(txq); @@ -1518,6 +1535,8 @@ ath_tx_start(struct ath_softc *sc, struc ATH_TXQ_UNLOCK(txq); } else { /* add to software queue */ + DPRINTF(sc, ATH_DEBUG_SW_TX_CTRL, + "%s: bf=%p: swq: TX'ing\n", __func__, bf); ath_tx_swq(sc, ni, txq, bf); } #else @@ -1966,16 +1985,41 @@ ath_tx_addto_baw(struct ath_softc *sc, s if (bf->bf_state.bfs_isretried) return; + /* + * If this occurs we're in a lot of trouble. We should try to + * recover from this without the session hanging? + */ + if (! bf->bf_state.bfs_seqno_assigned) { + device_printf(sc->sc_dev, + "%s: bf=%p, seqno_assigned is 0?!\n", __func__, bf); + return; + } + tap = ath_tx_get_tx_tid(an, tid->tid); if (bf->bf_state.bfs_addedbaw) device_printf(sc->sc_dev, - "%s: re-added? tid=%d, seqno %d; window %d:%d; " + "%s: re-added? bf=%p, tid=%d, seqno %d; window %d:%d; " + "baw head=%d tail=%d\n", + __func__, bf, tid->tid, SEQNO(bf->bf_state.bfs_seqno), + tap->txa_start, tap->txa_wnd, tid->baw_head, + tid->baw_tail); + + /* + * Verify that the given sequence number is not outside of the + * BAW. Complain loudly if that's the case. + */ + if (! BAW_WITHIN(tap->txa_start, tap->txa_wnd, + SEQNO(bf->bf_state.bfs_seqno))) { + device_printf(sc->sc_dev, + "%s: bf=%p: outside of BAW?? tid=%d, seqno %d; window %d:%d; " "baw head=%d tail=%d\n", - __func__, tid->tid, SEQNO(bf->bf_state.bfs_seqno), + __func__, bf, tid->tid, SEQNO(bf->bf_state.bfs_seqno), tap->txa_start, tap->txa_wnd, tid->baw_head, tid->baw_tail); + } + /* * ni->ni_txseqs[] is the currently allocated seqno. * the txa state contains the current baw start. @@ -1983,9 +2027,9 @@ ath_tx_addto_baw(struct ath_softc *sc, s index = ATH_BA_INDEX(tap->txa_start, SEQNO(bf->bf_state.bfs_seqno)); cindex = (tid->baw_head + index) & (ATH_TID_MAX_BUFS - 1); DPRINTF(sc, ATH_DEBUG_SW_TX_BAW, - "%s: tid=%d, seqno %d; window %d:%d; index=%d cindex=%d " + "%s: bf=%p, tid=%d, seqno %d; window %d:%d; index=%d cindex=%d " "baw head=%d tail=%d\n", - __func__, tid->tid, SEQNO(bf->bf_state.bfs_seqno), + __func__, bf, tid->tid, SEQNO(bf->bf_state.bfs_seqno), tap->txa_start, tap->txa_wnd, index, cindex, tid->baw_head, tid->baw_tail); @@ -2088,9 +2132,9 @@ ath_tx_update_baw(struct ath_softc *sc, cindex = (tid->baw_head + index) & (ATH_TID_MAX_BUFS - 1); DPRINTF(sc, ATH_DEBUG_SW_TX_BAW, - "%s: tid=%d, baw=%d:%d, seqno=%d, index=%d, cindex=%d, " + "%s: bf=%p: tid=%d, baw=%d:%d, seqno=%d, index=%d, cindex=%d, " "baw head=%d, tail=%d\n", - __func__, tid->tid, tap->txa_start, tap->txa_wnd, seqno, index, + __func__, bf, tid->tid, tap->txa_start, tap->txa_wnd, seqno, index, cindex, tid->baw_head, tid->baw_tail); /* @@ -2171,11 +2215,51 @@ ath_tx_tid_unsched(struct ath_softc *sc, } /* + * Return whether a sequence number is actually required. + * + * A sequence number must only be allocated at the time that a frame + * is considered for addition to the BAW/aggregate and being TXed. + * The sequence number must not be allocated before the frame + * is added to the BAW (protected by the same lock instance) + * otherwise a the multi-entrant TX path may result in a later seqno + * being added to the BAW first. The subsequent addition of the + * earlier seqno would then not go into the BAW as it's now outside + * of said BAW. + * + * This routine is used by ath_tx_start() to mark whether the frame + * should get a sequence number before adding it to the BAW. + * + * Then the actual aggregate TX routines will check whether this + * flag is set and if the frame needs to go into the BAW, it'll + * have a sequence number allocated for it. + */ +static int +ath_tx_seqno_required(struct ath_softc *sc, struct ieee80211_node *ni, + struct ath_buf *bf, struct mbuf *m0) +{ + const struct ieee80211_frame *wh; + uint8_t subtype; + + wh = mtod(m0, const struct ieee80211_frame *); + subtype = wh->i_fc[0] & IEEE80211_FC0_SUBTYPE_MASK; + + /* XXX assert txq lock */ + /* XXX assert ampdu is set */ + + return ((IEEE80211_QOS_HAS_SEQ(wh) && + subtype != IEEE80211_FC0_SUBTYPE_QOS_NULL)); +} + +/* * Assign a sequence number manually to the given frame. * * This should only be called for A-MPDU TX frames. + * + * If this is called after the initial frame setup, make sure you've flushed + * the DMA map or you'll risk sending stale data to the NIC. This routine + * updates the actual frame contents with the relevant seqno. */ -static ieee80211_seq +int ath_tx_tid_seqno_assign(struct ath_softc *sc, struct ieee80211_node *ni, struct ath_buf *bf, struct mbuf *m0) { @@ -2188,8 +2272,22 @@ ath_tx_tid_seqno_assign(struct ath_softc wh = mtod(m0, struct ieee80211_frame *); pri = M_WME_GETAC(m0); /* honor classification */ tid = WME_AC_TO_TID(pri); - DPRINTF(sc, ATH_DEBUG_SW_TX, "%s: pri=%d, tid=%d, qos has seq=%d\n", - __func__, pri, tid, IEEE80211_QOS_HAS_SEQ(wh)); + DPRINTF(sc, ATH_DEBUG_SW_TX, + "%s: bf=%p, pri=%d, tid=%d, qos has seq=%d\n", + __func__, bf, pri, tid, IEEE80211_QOS_HAS_SEQ(wh)); + + if (! bf->bf_state.bfs_need_seqno) { + device_printf(sc->sc_dev, "%s: bf=%p: need_seqno not set?!\n", + __func__, bf); + return -1; + } + /* XXX check for bfs_need_seqno? */ + if (bf->bf_state.bfs_seqno_assigned) { + device_printf(sc->sc_dev, + "%s: bf=%p: seqno already assigned (%d)?!\n", + __func__, bf, SEQNO(bf->bf_state.bfs_seqno)); + return bf->bf_state.bfs_seqno >> IEEE80211_SEQ_SEQ_SHIFT; + } /* XXX Is it a control frame? Ignore */ @@ -2217,9 +2315,14 @@ ath_tx_tid_seqno_assign(struct ath_softc } *(uint16_t *)&wh->i_seq[0] = htole16(seqno << IEEE80211_SEQ_SEQ_SHIFT); M_SEQNO_SET(m0, seqno); + bf->bf_state.bfs_seqno = seqno << IEEE80211_SEQ_SEQ_SHIFT; + bf->bf_state.bfs_seqno_assigned = 1; /* Return so caller can do something with it if needed */ - DPRINTF(sc, ATH_DEBUG_SW_TX, "%s: -> seqno=%d\n", __func__, seqno); + DPRINTF(sc, ATH_DEBUG_SW_TX, "%s: bf=%p: -> seqno=%d\n", + __func__, + bf, + seqno); return seqno; } @@ -2231,9 +2334,11 @@ ath_tx_tid_seqno_assign(struct ath_softc static void ath_tx_xmit_aggr(struct ath_softc *sc, struct ath_node *an, struct ath_buf *bf) { + struct ieee80211_node *ni = &an->an_node; struct ath_tid *tid = &an->an_tid[bf->bf_state.bfs_tid]; struct ath_txq *txq = bf->bf_state.bfs_txq; struct ieee80211_tx_ampdu *tap; + int seqno; ATH_TXQ_LOCK_ASSERT(txq); @@ -2245,10 +2350,63 @@ ath_tx_xmit_aggr(struct ath_softc *sc, s return; } + /* + * TODO: If it's _before_ the BAW left edge, complain very loudly. + * This means something (else) has slid the left edge along + * before we got a chance to be TXed. + */ + + /* + * Is there space in this BAW for another frame? + * If not, don't bother trying to schedule it; just + * throw it back on the queue. + * + * If we allocate the sequence number before we add + * it to the BAW, we risk racing with another TX + * thread that gets in a frame into the BAW with + * seqno greater than ours. We'd then fail the + * below check and throw the frame on the tail of + * the queue. The sender would then have a hole. + * + * XXX again, we're protecting ni->ni_txseqs[tid] + * behind this hardware TXQ lock, like the rest of + * the TIDs that map to it. Ugh. + */ + if (bf->bf_state.bfs_dobaw) { + if (! BAW_WITHIN(tap->txa_start, tap->txa_wnd, + ni->ni_txseqs[bf->bf_state.bfs_tid])) { + ATH_TXQ_INSERT_TAIL(tid, bf, bf_list); + ath_tx_tid_sched(sc, tid); + return; + } + if (! bf->bf_state.bfs_seqno_assigned) { + seqno = ath_tx_tid_seqno_assign(sc, ni, bf, bf->bf_m); + if (seqno < 0) { + device_printf(sc->sc_dev, + "%s: bf=%p, huh, seqno=-1?\n", + __func__, + bf); + /* XXX what can we even do here? */ + } + /* Flush seqno update to RAM */ + /* + * XXX This is required because the dmasetup + * XXX is done early rather than at dispatch + * XXX time. Ew, we should fix this! + */ + bus_dmamap_sync(sc->sc_dmat, bf->bf_dmamap, + BUS_DMASYNC_PREWRITE); + } + } + /* outside baw? queue */ if (bf->bf_state.bfs_dobaw && (! BAW_WITHIN(tap->txa_start, tap->txa_wnd, SEQNO(bf->bf_state.bfs_seqno)))) { + device_printf(sc->sc_dev, + "%s: bf=%p, shouldn't be outside BAW now?!\n", + __func__, + bf); ATH_TXQ_INSERT_TAIL(tid, bf, bf_list); ath_tx_tid_sched(sc, tid); return; @@ -2303,8 +2461,8 @@ ath_tx_swq(struct ath_softc *sc, struct tid = ath_tx_gettid(sc, m0); atid = &an->an_tid[tid]; - DPRINTF(sc, ATH_DEBUG_SW_TX, "%s: bf=%p, pri=%d, tid=%d, qos=%d\n", - __func__, bf, pri, tid, IEEE80211_QOS_HAS_SEQ(wh)); + DPRINTF(sc, ATH_DEBUG_SW_TX, "%s: bf=%p, pri=%d, tid=%d, qos=%d, seqno=%d\n", + __func__, bf, pri, tid, IEEE80211_QOS_HAS_SEQ(wh), SEQNO(bf->bf_state.bfs_seqno)); /* Set local packet state, used to queue packets to hardware */ bf->bf_state.bfs_tid = tid; @@ -2320,34 +2478,34 @@ ath_tx_swq(struct ath_softc *sc, struct ATH_TXQ_LOCK(txq); if (atid->paused) { /* TID is paused, queue */ - DPRINTF(sc, ATH_DEBUG_SW_TX, "%s: paused\n", __func__); + DPRINTF(sc, ATH_DEBUG_SW_TX, "%s: bf=%p: paused\n", __func__, bf); ATH_TXQ_INSERT_TAIL(atid, bf, bf_list); } else if (ath_tx_ampdu_pending(sc, an, tid)) { /* AMPDU pending; queue */ - DPRINTF(sc, ATH_DEBUG_SW_TX, "%s: pending\n", __func__); + DPRINTF(sc, ATH_DEBUG_SW_TX, "%s: bf=%p: pending\n", __func__, bf); ATH_TXQ_INSERT_TAIL(atid, bf, bf_list); /* XXX sched? */ } else if (ath_tx_ampdu_running(sc, an, tid)) { /* AMPDU running, attempt direct dispatch if possible */ if (txq->axq_depth < sc->sc_hwq_limit) { - ath_tx_xmit_aggr(sc, an, bf); DPRINTF(sc, ATH_DEBUG_SW_TX, - "%s: xmit_aggr\n", - __func__); + "%s: bf=%p: xmit_aggr\n", + __func__, bf); + ath_tx_xmit_aggr(sc, an, bf); } else { DPRINTF(sc, ATH_DEBUG_SW_TX, - "%s: ampdu; swq'ing\n", - __func__); + "%s: bf=%p: ampdu; swq'ing\n", + __func__, bf); ATH_TXQ_INSERT_TAIL(atid, bf, bf_list); ath_tx_tid_sched(sc, atid); } } else if (txq->axq_depth < sc->sc_hwq_limit) { /* AMPDU not running, attempt direct dispatch */ - DPRINTF(sc, ATH_DEBUG_SW_TX, "%s: xmit_normal\n", __func__); + DPRINTF(sc, ATH_DEBUG_SW_TX, "%s: bf=%p: xmit_normal\n", __func__, bf); ath_tx_xmit_normal(sc, txq, bf); } else { /* Busy; queue */ - DPRINTF(sc, ATH_DEBUG_SW_TX, "%s: swq'ing\n", __func__); + DPRINTF(sc, ATH_DEBUG_SW_TX, "%s: bf=%p: swq'ing\n", __func__, bf); ATH_TXQ_INSERT_TAIL(atid, bf, bf_list); ath_tx_tid_sched(sc, atid); } @@ -2478,11 +2636,11 @@ ath_tx_tid_drain(struct ath_softc *sc, s if (t == 0) { device_printf(sc->sc_dev, - "%s: node %p: tid %d: txq_depth=%d, " + "%s: node %p: bf=%p: tid %d: txq_depth=%d, " "txq_aggr_depth=%d, sched=%d, paused=%d, " "hwq_depth=%d, incomp=%d, baw_head=%d, " "baw_tail=%d txa_start=%d, ni_txseqs=%d\n", - __func__, ni, tid->tid, txq->axq_depth, + __func__, ni, bf, tid->tid, txq->axq_depth, txq->axq_aggr_depth, tid->sched, tid->paused, tid->hwq_depth, tid->incomp, tid->baw_head, tid->baw_tail, tap == NULL ? -1 : tap->txa_start, @@ -2493,7 +2651,7 @@ ath_tx_tid_drain(struct ath_softc *sc, s mtod(bf->bf_m, const uint8_t *), bf->bf_m->m_len, 0, -1); - t = 1; + //t = 1; } Modified: head/sys/dev/ath/if_ath_tx.h ============================================================================== --- head/sys/dev/ath/if_ath_tx.h Mon Mar 19 23:28:13 2012 (r233226) +++ head/sys/dev/ath/if_ath_tx.h Tue Mar 20 04:50:25 2012 (r233227) @@ -109,6 +109,8 @@ extern void ath_tx_addto_baw(struct ath_ struct ath_tid *tid, struct ath_buf *bf); extern struct ieee80211_tx_ampdu * ath_tx_get_tx_tid(struct ath_node *an, int tid); +extern int ath_tx_tid_seqno_assign(struct ath_softc *sc, + struct ieee80211_node *ni, struct ath_buf *bf, struct mbuf *m0); /* TX addba handling */ extern int ath_addba_request(struct ieee80211_node *ni, Modified: head/sys/dev/ath/if_ath_tx_ht.c ============================================================================== --- head/sys/dev/ath/if_ath_tx_ht.c Mon Mar 19 23:28:13 2012 (r233226) +++ head/sys/dev/ath/if_ath_tx_ht.c Tue Mar 20 04:50:25 2012 (r233227) @@ -644,7 +644,7 @@ ATH_AGGR_STATUS ath_tx_form_aggr(struct ath_softc *sc, struct ath_node *an, struct ath_tid *tid, ath_bufhead *bf_q) { - //struct ieee80211_node *ni = &an->an_node; + struct ieee80211_node *ni = &an->an_node; struct ath_buf *bf, *bf_first = NULL, *bf_prev = NULL; int nframes = 0; uint16_t aggr_limit = 0, al = 0, bpad = 0, al_delta, h_baw; @@ -652,6 +652,7 @@ ath_tx_form_aggr(struct ath_softc *sc, s int status = ATH_AGGR_DONE; int prev_frames = 0; /* XXX for AR5416 burst, not done here */ int prev_al = 0; /* XXX also for AR5416 burst */ + int seqno; ATH_TXQ_LOCK_ASSERT(sc->sc_ac2q[tid->ac]); @@ -707,16 +708,6 @@ ath_tx_form_aggr(struct ath_softc *sc, s */ /* - * If the packet has a sequence number, do not - * step outside of the block-ack window. - */ - if (! BAW_WITHIN(tap->txa_start, tap->txa_wnd, - SEQNO(bf->bf_state.bfs_seqno))) { - status = ATH_AGGR_BAW_CLOSED; - break; - } - - /* * XXX TODO: AR5416 has an 8K aggregation size limit * when RTS is enabled, and RTS is required for dual-stream * rates. @@ -744,6 +735,58 @@ ath_tx_form_aggr(struct ath_softc *sc, s } /* + * TODO: If it's _before_ the BAW left edge, complain very loudly. + * This means something (else) has slid the left edge along + * before we got a chance to be TXed. + */ + + /* + * Check if we have space in the BAW for this frame before + * we add it. + * + * see ath_tx_xmit_aggr() for more info. + */ + if (bf->bf_state.bfs_dobaw) { + if (! BAW_WITHIN(tap->txa_start, tap->txa_wnd, + ni->ni_txseqs[bf->bf_state.bfs_tid])) { + status = ATH_AGGR_BAW_CLOSED; + break; + } + /* XXX check for bfs_need_seqno? */ + if (! bf->bf_state.bfs_seqno_assigned) { + seqno = ath_tx_tid_seqno_assign(sc, ni, bf, bf->bf_m); + if (seqno < 0) { + device_printf(sc->sc_dev, + "%s: bf=%p, huh, seqno=-1?\n", + __func__, + bf); + /* XXX what can we even do here? */ + } + /* Flush seqno update to RAM */ + /* + * XXX This is required because the dmasetup + * XXX is done early rather than at dispatch + * XXX time. Ew, we should fix this! + */ + bus_dmamap_sync(sc->sc_dmat, bf->bf_dmamap, + BUS_DMASYNC_PREWRITE); + } + } + + /* + * If the packet has a sequence number, do not + * step outside of the block-ack window. + */ + if (! BAW_WITHIN(tap->txa_start, tap->txa_wnd, + SEQNO(bf->bf_state.bfs_seqno))) { + device_printf(sc->sc_dev, + "%s: bf=%p, seqno=%d, outside?!\n", + __func__, bf, SEQNO(bf->bf_state.bfs_seqno)); + status = ATH_AGGR_BAW_CLOSED; + break; + } + + /* * this packet is part of an aggregate. */ ATH_TXQ_REMOVE(tid, bf, bf_list); Modified: head/sys/dev/ath/if_athvar.h ============================================================================== --- head/sys/dev/ath/if_athvar.h Mon Mar 19 23:28:13 2012 (r233226) +++ head/sys/dev/ath/if_athvar.h Tue Mar 20 04:50:25 2012 (r233227) @@ -215,6 +215,8 @@ struct ath_buf { int bfs_ismrr:1; /* do multi-rate TX retry */ int bfs_doprot:1; /* do RTS/CTS based protection */ int bfs_doratelookup:1; /* do rate lookup before each TX */ + int bfs_need_seqno:1; /* need to assign a seqno for aggregation */ + int bfs_seqno_assigned:1; /* seqno has been assigned */ int bfs_nfl; /* next fragment length */ /* _______________________________________________ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscribe@freebsd.org" From owner-freebsd-wireless@FreeBSD.ORG Wed Mar 21 00:13:17 2012 Return-Path: Delivered-To: freebsd-wireless@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 30A121065779; Wed, 21 Mar 2012 00:13:15 +0000 (UTC) (envelope-from adrian@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id CE10A8FC0A; Wed, 21 Mar 2012 00:13:14 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q2L0DEEJ043039; Wed, 21 Mar 2012 00:13:14 GMT (envelope-from adrian@freefall.freebsd.org) Received: (from adrian@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q2L0DEx6043035; Wed, 21 Mar 2012 00:13:14 GMT (envelope-from adrian) Date: Wed, 21 Mar 2012 00:13:14 GMT Message-Id: <201203210013.q2L0DEx6043035@freefall.freebsd.org> To: adrian@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-wireless@FreeBSD.org From: adrian@FreeBSD.org Cc: Subject: Re: kern/166286: [net80211] [ath] initial switch to HT40 isn't causing a hardware channel change call X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.5 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, 21 Mar 2012 00:13:17 -0000 Synopsis: [net80211] [ath] initial switch to HT40 isn't causing a hardware channel change call Responsible-Changed-From-To: freebsd-bugs->freebsd-wireless Responsible-Changed-By: adrian Responsible-Changed-When: Wed Mar 21 00:13:04 UTC 2012 Responsible-Changed-Why: assign to maintainer. http://www.freebsd.org/cgi/query-pr.cgi?pr=166286 From owner-freebsd-wireless@FreeBSD.ORG Wed Mar 21 03:24:38 2012 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 99227106566B; Wed, 21 Mar 2012 03:24:38 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 62A2A8FC14; Wed, 21 Mar 2012 03:24:38 +0000 (UTC) Received: by pbcwz17 with SMTP id wz17so575993pbc.13 for ; Tue, 20 Mar 2012 20:24:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; bh=I93In2w5a2l63IEqJ0iSf0Kl9K53GYe9k7yXLrS+tx8=; b=P+qCSf5+L51Sj4yQ5H6sWn4Cw3QQcjHWfYkBGBt6FWFbbu5FYs8WziRV9PoFaTnyEe 47U7Do+l/vwYVJHdvSw6UQR4i03jTRB5z/drO6NyOSGEo+L2ghlUQq+dRBxBaDlpiDzM YnyUx6A0P6YqCOAeCJaReJ9JPH6H08DLeqcLar2tp71Qmn+5rGk0jKvlfOLw2scntrfQ ZpF9f9v9EvJYAI2NYmMvYLua+P8BtkhFe7iG2cZad+FQn3NT8jFAA32CUHMmaZjOSWdG t7cZjKivxwYLxD6M/PClOsa99MF2vy8mre3VctDdikcERIM7+Rui8NH9hYy+l37Cg+U6 dPMw== MIME-Version: 1.0 Received: by 10.68.191.168 with SMTP id gz8mr6921850pbc.37.1332300277991; Tue, 20 Mar 2012 20:24:37 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.143.33.5 with HTTP; Tue, 20 Mar 2012 20:24:37 -0700 (PDT) Date: Tue, 20 Mar 2012 20:24:37 -0700 X-Google-Sender-Auth: DkK-M7t_4eo6Fx-qLIzaH1mb33Q Message-ID: From: Adrian Chadd To: freebsd-wireless@freebsd.org, Bernhard Schmidt Content-Type: multipart/mixed; boundary=e89a8ff1c8d4cdc8e604bbb85425 Cc: Subject: [net80211] PR kern/166286: force a channel change upon a HT info change X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.5 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, 21 Mar 2012 03:24:38 -0000 --e89a8ff1c8d4cdc8e604bbb85425 Content-Type: text/plain; charset=ISO-8859-1 Hi, This patch forces a channel change - sta_recv_mgmt() doesn't set the channel width early enough to catch it after the ASSOC -> RUN state change. So there's a transition to HT20 upon association, but it doesn't transition to HT40 via ic_chan_set(). Thus the hardware is in HT20 mode, but HT40 frames are sent to the hardware .They obviously fail. This shows up when associating to an open HT40 AP. Since bgscan is disabled, there's no subsequent scan to force an ath_chan_set() with the updated flags. I'm not sure why (yet) it hasn't shown up in other scenarios. Bernhard - would you mind commenting on this? You were the last of us knee-deep in ieee80211_ht.c and the net80211 management path. Thanks! Adrian --e89a8ff1c8d4cdc8e604bbb85425 Content-Type: text/x-patch; charset=US-ASCII; name="net80211-force-curchan-on-ht-change-pr-166286.diff" Content-Disposition: attachment; filename="net80211-force-curchan-on-ht-change-pr-166286.diff" Content-Transfer-Encoding: base64 X-Attachment-Id: f_h01t8f5f0 SW5kZXg6IHN5cy9uZXQ4MDIxMS9pZWVlODAyMTFfaHQuYwo9PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBzeXMvbmV0 ODAyMTEvaWVlZTgwMjExX2h0LmMJKHJldmlzaW9uIDIzMzI1NCkKKysrIHN5cy9uZXQ4MDIxMS9p ZWVlODAyMTFfaHQuYwkod29ya2luZyBjb3B5KQpAQCAtMTQyOCwxMiArMTQyOCwxMyBAQAogICog cmVxdWlyZWQgY2hhbm5lbCBjaGFuZ2UgaXMgZG9uZSAoZS5nLiBpbiBzdGEgbW9kZSB3aGVuCiAg KiBwYXJzaW5nIHRoZSBjb250ZW50cyBvZiBhIGJlYWNvbiBmcmFtZSkuCiAgKi8KLXN0YXRpYyB2 b2lkCitzdGF0aWMgaW50CiBodGluZm9fdXBkYXRlX2NodyhzdHJ1Y3QgaWVlZTgwMjExX25vZGUg Km5pLCBpbnQgaHRmbGFncykKIHsKIAlzdHJ1Y3QgaWVlZTgwMjExY29tICppYyA9IG5pLT5uaV9p YzsKIAlzdHJ1Y3QgaWVlZTgwMjExX2NoYW5uZWwgKmM7CiAJaW50IGNoYW5mbGFnczsKKwlpbnQg cmV0ID0gMDsKIAogCWNoYW5mbGFncyA9IChuaS0+bmlfY2hhbi0+aWNfZmxhZ3MgJn4gSUVFRTgw MjExX0NIQU5fSFQpIHwgaHRmbGFnczsKIAlpZiAoY2hhbmZsYWdzICE9IG5pLT5uaV9jaGFuLT5p Y19mbGFncykgewpAQCAtMTQ2MCwxMSArMTQ2MSwxMyBAQAogCQkJICAgIElFRUU4MDIxMV9JU19D SEFOX0hUNDAoYykgPyA0MCA6IDIwLAogCQkJICAgIGMtPmljX2ZyZXEsIGMtPmljX2ZsYWdzKTsK IAkJCW5pLT5uaV9jaGFuID0gYzsKKwkJCXJldCA9IDE7CiAJCX0KIAkJLyogTkI6IGNhbGxlciBy ZXNwb25zaWJsZSBmb3IgZm9yY2luZyBhbnkgY2hhbm5lbCBjaGFuZ2UgKi8KIAl9CiAJLyogdXBk YXRlIG5vZGUncyB0eCBjaGFubmVsIHdpZHRoICovCiAJbmktPm5pX2NodyA9IElFRUU4MDIxMV9J U19DSEFOX0hUNDAobmktPm5pX2NoYW4pPyA0MCA6IDIwOworCXJldHVybiAocmV0KTsKIH0KIAog LyoKQEAgLTE1MTUsMTMgKzE1MTgsMTQgQEAKICAqIFBhcnNlIGFuZCB1cGRhdGUgSFQtcmVsYXRl ZCBzdGF0ZSBleHRyYWN0ZWQgZnJvbQogICogdGhlIEhUIGNhcCBhbmQgaW5mbyBpZSdzLgogICov Ci12b2lkCitpbnQKIGllZWU4MDIxMV9odF91cGRhdGVwYXJhbXMoc3RydWN0IGllZWU4MDIxMV9u b2RlICpuaSwKIAljb25zdCB1aW50OF90ICpodGNhcGllLCBjb25zdCB1aW50OF90ICpodGluZm9p ZSkKIHsKIAlzdHJ1Y3QgaWVlZTgwMjExdmFwICp2YXAgPSBuaS0+bmlfdmFwOwogCWNvbnN0IHN0 cnVjdCBpZWVlODAyMTFfaWVfaHRpbmZvICpodGluZm87CiAJaW50IGh0ZmxhZ3M7CisJaW50IHJl dCA9IDA7CiAKIAlpZWVlODAyMTFfcGFyc2VfaHRjYXAobmksIGh0Y2FwaWUpOwogCWlmICh2YXAt Pml2X2h0Y2FwcyAmIElFRUU4MDIxMV9IVENBUF9TTVBTKQpAQCAtMTU0MywxMyArMTU0NywxNiBA QAogCQllbHNlIGlmIChuaS0+bmlfaHQybmRjaGFuID09IElFRUU4MDIxMV9IVElORk9fMk5EQ0hB Tl9CRUxPVykKIAkJCWh0ZmxhZ3MgPSBJRUVFODAyMTFfQ0hBTl9IVDQwRDsKIAl9Ci0JaHRpbmZv X3VwZGF0ZV9jaHcobmksIGh0ZmxhZ3MpOworCWlmIChodGluZm9fdXBkYXRlX2NodyhuaSwgaHRm bGFncykpCisJCXJldCA9IDE7CiAKIAlpZiAoKGh0aW5mby0+aGlfYnl0ZTEgJiBJRUVFODAyMTFf SFRJTkZPX1JJRlNNT0RFX1BFUk0pICYmCiAJICAgICh2YXAtPml2X2ZsYWdzX2h0ICYgSUVFRTgw MjExX0ZIVF9SSUZTKSkKIAkJbmktPm5pX2ZsYWdzIHw9IElFRUU4MDIxMV9OT0RFX1JJRlM7CiAJ ZWxzZQogCQluaS0+bmlfZmxhZ3MgJj0gfklFRUU4MDIxMV9OT0RFX1JJRlM7CisKKwlyZXR1cm4g KHJldCk7CiB9CiAKIC8qCkBAIC0xNTc4LDcgKzE1ODUsNyBAQAogCQllbHNlIGlmIChJRUVFODAy MTFfSVNfQ0hBTl9IVDQwRCh2YXAtPml2X2Jzcy0+bmlfY2hhbikpCiAJCQlodGZsYWdzID0gSUVF RTgwMjExX0NIQU5fSFQ0MEQ7CiAJfQotCWh0aW5mb191cGRhdGVfY2h3KG5pLCBodGZsYWdzKTsK Kwkodm9pZCkgaHRpbmZvX3VwZGF0ZV9jaHcobmksIGh0ZmxhZ3MpOwogfQogCiAvKgpJbmRleDog c3lzL25ldDgwMjExL2llZWU4MDIxMV9odC5oCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIHN5cy9uZXQ4MDIxMS9p ZWVlODAyMTFfaHQuaAkocmV2aXNpb24gMjMzMjU0KQorKysgc3lzL25ldDgwMjExL2llZWU4MDIx MV9odC5oCSh3b3JraW5nIGNvcHkpCkBAIC0xODQsNyArMTg0LDcgQEAKIHZvaWQJaWVlZTgwMjEx X2h0X3RpbWVvdXQoc3RydWN0IGllZWU4MDIxMWNvbSAqKTsKIHZvaWQJaWVlZTgwMjExX3BhcnNl X2h0Y2FwKHN0cnVjdCBpZWVlODAyMTFfbm9kZSAqLCBjb25zdCB1aW50OF90ICopOwogdm9pZAlp ZWVlODAyMTFfcGFyc2VfaHRpbmZvKHN0cnVjdCBpZWVlODAyMTFfbm9kZSAqLCBjb25zdCB1aW50 OF90ICopOwotdm9pZAlpZWVlODAyMTFfaHRfdXBkYXRlcGFyYW1zKHN0cnVjdCBpZWVlODAyMTFf bm9kZSAqLCBjb25zdCB1aW50OF90ICosCitpbnQJaWVlZTgwMjExX2h0X3VwZGF0ZXBhcmFtcyhz dHJ1Y3QgaWVlZTgwMjExX25vZGUgKiwgY29uc3QgdWludDhfdCAqLAogCQljb25zdCB1aW50OF90 ICopOwogdm9pZAlpZWVlODAyMTFfaHRfdXBkYXRlaHRjYXAoc3RydWN0IGllZWU4MDIxMV9ub2Rl ICosIGNvbnN0IHVpbnQ4X3QgKik7CiBpbnQJaWVlZTgwMjExX2FtcGR1X3JlcXVlc3Qoc3RydWN0 IGllZWU4MDIxMV9ub2RlICosCkluZGV4OiBzeXMvbmV0ODAyMTEvaWVlZTgwMjExX3N0YS5jCj09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT0KLS0tIHN5cy9uZXQ4MDIxMS9pZWVlODAyMTFfc3RhLmMJKHJldmlzaW9uIDIzMzI1 NCkKKysrIHN5cy9uZXQ4MDIxMS9pZWVlODAyMTFfc3RhLmMJKHdvcmtpbmcgY29weSkKQEAgLTEy ODUsNiArMTI4NSw3IEBACiAJdWludDhfdCAqZnJtLCAqZWZybTsKIAl1aW50OF90ICpyYXRlcywg KnhyYXRlcywgKndtZSwgKmh0Y2FwLCAqaHRpbmZvOwogCXVpbnQ4X3QgcmF0ZTsKKwlpbnQgY2hh bl9jaGFuZ2UgPSAwOwogCiAJd2ggPSBtdG9kKG0wLCBzdHJ1Y3QgaWVlZTgwMjExX2ZyYW1lICop OwogCWZybSA9ICh1aW50OF90ICopJndoWzFdOwpAQCAtMTM3Miw4ICsxMzczLDkgQEAKICNlbmRp ZgogCQkJaWYgKHNjYW4uaHRjYXAgIT0gTlVMTCAmJiBzY2FuLmh0aW5mbyAhPSBOVUxMICYmCiAJ CQkgICAgKHZhcC0+aXZfZmxhZ3NfaHQgJiBJRUVFODAyMTFfRkhUX0hUKSkgewotCQkJCWllZWU4 MDIxMV9odF91cGRhdGVwYXJhbXMobmksCi0JCQkJICAgIHNjYW4uaHRjYXAsIHNjYW4uaHRpbmZv KTsKKwkJCQlpZiAoaWVlZTgwMjExX2h0X3VwZGF0ZXBhcmFtcyhuaSwKKwkJCQkgICAgc2Nhbi5o dGNhcCwgc2Nhbi5odGluZm8pKQorCQkJCQljaGFuX2NoYW5nZSA9IDE7CiAJCQkJLyogWFhYIHN0 YXRlIGNoYW5nZXM/ICovCiAJCQl9CiAJCQlpZiAoc2Nhbi5xdWlldCkKQEAgLTE0NDEsNiArMTQ0 MywxMyBAQAogI2VuZGlmCiAJCQkJaWVlZTgwMjExX2JnX3NjYW4odmFwLCAwKTsKIAkJCX0KKwor CQkJLyoKKwkJCSAqIElmIHdlJ3ZlIGhhZCBhIHN0YXRlIGNoYW5nZSAoZWcgSFQyMDwtPkhUNDAp CisJCQkgKiB0aGVuIHJlc2V0IHRoZSBvcGVyYXRpbmcgY2hhbm5lbC4KKwkJCSAqLworCQkJaWYg KGNoYW5fY2hhbmdlKQorCQkJCWllZWU4MDIxMV9zZXRjdXJjaGFuKGljLCBpYy0+aWNfY3VyY2hh bik7CiAJCQlyZXR1cm47CiAJCX0KIAkJLyoK --e89a8ff1c8d4cdc8e604bbb85425-- From owner-freebsd-wireless@FreeBSD.ORG Wed Mar 21 05:02:31 2012 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AAFEF1065670; Wed, 21 Mar 2012 05:02:31 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by mx1.freebsd.org (Postfix) with ESMTP id 7404D8FC0C; Wed, 21 Mar 2012 05:02:31 +0000 (UTC) Received: by dald2 with SMTP id d2so1185426dal.13 for ; Tue, 20 Mar 2012 22:02:31 -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=WDU6Ay5Zd41e4T9QmH9QZghtautfV7Il7RXaJFhSxZ4=; b=kL5jqsDSd5eBjigXtsGjo0YLCGWEPD+kzpZtTf7YOqXN+WvwOO3bq8FVflKWXIZVaE qF8rs+fZaPttklIIr/xoMsYywEYVeXRoGiV3UMimbIszlOwBSjncG37V2bFYBOAIFqGx dyK5Ha15hTVq8W45aYkN/dQdKGOBKWIhS10muXgmRKZPRRNkX1pO5QiXsAD6qQoxap3H PjiXJH6aaoScZC56H0rAyXoYdYth/+XbhOiDEKz5pdMbuVy5if0Auh0Z1I+daiyyReJK 7rbdywYZ+J6SO8O+XWCIgWOButsR9tK6/6AplDwXYNFzBk51TZHPTB1XSL5LLbqo+L57 a/vA== MIME-Version: 1.0 Received: by 10.68.130.6 with SMTP id oa6mr7422878pbb.96.1332306151259; Tue, 20 Mar 2012 22:02:31 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.143.33.5 with HTTP; Tue, 20 Mar 2012 22:02:31 -0700 (PDT) In-Reply-To: <201203201006.22954.erichfreebsdlist@ovitrap.com> References: <201112171258.56891.erichfreebsdlist@ovitrap.com> <201112180759.03722.erichfreebsdlist@ovitrap.com> <201203201006.22954.erichfreebsdlist@ovitrap.com> Date: Tue, 20 Mar 2012 22:02:31 -0700 X-Google-Sender-Auth: 8EuBhnHsdxZ32trvvl1NZWHoGOU Message-ID: From: Adrian Chadd To: Erich Dollansky Content-Type: text/plain; charset=ISO-8859-1 Cc: PseudoCylon , freebsd-wireless@freebsd.org, Bernhard Schmidt Subject: Re: Regression 8.2 --> 8.3 PRERELEASE Re: Zyxel NWD210N not accepted at boot time but after plugging it in again X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.5 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, 21 Mar 2012 05:02:31 -0000 Hi, Do you have a specific svn checkin revision that introduced this regression? Adrian From owner-freebsd-wireless@FreeBSD.ORG Wed Mar 21 05:04:24 2012 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 04228106564A for ; Wed, 21 Mar 2012 05:04:24 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by mx1.freebsd.org (Postfix) with ESMTP id BABFE8FC0C for ; Wed, 21 Mar 2012 05:04:23 +0000 (UTC) Received: by dald2 with SMTP id d2so1187725dal.13 for ; Tue, 20 Mar 2012 22:04:23 -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=YSMvA3Up2WJRDplUhmMQUuKcT8BWR4krZZ9T6FY60H0=; b=SnOsLGEdRUDgGLRB3dgC5YvD9d/Pu+3tlFY7BAaBW1KJhrBgkXz1vlxhmH/F6fDWIE /9D4t8Y8eDpSurV3pikZJXHMq64x5qh4SmsG0dwVPSt/JftnQ63S6Cecz4IvQpDA5b05 fx2Jdc0Lihegvs0AQ3JNQKuFFmmrQC9rdhEUXy1/TyVaHiysj+lssE/H/eg4HT/Wh2yv 4hvMXz7RRtG2MGXAHmiiFFTD1y5A1Dd1ghW19CldD3Uo6i5sRDDcyULphgMRvw324Vat QAr4gcSPDgVYE3XJ4wfWzu0esYmcN9Eqfc4sN14AVCyi/7xw9bbsPDR9K6o47r5xpUja dq3g== MIME-Version: 1.0 Received: by 10.68.232.2 with SMTP id tk2mr7599924pbc.68.1332306263505; Tue, 20 Mar 2012 22:04:23 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.143.33.5 with HTTP; Tue, 20 Mar 2012 22:04:23 -0700 (PDT) In-Reply-To: <4F651853.2050409@gmail.com> References: <4F4828C0.6020705@gmail.com> <4F5A8023.1090705@gmail.com> <4F5AC7CF.3090409@gmail.com> <4F5C0C86.7040503@gmail.com> <4F5C24ED.3090601@gmail.com> <4F5CD920.2000905@gmail.com> <4F5D0876.5040409@gmail.com> <4F5D14E0.3050301@gmail.com> <20120312001625.4d9b3b52.ray@ddteam.net> <4F5E7D17.7000102@gmail.com> <4F5E9814.7010803@gmail.com> <4F5E9BA3.2000401@gmail.com> <20120313131415.36ecd761.ray@dlink.ua> <4F5FE891.7050306@gmail.com> <20120314200718.b6b51452.ray@ddteam.net> <4F651853.2050409@gmail.com> Date: Tue, 20 Mar 2012 22:04:23 -0700 X-Google-Sender-Auth: PaOyQt7vOUt8PuyLNt44cliY6Vo Message-ID: From: Adrian Chadd To: matt Content-Type: text/plain; charset=ISO-8859-1 Cc: Aleksandr Rybalko , freebsd-wireless@freebsd.org Subject: Re: Please Test: Updated Ral Driver Patch for rt2860/rt3090 X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.5 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, 21 Mar 2012 05:04:24 -0000 Hi, How's the ralink driver tinkering going? How far out are we from committing something partially working to -HEAD? What are the showstoppers? Adrian From owner-freebsd-wireless@FreeBSD.ORG Wed Mar 21 05:53:45 2012 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DCA141065670; Wed, 21 Mar 2012 05:53:45 +0000 (UTC) (envelope-from erichfreebsdlist@ovitrap.com) Received: from alogreentechnologies.com (alogreentechnologies.com [67.212.226.44]) by mx1.freebsd.org (Postfix) with ESMTP id 82C088FC16; Wed, 21 Mar 2012 05:53:45 +0000 (UTC) Received: from amd620.ovitrap.com ([49.128.188.2]) (authenticated bits=0) by alogreentechnologies.com (8.13.1/8.13.1) with ESMTP id q2L5rZCV013242; Tue, 20 Mar 2012 23:53:37 -0600 From: Erich Dollansky To: Adrian Chadd Date: Wed, 21 Mar 2012 12:53:54 +0700 User-Agent: KMail/1.13.7 (FreeBSD/8.3-PRERELEASE; KDE/4.7.4; amd64; ; ) References: <201112171258.56891.erichfreebsdlist@ovitrap.com> <201203201006.22954.erichfreebsdlist@ovitrap.com> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201203211253.54409.erichfreebsdlist@ovitrap.com> Cc: PseudoCylon , freebsd-wireless@freebsd.org, Bernhard Schmidt Subject: Re: Regression 8.2 --> 8.3 PRERELEASE Re: Zyxel NWD210N not accepted at boot time but after plugging it in again X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.5 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, 21 Mar 2012 05:53:45 -0000 Hi, On Wednesday 21 March 2012 12:02:31 Adrian Chadd wrote: > > Do you have a specific svn checkin revision that introduced this regression? > no. I did not use this adaptor until I have had to visit the client last week. The machine behaved just like before I installed the patches which have been sent to me via e-mail. I am under the impression that the patch never made it into the source tree. Just as a reminder. The adaptor works after pulling it out an putting it back after the machine is up and running. The problem is that the micro code cannot be uploaded during the boot process as root is not mounted yet. Erich From owner-freebsd-wireless@FreeBSD.ORG Wed Mar 21 07:52:48 2012 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8D9A2106566C for ; Wed, 21 Mar 2012 07:52:48 +0000 (UTC) (envelope-from bschmidt@techwires.net) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) by mx1.freebsd.org (Postfix) with ESMTP id F38E98FC16 for ; Wed, 21 Mar 2012 07:52:47 +0000 (UTC) Received: by lboi15 with SMTP id i15so873935lbo.13 for ; Wed, 21 Mar 2012 00:52:46 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:x-originating-ip:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding:x-gm-message-state; bh=zfKKjWEy3U2N0iuJEvV1FUHCiVdCHY7M3wlG0wVfsl0=; b=V3c4CFvUrNJhoPfwfi5RG5gaTPzSWuL33GINn6KVPpXC2qYeD8diBPqzj5ymCsciuG ieYxZdXp3zXjHx7VjDYnvqsuqxvN3VLrsHQARuA8XtXzzkiXzis/iKsvks8h7eorjAi9 j8UNj/ut8rDt0Fw4NYRjX5dXo3QhWN3k7zo+8N4ovBs7mIdEH6+ynC3lDvApp3mMHC2i yu/JWk/WMFOhwFDB1Out/mw1HTQauDEsObiV4ywtePDSg40xS9qTWEvaw7Dd/OSFdzDL 7bIunuXA9xxenYWYuNpA75qTkxoDi/D6gVhx6hsOlAQ7moB+ixqFqxPWAqa8zGSsE1yN AwIw== MIME-Version: 1.0 Received: by 10.152.112.68 with SMTP id io4mr2090923lab.40.1332316366695; Wed, 21 Mar 2012 00:52:46 -0700 (PDT) Sender: bschmidt@techwires.net Received: by 10.152.112.234 with HTTP; Wed, 21 Mar 2012 00:52:46 -0700 (PDT) X-Originating-IP: [79.140.39.245] In-Reply-To: <201203211253.54409.erichfreebsdlist@ovitrap.com> References: <201112171258.56891.erichfreebsdlist@ovitrap.com> <201203201006.22954.erichfreebsdlist@ovitrap.com> <201203211253.54409.erichfreebsdlist@ovitrap.com> Date: Wed, 21 Mar 2012 08:52:46 +0100 X-Google-Sender-Auth: QC1D6jMcD2CPqWgdozc0VLNAqI8 Message-ID: From: Bernhard Schmidt To: Erich Dollansky Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQnZSZmRPIY5qHcEKu3ieQiQBBuzcmd1gg3QQC1/0RS7XzFOv6pYQlZsW3/Z0Z4IFLPYpj6W Cc: PseudoCylon , freebsd-wireless@freebsd.org Subject: Re: Regression 8.2 --> 8.3 PRERELEASE Re: Zyxel NWD210N not accepted at boot time but after plugging it in again X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.5 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, 21 Mar 2012 07:52:48 -0000 On Wed, Mar 21, 2012 at 06:53, Erich Dollansky wrote: > Hi, > > On Wednesday 21 March 2012 12:02:31 Adrian Chadd wrote: >> >> Do you have a specific svn checkin revision that introduced this regress= ion? >> > no. I did not use this adaptor until I have had to visit the client last = week. The machine behaved just like before I installed the patches which ha= ve been sent to me via e-mail. I am under the impression that the patch nev= er made it into the source tree. > > Just as a reminder. The adaptor works after pulling it out an putting it = back after the machine is up and running. The problem is that the micro cod= e cannot be uploaded during the boot process as root is not mounted yet. Uarg.. seems like the diff didn't make it into tree at all, sorry about tha= t. I'll take care of it asap. --=20 Bernhard From owner-freebsd-wireless@FreeBSD.ORG Wed Mar 21 07:54:27 2012 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B81BE1065674 for ; Wed, 21 Mar 2012 07:54:27 +0000 (UTC) (envelope-from bschmidt@techwires.net) Received: from mail-lpp01m010-f54.google.com (mail-lpp01m010-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 1D7598FC15 for ; Wed, 21 Mar 2012 07:54:26 +0000 (UTC) Received: by lagv3 with SMTP id v3so869662lag.13 for ; Wed, 21 Mar 2012 00:54:25 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=dbli+mGSwONr3gFn+59VMkXw3/xx4DIXAUnK/vsY2n4=; b=ZaGys7WRIayRLTngttoPcKr+FRm8PLAyKAloA1TfIeyX7zJslsm9FKgfdTAwL5UBB9 05l4pr7hmr+wUsGKAbFA0RYqFumLVr/gckGubCgud7AU/AueLx62ANNVzWLMhiIiPIg/ m8LpZqjQqT61+wF4aWIKcF7mpKkMZ2Ab5y1fme0pUbdm7yN7gcij/Px3H6SvyNVR47eX cHTc084uONKJ2BILJQ8yZUGXqV7XaHiKEtj8W9CwfH+mapfXNtpa8CBvyilH8Y02IxaY JeeXZO+zIQWTeD37fDjZo0IARY1HeNDWMb9SE0R3ysECqdHK+MWevq5YRwx/+NcwOeAW 6PAw== MIME-Version: 1.0 Received: by 10.112.88.2 with SMTP id bc2mr1058503lbb.85.1332316465837; Wed, 21 Mar 2012 00:54:25 -0700 (PDT) Received: by 10.152.112.234 with HTTP; Wed, 21 Mar 2012 00:54:25 -0700 (PDT) X-Originating-IP: [79.140.39.245] In-Reply-To: References: <4F4828C0.6020705@gmail.com> <4F5A8023.1090705@gmail.com> <4F5AC7CF.3090409@gmail.com> <4F5C0C86.7040503@gmail.com> <4F5C24ED.3090601@gmail.com> <4F5CD920.2000905@gmail.com> <4F5D0876.5040409@gmail.com> <4F5D14E0.3050301@gmail.com> <20120312001625.4d9b3b52.ray@ddteam.net> <4F5E7D17.7000102@gmail.com> <4F5E9814.7010803@gmail.com> <4F5E9BA3.2000401@gmail.com> <20120313131415.36ecd761.ray@dlink.ua> <4F5FE891.7050306@gmail.com> <20120314200718.b6b51452.ray@ddteam.net> <4F651853.2050409@gmail.com> Date: Wed, 21 Mar 2012 08:54:25 +0100 Message-ID: From: Bernhard Schmidt To: Adrian Chadd Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQmyGE5cU51qE8tV4q1Z7Q4I0lLW+8qh+GC7LB36H1dtDlJcRQiBP3VIHGBr/4Txm8dxkIi9 Cc: Aleksandr Rybalko , freebsd-wireless@freebsd.org Subject: Re: Please Test: Updated Ral Driver Patch for rt2860/rt3090 X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.5 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, 21 Mar 2012 07:54:27 -0000 On Wed, Mar 21, 2012 at 06:04, Adrian Chadd wrote: > Hi, > > How's the ralink driver tinkering going? > > How far out are we from committing something partially working to > -HEAD? What are the showstoppers? Lots of stuff, please let me go over at least the reg.h and var.h first. I'm only half way through the reg file yet. -- Bernhard From owner-freebsd-wireless@FreeBSD.ORG Wed Mar 21 17:28:23 2012 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D5D20106564A; Wed, 21 Mar 2012 17:28:23 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by mx1.freebsd.org (Postfix) with ESMTP id A21AB8FC0A; Wed, 21 Mar 2012 17:28:23 +0000 (UTC) Received: by dald2 with SMTP id d2so2153868dal.13 for ; Wed, 21 Mar 2012 10:28:23 -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=6Ozn8GmMl+Igu72JHodGqNGi6dbXoYO58Ol2xnYx5Dc=; b=0HsXL81YFsVNhFY/YokGcAVdtvrASi/mEIwQj9zBoS92tDyJ7Oue0jUQncp2iIC0VI NVFNW+06924lDZAFcv4QC88m5dNOQ5Y2/+URQU1kOTAKp/a2vD7Gk7x5bkd71np0wElw eiYryNoJYoruwCLmeVA61Ow67xCJ4zX6BbSGMxqmQjMCkc285ah5XtII5nb4qlB2JgrQ GW6s+dNq9kRESA9z6APmx9S9pUt8dFfQkF3hhzvWuwXfRbVUmV+n9einI1QvkTIcVZ2R 2uPvbmLK/F9nEaRJsyyzH6S2NGygiMNbcPQAiqpUGdeaeL4EOFebUgDoc22JcEArZgCy T8Pw== MIME-Version: 1.0 Received: by 10.68.234.195 with SMTP id ug3mr13580265pbc.4.1332350903248; Wed, 21 Mar 2012 10:28:23 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.143.33.5 with HTTP; Wed, 21 Mar 2012 10:28:23 -0700 (PDT) In-Reply-To: References: Date: Wed, 21 Mar 2012 10:28:23 -0700 X-Google-Sender-Auth: 0XQnMd0uZ2OS6yUHB_c-hKurLBs Message-ID: From: Adrian Chadd To: freebsd-wireless@freebsd.org, Bernhard Schmidt Content-Type: text/plain; charset=ISO-8859-1 Cc: Subject: Re: [net80211] PR kern/166286: force a channel change upon a HT info change X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.5 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, 21 Mar 2012 17:28:23 -0000 On 20 March 2012 20:24, Adrian Chadd wrote: > Hi, > > This patch forces a channel change - sta_recv_mgmt() doesn't set the > channel width early enough to catch it after the ASSOC -> RUN state > change. So there's a transition to HT20 upon association, but it > doesn't transition to HT40 via ic_chan_set(). Thus the hardware is in > HT20 mode, but HT40 frames are sent to the hardware .They obviously > fail. Bernhard and I had a chat on IRC. The main problem with this approach is that any other devices (eg iwn) don't do anything in their ic_chan_set() method. I also thought about it a bit more and can see how the gap between the htinfo update and notifying the driver could be quite annoying. That said, there _are_ plenty of races in net80211 at the moment as things go poking through the ic/vap state without holding locks. SMP and preemption makes this all quite scary. Adrian From owner-freebsd-wireless@FreeBSD.ORG Wed Mar 21 19:14:22 2012 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C29BB1065674 for ; Wed, 21 Mar 2012 19:14:22 +0000 (UTC) (envelope-from bschmidt@techwires.net) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 4418A8FC0A for ; Wed, 21 Mar 2012 19:14:21 +0000 (UTC) Received: by bkcjc3 with SMTP id jc3so1611807bkc.13 for ; Wed, 21 Mar 2012 12:14:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id :x-gm-message-state; bh=gRF+d0p9ugAwKKY+sue32DHQUqOQMgu1uY2mpIp+gO4=; b=U3N3l6vM8TD+/SHTJDQJi4tJ9/0laqDMH8CJ6kA21TfOLAC07+ZMNIAYiKFRWKk2/P l61l+zoQSS9FOGPGzaY6zF26DuSDQmsJnSRxXvTYxwGv9xHj7kLYIT0GHkCy4hfFowEK WSD5GGQToc1N7b22oKF9MmYfz9AQ6Qzttk2cAjwsMnRmZNmS1fJO/IZHQKvvR4m7pE6+ sFK4fGmJNfgHtvyBo6EwqLW488W5lR4tS9NuXSO2Pks8MA+CcY2gz1cb0mrQLlkUHIvp tIU57zDV4vlr0ytoTkOAaUnrN+PKE1dDdgK5J9PzTuipbHvEg/XRG64qZglj2SVGnAkc PXKw== Received: by 10.204.156.141 with SMTP id x13mr1914631bkw.50.1332357260977; Wed, 21 Mar 2012 12:14:20 -0700 (PDT) Received: from amy.lab.techwires.net (dslb-088-067-204-104.pools.arcor-ip.net. [88.67.204.104]) by mx.google.com with ESMTPS id r14sm5270798bkv.11.2012.03.21.12.14.18 (version=SSLv3 cipher=OTHER); Wed, 21 Mar 2012 12:14:20 -0700 (PDT) Sender: Bernhard Schmidt From: Bernhard Schmidt To: PseudoCylon Date: Wed, 21 Mar 2012 20:14:37 +0100 User-Agent: KMail/1.13.7 (FreeBSD/9.0-STABLE; KDE/4.7.4; amd64; ; ) References: <201112171258.56891.erichfreebsdlist@ovitrap.com> <201112180759.03722.erichfreebsdlist@ovitrap.com> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201203212014.37536.bschmidt@freebsd.org> X-Gm-Message-State: ALoCoQm7Ss1rl0q1sxixx86URkXtREdVc6yfArfSSNx3cX8aNI+WA473fyNU+uWP7BB7cylD5IiE Cc: freebsd-wireless@freebsd.org Subject: Re: Zyxel NWD210N not accepted at boot time but after plugging it in again X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.5 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, 21 Mar 2012 19:14:22 -0000 On Sunday 18 December 2011 06:32:46 PseudoCylon wrote: > On Sat, Dec 17, 2011 at 5:59 PM, Erich Dollansky > wrote: > > Hi, > > > > On Sunday 18 December 2011 06:45:18 PseudoCylon wrote: > >> On Sat, Dec 17, 2011 at 6:11 AM, Bernhard Schmidt wrote: > >> > On Saturday 17 December 2011 06:58:56 Erich Dollansky wrote: > >> > > >> > run(4) tries to load the firmware on attach at which point the root > >> > filesystem isn't yet mounted. Actually I think the prefered behaviour > >> > is to load it during init, not sure this is possible for run(4) > >> > though. Someone should check this. :) > >> > > >> mmm... It seems "someone" is me. > >> > >> At the quick look, the firmware could be loaded during the init. Give > >> me a few days, I will try to change. > >> > > if you need more information, just ask me. Please do not wonder if you do not get them at the spot. I am in a very remote location where electricity is cut off during the day. > > > Actually, it was quite straight forward. The patch follows. > > Also, a tarball is attached which include patch to man.4/run.4 and new > firmware. I don't know what has been changed, but I'd appreciate if > you try new firmware out. I committed the if_run.c and the new firmware a minute ago. Though, I skipped the man page change for sake of consistency, currently it seems most man pages have those instruction still included. But I agree, strictly speaking it isn't necessary. Thank! -- Bernhard From owner-freebsd-wireless@FreeBSD.ORG Wed Mar 21 20:06:32 2012 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 278BF1065674; Wed, 21 Mar 2012 20:06:32 +0000 (UTC) (envelope-from erichfreebsdlist@ovitrap.com) Received: from alogreentechnologies.com (alogreentechnologies.com [67.212.226.44]) by mx1.freebsd.org (Postfix) with ESMTP id C88FE8FC08; Wed, 21 Mar 2012 20:06:31 +0000 (UTC) Received: from amd620.ovitrap.com ([49.128.188.2]) (authenticated bits=0) by alogreentechnologies.com (8.13.1/8.13.1) with ESMTP id q2LK5jqP028053; Wed, 21 Mar 2012 14:06:06 -0600 From: Erich Dollansky To: Bernhard Schmidt Date: Thu, 22 Mar 2012 03:01:31 +0700 User-Agent: KMail/1.13.7 (FreeBSD/8.3-PRERELEASE; KDE/4.7.4; amd64; ; ) References: <201112171258.56891.erichfreebsdlist@ovitrap.com> <201203212014.37536.bschmidt@freebsd.org> In-Reply-To: <201203212014.37536.bschmidt@freebsd.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201203220301.31815.erichfreebsdlist@ovitrap.com> Cc: PseudoCylon , freebsd-wireless@freebsd.org Subject: Re: Zyxel NWD210N not accepted at boot time but after plugging it in again X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.5 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, 21 Mar 2012 20:06:32 -0000 Hi, On Thursday 22 March 2012 02:14:37 Bernhard Schmidt wrote: > On Sunday 18 December 2011 06:32:46 PseudoCylon wrote: > > On Sat, Dec 17, 2011 at 5:59 PM, Erich Dollansky > > I committed the if_run.c and the new firmware a minute ago. Though, I > skipped the man page change for sake of consistency, currently it seems > most man pages have those instruction still included. But I agree, > strictly speaking it isn't necessary. > > Thank! we have to thank you. I will test it tomorrow (today here). Erich From owner-freebsd-wireless@FreeBSD.ORG Wed Mar 21 21:34:23 2012 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D99D3106564A; Wed, 21 Mar 2012 21:34:23 +0000 (UTC) (envelope-from sendtomatt@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 9429E8FC0A; Wed, 21 Mar 2012 21:34:23 +0000 (UTC) Received: by pbcwz17 with SMTP id wz17so1257190pbc.13 for ; Wed, 21 Mar 2012 14:34:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=PT0iJ+GpvJq2GWHg7Rzd8XD0UuU1NNYbX4o/5CnOtkM=; b=cvRmXMDfmS4cpW+hXqsK+r06z5YO3YH4c5QeJ4o1tgQxgkDKYHqNmXBK/6zaoPljGe PWUz9qXSWr5C31thBi1LndZ89xLbMNLx+s5BfKTxZ06MfPYNYQKTU8DkzSh7GL3ft5up Y74/5Bgna/aFVOYUIucidB/jwGzK+W92eRQZDqgIfvz/BgAkC2OXKSkob1iRAfrlJEot lM45Zl7IG83TCAjoE+M/HdB/LmrTHBAM/G4Ic4KwoWgwhKQQe2/J9fp0S6dYudJr8uPF IM0FcpoEi9wuH9QIFMFXal0c3Y0erQmx7pbi9CWlBLLV+48YQ5GjBnsNTwsVPViHVreM EvYA== Received: by 10.68.219.161 with SMTP id pp1mr14822131pbc.30.1332365663070; Wed, 21 Mar 2012 14:34:23 -0700 (PDT) Received: from bakeneko.local ([75.101.87.90]) by mx.google.com with ESMTPS id l8sm2189640pbi.0.2012.03.21.14.34.09 (version=SSLv3 cipher=OTHER); Wed, 21 Mar 2012 14:34:21 -0700 (PDT) Message-ID: <4F6A48E7.1010006@gmail.com> Date: Wed, 21 Mar 2012 14:32:23 -0700 From: matt User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.1) Gecko/20120301 Thunderbird/10.0.1 MIME-Version: 1.0 To: Bernhard Schmidt References: <4F5A8023.1090705@gmail.com> <4F5AC7CF.3090409@gmail.com> <4F5C0C86.7040503@gmail.com> <4F5C24ED.3090601@gmail.com> <4F5CD920.2000905@gmail.com> <4F5D0876.5040409@gmail.com> <4F5D14E0.3050301@gmail.com> <20120312001625.4d9b3b52.ray@ddteam.net> <4F5E7D17.7000102@gmail.com> <4F5E9814.7010803@gmail.com> <4F5E9BA3.2000401@gmail.com> <20120313131415.36ecd761.ray@dlink.ua> <4F5FE891.7050306@gmail.com> <20120314200718.b6b51452.ray@ddteam.net> <4F651853.2050409@gmail.com> In-Reply-To: X-Enigmail-Version: 1.3.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Aleksandr Rybalko , freebsd-wireless@freebsd.org Subject: Re: Please Test: Updated Ral Driver Patch for rt2860/rt3090 X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.5 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, 21 Mar 2012 21:34:23 -0000 On 03/21/12 00:54, Bernhard Schmidt wrote: > On Wed, Mar 21, 2012 at 06:04, Adrian Chadd wrote: >> Hi, >> >> How's the ralink driver tinkering going? >> >> How far out are we from committing something partially working to >> -HEAD? What are the showstoppers? > Lots of stuff, please let me go over at least the reg.h and var.h > first. I'm only half way through the reg file yet. > Agreed...google code version needs some looking at before anything is committed...There are/were some rough edges last chance I got...unitialized warning for "val" in io_eeeprom_read and of course a fine panic after attach. At least this time there was a debugger...I can't find my firewire bracket. I'll hopefully get some time to keep messing around with it this weekend and see if either Bernhard's work or careful line-by-line comparison with mine can make it happy again. There were quite a few changes to the eeprom side of things I saw (eeprom_ctl), which I think is bringing us closer to OpenBSD compatibility, ie. same eeprom defines? Or just newer code? Thanks, Matt From owner-freebsd-wireless@FreeBSD.ORG Wed Mar 21 23:29:30 2012 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0B9FF1065676 for ; Wed, 21 Mar 2012 23:29:30 +0000 (UTC) (envelope-from sh4neriddle@yahoo.com) Received: from nm38-vm7.bullet.mail.bf1.yahoo.com (nm38-vm7.bullet.mail.bf1.yahoo.com [72.30.239.23]) by mx1.freebsd.org (Postfix) with SMTP id 886898FC20 for ; Wed, 21 Mar 2012 23:29:29 +0000 (UTC) Received: from [98.139.212.150] by nm38.bullet.mail.bf1.yahoo.com with NNFMP; 21 Mar 2012 23:27:42 -0000 Received: from [98.139.212.247] by tm7.bullet.mail.bf1.yahoo.com with NNFMP; 21 Mar 2012 23:27:42 -0000 Received: from [127.0.0.1] by omp1056.mail.bf1.yahoo.com with NNFMP; 21 Mar 2012 23:27:42 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 761759.88593.bm@omp1056.mail.bf1.yahoo.com Received: (qmail 33111 invoked by uid 60001); 21 Mar 2012 23:27:42 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1332372462; bh=k+67CXnBjXnf4nRQY9iR2KluhVjbafhkBoAU1YKoPXo=; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=U0AYo7a2sjs7iRyEARE1jRxE/enqWV3bWrvpyb+8SgL2oIB49/2VNsnMVL/Cu0oeQHy1MQCAvL1Gc8F0iULTFBGSAJOpm7I3WjE0zGcUkXL5AiHUNwVV1k17TLKeWRRwHwb/tUJdr/dTDjodZZoZcKIn3yp+cU8YuiQWYhzlVgY= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=T+CYt/wms5GPq5iN4mKFxS3k5axyWRMCNvGZU/mPQHbSTCDhjQR8l749QKPOUN3P6bc7sppkrEJ1AKH6KoRffka1VhSKJ4IhL2JRrZNUlkzLfpDziHos+f0nwwOXXZmKCq+jCKj0GqA5EYm+TiNYbdMK6ItT5TyLZ9CFIs+q6ls=; X-YMail-OSG: gw57WPEVM1kcSkVMaLRL3a3iisYan5UuYjzRm1m3dXARAJc y3ia7CDApKxhFcfllGbN9BGm0.LBOdGzQ9yPLAVbNnjkmiC.GB3R8dJhKcmt tzh7RfET2w10BiOnk7sTs59WRnJ6xTJqeJVN0EMuAoH0B_qzmhL2CG7E6jWV 0q9SV8K0JTY0tWOvapLuRVl.xh3WKrdRLYI6LaEtXa0n7GXyv78plhm.zR2O nvLud94DBBQ56A_y67m5YU7n8lKx5i6NNTNiq6m.0U.oFVAIdGMCHHA0ot4Z uPp3lssrMNulPVuL4RnhsYEhci1FBtK9SlMx27kvprK6tk8eUKDjolDLICyB XfY0P_oJSh5y1qgEk8vQlvdtneUTNtXJgqKnDOioDJuuQgvc038_dFBjqEJE dObAnNNzq_KRj54g_FnFZNAWA8s9ANADuc.OTyf4AuIz9SwGMriq0DxQFSzC 3JjnIMdf_15Rdx_jYJcDpCpeduFEu8Q3EHTlwx2LWYQKXJxOU2NzgY4oVjQA ppaWcML3T9AEHQlY7u8WU3g2P_YQB Received: from [71.90.34.145] by web162302.mail.bf1.yahoo.com via HTTP; Wed, 21 Mar 2012 16:27:42 PDT X-Mailer: YahooMailWebService/0.8.116.338427 Message-ID: <1332372462.30788.YahooMailNeo@web162302.mail.bf1.yahoo.com> Date: Wed, 21 Mar 2012 16:27:42 -0700 (PDT) From: Shane Riddle To: "freebsd-wireless@freebsd.org" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: intel Centrino 6150 Wireless Card w freebsd8.2 X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Shane Riddle 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, 21 Mar 2012 23:29:30 -0000 Hello Bernhard, Were you ever able to get a hold of this card? iwi and iwn don't seem to support it on my laptop.... or maybe I'm not doing something right. Before investigating further I figured I'd check here first. Thanks. On Wed, Sep 7, 2011 at 10:00, Adrian Chadd wrote: >On 7 September 2011 15:36, kuku kuku wrote: >>>>Thanks Adrian. >>Any plans on adding support with v9 release. >>>>Background: Our company is changing laptops ( ~30 ) wants to go with asus u46 for price/performance Which model is that exactly? >Hi, >>I don't know of any current plans to port the drivers. Bernhard would >be the best person to know. >If someone would like to step up and do/sponsor the port then I'm sure >it'll get done! As soon as I get my hands on one of those cards I can work on adding support for it. -- Bernhard From owner-freebsd-wireless@FreeBSD.ORG Thu Mar 22 01:29:30 2012 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6ACC51065674 for ; Thu, 22 Mar 2012 01:29:30 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by mx1.freebsd.org (Postfix) with ESMTP id 3C6CC8FC0A for ; Thu, 22 Mar 2012 01:29:29 +0000 (UTC) Received: by dald2 with SMTP id d2so2707051dal.13 for ; Wed, 21 Mar 2012 18: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:content-type; bh=b7aPIVUX8EtCLs9oAjAo52A7nBcdOZ4+Cyr0L37fauI=; b=QMy3eookPIv5ijGkLDwLfaP35hiJkctGKH6AN3SlXL6wcvPw1Dp6PHukSmm9PiQOF8 4YyYrInIECakM2VlCawirTUwjzeFuLXmdzCDL3BNIqLwDGCQODVnZvmdnz37zG3+56A+ y36p3Vx0KHUMq3hEvzPT6YViHe/tHnL5LoQe9AbxcGbWeUbVFuJMrN4D7iUT0XWUu8FF 8JiiSs5mZ+kqazGBknSCRkcY2wdQP6SJbdtUe81MOp/hskd4+xJVSIlKqtbfpCbp/42I 4A4ZfCboYA+qY0elD4yvHGsSfCeDAfIutO1jHi6u4O7thRlzZ3Qh1kWKxaJj9ODAFypX xVSw== MIME-Version: 1.0 Received: by 10.68.231.66 with SMTP id te2mr16352148pbc.42.1332379769756; Wed, 21 Mar 2012 18:29:29 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.143.33.5 with HTTP; Wed, 21 Mar 2012 18:29:29 -0700 (PDT) In-Reply-To: References: Date: Wed, 21 Mar 2012 18:29:29 -0700 X-Google-Sender-Auth: FXlI4gjmp1JwZZb104ZqXUcqOlw Message-ID: From: Adrian Chadd To: freebsd-wireless@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [net80211] PR kern/166286: force a channel change upon a HT info change X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.5 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, 22 Mar 2012 01:29:30 -0000 Hi, Here's a second patch. This patch: * Implements a channel width change taskqueue event; * Queues this event whenever a channel width change occurs from beacon frames; * Added a simple change to if_ath to call ath_chan_set() upon receipt of a channel width notification. TODO: * Move the chw routines from ieee80211_node.c/ieee80211_proto.c into ieee80211_ht.c; * Test it with CSAs to ensure we don't get multiple channel changes that aren't necessary. This seems simpler than adding a new state. But, hm, I can't help but wonder whether the correct thing to do here is add a new state that transitions ASSOC -> CHW -> ASSOC. Also there may be other htinfo changes - eg, if an AP decides to change from enabling to disabling RIFS. That currently isn't handled. Adrian From owner-freebsd-wireless@FreeBSD.ORG Thu Mar 22 01:29:50 2012 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 42D68106566B for ; Thu, 22 Mar 2012 01:29:50 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by mx1.freebsd.org (Postfix) with ESMTP id 0D11D8FC1B for ; Thu, 22 Mar 2012 01:29:50 +0000 (UTC) Received: by mail-pz0-f54.google.com with SMTP id d2so2707051dal.13 for ; Wed, 21 Mar 2012 18:29:50 -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=fWeekci9W0/+U7vL1NMDF6G14hC48ALUk7VCM4YE8TM=; b=IA0CXxU8kaKCOcQjaHZq5rsJYaiifuHv/ihx2xqbqUDhpyKiSfplVwrUqTZqd1b0fJ LvbY04IlDy4KYjXYG3u+2zsx7sKzJ14XL3sWS6c/USbbouclA5PdVh78fS+8BFHkr/Ex j/Dx9/niKmqYSRojX559ZYq9HRAGs9hZAlU91kIqBc/VZ6kS5KDjVFQqs3QC3RGKYCft jjh6SC2vEmYxVmXypebDMO8DaSabvKyHYgMscahVdckUSH1Xtyw5oWLFNyx/pFbgajjL WSL3hr5qpV2muBSdJB+04t4SE2+hckFx1T/K0Wjf23qrzPi7BK4UpjiF2vV+DcS6e2SZ /MsA== MIME-Version: 1.0 Received: by 10.68.194.199 with SMTP id hy7mr2261848pbc.37.1332379789920; Wed, 21 Mar 2012 18:29:49 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.143.33.5 with HTTP; Wed, 21 Mar 2012 18:29:49 -0700 (PDT) In-Reply-To: References: Date: Wed, 21 Mar 2012 18:29:49 -0700 X-Google-Sender-Auth: LVAIR-ESNYXMQpugGe1J8n6eeiQ Message-ID: From: Adrian Chadd To: freebsd-wireless@freebsd.org Content-Type: multipart/mixed; boundary=047d7b10ca79158b5104bbcad848 Subject: Re: [net80211] PR kern/166286: force a channel change upon a HT info change X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.5 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, 22 Mar 2012 01:29:50 -0000 --047d7b10ca79158b5104bbcad848 Content-Type: text/plain; charset=ISO-8859-1 .. and the patch. Adrian --047d7b10ca79158b5104bbcad848 Content-Type: text/x-patch; charset=US-ASCII; name="net80211-force-chw-on-ht-change-pr-166286-2.diff" Content-Disposition: attachment; filename="net80211-force-chw-on-ht-change-pr-166286-2.diff" Content-Transfer-Encoding: base64 X-Attachment-Id: f_h034kmhn0 SW5kZXg6IHN5cy9kZXYvYXRoL2lmX2F0aC5jCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIHN5cy9kZXYvYXRoL2lm X2F0aC5jCShyZXZpc2lvbiAyMzMwODkpCisrKyBzeXMvZGV2L2F0aC9pZl9hdGguYwkod29ya2lu ZyBjb3B5KQpAQCAtMTk5LDYgKzE5OSw3IEBACiBzdGF0aWMgdm9pZAlhdGhfc2Nhbl9zdGFydChz dHJ1Y3QgaWVlZTgwMjExY29tICopOwogc3RhdGljIHZvaWQJYXRoX3NjYW5fZW5kKHN0cnVjdCBp ZWVlODAyMTFjb20gKik7CiBzdGF0aWMgdm9pZAlhdGhfc2V0X2NoYW5uZWwoc3RydWN0IGllZWU4 MDIxMWNvbSAqKTsKK3N0YXRpYyB2b2lkCWF0aF91cGRhdGVfY2h3KHN0cnVjdCBpZWVlODAyMTFj b20gKik7CiBzdGF0aWMgdm9pZAlhdGhfY2FsaWJyYXRlKHZvaWQgKik7CiBzdGF0aWMgaW50CWF0 aF9uZXdzdGF0ZShzdHJ1Y3QgaWVlZTgwMjExdmFwICosIGVudW0gaWVlZTgwMjExX3N0YXRlLCBp bnQpOwogc3RhdGljIHZvaWQJYXRoX3NldHVwX3N0YXRpb25rZXkoc3RydWN0IGllZWU4MDIxMV9u b2RlICopOwpAQCAtNzk0LDYgKzc5NSw3IEBACiAJaWMtPmljX3NjYW5fc3RhcnQgPSBhdGhfc2Nh bl9zdGFydDsKIAlpYy0+aWNfc2Nhbl9lbmQgPSBhdGhfc2Nhbl9lbmQ7CiAJaWMtPmljX3NldF9j aGFubmVsID0gYXRoX3NldF9jaGFubmVsOworCWljLT5pY191cGRhdGVfY2h3ID0gYXRoX3VwZGF0 ZV9jaHc7CiAKIAkvKiA4MDIuMTFuIHNwZWNpZmljIC0gYnV0IGp1c3Qgb3ZlcnJpZGUgYW55d2F5 ICovCiAJc2MtPnNjX2FkZGJhX3JlcXVlc3QgPSBpYy0+aWNfYWRkYmFfcmVxdWVzdDsKQEAgLTU3 MTcsNyArNTcxOSwzMiBAQAogCQkgc2MtPnNjX2N1cmFpZCk7CiB9CiAKKy8qCisgKiBGb3Igbm93 LCBqdXN0IGRvIGEgY2hhbm5lbCBjaGFuZ2UuCisgKgorICogTGF0ZXIsIHdlJ2xsIGdvIHRocm91 Z2ggdGhlIGhhcmQgc2xvZyBvZiBzdXNwZW5kaW5nIHR4L3J4LCBjaGFuZ2luZyByYXRlCisgKiBj b250cm9sIHN0YXRlIGFuZCByZXNldHRpbmcgdGhlIGhhcmR3YXJlIHdpdGhvdXQgZHJvcHBpbmcg ZnJhbWVzIG91dAorICogb2YgdGhlIHF1ZXVlLgorICoKKyAqIFRoZSB1bmZvcnR1bmF0ZSB0cm91 YmxlIGhlcmUgaXMgbWFraW5nIGFic29sdXRlbHkgc3VyZSB0aGF0IHRoZQorICogY2hhbm5lbCB3 aWR0aCBjaGFuZ2UgaGFzIHByb3BhZ2F0ZWQgZW5vdWdoIHNvIHRoZSBoYXJkd2FyZQorICogYWJz b2x1dGVseSBpc24ndCBoYW5kZWQgYm9ndXMgZnJhbWVzIGZvciBpdCdzIGN1cnJlbnQgb3BlcmF0 aW5nCisgKiBtb2RlLiAoRWcsIDQwTUh6IGZyYW1lcyBpbiAyME1IeiBtb2RlLikgU2luY2UgVFgg YW5kIFJYIGNhbiBhbmQKKyAqIGRvZXMgb2NjdXIgaW4gcGFyYWxsZWwsIHdlIG5lZWQgdG8gbWFr ZSBjZXJ0YWluIHdlJ3ZlIGJsb2NrZWQKKyAqIGFueSBmdXJ0aGVyIG9uZ29pbmcgVFggKGFuZCBS WCwgdGhhdCBjYW4gY2F1c2UgcmF3IFRYKQorICogYmVmb3JlIHdlIGRvIHRoaXMuCisgKi8KIHN0 YXRpYyB2b2lkCithdGhfdXBkYXRlX2NodyhzdHJ1Y3QgaWVlZTgwMjExY29tICppYykKK3sKKwlz dHJ1Y3QgaWZuZXQgKmlmcCA9IGljLT5pY19pZnA7CisJc3RydWN0IGF0aF9zb2Z0YyAqc2MgPSBp ZnAtPmlmX3NvZnRjOworCisJRFBSSU5URihzYywgQVRIX0RFQlVHX1NUQVRFLCAiJXM6IGNhbGxl ZFxuIiwgX19mdW5jX18pOworCWF0aF9zZXRfY2hhbm5lbChpYyk7Cit9CisKK3N0YXRpYyB2b2lk CiBhdGhfc2V0X2NoYW5uZWwoc3RydWN0IGllZWU4MDIxMWNvbSAqaWMpCiB7CiAJc3RydWN0IGlm bmV0ICppZnAgPSBpYy0+aWNfaWZwOwpJbmRleDogc3lzL25ldDgwMjExL2llZWU4MDIxMV9odC5j Cj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT0KLS0tIHN5cy9uZXQ4MDIxMS9pZWVlODAyMTFfaHQuYwkocmV2aXNpb24gMjMz MjU0KQorKysgc3lzL25ldDgwMjExL2llZWU4MDIxMV9odC5jCSh3b3JraW5nIGNvcHkpCkBAIC0x NDI4LDEyICsxNDI4LDEzIEBACiAgKiByZXF1aXJlZCBjaGFubmVsIGNoYW5nZSBpcyBkb25lIChl LmcuIGluIHN0YSBtb2RlIHdoZW4KICAqIHBhcnNpbmcgdGhlIGNvbnRlbnRzIG9mIGEgYmVhY29u IGZyYW1lKS4KICAqLwotc3RhdGljIHZvaWQKK3N0YXRpYyBpbnQKIGh0aW5mb191cGRhdGVfY2h3 KHN0cnVjdCBpZWVlODAyMTFfbm9kZSAqbmksIGludCBodGZsYWdzKQogewogCXN0cnVjdCBpZWVl ODAyMTFjb20gKmljID0gbmktPm5pX2ljOwogCXN0cnVjdCBpZWVlODAyMTFfY2hhbm5lbCAqYzsK IAlpbnQgY2hhbmZsYWdzOworCWludCByZXQgPSAwOwogCiAJY2hhbmZsYWdzID0gKG5pLT5uaV9j aGFuLT5pY19mbGFncyAmfiBJRUVFODAyMTFfQ0hBTl9IVCkgfCBodGZsYWdzOwogCWlmIChjaGFu ZmxhZ3MgIT0gbmktPm5pX2NoYW4tPmljX2ZsYWdzKSB7CkBAIC0xNDYwLDExICsxNDYxLDEzIEBA CiAJCQkgICAgSUVFRTgwMjExX0lTX0NIQU5fSFQ0MChjKSA/IDQwIDogMjAsCiAJCQkgICAgYy0+ aWNfZnJlcSwgYy0+aWNfZmxhZ3MpOwogCQkJbmktPm5pX2NoYW4gPSBjOworCQkJcmV0ID0gMTsK IAkJfQogCQkvKiBOQjogY2FsbGVyIHJlc3BvbnNpYmxlIGZvciBmb3JjaW5nIGFueSBjaGFubmVs IGNoYW5nZSAqLwogCX0KIAkvKiB1cGRhdGUgbm9kZSdzIHR4IGNoYW5uZWwgd2lkdGggKi8KIAlu aS0+bmlfY2h3ID0gSUVFRTgwMjExX0lTX0NIQU5fSFQ0MChuaS0+bmlfY2hhbik/IDQwIDogMjA7 CisJcmV0dXJuIChyZXQpOwogfQogCiAvKgpAQCAtMTUxNSwxMyArMTUxOCwxNCBAQAogICogUGFy c2UgYW5kIHVwZGF0ZSBIVC1yZWxhdGVkIHN0YXRlIGV4dHJhY3RlZCBmcm9tCiAgKiB0aGUgSFQg Y2FwIGFuZCBpbmZvIGllJ3MuCiAgKi8KLXZvaWQKK2ludAogaWVlZTgwMjExX2h0X3VwZGF0ZXBh cmFtcyhzdHJ1Y3QgaWVlZTgwMjExX25vZGUgKm5pLAogCWNvbnN0IHVpbnQ4X3QgKmh0Y2FwaWUs IGNvbnN0IHVpbnQ4X3QgKmh0aW5mb2llKQogewogCXN0cnVjdCBpZWVlODAyMTF2YXAgKnZhcCA9 IG5pLT5uaV92YXA7CiAJY29uc3Qgc3RydWN0IGllZWU4MDIxMV9pZV9odGluZm8gKmh0aW5mbzsK IAlpbnQgaHRmbGFnczsKKwlpbnQgcmV0ID0gMDsKIAogCWllZWU4MDIxMV9wYXJzZV9odGNhcChu aSwgaHRjYXBpZSk7CiAJaWYgKHZhcC0+aXZfaHRjYXBzICYgSUVFRTgwMjExX0hUQ0FQX1NNUFMp CkBAIC0xNTQzLDEzICsxNTQ3LDE2IEBACiAJCWVsc2UgaWYgKG5pLT5uaV9odDJuZGNoYW4gPT0g SUVFRTgwMjExX0hUSU5GT18yTkRDSEFOX0JFTE9XKQogCQkJaHRmbGFncyA9IElFRUU4MDIxMV9D SEFOX0hUNDBEOwogCX0KLQlodGluZm9fdXBkYXRlX2NodyhuaSwgaHRmbGFncyk7CisJaWYgKGh0 aW5mb191cGRhdGVfY2h3KG5pLCBodGZsYWdzKSkKKwkJcmV0ID0gMTsKIAogCWlmICgoaHRpbmZv LT5oaV9ieXRlMSAmIElFRUU4MDIxMV9IVElORk9fUklGU01PREVfUEVSTSkgJiYKIAkgICAgKHZh cC0+aXZfZmxhZ3NfaHQgJiBJRUVFODAyMTFfRkhUX1JJRlMpKQogCQluaS0+bmlfZmxhZ3MgfD0g SUVFRTgwMjExX05PREVfUklGUzsKIAllbHNlCiAJCW5pLT5uaV9mbGFncyAmPSB+SUVFRTgwMjEx X05PREVfUklGUzsKKworCXJldHVybiAocmV0KTsKIH0KIAogLyoKQEAgLTE1NzgsNyArMTU4NSw3 IEBACiAJCWVsc2UgaWYgKElFRUU4MDIxMV9JU19DSEFOX0hUNDBEKHZhcC0+aXZfYnNzLT5uaV9j aGFuKSkKIAkJCWh0ZmxhZ3MgPSBJRUVFODAyMTFfQ0hBTl9IVDQwRDsKIAl9Ci0JaHRpbmZvX3Vw ZGF0ZV9jaHcobmksIGh0ZmxhZ3MpOworCSh2b2lkKSBodGluZm9fdXBkYXRlX2NodyhuaSwgaHRm bGFncyk7CiB9CiAKIC8qCkluZGV4OiBzeXMvbmV0ODAyMTEvaWVlZTgwMjExX2h0LmgKPT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PQotLS0gc3lzL25ldDgwMjExL2llZWU4MDIxMV9odC5oCShyZXZpc2lvbiAyMzMyNTQpCisr KyBzeXMvbmV0ODAyMTEvaWVlZTgwMjExX2h0LmgJKHdvcmtpbmcgY29weSkKQEAgLTE4NCw3ICsx ODQsNyBAQAogdm9pZAlpZWVlODAyMTFfaHRfdGltZW91dChzdHJ1Y3QgaWVlZTgwMjExY29tICop Owogdm9pZAlpZWVlODAyMTFfcGFyc2VfaHRjYXAoc3RydWN0IGllZWU4MDIxMV9ub2RlICosIGNv bnN0IHVpbnQ4X3QgKik7CiB2b2lkCWllZWU4MDIxMV9wYXJzZV9odGluZm8oc3RydWN0IGllZWU4 MDIxMV9ub2RlICosIGNvbnN0IHVpbnQ4X3QgKik7Ci12b2lkCWllZWU4MDIxMV9odF91cGRhdGVw YXJhbXMoc3RydWN0IGllZWU4MDIxMV9ub2RlICosIGNvbnN0IHVpbnQ4X3QgKiwKK2ludAlpZWVl ODAyMTFfaHRfdXBkYXRlcGFyYW1zKHN0cnVjdCBpZWVlODAyMTFfbm9kZSAqLCBjb25zdCB1aW50 OF90ICosCiAJCWNvbnN0IHVpbnQ4X3QgKik7CiB2b2lkCWllZWU4MDIxMV9odF91cGRhdGVodGNh cChzdHJ1Y3QgaWVlZTgwMjExX25vZGUgKiwgY29uc3QgdWludDhfdCAqKTsKIGludAlpZWVlODAy MTFfYW1wZHVfcmVxdWVzdChzdHJ1Y3QgaWVlZTgwMjExX25vZGUgKiwKSW5kZXg6IHN5cy9uZXQ4 MDIxMS9pZWVlODAyMTFfc3RhLmMKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gc3lzL25ldDgwMjExL2llZWU4MDIx MV9zdGEuYwkocmV2aXNpb24gMjMzMjU0KQorKysgc3lzL25ldDgwMjExL2llZWU4MDIxMV9zdGEu Ywkod29ya2luZyBjb3B5KQpAQCAtMTI4NSw2ICsxMjg1LDcgQEAKIAl1aW50OF90ICpmcm0sICpl ZnJtOwogCXVpbnQ4X3QgKnJhdGVzLCAqeHJhdGVzLCAqd21lLCAqaHRjYXAsICpodGluZm87CiAJ dWludDhfdCByYXRlOworCWludCBjaGFuX2NoYW5nZSA9IDA7CiAKIAl3aCA9IG10b2QobTAsIHN0 cnVjdCBpZWVlODAyMTFfZnJhbWUgKik7CiAJZnJtID0gKHVpbnQ4X3QgKikmd2hbMV07CkBAIC0x MzcyLDggKzEzNzMsOSBAQAogI2VuZGlmCiAJCQlpZiAoc2Nhbi5odGNhcCAhPSBOVUxMICYmIHNj YW4uaHRpbmZvICE9IE5VTEwgJiYKIAkJCSAgICAodmFwLT5pdl9mbGFnc19odCAmIElFRUU4MDIx MV9GSFRfSFQpKSB7Ci0JCQkJaWVlZTgwMjExX2h0X3VwZGF0ZXBhcmFtcyhuaSwKLQkJCQkgICAg c2Nhbi5odGNhcCwgc2Nhbi5odGluZm8pOworCQkJCWlmIChpZWVlODAyMTFfaHRfdXBkYXRlcGFy YW1zKG5pLAorCQkJCSAgICBzY2FuLmh0Y2FwLCBzY2FuLmh0aW5mbykpCisJCQkJCWNoYW5fY2hh bmdlID0gMTsKIAkJCQkvKiBYWFggc3RhdGUgY2hhbmdlcz8gKi8KIAkJCX0KIAkJCWlmIChzY2Fu LnF1aWV0KQpAQCAtMTQ0MSw2ICsxNDQzLDEzIEBACiAjZW5kaWYKIAkJCQlpZWVlODAyMTFfYmdf c2Nhbih2YXAsIDApOwogCQkJfQorCisJCQkvKgorCQkJICogSWYgd2UndmUgaGFkIGEgc3RhdGUg Y2hhbmdlIChlZyBIVDIwPC0+SFQ0MCkKKwkJCSAqIHRoZW4gc2NoZWR1bGUgYSBkZWxheWVkIGRy aXZlciBub3RpZmljYXRpb24uCisJCQkgKi8KKwkJCWlmIChjaGFuX2NoYW5nZSkKKwkJCQlpZWVl ODAyMTFfdXBkYXRlX2NodyhpYyk7CiAJCQlyZXR1cm47CiAJCX0KIAkJLyoKSW5kZXg6IHN5cy9u ZXQ4MDIxMS9pZWVlODAyMTFfcHJvdG8uYwo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBzeXMvbmV0ODAyMTEvaWVl ZTgwMjExX3Byb3RvLmMJKHJldmlzaW9uIDIzMzI1NCkKKysrIHN5cy9uZXQ4MDIxMS9pZWVlODAy MTFfcHJvdG8uYwkod29ya2luZyBjb3B5KQpAQCAtMTA1LDYgKzEwNSw3IEBACiBzdGF0aWMgdm9p ZCB1cGRhdGVfbWNhc3Qodm9pZCAqLCBpbnQpOwogc3RhdGljIHZvaWQgdXBkYXRlX3Byb21pc2Mo dm9pZCAqLCBpbnQpOwogc3RhdGljIHZvaWQgdXBkYXRlX2NoYW5uZWwodm9pZCAqLCBpbnQpOwor c3RhdGljIHZvaWQgdXBkYXRlX2Nodyh2b2lkICosIGludCk7CiBzdGF0aWMgdm9pZCBpZWVlODAy MTFfbmV3c3RhdGVfY2Iodm9pZCAqLCBpbnQpOwogc3RhdGljIGludCBpZWVlODAyMTFfbmV3X3N0 YXRlX2xvY2tlZChzdHJ1Y3QgaWVlZTgwMjExdmFwICosCiAJZW51bSBpZWVlODAyMTFfc3RhdGUs IGludCk7CkBAIC0xNDQsNiArMTQ1LDcgQEAKIAlUQVNLX0lOSVQoJmljLT5pY19wcm9taXNjX3Rh c2ssIDAsIHVwZGF0ZV9wcm9taXNjLCBpYyk7CiAJVEFTS19JTklUKCZpYy0+aWNfY2hhbl90YXNr LCAwLCB1cGRhdGVfY2hhbm5lbCwgaWMpOwogCVRBU0tfSU5JVCgmaWMtPmljX2JtaXNzX3Rhc2ss IDAsIGJlYWNvbl9taXNzLCBpYyk7CisJVEFTS19JTklUKCZpYy0+aWNfY2h3X3Rhc2ssIDAsIHVw ZGF0ZV9jaHcsIGljKTsKIAogCWljLT5pY193bWUud21lX2hpcHJpX3N3aXRjaF9oeXN0ZXJlc2lz ID0KIAkJQUdHUkVTU0lWRV9NT0RFX1NXSVRDSF9IWVNURVJFU0lTOwpAQCAtMTE0Nyw2ICsxMTQ5 LDE3IEBACiAJaWVlZTgwMjExX3JhZGlvdGFwX2NoYW5fY2hhbmdlKGljKTsKIH0KIAorc3RhdGlj IHZvaWQKK3VwZGF0ZV9jaHcodm9pZCAqYXJnLCBpbnQgbnBlbmRpbmcpCit7CisJc3RydWN0IGll ZWU4MDIxMWNvbSAqaWMgPSBhcmc7CisKKwkvKgorCSAqIFhYWCBzaG91bGQgd2UgZGVmZXIgdGhl IGNoYW5uZWwgd2lkdGggX2NvbmZpZ18gdXBkYXRlIHVudGlsIG5vdz8KKwkgKi8KKwlpYy0+aWNf dXBkYXRlX2NodyhpYyk7Cit9CisKIC8qCiAgKiBCbG9jayB1bnRpbCB0aGUgcGFyZW50IGlzIGlu IGEga25vd24gc3RhdGUuICBUaGlzIGlzCiAgKiB1c2VkIGFmdGVyIGFueSBvcGVyYXRpb25zIHRo YXQgZGlzcGF0Y2ggYSB0YXNrIChlLmcuCkBAIC0xMTYxLDYgKzExNzQsNyBAQAogCWllZWU4MDIx MV9kcmFpbnRhc2soaWMsICZpYy0+aWNfcHJvbWlzY190YXNrKTsKIAlpZWVlODAyMTFfZHJhaW50 YXNrKGljLCAmaWMtPmljX2NoYW5fdGFzayk7CiAJaWVlZTgwMjExX2RyYWludGFzayhpYywgJmlj LT5pY19ibWlzc190YXNrKTsKKwlpZWVlODAyMTFfZHJhaW50YXNrKGljLCAmaWMtPmljX2Nod190 YXNrKTsKIAl0YXNrcXVldWVfdW5ibG9jayhpYy0+aWNfdHEpOwogfQogCkluZGV4OiBzeXMvbmV0 ODAyMTEvaWVlZTgwMjExX25vZGUuYwo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBzeXMvbmV0ODAyMTEvaWVlZTgw MjExX25vZGUuYwkocmV2aXNpb24gMjMzMjU0KQorKysgc3lzL25ldDgwMjExL2llZWU4MDIxMV9u b2RlLmMJKHdvcmtpbmcgY29weSkKQEAgLTY4NSw2ICs2ODUsMTQgQEAKIAlpZWVlODAyMTFfcnVu dGFzayhpYywgJmljLT5pY19jaGFuX3Rhc2spOwogfQogCit2b2lkCitpZWVlODAyMTFfdXBkYXRl X2NodyhzdHJ1Y3QgaWVlZTgwMjExY29tICppYykKK3sKKworCWllZWU4MDIxMV9zZXR1cGN1cmNo YW4oaWMsIGljLT5pY19jdXJjaGFuKTsKKwlpZWVlODAyMTFfcnVudGFzayhpYywgJmljLT5pY19j aHdfdGFzayk7Cit9CisKIC8qCiAgKiBKb2luIHRoZSBzcGVjaWZpZWQgSUJTUy9CU1MgbmV0d29y ay4gIFRoZSBub2RlIGlzIGFzc3VtZWQgdG8KICAqIGJlIHBhc3NlZCBpbiB3aXRoIGEgaGVsZCBy ZWZlcmVuY2UuCkluZGV4OiBzeXMvbmV0ODAyMTEvaWVlZTgwMjExX25vZGUuaAo9PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 Ci0tLSBzeXMvbmV0ODAyMTEvaWVlZTgwMjExX25vZGUuaAkocmV2aXNpb24gMjMzMjU0KQorKysg c3lzL25ldDgwMjExL2llZWU4MDIxMV9ub2RlLmgJKHdvcmtpbmcgY29weSkKQEAgLTMyNCw2ICsz MjQsNyBAQAogdm9pZAlpZWVlODAyMTFfc2V0dXBjdXJjaGFuKHN0cnVjdCBpZWVlODAyMTFjb20g KiwKIAkgICAgc3RydWN0IGllZWU4MDIxMV9jaGFubmVsICopOwogdm9pZAlpZWVlODAyMTFfc2V0 Y3VyY2hhbihzdHJ1Y3QgaWVlZTgwMjExY29tICosIHN0cnVjdCBpZWVlODAyMTFfY2hhbm5lbCAq KTsKK3ZvaWQJaWVlZTgwMjExX3VwZGF0ZV9jaHcoc3RydWN0IGllZWU4MDIxMWNvbSAqKTsKIGlu dAlpZWVlODAyMTFfaWJzc19tZXJnZShzdHJ1Y3QgaWVlZTgwMjExX25vZGUgKik7CiBzdHJ1Y3Qg aWVlZTgwMjExX3NjYW5fZW50cnk7CiBpbnQJaWVlZTgwMjExX3N0YV9qb2luKHN0cnVjdCBpZWVl ODAyMTF2YXAgKiwgc3RydWN0IGllZWU4MDIxMV9jaGFubmVsICosCkluZGV4OiBzeXMvbmV0ODAy MTEvaWVlZTgwMjExX3Zhci5oCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIHN5cy9uZXQ4MDIxMS9pZWVlODAyMTFf dmFyLmgJKHJldmlzaW9uIDIzMzI1NCkKKysrIHN5cy9uZXQ4MDIxMS9pZWVlODAyMTFfdmFyLmgJ KHdvcmtpbmcgY29weSkKQEAgLTEzMCw2ICsxMzAsNyBAQAogCXN0cnVjdCB0YXNrCQlpY19tY2Fz dF90YXNrOwkvKiBkZWZlcnJlZCBtY2FzdCB1cGRhdGUgKi8KIAlzdHJ1Y3QgdGFzawkJaWNfY2hh bl90YXNrOwkvKiBkZWZlcnJlZCBjaGFubmVsIGNoYW5nZSAqLwogCXN0cnVjdCB0YXNrCQlpY19i bWlzc190YXNrOwkvKiBkZWZlcnJlZCBiZWFjb24gbWlzcyBobmRsciAqLworCXN0cnVjdCB0YXNr CQlpY19jaHdfdGFzazsJLyogZGVmZXJyZWQgSFQgQ0hXIHVwZGF0ZSAqLwogCiAJdWludDMyX3QJ CWljX2ZsYWdzOwkvKiBzdGF0ZSBmbGFncyAqLwogCXVpbnQzMl90CQlpY19mbGFnc19leHQ7CS8q IGV4dGVuZGVkIHN0YXRlIGZsYWdzICovCkBAIC0zMjIsNiArMzIzLDEwIEBACiAJCQkJICAgIGlu dCBiYXRpbWVvdXQsIGludCBiYXNlcWN0bCk7CiAJdm9pZAkJCSgqaWNfYW1wZHVfcnhfc3RvcCko c3RydWN0IGllZWU4MDIxMV9ub2RlICosCiAJCQkJICAgIHN0cnVjdCBpZWVlODAyMTFfcnhfYW1w ZHUgKik7CisKKwkvKiBUaGUgY2hhbm5lbCB3aWR0aCBoYXMgY2hhbmdlZCAoMjA8LT4yMDQwKSAq LworCXZvaWQJCQkoKmljX3VwZGF0ZV9jaHcpKHN0cnVjdCBpZWVlODAyMTFjb20gKik7CisKIAl1 aW50NjRfdAkJaWNfc3BhcmVbN107CiB9OwogCkluZGV4OiBzeXMvbmV0ODAyMTEvaWVlZTgwMjEx LmMKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PQotLS0gc3lzL25ldDgwMjExL2llZWU4MDIxMS5jCShyZXZpc2lvbiAyMzMy NTQpCisrKyBzeXMvbmV0ODAyMTEvaWVlZTgwMjExLmMJKHdvcmtpbmcgY29weSkKQEAgLTI1Niw2 ICsyNTYsMTMgQEAKIAltX2ZyZWVtKG0pOwogfQogCitzdGF0aWMgdm9pZAorbnVsbF91cGRhdGVf Y2h3KHN0cnVjdCBpZWVlODAyMTFjb20gKmljKQoreworCisJaWZfcHJpbnRmKGljLT5pY19pZnAs ICIlczogbmVlZCBjYWxsYmFja1xuIiwgX19mdW5jX18pOworfQorCiAvKgogICogQXR0YWNoL3Nl dHVwIHRoZSBjb21tb24gbmV0ODAyMTEgc3RhdGUuICBDYWxsZWQgYnkKICAqIHRoZSBkcml2ZXIg b24gYXR0YWNoIHRvIHByaW9yIHRvIGNyZWF0aW5nIGFueSB2YXAncy4KQEAgLTI4Nyw2ICsyOTQs NyBAQAogCiAJaWMtPmljX3VwZGF0ZV9tY2FzdCA9IG51bGxfdXBkYXRlX21jYXN0OwogCWljLT5p Y191cGRhdGVfcHJvbWlzYyA9IG51bGxfdXBkYXRlX3Byb21pc2M7CisJaWMtPmljX3VwZGF0ZV9j aHcgPSBudWxsX3VwZGF0ZV9jaHc7CiAKIAlpYy0+aWNfaGFzaF9rZXkgPSBhcmM0cmFuZG9tKCk7 CiAJaWMtPmljX2JpbnR2YWwgPSBJRUVFODAyMTFfQklOVFZBTF9ERUZBVUxUOwo= --047d7b10ca79158b5104bbcad848-- From owner-freebsd-wireless@FreeBSD.ORG Thu Mar 22 07:49:33 2012 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0333C106564A for ; Thu, 22 Mar 2012 07:49:33 +0000 (UTC) (envelope-from bschmidt@techwires.net) Received: from mail-lpp01m010-f54.google.com (mail-lpp01m010-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 712528FC0C for ; Thu, 22 Mar 2012 07:49:32 +0000 (UTC) Received: by lagv3 with SMTP id v3so1890109lag.13 for ; Thu, 22 Mar 2012 00:49:31 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=eGf5Et2VTjcLZFLBfRNDSOkk/EhxbdKBDm2jIa4n+p8=; b=LqmiP2OxsxrhJbHW01A0f6DbmeiuKZ2u15WKSDKKHh3oq5Q0RqjUs4tW0oU+djJIzw gNkLpoRMf46jE4/Z7t0tgkd1DPr5acr+a5Ebl2154YAy3tF9uPrMlsNF4F/yAEh3vuLe TfIdRXXdpLzQl5TqSADb0+ZOVGitERpgeLP9y4KKXEf4PCJUcBRf81Z0Yf4gHxnk5u/9 QM5qbF5wbALymb6/aX8T/ObOLTn/adVc18ljoP1hXd7z/mT7GNgzk+PIhmkMmgxlrTPs F9vMyfBBMnK5FIHi4zliJi1Kcsu4BxecpNSNcQ2nONbxjdS3Ve8SYbHs2RnTyHTLTyZ1 4HhQ== MIME-Version: 1.0 Received: by 10.152.112.68 with SMTP id io4mr4845553lab.40.1332402571128; Thu, 22 Mar 2012 00:49:31 -0700 (PDT) Received: by 10.152.112.234 with HTTP; Thu, 22 Mar 2012 00:49:31 -0700 (PDT) X-Originating-IP: [79.140.39.245] In-Reply-To: <1332372462.30788.YahooMailNeo@web162302.mail.bf1.yahoo.com> References: <1332372462.30788.YahooMailNeo@web162302.mail.bf1.yahoo.com> Date: Thu, 22 Mar 2012 08:49:31 +0100 Message-ID: From: Bernhard Schmidt To: Shane Riddle Content-Type: multipart/mixed; boundary=f46d0408d73df3301c04bbd025ec X-Gm-Message-State: ALoCoQnL+8B2ZHtACbrcjHauj6L8BOox0rUCIIgdAhzo5buwXuyeybV2YDspZWJMCUMaUB6IuRpS Cc: "freebsd-wireless@freebsd.org" Subject: Re: intel Centrino 6150 Wireless Card w freebsd8.2 X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.5 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, 22 Mar 2012 07:49:33 -0000 --f46d0408d73df3301c04bbd025ec Content-Type: text/plain; charset=ISO-8859-1 On Thu, Mar 22, 2012 at 00:27, Shane Riddle wrote: > Hello Bernhard, > > > Were you ever able to get a hold of this card? No, the cards with wimax support are hard to get. > iwi and iwn don't seem to support it on my laptop.... or maybe I'm not doing something right. Before investigating further I figured I'd check here first. I can't say for certain that the card is supported due to mentioned lack of hardware, but chances are pretty good that with just applying attached patch you get the card to work on a recent 9 version. Want to give it a shot? -- Bernhard --f46d0408d73df3301c04bbd025ec Content-Type: text/x-diff; charset=US-ASCII; name="iwn_6150.diff" Content-Disposition: attachment; filename="iwn_6150.diff" Content-Transfer-Encoding: base64 X-Attachment-Id: f_h03i2oel0 SW5kZXg6IHN5cy9kZXYvaXduL2lmX2l3bi5jCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIHN5cy9kZXYvaXduL2lm X2l3bi5jCShyZXZpc2lvbiAyMzMxNjUpCisrKyBzeXMvZGV2L2l3bi9pZl9pd24uYwkod29ya2lu ZyBjb3B5KQpAQCAtODksNiArODksOCBAQCBzdGF0aWMgY29uc3Qgc3RydWN0IGl3bl9pZGVudCBp d25faWRlbnRfdGFibGVbXSA9CiAJeyAweDgwODYsIDB4MDA4YiwgIkludGVsKFIpIENlbnRyaW5v KFIpIFdpcmVsZXNzLU4gMTAzMCIJIH0sCiAJeyAweDgwODYsIDB4MDA5MCwgIkludGVsKFIpIENl bnRyaW5vKFIpIEFkdmFuY2VkLU4gNjIzMCIJIH0sCiAJeyAweDgwODYsIDB4MDA5MSwgIkludGVs KFIpIENlbnRyaW5vKFIpIEFkdmFuY2VkLU4gNjIzMCIJIH0sCisJeyAweDgwODYsIDB4MDg4NSwg IkludGVsKFIpIENlbnRyaW5vKFIpIFdpcmVsZXNzLU4gKyBXaU1BWCA2MTUwIiB9LAorCXsgMHg4 MDg2LCAweDA4ODYsICJJbnRlbChSKSBDZW50cmlubyhSKSBXaXJlbGVzcy1OICsgV2lNQVggNjE1 MCIgfSwKIAl7IDB4ODA4NiwgMHgwODk2LCAiSW50ZWwoUikgQ2VudHJpbm8oUikgV2lyZWxlc3Mt TiAxMzAiCQkgfSwKIAl7IDB4ODA4NiwgMHg0MjI5LCAiSW50ZWwoUikgV2lyZWxlc3MgV2lGaSBM aW5rIDQ5NjUiCQkgfSwKIAl7IDB4ODA4NiwgMHg0MjJiLCAiSW50ZWwoUikgQ2VudHJpbm8oUikg VWx0aW1hdGUtTiA2MzAwIgkgfSwK --f46d0408d73df3301c04bbd025ec-- From owner-freebsd-wireless@FreeBSD.ORG Thu Mar 22 07:57:34 2012 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 112121065674 for ; Thu, 22 Mar 2012 07:57:34 +0000 (UTC) (envelope-from bschmidt@techwires.net) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) by mx1.freebsd.org (Postfix) with ESMTP id 6CA738FC16 for ; Thu, 22 Mar 2012 07:57:33 +0000 (UTC) Received: by lboi15 with SMTP id i15so1893292lbo.13 for ; Thu, 22 Mar 2012 00:57:26 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=sbGdirOQImSb2pFX/IYAWKbZ0TK3ONw/Br+/+0xZHbw=; b=XSiZnnUev1cDCILSRy8j5Nura3ijyKh0H9KQ4WFtjbzOaJk8jutmCOc8DGvss2Vb4k Ow3rXFOzl/jfJ1tX+ud2Zc/gdOY/K6/fJLph45UW6OCd6MY30gD/0EdjuzXfuB91Qfkh CYqrCysjBcu+OcwQfhCBGZQ00JyQLDPJmcMGLzTK9Q+o/pifNbaBd/Oh3ZCWLCoRzHX7 +8HTwQN+Yl1MzRT+qbUHcf/cJsqbuQG+O5wWNSeiY0hiwpNStYpVfdftGa3TFhac8TFs JRd89GpwCJ9IuGbODabuT6vmXcLzzbMEezwi/rkIntAI5H0Od4FMSQaS9JrGKysJKu1J Fhag== MIME-Version: 1.0 Received: by 10.152.103.12 with SMTP id fs12mr4842012lab.47.1332403046410; Thu, 22 Mar 2012 00:57:26 -0700 (PDT) Received: by 10.152.112.234 with HTTP; Thu, 22 Mar 2012 00:57:26 -0700 (PDT) X-Originating-IP: [79.140.39.245] In-Reply-To: <4F6A48E7.1010006@gmail.com> References: <4F5A8023.1090705@gmail.com> <4F5AC7CF.3090409@gmail.com> <4F5C0C86.7040503@gmail.com> <4F5C24ED.3090601@gmail.com> <4F5CD920.2000905@gmail.com> <4F5D0876.5040409@gmail.com> <4F5D14E0.3050301@gmail.com> <20120312001625.4d9b3b52.ray@ddteam.net> <4F5E7D17.7000102@gmail.com> <4F5E9814.7010803@gmail.com> <4F5E9BA3.2000401@gmail.com> <20120313131415.36ecd761.ray@dlink.ua> <4F5FE891.7050306@gmail.com> <20120314200718.b6b51452.ray@ddteam.net> <4F651853.2050409@gmail.com> <4F6A48E7.1010006@gmail.com> Date: Thu, 22 Mar 2012 08:57:26 +0100 Message-ID: From: Bernhard Schmidt To: matt Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQkxBAmMuo/XvB+R7+BcSd2XhoZrV4nPW/+yr+8fu5MELe+cPOg3FPvPebmxpmOAjXllvxyq Cc: Aleksandr Rybalko , freebsd-wireless@freebsd.org Subject: Re: Please Test: Updated Ral Driver Patch for rt2860/rt3090 X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.5 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, 22 Mar 2012 07:57:34 -0000 On Wed, Mar 21, 2012 at 22:32, matt wrote: > On 03/21/12 00:54, Bernhard Schmidt wrote: >> On Wed, Mar 21, 2012 at 06:04, Adrian Chadd wrote: >>> Hi, >>> >>> How's the ralink driver tinkering going? >>> >>> How far out are we from committing something partially working to >>> -HEAD? What are the showstoppers? >> Lots of stuff, please let me go over at least the reg.h and var.h >> first. I'm only half way through the reg file yet. >> > Agreed...google code version needs some looking at before anything is > committed...There are/were some rough edges last chance I > got...unitialized warning for "val" in io_eeeprom_read and of course a > fine panic after attach. At least this time there was a debugger...I > can't find my firewire bracket. Yeah, guess I've broken that while changing some of the EEPROM related stuff. Afaik Aleksandr already fixed it though. > I'll hopefully get some time to keep messing around with it this weekend > and see if either Bernhard's work or careful line-by-line comparison > with mine can make it happy again. There were quite a few changes to the > eeprom side of things I saw (eeprom_ctl), which I think is bringing us > closer to OpenBSD compatibility, ie. same eeprom defines? Or just newer > code? Same define names, same functions and same semantic. It's just the beginning though, I'm not even half way through the reg file yet and there are still 2 others ;) -- Bernhard From owner-freebsd-wireless@FreeBSD.ORG Thu Mar 22 09:39:54 2012 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 405AE106566B for ; Thu, 22 Mar 2012 09:39:54 +0000 (UTC) (envelope-from venture37@gmail.com) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id AAE1A8FC0C for ; Thu, 22 Mar 2012 09:39:53 +0000 (UTC) Received: by bkcjc3 with SMTP id jc3so2131700bkc.13 for ; Thu, 22 Mar 2012 02:39:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=OTuwkKhZK9oZ2ichN+FJ9ApMY3WLeTY8isKVHbeXaho=; b=rwGBOXXBUVDBEQDsirO+Fr5NvgiBuWcaBT/3smfI9PBcWce8zAFRRHXDrdXitU2WnM +IzZd7RVKm5a6oJqiw3aDW1dFwTMMwPzvq1D2fBEdA5+mf4C+ZIZJlynAE2h37jiWT6K mf/shVw6+apfRwvHHWmOsOC8aunfROTOzu6l2uxYOKMbo+RESHf8YpkFXyJBl/Q0R/7z ZHzdXkInXY1hvMb+TjNJ2+vGUXzAwGElz66jwLb1Z1OI9HQpaWfb032Rt4o7bf6+UggV kCeOooOF8FuAA4pPYBE09vsZNYBSmNUD2hoXbDXEWPgkBJxigk1GCEKPGi0l9VdW/tz1 F2OQ== Received: by 10.205.137.15 with SMTP id im15mr2756184bkc.54.1332409192693; Thu, 22 Mar 2012 02:39:52 -0700 (PDT) Received: from Sevans-MacBook-Pro.local (cpc2-brig17-2-0-cust527.3-3.cable.virginmedia.com. [81.101.198.16]) by mx.google.com with ESMTPS id u14sm8602098bkp.2.2012.03.22.02.39.50 (version=SSLv3 cipher=OTHER); Thu, 22 Mar 2012 02:39:51 -0700 (PDT) Message-ID: <4F6AF363.309@gmail.com> Date: Thu, 22 Mar 2012 09:39:47 +0000 From: Sevan / Venture37 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: freebsd-wireless@freebsd.org References: <4F5A8023.1090705@gmail.com> <4F5AC7CF.3090409@gmail.com> <4F5C0C86.7040503@gmail.com> <4F5C24ED.3090601@gmail.com> <4F5CD920.2000905@gmail.com> <4F5D0876.5040409@gmail.com> <4F5D14E0.3050301@gmail.com> <20120312001625.4d9b3b52.ray@ddteam.net> <4F5E7D17.7000102@gmail.com> <4F5E9814.7010803@gmail.com> <4F5E9BA3.2000401@gmail.com> <20120313131415.36ecd761.ray@dlink.ua> <4F5FE891.7050306@gmail.com> <20120314200718.b6b51452.ray@ddteam.net> <4F651853.2050409@gmail.com> <4F6A48E7.1010006@gmail.com> In-Reply-To: <4F6A48E7.1010006@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: Please Test: Updated Ral Driver Patch for rt2860/rt3090 X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.5 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, 22 Mar 2012 09:39:54 -0000 On 21/03/2012 21:32, matt wrote: > Agreed...google code version needs some looking at before anything is > committed...There are/were some rough edges last chance I > got...unitialized warning for "val" in io_eeeprom_read and of course a > fine panic after attach. At least this time there was a debugger...I > can't find my firewire bracket. I built the code last night, driver attached fine & no crashes but scanning still yields nothing. Sevan From owner-freebsd-wireless@FreeBSD.ORG Thu Mar 22 20:44:33 2012 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 794DB1065670; Thu, 22 Mar 2012 20:44:33 +0000 (UTC) (envelope-from uzimac@da3m0n8t3r.com) Received: from z.umatar.com (z.umatar.com [66.135.39.87]) by mx1.freebsd.org (Postfix) with ESMTP id 42D828FC16; Thu, 22 Mar 2012 20:44:33 +0000 (UTC) Received: from z.umatar.com (localhost [127.0.0.1]) by z.umatar.com (8.14.5/8.14.3) with ESMTP id q2MKa5KU055325; Thu, 22 Mar 2012 13:36:05 -0700 (PDT) (envelope-from uzimac@da3m0n8t3r.com) Received: (from uzimac@localhost) by z.umatar.com (8.14.5/8.14.3/Submit) id q2MKa5xA055324; Thu, 22 Mar 2012 13:36:05 -0700 (PDT) (envelope-from uzimac@da3m0n8t3r.com) X-Authentication-Warning: z.umatar.com: uzimac set sender to uzimac@da3m0n8t3r.com using -f From: "Waitman Gobble" To: Adrian Chadd Message-Id: <1332448565.55318@da3m0n8t3r.com> X-Originating-IP: 70.90.171.37 X-Mailer: Usermin 1.500 In-Reply-To: Date: Thu, 22 Mar 2012 13:36:05 -0700 (PDT) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="bound1332448565" Cc: freebsd-wireless@freebsd.org Subject: Re: [net80211] PR kern/166286: force a channel change upon a HT info change X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.5 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, 22 Mar 2012 20:44:33 -0000 This is a multi-part message in MIME format. --bound1332448565 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Adrian Chadd wrote .. > .. and the patch. > > > Adrian cool, going to check this out. thanks. it seems i often have to do a manual scan, its just become part of routine. maybe this is the ticket. :) -- Waitman Gobble San Jose California USA --bound1332448565-- From owner-freebsd-wireless@FreeBSD.ORG Fri Mar 23 00:36:11 2012 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 08E641065678; Fri, 23 Mar 2012 00:36:11 +0000 (UTC) (envelope-from erichfreebsdlist@ovitrap.com) Received: from alogreentechnologies.com (alogreentechnologies.com [67.212.226.44]) by mx1.freebsd.org (Postfix) with ESMTP id DCC4F8FC14; Fri, 23 Mar 2012 00:36:06 +0000 (UTC) Received: from amd620.ovitrap.com ([49.128.188.2]) (authenticated bits=0) by alogreentechnologies.com (8.13.1/8.13.1) with ESMTP id q2MEkko3025906; Thu, 22 Mar 2012 08:46:49 -0600 From: Erich Dollansky To: Bernhard Schmidt Date: Thu, 22 Mar 2012 21:47:01 +0700 User-Agent: KMail/1.13.7 (FreeBSD/8.3-PRERELEASE; KDE/4.7.4; amd64; ; ) References: <201112171258.56891.erichfreebsdlist@ovitrap.com> <201203212014.37536.bschmidt@freebsd.org> In-Reply-To: <201203212014.37536.bschmidt@freebsd.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201203222147.01507.erichfreebsdlist@ovitrap.com> Cc: PseudoCylon , freebsd-wireless@freebsd.org Subject: Re: Zyxel NWD210N not accepted at boot time but after plugging it in again X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.5 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, 23 Mar 2012 00:36:11 -0000 Hi, I just downloaded the latest 8.3 sources but got the same old problems. Is there such a delay or did something go wrong again? I used a server in Austria. Erich On Thursday 22 March 2012 02:14:37 Bernhard Schmidt wrote: > On Sunday 18 December 2011 06:32:46 PseudoCylon wrote: > > On Sat, Dec 17, 2011 at 5:59 PM, Erich Dollansky > > wrote: > > > Hi, > > > > > > On Sunday 18 December 2011 06:45:18 PseudoCylon wrote: > > >> On Sat, Dec 17, 2011 at 6:11 AM, Bernhard Schmidt wrote: > > >> > On Saturday 17 December 2011 06:58:56 Erich Dollansky wrote: > > >> > > > >> > run(4) tries to load the firmware on attach at which point the root > > >> > filesystem isn't yet mounted. Actually I think the prefered behaviour > > >> > is to load it during init, not sure this is possible for run(4) > > >> > though. Someone should check this. :) > > >> > > > >> mmm... It seems "someone" is me. > > >> > > >> At the quick look, the firmware could be loaded during the init. Give > > >> me a few days, I will try to change. > > >> > > > if you need more information, just ask me. Please do not wonder if you do not get them at the spot. I am in a very remote location where electricity is cut off during the day. > > > > > Actually, it was quite straight forward. The patch follows. > > > > Also, a tarball is attached which include patch to man.4/run.4 and new > > firmware. I don't know what has been changed, but I'd appreciate if > > you try new firmware out. > > I committed the if_run.c and the new firmware a minute ago. Though, I > skipped the man page change for sake of consistency, currently it seems > most man pages have those instruction still included. But I agree, > strictly speaking it isn't necessary. > > Thank! > > -- > Bernhard > > From owner-freebsd-wireless@FreeBSD.ORG Fri Mar 23 03:37:39 2012 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 20B511065670 for ; Fri, 23 Mar 2012 03:37:39 +0000 (UTC) (envelope-from moonlightakkiy@yahoo.ca) Received: from nm17-vm1.bullet.mail.ne1.yahoo.com (nm17-vm1.bullet.mail.ne1.yahoo.com [98.138.91.34]) by mx1.freebsd.org (Postfix) with SMTP id C43E68FC12 for ; Fri, 23 Mar 2012 03:37:38 +0000 (UTC) Received: from [98.138.90.50] by nm17.bullet.mail.ne1.yahoo.com with NNFMP; 23 Mar 2012 03:31:26 -0000 Received: from [98.138.226.133] by tm3.bullet.mail.ne1.yahoo.com with NNFMP; 23 Mar 2012 03:31:26 -0000 Received: from [127.0.0.1] by smtp220.mail.ne1.yahoo.com with NNFMP; 23 Mar 2012 03:31:26 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.ca; s=s1024; t=1332473486; bh=iUwRftPp5lvaR8Jj/Rj1ap/je+iD/fSv53H4OkLc8BE=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:Received:MIME-Version:Received:Received:In-Reply-To:References:Date:Message-ID:Subject:From:To:Cc:Content-Type; b=Ai6z6npOJtlKW5SMASDBHn/B9d6qu8yZP1KDEdU52GEs5plBnKRICq/+Q42vfhyHdxP5QSKZzQjEgbcc2UAEfqtjTiixOos+LAe37CbIwQ9eWKvfZ9v1wX6emz70u/6Uqs+0jZfXLlgPJ75Ckn4MoWfz+G/1g1PSdl9RekXqv3s= X-Yahoo-Newman-Id: 531593.37456.bm@smtp220.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: 1JzUsQgVM1l0tOeRbiiTKNr8DpPBIMnx572lqvFhWG9ynX1 qu6G609EXiuggc0nj8oakFhmfAglsKPFfCdFn6OVU4hgKKOfoPvB3Xl8NFPf Djxm0qTkQ_x.SmnZ6ch0vHxTmuUxI7ybqPRDexQnmZU7tT4ucC2O_iv.zVsm PSlXF5UhYXxVQhFCCxZ3Zan7oqWktGMh.OC_7BSQ_PrE30EymSXPaJjJeU5H P9wGFnk9fAQhMQgayz.dNYEggN.DXVqt44bJ.x63Ce9cR2z0xamJ75fhXyC0 hZAz0ixgm5WJibBqelwmBQyvA3mX431N5cE60etJxeNDGOOiIEgJxg_7qZEZ CUPCqIuc9jJPpkvkafaq8gGEnVIGyYpu6sHnUtnw3xblajyxpoCSXjyzWC07 c89CvQARanRR5VafBWmXOT6rwUwqXPiRGjyXCCg-- X-Yahoo-SMTP: Xr6qjFWswBAEmd20sAvB4Q3keqXvXsIH9TjJ Received: from mail-iy0-f182.google.com (moonlightakkiy@209.85.210.182 with plain) by smtp220.mail.ne1.yahoo.com with SMTP; 22 Mar 2012 20:31:26 -0700 PDT Received: by iahk25 with SMTP id k25so5227226iah.13 for ; Thu, 22 Mar 2012 20:31:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.190.42 with SMTP id gn10mr25491441pbc.94.1332473482888; Thu, 22 Mar 2012 20:31:22 -0700 (PDT) Received: by 10.68.12.168 with HTTP; Thu, 22 Mar 2012 20:31:22 -0700 (PDT) In-Reply-To: <201203222147.01507.erichfreebsdlist@ovitrap.com> References: <201112171258.56891.erichfreebsdlist@ovitrap.com> <201203212014.37536.bschmidt@freebsd.org> <201203222147.01507.erichfreebsdlist@ovitrap.com> Date: Thu, 22 Mar 2012 21:31:22 -0600 Message-ID: From: PseudoCylon To: Erich Dollansky Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-wireless@freebsd.org, Bernhard Schmidt Subject: Re: Zyxel NWD210N not accepted at boot time but after plugging it in again X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.5 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, 23 Mar 2012 03:37:39 -0000 On Thu, Mar 22, 2012 at 8:47 AM, Erich Dollansky wrote: > Hi, > > I just downloaded the latest 8.3 sources but got the same old problems. > > Is there such a delay or did something go wrong again? > It has just been committed to HEAD, and it won't go into RELEASE branch until next release, 8.3-RELEASE-p1, maybe. Until then, you need to reapply the patch by yourself. AK > I used a server in Austria. > > Erich > > On Thursday 22 March 2012 02:14:37 Bernhard Schmidt wrote: >> On Sunday 18 December 2011 06:32:46 PseudoCylon wrote: >> > On Sat, Dec 17, 2011 at 5:59 PM, Erich Dollansky >> > wrote: >> > > Hi, >> > > >> > > On Sunday 18 December 2011 06:45:18 PseudoCylon wrote: >> > >> On Sat, Dec 17, 2011 at 6:11 AM, Bernhard Schmidt wrote: >> > >> > On Saturday 17 December 2011 06:58:56 Erich Dollansky wrote: >> > >> > >> > >> > run(4) tries to load the firmware on attach at which point the root >> > >> > filesystem isn't yet mounted. Actually I think the prefered behaviour >> > >> > is to load it during init, not sure this is possible for run(4) >> > >> > though. Someone should check this. :) >> > >> > >> > >> mmm... It seems "someone" is me. >> > >> >> > >> At the quick look, the firmware could be loaded during the init. Give >> > >> me a few days, I will try to change. >> > >> >> > > if you need more information, just ask me. Please do not wonder if you do not get them at the spot. I am in a very remote location where electricity is cut off during the day. >> > > >> > Actually, it was quite straight forward. The patch follows. >> > >> > Also, a tarball is attached which include patch to man.4/run.4 and new >> > firmware. I don't know what has been changed, but I'd appreciate if >> > you try new firmware out. >> >> I committed the if_run.c and the new firmware a minute ago. Though, I >> skipped the man page change for sake of consistency, currently it seems >> most man pages have those instruction still included. But I agree, >> strictly speaking it isn't necessary. >> >> Thank! >> >> -- >> Bernhard >> >> From owner-freebsd-wireless@FreeBSD.ORG Fri Mar 23 07:30:16 2012 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 54A91106566C; Fri, 23 Mar 2012 07:30:16 +0000 (UTC) (envelope-from erichfreebsdlist@ovitrap.com) Received: from alogreentechnologies.com (alogreentechnologies.com [67.212.226.44]) by mx1.freebsd.org (Postfix) with ESMTP id D67CF8FC17; Fri, 23 Mar 2012 07:30:14 +0000 (UTC) Received: from amd620.ovitrap.com ([49.128.188.2]) (authenticated bits=0) by alogreentechnologies.com (8.13.1/8.13.1) with ESMTP id q2N78bUL006973; Fri, 23 Mar 2012 01:08:40 -0600 From: Erich Dollansky To: PseudoCylon Date: Fri, 23 Mar 2012 14:08:54 +0700 User-Agent: KMail/1.13.7 (FreeBSD/8.3-PRERELEASE; KDE/4.7.4; amd64; ; ) References: <201112171258.56891.erichfreebsdlist@ovitrap.com> <201203222147.01507.erichfreebsdlist@ovitrap.com> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201203231408.55141.erichfreebsdlist@ovitrap.com> Cc: freebsd-wireless@freebsd.org, Bernhard Schmidt Subject: Re: Zyxel NWD210N not accepted at boot time but after plugging it in again X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.5 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, 23 Mar 2012 07:30:16 -0000 Hi, On Friday 23 March 2012 10:31:22 PseudoCylon wrote: > On Thu, Mar 22, 2012 at 8:47 AM, Erich Dollansky > wrote: > > Hi, > > > > I just downloaded the latest 8.3 sources but got the same old problems. > > > > Is there such a delay or did something go wrong again? > > > > It has just been committed to HEAD, and it won't go into RELEASE > branch until next release, 8.3-RELEASE-p1, maybe. > then it was a misunderstanding. I thought it was committed also to the current 8,3 for testing. > Until then, you need to reapply the patch by yourself. > This is obvious then. Thank you! Erich From owner-freebsd-wireless@FreeBSD.ORG Fri Mar 23 11:20:10 2012 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C7B081065670; Fri, 23 Mar 2012 11:20:10 +0000 (UTC) (envelope-from develloper.unix@hotmail.fr) Received: from blu0-omc2-s37.blu0.hotmail.com (blu0-omc2-s37.blu0.hotmail.com [65.55.111.112]) by mx1.freebsd.org (Postfix) with ESMTP id 82ADC8FC1E; Fri, 23 Mar 2012 11:20:10 +0000 (UTC) Received: from BLU0-SMTP415 ([65.55.111.71]) by blu0-omc2-s37.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 23 Mar 2012 04:20:04 -0700 X-Originating-IP: [163.5.191.15] X-Originating-Email: [develloper.unix@hotmail.fr] Message-ID: Received: from [10.15.190.198] ([163.5.191.15]) by BLU0-SMTP415.phx.gbl over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 23 Mar 2012 04:20:02 -0700 Date: Fri, 23 Mar 2012 12:19:46 +0100 From: Quentin Schwerkolt User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120314 Thunderbird/11.0 MIME-Version: 1.0 To: freebsd-stable@freebsd.org, freebsd-wireless@freebsd.org Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Mar 2012 11:20:02.0479 (UTC) FILETIME=[E40733F0:01CD08E6] Cc: Subject: Can't load many network kernel module in 8.3-PREREALEASE X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.5 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, 23 Mar 2012 11:20:10 -0000 Hi, I can't load many if_* module on FreeBSD 8.3-PRERELEASE on amd64 and i386. I have rebuild the system from the latest source. When I try a kldload /boot/kernel/if_*.ko I have error such as "file exist" or "exec format error". kldstat just after system start: Id Refs Address Size Name 1 1 0xffffffff80100000 e58280 kernel kldload -v /boot/kernel/if_*.ko: kldload: can't load /boot/kernel/if_ae.ko: File exists kldload: can't load /boot/kernel/if_age.ko: File exists kldload: can't load /boot/kernel/if_alc.ko: File exists kldload: can't load /boot/kernel/if_ale.ko: File exists kldload: can't load /boot/kernel/if_an.ko: File exists kldload: can't load /boot/kernel/if_ath.ko: Exec format error kldload: can't load /boot/kernel/if_aue.ko: Exec format error kldload: can't load /boot/kernel/if_axe.ko: Exec format error kldload: can't load /boot/kernel/if_bce.ko: File exists kldload: can't load /boot/kernel/if_bfe.ko: File exists kldload: can't load /boot/kernel/if_bge.ko: File exists kldload: can't load /boot/kernel/if_cdce.ko: Exec format error kldload: can't load /boot/kernel/if_cue.ko: Exec format error kldload: can't load /boot/kernel/if_dc.ko: File exists kldload: can't load /boot/kernel/if_de.ko: File exists kldload: can't load /boot/kernel/if_ed.ko: File exists kldload: can't load /boot/kernel/if_em.ko: File exists kldload: can't load /boot/kernel/if_en.ko: Exec format error kldload: can't load /boot/kernel/if_et.ko: File exists kldload: can't load /boot/kernel/if_faith.ko: Exec format error kldload: can't load /boot/kernel/if_fatm.ko: Exec format error kldload: can't load /boot/kernel/if_fwe.ko: Exec format error kldload: can't load /boot/kernel/if_fwip.ko: Exec format error kldload: can't load /boot/kernel/if_fxp.ko: File exists kldload: can't load /boot/kernel/if_gif.ko: Exec format error kldload: can't load /boot/kernel/if_hatm.ko: Exec format error kldload: can't load /boot/kernel/if_igb.ko: File exists kldload: can't load /boot/kernel/if_jme.ko: File exists kldload: can't load /boot/kernel/if_kue.ko: Exec format error kldload: can't load /boot/kernel/if_le.ko: File exists kldload: can't load /boot/kernel/if_lge.ko: File exists kldload: can't load /boot/kernel/if_msk.ko: File exists kldload: can't load /boot/kernel/if_nfe.ko: File exists kldload: can't load /boot/kernel/if_nge.ko: File exists kldload: can't load /boot/kernel/if_patm.ko: Exec format error kldload: can't load /boot/kernel/if_pcn.ko: File exists kldload: can't load /boot/kernel/if_ral.ko: File exists kldload: can't load /boot/kernel/if_re.ko: File exists kldload: can't load /boot/kernel/if_rl.ko: File exists kldload: can't load /boot/kernel/if_rue.ko: Exec format error kldload: can't load /boot/kernel/if_rum.ko: Exec format error kldload: can't load /boot/kernel/if_sf.ko: File exists kldload: can't load /boot/kernel/if_sge.ko: File exists kldload: can't load /boot/kernel/if_sis.ko: File exists kldload: can't load /boot/kernel/if_sk.ko: File exists kldload: can't load /boot/kernel/if_sn.ko: File exists kldload: can't load /boot/kernel/if_ste.ko: File exists kldload: can't load /boot/kernel/if_stge.ko: File exists kldload: can't load /boot/kernel/if_ti.ko: File exists kldload: can't load /boot/kernel/if_tl.ko: File exists kldload: can't load /boot/kernel/if_tun.ko: File exists kldload: can't load /boot/kernel/if_tx.ko: File exists kldload: can't load /boot/kernel/if_txp.ko: File exists kldload: can't load /boot/kernel/if_uath.ko: Exec format error kldload: can't load /boot/kernel/if_udav.ko: Exec format error kldload: can't load /boot/kernel/if_upgt.ko: Exec format error kldload: can't load /boot/kernel/if_ural.ko: Exec format error kldload: can't load /boot/kernel/if_vge.ko: File exists kldload: can't load /boot/kernel/if_vlan.ko: Exec format error kldload: can't load /boot/kernel/if_vr.ko: File exists kldload: can't load /boot/kernel/if_vx.ko: File exists kldload: can't load /boot/kernel/if_wb.ko: File exists kldload: can't load /boot/kernel/if_wi.ko: File exists kldload: can't load /boot/kernel/if_xl.ko: File exists kldload: can't load /boot/kernel/if_zyd.ko: Exec format error Loaded /boot/kernel/if_bridge.ko, id=2 Loaded /boot/kernel/if_bwi.ko, id=4 Loaded /boot/kernel/if_bwn.ko, id=5 Loaded /boot/kernel/if_carp.ko, id=7 Loaded /boot/kernel/if_cas.ko, id=8 Loaded /boot/kernel/if_cxgb.ko, id=9 Loaded /boot/kernel/if_cxgbe.ko, id=10 Loaded /boot/kernel/if_disc.ko, id=11 Loaded /boot/kernel/if_edsc.ko, id=12 Loaded /boot/kernel/if_ef.ko, id=13 Loaded /boot/kernel/if_epair.ko, id=15 Loaded /boot/kernel/if_gem.ko, id=17 Loaded /boot/kernel/if_gre.ko, id=18 Loaded /boot/kernel/if_hme.ko, id=19 Loaded /boot/kernel/if_ic.ko, id=20 Loaded /boot/kernel/if_ipheth.ko, id=22 Loaded /boot/kernel/if_ipw.ko, id=23 Loaded /boot/kernel/if_iwi.ko, id=24 Loaded /boot/kernel/if_iwn.ko, id=25 Loaded /boot/kernel/if_ixgb.ko, id=26 Loaded /boot/kernel/if_lagg.ko, id=27 Loaded /boot/kernel/if_lmc.ko, id=28 Loaded /boot/kernel/if_malo.ko, id=31 Loaded /boot/kernel/if_mwl.ko, id=32 Loaded /boot/kernel/if_mxge.ko, id=33 Loaded /boot/kernel/if_my.ko, id=35 Loaded /boot/kernel/if_ndis.ko, id=36 Loaded /boot/kernel/if_nve.ko, id=38 Loaded /boot/kernel/if_nxge.ko, id=39 Loaded /boot/kernel/if_run.ko, id=41 Loaded /boot/kernel/if_stf.ko, id=42 Loaded /boot/kernel/if_tap.ko, id=43 Loaded /boot/kernel/if_urtw.ko, id=44 Loaded /boot/kernel/if_vte.ko, id=45 Loaded /boot/kernel/if_wpi.ko, id=46 kldstat after run kldload: Id Refs Address Size Name 1 151 0xffffffff80100000 e58280 kernel 2 1 0xffffffff81012000 585a if_bridge.ko 3 1 0xffffffff81018000 3534 bridgestp.ko 4 1 0xffffffff8101c000 151d3 if_bwi.ko 5 1 0xffffffff81032000 298a5 if_bwn.ko 6 1 0xffffffff8105c000 61dc siba_bwn.ko 7 1 0xffffffff81063000 4d1a if_carp.ko 8 1 0xffffffff81068000 6fbb if_cas.ko 9 1 0xffffffff8106f000 2688f if_cxgb.ko 10 1 0xffffffff81096000 21f92 if_cxgbe.ko 11 1 0xffffffff810b8000 4e9 if_disc.ko 12 1 0xffffffff810b9000 56f if_edsc.ko 13 1 0xffffffff810ba000 a09 if_ef.ko 15 1 0xffffffff810bb000 17ae if_epair.ko 17 1 0xffffffff810bd000 5bdd if_gem.ko 18 1 0xffffffff810c3000 1d13 if_gre.ko 19 1 0xffffffff810c5000 4240 if_hme.ko 20 1 0xffffffff810ca000 c1a if_ic.ko 21 1 0xffffffff810cb000 12ff iicbus.ko 22 1 0xffffffff810cd000 10d8 if_ipheth.ko 23 1 0xffffffff810cf000 7104 if_ipw.ko 24 1 0xffffffff810d7000 93f5 if_iwi.ko 25 1 0xffffffff810e1000 10fef if_iwn.ko 26 1 0xffffffff810f2000 6ba7 if_ixgb.ko 27 1 0xffffffff810f9000 51d4 if_lagg.ko 28 1 0xffffffff810ff000 a73d if_lmc.ko 29 1 0xffffffff8110a000 c3a7 sppp.ko 30 1 0xffffffff81117000 8d32 netgraph.ko 31 1 0xffffffff81120000 7192 if_malo.ko 32 1 0xffffffff81128000 ee81 if_mwl.ko 33 1 0xffffffff81137000 b087 if_mxge.ko 34 1 0xffffffff81143000 a4d9 zlib.ko 35 1 0xffffffff8114e000 3a53 if_my.ko 36 1 0xffffffff81152000 7e13 if_ndis.ko 37 1 0xffffffff8115a000 143e2 ndis.ko 38 1 0xffffffff8116f000 b456 if_nve.ko 39 1 0xffffffff8117b000 23cd3 if_nxge.ko 41 1 0xffffffff8119f000 ba50 if_run.ko 42 1 0xffffffff811ab000 1305 if_stf.ko 43 1 0xffffffff811ad000 2655 if_tap.ko 44 1 0xffffffff811b0000 892c if_urtw.ko 45 1 0xffffffff811b9000 47fb if_vte.ko 46 1 0xffffffff811be000 8c55 if_wpi.ko Cordially Quentin SCHWERKOLT From owner-freebsd-wireless@FreeBSD.ORG Fri Mar 23 16:27:39 2012 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A89021065675 for ; Fri, 23 Mar 2012 16:27:39 +0000 (UTC) (envelope-from freebsd@damnhippie.dyndns.org) Received: from qmta15.emeryville.ca.mail.comcast.net (qmta15.emeryville.ca.mail.comcast.net [76.96.27.228]) by mx1.freebsd.org (Postfix) with ESMTP id 786E28FC1E for ; Fri, 23 Mar 2012 16:27:39 +0000 (UTC) Received: from omta18.emeryville.ca.mail.comcast.net ([76.96.30.74]) by qmta15.emeryville.ca.mail.comcast.net with comcast id p2CC1i0051bwxycAF4SZaK; Fri, 23 Mar 2012 16:26:33 +0000 Received: from damnhippie.dyndns.org ([24.8.232.202]) by omta18.emeryville.ca.mail.comcast.net with comcast id p4SY1i0024NgCEG8e4SYPc; Fri, 23 Mar 2012 16:26:33 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id q2NGQUKX033853; Fri, 23 Mar 2012 10:26:30 -0600 (MDT) (envelope-from freebsd@damnhippie.dyndns.org) From: Ian Lepore To: Quentin Schwerkolt In-Reply-To: References: Content-Type: text/plain; charset="us-ascii" Date: Fri, 23 Mar 2012 10:26:30 -0600 Message-ID: <1332519990.8403.93.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-wireless@freebsd.org, freebsd-stable@freebsd.org Subject: Re: Can't load many network kernel module in 8.3-PREREALEASE X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.5 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, 23 Mar 2012 16:27:39 -0000 On Fri, 2012-03-23 at 12:19 +0100, Quentin Schwerkolt wrote: > Hi, > > I can't load many if_* module on FreeBSD 8.3-PRERELEASE on amd64 and i386. > I have rebuild the system from the latest source. When I try a kldload > /boot/kernel/if_*.ko I have error such as "file exist" or "exec format > error". > > kldstat just after system start: > Id Refs Address Size Name > 1 1 0xffffffff80100000 e58280 kernel > > kldload -v /boot/kernel/if_*.ko: > kldload: can't load /boot/kernel/if_ae.ko: File exists > kldload: can't load /boot/kernel/if_age.ko: File exists > kldload: can't load /boot/kernel/if_alc.ko: File exists > kldload: can't load /boot/kernel/if_ale.ko: File exists > kldload: can't load /boot/kernel/if_an.ko: File exists > kldload: can't load /boot/kernel/if_ath.ko: Exec format error > kldload: can't load /boot/kernel/if_aue.ko: Exec format error > kldload: can't load /boot/kernel/if_axe.ko: Exec format error > kldload: can't load /boot/kernel/if_bce.ko: File exists > kldload: can't load /boot/kernel/if_bfe.ko: File exists > kldload: can't load /boot/kernel/if_bge.ko: File exists > kldload: can't load /boot/kernel/if_cdce.ko: Exec format error > kldload: can't load /boot/kernel/if_cue.ko: Exec format error > kldload: can't load /boot/kernel/if_dc.ko: File exists > kldload: can't load /boot/kernel/if_de.ko: File exists > kldload: can't load /boot/kernel/if_ed.ko: File exists > kldload: can't load /boot/kernel/if_em.ko: File exists > kldload: can't load /boot/kernel/if_en.ko: Exec format error > kldload: can't load /boot/kernel/if_et.ko: File exists > kldload: can't load /boot/kernel/if_faith.ko: Exec format error > kldload: can't load /boot/kernel/if_fatm.ko: Exec format error > kldload: can't load /boot/kernel/if_fwe.ko: Exec format error > kldload: can't load /boot/kernel/if_fwip.ko: Exec format error > kldload: can't load /boot/kernel/if_fxp.ko: File exists > kldload: can't load /boot/kernel/if_gif.ko: Exec format error > kldload: can't load /boot/kernel/if_hatm.ko: Exec format error > kldload: can't load /boot/kernel/if_igb.ko: File exists > kldload: can't load /boot/kernel/if_jme.ko: File exists > kldload: can't load /boot/kernel/if_kue.ko: Exec format error > kldload: can't load /boot/kernel/if_le.ko: File exists > kldload: can't load /boot/kernel/if_lge.ko: File exists > kldload: can't load /boot/kernel/if_msk.ko: File exists > kldload: can't load /boot/kernel/if_nfe.ko: File exists > kldload: can't load /boot/kernel/if_nge.ko: File exists > kldload: can't load /boot/kernel/if_patm.ko: Exec format error > kldload: can't load /boot/kernel/if_pcn.ko: File exists > kldload: can't load /boot/kernel/if_ral.ko: File exists > kldload: can't load /boot/kernel/if_re.ko: File exists > kldload: can't load /boot/kernel/if_rl.ko: File exists > kldload: can't load /boot/kernel/if_rue.ko: Exec format error > kldload: can't load /boot/kernel/if_rum.ko: Exec format error > kldload: can't load /boot/kernel/if_sf.ko: File exists > kldload: can't load /boot/kernel/if_sge.ko: File exists > kldload: can't load /boot/kernel/if_sis.ko: File exists > kldload: can't load /boot/kernel/if_sk.ko: File exists > kldload: can't load /boot/kernel/if_sn.ko: File exists > kldload: can't load /boot/kernel/if_ste.ko: File exists > kldload: can't load /boot/kernel/if_stge.ko: File exists > kldload: can't load /boot/kernel/if_ti.ko: File exists > kldload: can't load /boot/kernel/if_tl.ko: File exists > kldload: can't load /boot/kernel/if_tun.ko: File exists > kldload: can't load /boot/kernel/if_tx.ko: File exists > kldload: can't load /boot/kernel/if_txp.ko: File exists > kldload: can't load /boot/kernel/if_uath.ko: Exec format error > kldload: can't load /boot/kernel/if_udav.ko: Exec format error > kldload: can't load /boot/kernel/if_upgt.ko: Exec format error > kldload: can't load /boot/kernel/if_ural.ko: Exec format error > kldload: can't load /boot/kernel/if_vge.ko: File exists > kldload: can't load /boot/kernel/if_vlan.ko: Exec format error > kldload: can't load /boot/kernel/if_vr.ko: File exists > kldload: can't load /boot/kernel/if_vx.ko: File exists > kldload: can't load /boot/kernel/if_wb.ko: File exists > kldload: can't load /boot/kernel/if_wi.ko: File exists > kldload: can't load /boot/kernel/if_xl.ko: File exists > kldload: can't load /boot/kernel/if_zyd.ko: Exec format error > Loaded /boot/kernel/if_bridge.ko, id=2 > Loaded /boot/kernel/if_bwi.ko, id=4 > Loaded /boot/kernel/if_bwn.ko, id=5 > Loaded /boot/kernel/if_carp.ko, id=7 > Loaded /boot/kernel/if_cas.ko, id=8 > Loaded /boot/kernel/if_cxgb.ko, id=9 > Loaded /boot/kernel/if_cxgbe.ko, id=10 > Loaded /boot/kernel/if_disc.ko, id=11 > Loaded /boot/kernel/if_edsc.ko, id=12 > Loaded /boot/kernel/if_ef.ko, id=13 > Loaded /boot/kernel/if_epair.ko, id=15 > Loaded /boot/kernel/if_gem.ko, id=17 > Loaded /boot/kernel/if_gre.ko, id=18 > Loaded /boot/kernel/if_hme.ko, id=19 > Loaded /boot/kernel/if_ic.ko, id=20 > Loaded /boot/kernel/if_ipheth.ko, id=22 > Loaded /boot/kernel/if_ipw.ko, id=23 > Loaded /boot/kernel/if_iwi.ko, id=24 > Loaded /boot/kernel/if_iwn.ko, id=25 > Loaded /boot/kernel/if_ixgb.ko, id=26 > Loaded /boot/kernel/if_lagg.ko, id=27 > Loaded /boot/kernel/if_lmc.ko, id=28 > Loaded /boot/kernel/if_malo.ko, id=31 > Loaded /boot/kernel/if_mwl.ko, id=32 > Loaded /boot/kernel/if_mxge.ko, id=33 > Loaded /boot/kernel/if_my.ko, id=35 > Loaded /boot/kernel/if_ndis.ko, id=36 > Loaded /boot/kernel/if_nve.ko, id=38 > Loaded /boot/kernel/if_nxge.ko, id=39 > Loaded /boot/kernel/if_run.ko, id=41 > Loaded /boot/kernel/if_stf.ko, id=42 > Loaded /boot/kernel/if_tap.ko, id=43 > Loaded /boot/kernel/if_urtw.ko, id=44 > Loaded /boot/kernel/if_vte.ko, id=45 > Loaded /boot/kernel/if_wpi.ko, id=46 > > kldstat after run kldload: > Id Refs Address Size Name > 1 151 0xffffffff80100000 e58280 kernel > 2 1 0xffffffff81012000 585a if_bridge.ko > 3 1 0xffffffff81018000 3534 bridgestp.ko > 4 1 0xffffffff8101c000 151d3 if_bwi.ko > 5 1 0xffffffff81032000 298a5 if_bwn.ko > 6 1 0xffffffff8105c000 61dc siba_bwn.ko > 7 1 0xffffffff81063000 4d1a if_carp.ko > 8 1 0xffffffff81068000 6fbb if_cas.ko > 9 1 0xffffffff8106f000 2688f if_cxgb.ko > 10 1 0xffffffff81096000 21f92 if_cxgbe.ko > 11 1 0xffffffff810b8000 4e9 if_disc.ko > 12 1 0xffffffff810b9000 56f if_edsc.ko > 13 1 0xffffffff810ba000 a09 if_ef.ko > 15 1 0xffffffff810bb000 17ae if_epair.ko > 17 1 0xffffffff810bd000 5bdd if_gem.ko > 18 1 0xffffffff810c3000 1d13 if_gre.ko > 19 1 0xffffffff810c5000 4240 if_hme.ko > 20 1 0xffffffff810ca000 c1a if_ic.ko > 21 1 0xffffffff810cb000 12ff iicbus.ko > 22 1 0xffffffff810cd000 10d8 if_ipheth.ko > 23 1 0xffffffff810cf000 7104 if_ipw.ko > 24 1 0xffffffff810d7000 93f5 if_iwi.ko > 25 1 0xffffffff810e1000 10fef if_iwn.ko > 26 1 0xffffffff810f2000 6ba7 if_ixgb.ko > 27 1 0xffffffff810f9000 51d4 if_lagg.ko > 28 1 0xffffffff810ff000 a73d if_lmc.ko > 29 1 0xffffffff8110a000 c3a7 sppp.ko > 30 1 0xffffffff81117000 8d32 netgraph.ko > 31 1 0xffffffff81120000 7192 if_malo.ko > 32 1 0xffffffff81128000 ee81 if_mwl.ko > 33 1 0xffffffff81137000 b087 if_mxge.ko > 34 1 0xffffffff81143000 a4d9 zlib.ko > 35 1 0xffffffff8114e000 3a53 if_my.ko > 36 1 0xffffffff81152000 7e13 if_ndis.ko > 37 1 0xffffffff8115a000 143e2 ndis.ko > 38 1 0xffffffff8116f000 b456 if_nve.ko > 39 1 0xffffffff8117b000 23cd3 if_nxge.ko > 41 1 0xffffffff8119f000 ba50 if_run.ko > 42 1 0xffffffff811ab000 1305 if_stf.ko > 43 1 0xffffffff811ad000 2655 if_tap.ko > 44 1 0xffffffff811b0000 892c if_urtw.ko > 45 1 0xffffffff811b9000 47fb if_vte.ko > 46 1 0xffffffff811be000 8c55 if_wpi.ko > > Cordially > > Quentin SCHWERKOLT If you use "kldstat -v" before the kldload commands, you'll probably find that all the modules that fail to load are already compiled into the kernel. kldstat shows compiled-in modules only if you add -v. -- Ian From owner-freebsd-wireless@FreeBSD.ORG Fri Mar 23 16:29:02 2012 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 41941106566B; Fri, 23 Mar 2012 16:29:02 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: from mail-wg0-f50.google.com (mail-wg0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id A12928FC0A; Fri, 23 Mar 2012 16:29:01 +0000 (UTC) Received: by wgbds12 with SMTP id ds12so2270082wgb.31 for ; Fri, 23 Mar 2012 09:28:54 -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=x0e6CvwVLqtY+Ezaim2bhavbf2NvjRbm8Owz/yy1sw0=; b=W2faE6Qh1KHwaN1699FQLBYhEyUbI8XRxIxsfT/4Yjbd4hZTv8f6DZnnb+wLYPZzg4 N9jUhu6dgQN2M3fFB4c6ydZYZvBOQxCC0lmqn7oUhHLb89J1P3f9Jy3DKdG6Dkj7rgHU 6foxrdjs6zNrGwx4unO4RAfkNSSUc6CwTFWSMJwMCzsKUBJ+gF8TLxWIGuT5Wu2aqh1Q bP5/ugPFTbCYGwDAqImht+B349kRnIwd4VnFbrjGnLa7D/mKlR8KQL8p9RIXqja3sB/3 Rt1DA/oGjm+xS3+R/rRi8wbCuEdGVQsAGPMGBgZSm3X741/rQAFAf0ZBw8TCVOSC2UsL 2l6Q== MIME-Version: 1.0 Received: by 10.180.104.137 with SMTP id ge9mr7864718wib.20.1332520134548; Fri, 23 Mar 2012 09:28:54 -0700 (PDT) Received: by 10.223.143.3 with HTTP; Fri, 23 Mar 2012 09:28:54 -0700 (PDT) In-Reply-To: References: Date: Fri, 23 Mar 2012 09:28:54 -0700 Message-ID: From: Kevin Oberman To: Quentin Schwerkolt Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-wireless@freebsd.org, freebsd-stable@freebsd.org Subject: Re: Can't load many network kernel module in 8.3-PREREALEASE X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.5 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, 23 Mar 2012 16:29:02 -0000 On Fri, Mar 23, 2012 at 4:19 AM, Quentin Schwerkolt wrote: > Hi, > > I can't load many if_* module on FreeBSD 8.3-PRERELEASE on amd64 and i386= . > I have rebuild the system from the latest source. When I try a kldload > /boot/kernel/if_*.ko I have error such as "file exist" or "exec format > error". > > kldstat just after system start: > Id Refs Address =A0 =A0 =A0 =A0 =A0 =A0Size =A0 =A0 Name > =A01 =A0 =A01 0xffffffff80100000 e58280 =A0 kernel > > kldload -v /boot/kernel/if_*.ko: > kldload: can't load /boot/kernel/if_ae.ko: File exists > kldload: can't load /boot/kernel/if_age.ko: File exists > kldload: can't load /boot/kernel/if_alc.ko: File exists > kldload: can't load /boot/kernel/if_ale.ko: File exists > kldload: can't load /boot/kernel/if_an.ko: File exists > kldload: can't load /boot/kernel/if_ath.ko: Exec format error > kldload: can't load /boot/kernel/if_aue.ko: Exec format error > kldload: can't load /boot/kernel/if_axe.ko: Exec format error GENERIC already has all of these drivers. Did you buidt a kernel with no network interfaces? If the kernel is built with the drivers, you can't load them as they already exist. (And you can't unload drivers built into the kernel, either.) --=20 R. Kevin Oberman, Network Engineer E-mail: kob6558@gmail.com From owner-freebsd-wireless@FreeBSD.ORG Fri Mar 23 17:07:42 2012 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 02853106566B for ; Fri, 23 Mar 2012 17:07:42 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-gy0-f182.google.com (mail-gy0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id B0E088FC16 for ; Fri, 23 Mar 2012 17:07:41 +0000 (UTC) Received: by ghrr20 with SMTP id r20so3570516ghr.13 for ; Fri, 23 Mar 2012 10:07:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=1zkmJ0sWMR7W3HNYqzoHCEADMBUjOi/j5FrVVeG/fgU=; b=US5TJxWF+TJ4IZVqPsgtWppBTtwmN/iSSflyfWYWvq8mSPVTMonJJ7p6pHNBqnxOhH BDzSDtV/PPSc12ji/1lwFX0NvKvT82uvQxRXfarH7mPoY5lSXzVBwLMhpwBgQgqvbmjp S5csYKhaeccyU4gTTL9z2i+HR+7HQ3Oj4R6TSQkA/SX9C6/wSdmEqRcp3KsnIrV6WugT gmb3v/wVuT6L4C3BOlMF1vT0O2jeRWC+XpaKkME2ZsxDRfUAAcGKEhqQtNxD+h0Xm7OD XQgjnlhIRL+Hsr45mURQ9C4p9FVw4Trfr2ukYJXAKjlrmT6Y2DQPDCLKjRvfBjMRUucp TNaQ== MIME-Version: 1.0 Received: by 10.68.234.195 with SMTP id ug3mr31523244pbc.4.1332522454385; Fri, 23 Mar 2012 10:07:34 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.143.33.5 with HTTP; Fri, 23 Mar 2012 10:07:34 -0700 (PDT) Date: Fri, 23 Mar 2012 10:07:34 -0700 X-Google-Sender-Auth: YxXJOhkfDfJTNZcuHIWry2SW_fg Message-ID: From: Adrian Chadd To: freebsd-wireless@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: ath5k-devel@lists.ath5k.org, ath9k-devel Subject: Request for help: gui toolkit creation for atheros PHY/MAC statistics X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.5 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, 23 Mar 2012 17:07:42 -0000 Hi all, I'd like some help in writing a GUI toolkit for recording, playing back and visualising some of the PHY/MAC statistics the Atheros NICs expose. What I can do: help with the MAC/PHY side of things, identify what initial things would be good to support and what would actually be useful. What I can't do: dedicate time to write a GUI. :-) What I'd like to see: something completely free/open source written so we can improve the foss wireless development process. (Why I'm doing this: I'm fed up staring at printf() debugging in ath9k/FreeBSD and it's hard to have others visualise what's going on ..) I'd like it to be in C++/QT (before you ask - if you can make python or ${OTHER_LANG} handle the sheer rates of wifi traffic, MAC counters and PHY errors, _live_, and on tablet/atom class hardware, then please by all means do so..) and I'd like it to be platform portable. That way it can be used as a visualisation tool on other platforms, even if it's unable to do live capture itself (think MacOSX/Windows.) I'm talking about peaking on upwards of 10,000 PHY events a second in a very noisy environment, as well as the potential for some frequency domain analysis of time series data. This is why I think C++ is a more suitable target language over anything scripting-y. If you're interested in this then please drop me a private line and we'll get this off the ground. Thanks, Adrian From owner-freebsd-wireless@FreeBSD.ORG Fri Mar 23 17:18:40 2012 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E6FAE106566B; Fri, 23 Mar 2012 17:18:40 +0000 (UTC) (envelope-from greearb@candelatech.com) Received: from ns3.lanforge.com (mail.candelatech.com [208.74.158.172]) by mx1.freebsd.org (Postfix) with ESMTP id BF32B8FC14; Fri, 23 Mar 2012 17:18:40 +0000 (UTC) Received: from [192.168.100.111] (firewall.candelatech.com [70.89.124.249]) (authenticated bits=0) by ns3.lanforge.com (8.14.2/8.14.2) with ESMTP id q2NHIYc2008650 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 23 Mar 2012 10:18:34 -0700 Message-ID: <4F6CB06A.6030102@candelatech.com> Date: Fri, 23 Mar 2012 10:18:34 -0700 From: Ben Greear Organization: Candela Technologies User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.1) Gecko/20120209 Thunderbird/10.0.1 MIME-Version: 1.0 To: Adrian Chadd References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-wireless@freebsd.org, ath9k-devel , ath5k-devel@venema.h4ckr.net Subject: Re: [ath9k-devel] Request for help: gui toolkit creation for atheros PHY/MAC statistics X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.5 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, 23 Mar 2012 17:18:41 -0000 On 03/23/2012 10:07 AM, Adrian Chadd wrote: > Hi all, > > I'd like some help in writing a GUI toolkit for recording, playing > back and visualising some of the PHY/MAC statistics the Atheros NICs > expose. > > What I can do: help with the MAC/PHY side of things, identify what > initial things would be good to support and what would actually be > useful. > What I can't do: dedicate time to write a GUI. :-) > What I'd like to see: something completely free/open source written so > we can improve the foss wireless development process. > (Why I'm doing this: I'm fed up staring at printf() debugging in > ath9k/FreeBSD and it's hard to have others visualise what's going on > ..) > > I'd like it to be in C++/QT (before you ask - if you can make python > or ${OTHER_LANG} handle the sheer rates of wifi traffic, MAC counters > and PHY errors, _live_, and on tablet/atom class hardware, then please > by all means do so..) and I'd like it to be platform portable. That > way it can be used as a visualisation tool on other platforms, even if > it's unable to do live capture itself (think MacOSX/Windows.) I wouldn't ask someone to do it and then tell them what language. Just suggest to them what it needs to do instead. The big question for me is: How do you propose to get the info out of the driver and up to user-space? Just in case it matters...while benchmarking my Linux ethtool patch to ath9k, I found it took around 35us to make the ethtool ioctl call to get the stats. This was on a dual-core Atom system. Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From owner-freebsd-wireless@FreeBSD.ORG Fri Mar 23 17:25:17 2012 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BE1061065676 for ; Fri, 23 Mar 2012 17:25:17 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-gy0-f182.google.com (mail-gy0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id 772908FC17 for ; Fri, 23 Mar 2012 17:25:17 +0000 (UTC) Received: by ghrr20 with SMTP id r20so3590092ghr.13 for ; Fri, 23 Mar 2012 10:25:16 -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 :content-transfer-encoding; bh=9mcbDnFafJssXRslMO0SmXZq1GpQr4EEPkl65s1KnIw=; b=shnTF6X7DGvPmNagZGu2gi9gnYxyQlj+6kEXJJX2o02XYf20KQPfIuodvOergq2BtE kWSLJoDK72hU7tTRYcJ1Nz7VdvL4PHr6aGs7j2hoD2OvNo++9/8aDsCR+V/iEmNEOnzN E3zFoqdhiV8Bfxz42SOAbVZyQmCUaKskEduEzNUmPZCzklzpVU/tqOIuatv4sxry56dF BUZSH/YEpvpe2NNq3Y3LPxesKwUtLPpC3RWrSDQJo+X21bmVAe7uXBSpDYStlqyWR/1b hppOEzgYP8wov+v30SeHy2KPqenP1M2PVkCipbRzIAs+1fDtTmVxQ4cqFpUfoDBEZvn4 lpJQ== MIME-Version: 1.0 Received: by 10.68.225.104 with SMTP id rj8mr30769352pbc.135.1332523516489; Fri, 23 Mar 2012 10:25:16 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.143.33.5 with HTTP; Fri, 23 Mar 2012 10:25:16 -0700 (PDT) In-Reply-To: <4F6CB06A.6030102@candelatech.com> References: <4F6CB06A.6030102@candelatech.com> Date: Fri, 23 Mar 2012 10:25:16 -0700 X-Google-Sender-Auth: TFwMI74PgogUTqpNIlv6gJ9CP2s Message-ID: From: Adrian Chadd To: Ben Greear Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-wireless@freebsd.org, ath9k-devel , ath5k-devel@venema.h4ckr.net Subject: Re: [ath9k-devel] Request for help: gui toolkit creation for atheros PHY/MAC statistics X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.5 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, 23 Mar 2012 17:25:17 -0000 On 23 March 2012 10:18, Ben Greear wrote: > I wouldn't ask someone to do it and then tell them what language. =A0Just > suggest > to them what it needs to do instead. I'm sorry if it came across as demanding. It's more that I've looked at how/where people tend to use these kinds of visualisation tools and they're not on quad-core i7 laptops. They're on little itty atom netbooks (or tablets these days, I guess) with comparitively limited CPU. I've also had people suggest C#. Which is fine, but as I'd like this to be totally open source, I don't want it to depend upon any closed source C# libraries or any microsoft only runtime bits. Same holds for any other language. The other thing is keeping multiple threads going so your UI doesn't become unresponsive when you're falling behind doing network/disk IO or math operations. Yes, I've written some GUI stuff, so I have a basic idea of what's going on. If someone wants to me prove me wrong by demonstrating it done in python or some other scripting language then fine. > The big question for me is: =A0How do you propose to get the info out > of the driver and up to user-space? I'll worry about that later. For FreeBSD, the PHY errors come out via radiotap, so it'll look like a BPF stream. > Just in case it matters...while benchmarking my Linux ethtool patch to > ath9k, > I found it took around 35us to make the ethtool ioctl call to get the > stats. =A0This was on a dual-core Atom system. Right, but you can fetch a whole lot of statistics each call. The ath/HAL ioctl API doesn't return a single stat on each invocation. It returns a whole swath of them. I'm not worried about extracting the data from the various flavours of wifi stacks we're working with in BSD/Linux. :-) Adrian From owner-freebsd-wireless@FreeBSD.ORG Fri Mar 23 21:14:40 2012 Return-Path: Delivered-To: freebsd-wireless@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D3FF81065670; Fri, 23 Mar 2012 21:14:40 +0000 (UTC) (envelope-from adrian@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id A69F98FC15; Fri, 23 Mar 2012 21:14:40 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q2NLEedU050866; Fri, 23 Mar 2012 21:14:40 GMT (envelope-from adrian@freefall.freebsd.org) Received: (from adrian@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q2NLEeLf050861; Fri, 23 Mar 2012 21:14:40 GMT (envelope-from adrian) Date: Fri, 23 Mar 2012 21:14:40 GMT Message-Id: <201203232114.q2NLEeLf050861@freefall.freebsd.org> To: adrian@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-wireless@FreeBSD.org From: adrian@FreeBSD.org Cc: Subject: Re: misc/166357: [ath] 802.11n TX stall when the first _AND_ last frame in the BAW is in the software queue X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.5 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, 23 Mar 2012 21:14:40 -0000 Synopsis: [ath] 802.11n TX stall when the first _AND_ last frame in the BAW is in the software queue Responsible-Changed-From-To: freebsd-bugs->freebsd-wireless Responsible-Changed-By: adrian Responsible-Changed-When: Fri Mar 23 21:14:27 UTC 2012 Responsible-Changed-Why: reassign to -wireless. http://www.freebsd.org/cgi/query-pr.cgi?pr=166357 From owner-freebsd-wireless@FreeBSD.ORG Fri Mar 23 21:59:45 2012 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B38A61065679; Fri, 23 Mar 2012 21:59:45 +0000 (UTC) (envelope-from develloper.unix@hotmail.fr) Received: from zimbra.averesystems.com (75-149-8-245-Pennsylvania.hfc.comcastbusiness.net [75.149.8.245]) by mx1.freebsd.org (Postfix) with ESMTP id 400748FC19; Fri, 23 Mar 2012 21:59:45 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zimbra.averesystems.com (Postfix) with ESMTP id 9996144601F; Fri, 23 Mar 2012 17:59:38 -0400 (EDT) X-Virus-Scanned: amavisd-new at averesystems.com Received: from zimbra.averesystems.com ([127.0.0.1]) by localhost (zimbra.averesystems.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9BY5gOlo5c-D; Fri, 23 Mar 2012 17:59:35 -0400 (EDT) Received: from hqrouter.arriad.com (vm.arriad.com [10.0.1.251]) by zimbra.averesystems.com (Postfix) with ESMTP id 80AE2446008; Fri, 23 Mar 2012 17:59:34 -0400 (EDT) X-Mailbox-Line: From owner-freebsd-stable@freebsd.org Fri Mar 23 12:17:40 2012 X-Original-To: aboyer@averesystems.com Delivered-To: aboyer@averesystems.com Received: from mx2.freebsd.org (mx2.freebsd.org [69.147.83.53]) by zimbra.averesystems.com (Postfix) with ESMTP id C9CFA20093 for ; Fri, 23 Mar 2012 12:17:39 -0400 (EDT) Received: from hub.freebsd.org (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id B77681A7588; Fri, 23 Mar 2012 16:16:20 +0000 (UTC) Received: from hub.freebsd.org (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id B33CB1065758; Fri, 23 Mar 2012 16:16:20 +0000 (UTC) (envelope-from owner-freebsd-stable@freebsd.org) Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C7B081065670; Fri, 23 Mar 2012 11:20:10 +0000 (UTC) (envelope-from develloper.unix@hotmail.fr) Received: from blu0-omc2-s37.blu0.hotmail.com (blu0-omc2-s37.blu0.hotmail.com [65.55.111.112]) by mx1.freebsd.org (Postfix) with ESMTP id 82ADC8FC1E; Fri, 23 Mar 2012 11:20:10 +0000 (UTC) Received: from BLU0-SMTP415 ([65.55.111.71]) by blu0-omc2-s37.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 23 Mar 2012 04:20:04 -0700 X-Originating-IP: [163.5.191.15] X-Originating-Email: [develloper.unix@hotmail.fr] Message-ID: Received: from [10.15.190.198] ([163.5.191.15]) by BLU0-SMTP415.phx.gbl over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 23 Mar 2012 04:20:02 -0700 Date: Fri, 23 Mar 2012 12:19:46 +0100 From: Quentin Schwerkolt User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120314 Thunderbird/11.0 MIME-Version: 1.0 To: freebsd-stable@freebsd.org, freebsd-wireless@freebsd.org Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Mar 2012 11:20:02.0479 (UTC) FILETIME=[E40733F0:01CD08E6] X-Mailman-Approved-At: Fri, 23 Mar 2012 16:16:15 +0000 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Sender: owner-freebsd-stable@freebsd.org Errors-To: owner-freebsd-stable@freebsd.org Cc: Subject: Can't load many network kernel module in 8.3-PREREALEASE X-BeenThere: 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: Fri, 23 Mar 2012 21:59:45 -0000 Hi, I can't load many if_* module on FreeBSD 8.3-PRERELEASE on amd64 and i386. I have rebuild the system from the latest source. When I try a kldload /boot/kernel/if_*.ko I have error such as "file exist" or "exec format error". kldstat just after system start: Id Refs Address Size Name 1 1 0xffffffff80100000 e58280 kernel kldload -v /boot/kernel/if_*.ko: kldload: can't load /boot/kernel/if_ae.ko: File exists kldload: can't load /boot/kernel/if_age.ko: File exists kldload: can't load /boot/kernel/if_alc.ko: File exists kldload: can't load /boot/kernel/if_ale.ko: File exists kldload: can't load /boot/kernel/if_an.ko: File exists kldload: can't load /boot/kernel/if_ath.ko: Exec format error kldload: can't load /boot/kernel/if_aue.ko: Exec format error kldload: can't load /boot/kernel/if_axe.ko: Exec format error kldload: can't load /boot/kernel/if_bce.ko: File exists kldload: can't load /boot/kernel/if_bfe.ko: File exists kldload: can't load /boot/kernel/if_bge.ko: File exists kldload: can't load /boot/kernel/if_cdce.ko: Exec format error kldload: can't load /boot/kernel/if_cue.ko: Exec format error kldload: can't load /boot/kernel/if_dc.ko: File exists kldload: can't load /boot/kernel/if_de.ko: File exists kldload: can't load /boot/kernel/if_ed.ko: File exists kldload: can't load /boot/kernel/if_em.ko: File exists kldload: can't load /boot/kernel/if_en.ko: Exec format error kldload: can't load /boot/kernel/if_et.ko: File exists kldload: can't load /boot/kernel/if_faith.ko: Exec format error kldload: can't load /boot/kernel/if_fatm.ko: Exec format error kldload: can't load /boot/kernel/if_fwe.ko: Exec format error kldload: can't load /boot/kernel/if_fwip.ko: Exec format error kldload: can't load /boot/kernel/if_fxp.ko: File exists kldload: can't load /boot/kernel/if_gif.ko: Exec format error kldload: can't load /boot/kernel/if_hatm.ko: Exec format error kldload: can't load /boot/kernel/if_igb.ko: File exists kldload: can't load /boot/kernel/if_jme.ko: File exists kldload: can't load /boot/kernel/if_kue.ko: Exec format error kldload: can't load /boot/kernel/if_le.ko: File exists kldload: can't load /boot/kernel/if_lge.ko: File exists kldload: can't load /boot/kernel/if_msk.ko: File exists kldload: can't load /boot/kernel/if_nfe.ko: File exists kldload: can't load /boot/kernel/if_nge.ko: File exists kldload: can't load /boot/kernel/if_patm.ko: Exec format error kldload: can't load /boot/kernel/if_pcn.ko: File exists kldload: can't load /boot/kernel/if_ral.ko: File exists kldload: can't load /boot/kernel/if_re.ko: File exists kldload: can't load /boot/kernel/if_rl.ko: File exists kldload: can't load /boot/kernel/if_rue.ko: Exec format error kldload: can't load /boot/kernel/if_rum.ko: Exec format error kldload: can't load /boot/kernel/if_sf.ko: File exists kldload: can't load /boot/kernel/if_sge.ko: File exists kldload: can't load /boot/kernel/if_sis.ko: File exists kldload: can't load /boot/kernel/if_sk.ko: File exists kldload: can't load /boot/kernel/if_sn.ko: File exists kldload: can't load /boot/kernel/if_ste.ko: File exists kldload: can't load /boot/kernel/if_stge.ko: File exists kldload: can't load /boot/kernel/if_ti.ko: File exists kldload: can't load /boot/kernel/if_tl.ko: File exists kldload: can't load /boot/kernel/if_tun.ko: File exists kldload: can't load /boot/kernel/if_tx.ko: File exists kldload: can't load /boot/kernel/if_txp.ko: File exists kldload: can't load /boot/kernel/if_uath.ko: Exec format error kldload: can't load /boot/kernel/if_udav.ko: Exec format error kldload: can't load /boot/kernel/if_upgt.ko: Exec format error kldload: can't load /boot/kernel/if_ural.ko: Exec format error kldload: can't load /boot/kernel/if_vge.ko: File exists kldload: can't load /boot/kernel/if_vlan.ko: Exec format error kldload: can't load /boot/kernel/if_vr.ko: File exists kldload: can't load /boot/kernel/if_vx.ko: File exists kldload: can't load /boot/kernel/if_wb.ko: File exists kldload: can't load /boot/kernel/if_wi.ko: File exists kldload: can't load /boot/kernel/if_xl.ko: File exists kldload: can't load /boot/kernel/if_zyd.ko: Exec format error Loaded /boot/kernel/if_bridge.ko, id=2 Loaded /boot/kernel/if_bwi.ko, id=4 Loaded /boot/kernel/if_bwn.ko, id=5 Loaded /boot/kernel/if_carp.ko, id=7 Loaded /boot/kernel/if_cas.ko, id=8 Loaded /boot/kernel/if_cxgb.ko, id=9 Loaded /boot/kernel/if_cxgbe.ko, id=10 Loaded /boot/kernel/if_disc.ko, id=11 Loaded /boot/kernel/if_edsc.ko, id=12 Loaded /boot/kernel/if_ef.ko, id=13 Loaded /boot/kernel/if_epair.ko, id=15 Loaded /boot/kernel/if_gem.ko, id=17 Loaded /boot/kernel/if_gre.ko, id=18 Loaded /boot/kernel/if_hme.ko, id=19 Loaded /boot/kernel/if_ic.ko, id=20 Loaded /boot/kernel/if_ipheth.ko, id=22 Loaded /boot/kernel/if_ipw.ko, id=23 Loaded /boot/kernel/if_iwi.ko, id=24 Loaded /boot/kernel/if_iwn.ko, id=25 Loaded /boot/kernel/if_ixgb.ko, id=26 Loaded /boot/kernel/if_lagg.ko, id=27 Loaded /boot/kernel/if_lmc.ko, id=28 Loaded /boot/kernel/if_malo.ko, id=31 Loaded /boot/kernel/if_mwl.ko, id=32 Loaded /boot/kernel/if_mxge.ko, id=33 Loaded /boot/kernel/if_my.ko, id=35 Loaded /boot/kernel/if_ndis.ko, id=36 Loaded /boot/kernel/if_nve.ko, id=38 Loaded /boot/kernel/if_nxge.ko, id=39 Loaded /boot/kernel/if_run.ko, id=41 Loaded /boot/kernel/if_stf.ko, id=42 Loaded /boot/kernel/if_tap.ko, id=43 Loaded /boot/kernel/if_urtw.ko, id=44 Loaded /boot/kernel/if_vte.ko, id=45 Loaded /boot/kernel/if_wpi.ko, id=46 kldstat after run kldload: Id Refs Address Size Name 1 151 0xffffffff80100000 e58280 kernel 2 1 0xffffffff81012000 585a if_bridge.ko 3 1 0xffffffff81018000 3534 bridgestp.ko 4 1 0xffffffff8101c000 151d3 if_bwi.ko 5 1 0xffffffff81032000 298a5 if_bwn.ko 6 1 0xffffffff8105c000 61dc siba_bwn.ko 7 1 0xffffffff81063000 4d1a if_carp.ko 8 1 0xffffffff81068000 6fbb if_cas.ko 9 1 0xffffffff8106f000 2688f if_cxgb.ko 10 1 0xffffffff81096000 21f92 if_cxgbe.ko 11 1 0xffffffff810b8000 4e9 if_disc.ko 12 1 0xffffffff810b9000 56f if_edsc.ko 13 1 0xffffffff810ba000 a09 if_ef.ko 15 1 0xffffffff810bb000 17ae if_epair.ko 17 1 0xffffffff810bd000 5bdd if_gem.ko 18 1 0xffffffff810c3000 1d13 if_gre.ko 19 1 0xffffffff810c5000 4240 if_hme.ko 20 1 0xffffffff810ca000 c1a if_ic.ko 21 1 0xffffffff810cb000 12ff iicbus.ko 22 1 0xffffffff810cd000 10d8 if_ipheth.ko 23 1 0xffffffff810cf000 7104 if_ipw.ko 24 1 0xffffffff810d7000 93f5 if_iwi.ko 25 1 0xffffffff810e1000 10fef if_iwn.ko 26 1 0xffffffff810f2000 6ba7 if_ixgb.ko 27 1 0xffffffff810f9000 51d4 if_lagg.ko 28 1 0xffffffff810ff000 a73d if_lmc.ko 29 1 0xffffffff8110a000 c3a7 sppp.ko 30 1 0xffffffff81117000 8d32 netgraph.ko 31 1 0xffffffff81120000 7192 if_malo.ko 32 1 0xffffffff81128000 ee81 if_mwl.ko 33 1 0xffffffff81137000 b087 if_mxge.ko 34 1 0xffffffff81143000 a4d9 zlib.ko 35 1 0xffffffff8114e000 3a53 if_my.ko 36 1 0xffffffff81152000 7e13 if_ndis.ko 37 1 0xffffffff8115a000 143e2 ndis.ko 38 1 0xffffffff8116f000 b456 if_nve.ko 39 1 0xffffffff8117b000 23cd3 if_nxge.ko 41 1 0xffffffff8119f000 ba50 if_run.ko 42 1 0xffffffff811ab000 1305 if_stf.ko 43 1 0xffffffff811ad000 2655 if_tap.ko 44 1 0xffffffff811b0000 892c if_urtw.ko 45 1 0xffffffff811b9000 47fb if_vte.ko 46 1 0xffffffff811be000 8c55 if_wpi.ko Cordially Quentin SCHWERKOLT _______________________________________________ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" From owner-freebsd-wireless@FreeBSD.ORG Sat Mar 24 04:46:24 2012 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E5841106564A; Sat, 24 Mar 2012 04:46:23 +0000 (UTC) (envelope-from qasimj@gmail.com) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 43A218FC17; Sat, 24 Mar 2012 04:46:22 +0000 (UTC) Received: by bkcjc3 with SMTP id jc3so4083638bkc.13 for ; Fri, 23 Mar 2012 21:46:22 -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=0cuwUa+L8lwddlaww60poHK5mK9DQCI1cukVglVE8tU=; b=PUjzmFYHlwza1V8F0NgUbDHmTGHDmVcuBs5nKVH3Vhsh4pyQLOryQ8UpHZtbezqPKd yYNHBWAMe/MiFPBa498l+P27cZDCZtxOS5JW3ZF7n+RlAKrNfSkulVi/ciF2+6rZkxis uCrcCnvRz31PuXBkDZdmeWh3ZARGcgTUITmDkIRnNif6Z0CnlB3ipmWx5PI1Y1EUmX4q e6/wqBDRqBDgyiX4c3942VTmBIKK9JQBPOHwhZJ3uK/FVtB2ThqkN3qRVSiqcrGzAZ7U CSh7nWoi0iVoQqtKOrvBwdFlTKnjS1RA6Sfak+xBQg4n3znwRHDTXRw2YiyhgT+lZk1T Q04A== MIME-Version: 1.0 Received: by 10.204.133.210 with SMTP id g18mr5435555bkt.107.1332564381962; Fri, 23 Mar 2012 21:46:21 -0700 (PDT) Received: by 10.204.38.4 with HTTP; Fri, 23 Mar 2012 21:46:21 -0700 (PDT) In-Reply-To: References: <4F6CB06A.6030102@candelatech.com> Date: Fri, 23 Mar 2012 23:46:21 -0500 Message-ID: From: Qasim Javed To: Adrian Chadd Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Ben Greear , freebsd-wireless@freebsd.org, ath9k-devel , ath5k-devel@venema.h4ckr.net Subject: Re: [ath5k-devel] [ath9k-devel] Request for help: gui toolkit creation for atheros PHY/MAC statistics X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.5 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, 24 Mar 2012 04:46:24 -0000 In addition to driver statistics, I was thinking that a tool like this should provide more insight like how many times the CPU is being interrupted by the Wifi card when it is offered a certain load. I was recently running into an issue with an XR9 card and interestingly I found using the "mpstat" tool that when the offered load goes beyond a certain threshold Mbps, the number of interrupts per second goes down! ath9k has a set of patches (compat wireless with "-pc" at the end of filename before the extension) that dump the TX/RX descriptors which contain rich information regarding the transmission and reception process. I had to write a custom script to process the binary dumps generated by those patches, but if the visualization tool can display that information it would be awesome. Those binary dumps contain almost all the information that could possibly be made available. -Qasim On Fri, Mar 23, 2012 at 12:25 PM, Adrian Chadd wrote: > On 23 March 2012 10:18, Ben Greear wrote: > >> I wouldn't ask someone to do it and then tell them what language. =A0Jus= t >> suggest >> to them what it needs to do instead. > > I'm sorry if it came across as demanding. It's more that I've looked > at how/where people tend to use these kinds of visualisation tools and > they're not on quad-core i7 laptops. They're on little itty atom > netbooks (or tablets these days, I guess) with comparitively limited > CPU. > > I've also had people suggest C#. Which is fine, but as I'd like this > to be totally open source, I don't want it to depend upon any closed > source C# libraries or any microsoft only runtime bits. Same holds for > any other language. > > The other thing is keeping multiple threads going so your UI doesn't > become unresponsive when you're falling behind doing network/disk IO > or math operations. > > Yes, I've written some GUI stuff, so I have a basic idea of what's > going on. If someone wants to me prove me wrong by demonstrating it > done in python or some other scripting language then fine. > >> The big question for me is: =A0How do you propose to get the info out >> of the driver and up to user-space? > > I'll worry about that later. For FreeBSD, the PHY errors come out via > radiotap, so it'll look like a BPF stream. > >> Just in case it matters...while benchmarking my Linux ethtool patch to >> ath9k, >> I found it took around 35us to make the ethtool ioctl call to get the >> stats. =A0This was on a dual-core Atom system. > > Right, but you can fetch a whole lot of statistics each call. The > ath/HAL ioctl API doesn't return a single stat on each invocation. It > returns a whole swath of them. > > I'm not worried about extracting the data from the various flavours of > wifi stacks we're working with in BSD/Linux. :-) > > > Adrian > _______________________________________________ > ath5k-devel mailing list > ath5k-devel@lists.ath5k.org > https://lists.ath5k.org/mailman/listinfo/ath5k-devel From owner-freebsd-wireless@FreeBSD.ORG Sat Mar 24 17:47:55 2012 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5E5071065670; Sat, 24 Mar 2012 17:47:55 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [115.70.110.159]) by mx1.freebsd.org (Postfix) with ESMTP id CACD98FC16; Sat, 24 Mar 2012 17:47:54 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id q2OHlLSU049001; Sun, 25 Mar 2012 04:47:21 +1100 (EST) (envelope-from smithi@nimnet.asn.au) Date: Sun, 25 Mar 2012 04:47:21 +1100 (EST) From: Ian Smith To: Quentin Schwerkolt In-Reply-To: Message-ID: <20120325042722.S2060@sola.nimnet.asn.au> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: freebsd-wireless@freebsd.org, freebsd-stable@freebsd.org Subject: Re: Can't load many network kernel module in 8.3-PREREALEASE X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.5 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, 24 Mar 2012 17:47:55 -0000 On Fri, 23 Mar 2012, Quentin Schwerkolt wrote: > I can't load many if_* module on FreeBSD 8.3-PRERELEASE on amd64 and i386. > I have rebuild the system from the latest source. When I try a kldload > /boot/kernel/if_*.ko I have error such as "file exist" or "exec format > error". I have no idea why you'd want to do that :) but you'll find that all the 'File exist' ones were already included in your kernel. > kldstat just after system start: > Id Refs Address Size Name > 1 1 0xffffffff80100000 e58280 kernel 'kldstat -v' will show all modules included in your (GENERIC?) kernel. > kldload -v /boot/kernel/if_*.ko: > kldload: can't load /boot/kernel/if_ae.ko: File exists > kldload: can't load /boot/kernel/if_age.ko: File exists > kldload: can't load /boot/kernel/if_alc.ko: File exists > kldload: can't load /boot/kernel/if_ale.ko: File exists > kldload: can't load /boot/kernel/if_an.ko: File exists > kldload: can't load /boot/kernel/if_ath.ko: Exec format error > kldload: can't load /boot/kernel/if_aue.ko: Exec format error > kldload: can't load /boot/kernel/if_axe.ko: Exec format error I'm not certain about the 'Exec format error' messages. Then below are listed the modules loaded that weren't in your kernel. > Loaded /boot/kernel/if_bridge.ko, id=2 > Loaded /boot/kernel/if_bwi.ko, id=4 [..] > Loaded /boot/kernel/if_vte.ko, id=45 > Loaded /boot/kernel/if_wpi.ko, id=46 > > kldstat after run kldload: > Id Refs Address Size Name > 1 151 0xffffffff80100000 e58280 kernel > 2 1 0xffffffff81012000 585a if_bridge.ko > 3 1 0xffffffff81018000 3534 bridgestp.ko > 4 1 0xffffffff8101c000 151d3 if_bwi.ko [..] Now showing all modules that were loaded in addition to those in kernel. Again, 'kldstat -v' will show all of them, with details of loaded ones. cheers, Ian