Re: Nvidia Module Tainting Kernel

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx
_______________________________________________
users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx



[Index of Archives]     [Older Fedora Users]     [Fedora Announce]     [Fedora Package Announce]     [EPEL Announce]     [EPEL Devel]     [Fedora Magazine]     [Fedora Summer Coding]     [Fedora Laptop]     [Fedora Cloud]     [Fedora Advisory Board]     [Fedora Education]     [Fedora Security]     [Fedora Scitech]     [Fedora Robotics]     [Fedora Infrastructure]     [Fedora Websites]     [Anaconda Devel]     [Fedora Devel Java]     [Fedora Desktop]     [Fedora Fonts]     [Fedora Marketing]     [Fedora Management Tools]     [Fedora Mentors]     [Fedora Package Review]     [Fedora R Devel]     [Fedora PHP Devel]     [Kickstart]     [Fedora Music]     [Fedora Packaging]     [Fedora SELinux]     [Fedora Legal]     [Fedora Kernel]     [Fedora OCaml]     [Coolkey]     [Virtualization Tools]     [ET Management Tools]     [Yum Users]     [Yosemite News]     [Gnome Users]     [KDE Users]     [Fedora Art]     [Fedora Docs]     [Fedora Sparc]     [Libvirt Users]     [Fedora ARM]

  Powered by Linux