Date: Thu, 09 Dec 2004 13:43:32 -0500 From: Mike Tancsa <mike@sentex.net> To: Bruce Evans <bde@zeta.org.au> Cc: freebsd-stable@freebsd.org Subject: Re: misc/74786: Smartlink Modem causes interrupt storm on RELENG_4 and RELENG_5 Message-ID: <6.2.0.14.0.20041209133753.0403b0c8@64.7.153.2> In-Reply-To: <20041208172619.Y1156@epsplex.bde.org> References: <200412062027.iB6KR1jE096684@www.freebsd.org> <20041207085811.P6480@epsplex.bde.org> <6.2.0.14.0.20041207100615.0335e328@64.7.153.2> <20041208172619.Y1156@epsplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
[cc'ing to FreeBSD-Stable]
Hi,
I know that the proposed patches I submitted are not the best patches, but
given that the next release of RELENG_4 is coming out, would it not be
better to commit those to RELENG_4 as they allow the modem to work when it
shares an interrupt with another device ? The sio and interrupt handling
code in RELENG_5 is different enough that I doubt the patches you are
proposing would make it back to RELENG_4. This at least lets the modem
work and prevents the machine from locking up in an interrupt storm on
RELENG_4 without breaking any functionality (as far as I know).
---Mike
At 02:22 AM 08/12/2004, Bruce Evans wrote:
>I think I understand this now. sio can indeed drive the interrupt (after
>you open an sio device, but not immediately at the end of the attach
>except in the serial console case). The main bugs are:
>1. sio asks for exclusive access to the interrupt for no good reason
> (some buses like isa might only support exclusive accesses, but sio
> doesn't care). uhci gets access first in your configuration, so
> allocation of the interrupt resource fails.
>2. Error handling for the failure in (1) is null, so both devices are
> "successfully" attached.
>3. sio sets a flag to tell it to use polling if there is no interrupt
> resource, but it doesn't set the flag if the interrupt resource
> couldn't be allocated or if the interrupt couldn't be set up.
>4. Upper layers provide negative help for debugging (3) using their
> own version of (3). They print "irq N" in boot messages if an
> interrupt resource justs exists. This doesn't mean that the device
> is using it.
>5. Device interrupts are still enabled in polling mode. This depends
> on nothing else sucessfully setting up the (shared) interrupt.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?6.2.0.14.0.20041209133753.0403b0c8>