On Tuesday 22 March 2005 01:08, Andrew Morton wrote:
>
> Sergey, I'm assuming this is a bug in the megaraid driver.
Sorry for a slow response.
>
> Can you confirm that it's still happening in 2.6.12-rc1?
Unfortunately I'm not shure I remember well the exact sequence
of operations I performed in ncurses based megaraid utility
(megamgr) to reproduce oops two a month ago.
If my memory (about the exact sequence) is correct I could not
reproduce this problem with 2.6.11. Will try 2.6.12-rc*
at the end of the week (this is a production server).
Thank you!
>
> "Sergey S. Kostyliov" <[EMAIL PROTECTED]> wrote:
> >
> > On Thursday 10 February 2005 12:49, Sergey S. Kostyliov wrote:
> > > On Thursday 10 February 2005 03:36, Andrew Morton wrote:
> > > > "Sergey S. Kostyliov" <[EMAIL PROTECTED]> wrote:
> > > > >
> > > > > Here is an oops I've just get on my smp system:
> > > > >
> > > > > Unable to handle kernel NULL pointer dereference at virtual address
> > > > > 0000001c
> > > > > printing eip:
> > > > > c01afe5b
> > > > > *pde = 00000000
> > > > > Oops: 0000 [#1]
> > > > > PREEMPT SMP
> > > > > Modules linked in: ipt_REJECT ipt_state ip_conntrack iptable_filter
> > > > > CPU: 2
> > > > > EIP: 0060:[<c01afe5b>] Not tainted VLI
> > > > > EFLAGS: 00010286 (2.6.10)
> > > > > EIP is at devfsd_close+0x1b/0xc8
> > > > > eax: f7440a00 ebx: 00000000 ecx: c01afe40 edx: ed395280
> > > > > esi: 00000000 edi: f7f17800 ebp: f74f96c8 esp: cdc70f84
> > > > > ds: 007b es: 007b ss: 0068
> > > > > Process megamgr.bin (pid: 12844, threadinfo=cdc70000 task=dd81e520)
> > > > > Stack: ed395280 ed395280 00000000 f7f17800 c0150c76 ee9e87f8 ed395280
> > > > > 00000000
> > > > > f1985c80 cdc70000 c014f50f 00000003 00000003 080caa60 00000000
> > > > > c01024df
> > > > > 00000003 080cc700 bfffe4f8 080caa60 00000000 bfffe4fc 00000006
> > > > > 0000007b
> > > > > Call Trace:
> > > > > [<c0150c76>] __fput+0x106/0x120
> > > > > [<c014f50f>] filp_close+0x4f/0x80
> > > > > [<c01024df>] syscall_call+0x7/0xb
> > > >
> > > > Can you work out what file is being closed? One way of doing that
> > > > would be
> > > > to work out how megamgr.bin is being invoked and to then run it by hand:
> > > >
> > > > strace -f -o log megamgr.bin <args>
> > > >
> > > > and we can then use the strace output to work out the pathname of the
> > > > offending file.
> > >
> > > [EMAIL PROTECTED] rathamahata $ grep 'open(' mg.log
> > > 5255 open("/usr/share/terminfo/l/linux", O_RDONLY) = 3
> > > 5255 open("/dev/megadev0", O_RDONLY) = 3
> > > [EMAIL PROTECTED] rathamahata $
> > Sorry, I forgot this part:
> > [EMAIL PROTECTED] rathamahata $ grep 'close(' mg.log
> > 5255 close(3) = 0
> > [EMAIL PROTECTED] rathamahata $
> >
> > >
> > > I guess it's /dev/megadev0 (manually created character device)
> > >
> > > [EMAIL PROTECTED] rathamahata $ ls -la /dev/megadev0
> > > crw-r--r-- 1 root root 253, 0 Feb 8 16:26 /dev/megadev0
> > > [EMAIL PROTECTED] rathamahata
> > >
> >
> > --
> > Sergey S. Kostyliov <[EMAIL PROTECTED]>
> > Jabber ID: [EMAIL PROTECTED]
>
--
Sergey S. Kostyliov <[EMAIL PROTECTED]>
Jabber ID: [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
