Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 25 Aug 2002 23:00:38 -0600 (MDT)
From:      "M. Warner Losh" <imp@bsdimp.com>
To:        matt@gsicomp.on.ca
Cc:        freebsd-hackers@FreeBSD.ORG
Subject:   Re: kern/41227: Serial port IRQs cannot be shared when they should be
Message-ID:  <20020825.230038.26740076.imp@bsdimp.com>
In-Reply-To: <011101c24ca4$09296310$1200a8c0@gsicomp.on.ca>
References:  <011101c24ca4$09296310$1200a8c0@gsicomp.on.ca>

next in thread | previous in thread | raw e-mail | index | archive | help
In message: <011101c24ca4$09296310$1200a8c0@gsicomp.on.ca>
            "Matthew Emmerton" <matt@gsicomp.on.ca> writes:
: I'm the originator of the patch in this PR.  The patch allows FreeBSD to
: work with some USR/3Com PCI modems that share IRQs with other system
: devices.

This patch is bogus.  Fast interrupts aren't supposed to be shared and
all bets are off if you try to share them.

: From the PR:
: 
: > Synopsis: Serial port IRQs cannot be shared when they should be
: >
: > State-Changed-From-To: open->feedback
: > State-Changed-By: njl
: > State-Changed-When: Fri Aug 23 17:42:14 PDT 2002
: > State-Changed-Why:
: > Have you discussed this on -hackers or -current?  There are reasons that
: > RF_SHAREABLE is not enabled in sio (in both -current and -stable).
: > The patch is not complete.
: >
: > http://www.freebsd.org/cgi/query-pr.cgi?pr=41227
: 
: Can anyone enlighten me on the reasons for this?  The user of the patch has
: experienced no problems using his PCI modem (sio) concurrently with his USB
: printer (ulpt) when both devices share IRQs.

There's issues with sio and shareable interrupts.  sio really wants to
have its own interrupt so it can do fast interrupts.  With fast
interrupts, it gets much better performance than it gets with non-fast
interrupts.  non-fast interrupts have too much latency to service the
16550 FIFOs.

The posted patch is wrong and shouldn't be applied.  

The solution?

The solution is to allow interrupts to be marked as "I'd like this to
be a fast interrupt" and have the bus make the determination if some
other device might be sharing things with it.  If the bus makes the
determination that the interrupt could be shared, then it shouldn't
allocate it (and the driver should retry with non-fast interrupts if
it can support that as a fallback).  We've been kocking around ideas
on how, exactly, to accomplish this.  I've not had time to code up
prototypes of the solutions yet, mostly because the acpi interrupt
routing stuff isn't quite to where we need it to be to ask the
questions (although jhb has some fixes that might be get us close).
It appears that the sio driver is broken for non-fast interrupts at
the moment for reasons unknown.

Warner

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020825.230038.26740076.imp>