3:14 p.m.
Hi,
To test out dkms compiling and installing my wifi driver I have
uninstalled the driver from the kernel with dkms, removed the driver
from dkms and re-added the driver to dkms.
When I boot Fedora dkms compiles and installs the driver into the
kernel but it does not issue a modprobe to actually load the driver, how
do I force dkms to do so, or alternatively am I missing the package that
would provide that functionality?
regards,
Steve
9:43 p.m.
On 02/13/17 05:14, Stephen Morris wrote:
To test out dkms compiling and installing my wifi driver I have
uninstalled the driver from the kernel with dkms, removed the driver
from dkms and re-added the driver to dkms.
When I boot Fedora dkms compiles and installs the driver into the
kernel but it does not issue a modprobe to actually load the driver,
how do I force dkms to do so, or alternatively am I missing the
package that would provide that functionality?
This sounds similar to the problem I'm seeing with the vboxvideo driver.
When a new kernel is built the vboxvideo driver is built for the newly
installed kernel. However, on reboot it does not get loaded. The
system comes up with dkms.service running in the background again
building the VBox modules. After that finishes I can reboot and the
system will come up the modules loaded and the proper display configuration.
I checked the sha256sum of the modules built by the kernel install and
the dkms.service and they match. I also checked the selinux contexts of
those and they matched.
I have done some checking and have yet to determine why dkms feels the
need to rebuild the modules.
Does the module loading succeed on subsequent boots?
--
Fedora Users List - The place to go to get others to do the work for you
11:46 p.m.
On 02/13/17 11:43, Ed Greshko wrote:
I have done some checking and have yet to determine why dkms feels
the
need to rebuild the modules.
Does the module loading succeed on subsequent boots?
Well, my knowledge seems "Out of Date".
Even though the additions install process mentions "dkms" it isn't using
dkms.
On kernel install the postinstall script is vboxadd and on startup it is
using systemd vboxadd service files. So, it would see, the there is a
difference between those 2 in my case.
--
Fedora Users List - The place to go to get others to do the work for you
3:21 a.m.
On 13/02/2017 15:46, Ed Greshko wrote:
On 02/13/17 11:43, Ed Greshko wrote:
> I have done some checking and have yet to determine why dkms feels the
> need to rebuild the modules.
>
> Does the module loading succeed on subsequent boots?
Well, my knowledge seems "Out of Date".
Even though the additions install process mentions "dkms" it isn't using
dkms.
On kernel install the postinstall script is vboxadd and on startup it is
using systemd vboxadd service files. So, it would see, the there is a
difference between those 2 in my case.
I've just cold started into Linux to get the info to setup my wife's
email after an android upgrade destroyed the ability for kmail to work
on existing accounts, and, the kernel module was loaded at boot time and
the network driver mounts worked successfully. I wasn't trying after a
kernel upgrade, I forced the removal and re-add to simulate a new kernel
to get dkms to compile the driver at boot time. Before I respond to the
other thread I had raised around the network device not being available
at boot time I'll need to do some more checking, but it looks like
systemd or networkmanager or something else in Fedora couldn't handle 2
wifi devices with the first device not being configured in
networkmanager at all and the second device configured with 'ONBOOT=yes'
on the 802.11AC interface. What I don't know is whether or not Fedora is
trying to simulate Ubuntu which starts the 802.11n device at boot even
though its not defined in networkmanager but successfully starts the
802.11AC device which is defined in networkmanager. I've removed the
802.11n device which has made the difference with the 802.11AC device
being available at boot time (what I don't understand at the moment is
why, when I configured the usb device to start with the 802.11n
interface rather than the 802.11AC interface the device was available at
boot time and the fact that there was another 802.11n wifi device
physically present and usable did not have any impact.).
The dkms issue may be an upstream issue as I think dkms under Ubuntu has
the same issue relative to modprobe but I'll need to try the same test
that I did under Fedora, if a kernel upgrade doesn't occur first.
regards,
Steve
2:22 p.m.
On 13/02/2017 19:21, Stephen Morris wrote:
On 13/02/2017 15:46, Ed Greshko wrote:
> On 02/13/17 11:43, Ed Greshko wrote:
>> I have done some checking and have yet to determine why dkms feels the
>> need to rebuild the modules.
>>
>> Does the module loading succeed on subsequent boots?
>
> Well, my knowledge seems "Out of Date".
>
> Even though the additions install process mentions "dkms" it isn't
using
> dkms.
>
> On kernel install the postinstall script is vboxadd and on startup it is
> using systemd vboxadd service files. So, it would see, the there is a
> difference between those 2 in my case.
>
I've just cold started into Linux to get the info to setup my wife's
email after an android upgrade destroyed the ability for kmail to work
on existing accounts, and, the kernel module was loaded at boot time
and the network driver mounts worked successfully. I wasn't trying
after a kernel upgrade, I forced the removal and re-add to simulate a
new kernel to get dkms to compile the driver at boot time. Before I
respond to the other thread I had raised around the network device not
being available at boot time I'll need to do some more checking, but
it looks like systemd or networkmanager or something else in Fedora
couldn't handle 2 wifi devices with the first device not being
configured in networkmanager at all and the second device configured
with 'ONBOOT=yes' on the 802.11AC interface. What I don't know is
whether or not Fedora is trying to simulate Ubuntu which starts the
802.11n device at boot even though its not defined in networkmanager
but successfully starts the 802.11AC device which is defined in
networkmanager. I've removed the 802.11n device which has made the
difference with the 802.11AC device being available at boot time (what
I don't understand at the moment is why, when I configured the usb
device to start with the 802.11n interface rather than the 802.11AC
interface the device was available at boot time and the fact that
there was another 802.11n wifi device physically present and usable
did not have any impact.).
The dkms issue may be an upstream issue as I think dkms under Ubuntu
has the same issue relative to modprobe but I'll need to try the same
test that I did under Fedora, if a kernel upgrade doesn't occur first.
regards,
Steve
I've removed the driver from DKMS in Ubuntu and re-added it, then run a
DKMS AUTOINSTALL to rebuild and re-install the driver back into the
running kernel and under Ubuntu the modprobe command to active the
driver is not issued either, but also under Ubuntu is seems that when
the rmmod command is issued to remove the driver from the running kernel
which removes wifi access, the dns resolver service seems to also be
shutdown, because after the driver is rebuilt by DKMS and the modprobe
issued a sudo apt-get update fails to be able to resolve the repository
names.
I've tried the same thing under Fedora to see if Fedora has the same
functionality, which fortunately Fedora doesn't, after the DKMS process
is done and the modprobe issued a sudo dnf update successfully refreshes
the repository lists and installs any available updates after prompting
whether or not to do so.
regards,
Steve
_______________________________________________
users mailing list -- users(a)lists.fedoraproject.org
To unsubscribe send an email to users-leave(a)lists.fedoraproject.org
5:39 p.m.
On 02/13/2017 12:22 PM, Stephen Morris wrote:
On 13/02/2017 19:21, Stephen Morris wrote:
I've removed the driver from DKMS in Ubuntu and re-added it, then run a
DKMS AUTOINSTALL to rebuild and re-install the driver back into the
running kernel and under Ubuntu the modprobe command to active the
driver is not issued either, but also under Ubuntu is seems that when
the rmmod command is issued to remove the driver from the running kernel
which removes wifi access, the dns resolver service seems to also be
shutdown, because after the driver is rebuilt by DKMS and the modprobe
issued a sudo apt-get update fails to be able to resolve the repository
names.
I've tried the same thing under Fedora to see if Fedora has the same
functionality, which fortunately Fedora doesn't, after the DKMS process
is done and the modprobe issued a sudo dnf update successfully refreshes
the repository lists and installs any available updates after prompting
whether or not to do so.
I've been watching this thread a bit and I'm not a DKMS user, but
from what I can gather, DKMS should do an automatic modprobe when
a kernel is upgraded or whatever based on certain criteria. Section 2
of the webpage at:
https://wiki.centos.org/HowTos/BuildingKernelModules
describes the process (the example is a patched CIFS filesystem). In a
nutshell:
1. The module's source directory must be in
/usr/src/<module>-<version>
2. There is a "dkms.conf" file in that directory that contains
some specific info.
3. It has been added to the DKMS tree via "dkms add"
4. It has been built under DKMS control via "dkms build"
5. It has been installed under DKMS control via "dkms install"
Note that I've never tried a DKMS add-on module, but that seems to be
the way it's done. I think that dkms.conf file is pretty critical,
along with the "dkms add", "dkms build" and "dkms install".
I don't
believe "dkms autoinstall" would modprobe modules that weren't added,
built and install using dkms as they weren't fully inserted under dkms'
care. That's just a guess.
----------------------------------------------------------------------
- Rick Stevens, Systems Engineer, AllDigital ricks(a)alldigital.com -
- AIM/Skype: therps2 ICQ: 226437340 Yahoo: origrps2 -
- -
- Artificial Intelligence usually beats real stupidity. -
----------------------------------------------------------------------
6:38 p.m.
On 02/13/2017 03:39 PM, Rick Stevens wrote:
On 02/13/2017 12:22 PM, Stephen Morris wrote:
> On 13/02/2017 19:21, Stephen Morris wrote:
> I've removed the driver from DKMS in Ubuntu and re-added it, then run a
> DKMS AUTOINSTALL to rebuild and re-install the driver back into the
> running kernel and under Ubuntu the modprobe command to active the
> driver is not issued either, but also under Ubuntu is seems that when
> the rmmod command is issued to remove the driver from the running kernel
> which removes wifi access, the dns resolver service seems to also be
> shutdown, because after the driver is rebuilt by DKMS and the modprobe
> issued a sudo apt-get update fails to be able to resolve the repository
> names.
> I've tried the same thing under Fedora to see if Fedora has the same
> functionality, which fortunately Fedora doesn't, after the DKMS process
> is done and the modprobe issued a sudo dnf update successfully refreshes
> the repository lists and installs any available updates after prompting
> whether or not to do so.
I've been watching this thread a bit and I'm not a DKMS user, but
from what I can gather, DKMS should do an automatic modprobe when
a kernel is upgraded or whatever based on certain criteria. Section 2
of the webpage at:
https://wiki.centos.org/HowTos/BuildingKernelModules
describes the process (the example is a patched CIFS filesystem). In a
nutshell:
1. The module's source directory must be in
/usr/src/<module>-<version>
2. There is a "dkms.conf" file in that directory that contains
some specific info.
3. It has been added to the DKMS tree via "dkms add"
4. It has been built under DKMS control via "dkms build"
5. It has been installed under DKMS control via "dkms install"
Note that I've never tried a DKMS add-on module, but that seems to be
the way it's done. I think that dkms.conf file is pretty critical,
along with the "dkms add", "dkms build" and "dkms install".
I don't
believe "dkms autoinstall" would modprobe modules that weren't added,
built and install using dkms as they weren't fully inserted under dkms'
care. That's just a guess.
I just built a module (evdi) under DKMS for a Mimo USB-based display. I
don't have the hardware handy (it's here somewhere), but I copied the
driver source to /usr/src/evdi-1.2.65 and created a dkms.conf file in
there that contains:
PACKAGE_NAME="evdi"
PACKAGE_VERSION=1.0.0
AUTOINSTALL=yes
MAKE[0]="make all INCLUDEDIR=/lib/modules/$kernelver/build/include
KVERSION=$kernelver DKMS_BUILD=1"
DEST_MODULE_LOCATION[0]="/kernel/drivers/gpu/drm/evdi"
BUILT_MODULE_NAME[0]="evdi"
CLEAN="make clean DKMS_BUILD=1"
Then I did (as root):
dkms add -m evdi -v 1.2.65
That added it to dkms' build stack as witnessed by dkms creating a
/var/lib/dkms/evdi/1.2.65 directory with a subdirectory named after the
current kernel version and a symlink, "source", pointing at
/usr/src/evdi-1.2.65. The next command:
dkms build -m evdi -v 1.2.65
actually built the driver, creating an "x86_64" subdirectory below the
kernel version directory with "log" and "module" subdirs below that.
The log subdirectory contains the build log of the module and the
module subdir contains the actual module (evdi.ko). I then ran:
dkms install -m evdi -v 1.2.65
and saw dkms install the module into /lib/modules/`uname -r`/extra/ and
do a full depmod:
# dkms install -m evdi -v 1.2.65
evdi:
Running module version sanity check.
- Original module
- No original module exists within this kernel
- Installation
- Installing to /lib/modules/4.9.7-201.fc25.x86_64/extra/
Adding any weak-modules
depmod.......
DKMS: install completed.
Doing a "modinfo evdi" returns the data I'd expect.
I won't know if it auto-modprobes until I get the new kernel update
and find the Mimo display and plug it in. Just thought you'd like to
see what I've done.
----------------------------------------------------------------------
- Rick Stevens, Systems Engineer, AllDigital ricks(a)alldigital.com -
- AIM/Skype: therps2 ICQ: 226437340 Yahoo: origrps2 -
- -
- grep me no patterns and I'll tell you no lines -
----------------------------------------------------------------------
12:42 p.m.
On 02/13/2017 04:38 PM, Rick Stevens wrote:
On 02/13/2017 03:39 PM, Rick Stevens wrote:
> On 02/13/2017 12:22 PM, Stephen Morris wrote:
>> On 13/02/2017 19:21, Stephen Morris wrote:
>> I've removed the driver from DKMS in Ubuntu and re-added it, then run a
>> DKMS AUTOINSTALL to rebuild and re-install the driver back into the
>> running kernel and under Ubuntu the modprobe command to active the
>> driver is not issued either, but also under Ubuntu is seems that when
>> the rmmod command is issued to remove the driver from the running kernel
>> which removes wifi access, the dns resolver service seems to also be
>> shutdown, because after the driver is rebuilt by DKMS and the modprobe
>> issued a sudo apt-get update fails to be able to resolve the repository
>> names.
>> I've tried the same thing under Fedora to see if Fedora has the same
>> functionality, which fortunately Fedora doesn't, after the DKMS process
>> is done and the modprobe issued a sudo dnf update successfully refreshes
>> the repository lists and installs any available updates after prompting
>> whether or not to do so.
>
> I've been watching this thread a bit and I'm not a DKMS user, but
> from what I can gather, DKMS should do an automatic modprobe when
> a kernel is upgraded or whatever based on certain criteria. Section 2
> of the webpage at:
>
> https://wiki.centos.org/HowTos/BuildingKernelModules
>
> describes the process (the example is a patched CIFS filesystem). In a
> nutshell:
>
> 1. The module's source directory must be in
>
> /usr/src/<module>-<version>
>
> 2. There is a "dkms.conf" file in that directory that contains
> some specific info.
>
> 3. It has been added to the DKMS tree via "dkms add"
>
> 4. It has been built under DKMS control via "dkms build"
>
> 5. It has been installed under DKMS control via "dkms install"
>
> Note that I've never tried a DKMS add-on module, but that seems to be
> the way it's done. I think that dkms.conf file is pretty critical,
> along with the "dkms add", "dkms build" and "dkms
install". I don't
> believe "dkms autoinstall" would modprobe modules that weren't added,
> built and install using dkms as they weren't fully inserted under dkms'
> care. That's just a guess.
I just built a module (evdi) under DKMS for a Mimo USB-based display. I
don't have the hardware handy (it's here somewhere), but I copied the
driver source to /usr/src/evdi-1.2.65 and created a dkms.conf file in
there that contains:
PACKAGE_NAME="evdi"
PACKAGE_VERSION=1.0.0
AUTOINSTALL=yes
MAKE[0]="make all INCLUDEDIR=/lib/modules/$kernelver/build/include
KVERSION=$kernelver DKMS_BUILD=1"
DEST_MODULE_LOCATION[0]="/kernel/drivers/gpu/drm/evdi"
BUILT_MODULE_NAME[0]="evdi"
CLEAN="make clean DKMS_BUILD=1"
Then I did (as root):
dkms add -m evdi -v 1.2.65
That added it to dkms' build stack as witnessed by dkms creating a
/var/lib/dkms/evdi/1.2.65 directory with a subdirectory named after the
current kernel version and a symlink, "source", pointing at
/usr/src/evdi-1.2.65. The next command:
dkms build -m evdi -v 1.2.65
actually built the driver, creating an "x86_64" subdirectory below the
kernel version directory with "log" and "module" subdirs below that.
The log subdirectory contains the build log of the module and the
module subdir contains the actual module (evdi.ko). I then ran:
dkms install -m evdi -v 1.2.65
and saw dkms install the module into /lib/modules/`uname -r`/extra/ and
do a full depmod:
# dkms install -m evdi -v 1.2.65
evdi:
Running module version sanity check.
- Original module
- No original module exists within this kernel
- Installation
- Installing to /lib/modules/4.9.7-201.fc25.x86_64/extra/
Adding any weak-modules
depmod.......
DKMS: install completed.
Doing a "modinfo evdi" returns the data I'd expect.
I won't know if it auto-modprobes until I get the new kernel update
and find the Mimo display and plug it in. Just thought you'd like to
see what I've done.
UPDATE: Just got the new kernel and dkms did build the module for the
kernel without me telling it to.
I located the display device, plugged it in and it "just worked." I
did NOT see the module in the output of "lsmod" but the device did
work. I don't know why it doesn't show up in lsmod, but it may be that
this is an X/Wayland module only, even though it's a ".ko" file.
----------------------------------------------------------------------
- Rick Stevens, Systems Engineer, AllDigital ricks(a)alldigital.com -
- AIM/Skype: therps2 ICQ: 226437340 Yahoo: origrps2 -
- -
- The trouble with troubleshooting is that trouble sometimes -
- shoots back. -
----------------------------------------------------------------------
3:27 p.m.
On 15/02/2017 04:42, Rick Stevens wrote:
On 02/13/2017 04:38 PM, Rick Stevens wrote:
> On 02/13/2017 03:39 PM, Rick Stevens wrote:
>> On 02/13/2017 12:22 PM, Stephen Morris wrote:
>>> On 13/02/2017 19:21, Stephen Morris wrote:
>>> I've removed the driver from DKMS in Ubuntu and re-added it, then run a
>>> DKMS AUTOINSTALL to rebuild and re-install the driver back into the
>>> running kernel and under Ubuntu the modprobe command to active the
>>> driver is not issued either, but also under Ubuntu is seems that when
>>> the rmmod command is issued to remove the driver from the running kernel
>>> which removes wifi access, the dns resolver service seems to also be
>>> shutdown, because after the driver is rebuilt by DKMS and the modprobe
>>> issued a sudo apt-get update fails to be able to resolve the repository
>>> names.
>>> I've tried the same thing under Fedora to see if Fedora has the same
>>> functionality, which fortunately Fedora doesn't, after the DKMS process
>>> is done and the modprobe issued a sudo dnf update successfully refreshes
>>> the repository lists and installs any available updates after prompting
>>> whether or not to do so.
>> I've been watching this thread a bit and I'm not a DKMS user, but
>> from what I can gather, DKMS should do an automatic modprobe when
>> a kernel is upgraded or whatever based on certain criteria. Section 2
>> of the webpage at:
>>
>> https://wiki.centos.org/HowTos/BuildingKernelModules
>>
>> describes the process (the example is a patched CIFS filesystem). In a
>> nutshell:
>>
>> 1. The module's source directory must be in
>>
>> /usr/src/<module>-<version>
>>
>> 2. There is a "dkms.conf" file in that directory that contains
>> some specific info.
>>
>> 3. It has been added to the DKMS tree via "dkms add"
>>
>> 4. It has been built under DKMS control via "dkms build"
>>
>> 5. It has been installed under DKMS control via "dkms install"
>>
>> Note that I've never tried a DKMS add-on module, but that seems to be
>> the way it's done. I think that dkms.conf file is pretty critical,
>> along with the "dkms add", "dkms build" and "dkms
install". I don't
>> believe "dkms autoinstall" would modprobe modules that weren't
added,
>> built and install using dkms as they weren't fully inserted under dkms'
>> care. That's just a guess.
> I just built a module (evdi) under DKMS for a Mimo USB-based display. I
> don't have the hardware handy (it's here somewhere), but I copied the
> driver source to /usr/src/evdi-1.2.65 and created a dkms.conf file in
> there that contains:
>
> PACKAGE_NAME="evdi"
> PACKAGE_VERSION=1.0.0
> AUTOINSTALL=yes
>
> MAKE[0]="make all INCLUDEDIR=/lib/modules/$kernelver/build/include
> KVERSION=$kernelver DKMS_BUILD=1"
> DEST_MODULE_LOCATION[0]="/kernel/drivers/gpu/drm/evdi"
> BUILT_MODULE_NAME[0]="evdi"
> CLEAN="make clean DKMS_BUILD=1"
>
> Then I did (as root):
>
> dkms add -m evdi -v 1.2.65
>
> That added it to dkms' build stack as witnessed by dkms creating a
> /var/lib/dkms/evdi/1.2.65 directory with a subdirectory named after the
> current kernel version and a symlink, "source", pointing at
> /usr/src/evdi-1.2.65. The next command:
>
> dkms build -m evdi -v 1.2.65
>
> actually built the driver, creating an "x86_64" subdirectory below the
> kernel version directory with "log" and "module" subdirs below
that.
> The log subdirectory contains the build log of the module and the
> module subdir contains the actual module (evdi.ko). I then ran:
>
> dkms install -m evdi -v 1.2.65
>
> and saw dkms install the module into /lib/modules/`uname -r`/extra/ and
> do a full depmod:
>
> # dkms install -m evdi -v 1.2.65
>
> evdi:
> Running module version sanity check.
> - Original module
> - No original module exists within this kernel
> - Installation
> - Installing to /lib/modules/4.9.7-201.fc25.x86_64/extra/
> Adding any weak-modules
>
> depmod.......
>
> DKMS: install completed.
>
> Doing a "modinfo evdi" returns the data I'd expect.
>
> I won't know if it auto-modprobes until I get the new kernel update
> and find the Mimo display and plug it in. Just thought you'd like to
> see what I've done.
UPDATE: Just got the new kernel and dkms did build the module for the
kernel without me telling it to.
I located the display device, plugged it in and it "just worked." I
did NOT see the module in the output of "lsmod" but the device did
work. I don't know why it doesn't show up in lsmod, but it may be that
this is an X/Wayland module only, even though it's a ".ko" file.
Thanks for the info Rick, what you did to manually use dkms to build and
install the driver in to the kernel is the same process I went through
which didn't issue a modprobe to make the network device usable, so I
couldn't access the network until I manually issued a modprobe which
then made the device immediately usable.
I also tried it a different way by issuing the same manual steps but
each time specifying the -c parameter to point it to the dkms.conf file
but that achieved the same results. This method though did highlight
what I consider the be a bug in DKMS, in that I consider that if I
specify the -c parameter I should not have to specify the -m and -v
parameters, but my experience with it is that DKMS complains about
insufficient parameters when running the build and install steps if -m
and -v are not supplied.
Just one comment on your dkms.conf file contents you have listed above,
I'm surprised that your module gets compiled at boot time as the
documentation I have read on the dkms.conf file dictates that the value
for PACKAGE_VERSION must match the version part of the directory
containing the source code, so in your case it should be 1.2.65 not 1.0.0.
Just as a side info, there is a known bug in DKMS (which I encountered
in my testing trying to get things to work) that if, in your case, there
are multiple version directories in /var/lib/dkms/evdi and any of those
directories don't physically exist, dkms fails with an error that it
can't find dkms.conf.
From the documentation I have read, when DKMS runs at boot time to
check if it needs to build and install the driver into the running
kernel, the command that is issued is DKMS AUTOINSTALL, which is why
AUTOINSTALL=yes in dkms.conf is critical.
Just for reference I have listed the contents of my dkms.conf file. On
git.com where I obtained my driver code from there was also a branch for
and rtl8812au network driver, where they supplied a dkms.conf file, and
my dkms.conf is based on that.
PACKAGE_NAME="rtl8814AU"
PACKAGE_VERSION="4.3.21_17997.20160531"
BUILT_MODULE_NAME[0]="8814au"
MAKE="'make' -j3 KVER=${kernelver}"
CLEAN="'make' clean"
DEST_MODULE_LOCATION[0]="/updates/dkms"
AUTOINSTALL="YES"
For me DKMS loses a lot of it usefulness if the driver is not loaded
(modprobed) at boot time if a compile is required for the running kernel
as I have network mounts in /etc/fstab that I would prefer to not have
to mount manually every time a kernel update occurs if the driver is not
compiled at kernel install time. I also don't understand why these
issues are occurring under both F25 and Ubuntu 16.10 as up to the point
of where I stopped using Mandriva (when it was forked to Mageia) 3 - 5
years ago, I was using dkms all the time for multiple drivers and didn't
encounter any of these problems.
regards,
Steve
----------------------------------------------------------------------
- Rick Stevens, Systems Engineer, AllDigital ricks(a)alldigital.com -
- AIM/Skype: therps2 ICQ: 226437340 Yahoo: origrps2 -
- -
- The trouble with troubleshooting is that trouble sometimes -
- shoots back. -
----------------------------------------------------------------------
_______________________________________________
users mailing list -- users(a)lists.fedoraproject.org
To unsubscribe send an email to users-leave(a)lists.fedoraproject.org
5:53 p.m.
On 02/15/2017 01:27 PM, Stephen Morris wrote:
On 15/02/2017 04:42, Rick Stevens wrote:
> On 02/13/2017 04:38 PM, Rick Stevens wrote:
>> On 02/13/2017 03:39 PM, Rick Stevens wrote:
>>> On 02/13/2017 12:22 PM, Stephen Morris wrote:
>>>> On 13/02/2017 19:21, Stephen Morris wrote:
>>>> I've removed the driver from DKMS in Ubuntu and re-added it, then
>>>> run a
>>>> DKMS AUTOINSTALL to rebuild and re-install the driver back into the
>>>> running kernel and under Ubuntu the modprobe command to active the
>>>> driver is not issued either, but also under Ubuntu is seems that when
>>>> the rmmod command is issued to remove the driver from the running
>>>> kernel
>>>> which removes wifi access, the dns resolver service seems to also be
>>>> shutdown, because after the driver is rebuilt by DKMS and the modprobe
>>>> issued a sudo apt-get update fails to be able to resolve the
>>>> repository
>>>> names.
>>>> I've tried the same thing under Fedora to see if Fedora has the same
>>>> functionality, which fortunately Fedora doesn't, after the DKMS
>>>> process
>>>> is done and the modprobe issued a sudo dnf update successfully
>>>> refreshes
>>>> the repository lists and installs any available updates after
>>>> prompting
>>>> whether or not to do so.
>>> I've been watching this thread a bit and I'm not a DKMS user, but
>>> from what I can gather, DKMS should do an automatic modprobe when
>>> a kernel is upgraded or whatever based on certain criteria. Section 2
>>> of the webpage at:
>>>
>>> https://wiki.centos.org/HowTos/BuildingKernelModules
>>>
>>> describes the process (the example is a patched CIFS filesystem). In a
>>> nutshell:
>>>
>>> 1. The module's source directory must be in
>>>
>>> /usr/src/<module>-<version>
>>>
>>> 2. There is a "dkms.conf" file in that directory that contains
>>> some specific info.
>>>
>>> 3. It has been added to the DKMS tree via "dkms add"
>>>
>>> 4. It has been built under DKMS control via "dkms build"
>>>
>>> 5. It has been installed under DKMS control via "dkms install"
>>>
>>> Note that I've never tried a DKMS add-on module, but that seems to be
>>> the way it's done. I think that dkms.conf file is pretty critical,
>>> along with the "dkms add", "dkms build" and "dkms
install". I don't
>>> believe "dkms autoinstall" would modprobe modules that weren't
added,
>>> built and install using dkms as they weren't fully inserted under
dkms'
>>> care. That's just a guess.
>> I just built a module (evdi) under DKMS for a Mimo USB-based display. I
>> don't have the hardware handy (it's here somewhere), but I copied the
>> driver source to /usr/src/evdi-1.2.65 and created a dkms.conf file in
>> there that contains:
>>
>> PACKAGE_NAME="evdi"
>> PACKAGE_VERSION=1.0.0
>> AUTOINSTALL=yes
>>
>> MAKE[0]="make all INCLUDEDIR=/lib/modules/$kernelver/build/include
>> KVERSION=$kernelver DKMS_BUILD=1"
>> DEST_MODULE_LOCATION[0]="/kernel/drivers/gpu/drm/evdi"
>> BUILT_MODULE_NAME[0]="evdi"
>> CLEAN="make clean DKMS_BUILD=1"
>>
>> Then I did (as root):
>>
>> dkms add -m evdi -v 1.2.65
>>
>> That added it to dkms' build stack as witnessed by dkms creating a
>> /var/lib/dkms/evdi/1.2.65 directory with a subdirectory named after the
>> current kernel version and a symlink, "source", pointing at
>> /usr/src/evdi-1.2.65. The next command:
>>
>> dkms build -m evdi -v 1.2.65
>>
>> actually built the driver, creating an "x86_64" subdirectory below the
>> kernel version directory with "log" and "module" subdirs
below that.
>> The log subdirectory contains the build log of the module and the
>> module subdir contains the actual module (evdi.ko). I then ran:
>>
>> dkms install -m evdi -v 1.2.65
>>
>> and saw dkms install the module into /lib/modules/`uname -r`/extra/ and
>> do a full depmod:
>>
>> # dkms install -m evdi -v 1.2.65
>>
>> evdi:
>> Running module version sanity check.
>> - Original module
>> - No original module exists within this kernel
>> - Installation
>> - Installing to /lib/modules/4.9.7-201.fc25.x86_64/extra/
>> Adding any weak-modules
>>
>> depmod.......
>>
>> DKMS: install completed.
>>
>> Doing a "modinfo evdi" returns the data I'd expect.
>>
>> I won't know if it auto-modprobes until I get the new kernel update
>> and find the Mimo display and plug it in. Just thought you'd like to
>> see what I've done.
> UPDATE: Just got the new kernel and dkms did build the module for the
> kernel without me telling it to.
>
> I located the display device, plugged it in and it "just worked." I
> did NOT see the module in the output of "lsmod" but the device did
> work. I don't know why it doesn't show up in lsmod, but it may be that
> this is an X/Wayland module only, even though it's a ".ko" file.
Thanks for the info Rick, what you did to manually use dkms to build and
install the driver in to the kernel is the same process I went through
which didn't issue a modprobe to make the network device usable, so I
couldn't access the network until I manually issued a modprobe which
then made the device immediately usable.
Can't speak to that. The MIMO device worked when I plugged it in,
but the module was NOT listed in "lsmod", so the module may be X or
Wayland-specific and loaded by that software...not the kernel in
general.
I also tried it a different way by issuing the same manual steps but
each time specifying the -c parameter to point it to the dkms.conf file
but that achieved the same results. This method though did highlight
what I consider the be a bug in DKMS, in that I consider that if I
specify the -c parameter I should not have to specify the -m and -v
parameters, but my experience with it is that DKMS complains about
insufficient parameters when running the build and install steps if -m
and -v are not supplied.
I think you still have to specify the -m and -v because you don't
specify WHERE the module source is--the conf file could be for any
module and you still need to tell it what you're building.
Just one comment on your dkms.conf file contents you have listed
above,
I'm surprised that your module gets compiled at boot time as the
documentation I have read on the dkms.conf file dictates that the value
for PACKAGE_VERSION must match the version part of the directory
containing the source code, so in your case it should be 1.2.65 not 1.0.0.
Well, yes they probably should be the same, but the .conf file
specifies the package name and version--not the module name and
version. I think this is just used by dkms to track things. The module
builds just fine.
Just as a side info, there is a known bug in DKMS (which I
encountered
in my testing trying to get things to work) that if, in your case, there
are multiple version directories in /var/lib/dkms/evdi and any of those
directories don't physically exist, dkms fails with an error that it
can't find dkms.conf.
Well, that, uh, sucks. :-)
From the documentation I have read, when DKMS runs at boot time to
check
if it needs to build and install the driver into the running kernel, the
command that is issued is DKMS AUTOINSTALL, which is why AUTOINSTALL=yes
in dkms.conf is critical.
I believe autoinstall just makes sure the module gets stuffed into
/lib/modules/`uname -r`/extra.
Just for reference I have listed the contents of my dkms.conf file.
On
git.com where I obtained my driver code from there was also a branch for
and rtl8812au network driver, where they supplied a dkms.conf file, and
my dkms.conf is based on that.
PACKAGE_NAME="rtl8814AU"
PACKAGE_VERSION="4.3.21_17997.20160531"
BUILT_MODULE_NAME[0]="8814au"
MAKE="'make' -j3 KVER=${kernelver}"
CLEAN="'make' clean"
DEST_MODULE_LOCATION[0]="/updates/dkms"
AUTOINSTALL="YES"
For me DKMS loses a lot of it usefulness if the driver is not loaded
(modprobed) at boot time if a compile is required for the running kernel
as I have network mounts in /etc/fstab that I would prefer to not have
to mount manually every time a kernel update occurs if the driver is not
compiled at kernel install time. I also don't understand why these
issues are occurring under both F25 and Ubuntu 16.10 as up to the point
of where I stopped using Mandriva (when it was forked to Mageia) 3 - 5
years ago, I was using dkms all the time for multiple drivers and didn't
encounter any of these problems.
I don't know that's a dkms issue. If the module builds, gets inserted
into your "/lib/modules/`uname -r`/extra" and a "depmod" is done,
then
dkms has done all it's supposed to do. I don't know you can direct it
to create a modprobe file to force a probe at boot.
To do that, I think you need to put a file in /etc/modprobe.d, e.g.
echo "8814au" >/etc/modprobe.d/rtl8814AU.conf
That should force a modprobe on boot. dkms should run before the
modprobe does, so the module should build, get installed, then modprobed
when a new kernel is installed.
----------------------------------------------------------------------
- Rick Stevens, Systems Engineer, AllDigital ricks(a)alldigital.com -
- AIM/Skype: therps2 ICQ: 226437340 Yahoo: origrps2 -
- -
- I doubt, therefore I might be. -
----------------------------------------------------------------------
4:04 p.m.
On 16/02/2017 09:53, Rick Stevens wrote:
On 02/15/2017 01:27 PM, Stephen Morris wrote:
> On 15/02/2017 04:42, Rick Stevens wrote:
>> On 02/13/2017 04:38 PM, Rick Stevens wrote:
>>> On 02/13/2017 03:39 PM, Rick Stevens wrote:
>>>> On 02/13/2017 12:22 PM, Stephen Morris wrote:
>>>>> On 13/02/2017 19:21, Stephen Morris wrote:
>>>>> I've removed the driver from DKMS in Ubuntu and re-added it,
then
>>>>> run a
>>>>> DKMS AUTOINSTALL to rebuild and re-install the driver back into the
>>>>> running kernel and under Ubuntu the modprobe command to active the
>>>>> driver is not issued either, but also under Ubuntu is seems that
when
>>>>> the rmmod command is issued to remove the driver from the running
>>>>> kernel
>>>>> which removes wifi access, the dns resolver service seems to also be
>>>>> shutdown, because after the driver is rebuilt by DKMS and the
modprobe
>>>>> issued a sudo apt-get update fails to be able to resolve the
>>>>> repository
>>>>> names.
>>>>> I've tried the same thing under Fedora to see if Fedora has the
same
>>>>> functionality, which fortunately Fedora doesn't, after the DKMS
>>>>> process
>>>>> is done and the modprobe issued a sudo dnf update successfully
>>>>> refreshes
>>>>> the repository lists and installs any available updates after
>>>>> prompting
>>>>> whether or not to do so.
>>>> I've been watching this thread a bit and I'm not a DKMS user,
but
>>>> from what I can gather, DKMS should do an automatic modprobe when
>>>> a kernel is upgraded or whatever based on certain criteria. Section 2
>>>> of the webpage at:
>>>>
>>>> https://wiki.centos.org/HowTos/BuildingKernelModules
>>>>
>>>> describes the process (the example is a patched CIFS filesystem). In a
>>>> nutshell:
>>>>
>>>> 1. The module's source directory must be in
>>>>
>>>> /usr/src/<module>-<version>
>>>>
>>>> 2. There is a "dkms.conf" file in that directory that
contains
>>>> some specific info.
>>>>
>>>> 3. It has been added to the DKMS tree via "dkms add"
>>>>
>>>> 4. It has been built under DKMS control via "dkms build"
>>>>
>>>> 5. It has been installed under DKMS control via "dkms
install"
>>>>
>>>> Note that I've never tried a DKMS add-on module, but that seems to
be
>>>> the way it's done. I think that dkms.conf file is pretty critical,
>>>> along with the "dkms add", "dkms build" and
"dkms install". I don't
>>>> believe "dkms autoinstall" would modprobe modules that
weren't added,
>>>> built and install using dkms as they weren't fully inserted under
dkms'
>>>> care. That's just a guess.
>>> I just built a module (evdi) under DKMS for a Mimo USB-based display. I
>>> don't have the hardware handy (it's here somewhere), but I copied
the
>>> driver source to /usr/src/evdi-1.2.65 and created a dkms.conf file in
>>> there that contains:
>>>
>>> PACKAGE_NAME="evdi"
>>> PACKAGE_VERSION=1.0.0
>>> AUTOINSTALL=yes
>>>
>>> MAKE[0]="make all INCLUDEDIR=/lib/modules/$kernelver/build/include
>>> KVERSION=$kernelver DKMS_BUILD=1"
>>> DEST_MODULE_LOCATION[0]="/kernel/drivers/gpu/drm/evdi"
>>> BUILT_MODULE_NAME[0]="evdi"
>>> CLEAN="make clean DKMS_BUILD=1"
>>>
>>> Then I did (as root):
>>>
>>> dkms add -m evdi -v 1.2.65
>>>
>>> That added it to dkms' build stack as witnessed by dkms creating a
>>> /var/lib/dkms/evdi/1.2.65 directory with a subdirectory named after the
>>> current kernel version and a symlink, "source", pointing at
>>> /usr/src/evdi-1.2.65. The next command:
>>>
>>> dkms build -m evdi -v 1.2.65
>>>
>>> actually built the driver, creating an "x86_64" subdirectory below
the
>>> kernel version directory with "log" and "module" subdirs
below that.
>>> The log subdirectory contains the build log of the module and the
>>> module subdir contains the actual module (evdi.ko). I then ran:
>>>
>>> dkms install -m evdi -v 1.2.65
>>>
>>> and saw dkms install the module into /lib/modules/`uname -r`/extra/ and
>>> do a full depmod:
>>>
>>> # dkms install -m evdi -v 1.2.65
>>>
>>> evdi:
>>> Running module version sanity check.
>>> - Original module
>>> - No original module exists within this kernel
>>> - Installation
>>> - Installing to /lib/modules/4.9.7-201.fc25.x86_64/extra/
>>> Adding any weak-modules
>>>
>>> depmod.......
>>>
>>> DKMS: install completed.
>>>
>>> Doing a "modinfo evdi" returns the data I'd expect.
>>>
>>> I won't know if it auto-modprobes until I get the new kernel update
>>> and find the Mimo display and plug it in. Just thought you'd like to
>>> see what I've done.
>> UPDATE: Just got the new kernel and dkms did build the module for the
>> kernel without me telling it to.
>>
>> I located the display device, plugged it in and it "just worked." I
>> did NOT see the module in the output of "lsmod" but the device did
>> work. I don't know why it doesn't show up in lsmod, but it may be that
>> this is an X/Wayland module only, even though it's a ".ko" file.
> Thanks for the info Rick, what you did to manually use dkms to build and
> install the driver in to the kernel is the same process I went through
> which didn't issue a modprobe to make the network device usable, so I
> couldn't access the network until I manually issued a modprobe which
> then made the device immediately usable.
Can't speak to that. The MIMO device worked when I plugged it in,
but the module was NOT listed in "lsmod", so the module may be X or
Wayland-specific and loaded by that software...not the kernel in
general.
My module is listed in lsmod as using cfg80211. Your device may have
worked when you plugged it in after dkms building it for the new kernel
because of the nature of plug-and-play. The whole nature of
plug-and-play is to sense a device has been attached to the pc and load
any necessary drivers for it to make it usable without the end user
having to do anything special.
> I also tried it a different way by issuing the same manual steps but
> each time specifying the -c parameter to point it to the dkms.conf file
> but that achieved the same results. This method though did highlight
> what I consider the be a bug in DKMS, in that I consider that if I
> specify the -c parameter I should not have to specify the -m and -v
> parameters, but my experience with it is that DKMS complains about
> insufficient parameters when running the build and install steps if -m
> and -v are not supplied.
I think you still have to specify the -m and -v because you don't
specify WHERE the module source is--the conf file could be for any
module and you still need to tell it what you're building.
You shouldn't
have to, the -m and -v parameters specify the name of the
directory in /usr/src that contains the source code (/usr/src is
compulsory) and within that directory it has to be able to find a
dkms.conf file to tell it how to build the module, but with the -c
parameter you have to specify the full path to the dkms.conf, so in your
case the parameter would be -c /usr/src/evdi-1.2.65/dkms.conf, and the
first two statements in dkms.conf specify the same information that are
specified with the -m and -v anyway, hence they should not be required.
Also the module that is being built it irrelevant to dkms, it doesn't
need to know, those details are taken care of by specifications in the
dkms.conf file, which in your case and my case is via make and the
associated source makefile plus the LOCATION[0] statement which may or
may not be honoured depending on the makefile.
> Just one comment on your dkms.conf file contents you have listed above,
> I'm surprised that your module gets compiled at boot time as the
> documentation I have read on the dkms.conf file dictates that the value
> for PACKAGE_VERSION must match the version part of the directory
> containing the source code, so in your case it should be 1.2.65 not 1.0.0.
Well, yes they probably should be the same, but the .conf file
specifies the package name and version--not the module name and
version. I think this is just used by dkms to track things. The module
builds just fine.
At boot time when the dkms autoinstall is run it goes to
/var/lib/dkms
to find any directories that are defined in there, which in my case
there is only one which is rtl8814AU, then it navigates into that
directory looking for sub directories, which in my case is a long name
that was specified in the -v, within that directory is a directory for
the kernel the module has been compiled into and a symlink called
'source' which points to the physical directory containing the source
(in your case it points to /usr/src/evdi-1.2.65). Having found that it
then tries to navigate to that symlink path and load the dkms.conf file,
it is this part that if there are multiple version directories with
source symlinks and the linked to paths don't physically exist or don't
contain a dkms.conf file that the message get produced and the process
stops. Having found the dkms.conf file it then uses the contents of that
to know how to build the module. The name of the module being built is
irrelevant, as in my case even though I'm compiling an rtl8814AU driver
the name of the module that gets built and loaded for the device is
8814au. This process get repeated for every directory it can find in
/var/lib/dkms where the contents of those directories indicate the
associated module has yet to be built for the current kernel and the
associated dkms.conf file has AUTOINSTALL="yes".
> Just as a side info, there is a known bug in DKMS (which I encountered
> in my testing trying to get things to work) that if, in your case, there
> are multiple version directories in /var/lib/dkms/evdi and any of those
> directories don't physically exist, dkms fails with an error that it
> can't find dkms.conf.
Well, that, uh, sucks. :-)
> From the documentation I have read, when DKMS runs at boot time to check
> if it needs to build and install the driver into the running kernel, the
> command that is issued is DKMS AUTOINSTALL, which is why AUTOINSTALL=yes
> in dkms.conf is critical.
I believe autoinstall just makes sure the module gets stuffed into
/lib/modules/`uname -r`/extra.
There are situations, from what I have read, where
location information
specified in dkms.conf can cause the module to be placed elsewhere, for
example, I believe it is possible to get the module placed in the
appropriate low level driver directory rather than in extra.
> Just for reference I have listed the contents of my dkms.conf file. On
> git.com where I obtained my driver code from there was also a branch for
> and rtl8812au network driver, where they supplied a dkms.conf file, and
> my dkms.conf is based on that.
>
> PACKAGE_NAME="rtl8814AU"
> PACKAGE_VERSION="4.3.21_17997.20160531"
> BUILT_MODULE_NAME[0]="8814au"
> MAKE="'make' -j3 KVER=${kernelver}"
> CLEAN="'make' clean"
> DEST_MODULE_LOCATION[0]="/updates/dkms"
> AUTOINSTALL="YES"
>
> For me DKMS loses a lot of it usefulness if the driver is not loaded
> (modprobed) at boot time if a compile is required for the running kernel
> as I have network mounts in /etc/fstab that I would prefer to not have
> to mount manually every time a kernel update occurs if the driver is not
> compiled at kernel install time. I also don't understand why these
> issues are occurring under both F25 and Ubuntu 16.10 as up to the point
> of where I stopped using Mandriva (when it was forked to Mageia) 3 - 5
> years ago, I was using dkms all the time for multiple drivers and didn't
> encounter any of these problems.
I don't know that's a dkms issue. If the module builds, gets inserted
into your "/lib/modules/`uname -r`/extra" and a "depmod" is done,
then
dkms has done all it's supposed to do. I don't know you can direct it
to create a modprobe file to force a probe at boot.
To do that, I think you need to put a file in /etc/modprobe.d, e.g.
echo "8814au" >/etc/modprobe.d/rtl8814AU.conf
That should force a modprobe on boot. dkms should run before the
modprobe does, so the module should build, get installed, then modprobed
when a new kernel is installed.
Thanks Rick, I'll try that and see what happens
next time a new kernel
is provided. I'll force a recompile at boot if the new kernel install
compiles it.
regards,
Steve
----------------------------------------------------------------------
- Rick Stevens, Systems Engineer, AllDigital ricks(a)alldigital.com -
- AIM/Skype: therps2 ICQ: 226437340 Yahoo: origrps2 -
- -
- I doubt, therefore I might be. -
----------------------------------------------------------------------
_______________________________________________
users mailing list -- users(a)lists.fedoraproject.org
To unsubscribe send an email to users-leave(a)lists.fedoraproject.org
10:08 p.m.
On 17/02/2017 08:04, Stephen Morris wrote:
On 16/02/2017 09:53, Rick Stevens wrote:
> On 02/15/2017 01:27 PM, Stephen Morris wrote:
>> On 15/02/2017 04:42, Rick Stevens wrote:
>>> On 02/13/2017 04:38 PM, Rick Stevens wrote:
>>>> On 02/13/2017 03:39 PM, Rick Stevens wrote:
>>>>> On 02/13/2017 12:22 PM, Stephen Morris wrote:
>>>>>> On 13/02/2017 19:21, Stephen Morris wrote:
>>>>>> I've removed the driver from DKMS in Ubuntu and re-added it,
then
>>>>>> run a
>>>>>> DKMS AUTOINSTALL to rebuild and re-install the driver back into
the
>>>>>> running kernel and under Ubuntu the modprobe command to active
the
>>>>>> driver is not issued either, but also under Ubuntu is seems that
>>>>>> when
>>>>>> the rmmod command is issued to remove the driver from the
running
>>>>>> kernel
>>>>>> which removes wifi access, the dns resolver service seems to
>>>>>> also be
>>>>>> shutdown, because after the driver is rebuilt by DKMS and the
>>>>>> modprobe
>>>>>> issued a sudo apt-get update fails to be able to resolve the
>>>>>> repository
>>>>>> names.
>>>>>> I've tried the same thing under Fedora to see if Fedora has
the
>>>>>> same
>>>>>> functionality, which fortunately Fedora doesn't, after the
DKMS
>>>>>> process
>>>>>> is done and the modprobe issued a sudo dnf update successfully
>>>>>> refreshes
>>>>>> the repository lists and installs any available updates after
>>>>>> prompting
>>>>>> whether or not to do so.
>>>>> I've been watching this thread a bit and I'm not a DKMS user,
but
>>>>> from what I can gather, DKMS should do an automatic modprobe when
>>>>> a kernel is upgraded or whatever based on certain criteria.
>>>>> Section 2
>>>>> of the webpage at:
>>>>>
>>>>> https://wiki.centos.org/HowTos/BuildingKernelModules
>>>>>
>>>>> describes the process (the example is a patched CIFS filesystem).
>>>>> In a
>>>>> nutshell:
>>>>>
>>>>> 1. The module's source directory must be in
>>>>>
>>>>> /usr/src/<module>-<version>
>>>>>
>>>>> 2. There is a "dkms.conf" file in that directory that
contains
>>>>> some specific info.
>>>>>
>>>>> 3. It has been added to the DKMS tree via "dkms add"
>>>>>
>>>>> 4. It has been built under DKMS control via "dkms
build"
>>>>>
>>>>> 5. It has been installed under DKMS control via "dkms
install"
>>>>>
>>>>> Note that I've never tried a DKMS add-on module, but that seems
>>>>> to be
>>>>> the way it's done. I think that dkms.conf file is pretty
critical,
>>>>> along with the "dkms add", "dkms build" and
"dkms install". I don't
>>>>> believe "dkms autoinstall" would modprobe modules that
weren't
>>>>> added,
>>>>> built and install using dkms as they weren't fully inserted under
>>>>> dkms'
>>>>> care. That's just a guess.
>>>> I just built a module (evdi) under DKMS for a Mimo USB-based
>>>> display. I
>>>> don't have the hardware handy (it's here somewhere), but I copied
the
>>>> driver source to /usr/src/evdi-1.2.65 and created a dkms.conf file in
>>>> there that contains:
>>>>
>>>> PACKAGE_NAME="evdi"
>>>> PACKAGE_VERSION=1.0.0
>>>> AUTOINSTALL=yes
>>>>
>>>> MAKE[0]="make all
>>>> INCLUDEDIR=/lib/modules/$kernelver/build/include
>>>> KVERSION=$kernelver DKMS_BUILD=1"
>>>> DEST_MODULE_LOCATION[0]="/kernel/drivers/gpu/drm/evdi"
>>>> BUILT_MODULE_NAME[0]="evdi"
>>>> CLEAN="make clean DKMS_BUILD=1"
>>>>
>>>> Then I did (as root):
>>>>
>>>> dkms add -m evdi -v 1.2.65
>>>>
>>>> That added it to dkms' build stack as witnessed by dkms creating a
>>>> /var/lib/dkms/evdi/1.2.65 directory with a subdirectory named
>>>> after the
>>>> current kernel version and a symlink, "source", pointing at
>>>> /usr/src/evdi-1.2.65. The next command:
>>>>
>>>> dkms build -m evdi -v 1.2.65
>>>>
>>>> actually built the driver, creating an "x86_64" subdirectory
below
>>>> the
>>>> kernel version directory with "log" and "module"
subdirs below that.
>>>> The log subdirectory contains the build log of the module and the
>>>> module subdir contains the actual module (evdi.ko). I then ran:
>>>>
>>>> dkms install -m evdi -v 1.2.65
>>>>
>>>> and saw dkms install the module into /lib/modules/`uname
>>>> -r`/extra/ and
>>>> do a full depmod:
>>>>
>>>> # dkms install -m evdi -v 1.2.65
>>>>
>>>> evdi:
>>>> Running module version sanity check.
>>>> - Original module
>>>> - No original module exists within this kernel
>>>> - Installation
>>>> - Installing to /lib/modules/4.9.7-201.fc25.x86_64/extra/
>>>> Adding any weak-modules
>>>>
>>>> depmod.......
>>>>
>>>> DKMS: install completed.
>>>>
>>>> Doing a "modinfo evdi" returns the data I'd expect.
>>>>
>>>> I won't know if it auto-modprobes until I get the new kernel update
>>>> and find the Mimo display and plug it in. Just thought you'd like to
>>>> see what I've done.
>>> UPDATE: Just got the new kernel and dkms did build the module for the
>>> kernel without me telling it to.
>>>
>>> I located the display device, plugged it in and it "just worked."
I
>>> did NOT see the module in the output of "lsmod" but the device did
>>> work. I don't know why it doesn't show up in lsmod, but it may be
that
>>> this is an X/Wayland module only, even though it's a ".ko"
file.
>> Thanks for the info Rick, what you did to manually use dkms to build
>> and
>> install the driver in to the kernel is the same process I went through
>> which didn't issue a modprobe to make the network device usable, so I
>> couldn't access the network until I manually issued a modprobe which
>> then made the device immediately usable.
> Can't speak to that. The MIMO device worked when I plugged it in,
> but the module was NOT listed in "lsmod", so the module may be X or
> Wayland-specific and loaded by that software...not the kernel in
> general.
My module is listed in lsmod as using cfg80211. Your device may have
worked when you plugged it in after dkms building it for the new
kernel because of the nature of plug-and-play. The whole nature of
plug-and-play is to sense a device has been attached to the pc and
load any necessary drivers for it to make it usable without the end
user having to do anything special.
>
>> I also tried it a different way by issuing the same manual steps but
>> each time specifying the -c parameter to point it to the dkms.conf file
>> but that achieved the same results. This method though did highlight
>> what I consider the be a bug in DKMS, in that I consider that if I
>> specify the -c parameter I should not have to specify the -m and -v
>> parameters, but my experience with it is that DKMS complains about
>> insufficient parameters when running the build and install steps if -m
>> and -v are not supplied.
> I think you still have to specify the -m and -v because you don't
> specify WHERE the module source is--the conf file could be for any
> module and you still need to tell it what you're building.
You shouldn't have to, the -m and -v parameters specify the name of
the directory in /usr/src that contains the source code (/usr/src is
compulsory) and within that directory it has to be able to find a
dkms.conf file to tell it how to build the module, but with the -c
parameter you have to specify the full path to the dkms.conf, so in
your case the parameter would be -c /usr/src/evdi-1.2.65/dkms.conf,
and the first two statements in dkms.conf specify the same information
that are specified with the -m and -v anyway, hence they should not be
required. Also the module that is being built it irrelevant to dkms,
it doesn't need to know, those details are taken care of by
specifications in the dkms.conf file, which in your case and my case
is via make and the associated source makefile plus the LOCATION[0]
statement which may or may not be honoured depending on the makefile.
>
>> Just one comment on your dkms.conf file contents you have listed above,
>> I'm surprised that your module gets compiled at boot time as the
>> documentation I have read on the dkms.conf file dictates that the value
>> for PACKAGE_VERSION must match the version part of the directory
>> containing the source code, so in your case it should be 1.2.65 not
>> 1.0.0.
> Well, yes they probably should be the same, but the .conf file
> specifies the package name and version--not the module name and
> version. I think this is just used by dkms to track things. The module
> builds just fine.
At boot time when the dkms autoinstall is run it goes to /var/lib/dkms
to find any directories that are defined in there, which in my case
there is only one which is rtl8814AU, then it navigates into that
directory looking for sub directories, which in my case is a long name
that was specified in the -v, within that directory is a directory for
the kernel the module has been compiled into and a symlink called
'source' which points to the physical directory containing the source
(in your case it points to /usr/src/evdi-1.2.65). Having found that it
then tries to navigate to that symlink path and load the dkms.conf
file, it is this part that if there are multiple version directories
with source symlinks and the linked to paths don't physically exist or
don't contain a dkms.conf file that the message get produced and the
process stops. Having found the dkms.conf file it then uses the
contents of that to know how to build the module. The name of the
module being built is irrelevant, as in my case even though I'm
compiling an rtl8814AU driver the name of the module that gets built
and loaded for the device is 8814au. This process get repeated for
every directory it can find in /var/lib/dkms where the contents of
those directories indicate the associated module has yet to be built
for the current kernel and the associated dkms.conf file has
AUTOINSTALL="yes".
>
>> Just as a side info, there is a known bug in DKMS (which I encountered
>> in my testing trying to get things to work) that if, in your case,
>> there
>> are multiple version directories in /var/lib/dkms/evdi and any of those
>> directories don't physically exist, dkms fails with an error that it
>> can't find dkms.conf.
> Well, that, uh, sucks. :-)
>
>> From the documentation I have read, when DKMS runs at boot time to
>> check
>> if it needs to build and install the driver into the running kernel,
>> the
>> command that is issued is DKMS AUTOINSTALL, which is why
>> AUTOINSTALL=yes
>> in dkms.conf is critical.
> I believe autoinstall just makes sure the module gets stuffed into
> /lib/modules/`uname -r`/extra.
There are situations, from what I have read, where location
information specified in dkms.conf can cause the module to be placed
elsewhere, for example, I believe it is possible to get the module
placed in the appropriate low level driver directory rather than in
extra.
>
>> Just for reference I have listed the contents of my dkms.conf file. On
>> git.com where I obtained my driver code from there was also a branch
>> for
>> and rtl8812au network driver, where they supplied a dkms.conf file, and
>> my dkms.conf is based on that.
>>
>> PACKAGE_NAME="rtl8814AU"
>> PACKAGE_VERSION="4.3.21_17997.20160531"
>> BUILT_MODULE_NAME[0]="8814au"
>> MAKE="'make' -j3 KVER=${kernelver}"
>> CLEAN="'make' clean"
>> DEST_MODULE_LOCATION[0]="/updates/dkms"
>> AUTOINSTALL="YES"
>>
>> For me DKMS loses a lot of it usefulness if the driver is not loaded
>> (modprobed) at boot time if a compile is required for the running
>> kernel
>> as I have network mounts in /etc/fstab that I would prefer to not have
>> to mount manually every time a kernel update occurs if the driver is
>> not
>> compiled at kernel install time. I also don't understand why these
>> issues are occurring under both F25 and Ubuntu 16.10 as up to the point
>> of where I stopped using Mandriva (when it was forked to Mageia) 3 - 5
>> years ago, I was using dkms all the time for multiple drivers and
>> didn't
>> encounter any of these problems.
> I don't know that's a dkms issue. If the module builds, gets inserted
> into your "/lib/modules/`uname -r`/extra" and a "depmod" is done,
then
> dkms has done all it's supposed to do. I don't know you can direct it
> to create a modprobe file to force a probe at boot.
>
> To do that, I think you need to put a file in /etc/modprobe.d, e.g.
>
> echo "8814au" >/etc/modprobe.d/rtl8814AU.conf
>
> That should force a modprobe on boot. dkms should run before the
> modprobe does, so the module should build, get installed, then modprobed
> when a new kernel is installed.
Thanks Rick, I'll try that and see what happens next time a new kernel
is provided. I'll force a recompile at boot if the new kernel install
compiles it.
Hi Rick,
I've tried the echo command you listed above but it did not work.
From what I have read on the net modprobe.d is only for passing options
into modules, not for loading modules.
The article went on the say the following command should be issued
instead:
echo "8814au" >/etc/sysconfig/modules/rtl8814AU.modules
but that didn't cause a modprobe at boot time to be issued either.
I've now worked around it using dkms but I'm not sure what the
impact of my workaround is if the driver gets built when a new kernel is
installed.
To workaround the issue I did the following:
1). Created a bash script in rtl8814AU-4.3.21_17997.20160531
call modprobe (it can be any name) containing the following commands:
#!/bin/bash
/sbin/depmod
/sbin/modprobe -v 8814au
I did originally have exec in front of each command, but
that caused the commands to not work.
2). Updated dkms.conf to be the following:
PACKAGE_NAME="rtl8814AU"
PACKAGE_VERSION="4.3.21_17997.20160531"
BUILT_MODULE_NAME[0]="8814au"
MAKE="'make' -j3 KVER=${kernelver}"
CLEAN="'make' clean"
DEST_MODULE_LOCATION[0]="/updates/dkms"
AUTOINSTALL="YES"
POST_INSTALL="modprobe"
The POST_INSTALL option specifies a script that is pathed
relative to /usr/src/rtl8814AU-4.3.21_17997.20160531 (in my case) which
is executed after the install process has finished. Unfortunately, due
to either a Fedora bug or an upstream bug, the script runs before the
depmod command issued by dkms, hence the requirement for the
script to have a depmod for the process to work.
regards,
Steve
regards,
Steve
> ----------------------------------------------------------------------
> - Rick Stevens, Systems Engineer, AllDigital ricks(a)alldigital.com -
> - AIM/Skype: therps2 ICQ: 226437340 Yahoo: origrps2 -
> - -
> - I doubt, therefore I might be. -
> ----------------------------------------------------------------------
> _______________________________________________
> users mailing list -- users(a)lists.fedoraproject.org
> To unsubscribe send an email to users-leave(a)lists.fedoraproject.org
_______________________________________________
users mailing list -- users(a)lists.fedoraproject.org
To unsubscribe send an email to users-leave(a)lists.fedoraproject.org
2621
days inactive
2629
days old
11 comments
3 participants
participants (3)
-
Ed Greshko -
Rick Stevens -
Stephen Morris