Hi,
I'm using the nvidia drivers from negativo17. I have the nvidia source module registered with dkms and it seems to be being compiled when I get a new kernel, if that is the case what do I need to do to resolve the following messages shown by "dmesg"?
[ 14.934074] nvidia: loading out-of-tree module taints kernel. [ 14.934086] nvidia: module license 'NVIDIA' taints kernel. [ 14.934087] Disabling lock debugging due to kernel taint [ 14.943865] nvidia: module verification failed: signature and/or required key missing - tainting kernel
regards,
Steve
On 02/20/18 04:41, Stephen Morris wrote:
I'm using the nvidia drivers from negativo17. I have the nvidia source module registered with dkms and it seems to be being compiled when I get a new kernel, if that is the case what do I need to do to resolve the following messages shown by "dmesg"?
[ 14.934074] nvidia: loading out-of-tree module taints kernel. [ 14.934086] nvidia: module license 'NVIDIA' taints kernel. [ 14.934087] Disabling lock debugging due to kernel taint [ 14.943865] nvidia: module verification failed: signature and/or required key missing - tainting kernel
When you load a proprietary module into the kernel it becomes tainted. There is no way to "fix" it. It is like replacing the battery in your iPhone with a battery you bought on the street corner. You have voided the warranty.
On 20/2/18 8:54 am, Ed Greshko wrote:
On 02/20/18 04:41, Stephen Morris wrote:
I'm using the nvidia drivers from negativo17. I have the nvidia source module registered with dkms and it seems to be being compiled when I get a new kernel, if that is the case what do I need to do to resolve the following messages shown by "dmesg"?
[ 14.934074] nvidia: loading out-of-tree module taints kernel. [ 14.934086] nvidia: module license 'NVIDIA' taints kernel. [ 14.934087] Disabling lock debugging due to kernel taint [ 14.943865] nvidia: module verification failed: signature and/or required key missing - tainting kernel
When you load a proprietary module into the kernel it becomes tainted. There is no way to "fix" it. It is like replacing the battery in your iPhone with a battery you bought on the street corner. You have voided the warranty.
I been in the situation of compiling kernel modules in other linux distributions where you could put statements in your source to stop these messages, but I have forgotten what they were.
Looking at dmesg again this morning, and searching for the work 'taints' I get the 2nd message listed above but not the first message (why?), and this search displays a message in the same format as the first message for my wifi driver which is also compiled, but I don't see any messages with the word 'taints' in them for the 6 compiled kernel modules provided by the vendor of my mouse that I am compiling via dkms. Of the 6 modules I am compiling one and possibly two are being actively loaded and used by the kernel, so why are these not producing the messages?
Also given that this morning I am seeing the equivalent of the first message for my wifi driver, but I am not seeing it for the nvidia driver, which makes it look like these messages are random, are they actually random or is the lack of the message and indication that the kernel is potentially not working correctly?
regards,
Steve
users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org
On 02/21/18 04:59, Stephen Morris wrote:
On 20/2/18 8:54 am, Ed Greshko wrote:
On 02/20/18 04:41, Stephen Morris wrote:
I'm using the nvidia drivers from negativo17. I have the nvidia source module registered with dkms and it seems to be being compiled when I get a new kernel, if that is the case what do I need to do to resolve the following messages shown by "dmesg"?
[ 14.934074] nvidia: loading out-of-tree module taints kernel. [ 14.934086] nvidia: module license 'NVIDIA' taints kernel. [ 14.934087] Disabling lock debugging due to kernel taint [ 14.943865] nvidia: module verification failed: signature and/or required key missing - tainting kernel
When you load a proprietary module into the kernel it becomes tainted. There is no way to "fix" it. It is like replacing the battery in your iPhone with a battery you bought on the street corner. You have voided the warranty.
I been in the situation of compiling kernel modules in other linux distributions where you could put statements in your source to stop these messages, but I have forgotten what they were.
Looking at dmesg again this morning, and searching for the work 'taints' I get the 2nd message listed above but not the first message (why?), and this search displays a message in the same format as the first message for my wifi driver which is also compiled, but I don't see any messages with the word 'taints' in them for the 6 compiled kernel modules provided by the vendor of my mouse that I am compiling via dkms. Of the 6 modules I am compiling one and possibly two are being actively loaded and used by the kernel, so why are these not producing the messages?
Also given that this morning I am seeing the equivalent of the first message for my wifi driver, but I am not seeing it for the nvidia driver, which makes it look like these messages are random, are they actually random or is the lack of the message and indication that the kernel is potentially not working correctly?
I'm confused as to what your goal is and what your understanding of what "taints" a kernel.
The lack of a message in dmesg or the journal with the word "taint" doesn't guarantee your kernel hasn't been tainted as there are several ways to have the kernel flagged as "tainted".
Take this VM that I've just installed.
[egreshko@f27k-v ~]$ dmesg | grep -i taint [egreshko@f27k-v ~]$ journalctl -b 0 | grep -i taint [egreshko@f27k-v ~]$ ./tainted Taint value: 1024 [bit] [bit value] [description] 10 1024 A module from drivers/staging was loaded
As it happens, the VM is connected to a wireless usb device which loads a drivers/staging module and thus the kernel is considered "tainted"
Now, take my desktop which is "seriously" tainted.
[egreshko@meimei tainted]$ dmesg | grep -i taint [ 6.508288] nvidia: loading out-of-tree module taints kernel. [ 6.508297] nvidia: module license 'NVIDIA' taints kernel. [ 6.508298] Disabling lock debugging due to kernel taint [ 6.515118] nvidia: module verification failed: signature and/or required key missing - tainting kernel [ 11.598031] CPU: 1 PID: 0 Comm: swapper/1 Tainted: P C OE 4.15.3-300.fc27.x86_64 #1
[egreshko@meimei tainted]$ journalctl -b 0 | grep -i taint Feb 18 17:59:21 meimei.greshko.com kernel: nvidia: loading out-of-tree module taints kernel. Feb 18 17:59:21 meimei.greshko.com kernel: nvidia: module license 'NVIDIA' taints kernel. Feb 18 17:59:21 meimei.greshko.com kernel: Disabling lock debugging due to kernel taint Feb 18 17:59:21 meimei.greshko.com kernel: nvidia: module verification failed: signature and/or required key missing - tainting kernel Feb 18 17:59:26 meimei.greshko.com kernel: CPU: 1 PID: 0 Comm: swapper/1 Tainted: P C OE 4.15.3-300.fc27.x86_64 #1
[egreshko@meimei tainted]$ ./tainted Taint value: 13313 [bit] [bit value] [description] 0 1 A module with a non-GPL license has been loaded, this includes modules with no license. Set by modutils >= 2.4.9 and module-init-tools 10 1024 A module from drivers/staging was loaded 12 4096 An out-of-tree module has been loaded 13 8192 An unsigned module has been loaded in a kernel supporting module signature
So, do you just want to eliminate the messages to make yourself think your kernel isn't tainted? Or something else?
Allegedly, on or about 21 February 2018, Stephen Morris sent:
I been in the situation of compiling kernel modules in other linux distributions where you could put statements in your source to stop these messages, but I have forgotten what they were.
A install is tainted by having certain kinds of things installed (in this case, binary support files that are not open-source).
It will still be tainted (i.e. not suitable for providing bug reports to sources that need the computer to be running in a defined state), even if you try and pretend that it is not (faking the flags).
To untaint a a kernel (e.g. for the purposes of debugging something), you have to stop using the modules that cause the tainting (you'd unload the Nvidia graphics driver and use a generic one, in this case). If, after doing that, the problem still occurs, you can make a bug report that can be used by the debugging team. But, if after that, the fault goes away, it points rather firmly at your binary blob being the cause of the problem. And since nobody here can debug closed source software, you're stuck.
On 02/21/18 08:23, Tim wrote:
Allegedly, on or about 21 February 2018, Stephen Morris sent:
I been in the situation of compiling kernel modules in other linux distributions where you could put statements in your source to stop these messages, but I have forgotten what they were.
A install is tainted by having certain kinds of things installed (in this case, binary support files that are not open-source).
It will still be tainted (i.e. not suitable for providing bug reports to sources that need the computer to be running in a defined state), even if you try and pretend that it is not (faking the flags).
To untaint a a kernel (e.g. for the purposes of debugging something), you have to stop using the modules that cause the tainting (you'd unload the Nvidia graphics driver and use a generic one, in this case). If, after doing that, the problem still occurs, you can make a bug report that can be used by the debugging team. But, if after that, the fault goes away, it points rather firmly at your binary blob being the cause of the problem. And since nobody here can debug closed source software, you're stuck.
BTW, one can determine if their kernel is tainted by doing a "cat /proc/sys/kernel/tainted". Anything other than 0 means "tainted".
The values are additive from this list....(may be out of date).
1 – A module with a non-GPL license has been loaded, this includes modules with no license. Set by modutils >= 2.4.9 and module-init-tools. 2 – A module was force loaded by insmod -f. Set by modutils >= 2.4.9 and module-init-tools. 4 – Unsafe SMP processors: SMP with CPUs not designed for SMP. 8 – A module was forcibly unloaded from the system by rmmod -f. 16 – A hardware machine check error occurred on the system. 32 – A bad page was discovered on the system. 64 – The user has asked that the system be marked “tainted”. This could be because they are running software that directly modifies the hardware, or for other reasons. 128 – The system has died. 256 – The ACPI DSDT has been overridden with one supplied by the user instead of using the one provided by the hardware. 512 – A kernel warning has occurred. 1024 – A module from drivers/staging was loaded. 268435456 – Unsupported hardware 536870912 – Technology Preview code was loaded
On 02/20/2018 12:59 PM, Stephen Morris wrote:
Looking at dmesg again this morning, and searching for the work 'taints' I get the 2nd message listed above but not the first message (why?), and this search displays a message in the same format as the first message for my wifi driver which is also compiled, but I don't see any messages with the word 'taints' in them for the 6 compiled kernel modules provided by the vendor of my mouse that I am compiling via dkms. Of the 6 modules I am compiling one and possibly two are being actively loaded and used by the kernel, so why are these not producing the messages?
If the license for the mouse drivers is GPL or similar, they most likely won't taint the kernel.
On 20/2/18 7:41 am, Stephen Morris wrote:
Hi,
I'm using the nvidia drivers from negativo17. I have the nvidia source module registered with dkms and it seems to be being compiled when I get a new kernel, if that is the case what do I need to do to resolve the following messages shown by "dmesg"?
[ 14.934074] nvidia: loading out-of-tree module taints kernel. [ 14.934086] nvidia: module license 'NVIDIA' taints kernel. [ 14.934087] Disabling lock debugging due to kernel taint [ 14.943865] nvidia: module verification failed: signature and/or required key missing - tainting kernel
regards,
Steve
Thankyou to everyone who responded, but I am still confused.
dmesg | grep -i taint give me the following output:
[ 13.573068] 8814au: loading out-of-tree module taints kernel. [ 13.573694] 8814au: module verification failed: signature and/or required key missing - tainting kernel [ 13.990668] nvidia: module license 'NVIDIA' taints kernel. [ 13.990670] Disabling lock debugging due to kernel taint
The nvidia messages about the loading out-of-tree module and the verification failed are no longer being produced, why?, nothing has changed on my system since the original list, there have not been any updates put on.
My confusion with the 'taint' message is coming from the days when I used to compile the nvidia module and the kernel in Mandriva in the days before Mandriva forked out to Mageia. Nvidia used to produce the taint messages back then, but then they were considered to be an indication that the module was potentially "corrupting" the kernel. In those days it was possible to remediate the production of the messages, but I don't remember whether they were remediated by adding a specific line into the, in this case, nvidia source or by setting a kernel config option to tell the kernel to not bother producing the messages.
From the responses I am getting it seems that the meaning of 'taints the kernel' has morphed into something else?
In the case of the nvidia module, I'm not sure whether I'm using the binary module or the one compiled from source via dkms, I have both installed and dkms is building the module into /lib/modules/$(uname -r)/extra every time a kernel upgrade occurs. But either way, both are coming from the negativo17 repository, that has its gpg signature installed, so I'm assuming the binary module and source have been signed with that certificate, so there shouldn't be any be any signing issue with the modules, unless the signature is not being carried through to the binary module dkms has produced.
In the case of my wifi driver, the source code for that has been downloaded for Github, which I thought used the GPL signature, so there again there shouldn't be any issue with the source unless dkms is not carrying that signature through. I assuming different versions of the GPL license are not an issue.
In the case of my mouse drivers, I am sourcing the source code for those from the Razor repository I have installed and there again that repositories gpg signature has also been installed. All 6 of these drivers have been compiled from their source by dkms, but in the case of these modules, none of them have caused the taint message to be produced. The dkms.conf file for these is completely different to the ones for nvidia and the wifi drivers, the dkms.conf for nvidia and wifi driver are exactly the same.
Hence my confusion about the messages, if the messages are reliably produced by the kernel despite indications that they may not be, why does the nvidia and wifi drivers produce the messages but the mouse drivers don't, even though all 3 sets of drivers are placed in /lib/modules/$(uname -r)/extra by dkms?
regards,
Steve
users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org
On 02/23/18 05:27, Stephen Morris wrote:
From the responses I am getting it seems that the meaning of 'taints the kernel' has morphed into something else?
Here is the definitive list of what taints the kernel. This is from the 4.14 documentation but is also valid for 4.15 kernels.
https://www.kernel.org/doc/html/v4.14/admin-guide/tainted-kernels.html
The numbers in the list correspond to the bit positions in the value supplied by "cat /proc/sys/kernel/tainted"
Why you don't get "tainted" messages in your dmesg output or journal? Don't know....and I'd not be interested in chasing it down.
I've a small program that converts the value from proc-tainted into real info if you need it.
On 02/23/18 05:59, Ed Greshko wrote:
The numbers in the list correspond to the bit positions in the value supplied by "cat /proc/sys/kernel/tainted"
That actually should have said "number - 1" corresponds to the bit position in the value returned by the cat command.
On 23/2/18 8:59 am, Ed Greshko wrote:
On 02/23/18 05:27, Stephen Morris wrote:
From the responses I am getting it seems that the meaning of 'taints the kernel' has morphed into something else?
Here is the definitive list of what taints the kernel. This is from the 4.14 documentation but is also valid for 4.15 kernels.
https://www.kernel.org/doc/html/v4.14/admin-guide/tainted-kernels.html
The numbers in the list correspond to the bit positions in the value supplied by "cat /proc/sys/kernel/tainted"
Why you don't get "tainted" messages in your dmesg output or journal? Don't know....and I'd not be interested in chasing it down.
I've a small program that converts the value from proc-tainted into real info if you need it.
Access to that program would be great, the output from the cat command you mentioned above of 12289 is meaningless to me especially after looking at the web page you highlighted.
There has to be a reason for whether taint messages are produced or not. I ran a 'dnf upgrade' yesterday which wanted to upgrade/install 125 packages, and even though it produced messages about conflicts between kmod-nvidia-390.25 and the equivalent X11 drivers I told the upgrade to proceed, which then proceeded to completion. The upgrade did not install a new kernel, nor did it result in compiling my wireless driver or mouse drivers. I have done cold start of the machine after the upgrade. I have just issued commands 'dmesg | grep -i taint' and 'journalctl --system --user -b | grep -i taint' and these commands now produce the out of tree taint message about the nvidia driver not the wireless driver they were previously.
Is systemd's parallelism the reason for the changes in these taint messages? Is it possible that these out of tree taint messages are only produced for the first module encountered, and the reason for the message chopping and changing between modules is that systemd's parallelism is not loading the modules in the same order from boot to boot, and that they have never been produced for the mouse driver, not because the compile that is done for the driver not causing the issue but because the mouse driver is loaded after the nvidia or wifi drivers, hence a out of tree taint message has already been produced?
The other alternative to this is, if I go back to compiling the kernel myself will that stop the messages being produced?
regards,
Steve
users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org
On 02/24/18 10:21, Stephen Morris wrote:
On 23/2/18 8:59 am, Ed Greshko wrote:
On 02/23/18 05:27, Stephen Morris wrote:
From the responses I am getting it seems that the meaning of 'taints the kernel' has morphed into something else?
Here is the definitive list of what taints the kernel. This is from the 4.14 documentation but is also valid for 4.15 kernels.
https://www.kernel.org/doc/html/v4.14/admin-guide/tainted-kernels.html
The numbers in the list correspond to the bit positions in the value supplied by "cat /proc/sys/kernel/tainted"
Why you don't get "tainted" messages in your dmesg output or journal? Don't know....and I'd not be interested in chasing it down.
I've a small program that converts the value from proc-tainted into real info if you need it.
Access to that program would be great, the output from the cat command you mentioned above of 12289 is meaningless to me especially after looking at the web page you highlighted.
12289 = 11000000000001 in binary
[bit] [bit value] [description] 0 1 A module with a non-GPL license has been loaded. (bit 0 is rightmost bit) 12 4096 An out-of-tree module has been loaded 13 8192 An unsigned module has been loaded in a kernel supporting module signature
1 + 4096 + 8192 = 12289
The program I reference simply does the math for you. The source is tainted.c and located at https://paste.fedoraproject.org/paste/a6HyoXLvYCMpjKeym-S~wg
But it is really easy to do it yourself as you can see.
The nVidia driver is a proprietary driver and thus doesn't have a GPL license The nVidia driver has been compiled from source that isn't in the kernel source tree. So, it is out-of-tree. The nVidia driver isn't signed and the kernel checks signatures.
It won't matter if you "binary one" or one you "compile if from source yourself" the result would be the same. Your kernel will be tainted no matter what you do or what may be happening to prevent the messages form appearing in logs.
It won't matter if you compile a kernel and manage somehow to insert the nVidia driver into the source code tree and fake a GPL license and sign the module and produce a 0 output from "cat /proc/sys/kernel/tainted" if you have a kernel crashes and submit a bugzilla it won't be debugged since any traces wouldn't match any debug info for the kernel as released.
You should run a system with only the mouse driver you talk about and check the output of the cat.
As I have mentioned elsewhere. I have a VM under Virtual Box with the vboxvideo driver and the Virtual Box Tools installed....
[egreshko@f27k ~]$ dmesg | grep -i taint [egreshko@f27k ~]$ journalctl -b -0 | grep -i taint [egreshko@f27k ~]$ cat /proc/sys/kernel/tainted 1024
So, even though there are no messages (and I don't care why that is the case) the kernel on the system is tainted.
Contrast that with a system running under "virt-manager"....
[egreshko@f27qk ~]$ dmesg | grep -i taint [egreshko@f27qk ~]$ journalctl -b -0 | grep -i taint [egreshko@f27qk ~]$ cat /proc/sys/kernel/tainted 0
Also, no messages. But not running a tainted kernel.
On 24/2/18 2:25 pm, Ed Greshko wrote:
On 02/24/18 10:21, Stephen Morris wrote:
On 23/2/18 8:59 am, Ed Greshko wrote:
On 02/23/18 05:27, Stephen Morris wrote:
From the responses I am getting it seems that the meaning of 'taints the kernel' has morphed into something else?
Here is the definitive list of what taints the kernel. This is from the 4.14 documentation but is also valid for 4.15 kernels.
https://www.kernel.org/doc/html/v4.14/admin-guide/tainted-kernels.html
The numbers in the list correspond to the bit positions in the value supplied by "cat /proc/sys/kernel/tainted"
Why you don't get "tainted" messages in your dmesg output or journal? Don't know....and I'd not be interested in chasing it down.
I've a small program that converts the value from proc-tainted into real info if you need it.
Access to that program would be great, the output from the cat command you mentioned above of 12289 is meaningless to me especially after looking at the web page you highlighted.
12289 = 11000000000001 in binary
[bit] [bit value] [description] 0 1 A module with a non-GPL license has been loaded. (bit 0 is rightmost bit) 12 4096 An out-of-tree module has been loaded 13 8192 An unsigned module has been loaded in a kernel supporting module signature
1 + 4096 + 8192 = 12289
The program I reference simply does the math for you. The source is tainted.c and located at https://paste.fedoraproject.org/paste/a6HyoXLvYCMpjKeym-S~wg
Thanks Ed. Is there any documentation anywhere on what each bit represents?
With bit 13 being set reflecting the loading of an unsigned module into a kernel supporting module signatures, is that because the kernel has been designed for secure boot, and will turning on secure boot resolve the signing issue?
But it is really easy to do it yourself as you can see.
The nVidia driver is a proprietary driver and thus doesn't have a GPL license The nVidia driver has been compiled from source that isn't in the kernel source tree. So, it is out-of-tree. The nVidia driver isn't signed and the kernel checks signatures.
It won't matter if you "binary one" or one you "compile if from source yourself" the result would be the same. Your kernel will be tainted no matter what you do or what may be happening to prevent the messages form appearing in logs.
It won't matter if you compile a kernel and manage somehow to insert the nVidia driver into the source code tree and fake a GPL license and sign the module and produce a 0 output from "cat /proc/sys/kernel/tainted" if you have a kernel crashes and submit a bugzilla it won't be debugged since any traces wouldn't match any debug info for the kernel as released.
You should run a system with only the mouse driver you talk about and check the output of the cat.
As I have mentioned elsewhere. I have a VM under Virtual Box with the vboxvideo driver and the Virtual Box Tools installed....
[egreshko@f27k ~]$ dmesg | grep -i taint [egreshko@f27k ~]$ journalctl -b -0 | grep -i taint [egreshko@f27k ~]$ cat /proc/sys/kernel/tainted 1024
So, even though there are no messages (and I don't care why that is the case) the kernel on the system is tainted.
Contrast that with a system running under "virt-manager"....
[egreshko@f27qk ~]$ dmesg | grep -i taint [egreshko@f27qk ~]$ journalctl -b -0 | grep -i taint [egreshko@f27qk ~]$ cat /proc/sys/kernel/tainted 0
Also, no messages. But not running a tainted kernel.
Are all these taint messages, and all the reasons for a taint message being produced saying that if we have to build our own drivers into the kernel to be able to use our hardware, and hence put us into the situation of potentially not getting support for kernel defects if any are encountered, that we shouldn't be using linux?
regards,
Steve
users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org
On 02/24/18 12:43, Stephen Morris wrote:
Thanks Ed. Is there any documentation anywhere on what each bit represents?
You mean other than the URL I've supplied at kernel.org and the comments within tainted.c ?
With bit 13 being set reflecting the loading of an unsigned module into a kernel supporting module signatures, is that because the kernel has been designed for secure boot, and will turning on secure boot resolve the signing issue?
Probably not, since 13 and 12 are probably a pair in your case.
Are all these taint messages, and all the reasons for a taint message being produced saying that if we have to build our own drivers into the kernel to be able to use our hardware, and hence put us into the situation of potentially not getting support for kernel defects if any are encountered, that we shouldn't be using linux?
No. It is just saying that in the unlikely event you run into a kernel problem and you want to report it you should first check to see if others have the problem and/or try to reproduce it a non-tainted environment. Like running whatever you thought caused the problem in a QEMU/KVM environment.
I don't think it is very likely that you're going to run into a kernel issue that needs reporting. I've never had a kernel crash except years ago when integrating the nVidia drivers was a DYI project.
On 24/2/18 11:12 pm, Ed Greshko wrote:
On 02/24/18 12:43, Stephen Morris wrote:
Thanks Ed. Is there any documentation anywhere on what each bit represents?
You mean other than the URL I've supplied at kernel.org and the comments within tainted.c ?
I haven't seen tainted.c as yet so I'm not sure what it has commented, but the info in the url indicates that bit 1 can have two reasons for being set, so my query is more around if a bit that has multiple reasons is set, how does one determine which of those reasons is causing it to be set.
With bit 13 being set reflecting the loading of an unsigned module into a kernel supporting module signatures, is that because the kernel has been designed for secure boot, and will turning on secure boot resolve the signing issue?
Probably not, since 13 and 12 are probably a pair in your case.
Are all these taint messages, and all the reasons for a taint message being produced saying that if we have to build our own drivers into the kernel to be able to use our hardware, and hence put us into the situation of potentially not getting support for kernel defects if any are encountered, that we shouldn't be using linux?
No. It is just saying that in the unlikely event you run into a kernel problem and you want to report it you should first check to see if others have the problem and/or try to reproduce it a non-tainted environment. Like running whatever you thought caused the problem in a QEMU/KVM environment.
I don't think it is very likely that you're going to run into a kernel issue that needs reporting. I've never had a kernel crash except years ago when integrating the nVidia drivers was a DYI project.
I have to admit I'm in the same situation as well, I haven't really had any kernel issues since the days when I was downloading the source directly from the nvidia site and also compiling my own kernel, because the binary kernel distributed with the distro was compiled for single cpu's only, hence running a quad core cpu meant that kernel was not useful, plus the source for their mp kernels had to be modified via the config because they were configured to support only 2 cores.
regards,
Steve
users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org
On 02/25/18 09:57, Stephen Morris wrote:
On 24/2/18 11:12 pm, Ed Greshko wrote:
On 02/24/18 12:43, Stephen Morris wrote:
Thanks Ed. Is there any documentation anywhere on what each bit represents?
You mean other than the URL I've supplied at kernel.org and the comments within tainted.c ?
I haven't seen tainted.c as yet so I'm not sure what it has commented, but the info in the url indicates that bit 1 can have two reasons for being set, so my query is more around if a bit that has multiple reasons is set, how does one determine which of those reasons is causing it to be set.
The number 1 is a list number in the kernel.org URL I've supplied.
As I've repeatedly said, the "BIT" is the number in the list "MINUS" one. So, BIT 0 is concerned with the GPL License status. Yes there is an "OR" condition but the situation is still the SAME. There is a problem with the LICENSE of a module which is deemed a "TAINT". Not complicated.
As for tainted.c, I sent you the URL for that file/program that you need to compile and run according to the directions in the file. I'm surprised that with your being so concerned about what taints your kernel you've not looked at the file, not compiled, and I guess not run the program?
https://paste.fedoraproject.org/paste/a6HyoXLvYCMpjKeym-S~wg
is tainted.c.
On 25/2/18 1:21 pm, Ed Greshko wrote:
On 02/25/18 09:57, Stephen Morris wrote:
On 24/2/18 11:12 pm, Ed Greshko wrote:
On 02/24/18 12:43, Stephen Morris wrote:
Thanks Ed. Is there any documentation anywhere on what each bit represents?
You mean other than the URL I've supplied at kernel.org and the comments within tainted.c ?
I haven't seen tainted.c as yet so I'm not sure what it has commented, but the info in the url indicates that bit 1 can have two reasons for being set, so my query is more around if a bit that has multiple reasons is set, how does one determine which of those reasons is causing it to be set.
The number 1 is a list number in the kernel.org URL I've supplied.
As I've repeatedly said, the "BIT" is the number in the list "MINUS" one. So, BIT 0 is concerned with the GPL License status. Yes there is an "OR" condition but the situation is still the SAME. There is a problem with the LICENSE of a module which is deemed a "TAINT". Not complicated.
As for tainted.c, I sent you the URL for that file/program that you need to compile and run according to the directions in the file. I'm surprised that with your being so concerned about what taints your kernel you've not looked at the file, not compiled, and I guess not run the program?
https://paste.fedoraproject.org/paste/a6HyoXLvYCMpjKeym-S~wg
is tainted.c.
Thanks Ed, I missed that url. I have now downloaded the code and compiled it. ./tainted 12801 which is what I am getting now since the last system update is telling me there is also a kernel warning involved.
regards,
Steve
users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org
On Sat, 2018-02-24 at 15:43 +1100, Stephen Morris wrote:
Are all these taint messages, and all the reasons for a taint message being produced saying that if we have to build our own drivers into the kernel to be able to use our hardware, and hence put us into the situation of potentially not getting support for kernel defects if any are encountered, that we shouldn't be using linux?
If you encounter a kernel defect, how can it be debugged if part of the kernel is not available? That's what tainting amounts to. IIRC you've said that you compile the Nvidia modules. What you are actually doing is compiling code (the dkms system) that enables Nvidia's binary blobs to be linked as modules into the Linux kernel. You don't (unless you work for Nvidia) have the source code of those blobs.
poc
On 25/2/18 12:15 am, Patrick O'Callaghan wrote:
On Sat, 2018-02-24 at 15:43 +1100, Stephen Morris wrote:
Are all these taint messages, and all the reasons for a taint message being produced saying that if we have to build our own drivers into the kernel to be able to use our hardware, and hence put us into the situation of potentially not getting support for kernel defects if any are encountered, that we shouldn't be using linux?
If you encounter a kernel defect, how can it be debugged if part of the kernel is not available? That's what tainting amounts to. IIRC you've said that you compile the Nvidia modules. What you are actually doing is compiling code (the dkms system) that enables Nvidia's binary blobs to be linked as modules into the Linux kernel. You don't (unless you work for Nvidia) have the source code of those blobs.
I can understand objects being linked together to build an executable module, but what I don't understand, based on what you are saying, is where the source code in the nvidia directory in /usr/src that dkms is compiling has come from if it hasn't come from nvidia?
regards,
Steve
poc _______________________________________________ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org
On Sun, 2018-02-25 at 13:00 +1100, Stephen Morris wrote:
On 25/2/18 12:15 am, Patrick O'Callaghan wrote:
On Sat, 2018-02-24 at 15:43 +1100, Stephen Morris wrote:
Are all these taint messages, and all the reasons for a taint message being produced saying that if we have to build our own drivers into the kernel to be able to use our hardware, and hence put us into the situation of potentially not getting support for kernel defects if any are encountered, that we shouldn't be using linux?
If you encounter a kernel defect, how can it be debugged if part of the kernel is not available? That's what tainting amounts to. IIRC you've said that you compile the Nvidia modules. What you are actually doing is compiling code (the dkms system) that enables Nvidia's binary blobs to be linked as modules into the Linux kernel. You don't (unless you work for Nvidia) have the source code of those blobs.
I can understand objects being linked together to build an executable module, but what I don't understand, based on what you are saying, is where the source code in the nvidia directory in /usr/src that dkms is compiling has come from if it hasn't come from nvidia?
No-one is saying it doesn't come from Nvidia. What I'm saying is that that code is *not* the entire Nvidia driver, it's simply linking code that enables the use of the binary driver they supply.
IOW you don't have the *complete* source of the driver. That's why it's tainted.
poc
On 26/2/18 1:12 am, Patrick O'Callaghan wrote:
On Sun, 2018-02-25 at 13:00 +1100, Stephen Morris wrote:
On 25/2/18 12:15 am, Patrick O'Callaghan wrote:
On Sat, 2018-02-24 at 15:43 +1100, Stephen Morris wrote:
Are all these taint messages, and all the reasons for a taint message being produced saying that if we have to build our own drivers into the kernel to be able to use our hardware, and hence put us into the situation of potentially not getting support for kernel defects if any are encountered, that we shouldn't be using linux?
If you encounter a kernel defect, how can it be debugged if part of the kernel is not available? That's what tainting amounts to. IIRC you've said that you compile the Nvidia modules. What you are actually doing is compiling code (the dkms system) that enables Nvidia's binary blobs to be linked as modules into the Linux kernel. You don't (unless you work for Nvidia) have the source code of those blobs.
I can understand objects being linked together to build an executable module, but what I don't understand, based on what you are saying, is where the source code in the nvidia directory in /usr/src that dkms is compiling has come from if it hasn't come from nvidia?
No-one is saying it doesn't come from Nvidia. What I'm saying is that that code is *not* the entire Nvidia driver, it's simply linking code that enables the use of the binary driver they supply.
IOW you don't have the *complete* source of the driver. That's why it's tainted.
Thanks Patrick, I guess the link process after the compile is pulling in modules from the libraries packages.
regards,
Steve
poc _______________________________________________ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org
On 24/2/18 3:43 pm, Stephen Morris wrote:
On 24/2/18 2:25 pm, Ed Greshko wrote:
On 02/24/18 10:21, Stephen Morris wrote:
On 23/2/18 8:59 am, Ed Greshko wrote:
On 02/23/18 05:27, Stephen Morris wrote:
From the responses I am getting it seems that the meaning of 'taints the kernel' has morphed into something else?
Here is the definitive list of what taints the kernel. This is from the 4.14 documentation but is also valid for 4.15 kernels.
https://www.kernel.org/doc/html/v4.14/admin-guide/tainted-kernels.html
The numbers in the list correspond to the bit positions in the value supplied by "cat /proc/sys/kernel/tainted"
Why you don't get "tainted" messages in your dmesg output or journal? Don't know....and I'd not be interested in chasing it down.
I've a small program that converts the value from proc-tainted into real info if you need it.
Access to that program would be great, the output from the cat command you mentioned above of 12289 is meaningless to me especially after looking at the web page you highlighted.
12289 = 11000000000001 in binary
[bit] [bit value] [description] 0 1 A module with a non-GPL license has been loaded. (bit 0 is rightmost bit) 12 4096 An out-of-tree module has been loaded 13 8192 An unsigned module has been loaded in a kernel supporting module signature
1 + 4096 + 8192 = 12289
The program I reference simply does the math for you. The source is tainted.c and located at https://paste.fedoraproject.org/paste/a6HyoXLvYCMpjKeym-S~wg
Thanks Ed. Is there any documentation anywhere on what each bit represents?
With bit 13 being set reflecting the loading of an unsigned module into a kernel supporting module signatures, is that because the kernel has been designed for secure boot, and will turning on secure boot resolve the signing issue?
-------------------------------------------------- Snipping the Rest of the Message --------------------------------------------------------------------------------------------------------
Just further to this, I did a system upgrade yesterday which installed a new kernel, so all the drivers were re-compiled. I have two versions of my wifi driver installed in dkms because the oldest of the 3 kernels that exist is using the older wifi driver (and with the kernel changes that were done that required a new version of the wifi driver to be obtained will potentially mean that the new version of the driver will not compile with the oldest version of the kernel I have), and with the kernel update that was done yesterday dkms for some reason decided to compile the wrong version of the wifi driver so I had to manually compile the driver with dkms to get wifi back again (the reasons why the wrong one was selected this time doesn't really matter, I have rectified the situation), but the last couple of compiles of the wifi driver I have done have highlighted that dkms has changed functionality. When I compiled the wifi driver, after the depmod process was run dkms ran dracut to update the associated initramfs, and produced messages about what the backup was called and to use the backup if the next boot failed. Now depending on how comprehensive the logic in this process is, it may or may not work, particularly when in my situation I am compiling 3 kernel modules that all potentially require initramfs changes (I know the nvidia driver does but I'm not sure about the mouse drivers). I know the main xorg nvidia package I am using installs a dracut config file but the wifi driver I am using does not because I am manually loading on the source into /usr/src, so I'm not sure why dkms run dracut when it is compiled, whereas it is understandable for the nvidia driver.
In addition to the above, before I compiled the wifi driver, I ran a 'dmesg | grep -i taint', and that reported the out of tree taint messages for the mouse driver for the first time, plus it produced two new messages that prior to yesterdays update had never been produced before. The output from the command is below:
[ 10.395281] razermouse: loading out-of-tree module taints kernel. [ 10.395344] razermouse: module verification failed: signature and/or required key missing - tainting kernel [ 10.874905] nvidia: module license 'NVIDIA' taints kernel. [ 10.874907] Disabling lock debugging due to kernel taint [ 123.187478] CPU: 6 PID: 825 Comm: systemd-logind Tainted: P OE 4.15.4-300.fc27.x86_64 #1 [ 123.194773] CPU: 3 PID: 655 Comm: nvidia-modeset Tainted: P W OE 4.15.4-300.fc27.x86_64 #1
Why are the two cpu messages now coming out for the first time, has the last update introduced something that is now causing these messages to be produced or has there been additional functionality added to the kernel to produce them.
Looking at the nvidia one, this one is probably understandable given that the nvidia drivers do taint the kernel, but I'm not sure where that module is coming from because when I use yumex to search for modeset I don't get any hits at all.
The systemd one is a bit disconcerting, from the perspective of any kernel modules that systemd has I would have expected to be a native part of the kernel, hence wouldn't be causing any tainted, hence what is this logind binary module that is being inserted into the kernel to cause tainting?
regards,
Steve
On 02/25/18 09:46, Stephen Morris wrote:
[ 10.395281] razermouse: loading out-of-tree module taints kernel. [ 10.395344] razermouse: module verification failed: signature and/or required key missing - tainting kernel [ 10.874905] nvidia: module license 'NVIDIA' taints kernel. [ 10.874907] Disabling lock debugging due to kernel taint [ 123.187478] CPU: 6 PID: 825 Comm: systemd-logind Tainted: P OE 4.15.4-300.fc27.x86_64 #1 [ 123.194773] CPU: 3 PID: 655 Comm: nvidia-modeset Tainted: P W OE 4.15.4-300.fc27.x86_64 #1
Look that the "P", "W", "O", and "E" in the messages above and reference them to those letters in the list in https://www.kernel.org/doc/html/v4.15/admin-guide/tainted-kernels.html
Note the "time" in the message. These are just more information being supplied to you. They are informative.
Why are the two cpu messages now coming out for the first time, has the last update introduced something that is now causing these messages to be produced or has there been additional functionality added to the kernel to produce them.
Looking at the nvidia one, this one is probably understandable given that the nvidia drivers do taint the kernel, but I'm not sure where that module is coming from because when I use yumex to search for modeset I don't get any hits at all.
The systemd one is a bit disconcerting, from the perspective of any kernel modules that systemd has I would have expected to be a native part of the kernel, hence wouldn't be causing any tainted, hence what is this logind binary module that is being inserted into the kernel to cause tainting?
The bottom line is, you're running a Wifi module and another module that you've complied yourself, your running the nVidia driver. Your kernel *is* tainted. You will/may get messages to that effect. Why they come at times and why they don't at others is immaterial. I've said it before, and I'll say it again. I'm not interested in chasing that....and I won't
Unless you're system is failing. Unless your wifi is broken. Unless your graphics are freezing. Your system is running just fine.
So, I'm pretty much at an end when it comes to this thread. There are *no* problems to be solved. So, your choice if you want to continue to worry about those messages and if/when they appear or don't appear.
So, I'm done.
On 25/2/18 1:21 pm, Ed Greshko wrote:
On 02/25/18 09:46, Stephen Morris wrote:
[ 10.395281] razermouse: loading out-of-tree module taints kernel. [ 10.395344] razermouse: module verification failed: signature and/or required key missing - tainting kernel [ 10.874905] nvidia: module license 'NVIDIA' taints kernel. [ 10.874907] Disabling lock debugging due to kernel taint [ 123.187478] CPU: 6 PID: 825 Comm: systemd-logind Tainted: P OE 4.15.4-300.fc27.x86_64 #1 [ 123.194773] CPU: 3 PID: 655 Comm: nvidia-modeset Tainted: P W OE 4.15.4-300.fc27.x86_64 #1
Look that the "P", "W", "O", and "E" in the messages above and reference them to those letters in the list in https://www.kernel.org/doc/html/v4.15/admin-guide/tainted-kernels.html
Note the "time" in the message. These are just more information being supplied to you. They are informative.
Why are the two cpu messages now coming out for the first time, has the last update introduced something that is now causing these messages to be produced or has there been additional functionality added to the kernel to produce them.
Looking at the nvidia one, this one is probably understandable given that the nvidia drivers do taint the kernel, but I'm not sure where that module is coming from because when I use yumex to search for modeset I don't get any hits at all.
The systemd one is a bit disconcerting, from the perspective of any kernel modules that systemd has I would have expected to be a native part of the kernel, hence wouldn't be causing any tainted, hence what is this logind binary module that is being inserted into the kernel to cause tainting?
The bottom line is, you're running a Wifi module and another module that you've complied yourself, your running the nVidia driver. Your kernel *is* tainted. You will/may get messages to that effect. Why they come at times and why they don't at others is immaterial. I've said it before, and I'll say it again. I'm not interested in chasing that....and I won't
Unless you're system is failing. Unless your wifi is broken. Unless your graphics are freezing. Your system is running just fine.
So, I'm pretty much at an end when it comes to this thread. There are *no* problems to be solved. So, your choice if you want to continue to worry about those messages and if/when they appear or don't appear.
So, I'm done.
Thanks Ed, sorry to be so much trouble.
regards,
Steve
users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org
On 02/22/2018 01:27 PM, Stephen Morris wrote:
From the responses I am getting it seems that the meaning of 'taints the kernel' has morphed into something else?
Here's my understanding of it from when I had nVidia graphics. Let's say that you have a kerneloops, but haven't rebooted. Your kernel is considered to be tainted by that because anybody trying to recreate a later kernel issue can't properly know what state the kernel was in. If you have any binary modules loaded that are closed source, your kernel is considered tainted because there's no way to troubleshoot that module or find out if it's involved. (My personal opinion is that in this case somebody should try to recreate the issue with an untainted kernel to see if that module's involved, but I guess that's too much bother.)
On 23/2/18 9:04 am, Joe Zeff wrote:
On 02/22/2018 01:27 PM, Stephen Morris wrote:
From the responses I am getting it seems that the meaning of 'taints the kernel' has morphed into something else?
Here's my understanding of it from when I had nVidia graphics. Let's say that you have a kerneloops, but haven't rebooted. Your kernel is considered to be tainted by that because anybody trying to recreate a later kernel issue can't properly know what state the kernel was in. If you have any binary modules loaded that are closed source, your kernel is considered tainted because there's no way to troubleshoot that module or find out if it's involved. (My personal opinion is that in this case somebody should try to recreate the issue with an untainted kernel to see if that module's involved, but I guess that's too much bother.)
I'm not sure at the moment whether the nvidia module being used is the binary one or the one I compiled from source, but I also compile my wifi driver from source and the 6 mouse modules are also compiled from source, and I am trying to understand why the taint messages, especially the out-of-tree module message, flip-flop between nvidia and my wifi driver, but they have never been produced by the mouse drivers, even though all 3 are compiled through dkms and all the compiled modules are located in the same directory. The dkms.conf file for the mouse driver is different from the file for the wifi driver, but the dkms.conf files for the wifi and nvidia drivers are the same.
regards,
Steve
users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org
-
Ed Greshko -
Ed Greshko -
Joe Zeff -
Patrick O'Callaghan -
Samuel Sieb -
Stephen Morris -
Tim