Re: panic: System call lstat returning with 1 locks held

2008/2/5, Yar Tikhiy <yar_at_comp.chem.msu.su>:
> On Fri, Feb 01, 2008 at 07:41:58PM +0100, Attilio Rao wrote:
>  > 2008/2/1, Yar Tikhiy <yar_at_comp.chem.msu.su>:
>
> [...]
>
> > >  Fatal trap 12: page fault while in kernel mode
>  > >
>  > > cpuid = 0; apic id = 00
>  > >
>  > > fault virtual address   = 0xdeadc0ee
>  > >  fault code              = supervisor read, page not present
>  > >  instruction pointer     = 0x20:0xc07a0676
>  > >  stack pointer           = 0x28:0xd614e9a0
>  > >  frame pointer           = 0x28:0xd614e9a4
>  > >
>  > > code segment            = base 0x0, limit 0xfffff, type 0x1b
>  > >
>  > >                         = DPL 0, pres 1, def32 1, gran 1
>  > >
>  > > processor eflags        = resume, IOPL = 0
>  > >
>  > > current process         = 43 (umount)
>  > >  [thread pid 43 tid 100052 ]
>  > >  Stopped at      isitmychild+0x6:        movl    0x10(%eax),%ecx
>  > >  db> panic: Assertion !mtx_owned(&w_mtx) failed at /usr/src/sys/kern/subr_witness
>  > >  .c:959
>  > >  cpuid = 0
>  > >  Uptime: 2m14s
>  > >  Cannot dump. No dump device defined.
>  > >  Automatic reboot in 15 seconds - press a key on the console to abort
>  >
>  > It would be suitable for you to add DDB to your kernel config and see
>  > a backtrace for it?
>
>
> DDB was there (my kernel was GENERIC + DEBUG_VFS_LOCKS,) but it
>  failed, too.  Fortunately, I've managed to save a dump with the
>  whole call stack.  Attached is the respective output from kgdb,
>  showing multiple failures including the one in NTFS.

Currently it is DDB which let it fail in witness after memory corruption.
But I'm more interested in the panic originator; so, as far as it is
unusable, can you please remove DDB option and try to get the panic
again? it should not give you the failing assertion without DDB.

Thanks,
Attilio


-- 
Peace can only be achieved by understanding - A. Einstein