starcms wrote:

grunt wrote:

I am also experiencing browser pages not able to load, and then quickly followed by the page loading. I am on 4.4 kernel r4470. Both my wired and wireless devices are experiencing this problem. At first i thought it was dnscrypt causing the problem. I switched some of my devices over to Google's DNS, but they are still experiencing this problem. I believe I started experiencing this problem on r4323. Maybe it was introduced in mwlwifi 10.3.4.0-20170606 but im guessing at this point.

I would like to try the latest wireless driver (20170713) on a 4.4 kernel build to see if the latest commits have addressed this problem. David, would you be able to build the latest 4.4 firmware image?

Not experiencing this problem at all, and never have.  Although I am on the latest 4.9 kernel build.

I noticed @bill1228 was describing I was experiencing so I wanted to state it for record purposes.

Are you using 4.9 on the mamba? If so do you still experience the reboot problem?

Do you know if i can just install the new wifi driver you just posted on top the 4.4 build?

starcms wrote:

davidc502 wrote:

First attempt failed... No difference in VPN throughput.  Will try again tomorrow night.

Will go back through the steps, and compile again.

Thanks David!  Really excited to see this working with NEON support.  I still can't believe NEON has never been utilized by LEDE on the 1200/1900/3200.  For those who didn't read my prior posts, this will result in a big if not huge performance increase for all models except the mamba/1900ac v1 (which has the armada xp SoC which doesn't support NEON).

Also, you might want to test other things as well, such as openssl key generation time, to see if it is working.  According to the PR, it should greatly affect "OpenSSL, ffmpeg, Opus Codec, fftw, libpng, mpg123 to name a few"

I'm excited to getting it working as well....  Probably won't be able to work on it tonight as the wife says I've been working too much and wants to go out for Margaritas tonight...   So probably won't be too productive as she apparently has other plans.

So, will mark some time on Saturday afternoon.

@diizzyy to enable that we also need to have CONFIG_VFP.
I FIND THIS... think we need to change target optimization option to use it
As i can see neon is utilized to parallelize instruction, but i think that we need to compile them in a particular way to actually utilize them

Separating NEON code from ordinary code

The compiler is not aware of the special significance of kernel_neon_begin() and
kernel_neon_end(), i.e., that it is only allowed to issue NEON/VFP instructions
between calls to these respective functions. Furthermore, GCC may generate NEON
instructions of its own at -O3 level if -mfpu=neon is selected, and even if the
kernel is currently compiled at -O2, future changes may result in NEON/VFP
instructions appearing in unexpected places if no special care is taken.

Therefore, the recommended and only supported way of using NEON/VFP in the
kernel is by adhering to the following rules:

isolate the NEON code in a separate compilation unit and compile it with
'-mfpu=neon -mfloat-abi=softfp';

issue the calls to kernel_neon_begin(), kernel_neon_end() as well as the calls
into the unit containing the NEON code from a compilation unit which is not
built with the GCC flag '-mfpu=neon' set.

As the kernel is compiled with '-msoft-float', the above will guarantee that
both NEON and VFP instructions will only ever appear in designated compilation
units at any optimization level.

davidc502 wrote:

starcms wrote:

Thanks David!  Really excited to see this working with NEON support.  I still can't believe NEON has never been utilized by LEDE on the 1200/1900/3200.  For those who didn't read my prior posts, this will result in a big if not huge performance increase for all models except the mamba/1900ac v1 (which has the armada xp SoC which doesn't support NEON).

Also, you might want to test other things as well, such as openssl key generation time, to see if it is working.  According to the PR, it should greatly affect "OpenSSL, ffmpeg, Opus Codec, fftw, libpng, mpg123 to name a few"

I'm excited to getting it working as well....  Probably won't be able to work on it tonight as the wife says I've been working too much and wants to go out for Margaritas tonight...   So probably won't be too productive as she apparently has other plans.

So, will mark some time on Saturday afternoon.

No rush, but definitely check the discussion at https://github.com/lede-project/source/pull/1211 before you try again.  @Ansuel posted some advice which sounds like it is very important to getting this to work, and more helpful advice may be posted before you try again:

@diizzyy to enable that we also need to have CONFIG_VFP.
I FIND THIS... think we need to change target optimization option to use it
As i can see neon is utilized to parallelize instruction, but i think that we need to compile them in a particular way to actually utilize them

Separating NEON code from ordinary code

The compiler is not aware of the special significance of kernel_neon_begin() and
kernel_neon_end(), i.e., that it is only allowed to issue NEON/VFP instructions
between calls to these respective functions. Furthermore, GCC may generate NEON
instructions of its own at -O3 level if -mfpu=neon is selected, and even if the
kernel is currently compiled at -O2, future changes may result in NEON/VFP
instructions appearing in unexpected places if no special care is taken.

Therefore, the recommended and only supported way of using NEON/VFP in the
kernel is by adhering to the following rules:

isolate the NEON code in a separate compilation unit and compile it with
'-mfpu=neon -mfloat-abi=softfp';

issue the calls to kernel_neon_begin(), kernel_neon_end() as well as the calls
into the unit containing the NEON code from a compilation unit which is not
built with the GCC flag '-mfpu=neon' set.

As the kernel is compiled with '-msoft-float', the above will guarantee that
both NEON and VFP instructions will only ever appear in designated compilation
units at any optimization level.

I understood the commits in the PR, but this is getting over my head.  Hopefully you understand

I'm excited to getting it working as well....  Probably won't be able to work on it tonight as the wife says I've been working too much and wants to go out for Margaritas tonight...   So probably won't be too productive as she apparently has other plans.

So, will mark some time on Saturday afternoon.

Latest wifi driver for the 3200acm is now available. As a gentle reminder, 3200acm owners need to be on r4542 to test the new driver.

A big thank you as always to yuhhaurlin for the continuing improvement/work.

davidc502 wrote:

Latest wifi driver for the 3200acm is now available. As a gentle reminder, 3200acm owners need to be on r4542 to test the new driver.

A big thank you as always to yuhhaurlin for the continuing improvement/work.

Been running for 21 hours with the latest driver without any kernel errors or router reboots.   Looks like yuhhaurlin's confidence was well founded!  Thanks to him and davidc502 for their quick turn around in getting us a more stable driver.

1)is there a build that addresses the wifi issues with the version 2 router ? I am currently drawn to your build davidc502, as all the results from my searches return to your build.

2) is there any general advice apart from what's available in the wiki to help with my journey into openwrt.

Hi,
I could really use some advice.I am completely new to openwrt, in fact I haven't flashed the router yet. I have bought a linksys wrt 1900 acs. It appears to be a version 2 (as the sticker denotes). I've been researching openwrt quite a bit and each review or forum message I saw Helped me narrow my decision towards using this router. I notice that certain users have wifi problems and also that the wiki suggests that the version 2 has unsupported wifi drivers. I have a moderate amount of experience with Linux and using the command line as I use it for all my embedded projects on raspberry pi's.
My questions are:
1)is there a build that addresses the wifi issues with the version 2 router ? I am currently drawn to your build davidc502, as all the results from my searches return to your build.
2) is there any general advice apart from what's available in the wiki to help with my journey into openwrt.

Thank you in advance

I have the same router as you do, and I've been using David's OpenWRT then LEDE builds for a while. The wifi driver for 1900ACS has been working really well for me and seems to be mature enough to not worry much about catastrophic performance problems

It really just depends on what you need/want out of your router.

As to the wifi driver, I also have the 1900acs, but is Version 1, but uses the same wifi driver as version 2. From what I understand the 2 are nearly identical except Version 2 has the Wifi power table on chip.

I've found the 1900acs wifi to be quite good, and comparable to the factory driver, and IMHO is a little better in my environment. Your experience may differ as the environment has so much to do with performance.

So, for your journey, it's good you have experience, and are handy with SSH as it can help immensely. The first step is getting familiar with the LuCi Gui, and getting the configuration the way you want it. From there, ssh and look around at the directory structure and where the configuration files are.

One way:

create a patch file with this in your buildroot.

./scripts/diffconfig.sh > configdiffPreNEON  //you will probably want to set aside this
vi neon.patch                             //copy and paste the patch above into file
git branch                                //just to list where your at, assume no branch
git checkout -b neonbuild origin/master   //create a branch for the patch
patch -p1 < neon.patch                    //apply the patch to your branch
make menuconfig                           //you will have to reset to one of the 2 new targets 370/380

git checkout master                       //to go back to your master branch
git branch -D neonbuild                   //delete the branch
git status                                //take a look at your current changes, you may have to clean up

One gotcha, check the current
  Advanced configuration*->Target Options->Target Optimizations
as it does not reset sometimes. You can just generate a diffconfig from your post patch config, delete the line in the file, and do a make defconfig;make oldconfig.

Built a couple days back against 4.9.37 fine for me.

I have a basic question that i couldn't find in FAQ section. Is it safe to update to new Lede firmware from old Lede firmware? I mean if i do it, can I still use the official firmware in the other partition? or should I update to new firmware from official firmware partition like I always do in ddwrt firmwares? My router is 3200ACM.

Sat Jul 15 21:06:54 2017 daemon.info dnscrypt-proxy[1564]: dnscrypt-proxy Refetching server certificates
Sat Jul 15 21:06:54 2017 user.warn igmpproxy[2782]: The source address 192.168.0.1 for group 239.255.255.250, is not in any valid net for upstream VIF.
Sat Jul 15 21:06:55 2017 user.warn igmpproxy[2782]: The source address 20.20.20.1 for group 239.255.255.250, is not in any valid net for upstream VIF.
Sat Jul 15 21:07:10 2017 daemon.err dnscrypt-proxy[1564]: dnscrypt-proxy Unable to retrieve server certificates
Sat Jul 15 21:07:10 2017 user.warn igmpproxy[2782]: The source address 192.168.0.1 for group 239.255.255.250, is not in any valid net for upstream VIF.
Sat Jul 15 21:07:10 2017 user.warn igmpproxy[2782]: The source address 20.20.20.1 for group 239.255.255.250, is not in any valid net for upstream VIF. So this has been happening since a few commits ago, any ideas?

jdc2389 wrote:

Sat Jul 15 21:06:54 2017 daemon.info dnscrypt-proxy[1564]: dnscrypt-proxy Refetching server certificates
Sat Jul 15 21:06:54 2017 user.warn igmpproxy[2782]: The source address 192.168.0.1 for group 239.255.255.250, is not in any valid net for upstream VIF.
Sat Jul 15 21:06:55 2017 user.warn igmpproxy[2782]: The source address 20.20.20.1 for group 239.255.255.250, is not in any valid net for upstream VIF.
Sat Jul 15 21:07:10 2017 daemon.err dnscrypt-proxy[1564]: dnscrypt-proxy Unable to retrieve server certificates
Sat Jul 15 21:07:10 2017 user.warn igmpproxy[2782]: The source address 192.168.0.1 for group 239.255.255.250, is not in any valid net for upstream VIF.
Sat Jul 15 21:07:10 2017 user.warn igmpproxy[2782]: The source address 20.20.20.1 for group 239.255.255.250, is not in any valid net for upstream VIF. So this has been happening since a few commits ago, any ideas?

I'm seeing these too, but not sure if it is impacting anything

Sun Jul 16 08:50:55 2017 daemon.info dnscrypt-proxy[1562]: dnscrypt-proxy Refetching server certificates
Sun Jul 16 08:51:10 2017 daemon.err dnscrypt-proxy[1562]: dnscrypt-proxy Unable to retrieve server certificates
Sun Jul 16 08:52:16 2017 daemon.info dnscrypt-proxy[1562]: dnscrypt-proxy Refetching server certificates
Sun Jul 16 08:52:31 2017 daemon.err dnscrypt-proxy[1562]: dnscrypt-proxy Unable to retrieve server certificates