From owner-cvs-all@FreeBSD.ORG Fri Sep 16 21:15:04 2005 Return-Path: X-Original-To: cvs-all@FreeBSD.org Delivered-To: cvs-all@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F24F716A41F; Fri, 16 Sep 2005 21:15:03 +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 8E66343D46; Fri, 16 Sep 2005 21:15:03 +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 j8GLCmjd053323; Fri, 16 Sep 2005 15:12:48 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Fri, 16 Sep 2005 15:13:01 -0600 (MDT) Message-Id: <20050916.151301.122028383.imp@bsdimp.com> To: ru@FreeBSD.org From: "M. Warner Losh" In-Reply-To: <20050916202207.GA22151@ip.net.ua> References: <20050916194405.GB24879@ip.net.ua> <20050916.135841.130619528.imp@bsdimp.com> <20050916202207.GA22151@ip.net.ua> 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]); Fri, 16 Sep 2005 15:12:49 -0600 (MDT) Cc: cvs-src@FreeBSD.org, src-committers@FreeBSD.org, cvs-all@FreeBSD.org, jhb@FreeBSD.org Subject: Re: cvs commit: src/sys/dev/re if_re.c X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Sep 2005 21:15:04 -0000 In message: <20050916202207.GA22151@ip.net.ua> Ruslan Ermilov writes: : Hmm, I'm not very fluent in device(9) API, but I wonder what's then : the analog of device_delete_child(sc->miibus) that the majority of : foo_detach() methods do. I.e., will the miibus device really be : removed? Yes. I believe so. : > How again can this happen? : > : tcpdump -n -i ed0 & : kldunload if_ed : : Still, ed_init_locked() will instantiate many things inappropriate : for ed_detach() context. How does ed_init_locked get called in ed_detach()? It looks to me that ed_stop is called, but ed_init() isn't. Where would it be called? : When experimenting with removing device_delete_child(sc->miibus) : in rl(4), every new kldunload/kldload will add another miibusX : device, showing that the child device removal doesn't happen : implicitly. I wonder if you can see the same with ed(4), or : if there's some code that does this. Also, the code that you : refer seems to only work for pccard, while PCI version should : be affected by the same "mii == NULL" bug. There's no ed + mii + pci. I'll take a look at these details tonight. Warner