Build for WRT3200ACM (Discontinued)

Note that hash changed, so your link above is wrong.

Better: https://github.com/cybrnook/source/commit/338f1e6145db64549b112bca6274c474ffd0410e ?

Just to test, I am going to add one more # comment and upload to make sure I have a grip on making changes.

Okay, I think I got it (thanks to both of you guys): https://github.com/cybrnook/source/commit/0c47225f587a16bd89e9a1a360686d57c6e1037b

Easiest for others may be if you give the link to the commit log of that branch, because your commits should be there first and the address stays the same despite your changes / additional commits: https://github.com/cybrnook/source/commits/mambafan

Makes sense, and keeps it "universal" (no changing hash).

So now that I got it rolled up into my feature branch. Is there a way I can now pull it down to incorporate it into my LEDE builds, before issuing a PR against LEDE? (and without just manually hacking it in there)

two different paths I am using, feature branch/personal repo is:
/cybrnook/source

and my snapshots are
/lede/source

I already assume it will be a combination of something like "git pull" or "git clone" or even "git remote add..." against my feature branch. While being located in my /lede/source folder.

But issue the "right" commands and in the proper order are what I would need a helping hand on.

Well, several ways, depending a bit if you build from the same repo or not.

  • If you normally build from the same repo using master branch, you could build this time from "mambafan" branch.

  • In the same repo you could also "git cherry-pick" the commit to another branch. Very useful command.

  • If you use a separate repo (like you edited while wrote this message), you can either copy the few files separately or use git commands to generate patch(es) that you can easily use for transfer to your main repo:

    git checkout mambafan
    git format-patch 88ca6390ea (= hash of the last official commit before your new commits)

    Patch file 0001-mvebu-replace fan_ctrl-sh-with-daemon-for-mamba.patch will be generated to the directory where you are. One patch file will be generated for each commit after 88ca6390ea.
    copy that patch file to your build repo's root dir
    cd to that dir. ( apparently /lede/source )

    Apply the patch with

    patch -p 1 -i 0001-mvebu-replace fan_ctrl-sh-with-daemon-for-mamba.patch

    or

    git am 0001-mvebu-replace fan_ctrl-sh-with-daemon-for-mamba.patch

    (the git am command creates a commit out of it. Patch does not)

(you can also check success first with: patch --dry-run -p 1 -i 0001-... )

I have been building a community build for WNDR3700 for some 5 years now. Some feedback on my own workflow:

  • I use a clean separate repo for "send Github PRs" and another one from which I build the firmwares and where I do the actual changes first and test them.
  • I transfer files between then manually (by "cp" etc.) or using patches like I explained above. I haven't bothered to connect the two repos, as I don't always first transfer things to Github.
  • I do not usually generate commits before I really want to transfer things to Github and show them for others. Editing files normally in the local repo and compiling is quite possible without creating a commit.
    • If you do NOT generate a commit, "git diff HEAD" works and shows differences.
  • In connection of a firmware build I create full diffs of all my changes in main repo and all feed repos, for each build. Comparing them visually (with Winmerge in Windows, meld in Linux) to the diffs from the previous build makes it easy to spot unexpected changes in upstream sources, config etc.
  • I also publish the full diffs with each build, enabling others to copy by changes for their own build. See https://www.dropbox.com/sh/t52c02rm20y8x9p/AABNHwoEsyaRgC_KViBGhY5Da/lede-r2709-b7677f05d6-20161231?dl=0 for an example
  • I actually also provide a script that creates a copy of my whole build environment in about 5 minutes with all my patches applied :wink: I use it myself to transfer my own environment to a clean Ubuntu every few months.
    You can see that process in Build for WNDR3700v1/v2 / WNDR3800 (discontinued) - #2 by hnyman
2 Likes

Solid gold! I have to take off for a few. But I am going to have to sit a read this a few times.

It seems easy enough (too easy, so doomed for trouble) to just pull the path and copy it over. Who woulda thunk it!

Thanks so much for taking the time to spell it out. As well, you can always point others trying to learn to this thread, it has a wealth of knowledge in here people would pay good money for!

Another piece that has now saved me from my headache..... :slight_smile: I have been wonder why in the hell the patch was ignoring the permission that the "patch" itself is clearly labeling they need (as I have been using the patch -p 1 -i ...). git am worked much better........(I see the difference now when git and patch are used. git for building, patch for live)

Building now against latest lede and my patch applied.

GNU patch, in contrast to git am, ignores access permissions and just uses the default umask settings.

1 Like

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 ]---

Thoughts?

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:

changes:
adblock 2.1.1
Kernel update to 4.4.40

mamba users:
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 :slight_smile: , 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.

1 Like

I just altered the fan_control script to take advantage of a feature of boot() in initscripts. While not exactly great, it is one way to address the issue of only starting the daemon on mamba device.

1 Like

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. :stuck_out_tongue_closed_eyes:

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.

1 Like

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. :wink:

Keep up the good work. I see there is a new wireless driver been announced.

--bill