OpenWrt/LEDE Project

  • Status Closed
  • Percent Complete
  • Task Type Bug Report
  • Category Base system
  • Assigned To
    Mathias Kresin
  • Operating System All
  • Severity Low
  • Priority Very Low
  • Reported Version Trunk
  • Due in Version Undecided
  • Due Date Undecided
  • Private
Attached to Project: OpenWrt/LEDE Project
Opened by Timo Valtoaho - 25.04.2017
Last edited by Mathias Kresin - 29.07.2017

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

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:


Closed by  Mathias Kresin
29.07.2017 07:29
Reason for closing:  Fixed
Additional comments about closing:  

Fixed with ht tps:// 9dd83b0fc194cccb38dca19d29b and ht tps:// 010c9d5a8fc67e5e48135f11aae. THe fix was backported to the lede-17.01 branch and will be included in the next release.

Jo-Philipp Wich commented on 25.04.2017 13:45

Are you able to capture a serial console log?

Timo Valtoaho commented on 25.04.2017 15:32

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.

Timo Valtoaho commented on 27.04.2017 04:52


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:

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

Timo Valtoaho commented on 28.04.2017 20:45

Git bisected this to 649e766a64a0d001f040dfc225c601b3d0af6f40

Aaron Z commented on 27.06.2017 03:01

Timo, you need to use the TFTP or ASUS Firmware Restoration utility, telnet and SSH will not work.
See 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
 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

Project Manager
Mathias Kresin commented on 27.06.2017 08:34

Aaron, would you please try an image from

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.

Aaron Z commented on 27.06.2017 10:25

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

Aaron Z

Project Manager
Mathias Kresin commented on 05.07.2017 10:34

Would you please try an image from and reported back whether the issue is fixed.

Aaron Z commented on 05.07.2017 12:15

I will try that tonight.

Aaron Z

Valentin commented on 05.07.2017 13:35


Same thing in HG556a ver. C Forum report.

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

My bootlog:


Valentin commented on 05.07.2017 13:44

Also tried, and the bootloop persist.


Project Manager
Mathias Kresin commented on 05.07.2017 14:22

Valentin, would you please try this image and provide a serial console bootlog.

Project Manager
Mathias Kresin commented on 07.07.2017 10:41


Aaron Z commented on 07.07.2017 10:56

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

Aaron Z commented on 08.07.2017 03:37

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

Henk Vergonet commented on 20.07.2017 15:16

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



Available keyboard shortcuts


Task Details

Task Editing