On Thu, 2014-03-06 at 09:57 -0600, Larry Finger wrote:
> On 03/05/2014 01:16 PM, Thierry Moreau wrote:
> > On 03/05/14 16:40, Larry Finger wrote:
> >>
> >> Please give me the exact set of commands you use to get this problem. If
> >> possible, capture the console output. As I am currently running
> >> long-term tests of the latest version of rtl8192ce using an RTL8188CE
> >> (10ec:8176), it will be a perfect time to test.
> >>
> >
> > Here is the command script, and the console log
> > (....sh 2>&1 | tee ....log)
> >
> > Is it possible that the Shuttle system be arranged with a digital output
> > enabling/inhibiting the Realtek wifi interface active participation in wifi
> > protocol?
> >
> > I did ask Shuttle tech support, but in any event I don't want to induce you to
> > troubleshoot a specific system.
>
> The problem is not specific to the Shuttle - I can reproduce it on my HP laptop.
> Furthermore, it affects other mac80211-based drivers. The EBUSY return comes out
> of mac80211/cfg80211/nl80211 code.
I deleted the earlier bits of this thread after skimming it, but IIRC
we're talking about scanning here right? If there's already a scan
in-progress, then the stack can often return EBUSY.
For example, from both cfg80211_wext_siwscan() and
nl80211_trigger_scan(), used by 'iwlist' and 'iw' respectively:
if (rdev->scan_req) {
err = -EBUSY;
goto out;
}
Scans do not get canceled just because another random scan request comes
in. Whatever userspace there is needs to wait for a scan completion
event and then request it's new scan. There are also stack internal
scans that happen from time to time that may cause a user-requested scan
to return EBUSY.
(NM hands this all off to wpa_supplicant, which itself handles the EBUSY
by waiting a bit and then requesting another scan.)
Dan
--
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
