abrt version: 2.0.5 cmdline: ro root=/dev/VolGroup00/systeme SYSFONT=latarcyrheb-sun16 LANG=fr_FR.UTF-8 KEYTABLE=fr-latin9 comment: on boot kernel: undefined reason: BUG: scheduling while atomic: swapper/0/0x10000002 time: Sat Jul 30 09:36:25 2011 backtrace: :BUG: scheduling while atomic: swapper/0/0x10000002 :no locks held by swapper/0. :Modules linked in: :Pid: 0, comm: swapper Not tainted 3.1.0-0.rc0.git11.2.fc17.x86_64 #1 :Call Trace: : [<ffffffff814e5e41>] __schedule_bug+0x75/0x7a : [<ffffffff814edc65>] schedule+0x95/0x7bb : [<ffffffff81076fe5>] ? kzalloc.constprop.3+0x29/0x2b : [<ffffffff81056e44>] __cond_resched+0x28/0x34 : [<ffffffff814ee5a3>] _cond_resched+0x19/0x22 : [<ffffffff8112d0e1>] slab_pre_alloc_hook+0x3b/0x54 : [<ffffffff8112f4fc>] kmem_cache_alloc_trace+0x29/0xca : [<ffffffff81076fe5>] kzalloc.constprop.3+0x29/0x2b : [<ffffffff81d66f5e>] pidmap_init+0x81/0xc0 : [<ffffffff81d4eb34>] start_kernel+0x372/0x409 : [<ffffffff81d4e2c4>] x86_64_start_reservations+0xaf/0xb3 : [<ffffffff81d4e140>] ? early_idt_handlers+0x140/0x140 : [<ffffffff81d4e3ca>] x86_64_start_kernel+0x102/0x111
Package: kernel Architecture: x86_64 OS Release: Fedora release 17 (Rawhide) Comment ----- on boot
Created attachment 515990 [details] dmesg with I I got hit by [ 0.001355] BUG: scheduling while atomic: swapper/0/0x10000002 [ 0.001472] no locks held by swapper/0. while booting 3.1.0-0.rc0.git12.1.fc17 kernel (switched to that one because with 3.1.0-0.rc0.git9.1.fc17 no disks were found and boot was going nowhere). That was followed by warnings about locking bugs, like in bug 537697, and a series of recursive faults (cf. bug 577968 and bug 716520). None of that was caught by abrt. The whole dmesg from a run which did not end in a total lockup is attached for a reference. See also bug 725332 bug here no virtio_net and no iscsi is involved.
Created attachment 516420 [details] another series of "scheduling while atomic" from 3.1.0-0.rc0.git12.1.fc17.x86_64 Here is a bunch of "scheduling while atomic: gdmlogin/1396/0x10000003" for a change but there is somewhat more to the story. This happened with the same kernel 3.1.0-0.rc0.git12.1.fc17.x86_64 and on the same installation as shown in dmesg from the previous attachment. On a freshly rebooted machine I was updating to the current rawhide while logged via ssh from another host. The following showed in a terminal window: ........ ---> Package iputils.x86_64 0:20101006-10.fc17 will be an update ---> Package kernel.x86_64 0:3.1.0-0.rc0.git15.1.fc17 will be installed ---> Package kernel-devel.x86_64 0:3.1.0-0.rc0.git15.1.fc17 will be installed Message from syslogd@localhost at Aug 2 16:23:29 ... kernel:[ 571.998008] Oops: 0010 [#1] SMP Message from syslogd@localhost at Aug 2 16:23:29 ... kernel:[ 571.998008] Stack: Message from syslogd@localhost at Aug 2 16:23:29 ... kernel:[ 571.998008] Call Trace: Message from syslogd@localhost at Aug 2 16:23:29 ... kernel:[ 571.998008] Code: Bad RIP value. Message from syslogd@localhost at Aug 2 16:23:29 ... kernel:[ 571.998008] CR2: ffffffff801503f4 ---> Package kernel-headers.x86_64 0:3.1.0-0.rc0.git12.1.fc17 will be updated ---> Package kernel-headers.x86_64 0:3.1.0-0.rc0.git15.1.fc17 will be an updated ........ As the test machine was making an impression that it was still working I tried in another terminal window to use 'dmesg' to check what happened. That succeeded but immediately after that the machine went into a deep freeze. Attached are results of a "copy-and-paste" collection on "remote". There are present multiple traces with "scheduling while atomic" and while they start the same as previously with '__schedule_bug+0x75/0x7a' after few lines they seem to differ quite substantially from what I observed before. OTOH maybe this is just a side-effect of an initial "unable to handle kernel paging request at ffffffff801503f4" and really just a noise while this is an occurence of a quite different bug? No idea how to repeat that. The second attempt of updating after a restart run without any problems.
I added a patch to kernel-3.1.0-0.rc0.git19.1.fc17 that seems to fix this issue. Should be available in tomorrow's rawhide.
(In reply to comment #10) > I added a patch to kernel-3.1.0-0.rc0.git19.1.fc17 that seems to fix this > issue. Should be available in tomorrow's rawhide. It seems to fix it here indeed, thanks!
I added a slightly better patch from upstream. Closing.
I just wondering is this patch included in the latest RHEL 6.3 kernel update?? kernel-2.6.32-279.5.1.el6 I'm using RHEL 6.3 with kernel-2.6.32-279.2.1.el6.x86_64 I saw similar kernel panic Thanks for help!
(In reply to comment #13) > I just wondering is this patch included in the latest RHEL 6.3 kernel > update?? > kernel-2.6.32-279.5.1.el6 > > I'm using RHEL 6.3 with kernel-2.6.32-279.2.1.el6.x86_64 > I saw similar kernel panic > > Thanks for help! You should report your kernel panic via the proper RHEL support channels.
I'm sorry So it's for Fedora only?? THanks..
(In reply to comment #15) > I'm sorry > So it's for Fedora only?? This bug report is for Fedora only, yes. The RHEL and Fedora kernels are vastly different. While the panic you saw may look similar there is no guarantee that it is the same exact problem or that the patch used in Fedora will fix it. It is best to report the issue in bugzilla against the RHEL product and work with the proper support channels to get your issue resolved.