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

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

Am 30.04.2014 19:29, schrieb Aaron Hamilton:
> Ok, I was able to get backports-3.14-1 compiled by commenting out a
> line in compat.h. However, even 3.14-1 doesn't appear to include your
> patch for catching the fw panic. I'm patching these into 3.14-1 now
> and deploying.

> Also, we had another instance today of the wifi going down. There's
> nothing unusual in dmesg and nothing shows up in the logs.
> The router is currently in the locked state, so I'd be more than happy to do
> whatever debugging or prodding is needed. I can also provide SSH
> access if it helps.

More important is to get UART work. You can solder a wire directly to
the chip.

> Lastly is there a more stable source for accessing these updates
> (OpenWrt maybe)? It seems like the backports releases for 3.15 and up
> aren't meant to work on a 2.6.39.4 kernel (or have bugs preventing
> them from compiling at least).
> 
> On Tue, Apr 29, 2014 at 2:08 AM, Aaron Hamilton
> <aaron@logicdatasystems.net> wrote:
>> 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 <linux@rempel-privat.de> wrote:
>>> 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
>>>


-- 
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/20140430/199e7471/attachment.pgp