From owner-freebsd-wireless@FreeBSD.ORG Sun Apr 15 16:31: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 67D95106566B; Sun, 15 Apr 2012 16:31:43 +0000 (UTC) (envelope-from venture37@gmail.com) Received: from mail-ee0-f54.google.com (mail-ee0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id BAE9B8FC12; Sun, 15 Apr 2012 16:31:42 +0000 (UTC) Received: by eekd17 with SMTP id d17so1221428eek.13 for ; Sun, 15 Apr 2012 09:31:41 -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:content-type:content-transfer-encoding; bh=nvYnaMkUzyO0WzrlYRXeLqRaZN0+jPvuJ3VPJUGEqnY=; b=cSZxQt0moYgXZ/n3qiURCtPxF5xAhmiVo5ay1lk5qNX+Etp4dheKAA1XeBC9qgFJog AZkCDzpFneq4g25GjCUgcSEaW2bq5QtRxNl1a6GIbsKHjfRs90JPfYrAJeY2YXHrongi uzFxZd4R2rDMCF0GFlho9dSmeFmbXgmSymdGTDMbKKAZPhmDVKFBAhIQcyHK0WXdKG1m yPJ8o7zf8HTPt2k2KGpZEIlKB9dOurBtFSuvbKLYiZ3WiyjYX6pKoUt1j/5SMKnGq7dc x2IylBkBJTpEXcg3hXcHKPOG93Ote0ZOdU+CT/tjs1JzHQqSJIdXGtEyPPxZ/YiF6Mg6 zkcg== Received: by 10.14.119.72 with SMTP id m48mr1153641eeh.72.1334507501574; Sun, 15 Apr 2012 09:31:41 -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 x4sm74151708eef.10.2012.04.15.09.31.38 (version=SSLv3 cipher=OTHER); Sun, 15 Apr 2012 09:31:39 -0700 (PDT) Message-ID: <4F8AF7E9.20706@gmail.com> Date: Sun, 15 Apr 2012 17:31:37 +0100 From: Sevan / Venture37 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Adrian Chadd References: <4F86FB15.5080500@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-wireless@freebsd.org Subject: Re: ath(4) hardware support list 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, 15 Apr 2012 16:31:43 -0000 On 12/04/2012 16:58, Adrian Chadd wrote: > .. upstream? What upstream? I assumed as the file was sourced from NetBSD based on license that it was also the authoritative source which we fetched from, I didn't think it was just the originating source :) http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/usb/usbdevs?rev=1.518.2.9;content-type=text%2Fplain Sevan From owner-freebsd-wireless@FreeBSD.ORG Sun Apr 15 16:46: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 593C7106566C for ; Sun, 15 Apr 2012 16:46:23 +0000 (UTC) (envelope-from bschmidt@techwires.net) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id D79AF8FC0C for ; Sun, 15 Apr 2012 16:46:22 +0000 (UTC) Received: by wern13 with SMTP id n13so3824637wer.13 for ; Sun, 15 Apr 2012 09:46: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=t9omL+FiBuYxmIFwksNihzIyba87Lrmvqf+HKNuo1uA=; b=DIY6m7yMV7qIfwuKbvWDSeejntwliAMuP+PffaHEw3h30a2SoeFTadM4fwaP5m0/Mb WL7saNQyxR0sCbMyvyP3qddNzJKStzguB3RqZecTXSdMCi8rVsKqt0JEoNn/nQHDZJeZ tHSx/MVMDZJnT4BJwS5WVaauKfi541X0i0QIDnbrvtzwb9pXR5ISIE73ePM6RF8i8hpi tkvmf4wiB4+ROSLiL3qvxgNS56lTu+0e8eht6aCQ5PvENBycqQHZ+Zose8QnReuqD31t mw8zvf45wYoNyLCPgD1yTpCYaQUbQi3LeC9Zf5T7ogFWOhBwka51hH9Jfl6htjWeOhts yCtw== Received: by 10.180.95.34 with SMTP id dh2mr11714453wib.15.1334508381831; Sun, 15 Apr 2012 09:46:21 -0700 (PDT) Received: from amy.lab.techwires.net (dslb-088-065-218-041.pools.arcor-ip.net. [88.65.218.41]) by mx.google.com with ESMTPS id l5sm13360831wia.11.2012.04.15.09.46.20 (version=SSLv3 cipher=OTHER); Sun, 15 Apr 2012 09:46:21 -0700 (PDT) Sender: Bernhard Schmidt From: Bernhard Schmidt To: freebsd-wireless@freebsd.org Date: Sun, 15 Apr 2012 18:46:40 +0200 User-Agent: KMail/1.13.7 (FreeBSD/9.0-STABLE; KDE/4.7.4; amd64; ; ) References: <4F8AF7E9.20706@gmail.com> In-Reply-To: <4F8AF7E9.20706@gmail.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201204151846.41050.bschmidt@freebsd.org> X-Gm-Message-State: ALoCoQlS7S/tqf8AXlb1o6QOtprRcDAnJFPkzijRgXC4wq0jDeVQJLWfiGKbJt0df/7JKxm7+zQB Cc: Subject: Re: ath(4) hardware support list 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, 15 Apr 2012 16:46:23 -0000 On Sunday 15 April 2012 18:31:37 Sevan / Venture37 wrote: > On 12/04/2012 16:58, Adrian Chadd wrote: > > .. upstream? What upstream? > > I assumed as the file was sourced from NetBSD based on license that it > was also the authoritative source which we fetched from, I didn't think > it was just the originating source :) > > http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/usb/usbdevs?rev=1.518.2.9;content-type=text%2Fplain The file was indeed initally imported from NetBSD. Changes can be and are applied directly though. http://svnweb.freebsd.org/base/head/sys/dev/usb/usbdevs?view=log -- Bernhard From owner-freebsd-wireless@FreeBSD.ORG Mon Apr 16 11:07: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 D56E81065680 for ; Mon, 16 Apr 2012 11:07:31 +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 C00E08FC2C for ; Mon, 16 Apr 2012 11:07:31 +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 q3GB7VrE022577 for ; Mon, 16 Apr 2012 11:07:31 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q3GB7VVv022573 for freebsd-wireless@FreeBSD.org; Mon, 16 Apr 2012 11:07:31 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 16 Apr 2012 11:07:31 GMT Message-Id: <201204161107.q3GB7VVv022573@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, 16 Apr 2012 11:07:31 -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/166684 wireless [ath] [net80211] mgmtrate/mcastrate isn't updated base p kern/166642 wireless [ieee80211] [patch] in 802.11n mode for FreeBSD AP, ha o kern/166641 wireless [ieee80211] [patch] mbuf/cluster leak in AP mode in 80 p kern/166357 wireless [ath] 802.11n TX stall when the first frame in the BAW o kern/166286 wireless [net80211] [ath] initial switch to HT40 isn't causing p kern/166190 wireless [ath] TX hangs and frames stuck in TX queue o kern/166086 wireless [Patch][ath] Reflect state of rfkill switch in a sysct o kern/165969 wireless [ath] Slower performance in adhoc mode vs Client/AP mo o kern/165966 wireless [ath] ath0: device timeout on SMP machines due to race o kern/165895 wireless [ath] overly busy cabq can tie up all tx buffers o kern/165870 wireless [bwn] bwn driver does not attach on HP Pavilion dv9420 o kern/165866 wireless [ath] TX hangs, requiring a "scan" to properly reset t o kern/165849 wireless [ath] [hang] network ath driver freeze o kern/165595 wireless [ipw] ipw(4): Can't load firmare for ipw2200bg o kern/165543 wireless [ath] ath0 endless scanning of channels without connec o kern/165517 wireless [net80211] bgscan isn't triggered when invalid beacons o kern/165475 wireless [ath] operational mode change doesn't poke the underly o kern/165382 wireless [kernel] taskqueue_unblock doesn't unblock currently q o kern/165306 wireless [ath] race conditions between scanning and beacon time o kern/165220 wireless [ath] "ath_rx_tasklet: sc_inreset_cnt > 0; skipping" m o kern/165214 wireless [ieee80211] Kernel panic in ieee80211_output.c:2505 o kern/165212 wireless [ath] No WiFi on Acer Aspire One 751h (Atheros AR5BHB6 o kern/165149 wireless [ath] [net80211] Ping with data length more than iv_fr o kern/165146 wireless [net80211] Net802.11 Fragment number is assigned 1 (sh o kern/165060 wireless [ath] vap->iv_bss race conditions causing crashes insi o kern/165021 wireless [ath] ath device timeout during scan/attach, if wlan_c o kern/164951 wireless [ath] [patch] Problem build of if_ath driver with cert 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 96 problems total. From owner-freebsd-wireless@FreeBSD.ORG Tue Apr 17 06:45:19 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 E27D2106564A for ; Tue, 17 Apr 2012 06:45:18 +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 B1F528FC0C for ; Tue, 17 Apr 2012 06:45:18 +0000 (UTC) Received: by dadz14 with SMTP id z14so26519327dad.17 for ; Mon, 16 Apr 2012 23:45:18 -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=aLCwVgnpx7fTLScwyaATSqUsXMwGERk+CEbnaQBdeHA=; b=klJY8clMx8apYaC4wdmv6hODLlKiTmayC5idpEuEJUFZ7RdLhTscFUbZMvwWmfKSMx p2+6D+IOTqpgIQvFie4wfYOZKqt+/fsS5/NCcZT5f8LSvXiNHIpP3l8RXOFoUZRV2gri KYoj41Vzi9dPB9i3IKBo6aBv/XLzOd1K/kRWKKiBJb3lNlfWibe6KISmpco/bOlbNg+T U1sUlTQR209HcEj0bF9aQdIe7wq0xXs8+C9Ikctp6J3oU/vhaGmJFHFxDOskhnF2kV2F aT7SJEtmj80NGVG2Wu6FGtLxUk2xOi8t2k9adrLj77nHs7KDP5Wh1nn+OLEAdeOQyxwK RnlQ== MIME-Version: 1.0 Received: by 10.68.225.132 with SMTP id rk4mr32807681pbc.157.1334645118276; Mon, 16 Apr 2012 23:45:18 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.142.101.9 with HTTP; Mon, 16 Apr 2012 23:45:17 -0700 (PDT) Date: Mon, 16 Apr 2012 23:45:17 -0700 X-Google-Sender-Auth: -bi6iQqZ6KATLdQqUgHs08aSUBg Message-ID: From: Adrian Chadd To: freebsd-wireless@freebsd.org Content-Type: multipart/mixed; boundary=047d7b2e07392d151504bdda4866 Subject: [patch] ifconfig: fix rate printing 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, 17 Apr 2012 06:45:19 -0000 --047d7b2e07392d151504bdda4866 Content-Type: text/plain; charset=ISO-8859-1 Hi, This patch should fix the rate print logic in ifconfig. Thanks, Adrian --047d7b2e07392d151504bdda4866 Content-Type: application/octet-stream; name="ifconfig-fix-rateprint.diff" Content-Disposition: attachment; filename="ifconfig-fix-rateprint.diff" Content-Transfer-Encoding: base64 X-Attachment-Id: f_h14lahj30 SW5kZXg6IHNiaW4vaWZjb25maWcvaWZpZWVlODAyMTEuYwo9PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBzYmluL2lm Y29uZmlnL2lmaWVlZTgwMjExLmMJKHJldmlzaW9uIDIzNDAxOSkKKysrIHNiaW4vaWZjb25maWcv aWZpZWVlODAyMTEuYwkod29ya2luZyBjb3B5KQpAQCAtMzgwOCw2ICszODA4LDI1IEBACiAJfQog fQogCisvKiBYWFggd291bGQgdGhlc2UgYmUgZ29vZCB0byBoYXZlIGluIGEgbGlicmFyeT8gKi8K K3N0YXRpYyBjb25zdCBjaGFyICoKK3JhdGUyc3RyKGludCByYXRlKQoreworCWlmIChyYXRlICYg SUVFRTgwMjExX1JBVEVfTUNTKQorCQlyZXR1cm4gKCJNQ1MgIik7CisJZWxzZQorCQlyZXR1cm4g KCJNYi9zIik7Cit9CisKK3N0YXRpYyBpbnQKK3JhdGUyc3BlZWQoaW50IHJhdGUpCit7CisJaWYg KElFRUU4MDIxMV9SQVRFX01DUykKKwkJcmV0dXJuIChyYXRlICZ+IElFRUU4MDIxMV9SQVRFX01D Uyk7CisJZWxzZQorCQlyZXR1cm4gKHJhdGUgLyAyKTsKK30KKwogc3RhdGljIHZvaWQKIGxpc3Rf dHhwYXJhbXMoaW50IHMpCiB7CkBAIC0zODE5LDM2ICszODM4LDIxIEBACiAJCXRwID0gJnR4cGFy YW1zLnBhcmFtc1ttb2RlXTsKIAkJaWYgKHRwLT5tZ210cmF0ZSA9PSAwICYmIHRwLT5tY2FzdHJh dGUgPT0gMCkKIAkJCWNvbnRpbnVlOwotCQlpZiAobW9kZSA9PSBJRUVFODAyMTFfTU9ERV8xMU5B IHx8IG1vZGUgPT0gSUVFRTgwMjExX01PREVfMTFORykgewotCQkJaWYgKHRwLT51Y2FzdHJhdGUg PT0gSUVFRTgwMjExX0ZJWEVEX1JBVEVfTk9ORSkKLQkJCQlMSU5FX0NIRUNLKCIlLTcuN3MgdWNh c3QgTk9ORSAgICBtZ210ICUydSBNQ1MgICIKLQkJCQkgICAgIm1jYXN0ICUydSBNQ1MgIG1heHJl dHJ5ICV1IiwKLQkJCQkgICAgbW9kZW5hbWVbbW9kZV0sCi0JCQkJICAgIHRwLT5tZ210cmF0ZSAm fiBJRUVFODAyMTFfUkFURV9NQ1MsCi0JCQkJICAgIHRwLT5tY2FzdHJhdGUgJn4gSUVFRTgwMjEx X1JBVEVfTUNTLAotCQkJCSAgICB0cC0+bWF4cmV0cnkpOwotCQkJZWxzZQotCQkJCUxJTkVfQ0hF Q0soIiUtNy43cyB1Y2FzdCAlMnUgTUNTICBtZ210ICUydSBNQ1MgICIKLQkJCQkgICAgIm1jYXN0 ICUydSBNQ1MgIG1heHJldHJ5ICV1IiwKLQkJCQkgICAgbW9kZW5hbWVbbW9kZV0sCi0JCQkJICAg IHRwLT51Y2FzdHJhdGUgJn4gSUVFRTgwMjExX1JBVEVfTUNTLAotCQkJCSAgICB0cC0+bWdtdHJh dGUgJn4gSUVFRTgwMjExX1JBVEVfTUNTLAotCQkJCSAgICB0cC0+bWNhc3RyYXRlICZ+IElFRUU4 MDIxMV9SQVRFX01DUywKLQkJCQkgICAgdHAtPm1heHJldHJ5KTsKLQkJfSBlbHNlIHsKLQkJCWlm ICh0cC0+dWNhc3RyYXRlID09IElFRUU4MDIxMV9GSVhFRF9SQVRFX05PTkUpCi0JCQkJTElORV9D SEVDSygiJS03LjdzIHVjYXN0IE5PTkUgICAgbWdtdCAlMnUgTWIvcyAiCi0JCQkJICAgICJtY2Fz dCAlMnUgTWIvcyBtYXhyZXRyeSAldSIsCi0JCQkJICAgIG1vZGVuYW1lW21vZGVdLAotCQkJCSAg ICB0cC0+bWdtdHJhdGUvMiwKLQkJCQkgICAgdHAtPm1jYXN0cmF0ZS8yLCB0cC0+bWF4cmV0cnkp OwotCQkJZWxzZQotCQkJCUxJTkVfQ0hFQ0soIiUtNy43cyB1Y2FzdCAlMnUgTWIvcyBtZ210ICUy dSBNYi9zICIKLQkJCQkgICAgIm1jYXN0ICUydSBNYi9zIG1heHJldHJ5ICV1IiwKLQkJCQkgICAg bW9kZW5hbWVbbW9kZV0sCi0JCQkJICAgIHRwLT51Y2FzdHJhdGUvMiwgdHAtPm1nbXRyYXRlLzIs Ci0JCQkJICAgIHRwLT5tY2FzdHJhdGUvMiwgdHAtPm1heHJldHJ5KTsKLQkJfQorCQlpZiAodHAt PnVjYXN0cmF0ZSA9PSBJRUVFODAyMTFfRklYRURfUkFURV9OT05FKQorCQkJTElORV9DSEVDSygi JS03LjdzIHVjYXN0IE5PTkUgICAgbWdtdCAlMnUgJXMgIgorCQkJICAgICJtY2FzdCAlMnUgJXMg bWF4cmV0cnkgJXUiLAorCQkJICAgIG1vZGVuYW1lW21vZGVdLAorCQkJICAgIHJhdGUyc3BlZWQo dHAtPm1nbXRyYXRlKSwgcmF0ZTJzdHIodHAtPm1nbXRyYXRlKSwKKwkJCSAgICByYXRlMnNwZWVk KHRwLT5tY2FzdHJhdGUpLCByYXRlMnN0cih0cC0+bWNhc3RyYXRlKSwKKwkJCSAgICB0cC0+bWF4 cmV0cnkpOworCQllbHNlCisJCQlMSU5FX0NIRUNLKCIlLTcuN3MgdWNhc3QgJTJ1ICVzIG1nbXQg JTJ1ICVzICIKKwkJCSAgICAibWNhc3QgJTJ1ICVzIG1heHJldHJ5ICV1IiwKKwkJCSAgICBtb2Rl bmFtZVttb2RlXSwKKwkJCSAgICByYXRlMnNwZWVkKHRwLT51Y2FzdHJhdGUpLCByYXRlMnN0cih0 cC0+dWNhc3RyYXRlKSwKKwkJCSAgICByYXRlMnNwZWVkKHRwLT5tZ210cmF0ZSksIHJhdGUyc3Ry KHRwLT5tZ210cmF0ZSksCisJCQkgICAgcmF0ZTJzcGVlZCh0cC0+bWNhc3RyYXRlKSwgcmF0ZTJz dHIodHAtPm1jYXN0cmF0ZSksCisJCQkgICAgdHAtPm1heHJldHJ5KTsKIAl9CiB9CiAK --047d7b2e07392d151504bdda4866-- From owner-freebsd-wireless@FreeBSD.ORG Tue Apr 17 18:12:51 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 383CF1065673 for ; Tue, 17 Apr 2012 18:12:51 +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 0E4D68FC12 for ; Tue, 17 Apr 2012 18:12:51 +0000 (UTC) Received: by dadz14 with SMTP id z14so28737636dad.17 for ; Tue, 17 Apr 2012 11:12:49 -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=IYRAQbVn8pqrrnBQifylp61h53W9kZDMHoaAuIiOixY=; b=ry0oAPb8MpNvAq3hMjNEpFRrM5Og9BIAJ5TUJX5b+pvqtUrT3Thdk8l4K8J5u4bCMv x3L5WSbAS7YX+ES1aTMpqCU6JrTf9B3ryzRJ1j8Si+2Za6G2jmSTf1P7OZWe0CS1BweX FhSD7PvgU+cVEsaO63X7wkHmwTi8LIESHpFAPC/muXQrqQ5FhZtAum7glSoZuMa5vlru OV0sM2YccqgYMJ0Yw6ONCrpdy0JUZN4UhUpqztzF3cEBo+pzOr0n6ZlPt3oe2AKXsAq8 INSmEJebCtH443WrVVLamcdU2TY5mBmn+s2D+n0+bPxQ3+RQ8txv6EPv2k755zYuNKSp e42w== MIME-Version: 1.0 Received: by 10.68.202.168 with SMTP id kj8mr38154027pbc.86.1334686369813; Tue, 17 Apr 2012 11:12:49 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.142.101.9 with HTTP; Tue, 17 Apr 2012 11:12:49 -0700 (PDT) Date: Tue, 17 Apr 2012 11:12:49 -0700 X-Google-Sender-Auth: XtRzQHiy2_9Kxhg_tPh0iJt7ww4 Message-ID: From: Adrian Chadd To: freebsd-wireless@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Question: IEEE80211_RATE_BASIC versus IEEE80211_RATE_MCS ? 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, 17 Apr 2012 18:12:51 -0000 Hi, So after doing some digging into the rate representation, I've discovered that both IEEE80211_RATE_BASIC and IEEE80211_RATE_MCS are represented as the high bit set (ie, 0x80.) My query is - how exactly should we be representing rates, and is there a clear, consistent, non-overlapping use case for where each is used? This shows up in setbasicrates(), where the 11na/11ng modes have the OFDM/CCK (respectively) rates set as basic, just like for 11a/11bg, however the high bit is set. ifconfig(8) at least just looks at the tx rateset list (which setbasicrates is setting up for us) and mis-interpreting the high bit as MCS, rather than as "basic". Any ideas/suggestions? I'd be tempted to create a 'ratecode_t' that is a uint8_t struct, then finding/fixing all instances where ratecode is being passed in as a uint8_t, but that may be slightly overkill. Adrian From owner-freebsd-wireless@FreeBSD.ORG Wed Apr 18 01:23:06 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 93081106564A for ; Wed, 18 Apr 2012 01:23:06 +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 6441B8FC16 for ; Wed, 18 Apr 2012 01:23:06 +0000 (UTC) Received: by pbcwz17 with SMTP id wz17so8791792pbc.13 for ; Tue, 17 Apr 2012 18:23:06 -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=nw8+cgEsaKJOBbyFbVZdzmX0sEznre9g5WnrDiAvdZE=; b=ZhGgAR2KFbcmVJuXM1yIHwFpHdYlYvBYiDHIF7cHupUij8BCbBDrLDhqIajHMG2QfR It0N6Crg1HKtZgtqv/mft3GrNDoJ1tCJTobSmIHeiSiLfJfRZgfsQPCUolp6iDgt05bW zExafBxoktq+gPDcbbosq1H2cR3DLmQ9KqEwE2fpScaX8m4MeSqvXoPSiZCkKmNCvLvR uYKc4vPcKyr1JT/iGuSMJNKyIecyN5rCNS45Bzv06Ou+Nj2aVjBnq4bpu4pDMOF0jVny e+4Sj/k2SgI6spzwBqkkLDUVOZsdGiS+YWwhuCY9PrPft8eapLX0x0FFZhFtyh9Xa8GM i0aA== MIME-Version: 1.0 Received: by 10.68.134.133 with SMTP id pk5mr2007048pbb.17.1334712186191; Tue, 17 Apr 2012 18:23:06 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.142.101.9 with HTTP; Tue, 17 Apr 2012 18:23:06 -0700 (PDT) Date: Tue, 17 Apr 2012 18:23:06 -0700 X-Google-Sender-Auth: IuvRN3WwXHtRpXt6VB86g9a7CXs Message-ID: From: Adrian Chadd To: freebsd-wireless@freebsd.org Content-Type: multipart/mixed; boundary=047d7b11190bbc3d8d04bde9e5c8 Subject: [RFC] disable hardware register byteswap, fixes Merlin AR9220 on AR71xx 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, 18 Apr 2012 01:23:06 -0000 --047d7b11190bbc3d8d04bde9e5c8 Content-Type: text/plain; charset=ISO-8859-1 Hi all, After quite a bit of hackery, hair tearing and other assorted stuff, I finally nailed the AR9220 + AR71xx instability that we've all been seeing. It seems to be a combination of: * incorrect power supplies being used (yes, I found that a board would work fine until you started interacting with the NIC, at which point it'd throw an immediate parity error - but then subsequent register poking via the debugger would come out fine); * _maybe_ some PCI bus glue issues? The PCI glue now looks a lot more like what's in Linux/Atheros code. * hardware register content byteswapping. The last one is a bit unfortunate. Here's a patch that pushes the register space byte swapping back into software, rather than hardware. I've given it a good thrashing on my AR71xx boards with various AR9220 NICs and they all work a-ok now, with no panics and no "weird stuff." I have no idea (yet) whether it's a timing issue with the PCI NIC/bus/controller, whether the hardware swizzling is just plain broken in some situations .. but what I don't want to do is turn all of this off without understanding what the root cause is. So if you've been dying (heh) to play with FreeBSD-HEAD on the DIR-825, or any other atheros MIPS + AR9220 board, here's your chance. I've had it rock solid on my AP96 and Routerstation / Routerstation pro boards for the last couple of days. The DIR-825 is based on the AP96 design (different switch PHY) so I would be very surprised to find it unstable. I may soon just give in and commit it, with a long explanation as to why I'm disabling it. If people would like it resurrected for whatever reason then the patch(es) will be in SVN history. As a data point - ath5k, ath9k and the Atheros reference driver all have the hardware register byteswap disabled. I'd rather not disable it without having firm evidence it's broken. I may also tidy up the register access stuff and make it all a compile time option. Thanks, Adrian --047d7b11190bbc3d8d04bde9e5c8 Content-Type: application/octet-stream; name="2012-04-17-ath-hal-noregswizzle-2.diff" Content-Disposition: attachment; filename="2012-04-17-ath-hal-noregswizzle-2.diff" Content-Transfer-Encoding: base64 X-Attachment-Id: f_h15p5x9s0 SW5kZXg6IHN5cy9kZXYvYXRoL2F0aF9oYWwvYXI1NDE2L2FyNTQxNl9yZXNldC5jCj09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT0KLS0tIHN5cy9kZXYvYXRoL2F0aF9oYWwvYXI1NDE2L2FyNTQxNl9yZXNldC5jCShyZXZpc2lv biAyMzQzNjkpCisrKyBzeXMvZGV2L2F0aC9hdGhfaGFsL2FyNTQxNi9hcjU0MTZfcmVzZXQuYwko d29ya2luZyBjb3B5KQpAQCAtMTM4NywxNiArMTM4NywxNSBAQAogCWlmICh0eXBlID09IEhBTF9S RVNFVF9DT0xEKSB7CiAJCWlmIChpc0JpZ0VuZGlhbigpKSB7CiAJCQkvKgotCQkJICogU2V0IENG RywgbGl0dGxlLWVuZGlhbiBmb3IgcmVnaXN0ZXIKLQkJCSAqIGFuZCBkZXNjcmlwdG9yIGFjY2Vz c2VzLgorCQkJICogU2V0IENGRywgbGl0dGxlLWVuZGlhbiBmb3IgZGVzY3JpcHRvciBhY2Nlc3Nl cy4KIAkJCSAqLwotCQkJbWFzayA9IElOSVRfQ09ORklHX1NUQVRVUyB8IEFSX0NGR19TV1JEIHwg QVJfQ0ZHX1NXUkc7CisJCQltYXNrID0gSU5JVF9DT05GSUdfU1RBVFVTIHwgQVJfQ0ZHX1NXUkQ7 CiAjaWZuZGVmIEFIX05FRURfREVTQ19TV0FQCiAJCQltYXNrIHw9IEFSX0NGR19TV1REOwogI2Vu ZGlmCiAJCQlIQUxERUJVRyhhaCwgSEFMX0RFQlVHX1JFU0VULAogCQkJICAgICIlcyBBcHBseWlu ZyBkZXNjcmlwdG9yIHN3YXBcbiIsIF9fZnVuY19fKTsKLQkJCU9TX1JFR19XUklURShhaCwgQVJf Q0ZHLCBMRV9SRUFEXzQoJm1hc2spKTsKKwkJCU9TX1JFR19XUklURShhaCwgQVJfQ0ZHLCBtYXNr KTsKIAkJfSBlbHNlCiAJCQlPU19SRUdfV1JJVEUoYWgsIEFSX0NGRywgSU5JVF9DT05GSUdfU1RB VFVTKTsKIAl9CkluZGV4OiBzeXMvZGV2L2F0aC9hdGhfaGFsL2FyNTIxMC9hcjUyMTBfcmVzZXQu Ywo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09Ci0tLSBzeXMvZGV2L2F0aC9hdGhfaGFsL2FyNTIxMC9hcjUyMTBfcmVzZXQu YwkocmV2aXNpb24gMjM0MzY5KQorKysgc3lzL2Rldi9hdGgvYXRoX2hhbC9hcjUyMTAvYXI1MjEw X3Jlc2V0LmMJKHdvcmtpbmcgY29weSkKQEAgLTU5NCwxMiArNTk0LDEwIEBACiAgICAgICAgIGlm ICgocmVzZXRNYXNrICYgQVJfUkNfUk1BQykgPT0gMCkgewogCQlpZiAoaXNCaWdFbmRpYW4oKSkg ewogCQkJLyoKLQkJCSAqIFNldCBDRkcsIGxpdHRsZS1lbmRpYW4gZm9yIHJlZ2lzdGVyCi0JCQkg KiBhbmQgZGVzY3JpcHRvciBhY2Nlc3Nlcy4KKwkJCSAqIFNldCBDRkcsIGxpdHRsZS1lbmRpYW4g Zm9yIGRlc2NyaXB0b3IgYWNjZXNzZXMuCiAJCQkgKi8KLQkJCW1hc2sgPSBJTklUX0NPTkZJR19T VEFUVVMgfAotCQkJCUFSX0NGR19TV1REIHwgQVJfQ0ZHX1NXUkQgfCBBUl9DRkdfU1dSRzsKLQkJ CU9TX1JFR19XUklURShhaCwgQVJfQ0ZHLCBMRV9SRUFEXzQoJm1hc2spKTsKKwkJCW1hc2sgPSBJ TklUX0NPTkZJR19TVEFUVVMgfCBBUl9DRkdfU1dURCB8IEFSX0NGR19TV1JEOworCQkJT1NfUkVH X1dSSVRFKGFoLCBBUl9DRkcsIG1hc2spOwogCQl9IGVsc2UKIAkJCU9TX1JFR19XUklURShhaCwg QVJfQ0ZHLCBJTklUX0NPTkZJR19TVEFUVVMpOwogCX0KSW5kZXg6IHN5cy9kZXYvYXRoL2F0aF9o YWwvYXI1MjExL2FyNTIxMV9yZXNldC5jCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIHN5cy9kZXYvYXRoL2F0aF9o YWwvYXI1MjExL2FyNTIxMV9yZXNldC5jCShyZXZpc2lvbiAyMzQzNjkpCisrKyBzeXMvZGV2L2F0 aC9hdGhfaGFsL2FyNTIxMS9hcjUyMTFfcmVzZXQuYwkod29ya2luZyBjb3B5KQpAQCAtNzY0LDEy ICs3NjQsMTAgQEAKICAgICAgICAgaWYgKChyZXNldE1hc2sgJiBBUl9SQ19NQUMpID09IDApIHsK IAkJaWYgKGlzQmlnRW5kaWFuKCkpIHsKIAkJCS8qCi0JCQkgKiBTZXQgQ0ZHLCBsaXR0bGUtZW5k aWFuIGZvciByZWdpc3RlcgotCQkJICogYW5kIGRlc2NyaXB0b3IgYWNjZXNzZXMuCisJCQkgKiBT ZXQgQ0ZHLCBsaXR0bGUtZW5kaWFuIGZvciBkZXNjcmlwdG9yIGFjY2Vzc2VzLgogCQkJICovCi0J CQltYXNrID0gSU5JVF9DT05GSUdfU1RBVFVTIHwKLQkJCQlBUl9DRkdfU1dURCB8IEFSX0NGR19T V1JEIHwgQVJfQ0ZHX1NXUkc7Ci0JCQlPU19SRUdfV1JJVEUoYWgsIEFSX0NGRywgTEVfUkVBRF80 KCZtYXNrKSk7CisJCQltYXNrID0gSU5JVF9DT05GSUdfU1RBVFVTIHwgQVJfQ0ZHX1NXVEQgfCBB Ul9DRkdfU1dSRDsKKwkJCU9TX1JFR19XUklURShhaCwgQVJfQ0ZHLCBtYXNrKTsKIAkJfSBlbHNl CiAJCQlPU19SRUdfV1JJVEUoYWgsIEFSX0NGRywgSU5JVF9DT05GSUdfU1RBVFVTKTsKIAl9Cklu ZGV4OiBzeXMvZGV2L2F0aC9hdGhfaGFsL2FyNTIxMi9hcjUyMTJfcmVzZXQuYwo9PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 Ci0tLSBzeXMvZGV2L2F0aC9hdGhfaGFsL2FyNTIxMi9hcjUyMTJfcmVzZXQuYwkocmV2aXNpb24g MjM0MzY5KQorKysgc3lzL2Rldi9hdGgvYXRoX2hhbC9hcjUyMTIvYXI1MjEyX3Jlc2V0LmMJKHdv cmtpbmcgY29weSkKQEAgLTEyNzMsMTQgKzEyNzMsMTMgQEAKICAgICAgICAgaWYgKChyZXNldE1h c2sgJiBBUl9SQ19NQUMpID09IDApIHsKIAkJaWYgKGlzQmlnRW5kaWFuKCkpIHsKIAkJCS8qCi0J CQkgKiBTZXQgQ0ZHLCBsaXR0bGUtZW5kaWFuIGZvciByZWdpc3RlcgotCQkJICogYW5kIGRlc2Ny aXB0b3IgYWNjZXNzZXMuCisJCQkgKiBTZXQgQ0ZHLCBsaXR0bGUtZW5kaWFuIGZvciBkZXNjcmlw dG9yIGFjY2Vzc2VzLgogCQkJICovCi0JCQltYXNrID0gSU5JVF9DT05GSUdfU1RBVFVTIHwgQVJf Q0ZHX1NXUkQgfCBBUl9DRkdfU1dSRzsKKwkJCW1hc2sgPSBJTklUX0NPTkZJR19TVEFUVVMgfCBB Ul9DRkdfU1dSRDsKICNpZm5kZWYgQUhfTkVFRF9ERVNDX1NXQVAKIAkJCW1hc2sgfD0gQVJfQ0ZH X1NXVEQ7CiAjZW5kaWYKLQkJCU9TX1JFR19XUklURShhaCwgQVJfQ0ZHLCBMRV9SRUFEXzQoJm1h c2spKTsKKwkJCU9TX1JFR19XUklURShhaCwgQVJfQ0ZHLCBtYXNrKTsKIAkJfSBlbHNlCiAJCQlP U19SRUdfV1JJVEUoYWgsIEFSX0NGRywgSU5JVF9DT05GSUdfU1RBVFVTKTsKIAkJaWYgKGFyNTIx MlNldFBvd2VyTW9kZShhaCwgSEFMX1BNX0FXQUtFLCBBSF9UUlVFKSkKSW5kZXg6IHN5cy9kZXYv YXRoL2F0aF9oYWwvYXI1MzEyL2FyNTMxMl9yZXNldC5jCj09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIHN5cy9kZXYv YXRoL2F0aF9oYWwvYXI1MzEyL2FyNTMxMl9yZXNldC5jCShyZXZpc2lvbiAyMzQzNjkpCisrKyBz eXMvZGV2L2F0aC9hdGhfaGFsL2FyNTMxMi9hcjUzMTJfcmVzZXQuYwkod29ya2luZyBjb3B5KQpA QCAtNzQwLDggKzc0MCw3IEBACiAgICAgICAgIGlmICgocmVzZXRNYXNrICYgQVJfUkNfTUFDKSA9 PSAwKSB7CiAJCWlmIChpc0JpZ0VuZGlhbigpKSB7CiAJCQkvKgotCQkJICogU2V0IENGRywgbGl0 dGxlLWVuZGlhbiBmb3IgcmVnaXN0ZXIKLQkJCSAqIGFuZCBkZXNjcmlwdG9yIGFjY2Vzc2VzLgor CQkJICogU2V0IENGRywgbGl0dGxlLWVuZGlhbiBmb3IgZGVzY3JpcHRvciBhY2Nlc3Nlcy4KIAkJ CSAqLwogI2lmZGVmIEFIX05FRURfREVTQ19TV0FQCiAJCQltYXNrID0gSU5JVF9DT05GSUdfU1RB VFVTIHwgQVJfQ0ZHX1NXUkQ7CkluZGV4OiBzeXMvZGV2L2F0aC9haF9vc2RlcC5jCj09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT0KLS0tIHN5cy9kZXYvYXRoL2FoX29zZGVwLmMJKHJldmlzaW9uIDIzNDM2OSkKKysrIHN5cy9k ZXYvYXRoL2FoX29zZGVwLmMJKHdvcmtpbmcgY29weSkKQEAgLTI2NywxMiArMjY3LDcgQEAKIAl9 CiAJaWYgKGFoLT5haF9jb25maWcuYWhfc2VyaWFsaXNlX3JlZ193YXIpCiAJCW10eF9sb2NrX3Nw aW4oJmFoX3JlZ3Nlcl9tdHgpOwotI2lmIF9CWVRFX09SREVSID09IF9CSUdfRU5ESUFOCi0JaWYg KE9TX1JFR19VTlNXQVBQRUQocmVnKSkKLQkJYnVzX3NwYWNlX3dyaXRlXzQodGFnLCBoLCByZWcs IHZhbCk7Ci0JZWxzZQotI2VuZGlmCi0JCWJ1c19zcGFjZV93cml0ZV9zdHJlYW1fNCh0YWcsIGgs IHJlZywgdmFsKTsKKwlidXNfc3BhY2Vfd3JpdGVfNCh0YWcsIGgsIHJlZywgdmFsKTsKIAlpZiAo YWgtPmFoX2NvbmZpZy5haF9zZXJpYWxpc2VfcmVnX3dhcikKIAkJbXR4X3VubG9ja19zcGluKCZh aF9yZWdzZXJfbXR4KTsKIH0KQEAgLTI4NiwxMiArMjgxLDExIEBACiAKIAlpZiAoYWgtPmFoX2Nv bmZpZy5haF9zZXJpYWxpc2VfcmVnX3dhcikKIAkJbXR4X2xvY2tfc3BpbigmYWhfcmVnc2VyX210 eCk7Ci0jaWYgX0JZVEVfT1JERVIgPT0gX0JJR19FTkRJQU4KLQlpZiAoT1NfUkVHX1VOU1dBUFBF RChyZWcpKQotCQl2YWwgPSBidXNfc3BhY2VfcmVhZF80KHRhZywgaCwgcmVnKTsKLQllbHNlCi0j ZW5kaWYKLQkJdmFsID0gYnVzX3NwYWNlX3JlYWRfc3RyZWFtXzQodGFnLCBoLCByZWcpOworCXZh bCA9IGJ1c19zcGFjZV9yZWFkXzQodGFnLCBoLCByZWcpOworCisJaWYgKHZhbCA9PSAweGRlYWRj MGRlKQorCQlhdGhfaGFsX3ByaW50ZihhaCwgIiVzOiByZWc9MHgleCwgdmFsPTB4ZGVhZGMwZGUh XG4iLCBfX2Z1bmNfXywgcmVnKTsKKwogCWlmIChhaC0+YWhfY29uZmlnLmFoX3NlcmlhbGlzZV9y ZWdfd2FyKQogCQltdHhfdW5sb2NrX3NwaW4oJmFoX3JlZ3Nlcl9tdHgpOwogCWlmIChhdGhfaGFs X2FscSkgewpAQCAtMzQzLDEyICszMzcsNyBAQAogCiAJaWYgKGFoLT5haF9jb25maWcuYWhfc2Vy aWFsaXNlX3JlZ193YXIpCiAJCW10eF9sb2NrX3NwaW4oJmFoX3JlZ3Nlcl9tdHgpOwotI2lmIF9C WVRFX09SREVSID09IF9CSUdfRU5ESUFOCi0JaWYgKE9TX1JFR19VTlNXQVBQRUQocmVnKSkKLQkJ YnVzX3NwYWNlX3dyaXRlXzQodGFnLCBoLCByZWcsIHZhbCk7Ci0JZWxzZQotI2VuZGlmCi0JCWJ1 c19zcGFjZV93cml0ZV9zdHJlYW1fNCh0YWcsIGgsIHJlZywgdmFsKTsKKwlidXNfc3BhY2Vfd3Jp dGVfNCh0YWcsIGgsIHJlZywgdmFsKTsKIAlpZiAoYWgtPmFoX2NvbmZpZy5haF9zZXJpYWxpc2Vf cmVnX3dhcikKIAkJbXR4X3VubG9ja19zcGluKCZhaF9yZWdzZXJfbXR4KTsKIH0KQEAgLTM2Miwx MiArMzUxLDcgQEAKIAogCWlmIChhaC0+YWhfY29uZmlnLmFoX3NlcmlhbGlzZV9yZWdfd2FyKQog CQltdHhfbG9ja19zcGluKCZhaF9yZWdzZXJfbXR4KTsKLSNpZiBfQllURV9PUkRFUiA9PSBfQklH X0VORElBTgotCWlmIChPU19SRUdfVU5TV0FQUEVEKHJlZykpCi0JCXZhbCA9IGJ1c19zcGFjZV9y ZWFkXzQodGFnLCBoLCByZWcpOwotCWVsc2UKLSNlbmRpZgotCQl2YWwgPSBidXNfc3BhY2VfcmVh ZF9zdHJlYW1fNCh0YWcsIGgsIHJlZyk7CisJdmFsID0gYnVzX3NwYWNlX3JlYWRfNCh0YWcsIGgs IHJlZyk7CiAJaWYgKGFoLT5haF9jb25maWcuYWhfc2VyaWFsaXNlX3JlZ193YXIpCiAJCW10eF91 bmxvY2tfc3BpbigmYWhfcmVnc2VyX210eCk7CiAJcmV0dXJuIHZhbDsKSW5kZXg6IHN5cy9kZXYv YXRoL2FoX29zZGVwLmgKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gc3lzL2Rldi9hdGgvYWhfb3NkZXAuaAkocmV2 aXNpb24gMjM0MzY5KQorKysgc3lzL2Rldi9hdGgvYWhfb3NkZXAuaAkod29ya2luZyBjb3B5KQpA QCAtOTcsMzkgKzk3LDEzIEBACiBleHRlcm4Jdm9pZCBhdGhfaGFsX3JlZ193cml0ZShzdHJ1Y3Qg YXRoX2hhbCAqYWgsIHVfaW50IHJlZywgdV9pbnQzMl90IHZhbCk7CiBleHRlcm4JdV9pbnQzMl90 IGF0aF9oYWxfcmVnX3JlYWQoc3RydWN0IGF0aF9oYWwgKmFoLCB1X2ludCByZWcpOwogI2Vsc2UK LS8qCi0gKiBUaGUgaGFyZHdhcmUgcmVnaXN0ZXJzIGFyZSBuYXRpdmUgbGl0dGxlLWVuZGlhbiBi eXRlIG9yZGVyLgotICogQmlnLWVuZGlhbiBob3N0cyBhcmUgaGFuZGxlZCBieSBlbmFibGluZyBo YXJkd2FyZSBieXRlLXN3YXAKLSAqIG9mIHJlZ2lzdGVyIHJlYWRzIGFuZCB3cml0ZXMgYXQgcmVz ZXQuICBCdXQgdGhlIFBDSSBjbG9jawotICogZG9tYWluIHJlZ2lzdGVycyBhcmUgbm90IGJ5dGUg c3dhcHBlZCEgIFRodXMsIG9uIGJpZy1lbmRpYW4KLSAqIHBsYXRmb3JtcyB3ZSBoYXZlIHRvIGV4 cGxpY2l0bHkgYnl0ZS1zd2FwIHRob3NlIHJlZ2lzdGVycy4KLSAqIE1vc3Qgb2YgdGhpcyBjb2Rl IGlzIGNvbGxhcHNlZCBhdCBjb21waWxlIHRpbWUgYmVjYXVzZSB0aGUKLSAqIHJlZ2lzdGVyIHZh bHVlcyBhcmUgY29uc3RhbnRzLgotICovCi0jaWYgX0JZVEVfT1JERVIgPT0gX0JJR19FTkRJQU4K LSNkZWZpbmUgT1NfUkVHX1dSSVRFKF9haCwgX3JlZywgX3ZhbCkgZG8gewkJCQlcCi0JaWYgKE9T X1JFR19VTlNXQVBQRUQoX3JlZykpCQkJCQlcCi0JCWJ1c19zcGFjZV93cml0ZV80KChidXNfc3Bh Y2VfdGFnX3QpKF9haCktPmFoX3N0LAlcCi0JCSAgICAoYnVzX3NwYWNlX2hhbmRsZV90KShfYWgp LT5haF9zaCwgKF9yZWcpLCAoX3ZhbCkpOwlcCi0JZWxzZQkJCQkJCQkJXAotCQlidXNfc3BhY2Vf d3JpdGVfc3RyZWFtXzQoKGJ1c19zcGFjZV90YWdfdCkoX2FoKS0+YWhfc3QsCVwKLQkJICAgIChi dXNfc3BhY2VfaGFuZGxlX3QpKF9haCktPmFoX3NoLCAoX3JlZyksIChfdmFsKSk7CVwKLX0gd2hp bGUgKDApCi0jZGVmaW5lIE9TX1JFR19SRUFEKF9haCwgX3JlZykJCQkJCQlcCi0JKE9TX1JFR19V TlNXQVBQRUQoX3JlZykgPwkJCQkJXAotCQlidXNfc3BhY2VfcmVhZF80KChidXNfc3BhY2VfdGFn X3QpKF9haCktPmFoX3N0LAkJXAotCQkgICAgKGJ1c19zcGFjZV9oYW5kbGVfdCkoX2FoKS0+YWhf c2gsIChfcmVnKSkgOgkJXAotCQlidXNfc3BhY2VfcmVhZF9zdHJlYW1fNCgoYnVzX3NwYWNlX3Rh Z190KShfYWgpLT5haF9zdCwJXAotCQkgICAgKGJ1c19zcGFjZV9oYW5kbGVfdCkoX2FoKS0+YWhf c2gsIChfcmVnKSkpCi0jZWxzZSAvKiBfQllURV9PUkRFUiA9PSBfTElUVExFX0VORElBTiAqLwog I2RlZmluZQlPU19SRUdfV1JJVEUoX2FoLCBfcmVnLCBfdmFsKQkJCQkJXAogCWJ1c19zcGFjZV93 cml0ZV80KChidXNfc3BhY2VfdGFnX3QpKF9haCktPmFoX3N0LAkJXAogCSAgICAoYnVzX3NwYWNl X2hhbmRsZV90KShfYWgpLT5haF9zaCwgKF9yZWcpLCAoX3ZhbCkpCiAjZGVmaW5lCU9TX1JFR19S RUFEKF9haCwgX3JlZykJCQkJCQlcCiAJYnVzX3NwYWNlX3JlYWRfNCgoYnVzX3NwYWNlX3RhZ190 KShfYWgpLT5haF9zdCwJCQlcCiAJICAgIChidXNfc3BhY2VfaGFuZGxlX3QpKF9haCktPmFoX3No LCAoX3JlZykpCi0jZW5kaWYgLyogX0JZVEVfT1JERVIgKi8KLSNlbmRpZiAvKiBBSF9ERUJVRyB8 fCBBSF9SRUdGVU5DIHx8IEFIX0RFQlVHX0FMUSAqLworI2VuZGlmCiAKICNpZmRlZiBBSF9ERUJV R19BTFEKIGV4dGVybgl2b2lkIE9TX01BUksoc3RydWN0IGF0aF9oYWwgKiwgdV9pbnQgaWQsIHVf aW50MzJfdCB2YWx1ZSk7Cg== --047d7b11190bbc3d8d04bde9e5c8-- From owner-freebsd-wireless@FreeBSD.ORG Wed Apr 18 09:37:01 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 2774D106564A for ; Wed, 18 Apr 2012 09:37:01 +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 98A2B8FC0A for ; Wed, 18 Apr 2012 09:37:00 +0000 (UTC) Received: by lbbgm6 with SMTP id gm6so1376907lbb.13 for ; Wed, 18 Apr 2012 02:36:58 -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 :x-gm-message-state; bh=zso1LH8SegTHVftCV4c3mnnFsjTOyD1ctO7tSF2fTrc=; b=EklI1ZRTBQcb9Cok7d3H6Kz6B3dfcgFkujqWYwGlz/ht/5P9e2/+hurptS+v0w7vv9 IbUdbaXqZtXEk6ijUtqapjpxEbIBYSOghiIaRG58tL9bnhwZqinkfghJD/2Na6N13SQJ 1SrRU+HHINQKtPEH6PgaYy3sZARHLVk0ct2kb34/jx26AB0M7qLeCaen0g2nJeMSbkTh N2IitYGmPPuunU7UIsYX0s+65PtphW7in21d33sGE9RyZIVjqhh5r6ami6YMgBz58d5S tr+EUByp7j/TAoQURGURgO7iW7c44B0v1k8MOR7YyNZeYDROMXa/b10IEXqN5umjuv2W NVlA== MIME-Version: 1.0 Received: by 10.152.112.100 with SMTP id ip4mr1496439lab.1.1334741818692; Wed, 18 Apr 2012 02:36:58 -0700 (PDT) Sender: bschmidt@techwires.net Received: by 10.152.144.195 with HTTP; Wed, 18 Apr 2012 02:36:58 -0700 (PDT) X-Originating-IP: [79.140.39.245] In-Reply-To: References: Date: Wed, 18 Apr 2012 11:36:58 +0200 X-Google-Sender-Auth: HvlmPvH4T4gveBEe_n9OBk9Ijk8 Message-ID: From: Bernhard Schmidt To: Adrian Chadd Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQkTFktLOfLMZVcYVgrE6z2nGwclBzQO+keT8Q17UMf4v33RPdbKnKUBRxxZLF55gdmGRE17 Cc: freebsd-wireless@freebsd.org Subject: Re: Question: IEEE80211_RATE_BASIC versus IEEE80211_RATE_MCS ? 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, 18 Apr 2012 09:37:01 -0000 On Tue, Apr 17, 2012 at 20:12, Adrian Chadd wrote: > Hi, > > So after doing some digging into the rate representation, I've > discovered that both IEEE80211_RATE_BASIC and IEEE80211_RATE_MCS are > represented as the high bit set (ie, 0x80.) > > My query is - how exactly should we be representing rates, and is > there a clear, consistent, non-overlapping use case for where each is > used? > > This shows up in setbasicrates(), where the 11na/11ng modes have the > OFDM/CCK (respectively) rates set as basic, just like for 11a/11bg, > however the high bit is set. ifconfig(8) at least just looks at the tx > rateset list (which setbasicrates is setting up for us) and > mis-interpreting the high bit as MCS, rather than as "basic". > > Any ideas/suggestions? I'd be tempted to create a 'ratecode_t' that is > a uint8_t struct, then finding/fixing all instances where ratecode is > being passed in as a uint8_t, but that may be slightly overkill. In some places the current channel can be abused to determine if it's a MCS or legacy rate, but this is really just an ugly hack. As you've already noted, the basic rate flag isn't handle correctly, neither in status output nor in IEs in the MCS case. Though, I'm not sure we *really* need (BASIC | MCS) right now anywhere, can you think of a place? Hmm, right, ni_txrate might be one of those places. Basically we have 2 arrays ni_rates and ni_htrates, the later implicitly has the MCS flag set, both can set the BASIC flag as required. The tricky part is just to figure out when and where to drop/set the flags as required when assigning from one of the arrays to another variable. I pondered changing "rate" to an uint16_t once and move all flags to the new byte, which would also allow to merge both arrays, but feared the ABI/API breakage.. -- Bernhard From owner-freebsd-wireless@FreeBSD.ORG Wed Apr 18 09:46:07 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 835B01065673 for ; Wed, 18 Apr 2012 09:46:07 +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 EB5748FC19 for ; Wed, 18 Apr 2012 09:46:06 +0000 (UTC) Received: by lagv3 with SMTP id v3so6965224lag.13 for ; Wed, 18 Apr 2012 02:46:05 -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=HtCqOjvvidQPQgoxJh2aog3GbpRBMO6z7nZ5HdRD7QE=; b=YGdv//qfrbM3WmdfiFWKYqC+NXaa2/mlSEdWd0lT06VXIboG0YSKKMnzgc+5ss9Tci 2P+GCF7cEGBiI5+XDzl5C6IyzZPLF+371zuFx/IZp82sq/Gd2rG6HJgjAiJI5EB/cZ2g gbB/8KX7mT8O3cnPK9qymun2F+ANXisJh0LYIlb21fEn5TYcV3N3rqkTbmJ9Q5P1Vnb9 //EYXOJOkFZg3wSmlTP19mg0V4mbB3nGGj4ffur2vsBxnZ68G+MKmZuj4VDr3oVGiAjv WyJ3K01vYLmT9HZhnMmwJA7n4RqbZyQ88o/IhL7bLJtRBOr2e8Eb7amwhXPMi0RnYt1V ui2w== MIME-Version: 1.0 Received: by 10.152.112.100 with SMTP id ip4mr1520830lab.1.1334742365736; Wed, 18 Apr 2012 02:46:05 -0700 (PDT) Sender: bschmidt@techwires.net Received: by 10.152.144.195 with HTTP; Wed, 18 Apr 2012 02:46:05 -0700 (PDT) X-Originating-IP: [79.140.39.245] In-Reply-To: References: Date: Wed, 18 Apr 2012 11:46:05 +0200 X-Google-Sender-Auth: U9dbEdZ7ppUY4j7HlvcYbhJu_xI Message-ID: From: Bernhard Schmidt To: freebsd-wireless@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQkH5XirnZG2wHA5WzsFWVVA7FwzHTQDgNxGK9i9He5gkypyjlYCRa9scohLgQyMShmIfZx6 Cc: Subject: Re: Question: IEEE80211_RATE_BASIC versus IEEE80211_RATE_MCS ? 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, 18 Apr 2012 09:46:07 -0000 On Wed, Apr 18, 2012 at 11:36, Bernhard Schmidt wrot= e: > On Tue, Apr 17, 2012 at 20:12, Adrian Chadd wrote: >> Hi, >> >> So after doing some digging into the rate representation, I've >> discovered that both IEEE80211_RATE_BASIC and IEEE80211_RATE_MCS are >> represented as the high bit set (ie, 0x80.) >> >> My query is - how exactly should we be representing rates, and is >> there a clear, consistent, non-overlapping use case for where each is >> used? >> >> This shows up in setbasicrates(), where the 11na/11ng modes have the >> OFDM/CCK (respectively) rates set as basic, just like for 11a/11bg, >> however the high bit is set. ifconfig(8) at least just looks at the tx >> rateset list (which setbasicrates is setting up for us) and >> mis-interpreting the high bit as MCS, rather than as "basic". >> >> Any ideas/suggestions? I'd be tempted to create a 'ratecode_t' that is >> a uint8_t struct, then finding/fixing all instances where ratecode is >> being passed in as a uint8_t, but that may be slightly overkill. > > In some places the current channel can be abused to determine if it's > a MCS or legacy rate, but this is really just an ugly hack. As you've > already noted, the basic rate flag isn't handle correctly, neither in > status output nor in IEs in the MCS case. Though, I'm not sure we > *really* need (BASIC | MCS) right now anywhere, can you think of a > place? Hmm, right, ni_txrate might be one of those places. Hmm, nope, ni_txrate actually doesn't require both. > Basically we have 2 arrays ni_rates and ni_htrates, the later > implicitly has the MCS flag set, both can set the BASIC flag as > required. The tricky part is just to figure out when and where to > drop/set the flags as required when assigning from one of the arrays > to another variable. > > I pondered changing "rate" =A0to an uint16_t once and move all flags to > the new byte, which would also allow to merge both arrays, but feared > the ABI/API breakage.. --=20 Bernhard From owner-freebsd-wireless@FreeBSD.ORG Thu Apr 19 00:13:02 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 1ECC0106564A; Thu, 19 Apr 2012 00:13:02 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id E551D8FC1A; Thu, 19 Apr 2012 00:13:01 +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 q3J0D1ZI050256; Thu, 19 Apr 2012 00:13:01 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q3J0D1ei050252; Thu, 19 Apr 2012 00:13:01 GMT (envelope-from linimon) Date: Thu, 19 Apr 2012 00:13:01 GMT Message-Id: <201204190013.q3J0D1ei050252@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-wireless@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/167080: [wireless][ath]channel switch on another VAP break channel setup of other 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, 19 Apr 2012 00:13:02 -0000 Synopsis: [wireless][ath]channel switch on another VAP break channel setup of other Responsible-Changed-From-To: freebsd-bugs->freebsd-wireless Responsible-Changed-By: linimon Responsible-Changed-When: Thu Apr 19 00:12:53 UTC 2012 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=167080 From owner-freebsd-wireless@FreeBSD.ORG Thu Apr 19 03:37:34 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 10E1C1065670 for ; Thu, 19 Apr 2012 03:37: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 D92A18FC0C for ; Thu, 19 Apr 2012 03:37:33 +0000 (UTC) Received: by pbcwz17 with SMTP id wz17so10321589pbc.13 for ; Wed, 18 Apr 2012 20:37:33 -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=80BwR3ETkPEpJmWxJn1P1RLsY1rh4rx4ScXxRgh6xJU=; b=r7LGLVQ0EBGQYe2ASb7iKk76T+ZrRfiv7R1bWYPM82DLPFYOqrMfPbyHGk3NEhoaX8 2FtwYTz76Z+SXMfR7zjfTJf+zFZCy7NZtxbvrAn7XtOLs7nbmZLIysx8xUWBiSw4m7k0 1Oph3mfm14r1Onc8NZ65hW+drC2MPiDe0nOBfUvtTP5hLeD7roSroiUykHFQyBk4YIm/ ZNIFJN6MJzQWuhQKxdKC4NUCNNAZbDvEnI9qNzwWwEMJVjJE24es8cXcwmXjED9wPIHN It2Eh3YAnpn25IE3X2s35FyDB3Y6NECWHfI9cL1L39kKHmRGFtR1FCbwYEAoGrKFAb06 uCbQ== MIME-Version: 1.0 Received: by 10.68.212.130 with SMTP id nk2mr1333786pbc.166.1334806653672; Wed, 18 Apr 2012 20:37:33 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.142.101.9 with HTTP; Wed, 18 Apr 2012 20:37:33 -0700 (PDT) In-Reply-To: References: Date: Wed, 18 Apr 2012 20:37:33 -0700 X-Google-Sender-Auth: 2PfnyNSTHSsuFG8MMCBfP8Cb4zk Message-ID: From: Adrian Chadd To: freebsd-wireless@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [RFC] disable hardware register byteswap, fixes Merlin AR9220 on AR71xx 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, 19 Apr 2012 03:37:34 -0000 Hi, I've committed this to -HEAD. All those AR9220's on AR71xx CPUs should now be quite stable. Next - this switch PHY stuff, grr.. Adrian From owner-freebsd-wireless@FreeBSD.ORG Thu Apr 19 17:38:36 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 357DA1065674; Thu, 19 Apr 2012 17:38:36 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-lpp01m010-f54.google.com (mail-lpp01m010-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 7A3598FC18; Thu, 19 Apr 2012 17:38:35 +0000 (UTC) Received: by lagv3 with SMTP id v3so8498033lag.13 for ; Thu, 19 Apr 2012 10:38:33 -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=Xbkxv8FVDy23I6vFJxpFCxSJqEu2SJz/Vd8a2G014jY=; b=ohQWYFRNkeOzh2KZKqddyMRpXBo3tsOLZBOx9hGolEG7fFSrHWv4Eh3XzEzYMoqNcK VgYzulAT/+CaMMmdgKl6DmN1C2lbvV+We0QRfRmmsoKDRVzk931WxvHFCRtzYuZHHTKw vPAWQKrvJd0muh+71Ia54Nnscdirm2XnqNQcPBhdUwQywchbDIznaNjipROUusy/TxYQ gLjWghvbUwMw0Jy4+abDCg7Wx42XASTLrNjc1rcmKTLVcpzMBvwPhgA9ebe9g3gGMfaC +7pdh4LRbpfwanMxykuRy6X/FVlfyC25x42SYH9E4ZxFjjEAaPn+nu4aINaVqw70rHog pg7g== MIME-Version: 1.0 Received: by 10.152.145.135 with SMTP id su7mr504835lab.5.1334857113567; Thu, 19 Apr 2012 10:38:33 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.112.106.71 with HTTP; Thu, 19 Apr 2012 10:38:33 -0700 (PDT) In-Reply-To: References: Date: Thu, 19 Apr 2012 10:38:33 -0700 X-Google-Sender-Auth: KyUbLnOvniYAAfhQBJYt3fKZ8Yk Message-ID: From: Adrian Chadd To: Bernhard Schmidt Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-wireless@freebsd.org Subject: Re: Question: IEEE80211_RATE_BASIC versus IEEE80211_RATE_MCS ? 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, 19 Apr 2012 17:38:36 -0000 Right, so we can treat ni_txrate as "don't interpret the basic flag on this." Are you happy with a project to migrate rate's from uint8_t to an opaque struct? That way we can: * add basic, mcs flags; * get ready for the 802.11ac rate configuration mess that's about to occur; * leverage the compiler to tell us when we're trying to do something like uint8_t <-> rate_t, rather than moving it to a uint16_t which the compiler will automagically promote/extend as necessary. It's probably quite ugly, but I think it's necessary to "grow". Adrian From owner-freebsd-wireless@FreeBSD.ORG Fri Apr 20 01:12:57 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 8DEC7106566B; Fri, 20 Apr 2012 01:12:57 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 5C6648FC1C; Fri, 20 Apr 2012 01:12:57 +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 q3K1CvKd081846; Fri, 20 Apr 2012 01:12:57 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q3K1CvfY081842; Fri, 20 Apr 2012 01:12:57 GMT (envelope-from linimon) Date: Fri, 20 Apr 2012 01:12:57 GMT Message-Id: <201204200112.q3K1CvfY081842@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-wireless@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/167113: [ath] AR5210: "stuck" TX seems to be occuring, without watchdog timeout firing 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, 20 Apr 2012 01:12:57 -0000 Synopsis: [ath] AR5210: "stuck" TX seems to be occuring, without watchdog timeout firing Responsible-Changed-From-To: freebsd-bugs->freebsd-wireless Responsible-Changed-By: linimon Responsible-Changed-When: Fri Apr 20 01:12:26 UTC 2012 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=167113