Re: [ath9k-devel] Is Wireless Client table supported by Ath9k ?
iw dev wlan0 station dump ? adrian 2010/12/6 Stanley Lee : > Dear All: > > Does anyone know that Wireless Client table is supported by Ath9k ? > > I use the Ralink Driver that I can capture the the Wireless Client table in > /proc/wireless/assocMob_tab like below: > # more /proc/wireless/assocMob_tab > MAC AID PSM LDT RxB TxB CTxR LTxR > 0022FA208924 1 0 1869926 46519 188088 36 48 > 00241D9E919D 2 0 1788764 902208 728332 54 48 > > Does the Ath9k has same info. like Ralink driver? > > > --- > Best Regards > Stanley lee，im@msa.hinet.net > 2010-12-06 > ___ > ath9k-devel mailing list > ath9k-devel@lists.ath9k.org > https://lists.ath9k.org/mailman/listinfo/ath9k-devel > > ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] Is Wireless Client table supported by Ath9k ?
2010/12/6 Stanley Lee : > Dear All: > > Does anyone know that Wireless Client table is supported by Ath9k ? > > I use the Ralink Driver that I can capture the the Wireless Client table in > /proc/wireless/assocMob_tab like below: > # more /proc/wireless/assocMob_tab > MAC AID PSM LDT RxB TxB CTxR LTxR > 0022FA208924 1 0 1869926 46519 188088 36 48 > 00241D9E919D 2 0 1788764 902208 728332 54 48 > > Does the Ath9k has same info. like Ralink driver? May be ath9k debug ?Please see http://linuxwireless.org/en/users/Drivers/ath9k/debug and enable mac80211 debug in kernel config cd /sys/kernel/debug/ath9k/ and cd /sys/kernel/debug/ieee80211 > > > --- > Best Regards > Stanley lee，im@msa.hinet.net > 2010-12-06 > ___ > ath9k-devel mailing list > ath9k-devel@lists.ath9k.org > https://lists.ath9k.org/mailman/listinfo/ath9k-devel > > ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] ar9170usb slow / poor performance
On Mon, Dec 6, 2010 at 3:09 PM, Mohammed Shafi wrote: > On Mon, Dec 6, 2010 at 2:21 PM, Wade Fitzpatrick > wrote: >> I have 2 USB wireless dongles: >> - Generic Realtek RTL8187 using rtl8187 driver >> - Netgear WN111v2 [Atheros AR9001-U(2)NG] using ar9170usb driver >> >> Performance of the Netgear has degraded severely since updating to Arch >> Linux kernel 2.6.36.1-3 from 2.6.35.4-2, also reported by >> http://article.gmane.org/gmane.linux.kernel.wireless.general/59911 >> >> Note that I only installed and enabled wlan1 because wlan0 was performing so >> badly. >> >> # lsusb -v -d 0bda:8187 >> >> Bus 002 Device 005: ID 0bda:8187 Realtek Semiconductor Corp. RTL8187 >> Wireless Adapter >> Device Descriptor: >> bLength 18 >> bDescriptorType 1 >> bcdUSB 2.00 >> bDeviceClass 0 (Defined at Interface level) >> bDeviceSubClass 0 >> bDeviceProtocol 0 >> bMaxPacketSize0 64 >> idVendor 0x0bda Realtek Semiconductor Corp. >> idProduct 0x8187 RTL8187 Wireless Adapter >> bcdDevice 1.00 >> iManufacturer 1 Manufacturer_Realtek_RTL8187_ >> iProduct 2 RTL8187_Wireless_LAN_Adapter >> iSerial 3 001AEF0050E6 >> bNumConfigurations 1 >> Configuration Descriptor: >> bLength 9 >> bDescriptorType 2 >> wTotalLength 39 >> bNumInterfaces 1 >> bConfigurationValue 1 >> iConfiguration 4 Wireless Network Card >> bmAttributes 0x80 >> (Bus Powered) >> MaxPower 500mA >> Interface Descriptor: >> bLength 9 >> bDescriptorType 4 >> bInterfaceNumber 0 >> bAlternateSetting 0 >> bNumEndpoints 3 >> bInterfaceClass 0 (Defined at Interface level) >> bInterfaceSubClass 0 >> bInterfaceProtocol 0 >> iInterface 5 Bulk-IN,Bulk-OUT,Bulk-OUT >> Endpoint Descriptor: >> bLength 7 >> bDescriptorType 5 >> bEndpointAddress 0x81 EP 1 IN >> bmAttributes 2 >> Transfer Type Bulk >> Synch Type None >> Usage Type Data >> wMaxPacketSize 0x0200 1x 512 bytes >> bInterval 0 >> Endpoint Descriptor: >> bLength 7 >> bDescriptorType 5 >> bEndpointAddress 0x02 EP 2 OUT >> bmAttributes 2 >> Transfer Type Bulk >> Synch Type None >> Usage Type Data >> wMaxPacketSize 0x0200 1x 512 bytes >> bInterval 0 >> Endpoint Descriptor: >> bLength 7 >> bDescriptorType 5 >> bEndpointAddress 0x03 EP 3 OUT >> bmAttributes 2 >> Transfer Type Bulk >> Synch Type None >> Usage Type Data >> wMaxPacketSize 0x0200 1x 512 bytes >> bInterval 0 >> Device Qualifier (for other device speed): >> bLength 10 >> bDescriptorType 6 >> bcdUSB 2.00 >> bDeviceClass 0 (Defined at Interface level) >> bDeviceSubClass 0 >> bDeviceProtocol 0 >> bMaxPacketSize0 64 >> bNumConfigurations 1 >> Device Status: 0x >> (Bus Powered) >> >> # lsusb -v -d 0846:9001 >> >> Bus 002 Device 004: ID 0846:9001 NetGear, Inc. WN111(v2) RangeMax Next >> Wireless [Atheros AR9001U-(2)NG] >> Device Descriptor: >> bLength 18 >> bDescriptorType 1 >> bcdUSB 2.00 >> bDeviceClass 255 Vendor Specific Class >> bDeviceSubClass 255 Vendor Specific Subclass >> bDeviceProtocol 255 Vendor Specific Protocol >> bMaxPacketSize0 64 >> idVendor 0x0846 NetGear, Inc. >> idProduct 0x9001 WN111(v2) RangeMax Next Wireless [Atheros >> AR9001U-(2)NG] >> bcdDevice 1.06 >> iManufacturer 16 ATHER >> iProduct 32 USB2.0 WLAN >> iSerial 48 12345 >> bNumConfigurations 1 >> Configuration Descriptor: >> bLength 9 >> bDescriptorType 2 >> wTotalLength 46 >> bNumInterfaces 1 >> bConfigurationValue 1 >> iConfiguration 0 >> bmAttributes 0x80 >> (Bus Powered) >> MaxPower 500mA >> Interface Descriptor: >> bLength 9 >> bDescriptorType 4 >> bInterfaceNumber 0 >> bAlternateSetting 0 >> bNumEndpoints 4 >> bInterfaceClass 255 Vendor Specific Class >> bInterfaceSubClass 0 >> bInterfaceProtocol 0 >> iInterface 0 >> Endpoint D
Re: [ath9k-devel] ath9k_htc, 2.6.36 and "Target is unresponsive" error
Rajkumar Manoharan [2010-12-03 17:03:33]: > > Please apply the following patch and try again > > > > https://patchwork.kernel.org/patch/369751/ > > > > Please apply the following firmware patch on linux-firmware git > then use the updated ar9271.fw > > http://marc.info/?l=linux-wireless&m=128214177613540&w=3 Hi, thank you for the patches, the issue seems to be gone now, cool :-) I don't know if it's standard or expected behavior, but it takes about 30 seconds to connect to my WPA/TKIP AP (Asus WL500g): r...@ts72xx:~# time ifup wlan0 && time ping -c1 www.kernel.org WPA: Configuring Interface real0m 8.08s user0m 0.26s sys 0m 0.58s PING www.kernel.org (199.6.1.164): 56 data bytes 64 bytes from 199.6.1.164: seq=0 ttl=54 time=50.000 ms --- www.kernel.org ping statistics --- 1 packets transmitted, 1 packets received, 0% packet loss round-trip min/avg/max = 50.000/50.000/50.000 ms real0m 26.24s user0m 0.00s sys 0m 0.04s This is from the dmesg: [ 22.73] usb 1-3: New USB device found, idVendor=0cf3, idProduct=1006 [ 22.73] usb 1-3: New USB device strings: Mfr=16, Product=32, SerialNumber=48 [ 22.74] usb 1-3: Product: USB2.0 WLAN [ 22.75] usb 1-3: Manufacturer: ATHEROS [ 22.75] usb 1-3: SerialNumber: 12345 [ 23.38] cfg80211: Calling CRDA to update world regulatory domain [ 25.27] usb 1-3: ath9k_htc: Transferred FW: ar9271.fw, size: 51312 [ 25.57] usb 1-3: ath9k_htc: HTC initialized with 33 credits [ 30.89] ath: EEPROM regdomain: 0x809c [ 30.89] ath: EEPROM indicates we should expect a country code [ 30.89] ath: doing EEPROM country->regdmn map search [ 30.89] ath: country maps to regdmn code: 0x52 [ 30.89] ath: Country alpha2 being used: CN [ 30.89] ath: Regpair used: 0x52 [ 31.83] cfg80211: Calling CRDA for country: CN [ 31.87] Registered led device: ath9k-phy0::radio [ 31.87] Registered led device: ath9k-phy0::assoc [ 31.87] Registered led device: ath9k-phy0::tx [ 31.88] Registered led device: ath9k-phy0::rx [ 31.88] usb 1-3: ath9k_htc: USB layer initialized [ 31.88] usbcore: registered new interface driver ath9k_hif_usb [ 67.93] wlan0: deauthenticating from 00:1d:60:9d:a8:e6 by local choice (reason=3) [ 73.74] wlan0: authenticate with 00:1d:60:9d:a8:e6 (try 1) [ 73.74] wlan0: authenticated [ 75.08] wlan0: associate with 00:1d:60:9d:a8:e6 (try 1) [ 76.42] wlan0: RX AssocResp from 00:1d:60:9d:a8:e6 (capab=0x11 status=0 aid=1) [ 76.42] wlan0: associated This is not related to the previous issue or the fix, I think, that it took a lot more without the firmware patch before. Thanks for any pointers. -- ynezz ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] Script to crash ath9k with DMA errors.
On Sat, Dec 04, 2010 at 09:18:50PM -0800, Ben Greear wrote:
> On 12/04/2010 06:41 PM, Felix Fietkau wrote:
> > On 2010-12-03 9:14 AM, Ben Greear wrote:
> >> On 12/01/2010 03:22 PM, Ben Greear wrote:
> >>> On 11/29/2010 04:44 PM, Luis R. Rodriguez wrote:
> On Mon, Nov 29, 2010 at 04:28:51PM -0800, Ben Greear wrote:
> >>>
> > BUG: unable to handle kernel NULL pointer dereference at 0040
> > IP: [] ath_tx_start+0x461/0x5ef [ath9k]
> > *pde =
> > Oops: [#1] SMP DEBUG_PAGEALLOC
> > last sysfs file: /sys/devices/pci:00/:00:1e.0/:08:01.0/irq
> > Modules linked in: aes_i586 aes_generic fuse nfs lockd fscache nfs_acl
> > auth_rpcgss sunrpc ipv6 uinput arc4 ecb ath9k mac80211 ath9k_common
> > ath9k_hw mi]
> >
> > Pid: 38, comm: kworker/u:1 Tainted: GW 2.6.37-rc3-wl+ #53
> > PDSBM/PDSBM
> > EIP: 0060:[] EFLAGS: 00010246 CPU: 1
> > EIP is at ath_tx_start+0x461/0x5ef [ath9k]
>
> Please use
>
> gdb drivers/net/wireless/ath/ath9k/
> l *(ath_tx_start+0x461)
>
> Luis
> >>>
> >>> I managed to hit that ath_tx_start crash again, and this time there were
> >>> no obvious
> >>> DMA or irq errors immediately preceding it. So, it might be a real bug
> >>> after all. I'll add some extra checks to see if tid->ac is NULL.
> >>
> >> I've made some small progress on this general issue.
> >>
> >> First, I added all sorts of debugging to try to figure out ath_tx_start
> >> crash.
> >> As best as I can tell, 'tid' is not NULL, but also is not a valid pointer,
> >> and probably something close to 0x0. I've added yet more debugging, but
> >> haven't
> >> hit the problem again.
> >>
> >> I also tried stopping DMA in a loop up to 5 times if it failed to stop
> >> previously in the loop. This did not appear to help at all.
> >>
> >> I also managed to make both the ath_tx_start crash and the DMA errors very
> >> hard to reproduce
> >> (I dare not say fixed, yet).
> >>
> >> It appears that this small patch (and possibly, the fact that I set
> >> debugging to 0x600
> >> instead of 0x400) makes the problems go away. This makes me wonder if a
> >> root cause is
> >> something to do with repeatedly resetting the hardware too fast, as
> >> setting channels rapidly
> >> would tend to do that, and channels are set on association by supplicant,
> >> it appears.
> > Please try this patch while leaving the unnecessary resets in place.
> > I found that when ath_drain_all_txq finds tx dma not stopped, it will
> > issue a reset at a point in time where it is both useless (since it's
> > right before a reset anyway) and dangerous (since the rx dma engine
> > isn't even disabled yet), so IMHO the right thing to do is to drop
> > this extra reset.
> >
> > --- a/drivers/net/wireless/ath/ath9k/xmit.c
> > +++ b/drivers/net/wireless/ath/ath9k/xmit.c
> > @@ -1194,18 +1194,8 @@ void ath_drain_all_txq(struct ath_softc
> > }
> > }
> >
> > - if (npend) {
> > - int r;
> > -
> > - ath_print(common, ATH_DBG_FATAL,
> > - "Failed to stop TX DMA. Resetting hardware!\n");
> > -
> > - r = ath9k_hw_reset(ah, sc->sc_ah->curchan, ah->caldata, false);
> > - if (r)
> > - ath_print(common, ATH_DBG_FATAL,
> > - "Unable to reset hardware; reset status %d\n",
> > - r);
> > - }
> > + if (npend)
> > + ath_print(common, ATH_DBG_FATAL, "Failed to stop TX DMA!\n");
> >
> > for (i = 0; i< ATH9K_NUM_TX_QUEUES; i++) {
> > if (ATH_TXQ_SETUP(sc, i))
>
>
> I applied this on top of all my patches, and on top of the 4 that Luis
> recently
> posted.
>
> I'm trying this on a different system than normal..happens to be configured
> with 115 stations. It was getting this fail-to-stop-RX warning even with my
> channel-change mitigation patch, so I left it in. I can still test w/it
> removed
> if you want.
>
> None of my interfaces are using WPA (or supplicant)..just un-encrypted
> association to an AP 3 feet away.
>
> The recent success I had on Friday was on a different system entirely,
> with only 84 STAs, and using wpa-supplicant with 30 or so stations
> using WPA and the other 55 on a different AP un-encrypted (still using
> wpa_supplicant for all of these).
>
> So, can't compare my previous reports directly with this one.
>
> I'm going to re-configure this one to have smaller numbers of
> stations and use wpa_supplicant..will see how that goes.
>
> Even with all these warnings in the logs..system is basically stable and
> a few interfaces are able to associate, at least for a short time.
>
>
> WARNING: at
> /home/greearb/git/linux.wireless-testing/drivers/net/wireless/ath/ath9k/recv.c:538
> ath_stoprecv+0xcd/0xd7 [ath9k]()
> Hardware name: 945GM
> Could not stop RX, we could be confusing the DMA engine when we start RX up
> Modules linked in: 8021q garp
Re: [ath9k-devel] Script to crash ath9k with DMA errors.
On 12/06/2010 11:36 AM, Luis R. Rodriguez wrote: > Can you clarify the status of this issue. It remains unclear to me from > your above description how things are going. As I read it some things > look OK now but you still get a warning. Ok, since you asked :) I worked on this over the weekend and this morning. I had all sorts of issues until I realized that I had one STA with non-configured SSID. It sometimes connected to one /a AP and the other STAs attempted to connect to another /n (on entirely different band) AP. I basically got zero stations associated for any length of time due to constant channel switching. No crashes, but lots of warnings about DMA failing to stop. Now..I've fixed this configuration issue (and adding steps to help prevent this mis-configuration again). With 16 properly configured non-encrypted stations, running with wpa-supplicant with netlink driver & sharing scan results, the interfaces quickly associate. However, I do continue to see DMA warnings such as these (I had picked up my portable phone, and it knocked all the interfaces offline ..here they are coming back up after I hung up the phone). Please note that I ported Felix's 2.6.37 patch he posted this morning to wireless-testing and have applied it. I'm highly tempted to just make that a WARN_ON_ONCE so at least my logs aren't spammed so heavily with the recv.c:531 DMA warning. Dec 6 11:32:15 atom kernel: sta2: direct probe to 00:18:e7:cb:ad:6e timed out Dec 6 11:32:15 atom kernel: sta14: direct probe to 00:18:e7:cb:ad:6e timed out Dec 6 11:32:15 atom kernel: ieee80211 wiphy0: device now idle Dec 6 11:32:15 atom kernel: ieee80211 wiphy0: device no longer idle - scanning Dec 6 11:32:15 atom kernel: start_sw_scan: running-other-vifs: 0 running-station-vifs: 16, associated-stations: 0 scanning all channels. Dec 6 11:32:17 atom kernel: ieee80211 wiphy0: device now idle Dec 6 11:32:22 atom kernel: ieee80211 wiphy0: device no longer idle - scanning Dec 6 11:32:22 atom kernel: start_sw_scan: running-other-vifs: 0 running-station-vifs: 16, associated-stations: 0 scanning all channels. Dec 6 11:32:24 atom kernel: ieee80211 wiphy0: device now idle Dec 6 11:32:29 atom kernel: ieee80211 wiphy0: device no longer idle - scanning Dec 6 11:32:29 atom kernel: start_sw_scan: running-other-vifs: 0 running-station-vifs: 16, associated-stations: 0 scanning all channels. Dec 6 11:32:29 atom kernel: ath: DMA failed to stop in 10 ms AR_CR=0x0024 AR_DIAG_SW=0x4220 Dec 6 11:32:29 atom kernel: [ cut here ] Dec 6 11:32:29 atom kernel: WARNING: at /home/greearb/git/linux.wireless-testing/drivers/net/wireless/ath/ath9k/recv.c:531 ath_stoprecv+0x90/0x9a [ath9) Dec 6 11:32:29 atom kernel: Hardware name: 945GM Dec 6 11:32:29 atom kernel: Could not stop RX, we could be confusing the DMA engine when we start RX up Dec 6 11:32:29 atom kernel: Modules linked in: michael_mic ath9k mac80211 ath9k_common ath9k_hw ath cfg80211 arc4 8021q garp stp llc macvlan pktgen isc] Dec 6 11:32:29 atom kernel: Pid: 2732, comm: kworker/u:2 Tainted: GW 2.6.37-rc4-wl+ #17 Dec 6 11:32:29 atom kernel: Call Trace: Dec 6 11:32:29 atom kernel: [<78436fbd>] warn_slowpath_common+0x77/0x8c Dec 6 11:32:29 atom kernel: [] ? ath_stoprecv+0x90/0x9a [ath9k] Dec 6 11:32:29 atom kernel: [] ? ath_stoprecv+0x90/0x9a [ath9k] Dec 6 11:32:29 atom kernel: [<7843704e>] warn_slowpath_fmt+0x2e/0x30 Dec 6 11:32:29 atom kernel: [] ath_stoprecv+0x90/0x9a [ath9k] Dec 6 11:32:29 atom kernel: [] ath_set_channel+0x94/0x1f2 [ath9k] Dec 6 11:32:29 atom kernel: [<7845a405>] ? mark_held_locks+0x47/0x5f Dec 6 11:32:29 atom kernel: [<7878e7cb>] ? _raw_spin_unlock_irqrestore+0x3c/0x48 Dec 6 11:32:29 atom kernel: [] ath9k_config+0x39a/0x479 [ath9k] Dec 6 11:32:29 atom kernel: [] ieee80211_hw_config+0x11b/0x125 [mac80211] Dec 6 11:32:29 atom kernel: [] ieee80211_scan_work+0x29e/0x3f7 [mac80211] Dec 6 11:32:29 atom kernel: [<78446f63>] ? process_one_work+0x13e/0x2bf Dec 6 11:32:29 atom kernel: [<78446fd4>] process_one_work+0x1af/0x2bf Dec 6 11:32:29 atom kernel: [<78446f63>] ? process_one_work+0x13e/0x2bf Dec 6 11:32:29 atom kernel: [] ? ieee80211_scan_work+0x0/0x3f7 [mac80211] Dec 6 11:32:29 atom kernel: [<78448722>] worker_thread+0xf9/0x1bf Dec 6 11:32:29 atom kernel: [<78448629>] ? worker_thread+0x0/0x1bf Dec 6 11:32:29 atom kernel: [<7844b252>] kthread+0x62/0x67 Dec 6 11:32:29 atom kernel: [<7844b1f0>] ? kthread+0x0/0x67 Dec 6 11:32:29 atom kernel: [<784036c6>] kernel_thread_helper+0x6/0x1a Dec 6 11:32:29 atom kernel: ---[ end trace 617a0f44fc30537b ]--- Dec 6 11:32:29 atom kernel: ath: DMA failed to stop in 10 ms AR_CR=0x0024 AR_DIAG_SW=0x4220 On module unload, I sometimes see lots of more scary looking DMA warnings, ..but again, system seems stable aside from the noise in the logs. I will capture these and post them next time I get a clean set of them (previous ones were on the mis-configur
Re: [ath9k-devel] Script to crash ath9k with DMA errors.
On Mon, Dec 06, 2010 at 11:47:47AM -0800, Ben Greear wrote: > On 12/06/2010 11:36 AM, Luis R. Rodriguez wrote: > > > Can you clarify the status of this issue. It remains unclear to me from > > your above description how things are going. As I read it some things > > look OK now but you still get a warning. > > Ok, since you asked :) > > I worked on this over the weekend and this morning. I had all sorts of > issues until I realized that I had one STA with non-configured SSID. > It sometimes connected to one /a AP and the other STAs attempted to connect > to another /n (on entirely different band) AP. I basically got zero stations > associated for any length > of time due to constant channel switching. No crashes, but lots of > warnings about DMA failing to stop. > > Now..I've fixed this configuration issue (and adding steps to help prevent > this mis-configuration > again). > > With 16 properly configured non-encrypted stations, running with > wpa-supplicant > with netlink driver & sharing scan results, the interfaces quickly associate. > > However, I do continue to see DMA warnings such as these (I had picked up my > portable phone, and it knocked all the interfaces offline ..here > they are coming back up after I hung up the phone). > > Please note that I ported Felix's 2.6.37 patch he posted this morning > to wireless-testing and have applied it. > > I'm highly tempted to just make that a WARN_ON_ONCE so at least my logs > aren't spammed so heavily with the recv.c:531 DMA warning. You can send this change upstream as well. Luis ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] Script to crash ath9k with DMA errors.
On Mon, Dec 06, 2010 at 11:53:13AM -0800, Luis Rodriguez wrote: > On Mon, Dec 06, 2010 at 11:47:47AM -0800, Ben Greear wrote: > > On 12/06/2010 11:36 AM, Luis R. Rodriguez wrote: > > > > > Can you clarify the status of this issue. It remains unclear to me from > > > your above description how things are going. As I read it some things > > > look OK now but you still get a warning. > > > > Ok, since you asked :) > > > > I worked on this over the weekend and this morning. I had all sorts of > > issues until I realized that I had one STA with non-configured SSID. > > It sometimes connected to one /a AP and the other STAs attempted to connect > > to another /n (on entirely different band) AP. I basically got zero > > stations associated for any length > > of time due to constant channel switching. No crashes, but lots of > > warnings about DMA failing to stop. > > > > Now..I've fixed this configuration issue (and adding steps to help prevent > > this mis-configuration > > again). > > > > With 16 properly configured non-encrypted stations, running with > > wpa-supplicant > > with netlink driver & sharing scan results, the interfaces quickly > > associate. > > > > However, I do continue to see DMA warnings such as these (I had picked up my > > portable phone, and it knocked all the interfaces offline ..here > > they are coming back up after I hung up the phone). > > > > Please note that I ported Felix's 2.6.37 patch he posted this morning > > to wireless-testing and have applied it. > > > > I'm highly tempted to just make that a WARN_ON_ONCE so at least my logs > > aren't spammed so heavily with the recv.c:531 DMA warning. > > You can send this change upstream as well. Also, feel free to limit the number of STAs you can have up physically by setting this to a number you bless yourself. Luis ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] Script to crash ath9k with DMA errors.
On Mon, Dec 6, 2010 at 8:47 PM, Ben Greear wrote: > With 16 properly configured non-encrypted stations, running with > wpa-supplicant > with netlink driver & sharing scan results, the interfaces quickly > associate. > > However, I do continue to see DMA warnings such as these (I had picked up my > portable phone, and it knocked all the interfaces offline ..here > they are coming back up after I hung up the phone). Is there some theory as to why using multiple interfaces cause so many problems with DMA? /Björn ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] Script to crash ath9k with DMA errors.
On 12/06/2010 12:11 PM, Björn Smedman wrote: > On Mon, Dec 6, 2010 at 8:47 PM, Ben Greear wrote: >> With 16 properly configured non-encrypted stations, running with >> wpa-supplicant >> with netlink driver& sharing scan results, the interfaces quickly >> associate. >> >> However, I do continue to see DMA warnings such as these (I had picked up my >> portable phone, and it knocked all the interfaces offline ..here >> they are coming back up after I hung up the phone). > > Is there some theory as to why using multiple interfaces cause so many > problems with DMA? Seems pretty directly related to channel changes and/or resets, and exacerbated by other interfaces sending data while another is scanning, for instance. Other issues we've found in the past have been various races that you wouldn't normally see with a single VIF. Thanks, Ben > > /Björn -- Ben Greear Candela Technologies Inc http://www.candelatech.com ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] Script to crash ath9k with DMA errors.
On 12/06/2010 11:53 AM, Luis R. Rodriguez wrote:
> On Mon, Dec 06, 2010 at 11:53:13AM -0800, Luis Rodriguez wrote:
>> On Mon, Dec 06, 2010 at 11:47:47AM -0800, Ben Greear wrote:
>>> On 12/06/2010 11:36 AM, Luis R. Rodriguez wrote:
>>>
Can you clarify the status of this issue. It remains unclear to me from
your above description how things are going. As I read it some things
look OK now but you still get a warning.
>>>
>>> Ok, since you asked :)
>>>
>>> I worked on this over the weekend and this morning. I had all sorts of
>>> issues until I realized that I had one STA with non-configured SSID.
>>> It sometimes connected to one /a AP and the other STAs attempted to connect
>>> to another /n (on entirely different band) AP. I basically got zero
>>> stations associated for any length
>>> of time due to constant channel switching. No crashes, but lots of
>>> warnings about DMA failing to stop.
>>>
>>> Now..I've fixed this configuration issue (and adding steps to help prevent
>>> this mis-configuration
>>> again).
>>>
>>> With 16 properly configured non-encrypted stations, running with
>>> wpa-supplicant
>>> with netlink driver& sharing scan results, the interfaces quickly
>>> associate.
>>>
>>> However, I do continue to see DMA warnings such as these (I had picked up my
>>> portable phone, and it knocked all the interfaces offline ..here
>>> they are coming back up after I hung up the phone).
>>>
>>> Please note that I ported Felix's 2.6.37 patch he posted this morning
>>> to wireless-testing and have applied it.
>>>
>>> I'm highly tempted to just make that a WARN_ON_ONCE so at least my logs
>>> aren't spammed so heavily with the recv.c:531 DMA warning.
>>
>> You can send this change upstream as well.
>
> Also, feel free to limit the number of STAs you can have up
> physically by setting this to a number you bless yourself.
I have a feeling there is no hard limit..but if I do find one,
I'll cook up a patch. Probably not many of us ever going to push
anywhere near what I'm trying, and folks like me can limit in
user-space if wanted...
I'll do up the warn-on-once patch shortly.
By the way, would you consider this channel-change suppression
patch, or something similar?
drivers/net/wireless/ath/ath9k/main.c
index f026a03..6c1c43b 100644
@@ -1605,6 +1605,16 @@ static int ath9k_config(struct ieee80211_hw *hw, u32
changed)
else
sc->sc_flags &= ~SC_OP_OFFCHANNEL;
+ /* If channels & HT are the same, then don't actually do
anything.
+*/
+ if ((sc->sc_ah->curchan == &sc->sc_ah->channels[pos]) &&
+ (aphy->chan_is_ht == conf_is_ht(conf))) {
+ ath_print(common, ATH_DBG_CONFIG,
+ "Skip Set channel: %d MHz, already there.\n",
+ curchan->center_freq);
+ goto skip_chan_change;
+ }
+
if (aphy->state == ATH_WIPHY_SCAN ||
aphy->state == ATH_WIPHY_ACTIVE)
ath9k_wiphy_pause_all_forced(sc, aphy);
Thanks,
Ben
--
Ben Greear
Candela Technologies Inc http://www.candelatech.com
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] Script to crash ath9k with DMA errors.
On 2010-12-06 9:28 PM, Ben Greear wrote:
> On 12/06/2010 11:53 AM, Luis R. Rodriguez wrote:
>> On Mon, Dec 06, 2010 at 11:53:13AM -0800, Luis Rodriguez wrote:
>>> On Mon, Dec 06, 2010 at 11:47:47AM -0800, Ben Greear wrote:
On 12/06/2010 11:36 AM, Luis R. Rodriguez wrote:
> Can you clarify the status of this issue. It remains unclear to me from
> your above description how things are going. As I read it some things
> look OK now but you still get a warning.
Ok, since you asked :)
I worked on this over the weekend and this morning. I had all sorts of
issues until I realized that I had one STA with non-configured SSID.
It sometimes connected to one /a AP and the other STAs attempted to connect
to another /n (on entirely different band) AP. I basically got zero
stations associated for any length
of time due to constant channel switching. No crashes, but lots of
warnings about DMA failing to stop.
Now..I've fixed this configuration issue (and adding steps to help prevent
this mis-configuration
again).
With 16 properly configured non-encrypted stations, running with
wpa-supplicant
with netlink driver& sharing scan results, the interfaces quickly
associate.
However, I do continue to see DMA warnings such as these (I had picked up
my
portable phone, and it knocked all the interfaces offline ..here
they are coming back up after I hung up the phone).
Please note that I ported Felix's 2.6.37 patch he posted this morning
to wireless-testing and have applied it.
I'm highly tempted to just make that a WARN_ON_ONCE so at least my logs
aren't spammed so heavily with the recv.c:531 DMA warning.
>>>
>>> You can send this change upstream as well.
>>
>> Also, feel free to limit the number of STAs you can have up
>> physically by setting this to a number you bless yourself.
>
> I have a feeling there is no hard limit..but if I do find one,
> I'll cook up a patch. Probably not many of us ever going to push
> anywhere near what I'm trying, and folks like me can limit in
> user-space if wanted...
>
> I'll do up the warn-on-once patch shortly.
>
> By the way, would you consider this channel-change suppression
> patch, or something similar?
>
>
> drivers/net/wireless/ath/ath9k/main.c
>
> index f026a03..6c1c43b 100644
> @@ -1605,6 +1605,16 @@ static int ath9k_config(struct ieee80211_hw *hw, u32
> changed)
> else
> sc->sc_flags &= ~SC_OP_OFFCHANNEL;
>
> + /* If channels & HT are the same, then don't actually do
> anything.
> + */
> + if ((sc->sc_ah->curchan == &sc->sc_ah->channels[pos]) &&
> + (aphy->chan_is_ht == conf_is_ht(conf))) {
> + ath_print(common, ATH_DBG_CONFIG,
> + "Skip Set channel: %d MHz, already there.\n",
> + curchan->center_freq);
> + goto skip_chan_change;
> + }
> +
I think this needs to check the offchannel flag as well, at least in one
direction. Skipping on-channel -> off-channel is fine, but the other way
around might break calibration
- Felix
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] Script to crash ath9k with DMA errors.
On Mon, Dec 06, 2010 at 12:22:26PM -0800, Ben Greear wrote: > On 12/06/2010 12:11 PM, Björn Smedman wrote: > > On Mon, Dec 6, 2010 at 8:47 PM, Ben Greear wrote: > >> With 16 properly configured non-encrypted stations, running with > >> wpa-supplicant > >> with netlink driver& sharing scan results, the interfaces quickly > >> associate. > >> > >> However, I do continue to see DMA warnings such as these (I had picked up > >> my > >> portable phone, and it knocked all the interfaces offline ..here > >> they are coming back up after I hung up the phone). > > > > Is there some theory as to why using multiple interfaces cause so many > > problems with DMA? > > Seems pretty directly related to channel changes and/or resets, and > exacerbated > by other interfaces sending data while another is scanning, for instance. > > Other issues we've found in the past have been various races that you wouldn't > normally see with a single VIF. Right, there might be some other hot path we need to lock around over. Not sure what it could be though we should be locking stopping RX over resets already though. These should all be atomic, in fact starting TX too IIRC, hence the name change of the lock to be specific to the PCU together. There may be other PCU changes we may need to contend against. Luis ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] Script to crash ath9k with DMA errors.
On 12/06/2010 12:42 PM, Luis R. Rodriguez wrote: > On Mon, Dec 06, 2010 at 12:22:26PM -0800, Ben Greear wrote: >> On 12/06/2010 12:11 PM, Björn Smedman wrote: >>> On Mon, Dec 6, 2010 at 8:47 PM, Ben Greear wrote: With 16 properly configured non-encrypted stations, running with wpa-supplicant with netlink driver& sharing scan results, the interfaces quickly associate. However, I do continue to see DMA warnings such as these (I had picked up my portable phone, and it knocked all the interfaces offline ..here they are coming back up after I hung up the phone). >>> >>> Is there some theory as to why using multiple interfaces cause so many >>> problems with DMA? >> >> Seems pretty directly related to channel changes and/or resets, and >> exacerbated >> by other interfaces sending data while another is scanning, for instance. >> >> Other issues we've found in the past have been various races that you >> wouldn't >> normally see with a single VIF. > > Right, there might be some other hot path we need to lock around over. > Not sure what it could be though we should be locking stopping RX > over resets already though. These should all be atomic, in fact > starting TX too IIRC, hence the name change of the lock to be > specific to the PCU together. There may be other PCU changes > we may need to contend against. Maybe the hardware/firmware guys could give us some clues as to what types of things can cause stopping RMA to fail? Maybe that could point us to what might be racing with the attempts to stop RMA? Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] Script to crash ath9k with DMA errors.
On Mon, Dec 06, 2010 at 01:00:05PM -0800, Ben Greear wrote: > On 12/06/2010 12:42 PM, Luis R. Rodriguez wrote: > > On Mon, Dec 06, 2010 at 12:22:26PM -0800, Ben Greear wrote: > >> On 12/06/2010 12:11 PM, Björn Smedman wrote: > >>> On Mon, Dec 6, 2010 at 8:47 PM, Ben Greear > >>> wrote: > With 16 properly configured non-encrypted stations, running with > wpa-supplicant > with netlink driver& sharing scan results, the interfaces quickly > associate. > > However, I do continue to see DMA warnings such as these (I had picked > up my > portable phone, and it knocked all the interfaces offline ..here > they are coming back up after I hung up the phone). > >>> > >>> Is there some theory as to why using multiple interfaces cause so many > >>> problems with DMA? > >> > >> Seems pretty directly related to channel changes and/or resets, and > >> exacerbated > >> by other interfaces sending data while another is scanning, for instance. > >> > >> Other issues we've found in the past have been various races that you > >> wouldn't > >> normally see with a single VIF. > > > > Right, there might be some other hot path we need to lock around over. > > Not sure what it could be though we should be locking stopping RX > > over resets already though. These should all be atomic, in fact > > starting TX too IIRC, hence the name change of the lock to be > > specific to the PCU together. There may be other PCU changes > > we may need to contend against. > > Maybe the hardware/firmware guys could give us some clues as to what > types of things can cause stopping RMA to fail? Maybe that could > point us to what might be racing with the attempts to stop RMA? We have no firmware, but yeah understanding how the hardware blocks would be key here. Good point. Luis ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
[ath9k-devel] [PATCH] ath9k: Make DMA warning in ath_stoprecv WARN_ON_ONCE.
From: Ben Greear
This decreases spammage in the log. A single line message
will still be printed, so users can be aware that problem
exists.
Signed-off-by: Ben Greear
---
:100644 100644 b4417d2... 082b16d... M drivers/net/wireless/ath/ath9k/recv.c
:100644 100644 f207007... 10cf682... M drivers/net/wireless/ath/debug.h
drivers/net/wireless/ath/ath9k/recv.c |8 ++--
drivers/net/wireless/ath/debug.h |2 ++
2 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/recv.c
b/drivers/net/wireless/ath/ath9k/recv.c
index b4417d2..082b16d 100644
--- a/drivers/net/wireless/ath/ath9k/recv.c
+++ b/drivers/net/wireless/ath/ath9k/recv.c
@@ -527,8 +527,12 @@ bool ath_stoprecv(struct ath_softc *sc)
sc->rx.rxlink = NULL;
spin_unlock_bh(&sc->rx.rxbuflock);
- ATH_DBG_WARN(!stopped, "Could not stop RX, we could be "
-"confusing the DMA engine when we start RX up\n");
+ if (unlikely(!stopped)) {
+ ath_print(ath9k_hw_common(sc->sc_ah), ATH_DBG_FATAL,
+ "Could not stop RX, we could be "
+ "confusing the DMA engine when we start RX up\n");
+ ATH_DBG_WARN_ON_ONCE(!stopped);
+ }
return stopped;
}
diff --git a/drivers/net/wireless/ath/debug.h b/drivers/net/wireless/ath/debug.h
index f207007..10cf682 100644
--- a/drivers/net/wireless/ath/debug.h
+++ b/drivers/net/wireless/ath/debug.h
@@ -71,12 +71,14 @@ enum ATH_DEBUG {
void ath_print(struct ath_common *common, int dbg_mask, const char *fmt, ...)
__attribute__ ((format (printf, 3, 4)));
#define ATH_DBG_WARN(foo, arg...) WARN(foo, arg)
+#define ATH_DBG_WARN_ON_ONCE(foo) WARN_ON_ONCE(foo)
#else
static inline void __attribute__ ((format (printf, 3, 4)))
ath_print(struct ath_common *common, int dbg_mask, const char *fmt, ...)
{
}
#define ATH_DBG_WARN(foo, arg)
+#define ATH_DBG_WARN_ON_ONCE(foo)
#endif /* CONFIG_ATH_DEBUG */
/** Returns string describing opmode, or NULL if unknown mode. */
--
1.7.2.3
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] [PATCH] ath9k: Make DMA warning in ath_stoprecv WARN_ON_ONCE.
On Mon, Dec 06, 2010 at 01:13:07PM -0800, gree...@gmail.com wrote: > From: Ben Greear > > This decreases spammage in the log. A single line message > will still be printed, so users can be aware that problem > exists. > > Signed-off-by: Ben Greear Acked-by: Luis R. Rodriguez Luis ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] [PATCH] ath9k: Make DMA warning in ath_stoprecv WARN_ON_ONCE.
On Mon, Dec 6, 2010 at 1:59 PM, Luis R. Rodriguez wrote: > On Mon, Dec 06, 2010 at 01:13:07PM -0800, gree...@gmail.com wrote: >> From: Ben Greear >> >> This decreases spammage in the log. A single line message >> will still be printed, so users can be aware that problem >> exists. >> >> Signed-off-by: Ben Greear > > Acked-by: Luis R. Rodriguez You forgot to address linville, and no need to send to ath9k-devel if you already know the patch is good. Luis ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
[ath9k-devel] ath9k: txctl and/or TID corruption in ath_tx_start_dma.
This system is running 84 VIFs, WPA encryption, wpa-supplicant scan-sharing
and some scan-avoidance logic in mac80211.
All stations are trying to run a 56kbps TCP data flow as soon as they
associate.
I have seen and reported this problem previously, but it seems I finally
got my debug code right, because now it prints useful information
and recovers.
Something is corrupting txctl->an, at the least.
The method with debug looks like this:
/* FIXME: tx power */
static int ath_tx_start_dma(struct ath_softc *sc, struct ath_buf *bf,
struct ath_tx_control *txctl)
{
struct sk_buff *skb = bf->bf_mpdu;
struct ieee80211_tx_info *tx_info = IEEE80211_SKB_CB(skb);
struct ieee80211_hdr *hdr = (struct ieee80211_hdr *)skb->data;
struct list_head bf_head;
struct ath_atx_tid *tid;
u8 tidno;
int rv = 0;
spin_lock_bh(&txctl->txq->axq_lock);
if ((tx_info->flags & IEEE80211_TX_CTL_AMPDU) && txctl->an) {
tidno = ieee80211_get_qos_ctl(hdr)[0] &
IEEE80211_QOS_CTL_TID_MASK;
BUG_ON(tidno < 0);
BUG_ON(tidno >= WME_NUM_TID);
tid = ATH_AN_2_TID(txctl->an, tidno);
if ((!tid) || ((unsigned long)(tid) < 4096)) {
printk("ERROR: ath9k: tid is NULL, tid: %p tidno: %i
txctl->an: %p\n",
tid, tidno, txctl->an);
WARN_ON(1);
rv = -EINVAL;
goto out;
}
if (!tid->ac) {
printk("ERROR: ath9k: tid->ac is NULL, tid: %p tidno:
%i\n",
tid, tidno);
WARN_ON(tid->ac == NULL);
rv = -EINVAL;
goto out;
}
else {
if (tid->ac->txq != txctl->txq) {
printk("ERROR: ath9k: tid->ac->txq (%p) !=
txctl->txq (%p), tidno: %i\n",
tid->ac->txq, txctl->txq, tidno);
WARN_ON(tid->ac->txq != txctl->txq);
rv = -EINVAL;
goto out;
}
}
/*
* Try aggregation if it's a unicast data frame
* and the destination is HT capable.
*/
ath_tx_send_ampdu(sc, tid, bf, txctl);
} else {
INIT_LIST_HEAD(&bf_head);
list_add_tail(&bf->list, &bf_head);
bf->bf_state.bfs_ftype = txctl->frame_type;
bf->bf_state.bfs_paprd = txctl->paprd;
if (bf->bf_state.bfs_paprd)
ar9003_hw_set_paprd_txdesc(sc->sc_ah, bf->bf_desc,
bf->bf_state.bfs_paprd);
ath_tx_send_normal(sc, txctl->txq, NULL, &bf_head);
}
out:
spin_unlock_bh(&txctl->txq->axq_lock);
return rv;
}
Dec 6 15:20:56 localhost kernel: ADDRCONF(NETDEV_UP): sta67: link is not ready
Dec 6 15:20:56 localhost kernel: start_sw_scan: running-other-vifs: 0
running-station-vifs: 69, associated-stations: 67 scanning current channel:
2437 MHz
Dec 6 15:20:56 localhost kernel: ADDRCONF(NETDEV_UP): sta68: link is not ready
Dec 6 15:20:56 localhost kernel: ERROR: ath9k: tid is NULL, tid: 002c
tidno: 0 txctl->an: 0028
Dec 6 15:20:56 localhost kernel: [ cut here ]
Dec 6 15:20:56 localhost kernel: WARNING: at
/home/greearb/git/linux.wireless-testing/drivers/net/wireless/ath/ath9k/xmit.c:1708
ath_tx_start+0x4cd/0x69a [ath9k]()
Dec 6 15:20:56 localhost kernel: Hardware name: PDSBM
Dec 6 15:20:56 localhost kernel: Modules linked in: aes_i586 aes_generic 8021q
garp stp llc michael_mic fuse macvlan pktgen nfs lockd fscache nfs_acl
auth_rpcgss sunrpc ipv6 uinput arc4 ecb ath9k mac80211 ath9k_common ath9k_hw
ath microcode e1000e iTCO_wdt cfg80211 iTCO_vendor_support pcspkr i2c_i801 i915
drm_kms_helper drm i2c_algo_bit i2c_core video output [last unloaded:
michael_mic]
Dec 6 15:20:56 localhost kernel: Pid: 7652, comm: sh Tainted: P
2.6.37-rc4-wl+ #55
Dec 6 15:20:56 localhost kernel: Call Trace:
Dec 6 15:20:56 localhost kernel: [<78436fbd>] warn_slowpath_common+0x77/0x8c
Dec 6 15:20:56 localhost kernel: [] ? ath_tx_start+0x4cd/0x69a
[ath9k]
Dec 6 15:20:56 localhost kernel: [] ? ath_tx_start+0x4cd/0x69a
[ath9k]
Dec 6 15:20:56 localhost kernel: [<78436fef>] warn_slowpath_null+0x1d/0x1f
Dec 6 15:20:56 localhost kernel: [] ath_tx_start+0x4cd/0x69a [ath9k]
Dec 6 15:20:56 localhost kernel: [] ath9k_tx+0x197/0x1c8 [ath9k]
Dec 6 15:20:56 localhost kernel: [] __ieee80211_tx+0x102/0x167
[mac80211]
Dec 6 15:20:56 localhost kernel: [] ieee80211_tx_pending+0x108/0x1fe
[mac80211]
Dec 6 15
Re: [ath9k-devel] Is setting txpower in master mode on ath9k supposed to work?
I have made a bit of progress on my problems with setting txpower in master mode on ath9k. It turns out that setting txpower does work, but that the settings that get sent to the adapter for a given requested txpower are wrong. If anybody knows the details of how ath9k_hw_set_def_power_per_rate_table works it might be obvious what is going wrong here. I have tested with two different adapters. In both cases, low values of txpower seem to max out the transmit power. As you increase txpower, nothing happens initially. Then the observed power steps down, and thereafter increases nicely as one would expect (though some boards seem to better calibrated and more consistent than others). See APPENDIX A for the raw data. This problem is troublesome, as it could cause regulatory limits to be exceeded, since setting a low txpower will actually cause a much higher txpower to be set on the adapter. Digging through the code a bit, it appears that ath9k_hw_def_set_txpower in eeprom_def.c is correctly receiving the requested txpower (or rather twice the requested txpower). However, the values it gets from ath9k_hw_set_def_power_per_rate_table appear to have are non-monotonic, and match the txpower I have been observing. APPENDIX B shows the ratesArray values as a function of powerLimit. Any tips would be appreciated, Blaise APPENDIX A: Received power as a function of txpower. (First column is txpower requested using iwconfig, second column is RSSI as seen by tcpdump on a monitor interface on another computer. Adapter 1 0 -57.5 1 -57.6 2 -57.0 3 -70.95 4 -71.45 5 -69.55 6 -71.4 7 -68.25 8 -67.5 9 -66.1 10 -67.4 11 -65.45 12 -63.15 13 -61.7 14 -60.35 15 -58.6 16 -59.6 17 -56.55 18 -57.55 19 -56.35 20 -58.5217391304 Adapter 2 0 -54.6 1 -55.2 2 -55.0 3 -55.2 4 -55.2 5 -68.2 6 -68.2 7 -66.2 8 -66.4 9 -65.0 10 -64.4 11 -63.6 12 -62.6 13 -61.6 14 -60.2 15 -58.4 16 -58.4 17 -57.2 APPENDIX B: ratesArray as a function of powerLimit (First number before colon is powerLimit, remaining numbers are entries in ratesArray.) Adapter 1 0: 32 32 32 32 32 32 32 32 36 36 36 36 36 36 36 32 32 32 32 32 32 32 32 30 10 10 10 10 10 10 10 10 10 10 10 10 2: 32 32 32 32 32 32 32 32 36 36 36 36 36 36 36 32 32 32 32 32 32 32 32 30 10 10 10 10 10 10 10 10 10 10 10 10 4: 32 32 32 32 32 32 32 32 36 36 36 36 36 36 36 32 32 32 32 32 32 32 32 30 10 10 10 10 10 10 10 10 10 10 10 10 6: 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 8: 12 12 12 12 12 12 12 12 12 12 12 12 12 12 12 12 12 12 12 12 12 12 12 12 10 10 10 10 10 10 10 10 10 10 10 10 10: 14 14 14 14 14 14 14 14 14 14 14 14 14 14 14 14 14 14 14 14 14 14 14 14 10 10 10 10 10 10 10 10 10 10 10 10 12: 16 16 16 16 16 16 16 16 16 16 16 16 16 16 16 16 16 16 16 16 16 16 16 16 10 10 10 10 10 10 10 10 10 10 10 10 14: 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 10 10 10 10 10 10 10 10 10 10 10 10 16: 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 10 10 10 10 10 10 10 10 10 10 10 10 18: 22 22 22 22 22 22 22 22 22 22 22 22 22 22 22 22 22 22 22 22 22 22 22 22 10 10 10 10 10 10 10 10 10 10 10 10 20: 24 24 24 24 24 24 24 24 24 24 24 24 24 24 24 24 24 24 24 24 24 24 24 24 10 10 10 10 10 10 10 10 10 10 10 10 22: 26 26 26 26 26 26 26 26 26 26 26 26 26 26 26 26 26 26 26 26 26 26 26 26 10 10 10 10 10 10 10 10 10 10 10 10 24: 28 28 28 28 28 28 28 28 28 28 28 28 28 28 28 28 28 28 28 28 28 28 28 28 10 10 10 10 10 10 10 10 10 10 10 10 26: 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 10 10 10 10 10 10 10 10 10 10 10 10 28: 32 32 32 32 32 32 32 32 32 32 32 32 32 32 32 32 32 32 32 32 32 32 32 30 10 10 10 10 10 10 10 10 10 10 10 10 30: 32 32 32 32 32 32 32 32 34 34 34 34 34 34 34 32 32 32 32 32 32 32 32 30 10 10 10 10 10 10 10 10 10 10 10 10 32: 32 32 32 32 32 32 32 32 36 36 36 36 36 36 36 32 32 32 32 32 32 32 32 30 10 10 10 10 10 10 10 10 10 10 10 10 34: 32 32 32 32 32 32 32 32 36 36 36 36 36 36 36 32 32 32 32 32 32 32 32 30 10 10 10 10 10 10 10 10 10 10 10 10 36: 32 32 32 32 32 32 32 32 36 36 36 36 36 36 36 32 32 32 32 32 32 32 32 30 10 10 10 10 10 10 10 10 10 10 10 10 38: 32 32 32 32 32 32 32 32 36 36 36 36 36 36 36 32 32 32 32 32 32 32 32 30 10 10 10 10 10 10 10 10 10 10 10 10 40: 32 32 32 32 32 32 32 32 36 36 36 36 36 36 36 32 32 32 32 32 32 32 32 30 10 10 10 10 10 10 10 10 10 10 10 10 Adapter 2 0: 30 30 30 30 30 30 30 26 0 0 0 0 0 0 0 30 30 30 30 30 30 30 30 26 0 0 0 0 0 0 0 0 0 0 0 0 2: 30 30 30 30 30 30 30 26 0 0 0 0 0 0 0 30 30 30 30 30 30 30 30 26 0 0 0 0 0 0 0 0 0 0 0 0 4: 30 30 30 30 30 30 30 26 0 0 0 0 0 0 0 30 30 30 30 30 30 30 30 26 0 0 0 0 0 0 0 0 0 0 0 0 6: 30 30 30 30 30 30 30 26 0 0 0 0 0 0 0 30 30 30 30 30 30 30 30 26 0 0 0 0 0 0 0 0 0 0 0 0 8: 30 30 30 30 30 30 30 26 0 0 0 0 0 0 0 30 30 30 30 30 30 30 30 26 0 0 0 0 0 0 0 0 0 0 0 0 10: 1 1 1 1 1 1 1 1 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 0 0 0 0 0 0 0 0 0 0 0 0 12: 3 3 3 3 3 3 3 3 0 0 0 0 0 0 0 3 3 3 3 3 3 3 3 3 0 0 0
Re: [ath9k-devel] Is setting txpower in master mode on ath9k supposed to work?
On Mon, Dec 6, 2010 at 8:05 PM, Blaise Gassend wrote: > I have made a bit of progress on my problems with setting txpower in > master mode on ath9k. It turns out that setting txpower does work, but > that the settings that get sent to the adapter for a given requested > txpower are wrong. If anybody knows the details of how > ath9k_hw_set_def_power_per_rate_table works it might be obvious what > is going wrong here. > > I have tested with two different adapters. In both cases, low values > of txpower seem to max out the transmit power. As you increase > txpower, nothing happens initially. Then the observed power steps > down, and thereafter increases nicely as one would expect (though some > boards seem to better calibrated and more consistent than others). See > APPENDIX A for the raw data. This problem is troublesome, as it could > cause regulatory limits to be exceeded, since setting a low txpower > will actually cause a much higher txpower to be set on the adapter. > > Digging through the code a bit, it appears that > ath9k_hw_def_set_txpower in eeprom_def.c is correctly receiving the > requested txpower (or rather twice the requested txpower). However, > the values it gets from ath9k_hw_set_def_power_per_rate_table appear > to have are non-monotonic, and match the txpower I have been > observing. APPENDIX B shows the ratesArray values as a function of > powerLimit. > > Any tips would be appreciated, > Blaise > > APPENDIX A: Received power as a function of txpower. > (First column is txpower requested using iwconfig, second column is > RSSI as seen by tcpdump on a monitor interface on another computer. > > Adapter 1 > 0 -57.5 > 1 -57.6 > 2 -57.0 > 3 -70.95 > 4 -71.45 > 5 -69.55 > 6 -71.4 > 7 -68.25 > 8 -67.5 > 9 -66.1 > 10 -67.4 > 11 -65.45 > 12 -63.15 > 13 -61.7 > 14 -60.35 > 15 -58.6 > 16 -59.6 > 17 -56.55 > 18 -57.55 > 19 -56.35 > 20 -58.5217391304 > > Adapter 2 > 0 -54.6 > 1 -55.2 > 2 -55.0 > 3 -55.2 > 4 -55.2 > 5 -68.2 > 6 -68.2 > 7 -66.2 > 8 -66.4 > 9 -65.0 > 10 -64.4 > 11 -63.6 > 12 -62.6 > 13 -61.6 > 14 -60.2 > 15 -58.4 > 16 -58.4 > 17 -57.2 > > APPENDIX B: ratesArray as a function of powerLimit > > (First number before colon is powerLimit, remaining numbers are > entries in ratesArray.) > > Adapter 1 > 0: 32 32 32 32 32 32 32 32 36 36 36 36 36 36 36 32 32 32 32 32 32 32 > 32 30 10 10 10 10 10 10 10 10 10 10 10 10 > 2: 32 32 32 32 32 32 32 32 36 36 36 36 36 36 36 32 32 32 32 32 32 32 > 32 30 10 10 10 10 10 10 10 10 10 10 10 10 > 4: 32 32 32 32 32 32 32 32 36 36 36 36 36 36 36 32 32 32 32 32 32 32 > 32 30 10 10 10 10 10 10 10 10 10 10 10 10 > 6: 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 > 10 10 10 10 10 10 10 10 10 10 10 10 10 10 > 8: 12 12 12 12 12 12 12 12 12 12 12 12 12 12 12 12 12 12 12 12 12 12 > 12 12 10 10 10 10 10 10 10 10 10 10 10 10 > 10: 14 14 14 14 14 14 14 14 14 14 14 14 14 14 14 14 14 14 14 14 14 14 > 14 14 10 10 10 10 10 10 10 10 10 10 10 10 > 12: 16 16 16 16 16 16 16 16 16 16 16 16 16 16 16 16 16 16 16 16 16 16 > 16 16 10 10 10 10 10 10 10 10 10 10 10 10 > 14: 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 > 18 18 10 10 10 10 10 10 10 10 10 10 10 10 > 16: 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 > 20 20 10 10 10 10 10 10 10 10 10 10 10 10 > 18: 22 22 22 22 22 22 22 22 22 22 22 22 22 22 22 22 22 22 22 22 22 22 > 22 22 10 10 10 10 10 10 10 10 10 10 10 10 > 20: 24 24 24 24 24 24 24 24 24 24 24 24 24 24 24 24 24 24 24 24 24 24 > 24 24 10 10 10 10 10 10 10 10 10 10 10 10 > 22: 26 26 26 26 26 26 26 26 26 26 26 26 26 26 26 26 26 26 26 26 26 26 > 26 26 10 10 10 10 10 10 10 10 10 10 10 10 > 24: 28 28 28 28 28 28 28 28 28 28 28 28 28 28 28 28 28 28 28 28 28 28 > 28 28 10 10 10 10 10 10 10 10 10 10 10 10 > 26: 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 > 30 30 10 10 10 10 10 10 10 10 10 10 10 10 > 28: 32 32 32 32 32 32 32 32 32 32 32 32 32 32 32 32 32 32 32 32 32 32 > 32 30 10 10 10 10 10 10 10 10 10 10 10 10 > 30: 32 32 32 32 32 32 32 32 34 34 34 34 34 34 34 32 32 32 32 32 32 32 > 32 30 10 10 10 10 10 10 10 10 10 10 10 10 > 32: 32 32 32 32 32 32 32 32 36 36 36 36 36 36 36 32 32 32 32 32 32 32 > 32 30 10 10 10 10 10 10 10 10 10 10 10 10 > 34: 32 32 32 32 32 32 32 32 36 36 36 36 36 36 36 32 32 32 32 32 32 32 > 32 30 10 10 10 10 10 10 10 10 10 10 10 10 > 36: 32 32 32 32 32 32 32 32 36 36 36 36 36 36 36 32 32 32 32 32 32 32 > 32 30 10 10 10 10 10 10 10 10 10 10 10 10 > 38: 32 32 32 32 32 32 32 32 36 36 36 36 36 36 36 32 32 32 32 32 32 32 > 32 30 10 10 10 10 10 10 10 10 10 10 10 10 > 40: 32 32 32 32 32 32 32 32 36 36 36 36 36 36 36 32 32 32 32 32 32 32 > 32 30 10 10 10 10 10 10 10 10 10 10 10 10 > > Adapter 2 > 0: 30 30 30 30 30 30 30 26 0 0 0 0 0 0 0 30 30 30 30 30 30 30 30 26 0 > 0 0 0 0 0 0 0 0 0 0 0 > 2: 30 30 30 30 30 30 30 26 0 0 0 0 0 0 0 30 30 30 30 30 30 30 30 26 0 > 0 0 0 0 0 0 0 0 0 0 0 > 4: 30 30 30 30 30 30 30 26 0 0 0 0 0 0 0 30 30 30 30 30 30 30 30 26 0 > 0 0 0 0 0 0 0 0 0 0 0 > 6: 30 30 3
Re: [ath9k-devel] Country code setting issue
On Sun, Dec 5, 2010 at 10:33 PM, mason wrote: > Appraently, they are the same but I found one thing is differently > distinguished. Every country has its own entry even though a lot of them share the same information. This was done because there is an inherent complexity that is simply not worth to maintain if you try to group countries together as with how Atheros used to bundle regulatory domains together. In the long run this is simply complex and a maintenance nightmare. > Except KR country, a wireless mobile can easily access to the AP set by > the rest of the countries' code. No. ath9k cards always respect the regulatory domain programmed into the hardware's EEPROM, the APIs for users only let the user help compliance further, never to allow more channels. Simply avoid setting the regulatory domain unless you really want to go out of your way to help with things, but things should already be taken care of for you. Luis ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] ath9k: txctl and/or TID corruption in ath_tx_start_dma.
On 12/06/2010 04:16 PM, Ben Greear wrote:
> This system is running 84 VIFs, WPA encryption, wpa-supplicant scan-sharing
> and some scan-avoidance logic in mac80211.
>
> All stations are trying to run a 56kbps TCP data flow as soon as they
> associate.
>
> I have seen and reported this problem previously, but it seems I finally
> got my debug code right, because now it prints useful information
> and recovers.
>
> Something is corrupting txctl->an, at the least.
I think maybe I found a cause for this. According to net/mac80211.h, sta
can be null, but this code never checks for that. If the compiler is being
clever, it may not actually do a dereference, so maybe that's why it never
crashed when assigning txctl->an.
I'm going to test this patch. This one isn't always easy to hit, so going
to leave lots of debugging in mine...but if this looks correct, I or someone
else can provide a cleaned up patch...
diff --git a/drivers/net/wireless/ath/ath9k/xmit.c
b/drivers/net/wireless/ath/ath9k/xmit.c
index 8b0b076..6cdb1d2 100644
--- a/drivers/net/wireless/ath/ath9k/xmit.c
+++ b/drivers/net/wireless/ath/ath9k/xmit.c
@@ -1764,7 +1764,20 @@ int ath_tx_start(struct ieee80211_hw *hw, struct sk_buff
*skb,
int frmlen = skb->len + FCS_LEN;
int q;
- txctl->an = (struct ath_node *)sta->drv_priv;
+ /* NOTE: sta can be NULL according to net/mac80211.h */
+ if (sta) {
+ txctl->an = (struct ath_node *)sta->drv_priv;
+ if (((unsigned long)(txctl->an)) < 4096) {
+ printk("invalid txctl->an: %p sta: %p sta->drv_priv:
%p\n",
+ txctl->an, sta, sta->drv_priv);
+ WARN_ON(1);
+ return -EINVAL;
+ }
+ }
+ else {
+ printk("ath9k: sta was NULL in ath_tx_start.\n");
+ }
+
if (info->control.hw_key)
frmlen += info->control.hw_key->icv_len;
> The method with debug looks like this:
>
> /* FIXME: tx power */
> static int ath_tx_start_dma(struct ath_softc *sc, struct ath_buf *bf,
> struct ath_tx_control *txctl)
> {
> struct sk_buff *skb = bf->bf_mpdu;
> struct ieee80211_tx_info *tx_info = IEEE80211_SKB_CB(skb);
> struct ieee80211_hdr *hdr = (struct ieee80211_hdr *)skb->data;
> struct list_head bf_head;
> struct ath_atx_tid *tid;
> u8 tidno;
> int rv = 0;
>
> spin_lock_bh(&txctl->txq->axq_lock);
>
> if ((tx_info->flags & IEEE80211_TX_CTL_AMPDU) && txctl->an) {
> tidno = ieee80211_get_qos_ctl(hdr)[0] &
> IEEE80211_QOS_CTL_TID_MASK;
> BUG_ON(tidno < 0);
> BUG_ON(tidno >= WME_NUM_TID);
> tid = ATH_AN_2_TID(txctl->an, tidno);
>
> if ((!tid) || ((unsigned long)(tid) < 4096)) {
> printk("ERROR: ath9k: tid is NULL, tid: %p tidno: %i txctl->an: %p\n",
> tid, tidno, txctl->an);
> WARN_ON(1);
> rv = -EINVAL;
> goto out;
> }
> if (!tid->ac) {
> printk("ERROR: ath9k: tid->ac is NULL, tid: %p tidno: %i\n",
> tid, tidno);
> WARN_ON(tid->ac == NULL);
> rv = -EINVAL;
> goto out;
> }
> else {
> if (tid->ac->txq != txctl->txq) {
> printk("ERROR: ath9k: tid->ac->txq (%p) != txctl->txq (%p), tidno: %i\n",
> tid->ac->txq, txctl->txq, tidno);
> WARN_ON(tid->ac->txq != txctl->txq);
> rv = -EINVAL;
> goto out;
> }
> }
>
> /*
> * Try aggregation if it's a unicast data frame
> * and the destination is HT capable.
> */
> ath_tx_send_ampdu(sc, tid, bf, txctl);
> } else {
> INIT_LIST_HEAD(&bf_head);
> list_add_tail(&bf->list, &bf_head);
>
> bf->bf_state.bfs_ftype = txctl->frame_type;
> bf->bf_state.bfs_paprd = txctl->paprd;
>
> if (bf->bf_state.bfs_paprd)
> ar9003_hw_set_paprd_txdesc(sc->sc_ah, bf->bf_desc,
> bf->bf_state.bfs_paprd);
>
> ath_tx_send_normal(sc, txctl->txq, NULL, &bf_head);
> }
> out:
> spin_unlock_bh(&txctl->txq->axq_lock);
> return rv;
> }
>
>
>
> Dec 6 15:20:56 localhost kernel: ADDRCONF(NETDEV_UP): sta67: link is not ready
> Dec 6 15:20:56 localhost kernel: start_sw_scan: running-other-vifs: 0
> running-station-vifs: 69, associated-stations: 67 scanning current channel:
> 2437 MHz
> Dec 6 15:20:56 localhost kernel: ADDRCONF(NETDEV_UP): sta68: link is not ready
> Dec 6 15:20:56 localhost kernel: ERROR: ath9k: tid is NULL, tid: 002c
> tidno: 0 txctl->an: 0028
> Dec 6 15:20:56 localhost kernel: [ cut here ]
> Dec 6 15:20:56 localhost kernel: WARNING: at
> /home/greearb/git/linux.wireless-testing/drivers/net/wireless/ath/ath9k/xmit.c:1708
> ath_tx_start+0x4cd/0x69a [ath9k]()
> Dec 6 15:20:56 localhost kernel: Hardware name: PDSBM
> Dec 6 15:20:56 localhost kernel: Modules linked in: aes_i586 aes_generic
> 8021q garp stp llc michael_mic fuse macvlan pktgen nfs lockd fscache nfs_acl
> auth_rpcgss sunrpc ipv6 uinput arc4 ecb ath9k mac80211 ath9k_common ath9k_hw
> ath microcode e1000e iTCO_wdt cfg80211 iTCO_vendor_support pcspkr i2c_i801
> i915
> drm_kms_helper drm i2c_algo_bit i2c_core video output [last unloaded:
> michael_mic]
> Dec 6 15:20:56 localhost kernel: Pid: 7652, comm: sh T
[ath9k-devel] [PATCH] ath9k: Check for NULL sta in ath_tx_start
From: Ben Greear It can be NULL according to docs, and logging showed it to be NULL in practice. Signed-off-by: Ben Greear --- :100644 100644 8b0b076... 5ddca08... M drivers/net/wireless/ath/ath9k/xmit.c drivers/net/wireless/ath/ath9k/xmit.c |5 - 1 files changed, 4 insertions(+), 1 deletions(-) diff --git a/drivers/net/wireless/ath/ath9k/xmit.c b/drivers/net/wireless/ath/ath9k/xmit.c index 8b0b076..5ddca08 100644 --- a/drivers/net/wireless/ath/ath9k/xmit.c +++ b/drivers/net/wireless/ath/ath9k/xmit.c @@ -1764,7 +1764,10 @@ int ath_tx_start(struct ieee80211_hw *hw, struct sk_buff *skb, int frmlen = skb->len + FCS_LEN; int q; - txctl->an = (struct ath_node *)sta->drv_priv; + /* NOTE: sta can be NULL according to net/mac80211.h */ + if (sta) + txctl->an = (struct ath_node *)sta->drv_priv; + if (info->control.hw_key) frmlen += info->control.hw_key->icv_len; -- 1.7.2.3 ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] [PATCH] ath9k: Check for NULL sta in ath_tx_start
On Mon, Dec 6, 2010 at 9:13 PM, wrote: > From: Ben Greear > > It can be NULL according to docs, and logging showed it > to be NULL in practice. > > Signed-off-by: Ben Greear Does this fix an oops? If so can you explain and provide the trace and resubmit and cc stable in the commit log? Luis ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] [PATCH] ath9k: Check for NULL sta in ath_tx_start
On 12/06/2010 09:21 PM, Luis R. Rodriguez wrote: > On Mon, Dec 6, 2010 at 9:13 PM, wrote: >> From: Ben Greear >> >> It can be NULL according to docs, and logging showed it >> to be NULL in practice. >> >> Signed-off-by: Ben Greear > > Does this fix an oops? If so can you explain and provide the trace and > resubmit and cc stable in the commit log? I think it fixes the TID corruption I posted about earlier. It seems so obvious though, that I'm curious why no one else sees problems, and why I didn't see more crashes in my setup. (The paprd code appears to send with null STA, for instance, and my printks showed lots of NULL stas in my 16-sta test setup, though I don't think I'm using the paprd code path.) I'll test some more and re-post tomorrow if all goes well. Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] [PATCH] ath9k: Check for NULL sta in ath_tx_start
On Tue, Dec 07, 2010 at 11:06:24AM +0530, Ben Greear wrote: > On 12/06/2010 09:21 PM, Luis R. Rodriguez wrote: > > On Mon, Dec 6, 2010 at 9:13 PM, wrote: > >> From: Ben Greear > >> > >> It can be NULL according to docs, and logging showed it > >> to be NULL in practice. > >> > >> Signed-off-by: Ben Greear > > > > Does this fix an oops? If so can you explain and provide the trace and > > resubmit and cc stable in the commit log? > > I think it fixes the TID corruption I posted about earlier. It seems > so obvious though, that I'm curious why no one else sees problems, > and why I didn't see more crashes in my setup. > > (The paprd code appears to send with null STA, for instance, and my > printks showed lots of NULL stas in my 16-sta test setup, though I > don't think I'm using the paprd code path.) paprd is used only with >= AR9003. Vasanth ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] Is setting txpower in master mode on ath9k supposed to work?
> Which chipset are you using? On which cards? With the AR9280/AR9220, > I see the output power is pretty close to what is being set through iw > (measured with a spectrum analyzer). I've been selecting output > levels between 5 and 17dBm. I agree that with my adapter 2, things behave well from 5 to 17dBm. (Adapter 1 works well from 3 to 20, but with worse calibration.) However, there the fact that it goes to a high power level from 0 to 5 dBm is disturbing to me. At best it is very misleading, and at worst it could cause regulatory violations. Adapter 1 is a PCI-E adapter from Sparklan http://sparklan.com/product.php?func=view&prod_id=157 http://sparklan.com/product.php?func=view&prod_id=63 (I have one of each, and they behave identically.) 03:00.0 Network controller: Atheros Communications Inc. AR928X Wireless Network Adapter (PCI-Express) (rev 01) Subsystem: Lite-On Communications Inc Device 6512 Flags: bus master, fast devsel, latency 0, IRQ 16 Memory at fbaf (64-bit, non-prefetchable) [size=64K] Capabilities: Kernel driver in use: ath9k Kernel modules: ath9k Adapter 2 is an Ubiquiti SR71-A (http://ubnt.com/sr71a) 02:02.0 Network controller: Atheros Communications Inc. AR9160 802.11abgn Wireless PCI Adapter (rev 01) Subsystem: Device 0777:4082 Flags: bus master, 66MHz, medium devsel, latency 168, IRQ 16 Memory at fb9e (32-bit, non-prefetchable) [size=64K] Capabilities: Kernel driver in use: ath9k Kernel modules: ath9k ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] [PATCH] ath9k: Check for NULL sta in ath_tx_start
On 12/06/2010 11:42 PM, Vasanthakumar Thiagarajan wrote: > On Tue, Dec 07, 2010 at 11:06:24AM +0530, Ben Greear wrote: >> On 12/06/2010 09:21 PM, Luis R. Rodriguez wrote: >>> On Mon, Dec 6, 2010 at 9:13 PM, wrote: From: Ben Greear It can be NULL according to docs, and logging showed it to be NULL in practice. Signed-off-by: Ben Greear >>> >>> Does this fix an oops? If so can you explain and provide the trace and >>> resubmit and cc stable in the commit log? >> >> I think it fixes the TID corruption I posted about earlier. It seems >> so obvious though, that I'm curious why no one else sees problems, >> and why I didn't see more crashes in my setup. >> >> (The paprd code appears to send with null STA, for instance, and my >> printks showed lots of NULL stas in my 16-sta test setup, though I >> don't think I'm using the paprd code path.) > > paprd is used only with>= AR9003. Whoever coded it up hopefully had that hardware...so why didn't they see lots of crashes? Thanks, Ben > > Vasanth -- Ben Greear Candela Technologies Inc http://www.candelatech.com ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
