Date: Thu, 18 Aug 2005 16:23:58 -0400 From: John Baldwin <jhb@FreeBSD.org> To: Maxim.Sobolev@portaone.com Cc: cvs-src@FreeBSD.org, src-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/dev/re if_re.c Message-ID: <200508181624.00106.jhb@FreeBSD.org> In-Reply-To: <4304E866.3030405@portaone.com> References: <200508181429.j7IET16d038533@repoman.freebsd.org> <200508181538.32988.jhb@FreeBSD.org> <4304E866.3030405@portaone.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thursday 18 August 2005 03:58 pm, Maxim Sobolev wrote: > John Baldwin wrote: > >>Well, see kern/85005. IMO some generic approach should be worked out and > >>implemented since I think many other network drivers may be affected by > >>the same problem. > > > > I've still yet to see what the real panic is. For one thing, if the > > foo_stop method does its jobs, the ethernet hardware shouldn't be > > generating interrupts. The stop method should be shutting the card down > > (i.e. turning off the receiver and transmitter for example). Is your > > ethernet driver sharing an interrupt with another device and the other > > device is > > Yes, this is the case here. It shares interrupt with IDE controller. > Panic happens in the re_rxeof() when the driver tries to dereference > sc->rl_ldata.rl_rx_mbuf[i], which has already been deallocated in the > re_stop(). Ok. > > interrupting? In that case, the ethernet driver would have the same > > panic if you did an 'ifconfig foo0 down' and then the other device > > interrupted. So, I > > No, I don't think it would since 'ifconfig foo0 down' resets IFF_UPP. Ah, yes. > > think clearing IFF_UPP in foo_shutdown() is wrong. foo_stop() should > > really be sufficient, and foo_intr() should be able to handle a spurious > > interrupt while the interface is stopped without panicing since it > > already needs to do so to handle the shared interrupt case. > > Apparently it doesn't handle it, which has been probably masked by the > IFF_UPP check in the re_intr(), so that this problem only happened at > shutdown, when IFF_UPP isn't cleared after re_stop(). Right. I think the better fix is for the driver to check the flag it manages and knows about (IFF_DRV_RUNNING) rather than IFF_UP in its interrupt handler and to revert the change to re_shutdown(). The vr(4) driver should probably be similarly fixed (check RUNNING in interrupt handler and just call stop in its shutdown method). -- John Baldwin <jhb@FreeBSD.org> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200508181624.00106.jhb>