Date: Mon, 22 May 2000 14:20:02 -0700 (PDT) From: mike ryan <mike+fbsd@medianstrip.net> To: freebsd-bugs@FreeBSD.org Subject: Re: kern/18756: [PATCH] fxp device causes lockups after suspend/resume Message-ID: <200005222120.OAA98718@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR kern/18756; it has been noted by GNATS.
From: mike ryan <mike+fbsd@medianstrip.net>
To: David Greenman <dg@root.com>
Cc: FreeBSD-gnats-submit@FreeBSD.ORG
Subject: Re: kern/18756: [PATCH] fxp device causes lockups after suspend/resume
Date: Mon, 22 May 2000 17:14:51 -0400
on May 22, David Greenman <dg@root.com> wrote:
> >
> >+ /* don't try to service interrupts when the interface isn't running */
> >+ if ((ifp->if_flags & IFF_RUNNING) == 0) {
> >+ return;
> >+ }
> >+
> > while ((statack = CSR_READ_1(sc, FXP_CSR_SCB_STATACK)) != 0) {
>
> This could be a problem. If an interrupt occurs, it must be acknowledged
> otherwise you'll be stuck in an infinit loop - PCI interrupts are level
> sensitive and must be cleared in the ISR.
the only time i've seen that return executed is when the interrupt
was for another device sharing the same IRQ that happened to have
been resumed first -- in my case, an onboard uhci usb controller.
without the check above, i do get resume lockups in fxp_intr.
i've just been assuming that an fxp can't generate a interrupt
unless it's running. if that's not correct, would it be better to
have a "device suspended" flag in fxp_softc and replace the
statement above to execute the necessary resume code if the device
is still suspended?
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-bugs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200005222120.OAA98718>