Date: Thu, 22 Dec 2005 21:42:57 +0100 From: Andrea Campi <andrea+freebsd_current@webcom.it> To: Sam Leffler <sam@errno.com> Cc: Andrea Campi <andrea+freebsd_current@webcom.it>, current@freebsd.org Subject: Re: Panic and LOR on -CURRENT with ath Message-ID: <20051222204257.GD30118@webcom.it> In-Reply-To: <43AA4415.8070300@errno.com> References: <20051221191919.GB17950@webcom.it> <43A9B5EA.8030905@errno.com> <20051221215457.GE17950@webcom.it> <43AA4415.8070300@errno.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Dec 21, 2005 at 10:13:41PM -0800, Sam Leffler wrote:
> >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.
Yes, now I do remember you mentioning this before. So it looks like this
isn't something I could help with, not unless a significant investment of
time (which I sadly lack). But I might find it in a few months if nobody
gets around to it sooner, as it would make a nice project for a networking
course I have in the next semester.
So basically I either have to live with it or turn off WITNESS, right?
> 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.
Will try switching to pf during the holidays (I've been meaning to do it
but I kept procrastinating, so thanks for giving me an incentive ;-)
Bye,
Andrea
--
Press every key to continue.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20051222204257.GD30118>