Unfortunately our units are in another state, so we're unable to make the electrical connections. If the UART is RS-232, we might be able to modify some locally - but it'll be a rather difficult challenge. Not to mention, we see a great deal of issues in the field, but can't duplicate them here.
On the firmware, I'm pulling down io_clean-2014.04.29 right now. I'm assuming this is what I should be using? Are there any other options for debugging aside from the UART? We're really in a bind and feel like the only work around is to setup a task to restart hostapd every hour. On Wed, Apr 30, 2014 at 11:27 AM, Oleksij Rempel <li...@rempel-privat.de> wrote: > 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 >> <aa...@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 <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 >>>> > > > -- > Regards, > Oleksij > _______________________________________________ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
