The following commit seems to cause problems with hibernation on 32-bit
systems:
commit 92923ca3aacef63c92dc297a75ad0c6dfe4eab37
Author: Nathan Zimmer <nzimmer@sgi.com>
Date: Tue Jun 30 14:56:48 2015 -0700
mm: meminit: only set page reserved in the memblock region
Without this commit, it takes less than 10-15 seconds on our test system
(https://linux-hardware.org/index.php?probe=e6a06c64c7) from
"systemctl hibernate" command till the system powers off. With the
mainline kernels 4.2-4.7, the system resumes OK.
With this commit, it takes more than 2 minutes for that system to
hibernate and it usually hangs on resume.
Let us revert the main parts of this commit in the 32-bit kernels for
now.
1. Got rid of statistics to simplify maintenance. Changing global
kernel structures is not a thing to take lightly.
2. Removed sanitization of pages. Starting from kernel 4.6, page
poisoning should be used instead. To enable it, set page_poison=on in
the boot options for the kernel.
3. The sanitization patch is now applied only if enhanced security is
enabled (disabled by default for ROSA Fresh, enabled for cert. builds).
You can also use "rpmbuild -ba --with enhanced_security <...>" to force
enable the feature.
It does not work. Say, kernel 4.6.x does not support broadcom-wl version
5.x. However, installing kernel 4.6.x should not remove that driver
because the user might have a different kernel installed that supports
it.
It would be cleaner if the driver packages specified the minimum required
kernel versions, "kernel >= x.y.z" (the kernel has the appropriate
"Provides" for that). Same for the maximum kernel versions supported by
the driver.
Similar for the obsoletes: this kernel may provide the listed drivers
but we cannot be sure about other kernels the user might have installed.
A safer route seems to be not to require dkms-* directly but rather -
via "Requires: kmod(xxx)". Again, it is not the kernel's responsibility
to keep track of all this.
While at it, cleaned up the spec a bit more.
If anyone needs the sources of our kernel, they can easily get an SRPM,
unpack it and run "rpmbuild -bp" to get the properly patched source
tree.
The configuration files for the different kernel flavours will also be
available in that source tree, in arch/x86/configs/.
Let us save a bit of a build time then and not build the RPM with the
sources by default.
Earlier, the patches were kept in the respective branches of a separate
project, https://abf.io/soft/kernel-patches-and-configs. And before that -
in the custom tarballs.
Now all the patches are kept here along with the spec file and are
applied the default way rather than by separate scripts. This should
make the maintenance of the patches as well as the experiments with the
new ones a lot easier.
The previous scheme seemed to offer a bit more flexibility (different
patch sets for different cases) at the cost of maintenance. But as it
turned out, that flexibility was not worth it and was rarely used,
at most.
The intent behind these things was to simplify building of pre-release
kernels and such. Over time, it became too cumbersome to use though.
Let us get rid of all that stuff and make the spec a bit cleaner.
