From owner-freebsd-stable@FreeBSD.ORG Fri Feb 27 14:19:04 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 95C40106566B; Fri, 27 Feb 2009 14:19:04 +0000 (UTC) (envelope-from bengta@P142.sics.se) Received: from sink.sics.se (sink.sics.se [193.10.64.88]) by mx1.freebsd.org (Postfix) with ESMTP id 3B8478FC17; Fri, 27 Feb 2009 14:19:04 +0000 (UTC) (envelope-from bengta@P142.sics.se) Received: from P142.sics.se (P142.sics.se [193.10.66.253]) by sink.sics.se (8.14.3/8.14.3) with ESMTP id n1REIdFe045569 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 27 Feb 2009 15:18:40 +0100 (CET) (envelope-from bengta@P142.sics.se) Received: from P142.sics.se (localhost [127.0.0.1]) by P142.sics.se (8.14.3/8.14.3) with ESMTP id n1REL83s002558; Fri, 27 Feb 2009 15:21:08 +0100 (CET) (envelope-from bengta@P142.sics.se) Received: (from bengta@localhost) by P142.sics.se (8.14.3/8.14.3/Submit) id n1REL6ZS002557; Fri, 27 Feb 2009 15:21:07 +0100 (CET) (envelope-from bengta@P142.sics.se) To: Weongyo Jeong From: Bengt Ahlgren In-Reply-To: <20090227035532.GC72273@weongyo.cdnetworks.kr> (Weongyo Jeong's message of "Fri\, 27 Feb 2009 12\:55\:32 +0900") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (berkeley-unix) References: <49A61894.5040804@fusiongol.com> <20090226045340.GC70144@weongyo.cdnetworks.kr> <49A74A21.1050109@freebsd.org> <20090227035532.GC72273@weongyo.cdnetworks.kr> Date: Fri, 27 Feb 2009 15:21:06 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Nathan Butcher , Sam Leffler , freebsd-stable@freebsd.org 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: Fri, 27 Feb 2009 14:19:05 -0000 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. Bengt