From owner-freebsd-wireless@FreeBSD.ORG Sun Mar 24 00:05:47 2013 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 39D7BE9F for ; Sun, 24 Mar 2013 00:05:47 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) by mx1.freebsd.org (Postfix) with ESMTP id D1FCB1C8 for ; Sun, 24 Mar 2013 00:05:46 +0000 (UTC) Received: by mail-wi0-f176.google.com with SMTP id hm14so9030262wib.9 for ; Sat, 23 Mar 2013 17:05:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=/OK67+DIJWXwbLM3WRtACjLqgEzzDzyBFsXHSaAgZnw=; b=X/C6WmWOFS4UdtsKNYpX4ekxqQtKHOp/X3u37VK0VaGf/0sVNT746lMFdOEz1vEo43 4exvArljovuqCDURMW2phgiFdebz1VE596bKHi4gSWRW27yGe5/niCIJR1madtgwVef2 yJPm3e9Ix4zfwXjIQXBDgzPm6kXQmPOg6i+BLx9xBrYdnfB9JPXNgGhqJgoPkB9QpG8D P9mEAvN+ET2GmgCb5dtc0bHWLAC4A13NCwuC+e/cSThOzHjixcB0L2+yU5mXB9Mmu34w an9Tp1bSBbXZ1PXo6CfEq+RCO7AuAHlS1xI7fl3Rf/3QCcy3OHRMvvH0APD1Ip4tVS9B QIqQ== MIME-Version: 1.0 X-Received: by 10.194.120.169 with SMTP id ld9mr10480878wjb.24.1364083545925; Sat, 23 Mar 2013 17:05:45 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.216.108.130 with HTTP; Sat, 23 Mar 2013 17:05:45 -0700 (PDT) In-Reply-To: <514E3D6D.4060800@gmail.com> References: <514E3D6D.4060800@gmail.com> Date: Sat, 23 Mar 2013 17:05:45 -0700 X-Google-Sender-Auth: -dAKET6toXqUr4uEfEkjKiSZF3k Message-ID: Subject: Re: Periodic panics with ath From: Adrian Chadd To: Joshua Isom Content-Type: text/plain; charset=ISO-8859-1 Cc: "freebsd-wireless@freebsd.org" X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Discussions of 802.11 stack, tools device driver development." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Mar 2013 00:05:47 -0000 Ok, do you get crashdumps? Can you attach the core.X.txt files from /var/crash ? Thanks, Adrian On 23 March 2013 16:40, Joshua Isom wrote: > I'm getting periodic panics with the latest ath driver. I've had six panics > today where the debugger was not entered and it just rebooted. Each one > lists ath_edma_tx_processq as the cause. I can provide all six core.txt > files, but here's some of the dmesg listed in one core.txt file. The dmesg > part looks like it has better info than the early backtrace. > >> Kernel page fault with the following non-sleepable locks held: >> exclusive sleep mutex ath0 TX lock (ath0 TX lock) r = 0 >> (0xffffff800090d790) locked @ >> /root/ATH/head/sys/modules/ath/../../dev/ath/if_ath_tx_edma.c:529 >> KDB: stack backtrace: >> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame >> 0xffffff8020bdd520 >> kdb_backtrace() at kdb_backtrace+0x39/frame 0xffffff8020bdd5d0 >> witness_warn() at witness_warn+0x4a8/frame 0xffffff8020bdd690 >> trap_pfault() at trap_pfault+0x5a/frame 0xffffff8020bdd740 >> trap() at trap+0x659/frame 0xffffff8020bdd950 >> calltrap() at calltrap+0x8/frame 0xffffff8020bdd950 >> --- trap 0xc, rip = 0xffffffff81334da4, rsp = 0xffffff8020bdda10, rbp = >> 0xffffff8020bddb30 --- >> ath_edma_tx_processq() at ath_edma_tx_processq+0x1a4/frame >> 0xffffff8020bddb30 >> taskqueue_run_locked() at taskqueue_run_locked+0xf0/frame >> 0xffffff8020bddb80 >> taskqueue_thread_loop() at taskqueue_thread_loop+0x7b/frame >> 0xffffff8020bddbb0 >> fork_exit() at fork_exit+0x84/frame 0xffffff8020bddbf0 >> fork_trampoline() at fork_trampoline+0xe/frame 0xffffff8020bddbf0 >> --- trap 0, rip = 0, rsp = 0xffffff8020bddcb0, rbp = 0 --- >> >> >> Fatal trap 12: page fault while in kernel mode >> cpuid = 1; apic id = 01 >> fault virtual address = 0x0 >> fault code = supervisor read data, page not present >> instruction pointer = 0x20:0xffffffff81334da4 >> stack pointer = 0x28:0xffffff8020bdda10 >> frame pointer = 0x28:0xffffff8020bddb30 >> code segment = base 0x0, limit 0xfffff, type 0x1b >> = DPL 0, pres 1, long 1, def32 0, gran 1 >> processor eflags = interrupt enabled, resume, IOPL = 0 >> current process = 0 (ath0 taskq) >> Kernel page faultath0: ath_edma_recv_proc_queue: handled npkts 0 >> with the following non-sleepable locks held: >> exclusive sleep mutex ath0 TX lock (ath0 TX lock) r = 0 >> (0xffffff800090d790) locked @ >> /root/ATH/head/sys/modules/ath/../../dev/ath/if_ath_tx_edma.c:529 >> KDB: stack backtrace: >> ath0: ath_edma_recv_proc_queue: handled npkts 0 >> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame >> 0xffffff8020bdd520 >> kdb_backtrace() at kdb_backtrace+0x39/frame 0xffffff8020bdd5d0 >> witness_warn() at witness_warn+0x4a8/frame 0xffffff8020bdd690 >> trap_pfault() at trap_pfault+0x5a/frame 0xffffff8020bdd740 >> trap() at trap+0x659/frame 0xffffff8020bdd950 >> calltrap() at calltrap+0x8/frame 0xffffff8020bdd950 >> --- trap 0xc, rip = 0xffffffff81334da4, rsp = 0xffffff8020bdda10, rbp = >> 0xffffff8020bddb30 --- >> ath_edma_tx_processq() at ath_edma_tx_processq+0x1a4/frame >> 0xffffff8020bddb30 >> taskqueue_run_locked() at taskqueue_run_locked+0xf0/frame >> 0xffffff8020bddb80 >> taskqueue_thread_loop() at taskqueue_thread_loop+0x7b/frame >> 0xffffff8020bddbb0 >> fork_exit() at fork_exit+0x84/frame 0xffffff8020bddbf0 >> fork_trampoline() at fork_trampoline+0xe/frame 0xffffff8020bddbf0 >> --- trap 0, rip = 0, rsp = 0xffffff8020bddcb0, rbp = 0 --- >> >> >> Fatal trap 12: page fault while in kernel mode >> cpuid = 1; apic id = 01 >> fault virtual address = 0x0 >> fault code = supervisor read data, page not present >> instruction pointer = 0x20:0xffffffff81334da4 >> stack pointer = 0x28:0xffffff8020bdda10 >> frame pointer = 0x28:0xffffff8020bddb30 >> code segment = base 0x0, limit 0xfffff, type 0x1b >> = DPL 0, pres 1, long 1, def32 0, gran 1 >> processor eflags = interrupt enabled, resume, IOPL = 0 >> current process = 0 (ath0 taskq) >> Uptime: 32m28s >> Dumping 270 out of 1771 >> MB:..6%..12%..24%..36%..42%..54%..66%..71%..83%..95% > > _______________________________________________ > freebsd-wireless@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-wireless > To unsubscribe, send any mail to "freebsd-wireless-unsubscribe@freebsd.org" From owner-freebsd-wireless@FreeBSD.ORG Sun Mar 24 13:12:22 2013 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 5E70347E for ; Sun, 24 Mar 2013 13:12:22 +0000 (UTC) (envelope-from k.s.mail@gmx.net) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) by mx1.freebsd.org (Postfix) with ESMTP id 0A8B6A2E for ; Sun, 24 Mar 2013 13:12:21 +0000 (UTC) Received: from mailout-de.gmx.net ([10.1.76.27]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0MbNJC-1U0zPk3Zie-00IlXz for ; Sun, 24 Mar 2013 14:12:20 +0100 Received: (qmail invoked by alias); 24 Mar 2013 13:12:20 -0000 Received: from pD9FB8E24.dip.t-dialin.net (EHLO [192.168.2.104]) [217.251.142.36] by mail.gmx.net (mp027) with SMTP; 24 Mar 2013 14:12:20 +0100 X-Authenticated: #32709443 X-Provags-ID: V01U2FsdGVkX1+YT6III06YC6M/e6LAMHb0k6/Msd98gLfmXgrsoL o9UKp5rZayrl0B Message-ID: <514EFBB2.3080209@gmx.net> Date: Sun, 24 Mar 2013 14:12:18 +0100 From: Kamil Szczesny User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: Adrian Chadd Subject: Re: ath0: device timeout on 9.1-RELEASE References: <51175C69.6050003@gmx.net> <511E9446.4070708@gmx.net> <511E9615.3020007@gmx.net> <512376AB.10003@gmx.net> <5123A714.6050105@gmx.net> <5130AF59.5080803@gmx.net> <5131197F.5050700@gmx.net> <5140E8D9.9020609@gmx.net> <5144253B.9050409@gmx.net> <514584A5.6090601@gmx.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: freebsd-wireless@freebsd.org X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Discussions of 802.11 stack, tools device driver development." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Mar 2013 13:12:22 -0000 Am 17.03.13 16:03, schrieb Adrian Chadd: > Hi! > > So this is exactly what I needed! > > On 17 March 2013 01:53, Kamil Szczesny wrote: >> Hi, >> >> it is an 11n NIC, but 11n mode was not working on 8.x-RELEASE either. What I >> am hoping for is that with 9.x-RELEASE 11n will work. We'll see. >> >> It's this one here: > AR5418! (PCIe AR5416.) > >> ath0@pci0:2:0:0: class=0x028000 card=0x3a701186 chip=0x0024168c >> rev=0x01 hdr=0x00 >> Something different, is it possible that with timer=i8254 the systemclock is >> getting faster out of sync? >> >> With 'sysctl dev.ath.0.debug=0x23' the debugging output is more verbose. >> Here we go: > [snip] > >> Mar 17 09:39:26 gomorrha kernel: ath0: ath_tx_dmasetup: m 0xfffffe0014902b00 >> len 42 >> Mar 17 09:39:26 gomorrha kernel: NODS >> 1c:7e:e5:10:61:16->ff:ff:ff:ff:ff:ff(ff:ff:ff:ff:ff:ff) probe_req 1M >> Mar 17 09:39:26 gomorrha kernel: 4000 0000 ffff ffff ffff 1c7e e510 6116 >> ffff ffff ffff 0000 0000 0108 8284 8b96 0c12 1824 3204 3048 606c >> Mar 17 09:39:26 gomorrha kernel: ath0: ath_tx_chaindesclist: 0: 00000000 >> 144f9ee8 213f002e 0120002a 00010000 0000001b >> Mar 17 09:39:26 gomorrha kernel: ath0: ath_tx_handoff: TXDP[1] = 0x5549600 >> (0xffffff810b33b600) depth 1 > So here you've queued a frame. > >> Mar 17 09:39:26 gomorrha kernel: ath0: ath_chan_set: 6 (2437 MHz, flags >> 0x480) >> Mar 17 09:39:26 gomorrha kernel: ath0: ath_draintxq: tx queue [9] 0, link 0 >> Mar 17 09:39:26 gomorrha kernel: ath0: ath_tx_stopdma: tx queue [0] 0, link >> 0 >> Mar 17 09:39:26 gomorrha kernel: ath0: ath_tx_stopdma: tx queue [1] >> 0x5549600, link 0xffffff810b33b600 >> Mar 17 09:39:26 gomorrha kernel: ath0: ath_tx_stopdma: tx queue [2] 0, link >> 0 >> Mar 17 09:39:26 gomorrha kernel: ath0: ath_tx_stopdma: tx queue [3] 0, link >> 0 >> Mar 17 09:39:26 gomorrha kernel: ath0: ath_tx_stopdma: tx queue [8] 0, link >> 0 >> Mar 17 09:39:26 gomorrha kernel: Q1[ 0] (DS.V:0xffffff810b33b600 >> DS.P:0x5549600) L:00000000 D:144f9ee8 F:0413 ! >> Mar 17 09:39:26 gomorrha kernel: 213f002e 0120002a 00010000 0000001b >> 0000023a 00000000 >> Mar 17 09:39:26 gomorrha kernel: 00000000 00000004 00000000 3f000000 >> 3f000000 3f000000 00808080 00000002 > The last DWORD in this line is Tx.Status[1] (ds_status1 in ar5416desc.h.) > >> Mar 17 09:39:26 gomorrha kernel: 00000000 00000000 00000000 80808080 >> 80808080 80808080 80808080 00000001 > The last DWORD in this line is Tx.Status[9] (ds_status9 in ar5416desc.h) > > .. and here, in ath_tx_stopdma(), the frame shows up as completed but > the error status is "excessive retries." > > Now - it could be because the NIC isn't sending back an interrupt and > it always shows up as excessive retries. It could be that the NIC is > trying to transmit it but then the channel change comes along and > cancels the frame transmit immediately, leading to the aborted frame > showing up like this. > > Are you able to update to -HEAD? Not only have I made some changes > with the AR5416 HAL and general TX handling, there's extra logging we > can enable to see fine grain timestamped descriptor information. > That'll tell us whether the hardware is trying to send the frame or > not. Thanks a lot for your effort and help! But unfortunately updating to HEAD is not an option for me, sorry at this point. I guess there is no way in using only the ath driver from 8.x or HEAD with 9.1? This very same nic was working at least with 8.x. regards, Kamil > Thanks, > > > > Adrian > From owner-freebsd-wireless@FreeBSD.ORG Mon Mar 25 11:06:53 2013 Return-Path: Delivered-To: freebsd-wireless@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 6CEE5EC for ; Mon, 25 Mar 2013 11:06:53 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 4E36DDC for ; Mon, 25 Mar 2013 11:06:53 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.6/8.14.6) with ESMTP id r2PB6rPM007356 for ; Mon, 25 Mar 2013 11:06:53 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.6/8.14.6/Submit) id r2PB6qwm007354 for freebsd-wireless@FreeBSD.org; Mon, 25 Mar 2013 11:06:52 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 25 Mar 2013 11:06:52 GMT Message-Id: <201303251106.r2PB6qwm007354@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-wireless@FreeBSD.org Subject: Current problem reports assigned to freebsd-wireless@FreeBSD.org X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Discussions of 802.11 stack, tools device driver development." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Mar 2013 11:06:53 -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/176238 wireless [ath] [patch] Correct buffer size calculation and simp o kern/176201 wireless [net80211] [patch] 11n station includes unrelated ht p o kern/176104 wireless [iwn] iwn0: iwn_intr: fatal firmware error o kern/175870 wireless [iwn] /etc/rc.d/netif restart cause system crash o kern/175722 wireless [ath]lot of bad seriesx hwrate in kernel messages o kern/175446 wireless [ath] high volumes of PHY errors lead to BB/MAC hangs o kern/175227 wireless [ath] beacon timers aren't necessarily reprogrammed af o kern/175183 wireless [iwn] iwn(4) becomes unresponsive during initial confi o kern/175053 wireless [iwn] iwn firmware error on 9-stable with Ultimate-N 6 o kern/174891 wireless [ieee80211] struct ieee80211_node is freed during acti o kern/174722 wireless [wlan] can't use channel 12 and 13 (14) with my wifi i o kern/174661 wireless [wlan] lost alias on wlan interface o kern/174283 wireless [net80211] panics in ieee80211_ff_age() and ieee80211_ o kern/174276 wireless [ath] if_ath memory modified after free o kern/174273 wireless [net80211] taking down a net80211 node with active fas o kern/173917 wireless [iwn] wpa-supplicant issues on iwn o kern/173898 wireless [iwn] [patch] iwn(4) DOES support 6235 chip. o kern/173883 wireless [ath] ath0: unable to attach - pci issue? o kern/173711 wireless [ath] powerd kills ath on the Asus EeePC 1005HA o kern/173342 wireless PS-Poll isn't working o kern/173336 wireless [ath] Atheros card improper device poweroff handling o o kern/172955 wireless [ath] 11n does not work in adhoc mode o kern/172706 wireless [wpi] wpi0 fails to load firmware when using country o kern/172672 wireless [ubt] Bluetooth device recognised but not working o kern/172661 wireless hostapd(8) securing wireless adapter in HostAP mode is o kern/172338 wireless [ath] [net80211] CCMP IV transmit counters are not cor o kern/171598 wireless [ath] TP-Link TL-WN951N W-LAN PCI Adapter 300 MBit stu o kern/171235 wireless [ath] ath loses connection, system freezes on netif re o kern/170889 wireless [ath] ath driver uses some uninitilized memory o kern/170620 wireless [ath] LOR and deadlock when multiple vaps are used o kern/170573 wireless [iwi] Intel 2200BG iwi NIC hangs with need multicast c o kern/170513 wireless [ath] ath logs: ath_tx_aggr_comp_aggr: AR5416 bug: o kern/170433 wireless [ath] TX hang after a stuck beacon message with active o kern/170397 wireless [ath] [patch] Uninitialized variables in ah_eeprom_928 o kern/170302 wireless [ath] 802.11n frames are not being transmitted with mu o kern/170281 wireless [ath] 802.11n locks up on aggregation setup (ampdutx) o kern/170098 wireless [ath] [net80211] VAPs (Virtual access points) with Ath o kern/170066 wireless [ral] ral(4) rt61pci Linksys freezes the machine as so o kern/169432 wireless [ath] BAR TX hang when aggregation session is reset du p kern/169362 wireless [ath] AR5416: radar pulse PHY errors sometimes include o kern/169336 wireless [ath] ANI isn't triggering in a busy/noisy environment o kern/169199 wireless [ath] Cannot set up static ip addresses for wireless w o kern/169084 wireless [ath] suspend/resume doesn't cause a rescan; the assoc o kern/168530 wireless [ath] Broken WEP probably o kern/168393 wireless AR9285: suspend/resume sometimes fails o kern/168170 wireless [net80211] ieee80211_send_bar() doesn't complete corre o kern/167870 wireless [ath] adhoc wifi client does not join an existing IBSS o kern/167834 wireless [ath] kickpcu; 'handled 0 packets' o kern/167828 wireless [iwn] iwn(4) doesn't recover automatically after firmw o kern/167798 wireless ifconfig(8): problem with "ifconfig list scan" command o kern/167491 wireless [ath] TID != hardware queue TID in ath_tx_aggr_comp_ag o kern/167113 wireless [ath] AR5210: "stuck" TX seems to be occuring, without o kern/167080 wireless [ath] channel switch on another VAP break channel setu o kern/166684 wireless [ath] [net80211] mgmtrate/mcastrate isn't updated base p kern/166642 wireless [ieee80211] [patch] in 802.11n mode for FreeBSD AP, ha o kern/166641 wireless [ieee80211] [patch] mbuf/cluster leak in AP mode in 80 p kern/166357 wireless [ath] 802.11n TX stall when the first frame in the BAW o kern/166286 wireless [net80211] [ath] initial switch to HT40 isn't causing p kern/166190 wireless [ath] TX hangs and frames stuck in TX queue o kern/166086 wireless [Patch][ath] Reflect state of rfkill switch in a sysct o kern/165969 wireless [ath] Slower performance in adhoc mode vs Client/AP mo o kern/165966 wireless [ath] ath0: device timeout on SMP machines due to race o kern/165895 wireless [ath] overly busy cabq can tie up all tx buffers o kern/165870 wireless [bwn] bwn driver does not attach on HP Pavilion dv9420 o kern/165866 wireless [ath] TX hangs, requiring a "scan" to properly reset t o kern/165849 wireless [ath] [hang] network ath driver freeze o kern/165595 wireless [ipw] ipw(4): Can't load firmare for ipw2200bg o kern/165543 wireless [ath] ath0 endless scanning of channels without connec o kern/165517 wireless [net80211] bgscan isn't triggered when invalid beacons o kern/165475 wireless [ath] operational mode change doesn't poke the underly o kern/165382 wireless [kernel] taskqueue_unblock doesn't unblock currently q o kern/165306 wireless [ath] race conditions between scanning and beacon time o kern/165220 wireless [ath] "ath_rx_tasklet: sc_inreset_cnt > 0; skipping" m o kern/165214 wireless [ieee80211] Kernel panic in ieee80211_output.c:2505 o kern/165212 wireless [ath] No WiFi on Acer Aspire One 751h (Atheros AR5BHB6 o kern/165149 wireless [ath] [net80211] Ping with data length more than iv_fr o kern/165146 wireless [net80211] Net802.11 Fragment number is assigned 1 (sh o kern/165060 wireless [ath] vap->iv_bss race conditions causing crashes insi o kern/165021 wireless [ath] ath device timeout during scan/attach, if wlan_c o kern/164721 wireless [ath] ath device timeouts o kern/164499 wireless [wi] [patch] if_wi needs fix for big endian architectu o kern/164382 wireless [ath] crash when down/deleting a vap - inside ieee8021 o kern/164365 wireless [iwi] iwi0: UP/DOWN in o bin/164102 wireless hostapd not configured for 802.11n o kern/163759 wireless [ath] ath(4) "stops working" in hostap mode o kern/163724 wireless [mwl] [patch] NULL check before dereference o kern/163719 wireless [ath] ath interface do not receive multicast o kern/163689 wireless [ath] TX timeouts when sending probe/mgmt frames durin o kern/163574 wireless [net80211] overly-frequent HT occupancy changes o kern/163573 wireless [ath] hostap mode TX buffer hang o kern/163559 wireless [ath] kernel panic AH_DEBUG o kern/163318 wireless [ath] ath(4) stops working p kern/163312 wireless [panic] [ath driver] kernel panic: page fault with ath o kern/163237 wireless [ath] AR5416 as HostAP. Delays among clients when a cl o kern/163082 wireless [ath] ar9285 diversity fixes o kern/162648 wireless [ath] AR9227 ADC DC calibration failure o kern/162647 wireless [ath] 11n TX aggregation session / TX hang o kern/161293 wireless [iwn] hang at startup when starting network o kern/161035 wireless [ieee80211] Incorrect number describing 11ng MCS rate o kern/160391 wireless [ieee80211] [patch] Panic in mesh mode o kern/160296 wireless [zyd] [panic] 802.11 usb device reboots system on 'ifc o misc/160176 wireless [mips] [panic] Kernel panic on AR7161 platform with AR o kern/157449 wireless [ath] MAC address conflict causes system to freeze o kern/157243 wireless [ath] investigate beacon TX (AP) / RX (STA) when under o kern/156904 wireless [ath] AR9285 antenna diversity algorithm is buggy and o kern/156884 wireless [ath] ath instablity o kern/156327 wireless [bwn] bwn driver causes 20%-50% packet loss o kern/156322 wireless [wpi] no ahdemo support for if_wpi o kern/156321 wireless [ath] ahdemo doesn't work with if_ath o kern/155498 wireless [ral] ral(4) needs to be resynced with OpenBSD's to ga o kern/155100 wireless [ath] ath driver on busy channel: "stuck beacon" p kern/154598 wireless [ath] Atheros 5424/2424 can't connect to WPA network o kern/154567 wireless [ath] ath(4) lot of bad series(0) o kern/154327 wireless [ath] AR5416 in station mode hangs when transmitting f o kern/154284 wireless [ath] Modern ath wifi cards (such as AR9285) have miss o kern/154153 wireless [ath] AR5213 + MIPS + WPA group key packet corruption o kern/153594 wireless [wlan] netif/devd race o kern/153448 wireless [ath] ath networking device loses association after a o kern/152750 wireless [ath] ath0 lot of bad series hwrate o kern/151198 wireless [ath] ath/5416 fails bgscan with "ath0: ath_chan_set: o kern/149786 wireless [bwn] bwn on Dell Inspiron 1150: connections stall o kern/149516 wireless [ath] ath(4) hostap with fake MAC/BSSID results in sta o kern/149373 wireless [realtek/atheros]: None of my network card working o kern/148322 wireless [ath] Triggering atheros wifi beacon misses in hostap o kern/148317 wireless [ath] FreeBSD 7.x hostap memory leak in net80211 or At o kern/148078 wireless [ath] wireless networking stops functioning o kern/146426 wireless [mwl] 802.11n rates not possible on mwl o kern/146425 wireless [mwl] mwl dropping all packets during and after high u o kern/145826 wireless [panic] [ath] Unable to configure adhoc mode on ath0/w o kern/144987 wireless [wpi] [panic] injecting packets with wlaninject using o kern/144755 wireless [wlan] netif/devd race o bin/144109 wireless hostapd(8) uses the MAC of the wireless interface, but o conf/143079 wireless hostapd(8) startup missing multi wlan functionality p kern/140567 wireless [ath] [patch] ath is not worked on my notebook PC o kern/140245 wireless [ath] [panic] Kernel panic during network activity on o kern/137592 wireless [ath] panic - 7-STABLE (Aug 7, 2009 UTC) crashes on ne 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 kern/121061 wireless [ath] [panic] panic while ejecting ath(4)-adapter duri o docs/120456 wireless ath(4) needs to specify requirement on wlan_scan_sta o kern/119513 wireless [ath] [irq] inserting dlink dwl-g630 wireless card res o kern/116747 wireless [ndis] FreeBSD 7.0-CURRENT crash with Dell TrueMobile f kern/105348 wireless [ath] ath device stopps TX 153 problems total. From owner-freebsd-wireless@FreeBSD.ORG Mon Mar 25 16:36:52 2013 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id E624F2A8 for ; Mon, 25 Mar 2013 16:36:52 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) by mx1.freebsd.org (Postfix) with ESMTP id 73E97FFA for ; Mon, 25 Mar 2013 16:36:52 +0000 (UTC) Received: by mail-wi0-f173.google.com with SMTP id ez12so2293457wid.12 for ; Mon, 25 Mar 2013 09:36:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=eWw9YKEp2FIuH/yROmvi5v/J98mmNR7BiJfJ8r8+yS0=; b=uklx3xW/No/5OO7wgM8OYAjuO5RdF5NGlgHjEhpUsaSjNpUDqbeK89MTx6eBB3hp3p MeDXIWgYrvjhng+x9GSSbpckgHW5UItN9kEIfWAQiYM98oiqMmQdBlYu1YD19R5CEdYR PUMuFz+BVEjHlLDr0IuwyQluP4I5FTz9qPq8/FLfACXFGSgHFfcdp0afh23u9Is0QV6s Bgn7rToZvJdzEfQORenbCKZuNfwBTZTbw5pPTliySWrzFu16HbgGD2lJ6li3Fy8Ten53 eZVeW2g9PXi8nEJ7vS9OjGTljnic+n6DSgDDbHfAvt+QVNf3olr+1hhxoJ/OGEM9M0oF rWCQ== MIME-Version: 1.0 X-Received: by 10.180.81.232 with SMTP id d8mr17987595wiy.25.1364229408751; Mon, 25 Mar 2013 09:36:48 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.216.108.130 with HTTP; Mon, 25 Mar 2013 09:36:48 -0700 (PDT) In-Reply-To: References: Date: Mon, 25 Mar 2013 09:36:48 -0700 X-Google-Sender-Auth: WHgTF2CHmz3_MifWiH3s8vngYpc Message-ID: Subject: Re: AR9300 From: Adrian Chadd To: Mark Austin Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-wireless@freebsd.org X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list 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, 25 Mar 2013 16:36:53 -0000 Sweet. Looks good! Adrian On 25 March 2013 08:46, Mark Austin wrote: > Good news. I can see the device from the os tools now. It registers as > ath0, I also have a rule setup in my /etc/rc.conf to have ath0 identified > as wlan0. > > The kernel message log shows: > ath0: mem 0xc2400000-0xc247ffff irq 17 at device > 0.0 on pci3 > > ar9300_set_stub_functions: setting stub functions > > > ar9300_set_stub_functions: setting stub functions > > > ar9300_attach: calling ar9300_hw_attach > > > ar9300_hw_attach: calling ar9300_eeprom_attach > > > ar9300_flash_map: unimplemented for now > > > Restoring Cal data from DRAM > > > Restoring Cal data from EEPROM > > > Restoring Cal data from Flash > > > Restoring Cal data from Flash > > > Restoring Cal data from OTP > > > ar9300_hw_attach: ar9300_eeprom_attach returned 0 > ar9300_fill_capability_info: (MCI) MCI support = 1 > ath0: RX status length: 48 > ath0: RX buffer size: 4096 > ath0: TX descriptor length: 128 > ath0: TX status length: 36 > ath0: TX buffers per descriptor: 4 > ar9300_freebsd_setup_x_tx_desc: called, 0x0/0, 0x0/0, 0x0/0 > ath_hal_init_channels: cc=0, regdmn=240 > getchannels: cc 0 regDmn 0xf0 mode 0xffffff ecm > getregstate: EEPROM cc 0 rd 0x10 > getregstate: EEPROM rd 0x6c > getchannels: !avail mode 0x1f800d (0x2) flags 0x2150 > getchannels: !avail mode 0x1f800d (0x20) flags 0xd0 > getchannels: !avail mode 0x1f800d (0x40) flags 0x150 > getchannels: !avail mode 0x1f800d (0x400) flags 0x8140 > getchannels: !avail mode 0x1f800d (0x200) flags 0x4140 > getchannels: !avail mode 0x1f800d (0x1000) flags 0x8480 > getchannels: !avail mode 0x1f800d (0x800) flags 0x4480 > ath_hal_init_channels: status=0, currentRD=108 > assignPrivateChannels: private[ 0] 5180/0x80340 -> channel 5180 > assignPrivateChannels: private[ 1] 5200/0x80340 -> channel 5200 > assignPrivateChannels: private[ 2] 5220/0x80340 -> channel 5220 > assignPrivateChannels: private[ 3] 5240/0x80340 -> channel 5240 > assignPrivateChannels: private[ 4] 5260/0x80340 -> channel 5260 > assignPrivateChannels: private[ 5] 5280/0x80340 -> channel 5280 > assignPrivateChannels: private[ 6] 5300/0x80340 -> channel 5300 > assignPrivateChannels: private[ 7] 5320/0x80340 -> channel 5320 > assignPrivateChannels: private[ 8] 5745/0x340 -> channel 5745 > assignPrivateChannels: private[ 9] 5765/0x340 -> channel 5765 > assignPrivateChannels: private[ 10] 5785/0x340 -> channel 5785 > assignPrivateChannels: private[ 11] 5805/0x340 -> channel 5805 > assignPrivateChannels: private[ 12] 5825/0x340 -> channel 5825 > assignPrivateChannels: private[ 13] 5500/0x80340 -> channel 5500 > assignPrivateChannels: private[ 14] 5520/0x80340 -> channel 5520 > assignPrivateChannels: private[ 15] 5540/0x80340 -> channel 5540 > assignPrivateChannels: private[ 16] 5560/0x80340 -> channel 5560 > assignPrivateChannels: private[ 17] 5580/0x80340 -> channel 5580 > assignPrivateChannels: private[ 18] 5600/0x80340 -> channel 5600 > assignPrivateChannels: private[ 19] 5620/0x80340 -> channel 5620 > assignPrivateChannels: private[ 20] 5640/0x80340 -> channel 5640 > assignPrivateChannels: private[ 21] 5660/0x80340 -> channel 5660 > assignPrivateChannels: private[ 22] 5680/0x80340 -> channel 5680 > assignPrivateChannels: private[ 23] 5700/0x80340 -> channel 5700 > assignPrivateChannels: private[ 24] 2412/0xa0 -> channel 2412 > assignPrivateChannels: private[ 25] 2417/0xa0 -> channel 2417 > assignPrivateChannels: private[ 26] 2422/0xa0 -> channel 2422 > assignPrivateChannels: private[ 27] 2427/0xa0 -> channel 2427 > assignPrivateChannels: private[ 28] 2432/0xa0 -> channel 2432 > assignPrivateChannels: private[ 29] 2437/0xa0 -> channel 2437 > assignPrivateChannels: private[ 30] 2442/0xa0 -> channel 2442 > assignPrivateChannels: private[ 31] 2447/0xa0 -> channel 2447 > assignPrivateChannels: private[ 32] 2452/0xa0 -> channel 2452 > assignPrivateChannels: private[ 33] 2457/0xa0 -> channel 2457 > assignPrivateChannels: private[ 34] 2462/0xa0 -> channel 2462 > assignPrivateChannels: private[ 35] 2467/0x2a0 -> channel 2467 > assignPrivateChannels: private[ 36] 2472/0x2a0 -> channel 2472 > assignPrivateChannels: 109 public, 37 private channels > ath_hal_init_channels: cc 0 > ath_hal_update_dfsdomain ah_dfsDomain: 2 > ath0: ath_edma_setup_rxfifo: type=0, FIFO depth = 16 entries > ath0: ath_edma_setup_rxfifo: type=1, FIFO depth = 128 entries > ath0: [HT] enabling HT modes > ath0: [HT] enabling short-GI in 20MHz mode > ath0: [HT] 1 stream STBC receive enabled > ath0: [HT] 1 stream STBC transmit enabled > ath0: [HT] 2 RX streams; 2 TX streams > ath0: AR9460 mac 640.2 RF5110 phy 3389.0 > ath0: 2GHz radio: 0x0000; 5GHz radio: 0x0000 > wlan0: Ethernet address: 84:4b:f5:2e:7e:2b > > > Regards, > -Mark Austin > > All else is in doubt, so this is the truth that I cling to. > > My Website: http://www.silverdire.com > > > > On Mon, Mar 25, 2013 at 11:05 AM, Mark Austin wrote: > >> I didn't see any changes to the git tree. I updated my svn repo and >> rebuilding the kernel now. >> >> >> Regards, >> -Mark Austin >> >> All else is in doubt, so this is the truth that I cling to. >> >> My Website: http://www.silverdire.com >> >> >> >> On Mon, Mar 25, 2013 at 10:59 AM, Mark Austin wrote: >> >>> This was added to the -HEAD code base? >>> >>> >>> Regards, >>> -Mark Austin >>> >>> All else is in doubt, so this is the truth that I cling to. >>> >>> My Website: http://www.silverdire.com >>> >>> >>> >>> On Sun, Mar 24, 2013 at 12:43 AM, Adrian Chadd wrote: >>> >>>> Hi, >>>> >>>> I've just committed a new regulatory domain for you! >>>> >>>> >>>> >>>> Adrian >>>> >>>> >>>> On 22 March 2013 14:05, Mark Austin wrote: >>>> >>>>> Okay. I'll be available tonight and some parts over the weekend in >>>>> case you need any more testing. >>>>> >>>>> >>>>> Regards, >>>>> -Mark Austin >>>>> >>>>> All else is in doubt, so this is the truth that I cling to. >>>>> >>>>> My Website: http://www.silverdire.com >>>>> >>>>> >>>>> >>>>> On Fri, Mar 22, 2013 at 3:12 PM, Adrian Chadd wrote: >>>>> >>>>>> >>>>>> >>>>>> On 22 March 2013 12:11, Mark Austin wrote: >>>>>> >>>>>>> Okay. I made the 2 requested changes to the kernel source code and >>>>>>> changed my kenv var before reloading the module. >>>>>>> >>>>>>> The kernel messages log shows (my emphasis in bold): >>>>>>> >>>>>>> ** >>>>>>> >>>>>> >>>>>> >>>>>>> *Mar 22 19:02:49 asher kernel: ath_hal_init_channels: cc=0, >>>>>>> regdmn=240* >>>>>>> *Mar 22 19:02:49 asher kernel: getchannels: cc 0 regDmn 0xf0 mode >>>>>>> 0xffffff ecm* >>>>>>> *Mar 22 19:02:49 asher kernel: isEepromValid: invalid regulatory >>>>>>> domain/country code 0x6c* >>>>>>> *Mar 22 19:02:49 asher kernel: getregstate: invalid EEPROM contents* >>>>>>> *Mar 22 19:02:49 asher kernel: ath_hal_init_channels: status=16, >>>>>>> currentRD=108* >>>>>>> >>>>>> >>>>>> Right. I'm missing that regulatory domain. >>>>>> >>>>>> I'll have to go and look at what's missing and update the HAL >>>>>> regulatory domain. I'll start with that specific entry just so you can get >>>>>> working. >>>>>> >>>>>> >>>>>> Adrian >>>>>> >>>>>> >>>>> >>>>> >>>> >>> >> > From owner-freebsd-wireless@FreeBSD.ORG Mon Mar 25 18:27:52 2013 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 1C119F27 for ; Mon, 25 Mar 2013 18:27:52 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::22a]) by mx1.freebsd.org (Postfix) with ESMTP id 7DEA18C4 for ; Mon, 25 Mar 2013 18:27:51 +0000 (UTC) Received: by mail-wi0-f170.google.com with SMTP id hm11so11398732wib.5 for ; Mon, 25 Mar 2013 11:27:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=ZlAajRMYtl8w9NDZp8Op4bX48MdD9+aPEk9GXVPEdfY=; b=Hwk/akx9uUAe93jRoSLy3K+6zMXsm+KYf/2RU7W+R4cnIssXlbsJB2Z2VxYEIdNZSp 52RsAJuSiUtIy5zPUm9vOKLzPQBVWMWilhc2yN8fPDHXmLQgivP/gxblSnZMn56jKSDB xSvNZAJoirWGFcz1uJFNdQ8Pq2OrKBKj2nbDx5xyPMWvCd3DYyZP10y0sRwzuD3AUE5D NJ+b7dBmdkenQ9z5IK1NaeUbBWVz8tpwRCJg5hU0GTfJpB3RryamAl0nL5LimPscO4Xx MzxslME8g7JP54t6f/eSDvo1tXS2Afb0NtB2FO6bXrfJY3BkqZ3d2rL0ORagZGNUoBHk 50Sw== MIME-Version: 1.0 X-Received: by 10.194.171.74 with SMTP id as10mr19898159wjc.0.1364236070531; Mon, 25 Mar 2013 11:27:50 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.216.108.130 with HTTP; Mon, 25 Mar 2013 11:27:50 -0700 (PDT) In-Reply-To: References: Date: Mon, 25 Mar 2013 11:27:50 -0700 X-Google-Sender-Auth: YJkY1SNj5zKpBorn39fjOwABDJw Message-ID: Subject: Re: AR9300 From: Adrian Chadd To: Mark Austin Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-wireless@freebsd.org X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list 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, 25 Mar 2013 18:27:52 -0000 Ok, so hm. Try running wpa_supplicant manually. wpa_supplicant -i wlan0 -c /etc/wpa_supplicant.conf See if it throws errors. Adrian On 25 March 2013 11:17, Mark Austin wrote: > Great. > > Now, when I attempt to connect to a WPA2 encrypted network, I get the > following output on the device in the console: > > wlan0: flags=8c43 metric 0 > mtu 1500 > ether 84:4b:f5:2e:7e:2b > inet 0.0.0.0 netmask 0xff000000 broadcast 255.255.255.255 > nd6 options=29 > media: IEEE 802.11 Wireless Ethernet autoselect (autoselect) > status: no carrier > ssid tea channel 9 (2452 MHz 11g) > regdomain 108 indoor ecm authmode WPA privacy ON deftxkey UNDEF > txpower 20 bmiss 7 scanvalid 60 protmode CTS wme burst roaming > MANUAL > root@asher:/home/ganthore # > > DHCP appears to never pickup an ip address. (Tested on other systems, > works fine.) > > The ssid and authmode are correct... > > On /boot/loader.conf, I have if_ath_pci_load="YES" set. > > In /etc/rc.conf, I have the following params set: > > zfs_enable="YES" > ifconfig_bge0="inet 10.71.0.253 netmask 255.255.0.0" > defaultrouter="10.71.0.1" > wlans_ath0="wlan0" > ifconfig_wlan0="WPA DHCP" > > > > Regards, > -Mark Austin > > All else is in doubt, so this is the truth that I cling to. > > My Website: http://www.silverdire.com > > > > On Mon, Mar 25, 2013 at 12:36 PM, Adrian Chadd wrote: > >> Sweet. Looks good! >> >> >> >> Adrian >> >> >> On 25 March 2013 08:46, Mark Austin wrote: >> >>> Good news. I can see the device from the os tools now. It registers as >>> ath0, I also have a rule setup in my /etc/rc.conf to have ath0 identified >>> as wlan0. >>> >>> The kernel message log shows: >>> ath0: mem 0xc2400000-0xc247ffff irq 17 at device >>> 0.0 on pci3 >>> >>> ar9300_set_stub_functions: setting stub functions >>> >>> >>> ar9300_set_stub_functions: setting stub functions >>> >>> >>> ar9300_attach: calling ar9300_hw_attach >>> >>> >>> ar9300_hw_attach: calling ar9300_eeprom_attach >>> >>> >>> ar9300_flash_map: unimplemented for now >>> >>> >>> Restoring Cal data from DRAM >>> >>> >>> Restoring Cal data from EEPROM >>> >>> >>> Restoring Cal data from Flash >>> >>> >>> Restoring Cal data from Flash >>> >>> >>> Restoring Cal data from OTP >>> >>> >>> ar9300_hw_attach: ar9300_eeprom_attach returned 0 >>> ar9300_fill_capability_info: (MCI) MCI support = 1 >>> ath0: RX status length: 48 >>> ath0: RX buffer size: 4096 >>> ath0: TX descriptor length: 128 >>> ath0: TX status length: 36 >>> ath0: TX buffers per descriptor: 4 >>> ar9300_freebsd_setup_x_tx_desc: called, 0x0/0, 0x0/0, 0x0/0 >>> ath_hal_init_channels: cc=0, regdmn=240 >>> getchannels: cc 0 regDmn 0xf0 mode 0xffffff ecm >>> getregstate: EEPROM cc 0 rd 0x10 >>> getregstate: EEPROM rd 0x6c >>> getchannels: !avail mode 0x1f800d (0x2) flags 0x2150 >>> getchannels: !avail mode 0x1f800d (0x20) flags 0xd0 >>> getchannels: !avail mode 0x1f800d (0x40) flags 0x150 >>> getchannels: !avail mode 0x1f800d (0x400) flags 0x8140 >>> getchannels: !avail mode 0x1f800d (0x200) flags 0x4140 >>> getchannels: !avail mode 0x1f800d (0x1000) flags 0x8480 >>> getchannels: !avail mode 0x1f800d (0x800) flags 0x4480 >>> ath_hal_init_channels: status=0, currentRD=108 >>> assignPrivateChannels: private[ 0] 5180/0x80340 -> channel 5180 >>> assignPrivateChannels: private[ 1] 5200/0x80340 -> channel 5200 >>> assignPrivateChannels: private[ 2] 5220/0x80340 -> channel 5220 >>> assignPrivateChannels: private[ 3] 5240/0x80340 -> channel 5240 >>> assignPrivateChannels: private[ 4] 5260/0x80340 -> channel 5260 >>> assignPrivateChannels: private[ 5] 5280/0x80340 -> channel 5280 >>> assignPrivateChannels: private[ 6] 5300/0x80340 -> channel 5300 >>> assignPrivateChannels: private[ 7] 5320/0x80340 -> channel 5320 >>> assignPrivateChannels: private[ 8] 5745/0x340 -> channel 5745 >>> assignPrivateChannels: private[ 9] 5765/0x340 -> channel 5765 >>> assignPrivateChannels: private[ 10] 5785/0x340 -> channel 5785 >>> assignPrivateChannels: private[ 11] 5805/0x340 -> channel 5805 >>> assignPrivateChannels: private[ 12] 5825/0x340 -> channel 5825 >>> assignPrivateChannels: private[ 13] 5500/0x80340 -> channel 5500 >>> assignPrivateChannels: private[ 14] 5520/0x80340 -> channel 5520 >>> assignPrivateChannels: private[ 15] 5540/0x80340 -> channel 5540 >>> assignPrivateChannels: private[ 16] 5560/0x80340 -> channel 5560 >>> assignPrivateChannels: private[ 17] 5580/0x80340 -> channel 5580 >>> assignPrivateChannels: private[ 18] 5600/0x80340 -> channel 5600 >>> assignPrivateChannels: private[ 19] 5620/0x80340 -> channel 5620 >>> assignPrivateChannels: private[ 20] 5640/0x80340 -> channel 5640 >>> assignPrivateChannels: private[ 21] 5660/0x80340 -> channel 5660 >>> assignPrivateChannels: private[ 22] 5680/0x80340 -> channel 5680 >>> assignPrivateChannels: private[ 23] 5700/0x80340 -> channel 5700 >>> assignPrivateChannels: private[ 24] 2412/0xa0 -> channel 2412 >>> assignPrivateChannels: private[ 25] 2417/0xa0 -> channel 2417 >>> assignPrivateChannels: private[ 26] 2422/0xa0 -> channel 2422 >>> assignPrivateChannels: private[ 27] 2427/0xa0 -> channel 2427 >>> assignPrivateChannels: private[ 28] 2432/0xa0 -> channel 2432 >>> assignPrivateChannels: private[ 29] 2437/0xa0 -> channel 2437 >>> assignPrivateChannels: private[ 30] 2442/0xa0 -> channel 2442 >>> assignPrivateChannels: private[ 31] 2447/0xa0 -> channel 2447 >>> assignPrivateChannels: private[ 32] 2452/0xa0 -> channel 2452 >>> assignPrivateChannels: private[ 33] 2457/0xa0 -> channel 2457 >>> assignPrivateChannels: private[ 34] 2462/0xa0 -> channel 2462 >>> assignPrivateChannels: private[ 35] 2467/0x2a0 -> channel 2467 >>> assignPrivateChannels: private[ 36] 2472/0x2a0 -> channel 2472 >>> assignPrivateChannels: 109 public, 37 private channels >>> ath_hal_init_channels: cc 0 >>> ath_hal_update_dfsdomain ah_dfsDomain: 2 >>> ath0: ath_edma_setup_rxfifo: type=0, FIFO depth = 16 entries >>> ath0: ath_edma_setup_rxfifo: type=1, FIFO depth = 128 entries >>> ath0: [HT] enabling HT modes >>> ath0: [HT] enabling short-GI in 20MHz mode >>> ath0: [HT] 1 stream STBC receive enabled >>> ath0: [HT] 1 stream STBC transmit enabled >>> ath0: [HT] 2 RX streams; 2 TX streams >>> ath0: AR9460 mac 640.2 RF5110 phy 3389.0 >>> ath0: 2GHz radio: 0x0000; 5GHz radio: 0x0000 >>> wlan0: Ethernet address: 84:4b:f5:2e:7e:2b >>> >>> >>> Regards, >>> -Mark Austin >>> >>> All else is in doubt, so this is the truth that I cling to. >>> >>> My Website: http://www.silverdire.com >>> >>> >>> >>> On Mon, Mar 25, 2013 at 11:05 AM, Mark Austin wrote: >>> >>>> I didn't see any changes to the git tree. I updated my svn repo and >>>> rebuilding the kernel now. >>>> >>>> >>>> Regards, >>>> -Mark Austin >>>> >>>> All else is in doubt, so this is the truth that I cling to. >>>> >>>> My Website: http://www.silverdire.com >>>> >>>> >>>> >>>> On Mon, Mar 25, 2013 at 10:59 AM, Mark Austin wrote: >>>> >>>>> This was added to the -HEAD code base? >>>>> >>>>> >>>>> Regards, >>>>> -Mark Austin >>>>> >>>>> All else is in doubt, so this is the truth that I cling to. >>>>> >>>>> My Website: http://www.silverdire.com >>>>> >>>>> >>>>> >>>>> On Sun, Mar 24, 2013 at 12:43 AM, Adrian Chadd wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> I've just committed a new regulatory domain for you! >>>>>> >>>>>> >>>>>> >>>>>> Adrian >>>>>> >>>>>> >>>>>> On 22 March 2013 14:05, Mark Austin wrote: >>>>>> >>>>>>> Okay. I'll be available tonight and some parts over the weekend in >>>>>>> case you need any more testing. >>>>>>> >>>>>>> >>>>>>> Regards, >>>>>>> -Mark Austin >>>>>>> >>>>>>> All else is in doubt, so this is the truth that I cling to. >>>>>>> >>>>>>> My Website: http://www.silverdire.com >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Fri, Mar 22, 2013 at 3:12 PM, Adrian Chadd wrote: >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On 22 March 2013 12:11, Mark Austin wrote: >>>>>>>> >>>>>>>>> Okay. I made the 2 requested changes to the kernel source code and >>>>>>>>> changed my kenv var before reloading the module. >>>>>>>>> >>>>>>>>> The kernel messages log shows (my emphasis in bold): >>>>>>>>> >>>>>>>>> ** >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> *Mar 22 19:02:49 asher kernel: ath_hal_init_channels: cc=0, >>>>>>>>> regdmn=240* >>>>>>>>> *Mar 22 19:02:49 asher kernel: getchannels: cc 0 regDmn 0xf0 >>>>>>>>> mode 0xffffff ecm* >>>>>>>>> *Mar 22 19:02:49 asher kernel: isEepromValid: invalid regulatory >>>>>>>>> domain/country code 0x6c* >>>>>>>>> *Mar 22 19:02:49 asher kernel: getregstate: invalid EEPROM >>>>>>>>> contents* >>>>>>>>> *Mar 22 19:02:49 asher kernel: ath_hal_init_channels: status=16, >>>>>>>>> currentRD=108* >>>>>>>>> >>>>>>>> >>>>>>>> Right. I'm missing that regulatory domain. >>>>>>>> >>>>>>>> I'll have to go and look at what's missing and update the HAL >>>>>>>> regulatory domain. I'll start with that specific entry just so you can get >>>>>>>> working. >>>>>>>> >>>>>>>> >>>>>>>> Adrian >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > From owner-freebsd-wireless@FreeBSD.ORG Mon Mar 25 19:37:15 2013 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 0319D2D1 for ; Mon, 25 Mar 2013 19:37:15 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) by mx1.freebsd.org (Postfix) with ESMTP id 5EE3ACE2 for ; Mon, 25 Mar 2013 19:37:14 +0000 (UTC) Received: by mail-wi0-f181.google.com with SMTP id hj8so3422909wib.8 for ; Mon, 25 Mar 2013 12:37:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=ztSQpVwyS3Aq0Mn6dTlkKg6rL3L+OguLDDtj4GMj2v0=; b=FVa9QWyq5nPqp311OOv4apRvXyg+3HPhKHUlg7ZYDp7CjPpbmIeuZdAblsX8p8r6T/ vSbG/EDqVPHRkqpztu12yz8qjy/zCHKY3D9pCNZysB3QTfc+e5N7tskAI91VELh2SetW 4b+QFXr8bWipCgj1d1jrelexO+EGJ7A1XAWOUKIFClaEXdwkk1PxnLpq8iVa4GKATs3i yzACV9KC2HC2Mmr7SFLfbuhqdJqsDvo6TgmWF5MwwSTDHz0kveF8c5N+JaPmskE9fIfd 32WDAcEbd1/gYuLmrbF4vVREdbPtmZctyyUv42bSbWGkBEOC/wqYltIdHQWFWo3AByEp yGfw== MIME-Version: 1.0 X-Received: by 10.194.120.169 with SMTP id ld9mr20281371wjb.24.1364240233417; Mon, 25 Mar 2013 12:37:13 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.216.108.130 with HTTP; Mon, 25 Mar 2013 12:37:13 -0700 (PDT) In-Reply-To: References: Date: Mon, 25 Mar 2013 12:37:13 -0700 X-Google-Sender-Auth: 3aCtszV-EcyK1ncYXz901NH5esY Message-ID: Subject: Re: AR9300 From: Adrian Chadd To: Mark Austin Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-wireless@freebsd.org X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list 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, 25 Mar 2013 19:37:15 -0000 Ok. Hm. I'm seeing the same in hostap mode. I wonder if I broke something. I'll go do some further digging and let you know. You could try this: wlandebug -i wlan0 +crypto +assoc see if it gives you any further useful debugging. Adrian On 25 March 2013 12:11, Mark Austin wrote: > Okay. I removed the line, killed off wpa_supplicant and started a new > daemon. Logging still drops: > > Trying to associate with 00:1f:6d:b8:c1:e1 (SSID='tea' freq=2422 MHz) > Associated with 00:1f:6d:b8:c1:e1 > WPA: Key negotiation completed with 00:1f:6d:b8:c1:e1 [PTK=TKIP GTK=TKIP] > CTRL-EVENT-CONNECTED - Connection to 00:1f:6d:b8:c1:e1 completed (reauth) > [id=0 id_str=] > WPA: Group rekeying completed with 00:1f:6d:b8:c1:e1 [GTK=TKIP] > WPA: Group rekeying completed with 00:1f:6d:b8:c1:e1 [GTK=TKIP] > CTRL-EVENT-DISCONNECTED bssid=00:1f:6d:b8:c1:e1 reason=0 > > > > Regards, > -Mark Austin > > All else is in doubt, so this is the truth that I cling to. > > My Website: http://www.silverdire.com > > > > On Mon, Mar 25, 2013 at 2:42 PM, Adrian Chadd wrote: > >> That's just due to channel scanning. It's harmless. >> >> Just remove the key_mgmt line, it's not needed for WPA/WPA2. >> >> >> >> Adrian >> >> >> On 25 March 2013 11:33, Mark Austin wrote: >> >>> In addition, the kernel outputs this a lot: >>> ath0: ath_edma_recv_proc_queue: handled npkts 0 >>> >>> >>> Regards, >>> -Mark Austin >>> >>> All else is in doubt, so this is the truth that I cling to. >>> >>> My Website: http://www.silverdire.com >>> >>> >>> >>> On Mon, Mar 25, 2013 at 2:32 PM, Mark Austin wrote: >>> >>>> ctrl_interface=/var/run/wpa_supplicant >>>> ctrl_interface_group=wheel >>>> update_config=1 >>>> >>>> network={ >>>> ssid="tea" >>>> psk="removed the password for obvious reasons" >>>> key_mgmt=WPA-PSK >>>> } >>>> >>>> >>>> >>>> Regards, >>>> -Mark Austin >>>> >>>> All else is in doubt, so this is the truth that I cling to. >>>> >>>> My Website: http://www.silverdire.com >>>> >>>> >>>> >>>> On Mon, Mar 25, 2013 at 2:31 PM, Mark Austin wrote: >>>> >>>>> wpa_supplicant logs: >>>>> >>>>> Trying to associate with 00:1f:6d:b8:c1:e1 (SSID='tea' freq=2422 MHz) >>>>> Associated with 00:1f:6d:b8:c1:e1 >>>>> *WPA: Key negotiation completed with 00:1f:6d:b8:c1:e1 [PTK=TKIP >>>>> GTK=TKIP]* >>>>> CTRL-EVENT-CONNECTED - Connection to 00:1f:6d:b8:c1:e1 completed >>>>> (reauth) [id=0 id_str=] >>>>> WPA: Group rekeying completed with 00:1f:6d:b8:c1:e1 [GTK=TKIP] >>>>> WPA: Group rekeying completed with 00:1f:6d:b8:c1:e1 [GTK=TKIP] >>>>> CTRL-EVENT-DISCONNECTED bssid=00:1f:6d:b8:c1:e1 *reason=0* >>>>> * >>>>> * >>>>> My test wpa_supplicant.conf file is: >>>>> >>>>> >>>>> >>>>> >>>>> Regards, >>>>> -Mark Austin >>>>> >>>>> All else is in doubt, so this is the truth that I cling to. >>>>> >>>>> My Website: http://www.silverdire.com >>>>> >>>>> >>>>> >>>>> On Mon, Mar 25, 2013 at 2:27 PM, Adrian Chadd wrote: >>>>> >>>>>> Ok, so hm. Try running wpa_supplicant manually. >>>>>> >>>>>> wpa_supplicant -i wlan0 -c /etc/wpa_supplicant.conf >>>>>> >>>>>> See if it throws errors. >>>>>> >>>>>> >>>>>> >>>>>> Adrian >>>>>> >>>>>> >>>>>> On 25 March 2013 11:17, Mark Austin wrote: >>>>>> >>>>>>> Great. >>>>>>> >>>>>>> Now, when I attempt to connect to a WPA2 encrypted network, I get >>>>>>> the following output on the device in the console: >>>>>>> >>>>>>> wlan0: flags=8c43 >>>>>>> metric 0 mtu 1500 >>>>>>> ether 84:4b:f5:2e:7e:2b >>>>>>> inet 0.0.0.0 netmask 0xff000000 broadcast 255.255.255.255 >>>>>>> nd6 options=29 >>>>>>> media: IEEE 802.11 Wireless Ethernet autoselect (autoselect) >>>>>>> status: no carrier >>>>>>> ssid tea channel 9 (2452 MHz 11g) >>>>>>> regdomain 108 indoor ecm authmode WPA privacy ON deftxkey >>>>>>> UNDEF >>>>>>> txpower 20 bmiss 7 scanvalid 60 protmode CTS wme burst >>>>>>> roaming MANUAL >>>>>>> root@asher:/home/ganthore # >>>>>>> >>>>>>> DHCP appears to never pickup an ip address. (Tested on other >>>>>>> systems, works fine.) >>>>>>> >>>>>>> The ssid and authmode are correct... >>>>>>> >>>>>>> On /boot/loader.conf, I have if_ath_pci_load="YES" set. >>>>>>> >>>>>>> In /etc/rc.conf, I have the following params set: >>>>>>> >>>>>>> zfs_enable="YES" >>>>>>> ifconfig_bge0="inet 10.71.0.253 netmask 255.255.0.0" >>>>>>> defaultrouter="10.71.0.1" >>>>>>> wlans_ath0="wlan0" >>>>>>> ifconfig_wlan0="WPA DHCP" >>>>>>> >>>>>>> >>>>>>> >>>>>>> Regards, >>>>>>> -Mark Austin >>>>>>> >>>>>>> All else is in doubt, so this is the truth that I cling to. >>>>>>> >>>>>>> My Website: http://www.silverdire.com >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Mon, Mar 25, 2013 at 12:36 PM, Adrian Chadd wrote: >>>>>>> >>>>>>>> Sweet. Looks good! >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Adrian >>>>>>>> >>>>>>>> >>>>>>>> On 25 March 2013 08:46, Mark Austin wrote: >>>>>>>> >>>>>>>>> Good news. I can see the device from the os tools now. It >>>>>>>>> registers as ath0, I also have a rule setup in my /etc/rc.conf to have ath0 >>>>>>>>> identified as wlan0. >>>>>>>>> >>>>>>>>> The kernel message log shows: >>>>>>>>> ath0: mem 0xc2400000-0xc247ffff irq 17 at >>>>>>>>> device 0.0 on pci3 >>>>>>>>> >>>>>>>>> ar9300_set_stub_functions: setting stub functions >>>>>>>>> >>>>>>>>> >>>>>>>>> ar9300_set_stub_functions: setting stub functions >>>>>>>>> >>>>>>>>> >>>>>>>>> ar9300_attach: calling ar9300_hw_attach >>>>>>>>> >>>>>>>>> >>>>>>>>> ar9300_hw_attach: calling ar9300_eeprom_attach >>>>>>>>> >>>>>>>>> >>>>>>>>> ar9300_flash_map: unimplemented for now >>>>>>>>> >>>>>>>>> >>>>>>>>> Restoring Cal data from DRAM >>>>>>>>> >>>>>>>>> >>>>>>>>> Restoring Cal data from EEPROM >>>>>>>>> >>>>>>>>> >>>>>>>>> Restoring Cal data from Flash >>>>>>>>> >>>>>>>>> >>>>>>>>> Restoring Cal data from Flash >>>>>>>>> >>>>>>>>> >>>>>>>>> Restoring Cal data from OTP >>>>>>>>> >>>>>>>>> >>>>>>>>> ar9300_hw_attach: ar9300_eeprom_attach returned 0 >>>>>>>>> ar9300_fill_capability_info: (MCI) MCI support = 1 >>>>>>>>> ath0: RX status length: 48 >>>>>>>>> ath0: RX buffer size: 4096 >>>>>>>>> ath0: TX descriptor length: 128 >>>>>>>>> ath0: TX status length: 36 >>>>>>>>> ath0: TX buffers per descriptor: 4 >>>>>>>>> ar9300_freebsd_setup_x_tx_desc: called, 0x0/0, 0x0/0, 0x0/0 >>>>>>>>> ath_hal_init_channels: cc=0, regdmn=240 >>>>>>>>> getchannels: cc 0 regDmn 0xf0 mode 0xffffff ecm >>>>>>>>> getregstate: EEPROM cc 0 rd 0x10 >>>>>>>>> getregstate: EEPROM rd 0x6c >>>>>>>>> getchannels: !avail mode 0x1f800d (0x2) flags 0x2150 >>>>>>>>> getchannels: !avail mode 0x1f800d (0x20) flags 0xd0 >>>>>>>>> getchannels: !avail mode 0x1f800d (0x40) flags 0x150 >>>>>>>>> getchannels: !avail mode 0x1f800d (0x400) flags 0x8140 >>>>>>>>> getchannels: !avail mode 0x1f800d (0x200) flags 0x4140 >>>>>>>>> getchannels: !avail mode 0x1f800d (0x1000) flags 0x8480 >>>>>>>>> getchannels: !avail mode 0x1f800d (0x800) flags 0x4480 >>>>>>>>> ath_hal_init_channels: status=0, currentRD=108 >>>>>>>>> assignPrivateChannels: private[ 0] 5180/0x80340 -> channel 5180 >>>>>>>>> assignPrivateChannels: private[ 1] 5200/0x80340 -> channel 5200 >>>>>>>>> assignPrivateChannels: private[ 2] 5220/0x80340 -> channel 5220 >>>>>>>>> assignPrivateChannels: private[ 3] 5240/0x80340 -> channel 5240 >>>>>>>>> assignPrivateChannels: private[ 4] 5260/0x80340 -> channel 5260 >>>>>>>>> assignPrivateChannels: private[ 5] 5280/0x80340 -> channel 5280 >>>>>>>>> assignPrivateChannels: private[ 6] 5300/0x80340 -> channel 5300 >>>>>>>>> assignPrivateChannels: private[ 7] 5320/0x80340 -> channel 5320 >>>>>>>>> assignPrivateChannels: private[ 8] 5745/0x340 -> channel 5745 >>>>>>>>> assignPrivateChannels: private[ 9] 5765/0x340 -> channel 5765 >>>>>>>>> assignPrivateChannels: private[ 10] 5785/0x340 -> channel 5785 >>>>>>>>> assignPrivateChannels: private[ 11] 5805/0x340 -> channel 5805 >>>>>>>>> assignPrivateChannels: private[ 12] 5825/0x340 -> channel 5825 >>>>>>>>> assignPrivateChannels: private[ 13] 5500/0x80340 -> channel 5500 >>>>>>>>> assignPrivateChannels: private[ 14] 5520/0x80340 -> channel 5520 >>>>>>>>> assignPrivateChannels: private[ 15] 5540/0x80340 -> channel 5540 >>>>>>>>> assignPrivateChannels: private[ 16] 5560/0x80340 -> channel 5560 >>>>>>>>> assignPrivateChannels: private[ 17] 5580/0x80340 -> channel 5580 >>>>>>>>> assignPrivateChannels: private[ 18] 5600/0x80340 -> channel 5600 >>>>>>>>> assignPrivateChannels: private[ 19] 5620/0x80340 -> channel 5620 >>>>>>>>> assignPrivateChannels: private[ 20] 5640/0x80340 -> channel 5640 >>>>>>>>> assignPrivateChannels: private[ 21] 5660/0x80340 -> channel 5660 >>>>>>>>> assignPrivateChannels: private[ 22] 5680/0x80340 -> channel 5680 >>>>>>>>> assignPrivateChannels: private[ 23] 5700/0x80340 -> channel 5700 >>>>>>>>> assignPrivateChannels: private[ 24] 2412/0xa0 -> channel 2412 >>>>>>>>> assignPrivateChannels: private[ 25] 2417/0xa0 -> channel 2417 >>>>>>>>> assignPrivateChannels: private[ 26] 2422/0xa0 -> channel 2422 >>>>>>>>> assignPrivateChannels: private[ 27] 2427/0xa0 -> channel 2427 >>>>>>>>> assignPrivateChannels: private[ 28] 2432/0xa0 -> channel 2432 >>>>>>>>> assignPrivateChannels: private[ 29] 2437/0xa0 -> channel 2437 >>>>>>>>> assignPrivateChannels: private[ 30] 2442/0xa0 -> channel 2442 >>>>>>>>> assignPrivateChannels: private[ 31] 2447/0xa0 -> channel 2447 >>>>>>>>> assignPrivateChannels: private[ 32] 2452/0xa0 -> channel 2452 >>>>>>>>> assignPrivateChannels: private[ 33] 2457/0xa0 -> channel 2457 >>>>>>>>> assignPrivateChannels: private[ 34] 2462/0xa0 -> channel 2462 >>>>>>>>> assignPrivateChannels: private[ 35] 2467/0x2a0 -> channel 2467 >>>>>>>>> assignPrivateChannels: private[ 36] 2472/0x2a0 -> channel 2472 >>>>>>>>> assignPrivateChannels: 109 public, 37 private channels >>>>>>>>> ath_hal_init_channels: cc 0 >>>>>>>>> ath_hal_update_dfsdomain ah_dfsDomain: 2 >>>>>>>>> ath0: ath_edma_setup_rxfifo: type=0, FIFO depth = 16 entries >>>>>>>>> ath0: ath_edma_setup_rxfifo: type=1, FIFO depth = 128 entries >>>>>>>>> ath0: [HT] enabling HT modes >>>>>>>>> ath0: [HT] enabling short-GI in 20MHz mode >>>>>>>>> ath0: [HT] 1 stream STBC receive enabled >>>>>>>>> ath0: [HT] 1 stream STBC transmit enabled >>>>>>>>> ath0: [HT] 2 RX streams; 2 TX streams >>>>>>>>> ath0: AR9460 mac 640.2 RF5110 phy 3389.0 >>>>>>>>> ath0: 2GHz radio: 0x0000; 5GHz radio: 0x0000 >>>>>>>>> wlan0: Ethernet address: 84:4b:f5:2e:7e:2b >>>>>>>>> >>>>>>>>> >>>>>>>>> Regards, >>>>>>>>> -Mark Austin >>>>>>>>> >>>>>>>>> All else is in doubt, so this is the truth that I cling to. >>>>>>>>> >>>>>>>>> My Website: http://www.silverdire.com >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Mon, Mar 25, 2013 at 11:05 AM, Mark Austin wrote: >>>>>>>>> >>>>>>>>>> I didn't see any changes to the git tree. I updated my svn repo >>>>>>>>>> and rebuilding the kernel now. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Regards, >>>>>>>>>> -Mark Austin >>>>>>>>>> >>>>>>>>>> All else is in doubt, so this is the truth that I cling to. >>>>>>>>>> >>>>>>>>>> My Website: http://www.silverdire.com >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Mon, Mar 25, 2013 at 10:59 AM, Mark Austin >>>>>>>>> > wrote: >>>>>>>>>> >>>>>>>>>>> This was added to the -HEAD code base? >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Regards, >>>>>>>>>>> -Mark Austin >>>>>>>>>>> >>>>>>>>>>> All else is in doubt, so this is the truth that I cling to. >>>>>>>>>>> >>>>>>>>>>> My Website: http://www.silverdire.com >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Sun, Mar 24, 2013 at 12:43 AM, Adrian Chadd < >>>>>>>>>>> adrian@freebsd.org> wrote: >>>>>>>>>>> >>>>>>>>>>>> Hi, >>>>>>>>>>>> >>>>>>>>>>>> I've just committed a new regulatory domain for you! >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Adrian >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 22 March 2013 14:05, Mark Austin wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Okay. I'll be available tonight and some parts over the >>>>>>>>>>>>> weekend in case you need any more testing. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Regards, >>>>>>>>>>>>> -Mark Austin >>>>>>>>>>>>> >>>>>>>>>>>>> All else is in doubt, so this is the truth that I cling to. >>>>>>>>>>>>> >>>>>>>>>>>>> My Website: http://www.silverdire.com >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On Fri, Mar 22, 2013 at 3:12 PM, Adrian Chadd < >>>>>>>>>>>>> adrian@freebsd.org> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 22 March 2013 12:11, Mark Austin wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Okay. I made the 2 requested changes to the kernel source >>>>>>>>>>>>>>> code and changed my kenv var before reloading the module. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> The kernel messages log shows (my emphasis in bold): >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> ** >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> *Mar 22 19:02:49 asher kernel: ath_hal_init_channels: cc=0, >>>>>>>>>>>>>>> regdmn=240* >>>>>>>>>>>>>>> *Mar 22 19:02:49 asher kernel: getchannels: cc 0 regDmn >>>>>>>>>>>>>>> 0xf0 mode 0xffffff ecm* >>>>>>>>>>>>>>> *Mar 22 19:02:49 asher kernel: isEepromValid: invalid >>>>>>>>>>>>>>> regulatory domain/country code 0x6c* >>>>>>>>>>>>>>> *Mar 22 19:02:49 asher kernel: getregstate: invalid EEPROM >>>>>>>>>>>>>>> contents* >>>>>>>>>>>>>>> *Mar 22 19:02:49 asher kernel: ath_hal_init_channels: >>>>>>>>>>>>>>> status=16, currentRD=108* >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Right. I'm missing that regulatory domain. >>>>>>>>>>>>>> >>>>>>>>>>>>>> I'll have to go and look at what's missing and update the HAL >>>>>>>>>>>>>> regulatory domain. I'll start with that specific entry just so you can get >>>>>>>>>>>>>> working. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Adrian >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > From owner-freebsd-wireless@FreeBSD.ORG Mon Mar 25 21:54:08 2013 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id E72B21D1 for ; Mon, 25 Mar 2013 21:54:08 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) by mx1.freebsd.org (Postfix) with ESMTP id 709CF36B for ; Mon, 25 Mar 2013 21:54:08 +0000 (UTC) Received: by mail-wi0-f179.google.com with SMTP id hn17so4604575wib.0 for ; Mon, 25 Mar 2013 14:54:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=v83sMvgJJ+4Wdnqkz1e86UvVlbgAcohizlOKVQsxnME=; b=fyBuWTegTJ7/FHXzrYFUgRN5L1SIulxOzMVjhle2oe2uoHottKcwSqif5giWLxZ4QW ill7QrASrPVh/4uVRGvoLUYng2+ohRA4aYpbWEm9kOYHCQrKxYHqyXM7eRRaOJmHxzoB n3y37fOWu7dVOuyu1Sk+D2ob6ixVaHTvr0/VcGt/vYivHABro3Kmglo7FxWhjL285cgL L4GCfENsZ1NQAXqYDD16QZfPNnFuaQYE4J88LlAhgOgOInf8njQ5M2edoneAE2ybVe31 i0+OweJDU9MtPe4o3m/gToYQnNmS3tjpSAZvxYzSBNmlL1cuxigYT5iJxEXfiOGLYQdp pS3Q== MIME-Version: 1.0 X-Received: by 10.180.74.131 with SMTP id t3mr19971277wiv.26.1364248447575; Mon, 25 Mar 2013 14:54:07 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.216.108.130 with HTTP; Mon, 25 Mar 2013 14:54:07 -0700 (PDT) In-Reply-To: References: Date: Mon, 25 Mar 2013 14:54:07 -0700 X-Google-Sender-Auth: pXgcZBIM23JYSt0QtJgKQM0gC2c Message-ID: Subject: Re: AR9300 From: Adrian Chadd To: Mark Austin Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-wireless@freebsd.org X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list 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, 25 Mar 2013 21:54:09 -0000 Hi, Please update the git repository and try again. I just fixed the TKIP key programming in the AR9300 HAL. Adrian From owner-freebsd-wireless@FreeBSD.ORG Mon Mar 25 23:13:20 2013 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 93F29FF2 for ; Mon, 25 Mar 2013 23:13:20 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-we0-x233.google.com (mail-we0-x233.google.com [IPv6:2a00:1450:400c:c03::233]) by mx1.freebsd.org (Postfix) with ESMTP id 3525C8F0 for ; Mon, 25 Mar 2013 23:13:20 +0000 (UTC) Received: by mail-we0-f179.google.com with SMTP id u3so5656951wey.24 for ; Mon, 25 Mar 2013 16:13:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:date:x-google-sender-auth:message-id :subject:from:to:content-type; bh=/+uO/Z/4P4CCzG1lSWxndZ1u13cVhG90IIrHOpHe+wI=; b=0Z3TmZ+BghGOnZf3zmu3jE9sxoO6S1Li9H8MaNgufFBzwLEpF1H9bPfmgG6fQo9da+ Z0F+MFfc0pXB7Gxp/9GiTVrgHdKUUqdnXPvYiYfos5RWWBA447leG4EEWFYDvXFl52cS jH7nUtr4RmUNVPTnxMtwP6ijv/ArbwcacAKEziVMSJvqAuNXghYOT+0cE0WmiN0hMitJ 7W1gmaa8KOJk3wPq+00ueuowOHzXUgLbedqnYzS3CcLRqjMXvQZ5kLMGs4CpIHNrDuKu Q5s17BirF8vZmJkfgO7sdaoipDyKdwkf00jko2iuORI82YYFt2OSPyNUdvRK+4Wq9z9G q8pA== MIME-Version: 1.0 X-Received: by 10.194.171.74 with SMTP id as10mr21044099wjc.0.1364253199354; Mon, 25 Mar 2013 16:13:19 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.216.108.130 with HTTP; Mon, 25 Mar 2013 16:13:19 -0700 (PDT) Date: Mon, 25 Mar 2013 16:13:19 -0700 X-Google-Sender-Auth: hRFQ_SAqlbyjCCkwPOQNvh_to0o Message-ID: Subject: [wip] ar9300 hostap support From: Adrian Chadd To: freebsd-wireless@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Discussions of 802.11 stack, tools device driver development." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Mar 2013 23:13:20 -0000 Hi, I've been working on AR9380 HAL hostap support in my spare time. Here's where I'm at so far: http://people.freebsd.org/~adrian/ath/20130325-cabq-edma-txq-rework-3.diff Now, this is not likely what I'm going to push into -HEAD. But it's being stable for me for now, save some odd crashes that have been reported with TX completion on the AR9380 chips. Now, what's going on and what I have to stage into -HEAD: * The whole descriptor linking thing is just plain wrong for the AR9380 chips. I have to nuke axq_link from orbit and use ath_hal_settxdesclink(). This requires some manual fiddling of things in a variety of places in both the pre-AR9380 chips and the AR9380 chips - it's used for CABQ assembly, for beacon programming, for general unicast traffic programming ... eek. * The CABQ assembly code needed to be tweaked for EDMA. Now I have to populate the whole list of CABQ frames (with the correct link pointers as listed above) before I can push that list into the hardware FIFO. * I need to separate out the FIFO contents from the pending TX queue in each hardware TXQ. Right now my EDMA TX code just pushes individual MPDU or AMPDU frames into the FIFO and then waits until the FIFO empties before pushing more frames in. I'm now changing it so there's a separate "what's in the FIFO" queue, so.. * .. I can properly support the whole CABQ method of "these frames are in the FIFO", because the CABQ support requires pushing multiple frames (linked with the link pointer) into a single FIFO entry, .. and * .. if I want to support restarting that queue during a stuck beacon or other recoverable reset, I need to know where my FIFO frame boundaries are. Now, ath9k does it a bit differently - it has a split queue setup, but the FIFO queue is a list of queues. I don't yet want to refactor everything that way, so I'm just marking the start/end of each frame list with ath_buf flags (ATH_BUF_FIFOPTR for the beginning and ATH_BUF_FIFOEND for the last buffer in a list) and then making sure I handle those right. Now, this seems to work - in both encrypted (CCMP/TKIP) and open mode. I'm not getting the high throughput I expect though - it looks like I'm transmitting far too many single frames at the moment, rather than being (more) aggressive at aggregation. I'll worry about that later. This includes testing with stations in sleep mode (ie, traffic going into the CABQ.) Now, what's left? * I have to finish converting over the axq_link references to ath_hal_settxdesclink(), and kill axq_link as a concept. * I need to figure out why we're seeing that panic with the AR9380 TX completion FIFO saying that something is free on Q1 when the Q1 FIFO is empty. * I need to mark intermediary buffers in a buffer list with ATH_BUF_BUSY, so they go onto the holdingbf queue. Otherwise the DMA engine may hang (and this is a problem in ath9k too! Go go gadget code review!) * Lots, lots more testing. I'd really like to figure out why the aggregation isn't as aggressive as it could be. I'll dig into that later. I should be seeing ~ 250-280mbit TCP throughput on 3x3 HT40; but now I'm seeing ~150mbit (ie, what I see with 2x2 HT/40.) That's obviously wrong. I'm seeing very reliable MCS23 transmission and reception so it isn't that. It seems to be something odd with how aggregates are being formed and said aggregation logic seeming to transmit more single frames than aggregate frames. Sigh. Anyway. If you want to test it out, the patch above applies cleanly to -HEAD and you _do_ need to update to the latest git HAL or encryption just plain won't work. From owner-freebsd-wireless@FreeBSD.ORG Tue Mar 26 06:01:30 2013 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 47983BE for ; Tue, 26 Mar 2013 06:01:30 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-we0-x235.google.com (mail-we0-x235.google.com [IPv6:2a00:1450:400c:c03::235]) by mx1.freebsd.org (Postfix) with ESMTP id D8799D3C for ; Tue, 26 Mar 2013 06:01:29 +0000 (UTC) Received: by mail-we0-f181.google.com with SMTP id d7so561559wer.40 for ; Mon, 25 Mar 2013 23:01:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=U7scILB9FLRLDKgivWs3ggUtoZ1ACs+DEs9yVUzI140=; b=q/u94nPIcntO2gDdrxEA6JOuHGPpisipC7Uf6aNvCxRdml/+SlVQ0u6DuhvOW/5NyU ogc/POLt3juf6WZkZsxkJG36uMS5CtbJc83pdbVwH7csvpmQCO+NQ+K8EDZ5xqwWJ+Nf LazaXD9edBD4FMpX73cdytx2W2asMfEdfCmq2qRzSWoHDoEHml2eny5uRIllodGkfIxL MBaGHd5OOU0f8OSOpmKKDbUzNScf4Rw499u/1cRODQL3sNmTJrQAtJImP6FfBXJa9eIU pYj77Np+WXWNUF6y3avKnrkIDldAPSvfJ5KfGFhb6Hbq0UBdgBDZlg1n5o8qT97QIG2N K83A== MIME-Version: 1.0 X-Received: by 10.194.171.74 with SMTP id as10mr22246925wjc.0.1364277688923; Mon, 25 Mar 2013 23:01:28 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.216.108.130 with HTTP; Mon, 25 Mar 2013 23:01:28 -0700 (PDT) In-Reply-To: References: Date: Mon, 25 Mar 2013 23:01:28 -0700 X-Google-Sender-Auth: sdDAofmkoL5dGEV5GKe--v_n34g Message-ID: Subject: Re: [wip] ar9300 hostap support From: Adrian Chadd To: freebsd-wireless@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Discussions of 802.11 stack, tools device driver development." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Mar 2013 06:01:30 -0000 Hi, Here's an update against the most recent -HEAD: http://people.freebsd.org/~adrian/ath/20130326-cabq-edma-tx-rework-5.diff I've done some more basic interoperability with the station devices I have hiding around here. There's been no real issues thus far. I've committed some of the shared work (mostly to do with cabq/multicast queue) code to -HEAD already. It may affect both the pre-AR9380 and AR9380 series NICs. I'd appreciate it if people updated to -HEAD anyway and tested it out. Thanks! Adrian On 25 March 2013 16:13, Adrian Chadd wrote: > Hi, > > I've been working on AR9380 HAL hostap support in my spare time. > > Here's where I'm at so far: > > http://people.freebsd.org/~adrian/ath/20130325-cabq-edma-txq-rework-3.diff > > Now, this is not likely what I'm going to push into -HEAD. But it's > being stable for me for now, save some odd crashes that have been > reported with TX completion on the AR9380 chips. > > Now, what's going on and what I have to stage into -HEAD: > > * The whole descriptor linking thing is just plain wrong for the > AR9380 chips. I have to nuke axq_link from orbit and use > ath_hal_settxdesclink(). This requires some manual fiddling of things > in a variety of places in both the pre-AR9380 chips and the AR9380 > chips - it's used for CABQ assembly, for beacon programming, for > general unicast traffic programming ... eek. > > * The CABQ assembly code needed to be tweaked for EDMA. Now I have to > populate the whole list of CABQ frames (with the correct link pointers > as listed above) before I can push that list into the hardware FIFO. > > * I need to separate out the FIFO contents from the pending TX queue > in each hardware TXQ. Right now my EDMA TX code just pushes individual > MPDU or AMPDU frames into the FIFO and then waits until the FIFO > empties before pushing more frames in. I'm now changing it so there's > a separate "what's in the FIFO" queue, so.. > > * .. I can properly support the whole CABQ method of "these frames are > in the FIFO", because the CABQ support requires pushing multiple > frames (linked with the link pointer) into a single FIFO entry, .. and > > * .. if I want to support restarting that queue during a stuck beacon > or other recoverable reset, I need to know where my FIFO frame > boundaries are. > > Now, ath9k does it a bit differently - it has a split queue setup, but > the FIFO queue is a list of queues. I don't yet want to refactor > everything that way, so I'm just marking the start/end of each frame > list with ath_buf flags (ATH_BUF_FIFOPTR for the beginning and > ATH_BUF_FIFOEND for the last buffer in a list) and then making sure I > handle those right. > > Now, this seems to work - in both encrypted (CCMP/TKIP) and open mode. > I'm not getting the high throughput I expect though - it looks like > I'm transmitting far too many single frames at the moment, rather than > being (more) aggressive at aggregation. I'll worry about that later. > This includes testing with stations in sleep mode (ie, traffic going > into the CABQ.) > > Now, what's left? > > * I have to finish converting over the axq_link references to > ath_hal_settxdesclink(), and kill axq_link as a concept. > * I need to figure out why we're seeing that panic with the AR9380 TX > completion FIFO saying that something is free on Q1 when the Q1 FIFO > is empty. > * I need to mark intermediary buffers in a buffer list with > ATH_BUF_BUSY, so they go onto the holdingbf queue. Otherwise the DMA > engine may hang (and this is a problem in ath9k too! Go go gadget code > review!) > * Lots, lots more testing. > > I'd really like to figure out why the aggregation isn't as aggressive > as it could be. I'll dig into that later. I should be seeing ~ > 250-280mbit TCP throughput on 3x3 HT40; but now I'm seeing ~150mbit > (ie, what I see with 2x2 HT/40.) That's obviously wrong. I'm seeing > very reliable MCS23 transmission and reception so it isn't that. It > seems to be something odd with how aggregates are being formed and > said aggregation logic seeming to transmit more single frames than > aggregate frames. Sigh. > > Anyway. If you want to test it out, the patch above applies cleanly to > -HEAD and you _do_ need to update to the latest git HAL or encryption > just plain won't work. From owner-freebsd-wireless@FreeBSD.ORG Tue Mar 26 20:10:09 2013 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id EF69A66B for ; Tue, 26 Mar 2013 20:10:09 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) by mx1.freebsd.org (Postfix) with ESMTP id 92062B4F for ; Tue, 26 Mar 2013 20:10:09 +0000 (UTC) Received: by mail-wi0-f173.google.com with SMTP id ez12so1531076wid.12 for ; Tue, 26 Mar 2013 13:10:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=ga1xXajtlPFb/ZEr2Xr//8VHT+piylVXssxx60rV19Q=; b=ki2kdPh8VjHrugoc04qCW+HDXmlXzpkAP7wiYSePTCrIeg33yheydso7zxpHXw/5nr zFWKG56B6XPNuUDAvLOSeIiS5YsdNHRhpB9XFsX5To6338/LJPc+NmiMC1DhbHB7YVkT Q9JgXMTmCE/Q3RlsFgirVhkmuBgkoeitAZYw9cNofvBXWZK6slkaOCy6DlRZ1gMos1or P+bPoqt6abnJTOMrvp/eUOhBE/3G5z5/Nvuv/nIvf6r48k1VU/eYqMcS5f+dfMUtuvCi rwvPjM7aADYqO/WscSwQY8TavbHsiG58iXHGTekzEh67KfvqO+3ShEMKS7P+i+vRoknK kbCA== MIME-Version: 1.0 X-Received: by 10.180.189.205 with SMTP id gk13mr5501551wic.25.1364328608874; Tue, 26 Mar 2013 13:10:08 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.216.108.130 with HTTP; Tue, 26 Mar 2013 13:10:08 -0700 (PDT) In-Reply-To: References: Date: Tue, 26 Mar 2013 13:10:08 -0700 X-Google-Sender-Auth: 0yfeGNHNhHMj9xm6sxf-cJCpgZc Message-ID: Subject: Re: [wip] ar9300 hostap support From: Adrian Chadd To: freebsd-wireless@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Discussions of 802.11 stack, tools device driver development." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Mar 2013 20:10:10 -0000 .. and it's all now in -HEAD. Please update to -HEAD before you test out the AR9380 support. Joshua - I've also put in a work around to stop things crashing on an empty tx queue. It'll just log a warning. I'm going to add some further debugging code to ensure that frames going into a TXQ actually _have_ the right queue ID set in the descriptor. It's quite possible that I've screwed this up somewhere. Thanks, Adrian On 25 March 2013 23:01, Adrian Chadd wrote: > Hi, > > Here's an update against the most recent -HEAD: > > http://people.freebsd.org/~adrian/ath/20130326-cabq-edma-tx-rework-5.diff > > I've done some more basic interoperability with the station devices I > have hiding around here. There's been no real issues thus far. > > I've committed some of the shared work (mostly to do with > cabq/multicast queue) code to -HEAD already. It may affect both the > pre-AR9380 and AR9380 series NICs. I'd appreciate it if people updated > to -HEAD anyway and tested it out. > > Thanks! > > > Adrian > > On 25 March 2013 16:13, Adrian Chadd wrote: >> Hi, >> >> I've been working on AR9380 HAL hostap support in my spare time. >> >> Here's where I'm at so far: >> >> http://people.freebsd.org/~adrian/ath/20130325-cabq-edma-txq-rework-3.diff >> >> Now, this is not likely what I'm going to push into -HEAD. But it's >> being stable for me for now, save some odd crashes that have been >> reported with TX completion on the AR9380 chips. >> >> Now, what's going on and what I have to stage into -HEAD: >> >> * The whole descriptor linking thing is just plain wrong for the >> AR9380 chips. I have to nuke axq_link from orbit and use >> ath_hal_settxdesclink(). This requires some manual fiddling of things >> in a variety of places in both the pre-AR9380 chips and the AR9380 >> chips - it's used for CABQ assembly, for beacon programming, for >> general unicast traffic programming ... eek. >> >> * The CABQ assembly code needed to be tweaked for EDMA. Now I have to >> populate the whole list of CABQ frames (with the correct link pointers >> as listed above) before I can push that list into the hardware FIFO. >> >> * I need to separate out the FIFO contents from the pending TX queue >> in each hardware TXQ. Right now my EDMA TX code just pushes individual >> MPDU or AMPDU frames into the FIFO and then waits until the FIFO >> empties before pushing more frames in. I'm now changing it so there's >> a separate "what's in the FIFO" queue, so.. >> >> * .. I can properly support the whole CABQ method of "these frames are >> in the FIFO", because the CABQ support requires pushing multiple >> frames (linked with the link pointer) into a single FIFO entry, .. and >> >> * .. if I want to support restarting that queue during a stuck beacon >> or other recoverable reset, I need to know where my FIFO frame >> boundaries are. >> >> Now, ath9k does it a bit differently - it has a split queue setup, but >> the FIFO queue is a list of queues. I don't yet want to refactor >> everything that way, so I'm just marking the start/end of each frame >> list with ath_buf flags (ATH_BUF_FIFOPTR for the beginning and >> ATH_BUF_FIFOEND for the last buffer in a list) and then making sure I >> handle those right. >> >> Now, this seems to work - in both encrypted (CCMP/TKIP) and open mode. >> I'm not getting the high throughput I expect though - it looks like >> I'm transmitting far too many single frames at the moment, rather than >> being (more) aggressive at aggregation. I'll worry about that later. >> This includes testing with stations in sleep mode (ie, traffic going >> into the CABQ.) >> >> Now, what's left? >> >> * I have to finish converting over the axq_link references to >> ath_hal_settxdesclink(), and kill axq_link as a concept. >> * I need to figure out why we're seeing that panic with the AR9380 TX >> completion FIFO saying that something is free on Q1 when the Q1 FIFO >> is empty. >> * I need to mark intermediary buffers in a buffer list with >> ATH_BUF_BUSY, so they go onto the holdingbf queue. Otherwise the DMA >> engine may hang (and this is a problem in ath9k too! Go go gadget code >> review!) >> * Lots, lots more testing. >> >> I'd really like to figure out why the aggregation isn't as aggressive >> as it could be. I'll dig into that later. I should be seeing ~ >> 250-280mbit TCP throughput on 3x3 HT40; but now I'm seeing ~150mbit >> (ie, what I see with 2x2 HT/40.) That's obviously wrong. I'm seeing >> very reliable MCS23 transmission and reception so it isn't that. It >> seems to be something odd with how aggregates are being formed and >> said aggregation logic seeming to transmit more single frames than >> aggregate frames. Sigh. >> >> Anyway. If you want to test it out, the patch above applies cleanly to >> -HEAD and you _do_ need to update to the latest git HAL or encryption >> just plain won't work. From owner-freebsd-wireless@FreeBSD.ORG Tue Mar 26 22:34:40 2013 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 66D3351F for ; Tue, 26 Mar 2013 22:34:40 +0000 (UTC) (envelope-from jrisom@gmail.com) Received: from mail-ia0-x235.google.com (mail-ia0-x235.google.com [IPv6:2607:f8b0:4001:c02::235]) by mx1.freebsd.org (Postfix) with ESMTP id 3ABD889C for ; Tue, 26 Mar 2013 22:34:40 +0000 (UTC) Received: by mail-ia0-f181.google.com with SMTP id o25so6723556iad.40 for ; Tue, 26 Mar 2013 15:34:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=lgcFGtkt4BXgOcld2GKXyKSY/oD33qW7W76auBGis4I=; b=yWonE3/DosbmZRAha51VH005WAX35Sw4Vn53ArNQ/PFrE+CrHs9BnhaN5lf1QahVWM BoiYIlhC2zrSkaXaDKPxKYF9+F7/X0Ll/evjMRFgcsvbPG5o89UNV3bHH4EFkUlL3zC/ QGp//yIsBA2VfIXYYtGlrpMeoQdGgU9bXIG+QMtTGGB92wWJLmhOQi1Phvu/cEntvkQb lnngV9++tsqj7l5WFg8N7aE0UvxIPDvNTTgm4dgu0e9yUZaaJU/b82F7nXhkMlukm06w tDcWv91eTvL10rSm9eZjUyljZR1B5Ny+P/ERXP8pGKwSwjSToJdrXEk6QfEo4sBwbeFc 1txg== X-Received: by 10.50.153.165 with SMTP id vh5mr2684900igb.48.1364337279183; Tue, 26 Mar 2013 15:34:39 -0700 (PDT) Received: from [192.168.1.44] (c-98-212-197-211.hsd1.il.comcast.net. [98.212.197.211]) by mx.google.com with ESMTPS id wx2sm4530251igb.4.2013.03.26.15.34.37 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 26 Mar 2013 15:34:38 -0700 (PDT) Message-ID: <51522277.6040107@gmail.com> Date: Tue, 26 Mar 2013 17:34:31 -0500 From: Joshua Isom User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: freebsd-wireless@freebsd.org Subject: Re: [wip] ar9300 hostap support References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Discussions of 802.11 stack, tools device driver development." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Mar 2013 22:34:40 -0000 I know it'll sound bad, but I've had two hours of uptime without a panic and while keeping network. It seems you'ved fixed the network connectivity problem, which could have been because of a weak signal, and the panics. My dmesg is getting occasional "ath0: ath_edma_recv_proc_queue: handled npkts 0" but not nearly as often as before. On 3/26/2013 3:10 PM, Adrian Chadd wrote: > .. and it's all now in -HEAD. > > Please update to -HEAD before you test out the AR9380 support. > > Joshua - I've also put in a work around to stop things crashing on an > empty tx queue. It'll just log a warning. > > I'm going to add some further debugging code to ensure that frames > going into a TXQ actually _have_ the right queue ID set in the > descriptor. It's quite possible that I've screwed this up somewhere. > > Thanks, > > > Adrian > From owner-freebsd-wireless@FreeBSD.ORG Wed Mar 27 00:11:48 2013 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id B5649DF for ; Wed, 27 Mar 2013 00:11:48 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::22a]) by mx1.freebsd.org (Postfix) with ESMTP id 57E938E for ; Wed, 27 Mar 2013 00:11:48 +0000 (UTC) Received: by mail-wi0-f170.google.com with SMTP id hm11so1810474wib.3 for ; Tue, 26 Mar 2013 17:11:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=DI3c4BqAGH9SdTYy5lY3hc/FuaRXQhlqVE3DL0V53n4=; b=tDXrsYnmTqHtnrnAGyTGcQeup+CPj6nCKEpRIVnZjkg00gSPecCBF3RMu5VyNz70Sg EGAqxH++kmVyuy66tKRtgADUyQx6aZLLFpqFYhaubF6KNJ9ZG8Rmh71QX9dagzsWkYQs JktXY+KtBovYz9NX/4KmH/TorfT3Thxpgc5bDhBGvTruDZoaRRimSZtnQpJPzbptmLwn KEG2Ix00XOIDUdE9xYzhQj5gnqF3LBoPicAmPkgAUqgelqWy4cLKdfiTPE5XoKCpE2yb RnQg/HOXZ2IaoCL6/T1T0eHU5fC+4EgqfCOPnMn9jdS2Bd5NrcPB/yDVzTaXhVxNKGcT asWA== MIME-Version: 1.0 X-Received: by 10.194.22.5 with SMTP id z5mr28069473wje.5.1364343107537; Tue, 26 Mar 2013 17:11:47 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.216.108.130 with HTTP; Tue, 26 Mar 2013 17:11:47 -0700 (PDT) In-Reply-To: <51522277.6040107@gmail.com> References: <51522277.6040107@gmail.com> Date: Tue, 26 Mar 2013 17:11:47 -0700 X-Google-Sender-Auth: KjDuxN2K4R-utGEEzBgQC4HHHvk Message-ID: Subject: Re: [wip] ar9300 hostap support From: Adrian Chadd To: Joshua Isom Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-wireless@freebsd.org X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Discussions of 802.11 stack, tools device driver development." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Mar 2013 00:11:48 -0000 On 26 March 2013 15:34, Joshua Isom wrote: > I know it'll sound bad, but I've had two hours of uptime without a panic and > while keeping network. It seems you'ved fixed the network connectivity > problem, which could have been because of a weak signal, and the panics. My > dmesg is getting occasional "ath0: ath_edma_recv_proc_queue: handled npkts > 0" but not nearly as often as before. Hah, that's nice to know. Please let me know if you see any further issues here. I have another tweak to add in soon in the TX completion code; I just noticed a very subtle difference between what my code does and what the reference code does. Thanks, Adrian From owner-freebsd-wireless@FreeBSD.ORG Wed Mar 27 00:21:11 2013 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 9BC206E2; Wed, 27 Mar 2013 00:21:11 +0000 (UTC) (envelope-from jrisom@gmail.com) Received: from mail-ie0-x22b.google.com (mail-ie0-x22b.google.com [IPv6:2607:f8b0:4001:c03::22b]) by mx1.freebsd.org (Postfix) with ESMTP id 645DE113; Wed, 27 Mar 2013 00:21:11 +0000 (UTC) Received: by mail-ie0-f171.google.com with SMTP id e14so7896725iej.30 for ; Tue, 26 Mar 2013 17:21:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=vxm/ZEY9X7CSKg+DyXXP3gPqVGG9i9Mpp+yH1TIC/tg=; b=Um3Ympn/iZU8EeaAh1XNuLkQrxWPBGVuMbxzPF/OGPR7jpTrsLmt/Pr3ZNRvc84Et5 Uw3QBu+11YSK1fksGRxXjxFjWxmlirGDQa8ngdq7lA++XTVqrmMN0Q3h8lnzKGTdwU8P h4vm14Eo1FyXFIcAOlqxgRU7EdhrOPZN312dEEITo2MehURTjolpwQo5tHdR0fz8P63P v9ZgwNUwI6uiobiEzUKvh0FX0CSjyHOvBsm3ET3DezE/4Ua2mDt9pcUzHkmEdIlyK+hD ZKGXGM0uFP5CPV20PBHnV1x7vg7vq1F5oZ8eqSixmZzs5xuslfG/HxN30PUftwaoab3z 8cbQ== X-Received: by 10.50.78.202 with SMTP id d10mr2857328igx.69.1364343671118; Tue, 26 Mar 2013 17:21:11 -0700 (PDT) Received: from [192.168.1.44] (c-98-212-197-211.hsd1.il.comcast.net. [98.212.197.211]) by mx.google.com with ESMTPS id s8sm4974451igs.0.2013.03.26.17.21.09 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 26 Mar 2013 17:21:10 -0700 (PDT) Message-ID: <51523B6F.5010506@gmail.com> Date: Tue, 26 Mar 2013 19:21:03 -0500 From: Joshua Isom User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: Adrian Chadd Subject: Re: [wip] ar9300 hostap support References: <51522277.6040107@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-wireless@freebsd.org X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Discussions of 802.11 stack, tools device driver development." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Mar 2013 00:21:11 -0000 Another panic, but a different cause. I think I'd seen it once before but I'm not sure. Unread portion of the kernel message buffer: ath0: ath_edma_recv_proc_queue: handled npkts 0 ath0: ath_edma_tx_processq: Q1: empty? panic: _mtx_lock_sleep: recursed on non-recursive mutex ath0_txq1 @ /root/ATH/head/sys/modules/ath/../../dev/ath/if_ath_tx_edma.c:667 cpuid = 1 KDB: enter: panic [...] (kgdb) bt #0 doadump (textdump=0) at pcpu.h:229 #1 0xffffffff802fb52e in db_dump (dummy=, dummy2=0, dummy3=0, dummy4=0x0) at /root/ATH/head/sys/ddb/db_command.c:543 #2 0xffffffff802fafda in db_command (last_cmdp=, cmd_table=, dopager=1) at /root/ATH/head/sys/ddb/db_command.c:449 #3 0xffffffff802fad92 in db_command_loop () at /root/ATH/head/sys/ddb/db_command.c:502 #4 0xffffffff802fd740 in db_trap (type=, code=0) at /root/ATH/head/sys/ddb/db_main.c:231 #5 0xffffffff8056e4e3 in kdb_trap (type=3, code=0, tf=) at /root/ATH/head/sys/kern/subr_kdb.c:654 #6 0xffffffff807d5368 in trap (frame=0xffffff8020bdd7d0) at /root/ATH/head/sys/amd64/amd64/trap.c:579 #7 0xffffffff807be232 in calltrap () at exception.S:228 #8 0xffffffff8056dcce in kdb_enter (why=0xffffffff808abd45 "panic", msg=) at cpufunc.h:63 #9 0xffffffff805390f7 in vpanic (fmt=, ap=) at /root/ATH/head/sys/kern/kern_shutdown.c:747 #10 0xffffffff80538fa6 in kassert_panic (fmt=) at /root/ATH/head/sys/kern/kern_shutdown.c:642 #11 0xffffffff80524cfa in __mtx_lock_sleep (c=0xffffff800090dea8, tid=18446741874793984000, opts=, file=, line=549311568) at /root/ATH/head/sys/kern/kern_mutex.c:394 #12 0xffffffff8052491a in __mtx_lock_flags (c=, opts=0, file=0xffffffff813f2dcf "/root/ATH/head/sys/modules/ath/../../dev/ath/if_ath_tx_edma.c", line=667) at /root/ATH/head/sys/kern/kern_mutex.c:224 #13 0xffffffff81335467 in ath_edma_tx_processq (sc=0xffffff800090d000, dosched=1) at /root/ATH/head/sys/modules/ath/../../dev/ath/if_ath_tx_edma.c:667 #14 0xffffffff8057cea0 in taskqueue_run_locked (queue=0xfffffe0006488500) at /root/ATH/head/sys/kern/subr_taskqueue.c:333 #15 0xffffffff8057d67b in taskqueue_thread_loop (arg=) at /root/ATH/head/sys/kern/subr_taskqueue.c:535 #16 0xffffffff80508a14 in fork_exit (callout=0xffffffff8057d5e0 , arg=0xffffff800090d810, frame=0xffffff8020bddc00) at /root/ATH/head/sys/kern/kern_fork.c:991 #17 0xffffffff807be76e in fork_trampoline () at exception.S:602 #18 0x0000000000000000 in ?? () On 3/26/2013 7:11 PM, Adrian Chadd wrote: > > Hah, that's nice to know. > > Please let me know if you see any further issues here. > > I have another tweak to add in soon in the TX completion code; I just > noticed a very subtle difference between what my code does and what > the reference code does. > > Thanks, > > > > Adrian > From owner-freebsd-wireless@FreeBSD.ORG Wed Mar 27 00:29:47 2013 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id C1FCC7D7 for ; Wed, 27 Mar 2013 00:29:47 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::236]) by mx1.freebsd.org (Postfix) with ESMTP id 5F7B515E for ; Wed, 27 Mar 2013 00:29:47 +0000 (UTC) Received: by mail-wi0-f182.google.com with SMTP id hi18so1733314wib.15 for ; Tue, 26 Mar 2013 17:29:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=XzRRWZuSjCV8v+FTj49HUqzjZJBXCRB9gAk3+1OFHes=; b=yvGGtSyp9FgQCiw0+mMxeD4ZWb3VLvR8OEY96qHGwN1m4UNVmI0SbillUDJdXYnixb cTCfe2iwqZxZMIYxPxgqCqXiXD2Mw4WcFV4w6aQ8AYUY+gA4TawlcLyhb27wnLqcB4j2 ZvDujMMcnmIhy3UFTPcHf5WMq8iYZzr3+5PUPvvtVVX8mNMkrY8TZqFhLp/Y6Nnz/nqf qes5R98vK7mFtKE6l2R+1szSgstrqKopvogVGJJ3cqKMKIx1oIAi4nn0fUZert1Wi4PJ 8LtDcI+S+R3HmWy5Z6g++UsA+BAMY9KPM3p7jdJD0BKEkKIGFVPc10x6+XrZ7zwpWd0F aDug== MIME-Version: 1.0 X-Received: by 10.194.120.169 with SMTP id ld9mr28053422wjb.24.1364344185657; Tue, 26 Mar 2013 17:29:45 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.216.108.130 with HTTP; Tue, 26 Mar 2013 17:29:45 -0700 (PDT) In-Reply-To: <51523B6F.5010506@gmail.com> References: <51522277.6040107@gmail.com> <51523B6F.5010506@gmail.com> Date: Tue, 26 Mar 2013 17:29:45 -0700 X-Google-Sender-Auth: r4Zki_VV1onYzVlb-HFGwP4kV4M Message-ID: Subject: Re: [wip] ar9300 hostap support From: Adrian Chadd To: Joshua Isom Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-wireless@freebsd.org X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Discussions of 802.11 stack, tools device driver development." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Mar 2013 00:29:47 -0000 it's the same underlying problem as before. I just screwed up the locking. Lemme fix that. Adrian On 26 March 2013 17:21, Joshua Isom wrote: > Another panic, but a different cause. I think I'd seen it once before but > I'm not sure. > > Unread portion of the kernel message buffer: > > ath0: ath_edma_recv_proc_queue: handled npkts 0 > ath0: ath_edma_tx_processq: Q1: empty? > panic: _mtx_lock_sleep: recursed on non-recursive mutex ath0_txq1 @ > /root/ATH/head/sys/modules/ath/../../dev/ath/if_ath_tx_edma.c:667 > > cpuid = 1 > KDB: enter: panic > > [...] > > (kgdb) bt > #0 doadump (textdump=0) at pcpu.h:229 > #1 0xffffffff802fb52e in db_dump (dummy=, dummy2=0, > dummy3=0, dummy4=0x0) > at /root/ATH/head/sys/ddb/db_command.c:543 > #2 0xffffffff802fafda in db_command (last_cmdp=, > cmd_table=, dopager=1) > at /root/ATH/head/sys/ddb/db_command.c:449 > #3 0xffffffff802fad92 in db_command_loop () at > /root/ATH/head/sys/ddb/db_command.c:502 > #4 0xffffffff802fd740 in db_trap (type=, code=0) at > /root/ATH/head/sys/ddb/db_main.c:231 > #5 0xffffffff8056e4e3 in kdb_trap (type=3, code=0, tf= out>) at /root/ATH/head/sys/kern/subr_kdb.c:654 > #6 0xffffffff807d5368 in trap (frame=0xffffff8020bdd7d0) at > /root/ATH/head/sys/amd64/amd64/trap.c:579 > #7 0xffffffff807be232 in calltrap () at exception.S:228 > #8 0xffffffff8056dcce in kdb_enter (why=0xffffffff808abd45 "panic", > msg=) at cpufunc.h:63 > #9 0xffffffff805390f7 in vpanic (fmt=, ap= optimized out>) > at /root/ATH/head/sys/kern/kern_shutdown.c:747 > #10 0xffffffff80538fa6 in kassert_panic (fmt=) at > /root/ATH/head/sys/kern/kern_shutdown.c:642 > #11 0xffffffff80524cfa in __mtx_lock_sleep (c=0xffffff800090dea8, > tid=18446741874793984000, opts=, > file=, line=549311568) at > /root/ATH/head/sys/kern/kern_mutex.c:394 > #12 0xffffffff8052491a in __mtx_lock_flags (c=, opts=0, > file=0xffffffff813f2dcf > "/root/ATH/head/sys/modules/ath/../../dev/ath/if_ath_tx_edma.c", line=667) > at /root/ATH/head/sys/kern/kern_mutex.c:224 > #13 0xffffffff81335467 in ath_edma_tx_processq (sc=0xffffff800090d000, > dosched=1) > at /root/ATH/head/sys/modules/ath/../../dev/ath/if_ath_tx_edma.c:667 > #14 0xffffffff8057cea0 in taskqueue_run_locked (queue=0xfffffe0006488500) at > /root/ATH/head/sys/kern/subr_taskqueue.c:333 > #15 0xffffffff8057d67b in taskqueue_thread_loop (arg=) > at /root/ATH/head/sys/kern/subr_taskqueue.c:535 > #16 0xffffffff80508a14 in fork_exit (callout=0xffffffff8057d5e0 > , arg=0xffffff800090d810, > frame=0xffffff8020bddc00) at /root/ATH/head/sys/kern/kern_fork.c:991 > #17 0xffffffff807be76e in fork_trampoline () at exception.S:602 > #18 0x0000000000000000 in ?? () > > > > On 3/26/2013 7:11 PM, Adrian Chadd wrote: >> >> >> Hah, that's nice to know. >> >> Please let me know if you see any further issues here. >> >> I have another tweak to add in soon in the TX completion code; I just >> noticed a very subtle difference between what my code does and what >> the reference code does. >> >> Thanks, >> >> >> >> Adrian >> > From owner-freebsd-wireless@FreeBSD.ORG Wed Mar 27 00:36:01 2013 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 204B1A8D for ; Wed, 27 Mar 2013 00:36:01 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-we0-x234.google.com (mail-we0-x234.google.com [IPv6:2a00:1450:400c:c03::234]) by mx1.freebsd.org (Postfix) with ESMTP id B548E18F for ; Wed, 27 Mar 2013 00:36:00 +0000 (UTC) Received: by mail-we0-f180.google.com with SMTP id r5so4289903wey.11 for ; Tue, 26 Mar 2013 17:35:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=N8qf+H/tyCv8YsmpKHMtApyEuAKOZFPg87Qa0np5emY=; b=QWuFr2l0sMQWdQKSd5WzUZeOtVA1//VjIzLs1WyL7klW5928ckzjU0Waa9doh43a+5 XEF5pDdDLsHXbWqIqPAwCS6Tjw6VYBC6SFoCG5KysFOWNxaSi6IjwscM91qrpclFHrD8 t2p8uQPbX/Gk0NxMWwutIWWf3wEp16gmpr3eXJjUH0h8Z/c1Ow7tVN4aMD+HV8B7WI4b ngr0LaMUPOg9+7XnX380B7lmR67OKbwpFbPU4LPM5ZkAyjEpDm4/jmdn7BT11L4GlPW5 UlJw3YzTIowNxBaqshifLzpFdJ8PZeRzhLH9G1iP0ixfTj/t9tJOHspx5X/JDYwLWHBN x86w== MIME-Version: 1.0 X-Received: by 10.180.189.205 with SMTP id gk13mr6427491wic.25.1364344559930; Tue, 26 Mar 2013 17:35:59 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.216.108.130 with HTTP; Tue, 26 Mar 2013 17:35:59 -0700 (PDT) In-Reply-To: References: <51522277.6040107@gmail.com> <51523B6F.5010506@gmail.com> Date: Tue, 26 Mar 2013 17:35:59 -0700 X-Google-Sender-Auth: C7uCTgwo1Zihyzf0oE9SUs6f1sw Message-ID: Subject: Re: [wip] ar9300 hostap support From: Adrian Chadd To: Joshua Isom Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-wireless@freebsd.org X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Discussions of 802.11 stack, tools device driver development." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Mar 2013 00:36:01 -0000 Ok, update to -HEAD again. Adrian From owner-freebsd-wireless@FreeBSD.ORG Wed Mar 27 23:35:24 2013 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id BEBBCD40; Wed, 27 Mar 2013 23:35:24 +0000 (UTC) (envelope-from jrisom@gmail.com) Received: from mail-ie0-x22f.google.com (mail-ie0-x22f.google.com [IPv6:2607:f8b0:4001:c03::22f]) by mx1.freebsd.org (Postfix) with ESMTP id 85AED9B7; Wed, 27 Mar 2013 23:35:24 +0000 (UTC) Received: by mail-ie0-f175.google.com with SMTP id c12so11081657ieb.34 for ; Wed, 27 Mar 2013 16:35:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=T/+y0qb5EcweBqlMsXzzDIg2PmZLGPMFvcs7zLI1gDc=; b=jsRzyI53iU3eTUjYPZIlr8qVgwrdjovdcp55j3afVh/KozVknwKbudr+KWyKJYhC7R uNjsY42gzxQ0SlQebHCcDuI1znE+M3HR0WU432lylE63yQ1H9fuGWoKcI95BxrgOn+l4 JqoOuI3WUXt3d9ih15JwmTuzV9mtVDe19wF9JIvoPu4wlybgHvbtlJqB8K5WHSKuDkPa dtFSkC5H1EOyqgKHls+dLjbBnpdyCBc7QYQCMq72qUjbQtHQUre6xcPOi5iBPPzTEFwK u+I5ZddP/Y3mlog7nFFo6y1J5JWkrcDa7k94EmMt29BxKkPrYNOCqaHpNiOEuIwFGvSd YEnA== X-Received: by 10.43.8.200 with SMTP id ot8mr12950568icb.11.1364427323627; Wed, 27 Mar 2013 16:35:23 -0700 (PDT) Received: from [192.168.1.44] (c-98-212-197-211.hsd1.il.comcast.net. [98.212.197.211]) by mx.google.com with ESMTPS id s8sm9421040igs.0.2013.03.27.16.35.22 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 27 Mar 2013 16:35:23 -0700 (PDT) Message-ID: <51538239.9030903@gmail.com> Date: Wed, 27 Mar 2013 18:35:21 -0500 From: Joshua Isom User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: Adrian Chadd Subject: Re: [wip] ar9300 hostap support References: <51522277.6040107@gmail.com> <51523B6F.5010506@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-wireless@freebsd.org X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Discussions of 802.11 stack, tools device driver development." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Mar 2013 23:35:24 -0000 On 3/26/2013 7:35 PM, Adrian Chadd wrote: > Ok, update to -HEAD again. > > > > > Adrian > So far 22 hours uptime. Other than what's probably debug messages, everything seems to be working fine. From owner-freebsd-wireless@FreeBSD.ORG Wed Mar 27 23:45:15 2013 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 7750E108 for ; Wed, 27 Mar 2013 23:45:15 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) by mx1.freebsd.org (Postfix) with ESMTP id 0F9DDA0C for ; Wed, 27 Mar 2013 23:45:14 +0000 (UTC) Received: by mail-wi0-f177.google.com with SMTP id hm14so2759333wib.4 for ; Wed, 27 Mar 2013 16:45:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=QFsqlKcGtBauNl4joCwOW7p65ZELmS3QTsF9AxxXeH8=; b=md+TYLs/i9eyhMpCseJPKBX3tRsOvEooJ+CEkRqAlM5GokwyTYE/pEw++mALn8gkIb 5eqtzpvH8eNIOOA12vB0AxTmkkMQRnpd6YQIRGRgxQBEbyQIGjIZUjRIWq1R7Crf514s vH7CtvmuV8nvXvIi7A6EkHVli8NqpCiEnpmiJXLnuOQjD32gUOnaAxUcOKxvzozi4a68 tGsk6Q2BGBcR4ZQghs/1I2V2AytrnleMIhO5Pm/Q5l7BBkORXfJe5wg4mCYs6nKk6shC 3JAoc/IC7fcbdZFwtNWUsjHNpKALtrqBEvDJWnicUzDKnCMLIXZAOsxf9oVnmvckxPLk y4TA== MIME-Version: 1.0 X-Received: by 10.180.89.105 with SMTP id bn9mr8471708wib.26.1364427435375; Wed, 27 Mar 2013 16:37:15 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.216.108.130 with HTTP; Wed, 27 Mar 2013 16:37:15 -0700 (PDT) In-Reply-To: <51538239.9030903@gmail.com> References: <51522277.6040107@gmail.com> <51523B6F.5010506@gmail.com> <51538239.9030903@gmail.com> Date: Wed, 27 Mar 2013 16:37:15 -0700 X-Google-Sender-Auth: SLP5NToE3gtmm6KzSV_6sZxQHLs Message-ID: Subject: Re: [wip] ar9300 hostap support From: Adrian Chadd To: Joshua Isom Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-wireless@freebsd.org X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Discussions of 802.11 stack, tools device driver development." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Mar 2013 23:45:15 -0000 On 27 March 2013 16:35, Joshua Isom wrote: > So far 22 hours uptime. Other than what's probably debug messages, > everything seems to be working fine. Please post the debug messages. Anything the driver spits out needs to be fixed. :-) Adrian From owner-freebsd-wireless@FreeBSD.ORG Wed Mar 27 23:47:56 2013 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id D266A162; Wed, 27 Mar 2013 23:47:56 +0000 (UTC) (envelope-from jrisom@gmail.com) Received: from mail-ie0-x235.google.com (mail-ie0-x235.google.com [IPv6:2607:f8b0:4001:c03::235]) by mx1.freebsd.org (Postfix) with ESMTP id 9A00BA2A; Wed, 27 Mar 2013 23:47:56 +0000 (UTC) Received: by mail-ie0-f181.google.com with SMTP id 17so11060527iea.12 for ; Wed, 27 Mar 2013 16:47:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=85otIHD65fA1gfxnSzJ4sauT1EnVXLJtgrlnXnwyYiI=; b=ty/TLS32HXmZBz0E4U+mEAjtgHx94YiaIllbH5h1dW6uPzV9eTwgwxLWd21NH9YYns nDR2NqlVjhJy7aTGsNnTJB69bYVgDzLopTCLF6BW1Jg4pMn4tzoI7zbEFmJpieM7DVB3 ArWpY58x1/7xjTXb9cnrSTFw+97Pfr19ypFH8F7QEaG+CB1T8QDMoqrqIY+nC/rJllvC HLzpaAZb4maB3AFfjDQIiL4mDGkwzgdkWopeamBjVXg5qFwtwhi5MGVohBZlvJFXGHLV 4iYq/gwVxI6iQwik1xMoOGNBRRLdgeZA/ATTR32tUGYX6T0Q5EDMw5ua1wcCwIrpx6C9 4P3A== X-Received: by 10.50.181.201 with SMTP id dy9mr5709060igc.18.1364428076329; Wed, 27 Mar 2013 16:47:56 -0700 (PDT) Received: from [192.168.1.44] (c-98-212-197-211.hsd1.il.comcast.net. [98.212.197.211]) by mx.google.com with ESMTPS id hi4sm9404279igc.6.2013.03.27.16.47.55 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 27 Mar 2013 16:47:55 -0700 (PDT) Message-ID: <5153852A.1040508@gmail.com> Date: Wed, 27 Mar 2013 18:47:54 -0500 From: Joshua Isom User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: Adrian Chadd Subject: Re: [wip] ar9300 hostap support References: <51522277.6040107@gmail.com> <51523B6F.5010506@gmail.com> <51538239.9030903@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-wireless@freebsd.org X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Discussions of 802.11 stack, tools device driver development." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Mar 2013 23:47:56 -0000 On 3/27/2013 6:37 PM, Adrian Chadd wrote: > On 27 March 2013 16:35, Joshua Isom wrote: > >> So far 22 hours uptime. Other than what's probably debug messages, >> everything seems to be working fine. > > Please post the debug messages. Anything the driver spits out needs to > be fixed. :-) > > > > Adrian > Maybe this way will be somewhat easy to work with. > [jri:~] jisom% dmesg | grep '\(ath\|ar9300\|wlan0\)' | uniq > ath0: mem 0xfdec0000-0xfdedffff irq 16 at device 0.0 on pci2 > ar9300_set_stub_functions: setting stub functions > ar9300_attach: calling ar9300_hw_attach > ar9300_hw_attach: calling ar9300_eeprom_attach > ar9300_flash_map: unimplemented for now > ar9300_hw_attach: ar9300_eeprom_attach returned 0 > ath0: RX status length: 48 > ath0: RX buffer size: 4096 > ath0: TX descriptor length: 128 > ath0: TX status length: 36 > ath0: TX buffers per descriptor: 4 > ar9300_freebsd_setup_x_tx_desc: called, 0x0/0, 0x0/0, 0x0/0 > ath0: ath_edma_setup_rxfifo: type=0, FIFO depth = 16 entries > ath0: ath_edma_setup_rxfifo: type=1, FIFO depth = 128 entries > ath0: [HT] enabling HT modes > ath0: [HT] enabling short-GI in 20MHz mode > ath0: [HT] 1 stream STBC receive enabled > ath0: [HT] 1 stream STBC transmit enabled > ath0: [HT] 3 RX streams; 3 TX streams > ath0: AR9380 mac 448.3 RF5110 phy 0.0 > ath0: 2GHz radio: 0x0000; 5GHz radio: 0x0000 > ar9300_Stub_GetCTSTimeout: called > ar9300_Stub_GetAntennaSwitch: called > wlan0: Ethernet address: 64:70:02:18:6d:95 > ath0: ath_edma_recv_proc_queue: handled npkts 0 > ath0: ath_edma_recv_tasklet: sc_inreset_cnt > 0; skipping > ath0: ath_edma_recv_proc_queue: handled npkts 0 > ath0: ath_edma_recv_tasklet: sc_inreset_cnt > 0; skipping > ath0: ath_edma_recv_proc_queue: handled npkts 0 > ath0: ath_edma_tx_processq: Q1: empty? > ath0: ath_edma_recv_proc_queue: handled npkts 0 > ar9300_reset[4253]: ar9300_stop_dma_receive failed > ath0: ath_edma_recv_proc_queue: handled npkts 0 > wlan0: link state changed to DOWN > ath0: ath_edma_recv_proc_queue: handled npkts 0 > wlan0: link state changed to UP > ath0: ath_edma_recv_proc_queue: handled npkts 0 > ar9300_reset[4253]: ar9300_stop_dma_receive failed > ath0: ath_edma_recv_proc_queue: handled npkts 0 > ar9300_reset[4253]: ar9300_stop_dma_receive failed > ath0: ath_edma_recv_proc_queue: handled npkts 0 > ar9300_reset[4253]: ar9300_stop_dma_receive failed > ath0: ath_edma_recv_proc_queue: handled npkts 0 > ar9300_reset[4253]: ar9300_stop_dma_receive failed > ath0: ath_edma_recv_proc_queue: handled npkts 0 > ar9300_reset[4253]: ar9300_stop_dma_receive failed > ath0: ath_edma_recv_proc_queue: handled npkts 0 > ar9300_reset[4253]: ar9300_stop_dma_receive failed > ath0: ath_edma_recv_proc_queue: handled npkts 0 > wlan0: link state changed to DOWN > ath0: ath_edma_recv_proc_queue: handled npkts 0 > wlan0: link state changed to UP > ath0: ath_edma_recv_proc_queue: handled npkts 0 > wlan0: link state changed to DOWN > ath0: ath_edma_recv_proc_queue: handled npkts 0 > wlan0: link state changed to UP > ath0: ath_edma_recv_proc_queue: handled npkts 0 > wlan0: link state changed to DOWN > ath0: ath_edma_recv_proc_queue: handled npkts 0 > wlan0: link state changed to UP > ath0: ath_edma_recv_proc_queue: handled npkts 0 > ar9300_reset[4253]: ar9300_stop_dma_receive failed > ath0: ath_edma_recv_proc_queue: handled npkts 0 > ar9300_reset[4253]: ar9300_stop_dma_receive failed > ath0: ath_edma_recv_proc_queue: handled npkts 0 > ar9300_reset[4253]: ar9300_stop_dma_receive failed > ath0: ath_edma_recv_proc_queue: handled npkts 0 > wlan0: link state changed to DOWN > ath0: ath_edma_recv_proc_queue: handled npkts 0 > wlan0: link state changed to UP > ath0: ath_edma_recv_proc_queue: handled npkts 0 > wlan0: link state changed to DOWN > ath0: ath_edma_recv_proc_queue: handled npkts 0 > wlan0: link state changed to UP > ath0: ath_edma_recv_proc_queue: handled npkts 0 > [jri:~] jisom% dmesg | grep 'ath0: ath_edma_recv_proc_queue: handled npkts 0' | wc -l > 1246 From owner-freebsd-wireless@FreeBSD.ORG Wed Mar 27 23:53:40 2013 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id C0F523BB for ; Wed, 27 Mar 2013 23:53:40 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wg0-f53.google.com (mail-wg0-f53.google.com [74.125.82.53]) by mx1.freebsd.org (Postfix) with ESMTP id 59905A78 for ; Wed, 27 Mar 2013 23:53:40 +0000 (UTC) Received: by mail-wg0-f53.google.com with SMTP id c11so1082241wgh.32 for ; Wed, 27 Mar 2013 16:53:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=jknItArQ6nCWM6rdgEdGid+EjJlOUqFggjRM7kDdX4I=; b=uyiHztENE/UYxGPQ6nwGjyj3Iac6U7ENdVD8BTCKQphiNFCV0tkBMOkaWiVlhkuW9o w62UUrjgTWaDVprY9WaLm06DuWFyinr3Rcfh91B9IttG4QCwZB71MezHQTGkcLzsFroN TiixhfsiCMEoJRzb5qj/FHfkQJczShYCoONNA3MU89yy8xRzEMvxLnkqlrYWYKWdJXne Miuavs3LIYpAwRz7rrJyUs9vOTvPkvZCi2kooHBKh9nfBGjk0sGeg30WYKkTxBwI4XUb 4D8cwUYq5Sum9E6dxcuAQ52X4uFahibkMfJ5jQyVeNyf7zxrezu97U+xVEVu81VXkGVy IL8Q== MIME-Version: 1.0 X-Received: by 10.194.171.74 with SMTP id as10mr34553990wjc.0.1364428419334; Wed, 27 Mar 2013 16:53:39 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.216.108.130 with HTTP; Wed, 27 Mar 2013 16:53:39 -0700 (PDT) In-Reply-To: <5153852A.1040508@gmail.com> References: <51522277.6040107@gmail.com> <51523B6F.5010506@gmail.com> <51538239.9030903@gmail.com> <5153852A.1040508@gmail.com> Date: Wed, 27 Mar 2013 16:53:39 -0700 X-Google-Sender-Auth: huplIzrzMaXgo3CignlYqducMeI Message-ID: Subject: Re: [wip] ar9300 hostap support From: Adrian Chadd To: Joshua Isom Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-wireless@freebsd.org X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Discussions of 802.11 stack, tools device driver development." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Mar 2013 23:53:40 -0000 On 27 March 2013 16:47, Joshua Isom wrote: >> ath0: ath_edma_recv_proc_queue: handled npkts 0 >> ath0: ath_edma_recv_tasklet: sc_inreset_cnt > 0; skipping That's likely from scanning. I still need to figure out why this is happening. >> ath0: ath_edma_recv_proc_queue: handled npkts 0 >> ath0: ath_edma_recv_tasklet: sc_inreset_cnt > 0; skipping scanning. >> ath0: ath_edma_recv_proc_queue: handled npkts 0 Scanning, maybe? >> ath0: ath_edma_tx_processq: Q1: empty? .. this has me worried. This would've caused a panic before. The next time it happens, but before you disconnect, please do this: sysctl dev.ath.0.txagg=1 I'd like to see if any other TX queue has a frame hanging around in it that hasn't been completed. Also, whats the output if 'ifconfig wlan0 list sta'? I wonder what the RSSI is and I do wonder why you see frequent disconnects. Thanks, Adrian From owner-freebsd-wireless@FreeBSD.ORG Thu Mar 28 19:10:32 2013 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 3F61E229 for ; Thu, 28 Mar 2013 19:10:32 +0000 (UTC) (envelope-from ganthore@gmail.com) Received: from mail-la0-x232.google.com (mail-la0-x232.google.com [IPv6:2a00:1450:4010:c03::232]) by mx1.freebsd.org (Postfix) with ESMTP id B57D6D75 for ; Thu, 28 Mar 2013 19:10:31 +0000 (UTC) Received: by mail-la0-f50.google.com with SMTP id ec20so18438383lab.9 for ; Thu, 28 Mar 2013 12:10:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=6wJQr350rhnHX5RLZgJ/qq7oGoADOKZtTLKwiMARU/E=; b=N4VOa1zmza+c8HAiLlc2m9yUZVTQ3eZ/0KQHvG95ra495jabbt+MGHZ0jMuqhLTAp0 lpV28s2EPaKaVfOMnBooi4Fmu6/IHbdIC2tPGhB9feB/sthleYs6Yp1t8OMrCAte84Ez /uFvnokSfOVhfjeFoXnjzYyiL7+rRBmeTz+tB7OYEZSkcN9XQ5sNXShW1Mk+vupuVVBB +GZ7UcIMiuplW4s+bXmth5Y444BOG4/rQ7PPlLzAMAgGPRrjcY0vFNQ867TH5lzMvdL8 12HOltnHmHAG0X941iW/G73XKqdfAkaDpFyauU8WmIf7x0BFBnx/RbzXpBLxvR6wzcVV m4dw== MIME-Version: 1.0 X-Received: by 10.112.139.130 with SMTP id qy2mr166534lbb.34.1364497830669; Thu, 28 Mar 2013 12:10:30 -0700 (PDT) Received: by 10.114.29.37 with HTTP; Thu, 28 Mar 2013 12:10:30 -0700 (PDT) Date: Thu, 28 Mar 2013 15:10:30 -0400 Message-ID: Subject: AR9300 Working From: Mark Austin To: freebsd-wireless@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Discussions of 802.11 stack, tools device driver development." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Mar 2013 19:10:32 -0000 Just wanted to let everyone know that the AR9300 code is now working with the AR946x NIC. The kernel message log reports: ath0: mem 0xc2400000-0xc247ffff irq 17 at device 0.0 on pci3 ar9300_set_stub_functions: setting stub functions ar9300_set_stub_functions: setting stub functions ar9300_attach: calling ar9300_hw_attach ar9300_hw_attach: calling ar9300_eeprom_attach ar9300_flash_map: unimplemented for now Restoring Cal data from DRAM Restoring Cal data from EEPROM Restoring Cal data from Flash Restoring Cal data from Flash Restoring Cal data from OTP ar9300_hw_attach: ar9300_eeprom_attach returned 0 ar9300_fill_capability_info: (MCI) MCI support = 1 ath0: RX status length: 48 ath0: RX buffer size: 4096 ath0: TX descriptor length: 128 ath0: TX status length: 36 ath0: TX buffers per descriptor: 4 ar9300_freebsd_setup_x_tx_desc: called, 0x0/0, 0x0/0, 0x0/0 ath0: ath_edma_setup_rxfifo: type=0, FIFO depth = 16 entries ath0: ath_edma_setup_rxfifo: type=1, FIFO depth = 128 entries ath0: [HT] enabling HT modes ath0: [HT] enabling short-GI in 20MHz mode ath0: [HT] 1 stream STBC receive enabled ath0: [HT] 1 stream STBC transmit enabled ath0: [HT] 2 RX streams; 2 TX streams ath0: AR9460 mac 640.2 RF5110 phy 0.0 ath0: 2GHz radio: 0x0000; 5GHz radio: 0x0000 wlan0: Ethernet address: 84:4b:f5:2e:7e:2b Ifconfig reports: wlan0: flags=8843 metric 0 mtu 1500 ether 84:4b:f5:2e:7e:2b inet 192.168.222.9 netmask 0xffffff00 broadcast 192.168.222.255 nd6 options=29 media: IEEE 802.11 Wireless Ethernet OFDM/36Mbps mode 11g status: associated ssid tea channel 3 (2422 MHz 11g) bssid 00:1f:6d:b8:c1:e1 regdomain 108 indoor ecm authmode WPA privacy ON deftxkey UNDEF TKIP 2:128-bit txpower 20 bmiss 7 scanvalid 60 protmode CTS wme burst roaming MANUAL Regards, -Mark Austin All else is in doubt, so this is the truth that I cling to. My Website: http://www.silverdire.com From owner-freebsd-wireless@FreeBSD.ORG Thu Mar 28 20:11:33 2013 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 268D1514; Thu, 28 Mar 2013 20:11:33 +0000 (UTC) (envelope-from jrisom@gmail.com) Received: from mail-ie0-x22c.google.com (mail-ie0-x22c.google.com [IPv6:2607:f8b0:4001:c03::22c]) by mx1.freebsd.org (Postfix) with ESMTP id DFE2A7F; Thu, 28 Mar 2013 20:11:32 +0000 (UTC) Received: by mail-ie0-f172.google.com with SMTP id c10so11974306ieb.17 for ; Thu, 28 Mar 2013 13:11:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=DJLCN425Q1IBYGBwSYoFWMGI1FQu+vhUIwFJKA1HUzc=; b=qz+LWg60ssIybOwyZhSNo8ZAN9gIoRzwrhpj7oGUbewhBUERdbE6M0Z00VEgnAN69b Yc3Dl+sV9Iz/DJpKvnw6LPVCUxyWYiPZ8wvCCVfefgjO+XG6+KSmcyS82bE83xax9uTN uDfq38tbOBsB16vgi9B3tb/l3s/1+axkSYBvdSL5Ygd6rn2dgHNg5kP5sFwcYoCRRM/c nG2rM0RVg2j9D9mUfnordZH7ufXyPmfwU4y011vMp8i40Vl93iXdsl/yO39QzbERpWkZ bMXHoSpp3jsF6GJVgiTh/h0tYFIfZ4OFLF+gEUbvGmm6gVIKaL4tri1nPNH0I4fC0agD i4Mg== X-Received: by 10.50.13.175 with SMTP id i15mr8478643igc.75.1364501492654; Thu, 28 Mar 2013 13:11:32 -0700 (PDT) Received: from [192.168.1.44] (c-98-212-197-211.hsd1.il.comcast.net. [98.212.197.211]) by mx.google.com with ESMTPS id j8sm11867757igm.9.2013.03.28.13.11.31 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 28 Mar 2013 13:11:31 -0700 (PDT) Message-ID: <5154A3F1.1090200@gmail.com> Date: Thu, 28 Mar 2013 15:11:29 -0500 From: Joshua Isom User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: Adrian Chadd Subject: Re: [wip] ar9300 hostap support References: <51522277.6040107@gmail.com> <51523B6F.5010506@gmail.com> <51538239.9030903@gmail.com> <5153852A.1040508@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-wireless@freebsd.org X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Discussions of 802.11 stack, tools device driver development." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Mar 2013 20:11:33 -0000 On 3/27/2013 6:53 PM, Adrian Chadd wrote: > .. this has me worried. This would've caused a panic before. The next > time it happens, but before you disconnect, please do this: > > sysctl dev.ath.0.txagg=1 > > I'd like to see if any other TX queue has a frame hanging around in it > that hasn't been completed. I had syslogd pipe the output to a perl script to set the sysctl, not ideal but effective I hope. I've got two today. > Mar 28 07:03:01 jri kernel: ath0: ath_edma_tx_processq: Q1: empty? > Mar 28 07:03:02 jri kernel: no tx bufs (empty list): 0 > Mar 28 07:03:02 jri kernel: no tx bufs (was busy): 0 > Mar 28 07:03:02 jri kernel: aggr single packet: 481 > Mar 28 07:03:02 jri kernel: aggr single packet w/ BAW closed: 0 > Mar 28 07:03:02 jri kernel: aggr non-baw packet: 20 > Mar 28 07:03:02 jri kernel: aggr aggregate packet: 1278 > Mar 28 07:03:02 jri kernel: aggr single packet low hwq: 13087 > Mar 28 07:03:02 jri kernel: aggr single packet RTS aggr limited: 0 > Mar 28 07:03:02 jri kernel: aggr sched, no work: 849 > Mar 28 07:03:02 jri kernel: 0: 0 1: 0 2: 318 3: 221 > Mar 28 07:03:02 jri kernel: 4: 331 5: 50 6: 221 7: 57 > Mar 28 07:03:02 jri kernel: 8: 35 9: 22 10: 13 11: 1 > Mar 28 07:03:02 jri kernel: 12: 5 13: 0 14: 1 15: 0 > Mar 28 07:03:02 jri kernel: 16: 2 17: 0 18: 0 19: 1 > Mar 28 07:03:02 jri kernel: 20: 0 21: 0 22: 0 23: 0 > Mar 28 07:03:02 jri kernel: 24: 0 25: 0 26: 0 27: 0 > Mar 28 07:03:02 jri kernel: 28: 0 29: 0 30: 0 31: 0 > Mar 28 07:03:02 jri kernel: 32: 0 33: 0 34: 0 35: 0 > Mar 28 07:03:02 jri kernel: 36: 0 37: 0 38: 0 39: 0 > Mar 28 07:03:02 jri kernel: 40: 0 41: 0 42: 0 43: 0 > Mar 28 07:03:02 jri kernel: 44: 0 45: 0 46: 0 47: 0 > Mar 28 07:03:02 jri kernel: 48: 0 49: 0 50: 0 51: 0 > Mar 28 07:03:02 jri kernel: 52: 0 53: 0 54: 0 55: 0 > Mar 28 07:03:02 jri kernel: 56: 0 57: 0 58: 0 59: 0 > Mar 28 07:03:02 jri kernel: 60: 0 61: 0 62: 0 63: 0 > Mar 28 07:03:02 jri kernel: > Mar 28 07:03:02 jri kernel: HW TXQ 0: axq_depth=0, axq_aggr_depth=0, axq_fifo_depth=0, holdingbf=0 > Mar 28 07:03:02 jri kernel: HW TXQ 1: axq_depth=0, axq_aggr_depth=0, axq_fifo_depth=0, holdingbf=0 > Mar 28 07:03:02 jri kernel: HW TXQ 2: axq_depth=0, axq_aggr_depth=0, axq_fifo_depth=0, holdingbf=0 > Mar 28 07:03:02 jri kernel: HW TXQ 3: axq_depth=0, axq_aggr_depth=0, axq_fifo_depth=0, holdingbf=0 > Mar 28 07:03:02 jri kernel: HW TXQ 8: axq_depth=0, axq_aggr_depth=0, axq_fifo_depth=0, holdingbf=0 > Mar 28 07:03:02 jri kernel: Total TX buffers: 512; Total TX buffers busy: 0 (512) > Mar 28 07:03:02 jri kernel: Total mgmt TX buffers: 32; Total mgmt TX buffers busy: 0 > Mar 28 07:03:02 jri kernel: 0: fifolen: 16/16; head=0; tail=0 > Mar 28 07:03:02 jri kernel: 1: fifolen: 128/128; head=45; tail=45 > Mar 28 07:03:02 jri kernel: Total RX buffers in free list: 368 buffers > Mar 28 07:03:05 jri kernel: ath0: ath_edma_recv_proc_queue: handled npkts 0 > Mar 28 07:38:13 jri kernel: ath0: ath_edma_tx_processq: Q1: empty? > Mar 28 07:38:14 jri kernel: no tx bufs (empty list): 0 > Mar 28 07:38:14 jri kernel: no tx bufs (was busy): 0 > Mar 28 07:38:14 jri kernel: aggr single packet: 481 > Mar 28 07:38:14 jri kernel: aggr single packet w/ BAW closed: 0 > Mar 28 07:38:14 jri kernel: aggr non-baw packet: 20 > Mar 28 07:38:14 jri kernel: aggr aggregate packet: 1278 > Mar 28 07:38:14 jri kernel: aggr single packet low hwq: 13087 > Mar 28 07:38:14 jri kernel: aggr single packet RTS aggr limited: 0 > Mar 28 07:38:14 jri kernel: aggr sched, no work: 849 > Mar 28 07:38:14 jri kernel: 0: 0 1: 0 2: 318 3: 221 > Mar 28 07:38:14 jri kernel: 4: 331 5: 50 6: 221 7: 57 > Mar 28 07:38:14 jri kernel: 8: 35 9: 22 10: 13 11: 1 > Mar 28 07:38:14 jri kernel: 12: 5 13: 0 14: 1 15: 0 > Mar 28 07:38:14 jri kernel: 16: 2 17: 0 18: 0 19: 1 > Mar 28 07:38:14 jri kernel: 20: 0 21: 0 22: 0 23: 0 > Mar 28 07:38:14 jri kernel: 24: 0 25: 0 26: 0 27: 0 > Mar 28 07:38:14 jri kernel: 28: 0 29: 0 30: 0 31: 0 > Mar 28 07:38:14 jri kernel: 32: 0 33: 0 34: 0 35: 0 > Mar 28 07:38:14 jri kernel: 36: 0 37: 0 38: 0 39: 0 > Mar 28 07:38:14 jri kernel: 40: 0 41: 0 42: 0 43: 0 > Mar 28 07:38:14 jri kernel: 44: 0 45: 0 46: 0 47: 0 > Mar 28 07:38:14 jri kernel: 48: 0 49: 0 50: 0 51: 0 > Mar 28 07:38:14 jri kernel: 52: 0 53: 0 54: 0 55: 0 > Mar 28 07:38:14 jri kernel: 56: 0 57: 0 58: 0 59: 0 > Mar 28 07:38:14 jri kernel: 60: 0 61: 0 62: 0 63: 0 > Mar 28 07:38:14 jri kernel: > Mar 28 07:38:14 jri kernel: HW TXQ 0: axq_depth=0, axq_aggr_depth=0, axq_fifo_depth=0, holdingbf=0 > Mar 28 07:38:14 jri kernel: HW TXQ 1: axq_depth=0, axq_aggr_depth=0, axq_fifo_depth=0, holdingbf=0 > Mar 28 07:38:14 jri kernel: HW TXQ 2: axq_depth=0, axq_aggr_depth=0, axq_fifo_depth=0, holdingbf=0 > Mar 28 07:38:14 jri kernel: HW TXQ 3: axq_depth=0, axq_aggr_depth=0, axq_fifo_depth=0, holdingbf=0 > Mar 28 07:38:14 jri kernel: HW TXQ 8: axq_depth=0, axq_aggr_depth=0, axq_fifo_depth=0, holdingbf=0 > Mar 28 07:38:14 jri kernel: Total TX buffers: 512; Total TX buffers busy: 0 (512) > Mar 28 07:38:14 jri kernel: Total mgmt TX buffers: 32; Total mgmt TX buffers busy: 0 > Mar 28 07:38:14 jri kernel: 0: fifolen: 16/16; head=0; tail=0 > Mar 28 07:38:14 jri kernel: 1: fifolen: 128/128; head=27; tail=27 > Mar 28 07:38:14 jri kernel: Total RX buffers in free list: 368 buffers > Mar 28 07:38:32 jri kernel: ath0: ath_edma_recv_proc_queue: handled npkts 0 > > Also, whats the output if 'ifconfig wlan0 list sta'? I wonder what the > RSSI is and I do wonder why you see frequent disconnects. > My RSSI tends to be between 7.0 and 8.5, I don't think I've seen 9.0 yet. I'm still working on improving my signal but at least for right now it's stable enough to be usable. Try making a little Faraday cage around your router, or put openwrt on it and drop your signal down for your connection. Don't forget to add a dozen random wifi APs and devices. > [jri:/var/log] jisom% ifconfig wlan0 list sta > ADDR AID CHAN RATE RSSI IDLE TXSEQ RXSEQ CAPS FLAG > c0:c1:c0:35:19:88 1 1 26M 8.5 0 1865 29712 EP AQEHTRS RSN HTCAP WPS WME > Thanks, > > > Adrian > From owner-freebsd-wireless@FreeBSD.ORG Thu Mar 28 20:15:27 2013 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 2EE116E5 for ; Thu, 28 Mar 2013 20:15:27 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c:c05::22b]) by mx1.freebsd.org (Postfix) with ESMTP id B9D57D8 for ; Thu, 28 Mar 2013 20:15:26 +0000 (UTC) Received: by mail-wi0-f171.google.com with SMTP id hn17so3687480wib.4 for ; Thu, 28 Mar 2013 13:15:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=S4NaiD27bTotC05fdVn701S1eLWcSkhExQvDT1xuGEM=; b=mCobylJgzDQID13zOARm1tFa2oLrSW8deJ6TvmDabaguSGSi50NWlzXu1jJEmE7+CV kDW2b+2jjKw9x6inKKUfryFD9aAZM09vbENhtg6Dgw5jsGGdeJO6JwyE0ajIXR7PZWZ+ 6Q5ZxBspmAa+M6mTR8M1wtsj4Nqghhu4r1tv4bX8WqOF5T8RvQK3XicJ2Op0ytbfkS68 1ksk3Z6LTvtu8uQ1DLik+k3Utpw3PNx074BLmSQTlqiJ4E4RfwK3r4JpfKu7m/Lqql7t J20yBtHOjju/W1PJCexeTKUtoHpZj8Jlk7diPgibBaqZhdqWqgbiXgkwLAfioOyDfAQc 4NtQ== MIME-Version: 1.0 X-Received: by 10.181.11.164 with SMTP id ej4mr18879128wid.29.1364501725922; Thu, 28 Mar 2013 13:15:25 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.216.108.130 with HTTP; Thu, 28 Mar 2013 13:15:25 -0700 (PDT) In-Reply-To: <5154A3F1.1090200@gmail.com> References: <51522277.6040107@gmail.com> <51523B6F.5010506@gmail.com> <51538239.9030903@gmail.com> <5153852A.1040508@gmail.com> <5154A3F1.1090200@gmail.com> Date: Thu, 28 Mar 2013 13:15:25 -0700 X-Google-Sender-Auth: 6cLEaUL-0BfO_suCloUcdHn5TFY Message-ID: Subject: Re: [wip] ar9300 hostap support From: Adrian Chadd To: Joshua Isom Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-wireless@freebsd.org X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Discussions of 802.11 stack, tools device driver development." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Mar 2013 20:15:27 -0000 On 28 March 2013 13:11, Joshua Isom wrote: >> I'd like to see if any other TX queue has a frame hanging around in it >> that hasn't been completed. > > > I had syslogd pipe the output to a perl script to set the sysctl, not ideal > but effective I hope. I've got two today. > >> Mar 28 07:03:01 jri kernel: ath0: ath_edma_tx_processq: Q1: empty? .. interesting. This is the interesting bit. >> Mar 28 07:03:02 jri kernel: HW TXQ 0: axq_depth=0, axq_aggr_depth=0, >> axq_fifo_depth=0, holdingbf=0 >> Mar 28 07:03:02 jri kernel: HW TXQ 1: axq_depth=0, axq_aggr_depth=0, >> axq_fifo_depth=0, holdingbf=0 >> Mar 28 07:03:02 jri kernel: HW TXQ 2: axq_depth=0, axq_aggr_depth=0, >> axq_fifo_depth=0, holdingbf=0 >> Mar 28 07:03:02 jri kernel: HW TXQ 3: axq_depth=0, axq_aggr_depth=0, >> axq_fifo_depth=0, holdingbf=0 >> Mar 28 07:03:02 jri kernel: HW TXQ 8: axq_depth=0, axq_aggr_depth=0, >> axq_fifo_depth=0, holdingbf=0 Right. None of these have any frames stuck in the FIFO. Good. Now, I have to go chase down why we're seeing this. >> Also, whats the output if 'ifconfig wlan0 list sta'? I wonder what the >> RSSI is and I do wonder why you see frequent disconnects. >> > > My RSSI tends to be between 7.0 and 8.5, I don't think I've seen 9.0 yet. > I'm still working on improving my signal but at least for right now it's > stable enough to be usable. Try making a little Faraday cage around your > router, or put openwrt on it and drop your signal down for your connection. > Don't forget to add a dozen random wifi APs and devices. oh I have attenuators. :-) Is it plausibly 7-9 dB in your environment? :-) I'm worried that I've not done the chip setup right and it's acting deaf-y. Adrian From owner-freebsd-wireless@FreeBSD.ORG Thu Mar 28 20:31:17 2013 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 67B83E05; Thu, 28 Mar 2013 20:31:17 +0000 (UTC) (envelope-from jrisom@gmail.com) Received: from mail-ie0-x230.google.com (mail-ie0-x230.google.com [IPv6:2607:f8b0:4001:c03::230]) by mx1.freebsd.org (Postfix) with ESMTP id 2DFA2171; Thu, 28 Mar 2013 20:31:17 +0000 (UTC) Received: by mail-ie0-f176.google.com with SMTP id x14so11872154ief.7 for ; Thu, 28 Mar 2013 13:31:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=GB90e3yT7fkRT+FpOfhMgwox85hkxhq64E608sO05Nw=; b=VWdg1z3LwZ5Ih+jUQxjki3uuR09pO+3w3ixWx7bIMRUcPUhI3yEfhbiDuqqfu+ukMA 4S4KaIfRHKZAjY5Q3MntGs3kgL/tUVoVklRKET5KiSJGijVB7LermWvoT14x8wHnEKDr EG3kouLEaaA2K+g9J12eX9WbQ5TXPSW/5iHierQVl0ANFkR1qmUXM0gkXwVUy/4Grmn0 iX5pywOxiQk5f1Qg656wRTbajubgfQzroZDdNGbER7r+P/22yyHiIN89K1c4srjrb2k/ pwEC8L6FqwA3at2aEtsBzzxgvAdKh0VTnJWgw+ejQxzcgmpZfQAZoGL8Y9Qbb0phdGgK WBZg== X-Received: by 10.50.176.129 with SMTP id ci1mr8459100igc.53.1364502676476; Thu, 28 Mar 2013 13:31:16 -0700 (PDT) Received: from [192.168.1.44] (c-98-212-197-211.hsd1.il.comcast.net. [98.212.197.211]) by mx.google.com with ESMTPS id wn10sm11996713igb.2.2013.03.28.13.31.15 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 28 Mar 2013 13:31:15 -0700 (PDT) Message-ID: <5154A891.2010303@gmail.com> Date: Thu, 28 Mar 2013 15:31:13 -0500 From: Joshua Isom User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: Adrian Chadd Subject: Re: [wip] ar9300 hostap support References: <51522277.6040107@gmail.com> <51523B6F.5010506@gmail.com> <51538239.9030903@gmail.com> <5153852A.1040508@gmail.com> <5154A3F1.1090200@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-wireless@freebsd.org X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Discussions of 802.11 stack, tools device driver development." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Mar 2013 20:31:17 -0000 On 3/28/2013 3:15 PM, Adrian Chadd wrote: > On 28 March 2013 13:11, Joshua Isom wrote: > >>> I'd like to see if any other TX queue has a frame hanging around in it >>> that hasn't been completed. >> >> >> I had syslogd pipe the output to a perl script to set the sysctl, not ideal >> but effective I hope. I've got two today. >> >>> Mar 28 07:03:01 jri kernel: ath0: ath_edma_tx_processq: Q1: empty? > > .. interesting. > > > This is the interesting bit. > >>> Mar 28 07:03:02 jri kernel: HW TXQ 0: axq_depth=0, axq_aggr_depth=0, >>> axq_fifo_depth=0, holdingbf=0 >>> Mar 28 07:03:02 jri kernel: HW TXQ 1: axq_depth=0, axq_aggr_depth=0, >>> axq_fifo_depth=0, holdingbf=0 >>> Mar 28 07:03:02 jri kernel: HW TXQ 2: axq_depth=0, axq_aggr_depth=0, >>> axq_fifo_depth=0, holdingbf=0 >>> Mar 28 07:03:02 jri kernel: HW TXQ 3: axq_depth=0, axq_aggr_depth=0, >>> axq_fifo_depth=0, holdingbf=0 >>> Mar 28 07:03:02 jri kernel: HW TXQ 8: axq_depth=0, axq_aggr_depth=0, >>> axq_fifo_depth=0, holdingbf=0 > > Right. None of these have any frames stuck in the FIFO. Good. Now, I > have to go chase down why we're seeing this. > I just noticed something odd, it counts from 0, 1, 2, 3, 8. It skips 4-7 and 9. Why aren't the rest set up? > > oh I have attenuators. :-) > > Is it plausibly 7-9 dB in your environment? :-) I'm worried that I've > not done the chip setup right and it's acting deaf-y. > Every device has poor reception in that room, but FreeBSD is the only one I can get numbers from. That's why the antenna I'm doing is directional. My laptop has an Intel chip, and even Intel's "Advanced Statistics" gives me no real numbers. The best I could give you is a "bar" count. > > Adrian > From owner-freebsd-wireless@FreeBSD.ORG Thu Mar 28 20:33:40 2013 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 5BF7498 for ; Thu, 28 Mar 2013 20:33:40 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wg0-f45.google.com (mail-wg0-f45.google.com [74.125.82.45]) by mx1.freebsd.org (Postfix) with ESMTP id E5E4C1A3 for ; Thu, 28 Mar 2013 20:33:39 +0000 (UTC) Received: by mail-wg0-f45.google.com with SMTP id x12so1966666wgg.24 for ; Thu, 28 Mar 2013 13:33:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=t4TIhkRvqJf72MKLbWtcOtQ83EJOPfXXswjbhTeLavU=; b=gZqGkelQQhDakkX35e9+q0vsfCL01Jd1dp/xM8utfax0CieZlsqDxMl4qBjnJYs4qB RFjTGBWsCGnhU6+0HeMi7IGGkWlyl5f5JzFdQ1oi0Q5Hh2TbmrLglUPjSXEyj6qAb8AH pHkCvwONS50essXERiOcoj6VDoyBqAUr4r5ALwKhVbDxR3wMCtjcNG8CKKF0J9xsjviy xWk2En9e0vC4UhH75oeYH4pUKqWN51nbJ+07sHQcmMGdspRekLgPP148Wj5jbEMwQlAj grzYxqg1bd424dzUMFAstn0BaWBSGOBxYhkK/7D1aE02Ra0Nb2ciJ7Pc8FFy5FKEBYwS ZjhA== MIME-Version: 1.0 X-Received: by 10.194.22.5 with SMTP id z5mr83013wje.5.1364502818787; Thu, 28 Mar 2013 13:33:38 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.216.108.130 with HTTP; Thu, 28 Mar 2013 13:33:38 -0700 (PDT) In-Reply-To: <5154A891.2010303@gmail.com> References: <51522277.6040107@gmail.com> <51523B6F.5010506@gmail.com> <51538239.9030903@gmail.com> <5153852A.1040508@gmail.com> <5154A3F1.1090200@gmail.com> <5154A891.2010303@gmail.com> Date: Thu, 28 Mar 2013 13:33:38 -0700 X-Google-Sender-Auth: XnVzlpnXOOnHpvGTG1maG2SdavQ Message-ID: Subject: Re: [wip] ar9300 hostap support From: Adrian Chadd To: Joshua Isom Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-wireless@freebsd.org X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Discussions of 802.11 stack, tools device driver development." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Mar 2013 20:33:40 -0000 On 28 March 2013 13:31, Joshua Isom wrote: >> Right. None of these have any frames stuck in the FIFO. Good. Now, I >> have to go chase down why we're seeing this. >> > > I just noticed something odd, it counts from 0, 1, 2, 3, 8. It skips 4-7 > and 9. Why aren't the rest set up? Because they're not needed at this point. There's just four WME categories (best effort, bulk, voice, video) and we map each WME level to one hardware TX queue. Later on there'll be others (eg uapsd, bulk management frames) that will show up. But that's a later project. >> Is it plausibly 7-9 dB in your environment? :-) I'm worried that I've >> not done the chip setup right and it's acting deaf-y. >> > > Every device has poor reception in that room, but FreeBSD is the only one I > can get numbers from. That's why the antenna I'm doing is directional. My > laptop has an Intel chip, and even Intel's "Advanced Statistics" gives me no > real numbers. The best I could give you is a "bar" count. Ok, that's good to know. Adrian From owner-freebsd-wireless@FreeBSD.ORG Thu Mar 28 22:39:05 2013 Return-Path: Delivered-To: freebsd-wireless@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 86B1CD13; Thu, 28 Mar 2013 22:39:05 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 5F7C2887; Thu, 28 Mar 2013 22:39:05 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.6/8.14.6) with ESMTP id r2SMd5J5076150; Thu, 28 Mar 2013 22:39:05 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.6/8.14.6/Submit) id r2SMd5HZ076149; Thu, 28 Mar 2013 22:39:05 GMT (envelope-from linimon) Date: Thu, 28 Mar 2013 22:39:05 GMT Message-Id: <201303282239.r2SMd5HZ076149@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-wireless@FreeBSD.org From: linimon@FreeBSD.org Subject: Re: kern/177451: [ieee80211] page fault in ieee80211_tx_mgt_timeout X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Discussions of 802.11 stack, tools device driver development." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Mar 2013 22:39:05 -0000 Old Synopsis: page fault in ieee80211_tx_mgt_timeout New Synopsis: [ieee80211] page fault in ieee80211_tx_mgt_timeout Responsible-Changed-From-To: freebsd-bugs->freebsd-wireless Responsible-Changed-By: linimon Responsible-Changed-When: Thu Mar 28 22:38:47 UTC 2013 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=177451 From owner-freebsd-wireless@FreeBSD.ORG Fri Mar 29 21:30:03 2013 Return-Path: Delivered-To: freebsd-wireless@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 6D6B3BD9 for ; Fri, 29 Mar 2013 21:30:03 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 5FB97B8D for ; Fri, 29 Mar 2013 21:30:03 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.6/8.14.6) with ESMTP id r2TLU3BQ045534 for ; Fri, 29 Mar 2013 21:30:03 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.6/8.14.6/Submit) id r2TLU3Hx045533; Fri, 29 Mar 2013 21:30:03 GMT (envelope-from gnats) Date: Fri, 29 Mar 2013 21:30:03 GMT Message-Id: <201303292130.r2TLU3Hx045533@freefall.freebsd.org> To: freebsd-wireless@FreeBSD.org Cc: From: PseudoCylon Subject: Re: kern/177451: [ieee80211] page fault in ieee80211_tx_mgt_timeout X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: PseudoCylon 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, 29 Mar 2013 21:30:03 -0000 The following reply was made to PR kern/177451; it has been noted by GNATS. From: PseudoCylon To: bug-followup@FreeBSD.org, davide@FreeBSD.org Cc: Subject: Re: kern/177451: [ieee80211] page fault in ieee80211_tx_mgt_timeout Date: Fri, 29 Mar 2013 15:21:58 -0600 http://fxr.watson.org/fxr/source/net80211/ieee80211_output.c?v=FREEBSD91#L2506 enum ieee80211_state ostate = (enum ieee80211_state) arg; casting a pointer to an enum http://fxr.watson.org/fxr/source/net80211/ieee80211_output.c?v=FREEBSD91#L2519 if (vap->iv_state == ostate) So that, this test is always false -> callout_reset() will never be called -> by the time the callout timer runs out, ni could be freed. From owner-freebsd-wireless@FreeBSD.ORG Fri Mar 29 22:50:01 2013 Return-Path: Delivered-To: freebsd-wireless@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id A4663B98 for ; Fri, 29 Mar 2013 22:50:01 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 9532BE89 for ; Fri, 29 Mar 2013 22:50:01 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.6/8.14.6) with ESMTP id r2TMo1a4060082 for ; Fri, 29 Mar 2013 22:50:01 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.6/8.14.6/Submit) id r2TMo1qu060081; Fri, 29 Mar 2013 22:50:01 GMT (envelope-from gnats) Date: Fri, 29 Mar 2013 22:50:01 GMT Message-Id: <201303292250.r2TMo1qu060081@freefall.freebsd.org> To: freebsd-wireless@FreeBSD.org Cc: From: PseudoCylon Subject: Re: kern/177451: [ieee80211] page fault in ieee80211_tx_mgt_timeout X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: PseudoCylon 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, 29 Mar 2013 22:50:01 -0000 The following reply was made to PR kern/177451; it has been noted by GNATS. From: PseudoCylon To: bug-followup@freebsd.org, davide@freebsd.org Cc: Subject: Re: kern/177451: [ieee80211] page fault in ieee80211_tx_mgt_timeout Date: Fri, 29 Mar 2013 16:37:20 -0600 Oops. The code casts the enum to the pointer to begin, so it works. Sorry, for the noise. On Fri, Mar 29, 2013 at 3:21 PM, PseudoCylon wrote: > http://fxr.watson.org/fxr/source/net80211/ieee80211_output.c?v=FREEBSD91#L2506 > enum ieee80211_state ostate = (enum ieee80211_state) arg; > casting a pointer to an enum > > http://fxr.watson.org/fxr/source/net80211/ieee80211_output.c?v=FREEBSD91#L2519 > if (vap->iv_state == ostate) > So that, this test is always false -> callout_reset() will never be > called -> by the time the callout timer runs out, ni could be freed. From owner-freebsd-wireless@FreeBSD.ORG Sat Mar 30 23:34:44 2013 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id AA34DCFD for ; Sat, 30 Mar 2013 23:34:44 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wg0-f45.google.com (mail-wg0-f45.google.com [74.125.82.45]) by mx1.freebsd.org (Postfix) with ESMTP id 4914ACE for ; Sat, 30 Mar 2013 23:34:43 +0000 (UTC) Received: by mail-wg0-f45.google.com with SMTP id x12so1234759wgg.0 for ; Sat, 30 Mar 2013 16:34:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:date:x-google-sender-auth:message-id :subject:from:to:content-type; bh=9vmzfN+FBiCw8souWKLUrlhpWU2lhhM/l1OPrGcrCI0=; b=JQYjK9qMCbMiJn7AmcArc8yfF4ZjfEiX7N1b/qflFmJSgJWWjIHGjVIruuO5gikRt1 KEwthTw1gq5x2Q+GN0SyPaA7eZL6VbbE4oCC9c650O3VRk4+Guojf814x4yxG22PClUt 8lAVIXKYELtkQgpQY2icqKXN2i+hin1AeYzTU42dMIoe1II8b2omp9E3d0a5CxsjQsa3 XTRMha2n/kRVwcRMJmBkQU79tXlF8mxTrGIDUqafHyJq9fB8JKHd0Bh2AI7m4BIl1T1X bwHFkc4EQ1J5dPSNefchTZqGzPEhzPJYcSWfouIGPazsbqRzeNcGL8cgBRHBtaGyNqRo n6NQ== MIME-Version: 1.0 X-Received: by 10.194.120.169 with SMTP id ld9mr9552034wjb.24.1364686482279; Sat, 30 Mar 2013 16:34:42 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.216.108.130 with HTTP; Sat, 30 Mar 2013 16:34:42 -0700 (PDT) Date: Sat, 30 Mar 2013 16:34:42 -0700 X-Google-Sender-Auth: zDIyrPlNow6Rx0Oln0cKLJdGoBU Message-ID: Subject: [rft] ar9300 HAL updated From: Adrian Chadd To: freebsd-wireless@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Discussions of 802.11 stack, tools device driver development." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Mar 2013 23:34:44 -0000 Hi, I've just updated the AR9300 HAL to the March 13 snapshot from QCA. This includes calibration and TX power calibration changes that may improve stability. As always, it's possible I broke something! I'd appreciate it if people would test this in STA and AP mode. Thanks! Adrian