Interesting note. I decided to flash to McWRT. I wanted to start fresh though so I flashed to the stock Linksys first. Once the image was installed, I noticed all my original settings were stored. Everything, wifi SSID, routing tables, everything. I wonder if this could have caused issues? So I did a factory restore, and have gone back to the latest Kaloz build. We'll see if that cures the issue...
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.
Page 113 of 598
@j0sh: Mine does that too...I have yet to figure out how it is doing it....but it does not seem to be breaking anything else.
@all: I am trying to use a usb webcam with my router, however the kmod-video-uvc stuff per http://wiki.openwrt.org/doc/howto/webcam, won't install, initially it was clear to me why, the custom images that people are making(eg Kaloz) were running a kernel different than the one in trunk. Now they are running the same version of the kernel, but I still can't add the usb uvc stuff...thoughts?
@jOsh: I'd like to be bored with the details of how you got syslog to work! I have been trying to figure out how to get remote (port 514) logging to work for WallWatcher with no luck yet. In the past I just used syslogd with no complaints but it has been discontinued for some reason.
Charlie
cblackxyzzy wrote:
@jOsh: I'd like to be bored with the details of how you got syslog to work! I have been trying to figure out how to get remote (port 514) logging to work for WallWatcher with no luck yet. In the past I just used syslogd with no complaints but it has been discontinued for some reason.
Charlie
Getting it to work on the router (client) side wasn't the issue unfortunately. I use a Synology NAS as my syslog server. Looks like there's a nasty bug in the latest version that precludes used from reading the logs from external devices. I can see the last 50 syslog entries that the server receives, but I can't search for a specific device and export the log file. I had to try and parse out the data from the actual .db file. It was ugly. As far as the router is concerned, simply point the syslog to your server ip and port and reboot. That's the only hang up I had. There's no indication that a reboot is required, but it is. Otherwise it'll keep looking for the old syslog server. There may be a way to recycle the syslog service, but I couldn't find it.
j0sh wrote:
OK, I may have something on this random lock up issue. I was finally able to open the syslog (I won't bore anyone on the details, but it was a major pain). I noticed this line prior to the lock up:
kernel: [ 9232.661995] INFO: rcu_sched self-detected stall on CPU { 0} (t=6000 jiffies g=69848 c=69847 q=459)ÅWá ##!
It only appears on the full debug syslog. It's followed by a TON of kernel entries, and what appear to be errors (just an example):
kernel: [ 9232.906695] Exception stack(0xcf257438 to 0xcf257480)
kernel: [ 9232.898312] [<c0008634>] (armada_370_xp_handle_irq) from [<c00097a0>]
That exception dump is a problem.
I think you should log an issue at the mwlwifi github repository so that the Marvel people can get a look at the dump.
I wouldn't mind seeing too, although working out what went wrong is usually quite hard.
Can you post the log between the "cut here" surrounded by square brackets and the similar "end ..." also surrounded by square brackets. I don't have another exception dump handy to give you the exact bracketed messages marking the beginning and end but they should be fairly obvious.
j0sh wrote:
and a few syslog errors:
syslog: plugin_load: Could not find plugin "df" in /usr/lib/collectd
syslog: plugin_load: Could not find plugin "cpu" in /usr/lib/collectd
Don't think these are important.
I've seen them too and they look like they're due to missing dependencies for collectd.
j0sh wrote:
Again, those are just a sample. I'm completely at a loss on this. I'm thinking I should reflash the Linksys FW, and then flash OpenWRT once again. However, it really is a pain to redefine all my routing rules, so I want to make sure I do this as few times as possible! Wondering if I should go back to McWRT.
If you get a kernel exception, especially in something like the wifi interrupt handler as it is here, that's pretty much fatal and must be fixed, 
Ian
raven-au wrote:
j0sh wrote:OK, I may have something on this random lock up issue. I was finally able to open the syslog (I won't bore anyone on the details, but it was a major pain). I noticed this line prior to the lock up:
kernel: [ 9232.661995] INFO: rcu_sched self-detected stall on CPU { 0} (t=6000 jiffies g=69848 c=69847 q=459)ÅWá ##!
It only appears on the full debug syslog. It's followed by a TON of kernel entries, and what appear to be errors (just an example):
kernel: [ 9232.906695] Exception stack(0xcf257438 to 0xcf257480)
kernel: [ 9232.898312] [<c0008634>] (armada_370_xp_handle_irq) from [<c00097a0>]That exception dump is a problem.
I think you should log an issue at the mwlwifi github repository so that the Marvel people can get a look at the dump.I wouldn't mind seeing too, although working out what went wrong is usually quite hard.
Can you post the log between the "cut here" surrounded by square brackets and the similar "end ..." also surrounded by square brackets. I don't have another exception dump handy to give you the exact bracketed messages marking the beginning and end but they should be fairly obvious.j0sh wrote:and a few syslog errors:
syslog: plugin_load: Could not find plugin "df" in /usr/lib/collectd
syslog: plugin_load: Could not find plugin "cpu" in /usr/lib/collectdDon't think these are important.
I've seen them too and they look like they're due to missing dependencies for collectd.j0sh wrote:Again, those are just a sample. I'm completely at a loss on this. I'm thinking I should reflash the Linksys FW, and then flash OpenWRT once again. However, it really is a pain to redefine all my routing rules, so I want to make sure I do this as few times as possible! Wondering if I should go back to McWRT.
If you get a kernel exception, especially in something like the wifi interrupt handler as it is here, that's pretty much fatal and must be fixed,
Ian
Man, I wish I would have had your input a few hours earlier! I tried re-flashing to stock FW, restoring all settings to default, then installed the Kaloz image. Still kept locking up. I ended up just going back to stock for the time being. Unfortunately I don't have the logs any more. Part of me was hoping that the device would continue to lock up on the stock FW so I could blame the issue on hardware and exchange it for a new device (I still might do that by the way)!
gufus wrote:
DavidMcWRT wrote:gufus wrote:Anyone using kaloz's latest build...
What is the revision number?
r44181
Thx
I'm using this build... I can't turn on the fan any more...
echo 255 > /sys/devices/gpio_fan/hwmon/hwmon0/pwm1
-ash: can't create /sys/devices/gpio_fan/hwmon/hwmon0/pwm1: nonexistent directory
update: the path changed...
echo 255 > /sys/devices/pwm_fan/hwmon/hwmon0/pwm1
(Last edited by digitalgeek on 2 Feb 2015, 17:36)
digitalgeek wrote:
gufus wrote:DavidMcWRT wrote:r44181
Thx
I'm using this build... I can't turn on the fan any more...
echo 255 > /sys/devices/gpio_fan/hwmon/hwmon0/pwm1
-ash: can't create /sys/devices/gpio_fan/hwmon/hwmon0/pwm1: nonexistent directoryupdate: the path changed...
echo 255 > /sys/devices/pwm_fan/hwmon/hwmon0/pwm1
Trunk has been updated now...
http://downloads.openwrt.org/snapshots/ … u/generic/
DISTRIB_ID='OpenWrt'
DISTRIB_RELEASE='Bleeding Edge'
DISTRIB_REVISION='r44233'
DISTRIB_CODENAME='chaos_calmer'
DISTRIB_TARGET='mvebu/generic'
DISTRIB_DESCRIPTION='OpenWrt Chaos Calmer r44233'
DISTRIB_TAINTS=''
ARM OpenWrt Linux-3.18.3
@gufus
Is this a working img with Luci?
openwrt-mvebu-armada-xp-mamba-squashfs-factory.img
Nope.
gufus wrote:
Nope.
ty.
hi
luci install command
edit
/etc/opkg.conf
<
dest root /
dest ram /tmp
lists_dir ext /var/opkg-lists
option overlay_root /overlay
src/gz chaos_calmer_base http://downloads.openwrt.org/snapshots/ … kages/base
#src/gz chaos_calmer_oldpackages http://downloads.openwrt.org/snapshots/ … ldpackages
src/gz chaos_calmer_packages http://downloads.openwrt.org/snapshots/ … s/packages
src/gz chaos_calmer_luci http://downloads.openwrt.org/snapshots/ … kages/luci
# src/gz chaos_calmer_routing http://downloads.openwrt.org/snapshots/ … es/routing
# src/gz chaos_calmer_telephony http://downloads.openwrt.org/snapshots/ … /telephony
# src/gz chaos_calmer_management http://downloads.openwrt.org/snapshots/ … management
>
command
opkg update
opkg install luci
what are the changes? the wifi driver has been updated?
You can check daily progress here: https://dev.openwrt.org/timeline (this doesn't include luci and a few other things that have repositories elsewhere) I don't believe the wifi driver has had any updates yet.
The automatic daily build was broken for a while, first because there was a missing symbol in the mvebu kernel config, and then because a few netfilter modules weren't being packaged properly. Both were recently resolved, and now you will be seeing a brand new build (including packages) built every day from the latest source.
@srkn editing the config file shouldn't be necessary anymore. The builds people are using here apparently predate the change, but anyone using the daily snapshot build can just use 'opkg update' and 'opkg install luci'
j0sh wrote:
raven-au wrote:j0sh wrote:Again, those are just a sample. I'm completely at a loss on this. I'm thinking I should reflash the Linksys FW, and then flash OpenWRT once again. However, it really is a pain to redefine all my routing rules, so I want to make sure I do this as few times as possible! Wondering if I should go back to McWRT.
If you get a kernel exception, especially in something like the wifi interrupt handler as it is here, that's pretty much fatal and must be fixed,
Man, I wish I would have had your input a few hours earlier! I tried re-flashing to stock FW, restoring all settings to default, then installed the Kaloz image. Still kept locking up. I ended up just going back to stock for the time being. Unfortunately I don't have the logs any more. Part of me was hoping that the device would continue to lock up on the stock FW so I could blame the issue on hardware and exchange it for a new device (I still might do that by the way)!
Others see wifi hangs so perhaps we'll see other reports.
Even so, knowing about it and having the backtrace is one thing, fixing it is quite another.
The interrupt service routine is very short (as it should be) and AFAICS doesn't do anything that should take very long so why it's taking a long time is a mystery (assuming that's really what the message means).
Ian
raven-au wrote:
j0sh wrote:raven-au wrote:If you get a kernel exception, especially in something like the wifi interrupt handler as it is here, that's pretty much fatal and must be fixed,
Man, I wish I would have had your input a few hours earlier! I tried re-flashing to stock FW, restoring all settings to default, then installed the Kaloz image. Still kept locking up. I ended up just going back to stock for the time being. Unfortunately I don't have the logs any more. Part of me was hoping that the device would continue to lock up on the stock FW so I could blame the issue on hardware and exchange it for a new device (I still might do that by the way)!
Others see wifi hangs so perhaps we'll see other reports.
Even so, knowing about it and having the backtrace is one thing, fixing it is quite another.
The interrupt service routine is very short (as it should be) and AFAICS doesn't do anything that should take very long so why it's taking a long time is a mystery (assuming that's really what the message means).Ian
Oh, wait, that's not in the wireless driver, mmm ....
I'll have a look around when I get a chance.
j0sh wrote:
OK, I may have something on this random lock up issue. I was finally able to open the syslog (I won't bore anyone on the details, but it was a major pain). I noticed this line prior to the lock up:
kernel: [ 9232.661995] INFO: rcu_sched self-detected stall on CPU { 0} (t=6000 jiffies g=69848 c=69847 q=459)ÅWá ##!
It only appears on the full debug syslog. It's followed by a TON of kernel entries, and what appear to be errors (just an example):
kernel: [ 9232.906695] Exception stack(0xcf257438 to 0xcf257480)
kernel: [ 9232.898312] [<c0008634>] (armada_370_xp_handle_irq) from [<c00097a0>]
And without the backtrace we don't even have the hex offset within the function where it occurred.
It's hard enough to guess where that might be in the source with only the hex offset but without it ...... ;(
raven-au wrote:
j0sh wrote:OK, I may have something on this random lock up issue. I was finally able to open the syslog (I won't bore anyone on the details, but it was a major pain). I noticed this line prior to the lock up:
kernel: [ 9232.661995] INFO: rcu_sched self-detected stall on CPU { 0} (t=6000 jiffies g=69848 c=69847 q=459)ÅWá ##!
It only appears on the full debug syslog. It's followed by a TON of kernel entries, and what appear to be errors (just an example):
kernel: [ 9232.906695] Exception stack(0xcf257438 to 0xcf257480)
kernel: [ 9232.898312] [<c0008634>] (armada_370_xp_handle_irq) from [<c00097a0>]And without the backtrace we don't even have the hex offset within the function where it occurred.
It's hard enough to guess where that might be in the source with only the hex offset but without it ...... ;(
If having this info is helpful I will go pick up another unit tomorrow and try to reproduce the issue and grab the log files. There's a ton of value in having OpenWRT working on this router and anything I can do to help I will.
gufus wrote:
Trunk has been updated now...
http://downloads.openwrt.org/snapshots/ … u/generic/DISTRIB_ID='OpenWrt'
DISTRIB_RELEASE='Bleeding Edge'
DISTRIB_REVISION='r44233'
DISTRIB_CODENAME='chaos_calmer'
DISTRIB_TARGET='mvebu/generic'
DISTRIB_DESCRIPTION='OpenWrt Chaos Calmer r44233'
DISTRIB_TAINTS=''ARM OpenWrt Linux-3.18.3
...I assume this does not include luci?
...if i'm running @kaloz build, I probably need to flash Linksys first?
@digitalgeek
You can safely download the sysupgrade file and use it to update the router.
nitroshift
j0sh wrote:
raven-au wrote:j0sh wrote:OK, I may have something on this random lock up issue. I was finally able to open the syslog (I won't bore anyone on the details, but it was a major pain). I noticed this line prior to the lock up:
kernel: [ 9232.661995] INFO: rcu_sched self-detected stall on CPU { 0} (t=6000 jiffies g=69848 c=69847 q=459)ÅWá ##!
It only appears on the full debug syslog. It's followed by a TON of kernel entries, and what appear to be errors (just an example):
kernel: [ 9232.906695] Exception stack(0xcf257438 to 0xcf257480)
kernel: [ 9232.898312] [<c0008634>] (armada_370_xp_handle_irq) from [<c00097a0>]And without the backtrace we don't even have the hex offset within the function where it occurred.
It's hard enough to guess where that might be in the source with only the hex offset but without it ...... ;(If having this info is helpful I will go pick up another unit tomorrow and try to reproduce the issue and grab the log files. There's a ton of value in having OpenWRT working on this router and anything I can do to help I will.
I had a quick look and this problem would have to be handled by the upstream ARM maintainers, it's probably hardware board specific, I've got no chance of working it out.
There's no guarantee the upstream folks will fix it either so it's probably better to just wait for someone else who has the problem to report it and provide a backtrace.
Ian
nitroshift wrote:
@digitalgeek
You can safely download the sysupgrade file and use it to update the router.
nitroshift
I'm relatively new to Openwrt, so i apologize if this question sounds dumb.
BUT.....if I'm running Kaloz build, the update file won't change any settings or Luci etc., correct?
Either way doesn't matter. I just want to know what to expect.
(Last edited by mojolacerator on 3 Feb 2015, 14:30)
raven-au wrote:
j0sh wrote:raven-au wrote:And without the backtrace we don't even have the hex offset within the function where it occurred.
It's hard enough to guess where that might be in the source with only the hex offset but without it ...... ;(If having this info is helpful I will go pick up another unit tomorrow and try to reproduce the issue and grab the log files. There's a ton of value in having OpenWRT working on this router and anything I can do to help I will.
I had a quick look and this problem would have to be handled by the upstream ARM maintainers, it's probably hardware board specific, I've got no chance of working it out.
There's no guarantee the upstream folks will fix it either so it's probably better to just wait for someone else who has the problem to report it and provide a backtrace.
Ian
Quick question, is there a chance that this could be an issue with the actual hardware? Just seems odd that the issue is so systemic in my environment, but not affecting too many other users; and certainly not as pervasive as mine.
@j0sh
As i said before, my devices are subjected to heavy traffic, both wired and wireless and they lock up very rarely and only on wireless. I would assume your hardware is faulty.
nitroshift
nitroshift wrote:
@j0sh
As i said before, my devices are subjected to heavy traffic, both wired and wireless and they lock up very rarely and only on wireless. I would assume your hardware is faulty.
nitroshift
Well that would mean that my hardware is faulty as well and I don't buy that at all. I can flash CC and configure and it runs fine as long as I don't do an upgrade. The minute the upgrade happens or I restore a backup that was done it takes a few hours and then the lockup of the router happens. I believe there is something software related going on here.
If it was hardware, then the stock linksys firmware would have the same issue or CC would after I flash and configure and it does not. Been running that fine for almost a week after flashing back to the stock linksys and restoring the backup.
(Last edited by dpdurst on 3 Feb 2015, 16:58)
Sorry, posts 2826 to 2825 are missing from our archive.
Page 113 of 598