svn commit: r189367 - head/sys/dev/pci

Scott Long scottl at samsco.org
Wed Mar 4 21:31:08 PST 2009


M. Warner Losh wrote:
> In message: <1236224629.1384.22.camel at widget.2hip.net>
>             Robert Noland <rnoland at FreeBSD.org> writes:
> : On Wed, 2009-03-04 at 19:41 -0700, M. Warner Losh wrote:
> : > In message: <1236218572.1384.19.camel at widget.2hip.net>
> : >             Robert Noland <rnoland at FreeBSD.org> writes:
> : > : On Wed, 2009-03-04 at 13:56 -0700, M. Warner Losh wrote:
> : > : > In message: <200903041823.n24INmcc049524 at svn.freebsd.org>
> : > : >             Robert Noland <rnoland at freebsd.org> 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


More information about the svn-src-all mailing list