From owner-freebsd-stable@FreeBSD.ORG Mon Mar 2 01:24:24 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B1319106566C for ; Mon, 2 Mar 2009 01:24:24 +0000 (UTC) (envelope-from n-butcher=freebsd-stable=freebsd.org=mmporwnv@fusiongol.com) Received: from smtp12.dentaku.gol.com (smtp12.dentaku.gol.com [203.216.5.74]) by mx1.freebsd.org (Postfix) with ESMTP id 807B68FC15 for ; Mon, 2 Mar 2009 01:24:24 +0000 (UTC) (envelope-from n-butcher=freebsd-stable=freebsd.org=mmporwnv@fusiongol.com) Received: from pat.gol.co.jp ([203.216.1.191] helo=[172.16.1.151]) by smtp12.dentaku.gol.com with esmtpsa (Dentaku) id 1LdwtI-0008Gy-RW; Mon, 02 Mar 2009 10:24:20 +0900 Message-ID: <49AB3544.6000008@fusiongol.com> Date: Mon, 02 Mar 2009 10:24:20 +0900 From: Nathan Butcher User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Bengt Ahlgren References: <49A61894.5040804@fusiongol.com> <20090226045340.GC70144@weongyo.cdnetworks.kr> <49A74A21.1050109@freebsd.org> <20090227035532.GC72273@weongyo.cdnetworks.kr> In-Reply-To: X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV GOL (outbound) X-Abuse-Complaints: abuse@gol.com Cc: freebsd-stable@freebsd.org, Sam Leffler , Weongyo Jeong Subject: Re: ural driver stalls under FreeBSD7.1 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2009 01:24:25 -0000 Bengt Ahlgren wrote: > Weongyo Jeong writes: > >> On Thu, Feb 26, 2009 at 06:04:17PM -0800, Sam Leffler wrote: >>> Bengt Ahlgren wrote: >>>> Weongyo Jeong 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 -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.