kernel April 2012

kernel@lists.fedoraproject.org

20 participants
19 discussions

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

05 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] Use BIOS Keyboard variable to set Numlock
by Joshua C. 29 May '12

29 May '12

Can some, please, apply the following patch to the fedora kernel? http://marc.info/?l=linux-kernel&m=133072333922354&w=2 . It sets the NumLock state on the keyboard according to the data in the bios.

3 5

Regression testing
by Justin Forbes 04 May '12

04 May '12

As some of you have seen in our community meeting and minutes, we are working on actively testing the kernel builds. The short version is a series of regression tests which reside in either the kernel git tree and can be run with 'make tests' or possibly a control script in a kernel-tests subpackage. This will allow any user to run the regression tests against their running kernel on real hardware, and hopefully improve the test base considerably. In addition we will have autotest hooked up to do this plus more extensive testing. More details can be found at https://fedoraproject.org/wiki/KernelTestingInitiative So here is the part where we really want to get community involved. We have a wiki page created to list the regression tests that need to be written, and even sign up to write some if you are so inclined. We need your ideas for regression tests. Tests should be simple pass/fail checks. Tests against specific modules are allowed and encouraged. For users testing where they module is not loaded, the test will simply be skipped. Destructive testing is possible, though it will not be included in the standard test run (a user should know and explicitly sign up for a risk of data loss). Please take a look and add your ideas: https://fedoraproject.org/wiki/KernelRegressionTests Thanks, Justin

3 3

Fwd: [PATCH] ARM: Fix restoration of IP scratch register when auditing syscalls
by Jon Masters 01 May '12

01 May '12

-------- Original Message -------- Subject: [PATCH] ARM: Fix restoration of IP scratch register when auditing syscalls Date: Sun, 29 Apr 2012 02:38:24 -0400 From: Jon Masters <jcm(a)jonmasters.org> To: Linux ARM Kernel <linux-arm-kernel(a)lists.infradead.org> CC: Jon Masters <jcm(a)redhat.com>, Al Viro <viro(a)zeniv.linux.org.uk>, Eric Paris <eparis(a)redhat.com>, Jon Masters <jcm(a)jonmasters.org> The audit subsystem builds upon ptrace to record system calls. This is done in a couple of places (on return from fork into a new task, on exit from the SWI vector), using calls to syscall_trace. The latter function abuses the userspace intra-procedure scratch register (regs->ARM_ip, aka r12), and intends to restore it prior to return to userspace. Unfortunately, there are cases where we will return to userspace without restoring. If we are in fact not ptracing but are merely auditing calls, we will happily trash the content of ip but will exit to userspace without restoring the value. It just so happens that GLIBC uses ip as a storage for the TLS thread pointer info, and bad things result. The fix is simply to have an additional out when not ptracing. Signed-off-by: Jon Masters <jcm(a)jonmasters.org> --- arch/arm/kernel/ptrace.c | 10 +++++++--- 1 files changed, 7 insertions(+), 3 deletions(-) diff --git a/arch/arm/kernel/ptrace.c b/arch/arm/kernel/ptrace.c index ede6443..7b05b6e 100644 --- a/arch/arm/kernel/ptrace.c +++ b/arch/arm/kernel/ptrace.c @@ -928,10 +928,10 @@ asmlinkage int syscall_trace(int why, struct pt_regs *regs, int scno) audit_syscall_entry(AUDIT_ARCH_NR, scno, regs->ARM_r0, regs->ARM_r1, regs->ARM_r2, regs->ARM_r3); - if (!test_thread_flag(TIF_SYSCALL_TRACE)) - return scno; + if (!test_thread_flag(TIF_SYSCALL_TRACE)) + goto out_no_ptrace; if (!(current->ptrace & PT_PTRACED)) - return scno; + goto out_no_ptrace; current_thread_info()->syscall = scno; @@ -951,4 +951,8 @@ asmlinkage int syscall_trace(int why, struct pt_regs *regs, int scno) regs->ARM_ip = ip; return current_thread_info()->syscall; + +out_no_ptrace: + regs->ARM_ip = ip; + return scno; }

3 4

CCISS Support in FC16?
by James Schatzman 30 Apr '12

30 Apr '12

Upon upgrading from FC14 to FC16 this DL380-G4 cannot be booted from any of the FC16 kernels. Still boots successfully from the old FC14 kernel. The results when booting 3.1.0 and 3.3.2 are different. The results when booting 3.3.2-1.fc16.i686.PAE and 3.3.2-6.fc16.i686.PAE are identical.I followed the instructions on fedoraproject.org, modifying the kernel command line options to get debugging output. 3.3.2 - console output - both 3.3.2-1.fc16.i686.PAE and 3.3.2-6.fc16.i686.PAE -------------------------------------------------------------- ... [see attachment] Write protecting the kernel text: 5456k Write protecting the kernel read-only data: 2124k NX-protecting the kernel data: 4784K init[1] general protection ip:b771a419 sp:bffccc5c error:0 Kernel panic - not syncing: Attempting to kill init! ---------------------------------------------------------------------- At this point the system is locked up and there does not appear to be any way to retrieve any init.log file. See the attachment for a screen dump of the final bits of the console output. Because this computer is located remotely I don't have any way to access more output than that. All initramfs files for all kernels have the cciss driver, according to lsinitrd. Neverethless, the FC16 kernels fail to boot. 3.1.0 console output ----------------------------------------------------- ....[lots of output] dmesg | grep dracut >>> very many screenshots [ I have no way to save the output to a file] The last 7 screens of this dmesg output are attached. From the emergency shell, the output of dmsetup ls --tree --> No devices found blkid --> no output blkid -c udev --> no output I am not sure what the initramfs is doing, but it appears to have trouble finding the LVM/ext3 root filesystem. 2.6 Boot --------------------------------------------------- Boots normally. Some data: dmsetup ls --tree VolGroup00-LogVol01 (253:1) ââ (104:2) VolGroup00-LogVol00 (253:0) ââ (104:2) blkid /dev/cciss/c0d0p1: LABEL="/boot" UUID="c051ed89-7747-4756-bb8e-6f15ccfead88" SEC_TYPE="ext2" TYPE="ext3" /dev/dm-0: UUID="8af89900-0449-40e8-952a-75b8ffa7a693" SEC_TYPE="ext2" TYPE="ext3" /dev/dm-1: TYPE="swap" /dev/cciss/c0d1p5: LABEL="/data1" UUID="c082e209-e3d9-4515-9327-e78fb434088a" SEC_TYPE="ext2" TYPE="ext3" /dev/cciss/c0d1p6: LABEL="/data2" UUID="3882e8f8-817e-4a6a-ae36-febcabddfcd4" SEC_TYPE="ext2" TYPE="ext3" /dev/cciss/c0d2: LABEL="data2" UUID="57fe361b-0d73-4cc9-9592-cfc7c8fad00d" SEC_TYPE="ext2" TYPE="ext3" /dev/cciss/c0d2p5: LABEL="/data3" UUID="5f079cb2-a086-4700-9b87-5d57e706dca8" SEC_TYPE="ext2" TYPE="ext3" /dev/cciss/c0d2p6: LABEL="/data4" UUID="cfcf37a2-f2ff-4ff5-98c7-d4fcd40e7418" SEC_TYPE="ext2" TYPE="ext3" /dev/VolGroup00/LogVol00: UUID="8af89900-0449-40e8-952a-75b8ffa7a693" SEC_TYPE="ext2" TYPE="ext3" /dev/VolGroup00/LogVol01: TYPE="swap" /dev/mapper/VolGroup00-LogVol01: TYPE="swap" /dev/mapper/VolGroup00-LogVol00: UUID="8af89900-0449-40e8-952a-75b8ffa7a693" SEC_TYPE="ext2" TYPE="ext3" /dev/cciss/c0d0p2: UUID="IC0t0N-WiTL-UQ7d-IsRD-w5Hz-91Pv-Big08T" TYPE="LVM2_member" blkid -c udev /dev/cciss/c0d0p1: LABEL="/boot" UUID="c051ed89-7747-4756-bb8e-6f15ccfead88" TYPE="ext3" /dev/cciss/c0d0p2: UUID="IC0t0N-WiTL-UQ7d-IsRD-w5Hz-91Pv-Big08T" TYPE="LVM2_member" /dev/cciss/c0d1p5: LABEL="/data1" UUID="c082e209-e3d9-4515-9327-e78fb434088a" TYPE="ext3" /dev/cciss/c0d1p6: LABEL="/data2" UUID="3882e8f8-817e-4a6a-ae36-febcabddfcd4" TYPE="ext3" /dev/cciss/c0d2: LABEL="data2" UUID="57fe361b-0d73-4cc9-9592-cfc7c8fad00d" SEC_TYPE="ext2" TYPE="ext3" /dev/cciss/c0d2p5: LABEL="/data3" UUID="5f079cb2-a086-4700-9b87-5d57e706dca8" TYPE="ext3" /dev/cciss/c0d2p6: LABEL="/data4" UUID="cfcf37a2-f2ff-4ff5-98c7-d4fcd40e7418" TYPE="ext3" /dev/mapper/VolGroup00-LogVol00: UUID="8af89900-0449-40e8-952a-75b8ffa7a693" TYPE="ext3" /dev/mapper/VolGroup00-LogVol01: TYPE="swap" more /etc/fstab /dev/VolGroup00/LogVol00 / ext3 defaults 1 1 LABEL=/boot /boot ext3 defaults 1 2 none /dev/pts devpts gid=5,mode=620 0 0 none /dev/shm tmpfs defaults 0 0 none /proc proc defaults 0 0 none /sys sysfs defaults 0 0 /dev/VolGroup00/LogVol01 swap swap defaults 0 0 LABEL=/data1 /d0 ext3 rw,acl 1 2 LABEL=/data2 /d1 ext3 defaults 1 2 LABEL=/data3 /d2 ext3 defaults 1 2 LABEL=/data4 /d3 ext3 defaults 1 2 Thanks! Jim

1 0

F15, F16 and F17 on the same kernel but with different patch sets?
by Joshua C. 29 Apr '12

29 Apr '12

Currently F15, f16 and f17 are on one and the same kernel but when you look at the git repo you'll see that those don't get the same patches. It looks like that most of the developers push to f17 and then let others apply the patches to f16 and f15 (if they are applied at all). It'll be great if those repos are synced and every future patch is applied to all three kernel. -- -- joshua

2 1

Fwd: Fixing audit on ARM
by Jon Masters 29 Apr '12

29 Apr '12

-------- Original Message -------- Subject: Fixing audit on ARM Date: Sun, 29 Apr 2012 02:38:23 -0400 From: Jon Masters <jcm(a)jonmasters.org> To: Linux ARM Kernel <linux-arm-kernel(a)lists.infradead.org> CC: Jon Masters <jcm(a)redhat.com>, Al Viro <viro(a)zeniv.linux.org.uk>, Eric Paris <eparis(a)redhat.com> Hi Folks, I've been playing around with getting ARM kernels built in more standard Fedora configurations (as have a number of other members of the Fedora ARM community). This has turned up a bunch of problems so far, which is both good and bad. The upside is that we can all work together to make sure some of these non-embedded features get more testing :) Anyway. I'm sending a trivial fix that prevents systemd going into a forkbomb OOM tailspin on all recent Fedora ARM kernels (unless we turn off audit). Note that the fact that this has been corrupting userspace up to this point suggests strongly to me that we should be also considering turning off audit on ARM systems until it is known that there are not other issues. But I can run my test system successfully, so I submit this fix for review anyway. Thanks, Jon.

1 0

Fedora Kernel Meeting 04-27-2012 Minutes
by Josh Boyer 28 Apr '12

28 Apr '12

====================================== #fedora-meeting: Fedora Kernel meeting ====================================== Meeting started by jwb at 17:59:30 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting/2012-04-27/fedora-kernel.20… . Meeting summary --------------- * init (jwb, 18:00:06) * rawhide (jwb, 18:02:51) * Rawhide is at 3.4-rc4-git3. RCs are coming fairly regularly (jwb, 18:08:17) * F17 (jwb, 18:09:37) * F17 at 3.3.2. 3.3.4 being built for TC2 (jwb, 18:12:29) * F16 (jwb, 18:13:56) * F16 is on 3.3.2. 3.3.4 will be built and submitted to updates-testing (jwb, 18:15:01) * LINK: http://codemonkey.org.uk/2012/04/27/weekly-fedora-kernel-bug-statistics-apr… weekly bug statistics (jwb, 18:19:33) * Progress on F16 bug count is being made. This also helps F15/F17 by either closing out duplicates or preventing those bugs from being hit there as all 3 releases are on the same kernel version (jwb, 18:20:17) * F15 (jwb, 18:47:05) * F15 is at 2.6.43.2 (3.3.2) (jwb, 18:48:25) * open floor (jwb, 18:49:29) * open floor - darkserver (jwb, 18:50:06) * ACTION: jwb to open bug against darkserver for additional build time issue (jwb, 18:52:35) * open floor (jwb, 18:53:39) Meeting ended at 19:00:33 UTC. Action Items ------------ * jwb to open bug against darkserver for additional build time issue Action Items, by person ----------------------- * jwb * jwb to open bug against darkserver for additional build time issue * **UNASSIGNED** * (none) People Present (lines said) --------------------------- * jwb (117) * VICODAN_ (63) * jforbes (31) * davej (21) * nirik (14) * dgilmore (8) * linville (6) * zodbot (3) * misc (2) * brunowolff (2) * jsmith (1) Generated by `MeetBot`_ 0.1.4 .. _`MeetBot`: http://wiki.debian.org/MeetBot

1 0

CCISS Support in FC16
by James Schatzman 25 Apr '12

25 Apr '12

Apparently I got my wires crossed slightly. The results when booting 3.1.0 and 3.3.2 are different. So... I followed the instructions on fedoraproject.org, modifying the kernel command line options to get debugging output. 3.3.2 - console output -------------------------------------------------------------- ... [see attachment] Write protecting the kernel text: 5456k Write protecting the kernel read-only data: 2124k NX-protecting the kernel data: 4784K init[1] general protection ip:b771a419 sp:bffccc5c error:0 Kernel panic - not syncing: Attempting to kill init! ---------------------------------------------------------------------- At this point the system is locked up and there does not appear to be any way to retrieve any init.log file. See the attachment for a screen dump of the final bits of the console output. Because this computer is located remotely I don't have any way to access more output than that. 3.1.0 console output ----------------------------------------------------- ....[lots of output] dmesg | grep dracut >>> very many screenshots [ I have no way to save the output to a file] The last 7 screens of this dmesg output are attached. From the emergency shell, the output of dmsetup ls --tree --> No devices found blkid --> no output blkid -c udev --> no output 2.6 Boot --------------------------------------------------- Boots normally. Some data: dmsetup ls --tree VolGroup00-LogVol01 (253:1) ââ (104:2) VolGroup00-LogVol00 (253:0) ââ (104:2) blkid /dev/cciss/c0d0p1: LABEL="/boot" UUID="c051ed89-7747-4756-bb8e-6f15ccfead88" SEC_TYPE="ext2" TYPE="ext3" /dev/dm-0: UUID="8af89900-0449-40e8-952a-75b8ffa7a693" SEC_TYPE="ext2" TYPE="ext3" /dev/dm-1: TYPE="swap" /dev/cciss/c0d1p5: LABEL="/data1" UUID="c082e209-e3d9-4515-9327-e78fb434088a" SEC_TYPE="ext2" TYPE="ext3" /dev/cciss/c0d1p6: LABEL="/data2" UUID="3882e8f8-817e-4a6a-ae36-febcabddfcd4" SEC_TYPE="ext2" TYPE="ext3" /dev/cciss/c0d2: LABEL="data2" UUID="57fe361b-0d73-4cc9-9592-cfc7c8fad00d" SEC_TYPE="ext2" TYPE="ext3" /dev/cciss/c0d2p5: LABEL="/data3" UUID="5f079cb2-a086-4700-9b87-5d57e706dca8" SEC_TYPE="ext2" TYPE="ext3" /dev/cciss/c0d2p6: LABEL="/data4" UUID="cfcf37a2-f2ff-4ff5-98c7-d4fcd40e7418" SEC_TYPE="ext2" TYPE="ext3" /dev/VolGroup00/LogVol00: UUID="8af89900-0449-40e8-952a-75b8ffa7a693" SEC_TYPE="ext2" TYPE="ext3" /dev/VolGroup00/LogVol01: TYPE="swap" /dev/mapper/VolGroup00-LogVol01: TYPE="swap" /dev/mapper/VolGroup00-LogVol00: UUID="8af89900-0449-40e8-952a-75b8ffa7a693" SEC_TYPE="ext2" TYPE="ext3" /dev/cciss/c0d0p2: UUID="IC0t0N-WiTL-UQ7d-IsRD-w5Hz-91Pv-Big08T" TYPE="LVM2_member" blkid -c udev /dev/cciss/c0d0p1: LABEL="/boot" UUID="c051ed89-7747-4756-bb8e-6f15ccfead88" TYPE="ext3" /dev/cciss/c0d0p2: UUID="IC0t0N-WiTL-UQ7d-IsRD-w5Hz-91Pv-Big08T" TYPE="LVM2_member" /dev/cciss/c0d1p5: LABEL="/data1" UUID="c082e209-e3d9-4515-9327-e78fb434088a" TYPE="ext3" /dev/cciss/c0d1p6: LABEL="/data2" UUID="3882e8f8-817e-4a6a-ae36-febcabddfcd4" TYPE="ext3" /dev/cciss/c0d2: LABEL="data2" UUID="57fe361b-0d73-4cc9-9592-cfc7c8fad00d" SEC_TYPE="ext2" TYPE="ext3" /dev/cciss/c0d2p5: LABEL="/data3" UUID="5f079cb2-a086-4700-9b87-5d57e706dca8" TYPE="ext3" /dev/cciss/c0d2p6: LABEL="/data4" UUID="cfcf37a2-f2ff-4ff5-98c7-d4fcd40e7418" TYPE="ext3" /dev/mapper/VolGroup00-LogVol00: UUID="8af89900-0449-40e8-952a-75b8ffa7a693" TYPE="ext3" /dev/mapper/VolGroup00-LogVol01: TYPE="swap" more /etc/fstab /dev/VolGroup00/LogVol00 / ext3 defaults 1 1 LABEL=/boot /boot ext3 defaults 1 2 none /dev/pts devpts gid=5,mode=620 0 0 none /dev/shm tmpfs defaults 0 0 none /proc proc defaults 0 0 none /sys sysfs defaults 0 0 /dev/VolGroup00/LogVol01 swap swap defaults 0 0 LABEL=/data1 /d0 ext3 rw,acl 1 2 LABEL=/data2 /d1 ext3 defaults 1 2 LABEL=/data3 /d2 ext3 defaults 1 2 LABEL=/data4 /d3 ext3 defaults 1 2 Thanks! Jim

1 0

CCISS Support in FC16
by James Schatzman 25 Apr '12

25 Apr '12

Can anyone tell me what kernel versions have support restored for CCISS SCSI controllers? After upgrading to FC16 with yum, my DL380 G4 no longer boots under either 3.1.0-7.fc16.i686 or 3.3.2-1-fc16.PAE kernels. Under the 3.1.0 kernel, dracut at least reports "dracut Warning: No root device /dev/VolGroup00/LogVol00 found". The 3.3.2 kernel reports only "Kernel panic - not syncing: Attempted to kill init!" which does not seem to be very informative to the non-kernel expert. Re-running "dracut -f" to rebuild the initramfs for either kernel does not help. No change in the behaviro is observed. II have seen bug report rhbz #754907 which may possibly be the same problem. This supposedly has been fixed but in what kernels? Thanks! Jim

2 1

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

kernel April 2012