From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from mail-iw0-f174.google.com ([209.85.214.174]:50466 "EHLO mail-iw0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751026Ab0KAQoh convert rfc822-to-8bit (ORCPT ); Mon, 1 Nov 2010 12:44:37 -0400 Received: by iwn10 with SMTP id 10so7222842iwn.19 for ; Mon, 01 Nov 2010 09:44:36 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: References: <8762whrqvm.fsf@gmail.com> From: "Luis R. Rodriguez" Date: Mon, 1 Nov 2010 09:44:15 -0700 Message-ID: Subject: Re: [ath9k-devel] ath9k: race conditions in dma To: =?UTF-8?Q?Bj=C3=B6rn_Smedman?= Cc: Ben Gamari , ath9k-devel@lists.ath9k.org, linux-wireless Content-Type: text/plain; charset=UTF-8 Sender: linux-wireless-owner@vger.kernel.org List-ID: 2010/11/1 Björn Smedman : > On Mon, Nov 1, 2010 at 4:43 PM, Ben Gamari wrote: >> On Mon, 1 Nov 2010 16:17:23 +0100, Björn Smedman wrote: >>> Hi all, >>> >>> I have an application that creates and destroys a lot of ap vifs and >>> does a lot of monitor frame injection. The recent ath9k rx locking >>> fixes have helped with stability in this use-case but there still >>> seems to be some tx/beacon related race condition(s). These manifests >>> themselves as follows on an AR913x based router running >>> compat-wireless-2010-10-19 (with locking fixes etc from openwrt): >>> >>> 1. TX DMA hangs under simultaneous high RX and TX load >>> 2. TX is completely hung but chip is never reset >> >> I have also observed both of these behaviors with just a standard >> hostapd single VIF configuration. Quite annoying. It seems to be better >> with recent wireless-testing trees. >> >> - Ben > > The next thing that looks racy to me is ath_beacon_alloc() vs > ath_beacon_tasklet() in beacon.c. Beacon queue TX DMA is always > stopped in main.c before calling ath_beacon_alloc() but > ath_beacon_tasklet() is scheduled when we get an SWBA interrupt. My > guess is that these keep coming even if we stop TX DMA on the beacon > queue, no? My TX PCU patches for ath9k are not merged yet, try those or wait until John merges them. Luis From mboxrd@z Thu Jan 1 00:00:00 1970 From: Luis R. Rodriguez Date: Mon, 1 Nov 2010 09:44:15 -0700 Subject: [ath9k-devel] ath9k: race conditions in dma In-Reply-To: References: <8762whrqvm.fsf@gmail.com> Message-ID: List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: ath9k-devel@lists.ath9k.org 2010/11/1 Bj?rn Smedman : > On Mon, Nov 1, 2010 at 4:43 PM, Ben Gamari wrote: >> On Mon, 1 Nov 2010 16:17:23 +0100, Bj?rn Smedman wrote: >>> Hi all, >>> >>> I have an application that creates and destroys a lot of ap vifs and >>> does a lot of monitor frame injection. The recent ath9k rx locking >>> fixes have helped with stability in this use-case but there still >>> seems to be some tx/beacon related race condition(s). These manifests >>> themselves as follows on an AR913x based router running >>> compat-wireless-2010-10-19 (with locking fixes etc from openwrt): >>> >>> 1. TX DMA hangs under simultaneous high RX and TX load >>> 2. TX is completely hung but chip is never reset >> >> I have also observed both of these behaviors with just a standard >> hostapd single VIF configuration. Quite annoying. It seems to be better >> with recent wireless-testing trees. >> >> - Ben > > The next thing that looks racy to me is ath_beacon_alloc() vs > ath_beacon_tasklet() in beacon.c. Beacon queue TX DMA is always > stopped in main.c before calling ath_beacon_alloc() but > ath_beacon_tasklet() is scheduled when we get an SWBA interrupt. My > guess is that these keep coming even if we stop TX DMA on the beacon > queue, no? My TX PCU patches for ath9k are not merged yet, try those or wait until John merges them. Luis