Bob Copeland wrote:
> On Tue, Apr 14, 2009 at 01:48:55PM -0700, Ben Greear wrote:
>> =======================================================
>> [ INFO: possible circular locking dependency detected ]
>> 2.6.29.1c3 #20
>> -------------------------------------------------------
>> ip/3220 is trying to acquire lock:
>> (&ifsta->work){--..}, at: [<c0135c9f>] __cancel_work_timer+0x3f/0x190
>>
>> but task is already holding lock:
>> (rtnl_mutex){--..}, at: [<c032d71f>] rtnl_lock+0xf/0x20
>
> Lock order between cfg80211 mutex and rtnl it seems... Hmm, was that
> before or after the change to cfg80211_get_dev_from_ifindex()?
It's 2.6.29.1 plus the patches I attached.
>> ath5k phy0: noise floor calibration failed (2462MHz)
>> BUG: soft lockup - CPU#0 stuck for 61s! [iwconfig:24158]
>> Modules linked in: michael_mic ath5k mac80211 cfg80211 nfs lockd auth_rpcgss
>> 8021q garp stp llc nf_d]
>
> I guess this is the noise floor calibration loop called from the
> reset workqueue? I had a patch a while ago to spinlock reset calls but
> I think the lock was too big of a hammer. Having a spinlock around
> ath5k_hw_* may be a good idea though, especially with lots of vifs.
It seems noise floor calibration is always printed before this panic,
so likely they are related. I haven't looked any farther at this point.
>>>> modprobe ath5k with nohwaccel=1 (I think that's the name...test system is
>>> nohwcrypt=1... but it would be nice if we swapped in/out keys into the
>>> hw crypto key cache based on vif.
>> Seems the HW hashes on the AP's MAC, and so if you have multiple VIFS
>> associated with the same AP, it breaks. This is from memory,
>> so I could be wrong here.
>
> Hmm, good point. Just curious, what's the use case for multiple virtual
> stations associated with the same AP?
We make test equipment, and want to emulate lots of client stations hitting
an AP (or group of APs on the same channel). We have already patched the
kernel to allow one interface to send to another, so we can have the two
VIFS talking to each other using tcp, udp, etc.
Thanks,
Ben
--
Ben Greear <gree...@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
_______________________________________________
ath5k-devel mailing list
ath5k-devel@lists.ath5k.org
https://lists.ath5k.org/mailman/listinfo/ath5k-devel
