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, 6 months
[PATCHSET] utrace for 3.1 kernel
by Oleg Nesterov
Hello.
utrace patches for 3.1 kernel. Untested, will try to do some tests
tomorrow.
I do not want to spam you all and the lists, please look at
git://git.kernel.org/pub/scm/linux/kernel/git/oleg/misc.git utrace-3.1
Oleg Nesterov (29):
utrace: add utrace_init_task/utrace_free_task calls
tracehooks: add utrace hooks
tracehooks: reintroduce tracehook_consider_fatal_signal()
add utrace hooks into sig_ignored() and recalc_sigpending()
restore the EXEC/EXIT/CLONE utrace hooks
utrace: utrace_report_death() can use task_utrace_struct()
restore the DEATH/REAP utrace hooks
utrace: remove jobctl bits
ptrace: take ->siglock around s/TRACED/RUNNING/
introduce wake_up_quiescent()
introduce ptrace_signal_wake_up()
wait_task_inactive: treat task->state and match_state as bitmasks
introduce TASK_UTRACED state
utrace: use TASK_UTRACED instead of TASK_TRACED
reintroduce tracehook_finish_jctl() as utrace_end_stop()
teach wake_up_quiescent() to do "selective" wake_up
ptrace_stop: do not assume the task is running after wake_up_quiescent()
get_signal_to_deliver: restore/restructure utrace/ptrace signal reporting
utrace_get_signal: s/JOBCTL_STOP_PENDING/JOBCTL_PENDING_MASK/
introduce ptrace_set_syscall_trace()
introduce PT_SYSCALL_TRACE flag
utrace: don't clear TIF_SYSCALL_TRACE if it is needed by ptrace
introduce task_utrace_lock/task_utrace_unlock
teach ptrace_set_syscall_trace() to play well with utrace
introduce PT_SINGLE_STEP and PT_SINGLE_BLOCK
utrace: finish_resume_report: don't do user_xxx_step() if ptrace_wants_step()
ptrace: shift user_*_step() from ptrace_resume() to ptrace_stop()
ptrace_disable: no need to disable stepping
ptrace_report_syscall: check TIF_SYSCALL_EMU
Roland McGrath (1):
utrace core
Documentation/DocBook/Makefile | 2 +-
Documentation/DocBook/utrace.tmpl | 589 +++++++++
arch/s390/kernel/traps.c | 4 +-
arch/x86/kernel/ptrace.c | 1 -
fs/exec.c | 5 +-
fs/proc/array.c | 14 +-
include/linux/ptrace.h | 7 +
include/linux/sched.h | 25 +-
include/linux/signal.h | 2 +
include/linux/tracehook.h | 53 +-
include/linux/utrace.h | 773 ++++++++++++
init/Kconfig | 9 +
kernel/Makefile | 1 +
kernel/exit.c | 5 +
kernel/fork.c | 9 +
kernel/ptrace.c | 57 +-
kernel/sched.c | 2 +-
kernel/signal.c | 97 ++-
kernel/utrace.c | 2461 +++++++++++++++++++++++++++++++++++++
19 files changed, 4062 insertions(+), 54 deletions(-)
create mode 100644 Documentation/DocBook/utrace.tmpl
create mode 100644 include/linux/utrace.h
create mode 100644 kernel/utrace.c
11 years, 10 months
Proposal to add build of kernel-backports package to kernel.spec
by John W. Linville
So, I have a little proposal for the Fedora kernel SRPM...
TL;DR -- I want to create a kernel-backports package that includes the
output of building compat-wireless against the corresponding kernel. A
version of this package will automatically be built for every kernel
RPM built.
Why?
Hardware enablement is an endless treadmill. As Fedora has matured,
the delta between current Fedora kernels and current upstream kernels
has tended to widen (at least for older releases e.g. F14). This can
cause problems both for users needing cutting-edge hardware support
and for developers trying to diagnose problems in Fedora kernels that
may have already been fixed upstream.
Creating a seperate package allows both of the above situations to
be addressed while allowing "normal" users to use the base kernel
without unnecessary risk of destabilization. Integrating the build
of that package with the kernel build ensures that every new kernel
automatically has a kernel-backports package built without need of
human intervention or creative scripting.
How does this proposal look?
I have a scratch F14 kernel build available here:
http://koji.fedoraproject.org/koji/taskinfo?taskID=3404605
You will also need an updated module-init-tools package:
http://koji.fedoraproject.org/koji/taskinfo?taskID=3404725
When you install the kernel-backports package, modinfo for an affected
driver (e.g. iwlagn) will show that the driver chosen by depmod will
change. Removing kernel-backports will point you back to the version
from the base kernel.
What is in the kernel-backports package?
At present, a stable release of the compat-wireless project would be
included in the kernel-backports package:
http://www.linuxwireless.org/en/users/Download
The compat-wireless project contains backports of sources from current
upstream kernels. These are not out-of-tree drivers in the traditional
sense. These drivers are in-tree -- just a later version of the tree.
As such, the compat-wireless sources follow the same license as the
upstream Linux kernel (i.e. GPLv2).
The compat-* project is expected/intended to expand to include wired
networking drivers and more in the future. As that happens, those new
compat-* drivers will be included in the kernel-backports package as
well.
Isn't this just a big kmod package?
No, or at least not exactly. Existing kmod package standards require a
separate kmod build for every kernel build. Most (or all?) of them
require complex versioning to distinquish between versions of the kmod
package and versions of the target kernel. They are a nightmare to
maintain. Worse, they require multiple kmod packages for multiple drivers,
multiplying the maintenance burden.
This proposal minimizes the maintenance required while maximizing the
coverage of driver upates. A single compat-wireless package update will
suffice to update a full suite of drivers all at once.
Isn't this too "bleeding edge" for non-rawhide Fedora?
Perhaps so, at least for many people. That is the advantage of having a
separate kernel-backports package. Those that don't want to use the
cutting-edge hardware support will simply not install the package.
Those who want or need that support will have it easily available.
Why not just use Rawhide?
Rawhide might have even more "bleeding" edge hardware support than the
kernel-backports package would get. Plus, Rawhide kernels will have
less mature core kernel changes as well. Keeping a stable release
kernel with a kernel-backports package offers an intermediate step
towards cutting-edge hardware support while maintaining a stable core
kernel.
Who will maintain it?
For now, I will. When I am old and gone, my successor will only have
to update the compat-wireless bits once per upstream kernel release
and perhaps add a few Fedora-specific compat-wireless patches as
things are backported to the Fedora base kernel that conflict with
the compat layer in compat-wireless.
Can we turn it off easily?
Yes. The spec file changes are all bracketed by a "with_backports"
symbol already. In fact, with_backports will have to be turned-off
in Rawhide and in any other Fedora releases where the kernel version
is the same or newer than the latest compat-wireless stable release.
What do the changes look like?
I'll paste the kernel.spec file changes for F14 below. I'll attach the
required module-init-tools.spec file patch to this email for reference
as well.
Conclusion
So, there is my proposal. What are the objections?
Once any major objections are addressed, I'll pursue any required Fedora
project management items required (e.g. a Feature page).
John
---
diff --git a/kernel.spec b/kernel.spec
index cc12bce..b96c348 100644
--- a/kernel.spec
+++ b/kernel.spec
@@ -25,6 +25,7 @@ Summary: The Linux kernel
#
# % define buildid .local
###################################################################
+%define buildid .1.compat
# The buildid can also be specified on the rpmbuild command line
# by adding --define="buildid .whatever". If both the specfile and
@@ -147,6 +148,10 @@ Summary: The Linux kernel
# should we do C=1 builds with sparse
%define with_sparse %{?_with_sparse: 1} %{?!_with_sparse: 0}
+# Include driver backports (e.g. compat-wireless) in the kernel build.
+# This builds a separate kernel-backports package.
+%define with_backports %{?_with_backports: 1} %{?!_with_backports: 0}
+
# Set debugbuildsenabled to 1 for production (build separate debug kernels)
# and 0 for rawhide (all kernels are debug kernels).
# See also 'make debug' and 'make release'.
@@ -531,6 +536,9 @@ BuildRequires: rpm-build >= 4.4.2.1-4
%endif
Source0: ftp://ftp.kernel.org/pub/linux/kernel/v2.6/linux-%{kversion}.tar.bz2
+%if %{with_backports}
+Source1: compat-wireless-3.0-2.tar.bz2
+%endif
Source11: genkey
Source14: find-provides
@@ -864,6 +872,10 @@ Patch14050: x86-PCI-don-t-use-native-Broadcom-CNB20LE-driver-whe.patch
# RHBZ #648571
Patch14051: modules-Fix-module_bug_list-list-corruption-race.patch
+%if %{with_backports}
+Patch20000: compat-wireless-vzalloc.patch
+%endif
+
%endif
BuildRoot: %{_tmppath}/kernel-%{KVERREL}-root
@@ -1042,6 +1054,37 @@ It should only be installed when trying to gather additional information
on kernel bugs, as some of these options impact performance noticably.
+%if %{with_backports}
+
+#
+# This macro creates a kernel-backports-<subpackage>.
+# %%kernel_variant_backports_package <condition> <subpackage>
+#
+%define kernel_variant_backports_package() \
+%if %{1}\
+%package %{?2:%{2}-}backports\
+Summary: Drivers backported from later versions of the Linux kernel\
+Group: System Environment/Kernel\
+License: GPLv2\
+Requires: kernel = %{rpmversion}-%{pkg_release}\
+Requires(post): module-init-tools >= 3.11.1-6.1.compat\
+%description %{?2:%{2}-}backports\
+This package provies pre-compiled drivers backported from later versions\
+of the Linux kernel. This package contains drivers from the upstream\
+Linux kernel exclusively. Out-of-tree drivers are not provided.\
+This version matches the kernel%{?2:-%{2}} package.\
+%{nil}\
+%endif
+
+%kernel_variant_backports_package %{with_up}
+%kernel_variant_backports_package %{with_smp} smp
+%kernel_variant_backports_package %{with_debug} debug
+%kernel_variant_backports_package %{with_pae} PAE
+%kernel_variant_backports_package %{with_pae_debug} PAEdebug
+
+%endif
+
+
%prep
# do a few sanity-checks for --with *only builds
%if %{with_baseonly}
@@ -1670,6 +1713,16 @@ find . \( -name "*.orig" -o -name "*~" \) -exec rm -f {} \; >/dev/null
cd ..
+%if %{with_backports}
+
+# Extract the compat-wireless bits
+%setup -q -n kernel-%{kversion}%{?dist} -T -D -a 1
+
+cd compat-wireless-3.0-2
+%patch20000 -p1
+
+%endif
+
###
### build
###
@@ -1787,6 +1840,9 @@ BuildKernel() {
# dirs for additional modules per module-init-tools, kbuild/modules.txt
mkdir -p $RPM_BUILD_ROOT/lib/modules/$KernelVer/extra
mkdir -p $RPM_BUILD_ROOT/lib/modules/$KernelVer/updates
+%if %{with_backports}
+ mkdir -p $RPM_BUILD_ROOT/lib/modules/$KernelVer/backports
+%endif
# first copy everything
cp --parents `find -type f -name "Makefile*" -o -name "Kconfig*"` $RPM_BUILD_ROOT/lib/modules/$KernelVer/build
cp Module.symvers $RPM_BUILD_ROOT/lib/modules/$KernelVer/build
@@ -1886,6 +1942,23 @@ BuildKernel() {
mkdir -p $RPM_BUILD_ROOT/usr/src/kernels
mv $RPM_BUILD_ROOT/lib/modules/$KernelVer/build $RPM_BUILD_ROOT/$DevelDir
ln -sf ../../..$DevelDir $RPM_BUILD_ROOT/lib/modules/$KernelVer/build
+
+%if %{with_backports}
+
+ cd ../compat-wireless-3.0-2/
+ make clean
+
+ make KLIB_BUILD=../linux-%{kversion}.%{_target_cpu} \
+ KMODPATH_ARG="INSTALL_MOD_PATH=$RPM_BUILD_ROOT" \
+ KMODDIR="backports" install-modules
+
+ # mark modules executable so that strip-to-file can strip them
+ find $RPM_BUILD_ROOT/lib/modules/$KernelVer/backports -name "*.ko" \
+ -type f | xargs --no-run-if-empty chmod u+x
+
+ cd -
+
+%endif
}
###
@@ -2103,6 +2176,54 @@ fi}\
%kernel_variant_post -v PAEdebug -r (kernel|kernel-smp)
%kernel_variant_preun PAEdebug
+%if %{with_backports}
+
+#
+# This macro defines a depmod operation for install/remove of backports.
+# %%kernel_variant_backports_depmod [-v <subpackage>]
+#
+%define kernel_variant_backports_depmod(v:) \
+%{expand:\
+/sbin/depmod -ae -F /boot/System.map-%{KVERREL}%{?-v:.%{-v*}} || exit $?\
+}\
+%{nil}
+
+#
+# This macro defines a %%post script for a kernel backports package.
+# %%kernel_variant_backports_post <condition> <subpackage>
+#
+%define kernel_variant_backports_post() \
+%if %{1}\
+%{expand:%%post %{?2:%{2}-}backports}\
+%{expand:%%kernel_variant_backports_depmod %{?2:-v %{2}}}\
+%endif\
+%{nil}
+
+#
+# This macro defines a %%postun script for a kernel backports package.
+# %%kernel_variant_backports_postun <condition> <subpackage>
+#
+%define kernel_variant_backports_postun() \
+%if %{1}\
+%{expand:%%postun %{?2:%{2}-}backports}\
+%{expand:%%kernel_variant_backports_depmod %{?2:-v %{2}}}\
+%endif\
+%{nil}
+
+%kernel_variant_backports_post %{with_up}
+%kernel_variant_backports_post %{with_smp} smp
+%kernel_variant_backports_post %{with_debug} debug
+%kernel_variant_backports_post %{with_pae} PAE
+%kernel_variant_backports_post %{with_pae_debug} PAEdebug
+
+%kernel_variant_backports_postun %{with_up}
+%kernel_variant_backports_postun %{with_smp} smp
+%kernel_variant_backports_postun %{with_debug} debug
+%kernel_variant_backports_postun %{with_pae} PAE
+%kernel_variant_backports_postun %{with_pae_debug} PAEdebug
+
+%endif
+
if [ -x /sbin/ldconfig ]
then
/sbin/ldconfig -X || exit $?
@@ -2209,10 +2330,39 @@ fi
%kernel_variant_files %{with_pae} PAE
%kernel_variant_files %{with_pae_debug} PAEdebug
+
+%if %{with_backports}
+
+#
+# This macro defines the %%files sections for a kernel-backports
+# package.
+# %%kernel_variant_backports_files <condition> <subpackage>
+#
+%define kernel_variant_backports_files() \
+%if %{1}\
+%{expand:%%files %{?2:%{2}-}backports}\
+%defattr(-,root,root)\
+/lib/modules/%{KVERREL}%{?2:.%{2}}/backports\
+%endif\
+%{nil}
+
+%kernel_variant_backports_files %{with_up}
+%kernel_variant_backports_files %{with_smp} smp
+%kernel_variant_backports_files %{with_debug} debug
+%kernel_variant_backports_files %{with_pae} PAE
+%kernel_variant_backports_files %{with_pae_debug} PAEdebug
+
+%endif
+
+
# plz don't put in a version string unless you're going to tag
# and build.
%changelog
+* Tue Oct 4 2011 John W. Linville <linville(a)redhat.com>
+- Add infrastructure for kernel-backports package
+- Include compat-wireless project in package above
+
* Mon Sep 12 2011 Josh Boyer <jwboyer(a)redhat.com>
- Backport 5336377d to fix RHBZ #648571
--
John W. Linville The water won't run clean until you get
linville(a)redhat.com the pigs out of the creek.
12 years
Re: Kernel-3.1 Crash
by Antonio Trande
>do you have multipath configured on your box?
If i have understand the 'multipath concept', yes. fdisk
output<http://www.fpaste.org/KXvm/>
>How often can you reproduce this problem.
Only with Kernel 3.1.
If fsck is enabled on / partition (btrfs filesystem) also with Kernel 3.0
2011/10/27 Vivek Goyal <vgoyal(a)redhat.com>
> On Thu, Oct 27, 2011 at 09:31:13PM +0200, Antonio Trande wrote:
> > Should i be the "victim" ? :)
> > If need tests, i'm available.
>
> do you have multipath configured on your box? How often can you reproduce
> this problem. Can you reproduce the problem with single cpu in the
> system.
>
> Thanks
> Vivek
>
> >
> > 2011/10/27 Vivek Goyal <vgoyal(a)redhat.com>
> >
> > > On Thu, Oct 27, 2011 at 03:20:51PM -0400, Jeff Moyer wrote:
> > > > Don Zickus <dzickus(a)redhat.com> writes:
> > > >
> > > > > On Thu, Oct 27, 2011 at 02:43:22PM -0400, Jeff Moyer wrote:
> > > > >> >> This doesn't look like the same problem. Here we've got BUG:
> > > scheduling
> > > > >> >> while atomic. If it was the bug fixed by the above commits,
> then
> > > you
> > > > >> >> would hit a BUG_ON. I would start looking at the btrfs bits to
> see
> > > if
> > > > >> >> they're holding any locks in this code path.
> > > > >> >
> > > > >> > Ignore that one and move to IMG_0350.IMG. 'scheduling while
> atomic'
> > > is
> > > > >> > just noise. Besides Mike and Vivek told me to blame you for not
> > > pushing
> > > > >> > Jens harder on these fixes. :-)))))
> > > > >>
> > > > >> I'm looking at 0355, which shows the very top of the trace, and
> that
> > > > >> says BUG: scheduling while atomic. So the problem reported here
> *is*
> > > > >> different from the one fixed by the above two commits. In fact, I
> > > don't
> > > > >> see evidence of the multipath + flush issue in any of these
> pictures.
> > > > >
> > > > > You have to ignore the 'schedule while atomic' thing it is just a
> > > > >
> > > > > printk("BUG: scheduling while atomic"), it is _not_ a BUG(). :-)
> > > > > (hint read kernel/sched.c::__schedule_bug)
> > > > >
> > > > > I see those messages all the time, it really should be a WARN and
> not a
> > > > > misleading BUG, but whatever.
> > > > >
> > > > > His machine died because the NMI watchdog detected a lockup. The
> > > lockup
> > > > > was because in blk_insert_cloned_request(), spin_lock_irqsave
> disabled
> > > > > interrupts and spun forever waiting on the q->queue_lock
> > > (IMG_0350.JPG).
> > > > >
> > > > > Mike and Vivek both said that is what you fixed for 3.2. They also
> > > said
> > > > > the only caller of blk_insert_cloned_request() is multipath, hence
> that
> > > > > argument. I'll cc them. Or maybe I can have them walk over to
> your
> > > cube.
> > > > > :-)
> > > >
> > > > Well then they know more than I do. The bug I fixed would not result
> in
> > > > infinite spinning on the queue lock. It resulted in a BUG_ON in
> > > > blk_insert_flush, since req->bio was NULL. So again, I really don't
> see
> > > > how this is related. We could put this all to rest by asking the
> victim
> > > > to try out those two patches.
> > >
> > > Sorry for the confusion here. We saw the blk_insert_cloned_request() in
> > > the trace and thought it could be related to your fixes. Did not think
> > > about exact symtom of the problem in your case. So you are right. Here
> > > we are spinning on spinlock infinitely and your patch fixed the
> BUG_ON().
> > > So may be it is a different issue.
> > >
> > > Thanks
> > > Vivek
> > >
> >
> >
> >
> > --
> > *Antonio Trande
> > "Fedora Ambassador"
> >
> > **mail*: mailto:sagitter@fedoraproject.org <sagitter(a)fedoraproject.org>
> > *Homepage*: http://www.fedora-os.org
> > *Sip Address* : sip:sagitter AT ekiga.net
> > *Jabber <http://jabber.org/>* :sagitter AT jabber.org
> > *GPG Key: CFE3479C*
>
--
*Antonio Trande
"Fedora Ambassador"
**mail*: mailto:sagitter@fedoraproject.org <sagitter(a)fedoraproject.org>
*Homepage*: http://www.fedora-os.org
*Sip Address* : sip:sagitter AT ekiga.net
*Jabber <http://jabber.org/>* :sagitter AT jabber.org
*GPG Key: CFE3479C*
12 years, 1 month
monthly irc meeting.
by Dave Jones
We've been having monthly team meetings for a few months, and have decided that
some of the material we end up discussing should really be shared with
a wider audience. Here are the minutes from this months meeting for example,
that Chuck captured: http://fpaste.org/3LYS/
So as noted at https://fedoraproject.org/wiki/Meeting_channel, we're going to try
a monthly one hour meeting at 1800UTC the 2nd Friday of every month in #fedora-meeting.
No fixed agenda to begin with, let's see where it goes.
Dave
12 years, 1 month
Re: Kernel-3.1 Crash
by Antonio Trande
The digital picture are here:
http://sagitter.fedorapeople.org/kernel-boot.tar.gz
2011/10/27 Don Zickus <dzickus(a)redhat.com>
> On Thu, Oct 27, 2011 at 04:56:27PM +0200, Antonio Trande wrote:
> > Ok. I've made a video [1].
> >
> > [1] <http://sagitter.fedorapeople.org/MOV03009.AVI>
>
> The video is to fuzzy and moving around to much for me to see the pieces I
> need to see. It is easier to take a picture (2 or 3 probably). Also
> make sure you cc the fedora list as someone there might be able to notice
> something and help out.
>
> Cheers,
> Don
>
> >
> > 2011/10/27 Don Zickus <dzickus(a)redhat.com>
> >
> > > On Thu, Oct 27, 2011 at 01:50:17PM +0200, Antonio Trande wrote:
> > > > Hello.
> > > >
> > > > After to have installed the lastest kernel (3.1-0-1) on my Fedora 16
> > > > x86_64bit, i get a kernel crash during boot.
> > > > Now the main problem is how to recover 'boot log' or 'messages log'
> in
> > > order
> > > > to ask help because it isnt created.
> > >
> > > Can you take a digital picture? Attaching that here will work (don't
> make
> > > the size very large). Or if your machine has a serial console, you can
> > > hook it up to another machine and run minicom to collect the output
> (after
> > > configuring the serial console on the grub command line, I need to dig
> up
> > > a documentation link to assist).
> > >
> > > Cheers,
> > > Don
> > >
> >
> >
> >
> > --
> > *Antonio Trande
> > "Fedora Ambassador"
> >
> > **mail*: mailto:sagitter@fedoraproject.org <sagitter(a)fedoraproject.org>
> > *Homepage*: http://www.fedora-os.org
> > *Sip Address* : sip:sagitter AT ekiga.net
> > *Jabber <http://jabber.org/>* :sagitter AT jabber.org
> > *GPG Key: CFE3479C*
>
--
*Antonio Trande
"Fedora Ambassador"
**mail*: mailto:sagitter@fedoraproject.org <sagitter(a)fedoraproject.org>
*Homepage*: http://www.fedora-os.org
*Sip Address* : sip:sagitter AT ekiga.net
*Jabber <http://jabber.org/>* :sagitter AT jabber.org
*GPG Key: CFE3479C*
12 years, 1 month
Fwd: Kernel-3.1 Crash
by Antonio Trande
---------- Forwarded message ----------
From: Antonio Trande <anto.trande(a)gmail.com>
Date: 2011/10/27
Subject: Re: Kernel-3.1 Crash
To: Vivek Goyal <vgoyal(a)redhat.com>
Should i be the "victim" ? :)
If need tests, i'm available.
2011/10/27 Vivek Goyal <vgoyal(a)redhat.com>
> On Thu, Oct 27, 2011 at 03:20:51PM -0400, Jeff Moyer wrote:
> > Don Zickus <dzickus(a)redhat.com> writes:
> >
> > > On Thu, Oct 27, 2011 at 02:43:22PM -0400, Jeff Moyer wrote:
> > >> >> This doesn't look like the same problem. Here we've got BUG:
> scheduling
> > >> >> while atomic. If it was the bug fixed by the above commits, then
> you
> > >> >> would hit a BUG_ON. I would start looking at the btrfs bits to see
> if
> > >> >> they're holding any locks in this code path.
> > >> >
> > >> > Ignore that one and move to IMG_0350.IMG. 'scheduling while atomic'
> is
> > >> > just noise. Besides Mike and Vivek told me to blame you for not
> pushing
> > >> > Jens harder on these fixes. :-)))))
> > >>
> > >> I'm looking at 0355, which shows the very top of the trace, and that
> > >> says BUG: scheduling while atomic. So the problem reported here *is*
> > >> different from the one fixed by the above two commits. In fact, I
> don't
> > >> see evidence of the multipath + flush issue in any of these pictures.
> > >
> > > You have to ignore the 'schedule while atomic' thing it is just a
> > >
> > > printk("BUG: scheduling while atomic"), it is _not_ a BUG(). :-)
> > > (hint read kernel/sched.c::__schedule_bug)
> > >
> > > I see those messages all the time, it really should be a WARN and not a
> > > misleading BUG, but whatever.
> > >
> > > His machine died because the NMI watchdog detected a lockup. The
> lockup
> > > was because in blk_insert_cloned_request(), spin_lock_irqsave disabled
> > > interrupts and spun forever waiting on the q->queue_lock
> (IMG_0350.JPG).
> > >
> > > Mike and Vivek both said that is what you fixed for 3.2. They also
> said
> > > the only caller of blk_insert_cloned_request() is multipath, hence that
> > > argument. I'll cc them. Or maybe I can have them walk over to your
> cube.
> > > :-)
> >
> > Well then they know more than I do. The bug I fixed would not result in
> > infinite spinning on the queue lock. It resulted in a BUG_ON in
> > blk_insert_flush, since req->bio was NULL. So again, I really don't see
> > how this is related. We could put this all to rest by asking the victim
> > to try out those two patches.
>
> Sorry for the confusion here. We saw the blk_insert_cloned_request() in
> the trace and thought it could be related to your fixes. Did not think
> about exact symtom of the problem in your case. So you are right. Here
> we are spinning on spinlock infinitely and your patch fixed the BUG_ON().
> So may be it is a different issue.
>
> Thanks
> Vivek
>
--
*Antonio Trande
"Fedora Ambassador"
**mail*: mailto:sagitter@fedoraproject.org <sagitter(a)fedoraproject.org>
*Homepage*: http://www.fedora-os.org
*Sip Address* : sip:sagitter AT ekiga.net
*Jabber <http://jabber.org/>* :sagitter AT jabber.org
*GPG Key: CFE3479C*
--
*Antonio Trande
"Fedora Ambassador"
**mail*: mailto:sagitter@fedoraproject.org <sagitter(a)fedoraproject.org>
*Homepage*: http://www.fedora-os.org
*Sip Address* : sip:sagitter AT ekiga.net
*Jabber <http://jabber.org/>* :sagitter AT jabber.org
*GPG Key: CFE3479C*
12 years, 1 month
Fwd: Kernel-3.1 Crash
by Antonio Trande
Ok. I've made a video [1].
[1] <http://sagitter.fedorapeople.org/MOV03009.AVI>
2011/10/27 Don Zickus <dzickus(a)redhat.com>
> On Thu, Oct 27, 2011 at 01:50:17PM +0200, Antonio Trande wrote:
> > Hello.
> >
> > After to have installed the lastest kernel (3.1-0-1) on my Fedora 16
> > x86_64bit, i get a kernel crash during boot.
> > Now the main problem is how to recover 'boot log' or 'messages log' in
> order
> > to ask help because it isnt created.
>
> Can you take a digital picture? Attaching that here will work (don't make
> the size very large). Or if your machine has a serial console, you can
> hook it up to another machine and run minicom to collect the output (after
> configuring the serial console on the grub command line, I need to dig up
> a documentation link to assist).
>
> Cheers,
> Don
>
--
*Antonio Trande
"Fedora Ambassador"
**mail*: mailto:sagitter@fedoraproject.org <sagitter(a)fedoraproject.org>
*Homepage*: http://www.fedora-os.org
*Sip Address* : sip:sagitter AT ekiga.net
*Jabber <http://jabber.org/>* :sagitter AT jabber.org
*GPG Key: CFE3479C*
--
*Antonio Trande
*
12 years, 1 month
Kernel-3.1 Crash
by Antonio Trande
Hello.
After to have installed the lastest kernel (3.1-0-1) on my Fedora 16
x86_64bit, i get a kernel crash during boot.
Now the main problem is how to recover 'boot log' or 'messages log' in order
to ask help because it isnt created.
With kernel 3.0-1-3 there is not problem.
Maybe the crash depends from btrfs filesystem.
Thanks.
--
*Antonio Trande
**
*
12 years, 1 month
[PATCH] Drop ia64
by Josh Boyer
There's been no work on ia64 in Fedora since roughly Fedora 9, we never build
it, and it's not making a comeback.
---
Makefile.config | 11 +--
config-ia64-generic | 205 ---------------------------------------------------
kernel.spec | 11 +---
3 files changed, 3 insertions(+), 224 deletions(-)
delete mode 100644 config-ia64-generic
diff --git a/Makefile.config b/Makefile.config
index ccb035d..df66aad 100644
--- a/Makefile.config
+++ b/Makefile.config
@@ -14,10 +14,9 @@ CONFIGFILES = \
$(CFG)-armv7hl-omap.config $(CFG)-armv7hl-tegra.config \
$(CFG)-ppc.config $(CFG)-ppc-smp.config \
$(CFG)-sparc64.config \
- $(CFG)-ppc64.config $(CFG)-ppc64-debug.config \
- $(CFG)-ia64.config
+ $(CFG)-ppc64.config $(CFG)-ppc64-debug.config
-PLATFORMS = x86 x86_64 powerpc powerpc32 powerpc64 s390x ia64 sparc64
+PLATFORMS = x86 x86_64 powerpc powerpc32 powerpc64 s390x sparc64
TEMPFILES = $(addprefix temp-, $(addsuffix -generic, $(PLATFORMS)))
configs: $(CONFIGFILES)
@@ -77,9 +76,6 @@ temp-powerpc32-generic: config-powerpc32-generic temp-powerpc-generic
temp-s390-generic: config-s390x temp-generic
perl merge.pl $^ > $@
-temp-ia64-generic: config-ia64-generic temp-generic
- perl merge.pl $^ > $@
-
kernel-$(VERSION)-i686-PAE.config: config-i686-PAE temp-x86-32-generic
perl merge.pl $^ i386 > $@
@@ -133,6 +129,3 @@ kernel-$(VERSION)-ppc.config: /dev/null temp-powerpc32-generic
kernel-$(VERSION)-ppc-smp.config: config-powerpc32-smp temp-powerpc32-generic
perl merge.pl $^ powerpc > $@
-
-kernel-$(VERSION)-ia64.config: /dev/null temp-ia64-generic
- perl merge.pl $^ ia64 > $@
diff --git a/config-ia64-generic b/config-ia64-generic
deleted file mode 100644
index f1fa705..0000000
diff --git a/kernel.spec b/kernel.spec
index 8bc0a74..36b02b9 100644
--- a/kernel.spec
+++ b/kernel.spec
@@ -374,13 +374,6 @@ Summary: The Linux kernel
%define kernel_image_elf 1
%endif
-%ifarch ia64
-%define all_arch_configs kernel-%{version}-ia64*.config
-%define image_install_path boot/efi/EFI/redhat
-%define make_target compressed
-%define kernel_image vmlinux.gz
-%endif
-
%ifarch alpha alphaev56
%define all_arch_configs kernel-%{version}-alpha*.config
%define image_install_path boot
@@ -509,7 +502,7 @@ Version: %{rpmversion}
Release: %{pkg_release}
# DO NOT CHANGE THE 'ExclusiveArch' LINE TO TEMPORARILY EXCLUDE AN ARCHITECTURE BUILD.
# SET %%nobuildarches (ABOVE) INSTEAD
-ExclusiveArch: noarch %{all_x86} x86_64 ppc ppc64 ia64 %{sparc} s390 s390x alpha alphaev56 %{arm}
+ExclusiveArch: noarch %{all_x86} x86_64 ppc ppc64 %{sparc} s390 s390x alpha alphaev56 %{arm}
ExclusiveOS: Linux
%kernel_reqprovconf
@@ -558,8 +551,6 @@ Source51: config-powerpc32-generic
Source52: config-powerpc32-smp
Source53: config-powerpc64
-Source60: config-ia64-generic
-
Source70: config-s390x
Source90: config-sparc64-generic
--
1.7.6.4
12 years, 1 month
