Date: Fri, 19 Jul 2013 17:04:47 -0400 From: John Baldwin <jhb@freebsd.org> To: Yuri <yuri@rawbw.com> Cc: Alan Cox <alc@freebsd.org>, freebsd-hackers@freebsd.org Subject: Re: Kernel crashes after sleep: how to debug? Message-ID: <201307191704.47622.jhb@freebsd.org> In-Reply-To: <51E9945B.1050907@rawbw.com> References: <51E3A334.8020203@rawbw.com> <201307191100.08549.jhb@freebsd.org> <51E9945B.1050907@rawbw.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Friday, July 19, 2013 3:32:43 pm Yuri wrote:
> On 07/19/2013 08:00, John Baldwin wrote:
> > Well, you can probably find the value of 'm' in a register if you look =
at=20
the
> > dissassembly around the fault. You can then cast that pointer to the=20
right
> > type and print its contents.
>=20
> Here is the value of *m in frame 8:
> (kgdb) p *(struct vm_page*)0xfffffe00b460abf8
> $3 =3D {pageq =3D {tqe_next =3D 0xfe26, tqe_prev =3D 0xfffffe00b5a124d8},=
listq=20
> =3D {tqe_next =3D 0xfffffe0081ad8f70, tqe_prev =3D 0xfffffe0081ad8f78},
> left =3D 0x6, right =3D 0xd00000201, object =3D 0x100000000, pindex =3D=20
> 4294901765, phys_addr =3D 18446741877712530608, md =3D {pv_list =3D {
> tqh_first =3D 0xfffffe00b460abc0, tqh_last =3D 0xfffffe00b5579020}, pat_m=
ode=20
> =3D -1268733096}, queue =3D 72 'H', segind =3D -85 '=EF=BF=BD',
> hold_count =3D -19360, order =3D 0 '\0', pool =3D 254 '=EF=BF=BD', cow =
=3D 65535,=20
> wire_count =3D 0, aflags =3D 0 '\0', flags =3D 0 '\0', oflags =3D 0,
> act_count =3D 0 '\0', busy =3D 176 '=EF=BF=BD', valid =3D 208 '=EF=BF=BD'=
, dirty =3D 126 '~'}
Hmm, that definitely looks like garbage. How are you with gdb scripting?
You could write a script that walks the PQ_ACTIVE queue and see if this
pointers ends up in there. It would then be interesting to see if the
previous page's next pointer is corrupted, or if the pageq.tqe_prev referen=
ces=20
that page then it could be that this vm_page structure has been stomped on=
=20
instead.
Ultimately I think you will need to look at any malloc/VM/page operations
done in the suspend and resume paths to see where this happens. It might
be slightly easier if the same page gets trashed every time as you could
print out the relevant field periodically during suspend and resume to
narrow down where the breakage occurs.
=2D-=20
John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201307191704.47622.jhb>