From owner-svn-src-stable@FreeBSD.ORG Mon Apr 29 05:38:03 2013 Return-Path: Delivered-To: svn-src-stable@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 3D254FAA; Mon, 29 Apr 2013 05:38:03 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-ee0-f54.google.com (mail-ee0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id 4DE33171E; Mon, 29 Apr 2013 05:38:01 +0000 (UTC) Received: by mail-ee0-f54.google.com with SMTP id e49so1309356eek.27 for ; Sun, 28 Apr 2013 22:37:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:sender:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=oJqvGfyAEwYas6OfWleVoN/fVXQ5kfiFeeF4nEadXO0=; b=KdyU/6aB9y+1anPLwmq1nPaaseF7eQZjk16UMel6c2+5rG34BHrZxLKWcVyivj5YF0 6uyc9xxqBC3fXvT8tv5wYHZJvMFqTQvij3cQdeUvsFAIQJQIyQpjNHh5r2s1TKiCnyu+ 2j+bLdVcqOZYNUMj+EOqOZgf8wwl8x0ULuPE/QHuDgIwrAtiTta/xDxeNNOF+bfRHyrD PrAoDGSCD5igGJGUeIf2+K3Crr3+6OVm9mAQSJPQzbpff5tshqrypXvuFQcQDePnSYXX yjX60i2sylq75ZfwokMsb2yye/AR0MGuMKikEDmtqbSlpPkk9/IrvuNg8NSCpdrOLHd0 q2jQ== X-Received: by 10.15.24.68 with SMTP id i44mr30721284eeu.19.1367213875572; Sun, 28 Apr 2013 22:37:55 -0700 (PDT) Received: from mavbook.mavhome.dp.ua (mavhome.mavhome.dp.ua. [213.227.240.37]) by mx.google.com with ESMTPSA id ch6sm30701753eeb.17.2013.04.28.22.37.52 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 28 Apr 2013 22:37:54 -0700 (PDT) Sender: Alexander Motin Message-ID: <517E072F.2030006@FreeBSD.org> Date: Mon, 29 Apr 2013 08:37:51 +0300 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130413 Thunderbird/17.0.5 MIME-Version: 1.0 To: Peter Wemm Subject: Re: svn commit: r249611 - in stable/9/sys/cam: ata scsi References: <201304180944.r3I9i05t093967@svn.freebsd.org> <517AC0BB.4040207@FreeBSD.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: svn-src-stable@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, svn-src-stable-9@freebsd.org X-BeenThere: svn-src-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: SVN commit messages for all the -stable branches of the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Apr 2013 05:38:03 -0000 On 29.04.2013 04:29, Peter Wemm wrote: > On Sat, Apr 27, 2013 at 5:56 PM, Peter Wemm wrote: >> On Fri, Apr 26, 2013 at 11:00 AM, Alexander Motin wrote: >>> On 26.04.2013 19:47, Peter Wemm wrote: >>>> >>>> On Thu, Apr 18, 2013 at 2:44 AM, Alexander Motin wrote: >>>>> >>>>> Author: mav >>>>> Date: Thu Apr 18 09:44:00 2013 >>>>> New Revision: 249611 >>>>> URL: http://svnweb.freebsd.org/changeset/base/249611 >> [..] >>>> This breaks a number of machines in the freebsd.org cluster. I have >>>> to back out both of these changes to get them to reboot. >>> >>> >>> I've made a search though the base system and found only two drivers >>> affected by this change: mpt and hptmv. I've patched both at head r249849 >>> and going to merge fix to stable/9 tomorrow unless objected. Have you tried >>> that patch instead of reverting? >> >> I'm testing this on ns1.freebsd.org and ns2.freebsd.org as we speak. >> If the cluster goes dark, that's why :) > > The machines have survived multiple reboots with > r249849. Thank you. > I do wonder if perhaps "post_sync" isn't the ideal name. Perhaps add > a "quiesce_hardware" eventhandler chain and make it clear that this is > the hook for what things like mpt were doing. It is only one specific case, but I am not sure that mpt is doing the right thing. According to the commit log, interrupts are disabled to prevent new incoming target commands. But may be it could/should be blocked in some other way. What worries me more is that I've just rediscovered that post_sync handlers are called even in case of panic, when no FS sync happens at all. Is it wise to touch random subsystems is state when nothing can be trusted? I've recalled that earlier I've even added checks to CAM ATA disk driver to not recurse lock in case of panic, but that IMO is a dirty hack. -- Alexander Motin