lkml.org 
[lkml]   [2005]   [May]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: OOPS + 2.6.9-gentoo-r9 (and .10 and .11) + 2xHPT302 + RAID5
From
Date
> We have been trying to re-build a new system after a system disk
> failed a couple of weeks ago. It was a gentoo system running 2.4, but
> this time we figured we would take the plunge and install 2.6, since
> we had a couple of problems with 2.4 and its support of the ITE RAID
> card. Now we have two HPT302 cards, 7x120Gb drives, one 160Gb drive
> attached to the motherboard, thats pretty much the only exceptional
> configuration, other than that, DVD-R, AMD2000+, 512Mb SDR memory...
>
> Anyway, we are onto our second rebuild now, the first was done using
> reiserfs on the system disk, this had intermitent segfaults during the
> build, which we first put down to gcc, but later we realised it was
> something to do with the kernel's reiserfs driver since it was OOPSing
> in that module. We then started getting segfaults with all manner of
> tools, including emerge (gentoo's port system) and corruption in the
> ports tree. I tried reinstalling all the components, rebuilding the
> kernel with different gcc's but still the same.
>
> So we figured we would rebuild and use ext3 as the root filesystem.
> Worked fine up until an hour ago, when it started OOPSing with the
> following (see examples below).
>
> Now, I am no C whizz, or kernel hacker, just very very confused as to
> what is going on. We have tried 2.6.9,2.6.10 and 2.6.11 with gcc 3.3
> and 3.4 with a reiserfs root, and we get problems, and now we change
> to ext3, we get the same, which leads me to suspect its not
> reiserfs/ext3, but something messing with it. My minimal research
> into possible causes has led me to think that raid5/md/lvm with the
> dual HPT302 cards could be doing something odd... I dont know how or
> why, hence my call for help!
>
> Any help would be appreciated, or perhaps a point in the right
> direction! I just cant beleive that something like this would have
> gone unoticed if it was a problem with the filesystem drivers.
>

By the looks of this report, have you taken a long run with
http://www.memtest86.com/ ? If not I really think you should.



> Unable to handle kernel paging request at virtual address 00200004
> printing eip:
> c0130292
> *pde = 00000000
> Oops: 0002 [#1]
> PREEMPT
> Modules linked in:
> CPU: 0
> EIP: 0060:[<c0130292>] Not tainted VLI
> EFLAGS: 00010006 (2.6.9-gentoo-r9)
> EIP is at find_lock_page+0x32/0xe0
> eax: 00200000 ebx: 00200000 ecx: 00000000 edx: 00000000
> esi: 00000000 edi: e9dc0d08 ebp: 00000000 esp: ee264d38
> ds: 007b es: 007b ss: 0068
> Process emerge (pid: 23819, threadinfo=ee264000 task=c8e21aa0)
> Stack: e9dc0d08 00000000 00000000 00000000 00000000 e9dc0d04 c0131f1f e9dc0d04
> 00000000 00000000 000000d0 0037806c 00000000 ee264000 00000000 b71a4000
> 00000147 0037806c e9dc0c6c c03ea160 ef64d7e0 00000000 00000000 00000000
> Call Trace:
> [<c0131f1f>] generic_file_buffered_write+0xff/0x5e0
> [<c01c6df6>] do_get_write_access+0x256/0x600
> [<c0168677>] inode_update_time+0xa7/0xe0
> [<c013265d>] generic_file_aio_write_nolock+0x25d/0x480
> [<c01c71e3>] journal_get_write_access+0x43/0x60
> [<c01329d3>] generic_file_aio_write+0x83/0x100
> [<c01b77a4>] ext3_file_write+0x44/0xe0
> [<c014d9be>] do_sync_write+0xbe/0xf0
> [<c0113200>] autoremove_wake_function+0x0/0x60
> [<c014daac>] vfs_write+0xbc/0x170
> [<c014dc31>] sys_write+0x51/0x80
> [<c0104207>] syscall_call+0x7/0xb


-
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/

\
 
 \ /
  Last update: 2005-05-11 12:10    [W:0.023 / U:0.176 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site