kernel January 2014

kernel@lists.fedoraproject.org

25 participants
31 discussions

Change to provides for kernel-PAE-modules-extra
by Bruno Wolff III 27 Jan '14

27 Jan '14

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

2 4

Silence advansys build time warning in Fedora's kernel build?
by Paul Bolle 23 Jan '14

23 Jan '14

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 getting pointless. 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 pci_ioremap_bar()"). 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 patch. Paul Bolle

3 7

kernel SOP?
by Frank Murphy 21 Jan '14

21 Jan '14

Forwarded from my post at test@ https://lists.fedoraproject.org/pipermail/test/2014-January/120172.html ___ Regards, Frank www.frankly3d.com

2 1

3.14 merge window kernels
by Josh Boyer 21 Jan '14

21 Jan '14

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

3 3

[PATCH] config, x86 enable boot cpu hotplug
by Prarit Bhargava 21 Jan '14

21 Jan '14

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

2 6

Rawhide: depmod: ERROR: Module 'hci_vhci' has devname (vhci) but lacks major and minor information. Ignoring
by Reindl Harald 20 Jan '14

20 Jan '14

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 ____________________________________ [harry@srv-rhsoft:~]$ rawhide 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/ker… ............................................ Downloading packages: Running transaction check Running transaction test Transaction test succeeded Running transaction Installieren : kernel-3.13.0-1.fc21.x86_64 1/1 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 1/1 Installiert: kernel.x86_64 0:3.13.0-1.fc21

2 2

OT? Nubmer of Cores used
by Frank Murphy 19 Jan '14

19 Jan '14

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

1 1

What makes kernel tainted?
by Frank Murphy 17 Jan '14

17 Jan '14

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

4 5

Kernel package scriptlet bugs
by Ankur Sinha 16 Jan '14

16 Jan '14

Hi, I've run into a couple of kernel scriptlet bugs just today. I've filed bugs at bugzilla: "warning: %post(kernel-3.13.0-0.rc8.git2.2.fc21.x86_64) scriptlet failed, exit status 127 (also with kernel-modules-extra)" https://bugzilla.redhat.com/show_bug.cgi?id=1053957 "Error in PREUN scriptlet in rpm package kernel-3.12.7-300.fc20.x86_64" https://bugzilla.redhat.com/show_bug.cgi?id=1053948 ^This is with the 3.12.7-300 kernel which is already in updates. It probably didn't get caught because nobody's tried removing the package yet. I thought I'd bring them to your attention, lest they get lost amongst all the other kernel bugs. -- Thanks, Warm regards, Ankur (FranciscoD) http://fedoraproject.org/wiki/User:Ankursinha Join Fedora! Come talk to us! http://fedoraproject.org/wiki/Fedora_Join_SIG

2 2

Rawhide debug options in 3.14 and future
by Josh Boyer 16 Jan '14

16 Jan '14

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

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

kernel January 2014