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. 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
