NTFS panic

Doug Barton dougb at FreeBSD.org
Sun Jan 7 22:12:49 PST 2007


Using -current from as long ago as 12/18, or as recent as last night,
I get the same panic (attached) whenever I try to access data on an
NTFS volume.

Any takers?

Doug

-- 

    This .signature sanitized for your protection

-------------- next part --------------
Unread portion of the kernel message buffer:


Fatal trap 12: page fault while in kernel mode
cpuid = 1; apic id = 01
fault virtual address   = 0x0
fault code              = supervisor write, page not present
instruction pointer     = 0x20:0xc067e4aa
stack pointer           = 0x28:0xe9c6e9a0
frame pointer           = 0x28:0xe9c6ebf0
code segment            = base 0x0, limit 0xfffff, type 0x1b
                        = DPL 0, pres 1, def32 1, gran 1
processor eflags        = interrupt enabled, resume, IOPL = 0
current process         = 6084 (ls)
Physical memory: 2033 MB
Dumping 213 MB: 198 182 166 150 134 118 102 86 70 54 38 22 6

#0  doadump () at pcpu.h:166
166     pcpu.h: No such file or directory.
        in pcpu.h
(kgdb) where
#0  doadump () at pcpu.h:166
#1  0xc044f964 in db_fncall (dummy1=-1066756900, dummy2=0, dummy3=1, 
    dummy4=0xe9c6e774 "Ù\001lÀÀ~~ÀªägÀ ñ}À°çÆé\002")
    at /usr/local/src/sys/ddb/db_command.c:486
#2  0xc044fe99 in db_command_loop () at /usr/local/src/sys/ddb/db_command.c:401
#3  0xc045137d in db_trap (type=12, code=0)
    at /usr/local/src/sys/ddb/db_main.c:222
#4  0xc05396a5 in kdb_trap (type=12, code=0, tf=0xe9c6e960)
    at /usr/local/src/sys/kern/subr_kdb.c:502
#5  0xc067ff01 in trap_fatal (frame=0xe9c6e960, eva=0)
    at /usr/local/src/sys/i386/i386/trap.c:859
#6  0xc06800cb in trap_pfault (frame=0xe9c6e960, usermode=0, eva=0)
    at /usr/local/src/sys/i386/i386/trap.c:777
#7  0xc0680917 in trap (frame=0xe9c6e960)
    at /usr/local/src/sys/i386/i386/trap.c:462
#8  0xc066b8bb in calltrap () at /usr/local/src/sys/i386/i386/exception.s:139
#9  0xc067e4aa in memset () at /usr/local/src/sys/i386/i386/support.s:698
Previous frame inner to this frame (corrupt stack?)



More information about the freebsd-current mailing list