From owner-freebsd-wireless@FreeBSD.ORG Sun Mar 11 01:58:23 2012 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 139541065678 for ; Sun, 11 Mar 2012 01:58:23 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by mx1.freebsd.org (Postfix) with ESMTP id D539A8FC1B for ; Sun, 11 Mar 2012 01:58:22 +0000 (UTC) Received: by dald2 with SMTP id d2so3689058dal.13 for ; Sat, 10 Mar 2012 17:58:22 -0800 (PST) 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=y67YDojbNewDdBe3eqp6ue+NqU7nqb0poXDmoOgla+M=; b=D7A8vvAeiJ7nfp6MIrvt8jXirE2Ojw1t/2Y9jfZykVSrX/I9Jg2Ea5M0/JjLAQI18A u512yta3vV9eOLkvJ0ILs8SU4j3ivymWXzN5KACOav3HDQqlZHzeKrCKjvX6RzPNDY5A DYmy0RzLBwCb/OzoiYqgd7nOdWVNK50JABzlaMK8XhjKpHaWK/Dq7KdvO+If3OqDuYfE Vb6/OqS8Czj0BwSnDGkvfjrEWvUi2JHGV9PwuY37as2lozmDtFZYMdTtmTNxGKcby1Ae TviyIEinL89sWCSmyedU81SpwiKJbAcoZhQVffYSmHdPXb8Vky8idJ169MhQsb3to6SL a//Q== MIME-Version: 1.0 Received: by 10.68.234.195 with SMTP id ug3mr2891887pbc.4.1331431102657; Sat, 10 Mar 2012 17:58:22 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.143.33.5 with HTTP; Sat, 10 Mar 2012 17:58:22 -0800 (PST) In-Reply-To: <4F5C0302.8090403@unsane.co.uk> References: <4F59DD98.8080905@unsane.co.uk> <4F5AA149.8000904@unsane.co.uk> <4F5BDF3C.8070605@unsane.co.uk> <4F5C0302.8090403@unsane.co.uk> Date: Sat, 10 Mar 2012 17:58:22 -0800 X-Google-Sender-Auth: foROS4f5pCEvfJ2G6XOhp28Mc88 Message-ID: From: Adrian Chadd To: Vincent Hoffman Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-wireless@freebsd.org Subject: Re: ath0 timeout was "Re: (more) bugs fixed in -HEAD, AP mode is now mostly (again) stable!" X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.5 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, 11 Mar 2012 01:58:23 -0000 Hiya, Next time it happens, do the sysctl before the scan. The sysctl will tell me how deep each hardware TX queue is. I should likely add some further debugging to tell me how deep the per-TID software queues are; that'd be helpful here. What you're seeing there is something weird which is causing the TX frames to be queued in software/hardware and not be transmitted, to the point of buffer exhaustion. See "total TX buffers: 0" ? That means the frames can't go out for some reason. There's nothing in the hardware queue, so that also has me slightly concerned. I wonder if this is a problem with aggregation and buffer exhaustion. Hm, can you do "wlandebug +11n" and see if it's trying to exchange ADDBA frames (and failing) ? There's a known bug where Thanks, Adrian