Bug 870177 - Kernel panic under specific ramdisk (brd.c) test conditions
Kernel panic under specific ramdisk (brd.c) test conditions
Status: CLOSED DUPLICATE of bug 962593
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: kernel (Show other bugs)
x86_64 Linux
unspecified Severity low
: rc
: ---
Assigned To: Red Hat Kernel Manager
Red Hat Kernel QE team
Depends On:
  Show dependency treegraph
Reported: 2012-10-25 13:48 EDT by Jonathan DePrizio
Modified: 2015-08-05 11:15 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2015-08-05 11:15:00 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
vmcore file (82.60 MB, application/x-bzip2)
2012-10-25 13:48 EDT, Jonathan DePrizio
no flags Details

  None (edit)
Description Jonathan DePrizio 2012-10-25 13:48:04 EDT
Created attachment 633486 [details]
vmcore file

Description of problem:
This is a reproducible kernel panic on my system.  The test uses vdbench to do combined read/writes of 6KB to /dev/ram0, with offset=2K (full vdbench configuration file is below). The test produces a kernel panic (with kdump, attached (if it uploads properly)).  This panic does not occur in an all-reads test, or when offset=4K.

I've marked this as low severity, because I don't think anyone will actually do this.

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

How reproducible:
Every time on this machine.  Crash happens almost immediately (within 30 seconds).

Steps to Reproduce:
1.Setup ramdisk in grub.conf with a reasonably large size (in my case, ~40GB)
2.Run vdbench script below
Actual results:
Kernel panic, sad user.

Expected results:
Don't panic, happy user.

Additional info:

Machine is a Dell R710 with 96GB of RAM.  Here is my grub line, in which I've set the ramdisk size:

kernel /vmlinuz-2.6.32-279.2.1.el6.x86_64 ro root=/dev/mapper/vg_vbitr71057-lv_root rd_NO_LUKS  KEYBOARDTYPE=pc KEYTABLE=us LANG=en_US.UTF-8 rd_LVM_LV=vg_vbitr71057/lv_swap rd_LVM_LV=v     g_vbitr71057/lv_root quiet rd_NO_MD rhgb crashkernel=auto SYSFONT=latarcyrheb-sun16 rd_NO_DM ramdisk_size=41943040

Here is my vdbench test file:

Crash output:
      KERNEL: /usr/lib/debug/lib/modules/2.6.32-279.2.1.el6.x86_64/vmlinux
        CPUS: 16
        DATE: Tue Oct 23 11:02:47 2012
      UPTIME: 00:16:31
LOAD AVERAGE: 0.28, 0.15, 0.09
       TASKS: 547
    NODENAME: VBIT-R710-57
     RELEASE: 2.6.32-279.2.1.el6.x86_64
     VERSION: #1 SMP Fri Jul 20 01:55:29 UTC 2012
     MACHINE: x86_64  (2394 Mhz)
      MEMORY: 96 GB
       PANIC: "kernel BUG at drivers/block/brd.c:78!"
         PID: 5214
     COMMAND: "java"
        TASK: ffff880bef1b4040  [THREAD_INFO: ffff880c202c4000]
         CPU: 13
crash> bt
PID: 5214   TASK: ffff880bef1b4040  CPU: 13  COMMAND: "java"
 #0 [ffff880c202c5550] machine_kexec at ffffffff8103281b
 #1 [ffff880c202c55b0] crash_kexec at ffffffff810ba792
 #2 [ffff880c202c5680] oops_end at ffffffff815013c0
 #3 [ffff880c202c56b0] die at ffffffff8100f26b
 #4 [ffff880c202c56e0] do_trap at ffffffff81500cb4
 #5 [ffff880c202c5740] do_invalid_op at ffffffff8100ce35
 #6 [ffff880c202c57e0] invalid_op at ffffffff8100bedb
    [exception RIP: brd_lookup_page+51]
    RIP: ffffffff8135c5a3  RSP: ffff880c202c5898  RFLAGS: 00010202
    RAX: ffffea002984d058  RBX: 00000000003e2540  RCX: 0000000000000000
    RDX: 0000000000000000  RSI: 00000000003e2540  RDI: 0000000000000000
    RBP: ffff880c202c58a8   R8: 0000000000000000   R9: 0000000000000000
    R10: 0000000000000000  R11: 0000000000000000  R12: 0000000001f12a00
    R13: ffff880c1e8b5df0  R14: ffff880c1f1c6ac0  R15: 0000000000001000
    ORIG_RAX: ffffffffffffffff  CS: 0010  SS: 0018
 #7 [ffff880c202c5890] brd_lookup_page at ffffffff8135c591
 #8 [ffff880c202c58b0] brd_insert_page at ffffffff8135c5db
 #9 [ffff880c202c58e0] brd_make_request at ffffffff8135ccff
#10 [ffff880c202c5970] generic_make_request at ffffffff81256eee
#11 [ffff880c202c5a40] submit_bio at ffffffff8125724d
#12 [ffff880c202c5a90] dio_bio_submit at ffffffff811b5bbc
#13 [ffff880c202c5ac0] __blockdev_direct_IO_newtrunc at ffffffff811b66c1
#14 [ffff880c202c5ba0] __blockdev_direct_IO at ffffffff811b6c5e
#15 [ffff880c202c5c20] blkdev_direct_IO at ffffffff811b4377
#16 [ffff880c202c5c60] generic_file_direct_write at ffffffff81114e62
#17 [ffff880c202c5cd0] __generic_file_aio_write at ffffffff81116675
#18 [ffff880c202c5d90] blkdev_aio_write at ffffffff811b3b0c
#19 [ffff880c202c5dc0] do_sync_write at ffffffff8117ae9a
#20 [ffff880c202c5ef0] vfs_write at ffffffff8117b198
#21 [ffff880c202c5f30] sys_pwrite64 at ffffffff8117bc72
#22 [ffff880c202c5f80] system_call_fastpath at ffffffff8100b0f2
    RIP: 0000003652c0eec3  RSP: 00007f777a4bb648  RFLAGS: 00000206
    RAX: 0000000000000012  RBX: ffffffff8100b0f2  RCX: 0000000000000000
    RDX: 0000000000001000  RSI: 00007f76e4001000  RDI: 000000000000000a
    RBP: 00007f777a4bb640   R8: 00007f76e4001000   R9: 000000000000145e
    R10: 00000003e253f800  R11: 0000000000000293  R12: 0000000000000113
    R13: 0000000000000000  R14: 00000000c0463060  R15: 0000000000000000
    ORIG_RAX: 0000000000000012  CS: 0033  SS: 002b
Comment 2 RHEL Product and Program Management 2012-12-14 03:23:57 EST
This request was not resolved in time for the current release.
Red Hat invites you to ask your support representative to
propose this request, if still desired, for consideration in
the next release of Red Hat Enterprise Linux.
Comment 3 Artem Savkov 2015-08-05 11:15:00 EDT
While investigating this issue I found out that the issue was fixed in Bug 962593 in rhel6.6. Closing as duplicate, if there is need for inclusion in older z-streams a new bug requesting this should be opened.

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

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