fedora 14 kernel performance with ip forwarding workload
by Jesse Brandeburg
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
8 years, 10 months
Regression testing
by Justin Forbes
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
11 years, 12 months
Fwd: [PATCH] ARM: Fix restoration of IP scratch register when auditing syscalls
by Jon Masters
-------- 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;
}
11 years, 12 months
CCISS Support in FC16?
by James Schatzman
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
11 years, 12 months
F15, F16 and F17 on the same kernel but with different patch sets?
by Joshua C.
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
12 years
Fwd: Fixing audit on ARM
by Jon Masters
-------- 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.
12 years
Fedora Kernel Meeting 04-27-2012 Minutes
by Josh Boyer
======================================
#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....
.
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-a...
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
12 years
CCISS Support in FC16
by James Schatzman
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
12 years
CCISS Support in FC16
by James Schatzman
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
12 years
