On Mon, Nov 8, 2010 at 11:40 AM, Mark Mentovai <mark@xxxxxxxxxxxx> wrote: > Following up on the old-ish â[ath5k-devel] Race condition in CRDA calls?â threadâ > > I independently experienced this problem, debugged it, and came to the same conclusion. There is in fact a race between regulatory requests being made via regulatory_hint and CRDA actually updating regulatory data. I see this on a system with two cards that come up one after the other during boot. > > 1. cfg80211 calls CRDA to update the world regulatory domain and CRDA does so. The regulatory domain is now 00. > > 2. The first cardâs driver (in my case, ath9k) calls regulatory_hint to provide US as a driver hint. ignore_request decides against intersection because the last request came from the core. Thereâs a CRDA call, but CRDA isnât quick enough to respond. The regulatory domain is still 00, because CRDA hasnât changed it yet. > > 3. The second cardâs driver (also ath9k) calls regulatory_hint to provide US as a driver hint. ignore_request sees that the last request came from a driver (instead of the core) and since the regulatory domain is changing from 00 to US, decides that intersection must be performed. > > 4. When CRDA finally responds to the request from #2 or #3, cfg80211 sees that last_request->intersect is true, and intersects. The regulatory domain is set to the intersection of 00 and US. > > The race here is between CRDA providing data and the second cardâs request being made via regulatory_hint. regulatory_hint and ignore_request assume that last_request is in sync with the currently-set regulatory domain, but there is no such synchronization. > > Hereâs my openwrt-devel post describing the above in a slightly different level of detail:https://lists.openwrt.org/pipermail/openwrt-devel/2010-November/008570.html.-- I'll take a look at this once I get done with the compat-wireless-2.6.37 release. Thanks for the report. Luis -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
