From owner-freebsd-wireless@FreeBSD.ORG Sun Jun 2 22:31:26 2013 Return-Path: Delivered-To: FreeBSD-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 23EA84CC for ; Sun, 2 Jun 2013 22:31:26 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-qc0-x235.google.com (mail-qc0-x235.google.com [IPv6:2607:f8b0:400d:c01::235]) by mx1.freebsd.org (Postfix) with ESMTP id DDFFA1B3F for ; Sun, 2 Jun 2013 22:31:25 +0000 (UTC) Received: by mail-qc0-f181.google.com with SMTP id u11so1818216qcx.12 for ; Sun, 02 Jun 2013 15:31:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=aahPozaZ8NraYPniYsaRY5ngvB2E3Nqz9u8BUmZdf+Q=; b=vqSJ6szPNXnKKjGZAgHjQgUkQJF7fzYiqTAqmQo6PqwIjHIky5gKji0S8kJUGjVuPv X6qjP2QdxtRfhzWnbxAt79zOIQYoPegnn907uI59VEjynmYWgtJ/a14x8AOJsIEwdi5s 93Gi/ot35d0shgoIarzg6v6u/FLztNjscT4aLpHcF1iXvigj4NYDIK36Hk7jRSBAVip/ JFsCsMdYWBBJZYPCkoI7WYqxvGMbizcRQ51RIX3WusaUsKckhyA+MjDb/j77QrXbFxat Slv8a4dYJwQYa2PmAPI69cHN7WoYjhYUCJQJ0tSCSxnHzpAugjiULl5MQMIOObPUy3EK xy7A== MIME-Version: 1.0 X-Received: by 10.49.38.169 with SMTP id h9mr18684579qek.54.1370212285366; Sun, 02 Jun 2013 15:31:25 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.71.12 with HTTP; Sun, 2 Jun 2013 15:31:25 -0700 (PDT) In-Reply-To: References: Date: Sun, 2 Jun 2013 15:31:25 -0700 X-Google-Sender-Auth: 0q6Q6JcjXEDItvY9_4602njx7jI Message-ID: Subject: Re: panic: ath_legacy_tx_dma_restart: Q3: called with PUTRUNNING=1 From: Adrian Chadd To: Kim Culhan Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD-wireless@freebsd.org X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Discussions of 802.11 stack, tools device driver development." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Jun 2013 22:31:26 -0000 .. and stupidly, my reset code does this: * wait for tx/rx to finish * bump reset counter rather than what it should be doing, which is: * bump reset counter * wait for tx/rx to finish because TX will continue if the reset flag isn't set. And I bet that's what is going on. Thanks for pointing this out Kim! I'll add this to the PR you create and push out a fix to HEAD for you to try ASAP. Adrian On 2 June 2013 15:26, Adrian Chadd wrote: > On 2 June 2013 04:49, Kim Culhan wrote: >> Been seeing panics as in the Subject for a few weeks. >> >> Now running (and seeing the panics) with r251078M. >> >> Please let me know if additional info is needed. > > So, just to brain dump what the story is here. > > I changed the TX DMA code to implement exactly what the hardware guys > want - I touch TxDP once, then I just use the link pointer in the last > descriptor in the list to restart DMA. > > This fix is designed to catch if DMA is being restarted _after_ we've > already started DMA and written a TxDP to the hardware. > > So, either: > > * I've screwed up the stuck beacon reset path and the hardware isn't > being fully stopped before DMA is restarted (which I've done some > simple testing of; it doesn't seem like that); > * There's some parallel transmission going on that's managed to queue > a frame to the transmit queue _and_ start DMA before the reset has > completed. > > Now, in days gone past (read pre FreeBSD-10) this kind of stuff would > happen all the time and well, it may explain a lot of why things can > get very unhappy. I'm trying to eliminate these, which means adding > KASSERT()s to the kernel as I find conditions that must not occur, and > .. Kim found one. > > So I'll go chase this one down. > > Thanks Kim! > > > > Adrian