Date: Mon, 02 Mar 2009 10:24:20 +0900 From: Nathan Butcher <n-butcher@fusiongol.com> To: Bengt Ahlgren <bengta@sics.se> Cc: freebsd-stable@freebsd.org, Sam Leffler <sam@freebsd.org>, Weongyo Jeong <weongyo@freebsd.org> Subject: Re: ural driver stalls under FreeBSD7.1 Message-ID: <49AB3544.6000008@fusiongol.com> In-Reply-To: <uh7d4d4rmel.fsf@P142.sics.se> References: <49A61894.5040804@fusiongol.com> <20090226045340.GC70144@weongyo.cdnetworks.kr> <uh7hc2h13a7.fsf@P142.sics.se> <49A74A21.1050109@freebsd.org> <20090227035532.GC72273@weongyo.cdnetworks.kr> <uh7d4d4rmel.fsf@P142.sics.se>
next in thread | previous in thread | raw e-mail | index | archive | help
Bengt Ahlgren wrote: > Weongyo Jeong <weongyo.jeong@gmail.com> writes: > >> On Thu, Feb 26, 2009 at 06:04:17PM -0800, Sam Leffler wrote: >>> Bengt Ahlgren wrote: >>>> Weongyo Jeong <weongyo.jeong@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. ...and turning bgscan off, as per Jeong's advice has solved the problem for me. So yes, background scanning is responsible for the hangs in ural.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?49AB3544.6000008>