From owner-cvs-src@FreeBSD.ORG Mon Sep 19 04:39:24 2005 Return-Path: X-Original-To: cvs-src@FreeBSD.org Delivered-To: cvs-src@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 82D8E16A41F; Mon, 19 Sep 2005 04:39:24 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1AD2843D46; Mon, 19 Sep 2005 04:39:24 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost.village.org [127.0.0.1] (may be forged)) by harmony.bsdimp.com (8.13.3/8.13.3) with ESMTP id j8J4d0Vf014511; Sun, 18 Sep 2005 22:39:00 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Sun, 18 Sep 2005 22:39:10 -0600 (MDT) Message-Id: <20050918.223910.51643480.imp@bsdimp.com> To: rik@cronyx.ru From: "M. Warner Losh" In-Reply-To: <432E3252.5060608@cronyx.ru> References: <200509190310.j8J3ALgt095979@repoman.freebsd.org> <432E3252.5060608@cronyx.ru> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.bsdimp.com [127.0.0.1]); Sun, 18 Sep 2005 22:39:00 -0600 (MDT) Cc: cvs-src@FreeBSD.org, src-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/dev/an if_an.c src/sys/dev/arl if_arl_isa.c src/sys/dev/awi if_awi_pccard.c src/sys/dev/cm if_cm_isa.c src/sys/dev/cnw if_cnw.c src/sys/dev/cp if_cp.c src/sys/dev/cs if_cs.c src/sys/dev/ed if_ed.c src/sys/dev/em if_em.c ... X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Sep 2005 04:39:24 -0000 In message: <432E3252.5060608@cronyx.ru> Roman Kurakin writes: : I didn't check what was done for my drivers, but I'll : put situation the other way. At the point we are going : to unregister interrupt handler we have atleast half-stoped : device. This may mean that any coming packet through : if_start would reactivate device or put it to unknown state. : Just as with problem you've tried to fix this is hardly : depend on driver design. IMHO the better aproach is to : set some flag for the interrupt handler that we should only : clear any interrupts and ignore interrupt details. While an addition flag may be necessary to cover all cases, this change is necessary because the interrupt handlers in each of these drivers appears to depend on ifp being allocated and alive. This change fixes the ordering problem. I'm working on a better, more complete solution. These changes are a step in that road. Warner