Return-path: Received: from he.sipsolutions.net ([78.46.109.217]:42546 "EHLO sipsolutions.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932315Ab0CaINj (ORCPT ); Wed, 31 Mar 2010 04:13:39 -0400 Subject: Re: [PATCH V2] mac80211: Revise,pending queue depth in ieee80211_local data structure From: Johannes Berg To: Bruno Randolf Cc: Lorenzo Bianconi , linux-wireless@vger.kernel.org In-Reply-To: <201003311712.12301.br1@einfach.org> References: <4BA24A12.4030208@gmail.com> <201003211101.16481.randolf.bruno@gmail.com> <1269281564.7645.1.camel@jlt3.sipsolutions.net> <201003311712.12301.br1@einfach.org> Content-Type: text/plain; charset="UTF-8" Date: Wed, 31 Mar 2010 10:13:37 +0200 Message-ID: <1270023217.16210.0.camel@jlt3.sipsolutions.net> Mime-Version: 1.0 Sender: linux-wireless-owner@vger.kernel.org List-ID: On Wed, 2010-03-31 at 17:12 +0900, Bruno Randolf wrote: > On Tuesday 23 March 2010 03:12:44 you wrote: > > On Sun, 2010-03-21 at 11:01 +0900, Bruno Randolf wrote: > > > On Sunday 21 March 2010 05:40:05 Johannes Berg wrote: > > > > On Sat, 2010-03-20 at 21:02 +0100, Lorenzo Bianconi wrote: > > > > > >> setup 2 wireless cards, talking to each other (i use IBSS) on > > > > > >> different > > > > > > > > > > >> machines. then setup routing like this: > > > > > PC1<--ethernet cable-->Device1<--wireless link-->Device2<--ethernet > > > > > cable-->PC2 > > > > > > > > I'm not really sure how this scenario differs from injecting traffic > > > > locally, but I'll try to reproduce. > > > > > > if you generate traffic locally it's enough to stop the queues, this will > > > cause userspace to stop generating traffic. in the forwarding case (which > > > we are talking about) stopping the queues will not stop the sender to > > > send traffic, thus we have to start dropping packets at some point. > > > > So I tried this scenario, and I see the queues stopping, and traffic > > being dropped quite as you'd want it. Even the race condition that I > > noticed didn't ever trigger. > > > > Please make sure you're using a kernel recent enough to include the > > fixes, maybe try compat-wireless. > > so it must be an ath5k bug then... lorenzo's description just resembled my > case so much, that i thought it could be the same bug. sorry to have bothered > you with this... I don't think there's any way this can be a driver bug, assuming it stops the queues properly, which it has to unless it comes up with its own queueing scheme... johannes