OpenWrt Forum Archive

Topic: Update on Linksys WRT1900AC support

The content of this topic has been archived between 16 Sep 2014 and 7 May 2018. Unfortunately there are posts – most likely complete pages – missing.

drawz wrote:
davidc502 wrote:

Looks like I'm going to need some help, and this is totally unbelievable, but true.. lol

I ordered a re-furbished Linksys 1900AC from a seller on Ebay to which I received it today - about 4 hours ago.

I boot it up, and plug it into my laptop, and notice that I can't get to the management page 192.168.1.1, but can get to the internet. So I started doing some troubleshooting, and noticed the routers DNS server is "OpenWrt.lan".

Name:    OpenWrt.lan
Address:  192.168.1.1

The previous user apparently had problems after installing OpenWRT, and returned it... From there it appears I got it. Unbelievable to say the least. How something like this passed only to be re-sent as "certified refurbished" is beyond me.

Well, I found out that I can telnet to the router, and get the # prompt. In this condition (wireless is not working and the management page is not working), what can I do with a telnet connection to get this thing running to the point where I can re-flash it?

I've contacted the ebay seller, but they don't work weekends. This gives me time to get it working, so I don't have to send it back.

Thanks,

David

More than likely, there is just no web GUI installed. Your best bet is to download and flash a newer OpenWrt version from the command line, especially if you are able to get your WAN connection with DHCP. If you flash the 15.05-rc1 build, you should get a web GUI and then you can go from there.

You have to install LuCI (after flashing a trunk image).
192.168.1.1 (Telnet)
opkg update
opkg install luci

Back to 192.168.1.1 to log in.

@GV00

I had a problem going back to the latest factory firmware even resetting modem all it would display is a Linksys splash screen
that I could do nothing with. A reboot and reset and I was back at the useless screen. I did the 3 reboots and flashed the factory firmware again from openwrt but this time I installed the previous factory flash and it worked and updated to the latest factory.
You have to be hard wired. and reboot after installing then hold the reset until the power light flashes then go to 192.168.1.1 in your browser and set it up. After that I flashed again to the latest factory image and all went well. Good luck

Hey guys, been following along forever but finally decided to chime in. First, Thanks a million to  Kaloz ive been running his
CHAOS CALMER (Bleeding Edge, r45573) build for over a month with no major hiccups and no ttl cable. My question is before moving to the new 15 build, has anyone had major problems  when doing on a root /overlay. have a 8gb usb with a good bit of packages. Is a sysupgrade somewhat safe or would it be better to reset everything; and flash from factory fm. Thanks

northbound wrote:

@GV00

I had a problem going back to the latest factory firmware even resetting modem all it would display is a Linksys splash screen
that I could do nothing with. A reboot and reset and I was back at the useless screen. I did the 3 reboots and flashed the factory firmware again from openwrt but this time I installed the previous factory flash and it worked and updated to the latest factory.
You have to be hard wired. and reboot after installing then hold the reset until the power light flashes then go to 192.168.1.1 in your browser and set it up. After that I flashed again to the latest factory image and all went well. Good luck

Pretty much exactly what I'm experiencing. Do you have somewhere trustworthy where the previous revisions can be downloaded? It looks like the one thing I wiped out after successfully installing OpenWRT was the backup I'd made of the previous version, and the Linksys site seems to h ave something against maintaining an easily-accessed  directory of historical versions.

grimley wrote:
drawz wrote:
davidc502 wrote:

Looks like I'm going to need some help, and this is totally unbelievable, but true.. lol

I ordered a re-furbished Linksys 1900AC from a seller on Ebay to which I received it today - about 4 hours ago.

I boot it up, and plug it into my laptop, and notice that I can't get to the management page 192.168.1.1, but can get to the internet. So I started doing some troubleshooting, and noticed the routers DNS server is "OpenWrt.lan".

Name:    OpenWrt.lan
Address:  192.168.1.1

The previous user apparently had problems after installing OpenWRT, and returned it... From there it appears I got it. Unbelievable to say the least. How something like this passed only to be re-sent as "certified refurbished" is beyond me.

Well, I found out that I can telnet to the router, and get the # prompt. In this condition (wireless is not working and the management page is not working), what can I do with a telnet connection to get this thing running to the point where I can re-flash it?

I've contacted the ebay seller, but they don't work weekends. This gives me time to get it working, so I don't have to send it back.

Thanks,

David

More than likely, there is just no web GUI installed. Your best bet is to download and flash a newer OpenWrt version from the command line, especially if you are able to get your WAN connection with DHCP. If you flash the 15.05-rc1 build, you should get a web GUI and then you can go from there.

You have to install LuCI (after flashing a trunk image).
192.168.1.1 (Telnet)
opkg update
opkg install luci

Back to 192.168.1.1 to log in.

Looks like I'm a few steps closer -- Thanks

Installed luci, and was able to log into 192.168.1.1.

Downloaded stock flash from Linksys, and Flashed new firmware image, but there's a problem.

This error message showed up --

/usr/lib/lua/luci/dispatcher.lua:433: Failed to execute function dispatcher target for entry '/'.
The called action terminated with an exception:
/usr/lib/lua/luci/util.lua:587: Unable to establish ubus connection
stack traceback:
    [C]: in function 'assert'
    /usr/lib/lua/luci/dispatcher.lua:433: in function 'dispatch'
    /usr/lib/lua/luci/dispatcher.lua:168: in function </usr/lib/lua/luci/dispatcher.lua:167>

It looked like the Linksys image was in place, but the management page would not open... However, I could still get to the internet... So, I decided to do the 3 power offs method of reverting back, but the OpenWRT image was re-loaded.

Question: Would this process work better by flashing from telnet as opposed to the OpenWRT software management page?

In the meantime, I think I will try flashing again through the GUI. 

What's amazing is that I came into this totally cold, and not knowing anything..  I knew this router was arriving, and was looking at this open source software just in case I didn't like the Linksys software. So, to find this router in non working condition because someone had already tried OpenWRT is freaky to say the least.

Daivd

The error from the last flash was due to not clearing the save settings check box.

After unchecking the save setting box, there was no error during the flash process. After waiting some 4 minutes, I tried going to 192.168.1.1, and got the setup screen, but 'next' is greyed out, so there's nothing I can do. Ended up doing the 3 power off proceedure again, and now I'm back to OpenWRT software.

I guess I'm going to try to find a older image version from Linksys, and see if that will work.

(Last edited by davidc502 on 30 May 2015, 16:00)

GV00 wrote:
northbound wrote:

@GV00

I had a problem going back to the latest factory firmware even resetting modem all it would display is a Linksys splash screen
that I could do nothing with. A reboot and reset and I was back at the useless screen. I did the 3 reboots and flashed the factory firmware again from openwrt but this time I installed the previous factory flash and it worked and updated to the latest factory.
You have to be hard wired. and reboot after installing then hold the reset until the power light flashes then go to 192.168.1.1 in your browser and set it up. After that I flashed again to the latest factory image and all went well. Good luck

Pretty much exactly what I'm experiencing. Do you have somewhere trustworthy where the previous revisions can be downloaded? It looks like the one thing I wiped out after successfully installing OpenWRT was the backup I'd made of the previous version, and the Linksys site seems to h ave something against maintaining an easily-accessed  directory of historical versions.

If you want to trust me here is a link also a checksum be sure to verify.

https://onedrive.live.com/redir?resid=E … =folder%2c

davidc502 wrote:

The error from the last flash was due to not clearing the save settings check box.

After unchecking the save setting box, there was no error during the flash process. After waiting some 4 minutes, I tried going to 192.168.1.1, and got the setup screen, but 'next' is greyed out, so there's nothing I can do. Ended up doing the 3 power off proceedure again, and now I'm back to OpenWRT software.

I guess I'm going to try to find a older image version from Linksys, and see if that will work.

I just posted a link to the previous version of factory firmware what you are seeing is exactly what I had happening.

Problem has now been solved....  By the recommendation above... I ended up flashing to a earlier Linksys flash version -- FW_WRT1900AC_1.1.8.164461_prod.img  (1.1.9.x is the most recent as of this date)

After flashing, I ended up rebooting, and then re-setting (holding in reset button). From there went to 192.168.1.1, and followed the instructions.

Thanks for everyone's help as it's very much appreciated.

@davidc502
Glad you are up and running.

Anyone know if there will be a RC2 soon?
If not I guess I will go back to the trunk only about 4 hrs left on the new build.

GV00 wrote:
northbound wrote:

@GV00

I had a problem going back to the latest factory firmware even resetting modem all it would display is a Linksys splash screen
that I could do nothing with. A reboot and reset and I was back at the useless screen. I did the 3 reboots and flashed the factory firmware again from openwrt but this time I installed the previous factory flash and it worked and updated to the latest factory.
You have to be hard wired. and reboot after installing then hold the reset until the power light flashes then go to 192.168.1.1 in your browser and set it up. After that I flashed again to the latest factory image and all went well. Good luck

Pretty much exactly what I'm experiencing. Do you have somewhere trustworthy where the previous revisions can be downloaded? It looks like the one thing I wiped out after successfully installing OpenWRT was the backup I'd made of the previous version, and the Linksys site seems to h ave something against maintaining an easily-accessed  directory of historical versions.

http://www.protechs-online.com/download … 1_prod.img

i flashed to

OpenWrt Chaos Calmer 15.05-rc1

and now i can't connect to my vpn - the error in windows (both windows 8  laptop and windows 7 box say that the most likely reason is the firewall/router do not allow generic routing encapsulation)

i've never had this error before on the stock firmware or the firmware i built myself.

is there a setting somewhere in OpenWrt Chaos Calmer 15.05-rc1 firmware or do i need to flash back ?


i tried to install kmod-gre but got this error

Collected errors:
* satisfy_dependencies_for: Cannot satisfy the following dependencies for kmod-gre:
*     kernel (= 3.18.14-1-9fa165ccd123d47725e8e99b001107b5) *     kernel (= 3.18.14-1-9fa165ccd123d47725e8e99b001107b5) *
* opkg_install_cmd: Cannot install package kmod-gre.

i was going to test the release candidate but i'll go back to my own build

(Last edited by ethereal on 30 May 2015, 23:14)

ethereal wrote:

i flashed to

OpenWrt Chaos Calmer 15.05-rc1

and now i can't connect to my vpn - the error in windows (both windows 8  laptop and windows 7 box say that the most likely reason is the firewall/router do not allow generic routing encapsulation)

i've never had this error before on the stock firmware or the firmware i built myself.

is there a setting somewhere in OpenWrt Chaos Calmer 15.05-rc1 firmware or do i need to flash back ?


i tried to install kmod-gre but got this error

Collected errors:
* satisfy_dependencies_for: Cannot satisfy the following dependencies for kmod-gre:
*     kernel (= 3.18.14-1-9fa165ccd123d47725e8e99b001107b5) *     kernel (= 3.18.14-1-9fa165ccd123d47725e8e99b001107b5) *
* opkg_install_cmd: Cannot install package kmod-gre.

i was going to test the release candidate but i'll go back to my own build

I had the same vpn error a few months back and, if I recall right, it's due to mismatched package versions to the kernel version... that's also why you're getting the dependency error. 

Most OpenWRT packages are updated to the latest kernel version, so when you begin to get the dependency errors, it's time to flash a build with the updated kernel version

EDIT
Even if you go back to your own build, if you don't have it built with kernel 3.18.14, you're going to get the same error, as it's not a problem with the build, but a dependency on kernel 3.18.14 for the package to be installed

(Last edited by JW0914 on 30 May 2015, 23:34)

ethereal wrote:

i flashed to

OpenWrt Chaos Calmer 15.05-rc1

and now i can't connect to my vpn - the error in windows (both windows 8  laptop and windows 7 box say that the most likely reason is the firewall/router do not allow generic routing encapsulation)

i've never had this error before on the stock firmware or the firmware i built myself.

is there a setting somewhere in OpenWrt Chaos Calmer 15.05-rc1 firmware or do i need to flash back ?


i tried to install kmod-gre but got this error

Collected errors:
* satisfy_dependencies_for: Cannot satisfy the following dependencies for kmod-gre:
*     kernel (= 3.18.14-1-9fa165ccd123d47725e8e99b001107b5) *     kernel (= 3.18.14-1-9fa165ccd123d47725e8e99b001107b5) *
* opkg_install_cmd: Cannot install package kmod-gre.

i was going to test the release candidate but i'll go back to my own build

Get your *.ipk files from here http://downloads.openwrt.org/chaos_calm … u/generic/ for CC-RC1

JW0914 wrote:
ethereal wrote:

i flashed to

OpenWrt Chaos Calmer 15.05-rc1

and now i can't connect to my vpn - the error in windows (both windows 8  laptop and windows 7 box say that the most likely reason is the firewall/router do not allow generic routing encapsulation)

i've never had this error before on the stock firmware or the firmware i built myself.

is there a setting somewhere in OpenWrt Chaos Calmer 15.05-rc1 firmware or do i need to flash back ?


i tried to install kmod-gre but got this error

Collected errors:
* satisfy_dependencies_for: Cannot satisfy the following dependencies for kmod-gre:
*     kernel (= 3.18.14-1-9fa165ccd123d47725e8e99b001107b5) *     kernel (= 3.18.14-1-9fa165ccd123d47725e8e99b001107b5) *
* opkg_install_cmd: Cannot install package kmod-gre.

i was going to test the release candidate but i'll go back to my own build

I had the same vpn error a few months back and, if I recall right, it's due to mismatched package versions to the kernel version... that's also why you're getting the dependency error. 

Most OpenWRT packages are updated to the latest kernel version, so when you begin to get the dependency errors, it's time to flash a build with the updated kernel version

EDIT
Even if you go back to your own build, if you don't have it built with kernel 3.18.14, you're going to get the same error, as it's not a problem with the build, but a dependency on kernel 3.18.14 for the package to be installed

thanks for your reply

i was running 15.05-rc1 because i thought this was the only version we should be running at the moment so they can fix any bugs.

is this a bug that needs reporting ?

if yes, how do you report it ?

ethereal wrote:
JW0914 wrote:
ethereal wrote:

i flashed to

OpenWrt Chaos Calmer 15.05-rc1

and now i can't connect to my vpn - the error in windows (both windows 8  laptop and windows 7 box say that the most likely reason is the firewall/router do not allow generic routing encapsulation)

i've never had this error before on the stock firmware or the firmware i built myself.

is there a setting somewhere in OpenWrt Chaos Calmer 15.05-rc1 firmware or do i need to flash back ?


i tried to install kmod-gre but got this error

Collected errors:
* satisfy_dependencies_for: Cannot satisfy the following dependencies for kmod-gre:
*     kernel (= 3.18.14-1-9fa165ccd123d47725e8e99b001107b5) *     kernel (= 3.18.14-1-9fa165ccd123d47725e8e99b001107b5) *
* opkg_install_cmd: Cannot install package kmod-gre.

i was going to test the release candidate but i'll go back to my own build

I had the same vpn error a few months back and, if I recall right, it's due to mismatched package versions to the kernel version... that's also why you're getting the dependency error. 

Most OpenWRT packages are updated to the latest kernel version, so when you begin to get the dependency errors, it's time to flash a build with the updated kernel version

EDIT
Even if you go back to your own build, if you don't have it built with kernel 3.18.14, you're going to get the same error, as it's not a problem with the build, but a dependency on kernel 3.18.14 for the package to be installed

thanks for your reply

i was running 15.05-rc1 because i thought this was the only version we should be running at the moment so they can fix any bugs.

is this a bug that needs reporting ?

if yes, how do you report it ?

IMO, flash a fresh copy from stock FIRST.

ethereal wrote:
JW0914 wrote:
ethereal wrote:

i flashed to

OpenWrt Chaos Calmer 15.05-rc1

and now i can't connect to my vpn - the error in windows (both windows 8  laptop and windows 7 box say that the most likely reason is the firewall/router do not allow generic routing encapsulation)

i've never had this error before on the stock firmware or the firmware i built myself.

is there a setting somewhere in OpenWrt Chaos Calmer 15.05-rc1 firmware or do i need to flash back ?


i tried to install kmod-gre but got this error

Collected errors:
* satisfy_dependencies_for: Cannot satisfy the following dependencies for kmod-gre:
*     kernel (= 3.18.14-1-9fa165ccd123d47725e8e99b001107b5) *     kernel (= 3.18.14-1-9fa165ccd123d47725e8e99b001107b5) *
* opkg_install_cmd: Cannot install package kmod-gre.

i was going to test the release candidate but i'll go back to my own build

I had the same vpn error a few months back and, if I recall right, it's due to mismatched package versions to the kernel version... that's also why you're getting the dependency error. 

Most OpenWRT packages are updated to the latest kernel version, so when you begin to get the dependency errors, it's time to flash a build with the updated kernel version

EDIT
Even if you go back to your own build, if you don't have it built with kernel 3.18.14, you're going to get the same error, as it's not a problem with the build, but a dependency on kernel 3.18.14 for the package to be installed

thanks for your reply

i was running 15.05-rc1 because i thought this was the only version we should be running at the moment so they can fix any bugs.

is this a bug that needs reporting ?

if yes, how do you report it ?

No, it's not a bug.

As previously explained, most packages in the package repository are updated when the kernel version is updated.  Right now, the kernel version is 3.18.14, and if you try to install a package already updated with a dependency for 3.18.14 when you're on kernel version 3.18.9, for example, you will get a failure due to the updated package can see you're running kernel version 3.18.9 and not 3.18.14.

Don't overthink it... a dependency error is literally just what it says... a dependency error.

(Last edited by JW0914 on 31 May 2015, 00:04)

every single build that i've flashed - and its probably between 20 to 30 - the vpn worked with absolutely no help or configuration from me, it just worked.

i think my point was - we are expected to use the 15.05-rc1 3.18 and i was expecting the vpn to work. is everything i need for pptp vpn installed and ready to go ?

do i simply have to configure port forwarding ?

do i have to install additional packages and how do i do that if the kernel is 3.18 and the packages may be 3.18.14 ?

this is not a big problem for me - i've gone back to - 3.18.14 - 45741

i just thought there was a problem with the firmware - but to be fair i don't have a clue what i'm doing :-)

Stock firmware -- Bandwidth usage is totally useless, and inaccurate to boot. 

"See your total internet usage and how much bandwidth each device is consuming"

This is a complete joke.. It spits out a number in Mbps or Kbps which is speed. I thought it was going to tell me how many GigaBytes I've used at the end of the month... wrong.

Well technically bandwidth is throughput or speed. So total bandwidth usage tells the total of all data streams being utilised at any point in time.

Having said that, it would be much more useful if it also counted the total data downloaded, so i agree on that point.

I've been using
https://github.com/pyrovski/wrtbwmon, on OpenWRT

With a few tweaks and I can see both the total data used and the data used per user.

Tested the following to see if Linksys "Network Map" is accurate or not.

1. Using Utorrent, download Ubuntu 14.4.2LTS
2. Throttled maximum download bandwidth to 2.8Mbps (350kBps)
3. Monitored the desktop interface using Resource Monitor.

Created a continuous stream at around 2.8 - 3Mbps, and verified that stream with Resource Monitor. There were slight variations in download, but Utorrent seemed to keep the download bandwidth throttled at around 2.8-3Mbps.

Linksys Network Map was in the ball park 'most' of the time, but not always, using a 10 second polling cycle.

80% of the time would show somewhere around 2.8Mbps (Varying 1.5 to 4Mbps. (Just a rough guestimate)
20% of the time would show from 0Mbps to 10Mbps being used. Totally inaccurate readings.

I could have written each poll and plotted it in a graph, but I wasn't trying to be that scientific. The idea was to just get an idea of how accurate the so called Network Map is. It's not that accurate.

Bottom Line: Network Map would be good to use if trying to find out who is gobbling up all of the available bandwidth. Other than that, it's pretty much useless.

I realize this post would probably be better suited for the linksys forum. However, I want to take some time to evaluate the stock image before moving over to the open image.

My hope is that the Linksys WRT1900AC Open software is continuing to be worked on at a good pace. Because eventually, when it becomes really stable, I'll want to change over to it.

Best Regards,

bdherouville wrote:

Hi,

Sorry but the connection throught 5GHz is too slow & buggy. I have to reboot everyday. The wife's level of complain is too hight wink
I am reverting back to stock firmware. Shame on Belkin/Linksys who have said that this device will be openwrt compliant.

regards,

The device is OpenWRT compliant... if it wasn't, OpenWRT wouldn't run on it.

The firmware, like all firmware, is a work in progress.  Since January, when I first flashed OpenWRT, the 5Ghz radio has worked fine... until this latest snapshot/RC build.  I suspect it will be ironed out within a couple of days, however, you shouldn't make a generalized judgment without knowing a decent amount about OpenWRT on the WRT1900, as it's impossible to made an educated judgment without all the facts.

I recall a few days back there were reported issues with the 5Ghz radio, and both the latest snapshot build (5/30) and RC build (5/20) have completely disabled the 5Ghz radio.

I flashed the 5/30 snapshot build last night and had a signal of 0% on the 5Ghz radio, with the LED indicator off as well.  I then flashed the 5/20 RC build this morning with the same results, 0% signal and no LED indicator (indicating the radio is disabled).

Chadster766 wrote:

I captured another lockup log:

Hostname WRT1
Model Linksys WRT1900AC
Firmware Version OpenWrt Chaos Calmer r45601 / LuCI (git-15.125.30735-c38b4cd) 
Kernel Version 3.18.11
Local Time Wed May 27 14:31:51 2015
Uptime 0h 15m 22s
Load Average 0.00, 0.10, 0.18

Wed May 27 11:47:29 2015 daemon.info hostapd: wlan0: STA 68:a3:c4:72:f1:b6 WPA: group key handshake completed (RSN)
Wed May 27 11:47:29 2015 daemon.info hostapd: wlan0: STA 84:4b:f5:28:37:d1 WPA: group key handshake completed (RSN)
Wed May 27 11:47:29 2015 daemon.info hostapd: wlan0: STA 34:c0:59:7b:b7:51 WPA: group key handshake completed (RSN)
Wed May 27 11:47:29 2015 daemon.info hostapd: wlan0: STA f8:f1:b6:e9:c2:72 WPA: group key handshake completed (RSN)
Wed May 27 11:47:29 2015 daemon.info hostapd: wlan0: STA 00:61:71:cd:a1:ef WPA: group key handshake completed (RSN)
Wed May 27 11:47:29 2015 daemon.info hostapd: wlan0: STA fc:e9:98:d1:33:39 WPA: group key handshake completed (RSN)
Wed May 27 11:47:29 2015 daemon.info hostapd: wlan0: STA 90:18:7c:32:50:43 WPA: group key handshake completed (RSN)
Wed May 27 11:47:29 2015 daemon.info hostapd: wlan0: STA c4:9a:02:56:6b:84 WPA: group key handshake completed (RSN)
Wed May 27 11:47:29 2015 daemon.info hostapd: wlan0: STA 98:f1:70:08:10:0d WPA: group key handshake completed (RSN)
Wed May 27 11:47:29 2015 daemon.info hostapd: wlan0: STA 8c:3a:e3:6d:03:3b WPA: group key handshake completed (RSN)
Wed May 27 11:47:29 2015 daemon.info hostapd: wlan0: STA 4c:8d:79:b0:66:cd WPA: group key handshake completed (RSN)
Wed May 27 11:47:30 2015 daemon.info hostapd: wlan0: STA 90:72:40:7b:1d:44 WPA: group key handshake completed (RSN)
Wed May 27 11:47:51 2015 daemon.info hostapd: wlan1: STA 80:00:0b:91:1b:5d WPA: group key handshake completed (RSN)
Wed May 27 11:47:52 2015 daemon.info hostapd: wlan1: STA 64:a3:cb:44:66:fa WPA: group key handshake completed (RSN)
Wed May 27 11:47:54 2015 daemon.info hostapd: wlan1: STA 0c:3e:9f:75:52:ff WPA: group key handshake completed (RSN)
Wed May 27 11:50:00 2015 cron.info crond[1025]: USER root pid 28438 cmd /sbin/fan_ctrl.sh
Wed May 27 11:55:00 2015 cron.info crond[1025]: USER root pid 28443 cmd /sbin/fan_ctrl.sh
Wed May 27 11:55:06 2015 kern.err kernel: [1218508.928283] INFO: rcu_sched self-detected stall on CPU { 0}  (t=6000 jiffies g=7147915 c=7147914 q=97)
Wed May 27 11:55:06 2015 kern.info kernel: [1218508.937871] Task dump for CPU 0:
Wed May 27 11:55:06 2015 kern.info kernel: [1218508.941297] kworker/u4:0    R running      0 26554      2 0x00000002
Wed May 27 11:55:06 2015 kern.info kernel: [1218508.947946] Workqueue: phy1 ieee80211_iface_work [mac80211]
Wed May 27 11:55:06 2015 kern.warn kernel: [1218508.953733] Backtrace: 
Wed May 27 11:55:06 2015 kern.warn kernel: [1218508.956397] [<c001ae24>] (dump_backtrace) from [<c001b18c>] (show_stack+0x18/0x1c)
Wed May 27 11:55:06 2015 kern.warn kernel: [1218508.964177]  r6:c044d000 r5:c044d0c0 r4:cde3c400 r3:00000006
Wed May 27 11:55:06 2015 kern.warn kernel: [1218508.970124] [<c001b174>] (show_stack) from [<c0044dd8>] (sched_show_task+0xc8/0xfc)
Wed May 27 11:55:06 2015 kern.warn kernel: [1218508.977993] [<c0044d10>] (sched_show_task) from [<c0046fcc>] (dump_cpu_task+0x40/0x44)
Wed May 27 11:55:06 2015 kern.warn kernel: [1218508.986120]  r5:c044d0c0 r4:00000000
Wed May 27 11:55:06 2015 kern.warn kernel: [1218508.989946] [<c0046f8c>] (dump_cpu_task) from [<c005f550>] (rcu_dump_cpu_stacks+0x70/0xb4)
Wed May 27 11:55:06 2015 kern.warn kernel: [1218508.998423]  r4:00000000 r3:00000001
Wed May 27 11:55:06 2015 kern.warn kernel: [1218509.002237] [<c005f4e0>] (rcu_dump_cpu_stacks) from [<c00620e8>] (rcu_check_callbacks+0x24c/0x668)
Wed May 27 11:55:06 2015 kern.warn kernel: [1218509.011409]  r9:c044d000 r8:c044d000 r7:0f999000 r6:00000061 r5:c0440214 r4:cfdd9214
Wed May 27 11:55:06 2015 kern.warn kernel: [1218509.019457] [<c0061e9c>] (rcu_check_callbacks) from [<c0064190>] (update_process_times+0x48/0x68)
Wed May 27 11:55:06 2015 kern.warn kernel: [1218509.028545]  r10:c046fc80 r9:c046fc80 r8:c046fc00 r7:00000000 r6:00000000 r5:cde3c400
Wed May 27 11:55:06 2015 kern.warn kernel: [1218509.036666]  r4:cde32000
Wed May 27 11:55:06 2015 kern.warn kernel: [1218509.039427] [<c0064148>] (update_process_times) from [<c007224c>] (tick_sched_timer+0x210/0x254)
Wed May 27 11:55:06 2015 kern.warn kernel: [1218509.048426]  r7:cde33808 r6:cfdd9570 r5:00045436 r4:30c4ba64
Wed May 27 11:55:06 2015 kern.warn kernel: [1218509.054357] [<c007203c>] (tick_sched_timer) from [<c0064efc>] (__run_hrtimer.isra.35+0xa8/0x144)
Wed May 27 11:55:06 2015 kern.warn kernel: [1218509.063355]  r10:cfdd9368 r9:00000000 r8:cfdd9378 r7:00000001 r6:cfdd9368 r5:cfdd93a0
Wed May 27 11:55:06 2015 kern.warn kernel: [1218509.071478]  r4:cfdd9570
Wed May 27 11:55:06 2015 kern.warn kernel: [1218509.074223] [<c0064e54>] (__run_hrtimer.isra.35) from [<c00651ac>] (hrtimer_interrupt+0x138/0x2ac)
Wed May 27 11:55:06 2015 kern.warn kernel: [1218509.083394]  r7:00000001 r6:cfdd9368 r5:00045436 r4:30c4ae5c
Wed May 27 11:55:06 2015 kern.warn kernel: [1218509.089339] [<c0065074>] (hrtimer_interrupt) from [<c0266c1c>] (armada_370_xp_timer_interrupt+0x4c/0x54)
Wed May 27 11:55:06 2015 kern.warn kernel: [1218509.099035]  r10:c0487f98 r9:000003ff r8:cfddcc40 r7:00000010 r6:cf80aa00 r5:c04516e8
Wed May 27 11:55:06 2015 kern.warn kernel: [1218509.107143]  r4:cfddcc40
Wed May 27 11:55:06 2015 kern.warn kernel: [1218509.109904] [<c0266bd0>] (armada_370_xp_timer_interrupt) from [<c005bbe8>] (handle_percpu_devid_irq+0x74/0x8c)
Wed May 27 11:55:06 2015 kern.warn kernel: [1218509.120121]  r4:cf803c40 r3:c0266bd0
Wed May 27 11:55:06 2015 kern.warn kernel: [1218509.123936] [<c005bb74>] (handle_percpu_devid_irq) from [<c0057fd0>] (generic_handle_irq+0x34/0x44)

After the "rcu_sched self-detected stall on CPU { 0}" the router is unresponsive and only filling the logs with kern.warn entries.

It also looks like this is relate to the "/sbin/fan_ctrl.sh" more than wireless at this point.

I'm going to change the schedule to once every 15 minutes for /sbin/fan_ctrl.sh crontab and see what happens.

How do you configure your log so that you can grab it post-lockup?

Sorry, posts 5301 to 5300 are missing from our archive.