n 3/2/17 10:35 am, Rick Stevens wrote:
On 02/02/2017 01:07 PM, Stephen Morris wrote:
On 3/2/17 4:28 am, poma wrote:
On 02.02.2017 14:19, poma wrote:
On 01.02.2017 22:12, Stephen Morris wrote:
[...]
I'm about to try to interface the source code for this driver to
dkms so
that it will get compiled every time I boot from a new kernel, but at
the moment I'm not sure how to tell dkms where to find the source code,
so I'll have to try to investigate that.
"dkms.conf" of rtl8812AU is working example
https://github.com/diederikdehaas/rtl8812AU
# journalctl -o cat -b -u dkms
Starting Builds and install new kernel modules through DKMS...
Kernel preparation unnecessary for this kernel. Skipping...
Building module:
cleaning build area...
'make'......................................
cleaning build area...
DKMS: build completed.
8812au.ko:
Running module version sanity check.
- Original module
- No original module exists within this kernel
- Installation
- Installing to /lib/modules/4.9.6-100.fc24.x86_64/extra/
Adding any weak-modules
depmod......
DKMS: install completed.
Kernel preparation unnecessary for this kernel. Skipping...
Building module:
cleaning build area...
'make'................................
cleaning build area...
DKMS: build completed.
8814au.ko:
Running module version sanity check.
- Original module
- No original module exists within this kernel
- Installation
- Installing to /lib/modules/4.9.6-100.fc24.x86_64/extra/
Adding any weak-modules
depmod....
DKMS: install completed.
Started Builds and install new kernel modules through DKMS.
# modinfo -k $(uname -r) -n 8812au 8814au
/lib/modules/4.9.6-100.fc24.x86_64/extra/8812au.ko
/lib/modules/4.9.6-100.fc24.x86_64/extra/8814au.ko
# modprobe -v 8812au ; modprobe -v 8814au
insmod /lib/modules/4.9.6-100.fc24.x86_64/kernel/net/rfkill/rfkill.ko.xz
insmod
/lib/modules/4.9.6-100.fc24.x86_64/kernel/net/wireless/cfg80211.ko.xz
insmod /lib/modules/4.9.6-100.fc24.x86_64/extra/8812au.ko
insmod /lib/modules/4.9.6-100.fc24.x86_64/extra/8814au.ko
# dmesg -t
...
RTL871X: module init start
RTL871X: rtl8821au v4.3.14
RTL871X: rtl8821au BT-Coex version = BTCOEX20150128-51
usbcore: registered new interface driver rtl8821au
RTL871X: module init ret=0
RTL871X: module init start
RTL871X: rtl8814au v4.3.21_17997.20160531
usbcore: registered new interface driver rtl8814au
RTL871X: module init ret=0
DKMS - RTL8814AU,
as explained for RTL8812AU here:
https://github.com/diederikdehaas/rtl8812AU
$ git clone https://github.com/diederikdehaas/rtl8814AU.git
$ cd rtl8814AU/
...
// eventual steps, previously mentioned
...
$ curl -JLO
https://raw.githubusercontent.com/diederikdehaas/rtl8812AU/driver-4.3.14/dkms.conf
$ sed -i 's/12/14/g' dkms.conf
$ git add .
$ git commit -m "Added dkms.conf"
$ git tag 4.3.21_17997.20160531
$ su
# DRV_NAME=rtl8814AU
# DRV_VERSION=4.3.21_17997.20160531
# mkdir /usr/src/${DRV_NAME}-${DRV_VERSION}
# git archive ${DRV_VERSION} | tar -x -C
/usr/src/${DRV_NAME}-${DRV_VERSION}
# dkms add -m ${DRV_NAME} -v ${DRV_VERSION}
# dkms build -m ${DRV_NAME} -v ${DRV_VERSION}
# dkms install -m ${DRV_NAME} -v ${DRV_VERSION}
# modinfo 8814au -F version
# modprobe -v 8814au
'modprobe' goes if the device is already plugged in,
otherwise re-plug USB device, and if VID/PID of device and driver
match - auto loading kicks in.
I think I have worked out the issue with the flashing light on the
device, it seems to be functioning the same way as the flashing lights
on ethernet pci cards, which from the functionality of the vendor
supplied driver under windows, is not the vendor intended mode of
operation.
I now have two issues with the device, one is dkms and the other is
standard networking functionality.
For dkms I have used the rtl8812au dkms.conf as my starting point. My
file is below.
PACKAGE_NAME="rtl8814AU"
PACKAGE_VERSION="4.3.21"
BUILT_MODULE_NAME[0]="8814au"
MAKE="'make' -j3 KVER=${kernelver}"
CLEAN="'make' clean"
DEST_MODULE_LOCATION[0]="/updates/dkms"
AUTOINSTALL="YES"
The driver source code is stored in directory /usr/src/rtl8814AU-4.3.21,
does the version number in the directory name and the 'PACKAGE_VERSION'
in the conf file have to match the internal version number in the driver
for the boot time compile of the driver to work?
I've added the -j3 in the make to get the multi-threaded compile and
I've added the KVER parameter as from my search I did on the net I found
an article relative to an older version of Fedora that said the KVER
parameter must be added to get the driver compiled against the correct
kernel version at kernel install time (they said that without that
parameter the driver would be compiled against the running kernel, not
the newly installed kernel).
With the setup I have if I issue the commands:
sudo dkms build -c /usr/src/rtl8814AU-4.3.21/dkms.conf -m rtl8814AU
-v 4.3.21 and
sudo dkms install -c /usr/src/rtl8814AU-4.3.21/dkms.conf -m
rtl8814AU -v 4.3.21 and
sudo modprobe -v 8814au
they build, install and load the module successfully. I've also found
that the driver does not get loaded and used unless I issue the modprobe
command.
If I issue the command journalctl -o cat -b -u dkms I only get the two
messages below, which are also the only two message I get shown in the
boot display when the driver needs to be compiled for a new kernel.
Starting Builds and install new kernel modules through DKMS...
Started Builds and install new kernel modules through DKMS.
I'm also noticing that when the driver has already been compiled and
installed into the kernel, and I boot my machine, the mounts for my
network connected nas are failing again because the network via this
wireless device is not available. From the flashing of the light on the
device this driver is doing, the network appears to not actually
becoming active until after the display manager is started, and in my
case, I physically log into KDE.
That's normal if you don't have the network in question set to start
at boot. You need to make sure the
/etc/sysconfig/network-scripts/ifcfg-<name-of-connection>
file contains "ONBOOT=yes". Otherwise, they only come up when YOUR
instance of NetworkManager comes up (e.g. when you actually log into
your desktop).
Thanks Rick, I have a definition in networkmanager to connect to the
2.4GHz channel on my rounter named Linksys07468, which when I checked
the corresponding ifcfg file found that it indeed did have "ONBOOT=no".
I have changed it to yes but I don't understand why it was set that way
because I found that several days ago and changed it to yes, hence I'm
confused as to why it changed back.
Also I found a couple of days ago that for some reason I had two
definitions to the 5GHz channel on the router in Networkmanager both
name Linksys07468_5Ghz, one of which Networkmanager said had not been
used and the other it said had been used an hour before, so I deleted
the one that was flagged as not having been used. Looking in
/etc/sysconfig/network-scripts there is a file in there named
ifcfg-Linksys07648_5Ghz-1 which does have "ONBOOT=yes", does that ifcfg
file need to have the "-1" removed from it to match the connection name
in Networkmanager?
As a side issue to this, just for info, the names of the entries I have
in Networkmanager are named to match the SSID's exposed by my router.
I know that dkms is being run at boot time as I can see the 'job start
timer messages' for dkms, akmod and firewalld, which all seem to be
running in parallel and halt the boot process until they have started,
all disappear and the boot continue.
Is the issue I am seeing with the network expected functionality or is
it an indication there is a timing issue in the driver?
As I said, that's normal unless the "ONBOOT=yes" flag is set in the
aforementioned file(s). I'm not sure if this corresponds to the NM
"Automatically connect to this network when it is available" option or
not. Just try setting the flag in the appropriate file and reboot.
You should also be aware that there are occasions where systemd tries
to mount the filesystems before the network actually comes up--even on
systems with historically 100% functional networking. It is a race
condition that has been a thorn in many people's sides for quite a
while. This can also cause problems with shutting your system down
cleanly. Shutdown will seem to hang for 90 seconds, then systemd
times out, sends a SIGTERM to all processes, and the system finally
shuts down. Maybe. You may have to power-cycle it. Grrrr!
I encountered this shutdown issue two days ago when I was trying to
shutdown, it just sat at a black screen and I had to actually power the
machine off so I could go to work.
regards,
Steve
----------------------------------------------------------------------
- Rick Stevens, Systems Engineer, AllDigital ricks@xxxxxxxxxxxxxx -
- AIM/Skype: therps2 ICQ: 226437340 Yahoo: origrps2 -
- -
- Grabel's Law: 2 is not equal to 3--not even for large values of 2. -
----------------------------------------------------------------------
_______________________________________________
users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx
_______________________________________________
users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx
