Change to provides for kernel-PAE-modules-extra
by Bruno Wolff III
kernel-PAE-modules-extra used to provide kernel-modules-extra. This allowed
packages that needed either to just require kernel-modules-extra. I see
that both provide installonlypkg(kernel-module). Should packages that
need either require that instead?
This affects at least the following packages (maybe indirectly):
gfs2-utils
joystick-support
libguestfs
perl-Sys-Guestfs
python-libguestfs
virt-v2v
10 years, 2 months
3.14 merge window kernels
by Josh Boyer
Hi All,
I'll be starting the 3.14 merge window kernels sometime later today.
As usual, I'll do my best on the various arch configs and would
appreciate if people could look them over as the flow in.
For those wanting to get additional patches in, please wait until
3.14-rc1 is built so that we don't have to fight through both merge
window and patch churn.
josh
10 years, 3 months
[PATCH] config, x86 enable boot cpu hotplug
by Prarit Bhargava
Set CONFIG_BOOTPARAM_HOTPLUG_CPU0 to 'y'. Currently, to disable CPU0,
the "boot" cpu, one must specify cpu0_hotplug as a kernel parameter.
Setting this config variable to 1 enables it by default.
I've tested this on systems where it was expected to work and it seems to
function properly.
Signed-off-by: Prarit Bhargava <prarit(a)redhat.com>
---
config-x86_64-generic | 2 ++
1 file changed, 2 insertions(+)
diff --git a/config-x86_64-generic b/config-x86_64-generic
index 0bb4160..04431cb 100644
--- a/config-x86_64-generic
+++ b/config-x86_64-generic
@@ -171,3 +171,5 @@ CONFIG_SFC_MTD=y
CONFIG_MTD_CHAR=m
CONFIG_MTD_BLOCK=m
+# Override bootcpu hotplug
+CONFIG_BOOTPARAM_HOTPLUG_CPU0=y
--
1.8.3.1
10 years, 3 months
OT? Nubmer of Cores used
by Frank Murphy
Had an old box (F20)
Core2 Quad
was giving lots of grief.
Got a new one.
kernel-3.12.8-300.fc20.x86_64
cat /proc/cpuinfo
shows only 1 core
processor : 0
even though with
uname -a "SMP" shows up. #latest
How can I be certain all cores are in use.
This box I'm typing on an i3,
show 4 processors.
___
Regards,
Frank
www.frankly3d.com
10 years, 3 months
What makes kernel tainted?
by Frank Murphy
Just for knowledge, it boots fine.
Already looked at:
http://www.tux.org/lkml/#s1-18
WARNING: CPU: 0 PID: 1730 at lib/idr.c:527
idr_remove.part.6+0x243/0x250()
idr_remove called for id=94 which is not allocated.
Cannot report due to tainted kernel,
can this happen without proprietary stuff (nvidia etc..?
CPU: 0 PID: 1730 Comm: systemd Tainted: G W
3.13.0-0.rc7.git0.2.fc21.x86_64 #1 Hardware name: Gigabyte Technology
Co., Ltd. To be filled by O.E.M./H61MA-D2V, BIOS F6 04/17/2013
___
Regards,
Frank
www.frankly3d.com
10 years, 3 months
Rawhide debug options in 3.14 and future
by Josh Boyer
We've known for a while that the current policy of shipping Rawhide
kernels with debug enabled leads to a pretty big performance hit for a
large number of people. A while ago Justin, Adam Williamson, Kevin
Fenzi, and I (with the help of others) dug in and figured out that
most of this impact comes from having SLUB debugging turned on and
enabled by default. We took two measures to help alleviate some of
this. The first was that we ship the first -rcX build, and each final
kernel release build, with debug disabled. The second was that Justin
got the Rawhide NoDebug repo up and running.
Both of those steps seemed to help, and the NoDebug repo has been a
success as far as we can tell. Which is to say that people tell us
they use it, and they complain when it isn't up to date. However,
even the most ardent Rawhide testers seem to have realized that
booting with slub_debug=- gets them what they need and made it their
default way of running kernels. Basically, that negates the value of
having it enabled for the majority of the people actually bothering to
run Rawhide kernels in the first place.
After discussing it with the rest of the team and realizing that the
runtime enable/disable function works both ways, we're going to start
disabling SLUB debug by default in Rawhide kernels starting with 3.14
for all kernel builds after the corresponding -rc1 release. I spent
some time looking through bugzilla and realized that most of the SLUB
debugging stuff that gets caught happens in the merge window kernels
(pre-rc1), so we'll leave it enabled for the merge window to catch the
stuff happening there. After -rc1 is released, it will remain
disabled by default.
So to summarize:
- SLUB debugging will only be enabled by default on merge window
snapshot kernels
- No other debug options are changing, as we're doing this to address
a specific problem. This is not a flag day, and things like lockdep
debugging and other options are still very helpful. That means for
those wanting all debug options disabled, the NoDebug repo is where
you want to go.
Hopefully this makes Rawhide a bit more usable for people, which will
correlate with an uptick in it being used. If you have any questions,
let us know.
As an aside, Dave brought up that it might be nice to have a script
that we could run to sort of "debugize" a non-debug kernel. Things
like switching on slub debugging, disabling 'rhgb' and 'quiet' from
the default command line, or any other runtime tunables that we can
think of. Rather than asking for things piecemeal, we could just have
the user run such a script to help them get us debugging information.
If someone is interested in scripting something like that, please
speak up!
josh
10 years, 3 months
