kernel November 2012

kernel@lists.fedoraproject.org

15 participants
16 discussions

fedora 14 kernel performance with ip forwarding workload
by Jesse Brandeburg 04 Jun '15

04 Jun '15

The other day I was running the stock fedora kernel on my ip forwarding setup, to see what the performance was, and the performance wasn't very good. system is S5520HC dual socket 2.93GHz Xeon 5570 (Nehalem) with 3 quad port 82580 adapters (12 ports). Traffic is bidirectional 64 byte packets being forwarded and received on each port, basically port to port routing. I am only using 12 flows currently. The driver is igb, and I am using an affinity script that lines up each pair of ports that are forwarding traffic into optimal configurations for cache locality. I am also disabling remote_node_defrag_ratio to stop cross node traffic. With the fedora default kernel from F14 it appears that CONFIG_NETFILTER=y means that I cannot unload all of netfilter even if I stop iptables service. perf showed netfilter being prominent, and removing it gives me much higher throughput. Is there a reason CONFIG_NETFILTER=y ? Isn't it a good thing to be able to disable netfilter if you want to? Jesse

5 9

[PATCH] Drop the old Adaptec AIC7xxx driver
by Paul Bolle 04 Feb '13

04 Feb '13

Ever since v2.4.3 this driver is advertised as not being under active development. It's main advantage to most users will be the warnings it generates at build time: drivers/scsi/aic7xxx_old.c: In function ‘aic7xxx_register’: drivers/scsi/aic7xxx_old.c:7901:5: warning: case value ‘257’ not in enumerated type ‘ahc_chip’ [-Wswitch] drivers/scsi/aic7xxx_old.c:7898:5: warning: case value ‘513’ not in enumerated type ‘ahc_chip’ [-Wswitch] drivers/scsi/aic7xxx_old.c: In function ‘aic7xxx_load_seeprom’: drivers/scsi/aic7xxx_old.c:8517:5: warning: case value ‘257’ not in enumerated type ‘ahc_chip’ [-Wswitch] drivers/scsi/aic7xxx_old.c:8510:5: warning: case value ‘513’ not in enumerated type ‘ahc_chip’ [-Wswitch] Let's drop this old driver. Signed-off-by: Paul Bolle <pebolle(a)tiscali.nl> --- 0) I'm trying to get my kernel builds (which use the Fedora kernel config) warning free. Upstream declined the brilliant fix to silence these warnings (see https://lkml.org/lkml/2012/9/21/104 ). 1) Plan B is to simply drop this old driver in the Fedora kernel altogether. That should silence these warnings too, shouldn't it? But is dropping this old driver acceptable? 2) This patch is entirely untested. config-generic | 1 - 1 file changed, 1 deletion(-) diff --git a/config-generic b/config-generic index 4a8015f..5cc8f8d 100644 --- a/config-generic +++ b/config-generic @@ -341,7 +341,6 @@ CONFIG_SCSI_3W_9XXX=m CONFIG_SCSI_ACARD=m CONFIG_SCSI_AACRAID=m CONFIG_SCSI_AIC7XXX=m -CONFIG_SCSI_AIC7XXX_OLD=m CONFIG_AIC7XXX_CMDS_PER_DEVICE=4 CONFIG_AIC7XXX_RESET_DELAY_MS=15000 # CONFIG_AIC7XXX_BUILD_FIRMWARE is not set -- 1.7.11.7

2 2

Re: [kernel] Disable debugging options.
by Thorsten Leemhuis 21 Nov '12

21 Nov '12

On 18.06.2012 15:09, Josh Boyer wrote: > commit 3b37beedf48825354c42e25f7001677320958d38 > Author: Josh Boyer <jwboyer(a)redhat.com> > Date: Mon Jun 18 09:09:58 2012 -0400 > > Disable debugging options. > > config-generic | 8 ++-- > config-nodebug | 112 ++++++++++++++++++++++++++-------------------------- > config-x86-generic | 2 +- > kernel.spec | 9 +++- > 4 files changed, 67 insertions(+), 64 deletions(-) > --- > diff --git a/config-generic b/config-generic > index 6b1c651..08c28ba 100644 > --- a/config-generic > +++ b/config-generic > @@ -1446,13 +1446,13 @@ CONFIG_B43_SDIO=y > CONFIG_B43_BCMA=y > # CONFIG_B43_BCMA_EXTRA is not set > CONFIG_B43_BCMA_PIO=y > -CONFIG_B43_DEBUG=y > +# CONFIG_B43_DEBUG is not set > [...] Just out of curiosity: Why is enabling and disabling the debug options done via "make {no,}debug" in the git checkout and not by an conditional within the spec file? That afaics makes it harder to switch the debug options off if you only have the SRPM at hand. Or am I missing something obvious here? CU knurd

3 6

why is memory hotplug disabled in f17+
by Roman Kagan 21 Nov '12

21 Nov '12

As I found out recently, memory hotplug is disabled in f17 and f18 kernels (but not in f16). Can anybody please recall the reason for that? The commit doing that is not particularly enlightening: commit 2ee9f1482920f6d831eb6d70458bd0988394982b Author: Dave Jones <davej(a)redhat.com> Date: Fri Jan 13 17:33:51 2012 -0500 Disable memory hotplug on x86-64 I'd like to propose to re-enable it but I'm trying to figure out why it was disabled in the first place. Thanks, Roman.

2 2

Rawhide nodebug repo currently has a debug kernel
by Bruno Wolff III 20 Nov '12

20 Nov '12

3.7.0-0.rc6.git1.1.fc19 in the rawhide nodebug repo looks to be a debug kernel based on the rpms in that repo. (It also appears to have the performance issues of a debug kernel.)

2 1

Fedora Kernel Meeting Minutes for Nov 16, 2012
by Josh Boyer 19 Nov '12

19 Nov '12

The minutes below are fairly sparse in content. The meeting itself was very brief, so feel free to look in the full logs. A summary on F18 beta is "we're in fairly decent shape. Testing and karma for the kernels in updates-testing are always appreciated." ============================== #fedora-meeting: Fedora Kernel ============================== Meeting started by jwb at 19:00:03 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting/2012-11-16/fedora-meeting.2… . Meeting summary --------------- * init (jwb, 19:00:19) * F18 beta status (jwb, 19:02:10) * open floor (jwb, 19:10:56) * LINK: http://paste.stg.fedoraproject.org/1794/ (nirik, 19:31:07) Meeting ended at 19:35:50 UTC. Action Items ------------ Action Items, by person ----------------------- * **UNASSIGNED** * (none) People Present (lines said) --------------------------- * jwb (56) * jforbes (21) * brunowolff (9) * nirik (9) * zodbot (2) Generated by `MeetBot`_ 0.1.4 .. _`MeetBot`: http://wiki.debian.org/MeetBot

1 0

nodebug repo feedback
by Bruno Wolff III 16 Nov '12

16 Nov '12

Observations: Not having it obvious in the kernel name that it was a kernel from the nodebug repo caused a minor amount of confusion. A normal rawhide kernel and a nodebug repo kernel both ended up with the name 3.7.0-0.rc5.git1.3.fc19. A normal rawhide nodebug kernel is still being built once per rc. There seems to be a lot of variability in the lag of when a nodebug version of any particular rawhide kernel. Suggestions: Instead of bumping the release number for nodebug kernels and the string ".nodebug" to the end of the release. For example: 3.7.0-0.rc5.git1.3.fc19.nodebug Always build debug kernels for rawhide. Automate building of nodebug kernels so that once a rawhide kernel has successfully completed building in koji, the same kernel gets rebuilt as a nodebug kernel. Check on the order of hourly.

4 9

Hi from ARM
by Peter Robinson 16 Nov '12

16 Nov '12

I'm been bothering Josh and others long enough with breaking kernel builds with the ARM bits that I should probably be subscribed to the list now that I know there is one! Have a good weekend Peter

1 0

[PATCH] KConfig: enable CONFIG_CIFS_SMB2
by Jeff Layton 16 Nov '12

16 Nov '12

Enough of the CIFS SMB2 code has been merged into 3.7 that users can now mount SMB2.1 shares from servers that support it. It's still fairly experimental, but enabling the Kconfig option is unlikely to break users who are using SMB1. Let's go ahead and enable this in 3.7 kernels. I think this patch should be sufficient, but let me know if we should do anything else. Signed-off-by: Jeff Layton <jlayton(a)redhat.com> --- config-generic | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/config-generic b/config-generic index 1ac3545..a27aedd 100644 --- a/config-generic +++ b/config-generic @@ -3671,7 +3671,7 @@ CONFIG_RPCSEC_GSS_KRB5=m CONFIG_CIFS=m CONFIG_CIFS_STATS=y # CONFIG_CIFS_STATS2 is not set -# CONFIG_CIFS_SMB2 is not set +CONFIG_CIFS_SMB2=y CONFIG_CIFS_UPCALL=y CONFIG_CIFS_XATTR=y CONFIG_CIFS_POSIX=y -- 1.7.11.7

2 1

Unknown module key warnings
by Bruno Wolff III 16 Nov '12

16 Nov '12

As far as I can tell the unknown module key isn't a problem, but I get a number of warnings for it during boot. Is there really a problem here? If there isn't, can these be suppressed? Here is an example warning: Nov 12 00:03:43 bruno kernel: [ 40.835401] Request for unknown module key 'Fedora kernel signing key: 2f230f4662d4290a932538bd964f802eaa42f49a' err -11

2 9

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

kernel November 2012