Panic and LOR on -CURRENT with ath
Sam Leffler
sam at errno.com
Wed Dec 21 22:12:39 PST 2005
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
More information about the freebsd-current
mailing list