[ath9k-devel] Stable Version for ath9k_htc in AP Mode?

[Oleksij Rempel <linux@rempel-privat.de>]

Am 29.04.2014 08:19, schrieb Aaron Hamilton:
> On Mon, Apr 28, 2014 at 3:03 PM, Oleksij Rempel <linux@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 at lists.ath9k.org
>>> https://lists.ath9k.org/mailman/listinfo/ath9k-devel
>>>
>>
>>
>> --
>> Regards,
>> Oleksij
>>


-- 
Regards,
Oleksij

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 278 bytes
Desc: OpenPGP digital signature
Url : http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20140429/e2b15fe4/attachment.pgp