From owner-freebsd-wireless@FreeBSD.ORG Sun Mar 17 00:25: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 7ECB9EA5 for ; Sun, 17 Mar 2013 00:25:32 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-pd0-f175.google.com (mail-pd0-f175.google.com [209.85.192.175]) by mx1.freebsd.org (Postfix) with ESMTP id 5AD1B9B6 for ; Sun, 17 Mar 2013 00:25:32 +0000 (UTC) Received: by mail-pd0-f175.google.com with SMTP id r11so501428pdi.20 for ; Sat, 16 Mar 2013 17:25:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=ipOdG0H6pmqtUB+SvEeiim4goGEtKDAj7zZiRVN/MLg=; b=jOL/i3s40WF3AeqP6BFyUh2oY2VVeI9/jd26Jy2qv7JX1bY7DkJxBrZ1SIioSqS1/3 J3/eUmRKGL6L+92vi94Vt2zf5X9Ov26dOgwhg9iGs7QMFQDsuMmrRv+ZgKY3q7CsakBj h6heNwUoy3ISTIg4JB2DRRFB2VBAMWYY4tthnoqRAlPO9+FezYOFuL/7KQMqEXRuhU2C PvNermF6EwhQJH6zIQB2AS7isWU7Bg0i+GcbFz5weY9S06nBloR2R1QwFuke4gBv1Mi5 MSwm0RTlsbkctEHlEQkn6vBZLO1yW5wECw29swcqMYX1FOAaNw+gf0iwcVuCsEUcRvRD 98lQ== MIME-Version: 1.0 X-Received: by 10.68.143.106 with SMTP id sd10mr11562708pbb.50.1363479926046; Sat, 16 Mar 2013 17:25:26 -0700 (PDT) Received: by 10.70.39.69 with HTTP; Sat, 16 Mar 2013 17:25:25 -0700 (PDT) In-Reply-To: <5143A1C3.7010304@gmail.com> References: <5142813d.83c2e00a.67a8.39d5@mx.google.com> <514284E5.9060303@gmail.com> <51428E10.1000801@gmail.com> <78975985-a190-4915-82b5-b1810d6115b2@email.android.com> <5143A1C3.7010304@gmail.com> Date: Sat, 16 Mar 2013 17:25:25 -0700 Message-ID: Subject: Re: Fine, OK, here's my initial AR9380/AR9485 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: Sun, 17 Mar 2013 00:25:32 -0000 On 15 March 2013 15:33, Joshua Isom wrote: >> 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 >> 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 .. I really should remove that, but. >> 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 Cool, normal AR9380. Nothing fancy. >> ath0: 2GHz radio: 0x0000; 5GHz radio: 0x0000 >> ar9300_Stub_GetSlotTime: called >> ar9300_Stub_GetSlotTime: called >> ar9300_Stub_GetCTSTimeout: called >> ar9300_Stub_GetCTSTimeout: called >> ar9300_Stub_GetAntennaSwitch: called >> ar9300_Stub_GetAntennaSwitch: called Ok. I should implement those stub routines in the driver. Can you file a bug report (against my fork, not the qca tree) with the above stubs? That way I don't forget. I wonder why you see them and I don't. Or do I just never check dmesg. >> wlan0: Ethernet address: 64:70:02:18:6d:95 >> ath0: ath_edma_recv_proc_queue: handled npkts 0 ngood 0 >> ath0: ath_edma_recv_proc_queue: handled npkts 0 ngood 0 >> ath0: ath_edma_recv_proc_queue: handled npkts 0 ngood 0 >> ath0: ath_edma_recv_proc_queue: handled npkts 0 ngood 0 >> ath0: ath_edma_recv_proc_queue: handled npkts 0 ngood 0 >> ath0: ath_edma_recv_proc_queue: handled npkts 0 ngood 0 >> ath0: ath_edma_recv_proc_queue: handled npkts 0 ngood 0 >> ath0: ath_edma_recv_proc_queue: handled npkts 0 ngood 0 >> ath0: ath_edma_recv_proc_queue: handled npkts 0 ngood 0 >> ath0: ath_edma_recv_proc_queue: handled npkts 0 ngood 0 >> ath0: ath_edma_recv_proc_queue: handled npkts 0 ngood 0 >> ath0: ath_edma_recv_proc_queue: handled npkts 0 ngood 0 >> ath0: ath_edma_recv_proc_queue: handled npkts 0 ngood 0 >> ath0: ath_edma_recv_proc_queue: handled npkts 0 ngood 0 >> ath0: ath_edma_recv_proc_queue: handled npkts 0 ngood 0 >> ath0: ath_edma_recv_proc_queue: handled npkts 0 ngood 0 >> ath0: ath_edma_recv_proc_queue: handled npkts 0 ngood 0 >> ath0: ath_edma_recv_proc_queue: handled npkts 0 ngood 0 >> ath0: ath_edma_recv_proc_queue: handled npkts 0 ngood 0 >> ath0: ath_edma_recv_proc_queue: handled npkts 0 ngood 0 >> ath0: ath_edma_recv_proc_queue: handled npkts 0 ngood 0 >> ath0: ath_edma_recv_proc_queue: handled npkts 0 ngood 0 >> ath0: ath_edma_recv_proc_queue: handled npkts 0 ngood 0 >> ath0: ath_edma_recv_proc_queue: handled npkts 0 ngood 0 >> ath0: ath_edma_recv_proc_queue: handled npkts 0 ngood 0 >> ath0: ath_edma_recv_proc_queue: handled npkts 0 ngood 0 >> ath0: ath_edma_recv_proc_queue: handled npkts 0 ngood 0 >> ath0: ath_edma_recv_proc_queue: handled npkts 0 ngood 0 >> ath0: ath_edma_recv_proc_queue: handled npkts 0 ngood 0 This is well known. For some odd reason I get a RXEOL interrupt when I initialise the RX FIFO. I don't know why yet. It's harmless but I'd like to figure out why. >> ar9300_reset[4254]: ar9300_stop_dma_receive failed Likely another channel scan, maybe? Or maybe it finally associated? >> ath0: ath_edma_recv_proc_queue: handled npkts 0 ngood 0 Thanks for being patient so far! Adrian From owner-freebsd-wireless@FreeBSD.ORG Sun Mar 17 06:24:06 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 1428AD6F for ; Sun, 17 Mar 2013 06:24:06 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-pb0-f50.google.com (mail-pb0-f50.google.com [209.85.160.50]) by mx1.freebsd.org (Postfix) with ESMTP id D0DF7308 for ; Sun, 17 Mar 2013 06:24:05 +0000 (UTC) Received: by mail-pb0-f50.google.com with SMTP id up1so5447283pbc.23 for ; Sat, 16 Mar 2013 23:23:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=9bG1BVF36RdTGvoL/mBNXV6vlf/sbiQ8PPrgOGHnCZs=; b=W0XCfyrA7BqFPXG1qVmiwLUCgs9/1HR5pvioLhY3Usfl24MNm8TYmyIXMU0q5dqdN+ CHV27ioFhdMNfF28/jKNYQ/2HHyWbzK7AvD3PXtlCzVeUTGENAW5Le4HAiTlIiU1Dx+H or9alVwk92E0jw1Mmkx5MJHppvFi11bASRL+Q3qh27Na+t08M3LGPkoMQdpteiLe6Fnr 5rLtd+Mt7sSf9p746f92pfqDBwn1c3JKZFq/zGgBVO0/abTUBwBb4v5EpugDINMm/CWZ bEGTRyiXp0tHVH7s0PVjxtO9kj2LL5O7eUP5LSRIJBAPgOWSJwhscUPzYmZFIDLJrRbA POXg== MIME-Version: 1.0 X-Received: by 10.66.230.198 with SMTP id ta6mr4145816pac.126.1363501439875; Sat, 16 Mar 2013 23:23:59 -0700 (PDT) Received: by 10.70.39.69 with HTTP; Sat, 16 Mar 2013 23:23:59 -0700 (PDT) In-Reply-To: References: <5142813d.83c2e00a.67a8.39d5@mx.google.com> <514284E5.9060303@gmail.com> <51428E10.1000801@gmail.com> <78975985-a190-4915-82b5-b1810d6115b2@email.android.com> <5143A1C3.7010304@gmail.com> Date: Sat, 16 Mar 2013 23:23:59 -0700 Message-ID: Subject: Re: Fine, OK, here's my initial AR9380/AR9485 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: Sun, 17 Mar 2013 06:24:06 -0000 I've just fixed a couple things with the AR9300 HAL: * I've implemented a "get slot time" method, so one stub function call message should disappear; * I've fixed a quirk with slot/ack/rtscts timeout calculations in HT40 - the AR9300 HAL was compensating for the 40Mhz width of the channel, but FreeBSD's HAL library call already does this. So now the HAL doesn't double compensate for this. * I broke and then fixed some compile time issues. Please update and test! Thanks, Adrian From owner-freebsd-wireless@FreeBSD.ORG Sun Mar 17 14:07:52 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 68905342 for ; Sun, 17 Mar 2013 14:07:52 +0000 (UTC) (envelope-from lwhsu.freebsd@gmail.com) Received: from mail-pb0-f46.google.com (mail-pb0-f46.google.com [209.85.160.46]) by mx1.freebsd.org (Postfix) with ESMTP id 3301A297 for ; Sun, 17 Mar 2013 14:07:52 +0000 (UTC) Received: by mail-pb0-f46.google.com with SMTP id uo15so5731738pbc.33 for ; Sun, 17 Mar 2013 07:07: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=isZ+UEFIaGraFvmfVCWZj9rWd6SfeFWW52SV5EcLw98=; b=HYbcCFV9AeHeo/YE3Vdx3hUqW9Xj8ySkuCa9E+mB6NgYvgvsHu6Yuc3MHcVK0OZ/gg d7/YrC+DNZ7u7a+wWoE1rATUGrpRF6c6kheGUKiEnAE6SsJQAnyn9hcrlRPNGgpxQiPj o8I0Ol5Ks9Uig9h7txy0xQVHx0mBHUFBfEnm/JVRBLbqlOduIhxxJdeJnFAUsRGQICBc XXjp/eQzuZ1ph4gYUNmsxPnBeUBty2hZKa0PxIYlsRBOuUgYebsIrtvklfRgvxBEkuBB GEs5ErAO4ycJhujWefItmKx6Xq7c8GH/KD8xBZxdqzEDfAK1wsspoXIwPWXeuzmkjYoJ f5eg== MIME-Version: 1.0 X-Received: by 10.68.244.1 with SMTP id xc1mr27721949pbc.165.1363529266408; Sun, 17 Mar 2013 07:07:46 -0700 (PDT) Sender: lwhsu.freebsd@gmail.com Received: by 10.68.59.169 with HTTP; Sun, 17 Mar 2013 07:07:46 -0700 (PDT) In-Reply-To: References: <5142813d.83c2e00a.67a8.39d5@mx.google.com> <514284E5.9060303@gmail.com> <51428E10.1000801@gmail.com> <78975985-a190-4915-82b5-b1810d6115b2@email.android.com> <5143A1C3.7010304@gmail.com> Date: Sun, 17 Mar 2013 22:07:46 +0800 X-Google-Sender-Auth: TTb-O9_FORCPSYLCoWMuuBNKFVE Message-ID: Subject: Re: Fine, OK, here's my initial AR9380/AR9485 support From: Li-Wen Hsu To: Adrian Chadd Content-Type: text/plain; charset=UTF-8 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, 17 Mar 2013 14:07:52 -0000 On Sun, Mar 17, 2013 at 2:23 PM, Adrian Chadd wrote: > I've just fixed a couple things with the AR9300 HAL: > > * I've implemented a "get slot time" method, so one stub function call > message should disappear; > * I've fixed a quirk with slot/ack/rtscts timeout calculations in HT40 > - the AR9300 HAL was compensating for the 40Mhz width of the channel, > but FreeBSD's HAL library call already does this. So now the HAL > doesn't double compensate for this. > * I broke and then fixed some compile time issues. > > Please update and test! Thanks make this work, after updating to r248420 with commit f56a13fa8492944f899d4d1b23b8a068bc543c4c on github. I finally got my AR9380 work. -- Li-Wen Hsu http://lwhsu.org From owner-freebsd-wireless@FreeBSD.ORG Sun Mar 17 14:43:39 2013 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id ABD92EE2 for ; Sun, 17 Mar 2013 14:43:39 +0000 (UTC) (envelope-from lwhsu.freebsd@gmail.com) Received: from mail-da0-x233.google.com (mail-da0-x233.google.com [IPv6:2607:f8b0:400e:c00::233]) by mx1.freebsd.org (Postfix) with ESMTP id 5CED03CF for ; Sun, 17 Mar 2013 14:43:39 +0000 (UTC) Received: by mail-da0-f51.google.com with SMTP id g27so2838dan.10 for ; Sun, 17 Mar 2013 07:43: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=nSbp/8fMMsjXfmTh/8amqnZkcdno2y9nT+SeqBIU7fQ=; b=yodnmXefH0at2tOET1SgzBUpnAYe4q09Q2wkjek3aePUHZlCW4zp/7cfsUaZQL0vuv E2HifkZahSAG6hQPuOKn8YA0gsUZIDoKajMks3f7/jljB0sFZv14AvwGLHmjzt6FIPVl vDTJ4mnCvdPfjoAdDuXB7dgZBNIj9Ddm+eNprtYy/SL2L8cQ8ac8ReyTyM4JSK0M6E73 QgjwLq5Nur4P/Uru9T37RgOq5iJAclDLJTvOJltwfZ0scwzK2CqIU7KyMW17+kvkDuSS k+L9DD/E3oYdGFAj7UBF0RlkoLvw0aLHPlA3Fz7uaISWNot+NWi5ZFefeqBAsTSeGfb1 +TKw== MIME-Version: 1.0 X-Received: by 10.68.143.197 with SMTP id sg5mr28672162pbb.101.1363531418601; Sun, 17 Mar 2013 07:43:38 -0700 (PDT) Sender: lwhsu.freebsd@gmail.com Received: by 10.68.59.169 with HTTP; Sun, 17 Mar 2013 07:43:38 -0700 (PDT) In-Reply-To: References: <5142813d.83c2e00a.67a8.39d5@mx.google.com> <514284E5.9060303@gmail.com> <51428E10.1000801@gmail.com> <78975985-a190-4915-82b5-b1810d6115b2@email.android.com> <5143A1C3.7010304@gmail.com> Date: Sun, 17 Mar 2013 22:43:38 +0800 X-Google-Sender-Auth: IQtkHRvcfacVm-ghjVJoA90hH_M Message-ID: Subject: Re: Fine, OK, here's my initial AR9380/AR9485 support From: Li-Wen Hsu To: Adrian Chadd Content-Type: text/plain; charset=UTF-8 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, 17 Mar 2013 14:43:39 -0000 On Sun, Mar 17, 2013 at 10:07 PM, Li-Wen Hsu wrote: > On Sun, Mar 17, 2013 at 2:23 PM, Adrian Chadd wrote: >> I've just fixed a couple things with the AR9300 HAL: >> >> * I've implemented a "get slot time" method, so one stub function call >> message should disappear; >> * I've fixed a quirk with slot/ack/rtscts timeout calculations in HT40 >> - the AR9300 HAL was compensating for the 40Mhz width of the channel, >> but FreeBSD's HAL library call already does this. So now the HAL >> doesn't double compensate for this. >> * I broke and then fixed some compile time issues. >> >> Please update and test! > > Thanks make this work, after updating to r248420 with commit > f56a13fa8492944f899d4d1b23b8a068bc543c4c on github. > I finally got my AR9380 work. Oops, accidentally clicked on "send." Before the changes you made yesterday, I can only see it got found by kernel, but was unable to get IP through DHCP, and the status of wlan0 was flipping between associated and no carrier, while ath0 is always associated. Don't know if this has something to do with that I'm using WPA2. Thanks making this work, even I haven't posted my report. :) I am using clang from head, and this patch is needed: diff --git a/hal/ar9300/ar9300_radio.c b/hal/ar9300/ar9300_radio.c index 2f3bb3f..aedb76f 100644 --- a/hal/ar9300/ar9300_radio.c +++ b/hal/ar9300/ar9300_radio.c @@ -80,7 +80,7 @@ ar9300_set_channel(struct ath_hal *ah, struct ieee80211_channel *chan) u_int8_t clk_25mhz = AH9300(ah)->clk_25mhz; CHAN_CENTERS centers; int load_synth_channel; -#ifdef AH_DEBUG +#if defined(AH_DEBUG) && defined(AH_DEBUG_ALQ) HAL_CHANNEL_INTERNAL *ichan = ath_hal_checkchannel(ah, chan); #endif This is absolutely not a good fix, but it seems that we can get it off after finishing TODOs in that file. And it looks that the code will be import to contrib/sys/dev/ath/ath_hal/ar9300, but the current instructions still are: $ cd sys/dev/ath/ath_hal/ar9003/ $ ln -s /path/to/git/qcamain_open_hal_public/hal/ar9300/* . So this is still needed: $ ln -s sys/dev/ath/ath_hal/ar9003 sys/dev/ath/ath_hal/ar9300 as well as this patch: Index: sys/modules/ath/Makefile =================================================================== --- sys/modules/ath/Makefile (revision 248420) +++ sys/modules/ath/Makefile (working copy) @@ -125,12 +125,13 @@ # + AR9300 HAL # .PATH: ${.CURDIR}/../../contrib/sys/dev/ath/ath_hal/ar9300 -#SRCS+= ar9300_interrupts.c ar9300_radar.c ar9300_ani.c ar9300_keycache.c -#SRCS+= ar9300_radio.c ar9300_xmit.c ar9300_attach.c ar9300_mci.c ar9300_stub.c -#SRCS+= ar9300_xmit_ds.c ar9300_beacon.c ar9300_misc.c ar9300_recv.c -#SRCS+= ar9300_stub_funcs.c ar9300_eeprom.c ar9300_paprd.c ar9300_recv_ds.c -#SRCS+= ar9300_freebsd.c ar9300_phy.c ar9300_reset.c ar9300_gpio.c -#SRCS+= ar9300_power.c ar9300_timer.c +.PATH: ${.CURDIR}/../../../sys/dev/ath/ath_hal/ar9300 +SRCS+= ar9300_interrupts.c ar9300_radar.c ar9300_ani.c ar9300_keycache.c +SRCS+= ar9300_radio.c ar9300_xmit.c ar9300_attach.c ar9300_mci.c ar9300_stub.c +SRCS+= ar9300_xmit_ds.c ar9300_beacon.c ar9300_misc.c ar9300_recv.c +SRCS+= ar9300_stub_funcs.c ar9300_eeprom.c ar9300_paprd.c ar9300_recv_ds.c +SRCS+= ar9300_freebsd.c ar9300_phy.c ar9300_reset.c ar9300_gpio.c +SRCS+= ar9300_power.c ar9300_timer.c # NB: rate control is bound to the driver by symbol names so only pick one .if ${ATH_RATE} == "sample" @@ -164,5 +165,5 @@ CWARNFLAGS+= ${CWARNFLAGS.${.IMPSRC:T}} # AR9300 HAL build overrides, as there's still some code to tidy up -#CWARNFLAGS.ar9300_eeprom.c= ${NO_WCONSTANT_CONVERSION} -#CWARNFLAGS.ar9300_reset.c= ${NO_WSOMETIMES_UNINITIALIZED} +CWARNFLAGS.ar9300_eeprom.c= ${NO_WCONSTANT_CONVERSION} +CWARNFLAGS.ar9300_reset.c= ${NO_WSOMETIMES_UNINITIALIZED} Following is my dmesg output (after loading if_ath.ko & if_ath_pci.ko) ath0: mem 0xf2600000-0xf261ffff 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 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 entriesath0: 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 1140.8 ath0: 2GHz radio: 0x0000; 5GHz radio: 0x0000 wlan0: Ethernet address: xx:xx:xx:xx:xx:xx (masked when posting) ath0: ath_edma_recv_proc_queue: handled npkts 0 ngood 0 ath0: ath_edma_recv_proc_queue: handled npkts 0 ngood 0 ath0: ath_edma_recv_proc_queue: handled npkts 0 ngood 0 ath0: ath_edma_recv_proc_queue: handled npkts 0 ngood 0 ath0: ath_edma_recv_proc_queue: handled npkts 0 ngood 0 ath0: ath_edma_recv_proc_queue: handled npkts 0 ngood 0 ath0: ath_edma_recv_proc_queue: handled npkts 0 ngood 0 ath0: ath_edma_recv_proc_queue: handled npkts 0 ngood 0 ath0: ath_edma_recv_proc_queue: handled npkts 0 ngood 0 ath0: ath_edma_recv_proc_queue: handled npkts 0 ngood 0 ath0: ath_edma_recv_proc_queue: handled npkts 0 ngood 0 ath0: ath_edma_recv_proc_queue: handled npkts 0 ngood 0 ath0: ath_edma_recv_proc_queue: handled npkts 0 ngood 0 ath0: ath_edma_recv_proc_queue: handled npkts 0 ngood 0 ath0: ath_edma_recv_proc_queue: handled npkts 0 ngood 0 ath0: ath_edma_recv_proc_queue: handled npkts 0 ngood 0 ath0: ath_edma_recv_proc_queue: handled npkts 0 ngood 0 ath0: ath_edma_recv_proc_queue: handled npkts 0 ngood 0 wlan0: link state changed to UP Thanks again for making this work, I am happy to help with further testing and debugging. Cheers, Li-Wen -- Li-Wen Hsu http://lwhsu.org From owner-freebsd-wireless@FreeBSD.ORG Sun Mar 17 15:03:42 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 4313D6B1 for ; Sun, 17 Mar 2013 15:03:42 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com [IPv6:2a00:1450:400c:c05::22e]) by mx1.freebsd.org (Postfix) with ESMTP id BBA4764F for ; Sun, 17 Mar 2013 15:03:41 +0000 (UTC) Received: by mail-wi0-f174.google.com with SMTP id hi8so1829127wib.13 for ; Sun, 17 Mar 2013 08:03:40 -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=8/GOWgOl/Sels3M8Rt/Go/sOR+X0fuJKyZR1PJulqTY=; b=emBxw9We86DFhGpGoCpBYgckbfUPI9G/b2OuIjwGwvJt7q+tgPDK9SyVPVxyX/BKOP hItqE3qer5c9pfnnrhTiFcAQb0BkYKAvgIFEnoIRL64XccCb5E2PDNm0dXhQJzRgHWi9 T5AjsgI7vgSSj62wsHFW12QJZLNcp/NLuIb+t+5VKbLzZb6bHz3x1BlN1uJf5TGqF3Vh e/RPPM4Ea+Frb4MDbV7VJ93dt3xH0ZIo8cSFIHujcF8z1GCVILWBLYkW3vU6sSkTNahZ amWlBq6ySN02qQFoZXzBbvI3fAHvC2ODlSmQ4V/v4VXIH4DZ/42luC/wmtAiyPvvMXZ2 n32Q== MIME-Version: 1.0 X-Received: by 10.180.87.129 with SMTP id ay1mr11685326wib.1.1363532620885; Sun, 17 Mar 2013 08:03:40 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.216.111.201 with HTTP; Sun, 17 Mar 2013 08:03:40 -0700 (PDT) In-Reply-To: <514584A5.6090601@gmx.net> References: <51175C69.6050003@gmx.net> <511E910D.1080901@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> Date: Sun, 17 Mar 2013 08:03:40 -0700 X-Google-Sender-Auth: 5TwfF_GrQ29gj5D8XhVagdycWkY Message-ID: Subject: Re: ath0: device timeout on 9.1-RELEASE From: Adrian Chadd To: Kamil Szczesny 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, 17 Mar 2013 15:03:42 -0000 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, Adrian From owner-freebsd-wireless@FreeBSD.ORG Sun Mar 17 21:22:14 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 971176FA for ; Sun, 17 Mar 2013 21:22:14 +0000 (UTC) (envelope-from jrisom@gmail.com) Received: from mail-ia0-x22c.google.com (mail-ia0-x22c.google.com [IPv6:2607:f8b0:4001:c02::22c]) by mx1.freebsd.org (Postfix) with ESMTP id 62E492DF for ; Sun, 17 Mar 2013 21:22:14 +0000 (UTC) Received: by mail-ia0-f172.google.com with SMTP id l29so4751154iag.31 for ; Sun, 17 Mar 2013 14:22:14 -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=+22OUyQnYnGi3JzHk0jG5LGyAao6QXe/hhO4d1jCqK4=; b=mH40tFCG2AWeuil1HcIB0G8pO9uIvyUGPyxsZmO5m9CDTmVGajjb7VW/su/IdafK0R bvW2+UuNZeX935VeQXIn09eTCKWR3uFjLEjR361l5DUI1nZGGfrp0PmRuC5RgL8KcXj+ SHf0zPpM43hdNU/tSTpd2vlltMW/NtuQdaxIqFqzsagdYAtrLzN0Ld2hNzT/xB6gn18j IsYSMxKmuA5jJxDsGK7DhTh+WHpzU7iA2Ux0BDbzdqpQTqmg3zLdV37OrTyWbRYmGEdm Xwc8j2AYcFA3oa85fk4KvqkBELg5j/Ow5IPdrG7PQuZJol5XlnPUyoqwEIgX/6OZ1swb KinA== X-Received: by 10.50.187.225 with SMTP id fv1mr5210186igc.74.1363555334160; Sun, 17 Mar 2013 14:22:14 -0700 (PDT) Received: from [192.168.1.14] (c-98-212-197-211.hsd1.il.comcast.net. [98.212.197.211]) by mx.google.com with ESMTPS id ih1sm6917869igc.3.2013.03.17.14.22.12 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 17 Mar 2013 14:22:13 -0700 (PDT) Message-ID: <514633FF.6070108@gmail.com> Date: Sun, 17 Mar 2013 16:22:07 -0500 From: Joshua Isom User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: Adrian Chadd Subject: Re: Fine, OK, here's my initial AR9380/AR9485 support References: <5142813d.83c2e00a.67a8.39d5@mx.google.com> <514284E5.9060303@gmail.com> <51428E10.1000801@gmail.com> <78975985-a190-4915-82b5-b1810d6115b2@email.android.com> <5143A1C3.7010304@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: Sun, 17 Mar 2013 21:22:14 -0000 How do you file a bug report against the fork? On 3/16/2013 7:25 PM, Adrian Chadd wrote: > On 15 March 2013 15:33, Joshua Isom wrote: > >>> 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 >>> 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 > > .. I really should remove that, but. > >>> 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 > > Cool, normal AR9380. Nothing fancy. > >>> ath0: 2GHz radio: 0x0000; 5GHz radio: 0x0000 > >>> ar9300_Stub_GetSlotTime: called >>> ar9300_Stub_GetSlotTime: called >>> ar9300_Stub_GetCTSTimeout: called >>> ar9300_Stub_GetCTSTimeout: called >>> ar9300_Stub_GetAntennaSwitch: called >>> ar9300_Stub_GetAntennaSwitch: called > > Ok. I should implement those stub routines in the driver. Can you file > a bug report (against my fork, not the qca tree) with the above stubs? > That way I don't forget. > > I wonder why you see them and I don't. Or do I just never check dmesg. > >>> wlan0: Ethernet address: 64:70:02:18:6d:95 >>> ath0: ath_edma_recv_proc_queue: handled npkts 0 ngood 0 >>> ath0: ath_edma_recv_proc_queue: handled npkts 0 ngood 0 >>> ath0: ath_edma_recv_proc_queue: handled npkts 0 ngood 0 >>> ath0: ath_edma_recv_proc_queue: handled npkts 0 ngood 0 >>> ath0: ath_edma_recv_proc_queue: handled npkts 0 ngood 0 >>> ath0: ath_edma_recv_proc_queue: handled npkts 0 ngood 0 >>> ath0: ath_edma_recv_proc_queue: handled npkts 0 ngood 0 >>> ath0: ath_edma_recv_proc_queue: handled npkts 0 ngood 0 >>> ath0: ath_edma_recv_proc_queue: handled npkts 0 ngood 0 >>> ath0: ath_edma_recv_proc_queue: handled npkts 0 ngood 0 >>> ath0: ath_edma_recv_proc_queue: handled npkts 0 ngood 0 >>> ath0: ath_edma_recv_proc_queue: handled npkts 0 ngood 0 >>> ath0: ath_edma_recv_proc_queue: handled npkts 0 ngood 0 >>> ath0: ath_edma_recv_proc_queue: handled npkts 0 ngood 0 >>> ath0: ath_edma_recv_proc_queue: handled npkts 0 ngood 0 >>> ath0: ath_edma_recv_proc_queue: handled npkts 0 ngood 0 >>> ath0: ath_edma_recv_proc_queue: handled npkts 0 ngood 0 >>> ath0: ath_edma_recv_proc_queue: handled npkts 0 ngood 0 >>> ath0: ath_edma_recv_proc_queue: handled npkts 0 ngood 0 >>> ath0: ath_edma_recv_proc_queue: handled npkts 0 ngood 0 >>> ath0: ath_edma_recv_proc_queue: handled npkts 0 ngood 0 >>> ath0: ath_edma_recv_proc_queue: handled npkts 0 ngood 0 >>> ath0: ath_edma_recv_proc_queue: handled npkts 0 ngood 0 >>> ath0: ath_edma_recv_proc_queue: handled npkts 0 ngood 0 >>> ath0: ath_edma_recv_proc_queue: handled npkts 0 ngood 0 >>> ath0: ath_edma_recv_proc_queue: handled npkts 0 ngood 0 >>> ath0: ath_edma_recv_proc_queue: handled npkts 0 ngood 0 >>> ath0: ath_edma_recv_proc_queue: handled npkts 0 ngood 0 >>> ath0: ath_edma_recv_proc_queue: handled npkts 0 ngood 0 > > This is well known. For some odd reason I get a RXEOL interrupt when I > initialise the RX FIFO. I don't know why yet. It's harmless but I'd > like to figure out why. > >>> ar9300_reset[4254]: ar9300_stop_dma_receive failed > > Likely another channel scan, maybe? Or maybe it finally associated? > >>> ath0: ath_edma_recv_proc_queue: handled npkts 0 ngood 0 > > Thanks for being patient so far! > > > > Adrian > From owner-freebsd-wireless@FreeBSD.ORG Sun Mar 17 21:40: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 4A384AA0 for ; Sun, 17 Mar 2013 21:40:09 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wg0-f43.google.com (mail-wg0-f43.google.com [74.125.82.43]) by mx1.freebsd.org (Postfix) with ESMTP id CE9DC38B for ; Sun, 17 Mar 2013 21:40:08 +0000 (UTC) Received: by mail-wg0-f43.google.com with SMTP id e12so4207034wge.22 for ; Sun, 17 Mar 2013 14:40:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=UQ1/fsIvLaEATTw6N4PP6rOSM6IRsFosCeCQmyv9uOw=; b=RCpxHx2Ye7DZSp1JFiLhep/UkNqLJ6rEkirSXjv/g7lHiAu3HeG1588SKuZdplbbdr cnH5fFBtcikkf5khGgU3VyCa3zxEa9hfXrp74fzSWCshACtQ6XSz2AxM04ETLylnWaBi 7CxGHk/xIaPYG5bmkz+UinRhfANmYbGktHEhjO34KVv1a+/o0zXATvHvT1SIKZOyh0WT IOgq0IJaog7pq+u4VaQ/k6zm7faOKpLu3RaxHVBbob7E2HuRzVhF5cvDO9EvD5kh2P1p OH6tnSLnov4mqhzfuOiTUXRRovkmPZnDxgL+b5S76qOXML6u9T50jO3RDqg+744i2v9f 3cig== MIME-Version: 1.0 X-Received: by 10.194.237.129 with SMTP id vc1mr20803053wjc.20.1363556402215; Sun, 17 Mar 2013 14:40:02 -0700 (PDT) Received: by 10.216.111.201 with HTTP; Sun, 17 Mar 2013 14:40:01 -0700 (PDT) In-Reply-To: <514633FF.6070108@gmail.com> References: <5142813d.83c2e00a.67a8.39d5@mx.google.com> <514284E5.9060303@gmail.com> <51428E10.1000801@gmail.com> <78975985-a190-4915-82b5-b1810d6115b2@email.android.com> <5143A1C3.7010304@gmail.com> <514633FF.6070108@gmail.com> Date: Sun, 17 Mar 2013 14:40:01 -0700 Message-ID: Subject: Re: Fine, OK, here's my initial AR9380/AR9485 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: Sun, 17 Mar 2013 21:40:09 -0000 Just go to my github - github.com/erikarn/ - then click on repositories, then the HAL fork, then just file an issue there. Adrian On 17 March 2013 14:22, Joshua Isom wrote: > How do you file a bug report against the fork? > > > On 3/16/2013 7:25 PM, Adrian Chadd wrote: >> >> On 15 March 2013 15:33, Joshua Isom wrote: >> >>>> 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 >>>> 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 >> >> >> .. I really should remove that, but. >> >>>> 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 >> >> >> Cool, normal AR9380. Nothing fancy. >> >>>> ath0: 2GHz radio: 0x0000; 5GHz radio: 0x0000 >> >> >>>> ar9300_Stub_GetSlotTime: called >>>> ar9300_Stub_GetSlotTime: called >>>> ar9300_Stub_GetCTSTimeout: called >>>> ar9300_Stub_GetCTSTimeout: called >>>> ar9300_Stub_GetAntennaSwitch: called >>>> ar9300_Stub_GetAntennaSwitch: called >> >> >> Ok. I should implement those stub routines in the driver. Can you file >> a bug report (against my fork, not the qca tree) with the above stubs? >> That way I don't forget. >> >> I wonder why you see them and I don't. Or do I just never check dmesg. >> >>>> wlan0: Ethernet address: 64:70:02:18:6d:95 >>>> ath0: ath_edma_recv_proc_queue: handled npkts 0 ngood 0 >>>> ath0: ath_edma_recv_proc_queue: handled npkts 0 ngood 0 >>>> ath0: ath_edma_recv_proc_queue: handled npkts 0 ngood 0 >>>> ath0: ath_edma_recv_proc_queue: handled npkts 0 ngood 0 >>>> ath0: ath_edma_recv_proc_queue: handled npkts 0 ngood 0 >>>> ath0: ath_edma_recv_proc_queue: handled npkts 0 ngood 0 >>>> ath0: ath_edma_recv_proc_queue: handled npkts 0 ngood 0 >>>> ath0: ath_edma_recv_proc_queue: handled npkts 0 ngood 0 >>>> ath0: ath_edma_recv_proc_queue: handled npkts 0 ngood 0 >>>> ath0: ath_edma_recv_proc_queue: handled npkts 0 ngood 0 >>>> ath0: ath_edma_recv_proc_queue: handled npkts 0 ngood 0 >>>> ath0: ath_edma_recv_proc_queue: handled npkts 0 ngood 0 >>>> ath0: ath_edma_recv_proc_queue: handled npkts 0 ngood 0 >>>> ath0: ath_edma_recv_proc_queue: handled npkts 0 ngood 0 >>>> ath0: ath_edma_recv_proc_queue: handled npkts 0 ngood 0 >>>> ath0: ath_edma_recv_proc_queue: handled npkts 0 ngood 0 >>>> ath0: ath_edma_recv_proc_queue: handled npkts 0 ngood 0 >>>> ath0: ath_edma_recv_proc_queue: handled npkts 0 ngood 0 >>>> ath0: ath_edma_recv_proc_queue: handled npkts 0 ngood 0 >>>> ath0: ath_edma_recv_proc_queue: handled npkts 0 ngood 0 >>>> ath0: ath_edma_recv_proc_queue: handled npkts 0 ngood 0 >>>> ath0: ath_edma_recv_proc_queue: handled npkts 0 ngood 0 >>>> ath0: ath_edma_recv_proc_queue: handled npkts 0 ngood 0 >>>> ath0: ath_edma_recv_proc_queue: handled npkts 0 ngood 0 >>>> ath0: ath_edma_recv_proc_queue: handled npkts 0 ngood 0 >>>> ath0: ath_edma_recv_proc_queue: handled npkts 0 ngood 0 >>>> ath0: ath_edma_recv_proc_queue: handled npkts 0 ngood 0 >>>> ath0: ath_edma_recv_proc_queue: handled npkts 0 ngood 0 >>>> ath0: ath_edma_recv_proc_queue: handled npkts 0 ngood 0 >> >> >> This is well known. For some odd reason I get a RXEOL interrupt when I >> initialise the RX FIFO. I don't know why yet. It's harmless but I'd >> like to figure out why. >> >>>> ar9300_reset[4254]: ar9300_stop_dma_receive failed >> >> >> Likely another channel scan, maybe? Or maybe it finally associated? >> >>>> ath0: ath_edma_recv_proc_queue: handled npkts 0 ngood 0 >> >> >> Thanks for being patient so far! >> >> >> >> Adrian >> > From owner-freebsd-wireless@FreeBSD.ORG Sun Mar 17 22:28: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 6F7CC5A9 for ; Sun, 17 Mar 2013 22:28:01 +0000 (UTC) (envelope-from jrisom@gmail.com) Received: from mail-ie0-x22d.google.com (mail-ie0-x22d.google.com [IPv6:2607:f8b0:4001:c03::22d]) by mx1.freebsd.org (Postfix) with ESMTP id 0ED696F2 for ; Sun, 17 Mar 2013 22:28:01 +0000 (UTC) Received: by mail-ie0-f173.google.com with SMTP id 9so6320463iec.32 for ; Sun, 17 Mar 2013 15:28:00 -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=qjacxHJFC+UL2LE+5UIqVyE3+ilwQsnuftcOSSCg5E4=; b=Pjc2KY9WZ708TcKj7IDPvHUsfd3YJmjo5ZCzQO3DIfD/JbLOEDhb+0XFZ7Q49XhU3W ArVyVyvLutUhECuJ7Yct1F2HfKlFAT4nCazwSZSJiP099INCwpb81F5r4+w4CTirgNsR meBkCQ6GaakttMPk9uvPFfE3QViIqbhUbekgwpjJLZZYHMZEFtBv+mMAfgqPKfBDLumN A/rKvIdBpV+yde/gxKkhIZ3wUyOakri7XbzzxXYwqolIDKNZbJGcgLSTapCpPZnagbed KkveRCXh6H8EsmXZNfJAVKO8Hr8/9Bq5rvoXr/bjeuFiVFVXfH8nZ3ei/2w/k6CkZIee nGMQ== X-Received: by 10.42.126.133 with SMTP id e5mr8067224ics.17.1363559280803; Sun, 17 Mar 2013 15:28:00 -0700 (PDT) Received: from [192.168.1.14] (c-98-212-197-211.hsd1.il.comcast.net. [98.212.197.211]) by mx.google.com with ESMTPS id wx2sm8296506igb.4.2013.03.17.15.27.59 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 17 Mar 2013 15:27:59 -0700 (PDT) Message-ID: <5146436A.4000806@gmail.com> Date: Sun, 17 Mar 2013 17:27:54 -0500 From: Joshua Isom User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: Adrian Chadd Subject: Re: Fine, OK, here's my initial AR9380/AR9485 support References: <5142813d.83c2e00a.67a8.39d5@mx.google.com> <514284E5.9060303@gmail.com> <51428E10.1000801@gmail.com> <78975985-a190-4915-82b5-b1810d6115b2@email.android.com> <5143A1C3.7010304@gmail.com> <514633FF.6070108@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: Sun, 17 Mar 2013 22:28:01 -0000 There's no issues for the fork, only the master. On 3/17/2013 4:40 PM, Adrian Chadd wrote: > Just go to my github - github.com/erikarn/ - then click on > repositories, then the HAL fork, then just file an issue there. > > > > Adrian > > From owner-freebsd-wireless@FreeBSD.ORG Sun Mar 17 22:32:04 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 CACC35D3 for ; Sun, 17 Mar 2013 22:32:04 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) by mx1.freebsd.org (Postfix) with ESMTP id 63624701 for ; Sun, 17 Mar 2013 22:32:04 +0000 (UTC) Received: by mail-wi0-f175.google.com with SMTP id l13so2028567wie.8 for ; Sun, 17 Mar 2013 15:32:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=Nbwm/J7ro2w5yaqdQ3ZczONvpVn0mxNNd0MJGC+rFk4=; b=aO6nPXkiAU7uqiwLrpN2kVdr3ahMsoN56m/HusMq8TvOcuSsMVzclVDngJ54u6lj1n ZMFsHzgjH0XHUeJ0PQ4ms1ZgAgIPjqIjeVsqJhK5T6OnMPZCoiPN632uwVdKmWYSAaw7 Te106H/3zKAqVlyqfS8eOLL9HkrbY70M7me0IZzg/HGFLVraRSSZ0HG4qn/X5ToqUmgJ /VW4Qq7hMk5uxOgz3rkrCwHrOXsnumHN5dFFiuwrG+qs0zovTPoqkSgXsIY2sQFnyBkI F8DyPixb1H+IvWaaRyqcoWqDrVVqY91doFHiHMzBYVOoJn39BXKSEh1TayfYOk3RD+/9 wHVw== MIME-Version: 1.0 X-Received: by 10.180.97.233 with SMTP id ed9mr12890940wib.32.1363559523606; Sun, 17 Mar 2013 15:32:03 -0700 (PDT) Received: by 10.216.111.201 with HTTP; Sun, 17 Mar 2013 15:32:03 -0700 (PDT) In-Reply-To: <5146436A.4000806@gmail.com> References: <5142813d.83c2e00a.67a8.39d5@mx.google.com> <514284E5.9060303@gmail.com> <51428E10.1000801@gmail.com> <78975985-a190-4915-82b5-b1810d6115b2@email.android.com> <5143A1C3.7010304@gmail.com> <514633FF.6070108@gmail.com> <5146436A.4000806@gmail.com> Date: Sun, 17 Mar 2013 15:32:03 -0700 Message-ID: Subject: Re: Fine, OK, here's my initial AR9380/AR9485 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: Sun, 17 Mar 2013 22:32:04 -0000 Fixed! Adrian On 17 March 2013 15:27, Joshua Isom wrote: > There's no issues for the fork, only the master. > > > On 3/17/2013 4:40 PM, Adrian Chadd wrote: >> >> Just go to my github - github.com/erikarn/ - then click on >> repositories, then the HAL fork, then just file an issue there. >> >> >> >> Adrian >> >> > From owner-freebsd-wireless@FreeBSD.ORG Sun Mar 17 23:12:00 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 E03DEFEC for ; Sun, 17 Mar 2013 23:12:00 +0000 (UTC) (envelope-from jrisom@gmail.com) Received: from mail-ie0-x229.google.com (mail-ie0-x229.google.com [IPv6:2607:f8b0:4001:c03::229]) by mx1.freebsd.org (Postfix) with ESMTP id AC539839 for ; Sun, 17 Mar 2013 23:12:00 +0000 (UTC) Received: by mail-ie0-f169.google.com with SMTP id 13so6427115iea.28 for ; Sun, 17 Mar 2013 16:12:00 -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=n0n/kIb+O6ipKJVl9+p9RMOsjftL4XCiBuHMTBdD3Rs=; b=iqOSr/F+KylWyyXzdp+Fen/Ow+BuRmsfZWJB9KoWWOWvohjTomGqIgfvgWHGxir07C XFBtAEUCQULMJZncUtKgYA42WrycvrinVGUHth2PMKHwi0jOQMtIMmebhx5kY3hUzlg0 MBu6oKDq/D4SBvXA+Lwiqo/Cz7LmlT2lzjMI9ht3AlP1CzfQ97M6laavfRi0UZuaZsoY +tyqSeUCUOQorLgLtPThy/4gPHtb/4VNM6FKDacd3rTcLUAio19Aiiuqo9GekDOgWfZv fTDvzKuegybglZtUZc1v0sQ3ob2fr5G/phsE5dwBNeP9fV7u1VwMKfdVpTKLbbombdGx SxVg== X-Received: by 10.50.13.71 with SMTP id f7mr4875491igc.32.1363561919802; Sun, 17 Mar 2013 16:11:59 -0700 (PDT) Received: from [192.168.1.14] (c-98-212-197-211.hsd1.il.comcast.net. [98.212.197.211]) by mx.google.com with ESMTPS id ih1sm7320060igc.3.2013.03.17.16.11.58 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 17 Mar 2013 16:11:59 -0700 (PDT) Message-ID: <51464DB9.3020908@gmail.com> Date: Sun, 17 Mar 2013 18:11:53 -0500 From: Joshua Isom User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: freebsd-wireless@freebsd.org Subject: Re: Fine, OK, here's my initial AR9380/AR9485 support References: <5142813d.83c2e00a.67a8.39d5@mx.google.com> <514284E5.9060303@gmail.com> <51428E10.1000801@gmail.com> <78975985-a190-4915-82b5-b1810d6115b2@email.android.com> <5143A1C3.7010304@gmail.com> 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: Sun, 17 Mar 2013 23:12:00 -0000 On 3/17/2013 9:43 AM, Li-Wen Hsu wrote: > > Oops, accidentally clicked on "send." Before the changes you made yesterday, > I can only see it got found by kernel, but was unable to get IP > through DHCP, and > the status of wlan0 was flipping between associated and no carrier, while ath0 > is always associated. Don't know if this has something to do with > that I'm using WPA2. > Thanks making this work, even I haven't posted my report. :) > > I am using clang from head, and this patch is needed: > Are you checking your signal strength. I had a lot of problems when I moved the computer across the house. When I could connect, I'd get at least 20% of packets dropped and anything that needed udp was useless. I'm going to build a directional antenna, but just added an extension to one antenna and repositioning it gave me about 5dB improvement, which would be around three times the signal strength. From owner-freebsd-wireless@FreeBSD.ORG Mon Mar 18 11:06:54 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 3804FCE7 for ; Mon, 18 Mar 2013 11:06:52 +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 EAE6DAC9 for ; Mon, 18 Mar 2013 11:06:51 +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 r2IB6pUJ002346 for ; Mon, 18 Mar 2013 11:06:51 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.6/8.14.6/Submit) id r2IB6p1q002344 for freebsd-wireless@FreeBSD.org; Mon, 18 Mar 2013 11:06:51 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 18 Mar 2013 11:06:51 GMT Message-Id: <201303181106.r2IB6p1q002344@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, 18 Mar 2013 11:06:54 -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 Tue Mar 19 13:50:03 2013 Return-Path: Delivered-To: freebsd-wireless@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 9A62FA3A for ; Tue, 19 Mar 2013 13:50: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 74038777 for ; Tue, 19 Mar 2013 13:50: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 r2JDo3IS023438 for ; Tue, 19 Mar 2013 13:50:03 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.6/8.14.6/Submit) id r2JDo3Hg023437; Tue, 19 Mar 2013 13:50:03 GMT (envelope-from gnats) Date: Tue, 19 Mar 2013 13:50:03 GMT Message-Id: <201303191350.r2JDo3Hg023437@freefall.freebsd.org> To: freebsd-wireless@FreeBSD.org Cc: From: hiren panchasara Subject: Re: kern/175870: [iwn] /etc/rc.d/netif restart cause system crash X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: hiren panchasara 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, 19 Mar 2013 13:50:03 -0000 The following reply was made to PR kern/175870; it has been noted by GNATS. From: hiren panchasara To: bug-followup@FreeBSD.org, giepher@gmail.com Cc: Subject: Re: kern/175870: [iwn] /etc/rc.d/netif restart cause system crash Date: Tue, 19 Mar 2013 06:47:43 -0700 Did you get a coredump on crash? Can you share that if you did? I could not reproduce it on CURRENT on my T420 with Centrino Advanced-N 6205. cheers, Hiren From owner-freebsd-wireless@FreeBSD.ORG Tue Mar 19 19:39: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 301E7BC8 for ; Tue, 19 Mar 2013 19:39:52 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-we0-x232.google.com (mail-we0-x232.google.com [IPv6:2a00:1450:400c:c03::232]) by mx1.freebsd.org (Postfix) with ESMTP id C6319FE0 for ; Tue, 19 Mar 2013 19:39:51 +0000 (UTC) Received: by mail-we0-f178.google.com with SMTP id o45so765653wer.9 for ; Tue, 19 Mar 2013 12:39:49 -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=pkiPMYA3WTqPmAlo1RIkBfABc5SA3fH+01LUu2x/qg4=; b=nEZHj+8py+6uYkz1dVh0Ypvd7pXPNsXWWUdVKO3Yqx1F1PbFg30nGxMaV87YS/6gTW b9K5MEExgreppC52DVGKVPHEEZeNbpWT3+1K65iXQIqJfrl8NBddT3+FKJTIVNVOeqZk IiT/3ZSga0MgPiq/10ljaai6n0tVyBtJ2HssVPUQl9L5rLECCO/LLuXAD1nUr0owAPbc SFtfInCS7BdJ21kamdojA8nrfrVZwIluoFwbvWVbf5bN8wbaEmZU/LIwT1hnIEAHp0mX Lr6COZ3oICXAI4p5GioGc7GK4V8aC0yhI0ZXhrgJvigzWIsML5cEQQs6OW2mcHyaqM8+ jtZA== MIME-Version: 1.0 X-Received: by 10.180.14.233 with SMTP id s9mr5688332wic.25.1363721989821; Tue, 19 Mar 2013 12:39:49 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.216.108.130 with HTTP; Tue, 19 Mar 2013 12:39:49 -0700 (PDT) Date: Tue, 19 Mar 2013 12:39:49 -0700 X-Google-Sender-Auth: KZk63ztH6MHXjRjsgK0k_kl7zMw Message-ID: Subject: update - better EDMA RX support, testing AR9580 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, 19 Mar 2013 19:39:52 -0000 Hi all, I've just committed some new RX handling code. Since the RX FIFO on the AR9380 and later chips is very shallow (128 entries), you have to refill the FIFO much quicker than you can handle frames. So instead of doing it in the RX task (which is shared with the TX completion task and runs at a lower priority than interrupt handling) - I'm now completing buffers and refilling the FIFO in the interrupt thread. I'm then doing the RX frame handling in the deferred path. This way the RX path (and most other things!) will be preempted by the interrupt thread if there's more RX frames to handle, and those will just be pushed into the RX queue. I've tested this with TCP iperf on a 2x2 setup and I now don't get any FIFO full errors. So I'd appreciate it if people would update to today's -HEAD and try it out. Thanks! Adrian From owner-freebsd-wireless@FreeBSD.ORG Wed Mar 20 03:31:46 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 AD60ADD4 for ; Wed, 20 Mar 2013 03:31:46 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-we0-x22d.google.com (mail-we0-x22d.google.com [IPv6:2a00:1450:400c:c03::22d]) by mx1.freebsd.org (Postfix) with ESMTP id 3BCD1952 for ; Wed, 20 Mar 2013 03:31:46 +0000 (UTC) Received: by mail-we0-f173.google.com with SMTP id x51so967659wey.32 for ; Tue, 19 Mar 2013 20:31: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:content-type; bh=8qyws/k85XNAhlA/fDrzZMl+AJ43H/rEnkfEu4xciqo=; b=mRLBN9i75qZoxK7Qa8q0CrbsAA32KG0ZDzuAWhvnMrVBK/mSTcjjdvkO64Lu64j5od rspaeIxaDFKqiuTHkEEH/iwOHC6tda+k9Q+iW6zIBng62nTQHn+7mGLGnMEl2oD9aQ/J 45OXvyipqRaFvqqWEnidWa8gJFJl90RKoP0oj7PbOMJkxLPZW2O6Sj7bYFRXV8nVAIuA 6gXpyDITKPFf+CdqaeuGx8/GLZ+iLdbQmA3cj9fnj12f4ns3uquS93Q9tSYlB7UDh4HT kxq9cr7SYBoWRTouxu3QlfwEYUrIvzADyyz1yhLHMbZ0ojyYtm9lUi1+CTasjabw3UIR coCg== MIME-Version: 1.0 X-Received: by 10.180.74.131 with SMTP id t3mr7272318wiv.26.1363750305467; Tue, 19 Mar 2013 20:31:45 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.216.108.130 with HTTP; Tue, 19 Mar 2013 20:31:45 -0700 (PDT) In-Reply-To: References: Date: Tue, 19 Mar 2013 20:31:45 -0700 X-Google-Sender-Auth: sU-smm627mf9FuCq04gOlJw1m7I Message-ID: Subject: Re: update - better EDMA RX support, testing AR9580 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: Wed, 20 Mar 2013 03:31:46 -0000 On 19 March 2013 12:39, Adrian Chadd wrote: > Hi all, > > I've just committed some new RX handling code. Since the RX FIFO on > the AR9380 and later chips is very shallow (128 entries), you have to > refill the FIFO much quicker than you can handle frames. .. and an AR9390 STA -> AR9380 AP at MCS24 is giving me around 230mbit TCP. My goal is to hit 200mbit TCP on 2x2 and 300mbit TCP on 3x3. But, I won't complain about getting to 230mbit this early in the game. Adrian From owner-freebsd-wireless@FreeBSD.ORG Thu Mar 21 02:43: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 A77D02D6 for ; Thu, 21 Mar 2013 02:43:22 +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 7BB3E1DA for ; Thu, 21 Mar 2013 02:43:22 +0000 (UTC) Received: by mail-ie0-f172.google.com with SMTP id c10so2951277ieb.17 for ; Wed, 20 Mar 2013 19:43:22 -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=b5b6rm4l8I12KeF/veA1XiCC+mJxLckCK/HQj7gP6ew=; b=rHI+1Y1TklhWW/2l8D34dChcILc+5MIynWAm9E6ssKKlliP2iV0SQuPJYZLbOIWFsv sE9IyEDDxR4hlLARiC70kfG6EgAezHjZpyaQdxV/d4sP+jAaio9zonmnVGJT42ax+4C0 hbmqWJoPlImiielOK9CerPR0tN1r6YIFUGVcnSoEjlNFwfJcbiUEZeeRophdSZEA34e6 y/gC1oQbXefxZWbf0hesQdIgNGfTSByde2n831pTFfS1uvBkXpa0cKP5PKrRdZ9hSbrv lMlxfaDzLBkv3je5RiXAWzyp6dDXEl6uL1Gd/SN8lsK0EXm6G928AawU6/DcZukVz9UF jrVA== X-Received: by 10.42.54.5 with SMTP id p5mr15123926icg.49.1363833802173; Wed, 20 Mar 2013 19:43:22 -0700 (PDT) Received: from [192.168.1.14] (c-98-212-197-211.hsd1.il.comcast.net. [98.212.197.211]) by mx.google.com with ESMTPS id wn10sm2022655igb.2.2013.03.20.19.43.20 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 20 Mar 2013 19:43:21 -0700 (PDT) Message-ID: <514A73C8.7050102@gmail.com> Date: Wed, 20 Mar 2013 21:43:20 -0500 From: Joshua Isom User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: freebsd-wireless@freebsd.org Subject: Re: update - better EDMA RX support, testing AR9580 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: Thu, 21 Mar 2013 02:43:22 -0000 On 3/19/2013 10:31 PM, Adrian Chadd wrote: > On 19 March 2013 12:39, Adrian Chadd wrote: >> Hi all, >> >> I've just committed some new RX handling code. Since the RX FIFO on >> the AR9380 and later chips is very shallow (128 entries), you have to >> refill the FIFO much quicker than you can handle frames. > > .. and an AR9390 STA -> AR9380 AP at MCS24 is giving me around 230mbit TCP. > > My goal is to hit 200mbit TCP on 2x2 and 300mbit TCP on 3x3. > > But, I won't complain about getting to 230mbit this early in the game. > > > > Adrian Any tips for backporting the code to -STABLE? Currently I had to comment out the scsi cd driver because it was causing kernel panics. Now I'm getting kernel panics from geom_io.c due to a failed assert. From owner-freebsd-wireless@FreeBSD.ORG Thu Mar 21 03:19:27 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 9700FB0A for ; Thu, 21 Mar 2013 03:19:27 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) by mx1.freebsd.org (Postfix) with ESMTP id 3598F5F5 for ; Thu, 21 Mar 2013 03:19:27 +0000 (UTC) Received: by mail-wi0-f180.google.com with SMTP id hi8so2573063wib.7 for ; Wed, 20 Mar 2013 20:19: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=NScPs/M1xvg6xMh+fi/TYayEs0hCNAiZgmhU3BUdHqU=; b=diTiRhcoSv88RR0sqPFyXsxYQ/Zbkht3qy3rYsKD5CqS1Wq5khyOcE8X2b0MR9M4vr JY5Q/OTKfGMnEKG1Xa9u3TMPCc97Uvr/aIcYaPmQ7gLSDRsPfnBJFkC4s42CggeBeUCU qsst1wLYZJUaoFa4RNHHrxD/1NfGI6KXp+fSTKpXgy6viVqMPT/k8TAFuFoiKO96lNGu TEw1mQuLfuTYFpAIl5/9Ji8n6IOmcuDAc/OztRDfiEbw8tiJ0c3KXdJLtWg51G0+ekJs DQ9sfSkAcBz1t6kHdU1Nc4tcBplUHmrfQOBPk6xWotNwQ77+88UZLEBkiB5p2oRuMjcg mb+w== MIME-Version: 1.0 X-Received: by 10.180.79.6 with SMTP id f6mr2068845wix.26.1363835966430; Wed, 20 Mar 2013 20:19:26 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.216.108.130 with HTTP; Wed, 20 Mar 2013 20:19:26 -0700 (PDT) In-Reply-To: <514A73C8.7050102@gmail.com> References: <514A73C8.7050102@gmail.com> Date: Wed, 20 Mar 2013 20:19:26 -0700 X-Google-Sender-Auth: jaMEFwVJwelbFixFqwbi7-Gv8vM Message-ID: Subject: Re: update - better EDMA RX support, testing AR9580 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, 21 Mar 2013 03:19:27 -0000 Hi, I have no plans to backport this to stable, sorry. :( Adrian On 20 March 2013 19:43, Joshua Isom wrote: > On 3/19/2013 10:31 PM, Adrian Chadd wrote: >> >> On 19 March 2013 12:39, Adrian Chadd wrote: >>> >>> Hi all, >>> >>> I've just committed some new RX handling code. Since the RX FIFO on >>> the AR9380 and later chips is very shallow (128 entries), you have to >>> refill the FIFO much quicker than you can handle frames. >> >> >> .. and an AR9390 STA -> AR9380 AP at MCS24 is giving me around 230mbit >> TCP. >> >> My goal is to hit 200mbit TCP on 2x2 and 300mbit TCP on 3x3. >> >> But, I won't complain about getting to 230mbit this early in the game. >> >> >> >> Adrian > > > Any tips for backporting the code to -STABLE? Currently I had to comment > out the scsi cd driver because it was causing kernel panics. Now I'm getting > kernel panics from geom_io.c due to a failed assert. > _______________________________________________ > 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 Thu Mar 21 03:53:18 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 31CE1EC2 for ; Thu, 21 Mar 2013 03:53:18 +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 CB9396CC for ; Thu, 21 Mar 2013 03:53:17 +0000 (UTC) Received: by mail-wi0-f170.google.com with SMTP id hm11so6662315wib.1 for ; Wed, 20 Mar 2013 20:53:17 -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=WiDPDvxFAbU4UsCckSJ8W2IpCxNWgxfN7Mtu722YaNU=; b=tYIuGOM9bQiDKqaxmOtWcieC4HnZJFNE4xCeNWM3PhfCGiGRYp/07LCzb2aN8XPVcH +QPY7gE4BLSh8pUBbxBCjHFWPUKOEUoAytx9WQsdEDCxdjwD4z8KfC+y1FFNssMMRHaY FkF83YcTSMMK6pGpVqE41q0lvecC3uwh8IwbitwIFywc//T9fC4fSZ2vz5oKe+ake0uz etZQDYcc+hUN9nKkbJiBXcP53Tu3alv799QQcJ9TOSNZzR6tI9O9w+x7buGPB6TQQ0+/ 27/DBu2lwxr4VWzyK23kblmvjGR+afsS7IYqhlu0ma2gon26lmGZLcmlMQcsf3C7lchK jjhQ== MIME-Version: 1.0 X-Received: by 10.180.74.131 with SMTP id t3mr1956408wiv.26.1363837997044; Wed, 20 Mar 2013 20:53:17 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.216.108.130 with HTTP; Wed, 20 Mar 2013 20:53:16 -0700 (PDT) Date: Wed, 20 Mar 2013 20:53:16 -0700 X-Google-Sender-Auth: RO7okTaZdkv0OKZkw_g6jJDP4_0 Message-ID: Subject: FYI: why hostap mode isn't ready yet for AR9380 and later chips 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: Thu, 21 Mar 2013 03:53:18 -0000 Hi, I've had a few people ask why AR9380 hostap mode isn't working yet and when I expect to have that working. Firstly - it's because I have a day job, and that day job isn't FreeBSD. Honest. But all jokes aside, the last main thing to deal with at the moment is tidying up the TX path - specifically how the CABQ traffic is assembled. Right now any traffic that gets shoved in the CABQ confuses my TX FIFO hack to bring up unicast / station mode traffic, and this will eventually hang the driver. I'm designing some replacement TX code which will "fix" all of this but it's going to take time. So, as usual, it'll happen but it'll take time. It's not all bad news - I know that basic hostap services work, right up to 3x3 MCS23. So the basics are there and working fine. It's just the CABQ handling that is finally forcing me to do a redesign of that part of the codebase. I'll let everyone know when I have pushed some code into -HEAD for further testing. Thanks, Adrian From owner-freebsd-wireless@FreeBSD.ORG Thu Mar 21 15:19:38 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 BDB4E744 for ; Thu, 21 Mar 2013 15:19:38 +0000 (UTC) (envelope-from ganthore@gmail.com) Received: from mail-la0-x231.google.com (mail-la0-x231.google.com [IPv6:2a00:1450:4010:c03::231]) by mx1.freebsd.org (Postfix) with ESMTP id 4F5B314D for ; Thu, 21 Mar 2013 15:19:38 +0000 (UTC) Received: by mail-la0-f49.google.com with SMTP id fs13so5305791lab.22 for ; Thu, 21 Mar 2013 08:19:37 -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=J6zFPd3fRmd3hgbF6U0ddtYu+2zg2xqodCS426lGbnw=; b=CO9EVWzmjyxSn7zFHRpmko3bEba4wMQ3s37VDF5S34/bbqiXE6OWOUwvivYI2BtNru 4atjP5fYEf2VDmbmyb4EqKbPtVwcfTfhDuaMrAhLWD93IZw6u34/dUTuI0K4Z/NObPgU 8WNH0KFi1kOU3FtPltONWVgvxfw5rVFvnxhTT//a4M6e2mvot2+SMZFD2u3f6HGTQRdN 644qam8epAI0Oj6l4lqQj2W5STlK7AeiYOJsRNrrqmEOSCBg6WfksLEnJg9dabuOs65L I9mLa/91610nIoWw4Naa+q55MO9GzF1VZCzzFHg64vBqs8GeJ10FVDRAU5IH4nb7tbIS EKHg== MIME-Version: 1.0 X-Received: by 10.152.110.74 with SMTP id hy10mr7745035lab.37.1363879177150; Thu, 21 Mar 2013 08:19:37 -0700 (PDT) Received: by 10.114.29.37 with HTTP; Thu, 21 Mar 2013 08:19:37 -0700 (PDT) Date: Thu, 21 Mar 2013 11:19:37 -0400 Message-ID: Subject: AR9300 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, 21 Mar 2013 15:19:38 -0000 I'm going to help test the AR9300 code. I just checked out a complete copy of the HEAD sources along with the latest copy of the AR9300 from the erikarn git repo. I moved the source code into the correct file/folder location that is listed in the comments of the ath Makefile. I'm under the assumption that I just need to un-comment out the AR9300 blocks and rebuild the sources? Will this require rebuilding just the kernel or will I also need to rebuild the world tools? 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 21 15:46:37 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 8DD9975B for ; Thu, 21 Mar 2013 15:46:37 +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 31C3032C for ; Thu, 21 Mar 2013 15:46:37 +0000 (UTC) Received: by mail-wi0-f177.google.com with SMTP id hm14so3260794wib.4 for ; Thu, 21 Mar 2013 08:46:36 -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=FG2FeicWuruLXvhrEO4yqyhf3EaFAFuzjMQf1FcA9rg=; b=stLgRsP+/sJ653N3sCw2Qeh/i8JPAULkXeOWZSkLG2TkTm/kWuEni5ObbWnK+/n8a0 xmdqSAzklbOM0sizQbjco58CGVS4wxFTNDpTNNeCi8sb5/dKG+SSTh86EGgd8dDnxz96 U8k/PW2tVa8tIeXY/RkH8emLJ43Zg94oql/dhREXPLYFcui1A7n2WJ8yULnP/mr6X+TE wWBKqvaPfIvZj7vORJpigsN2kdcstJpu4Tgx4hmkpiMgoiyRWcDah29zyN2hA3jNBse7 FLLrf10wb64XoubVTiAHyO5hS8qB7A89ucYLYK4nvoyrsxiTvBTxq0g/BIn02g2VLjK6 cGig== MIME-Version: 1.0 X-Received: by 10.180.13.34 with SMTP id e2mr5797105wic.29.1363880796328; Thu, 21 Mar 2013 08:46:36 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.216.108.130 with HTTP; Thu, 21 Mar 2013 08:46:35 -0700 (PDT) In-Reply-To: References: Date: Thu, 21 Mar 2013 08:46:35 -0700 X-Google-Sender-Auth: iAmxX7wj3UDJIPX6w-7Yb3RiQWM Message-ID: Subject: Re: AR9300 From: Adrian Chadd To: Mark Austin 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, 21 Mar 2013 15:46:37 -0000 Hi! You'll need to comment out the ath, ath_hal, and ath_rate_sample devices in your kernel. You'll need to add: ATH_DEBUG AH_DEBUG ATH_ENABLE_11N ATH_DIAGAPI .. AH_DEBUG / ATH_ENABLE_11N Are required for it to work; the others are for debugging. The build only works as a module. You'll need to rebuild your kernel with the above options and the above devices commented out so you can load ath and ath_pci as modules. Then yes, kldload if_ath_pci should do the trick. Adrian On 21 March 2013 08:19, Mark Austin wrote: > I'm going to help test the AR9300 code. I just checked out a complete copy > of the HEAD sources along with the latest copy of the AR9300 from the > erikarn git repo. I moved the source code into the correct file/folder > location that is listed in the comments of the ath Makefile. I'm under the > assumption that I just need to un-comment out the AR9300 blocks and rebuild > the sources? Will this require rebuilding just the kernel or will I also > need to rebuild the world tools? > > Regards, > -Mark Austin > > All else is in doubt, so this is the truth that I cling to. > > My Website: http://www.silverdire.com > _______________________________________________ > freebsd-wireless@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-wireless > To unsubscribe, send any mail to "freebsd-wireless-unsubscribe@freebsd.org" From owner-freebsd-wireless@FreeBSD.ORG Fri Mar 22 13:38: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 855037DF for ; Fri, 22 Mar 2013 13:38:47 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-we0-x229.google.com (mail-we0-x229.google.com [IPv6:2a00:1450:400c:c03::229]) by mx1.freebsd.org (Postfix) with ESMTP id 278A9AFF for ; Fri, 22 Mar 2013 13:38:47 +0000 (UTC) Received: by mail-we0-f169.google.com with SMTP id x56so2453992wey.0 for ; Fri, 22 Mar 2013 06:38:46 -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=IXKU5VoUX9bD3UxYTKgEewMT5MQtVlFVpw5Bidb+ZGA=; b=Te/EFjZJqoNj/WNTtZfq6app1nTrpLimW+uRk9sZ/8n6Z7xFkcTyYM1EmbVGJ5gS9B CRbGIE2XvbgCQSIlfwIUCW4PtEikEQPTcs5DaOdm7cvzFBlAV7MukO9cGcELGRuN5IrB jX+ZdkJX5BIjy+996njDrqOS4/4Y17RgXohRq5ztJEaNSXfPNhSnjGBmw+odYaMkFPH3 1Sh4bZ8vF58FnoSgrPzx9zcGCsHdkzb6AWaeLTPiQHESqeAd+oCVo/LSxoD4ewHnqR3I qUP+UqITDXap+Sa+7TF+nONFr8hfdc3c+UeXkRLLRi+U+oHQh0kL5o+jPGGCjCNXEF7+ 8axQ== MIME-Version: 1.0 X-Received: by 10.194.120.169 with SMTP id ld9mr3180067wjb.24.1363959526274; Fri, 22 Mar 2013 06:38:46 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.216.108.130 with HTTP; Fri, 22 Mar 2013 06:38:46 -0700 (PDT) Date: Fri, 22 Mar 2013 06:38:46 -0700 X-Google-Sender-Auth: ig4lM6VQNvpSyf3BTUDt99jCjNI Message-ID: Subject: [RFT] TXQ locking patch; CABQ refactor 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: Fri, 22 Mar 2013 13:38:47 -0000 Hi, This patch implements two things: * it refactors out the cabq hardware TXQ code from the cabq list setup code; * it restores the per-TXQ lock (for hardware TXQs and the VAP multicast TXQs) and wraps list operations around those. The main reason for the second part of the patch is to try and reduce latency/contention on grabbing locks when setting up the CABQ for transmit. I saw the TX lock getting acquired and contended on when also sending out CABQ frames and I didn't want to have this lead to missed / stuck beacons. I've not yet tested adhoc, EDMA NICs or legacy+TDMA. I'd appreciate whatever testing people can give it. Please let me know if you end up with more stuck beacons. Adrian From owner-freebsd-wireless@FreeBSD.ORG Fri Mar 22 15:55:03 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 C1197F54 for ; Fri, 22 Mar 2013 15:55:03 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-da0-x22c.google.com (mail-da0-x22c.google.com [IPv6:2607:f8b0:400e:c00::22c]) by mx1.freebsd.org (Postfix) with ESMTP id 966208C4 for ; Fri, 22 Mar 2013 15:55:03 +0000 (UTC) Received: by mail-da0-f44.google.com with SMTP id z20so2341289dae.31 for ; Fri, 22 Mar 2013 08:55:03 -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=3Y/dR+w+joPCJp7/KEmaP6ibg6j403tBZaRlphXlBPU=; b=S4+7GbJNr+427+sJwaYbFYyl1V4vKedbiYo7LN6VKVVpQ43W8xT2EFJbU6L6tDSquB Zsr0FPwUHE8CA0nf4wGHBGvTrhW/6MLhUrxa8WPYIzRozT1Mx8ZHTJy3DqjxEAPv6rNv uBj4a0zHwvv/hQPhUXagD1050y6Rte01n4Y86DypWhtxuWP59uGwMqjFAnKtHtjoXAtZ CWvIXv5Plz+2dK7SL1uVs1xBTJNSd5Ywx4QChzL8qmmYrlsiXqr/VvYX5MQhXR9lXbBJ YVWcwToDJKGFAqpkjJZwYfJB4yZzPxNtP7SODBMmlalcTaloD2Zi81U53C7TvVRAGP4p dgkw== MIME-Version: 1.0 X-Received: by 10.68.211.37 with SMTP id mz5mr3496849pbc.83.1363967703259; Fri, 22 Mar 2013 08:55:03 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.70.39.69 with HTTP; Fri, 22 Mar 2013 08:55:03 -0700 (PDT) In-Reply-To: References: Date: Fri, 22 Mar 2013 08:55:03 -0700 X-Google-Sender-Auth: aEPuvB9kuXiGx6J3EztKqKmMNxM 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: Fri, 22 Mar 2013 15:55:03 -0000 Hi, I'm cc'ing -wireless now, as this is actually good to have public. Ok, can you post (or re-post) the ath device line from 'pciconf -lv' ? I'd like to see which device it is. And, inline: On 22 March 2013 08:44, Mark Austin wrote: > Hey Adrian, > > Okay. I was able to successfully build the kernel. I installed and loaded > the kernel today and was able to kldload the if_ath_pci module. > > ath0 is not exposed to ifconfig as a device. > > The module gives the following kernel messages: > > Mar 22 15:37:12 asher kernel: ath0: mem > 0xc2400000-0xc247ffff irq 17 at device 0.0 on pci3 > Ok, so it probed fine. > Mar 22 15:37:12 asher kernel: ar9300_set_stub_functions: setting stub > functions > Mar 22 15:37:12 asher kernel: ar9300_set_stub_functions: setting stub > functions > Mar 22 15:37:12 asher kernel: ar9300_attach: calling ar9300_hw_attach > Mar 22 15:37:12 asher kernel: ar9300_hw_attach: calling > ar9300_eeprom_attach > Mar 22 15:37:12 asher kernel: ar9300_flash_map: unimplemented for now > Mar 22 15:37:12 asher kernel: Restoring Cal data from DRAM > Mar 22 15:37:12 asher kernel: Restoring Cal data from EEPROM > Mar 22 15:37:12 asher kernel: Restoring Cal data from Flash > Mar 22 15:37:12 asher kernel: Restoring Cal data from Flash > Mar 22 15:37:12 asher kernel: Restoring Cal data from OTP > Mar 22 15:37:12 asher kernel: ar9300_hw_attach: ar9300_eeprom_attach > returned 0 > Mar 22 15:37:12 asher kernel: ar9300_fill_capability_info: (MCI) MCI > support = 1 > Ok, so MCI is available but we don't enable it by default. Well, I hope we don't enable it in the HAL by default as I haven't implemented MCI yet. > Mar 22 15:37:12 asher kernel: ath0: RX status length: 48 > Mar 22 15:37:12 asher kernel: ath0: RX buffer size: 4096 > Mar 22 15:37:12 asher kernel: ath0: TX descriptor length: 128 > Mar 22 15:37:12 asher kernel: ath0: TX status length: 36 > Mar 22 15:37:12 asher kernel: ath0: TX buffers per descriptor: 4 > Mar 22 15:37:12 asher kernel: ar9300_freebsd_setup_x_tx_desc: called, > 0x0/0, 0x0/0, 0x0/0 > Mar 22 15:37:12 asher kernel: ath0: ath_getchannels: unable to collect > channel list from hal, status 12 > Mar 22 15:37:12 asher kernel: device_attach: ath0 attach returned 22 > Ok, HAL status 12 here is HAL_EINVAL. That's a call to ath_hal_init_channels() that's failing. So I wonder if it's a regulatory domain database problem. I wonder what the EEPROM code is. It may be something really stupid like the default regulatory domain not being in the HAL database. Can you edit sys/dev/ath/ath_hal/ah_regdomain.c, and find ath_hal_init_channels(). Then before the call to getchannels, add this: ath_hal_printf(ah, "%s: cc=%d, regdmn=%d\n", __func__, (int) cc, (int) regDmn); Then just recompile/reinstall the modules, and reload if_ath.ko and then if_ath_pci.ko. I'd like to see _what_ the initial detected regulatory domain is. I bet it's erroring out there. Thanks, Adrian From owner-freebsd-wireless@FreeBSD.ORG Fri Mar 22 17:23:13 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 7D455FE6 for ; Fri, 22 Mar 2013 17:23:13 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-da0-x22c.google.com (mail-da0-x22c.google.com [IPv6:2607:f8b0:400e:c00::22c]) by mx1.freebsd.org (Postfix) with ESMTP id 5132BFAC for ; Fri, 22 Mar 2013 17:23:13 +0000 (UTC) Received: by mail-da0-f44.google.com with SMTP id z20so2381702dae.31 for ; Fri, 22 Mar 2013 10:23: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=SoVGcEUBdXaQousZ1SP6TO4d2c18pqTLByR15u1OSVU=; b=jAYF9YGvRhId5fVaxf9QkG0a+dUHq6L4YLbqfcZZKVg4GAgeRjee9Gth/d+IdSYyUl u/POa5yC8+GQ6tzati8QynXJD9+im1XMg3GP9X3vZV3qJq6JZCC7dGxZhkyKh+6OOVsh W6k+1TG6GHvPEfl21OjSTt1xnngVNrTeZLgID3+eDESjaDjfJY8riMU+G0Z2Rw6i2qoZ RmNUVLXyQwjSjB1wr6VKzZS2EYNeSlsmwd4d6Cmi3xTa9SRgY2wy+OLGxF9luf2lwpJ0 9YpV+WW1zQX9LImAhC0lmGWQlCsXM02Pln60xH7obfB9KUblhBg56mzTQiSwA/P3VYWb cSgg== MIME-Version: 1.0 X-Received: by 10.66.176.205 with SMTP id ck13mr4606868pac.50.1363972993172; Fri, 22 Mar 2013 10:23:13 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.70.39.69 with HTTP; Fri, 22 Mar 2013 10:23:12 -0700 (PDT) In-Reply-To: References: Date: Fri, 22 Mar 2013 10:23:12 -0700 X-Google-Sender-Auth: I5c10Fp7Uf5Z3lqrOCjY2oOr0AM 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: Fri, 22 Mar 2013 17:23:13 -0000 On 22 March 2013 10:18, Mark Austin wrote: > pciconf -la gives the following information regarding the Atheros device: > > none2@pci0:3:0:0: class=0x028000 card=0xe052105b chip=0x0034168c > rev=0x01 hdr=0x00 > vendor = 'Atheros Communications Inc.' > class = network > > I'll add the ath_hal_printf function into the ah_regdomain.c code and get > back to you when I can today. > > THanks. Right, it's an AR946x NIC. I've tested this; it should work fine. I bet it's a NIC regulatory domain problem that'll require me to update the HAL regdomain code.. :/ Adrian From owner-freebsd-wireless@FreeBSD.ORG Fri Mar 22 19:12:45 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 4E4BC26C for ; Fri, 22 Mar 2013 19:12:45 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-da0-x22d.google.com (mail-da0-x22d.google.com [IPv6:2607:f8b0:400e:c00::22d]) by mx1.freebsd.org (Postfix) with ESMTP id 1D8E5D55 for ; Fri, 22 Mar 2013 19:12:45 +0000 (UTC) Received: by mail-da0-f45.google.com with SMTP id v40so2427047dad.32 for ; Fri, 22 Mar 2013 12:12:44 -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=096SfYtVhz9V7+pO1K8+sijjbu+aKmJWlauHnwJWOnY=; b=o0efIx6kzBzdM7eaDj3tHZJa1zpp+92Gk1t/1SH8t5+Kfo9wj9r+ZC2xfTEzxfbKeS lTOKyG29eqRqRHiyLn34C7LE+quqvl9AFTnJqy9PcGOIC5DHFJd9im/oql9mP78XfFWl Q8ZyLgdl1wZVc/aVZiIxGKIQWO9/TJMSU3rLsSGs8cGE7Okb9tghXID+sWYw+Tkmhdda 8BWgImjjfZHL0h+J3y2vCekmvWdsu5pgjRnq5vR3mYfF9BlQfnxZh73NbtvDN038w1zd ZUamFcB2D0geBXTf8cghJ3vQ/yVxnAPLXEM6Vzk6S1wCaYfcytnS3TWxZUeCskKmygoG pk8g== MIME-Version: 1.0 X-Received: by 10.66.176.205 with SMTP id ck13mr5149307pac.50.1363979564851; Fri, 22 Mar 2013 12:12:44 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.70.39.69 with HTTP; Fri, 22 Mar 2013 12:12:44 -0700 (PDT) In-Reply-To: References: Date: Fri, 22 Mar 2013 12:12:44 -0700 X-Google-Sender-Auth: BHJcsD0wYWtY-YZl5qQncaX_rw0 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: Fri, 22 Mar 2013 19:12:45 -0000 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 Sat Mar 23 23:40:36 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 2761DA00 for ; Sat, 23 Mar 2013 23:40:36 +0000 (UTC) (envelope-from jrisom@gmail.com) Received: from mail-ie0-x234.google.com (mail-ie0-x234.google.com [IPv6:2607:f8b0:4001:c03::234]) by mx1.freebsd.org (Postfix) with ESMTP id ED1D513B for ; Sat, 23 Mar 2013 23:40:35 +0000 (UTC) Received: by mail-ie0-f180.google.com with SMTP id a11so5880123iee.39 for ; Sat, 23 Mar 2013 16:40:35 -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 :content-type:content-transfer-encoding; bh=LUwkKgDoY5vMwuwb8FNwAWLyMYYLk3wf8UTlA/ECvzI=; b=XRxzexHU8zrK8T4O8c2tREPgOb4ynz3JpTdhrzhmoQDVo+LVDZASgtdZe+N+M2yzrr UFygpW1TKegUzuTr0nqAdSPkAXuHj66JUSGXaUJ+aTPHSbxWLuaboDb4Xk4pnmPRvnyo PyTDkKXtDCmbIBWjbyWrMuDYK80+y0ljxYs0WH5iGMQOpPCgflwZjPriafqzDd729ZPa +70pluDCsPcRIBcL43Odv1afNQOK2ObOuNvqc+1hp7gEAY1ytwkSSSKSNNWgVRGfaAAe SJBVkn+0yYvetXIl3fKBnxVmTkeAT5yLXaAqIOEiFgt4K7jimb2G0FXzwchG5PuppknN vtdQ== X-Received: by 10.50.212.105 with SMTP id nj9mr7998359igc.17.1364082035072; Sat, 23 Mar 2013 16:40:35 -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 wn10sm13806153igb.2.2013.03.23.16.40.33 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 23 Mar 2013 16:40:34 -0700 (PDT) Message-ID: <514E3D6D.4060800@gmail.com> Date: Sat, 23 Mar 2013 18:40:29 -0500 From: Joshua Isom User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: "freebsd-wireless@freebsd.org" Subject: Periodic panics with ath 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: Sat, 23 Mar 2013 23:40:36 -0000 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%