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):
0) I've tried to get a trivial patch upstream. It silences a build time
warning generated by the advansys driver:
- November 2012: https://lkml.org/lkml/2012/11/5/164 ;
- January 2013: https://lkml.org/lkml/2013/1/29/144 ; and
- January 2014: https://lkml.org/lkml/2014/1/8/569 .
That patch seems to be going nowhere. So a kernel build still generates
a warning when this driver is included. After seven years that is
1) It seems that advansys is unmaintained. The last time its maintainer
touched it - by acking a patch - was in 2008, with commit 25729a7fb88e
("[SCSI] advansys, arcmsr, ipr, nsp32, qla1280, stex: use
Advansys boards should also be quite old by now. I _guess_ they were
produced until a decade ago. On the other hand, there still could be a
few users left, see:
- https://bugzilla.redhat.com/show_bug.cgi?id=844390 (July 2012); and
- https://bugzilla.redhat.com/show_bug.cgi?id=558231 (January 2010).
Other evidence of actual use in Fedora is much older. The most recent I
could find was https://bugzilla.redhat.com/show_bug.cgi?id=162431 (July
2005). And I don't think nine year old reports are very relevant.
3) Is it acceptable for Fedora to remove advansys from
config-x86-generic? Or would my trivial patch - or something like it -
be acceptable? Either way, I'd like to be able to finally drop my local
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.
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
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
@@ -171,3 +171,5 @@ CONFIG_SFC_MTD=y
+# Override bootcpu hotplug
not sure if the depmod-message does any harm (not for me at least)
if i understand the message correctly "hci_vhci" may not be loaded
Last login: Mon Jan 20 20:33:24 2014 from 192.168.196.1
[root@rawhide ~]# yum update http://kojipkgs.fedoraproject.org//packages/kernel/3.13.0/1.fc21/x86_64/k...
Running transaction check
Running transaction test
Transaction test succeeded
Installieren : kernel-3.13.0-1.fc21.x86_64
depmod: ERROR: Module 'hci_vhci' has devname (vhci) but lacks major and minor information. Ignoring.
Überprüfung läuft: kernel-3.13.0-1.fc21.x86_64
Had an old box (F20)
was giving lots of grief.
Got a new one.
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.
Just for knowledge, it boots fine.
Already looked at:
WARNING: CPU: 0 PID: 1730 at lib/idr.c:527
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
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
- 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