[elrepo] Announcement: EL7 Updated kernel-ml Package Set [4.14.6-1]

[Derek Schrock]

On Thu, Dec 14, 2017 at 01:44:36PM EST, Alan Bartlett wrote:
> Announcing the release of the kernel-ml-4.14.6-1.el7.elrepo package
> set into the EL7 elrepo-kernel repository:
> 
> https://elrepo.org/tiki/kernel-ml
> 
> The upstream changelog:
> 
> https://www.kernel.org/pub/linux/kernel/v4.x/ChangeLog-4.14.6
> 
> The following files are currently synchronising to our mirror sites:
> 
> x86_64
> kernel-ml-4.14.6-1.el7.elrepo.x86_64.rpm
> kernel-ml-devel-4.14.6-1.el7.elrepo.x86_64.rpm
> kernel-ml-doc-4.14.6-1.el7.elrepo.noarch.rpm
> kernel-ml-headers-4.14.6-1.el7.elrepo.x86_64.rpm
> kernel-ml-tools-4.14.6-1.el7.elrepo.x86_64.rpm
> kernel-ml-tools-libs-4.14.6-1.el7.elrepo.x86_64.rpm
> kernel-ml-tools-libs-devel-4.14.6-1.el7.elrepo.x86_64.rpm
> perf-4.14.6-1.el7.elrepo.x86_64.rpm
> python-perf-4.14.6-1.el7.elrepo.x86_64.rpm
> 
> nosrc
> kernel-ml-4.14.6-1.el7.elrepo.nosrc.rpm
> 
> We provide these kernels for hardware testing in an effort to identify
> new/updated drivers which can then be targeted for backporting as kmod
> packages. Meanwhile, these kernels may provide interim relief to
> people with non-functional hardware. We stress that we consider such
> kernels as a last resort for those who are unable to get their
> hardware working using the RHEL-7 kernel with supplementary kmod
> packages.
> 
> These packages are provided "As-Is" with no implied warranty or
> support. Using the kernel-ml may expose your system to security,
> performance and/or data corruption issues. Since timely updates may
> not be available from the ELRepo Project, the end user has the
> ultimate responsibility for deciding whether to continue using the
> kernel-ml packages in regular service.
> 
> The packages are intentionally named kernel-ml so as not to conflict
> with the RHEL-7 kernels and, as such, they may be installed and
> updated alongside the regular kernel. The kernel configuration is
> based upon a default RHEL-7 configuration with added functionality
> enabled as appropriate.
> 
> If a bug is found when using these kernels, the end user is encouraged
> to report it upstream to the Linux Kernel Bug Tracker [1] and, for our
> reference, to the ELRepo bug tracker [2]. By taking such action, the
> reporter will be assisting the kernel developers, Red Hat and the Open
> Source Community as a whole.
> 
> Thank you,
> 
> The ELRepo Team.
> 
> [1] https://bugzilla.kernel.org/
> [2] https://elrepo.org/bugs/
> _______________________________________________
> elrepo mailing list
> elrepo at lists.elrepo.org
> http://lists.elrepo.org/mailman/listinfo/elrepo

You can see the solution to this issue here:

https://devtalk.nvidia.com/default/topic/1027427/linux/nvidia-384-98-and-display-orientation-chaning-when-x-restarts-layout-less-xorg-conf/post/5226491/#5226491

It's possible for some older hardware the kernel param nvidia-drm.modeset=1 needs set.  We're using NVS 510s.