From owner-freebsd-stable@FreeBSD.ORG Mon Jun 29 16:16:54 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D9CD7106564A; Mon, 29 Jun 2009 16:16:54 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from mail-bw0-f216.google.com (mail-bw0-f216.google.com [209.85.218.216]) by mx1.freebsd.org (Postfix) with ESMTP id 3365E8FC08; Mon, 29 Jun 2009 16:16:53 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: by bwz12 with SMTP id 12so439205bwz.43 for ; Mon, 29 Jun 2009 09:16:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=ZTBH5yiEHjeNlcBP/0E5cz7fzD2nQY1MdGdKRsjBqeI=; b=HEq5Qn0b9/LgU1WChNBfCr2Dmk0MfIt8CvE8wwOvD9vFGegl4RKVfRD7AvU+HBQEkJ SmahNu7eSjcgCtYH2HEBoLMazqfYUz3K62uupZWL/+3lIicighIUVSK83c4W7UzQxVWH Oy5m4RvlOPW0Dzt6CUVaelEtdhKA+axq18ToM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=PVvxN8Ms9IWF4qenZ/GR19w2+zQqlHlkVFVo5dw0tyYpzLeARqrku5V6H96rm/zZku SZBtpbiMrPip2iKqTCJGUj8PxsdRel1U8uvRpbvGMr/6nPnp2jfthKpjdbQ3MoqNiCOA OwfWX23rERhDGgCYKreJtodV9UMwt81MpHiRY= MIME-Version: 1.0 Received: by 10.204.64.67 with SMTP id d3mr7287142bki.142.1246292213024; Mon, 29 Jun 2009 09:16:53 -0700 (PDT) In-Reply-To: <20090629132116.GZ2884@deviant.kiev.zoral.com.ua> References: <3bbf2fe10906290458v3d57441ar44c4ed8f36c957f@mail.gmail.com> <3bbf2fe10906290611j683a0ddawbd524e406e832d54@mail.gmail.com> <20090629132116.GZ2884@deviant.kiev.zoral.com.ua> Date: Mon, 29 Jun 2009 20:16:52 +0400 Message-ID: From: pluknet To: Kostik Belousov Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Attilio Rao , freebsd-stable Subject: Re: [nfs] process locks in "bo_wwait" on 6.4 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: Mon, 29 Jun 2009 16:16:55 -0000 2009/6/29 Kostik Belousov : > On Mon, Jun 29, 2009 at 05:18:03PM +0400, pluknet wrote: >> 2009/6/29 Attilio Rao : >> > 2009/6/29 pluknet : >> >> 2009/6/29 Attilio Rao : >> >>> 2009/6/29 pluknet : >> >>>> 2009/6/26 pluknet : >> >>>>> 2009/6/26 pluknet : >> >>>>>> Hello. >> >>>>>> >> >>>>>> While building a module on nfs mounted /usr/src >> >>>>>> I got an unkillable process waiting forever in bo_wwait. >> >>>>> >> >>>>> Small note: iface on NFS server has mtu changed from 1500 to 1450. >> >>>>> Can this be a source of the problem? >> >>>> >> >>>> This is 100% reproducible. Lock in the same place. Any hints? >> >>> >> >>> Can you also show the value of ps? >> >>> A precise map of what processes are doing would give an help. >> >>> Also would be useful to printout traces for other threads and not only >> >>> the stucked one. >> >>> >> >> >> >> >From another run: >> > >> > I'm unable to see who would be locking the buffer object in question. >> > Do you have INVARIANT_SUPPORT/INVARIANTS on? >> >> Yes, I do both. >> >> > What revision of /usr/src/sys/kern/vfs_bio.c are you running with? >> > >> >> As of 6.4-R: CVS rev 1.491.2.12.4.1 / SVN rev 183531. > > It seems that your changes of MTU cause nfs requests to never reach > network. bo_wwait is the state where thread waits for all outstanding > i/o on bufobj to drain. > It appears that you are right. I found in tcpdump that nfs client tries to send UDP packets sized in 1500 bytes. 19:40:13.937085 IP (tos 0x0, ttl 64, id 4658, offset 0, flags [+], proto: UDP (17), length: 1500) client.1662412076 > server.nfs: 1472 write fh 1145,216955/1372174 1779 (1779) bytes @ 0 While here I reverted mtu on NFS server back to 1500, then after some seconds "locked up" NFS client box continued to build a module as there were no any locking problems at all. So I understand this as defined behavior. -- wbr, pluknet