Return-path: Received: from mail.candelatech.com ([208.74.158.172]:39626 "EHLO ns3.lanforge.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753076Ab0LFVAP (ORCPT ); Mon, 6 Dec 2010 16:00:15 -0500 Message-ID: <4CFD4ED5.20808@candelatech.com> Date: Mon, 06 Dec 2010 13:00:05 -0800 From: Ben Greear MIME-Version: 1.0 To: "Luis R. Rodriguez" CC: =?ISO-8859-1?Q?Bj=F6rn_Smedman?= , Luis Rodriguez , Felix Fietkau , "ath9k-devel@lists.ath9k.org" , "linux-wireless@vger.kernel.org" Subject: Re: [ath9k-devel] Script to crash ath9k with DMA errors. References: <4CF44543.9070605@candelatech.com> <20101130004424.GC1901@tux> <4CF6D8C8.2000308@candelatech.com> <4CF8A6DE.4020804@candelatech.com> <4CFAFBE1.3080505@openwrt.org> <4CFB20BA.5090300@candelatech.com> <20101206193600.GC21442@tux> <4CFD3DE3.4000207@candelatech.com> <4CFD4602.1030304@candelatech.com> <20101206204230.GG21442@tux> In-Reply-To: <20101206204230.GG21442@tux> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Sender: linux-wireless-owner@vger.kernel.org List-ID: On 12/06/2010 12:42 PM, Luis R. Rodriguez wrote: > On Mon, Dec 06, 2010 at 12:22:26PM -0800, Ben Greear wrote: >> On 12/06/2010 12:11 PM, Bj?rn Smedman wrote: >>> On Mon, Dec 6, 2010 at 8:47 PM, Ben Greear wrote: >>>> With 16 properly configured non-encrypted stations, running with >>>> wpa-supplicant >>>> with netlink driver& sharing scan results, the interfaces quickly >>>> associate. >>>> >>>> However, I do continue to see DMA warnings such as these (I had picked up my >>>> portable phone, and it knocked all the interfaces offline ..here >>>> they are coming back up after I hung up the phone). >>> >>> Is there some theory as to why using multiple interfaces cause so many >>> problems with DMA? >> >> Seems pretty directly related to channel changes and/or resets, and exacerbated >> by other interfaces sending data while another is scanning, for instance. >> >> Other issues we've found in the past have been various races that you wouldn't >> normally see with a single VIF. > > Right, there might be some other hot path we need to lock around over. > Not sure what it could be though we should be locking stopping RX > over resets already though. These should all be atomic, in fact > starting TX too IIRC, hence the name change of the lock to be > specific to the PCU together. There may be other PCU changes > we may need to contend against. Maybe the hardware/firmware guys could give us some clues as to what types of things can cause stopping RMA to fail? Maybe that could point us to what might be racing with the attempts to stop RMA? Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com