From mboxrd@z Thu Jan 1 00:00:00 1970 From: Oleksij Rempel Date: Wed, 30 Apr 2014 20:27:39 +0200 Subject: [ath9k-devel] Stable Version for ath9k_htc in AP Mode? In-Reply-To: References: <2BDAE2F2-CAF2-4C43-9A80-9408F1A1AEA5@logicdatasystems.net> <535ED04D.709@rempel-privat.de> <535F472E.8030302@rempel-privat.de> Message-ID: <5361409B.9010406@rempel-privat.de> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: ath9k-devel@lists.ath9k.org 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 > 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 wrote: >>> Am 29.04.2014 08:19, schrieb Aaron Hamilton: >>>> On Mon, Apr 28, 2014 at 3:03 PM, Oleksij Rempel 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