Typically there are only two clients at a time, sometimes three. We're using backports-3.12.8-1, which doesn't appear to have the patch. I've tried compiling both backports-3.14-1 and 3.15-rc1, but both fail for various reasons. Hopefully someone on the backports mailing list can help with that portion.
On Mon, Apr 28, 2014 at 11:31 PM, Oleksij Rempel <li...@rempel-privat.de> wrote: > Am 29.04.2014 08:19, schrieb Aaron Hamilton: >> On Mon, Apr 28, 2014 at 3:03 PM, Oleksij Rempel <li...@rempel-privat.de> >> wrote: >>> >>> Am 28.04.2014 22:43, schrieb Aaron Hamilton: >>>> Has anyone had success running an ath9k_htc module in AP mode for any >>>> length of time? If so, what versions of OS/hostapd/ath are you using? >>>> Would you mind sharing your magic config files for your kernel, backports, >>>> hostapd, etc? >>> >>> Usually i do benchmark tests and some hours of load tests. Some devices >>> fail on high load. Yesterday i was able to narrow down one of firmware >>> crashes, but with current fw and kernel, it will recover connection in >>> some seconds. So this problem is not nice, but not critical. >>> >>> If you are able to grub firmware log from uart port on the chip, or get >>> panic report from kernel, if you have patched kernel, then it will be >>> good start. >> >> Unfortunately our modules don't have a UART port accessible. When >> clients are no longer able to connect, I can't seem to find anything >> unusual in dmesg. The only thing of interest are log entries for "IEEE >> 802.11: deauthenticated due to local deauth request". Although >> sometimes there's no indicating or activity at all. > > How many clients do you have? we can't handle more then 8. There is no > enough RAM for more. > >> I'm deploying several units with debugfs enabled (wasn't there >> previously). Is there anything I should be looking for there? > > No. Check if you have "ath9k_htc: catch fw panic pattern" patch. > >>> >>> In any case most interesting changes are from this year, so don't use >>> old backports. >>> >>> If you have firmware crashes, i would suggest you todays FW source: >>> https://github.com/olerem/open-ath9k-htc-firmware/commits/io_clean >>> >>> the difference to other branches is that panic report should show >>> address of function which made ioread/write request >>> >>>> I'm desperate for stability as this problem has been ongoing for quite >>>> some time. We are using ar9710 chips in vehicle hotspots and the best >>>> we've been able to achieve is a few days of connectivity. Usually within >>>> hours all wifi clients loose their connection which can only be corrected >>>> with a hostapd restart (or power cycle). >>> >>> Are you sure you are using ar9710 with ath9k-htc? >>> >> >> Sorry, that's a typo. We're using AR9271 Rev 1 chipsets. Here's an >> image: http://www.zcom.com.tw/program1/big_pic/ZCN-722M.jpg >> >> I also neglected to mention that I've compiled the kernel without QoS >> support as that seems to make the problem worse. >> >>>> Here's our setup: >>>> - host: at91 ARM processor on 2.6.39.4 kernel >>>> - runtime power management and LED support removed from kernel (otherwise >>>> entire device reboots when load is put on wifi interface) >>>> - hostapd-2.0 >>>> - latest ath9k_htc firmware compiled from source (indicates v1.4 on boot) >>>> >>>> At this point I'm willing to try just about anything to get at least a >>>> week or more of ongoing stability. >>>> >>>> Thanks in advance! >>>> _______________________________________________ >>>> ath9k-devel mailing list >>>> ath9k-devel@lists.ath9k.org >>>> https://lists.ath9k.org/mailman/listinfo/ath9k-devel >>>> >>> >>> >>> -- >>> Regards, >>> Oleksij >>> > > > -- > Regards, > Oleksij > _______________________________________________ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
