Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 19 May 2005 16:55:45 +1000
From:      Peter Jeremy <PeterJeremy@optushome.com.au>
To:        Jamie Heckford <jamie@tridentmicrosystems.co.uk>
Cc:        freebsd-stable@freebsd.org
Subject:   Re: 5.4-RC2 freezing - ATA related?
Message-ID:  <20050519065544.GC2129@cirb503493.alcatel.com.au>
In-Reply-To: <20050518231544.GA13555@nipples.trident-uk.co.uk>
References:  <001801c55a14$609720d0$37cba1cd@emerytelcom.com> <20050518150316.GA11987@nipples.trident-uk.co.uk> <20050518195312.GB2129@cirb503493.alcatel.com.au> <20050518222937.GA13356@nipples.trident-uk.co.uk> <20050518155452.M87264@carver.gumbysoft.com> <20050518231544.GA13555@nipples.trident-uk.co.uk>

next in thread | previous in thread | raw e-mail | index | archive | help
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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050519065544.GC2129>