As per wrtpat comment patch files do not copy/paste well.
irc #openwrt ?
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 367 of 598
hmmm, I thought I was careful.... will try to type it in from scratch in vi....
cheers
I just openend a case about the wifi issue (2 ssids -> wifi crash) on github kaloz. I hope the problem can be fixed^^
so long
Running Very Well So Far:
Hostname OpenWrt
Model Linksys WRT1900ACv2
Firmware Version OpenWrt Designated Driver r47958 / LuCI Branch (git-15.354.35228-edf352e)
Kernel Version 4.4.0-rc6
Local Time Mon Dec 21 14:58:14 2015
Uptime 1h 2m 54s
Load Average 0.00, 0.01, 0.05
@wrtpat and @anomeome
A big thank you to both of you... building now and will take it for a spin to see how it behaves.
Cheers 
@anyone.. How can I use the .13 version mwlwifi with the lates Designated Driver? Do just check out the commit from Kaloz's repo that corresponds to that version? Need a little help with this.
Thanks,
Mike
P.S. thanks to wrtpat for the nand patch!!
mmcneil wrote:
@anyone.. How can I use the .13 version mwlwifi with the lates Designated Driver? Do just check out the commit from Kaloz's repo that corresponds to that version? Need a little help with this.
Thanks,
Mike
P.S. thanks to wrtpat for the nand patch!!
I just built the latest trunk/DD Kernel 4.1.3 with the .13 driver using JohnnySL's instructions over here >> https://forum.openwrt.org/viewtopic.php … 49#p301749
update on my nand issues now that the patch works:
4.1.13 builds are rock solid stable through multiple config changes and reboots.
4.4rc5 is still an unknown... the patch may not be needed as the frequency of crashes on boot seems to have increased.
Cheers
doITright wrote:
update on my nand issues now that the patch works:
4.1.13 builds are rock solid stable through multiple config changes and reboots.
4.4rc5 is still an unknown... the patch may not be needed as the frequency of crashes on boot seems to have increased.
Cheers
Which mwlwifi driver are you using? Approximately how many sirq's/sec are at idle and during use.
im running DD Kernel 4.1.13 and the .13 driver and getting the following:
88: 1974757 0 armada_370_xp_irq 59 Level mwlwifi
89: 0 1600897 armada_370_xp_irq 60 Level mwlwifi
88: 1974840 0 armada_370_xp_irq 59 Level mwlwifi
89: 0 1601044 armada_370_xp_irq 60 Level mwlwifiThe .14 and .15 drivers are at least 3 times those values.
(Last edited by kirkgbr on 22 Dec 2015, 03:46)
kirkgbr wrote:
doITright wrote:update on my nand issues now that the patch works:
4.1.13 builds are rock solid stable through multiple config changes and reboots.
4.4rc5 is still an unknown... the patch may not be needed as the frequency of crashes on boot seems to have increased.
Cheers
Which mwlwifi driver are you using? Approximately how many sirq's/sec are at idle and during use.
im running DD Kernel 4.1.13 and the .13 driver and getting the following:
88: 1974757 0 armada_370_xp_irq 59 Level mwlwifi 89: 0 1600897 armada_370_xp_irq 60 Level mwlwifi 88: 1974840 0 armada_370_xp_irq 59 Level mwlwifi 89: 0 1601044 armada_370_xp_irq 60 Level mwlwifiThe .14 and .15 drivers are at least 3 times those values.
On 4.4rc5 with latest .15 right now
Firmware Version OpenWrt Designated Driver r47958 / LuCI (git-15.343.57108-63155e9)
Kernel Version 4.4.0-rc5
Local Time Mon Dec 21 21:54:35 2015
Uptime 0h 30m 25s
Load Average 0.00, 0.01, 0.03
root@WRT1900AC-P:~# sensors
tmp421-i2c-0-4c
Adapter: mv64xxx_i2c adapter
temp1: +37.8°C
temp2: +38.4°C
armada_thermal-virtual-0
Adapter: Virtual device
temp1: +47.2°C
root@WRT1900AC-P:~# grep mwl /proc/interrupts ; sleep 1; grep mwl /proc/interrup
ts
90: 3391787 0 armada_370_xp_irq 59 Level mwlwifi
91: 3296249 0 armada_370_xp_irq 60 Level mwlwifi
90: 3393814 0 armada_370_xp_irq 59 Level mwlwifi
91: 3298223 0 armada_370_xp_irq 60 Level mwlwifi
root@WRT1900AC-P:~#
The softirqs are still there but core0/1 are almost nil at idle
Need to play around with it for a bit.... may try it with .13 if ping times have not improved....
Cheers
doITright wrote:
kirkgbr wrote:doITright wrote:update on my nand issues now that the patch works:
4.1.13 builds are rock solid stable through multiple config changes and reboots.
4.4rc5 is still an unknown... the patch may not be needed as the frequency of crashes on boot seems to have increased.
Cheers
Which mwlwifi driver are you using? Approximately how many sirq's/sec are at idle and during use.
im running DD Kernel 4.1.13 and the .13 driver and getting the following:
88: 1974757 0 armada_370_xp_irq 59 Level mwlwifi 89: 0 1600897 armada_370_xp_irq 60 Level mwlwifi 88: 1974840 0 armada_370_xp_irq 59 Level mwlwifi 89: 0 1601044 armada_370_xp_irq 60 Level mwlwifiThe .14 and .15 drivers are at least 3 times those values.
On 4.4rc5 with latest .15 right now
Firmware Version OpenWrt Designated Driver r47958 / LuCI (git-15.343.57108-63155e9)
Kernel Version 4.4.0-rc5
Local Time Mon Dec 21 21:54:35 2015
Uptime 0h 30m 25s
Load Average 0.00, 0.01, 0.03root@WRT1900AC-P:~# sensors
tmp421-i2c-0-4c
Adapter: mv64xxx_i2c adapter
temp1: +37.8°C
temp2: +38.4°Carmada_thermal-virtual-0
Adapter: Virtual device
temp1: +47.2°Croot@WRT1900AC-P:~# grep mwl /proc/interrupts ; sleep 1; grep mwl /proc/interrup
ts
90: 3391787 0 armada_370_xp_irq 59 Level mwlwifi
91: 3296249 0 armada_370_xp_irq 60 Level mwlwifi
90: 3393814 0 armada_370_xp_irq 59 Level mwlwifi
91: 3298223 0 armada_370_xp_irq 60 Level mwlwifi
root@WRT1900AC-P:~#The softirqs are still there but core0/1 are almost nil at idle
Need to play around with it for a bit.... may try it with .13 if ping times have not improved....
Cheers
Thanks -- and be sure to report back ping times for wireless.
I'm running 4.4.0-rc5 with the .13 version of mwlwifi and I'm seeing high temps:
root@OpenWrt:~# uname -a
Linux OpenWrt 4.4.0-rc5 #1 SMP Mon Dec 21 22:14:10 PST 2015 armv7l GNU/Linux
root@OpenWrt:~# sensors
tmp421-i2c-0-4c
Adapter: mv64xxx_i2c adapter
temp1: +45.7°C
temp2: +47.8°C
armada_thermal-virtual-0
Adapter: Virtual device
temp1: +71.8°C
I noticed that I didn't have the pwm-fan module installed so I'm rebuilding to include it. Are these temps normal for the wrt1200ac? I'm guessing no. What else can I do to lower the temps? Thanks to kirkgbr for the tip on using the .13 wifi driver.
Mike
mmcneil wrote:
I noticed that I didn't have the pwm-fan module installed so I'm rebuilding to include it. Are these temps normal for the wrt1200ac? I'm guessing no. What else can I do to lower the temps? Thanks to kirkgbr for the tip on using the .13 wifi driver.
Mike
Credit goes to JohnnySL 
mmcneil wrote:
...I noticed that I didn't have the pwm-fan module installed so I'm rebuilding to include it. Are these temps normal for the wrt1200ac?
You may not benefit from doing that. I don't think the wrt1200ac hardware includes a fan.
(Last edited by wrtpat on 22 Dec 2015, 15:20)
wrtpat wrote:
mmcneil wrote:...I noticed that I didn't have the pwm-fan module installed so I'm rebuilding to include it. Are these temps normal for the wrt1200ac?
You may not benefit from doing that. I don't think the wrt1200ac hardware includes a fan.
wrtpat is correct. No fan in 1200ac. I should have caught that 
wrtpat wrote:
I like to use 'top' to get a sense for per-core CPU utilization (esp. sirq, given the recent developments in the mwlwifi driver).
I'm using the procps-ng impl of top (as opposed to the busybox impl) in my image. I'm noticing that top is not correctly showing any of the CPU metrics. Everything is zeros. What the heck. Anyone else seeing this?root@OpenWrt:~# uname -a ; cat /etc/openwrt_version
Linux OpenWrt 4.4.0-rc5 #7 SMP Sat Dec 19 22:37:54 MST 2015 armv7l GNU/Linux
r47953root@OpenWrt:~# top -v
procps-ng 3.3.11top - 13:28:37 up 14:46, 0 users, load average: 0.06, 0.07, 0.05 Tasks: 81 total, 1 running, 80 sleeping, 0 stopped, 0 zombie %Cpu0 : 0.0 us, 0.0 sy, 0.0 ni,100.0 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st %Cpu1 : 0.0 us, 0.0 sy, 0.0 ni,100.0 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st KiB Mem : 254720 total, 187632 free, 35508 used, 31580 buff/cache KiB Swap: 0 total, 0 free, 0 used. 181904 avail Mem PID USER PR NI VIRT RES %CPU %MEM TIME+ S COMMAND 1 root 20 0 1364 720 0.0 0.3 0:00.00 S procd 2 root 20 0 0 0 0.0 0.0 0:00.00 S kthreadd 3 root 20 0 0 0 0.0 0.0 0:00.00 S ksoftirqd/0 4 root 20 0 0 0 0.0 0.0 0:00.00 S kworker/0:0 5 root 0 -20 0 0 0.0 0.0 0:00.00 S kworker/0:0H 6 root 20 0 0 0 0.0 0.0 0:00.00 S kworker/u4:0 7 root 20 0 0 0 0.0 0.0 0:00.00 S rcu_sched 8 root 20 0 0 0 0.0 0.0 0:00.00 S rcu_bh 9 root rt 0 0 0 0.0 0.0 0:00.00 S migration/0 10 root rt 0 0 0 0.0 0.0 0:00.00 S migration/1 11 root 20 0 0 0 0.0 0.0 0:00.00 S ksoftirqd/1 12 root 20 0 0 0 0.0 0.0 0:00.00 S kworker/1:0 13 root 0 -20 0 0 0.0 0.0 0:00.00 S kworker/1:0H 128 root 0 -20 0 0 0.0 0.0 0:00.00 S writeback 129 root 0 -20 0 0 0.0 0.0 0:00.00 S crypto 131 root 0 -20 0 0 0.0 0.0 0:00.00 S bioset 132 root 0 -20 0 0 0.0 0.0 0:00.00 S kblockd 148 root 20 0 0 0 0.0 0.0 0:00.00 S kworker/0:1 169 root 20 0 0 0 0.0 0.0 0:00.00 S kswapd0 170 root 0 -20 0 0 0.0 0.0 0:00.00 S vmstat 171 root 20 0 0 0 0.0 0.0 0:00.00 S fsnotify_mark 213 root -51 0 0 0 0.0 0.0 0:00.00 S irq/30-f10d0000 217 root 0 -20 0 0 0.0 0.0 0:00.00 S bioset 222 root 0 -20 0 0 0.0 0.0 0:00.00 S bioset 227 root 0 -20 0 0 0.0 0.0 0:00.00 S bioset 232 root 0 -20 0 0 0.0 0.0 0:00.00 S bioset 237 root 0 -20 0 0 0.0 0.0 0:00.00 S bioset 242 root 0 -20 0 0 0.0 0.0 0:00.00 S bioset 247 root 0 -20 0 0 0.0 0.0 0:00.00 S bioset 252 root 0 -20 0 0 0.0 0.0 0:00.00 S bioset 257 root 0 -20 0 0 0.0 0.0 0:00.00 S bioset 262 root 0 -20 0 0 0.0 0.0 0:00.00 S bioset 267 root 20 0 0 0 0.0 0.0 0:00.00 S spi0 272 root 0 -20 0 0 0.0 0.0 0:00.00 S bioset
I think I've gotten to the bottom of this issue.
This is not an issue specific to Linksys WRT1900AC. It most likely affects anyone using latest trunk on a supported platform... but I'll post my workaround here, incase it helps someone.
It looks like (IMHO) the procps-ng code has a bug.
The code is using invalid format specifiers in calls to the 'sscanf' stdio C library function.
Certain data items are being classified as 'long double' rather than 'long long unsigned'
This code in proc/readproc.c
.
.
. line #570
num = sscanf(S,
"%c "
"%d %d %d %d %d "
"%lu %lu %lu %lu %lu "
"%Lu %Lu %Lu %Lu " /* utime stime cutime cstime */
"%ld %ld "
"%d "
"%ld "
"%Lu " /* start_time */
"%lu "
"%ld "
"%lu %"KLF"u %"KLF"u %"KLF"u %"KLF"u %"KLF"u "
"%*s %*s %*s %*s " /* discard, no RT signals & Linux 2.1 used hex */
"%"KLF"u %*u %*u "
"%d %d "
"%lu %lu",
&P->state,
&P->ppid, &P->pgrp, &P->session, &P->tty, &P->tpgid,
&P->flags, &P->min_flt, &P->cmin_flt, &P->maj_flt, &P->cmaj_flt,
&P->utime, &P->stime, &P->cutime, &P->cstime,
&P->priority, &P->nice,
&P->nlwp,
&P->alarm,
&P->start_time,
&P->vsize,
&P->rss,
&P->rss_rlim, &P->start_code, &P->end_code, &P->start_stack, &P->kstk_esp, &P->kstk_eip,
/* P->signal, P->blocked, P->sigignore, P->sigcatch, */ /* can't use */
&P->wchan, /* &P->nswap, &P->cnswap, */ /* nswap and cnswap dead for 2.4.xx and up */
/* -- Linux 2.0.35 ends here -- */
&P->exit_signal, &P->processor, /* 2.2.1 ends with "exit_signal" */
/* -- Linux 2.2.8 to 2.5.17 end here -- */
&P->rtprio, &P->sched /* both added to 2.5.18 */
);
.
.
.should be (Notice: all occurrences of %Lu have been changed to %llu)
.
.
. line #570
num = sscanf(S,
"%c "
"%d %d %d %d %d "
"%lu %lu %lu %lu %lu "
"%llu %llu %llu %llu " /* utime stime cutime cstime */
"%ld %ld "
"%d "
"%ld "
"%llu " /* start_time */
"%lu "
"%ld "
"%lu %"KLF"u %"KLF"u %"KLF"u %"KLF"u %"KLF"u "
"%*s %*s %*s %*s " /* discard, no RT signals & Linux 2.1 used hex */
"%"KLF"u %*u %*u "
"%d %d "
"%lu %lu",
&P->state,
&P->ppid, &P->pgrp, &P->session, &P->tty, &P->tpgid,
&P->flags, &P->min_flt, &P->cmin_flt, &P->maj_flt, &P->cmaj_flt,
&P->utime, &P->stime, &P->cutime, &P->cstime,
&P->priority, &P->nice,
&P->nlwp,
&P->alarm,
&P->start_time,
&P->vsize,
&P->rss,
&P->rss_rlim, &P->start_code, &P->end_code, &P->start_stack, &P->kstk_esp, &P->kstk_eip,
/* P->signal, P->blocked, P->sigignore, P->sigcatch, */ /* can't use */
&P->wchan, /* &P->nswap, &P->cnswap, */ /* nswap and cnswap dead for 2.4.xx and up */
/* -- Linux 2.0.35 ends here -- */
&P->exit_signal, &P->processor, /* 2.2.1 ends with "exit_signal" */
/* -- Linux 2.2.8 to 2.5.17 end here -- */
&P->rtprio, &P->sched /* both added to 2.5.18 */
);
.
.
.Same goes for calls to 'sscanf' in top/top.c
This code
.
.
. line #2388
if (4 > sscanf(bp, "cpu %Lu %Lu %Lu %Lu %Lu %Lu %Lu %Lu"
, &sum_ptr->cur.u, &sum_ptr->cur.n, &sum_ptr->cur.s
, &sum_ptr->cur.i, &sum_ptr->cur.w, &sum_ptr->cur.x
, &sum_ptr->cur.y, &sum_ptr->cur.z))
error_exit(N_txt(FAIL_statget_txt));
.
.
. line #2419
if (4 > sscanf(bp, "cpu%d %Lu %Lu %Lu %Lu %Lu %Lu %Lu %Lu", &cpu_ptr->id
, &cpu_ptr->cur.u, &cpu_ptr->cur.n, &cpu_ptr->cur.s
, &cpu_ptr->cur.i, &cpu_ptr->cur.w, &cpu_ptr->cur.x
, &cpu_ptr->cur.y, &cpu_ptr->cur.z)) {
memmove(cpu_ptr, sum_ptr, sizeof(CPU_t));
break; // tolerate cpus taken offline
}
.
.
.should be (Notice: all occurrences of %Lu have been changed to %llu)
.
.
. line #2388
if (4 > sscanf(bp, "cpu %llu %llu %llu %llu %llu %llu %llu %llu"
, &sum_ptr->cur.u, &sum_ptr->cur.n, &sum_ptr->cur.s
, &sum_ptr->cur.i, &sum_ptr->cur.w, &sum_ptr->cur.x
, &sum_ptr->cur.y, &sum_ptr->cur.z))
error_exit(N_txt(FAIL_statget_txt));
.
.
. line #2419
if (4 > sscanf(bp, "cpu%d %llu %llu %llu %llu %llu %llu %llu %llu", &cpu_ptr->id
, &cpu_ptr->cur.u, &cpu_ptr->cur.n, &cpu_ptr->cur.s
, &cpu_ptr->cur.i, &cpu_ptr->cur.w, &cpu_ptr->cur.x
, &cpu_ptr->cur.y, &cpu_ptr->cur.z)) {
memmove(cpu_ptr, sum_ptr, sizeof(CPU_t));
break; // tolerate cpus taken offline
}
.
.
.After making those simple changes, and recompiling... the top command now correctly shows CPU times & percentages
top - 11:34:06 up 2 days, 12:52, 0 users, load average: 0.10, 0.06, 0.06
Tasks: 83 total, 1 running, 82 sleeping, 0 stopped, 0 zombie
%Cpu0 : 1.4 us, 0.8 sy, 0.0 ni, 96.7 id, 0.0 wa, 0.0 hi, 1.1 si, 0.0 st
%Cpu1 : 1.3 us, 2.7 sy, 0.0 ni, 96.0 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
KiB Mem : 254720 total, 166520 free, 35988 used, 52212 buff/cache
KiB Swap: 0 total, 0 free, 0 used. 172832 avail Mem
PID USER PR NI VIRT RES %CPU %MEM TIME+ S COMMAND
23380 root 20 0 1152 728 1.3 0.3 0:00.22 S luci-bwc
1697 root 20 0 1560 100 0.4 0.0 20:42.68 S hostapd
6035 root 20 0 0 0 0.4 0.0 0:01.58 S kworker/u4:1
11424 root 20 0 1784 1040 0.3 0.4 0:22.70 R top
1823 nobody 20 0 3240 3040 0.1 1.2 2:03.52 S dnsmasq
1660 root 20 0 772 520 0.1 0.2 0:11.26 S vnstatd
596 root 20 0 1352 856 0.1 0.3 1:01.79 S ubusd
8 root 20 0 0 0 0.0 0.0 0:00.16 S rcu_bh
7 root 20 0 0 0 0.0 0.0 0:36.88 S rcu_sched
11 root 20 0 0 0 0.0 0.0 0:07.12 S ksoftirqd/1
12 root 20 0 0 0 0.0 0.0 0:08.45 S kworker/1:0
13 root 0 -20 0 0 0.0 0.0 0:00.00 S kworker/1:0H
128 root 0 -20 0 0 0.0 0.0 0:00.00 S writeback
129 root 0 -20 0 0 0.0 0.0 0:00.00 S crypto
9 root rt 0 0 0 0.0 0.0 0:00.55 S migration/0
132 root 0 -20 0 0 0.0 0.0 0:00.00 S kblockd
148 root 20 0 0 0 0.0 0.0 0:00.25 S kworker/0:1
169 root 20 0 0 0 0.0 0.0 0:00.00 S kswapd0
170 root 0 -20 0 0 0.0 0.0 0:00.00 S vmstat
171 root 20 0 0 0 0.0 0.0 0:00.00 S fsnotify_mark
213 root -51 0 0 0 0.0 0.0 0:01.10 S irq/30-f10d0000
217 root 0 -20 0 0 0.0 0.0 0:00.00 S bioset
222 root 0 -20 0 0 0.0 0.0 0:00.00 S bioset
227 root 0 -20 0 0 0.0 0.0 0:00.00 S bioset
4 root 20 0 0 0 0.0 0.0 0:20.61 S kworker/0:0
237 root 0 -20 0 0 0.0 0.0 0:00.00 S bioset
242 root 0 -20 0 0 0.0 0.0 0:00.00 S bioset
247 root 0 -20 0 0 0.0 0.0 0:00.00 S bioset
252 root 0 -20 0 0 0.0 0.0 0:00.00 S bioset
257 root 0 -20 0 0 0.0 0.0 0:00.00 S bioset
262 root 0 -20 0 0 0.0 0.0 0:00.00 S bioset
267 root 20 0 0 0 0.0 0.0 0:00.00 S spi0
272 root 0 -20 0 0 0.0 0.0 0:00.00 S bioset I will see if I can get the up-stream package maintainer to fix this, by opening an issue here -> https://gitlab.com/procps-ng/procps
(Last edited by wrtpat on 22 Dec 2015, 19:44)
@wrtpat, thanks for looking into that. It is annoying.
And just fyi, another tool that helps report on CPU utilization as well as softirq's and several others is "mpstat" bundled with the sysstat package.
Output below is my 1900ac v1 running DD kernel 4.1.13 and the 10.3.0.13 mwlwifi during a wireless file copy.
root@router:~# mpstat 1 2 -P ALL
Linux 4.1.13 (routi4) 12/22/15 _armv7l_ (2 CPU)
13:25:20 CPU %usr %nice %sys %iowait %irq %soft %steal %guest %gnice %idle
13:25:21 all 0.00 0.00 0.50 0.00 0.00 49.50 0.00 0.00 0.00 50.00
13:25:21 0 0.00 0.00 1.00 0.00 0.00 55.00 0.00 0.00 0.00 44.00
13:25:21 1 0.00 0.00 0.00 0.00 0.00 44.00 0.00 0.00 0.00 56.00
13:25:21 CPU %usr %nice %sys %iowait %irq %soft %steal %guest %gnice %idle
13:25:22 all 0.00 0.00 0.00 0.00 0.00 48.50 0.00 0.00 0.00 51.50
13:25:22 0 0.00 0.00 0.00 0.00 0.00 55.00 0.00 0.00 0.00 45.00
13:25:22 1 0.00 0.00 0.00 0.00 0.00 42.00 0.00 0.00 0.00 58.00
Average: CPU %usr %nice %sys %iowait %irq %soft %steal %guest %gnice %idle
Average: all 0.00 0.00 0.25 0.00 0.00 49.00 0.00 0.00 0.00 50.75
Average: 0 0.00 0.00 0.50 0.00 0.00 55.00 0.00 0.00 0.00 44.50
Average: 1 0.00 0.00 0.00 0.00 0.00 43.00 0.00 0.00 0.00 57.00Hi.
Tried this one https://downloads.openwrt.org/people/ka … pgrade.tar
Also got 20ms extra latency on wifi.
(Last edited by hmvs on 22 Dec 2015, 20:48)
@kirkgbr, thanks for the 'mpstat' tip. That may come to be handy in the future, so I will have to keep that in mind.
Still can't get qos-scripts working right since kernel upgrade. I've enabled everything I can think of.
Here's the kernel config I'm using...
and the error:
root@ZOMGWTFBBQWIFI:~# tc filter add dev eth1 parent ffff: protocol ip prio 1 u32 match u32 0 0 flowid 1:1 action connmark action mirred egress redirect dev ifb0
RTNETLINK answers: Invalid argument
We have an error talking to the kernel
I see someone else has a ticket open for this as well..
https://dev.openwrt.org/ticket/21374
davidc502 wrote:
Thanks -- and be sure to report back ping times for wireless.
Seems I have some good news at least.... 4.4rc5 (r47961) @ .15 from 20151215
This is via my wireless bridge! pc -> WRT54GS -> bridge 2.4 GHz -> WRT1900AC -> NAS
Pinging 192.168.1.1 with 32 bytes of data:
Reply from 192.168.1.1: bytes=32 time=1ms TTL=64
Reply from 192.168.1.1: bytes=32 time=1ms TTL=64
Reply from 192.168.1.1: bytes=32 time=1ms TTL=64
Reply from 192.168.1.1: bytes=32 time=2ms TTL=64
Reply from 192.168.1.1: bytes=32 time=1ms TTL=64
Reply from 192.168.1.1: bytes=32 time=1ms TTL=64
Reply from 192.168.1.1: bytes=32 time=1ms TTL=64
Reply from 192.168.1.1: bytes=32 time=1ms TTL=64
Pinging 192.168.1.20 with 32 bytes of data:
Reply from 192.168.1.20: bytes=32 time=3ms TTL=64
Reply from 192.168.1.20: bytes=32 time=1ms TTL=64
Reply from 192.168.1.20: bytes=32 time=1ms TTL=64
Reply from 192.168.1.20: bytes=32 time=1ms TTL=64
Reply from 192.168.1.20: bytes=32 time=1ms TTL=64
Reply from 192.168.1.20: bytes=32 time=4ms TTL=64
Reply from 192.168.1.20: bytes=32 time=1ms TTL=64
Reply from 192.168.1.20: bytes=32 time=1ms TTL=64
Granted... last time I tried this it was over the 5GHz bridge using two 1900ACs... so not apples to apples but beats 20 + ms
Cheers
Question for all....
Does any one have issues with the 5GHz radio on 4.4rc5 with .15 driver?
Not staying up and logs don't show anything....
config wifi-device 'radio1'
option type 'mac80211'
option hwmode '11a'
option path 'platform/soc/soc:pcie-controller/pci0000:00/0000:00:03.0/00
option country 'CA'
option channel '161'
option txpower '20'
option htmode 'VHT80'
config wifi-iface
option device 'radio1'
option mode 'ap'
option encryption 'psk2'
option key 'xxxxxxxxxxxxx'
option ssid 'WRT1900AC-P5GHz'
option network 'lan'
Cheers
@wrtpat, looks like the fixed the missing dependencies for thermal_sys.ko.
doITright wrote:
...
Does any one have issues with the 5GHz radio on 4.4rc5 with .15 driver?Not staying up and logs don't show anything....
Could you explain in more detail, what "Not staying up" means?
- Are you able to successfully connect a 5Ghz client after initially booting the router up? What is the client?
- When you disconnect that client, can you reconnect that same client?
- Are there other 5Ghz clients concurrently connected/connecting at the time? What are they?
- Once connected, does the client stay connected only for a time, and then disconnects? Or does it stay connected until you explicitly disconnect?
Just trying to get a sense for what "Not staying up" means here.
BTW, I'm on a similar config and I have zero issues with clients connecting, staying connected, disconnecting/reconnecting, etc.... all good here.
kirkgbr wrote:
@wrtpat, looks like the fixed the missing dependencies for thermal_sys.ko.
@kirkgbr, thanks for the heads-up....
Yes, I saw that. I was just git cloning a fresh build root, to give it a try.
Page 367 of 598