OpenWrt Forum Archive

Topic: davidc502 1900ac 3200acm builds

The content of this topic has been archived between 26 Feb 2018 and 7 May 2018. Unfortunately there are posts – most likely complete pages – missing.

Rango (WRT3200acm) with latest 12/27 build still very flaky wifi sad

log full of
ieee80211 phy(0|1): staid # deleted
(not sure if related to instability of wifi)

PhanLord wrote:

Rango (WRT3200acm) with latest 12/27 build still very flaky wifi sad

log full of
ieee80211 phy(0|1): staid # deleted
(not sure if related to instability of wifi)

Marvel driver issue (https://community.linksys.com/t5/Wirele … p/1246764/)

WRT1900ACS , Lede SNAPSHOT r5621-1064e76e4e


Dear David,
iIt lacks again "transmission-*" packages. Only "luci-app-transmission" is present

Please, fix it.

I know that you are not agree about running transmission into router, but this is mandatory for me.

Thanks.

@beginner67890

Thank you very much for your time writing back and trying to help. To sum it up: My router is running now since 18 days, no reboot. The last dmesg bug was the same I wrote before about:

[Dec22 15:53] swap_free: Bad swap file entry 00000c00
[  +0.005019] BUG: Bad page map in process sleep  pte:00060000 pmd:1bd74831

I deactivated the script the same day, which has the sleep 20 command in it, and since then, no bug report anymore in dmesg, no reboot/crash. So I totally believe it is related. Beause Three times before, when I looked into dmesg I saw this too, and then randome time later, the router rebooted.

I totally believe, that it is connected to the same problem the 1900v1 has with CPUFREQ and CPUIDLE. Maybe the sleep command triggers it somehow, and because no one else (than me) uses a script here, which has a sleep command in, no one sees those reboots.

I politely asked David to include the patch too for the WRT1200AC but he just laughed at me with some rude comment. So I have to build my own build at some point I guess, which I havent tied so far, because I thought the WRT1200AC is not officially supported by the native Lede source, and David had implemented patches in his build inviroment, which he does not make public, even I also asked politely for that.

It seems if you just use the router as a potato (not much cpu and ram load), it is "stable". So this seems why no one else notices these issues. But I am dependent on bash scripts which uses a sleep, so I want to see this be fixed.

My other theory is, that the RAM isnt clocked correctl, whatever reason for, maybe a false config file somewhere in the code. This would lead to a maybe slightly overclocked RAM, leading to memory corruptions and reboots. The sleep may trigger this way sooner than it normally would happen, maybe because every 20 seconds, a new random part of RAM is filled and released, which normally wouldnt happen. Opening Luci may also trigger this, or other RAM related programs, running on the router.

@meffovic
I think "sleep x" is used in some bash scripts of Lede per default too, I dont know which one though, mostly some watchdog scripts.

ambrosa wrote:

WRT1900ACS , Lede SNAPSHOT r5621-1064e76e4e


Dear David,
iIt lacks again "transmission-*" packages. Only "luci-app-transmission" is present

Please, fix it.

I know that you are not agree about running transmission into router, but this is mandatory for me.

Thanks.

I think David has already said the transmission packages don't build correctly on kernel 4.9.
The error is upstream and until transmission is fixed by the authors, there isn't much David can do.
If transmission is important for you, you can change the feed to point to the kernel 4.4 version used for the WRT1900AC v1 and they will install correctly, as mentioned earlier in this thread.

DNSCrypt Repo was deleted, anyone know why?

Transmission package fails to build because it's missing the Makefile.in.in under /po.

@davidc502

Rather than blaming on the maintainer, check the build log, find the error and fix it or provide exact info why a certain package fails to build.

nitroshift

What about multi SSID?

I only can  use one SSID at 2.4 (never test on 5).
Is very usefull for guest.

Thanks

My 3200acm@r5422 rebooted randomly after 8 days and than again rebooted after 2 days.
The free memory also seems to run out quickly again.
I've also noticed that the singal quality for 5ghz is quite strange...
My Samsung S7@80MHz is only 4-5meters away from the router and Signal quality is -83dBm (-83 / -98 dBm).
And my Samsung Tablet@40MHz right next to the router has only a singal Quality of -51dBm... Is my wifi module faulty ?

driver version: 10.3.4.0-20170810
firmware version: 0x09030201

So Im looking to upgrade to a newer build but reading here kinda holds me back.
What build can you recommend ?
I need a stable router and i dont run anything fancy.
Just a few vlans, SQM-QoS, DNSCrypt-Proxy and Adblock

Any advice how to perform a clean flash ?
Should i go back to the Linksys partition and flash from there ?

Hi David
Belated Happy New Year to you!
I finally got round to testing the latest 4.9 version on my WRT1900 v1. I couldnt update packages without disabling the sig verification check in opkg.conf.
I'll report back on the reboot situation when I have some evidence.!

GaNi wrote:

DNSCrypt Repo was deleted, anyone know why?

Alas, seems the author dropped this project. Discussions found here:
https://www.reddit.com/r/privacy/commen … _dnscrypt/

And author's comment:
https://twitter.com/jedisct1/status/928942292202860544

Community supported one still exists, but no features will be added in the future. You can fetch the latest resolvers list from them, though.
https://github.com/dyne/dnscrypt-proxy

Seems that auto-refresh address (download.dnscrypt.org) of the resolver's list is hardcoded. You can create a cron job to download the resolver list from the new location.

(Last edited by raidenii on 8 Jan 2018, 04:55)

Zorr0x wrote:

The free memory also seems to run out quickly again.

It's OK, it mostly used for cache (check in collectd).
If you are (like me) don't like it so much, add this to Crontab:

0 0 * * * /bin/sync; echo 3 > /proc/sys/vm/drop_caches
raidenii wrote:

Seems that auto-refresh address (download.dnscrypt.org) of the resolver's list is hardcoded. You can create a cron job to download the resolver list from the new location.

I have an older version of davidc502 REBOOT on my WRT1200ACv1. I was able to mod the dnscrypt-proxy lookup of the dnscrypt-resolvers.csv to fetch from the new location. Edit as shown here:

#mcedit /usr/lib/lua/luci/model/cbi/dnscrypt-proxy/overview_tab.lua

local url="https://raw.githubusercontent.com/dyne/dnscrypt-proxy/master/dnscrypt-resolvers.csv"

Be sure to REFRESH LIST in luci Services/Dnscrypt-proxy tab.

EDIT: Maybe need to

/etc/init.d/dnscrypt-proxy restart

(Last edited by beginner67890 on 8 Jan 2018, 19:09)

beginner67890 wrote:
raidenii wrote:

Seems that auto-refresh address (download.dnscrypt.org) of the resolver's list is hardcoded. You can create a cron job to download the resolver list from the new location.

I have an older version of davidc502 REBOOT on my WRT1200ACv1. I was able to mod the dnscrypt-proxy lookup of the dnscrypt-resolvers.csv to fetch from the new location. Edit as shown here:

#mcedit /usr/lib/lua/luci/model/cbi/dnscrypt-proxy/overview_tab.lua

local url="https://raw.githubusercontent.com/dyne/dnscrypt-proxy/master/dnscrypt-resolvers.csv"

Be sure to REFRESH LIST in luci Services/Dnscrypt-proxy tab.

Thanks. I use rawgit to fetch the list.

WRT1900ACS , Lede SNAPSHOT r5621-1064e76e4e

It was running fine for about 4 days. Tomorrow a strange problem:
- ethernet connections ok
- wifi (2.4 GHZ) link connection ok but no internet access

I open system log and it's full of:

Wed Jan 10 07:44:22 2018 daemon.info dnscrypt-proxy[2222]: dnscrypt-proxy Refetching server certificates
Wed Jan 10 07:44:22 2018 daemon.info dnscrypt-proxy[2222]: dnscrypt-proxy Server certificate with serial #1496061161 received
Wed Jan 10 07:44:22 2018 daemon.info dnscrypt-proxy[2222]: dnscrypt-proxy This certificate is valid
Wed Jan 10 07:44:22 2018 daemon.info dnscrypt-proxy[2222]: dnscrypt-proxy Chosen certificate #1496061161 is valid from [2017-05-29] to [2027-05-27]
Wed Jan 10 07:44:22 2018 daemon.info dnscrypt-proxy[2222]: dnscrypt-proxy The key rotation period for this server may exceed the recommended value. This is bad for forward secrecy.
Wed Jan 10 07:44:22 2018 daemon.info dnscrypt-proxy[2222]: dnscrypt-proxy Server key fingerprint is E737:6400:D646:0720:7D9D:29AB:A4C9:070C:4546:CEF7:0CFE:D62F:41E9:FEAA:C58F:6376
Wed Jan 10 07:44:34 2018 daemon.info hostapd: wlan1: STA 84:c7:ea:20:1f:29 IEEE 802.11: authenticated
Wed Jan 10 07:44:34 2018 daemon.info hostapd: wlan1: STA 84:c7:ea:20:1f:29 IEEE 802.11: associated (aid 1)
Wed Jan 10 07:44:34 2018 daemon.notice hostapd: wlan1: AP-STA-CONNECTED 84:c7:ea:20:1f:29
Wed Jan 10 07:44:34 2018 daemon.info hostapd: wlan1: STA 84:c7:ea:20:1f:29 WPA: pairwise key handshake completed (RSN)
Wed Jan 10 07:44:34 2018 daemon.info dnsmasq-dhcp[4087]: DHCPDISCOVER(br-lan) 84:c7:ea:20:1f:29
Wed Jan 10 07:44:34 2018 daemon.info dnsmasq-dhcp[4087]: DHCPOFFER(br-lan) 192.168.1.85 84:c7:ea:20:1f:29
Wed Jan 10 07:44:34 2018 daemon.info dnsmasq-dhcp[4087]: DHCPREQUEST(br-lan) 192.168.1.85 84:c7:ea:20:1f:29
Wed Jan 10 07:44:34 2018 daemon.info dnsmasq-dhcp[4087]: DHCPACK(br-lan) 192.168.1.85 84:c7:ea:20:1f:29 XperiaXZ
Wed Jan 10 07:44:37 2018 daemon.notice hostapd: wlan1: AP-STA-DISCONNECTED 84:c7:ea:20:1f:29
Wed Jan 10 07:44:37 2018 daemon.info hostapd: wlan1: STA 84:c7:ea:20:1f:29 IEEE 802.11: disassociated
Wed Jan 10 07:44:38 2018 daemon.info hostapd: wlan1: STA 84:c7:ea:20:1f:29 IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)
Wed Jan 10 07:44:42 2018 daemon.info hostapd: wlan1: STA 84:c7:ea:20:1f:29 IEEE 802.11: authenticated
Wed Jan 10 07:44:42 2018 daemon.info hostapd: wlan1: STA 84:c7:ea:20:1f:29 IEEE 802.11: associated (aid 1)
Wed Jan 10 07:44:42 2018 daemon.notice hostapd: wlan1: AP-STA-CONNECTED 84:c7:ea:20:1f:29
Wed Jan 10 07:44:42 2018 daemon.info hostapd: wlan1: STA 84:c7:ea:20:1f:29 WPA: pairwise key handshake completed (RSN)
Wed Jan 10 07:44:42 2018 daemon.info dnsmasq-dhcp[4087]: DHCPDISCOVER(br-lan) 84:c7:ea:20:1f:29
Wed Jan 10 07:44:42 2018 daemon.info dnsmasq-dhcp[4087]: DHCPOFFER(br-lan) 192.168.1.85 84:c7:ea:20:1f:29
Wed Jan 10 07:44:42 2018 daemon.info dnsmasq-dhcp[4087]: DHCPREQUEST(br-lan) 192.168.1.85 84:c7:ea:20:1f:29
Wed Jan 10 07:44:42 2018 daemon.info dnsmasq-dhcp[4087]: DHCPACK(br-lan) 192.168.1.85 84:c7:ea:20:1f:29 XperiaXZ
Wed Jan 10 07:44:45 2018 daemon.notice hostapd: wlan1: AP-STA-DISCONNECTED 84:c7:ea:20:1f:29
Wed Jan 10 07:44:45 2018 daemon.info hostapd: wlan1: STA 84:c7:ea:20:1f:29 IEEE 802.11: disassociated
Wed Jan 10 07:44:46 2018 daemon.info hostapd: wlan1: STA 84:c7:ea:20:1f:29 IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)
Wed Jan 10 07:44:59 2018 daemon.info hostapd: wlan1: STA 84:c7:ea:20:1f:29 IEEE 802.11: authenticated
Wed Jan 10 07:44:59 2018 daemon.info hostapd: wlan1: STA 84:c7:ea:20:1f:29 IEEE 802.11: associated (aid 1)
Wed Jan 10 07:44:59 2018 daemon.notice hostapd: wlan1: AP-STA-CONNECTED 84:c7:ea:20:1f:29
Wed Jan 10 07:44:59 2018 daemon.info hostapd: wlan1: STA 84:c7:ea:20:1f:29 WPA: pairwise key handshake completed (RSN)
Wed Jan 10 07:45:00 2018 daemon.info dnsmasq-dhcp[4087]: DHCPDISCOVER(br-lan) 84:c7:ea:20:1f:29
Wed Jan 10 07:45:00 2018 daemon.info dnsmasq-dhcp[4087]: DHCPOFFER(br-lan) 192.168.1.85 84:c7:ea:20:1f:29
Wed Jan 10 07:45:00 2018 daemon.info dnsmasq-dhcp[4087]: DHCPREQUEST(br-lan) 192.168.1.85 84:c7:ea:20:1f:29
Wed Jan 10 07:45:00 2018 daemon.info dnsmasq-dhcp[4087]: DHCPACK(br-lan) 192.168.1.85 84:c7:ea:20:1f:29 XperiaXZ
Wed Jan 10 07:45:00 2018 cron.info crond[1761]: USER root pid 14264 cmd /sbin/fan_ctrl.sh
Wed Jan 10 07:45:03 2018 daemon.notice hostapd: wlan1: AP-STA-DISCONNECTED 84:c7:ea:20:1f:29
Wed Jan 10 07:45:03 2018 daemon.info hostapd: wlan1: STA 84:c7:ea:20:1f:29 IEEE 802.11: disassociated
Wed Jan 10 07:45:04 2018 daemon.info hostapd: wlan1: STA 84:c7:ea:20:1f:29 IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)
Wed Jan 10 07:45:08 2018 daemon.info hostapd: wlan1: STA 84:c7:ea:20:1f:29 IEEE 802.11: authenticated
Wed Jan 10 07:45:08 2018 daemon.info hostapd: wlan1: STA 84:c7:ea:20:1f:29 IEEE 802.11: associated (aid 1)
Wed Jan 10 07:45:08 2018 daemon.notice hostapd: wlan1: AP-STA-CONNECTED 84:c7:ea:20:1f:29
Wed Jan 10 07:45:08 2018 daemon.info hostapd: wlan1: STA 84:c7:ea:20:1f:29 WPA: pairwise key handshake completed (RSN)
Wed Jan 10 07:45:08 2018 daemon.info dnsmasq-dhcp[4087]: DHCPDISCOVER(br-lan) 84:c7:ea:20:1f:29
Wed Jan 10 07:45:08 2018 daemon.info dnsmasq-dhcp[4087]: DHCPOFFER(br-lan) 192.168.1.85 84:c7:ea:20:1f:29
Wed Jan 10 07:45:08 2018 daemon.info dnsmasq-dhcp[4087]: DHCPREQUEST(br-lan) 192.168.1.85 84:c7:ea:20:1f:29
Wed Jan 10 07:45:08 2018 daemon.info dnsmasq-dhcp[4087]: DHCPACK(br-lan) 192.168.1.85 84:c7:ea:20:1f:29 XperiaXZ
Wed Jan 10 07:45:10 2018 user.warn igmpproxy[4195]: MRT_DEL_MFC; Errno(2): No such file or directory
Wed Jan 10 07:45:11 2018 daemon.notice hostapd: wlan1: AP-STA-DISCONNECTED 84:c7:ea:20:1f:29
Wed Jan 10 07:45:11 2018 daemon.info hostapd: wlan1: STA 84:c7:ea:20:1f:29 IEEE 802.11: disassociated
Wed Jan 10 07:45:12 2018 daemon.info hostapd: wlan1: STA 84:c7:ea:20:1f:29 IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)
Wed Jan 10 07:46:21 2018 daemon.info hostapd: wlan1: STA 84:c7:ea:20:1f:29 IEEE 802.11: authenticated
Wed Jan 10 07:46:21 2018 daemon.info hostapd: wlan1: STA 84:c7:ea:20:1f:29 IEEE 802.11: associated (aid 1)
Wed Jan 10 07:46:21 2018 daemon.notice hostapd: wlan1: AP-STA-CONNECTED 84:c7:ea:20:1f:29
Wed Jan 10 07:46:21 2018 daemon.info hostapd: wlan1: STA 84:c7:ea:20:1f:29 WPA: pairwise key handshake completed (RSN)
Wed Jan 10 07:46:22 2018 daemon.info dnsmasq-dhcp[4087]: DHCPDISCOVER(br-lan) 84:c7:ea:20:1f:29
Wed Jan 10 07:46:22 2018 daemon.info dnsmasq-dhcp[4087]: DHCPOFFER(br-lan) 192.168.1.85 84:c7:ea:20:1f:29
Wed Jan 10 07:46:22 2018 daemon.info dnsmasq-dhcp[4087]: DHCPREQUEST(br-lan) 192.168.1.85 84:c7:ea:20:1f:29
Wed Jan 10 07:46:22 2018 daemon.info dnsmasq-dhcp[4087]: DHCPACK(br-lan) 192.168.1.85 84:c7:ea:20:1f:29 XperiaXZ
Wed Jan 10 07:46:24 2018 daemon.notice hostapd: wlan1: AP-STA-DISCONNECTED 84:c7:ea:20:1f:29
Wed Jan 10 07:46:24 2018 daemon.info hostapd: wlan1: STA 84:c7:ea:20:1f:29 IEEE 802.11: disassociated
Wed Jan 10 07:46:25 2018 daemon.info hostapd: wlan1: STA 84:c7:ea:20:1f:29 IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)
Wed Jan 10 07:46:30 2018 daemon.info hostapd: wlan1: STA 84:c7:ea:20:1f:29 IEEE 802.11: authenticated
Wed Jan 10 07:46:30 2018 daemon.info hostapd: wlan1: STA 84:c7:ea:20:1f:29 IEEE 802.11: associated (aid 1)
Wed Jan 10 07:46:30 2018 daemon.notice hostapd: wlan1: AP-STA-CONNECTED 84:c7:ea:20:1f:29
Wed Jan 10 07:46:30 2018 daemon.info hostapd: wlan1: STA 84:c7:ea:20:1f:29 WPA: pairwise key handshake completed (RSN)
Wed Jan 10 07:46:30 2018 daemon.info dnsmasq-dhcp[4087]: DHCPDISCOVER(br-lan) 84:c7:ea:20:1f:29
(...omissis...)

(full log on https://pastebin.com/6qPQnfGR )

After a reboot , it runs fine as usual.
Any idea ?

(Last edited by ambrosa on 10 Jan 2018, 09:42)

wayne1958 wrote:

Hi David
Belated Happy New Year to you!
I finally got round to testing the latest 4.9 version on my WRT1900 v1. I couldnt update packages without disabling the sig verification check in opkg.conf.
I'll report back on the reboot situation when I have some evidence.!

UPDATE => in my experiecne the reboot issue is definately solved! Many thanks.....

wayne1958 wrote:

UPDATE => in my experiecne the reboot issue is definately solved! Many thanks.....

Yes, IDLE reboot issue is solved in 4.9.

@all
Guys, i need a help from anyone using 1900ACv1 with 4.9.
Can you please try to switch you country code in /etc/config/wireless to 'BZ', then reboot and tell me what you see in 'iw reg get' command output?

makedir wrote:

@beginner67890

I totally believe, that it is connected to the same problem the 1900v1 has with CPUFREQ and CPUIDLE. Maybe the sleep command triggers it somehow, and because no one else (than me) uses a script here, which has a sleep command in, no one sees those reboots.

I politely asked David to include the patch too for the WRT1200AC but he just laughed at me with some rude comment. So I have to build my own build at some point I guess, which I havent tied so far, because I thought the WRT1200AC is not officially supported by the native Lede source, and David had implemented patches in his build inviroment, which he does not make public, even I also asked politely for that.

It seems if you just use the router as a potato (not much cpu and ram load), it is "stable". So this seems why no one else notices these issues. But I am dependent on bash scripts which uses a sleep, so I want to see this be fixed.


makedir-

I feel you are mistaken about the davidc502 build for the WRT1200AC for several reasons.

1) The WRT1900ACv1 uses a completely different CPU than WRT1200AC and the other routers covered by this thread. Expecting a patch that possibly solves a problem with the WRT1900AC cpuidle to also work on the rest of the routers would be a very strange coincidence. I haven't looked into the cpuidle recently so maybe things have changed except that has always been a problem for the Marvell SOCs. These proposed fixes have been tried before and there have been some low level problems preventing their reliability every time. These experiments have always been reverted after testing.

2) I am sure davidc502 knows a lot more about these problems and whether there has been a breakthrough finally allowing the advanced cpufreq and cpuidle features of these Marvell designs.

3) Please do not expect davidc502 to become a developer in addition to the maintainer for these builds. I am certain he communicates with the developers who work on the code and adopts their patches when he feels they are stable so expecting him to also test and troubleshoot the code is arguably going too far.

4) The same cpu is clocked to much higher frequencies on the newer Linksys routers. I really doubt there is a problem with timing on the WRT1200AC because of the most conservative clocking of all of these routers. Here is a good place to track down the answers to your questions:
https://wiki.openwrt.org/toh/linksys/wrt_ac_series

I also have a lot yet to learn. Join the club.

The LEDE still uses the 4.9 kernel so looking at the newest kernel 4.14.13 mvebu code written by Marvell the supplier to Linksys still shows a broken cpuidle:

static __init int armada_38x_cpuidle_init(void)
{
    struct device_node *np;
    void __iomem *mpsoc_base;
    u32 reg;

    pr_warn("CPU idle is currently broken on Armada 38x: disabling\n");
    return 0;

http://elixir.free-electrons.com/linux/ … ebu/pmsu.c

@beginner67890

This isnt meant in a mean way, but no, I feel YOU are mistaken. Or at least not get my point on this.

1) They are both related CPUs, both by the same manufacturer, both the same CPU family. ONE is just a little bit "older". What does this lead to? They obviously both have the same or similar silicon somewhere in them. CPUFREQ and CPUIDLE was always bugged for ALL of the family with Linux. The OpenWRT devs though forgot to disable it too for 1900v1. And they implemented a "cheap" patch years ago for the other models, 1200, 1900v2, 3200, "disabling" CPUIDLE at boot time. BUT, as I see it, the patch isnt 100% the same, as disabling the flags in the config for compiled version for this 1900v1. ERGO, it can be, that this bug isnt 100% fixed for the 1200, 1900v2, 3200.

2) No, he does not obviously, because see 3) and your point. He is not a dev.

3) see 2)

4) I said RAM CLOCKS, and/or RAM VOLTAGE, not CPU clocks...

Those reboots as I see happen for a page fault of RAM caused by bad RAM (badly clocked, voltage wrong, overheat), and CPU idle states causing this.

I had again no reboot over the past days. I actually turned on a sleep 20 script, and after 2 days had, oh wonder, another page fault bug.

(Last edited by makedir on 12 Jan 2018, 15:48)

makedir-

Sure, I can accept your terms. I would hope you could also give davidc502 his space.

I agree the page faults are a serious problem. I would certainly want to find the solution if they happened to my router. They sometimes can be due to looking for a file that is missing or looking for a bad memory address for example. I suppose a faulty memory chip or bad timing could be seen as the same type of memory problem by the kernel. I hope you find the reason.

I imagine the kernel expects certain features to be supported across the board by all cpus and might cause a problem when a certain cpu doesn't provide the basic features. Perhaps just disabling the cpuidle and cpufreq isn't enough and the kernel tries to use the features anyway causing the problems with the sleep command or other timing requirements. That is just speculation because I haven't looked into the actual way the kernel would react in this case. There is a lot more I don't know in addition.

Good luck.

makedir wrote:

@beginner67890
This isnt meant in a mean way, but no, I feel YOU are mistaken. Or at least not get my point on this.

1) They are both related CPUs, both by the same manufacturer, both the same CPU family. ONE is just a little bit "older". What does this lead to? They obviously both have the same or similar silicon somewhere in them. CPUFREQ and CPUIDLE was always bugged for ALL of the family with Linux. The OpenWRT devs though forgot to disable it too for 1900v1. And they implemented a "cheap" patch years ago for the other models, 1200, 1900v2, 3200, "disabling" CPUIDLE at boot time. BUT, as I see it, the patch isnt 100% the same, as disabling the flags in the config for compiled version for this 1900v1. ERGO, it can be, that this bug isnt 100% fixed for the 1200, 1900v2, 3200.

2) No, he does not obviously, because see 3) and your point. He is not a dev.

3) see 2)

4) I said RAM CLOCKS, and/or RAM VOLTAGE, not CPU clocks...

Those reboots as I see happen for a page fault of RAM caused by bad RAM (badly clocked, voltage wrong, overheat), and CPU idle states causing this.

I had again no reboot over the past days. I actually turned on a sleep 20 script, and after 2 days had, oh wonder, another page fault bug.

Hi mate you do know that davidc502  is not a dev. Have you filed a bug report with the people who can fix it?
https://bugs.lede-project.org/

Hi.
Do we have a stable wifi in 2018? I wonder. Reading pages of the forum and it's still issue after issue.
I am copy pasting new drivers *.bin to any kernel (i really don't want to go through long router upgrade procedure each time - once in a year is the limit).
Why we have to change kernels? When this become stable. With new minor version of kernel, cannot apply packages posted.
And when this project will get auto-update, 100% configuration kept.
Some people would just like their router run reliably 24/7, instead of playing with vanilla configuration.
It's a huge different between vanilla router and configured router.

*was travelling for one month, and the router survived! (thanks to the tons of safeguard scripts). Well, except wifi. Which i didn't need remotely. But im back and wifi is dead in few days repeatedly:/

(Last edited by wrtuser123 on 13 Jan 2018, 00:44)

makedir -

I just ran a test to sleep for just 1 second without difficulty. I do not have the optional bash shell installed and just was running the default ash shell. I don't know if the ash has a built-in sleep or if that calls the /bin/busybox sleep. I also tried the busybox sleep with no problem. There were no errors in the ssh console nor in the logs.

Could you try the /bin/busybox sleep or shorthand /bin/sleep command in your shell script to see if that works better than the bash sleep?

root@LEDE:/bin# ./busybox sleep --help
BusyBox v1.27.2 () multi-call binary.

Usage: sleep [N]...

Pause for a time equal to the total of the args given, where each arg can
have an optional suffix of (s)econds, (m)inutes, (h)ours, or (d)ays
root@LEDE:/bin# 

I have an issue.. I get "nan" values on all my grapth for my WRT1900ACSv2 in Statistics > Graphs. How can I fix it?

(with r5621)