Created attachment 708750 [details] dmesg Description of problem: When creating a RAID LV (native LVM raid, not using mdmadm), I get an oops. Version-Release number of selected component (if applicable): 3.8.2-206.fc18.x86_64 #1 SMP Fri Mar 8 15:03:34 UTC 2013 x86_64 lvm2-2.02.98-4.fc18.x86_64 How reproducible: Always Steps to Reproduce: 1. Create three 80GB virtual disks 2. gdisk, GPT, single partition all space, type 8E00 3. pvcreate /dev/sd[bcd]1 4. vgcreate vg1 /dev/sd[bcd]1 5. lvcreate --type raid5 -L 50G -i 2 -I 64 -n r5 vg1 Actual results: shell hangs. in another shell, dmesg: [10680.534672] BUG: unable to handle kernel NULL pointer dereference at 0000000000000290 [10680.534994] IP: [<ffffffffa0388ce4>] ops_run_io+0x284/0x690 [raid456] [10680.535268] PGD 9c817067 PUD 9c818067 PMD 0 [10680.535268] Oops: 0000 [#1] SMP Expected results: For the LV to be created. Additional info: Attaching full dmesg as a text file.
Regression summary: Appears to be a regression in 3.8.x kernels. Above system will oops on startup if the three devices making up the RAID LV are attached. If they're detached, oops doesn't occur. Oops with 3.8x kernels, but not 3.7.x or 3.6.x kernels: Regression detail: 1. Still occurs even if elevator=deadline parameter is removed. 2. These kernels oops on startup: 3.8.1-201.fc18.x86_64 3.8.2-206.fc18.x86_64 3. These kernels boot normally: 3.6.10-4.fc18.x86_64 3.6.11-3.fc18.x86_64 3.7.2-204.fc18.x86_64 3.7.4-204.fc18.x86_64 3.7.6-201.fc18.x86_64
Created attachment 708764 [details] oops_boot_3.8.2.txt Serial console output 3.8.2-206.fc18.x86_64, recovery mode startup, oops.
Created attachment 709051 [details] dmesg_qemu-kvm_3.8.2.txt Prior attempts used VirtualBox. The same problem occurs with qemu-kvm. This is a F18 3.8.2 guest on an F18 3.8.2 host.
Are you still seeing this with 3.9.y?
Uncertain. Any particular subversion I should test it with? If not, I'll use 3.9.5 since that's what I have.
This bug isn't reproducible with 3.9.5-301.fc19.x86_64.
Thanks.