Re: Panic and LOR on -CURRENT with ath

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