Return-path: Received: from wf-out-1314.google.com ([209.85.200.175]:6112 "EHLO wf-out-1314.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753087AbZAINl4 (ORCPT ); Fri, 9 Jan 2009 08:41:56 -0500 Received: by wf-out-1314.google.com with SMTP id 27so9841333wfd.4 for ; Fri, 09 Jan 2009 05:41:55 -0800 (PST) Message-ID: (sfid-20090109_144201_086568_1863DFA1) Date: Fri, 9 Jan 2009 08:41:55 -0500 From: "Bob Copeland" To: "Hugh Dickins" Subject: Re: [ath5k-devel] ath5k_tasklet_rx BUG_ON(bf->skb == NULL) Cc: "Maxim Levitsky" , linux-wireless@vger.kernel.org, "Jiri Slaby" , ath5k-devel@venema.h4ckr.net In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 References: <1231426017.922.2.camel@maxim-laptop> Sender: linux-wireless-owner@vger.kernel.org List-ID: On Thu, Jan 8, 2009 at 1:41 PM, Bob Copeland wrote: > On Thu, Jan 8, 2009 at 12:55 PM, Hugh Dickins wrote: >> Let me see if I can reproduce the ath5k BUG with a straightforward >> memhog, repeatedly dirtying more anon memory than RAM can provide. >> Is there something suitable I could run to exercise that wireless >> path concurrently? It was just idling when I hit the BUGs before. > > Receiving any packets will do it, in your case it was probably > beacons from nearby APs if you weren't using the wifi. So iperf > or similar will work. Actually it's probably enough to just intentionally fail one of the allocations in the driver. I'll do that and let you know if I can easily break it. -- Bob Copeland %% www.bobcopeland.com