northbound wrote:

r46705 was not a good build it broke gufus's fan script and seemed to use too much cpu. Also noticed something new in
startup, "linksys_recovery" so I am back to r46687 which ran stable for a few days before I tried r46705.
A handy command "fw_printenv boot_part"
"fw_setenv boot_part 2" That is if you are on 1 and want to revert to previous firmware.

You're also forgetting to change bootcmd, otherwise you'll boot the wrong kernel.  If you're booting partition 1, it should boot nandboot, partition 2 should be altnandboot or whatever it is.

The linksys recovery script is what's needed to reset the boot counter so it doesn't perform auto recovery when it shouldn't.

There haven't been any changes that would break the fan script.

The linksys recovery script also enables auto recovery now, so power on, wait 5 seconds, power off (3 times) it will change to the previous partition.

If you're running trunk, 46687 is a not so friendly commit, as you'll need to adjust the hash for mwlwifi to run 10.3.0.3 instead of .8

It's possible your bootcmd and boot_part were out of sync, and loaded an old kernel causing your issue.  Make sure to build target/linux/clean if you compile the latest trunk as there are kernel changes that are necessary for system changes that went into place, regarding using the same mac on multiple interfaces.

I'm also currently testing the armada thermal throttling support, not seeing any issues with it yet.

nyt wrote:

northbound wrote:

r46705 was not a good build it broke gufus's fan script and seemed to use too much cpu. Also noticed something new in
startup, "linksys_recovery" so I am back to r46687 which ran stable for a few days before I tried r46705.
A handy command "fw_printenv boot_part"
"fw_setenv boot_part 2" That is if you are on 1 and want to revert to previous firmware.

You're also forgetting to change bootcmd, otherwise you'll boot the wrong kernel.  If you're booting partition 1, it should boot nandboot, partition 2 should be altnandboot or whatever it is.

The linksys recovery script is what's needed to reset the boot counter so it doesn't perform auto recovery when it shouldn't.

There haven't been any changes that would break the fan script.

The linksys recovery script also enables auto recovery now, so power on, wait 5 seconds, power off (3 times) it will change to the previous partition.

If you're running trunk, 46687 is a not so friendly commit, as you'll need to adjust the hash for mwlwifi to run 10.3.0.3 instead of .8

It's possible your bootcmd and boot_part were out of sync, and loaded an old kernel causing your issue.  Make sure to build target/linux/clean if you compile the latest trunk as there are kernel changes that are necessary for system changes that went into place, regarding using the same mac on multiple interfaces.

I'm also currently testing the armada thermal throttling support, not seeing any issues with it yet.

I don't have a "nix" box so I use the builds from the buildbot and the build of r46687 has the 10.3.0.3 mwlwifi. So what is the right way to switch from nand to altnand? I have quit flashing from Linksys factory builds  so I usually have two working OpenWrt builds to choose from. Maybe the fan issue was a fluke I would click restart and it would run for awhile but it would not take long to heat up and the fan would not come back on until I clicked restart again on the fan_control.

All that a VLAN does is to split a wired connection into multiple networks.

you are trying to make a new network for the wireless interfaces, right?

@nyt

root@OpenWrt:~# fw_printenv bootcmd
bootcmd=run nandboot
root@OpenWrt:~# fw_printenv boot_part
boot_part=2
root@OpenWrt:~#

So it appears that I am out of sync. So the correct thing to do now is "fw_setenv bootcmd altnandboot" and I will be back into sync?

So Linksys_recovery would keep both in sync? I have so much to learn
Unlike a previous poster I bought my wrt1900acv1 to play with and learn.
Thanks nyt I appreciate the help.

dlang wrote:

All that a VLAN does is to split a wired connection into multiple networks.

'k

dlang wrote:

you are trying to make a new network for the wireless interfaces, right?

yes

northbound wrote:

@nyt

root@OpenWrt:~# fw_printenv bootcmd
bootcmd=run nandboot
root@OpenWrt:~# fw_printenv boot_part
boot_part=2
root@OpenWrt:~#

So it appears that I am out of sync. So the correct thing to do now is "fw_setenv bootcmd altnandboot" and I will be back into sync?

So Linksys_recovery would keep both in sync? I have so much to learn
Unlike a previous poster I bought my wrt1900acv1 to play with and learn.
Thanks nyt I appreciate the help.

root@AC1900M:~# grep rootfs /proc/mtd
mtd7: 02500000 00020000 "rootfs2"
root@AC1900M:~#

This will show what kernel your on, I'm on kernel2 (alt_image)

northbound wrote:

@nyt

root@OpenWrt:~# fw_printenv bootcmd
bootcmd=run nandboot
root@OpenWrt:~# fw_printenv boot_part
boot_part=2
root@OpenWrt:~#

So it appears that I am out of sync. So the correct thing to do now is "fw_setenv bootcmd altnandboot" and I will be back into sync?

So Linksys_recovery would keep both in sync? I have so much to learn
Unlike a previous poster I bought my wrt1900acv1 to play with and learn.
Thanks nyt I appreciate the help.

root@AC1900M:~# grep rootfs /proc/mtd
mtd7: 02500000 00020000 "rootfs2"
root@AC1900M:~#

This will show what kernel your on, I'm on kernel2 (alt_image)

gufus wrote:

northbound wrote:

@nyt

root@OpenWrt:~# fw_printenv bootcmd
bootcmd=run nandboot
root@OpenWrt:~# fw_printenv boot_part
boot_part=2
root@OpenWrt:~#

So it appears that I am out of sync. So the correct thing to do now is "fw_setenv bootcmd altnandboot" and I will be back into sync?

So Linksys_recovery would keep both in sync? I have so much to learn
Unlike a previous poster I bought my wrt1900acv1 to play with and learn.
Thanks nyt I appreciate the help.

root@AC1900M:~# grep rootfs /proc/mtd
mtd7: 02500000 00020000 "rootfs2"
root@AC1900M:~#

This will show what kernel your on, I'm on kernel2 (alt_image)

root@OpenWrt:~# fw_printenv bootcmd
bootcmd=run altnandboot
root@OpenWrt:~#  fw_printenv boot_part
boot_part=2
root@OpenWrt:~# grep rootfs /proc/mtd
mtd5: 02500000 00020000 "rootfs1"
root@OpenWrt:~#

I now have the first 2 in sync do I also have to get rootfs in sync also? Is there somewhere that would describe this in detail?
All I am finding is scattered info and a lot of it is old and I am guessing obsolete.

physically what this is doing is

eth0 -> port 5 on switch
eth1 -> port 6 on switch
WAN -> port 4 on switch
LAN1 -> port 0 on switch
LAN2 -> port 1 on switch
LAN3 -> port 2 on switch
LAN4 -> port 3 on switch

vlan1 connects ports 0 1 2 3 5 on the switch
vlan2 connects ports 4 6 on the switch

dlang wrote:

physically what this is doing is

eth0 -> port 5 on switch
eth1 -> port 6 on switch
WAN -> port 4 on switch
LAN1 -> port 0 on switch
LAN2 -> port 1 on switch
LAN3 -> port 2 on switch
LAN4 -> port 3 on switch

vlan1 connects ports 0 1 2 3 5 on the switch
vlan2 connects ports 4 6 on the switch

This is were you mixed me up, thats wrong

This is correct
http://www.gypsy-designs.com/port+layout.png

northbound wrote:

gufus wrote:

root@AC1900M:~# grep rootfs /proc/mtd
mtd7: 02500000 00020000 "rootfs2"
root@AC1900M:~#

This will show what kernel your on, I'm on kernel2 (alt_image)

root@OpenWrt:~# fw_printenv bootcmd
bootcmd=run altnandboot
root@OpenWrt:~#  fw_printenv boot_part
boot_part=2
root@OpenWrt:~# grep rootfs /proc/mtd
mtd5: 02500000 00020000 "rootfs1"
root@OpenWrt:~#

I now have the first 2 in sync do I also have to get rootfs in sync also? Is there somewhere that would describe this in detail?
All I am finding is scattered info and a lot of it is old and I am guessing obsolete.

That's not really correct to show what fs you're on.  the root fs will show up as ubi if you cat /proc/mtd.

The boot command for the kernel will show you what fs was actually booted.

root@ZOMGWTFBBQWIFI:~# cat /proc/cmdline
console=ttyS0,115200 mtdparts=armada-nand:1024K(uboot)ro,256K(u_env),256K(s_env),1m@9m(devinfo),40m@10m(kernel),37m@13m(rootfs),40m@50m(alt_kernel),37m@53m(alt_rootfs),80m@10m(ubifs),-@90m(syscfg) root=/dev/mtdblock7 ro rootfstype=jffs2 init=/sbin/init

root@ZOMGWTFBBQWIFI:/system# cat /proc/mtd | grep mtd7 (some lines in output snipped)
mtd4: 02800000 00020000 "kernel1"
mtd5: 02500000 00020000 "rootfs1"
mtd6: 02800000 00020000 "kernel2"
mtd7: 02500000 00020000 "ubi"

When the next CC build comes out it will have the linksys recovery script and updated mtd in place to keep all of that happy.  Until then, your boot counter won't reset, so when you boot the router there's a chance auto recovery will change what you're actually booting.

This is not correct.  See next post.

eth0 -> port 5 on switch
eth1 -> port 6 on switch
WAN -> port 4 on switch
LAN1 -> port 3 on switch
LAN2 -> port 2 on switch
LAN3 -> port 1 on switch
LAN4 -> port 0 on switch

So I've been trying to prove what part of the wrt1900ac is unstable. For the past couple days I've been using the router without the wireless driver but still my main router to the Internet. I rmmod' the mwlwifi driver from the kernel and am using another router for AP duty.

Running on a recent trunk release (46693) I have gone now for 2 days and 7 hours. Prior to this I rarely would make it past 12-24 hours without a stall CPU or complete lockup (no message from console).

On top of this I've been running the Linux command "stress" during that time with the following parameters:
"stress -c 2 -i 2 -m 2 --vm-bytes 64M"
This is suppose to stress the cpu, i/o subsystem and memory.

I can assume at this point the SOC and the kernel image are stable. Can I also assume the issue I am facing and potentially others is the wifi hardware or the mwlwifi driver?

What is interesting is that the router has become less stable with more recent commits. A few months ago it ran much longer so this makes me think it has something to do with the mwlwifi driver.

Thoughts?

So I've been trying to prove what part of the wrt1900ac is unstable....

Running on a recent trunk release (46693) I have gone now for 2 days and 7 hours. Prior to this I rarely would make it past 12-24 hours without a stall CPU or complete lockup (no message from console).

tusc wrote:

So I've been trying to prove what part of the wrt1900ac is unstable....

Running on a recent trunk release (46693) I have gone now for 2 days and 7 hours. Prior to this I rarely would make it past 12-24 hours without a stall CPU or complete lockup (no message from console).

I've never had the router lock up, but I have had plenty of issues.  For example playing Hearthstone or League of Legends I routinely am disconnected right now.  Both PCs use wired connections.  FWIW it doesn't seem too bad when just one PC is playing, but when two play it seems to be much worse.  It also doesn't seem to matter if the router has been up for 24 hours or 24 seconds.

I've been running ping -t openwrt.org in the background and I've started to notice a problem when the disconnects happen:

Reply from 78.24.191.177: bytes=32 time=836ms TTL=45
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Reply from 78.24.191.177: bytes=32 time=1247ms TTL=45

Maybe I should ping something other than openwrt.org?  But it is strange at the time I get drops the pings go to over 1200ms!

Leaving it running for hours I've noticed the pinged climbed from consistently 170ms to consistently ~1000ms pings.  In case it was something to do with the ping command in windows 10 I stopped it command and retried.  The output was still
Reply from 78.24.191.177: bytes=32 time=1023ms TTL=45
Reply from 78.24.191.177: bytes=32 time=979ms TTL=45
Reply from 78.24.191.177: bytes=32 time=982ms TTL=45
Reply from 78.24.191.177: bytes=32 time=1001ms TTL=45

Looking to confirm the problem was at the router I tried a tracert.  However everything was fast again.  So I did the ping again.  Now the times were all at ~170ms like they should be!

Has anybody else witnessed similar behaviour?

dont ping OWRT.. it lags baddly.. and your contributing to the lag...

edit: use one of these to see which hop has lag
on win: tracert <gameserver>