[ath9k-devel] Questions about hardware and the ath9k driver
Hi, I'm currently working on a project that at some point needs service time measurements for DATA frames (the amount of time it takes for a frame to just get transmitted, from the moment it is popped off the outgoing queue by the hardware). Until now, I've been using ath5k-supported cards, but have trouble getting them work reliably in IBSS mode. So here come my questions. Since I've been able to modify the ath5k driver to gather service time measurements, I'd like to know whether it will be possible to adapt my changes to the ath9k driver. The changes rely on the ability for the driver to set the firmware to trigger a TX interrupt each time a frame is successfully transmitted or all the retransmissions failed. In madwifi, for example, that TX interrupt was initially triggered only once every several frames, and descriptors were cleaned several at a time, at each interrupt. Is the IBSS well supported in ath9k? I understand I won't be able to use it with 802.11n rates, but does it at least support well the 802.11a, b and g rates? Are there any USB dongles available on the market and well supported by ath9k? If that were the case, it would be much more convenient than to replace my current mini-PCI cards. In the case of mini-PCI cards, is it possible to put one in replacement of a 802.11g card? I'm affraid 802.11n cards would have three antenna connectors, whereas the g cards have only two. Finally, do you recommend any specific card/dongle that is known for working well in IBSS mode? Thanks for your help. Ignacy -- Everything is more fun naked except cooking with grease. ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
[ath9k-devel] ath9k_htc: Target is unresponsive
Hi everyone, This is an old issue, about which it seems the first posts date back to 2009. With the latest possible version of the firmware for AR9271 and the latest possible wireless drivers, the issue is still there. Whether this is still the exact same problem every time remains to be checked, but it is annoying enough to deserve some consideration. The problem is that the driver can't talk to the device if the following conditions are met: - The system cold boots with the USB dongle inserted or the USB dongle is inserted on a running system. - The interface is *not* brought up. - The system (warm) reboots. Then the driver complains about the target being unresponsive after uploading the firmware. Apparently the only way to make it work again is to unplug and then plug the USB dongle back, physically. It seems that if the USB port is not powered down during reboot (which happens with at least two different setups that I've tested it with), the device is left in a broken state. I would gladly help in tracing down this bug if only I knew where to start. Thanks for any suggestion. Ignacy -- A person is shit's way of making more shit. -- S. Barnett, anthropologist. ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] ath9k_htc: Target is unresponsive
On Wed, May 15, 2013 at 06:11:49PM +0200, thus spake Eugene Krasnikov: > there is a function in driver "ath9k_htc_reset" > http://lxr.free-electrons.com/source/drivers/net/wireless/ath/ath9k/htc_drv_main.c#L189 > but not sure that is what you are looking for. >From the issue report about watchdog problems, I gather that the device is supposed to be prepared for reception of the firmware code from the driver. This normally happens when the device boots up and passes the first stage of the bootloader. I suppose (I'm really totally guessing) that the driver somehow doesn't do something to prepare the device for firmware upload if the device is already past stage 2. I would love to have the UART pins connected to some terminal, but I don't have the soldering tools for such small-scale work... -- A person is shit's way of making more shit. -- S. Barnett, anthropologist. ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] ath9k_htc: Target is unresponsive
On Thu, May 16, 2013 at 03:27:15PM +0200, thus spake Oleksij Rempel: > Am 15.05.2013 15:42, schrieb Ignacy Gawedzki: > >Hi everyone, > > > >This is an old issue, about which it seems the first posts date back to 2009. > >With the latest possible version of the firmware for AR9271 and the latest > >possible wireless drivers, the issue is still there. Whether this is still > >the exact same problem every time remains to be checked, but it is annoying > >enough to deserve some consideration. > > > >The problem is that the driver can't talk to the device if the following > >conditions are met: > > > > - The system cold boots with the USB dongle inserted or the USB dongle is > >inserted on a running system. > > > > - The interface is *not* brought up. > > > > - The system (warm) reboots. > > > >Then the driver complains about the target being unresponsive after uploading > >the firmware. Apparently the only way to make it work again is to unplug and > >then plug the USB dongle back, physically. It seems that if the USB port is > >not powered down during reboot (which happens with at least two different > >setups that I've tested it with), the device is left in a broken state. > > > >I would gladly help in tracing down this bug if only I knew where to start. > > > >Thanks for any suggestion. > > Hi Ignacy, > > i can't reproduce this issue on my system. I tested it with 4 > different ath9_htc adapter. Without luck. Without luck, but it seems you're the lucky one anyway. =) > Please provide as match > information as possible: > - Usb host controller Tested both on Raspberry Pi and on Dell XPS 13. The latter uses Intel EHCI, 8086:1c2d and Fresco Logic 1b73:1009, I don't know which one is used exactly. > - Adapter manufacture and version, or even better add it to the > wiki, and upload some images: > http://wikidevi.com/wiki/Main_Page TP-Link TL-WN722NC, exactly as the one on the wiki. > - your kernel version Tested with 3.5.0 on XPS and 3.6.11, 3.8.12 and 3.9.2 on RPi (using a customized buildroot, but I can provide the .config if needed). > I assume it is not firmware. May be there are some issue with boot > loader on adapter. Are you sure that UART pins are not soldered? I opened the dongle, managed to solder the metal shield off and the pins weren't used (all four 48-51, among others). > Current ath9k_htc do not have mechanism to reset an adapter. I will > start to work on it after some other issues are done. Is it physically possible? > PS: please find some way to enable uart, at least TX pin. I tried to solder the TX pin, but it's really too tiny. I don't have an iron so small as to be able to do it, sorry. I would really love to have an UART connection, but that's just beyond my abilities. BTW, it would really be great to have a way to send debug message up the USB link, just as with carl9170. Thanks for your help anyway, I hope we'll find a way to make that work. -- Sex on TV doesn't hurtunless you fall off. ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] ath9k_htc: Target is unresponsive
On Thu, May 16, 2013 at 07:46:56PM +0200, thus spake Oleksij Rempel: > Am 16.05.2013 19:20, schrieb Ignacy Gawedzki: > >TP-Link TL-WN722NC, exactly as the one on the wiki. > > That is interesting. I have got today TL-WN722N, but i still can't > reproduce this issue. Are you sure that not any subsystem ups the interface before you have any chance to warm reboot? Or that you don't have a hub that cuts power to devices on warm reboot? > >I tried to solder the TX pin, but it's really too tiny. I don't have an iron > >so small as to be able to do it, sorry. I would really love to have an UART > >connection, but that's just beyond my abilities. BTW, it would really be > >great to have a way to send debug message up the USB link, just as with > >carl9170. > > That make no sense. Debug message i need, are from boot loader. > There is no way, that boot loader can send messages over usb. Or if > firmwre will crash, it wont send any thing too. I understand. > So what do we have: > - TL-WN722N is working. Or your model is different, or it is broken one. I happen to have 8 of them, bought at different times and all exhibit the problem. > - Did you checked the cable? I usually plug the device directly to the USB port, but I also happen to use the cradle (supplied with the WN722NC version) that has a cable, when I need two wireless interfaces on the RPi (both of them don't fit at once directly on the ports). > - usb host controller? I'll try on yet another one and will tell you the results. > - other options? Hmmm... :/ -- -= Best Viewed Using [INLINE] =- ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] ath9k_htc: Target is unresponsive
On Thu, May 16, 2013 at 08:50:30PM +0200, thus spake Ignacy Gawedzki:
> I'll try on yet another one and will tell you the results.
Just tried on ICH7, same thing. The easiest way to reproduce the bug is to
boot into single user mode ("recovery mode" on Ubuntu), in order to prevent
any NetworkManager or udev from interfering. Then, without any attempt to up
the interface, reboot the system by typing "reboot" in a root shell.
--
"The whole problem with the world is that fools and fanatics are
always so certain of themselves, and wiser people so full of doubts."
- Bertrand Russell
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] ath9k_htc: Target is unresponsive
On Fri, May 17, 2013 at 10:07:00AM +0200, thus spake Oleksij Rempel: > OK, now i was able to reproduce it on ar9271. Ah, good, but what did you do wrong previously then? > In attachment is the log i grubbed form adapter. > Lines starting with # are my comments At least we can already diagnose a problem with A_PRINTF. :/ Do these logs speak to anyone? -- /* This is not a comment */ ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] ath9k_htc: Target is unresponsive
On Fri, May 17, 2013 at 11:33:53AM +0200, thus spake Eugene Krasnikov: > Did anybody tried to force the usb to go to suspend? If something like > this "echo suspend | sudo tee /sys/bus/usb/devices/usb3/power/level" > will help to reproduce this issue? This way of forcing suspend is apparently deprecated and doesn't work in my case. I tried to set power/control to auto, but it has no apparent effect on anything. :( -- I drive too fast to worry about cholesterol. ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] ath9k_htc: Target is unresponsive
On Fri, May 17, 2013 at 12:30:34PM +0200, thus spake Ignacy Gawedzki: > On Fri, May 17, 2013 at 11:33:53AM +0200, thus spake Eugene Krasnikov: > > Did anybody tried to force the usb to go to suspend? If something like > > this "echo suspend | sudo tee /sys/bus/usb/devices/usb3/power/level" > > will help to reproduce this issue? > > This way of forcing suspend is apparently deprecated and doesn't work in my > case. I tried to set power/control to auto, but it has no apparent effect on > anything. :( Okay, I did manage to make it fail. In single-user mode (to prevent any daemon from interfering), I plugged the dongle, set power/control to "auto" and after a few seconds unloaded/reloaded the ath9k_htc module. This made the target unresponsive. If I do the same without setting power/control to "auto" (it is "on" by default), then unloading/reloading the module doesn't make the device unresponsive. BTW, Oleksij, just out of curiosity, how did you manage to solder those UART pins? -- I have not lost my mind, it's backed up on disk somewhere. ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] ath9k_htc: Target is unresponsive
On Fri, May 17, 2013 at 12:48:53PM +0200, thus spake Oleksij Rempel: > Here an example of soldered pins, it is ar7010 device. I attached > here jtag pins. > https://plus.google.com/u/0/102032716864870215256/posts/hZoEq8bo3zk Wow, my soldering iron has too broad a tip for that precision work. :/ > here is a workaround for this issue, please test it: > https://github.com/olerem/open-ath9k-htc-firmware/commits/suspend It seems to work just right on the PC. I'll test on the RPi and let you know. Big thanks! -- :wq! ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] ath9k_htc: Target is unresponsive
On Fri, May 17, 2013 at 01:22:43PM +0200, thus spake Ignacy Gawedzki: > On Fri, May 17, 2013 at 12:48:53PM +0200, thus spake Oleksij Rempel: > > Here an example of soldered pins, it is ar7010 device. I attached > > here jtag pins. > > https://plus.google.com/u/0/102032716864870215256/posts/hZoEq8bo3zk > > Wow, my soldering iron has too broad a tip for that precision work. :/ > > > here is a workaround for this issue, please test it: > > https://github.com/olerem/open-ath9k-htc-firmware/commits/suspend > > It seems to work just right on the PC. I'll test on the RPi and let you know. Works on the RPi as well! Are there any implications for this being a workaround and not a proper fix? -- Sex on TV doesn't hurtunless you fall off. ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
[ath9k-devel] ath9k_htc: station unable to authenticate
Hi, After a lot of git-bisecting and other testing, it appears that commit 382a103b2b528a3085cde4ac56fc69d92a828b72 (linux-stable.git) is the culprit. To reproduce the problem, use backports-20130607, and the ath9k defconfig (with no change otherwise). The station is unable to authenticate with WPA2 to the AP. Interestingly enough, if a monitor vif is created and upped beforehand, the authentication succeeds. After reverting the commit, authentication succeeds very quickly (without the need to up a monitor vif), just as expected. Note that I have kernel 3.8.0 (as per Ubuntu 13.04) and that original ath9k_htc driver works as expected. This has been also tested on Debian with driver from original kernel 3.9 (i.e. without backports). For the moment I can live with the commit reverted, but I suppose it's been there to fix something else, so this should probably be looked into by someone more knowledgeable than me. Ignacy -- A person is shit's way of making more shit. -- S. Barnett, anthropologist. -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] ath9k_htc: station unable to authenticate
On Wed, Jun 19, 2013 at 03:38:47PM +0200, thus spake Oleksij Rempel: > hm.. looks like this code depends on power_save. is it correct? > > Ignacy, > > can you please take a look if power_save mode is enabled by you. > > iw dev wlan0 get power_save > > if yes. Try to disable it. Although I have been building with CFG80211_DEFAULT_PS=y, the iw get power_save command tells me it's off. > I think last week power_save was set to disabled by default. There > are too many bugs right now. I'll test without CFG80211_DEFAULT_PS, just to be sure. Thanks for the hint. -- NO CARRIER ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] ath9k_htc: station unable to authenticate
On Wed, Jun 19, 2013 at 05:08:12PM +0200, thus spake Oleksij Rempel: > Ignacy wrote: > >The station is unable to authenticate with WPA2 to the AP. Interestingly > >enough, if a monitor vif is created and upped beforehand, the authentication > >succeeds. > > which looks more like power management issue. If monitore mode is > enabled, no power sawing is done. But i use CFG80211_DEFAULT_PS=y on > my system too and didn't had this issue. Even power_save=on is > working. What else is different? > > Ignacy, Is it RPi + TL-WN722NC? Yes, absolutely, but it happens on a Dell XPS 13" as well (Ubuntu 13.04). -- P.S. All information contained in the above letter is false, for reasons of military security. ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] ath9k_htc: station unable to authenticate
On Wed, Jun 19, 2013 at 07:59:39PM +0200, thus spake Ignacy Gawedzki: > On Wed, Jun 19, 2013 at 05:08:12PM +0200, thus spake Oleksij Rempel: > > Ignacy, Is it RPi + TL-WN722NC? > > Yes, absolutely, but it happens on a Dell XPS 13" as well (Ubuntu 13.04). BTW, removing CFG80211_DEFAULT_PS doesn't make any difference. -- Everything is more fun naked except cooking with grease. ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] ath9k_htc: station unable to authenticate
On Wed, Jun 19, 2013 at 08:37:42PM +0200, thus spake Oleksij Rempel: > Can you please tell more about your access point: > - hardware > - firmware > - configuration > - "iw dev wlan0 scan dump" I tested the thing with at least three different APs: - Netgear DG834Gv4 with latest firmware. - Netgear DG834Gv5 (don't know which firmware and can't check at this time). - hostapd (can't say which version at this time either) with the same ath9k_htc. All APs are configured for WPA2-PSK. The scan dump for the first AP: BSS 00:1e:2a:ed:35:70 (on wlan7) TSF: 163623606 usec (0d, 00:02:43) freq: 2412 beacon interval: 100 capability: ESS Privacy ShortSlotTime (0x0411) signal: -43.00 dBm last seen: 24 ms ago Information elements from Probe Response frame: SSID: Wolfnet Supported rates: 1.0* 2.0* 5.5* 11.0* 18.0 24.0 36.0 54.0 DS Parameter set: channel 1 ERP: Barker_Preamble_Mode RSN: * Version: 1 * Group cipher: CCMP * Pairwise ciphers: CCMP * Authentication suites: PSK * Capabilities: 16-PTKSA-RC (0x000c) Extended supported rates: 6.0 9.0 12.0 48.0 WMM: * Parameter version 1 * u-APSD * BE: CW 15-1023, AIFSN 3 * BK: CW 15-1023, AIFSN 7 * VI: CW 7-15, AIFSN 2, TXOP 3008 usec * VO: CW 3-7, AIFSN 2, TXOP 1504 usec -- Save the whales. Feed the hungry. Free the mallocs. ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] ath9k_htc: station unable to authenticate
On Wed, Jun 19, 2013 at 11:39:55AM -0700, thus spake Ben Greear: > Does the ath9k_htc do it's own rate control, perhaps modelled on > ath9k_rate_control algorithm? Do you mean ATH9K_LEGACY_RATE_CONTROL ? > If so, that could be the problem...it has issues with associating when > network conditions are poor... Frankly, I doubt this is the case. With so many different setups, and the AP is like one meter away from the station right now. -- The groove will take you through times without money much better than money will take you through times without groove. ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] ath9k_htc: station unable to authenticate
On Thu, Jun 20, 2013 at 07:33:30AM +0200, thus spake Oleksij Rempel: > Am 19.06.2013 21:33, schrieb Ignacy Gawedzki: > >I tested the thing with at least three different APs: > > > > - Netgear DG834Gv4 with latest firmware. > > this one is BG with Broadcom BCM4318. Is here original firmware or openwrt? Original firmware, since OpenWRT doesn't support the ADSL chip. > > - Netgear DG834Gv5 (don't know which firmware and can't check at this > > time). > > this is BG with Conexant CX94610 > > > - hostapd (can't say which version at this time either) with the same > > ath9k_htc. > > this one is actually BGN, did you configured it for N? Can you > please provide your hostapd.conf. I'll manage to get the configuration as soon as possible. It seems the association problem went away since I patched the drivers on the AP too, so "unpatching" the drivers on the station is not enough to reproduce the problem. I'll unpatch the drivers on the AP and re-run the test. > Do you have problems on all 3 configurations? On both Netgears for sure. For hostapd I'll confirm that in a little while. > Can you please test it > with some N (HT) capable AP. But please, not with N-draft certified > AP. Is ath9k_htc N-capable? -- I used to have a sig, but I've stopped smoking now. ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] ath9k_htc: station unable to authenticate
On Thu, Jun 20, 2013 at 12:39:29PM +0530, thus spake Sujith Manoharan: > Ignacy Gawedzki wrote: > > After reverting the commit, authentication succeeds very quickly (without > > the > > need to up a monitor vif), just as expected. > > > > Note that I have kernel 3.8.0 (as per Ubuntu 13.04) and that original > > ath9k_htc driver works as expected. This has been also tested on Debian > > with > > driver from original kernel 3.9 (i.e. without backports). > > > > For the moment I can live with the commit reverted, but I suppose it's been > > there to fix something else, so this should probably be looked into by > > someone > > more knowledgeable than me. > > Can you test if this patch helps (without reverting the mac80211 commit) ? It works indeed, at least with the DG834Gv4. > > diff --git a/drivers/net/wireless/ath/ath9k/htc_drv_main.c > b/drivers/net/wireless/ath/ath9k/htc_drv_main.c > index eaa94fe..fba6ea7 100644 > --- a/drivers/net/wireless/ath/ath9k/htc_drv_main.c > +++ b/drivers/net/wireless/ath/ath9k/htc_drv_main.c > @@ -1183,7 +1183,7 @@ static int ath9k_htc_config(struct ieee80211_hw *hw, > u32 changed) > mutex_lock(&priv->htc_pm_lock); > > priv->ps_idle = !!(conf->flags & IEEE80211_CONF_IDLE); > - if (priv->ps_idle) > + if (!priv->ps_idle) > chip_reset = true; > > mutex_unlock(&priv->htc_pm_lock); > > > Sujith > -- "The whole problem with the world is that fools and fanatics are always so certain of themselves, and wiser people so full of doubts." - Bertrand Russell ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
