Once the interrupt line is shared with PCI semantics, the handler chain no
longer qualifies as "fast".
> Seems to me you are blaming SCSI low-level drivers without naming them.
> The IRQ latency problem we observe in the SCSI layer is not the fault of
> SCSI low-level drivers. Their _own_ interrupt code is generally _fast_,
> as all interrupt code is required to be on a serious O/S.
Yes, SCSI drivers are prime offenders. Many SCSI drivers use "fast"
interrupt handlers and then do a bunch of work in the interrupt handler.
(SCSI bus resets, disconnects, etc.)
The SCSI drivers have been a big support headache for me. Since they are
initialized first they grab the interrupt with SA_INTERRUPT. Most people
don't understand the resulting error, and those that do blame the Ethernet
driver for not being willing to share the interrupt.
> Your flames about IRQ handling hasn't have the effect you expected for the
> simple reason they were not targetted to the right persons. It was a
> kernel architecture issue and a SCSI generic layer driver issue and you
> flames always were against the low-level drivers that were exactly the
> _wrong_ target with regards to the problem.
??? I don't see that -- I still see it as a low-level driver issue. Don't
use SA_INTERRUPT. The higher level issue is that you might want to restructure
everything into a SCSI_BH manner. But even then, don't use SA_INTERRUPT.
Donald Becker becker@cesdis.gsfc.nasa.gov
USRA-CESDIS, Center of Excellence in Space Data and Information Sciences.
Code 930.5, Goddard Space Flight Center, Greenbelt, MD. 20771
301-286-0882 http://cesdis.gsfc.nasa.gov/people/becker/whoiam.html
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/