Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

FS#735 - LEDE 17.01.1 boot loop on Asus RT-N56U ramips, rt3883 #5886

Closed
openwrt-bot opened this issue Apr 25, 2017 · 16 comments
Closed

FS#735 - LEDE 17.01.1 boot loop on Asus RT-N56U ramips, rt3883 #5886

openwrt-bot opened this issue Apr 25, 2017 · 16 comments
Labels

Comments

@openwrt-bot
Copy link

openwrt-bot commented Apr 25, 2017

tinde:

After upgrading 17.01.0=>17.01.1 router won't boot up at all. After image is flashed and router reboots, power light flashes, then it lits up, followed by LAN light. Then they both go down and it starts all over again. PWR light flashes, then stays on, LAN follows, and reboot.

Tested both downloaded lede-17.01.1-ramips-rt3883-rt-n56u-squashfs-sysupgrade.bin and lede-17.01.1-ramips-rt3883-rt-n56u-squashfs-factory.bin, as well as builded image using lede-imagebuilder-17.01.1-ramips-rt3883.Linux-x86_64.tar.xz. SHA256 sums verified. All fails.

Problem occurs every time, no matter whether I flash it using Luci, sysupgrade via SSH or Asus native firmware restoration utility.

Recovery is done by flashing any other FW, padawan, openwrt or lede 17.01.0 using Asus FW restoration utility. It is only way to connect to router when bootlooping, no SSH or telnet connection.

Sounds identical to #733:

https://bugs.lede-project.org/index.php?do=details&task_id=733

BR,
tinde

@openwrt-bot
Copy link
Author

openwrt-bot commented Apr 25, 2017

jow-:

Are you able to capture a serial console log?

@openwrt-bot
Copy link
Author

openwrt-bot commented Apr 25, 2017

tinde:

I'm afraid that I'm not. AFAIK it requires opening the router case and using some kind of cable to connect it to a computer, so beyond my skills.

@openwrt-bot
Copy link
Author

openwrt-bot commented Apr 27, 2017

tinde:

Hi

I made some testing yesterday. Flashed latest Asus' official firmware in, then tried with different lede firmwares. Results were so, that neither rt-n56u-squashfs-factory.bin nor rt-n56u-squashfs-sysupgrade.bin v17.01.1 was booting up. Also, older v17.01.0 rt-n56u-squashfs-factory.bin never booted up. Only way to recover is to use Asus' firmware restoration utility for flashing v.17.01.0 sysupgrade version.

Also tried builds from Image generator, same results.

One thing to note, I never managed to get in to a failsafe mode. Well, router itself was in failsafe mode according to PWR led flashing cycle, but no SSH or telnet connections could be established. Guides used in this phase:

https://lede-project.org/docs/user-guide/failsafe_and_factory_reset

https://wiki.openwrt.org/doc/howto/generic.failsafe

Leds were acting pretty much like it was described in the latter.

@openwrt-bot
Copy link
Author

openwrt-bot commented Apr 28, 2017

tinde:

Git bisected this to 649e766

@openwrt-bot
Copy link
Author

openwrt-bot commented Jun 27, 2017

aczlan:

Timo, you need to use the TFTP or ASUS Firmware Restoration utility, telnet and SSH will not work.
See https://wiki.openwrt.org/toh/asus/rt-n56u#install_via_tftp for details (note that if you use the utility, you MUST disconnect or disable ALL interfaces other than the one connected to the router or the utility will NOT work).

Attached are my bootlogs from 17.01.1 (and 17.01.2 which seems :
FS#735 - lede-17.01.1-ramips-rt3883-rt-n56u-squashfs-sysupgrade.log
and:
FS#735 - lede-17.01.2-ramips-rt3883-rt-n56u-squashfs-sysupgrade.log
Both have 3-4 boot cycles in them and both versions seem to have the same issue (both end with a kernel panic on the same line number).
I am not setup to build my own images, but am open to flashing other images to test with.

Aaron Z

@openwrt-bot
Copy link
Author

openwrt-bot commented Jun 27, 2017

mkresin:

Aaron, would you please try an image from https://downloads.lede-project.org/snapshots/targets/ramips/rt3883/.

As already bisected by Timo it is an update of the wireless drivers which causes the crash. But the release images are build without debug informations and do not print the really important informations in the stacktrace.

@openwrt-bot
Copy link
Author

openwrt-bot commented Jun 27, 2017

aczlan:

Here is a boot log with the nightly from 26 Jun:
FS#735 -26Jun2017lede-ramips-rt3883-rt-n56u-squashfs-sysupgrade.log

Aaron Z

@openwrt-bot
Copy link
Author

openwrt-bot commented Jul 5, 2017

mkresin:

Would you please try an image from https://www.kresin.me/files/lede-17.01.2/ and reported back whether the issue is fixed.

@openwrt-bot
Copy link
Author

openwrt-bot commented Jul 5, 2017

aczlan:

I will try that tonight.

Aaron Z

@openwrt-bot
Copy link
Author

openwrt-bot commented Jul 5, 2017

vk496:

Hello.

Same thing in HG556a ver. C [[https://forum.lede-project.org/t/hg556a-ver-c-boot-loop/4811|Forum report]].

Tried with snapshot of 04/07/2017 (also stable versions have the same problem).

My bootlog: https://pastebin.com/mBnsKkgQ

Salu2

@openwrt-bot
Copy link
Author

openwrt-bot commented Jul 5, 2017

vk496:

Also tried [[https://www.kresin.me/files/lede-17.01.2/|https://www.kresin.me/files/lede-17.01.2/]], and the bootloop persist.

Salu2

@openwrt-bot
Copy link
Author

openwrt-bot commented Jul 5, 2017

mkresin:

Valentin, would you please try [[www.kresin.me/files/lede-brcm63xx-generic-HG556a-C-squashfs-cfe.bin|this image]] and provide a serial console bootlog.

@openwrt-bot
Copy link
Author

openwrt-bot commented Jul 7, 2017

mkresin:

Anyone?

@openwrt-bot
Copy link
Author

openwrt-bot commented Jul 7, 2017

aczlan:

Sorry, didn't make it home till after 11PM the last two nights so I haven't had time to try installing it. I will try to get it installed tonight.

Aaron Z

@openwrt-bot
Copy link
Author

openwrt-bot commented Jul 8, 2017

aczlan:

That image works for me (it boots, I can enable wifi and connect to the internet through it). Bootlog attached: FS#735 -MKresin5JulBootl.log

Aaron Z

@openwrt-bot
Copy link
Author

openwrt-bot commented Jul 20, 2017

hvegh:

Hey all....

There's a two line fix for this see
FS#918 - Kernel panic: rt2800lib.ko rt2800_probe_hw

Btw the method of communication can be improved imho...

Mathias Kresin commented on 20.07.2017 06:07
And now check the author of this patch and the one who commented in FS#735...

But it will not be the final fix. Jonas send patches upstream to fix the broken clk_get_rate() implementations instead. It is only waiting for them to be ACK'ed, to backport them to LEDE.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant