On 07/10/2017 10:23 AM, Rick Stevens wrote: > On 07/08/2017 06:08 PM, Stephen Morris wrote: >> On 7/8/17 4:43 AM, Rick Stevens wrote: >>> On 07/07/2017 02:04 AM, Stephen Morris wrote: >>>> On 7/6/17 8:50 AM, Rick Stevens wrote: >>>>> On 07/05/2017 03:25 PM, Stephen Morris wrote: >>>>>> On 6/24/17 4:03 PM, Samuel Sieb wrote: >>>>>>> On 06/23/2017 05:56 PM, Stephen Morris wrote: >>>>>>>> I am using a DWA-192 usb WiFi adapter in F25 hence I need >>>>>>>> to get >>>>>>>> a driver from github to be compiled on my system so that I can use >>>>>>>> the adapter. This driver compiled and worked quite happily with >>>>>>>> kernel 4.9.9, not that the kernel version is necessarily an >>>>>>>> indicator >>>>>>>> of compile success. It had been a month or more since I had apply >>>>>>>> any >>>>>>>> system updates, so I did so two days ago, which as part of the >>>>>>>> update >>>>>>>> updated the kernel to 4.11.5, and when dkms went to compile the >>>>>>>> driver for the new kernel the compile failed with error messages >>>>>>>> about implicit function definitions and messages about warnings >>>>>>>> having been converted to errors. >>>>>>> That's the problem with using out-of-tree drivers. Someone has to >>>>>>> keep them up-to-date with kernel changes. >>>>>>> >>>>>>>> Does anyone know if there is an updated driver that will >>>>>>>> compile >>>>>>>> with the current level of F25 or whether it has yet to be updated >>>>>>>> for >>>>>>>> compatibility with F25 and hence I will need to continue to use >>>>>>>> Ethernet internet access? >>>>>>> https://github.com/xxNull-lsk/rtl8812AU has a recent commit that >>>>>>> mentions kernel 4.11. I think >>>>>>> https://wikidevi.com/wiki/D-Link_DWA-192 is suggesting that you have >>>>>>> to modify one of the files to add your device id to it. >>>>>> I downloaded the rtl8812AU driver even though its not necessarily the >>>>>> right chipset (I believed the chipset in the DWA-192 was the rtl8814AU >>>>>> chipset) but when I compiled it, it failed with the same errors. >>>>>> It seems to me that the reason the source code is failing to compile >>>>>> after the system update is that the compiler has been changed, as this >>>>>> is the only reason I can see that source code that compiled fine >>>>>> before >>>>>> the update won't compile after the update, unless the functions >>>>>> that the >>>>>> compiler is rejecting as being implicitly defined, are functions that >>>>>> were defined in the 4.9.9 kernel but have been removed sometime >>>>>> between >>>>>> there and the 4.11.5 kernel. >>>>> I just built the driver from https://github.com/xxNull-lsk/rtl8812AU on >>>>> my machine with kernel 4.11.8-200.fc25.x86_64 with absolutely no >>>>> problem. Note that you must have the kernel-devel RPM installed, and >>>>> I'd recommend also having the elfutils-libelf-devel RPM installed. >>>>> >>>>> I didn't build it for DKMS use, just the regular build: >>>>> >>>>> [rick@prophead rtl8812AU-master]$ uname -r >>>>> 4.11.8-200.fc25.x86_64 >>>>> >>>>> [rick@prophead rtl8812AU-master]$ modinfo 8812au.ko >>>>> filename: /home/rick/Downloads/Drivers/rtl8812AU-master/8812au.ko >>>>> version: v5.1.5_19247.20160830 >>>>> author: Realtek Semiconductor Corp. >>>>> description: Realtek Wireless Lan Driver >>>>> license: GPL >>>>> srcversion: C550A52D7A7F27740561522 >>>>> alias: usb:v2604p0012d*dc*dsc*dp*ic*isc*ip*in* >>>>> alias: usb:v2001p3316d*dc*dsc*dp*ic*isc*ip*in* >>>>> alias: usb:v2001p3315d*dc*dsc*dp*ic*isc*ip*in* >>>>> alias: usb:v07B8p8812d*dc*dsc*dp*ic*isc*ip*in* >>>>> alias: usb:v2019pAB30d*dc*dsc*dp*ic*isc*ip*in* >>>>> alias: usb:v1740p0100d*dc*dsc*dp*ic*isc*ip*in* >>>>> alias: usb:v1058p0632d*dc*dsc*dp*ic*isc*ip*in* >>>>> alias: usb:v2001p3313d*dc*dsc*dp*ic*isc*ip*in* >>>>> alias: usb:v0586p3426d*dc*dsc*dp*ic*isc*ip*in* >>>>> alias: usb:v0E66p0022d*dc*dsc*dp*ic*isc*ip*in* >>>>> alias: usb:v0B05p17D2d*dc*dsc*dp*ic*isc*ip*in* >>>>> alias: usb:v0409p0408d*dc*dsc*dp*ic*isc*ip*in* >>>>> alias: usb:v0789p016Ed*dc*dsc*dp*ic*isc*ip*in* >>>>> alias: usb:v04BBp0952d*dc*dsc*dp*ic*isc*ip*in* >>>>> alias: usb:v0DF6p0074d*dc*dsc*dp*ic*isc*ip*in* >>>>> alias: usb:v7392pA822d*dc*dsc*dp*ic*isc*ip*in* >>>>> alias: usb:v2001p330Ed*dc*dsc*dp*ic*isc*ip*in* >>>>> alias: usb:v050Dp1106d*dc*dsc*dp*ic*isc*ip*in* >>>>> alias: usb:v0BDAp881Cd*dc*dsc*dp*ic*isc*ip*in* >>>>> alias: usb:v0BDAp881Bd*dc*dsc*dp*ic*isc*ip*in* >>>>> alias: usb:v0BDAp881Ad*dc*dsc*dp*ic*isc*ip*in* >>>>> alias: usb:v0BDAp8812d*dc*dsc*dp*ic*isc*ip*in* >>>>> depends: cfg80211 >>>>> vermagic: 4.11.8-200.fc25.x86_64 SMP mod_unload >>>>> >>>>> <other stuff snipped> >>>> I have the kernel-devel, kernel-headers and the elfutils package already >>>> installed but it makes no difference. One thing of note with this is, I >>>> have copied the source code to Ubuntu and the latest update has upgraded >>>> their kernel (Ubuntu 16.10) to 4.8.8, I don't know how their kernel >>>> numbering relates to Fedora's numbering, and it compile quite happily >>>> via dkms. I have also tried a straight make from the source code >>>> directory and it fails with the same errors. I have copied a snippet of >>>> one of the errors below. >>>> >>>> >>>> In file included from >>>> /usr/local/downloads/dwa192/rtl8814AU-driver-4.3.21/include/drv_types.h:32:0, >>>> >>>> >>>> from >>>> /usr/local/downloads/dwa192/rtl8814AU-driver-4.3.21/core/rtw_cmd.c:22: >>>> /usr/local/downloads/dwa192/rtl8814AU-driver-4.3.21/include/osdep_service.h: >>>> >>>> In function ‘thread_enter’: >>>> /usr/local/downloads/dwa192/rtl8814AU-driver-4.3.21/include/osdep_service.h:343:2: >>>> >>>> error: implicit declaration of function ‘allow_signal’ >>>> [-Werror=implicit-function-declaration] >>>> allow_signal(SIGTERM); >>>> ^~~~~~~~~~~~ >>>> >>>> Just having a look at this error, is this because the makefile has the >>>> -Werror parameter specified, or is it something supplied by the compiler >>>> itself? >>>> >>>> In the messages above I am compiling the rtl8814AU driver but the >>>> rtl8812AU driver I downloaded is getting exactly the same errors. >>> It appears you're using a different driver than the 8812AU driver I >>> built from github at: >>> >>> https://github.com/gnab/rtl8812au >>> >>> Digging through the source, it appears to be v5.1.5_19247.20160830. >>> I included the USB device listings above. Do an "lsusb" with your >>> device plugged in and see if the vendor and product match one of the >>> entries above, e.g.: >>> >>> alias: usb:v1058p0632d*dc*dsc*dp*ic*isc*ip*in* >>> ^^^^ ^^^^ >>> |||| |||| >>> |||| -------> USB Product ID >>> ------------> USB Vendor ID >>> >>> Perhaps it'll match up. >>> >>> That all being said, I pulled down your driver (the rtl8814AU) version >>> from >>> >>> https://github.com/diederikdehaas/rtl8814AU >>> >>> and built it. There is a bug in one of the header files. If you want >>> to fix it, go into your >>> >>> /usr/local/downloads/dwa192/rtl8814AU-driver-4.3.21/include >>> >>> directory and edit the "osdep_service_linux.h" file. Go down to line >>> 59 or so and insert the following lines BELOW the line that reads >>> "#include <linux/vmalloc.h>" >>> >>> #if (LINUX_VERSION_CODE >= KERNEL_VERSION(4, 11, 0)) >>> #include <linux/sched/signal.h> >>> #endif >>> >>> This adds the definition of the functions that the compiler is bitching >>> about. Then try "make" again. Worked for me: >>> >>> [rick@prophead rtl8814AU-driver-4.3.21]$ modinfo 8814au.ko >>> filename: >>> /home/rick/Downloads/Drivers/rtl8814AU-driver-4.3.21/8814au.ko >>> version: v4.3.21_17997.20160531 >>> author: Realtek Semiconductor Corp. >>> description: Realtek Wireless Lan Driver >>> license: GPL >>> srcversion: E16A7178CDD95B68C2D2259 >>> alias: usb:v7392pA834d*dc*dsc*dp*ic*isc*ip*in* >>> alias: usb:v056Ep400Dd*dc*dsc*dp*ic*isc*ip*in* >>> alias: usb:v056Ep400Bd*dc*dsc*dp*ic*isc*ip*in* >>> alias: usb:v0B05p1817d*dc*dsc*dp*ic*isc*ip*in* >>> alias: usb:v2001p331Ad*dc*dsc*dp*ic*isc*ip*in* >>> alias: usb:v0BDAp8813d*dc*dsc*dp*ic*isc*ip*in* >>> depends: cfg80211 >>> vermagic: 4.11.8-200.fc25.x86_64 SMP mod_unload >> >> I apologise for sending my response directly to you Rick, it appears >> that I used reply instead of reply-list. >> >> I did the changes you suggested to my source code and the code did >> compile successfully, so I copied that code to the source location for >> dkms to pick it up from, and ran the dkms autoinstall process and it was >> compiled and built into the kernel successfully, and I now have wireless >> access back again. >> >> Thankyou for all your help. >> >> Just one question on this, with all the include files that are in that >> source, how did you find that what you have provided the solution for >> was the issue and what the needed include was and where it should be >> placed? > > You have to look at the error messages to see what's wrong. In this > case, it was complaining about an implicit declaration of the > "allow_signal()" function. The trick is that allow_signal() is a kernel > function and is defined in the kernel headers. To solve this sort of > weirdness, you have to understand a little bit about how Gnu make works > when building kernel modules. > > Part of the Makefile directs make to "cd" to the kernel build directory > via this command: > > modules: > $(MAKE) ARCH=$(ARCH) CROSS_COMPILE=$(CROSS_COMPILE) -C $(KSRC) > M=$(shell pwd) modules > > Where "$(KSRC)" is determined via: > > KVER := $(shell uname -r) > KSRC := /lib/modules/$(KVER)/build > > earlier in the Makefile. The "M" variable is where the module source > code is. When make runs, it fills in the "M" variable and then "cd"s to > the kernel source directory so "#include <...>" things will now be based > on the kernel source directory as the base directory for the build (see > below). > > I looked through the module's headers and saw no references to the > kernel header that declares the allow_signal() function, so I added > code to the header in the module source where os-specific things were > done which includes the kernel header in question if the kernel was > V4.11 or higher and keeping in mind that at that point, the make is > running in the kernel source directory--NOT the module's source > directory. At this point, I should have also mentioned that the kernel source has a Makefile that is invoked at the "cd" time and it does some stuff depending on the "modules" part of that make command above. It's a convoluted thing. > Without the "-C whateverdirectory" option, an "#include <blah>" (with > angle brackets) will start looking at /usr/include for headers. With the > "-C", then "#include <blah>" starts at the directory defined by the "-C" > option. The "-C" doesn't affect '#include ""' directives (includes using > quotes--not angle brackets). It's a subtle but important nuance. > > Probably more detail than you really wanted to know. I'm just glad it > works for you. You might want to send a note to the github repo about > this issue. I'm sure they'd be happy to find out about it and actually > have a ready-made fix. You'd be a hero! > ---------------------------------------------------------------------- > - Rick Stevens, Systems Engineer, AllDigital ricks@xxxxxxxxxxxxxx - > - AIM/Skype: therps2 ICQ: 226437340 Yahoo: origrps2 - > - - > - You possess a mind not merely twisted, but actually sprained. - > ---------------------------------------------------------------------- > _______________________________________________ > users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx > -- ---------------------------------------------------------------------- - Rick Stevens, Systems Engineer, AllDigital ricks@xxxxxxxxxxxxxx - - AIM/Skype: therps2 ICQ: 226437340 Yahoo: origrps2 - - - - Never eat anything larger than your head - ---------------------------------------------------------------------- _______________________________________________ users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx
