From owner-svn-src-all@FreeBSD.ORG Thu Mar 5 05:31:07 2009 Return-Path: Delivered-To: svn-src-all@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E8229106566C; Thu, 5 Mar 2009 05:31:07 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id 78D938FC12; Thu, 5 Mar 2009 05:31:07 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from phobos.local ([192.168.254.200]) (authenticated bits=0) by pooker.samsco.org (8.14.2/8.14.2) with ESMTP id n255Uxrb092131; Wed, 4 Mar 2009 22:30:59 -0700 (MST) (envelope-from scottl@samsco.org) Message-ID: <49AF6393.6060402@samsco.org> Date: Wed, 04 Mar 2009 22:30:59 -0700 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.13) Gecko/20080313 SeaMonkey/1.1.9 MIME-Version: 1.0 To: "M. Warner Losh" References: <1236218572.1384.19.camel@widget.2hip.net> <20090304.194158.1159134197.imp@bsdimp.com> <1236224629.1384.22.camel@widget.2hip.net> <20090304.210322.1353606728.imp@bsdimp.com> In-Reply-To: <20090304.210322.1353606728.imp@bsdimp.com> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.4 required=3.8 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on pooker.samsco.org Cc: svn-src-head@FreeBSD.org, svn-src-all@FreeBSD.org, src-committers@FreeBSD.org, rnoland@FreeBSD.org Subject: Re: svn commit: r189367 - head/sys/dev/pci X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.5 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: Thu, 05 Mar 2009 05:31:08 -0000 M. Warner Losh wrote: > In message: <1236224629.1384.22.camel@widget.2hip.net> > Robert Noland writes: > : On Wed, 2009-03-04 at 19:41 -0700, M. Warner Losh wrote: > : > In message: <1236218572.1384.19.camel@widget.2hip.net> > : > Robert Noland writes: > : > : On Wed, 2009-03-04 at 13:56 -0700, M. Warner Losh wrote: > : > : > In message: <200903041823.n24INmcc049524@svn.freebsd.org> > : > : > Robert Noland writes: > : > : > : Author: rnoland > : > : > : Date: Wed Mar 4 18:23:48 2009 > : > : > : New Revision: 189367 > : > : > : URL: http://svn.freebsd.org/changeset/base/189367 > : > : > : > : > : > : Log: > : > : > : Extend the management of PCIM_CMD_INTxDIS. > : > : > : > : > : > : We now explicitly enable INTx during bus_setup_intr() if it is needed. > : > : > : Several of the ata drivers were managing this bit internally. This is > : > : > : better handled in pci and it should work for all drivers now. > : > : > : > : > : > : We also mask INTx during bus_teardown_intr() by setting this bit. > : > : > : > : > : > : Reviewed by: jhb > : > : > : MFC after: 3 days > : > : > > : > : > Note: the INTxDIS bit is new in PCI 3.0, and has no effect on earlier > : > : > devices. This should be highlighted in the comments somewhere... > : > : > : > : It is documented in 2.3 as well, I'm not sure about previous versions of > : > : the spec though. > : > > : > It isn't in 2.2, and even after 2.3 it is "optional". > : > : The bit should be unused if it isn't supported by a given piece of > : hardware. If it doesn't do anything, we are no worse off than before. > : I don't think this will cause any harm, only goodness when it is > : supported. > > Yes. I agree. This is just the sort of bit, however, that people > looking for an interrupt storm would latch on to as being just the > ticket... Which is why I suggested a comment... Well, the other risk is that devices that claim strict PCI 2.0, 2.1, or 2.2 compatibility might treat this bit as "undefined" and thus eligible for a SERR condition, or even reassign it for proprietary use. I think that this risk is small, but non-zero. I think that as long as we only manipulate this bit in conjunction with MSI, we should be fine. But yes, it must be stressed that this bit is not some magical cure-all for interrupt storms, nor is it an appropriate mechanism for handling arbitrary interrupts in an interrupt handler. Scott