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. EinsteinReceived on Tue Feb 05 2008 - 18:56:27 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:26 UTC