Bug 920413

Summary: oops creating RAID LV
Product: [Fedora] Fedora Reporter: Chris Murphy <bugzilla>
Component: kernelAssignee: fedora-kernel-raid
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 18CC: agk, brsmith, gansalmon, itamar, jbrassow, jonathan, kernel-maint, madhu.chinakonda
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-07-03 00:22:52 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
dmesg
none
oops_boot_3.8.2.txt
none
dmesg_qemu-kvm_3.8.2.txt none

Description Chris Murphy 2013-03-12 04:05:32 UTC
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.

Comment 1 Chris Murphy 2013-03-12 04:41:37 UTC
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

Comment 2 Chris Murphy 2013-03-12 04:42:52 UTC
Created attachment 708764 [details]
oops_boot_3.8.2.txt

Serial console output 3.8.2-206.fc18.x86_64, recovery mode startup, oops.

Comment 3 Chris Murphy 2013-03-12 16:05:28 UTC
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.

Comment 4 Josh Boyer 2013-07-02 19:54:27 UTC
Are you still seeing this with 3.9.y?

Comment 5 Chris Murphy 2013-07-02 21:26:38 UTC
Uncertain. Any particular subversion I should test it with? If not, I'll use 3.9.5 since that's what I have.

Comment 6 Chris Murphy 2013-07-02 21:48:24 UTC
This bug isn't reproducible with 3.9.5-301.fc19.x86_64.

Comment 7 Josh Boyer 2013-07-03 00:22:52 UTC
Thanks.