Hi, Yes we use our own filesystem module. Apart from this i also see oops due to invalid address etc. I suspect our module is overwriting in to the stack, probably causing corruption. Is there a way to increase the stack size? I am pasting one of those stack below. This is the first time our module is getting ported on AMD64. The kernel used is 2.4.21-143-numa. opteron# lsmod Module Size Used by Tainted: P panfs 6260392 2 (autoclean) nfsd 92752 4 (autoclean) ide-cd 36616 0 (autoclean) cdrom 34664 0 (autoclean) [ide-cd] ipv6 284856 -1 (autoclean) key 78248 0 (autoclean) [ipv6] joydev 7136 0 (unused) evdev 6496 0 (unused) input 7488 0 [joydev evdev] usb-ohci 23728 0 (unused) usbcore 87488 1 [usb-ohci] bcm5700 93232 1 lvm-mod 81152 0 (autoclean) reiserfs 248088 1 <1>Unable to handle kernel paging request at virtual address 000000ffd1e7f664 printing rip: ffffffff801c686d PML4 0 Oops: 0002 CPU 1 Pid: 8015, comm: detect_corrupti Tainted: PF RIP: 0010:[<ffffffff801c686d>]{kdbm_memmap+205} RSP: 0018:0000010011e43a88 EFLAGS: 00010292 RAX: fffffffff000eef3 RBX: 0000000000000000 RCX: ffffffff8047e5e0 RDX: 0000000000000001 RSI: 0000000000000000 RDI: 0000010011e43b20 RBP: 0000010000000058 R08: f000f8599f400175 R09: f000eef39f40008e R10: f000ff53f000ef57 R11: f000e987f000fea5 R12: 000000000007fff0 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 FS: 0000000000000000(0000) GS:ffffffff804e8280(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b CR2: 000000ffd1e7f664 CR3: 000000007f902000 CR4: 00000000000006e0 Process detect_corrupti (pid: 8015, stackpage=10011e43000) Stack: 0000010011e43a88 0000000000000018 ffffffff801c6819 0000000000000007 0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000010000000000 0000000000000000 f000eef300000001 Call Trace: [<ffffffff801c6819>]{kdbm_memmap+121} [<ffffffff801c21f8>]{kdb_parse+504} [<ffffffff801c4929>]{kdb_read+9} [<ffffffff801c496b>]{kdb_getstr+59} [<ffffffff801c26bc>]{kdb_local+876} [<ffffffff80125a85>]{release_console_sem+165} [<ffffffff801258cb>]{vprintk+331} [<ffffffff8012597d>]{printk+141} [<ffffffff801c283a>]{kdb_main_loop+186} [<ffffffff802d8090>]{kdba_main_loop+128} [<ffffffff801c2f95>]{kdb+1509} [<ffffffff80111621>]{die+241} [<ffffffff801c7895>]{do_page_fault+1237} [<ffffffff801109a2>]{error_exit+0} [<ffffffff8012966a>]{do_exit+154} [<ffffffff801299c3>]{sys_exit+19} [<ffffffff801102a3>]{tracesys_call+10} Code: ff 44 84 10 eb 04 ff 44 24 30 8b 44 24 0c ff c0 48 83 bc 24 kdb: Debugger re-entered on cpu 1, new reason = 5 Attempting to abort command and recover [1]kdb> Thanks, Satya

From: Andi Kleen <ak@suse.de> To: adelphia user <sendtoadelphia@hotmail.com> CC: suse-amd64@suse.com Subject: Re: [suse-amd64] oops in current->journal-info in ext3 and reiserfs Date: Mon, 21 Jun 2004 12:54:25 +0200

On Mon, Jun 21, 2004 at 09:07:40AM +0530, adelphia user wrote:

...

Hello ,

I am seeing oopses in ext3 and also in reiserfs because of invalid current->journal_info. I am facing this problem in kernel 2.4.21-143-numa. This is on suse 8.1 amd64.

This is very likely a kernel stack overflow.

Do you use any special kernel modules? Please send your lsmod output.

-Andi

-- Check the List-Unsubscribe header to unsubscribe For additional commands, email: suse-amd64-help@suse.com

_________________________________________________________________ Apply to 50,000 jobs now. http://go.msnserver.com/IN/50740.asp Post your CV on naukri.com today.