Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 23 Jun 2009 17:58:07 -0400
From:      John Baldwin <jhb@freebsd.org>
To:        Marius Strobl <marius@alchemy.franken.de>
Cc:        svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, yongari@freebsd.org
Subject:   Re: svn commit: r194763 - in head/sys: conf dev/gem modules/gem
Message-ID:  <200906231758.07994.jhb@freebsd.org>
In-Reply-To: <20090623211342.GJ71667@alchemy.franken.de>
References:  <200906232036.n5NKax9O089354@svn.freebsd.org> <200906231703.20496.jhb@freebsd.org> <20090623211342.GJ71667@alchemy.franken.de>

next in thread | previous in thread | raw e-mail | index | archive | help
On Tuesday 23 June 2009 5:13:42 pm Marius Strobl wrote:
> On Tue, Jun 23, 2009 at 05:03:20PM -0400, John Baldwin wrote:
> > On Tuesday 23 June 2009 4:36:59 pm Marius Strobl wrote:
> > > Author: marius
> > > Date: Tue Jun 23 20:36:59 2009
> > > New Revision: 194763
> > > URL: http://svn.freebsd.org/changeset/base/194763
> > > 
> > > Log:
> > >   - Initialize the ifnet structure, especially if_dname, before probing
> > >     the PHYs as some PHY drivers use it (but probably shouldn't). How
> > >     gem(4) has worked with brgphy(4) on powerpc without this so far is
> > >     unclear to me.
> > >   - Introduce a dying flag which is set during detach and checked in
> > >     gem_ioctl() in order to prevent active BPF listeners to clear
> > >     promiscuous mode which may lead to the tick callout being restarted
> > >     which will trigger a panic once it's actually gone.
> > 
> > This should not be needed assuming you follow a model of:
> > 
> > gem_detach()
> > {
> > 
> > 	ether_ifdetach(ifp);	/* calls bpfdetach() */
> > 	GEM_LOCK(sc);
> > 	gem_stop(sc);
> > 	GEM_UNLOCK(sc);
> > 	...
> > }
> > 
> > If you are invoking gem_stop() prior to ether_ifdetach() then that is your 
> > real bug. :)
> > 
> 
> Okay, I'll let yongari@ comment on this as he was the one
> who claimed that either clearing IFF_UP in the driver before
> calling ether_ifdetach(9) (which I think is a layering
> violation) or the committed approach is necessary in order
> to solve the problem :)

I don't think one needs to clear IFF_UP explicitly.  if_detach() will 
if_down() the interface as parts of its internal teardown.

-- 
John Baldwin



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200906231758.07994.jhb>