@Sera @Villeneuve

If its any help.  I have a mamba running swrt-2017-01-10.  It too suffers from 4.9 reboots, when some load is applied, otherwise it will reboot every day or so

My rango is on a LEDE build, so am following the issues with that too

BR/Phil...

Thanks for that, appears the reboot on mamba happens on OpenWrt as well as LEDE. I just have not experienced it with any of my owrt builds, but that would be the nature of this issue.

@doITright, thanks, I still have that particular build on my drop. Good to know that the issue also happens with later kernels. I was beginning to wonder if maybe the reason I had not seen it on a owrt build was because I was always doing a linux-next image.

But(just a wee one), how to isolate this? No crash log file generated, assumption is that it is the kernel (probably correct), and I have not found any repeatable/identifiable method of forcing.

@Villeneuve

I tend to notice the "crash" when using torrent and when down load rates hit > 10 MB/s sustained

Will see if I can trigger this tonight, before I update to next-20170424

Cheers

Thank you for the tips...  very handy...  next-201704024 built without problems last night for all LinksysWRT devices

Will try using your build_dist script going forward...

Cheers

@sera, in changing things up to further test the mamba reboot issue, I noticed an anomaly with a build based on latest patchset. Appears to be a DTS issue, but as I thought DTS for series were upstream(at least mamba,cobra,shelby), I find it surprising:

linux-next on mamba: USB 1.x thumb(has a led), plugged into USB3 (port 2), no power i.e. led not lit

Have not tried on rango to see if behaviour is same, but you got one of those...

@Villeneuve

Mamba uptime of just over 2 days of regular use

Started torrent -> 18.6 G game -> triggered a "crash" within a minute and then torrent finished the download peaking around 26 MB/s

Cleaned up started torrent again (same game) -> triggered another "crash" in just over a minute

Will upgrade to next-20170424 now and repeat

Cheers

@doITright, I have been trying to keep it simple in terms of SW in the picture. iperf3 between the mamba and an odroid-c1 running ubuntu; on inside LAN nic so far. Just changing # streams, buffer size etc., don't even have the radios turned on. I did have it fail many times with no radios, 0 load, really nothing at all happening on router(may have gotten bored and fallen asleep I suppose), when I was testing with LEDE. Still yet to have anything untoward happen with owrt.

Not much in my build, there is a configdiff in the owrt directory of my drop if you want to take a peek. What FS are you flashing (ubi,squash)? What other bits differ in the picture?

Edit: Fan changes be workin'

(Last edited by Villeneuve on 26 Apr 2017, 00:58)

@Villeneuve

Fresh git clone with only luci, luci-app-statistics, lm-sensors, htop, iperf, iper3 + all dependencies
Always use squashfs and usually sysupgrade + restore backup archive (always current)

Model Linksys WRT1900AC
Firmware Version OpenWrt Designated Driver 50104+swrt-2017-04-24 / LuCI Master (git-17.113.50864-8701c8b)
Kernel Version 4.11.0-rc7-next-20170421
Local Time Tue Apr 25 20:44:35 2017
Uptime 1h 57m 17s

One crash within 10 minutes of sysupgrade (again with torrent)

Piped 47 GB though the wireless interface trying to trigger it again, but so far so good

Cheers

@doITright, Just got a crash, the odroid-c1/Ubuntu 16.04.2, mamba just keeps on ticking.

So wifi? if so, than this is different than what is occurring on LEDE because, as I said, I did not even have the radios on when testing. Also, the last (2?) patchsets have the rather borked mwlwifi, but you were getting breakage before the push.

I have been using UBIFS with @sera builds because, well it's there so why not. I doubt it, but I will squash it and try again.

Hi Guys

I just got an WRT1900AC v1, and after playing a little with oficial firmware, just changed to OpenWRT

https://drive.google.com/open?id=0BwPiN … mpSaEwtMWs

I've used this firmware link above, i think is the lastest one right now, with good options. The flash was OK.

But i'm facing 2 problems

1 - cannot make my internet work proper - My FTTH ISP uses PPPoE and request VLAN 10 for internet.

I cannot make the VLAN proper work. On my tplink 1043 and tplink 4300 it works, i tagg like this and it works ...

I just bind like this and change to pppoe and i can dial and it works

But cannot make it work for WRT 1900AC v1.

( The PPPoE WAN needs to be on VLAN 10 ) all other 4 LAN not ... it will work with dhcp and works like a charm as i said on the other routers.

2 Problem ... i cannot try other OpenWRT/LEDE imgs. When i try to change to official build, or other builds like suggested on wiki, i got error ( the img file does not contain supported format, double check file and try again )

So like this, i cannot update to current openwrt oficial image, or other build ... only this: https://davidc502sis.dynamic-dns.net/ and the one from the link on @villeneuve

sign c7v2|c5v1 & WRTxx00ACx Images: Stuff )

Cannot even revert back to original firmware as it claims not supported format.

Can someone help me ??

Thx

(Last edited by ygor.almeida on 26 Apr 2017, 04:34)

The led triggers are set up by openwrt, I assume the wrong port configuration is used with the new usb-port trigger (since approx 4.9). If your thumb drive is USB3.0 both leds the big and the small one should be glowing. If it's USB2.0 or older only the big one should glow. (Ignoring the existence of the usb2/sata port for this discussion to not create confusion)

You can play with the ports assignment under sys/class/leds/*:white:usb3_1/ports/ for the big one and sys/class/leds/*:white:usb3_2/ports/ for the little one. Just echo 0 or 1 to those files until you get the behaviour I described above. Then let me know what combination works and I can make it the default combination. I just used what I thought might be correct based on someone's lsbusb output. Couldn't verify it myself.

---

Yes the last two swrt releases come with the new not yet fully ready mwlwifi. That's another potential source for crashes.

In /etc/config/network:

config switch
    option name 'switch0'
    option reset '1'
    option enable_vlan '1'

config switch_vlan
    option device 'switch0'
    option vlan '1'
    option ports '0 1 2 3 5'

config switch_vlan
    option device 'switch0'
    option vlan '2'
    option vid '10'
    option ports '4t 6'

@sera, The LED I am referring to is actually on the USB thumb drive(so no power to the USB port), not the mamba front display LEDs.

Villeneuve,

ah, that would indeed most likely be a dts bug that went unnoticed for 2 years.

So the device in question is a Mamba and for some reason vbus doesn't deliver any power. Can you check if some old release (like CC) has the same issue? It should, if the dts theory is correct.

@sera, flashed the @Kaloz CC image that is linked off of wiki and it does indeed have power to the USB port, so appears to something introduced.

Villeneuve,

so a change in the driver or a more fundamental issue even. Might or might not be related to the reboot issue. At least well suited for bisecting should it be needed. Can you check with 4.10 and maybe anything in between 3.18 and 4.10 if 4.10 shows the same behaviour so we can narrow it down at least a bit?

@ygor.almeida, A feature introduced to LEDE make you force a different image(currently). So if you are on a LEDE build and want to go elsewhere, you will have to scp an image over to /tmp and then:

sysupgrade -F -n /tmp/imagename

If you are running a windowX box check out this, less painful scp than putty.

If you are using my image just beware that I am putting up a build whenever a new mwlwifi push happens(frequently as of late); this is just for testing, and expect issues, use an older one if not your interest.

@sera, built a 4.10.12 on latest and the USB port has power. I guess a regression in next. I am seeing this when I flash a squash image, but not with a ubi? Going to bang this 4.10 image to test for the reboot.

Villeneuve,

as there is no overlay that could be cleared with the ubi images a failsafe mode can't be implemented. You seeing this message would mean you pressed the wps or reset button during boot. I suggest you test an image not being in failsafe mode for spontaneous reboots.

4.10.12 working narrows it down a lot already. Next would be testing 4.11 and then bisect. A quick glance at the git log shows to many possible candidates as to make a good guess.

swrt-2017-04-26
---------------

Another release in short succession. There were several commits to mwlwifi, at
least two important fixes. At a minimum the driver isn't as leaky as before.

Also bump next and revert the commit that broke mvneta as well as dependants.
Bluetooth gained a new dependency so add it. Also drop the pwm-fan patch as
it's already included. The required dts changes will enter trough a different
tree and aren't in next yet.

@sera, 4.11.rc8 build with latest has power to USB port. On the fail-safe issue, I have flashed 3 squashfs images, from last 2 patch-sets, 3 different kernels, and the banner always presents. Appears it is being programmatically set.

With the squashfs based images you should see during boot "initramfs: Press any button to enter failsafe". Any button refers to wps and reset key. If a keystroke is detected "initramfs: .. entering failsafe" will be printed and you should see the failsafe banner.

Only if I press either of them during the short window (2s by default) the device will show the failsafe banner. So wonder what might send the keystrokes in your case.

Does "cat /dev/input/event0 | hexdump" generate any output without pressing either button? Are there other input devices connected to your Mamba and the initramfs isn't yet made clever enough.

Do other Mamba users see the same? Either way something isn't as it should.

@sera

I see this as well on the mamba

 -----------------------------------------------------
 DESIGNATED DRIVER (Bleeding Edge, 50104+swrt-2017-04-24)
 -----------------------------------------------------
  * 2 oz. Orange Juice         Combine all juices in a
  * 2 oz. Pineapple Juice      tall glass filled with
  * 2 oz. Grapefruit Juice     ice, stir well.
  * 2 oz. Cranberry Juice
 -----------------------------------------------------
================= FAILSAFE MODE active ================
special commands:
* firstboot          reset settings to factory defaults
* mount_root     mount root-partition with config files

after mount_root:
* passwd                         change root's password
* /etc/config               directory with config files

for more help see:
[url]http://wiki.openwrt.org/doc/howto/generic.failsafe[/url]
=======================================================

Will try swrt-2017-04-26 shortly

Cheers

doITright,

could you apply the following patch https://paste.pound-python.org/show/XBr … pT6lRLVWx/ which should give a hint as to what might be wrong.

Also please install evtest (packages feed) and run "evtest /dev/input/event0" and check that it's indeed the "gpio_keys" pseudo keyboard and that pressing the buttons produces the expected keystrokes?

Thanks

@sera

Will give it a go after work...

Ran into an issue jumping between 0424 and 0426 -> reboot loop after restoring settings from archive

I realize we have a new wifi driver in play, but could restoring the setting from 0328 archive cause the loop?

Back on 0424 and stable now.  Will try again with an archive from this version, and from scratch if it blows up again

Cheers