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