good to know! that was exactly my issue.
Interesting update in my logs this morning (running 1.47 build):
Sat Jan 7 10:01:13 2017 kern.err kernel: [124503.949317] ieee80211 phy0: create ba result error 1
Sat Jan 7 10:01:13 2017 kern.err kernel: [124503.962795] ieee80211 phy0: ampdu operation error code: -22
Sat Jan 7 10:01:14 2017 kern.warn kernel: [124504.395787] ------------[ cut here ]------------
Sat Jan 7 10:01:14 2017 kern.warn kernel: [124504.400563] WARNING: CPU: 1 PID: 8495 at compat-wireless-2016-10-08/net/mac80211/agg-tx.c:398 ___ieee80211_stop_tx_ba_session+0x1e8/0x1f8 mac80211
Sat Jan 7 10:01:14 2017 kern.warn kernel: [124504.414190] Modules linked in: pppoe ppp_async iptable_nat ip6table_nat pppox ppp_generic nf_nat_ipv6 nf_nat_ipv4 nf_conntrack_ipv6 nf_conntrack_ipv4 ipt_REJECT ipt_MASQUERADE xt_time xt_tcpudp xt_tcpmss xt_statistic xt_state xt_recent xt_nat xt_multiport xt_mark xt_mac xt_limit xt_length xt_hl xt_helper xt_ecn xt_dscp xt_conntrack xt_connmark xt_connlimit xt_connbytes xt_comment xt_TCPMSS xt_REDIRECT xt_LOG xt_HL xt_DSCP xt_CLASSIFY ums_usbat ums_sddr55 ums_sSat Jan 7 10:01:14 2017 kern.warn kernel: [124504.534483] CPU: 1 PID: 8495 Comm: kworker/u4:2 Not tainted 4.4.39 #0
Sat Jan 7 10:01:14 2017 kern.warn kernel: [124504.541035] Hardware name: Marvell Armada 380/385 (Device Tree)
Sat Jan 7 10:01:14 2017 kern.warn kernel: [124504.547088] Workqueue: phy0 ieee80211_iface_work [mac80211]
Sat Jan 7 10:01:14 2017 kern.warn kernel: [124504.552787]  (unwind_backtrace) from  (show_stack+0x10/0x14)
Sat Jan 7 10:01:14 2017 kern.warn kernel: [124504.560654]  (show_stack) from  (dump_stack+0x8c/0xa0)
Sat Jan 7 10:01:14 2017 kern.warn kernel: [124504.567995]  (dump_stack) from  (warn_slowpath_common+0x94/0xb0)
Sat Jan 7 10:01:14 2017 kern.warn kernel: [124504.576206]  (warn_slowpath_common) from  (warn_slowpath_null+0x1c/0x24)
Sat Jan 7 10:01:14 2017 kern.warn kernel: [124504.585133]  (warn_slowpath_null) from  (___ieee80211_stop_tx_ba_session+0x1e8/0x1f8 [mac80211])
Sat Jan 7 10:01:14 2017 kern.warn kernel: [124504.596182]  (___ieee80211_stop_tx_ba_session [mac80211]) from  (__ieee80211_stop_tx_ba_session+0x2c/0x40 [mac80211])
Sat Jan 7 10:01:14 2017 kern.warn kernel: [124504.609052]  (__ieee80211_stop_tx_ba_session [mac80211]) from  (ieee80211_iface_work+0x1c0/0x610 [mac80211])
Sat Jan 7 10:01:14 2017 kern.warn kernel: [124504.621124]  (ieee80211_iface_work [mac80211]) from  (process_one_work+0x228/0x3bc)
Sat Jan 7 10:01:14 2017 kern.warn kernel: [124504.630993]  (process_one_work) from  (worker_thread+0x310/0x504)
Sat Jan 7 10:01:14 2017 kern.warn kernel: [124504.639292]  (worker_thread) from  (kthread+0xf0/0xf8)
Sat Jan 7 10:01:14 2017 kern.warn kernel: [124504.646633]  (kthread) from  (ret_from_fork+0x14/0x3c)
Sat Jan 7 10:01:14 2017 kern.warn kernel: [124504.653983] ---[ end trace c6eb457c98851d3e ]---
Nope, can't say I have seen that before....... Outside of just the info in the log, are you experiencing any issues with any of your clients when it happens? If you are on the 3200ACM, this device has a handful of issues right now that are driver/firmware related, so you won't get too far with that one (yet).
Incremental update as to stay current with trunk, r2815 CAPRICORN R1.50:
Kernel update to 4.4.40
I am revisiting the drawing board on the fan approach. Between piecing together working fan daemons and trying to learn git, I am going to take a step back for the moment to really think what I am trying to accomplish with it.
So, in the meantime, I am reverting to the Kaloz script (though I of course had to modify it , adjusting the values and also added logging so you can see in your system log when the fan changes states, and to what speed).
When you first boot, the cronjob will be created for you.
So your removing the ability to stop the fan controller? (Although that seems to be a very rare case)
I dropped back to the fan_ctrl.sh script for now, and I am just writing out to rc.local in the events it's mamba (using the same function of "if mvebu_board_name". That works good for the script since I am relying back on cron, and I don't want to wait 5 min after boot for the fan to spin down. rc.local at least gives me one execution of the script off of first boot (within seconds, not minutes).
I will likely try to push something like this to begin with, since it's simple, and it satisfies my original itch of just removing the crontab from ALL mvebu devices, when only mamba needs the fan job.
However I want to come back to the daemon, but you mentioned you wanted to also alter the logic in your script, to remove and rearrange some things. I don't think you have done that yet? When you do, I would love to read your work and pick from it.
I saw you still have the STOP place holder in there of 80, but I don't think that will do anything for you unless you "enable" it, which will then symlink it into rc.d for starts/stop. On that, I don't think the start is serving you any purpose either, is it?
No, everything works as expected on mamba, start, stop, boot startup, spin-up on stop or kill(-15). That is the way the initscript stuff works with the START, STOP define levels from the init.d script. The short coming from my perspective is that on devices other than mamba, the stuff is still there, just not running; including the scripts, the links in rc.d.
Edit: Easy enough to just use vi on your mamba and replace with this to try it out.
Will check it out when I get back to the house. Thanks for the heads up my friend.
Oh, and I wouldn't be mad if you wanted to tune up that fan_monitor script that way you were talking about the other day. I know you said you have a couple things you wanted to adjust.
I need to do a new build anyways, I want to remove polarssl altogether since it's now deprecated.
EDIT: Just wanted to add, that I tested before by just dropped a script in init.d with bash shebang and rc.common header ( #!/bin/sh /etc/rc.common ) , but on boot it wasn't taking it by default and applying it, even though I had START/STOP defined. This is why I had to "enable" the script in init.d to have the system then create the symlinks to rc.d.
Thanks for this build! Working great on my WRT1200AC which has been running a buggy version of OpenWRT, kept crashing every now and then with torrenting, that is solved now! Just installed a few packages for my own use and enjoying it as I was. Great work.
Put up the complete change if you want to take a kick. Not really convinced as to this method being better than what is already there, so not sure I will submit a PR.
Running r2815 on my wrt1900acs v1. Running great, no issues. The LEDE builds of late have run so much better then my recent experience with DD-WRT that I am not even tempted to try them.
Also loaded it on my wrt1900ac v1. Fan control looks correct, back to way it was with the exception of the different temperature setting. I see you set the cpu temps lower then they were in standard build. I always figured if the settings were good enough for Linksys they were good enough for me.
Keep up the good work. I see there is a new wireless driver been announced.
Thanks for the feedback. For the fan values, I published a new build last night (though unannounced) that removes polarssl (most important), but I also tweaked the fan script some more and added another "threshold", so there is now an OFF, LOW, MID, HIGH. As well, you can adjust the values for these threshold as you wish. Just modify the script directly in /sbin/fan_ctrl.sh.
The driver is interesting as it seems to be directly related to ACS (WRT1900ACS?), if that's the case, I will publish some builds this afternoon with the driver up to date (which will include the previous 2 or 3 commits as well). The ACS is/was typically my primary router to begin with, i just am using the ACv1 for the moment as we have been poking at the fan controls. But I think @anomeome is making quick progress on that side.
Hi, I'm currently using davidc502's fw on my 1200AC, and would like to try your version as I use both PIA VPN and Adblocker. Can I just use the sysupgrade and perhaps not save settings?
My recommendations of course would be to not save settings in between different builds. (I enable things david doesn't, and vice versa).
As far as the upgrade goes, I would not be able to confidently answer that. I always keep linksys stock firmware on Partition 1, and flash custom firmware on Partition 2. So if you upgrade, you will be flashing whatever the "alt" partition is at that time. Leaving david's on one partition, and mine on the second.
With that said, I have a script in my builds that help you quickly bounce over the "alt" partition for flashing (intended to be your stock linksys parittion). It is in /usr/sbin/bootTaOther.sh
And since it's in *sbin" you can just type in it's name and hit "tab" to have it auto completed and hit enter.
Yes I saw that the driver seemed to be focused on the acs routers. Will be interesting to see what, if any, difference it makes. Will be watching for your build later today. Did see a build posted that is later then r2815, but going to wait on the new driver build.
I found the fan_monitor script was oscillating between 0-75% as I had simply set the fan off without adjusting the the MID temperatures. As I prefer to keep things cooler in support of longevity, I have gone back to keeping the fan at 50% and leaving the temperatures at a lower setting. I put a comment in the file to such and will leave it to others if they want the fan off to find the right MID temperatures. I know some will not want the massive extra power draw in getting those turbines spun up, and keeping them there, but I cannot hear that device at 50% sitting on my desk right beside me. Last change, add .patch to URL to get a patch. As far as building and installing this it WFM on mamba,rango in terms of correctly controlling the fan.
On the mwlwifi update for ACS, if someone with an ACS has tested maybe add a comment to the open PR. There is in all likelihood < 48 hrs. to code freeze for the first LEDE stable release.
To be quick, let me test the ACS first, then come back to the fan. If the driver is okay I would really like to be latest in the first stable.
new build: 2888 CAPRICORN R2.00
- mwlwifi driver 20170110
- removed "perl" packages (were a dependency of "lm-seneors-detect", also removed)
EDIT: Will post another build relatively soon. Commits against source are through the roof past couple days. Once it calms down, I will push another. But for those wanting to test the latest driver, here it is.....
Just installed your r2885 build with latest driver. Too soon to say if it looks good, but it did load on my wrt1900acs v1. The download took a very long time so am guessing you have a following that wants to try the latest. Will let you know, of course, if I have any issues.
One thing of note is on dslreports I now get a B for buffer bloat where before with the same settings I got all A's No biggie, but something has changed.