jow-:

Are you able to capture a serial console log?

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.

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.

tinde:

Git bisected this to 649e766

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

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.

aczlan:

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

Aaron Z

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.

aczlan:

I will try that tonight.

Aaron Z

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

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

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.

mkresin:

Anyone?

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

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

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.