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.

So I want to populate my MAC-Filter list but have many to add.  If I add them via text editor to /etc/config/wireless, will that survive a reboot?  I would confirm myself with a reboot but kinda want to preserve my uptime while testing.

(Last edited by kirkgbr on 2 Sep 2015, 18:59)

Yes kirkgbr, config changes done in the /etc/config/ directory will be saved even after reboot.

kburk wrote:

Yes kirkgbr, config changes done in the /etc/config/ directory will be saved even after reboot.

Awesome!!! Thanks

It is so darn nice being able to manage this router from the command line and not the gui.  You dev's deserve some HUGE kudo's.

(Last edited by kirkgbr on 2 Sep 2015, 19:38)

@kirkgbr

Unless modified files are under /tmp they will survive reboots.

nitroshift

nitroshift wrote:

@kirkgbr

Unless modified files are under /tmp they will survive reboots.

nitroshift

Good to know.  I wasn't sure if the OS/firmware was like my NAS and rebuilds certain config files from other locations at boot time.

its possible to share usb pendrive on my lan? how i can do that ?

eduzola wrote:

its possible to share usb pendrive on my lan? how i can do that ?

Same as with any openwrt router.  Samba.

Do anybody know if this works, if I want to start from OpenWRT in stock Linksys firmware:

OpenWRT:

fw_printenv boot_part
fw_setenv boot_part 1
fw_printenv boot_part
reboot

The first command gets the current boot partition (which was 2 for me). Second command sets the boot partition to 1. Third command verifies that the boot partition was reset to 1. #Last one reboots into Linksys stock firmware on partition 1?.

Today I read in DD-WRT forum, that this works with DD-WRT firmware.

DD-WRT:

ubootenv get boot_part
ubootenv set boot_part 1
ubootenv get boot_part
reboot

The first command gets the current boot partition (which was 2 for me). Second command sets the boot partition to 1. Third command verifies that the boot partition was reset to 1. Last one reboots into Linksys stock firmware on partition 1.

(Last edited by slan on 3 Sep 2015, 00:57)

It took 16 days for a CPU stall, but captured both of the logs this time.  It was the type of crash that causes the entire router to freeze... No Wifi, can't even ping the gateway. If someone wants more of the logs let me know.

From the Kernel Log.

[1139506.644751] INFO: rcu_sched self-detected stall on CPU { 0}  (t=6000 jiffies g=7831721 c=7831720 q=309)
[1139506.654430] Task dump for CPU 0:
[1139506.657855] kworker/u4:1    R running      0 32761      2 0x00000002
[1139506.664500] Workqueue: phy1 ieee80211_ba_session_work [mac80211]
[1139506.670722] Backtrace:
[1139506.673387] [<c001ae14>] (dump_backtrace) from [<c001b17c>] (show_stack+0x18/0x1c)
[1139506.681167]  r6:c044cfc0 r5:c044d080 r4:ce64f400 r3:00000006
[1139506.687112] [<c001b164>] (show_stack) from [<c0044e64>] (sched_show_task+0xc8/0xfc)
[1139506.694996] [<c0044d9c>] (sched_show_task) from [<c00470fc>] (dump_cpu_task+0x40/0x44)
[1139506.703119]  r5:c044d080 r4:00000000
[1139506.706944] [<c00470bc>] (dump_cpu_task) from [<c005f79c>] (rcu_dump_cpu_stacks+0x70/0xb4)
[1139506.715419]  r4:00000000 r3:00000001
[1139506.719233] [<c005f72c>] (rcu_dump_cpu_stacks) from [<c0062334>] (rcu_check_callbacks+0x24c/0x668)
[1139506.728406]  r9:c044cfc0 r8:c044cfc0 r7:0f99a000 r6:00000135 r5:c043f214 r4:cfdd9214
[1139506.736456] [<c00620e8>] (rcu_check_callbacks) from [<c00643dc>] (update_process_times+0x48/0x68)
[1139506.745543]  r10:c046fa70 r9:c046fa70 r8:c046f9f0 r7:00000000 r6:00000000 r5:ce64f400
[1139506.753651]  r4:ce634000
[1139506.756412] [<c0064394>] (update_process_times) from [<c007250c>] (tick_sched_timer+0x224/0x268)
[1139506.765411]  r7:ce635648 r6:cfdd9570 r5:00040c59 r4:eb87c32c
[1139506.771341] [<c00722e8>] (tick_sched_timer) from [<c0065198>] (__run_hrtimer.isra.35+0xa8/0x144)
[1139506.780339]  r10:cfdd9368 r9:00000000 r8:cfdd9378 r7:00000001 r6:cfdd9368 r5:cfdd93a0
[1139506.788460]  r4:cfdd9570
[1139506.791206] [<c00650f0>] (__run_hrtimer.isra.35) from [<c0065448>] (hrtimer_interrupt+0x138/0x2ac)
[1139506.800377]  r7:00000001 r6:cfdd9368 r5:00040c59 r4:eb87b7ec
[1139506.806320] [<c0065310>] (hrtimer_interrupt) from [<c02653e8>] (armada_370_xp_timer_interrupt+0x4c/0x54)
[1139506.816016]  r10:c0487d58 r9:000003ff r8:cfddcc40 r7:00000010 r6:cf80aa00 r5:c04514f8
[1139506.824125]  r4:cfddcc40
[1139506.826885] [<c026539c>] (armada_370_xp_timer_interrupt) from [<c005be34>] (handle_percpu_devid_irq+0x74/0x8c)
[1139506.837103]  r4:cf803c40 r3:c026539c
[1139506.840919] [<c005bdc0>] (handle_percpu_devid_irq) from [<c005821c>] (generic_handle_irq+0x34/0x44)
[1139506.850179]  r8:cf805000 r7:00000001 r6:ce635d78 r5:00000000 r4:00000010 r3:c005bdc0
[1139506.858230] [<c00581e8>] (generic_handle_irq) from [<c0058524>] (__handle_domain_irq+0x90/0xa4)
[1139506.867143]  r4:c043f8f8 r3:0000005e
[1139506.870955] [<c0058494>] (__handle_domain_irq) from [<c0008698>] (armada_370_xp_handle_irq+0x64/0xe0)
[1139506.880388]  r8:ce635648 r7:00000001 r6:c0487d6c r5:20000153 r4:c0011e14 r3:ce635648
[1139506.888437] [<c0008634>] (armada_370_xp_handle_irq) from [<c00097a0>] (__irq_svc+0x40/0x54)

This was from the system log.

Wed Sep  2 21:51:22 2015 kern.err kernel: [1139506.644751] INFO: rcu_sched self-detected stall on CPU { 0}  (t=6000 jiffies g=7831721 c=7831720 q=309)
Wed Sep  2 21:51:22 2015 kern.info kernel: [1139506.654430] Task dump for CPU 0:
Wed Sep  2 21:51:22 2015 kern.info kernel: [1139506.657855] kworker/u4:1    R running      0 32761      2 0x00000002
Wed Sep  2 21:51:22 2015 kern.info kernel: [1139506.664500] Workqueue: phy1 ieee80211_ba_session_work [mac80211]
Wed Sep  2 21:51:22 2015 kern.warn kernel: [1139506.670722] Backtrace:
Wed Sep  2 21:51:22 2015 kern.warn kernel: [1139506.673387] [<c001ae14>] (dump_backtrace) from [<c001b17c>] (show_stack+0x18/0x1c)
Wed Sep  2 21:51:22 2015 kern.warn kernel: [1139506.681167]  r6:c044cfc0 r5:c044d080 r4:ce64f400 r3:00000006
Wed Sep  2 21:51:22 2015 kern.warn kernel: [1139506.687112] [<c001b164>] (show_stack) from [<c0044e64>] (sched_show_task+0xc8/0xfc)
Wed Sep  2 21:51:22 2015 kern.warn kernel: [1139506.694996] [<c0044d9c>] (sched_show_task) from [<c00470fc>] (dump_cpu_task+0x40/0x44)
Wed Sep  2 21:51:22 2015 kern.warn kernel: [1139506.703119]  r5:c044d080 r4:00000000
Wed Sep  2 21:51:22 2015 kern.warn kernel: [1139506.706944] [<c00470bc>] (dump_cpu_task) from [<c005f79c>] (rcu_dump_cpu_stacks+0x70/0xb4)
Wed Sep  2 21:51:22 2015 kern.warn kernel: [1139506.715419]  r4:00000000 r3:00000001
Wed Sep  2 21:51:22 2015 kern.warn kernel: [1139506.719233] [<c005f72c>] (rcu_dump_cpu_stacks) from [<c0062334>] (rcu_check_callbacks+0x24c/0x668)
Wed Sep  2 21:51:22 2015 kern.warn kernel: [1139506.728406]  r9:c044cfc0 r8:c044cfc0 r7:0f99a000 r6:00000135 r5:c043f214 r4:cfdd9214
Wed Sep  2 21:51:22 2015 kern.warn kernel: [1139506.736456] [<c00620e8>] (rcu_check_callbacks) from [<c00643dc>] (update_process_times+0x48/0x68)
Wed Sep  2 21:51:22 2015 kern.warn kernel: [1139506.745543]  r10:c046fa70 r9:c046fa70 r8:c046f9f0 r7:00000000 r6:00000000 r5:ce64f400
Wed Sep  2 21:51:22 2015 kern.warn kernel: [1139506.753651]  r4:ce634000
Wed Sep  2 21:51:22 2015 kern.warn kernel: [1139506.756412] [<c0064394>] (update_process_times) from [<c007250c>] (tick_sched_timer+0x224/0x268)
Wed Sep  2 21:51:22 2015 kern.warn kernel: [1139506.765411]  r7:ce635648 r6:cfdd9570 r5:00040c59 r4:eb87c32c
Wed Sep  2 21:51:22 2015 kern.warn kernel: [1139506.771341] [<c00722e8>] (tick_sched_timer) from [<c0065198>] (__run_hrtimer.isra.35+0xa8/0x144)
Wed Sep  2 21:51:22 2015 kern.warn kernel: [1139506.780339]  r10:cfdd9368 r9:00000000 r8:cfdd9378 r7:00000001 r6:cfdd9368 r5:cfdd93a0
Wed Sep  2 21:51:22 2015 kern.warn kernel: [1139506.788460]  r4:cfdd9570
Wed Sep  2 21:51:22 2015 kern.warn kernel: [1139506.791206] [<c00650f0>] (__run_hrtimer.isra.35) from [<c0065448>] (hrtimer_interrupt+0x138/0x2ac)
Wed Sep  2 21:51:22 2015 kern.warn kernel: [1139506.800377]  r7:00000001 r6:cfdd9368 r5:00040c59 r4:eb87b7ec
Wed Sep  2 21:51:22 2015 kern.warn kernel: [1139506.806320] [<c0065310>] (hrtimer_interrupt) from [<c02653e8>] (armada_370_xp_timer_interrupt+0x4c/0x54)
Wed Sep  2 21:51:22 2015 kern.warn kernel: [1139506.816016]  r10:c0487d58 r9:000003ff r8:cfddcc40 r7:00000010 r6:cf80aa00 r5:c04514f8
Wed Sep  2 21:51:22 2015 kern.warn kernel: [1139506.824125]  r4:cfddcc40
Wed Sep  2 21:51:22 2015 kern.warn kernel: [1139506.826885] [<c026539c>] (armada_370_xp_timer_interrupt) from [<c005be34>] (handle_percpu_devid_irq+0x74/0x8c)
Wed Sep  2 21:51:22 2015 kern.warn kernel: [1139506.837103]  r4:cf803c40 r3:c026539c
Wed Sep  2 21:51:22 2015 kern.warn kernel: [1139506.840919] [<c005bdc0>] (handle_percpu_devid_irq) from [<c005821c>] (generic_handle_irq+0x34/0x44)
Wed Sep  2 21:51:22 2015 kern.warn kernel: [1139506.850179]  r8:cf805000 r7:00000001 r6:ce635d78 r5:00000000 r4:00000010 r3:c005bdc0
Wed Sep  2 21:51:22 2015 kern.warn kernel: [1139506.858230] [<c00581e8>] (generic_handle_irq) from [<c0058524>] (__handle_domain_irq+0x90/0xa4)
Wed Sep  2 21:51:22 2015 kern.warn kernel: [1139506.867143]  r4:c043f8f8 r3:0000005e
Wed Sep  2 21:51:22 2015 kern.warn kernel: [1139506.870955] [<c0058494>] (__handle_domain_irq) from [<c0008698>] (armada_370_xp_handle_irq+0x64/0xe0)
Wed Sep  2 21:51:22 2015 kern.warn kernel: [1139506.880388]  r8:ce635648 r7:00000001 r6:c0487d6c r5:20000153 r4:c0011e14 r3:ce635648
Wed Sep  2 21:51:22 2015 kern.warn kernel: [1139506.888437] [<c0008634>] (armada_370_xp_handle_irq) from [<c00097a0>] (__irq_svc+0x40/0x54)
Wed Sep  2 21:51:22 2015 kern.warn kernel: [1139506.897002] Exception stack(0xce635648 to 0xce635690)

(Last edited by davidc502 on 3 Sep 2015, 04:18)

davidc502 wrote:

It took 16 days for a CPU stall, but captured both of the logs this time.  It was the type of crash that causes the entire router to freeze... No Wifi, can't even ping the gateway. If someone wants more of the logs let me know.

From the Kernel Log.

post it to https://github.com/kaloz/mwlwifi/issues

davidc502 wrote:

It took 16 days for a CPU stall, but captured both of the logs this time.  It was the type of crash that causes the entire router to freeze... No Wifi, can't even ping the gateway. If someone wants more of the logs let me know.

From the Kernel Log.

[1139506.644751] INFO: rcu_sched self-detected stall on CPU { 0}  (t=6000 jiffies g=7831721 c=7831720 q=309)
[1139506.654430] Task dump for CPU 0:
[1139506.657855] kworker/u4:1    R running      0 32761      2 0x00000002
[1139506.664500] Workqueue: phy1 ieee80211_ba_session_work [mac80211]


You've experienced issue #21 https://github.com/kaloz/mwlwifi/issues/21

redbeard2 wrote:

All,

I'm running RC3 (vanilla, straight downloaded image) on a wrt1900ac v2. If I'm in the same room as the router, 802.11ac performs very well. However, if I step just a room or two away, instead of 200+ Mbps I drop to around 3-5 Mbps. Contrast this with the 802.11n radio, which still performs very well no matter where I go in my house.

I thought 802.11ac was supposed to have at least the range of 802.11n? Is this a known problem with openwrt on the wrt1900ac? If it's known and is on the plan to be fixed, I'll live with it for now. However, if it's just a limitation of 802.11ac, then I'm not sure the money I spent on this router is worth it.

If it's a known openwrt issue, are there some settings I can tweak?

Thanks guys. I really love openwrt and hope there's a fix I can take advantage of.

That does seem a drastic drop, but a 5GHz signal will suffer much higher attenuation through walls / round corners compared with 2.5GHz, so I would expect the data throughput at a given range to be lower with 5GHz. So 5GHz /802.11ac is best suited to providing higher data rates than 2.5Ghz/802.11n but at shorter ranges, IMX.

nyt wrote:
davidc502 wrote:

It took 16 days for a CPU stall, but captured both of the logs this time.  It was the type of crash that causes the entire router to freeze... No Wifi, can't even ping the gateway. If someone wants more of the logs let me know.

From the Kernel Log.

post it to https://github.com/kaloz/mwlwifi/issues

Appended to issue #21

davidc502 wrote:

It took 16 days for a CPU stall, but captured both of the logs this time.  It was the type of crash that causes the entire router to freeze... No Wifi, can't even ping the gateway. If someone wants more of the logs let me know.

From the Kernel Log.

[1139506.644751] INFO: rcu_sched self-detected stall on CPU { 0}  (t=6000 jiffies g=7831721 c=7831720 q=309)
[1139506.654430] Task dump for CPU 0:
[1139506.657855] kworker/u4:1    R running      0 32761      2 0x00000002
[1139506.664500] Workqueue: phy1 ieee80211_ba_session_work [mac80211]

5ghz wifi

gufus wrote:
davidc502 wrote:

It took 16 days for a CPU stall, but captured both of the logs this time.  It was the type of crash that causes the entire router to freeze... No Wifi, can't even ping the gateway. If someone wants more of the logs let me know.

From the Kernel Log.

[1139506.644751] INFO: rcu_sched self-detected stall on CPU { 0}  (t=6000 jiffies g=7831721 c=7831720 q=309)
[1139506.654430] Task dump for CPU 0:
[1139506.657855] kworker/u4:1    R running      0 32761      2 0x00000002
[1139506.664500] Workqueue: phy1 ieee80211_ba_session_work [mac80211]

5ghz wifi

Yeah, I believe 5ghz has always been the culprit for me.

davidc502 wrote:
gufus wrote:
davidc502 wrote:

It took 16 days for a CPU stall, but captured both of the logs this time.  It was the type of crash that causes the entire router to freeze... No Wifi, can't even ping the gateway. If someone wants more of the logs let me know.

From the Kernel Log.

[1139506.644751] INFO: rcu_sched self-detected stall on CPU { 0}  (t=6000 jiffies g=7831721 c=7831720 q=309)
[1139506.654430] Task dump for CPU 0:
[1139506.657855] kworker/u4:1    R running      0 32761      2 0x00000002
[1139506.664500] Workqueue: phy1 ieee80211_ba_session_work [mac80211]

5ghz wifi

Yeah, I believe 5ghz has always been the culprit for me.

I found that putting 5Ghz on cpu 1 and 2.4Ghz on cpu 0 solves this in McWRT which is in the current base config.

Chadster766 wrote:
davidc502 wrote:
gufus wrote:

5ghz wifi

Yeah, I believe 5ghz has always been the culprit for me.

I found that putting 5Ghz on cpu 1 and 2.4Ghz on cpu 0 solves this in McWRT which is in the current base config.

How can we configure to put 5Ghz on cpu 1 and 2.4Ghz on cpu 0?

First find out which cpu they are on now:
cat /proc/interrupts

Then change them as shown in the example below in a startup or rc.local script:

echo 2 > /proc/irq/60/smp_affinity
echo 2 > /proc/irq/46/smp_affinity
sleep 1

1 = cpu0, 2=cpu1, 3=both cpu

(Last edited by Chadster766 on 3 Sep 2015, 22:57)

davidc502 wrote:
gufus wrote:
davidc502 wrote:

It took 16 days for a CPU stall, but captured both of the logs this time.  It was the type of crash that causes the entire router to freeze... No Wifi, can't even ping the gateway. If someone wants more of the logs let me know.

From the Kernel Log.

[1139506.644751] INFO: rcu_sched self-detected stall on CPU { 0}  (t=6000 jiffies g=7831721 c=7831720 q=309)
[1139506.654430] Task dump for CPU 0:
[1139506.657855] kworker/u4:1    R running      0 32761      2 0x00000002
[1139506.664500] Workqueue: phy1 ieee80211_ba_session_work [mac80211]

5ghz wifi

Yeah, I believe 5ghz has always been the culprit for me.

I'm optimistic marvell.com will find this bug.

Chadster766 wrote:
davidc502 wrote:
gufus wrote:

5ghz wifi

Yeah, I believe 5ghz has always been the culprit for me.

I found that putting 5Ghz on cpu 1 and 2.4Ghz on cpu 0 solves this in McWRT which is in the current base config.

Do you think it might help in RC3?

gufus wrote:
Chadster766 wrote:
davidc502 wrote:

Yeah, I believe 5ghz has always been the culprit for me.

I found that putting 5Ghz on cpu 1 and 2.4Ghz on cpu 0 solves this in McWRT which is in the current base config.

Do you think it might help in RC3?

Give it a try,  I look forward to your results.

Chadster766 wrote:
gufus wrote:
Chadster766 wrote:

I found that putting 5Ghz on cpu 1 and 2.4Ghz on cpu 0 solves this in McWRT which is in the current base config.

Do you think it might help in RC3?

Give it a try,  I look forward to your results.

I just set it up. each band on different CPU. Usually, I got lockup daily. We'll see.

Chadster766 wrote:
gufus wrote:
Chadster766 wrote:

I found that putting 5Ghz on cpu 1 and 2.4Ghz on cpu 0 solves this in McWRT which is in the current base config.

Do you think it might help in RC3?

Give it a try,  I look forward to your results.

It's up ...

 70:          0          0  f1018140.gpio   1  gpio_keys
 87:        181     159395  armada_370_xp_irq  59  mwlwifi (5ghz)
 88:     104622          0  armada_370_xp_irq  60  mwlwifi (2.4ghz)
 89:          2          0  armada_370_xp_irq  51  f1060900.xor

I'm just trying this as well, but my wifis are on interrupt 88, 89.
In the example/gufus example they are 87,88 -- do they stay consistent on a reboot, or should the script setting their affinity grep for "armada_370_xp_irq  59" and flip the irq on the output?

I grepped it, just in case

echo 2 > /proc/irq/`cat /proc/interrupts | grep 'armada_370_xp_irq  59' | cut -f1 -d':' | cut -f2 -d' '`/smp_affinity

(Last edited by IvanRaide on 4 Sep 2015, 13:27)

IvanRaide wrote:

I'm just trying this as well, but my wifis are on interrupt 88, 89.
In the example/gufus example they are 87,88 -- do they stay consistent on a reboot, or should the script setting their affinity grep for "armada_370_xp_irq  59" and flip the irq on the output?

I grepped it, just in case

echo 2 > /proc/irq/`cat /proc/interrupts | grep 'armada_370_xp_irq  59' | cut -f1 -d':' | cut -f2 -d' '`/smp_affinity

I thought they stayed the same on a firmware version basis but maybe not. Thanks for the script smile