Date: Wed, 21 Dec 2005 22:13:41 -0800 From: Sam Leffler <sam@errno.com> To: Andrea Campi <andrea@webcom.it> Cc: Andrea Campi <andrea+freebsd_current@webcom.it>, current@freebsd.org Subject: Re: Panic and LOR on -CURRENT with ath Message-ID: <43AA4415.8070300@errno.com> In-Reply-To: <20051221215457.GE17950@webcom.it> References: <20051221191919.GB17950@webcom.it> <43A9B5EA.8030905@errno.com> <20051221215457.GE17950@webcom.it>
next in thread | previous in thread | raw e-mail | index | archive | help
Andrea Campi wrote: > Sam, > > On Wed, Dec 21, 2005 at 12:07:06PM -0800, Sam Leffler wrote: > >>This is a driver lock held across an ioctl that does copyout and the >>destination faults. I've tried to get people to buy into a solution to >>the general problem w/o luck. > > > Does this only need someone to sit down and code a solution, or is that > a broader and not only technical issue? It's a design issue with implications. The net80211 ioctl code is typically invoked from drivers w/ the driver lock held to guard against changes in state used by code that is invoked from an interrupt thread. But once inside net80211 there's no way to release the lock around calls like copyout. I've suggested exposing the driver lock to the net80211 layer so it can unlock+relock but gotten zero response so the problem remains. A concern is whether doing this forces driver locking into a particular model that is undesirable. This issue is really caused by the confusion in drivers over who is responsible for locking net80211 state. The net80211 layer handles the major pieces itself but some small bits are still implicitly handled by single-threading the rx path. Drivers that use the driver lock on the rx path must thus hold it over ioctl; other drivers do not except they cannot tell if an ioctl interacts with the rx path. > > >>It appears the mbuf was reclaimed while sitting on the tx queue waiting >>to be reaped. I've seen a few complaints of this sort but never enough >>info to start looking. This problem seems to be common to soekris h/w >>or perhaps this general config which is common on soekris h/w. Knowing >>the configuration might be useful; e.g. bridged config? what packet >>filter package? network setup? > > > Nope, no bridging; this is nanobsd with a GENERIC kernel minus a lot of > stuff plus ipfw (which I also use for NAT). Nothing fancy really. It's > not even under any high load. > > Is there anything I can investigate from DDB? The info you want is gone by the time the crash happens. Last time I chased a similar problem I did some private hacks to write-protect mbufs to catch unexpected modification. You might try removing ipfw or using an alternate packet filter if that's feasible. I wouldn't be surprised if this is related to ipfw and/or divert sockets. Sam
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?43AA4415.8070300>