Bugzilla (bugzilla.redhat.com) will be under maintenance for infrastructure upgrades and will not be available on July 31st between 12:30 AM - 05:30 AM UTC. We appreciate your understanding and patience. You can follow status.redhat.com for details.
Bug 982773 - Kernel panic: BUG: unable to handle kernel paging request at 00007f2ccc000000
Summary: Kernel panic: BUG: unable to handle kernel paging request at 00007f2ccc000000
Status: CLOSED DUPLICATE of bug 976789
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 19
Hardware: x86_64
OS: Linux
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2013-07-09 20:47 UTC by Juan Orti
Modified: 2013-07-14 01:12 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2013-07-14 01:12:55 UTC
Type: Bug

Attachments (Terms of Use)
vmcore-dmesg (116.58 KB, text/plain)
2013-07-09 20:47 UTC, Juan Orti
no flags Details

Description Juan Orti 2013-07-09 20:47:58 UTC
Created attachment 771229 [details]

Description of problem:
I have had a kernel panic that I think it's related to using two KVM virtual machines.

Version-Release number of selected component (if applicable):

How reproducible:
I have reproduced it a couple of times. It has happened when I was playing with two VMs (Whonix: http://sourceforge.net/p/whonix/wiki/Home/#whonix-homepage - they are i686 Debian images).
Some months ago, I used another KVM vms in F18 without problems. In these months I have updated the UEFI BIOS firmware and touched some parameters like setting "max performance" in the BIOS and reserving 1024M to the SandyBridge GPU.
My motherboard is an Asus P8Z68-V LE with BIOS version 4002 and a Intel Core i7-2600K

Steps to Reproduce:
1. I start two VMs
2. Play a little with them
3. Crash

Additional info:
I have configured kdump and this is what I see. If you need the vmcore file I keep it, it's 9,3GB

# crash vmcore /usr/lib/debug/lib/modules/`uname -r`/vmlinux

crash 6.1.4-1.fc19
Copyright (C) 2002-2013  Red Hat, Inc.
Copyright (C) 2004, 2005, 2006, 2010  IBM Corporation
Copyright (C) 1999-2006  Hewlett-Packard Co
Copyright (C) 2005, 2006, 2011, 2012  Fujitsu Limited
Copyright (C) 2006, 2007  VA Linux Systems Japan K.K.
Copyright (C) 2005, 2011  NEC Corporation
Copyright (C) 1999, 2002, 2007  Silicon Graphics, Inc.
Copyright (C) 1999, 2000, 2001, 2002  Mission Critical Linux, Inc.
This program is free software, covered by the GNU General Public License,
and you are welcome to change it and/or distribute copies of it under
certain conditions.  Enter "help copying" to see the conditions.
This program has absolutely no warranty.  Enter "help warranty" for details.
GNU gdb (GDB) 7.3.1
Copyright (C) 2011 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-unknown-linux-gnu"...

crash: cannot determine thread return address
      KERNEL: /usr/lib/debug/lib/modules/3.9.9-301.fc19.x86_64/vmlinux
    DUMPFILE: vmcore
        CPUS: 8
        DATE: Tue Jul  9 21:15:07 2013
      UPTIME: 03:34:49
LOAD AVERAGE: 1.32, 0.83, 1.07
       TASKS: 634
    NODENAME: xenon.miceliux.com
     RELEASE: 3.9.9-301.fc19.x86_64
     VERSION: #1 SMP Thu Jul 4 15:10:36 UTC 2013
     MACHINE: x86_64  (3502 Mhz)
      MEMORY: 15 GB
       PANIC: "Oops: 0003 [#1] SMP " (check log for details)
         PID: 1095
     COMMAND: "polkitd"
        TASK: ffff8803dc4d8000  [THREAD_INFO: ffff880408bf6000]
         CPU: 0

crash> bt
PID: 1095   TASK: ffff8803dc4d8000  CPU: 0   COMMAND: "polkitd"
 #0 [ffff880408bf79b8] machine_kexec at ffffffff8103dc52
 #1 [ffff880408bf7a08] crash_kexec at ffffffff810c69b3
 #2 [ffff880408bf7ad0] oops_end at ffffffff81648030
 #3 [ffff880408bf7af8] no_context at ffffffff8163c4a8
 #4 [ffff880408bf7b40] __bad_area_nosemaphore at ffffffff8163c528
 #5 [ffff880408bf7b88] bad_area_nosemaphore at ffffffff8163c694
 #6 [ffff880408bf7b98] __do_page_fault at ffffffff8164abee
 #7 [ffff880408bf7c90] do_page_fault at ffffffff8164adee
 #8 [ffff880408bf7ca0] page_fault at ffffffff81647498
    [exception RIP: anon_vma_chain_link+18]
    RIP: ffffffff81164582  RSP: ffff880408bf7d58  RFLAGS: 00010246
    RAX: ffff8803de579388  RBX: 00007f2ccc000000  RCX: ffff880408bf7fd8
    RDX: ffff8803de579380  RSI: 00007f2ccc000000  RDI: ffff880326cb9398
    RBP: ffff880408bf7d68   R8: 0000000000016d60   R9: ffffffff81166249
    R10: ffff88041f5ddd80  R11: 000000000000000e  R12: ffff8803de579380
    R13: ffff8803de579380  R14: ffff8803de579380  R15: 00007f2ccc000000
    ORIG_RAX: ffffffffffffffff  CS: 0010  SS: 0018
 #9 [ffff880408bf7d70] anon_vma_clone at ffffffff81166282
#10 [ffff880408bf7db8] anon_vma_fork at ffffffff8116636e
#11 [ffff880408bf7df0] dup_mm at ffffffff8105a566
#12 [ffff880408bf7e60] copy_process.part.24 at ffffffff8105b36d
#13 [ffff880408bf7ed8] do_fork at ffffffff8105be5d
#14 [ffff880408bf7f38] sys_clone at ffffffff8105c166
#15 [ffff880408bf7f48] stub_clone at ffffffff8164f679
    RIP: 00007f2ceddd87fc  RSP: 00007fff4e5e3e00  RFLAGS: 00000246
    RAX: 0000000000000038  RBX: 0000000000000000  RCX: ffffffffffffffff
    RDX: 0000000000000000  RSI: 0000000000000000  RDI: 0000000001200011
    RBP: 00007fff4e5e3e60   R8: 0000000000000447   R9: 0000000000000000
    R10: 00007f2cef9e7b10  R11: 0000000000000246  R12: 00007fff4e5e3e00
    R13: 00007fff4e5e3e20  R14: 0000000000000001  R15: 0000000000000001
    ORIG_RAX: 0000000000000038  CS: 0033  SS: 002b

Comment 1 Josh Boyer 2013-07-10 01:53:31 UTC
Please try http://koji.fedoraproject.org/koji/buildinfo?buildID=431939

This might be a duplicate of 980643 976789

Comment 2 Juan Orti 2013-07-13 18:52:38 UTC
(In reply to Josh Boyer from comment #1)
> Please try http://koji.fedoraproject.org/koji/buildinfo?buildID=431939
> This might be a duplicate of 980643 976789

This kernel works perfect for me. I've been using it for two days and I haven't got any more crashes. I've been doing extensive testing with 5 vms without problems so far. Before, with kernel-3.9.9-301.fc19.x86_64 I had 3-4 crashes per day.

Thank you!

Comment 3 Josh Boyer 2013-07-14 01:12:55 UTC
Great, thanks.  I'm going to mark this as a duplicate then.

*** This bug has been marked as a duplicate of bug 976789 ***

Note You need to log in before you can comment on or make changes to this bug.