Am 30.04.2014 20:59, schrieb Aaron Hamilton: > 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.
It is TTL level, 3,3 Volt. > Not > to mention, we see a great deal of issues in the field, but can't > duplicate them here. Did you tried to grab hostpad log to so what kind of connections do you have? What is your hostapd config? > On the firmware, I'm pulling down io_clean-2014.04.29 right now. I'm > assuming this is what I should be using? You can use it, but these changes should make sense only if you can get oops log from firmware. Or at least FW panic report from dmesg. Theoretically this change set should not affect stability. > 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. Hmm.. restarting hostpad should not affect firmware. Is it really working for you? > 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. -- Regards, Oleksij
signature.asc
Description: OpenPGP digital signature
_______________________________________________ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
