From owner-freebsd-net@FreeBSD.ORG Tue Jul 7 09:51:29 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6D3D610656C3 for ; Tue, 7 Jul 2009 09:51:29 +0000 (UTC) (envelope-from nvass9573@gmx.com) Received: from mail.gmx.com (unknown [213.165.64.42]) by mx1.freebsd.org (Postfix) with SMTP id CC7578FC1C for ; Tue, 7 Jul 2009 09:51:28 +0000 (UTC) (envelope-from nvass9573@gmx.com) Received: (qmail invoked by alias); 07 Jul 2009 09:51:26 -0000 Received: from ipa49.88.91.tellas.gr (EHLO [192.168.1.5]) [91.140.88.49] by mail.gmx.com (mp-eu004) with SMTP; 07 Jul 2009 11:51:26 +0200 X-Authenticated: #46156728 X-Provags-ID: V01U2FsdGVkX194xic7lQF4Oi5Ugrv78cVmnCb8RB8qS+8V7OMKKw /TH7TlTR3lP8Fd Message-ID: <4A531A94.40701@gmx.com> Date: Tue, 07 Jul 2009 12:51:16 +0300 From: Nikos Vassiliadis User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Nikos Vassiliadis , freebsd-net@freebsd.org, weongyo.jeong@gmail.com References: <4A43386D.80500@gmx.com> <20090625103420.GD31161@weongyo.cdnetworks.kr> <4A436A8A.1000405@gmx.com> <20090626041246.GE31161@weongyo.cdnetworks.kr> <4A461AF9.7040900@gmx.com> <20090629032520.GA1138@weongyo.cdnetworks.kr> <4A4880EF.5010206@gmx.com> <4A4E2873.3010501@gmx.com> <20090706043747.GD1138@weongyo.cdnetworks.kr> In-Reply-To: <20090706043747.GD1138@weongyo.cdnetworks.kr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.54 Cc: Subject: Re: ndis and USB wirelless ethernet X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2009 09:51:29 -0000 Weongyo Jeong wrote: > I'm happy to see your device is successfully associated with AP. > However it seems it's a bad news that you sometimes meet crashes. Does > a random crash mean a OS hang (e.g. could not type any keys) or no more > work of network operations? It hangs, I cannot use the keyboard and I have to power-cycle it. It can happen after some time downloading and uploading. It hangs after 5 to 30 minutes of heavy traffic. By heavy traffic, I mean the maximum I can get from this device, which is 50KBytes/sec. I am not sure what will happen if I let it idle for, let's say one day, but I haven't had a single crash during times with low activity, such as ssh traffic. > Frankly speaking, for both cases it looks I could not provide any > solutions without backtraces unless I encountered same problems on my > environment. It'd better if we can reproduce its problem easily. Unfortunately, I have no solid facts to show you. The only strange thing I've seen and is consistent, is this: speed# vmstat -m | grep USBdev ; sleep 1 ; vmstat -m | grep USBdev ; sleep 1 ; vmstat -m | grep USBdev USBdev 53 4K - 267579 16,32,128,1024 USBdev 53 4K - 267612 16,32,128,1024 USBdev 53 4K - 267642 16,32,128,1024 speed# speed# vmstat -m | grep USBdev ; sleep 1 ; vmstat -m | grep USBdev ; sleep 1 ; vmstat -m | grep USBdev USBdev 53 4K - 268071 16,32,128,1024 USBdev 53 4K - 268101 16,32,128,1024 USBdev 53 4K - 268140 16,32,128,1024 And then with some traffic: speed# ping -i 0.01 192.168.1.1 > /dev/null & [1] 1777 speed# vmstat -m | grep USBdev ; sleep 1 ; vmstat -m | grep USBdev ; sleep 1 ; vmstat -m | grep USBdev USBdev 53 4K - 270249 16,32,128,1024 USBdev 58 4K - 271095 16,32,128,1024 USBdev 56 4K - 272008 16,32,128,1024 speed# vmstat -m | grep USBdev ; sleep 1 ; vmstat -m | grep USBdev ; sleep 1 ; vmstat -m | grep USBdev USBdev 54 4K - 279649 16,32,128,1024 USBdev 57 4K - 280544 16,32,128,1024 USBdev 54 4K - 281423 16,32,128,1024 I don't know how relevant is the above, but it seemed strange, so I am posting it... > One thing to hang as far as I know is that try to execute `ifconfig down > && ifconfig up' multiple times. In NDIS USB support it's recommended > that `ifconfig up' is executed once. OK, noted and avoided. > I think you can try another drivers. Will do. > AFAIK this behavior (ASSOC -> RUN) depends on the routine of the link > status change on NDIS driver that in private experience, some drivers > doesn't call the link status handler even if it's ready to use or call > the handler too early which is one of the abnormal. > > So don't know what's going on in NDIS driver currently. I see. Thanks again Weongyo for your help, I'll report again when I'll find some more useful bits about the problem. Regards, Nikos