kernel October 2011

kernel@lists.fedoraproject.org

16 participants
18 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

[PATCHSET] utrace for 3.1 kernel
by Oleg Nesterov 07 Feb '12

07 Feb '12

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

4 39

Proposal to add build of kernel-backports package to kernel.spec
by John W. Linville 17 Nov '11

17 Nov '11

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.

6 18

Re: Kernel-3.1 Crash
by Antonio Trande 28 Oct '11

28 Oct '11

>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*

2 5

monthly irc meeting.
by Dave Jones 27 Oct '11

27 Oct '11

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

2 3

Re: Kernel-3.1 Crash
by Antonio Trande 27 Oct '11

27 Oct '11

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*

4 9

Fwd: Kernel-3.1 Crash
by Antonio Trande 27 Oct '11

27 Oct '11

---------- 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*

1 0

Fwd: Kernel-3.1 Crash
by Antonio Trande 27 Oct '11

27 Oct '11

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 *

1 0

Kernel-3.1 Crash
by Antonio Trande 27 Oct '11

27 Oct '11

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 ** *

2 1

[PATCH] Drop ia64
by Josh Boyer 27 Oct '11

27 Oct '11

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

4 3

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

kernel October 2011