DWA192 Driver 8814au Loadable Under Kernel 4.13.16-300 but not Loadable Under Kernel 4.14.7-300.

[Stephen Morris]

Having just done a system upgrade, the upgrade has upgraded the kernel 
from 4.13.16-300 to 4.14.7-300, consequently I no longer have wifi access.

Manually compiling the driver for 4.14.7-300 produces the following 
warnings:

WARNING: "__vfs_read" [/usr/src/rtl8814au-5.1.5/8814au.ko] undefined!
WARNING: "vfs_read" [/usr/src/rtl8814au-5.1.5/8814au.ko] undefined!

A subsequent insmod 8814au or modprobe 8814au does not load the driver 
because of an undefined symbol, but does not specify what the symbol is. 
My assumption it is because of the above warnings.

Having done a search through the headers for kernel 4.14.7-300 I have 
found that include file fs.h has the definitions for __vfs_read and 
vfs_read.

In the driver include file osdep_service_linux.h I found the following 
statements:

#ifdef CONFIG_EFUSE_CONFIG_FILE
         #include <linux/fs.h>
#endif

In an attempt to fix the warnings I did and explicit #include 
<linux/fs.h>, and recompiled the driver source but doing this did not 
resolve the warnings.

Does anyone know what I need to do to resolve the warnings and hence 
make the driver kernel loadable?

regards,

Steve

[Ed Greshko]

On 12/26/17 10:26, Stephen Morris wrote:
> Having just done a system upgrade, the upgrade has upgraded the kernel from
> 4.13.16-300 to 4.14.7-300, consequently I no longer have wifi access.
>
> Manually compiling the driver for 4.14.7-300 produces the following warnings:
>
> WARNING: "__vfs_read" [/usr/src/rtl8814au-5.1.5/8814au.ko] undefined!
> WARNING: "vfs_read" [/usr/src/rtl8814au-5.1.5/8814au.ko] undefined!
>
> A subsequent insmod 8814au or modprobe 8814au does not load the driver because of
> an undefined symbol, but does not specify what the symbol is. My assumption it is
> because of the above warnings.
>
> Having done a search through the headers for kernel 4.14.7-300 I have found that
> include file fs.h has the definitions for __vfs_read and vfs_read.
>
> In the driver include file osdep_service_linux.h I found the following statements:
>
> #ifdef CONFIG_EFUSE_CONFIG_FILE
>         #include <linux/fs.h>
> #endif
>
> In an attempt to fix the warnings I did and explicit #include <linux/fs.h>, and
> recompiled the driver source but doing this did not resolve the warnings.
>
> Does anyone know what I need to do to resolve the warnings and hence make the
> driver kernel loadable?

From where did you obtain the driver?

I don't have the HW to test on, but https://github.com/zebulon2/rtl8814au seems to
compile just fine.  It also has a note from 13 days ago about "Fix a compilation
error on kernel v4.14 and later"

[Stephen Morris]

On 26/12/2017 14:03, Ed Greshko wrote:
> On 12/26/17 10:26, Stephen Morris wrote:
> > Having just done a system upgrade, the upgrade has upgraded the kernel from
> > 4.13.16-300 to 4.14.7-300, consequently I no longer have wifi access.
> >
> > Manually compiling the driver for 4.14.7-300 produces the following warnings:
> >
> > WARNING: "__vfs_read" [/usr/src/rtl8814au-5.1.5/8814au.ko] undefined!
> > WARNING: "vfs_read" [/usr/src/rtl8814au-5.1.5/8814au.ko] undefined!
> >
> > A subsequent insmod 8814au or modprobe 8814au does not load the driver because of
> > an undefined symbol, but does not specify what the symbol is. My assumption it is
> > because of the above warnings.
> >
> > Having done a search through the headers for kernel 4.14.7-300 I have found that
> > include file fs.h has the definitions for __vfs_read and vfs_read.
> >
> > In the driver include file osdep_service_linux.h I found the following statements:
> >
> > #ifdef CONFIG_EFUSE_CONFIG_FILE
> >          #include <linux/fs.h>
> > #endif
> >
> > In an attempt to fix the warnings I did and explicit #include <linux/fs.h>, and
> > recompiled the driver source but doing this did not resolve the warnings.
> >
> > Does anyone know what I need to do to resolve the warnings and hence make the
> > driver kernel loadable?
>
> From where did you obtain the driver?
>
> I don't have the HW to test on, but https://github.com/zebulon2/rtl8814au seems to
> compile just fine.  It also has a note from 13 days ago about "Fix a compilation
> error on kernel v4.14 and later"

Thanks Ed, I don't remember where I got the driver from other than I 
found it on github via google for an early version of the 4.13 kernel, 
when the driver I was using prior to this one that had to be modified to 
cater for function moves between kernel header files with the 4.11 
kernel,  failing to compile with the 4.13 kernel. The driver I was using 
also came pre-configured for installation with dkms which was an advantage.

I'll try the driver you linked and see how it goes. As a matter of 
interest how did you find this link, my searches haven't provided it?

regards,

Steve
> users mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]

[Ed Greshko]

On 12/26/17 13:03, Stephen Morris wrote:
> Thanks Ed, I don't remember where I got the driver from other than I found it on
> github via google for an early version of the 4.13 kernel, when the driver I was
> using prior to this one that had to be modified to cater for function moves between
> kernel header files with the 4.11 kernel,  failing to compile with the 4.13 kernel.
> The driver I was using also came pre-configured for installation with dkms which
> was an advantage.
>
> I'll try the driver you linked and see how it goes. As a matter of interest how did
> you find this link, my searches haven't provided it?

My google search was simply "8814au driver" and the link I provided was the first one.

FWIW, the link I provided does say that it is forked from tpircher/rtl8814AU
(https://github.com/tpircher/rtl8814AU) and it has nice suggestions if you want to
use dkms to keep the driver compiled automatically after kernel updates.

[Stephen Morris]

On 26/12/2017 16:50, Ed Greshko wrote:
> On 12/26/17 13:03, Stephen Morris wrote:
> > Thanks Ed, I don't remember where I got the driver from other than I found it on
> > github via google for an early version of the 4.13 kernel, when the driver I was
> > using prior to this one that had to be modified to cater for function moves between
> > kernel header files with the 4.11 kernel,  failing to compile with the 4.13 kernel.
> > The driver I was using also came pre-configured for installation with dkms which
> > was an advantage.
> >
> > I'll try the driver you linked and see how it goes. As a matter of interest how did
> > you find this link, my searches haven't provided it?
>
> My google search was simply "8814au driver" and the link I provided was the first one.

The search I was doing was "dwa192 rtl8814au linux driver" and it didn't 
provide the link you got.
> FWIW, the link I provided does say that it is forked from tpircher/rtl8814AU
> (https://github.com/tpircher/rtl8814AU) and it has nice suggestions if you want to
> use dkms to keep the driver compiled automatically after kernel updates.

I've compiled the driver without any errors or warnings and installed it 
and it is working fine.

The previous driver I was using came with a bash dkms install and remove 
script, which I've copied to the directory I unzipped your link to, and 
having modified it for this driver, it copies the directory to /usr/src 
where it needs to be, and then does a dkms add, build and install, which 
places the driver in /lib/modules/$(uname -r)/extra as required. I did 
have an issue with modprobe because the previous driver somehow made its 
way down to the wireless directory in the module structure, so I had to 
manually remove it.

This driver has also rectified the wireless performance issue I had with 
the previous driver. The previous driver was connecting with a bitrate 
of 452 mb/s whereas this driver is connecting at 1.3 gb/s on the 5GHz 
channel as it should be, so it looks like this driver correctly supports 
AC whereas, looking at the supported bitrates on the 5 GHz channel, the 
previous driver seemed to only be supported 80211n on the 5 GHz channel.

As a result of this driver seeming to support 80211ac, the wireless 
signal strength seems to be stronger as well, at least compared to the 
previous driver.

regards,

Steve
> users mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]