5.4-RC2 freezing - ATA related?
Peter Jeremy
PeterJeremy at optushome.com.au
Wed May 18 23:56:04 PDT 2005
Previously posted trap frame:
#5 0xc0691771 in trap (frame=
{tf_fs = -1068433384, tf_es = -989790192, tf_ds = 16, tf_edi = -106612473
6, tf_esi = -1066124736, tf_ebp = -323699844, tf_isp = -323699872, tf_ebx = -10
07063716, tf_edx = 528, tf_ecx = -1013235680, tf_eax = 307472464, tf_trapno = 1
2, tf_err = 2, tf_eip = -1067870386, tf_cs = 8, tf_eflags = 66050, tf_esp = -98
9760240, tf_ss = -1007063716}) at /usr/src/sys/i386/i386/trap.c:425
On Thu, 2005-May-19 00:15:44 +0100, Jamie Heckford wrote:
>Fatal trap 12: page fault while in kernel mode
>fault virtual address = 0x214
That's a NULL pointer somewhere. The trap frame shows %edx is 528 so
the code has presumably tried to dereference %edx but it's not clear
how %edx would up with that value.
>fault code = supervisor write, page not present
>instruction pointer = 0x8:0xc059974e
>stack pointer = 0x10:0xecb4bb74
>frame pointer = 0x10:0xecb4bb7c
This instruction pointer matches the trap frame but not the traceback
you posted. The trap frame gives the stack pointer as 0xC5017510
(which is nonsense) with a nonsense stack segment but the frame
pointer matches. Having the frame pointer above the stack pointer
is also unusual.
It looks like gdb is a bit confused. You could try:
disasm 0xc059974e
x/x 0xecb4bb74
Does the instruction either at or immediately before 0xc059974e
include [%edx]? What function is it in and can you work out the
line number? Does the address reported by the x/x match anything
in the backtrace?
--
Peter Jeremy
More information about the freebsd-stable
mailing list