Date: Mon, 19 Sep 2005 08:31:11 -0600 (MDT) From: "M. Warner Losh" <imp@bsdimp.com> To: ru@freebsd.org Cc: cvs-src@freebsd.org, src-committers@freebsd.org, cvs-all@freebsd.org Subject: Re: cvs commit: src/sys/dev/ed if_ed.c if_ed_pccard.c if_edvar.h Message-ID: <20050919.083111.123550990.imp@bsdimp.com> In-Reply-To: <20050919054051.GB65954@ip.net.ua> References: <200509182051.j8IKpYGU073493@repoman.freebsd.org> <20050919054051.GB65954@ip.net.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
In message: <20050919054051.GB65954@ip.net.ua>
Ruslan Ermilov <ru@freebsd.org> writes:
: About the commonality... Usually foo_stop() (which is called first in
: foo_detach() if you were talking about the detach) disables interrupts,
: so foo_intr() doesn't usually happen. From reading the code, I see the
: same holds true for ed(4).
Wrong. Foo_intr() does still happen because other devices can
generate interrupts...
: OTOH, it was shown that on some SMP machines it's possible to get a
: call to foo_intr() after foo_stop() has been called by foo_shutdown(),
: which will lead to a panic in most of the drivers. See kern/85005 and
: kern/62889 for some examples.
:
: I think the generic solution to this problem should be to return from
: foo_intr() quickly if IFF_DRV_RUNNING is not set.
Only if we free ifp after we tear down the interrupts.
Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050919.083111.123550990.imp>