Re: rtlwifi (rtl8192ce) consistently reports EBUSY error, but scanning works

[Dan Williams <dcbw@redhat.com>]

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