Bug 152490 - kernel panics when logical volume is striped over 4 drives
kernel panics when logical volume is striped over 4 drives
Status: CLOSED CURRENTRELEASE
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: kernel (Show other bugs)
4.0
i386 Linux
medium Severity high
: ---
: ---
Assigned To: Alasdair Kergon
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-03-29 16:38 EST by Jonathan Fraser
Modified: 2009-11-25 18:08 EST (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-11-25 18:08:26 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Jonathan Fraser 2005-03-29 16:38:59 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.6) Gecko/20050323 Firefox/1.0.2 Fedora/1.0.2-1.3.1

Description of problem:
created a logical volume striped accross 4 drives.
created an ext2 file system on the volume.
mounted the FS and started sequential write
io to a file using DD.
The kernel panics.

If the lvm is make accross 4 drives without striping,
that is the physical volumes are concatenated, the 
system run fine.

Also fails on FC3 kernels, up to 2.6.10-1.770_FC3

Version-Release number of selected component (if applicable):
Kernel 2.6.9-5.ELsmp on an i686

How reproducible:
Always

Steps to Reproduce:
1.  Attach 4 250Gb drives to Broadcom(Serverworks ATA controller)
2.  modprobe sata_svw
3.  zero any existing partitions on new disks
4. pvcreate /dev/sd{a,b,c,d}
5. vgcreate VG_Test /dev/sd{a,b,c,d}
6. lvcreate VG_Test -L 900G -i 4 -n LV_Test
7. mfks -t ext2 -b 4096 /dev/VG_Test/LV_Test
8. mount /dev/VG_Test/LV_Test /mnts/test1
9. cd /mnts/test1
10 dd if=/dev/zero of=BIG bs=256k

  

Actual Results:  Unable to handle kernel NULL pointer dereference at virtual address 00000000
 printing eip:
c013f253
*pde = 00004001
Oops: 0000 [#1]
SMP
Modules linked in: sd_mod sata_svw libata scsi_mod md5 ipv6 parport_pc lp parport autofs4 i2c_dev i2c_core nfs lockd sunrpc button battery ac uhci_hcd e1000 floppy dm_snapshot dm_zero dm_mirror ext3 jbd dm_mod
CPU:    3
EIP:    0060:[<c013f253>]    Not tainted VLI
EFLAGS: 00010246   (2.6.9-5.ELsmp)
EIP is at __free_pages+0x3/0x4a
eax: 00000000   ebx: c43ba780   ecx: 00000000   edx: 00000000
esi: f7f8d080   edi: 00000000   ebp: 00000000   esp: c03bbef8
ds: 007b   es: 007b   ss: 0068
Process swapper (pid: 0, threadinfo=c03bb000 task=c43805b0)
Stack: c43ba780 c013e0b8 d4c40400 f7f8d080 d4c40480 c0146398 00000000 00000000
       c43ba780 d4c40400 00010000 c01463c7 00000000 c01463dd c015a35f 00010000
       d4c40400 00000000 c03bbf68 c02191ec f054390c 00000000 00000000 00000000
Call Trace:
 [<c013e0b8>] mempool_free+0x60/0x64
 [<c0146398>] bounce_end_io+0x52/0x81
 [<c01463c7>] bounce_end_io_write+0x0/0x1b
 [<c01463dd>] bounce_end_io_write+0x16/0x1b
 [<c015a35f>] bio_endio+0x50/0x55
 [<c02191ec>] __end_that_request_first+0xea/0x1ab
 [<f8c1d680>] scsi_end_request+0x1b/0xa0 [scsi_mod]
 [<f8c1da43>] scsi_io_completion+0x20b/0x417 [scsi_mod]
 [<c011cf19>] __wake_up+0x29/0x3c
 [<f8c19b15>] scsi_finish_command+0xad/0xb1 [scsi_mod]
 [<f8c19a3a>] scsi_softirq+0xb6/0xbe [scsi_mod]
 [<c0124b94>] __do_softirq+0x4c/0xb1
 [<c0107f05>] do_softirq+0x4f/0x56
 =======================
 [<c010781b>] do_IRQ+0x125/0x130
 [<c02c6c60>] common_interrupt+0x18/0x20
 [<c0104018>] default_idle+0x0/0x2c
 [<c0104041>] default_idle+0x29/0x2c
 [<c010409d>] cpu_idle+0x26/0x3b 
Code: 00 00 89 d8 f3 ab 89 d7 5a 89 f8 5b 5f c3 56 53 8b 30 89 c3 4e 78 0e 8b 53 04 8b 44 b3 08 e8 47 fa ff ff eb ef 5b 5e c3 53 89 c1 <8b> 00 89 d3 f6 c4 08 75 3c 8b 01 89 ca f6 c4 80 74 03 8b 51 0c
 <0>Kernel panic - not syncing: Fatal exception in interrupt


Expected Results:  Should not panic

Additional info:

Machine: 2 HT xeons, 6gb memory.

I've tested this both on RHEL4 and on FC3 with the 2.6.10-1.770_FC3smp. 
      Same results
I've tested with both the sata_svw driver and our raid driver for the
card.
      Same results.
Comment 1 Alasdair Kergon 2005-05-04 08:59:17 EDT
There were some bugs affecting large/striped logical volumes that have been fixed.

Is this still a problem with the latest FC4 test kernels?
Comment 2 Jonathan Fraser 2005-05-04 16:52:21 EDT
This problem appears to be fixed in FC3 2.6.11_1.14_FC3
Comment 3 Alasdair Kergon 2005-05-05 17:32:50 EDT
So we need to see if the fix made it into the RHEL4 U1 kernel, or else locate
the appropriate patch and apply for U2.
Comment 5 Alasdair Kergon 2009-11-25 18:08:26 EST
Assuming this was fixed long ago.

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