On Wed, 2009-03-04 at 22:30 -0700, Scott Long wrote: > M. Warner Losh wrote: > > In message: <1236224629.1384.22.ca...@widget.2hip.net> > > Robert Noland <rnol...@freebsd.org> writes: > > : On Wed, 2009-03-04 at 19:41 -0700, M. Warner Losh wrote: > > : > In message: <1236218572.1384.19.ca...@widget.2hip.net> > > : > Robert Noland <rnol...@freebsd.org> writes: > > : > : On Wed, 2009-03-04 at 13:56 -0700, M. Warner Losh wrote: > > : > : > In message: <200903041823.n24inmcc049...@svn.freebsd.org> > > : > : > Robert Noland <rnol...@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.
I'm happy to add a comment, I'm just not certain what that comment should be. I don't find where it is marked as optional in the 2.3 spec, though I do find the part about interrupt pins being optional... robert. > Scott -- Robert Noland <rnol...@freebsd.org> FreeBSD
signature.asc
Description: This is a digitally signed message part
