Return-path: Received: from yx-out-2324.google.com ([74.125.44.30]:54748 "EHLO yx-out-2324.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754716AbYKCI0F (ORCPT ); Mon, 3 Nov 2008 03:26:05 -0500 Received: by yx-out-2324.google.com with SMTP id 8so920905yxm.1 for ; Mon, 03 Nov 2008 00:26:03 -0800 (PST) Message-ID: <43e72e890811030026t319c551cp91807318f9a6b838@mail.gmail.com> (sfid-20081103_092612_709228_B6BCE439) Date: Mon, 3 Nov 2008 00:26:03 -0800 From: "Luis R. Rodriguez" To: "Johannes Berg" Subject: Re: wireless-testing commit eb9d4e8399181357cb6f6625ba7f849987432c6c causes stalls Cc: "Bob Copeland" , "Nick Kossifidis" , tim.gardner@canonical.com, mick@madwifi.org, linux-wireless@vger.kernel.org, "John W. Linville" In-Reply-To: <1225699482.3619.34.camel@johannes.berg> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 References: <4908B754.1050400@tpi.com> <20081102184146.GA6065@hash.localnet> <43e72e890811021249x6047b38do5d7ead10fe4098e7@mail.gmail.com> <1225696692.3619.18.camel@johannes.berg> <43e72e890811022329g510a280wfd033538ee9b8c17@mail.gmail.com> <1225697686.3619.25.camel@johannes.berg> <43e72e890811022351m2c03e0b4g2a67a70cd6a7bd3c@mail.gmail.com> <1225698867.3619.31.camel@johannes.berg> <43e72e890811030001x7a3b166am440873fcf2c143d4@mail.gmail.com> <1225699482.3619.34.camel@johannes.berg> Sender: linux-wireless-owner@vger.kernel.org List-ID: On Mon, Nov 3, 2008 at 12:04 AM, Johannes Berg wrote: > On Mon, 2008-11-03 at 00:01 -0800, Luis R. Rodriguez wrote: > >> > But you're saying it's "normal" to get this failure, >> >> No, I'm just sayings its possible, right now mac80211 assumes its not >> and if it does its because we somehow lied to mac80211 of our >> capabilities. > > Well, yes, sort of. > >> > so wouldn't it >> > always do that sooner or later and always say your hw is broken? >> >> Nope > > Why not? > >> > Also, >> > that's a bad thing to do in userspace, imho. >> >> What should we do with these rare failures then? > > print an error message? ignore them? try again? I'd prefer a simple error print than a WARN_ON(). >> > hw borked is one obvious case, but it shouldn't happen enough >> > for this to be a problem yet. >> >> This I agree with. It is rare, its just possible, right now mac80211 >> assumes it never will. > > It's _always_ assumed that by ignoring the return value, now it's just > noisy about it because clearly it doesn't like when the driver fails to > do what it wants since then the hw and sw states get out of sync. I > really don't see what to do other than retry maybe, but that might well > be done in the driver instead. As can be seen from the patch suggested what some drivers will end up doing is just ignoring failures but I guess that can be up to the drivers to deal with as you are suggesting. I'd be inclined to try to disable the device in case of a few failed resets to be specific with ath5k. Would mac80211 want to be informed of that through the return value? Is the WARN still appropriate? Luis