Messages in this thread | | | From | Norbert van Nobelen <> | Subject | Re: raid5 crash | Date | Wed, 22 Dec 2004 23:26:15 +0100 |
| |
The sii 3114 is a RAID controller by itself.
Is in not conflicting somewhere (like running software RAID5 and at the same time hardware RAID X?)
On Wednesday 22 December 2004 23:04, you wrote: > I am running kernel 2.6.9-gentoo-r10 on an Athlon XP 2400+ computer with a > SiI 3114 SATA controller hosting 4 WD2500JD-00G drives. I have combined > these drives into a raid5 array using software raid, but unfortunately the > array is not stable. I have tried several filesystems (ext3, reiserfs, > xfs), but after copying several gigabytes of data into the array (using > scp) and then trying to read them back (using rsync to compare over the > network) always results in data corruption. Here is the output from > 'dmesg': > > kernel BUG at drivers/md/raid5.c:813! > invalid operand: 0000 [#1] > Modules linked in: sata_sil libata sbp2 ohci1394 ieee1394 usb_storage > ehci_hcd usbcore > CPU: 0 > EIP: 0060:[<c039cdd2>] Not tainted VLI > EFLAGS: 00010006 (2.6.9-gentoo-r10) > EIP is at add_stripe_bio+0x1c2/0x200 > eax: 00045168 ebx: d3974b00 ecx: d3974980 edx: 00000000 > esi: 00045140 edi: 00000000 ebp: e33200a4 esp: f0a05ac4 > ds: 007b es: 007b ss: 0068 > Process rsync (pid: 32092, threadinfo=f0a04000 task=f6c10020) > Stack: 00000000 00000296 00000140 e3320028 00045140 00000000 d3974980 > c039e092 e3320028 d3974980 00000000 00000000 00000000 f0a05b1c de3e1ae0 > 00045158 00000000 00000003 00000004 de3e1ae0 dfe90e00 00000000 00000003 > f7d85088 Call Trace: > [<c039e092>] make_request+0x122/0x200 > [<c032dc6f>] generic_make_request+0x15f/0x1e0 > [<c011d590>] autoremove_wake_function+0x0/0x60 > [<c032dd4d>] submit_bio+0x5d/0x100 > [<c0172d43>] mpage_bio_submit+0x23/0x40 > [<c0173170>] do_mpage_readpage+0x2d0/0x480 > [<c012367d>] __do_softirq+0x7d/0x90 > [<c02b54df>] radix_tree_node_alloc+0x1f/0x60 > [<c02b5762>] radix_tree_insert+0xe2/0x100 > [<c0136e54>] add_to_page_cache+0x54/0x80 > [<c017346b>] mpage_readpages+0x14b/0x180 > [<c018f1f0>] reiserfs_get_block+0x0/0x1450 > [<c013ddf4>] read_pages+0x134/0x140 > [<c018f1f0>] reiserfs_get_block+0x0/0x1450 > [<c013b390>] __alloc_pages+0x1d0/0x370 > [<c01081c5>] do_IRQ+0xc5/0xe0 > [<c013e04f>] do_page_cache_readahead+0xcf/0x130 > [<c013e19f>] page_cache_readahead+0xef/0x1e0 > [<c013765c>] do_generic_mapping_read+0x11c/0x4d0 > [<c0137cae>] __generic_file_aio_read+0x1be/0x1f0 > [<c0137a10>] file_read_actor+0x0/0xe0 > [<c0137e1a>] generic_file_read+0xba/0xe0 > [<c011ac24>] do_page_fault+0x194/0x591 > [<c011d590>] autoremove_wake_function+0x0/0x60 > [<c0126f6b>] update_wall_time+0xb/0x40 > [<c012739f>] do_timer+0xdf/0xf0 > [<c015270c>] vfs_read+0xbc/0x170 > [<c012367d>] __do_softirq+0x7d/0x90 > [<c0152a71>] sys_read+0x51/0x80 > [<c010603b>] syscall_call+0x7/0xb > Code: 72 08 0f ba a8 90 00 00 00 02 83 c4 0c 5b 5e 5f 5d c3 89 cb e9 cd fe > ff ff 8b 5d 00 e9 c5 fe ff ff 77 08 39 f0 0f 86 94 fe ff ff <0f> 0b 2d 0370 > 92 44 c0 e9 87 fe ff ff 0f 87 a8 fe ff ff 39 f0 > > Any idea whether this is a kernel bug or a hardware problem? > Please CC any replies to me. > > Sincerely, - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |