From owner-freebsd-wireless@FreeBSD.ORG Sat Dec 8 09:24:06 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 3244D218 for ; Sat, 8 Dec 2012 09:24:06 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wi0-f174.google.com (mail-wi0-f174.google.com [209.85.212.174]) by mx1.freebsd.org (Postfix) with ESMTP id B0DEC8FC12 for ; Sat, 8 Dec 2012 09:24:05 +0000 (UTC) Received: by mail-wi0-f174.google.com with SMTP id hm9so137380wib.13 for ; Sat, 08 Dec 2012 01:24:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; bh=xr//CNb0ZuCwYlpVftN7kUtLV0oAyKEEU0HKUl8GiYo=; b=Ob+NB8U+4IZmTQ5wn/0w8r4uhfzBMjnc4c73m2nKnqxgh8CSxWLWDQ/SywroKJ3dYu zyGfI/hQPhqKi7jb532T7ay+m7emucnY3+O3M2C0U9IMLUASmT8s8zX738tw5zA9A6tS dN5EYf0uvnPxbdE+FPI6DYrXF6+PQs8OLuYt9PMfamYLSzSXYyTe7c2eZ+V398kiLlYU X9RmT5MlDiDYaKY5agVS2AgmBkTdhDnbGHVERHKut5iFigTZGdDLDb07mWBKRC10SSjD fYlraKt8JwR4oKKU6GMpz6g/NVzTa+xjorwZWWuI99pKUk0MLicEBB1o3J8GbpgjsRPC Ogyg== MIME-Version: 1.0 Received: by 10.216.139.140 with SMTP id c12mr3328732wej.46.1354958644553; Sat, 08 Dec 2012 01:24:04 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.217.57.9 with HTTP; Sat, 8 Dec 2012 01:24:04 -0800 (PST) Date: Sat, 8 Dec 2012 01:24:04 -0800 X-Google-Sender-Auth: s19I0uYLb9WWeW97yQ2IljD2AaI Message-ID: Subject: Hm, somehow the fast frames code is broken (surprise) From: Adrian Chadd To: freebsd-wireless@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 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: Sat, 08 Dec 2012 09:24:06 -0000 Hi, I've started seeing panics in the fast frames code in FreeBSD-HEAD. It's quite possible this has been here a while; I've heard rumours about this dating back to last year. The reason? Because I was doing iperf tests between AR5212/AR5413/AR5414 NICs and the HAL/driver enables the fast frames support. Which was working fine (which I'm honestly shocked about!) - except that there are two rather grr-y bugs: * upon a node purge, there's a panic inside m_free() from ieee80211_ff_node_cleanup(), where it dereferences a pointer 0xdeadc0de. So there's some use-after-free nonsense going * the TX staging code panics when flushing the staging queue; it claims the staging queue is empty when it shouldn't be. The latter is likely due to r227352 - Bernhard and I shuffled the code around to make the TX AMPDU state be per-TID rather than per-AC. I may have screwed something up in the mapping and it's checking the wrong staging queue. It doesn't show up with the 802.11n NICs because they disable the fast frames HAL support. (The chips support fast frames just fine, for what it's worth.) Anyway. If you've ever seen his panic, please let me know. I'm not going to disable fast frames; I'm going to try and figure out why it's busted and then fix it up. Fast frames for legacy atheros cards speaking to an 802.11n AP is conceptually just fine. (This just resurrects my desire to extend ath_rate_sample to have a third packet 'size', for aggregates and fast frames packets..) Adrian