From owner-freebsd-current@FreeBSD.ORG Tue Sep 29 20:08:07 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B7455106568B for ; Tue, 29 Sep 2009 20:08:07 +0000 (UTC) (envelope-from lstewart@freebsd.org) Received: from lauren.room52.net (lauren.room52.net [210.50.193.198]) by mx1.freebsd.org (Postfix) with ESMTP id 58E258FC14 for ; Tue, 29 Sep 2009 20:08:06 +0000 (UTC) Received: from lstewart-laptop.caia.swin.edu.au (user-64-9-232-221.googlewifi.com [64.9.232.221]) (authenticated bits=0) by lauren.room52.net (8.14.3/8.14.3) with ESMTP id n8TJUXbh076245 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 30 Sep 2009 05:30:39 +1000 (EST) (envelope-from lstewart@freebsd.org) Message-ID: <4AC26052.7010303@freebsd.org> Date: Tue, 29 Sep 2009 12:30:26 -0700 From: Lawrence Stewart User-Agent: Thunderbird 2.0.0.23 (X11/20090909) MIME-Version: 1.0 To: Poul-Henning Kamp References: <86051.1254232666@critter.freebsd.dk> In-Reply-To: <86051.1254232666@critter.freebsd.dk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,RDNS_DYNAMIC, SPF_SOFTFAIL autolearn=disabled version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on lauren.room52.net Cc: current@freebsd.org Subject: Re: if_rum dies on transmit... X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Sep 2009 20:08:07 -0000 Poul-Henning Kamp wrote: > Has anybody else seen if_rum die when you try to transmit a file over > a TCP connection ? > > If I try to print across the network, upload a file with ftp or anything > else of that general tenor, if_rum seems to hang the output queue and > stops transmitting packets. Yes I see the same thing with my D-LINK DWA-110 USB stick which shows up as a rum device. According to Sam who had a quick look at the issue for me when I first noticed it, the rum driver is in pretty bad shape and should be expected to be flaky. I don't think the issue is specific to TCP connections though. I think it's related to timing of inbound/outbound packets. I would frequently trigger it when fetch ran as part of a port update, but it happened at other seemingly random times as well. I suspect that TCP incoming data and the outgoing ACKs might tickle the (locking? state machine?) bug more effectively than other traffic mixes. > > Restarting wpa_supplicant mostly resolves the issue, but it does not > on its own discover the problem. > > According to tcpdump(8), packets are still received. > > Any ideas ? > I've never done any driver work so I have no idea how to resolve the issue, and just live with it randomly crapping out on me. I found restarting wpa_supplicant to be a hit and miss way to fix it. The easiest way to avoid panics or re occurrences was to pull the dongle, wait 5 secs, reinsert and then recreate the wlan dev and start wpa_supplicant. Cheers, Lawrence