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 393 of 598

Post #9801

fabbari

1 Feb 2016, 15:22

My wrt1900v2 is running with custom builds - trunk with these two patches:

Chadster fixes - Quilt: package/kernel/mwlwifi/patches/120-chadster_fix.patch - Patch: http://pastebin.com/Vp19wxR4

Kernel Proposed NAND Patch - Quilt: target/linux/mvebu/patches-4.4/300-pxa3xx_nand.patch - Patch: http://pastebin.com/ex9Fka7g

I need to restart the router every night - I have a lot of devices around - that may be why I see the performance degradation more often than I would like, especially on the 5GHZ band.

Looking into disabling IPV6 - to see if some of the issues may be coming out of the reported issues.

So far - when things don't screech to an halt - the performance is excellent. I am also moving the wifi IRQs on the secondary core - just to get a bit more balanced use of the cores.

This is my startup commands:

# Offload mwlwifi IRQs to CPU1
# 2 -> MASK 10 -> enable CPU1
# 1 -> MASK 01 -> enable CPU0
echo 2 > /proc/irq/103/smp_affinity
echo 2 > /proc/irq/104/smp_affinity

And this shows it's actually doing it's job:

           CPU0       CPU1       
.....
.....
103:          0    2396786       GIC  61 Level     mwlwifi
104:          0    2312648       GIC  65 Level     mwlwifi
.....
.....

The wireless configuration was hand changed to the following:

config wifi-device 'radio0'
    option type 'mac80211'
    option hwmode '11a'
    option path 'platform/soc/soc:pcie-controller/pci0000:00/0000:00:01.0/0000:01:00.0'
    option htmode 'VHT80'
    list ht_capab 'LDPC'
    list ht_capab 'SHORT-GI-20'
    list ht_capab 'SHORT-GI-40'
    list ht_capab 'TX-STBC'
    list ht_capab 'RX-STBC1'
    list ht_capab 'DSSS_CCK-40'
    option distance '0'
    option frag '500'
    option rts '2346'
    option country 'US'
    option channel '149'
    option txpower '30'


config wifi-device 'radio1'
    option type 'mac80211'
    option path 'platform/soc/soc:pcie-controller/pci0000:00/0000:00:02.0/0000:02:00.0'
    option country 'US'
    option txpower '30'
    option bursting '1'
    option ff '1'
    option compression '1'
    option noscan '1'
    option hwmode '11g'
    list ht_capab 'SHORT-GI-40'
    list ht_capab 'TX-STBC'
    list ht_capab 'RX-STBC1'
    list ht_capab 'DSSS_CCK-40'
    option htmode 'HT40'
    option distance '0'
    option frag '500'
    option rts '2436'
    option channel '4'

These give me very good performance on the 2.4G band and fast performance on 5.0G.

What kind of tuning and patching are you people running? How do they perform?

I'm posting this to try and work collectively on a fine tuned configuration of our routers - patches, wifi configurations, system tune ups.

Post #9802

Chadster766

1 Feb 2016, 16:29

fabbari wrote:

My wrt1900v2 is running with custom builds - trunk with these two patches:
Chadster fixes - Quilt: package/kernel/mwlwifi/patches/120-chadster_fix.patch - Patch: http://pastebin.com/Vp19wxR4

This patch file looks good. Thanks for posting it

Post #9803

Chadster766

1 Feb 2016, 17:18

fabbari wrote:

My wrt1900v2 is running with custom builds - trunk with these two patches:
Kernel Proposed NAND Patch - Quilt: target/linux/mvebu/patches-4.4/300-pxa3xx_nand.patch - Patch: http://pastebin.com/ex9Fka7g

What does this kernel nand driver patch do? I would think kernels +4.2.0 can properly deal with nand flash.

Post #9804

tekiwibird

1 Feb 2016, 19:10

@davidc502, how do I use your builds on the wrt1900acs?

I installed your shelby NAND w/luci. It didn't port over all my configs from the kaloz build properly, wifi was disabled, lan works, and luci wasn't enabled. I had to ssh, install luci and enable websever. Looking at the WiFi configurations, there are two networks that are using a generic driver and two that are using the marvel driver. It seems the saved configs from the kaloz build had bound to the generic drivers, as they were the first two entries.

I ended up going back to the kaloz build for now.

(Last edited by tekiwibird on 1 Feb 2016, 20:02)

Post #9805

aafj

1 Feb 2016, 21:09

Another wireless example.
http://pastebin.com/ibsFx1VD

Post #9806

davidc502

1 Feb 2016, 21:11

The builds are based on Trunk, so you should be able to update from trunk without any issues. However, any other builds, like Kaloz, it looks like there may be problems importing the configuration. < Good to know

Not sure why you didn't get LuCi.. Each build was based on the same .config with the exception of the hardware version. So far, everyone else I've talked to received LuCi, so I'm not sure what happened there.

Post #9807

tekiwibird

1 Feb 2016, 21:16

davidc502 wrote:

Not sure why you didn't get LuCi.. Each build was based on the same .config with the exception of the hardware version. So far, everyone else I've talked to received LuCi, so I'm not sure what happened there.

I may have assumed it wasn't installed -- I didn't check. The webserver wasn't enabled after the flash, so I ssh'd in and installed luci-ssl and enabled the webserver. Maybe it was included and all I needed to do was enable the webserver.

Post #9808

anomeome

1 Feb 2016, 21:31

Are people still experiencing the nand timeout issue? I have not used the nand patch in my builds since December and have not been running into the issue.

Post #9809

doITright

1 Feb 2016, 22:04

anomeome wrote:

Are people still experiencing the nand timeout issue? I have not used the nand patch in my builds since December and have not been running into the issue.

Ticket is still open:

https://dev.openwrt.org/ticket/21404

I still include the patch in each build of trunk and 4.4.0 (just in case)

Cheers

Post #9810

kirkgbr

1 Feb 2016, 22:26

doITright wrote:

anomeome wrote:
Are people still experiencing the nand timeout issue? I have not used the nand patch in my builds since December and have not been running into the issue.
Ticket is still open:
https://dev.openwrt.org/ticket/21404
I still include the patch in each build of trunk and 4.4.0 (just in case)

Heck, i include the patch in 4.1 or 4.4 just in case

Post #9811

legend_xin

1 Feb 2016, 23:51

My wrt1900v2 is running with Openwrt ChaosCalmer15.05 /LuCi（git-15.248.30277-383645）
Luci- shadowsock and Luci-app Chiandns command line install is ok, but Luci control no services memu?
Could you please help fix this issue?

Thanks

Post #9812

northbound

2 Feb 2016, 00:46

anomeome wrote:

Are people still experiencing the nand timeout issue? I have not used the nand patch in my builds since December and have not been running into the issue.

I have tried without and usually it boots ok but a reboot on luci shows the problem. Usually a power off and on will load it in 1 or 2 try's. But the patch allows reboots from luci and a power off and on to ALWAYS come up first try. So I am sticking with the patch for consistency. For the little delay in boot it is well worth it. Too bad the powers that be have not pushed to 4.1 4.4 etc.
wrt1900ac v1

Post #9813

davidc502

2 Feb 2016, 00:52

northbound wrote:

anomeome wrote:
Are people still experiencing the nand timeout issue? I have not used the nand patch in my builds since December and have not been running into the issue.
I have tried without and usually it boots ok but a reboot on luci shows the problem. Usually a power off and on will load it in 1 or 2 try's. But the patch allows reboots from luci and a power off and on to ALWAYS come up first try. So I am sticking with the patch for consistency. For the little delay in boot it is well worth it. Too bad the powers that be have not pushed to 4.1 4.4 etc.
wrt1900ac v1

So what is anyone going to get out of kernel 4.1.4.4 compared to running 4.1.15?

Post #9814

northbound

2 Feb 2016, 01:00

davidc502 wrote:

northbound wrote:
anomeome wrote:
Are people still experiencing the nand timeout issue? I have not used the nand patch in my builds since December and have not been running into the issue.
I have tried without and usually it boots ok but a reboot on luci shows the problem. Usually a power off and on will load it in 1 or 2 try's. But the patch allows reboots from luci and a power off and on to ALWAYS come up first try. So I am sticking with the patch for consistency. For the little delay in boot it is well worth it. Too bad the powers that be have not pushed to 4.1 4.4 etc.
wrt1900ac v1
So what is anyone going to get out of kernel 4.1.4.4 compared to running 4.1.15?

4.1.16 on a wrt1900ac v1 cycles the fan "setpoint 60c" at idle
4.4.0 runs at 53 to 54 at idle
both running the latest .16 mwlwifi.ko
Not what you were asking just my observation on what I am messing with.

Post #9815

anomeome

2 Feb 2016, 01:13

I lied about not using the nand patch in my builds. I was looking at the tree that I use to build for my C7V2 rather than my wrt1900v1, which still does have the patch. What got me curious was the patch posted by fabbari which is much more extensive than what was put together back in Nov/Dec when the nand issue raised its head again.

4.4 still looks to be faster at processing packets than 4.1 for me (without QOS wan->lan throughput).

(Last edited by anomeome on 2 Feb 2016, 01:22)

Post #9816

doITright

2 Feb 2016, 01:56

anomeome wrote:

I lied about not using the nand patch in my builds. I was looking at the tree that I use to build for my C7V2 rather than my wrt1900v1, which still does have the patch. What got me curious was the patch posted by fabbari which is much more extensive than what was put together back in Nov/Dec when the nand issue raised its head again.
4.4 still looks to be faster at processing packets than 4.1 for me (without QOS wan->lan throughput).

Thinking of taking that patch for a spin now

Hope I can get past the copy/paste probs...

Cheers

Post #9817

davidc502

2 Feb 2016, 02:04

northbound wrote:

davidc502 wrote:
northbound wrote:
I have tried without and usually it boots ok but a reboot on luci shows the problem. Usually a power off and on will load it in 1 or 2 try's. But the patch allows reboots from luci and a power off and on to ALWAYS come up first try. So I am sticking with the patch for consistency. For the little delay in boot it is well worth it. Too bad the powers that be have not pushed to 4.1 4.4 etc.
wrt1900ac v1
So what is anyone going to get out of kernel 4.1.4.4 compared to running 4.1.15?
4.1.16 on a wrt1900ac v1 cycles the fan "setpoint 60c" at idle
4.4.0 runs at 53 to 54 at idle
both running the latest .16 mwlwifi.ko
Not what you were asking just my observation on what I am messing with.

Are you seeing less soft IRQ's? Or less processor utilization in general?

Post #9818

northbound

2 Feb 2016, 02:21

davidc502 wrote:

northbound wrote:
davidc502 wrote:
So what is anyone going to get out of kernel 4.1.4.4 compared to running 4.1.15?
4.1.16 on a wrt1900ac v1 cycles the fan "setpoint 60c" at idle
4.4.0 runs at 53 to 54 at idle
both running the latest .16 mwlwifi.ko
Not what you were asking just my observation on what I am messing with.
Are you seeing less soft IRQ's? Or less processor utilization in general?

All I am sayin is less heat. Soft irq still @ 2k per at idle which is bs if there is no active connection. And even if there is a connection at idle it is wrong. It is like an engine that can run at 10k so lets idle it at 5k for the heck of it just in case.
Ok, that is a reach but maybe you get my point.

Post #9819

kirkgbr

2 Feb 2016, 03:43

anomeome wrote:

I lied about not using the nand patch in my builds. I was looking at the tree that I use to build for my C7V2 rather than my wrt1900v1, which still does have the patch. What got me curious was the patch posted by fabbari which is much more extensive than what was put together back in Nov/Dec when the nand issue raised its head again.
4.4 still looks to be faster at processing packets than 4.1 for me (without QOS wan->lan throughput).

fabbari is running a 1900 V2. Will that nand patch work for V1's .

Post #9820

northbound

2 Feb 2016, 03:54

@davidc502
If you get time check this build out.

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

4.4.0 w/nand patch and latest .16 driver and the best part working led's
paste the below line in Luci>system>startup

insmod leds-tlc591xx.ko

Thanks to nitroshift for the start and kirkgbr for the final piece to the tlc591xx.ko puzzle.

Post #9821

dana44

2 Feb 2016, 05:28

dana44 wrote:

I have the 1900ac running 15.05. Often when doing a ping -t google.com I get output along the lines of:
Reply from 216.58.216.142: bytes=32 time=13ms TTL=56
Request timed out.
Request timed out.
Request timed out.
Reply from 216.58.216.142: bytes=32 time=14ms TTL=56
Reply from 216.58.216.142: bytes=32 time=14ms TTL=56
Reply from 216.58.216.142: bytes=32 time=12ms TTL=56
Reply from 216.58.216.142: bytes=32 time=13ms TTL=56
Reply from 216.58.216.142: bytes=32 time=14ms TTL=56
Request timed out.
Reply from 216.58.216.142: bytes=32 time=16ms TTL=56
Reply from 216.58.216.142: bytes=32 time=15ms TTL=56
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Reply from 216.58.216.142: bytes=32 time=12ms TTL=56
This is all internet traffic. I get disconnect from my games. This PC is directly wired to the router. I've got this after the router has been up for days or seconds.
In the log the closest thing to an error I see is multiple
kern.err kernel: [ 2423.194956] ata1: illegal qc_active transition (00000000->00000400)
what does that mean?
How can I debug what my problem is and make this reliable?

I disconnected my eSATA drive and everything was good for the last ~month. However I recently decided to plug it back it to find a way to use this router as a NAS. By "coincidence" this problem has instantly reared its head again.

Is anybody using the eSATA port? Is there anyway to a useful bug report or anything to help get this fixed?

Post #9822

fabbari

2 Feb 2016, 14:19

Hi all,

the NAND patch is the sum of the NAND timeout patch - I still occasionally would get the timeout issues on boot, even on 4.4 - and these: http://lists.infradead.org/pipermail/li … 3088.html; mostly code cleanup and fixes for edge cases we should not hit on our boards.

There are another couple of patches circulating in the kernel list - I'm reading them and figuring out if they bring in any benefits. Most of these should land in the kernel sooner or later.

Fabbari

Post #9823

davidc502

2 Feb 2016, 14:30

northbound wrote:

@davidc502
If you get time check this build out.
https://onedrive.live.com/redir?resid=E … =folder%2c
4.4.0 w/nand patch and latest .16 driver and the best part working led's
paste the below line in Luci>system>startup
insmod leds-tlc591xx.ko
Thanks to nitroshift for the start and kirkgbr for the final piece to the tlc591xx.ko puzzle.

How much stability is there in this build? I have a work from home wife, that needs really stability.

Post #9824

northbound

2 Feb 2016, 14:53

davidc502 wrote:

northbound wrote:
@davidc502
If you get time check this build out.
https://onedrive.live.com/redir?resid=E … =folder%2c
4.4.0 w/nand patch and latest .16 driver and the best part working led's
paste the below line in Luci>system>startup
insmod leds-tlc591xx.ko
Thanks to nitroshift for the start and kirkgbr for the final piece to the tlc591xx.ko puzzle.
How much stability is there in this build? I have a work from home wife, that needs really stability.

You might not want to use it then. It works fine for me but it has only been up for 15 hrs. I posted it to see if you saw the same temp difference I did from 4.1.16 to 4.4.0 I did forget to tag collectd cpu in this build but it can be added.

Post #9825

doITright

2 Feb 2016, 14:56

kirkgbr wrote:

anomeome wrote:
I lied about not using the nand patch in my builds. I was looking at the tree that I use to build for my C7V2 rather than my wrt1900v1, which still does have the patch. What got me curious was the patch posted by fabbari which is much more extensive than what was put together back in Nov/Dec when the nand issue raised its head again.
4.4 still looks to be faster at processing packets than 4.1 for me (without QOS wan->lan throughput).
fabbari is running a 1900 V2. Will that nand patch work for V1's .

Yes... built with that patch last night without one single issue... running it on my v1 for over 12 hours now...

So far so good

Cheers

Sorry, posts 9826 to 9825 are missing from our archive.

Page 393 of 598