From owner-svn-src-all@FreeBSD.ORG Mon Feb 25 19:06:04 2013 Return-Path: Delivered-To: svn-src-all@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 E7D2E3D1; Mon, 25 Feb 2013 19:06:04 +0000 (UTC) (envelope-from andrew@fubar.geek.nz) Received: from smtp3.clear.net.nz (smtp3.clear.net.nz [203.97.33.64]) by mx1.freebsd.org (Postfix) with ESMTP id B60D2F97; Mon, 25 Feb 2013 19:06:04 +0000 (UTC) Received: from mxin3-orange.clear.net.nz (lb2-srcnat.clear.net.nz [203.97.32.237]) by smtp3.clear.net.nz (CLEAR Net Mail) with ESMTP id <0MIS002XYIE2BB30@smtp3.clear.net.nz>; Tue, 26 Feb 2013 08:06:03 +1300 (NZDT) Received: from 202-0-48-19.paradise.net.nz (HELO bender) ([202.0.48.19]) by smtpin32.paradise.net.nz with ESMTP; Tue, 26 Feb 2013 08:06:02 +1300 Date: Tue, 26 Feb 2013 08:05:42 +1300 From: Andrew Turner Subject: Re: svn commit: r247116 - in head/sys: fs/nfs fs/nfsclient kern nfsclient sys tools In-reply-to: <20130225115500.GW2454@kib.kiev.ua> To: Konstantin Belousov Message-id: <20130226080542.253c69ea@bender> MIME-version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit References: <201302211902.r1LJ2o5T033708@svn.freebsd.org> <20130225201313.2050da18@bender> <20130225085019.GU2454@kib.kiev.ua> <20130225233603.49a5d4a5@bender> <20130225115500.GW2454@kib.kiev.ua> Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2013 19:06:05 -0000 On Mon, 25 Feb 2013 13:55:00 +0200 Konstantin Belousov wrote: > On Mon, Feb 25, 2013 at 11:36:03PM +1300, Andrew Turner wrote: > > On Mon, 25 Feb 2013 10:50:19 +0200 > > Konstantin Belousov wrote: > > > > > On Mon, Feb 25, 2013 at 08:13:13PM +1300, Andrew Turner wrote: > > > > On Thu, 21 Feb 2013 19:02:50 +0000 (UTC) > > > > John Baldwin wrote: > > > > > > > > > Author: jhb > > > > > Date: Thu Feb 21 19:02:50 2013 > > > > > New Revision: 247116 > > > > > URL: http://svnweb.freebsd.org/changeset/base/247116 > > > > > > > > > > Log: > > > > > Further refine the handling of stop signals in the NFS > > > > > client. The changes in r246417 were incomplete as they did > > > > > not add explicit calls to sigdeferstop() around all the > > > > > places that previously passed SBDRY to _sleep(). In addition, > > > > > nfs_getcacheblk() could trigger a write RPC from getblk() > > > > > resulting in sigdeferstop() recursing. Rather than manually > > > > > deferring stop signals in specific places, change the VFS_*() > > > > > and VOP_*() methods to defer stop signals for filesystems > > > > > which request this behavior via a new VFCF_SBDRY flag. Note > > > > > that this has to be a VFC flag rather than a MNTK flag so > > > > > that it works properly with VFS_MOUNT() when the mount is not > > > > > yet fully constructed. For now, only the NFS clients are set > > > > > this new flag in VFS_SET(). A few other related changes: > > > > > - Add an assertion to ensure that TDF_SBDRY doesn't leak to > > > > > userland. > > > > > - When a lookup request uses VOP_READLINK() to follow a > > > > > symlink, mark the request as being on behalf of the thread > > > > > performing the lookup (cnp_thread) rather than using a NULL > > > > > thread pointer. This causes NFS to properly handle signals > > > > > during this VOP on an interruptible mount. > > > > > > > > > > PR: kern/176179 > > > > > Reported by: Russell Cattelan (sigdeferstop() > > > > > recursion) Reviewed by: kib > > > > > MFC after: 1 month > > > > > > > > This change is causing init to crash for me on armv6. I'm > > > > netbooting a PandaBoard and it appears init is receiving a > > > > SIGABRT before it gets into main(). > > > > > > > > Do you have any idea where I could look to track down why it is > > > > doing this? > > > > > > It is weird. SIGABRT sent by the kernel usually means that > > > execve(2) already destroyed the previous address space of the > > > process, but the new image cannot be activated, most likely due > > > to image format error discovered too late, or resource shortage. > > > > > > Could it be that some NFS RPC fails after the patch, but I cannot > > > imagine why. You would need to track this. Also, verify that the > > > init binary is correct. > > > > > > I tried amd64 netboot, and it worked fine. > > > > It looks like this change is not the issue, it just changed the > > symptom enough for me to not realise I was seeing an issue where > > it would crash the kernel before. I reinstated this change but only > > allowed the kernel to access half the memory and it booted > > correctly. > > > > The real issue appears to be related to something in the vm layer > > not working on ARM boards with too much memory (somewhere between > > 512MiB and 1GiB). > > Hm, do you have r246926, r246929 and r247046 ? Yes, I've updated the kernel to r247213. Andrew