From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 18 18:42:55 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id DE4CAD7A; Thu, 18 Jul 2013 18:42:55 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) by mx1.freebsd.org (Postfix) with ESMTP id BB8EAF85; Thu, 18 Jul 2013 18:42:55 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 1F0C9B939; Thu, 18 Jul 2013 14:42:55 -0400 (EDT) From: John Baldwin To: Yuri Subject: Re: Kernel crashes after sleep: how to debug? Date: Thu, 18 Jul 2013 14:42:35 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p25; KDE/4.5.5; amd64; ; ) References: <51E3A334.8020203@rawbw.com> <201307161107.37460.jhb@freebsd.org> <51E830D4.7060302@rawbw.com> In-Reply-To: <51E830D4.7060302@rawbw.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201307181442.35401.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Thu, 18 Jul 2013 14:42:55 -0400 (EDT) Cc: Alan Cox , freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jul 2013 18:42:55 -0000 On Thursday, July 18, 2013 2:15:48 pm Yuri wrote: > On 07/16/2013 08:07, John Baldwin wrote: > > Can you go to frame 8 and do 'l' in kgdb? > > (kgdb) up 8 > #8 0xffffffff80baea78 in vm_pageout () at /usr/src/sys/vm/vm_pageout.c:829 > 829 if (!VM_OBJECT_TRYLOCK(object) && > (kgdb) l > 824 if (!vm_pageout_page_lock(m, &next)) { > 825 vm_page_unlock(m); > 826 continue; > 827 } > 828 object = m->object; > 829 if (!VM_OBJECT_TRYLOCK(object) && > 830 !vm_pageout_fallback_object_lock(m, &next)) { > 831 vm_page_unlock(m); > 832 VM_OBJECT_UNLOCK(object); > 833 continue; Hmm, so this seems to indicate you have a page on the active queue that doesn't have an associated VM object. Can you maybe 'p *m'? Maybe some temporary page is allocated during suspend but isn't freed appropriately? -- John Baldwin