Date: Thu, 9 Dec 2004 18:50:23 GMT From: Mike Tancsa <mike@sentex.net> To: freebsd-bugs@FreeBSD.org Subject: Re: misc/74786: Smartlink Modem causes interrupt storm on RELENG_4 and RELENG_5 Message-ID: <200412091850.iB9IoNH3097924@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR kern/74786; it has been noted by GNATS.
From: Mike Tancsa <mike@sentex.net>
To: Bruce Evans <bde@zeta.org.au>
Cc: freebsd-gnats-submit@freebsd.org, freebsd-stable@freebsd.org
Subject: Re: misc/74786: Smartlink Modem causes interrupt storm on
RELENG_4 and RELENG_5
Date: Thu, 09 Dec 2004 13:43:32 -0500
[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?200412091850.iB9IoNH3097924>