WRT1900AC Spontaneous Reboots, lockups

[chadster766]

Your build, unmodified. I noticed another issue after flashing your 1.0.5 build. The router now will only flash to, and boot off of alt_nand. I tried flashing back to stock latest and it went to alt_nand. Then flashed stock n-1 thinking it would overwrite openwrt on the primary. Nope, it flashed again to alt_nand. So then from n-1 I figured surely if I flash latest stock from n-1, of course it will ping pong now to primary. Nope, again back to alt_nand.

Odd, I can't remember which U-Boot environment variable controls that but AFAIK the firmware doesn't change it's value.

It could be that your primary image is corrupted. In which case you can flash to both primary and alternate locations with the below commands.

run update_both_images
Boot

Your answer about the v1.0.5 image you are using is unclear to me.
Did you download a pre built image for the below link?
https://github.com/Chadster766/McWRT/releases

 

[cybrnook]

Yes, I used your pre-built image off your github following your wiki guide.

Not the end of the world, but wanted to make you aware that I think there may be something up with how the environment gets set after a openwrt install. Not sure if it's running a script (that's gets put in place during install? ) to set a persistent alt_nand variable now or not. I would think this would cause an issue in the linksys fall back to previous image feature (on stock firmware), as it would always fall back to the openwrt image.

Again, nothing earth shattering, just observations I have since put back in place the ol' ac66u until further notice as I need a stable WiFi daily driver.

 

[chadster766]

Yes, I used your pre-built image off your github following your wiki guide.

Not the end of the world, but wanted to make you aware that I think there may be something up with how the environment gets set after a openwrt install. Not sure if it's running a script (that's gets put in place during install? ) to set a persistent alt_nand variable now or not. I would think this would cause an issue in the linksys fall back to previous image feature (on stock firmware), as it would always fall back to the openwrt image.

Again, nothing earth shattering, just observations I have since put back in place the ol' ac66u until further notice as I need a stable WiFi daily driver.

Thanks I will keep an eye out for other reports of this.
The process outlined in the below link does work:

https://github.com/Chadster766/McWRT/wiki/Manually-switch-to-previous-firmware

I professionally have 8 of these units running McWRT v1.0.5 at high traffic locations as AP (lan to lan) without complaint. I hope the next release will work better for you

 

[cybrnook]

Just to verify, next release is 1.0.6 based on chaos calmer, correct? That will include the new drivers marvell just dished out the past week?

 

[chadster766]

Just to verify, next release is 1.0.6 based on chaos calmer, correct? That will include the new drivers marvell just dished out the past week?

I'm planning the first CC release as CCv2.0.0

It may contain the same driver with custom fixes, an altogether different driver that's currently under development or the binary blog from the new Linksys GPL if it proves to be stable and good.

The "New" Marvell driver in the Linksys GPL has the "*.c" source code files removed. The header (*.h) files are the same except for a version change listed in the files comment headers. So there is not way to compile it unless I were to implement the binary blob.

IMO I think that it is the same Marvel source but Linksys is implementing it better but who can know for sure since the source is pulled.

 

[cybrnook]

Thanks I will keep an eye out for other reports of this.
The process outlined in the below link does work:

https://github.com/Chadster766/McWRT/wiki/Manually-switch-to-previous-firmware

I professionally have 8 of these units running McWRT v1.0.5 at high traffic locations as AP (lan to lan) without complaint. I hope the next release will work better for you

Oh yeah, not an issue flashing back (regardless of which nand side it is on). Since I first fired it up (3 days ago) this was my sequence (nands were determined via sysinfo.cgi):

1 - Stock 161917 (lived on primary nand)
2 - Updated to 164461 (flashed to alt_nand) - First "unplanned-reboot" was the next day
3 - McWRT 1.0.5 (Flashed from linksys GUI, so it landed on primary nand, since that was "next")

---this is where it breaks---

4 - Flashed back to Stock 161917 (Went to alt_nand)
5 - Flashed to latest 164461 (Went to alt_nand)
6 - Flashed again 161917 (went to alt_nand)
7 - Flashed back to latest 164461 (went to alt_nand) - Gave up at this point

Is unfortunate, since the linkysys provides a "dual boot" fail back that seems to be borked with openwrt. I linked a note/patch that was published via belkin, that the nands are supposed to "Ping Pong" when flashing:

http://patchwork.openwrt.org/patch/5371/

"The sysupgrade has the ping-pong effect:
when we are runnning the firmware from Primary partition and do
sysupgrade the new firmware is written to the Alternative partition, on
next reboot bootcmd is set to Alternative partition; when we are running
the firmware from Alternative partition and do sysupgrade, the new
firmware is written to the Primary partition, on next reboot bootcmd is
set to Primary partition."

 

[chadster766]

Oh yeah, not an issue flashing back (regardless of which nand side it is on). Since I first fired it up (3 days ago) this was my sequence (nands were determined via sysinfo.cgi):

1 - Stock 161917 (lived on primary nand)
2 - Updated to 164461 (flashed to alt_nand) - First "unplanned-reboot" was the next day
3 - McWRT 1.0.5 (Flashed from linksys GUI, so it landed on primary nand, since that was "next")

---this is where it breaks---

4 - Flashed back to Stock 161917 (Went to alt_nand)
5 - Flashed to latest 164461 (Went to alt_nand)
6 - Flashed again 161917 (went to alt_nand)
7 - Flashed back to latest 164461 (went to alt_nand) - Gave up at this point

Is unfortunate, since the linkysys provides a "dual boot" fail back that seems to be borked with openwrt. I linked a note/patch that was published via belkin, that the nands are supposed to "Ping Pong" when flashing:

http://patchwork.openwrt.org/patch/5371/

"The sysupgrade has the ping-pong effect:
when we are runnning the firmware from Primary partition and do
sysupgrade the new firmware is written to the Alternative partition, on
next reboot bootcmd is set to Alternative partition; when we are running
the firmware from Alternative partition and do sysupgrade, the new
firmware is written to the Primary partition, on next reboot bootcmd is
set to Primary partition."

When you use U-Boot commands to flash images I believe it will flash to the currently active image location unless you specify otherwise.

That is why the OpenWRT McWRT Wiki home page recommends always flashing the OpenWRT images from the Linksys UI unless you have the USB to TTL cable.

 

[cybrnook]

Do you ever sleep? Thanks for taking the time to reply! I see you are busy in a number of forums for this project so I will kindly thank you for your time boss.

Just as an FYI, all my flashing was performed from the linksys UI, outside of the flash back to linksys firmware from McWRT. Where that, of course, was flashed from the OpenWRT UI.

Anyways, like I said. I got the router tucked away back in its box in the closet. Waiting for the day that may hopefully come where this router is fully supported under the OpenWRT trunk/platform.

Thanks Again!

 

[chadster766]

Do you ever sleep? Thanks for taking the time to reply! I see you are busy in a number of forums for this project so I will kindly thank you for your time boss.

Just as an FYI, all my flashing was performed from the linksys UI, outside of the flash back to linksys firmware from McWRT. Where that, of course, was flashed from the OpenWRT UI.

Anyways, like I said. I got the router tucked away back in its box in the closet. Waiting for the day that may hopefully come where this router is fully supported under the OpenWRT trunk/platform.

Thanks Again!

Thank you

I will look into the flash issue. It's important that it works as expected. Luckily image issues are at a minimum.

 

[oliamali]

if I had a bad unit or not but I tried pretty much everything and couldn't get it to lock up or reboot at all Coque galaxy A3 etui samsung galaxy A3.


-------------------------------------------------

 

[htismaqe]

I haven't had a spontaneous reboot since July. I've rebooted it myself due to work around the house and one firmware upgrade but that is it. Rock solid.