From owner-freebsd-stable@FreeBSD.ORG Sun Sep 6 16:07:58 2009 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6331A10656A8; Sun, 6 Sep 2009 16:07:58 +0000 (UTC) (envelope-from thierry.herbelot@free.fr) Received: from smtp4-g21.free.fr (smtp4-g21.free.fr [212.27.42.4]) by mx1.freebsd.org (Postfix) with ESMTP id 3D6D28FC08; Sun, 6 Sep 2009 16:07:54 +0000 (UTC) Received: from smtp4-g21.free.fr (localhost [127.0.0.1]) by smtp4-g21.free.fr (Postfix) with ESMTP id 8BB954C80D0; Sun, 6 Sep 2009 18:07:49 +0200 (CEST) Received: from mail.herbelot.nom (bne75-4-82-227-159-103.fbx.proxad.net [82.227.159.103]) by smtp4-g21.free.fr (Postfix) with ESMTP id 5D10F4C8140; Sun, 6 Sep 2009 18:07:47 +0200 (CEST) Received: from tulipe.herbelot.nom (tulipe.herbelot.nom [192.168.2.5]) by mail.herbelot.nom (8.14.1/8.14.1) with ESMTP id n86G7jVO007673; Sun, 6 Sep 2009 18:07:46 +0200 (CEST) From: Thierry Herbelot To: "A.J. \"Fonz\" van Werven" Date: Sun, 6 Sep 2009 18:07:39 +0200 User-Agent: KMail/1.9.10 References: <200909061537.n86FbqhP001617@satellite.xs4all.nl> In-Reply-To: <200909061537.n86FbqhP001617@satellite.xs4all.nl> X-Warning: Windows can lose your files X-Op-Sys: Le FriBi de la mort qui tue X-Org: TfH&Co X-MailScanner: Found to be clean MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Content-Disposition: inline Message-Id: <200909061807.40053.thierry.herbelot@free.fr> Cc: stable@freebsd.org, jhb@freebsd.org Subject: Re: Panic in recent 7.2-Stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Sep 2009 16:07:58 -0000 Le Sunday 06 September 2009, A.J. "Fonz" van Werven a écrit : > Kostik Belousov wrote: > > I expect that the following patch, that is the partial merge of r194459, > > would fix it. It patches sys/vm/vm_phys.c. > > > > Index: vm_phys.c > > =================================================================== > > --- vm_phys.c (revision 194458) > > +++ vm_phys.c (revision 194459) > > @@ -382,8 +382,7 @@ > > if (pa >= seg->start && pa < seg->end) > > return (&seg->first_page[atop(pa - seg->start)]); > > } > > - panic("vm_phys_paddr_to_vm_page: paddr %#jx is not in any segment", > > - (uintmax_t)pa); > > + return (NULL); > > } > > > > /* > > Hi, > > A quick grep on the file in question revealed that there are two > functions that may panic() with "page not in any segment": the > vm_phys_paddr_to_vm_page() being patched and also the next function > vm_phys_paddr_to_segind(). I'm not exactly current with the memory > management code so this may be a very stupid question, but I'll ask it > anyway: don't both functions need to be patched? > > My apologies if I'm way off the mark here, but I'm just trying to help. you are right : there seems the vm handling has been recently updated and maybe even "those who know" may not have reviewed/updated all panic conditions (removing the panic in vm_phys_paddr_to_vm_page at least allows correct operation of a -Stable kernel, like under -Current) TfH > > Regards, > > Alphons