Re: PCI SIO devices hog interrupts, cause lock order problems

On Mon, 30 Aug 2004, M. Warner Losh wrote:

> In message: <012301c48e25$14924180$84cba8c0_at_hh.kew.com>
>             "Andrew H. Derbyshire" <ahd_at_kew.com> writes:
> : Basically, any PCI SIO device hogs its interrupt if the PUC device is not
> : also in the kernel, and this causes real problems for any environment like
> : mine where pulling the modem is not trivial.

This seems to be just the old bug that interrupt attributes are wired
at bus_setup_intr() time, but that time is too early for at least the
INTR_FAST attribute because the best possible wiring depends on the
set of devices that is actively using the interrupt.  (This set may
grow as more devices are attached; it should also shrink as devices
are attached, and it should be fully dynamic so that inactive devices
don't pessimize the interrupt wiring of active ones.)

sio just attempts to set up the interrupt using INTR_FAST because that
is best for it.  If this fails, then sio tries again without INTR_FAST.
The fallback only helps if, if some (non-sio) device on the interrupt
can't handle INTR_FAST, then at least one such device is wired to the
interrupt before any (not necessarily sio) device asks for the interrupt
to be wired as INTR_FAST.

Using puc works around the problem by breaking setup of the interrupt
using INTR_FAST more deterministically provided PUC_FASTINTR is not
used.  This depends on the magic and arguably broken ordering of puc
and pci-sio attachment -- it depends on puc being attached first, but
perhaps pci-sio should be first since it is less generic and more
efficient for the small set of hardware that it handles.

The cy driver works around the problem in a different way: INTR_FAST
is not tried by default, but the CY_PCI_FASTINTR option forces it to
be tried first with a fallback to !INTR_FAST in the same way as in
sio.  Thus the default is fail-safe but pessimal for cy.  The default
is fail-unsafe for sio mainly for historical reasons.

> Does the distributed GENERIC
> : kernel have room for the PUC device?  Are there side effects that PUC should
> : be excluded from GENERIC?
>
> puc should be in GENERIC, imho.

I agree.  It is too large due to its sparse data structures, but since the
sparse data compresses very well, it doesn't take any more space on
boot media than most drivers in GENERIC.

Bruce