ural driver stalls under FreeBSD7.1

[Sam Leffler]

Bengt Ahlgren wrote:
> Weongyo Jeong <weongyo.jeong at gmail.com> writes:
>
>   
>> On Thu, Feb 26, 2009 at 06:04:17PM -0800, Sam Leffler wrote:
>>     
>>> Bengt Ahlgren wrote:
>>>       
>>>> Weongyo Jeong <weongyo.jeong at gmail.com> writes:
>>>>  
>>>>         
>>>>> On Thu, Feb 26, 2009 at 01:20:36PM +0900, Nathan Butcher wrote:
>>>>>    
>>>>>           
>>>>>> I have a Buffalo WLI-U2-KG54-AI wireless USB adaptor.
>>>>>> It has been malfunctioning for quite a while under FreeBSD7.0 and 7.1
>>>>>>
>>>>>> Typically, It works for a while until eventually it stalls data
>>>>>> transfers completely. It always seems to do this after an unspecified
>>>>>> amount of time.
>>>>>>
>>>>>> I know the hardware isn't at fault because the device works fine under
>>>>>> Linux.
>>>>>>      
>>>>>>             
>>>>> Could you please check that `ifconfig <ifname> -bgscan' disabling the
>>>>> background scan helps your symptom?
>>>>>           
>>>> The above sounds like the same problem as this:
>>>>
>>>> http://lists.freebsd.org/pipermail/freebsd-mobile/2009-February/011376.html
>>>> http://lists.freebsd.org/pipermail/freebsd-mobile/2009-February/011343.html
>>>>
>>>> The problem is in the background scanning logic in sys/net80211.
>>>>         
>>> I don't see how you come to this conclusion.  ural is a totally 
>>> different driver than ath and so far as I can recall you never found the 
>>> cause for your problem w/ ath.  Most of the usb wireless drivers do a 
>>> haphazard job of synchronizing async tasks like bg scan with the 
>>> foreground tx/rx processing.  This can lead to firmware and/or usb 
>>> issues.  ath does not have these issues but I am aware of at least one 
>>> problem w/ bg scanning in ath under RELENG_7 (that is not present in HEAD).
>>>       
>> I agree with sam because I saw some cases like stalls during background
>> scanning that most of them I think it's caused by H/W miss-operation or
>> miss-configuration by mistakes of driver.
>>     
>
> Looking into if_ural (1.69.6.1 - 7.1R version), it partly has the same
> calls to net80211 which causes problems for ath.
>
> At line 1477, it has the same test as ath has to check for bg
> scanning:
>
> 			if (ic->ic_flags & IEEE80211_F_SCAN)
> 				ieee80211_cancel_scan(ic);
>
> That means that ieee80211_cancel_scan won't be called in the window
> between when scan_next is run (which resets IEEE80211_F_SCAN), and
> ieee80211_bg_scan is called the next time (setting IEEE80211_F_SCAN
> again).  This is the same problem as ath has.
>
> But I can't find that ural calls ieee80211_pwrsave to queue packets if
> a bgscan was running.  It seems that it just merrily tries to send
> packets despite scanning is going on.
>
> Please note that even though ieee80211_cancel_scan IS called, that
> won't take effect until the next clock tick.  So if the output routine
> just carries on with sending a packet, it will do so in the middle of
> the scan.  This is something that should be fixed in net80211.
>
> So, I find that ural also suffers from the problem with the scanning
> logic in net80211.
>   
It appears RELENG_7's scanning code lacks the locking that's in HEAD to 
guard against the race you describe.

    Sam