From owner-freebsd-wireless@FreeBSD.ORG Sun Nov 3 17:56:09 2013 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id BBD6B65D; Sun, 3 Nov 2013 17:56:09 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-qc0-x233.google.com (mail-qc0-x233.google.com [IPv6:2607:f8b0:400d:c01::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 65C8A2A35; Sun, 3 Nov 2013 17:56:09 +0000 (UTC) Received: by mail-qc0-f179.google.com with SMTP id k18so3509871qcv.38 for ; Sun, 03 Nov 2013 09:56:08 -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:message-id:subject :from:to:cc:content-type; bh=NlrG4wNrL09iDomEUipaW/rTe8So5H02pro7JNWh9Ok=; b=TYA2Uv6WBUrCYvIbB5X6Uwca3I+ee9qCvpMYWXb4A3MYpYppWq8pP0MPmGyEaaAFiC Z9QWKQ/uCVCwMcC02Xfrdzx4CfTJmBLgWUb6jgV+2/cYhaLk1vZdMh3LRt7hnPJaeklW fFZ+ZeqxP+KmG9I7hpomilMqMO4eFFdLCFHClg5iXJVujl4EcHv8yp7F2oVFutA00J2m EMDK6opUS8eL5vcL+okgSDghGZ38k6Rm0+CcY7POASDcazURunFj8DP/q/nAcUx8FYwx lmGnM72eru8BYcHJXrbAaLY6wkXimN1t0nDLbDUQj723/OP6iLq2hBxt91n6HvhDaUyn s1vQ== MIME-Version: 1.0 X-Received: by 10.224.51.131 with SMTP id d3mr17707474qag.0.1383501368569; Sun, 03 Nov 2013 09:56:08 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.224.207.66 with HTTP; Sun, 3 Nov 2013 09:56:08 -0800 (PST) In-Reply-To: <1383419596.3253.42.camel@eva02.mbsd> References: <1382572583.1862.39.camel@eva02.mbsd> <1382589020.1846.36.camel@eva02.mbsd> <1383331203.12614.1.camel@eva02.mbsd> <1383336004.13657.18.camel@eva02.mbsd> <1383338117.13657.53.camel@eva02.mbsd> <1383382815.31973.1.camel@eva02.mbsd> <1383419596.3253.42.camel@eva02.mbsd> Date: Sun, 3 Nov 2013 09:56:08 -0800 X-Google-Sender-Auth: 6LW7WgQ8fQeIU01Y_JcFzla5h3M Message-ID: Subject: Re: service netif restart [iface] runs a wpa_supplicant twice From: Adrian Chadd To: clutton , "freebsd-arch@freebsd.org" 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, 03 Nov 2013 17:56:09 -0000 On 2 November 2013 12:13, clutton wrote: [snip] > What was happened? netif tries to setup wlan0 (clone, wpa, dhcp, etc), > when wlan0 interface occurs, devd runs another copy of netif. Well, it sounds like we need to pick an architecture _and_ fix the behaviour here. Which is: * I think wpa-supplicant should always run if it's required in /etc/rc.conf; * netif should check if devd is configured and if so, just leave the configuration up to devd * if it isn't running, then devd should be responsible for dhclient/add-to-wpa-config What we first have to establish is whether add_interface and remove_interface (or whatever they're called) are correctly working, for ethernet and wifi driver types. Then, we need to ensure they can coexist (ie, one wpa_supplicant, but with both ethernet/wifi drivers loaded and active on their relevant interfaces.) _then_ we can break out the "stuff devd does" out of netif and have _either_ netif (x)or devd call this new script to setup/teardown the interface runtime state. How's that sound? -adrian From owner-freebsd-wireless@FreeBSD.ORG Mon Nov 4 05:26:30 2013 Return-Path: Delivered-To: freebsd-wireless@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 0E218888; Mon, 4 Nov 2013 05:26:30 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D420D2905; Mon, 4 Nov 2013 05:26:29 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id rA45QTTd059775; Mon, 4 Nov 2013 05:26:29 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id rA45QTcC059774; Mon, 4 Nov 2013 05:26:29 GMT (envelope-from linimon) Date: Mon, 4 Nov 2013 05:26:29 GMT Message-Id: <201311040526.rA45QTcC059774@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-wireless@FreeBSD.org From: linimon@FreeBSD.org Subject: Re: kern/183644: [ath] [patch] ath(4) "stops" working 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: Mon, 04 Nov 2013 05:26:30 -0000 Old Synopsis: ath(4) "stops" working New Synopsis: [ath] [patch] ath(4) "stops" working Responsible-Changed-From-To: freebsd-bugs->freebsd-wireless Responsible-Changed-By: linimon Responsible-Changed-When: Mon Nov 4 05:26:10 UTC 2013 Responsible-Changed-Why: http://www.freebsd.org/cgi/query-pr.cgi?pr=183644 From owner-freebsd-wireless@FreeBSD.ORG Mon Nov 4 05:59:11 2013 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 9C5A7B14; Mon, 4 Nov 2013 05:59:11 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-qe0-x22d.google.com (mail-qe0-x22d.google.com [IPv6:2607:f8b0:400d:c02::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 3C2212AA2; Mon, 4 Nov 2013 05:59:11 +0000 (UTC) Received: by mail-qe0-f45.google.com with SMTP id 8so3892786qea.18 for ; Sun, 03 Nov 2013 21:59:10 -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:message-id:subject :from:to:cc:content-type; bh=05eKu0ya9vvm7/gJkFDCFfzSa01Dd0PPX2bJEyUACyY=; b=Auy5Fo2luUURaBbkv5ESmVTwUpeNy/iKrMjqQEXyVoq4ANyCJzsPRtK0twMmMvi55I EyGMcDpmvcoOugbqxgECc5HsWts+6ohLxW750yPCQ9rqN8Gh+iHRfBYi5rUln2/Ce8Cj 6pi4mFtjHgZwHrT6LRWa4ShSPanU8FBYanen7qFyyHDw5DF+rI0CX5P4+wRU4YAUiZyh 7ASaLd6gNepgTUYhXdCG9NrJEEWTjxD4z47XZKgOnHmtdpDCfvwjSSjS3rbwWVT4tYlN 5LPTmBlO0ZJwt/UrQ260Cw00ZTdwoEHmBXLAhnWZIjoVTWQXWnY3MFqwDrwppOuacFTX S90Q== MIME-Version: 1.0 X-Received: by 10.229.34.134 with SMTP id l6mr20015339qcd.22.1383544750390; Sun, 03 Nov 2013 21:59:10 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.224.207.66 with HTTP; Sun, 3 Nov 2013 21:59:10 -0800 (PST) In-Reply-To: <001e01ceb064$80168220$80438660$@info> References: <20130913112427.Horde.Lr2e32AbzvcQIrrWuDh-dg1@d2ux.org> <001e01ceb064$80168220$80438660$@info> Date: Sun, 3 Nov 2013 21:59:10 -0800 X-Google-Sender-Auth: qQTkHNmEQvnUw9CTaju-j6RbBfc Message-ID: Subject: Re: Centrino Wireless N2230 support From: Adrian Chadd To: Cedric GROSS Content-Type: text/plain; charset=ISO-8859-1 Cc: "freebsd-wireless@freebsd.org" , "freebsd-drivers@freebsd.org" , Matthias Petermann , freebsd-current 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: Mon, 04 Nov 2013 05:59:11 -0000 [snip] For what it's worth, I've started merging this stuff into -HEAD. I'm going to merge in the hardware updates but none of the PAN stuff this pass. Since the linux iwlwifi driver doesn't at all support the 4965 chipset, cedric's stuff just plainly breaks that. So I'm going to have to be .. gentler. I'll post an update to -HEAD when I have this stuff in the tree and working (for various values of 'working', though.) -adrian From owner-freebsd-wireless@FreeBSD.ORG Mon Nov 4 08:20:39 2013 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 277E8B06 for ; Mon, 4 Nov 2013 08:20:39 +0000 (UTC) (envelope-from sven@hazejager.nl) Received: from mail-ob0-f179.google.com (mail-ob0-f179.google.com [209.85.214.179]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E876C2371 for ; Mon, 4 Nov 2013 08:20:38 +0000 (UTC) Received: by mail-ob0-f179.google.com with SMTP id uy5so6823384obc.10 for ; Mon, 04 Nov 2013 00:20:32 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=+2GKk+3T/9ZPJ45X4z45Wq7ca1kmobGQZlUE6wJBIt4=; b=lKVPEpOAm0eOnG+6tmb0h18U/zmeQqPdQQWu1M9c4513vos+S5hWpH9SxFpjy24PGE oPQxD4+9OM8QhX7AUmm3k5rkdO8fsGR+5IOQ7NmeVVH3dp15Q3UT7LCQbgdrMilHAesY 843i2JwgKPYPbt0uy6WZJ9X92LdNQaLxG3UF4thT13XUTLoiZcdBpJ95XNq4IsD/kp/q AzDeh2iaVXWXBXW0kYkUIZPnZvjfcY4N8S67dAmDI5FHjV0Xh/QzwDl9lqPoMAzOJ0hX 0YGpcyZppQThPJdMFypSHwzCY2RwwnMzOZTM5lzsF0wOqVviijkPWTXDPT9c9BD55iX9 d6uA== X-Gm-Message-State: ALoCoQk4k02axFKMi7u4jvvvCuT1D+e66P8Xqi6q838jQlHlifrqsJ7axp0whNJBw5axUvZu0s+J MIME-Version: 1.0 X-Received: by 10.60.149.169 with SMTP id ub9mr4320231oeb.39.1383553232165; Mon, 04 Nov 2013 00:20:32 -0800 (PST) Received: by 10.182.18.9 with HTTP; Mon, 4 Nov 2013 00:20:32 -0800 (PST) X-Originating-IP: [84.207.225.82] Date: Mon, 4 Nov 2013 09:20:32 +0100 Message-ID: Subject: AR9160 on HEAD - unstable? From: Sven Hazejager To: freebsd-wireless@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 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: Mon, 04 Nov 2013 08:20:39 -0000 Ever since I upgraded my NanoBSD from May to October HEAD, I seem to be getting disconnects on my WLAN. It is most visible when I'm on a Skype video call on my MacBook Air, signal strength fine (MCS 15), but the MBA just loses the connection and I need to switch its wireless off and on again. Somehow it feels that these problems have gotten worse over the past few days (uptime of the box is now 12 days). This is what I see on dmesg on the NanoBSD box. What's that FRDS output...? ath0: ath_tx_default_comp: bf 0xc293e090: seqno 211: bf_next not NULL! ath0: ath_tx_default_comp: bf 0xc29438c0: seqno 212: bf_next not NULL! ath0: ath_tx_default_comp: bf 0xc2942160: seqno 213: bf_next not NULL! FRDS 02:27:a7:10:7b:00->14:10:9f:f3:fb:64(00:0b:6b:b1:3a:e7) data QoS [TID 0] WEP [IV 7e 90 00 03 00 00 KID 0] 0M 8842 0000 1410 9ff3 fb64 000b 6bb1 3ae7 0227 a710 7b00 700d 0000 0000 7e90 0020 0300 0000 aaaa 0300 0000 0800 FRDS 02:27:a7:10:7b:00->14:10:9f:f3:fb:64(00:0b:6b:b1:3a:e7) data QoS [TID 0] WEP [IV 73 01 00 00 00 00 KID 1] 0M 8842 0000 1410 9ff3 fb64 000b 6bb1 3ae7 0227 a710 7b00 40c9 0000 0300 7301 0060 0000 0000 aaaa 0300 0000 0800 FRDS 02:27:a7:10:7b:00->14:10:9f:f3:fb:64(00:0b:6b:b1:3a:e7) data QoS [TID 0] WEP [IV 6e 7a 00 00 00 00 KID 0] 0M 8842 0000 1410 9ff3 fb64 000b 6bb1 3ae7 0227 a710 7b00 303d 0000 0000 6e7a 0020 0000 0000 aaaa 0300 0000 0800 FRDS 02:27:a7:10:7b:00->14:10:9f:f3:fb:64(00:0b:6b:b1:3a:e7) data QoS [TID 0] WEP [IV 7d 0a 00 00 00 00 KID 0] 0M 8842 0000 1410 9ff3 fb64 000b 6bb1 3ae7 0227 a710 7b00 c0a7 0000 0000 7d0a 0020 0000 0000 aaaa 0300 0000 0800 FRDS 02:27:a7:10:7b:00->14:10:9f:f3:fb:64(00:0b:6b:b1:3a:e7) data QoS [TID 0] WEP [IV 99 11 00 00 00 00 KID 0] 0M 8842 0000 1410 9ff3 fb64 000b 6bb1 3ae7 0227 a710 7b00 7019 0000 0000 9911 0020 0000 0000 aaaa 0300 0000 0800 ath0: stuck beacon; resetting (bmiss count 4) ath0: stuck beacon; resetting (bmiss count 4) ath0: stuck beacon; resetting (bmiss count 4) ath0: stuck beacon; resetting (bmiss count 4) ath0: device timeout FRDS 00:11:32:1a:e1:54->14:10:9f:f3:fb:64(00:0b:6b:b1:3a:e7) data QoS [TID 0] WEP [IV 37 00 00 00 00 00 KID 1] 0M 8842 0000 1410 9ff3 fb64 000b 6bb1 3ae7 0011 321a e154 7024 0000 0000 3700 0060 0000 0000 aaaa 0300 0000 0800 FRDS 02:27:a7:10:7b:00->14:10:9f:f3:fb:64(00:0b:6b:b1:3a:e7) data QoS [TID 0] WEP [IV 33 02 00 00 00 00 KID 0] 0M 8842 2c00 1410 9ff3 fb64 000b 6bb1 3ae7 0227 a710 7b00 3023 0000 15fc 3302 0020 0000 0000 aaaa 0300 0000 0800 ath0: stuck beacon; resetting (bmiss count 4) ath0: stuck beacon; resetting (bmiss count 4) ath0: stuck beacon; resetting (bmiss count 4) ath0: ath_tx_default_comp: bf 0xc29538d0: seqno 128: bf_next not NULL! ath0: ath_tx_default_comp: bf 0xc294d600: seqno 129: bf_next not NULL! ath0: ath_tx_default_comp: bf 0xc29490f0: seqno 130: bf_next not NULL! ath0: ath_tx_default_comp: bf 0xc2953270: seqno 131: bf_next not NULL! ath0: ath_tx_default_comp: bf 0xc29458a0: seqno 132: bf_next not NULL! ath0: ath_tx_default_comp: bf 0xc294f1a0: seqno 133: bf_next not NULL! ath0: ath_tx_default_comp: bf 0xc2944250: seqno 134: bf_next not NULL! ath0: ath_tx_default_comp: bf 0xc2946340: seqno 135: bf_next not NULL! ath0: ath_tx_default_comp: bf 0xc293b500: seqno 136: bf_next not NULL! ath0: ath_tx_default_comp: bf 0xc294bd90: seqno 137: bf_next not NULL! ath0: ath_tx_default_comp: bf 0xc2954d00: seqno 138: bf_next not NULL! ath0: ath_tx_default_comp: bf 0xc2949ca0: seqno 139: bf_next not NULL! ath0: ath_tx_default_comp: bf 0xc293f900: seqno 140: bf_next not NULL! ath0: ath_tx_default_comp: bf 0xc2943ae0: seqno 141: bf_next not NULL! ath0: ath_tx_default_comp: bf 0xc2945460: seqno 142: bf_next not NULL! ath0: ath_tx_default_comp: bf 0xc294b620: seqno 143: bf_next not NULL! ath0: ath_tx_default_comp: bf 0xc2936330: seqno 144: bf_next not NULL! ath0: ath_tx_default_comp: bf 0xc29425a0: seqno 145: bf_next not NULL! ath0: ath_tx_default_comp: bf 0xc293d1b0: seqno 146: bf_next not NULL! ath0: ath_tx_default_comp: bf 0xc2946de0: seqno 147: bf_next not NULL! ath0: ath_tx_default_comp: bf 0xc294cfa0: seqno 148: bf_next not NULL! ath0: ath_tx_default_comp: bf 0xc2945f00: seqno 149: bf_next not NULL! ath0: ath_tx_default_comp: bf 0xc2948870: seqno 150: bf_next not NULL! ath0: ath_tx_default_comp: bf 0xc294d710: seqno 151: bf_next not NULL! ath0: ath_tx_default_comp: bf 0xc293da30: seqno 152: bf_next not NULL! ath0: ath_tx_default_comp: bf 0xc2938420: seqno 153: bf_next not NULL! ath0: ath_tx_default_comp: bf 0xc2955030: seqno 154: bf_next not NULL! ath0: ath_tx_default_comp: bf 0xc2937210: seqno 155: bf_next not NULL! ath0: ath_tx_default_comp: bf 0xc293d5f0: seqno 156: bf_next not NULL! ath0: ath_tx_default_comp: bf 0xc2943e10: seqno 157: bf_next not NULL! ath0: ath_tx_default_comp: bf 0xc293f3b0: seqno 158: bf_next not NULL! ath0: ath_tx_default_comp: bf 0xc294e5f0: seqno 160: bf_next not NULL! ath0: ath_tx_default_comp: bf 0xc29414a0: seqno 161: bf_next not NULL! ath0: ath_tx_default_comp: bf 0xc294de80: seqno 162: bf_next not NULL! ath0: ath_tx_default_comp: bf 0xc2938a80: seqno 163: bf_next not NULL! FRDS 02:27:a7:10:7b:00->14:10:9f:f3:fb:64(00:0b:6b:b1:3a:e7) data QoS [TID 0] WEP [IV 32 00 00 stray irq7 00 00 00 KID 1] 0M 8842 0000 1410 9ff3 fb64 000b 6bb1 3ae7 0227 a710 7b00 500a 0000 0300 3200 0060 0000 0000 aaaa 0300 0000 0800 ath0: ath_tx_default_comp: bf 0xc293aa60: seqno 813: bf_next not NULL! ath0: ath_tx_default_comp: bf 0xc29449c0: seqno 807: bf_next not NULL! ath0: ath_tx_default_comp: bf 0xc2954f20: seqno 808: bf_next not NULL! ath0: ath_tx_default_comp: bf 0xc2957780: seqno 809: bf_next not NULL! ath0: ath_tx_default_comp: bf 0xc2936550: seqno 810: bf_next not NULL! ath0: ath_tx_default_comp: bf 0xc293f4c0: seqno 811: bf_next not NULL! From owner-freebsd-wireless@FreeBSD.ORG Mon Nov 4 11:06:59 2013 Return-Path: Delivered-To: freebsd-wireless@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 2AD03789 for ; Mon, 4 Nov 2013 11:06:59 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 173CC2C53 for ; Mon, 4 Nov 2013 11:06:59 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id rA4B6wHs048576 for ; Mon, 4 Nov 2013 11:06:58 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id rA4B6wBD048574 for freebsd-wireless@FreeBSD.org; Mon, 4 Nov 2013 11:06:58 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 4 Nov 2013 11:06:58 GMT Message-Id: <201311041106.rA4B6wBD048574@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-wireless@FreeBSD.org Subject: Current problem reports assigned to 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: Mon, 04 Nov 2013 11:06:59 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/183644 wireless [ath] [patch] ath(4) "stops" working o kern/183430 wireless [iwn] latest change to the rate code setup uses 11n ra o kern/183428 wireless [net80211] [iwn] Some APs seem to announce HT but no H o kern/181898 wireless [iwn] [patch] Centrino Advanced-N 6235 with latest iwn o kern/181694 wireless [iwn] [patch] Initialize hardware in iwn(4) resume cod o kern/181161 wireless [wl] config a old compaq wl-110 wireless card make ker o kern/181132 wireless [iwn] stream calculation is wrong for the Intel 4965 o kern/181100 wireless [bwi] Turning up bwi0 crashes / deadlocks the kernel o kern/180816 wireless [iwl] Intel Centrino Wireless-N 2200 not supported o kern/179847 wireless [ath] [patch] Update regdomain in ath drivers includin o kern/179709 wireless [ath] Atheros 5212 does not work: stuck beacon; resett o kern/179547 wireless [ath] Add AR9485 custom board fixes (CUS198) o kern/179482 wireless [ath] [patch] Fix AR9462 external LNA configuration o kern/179269 wireless [ath] [AR9285] RX antenna diversity is not functioning o kern/179232 wireless [ath] panic in ath o kern/178986 wireless [ath] Change mac address of ath(4) is not reflected wh o kern/178492 wireless [ath] ath0 (AR9287) panic o kern/178491 wireless [ath] ath0 (AR9287) stuck beacon o kern/178477 wireless [ath] missed beacon / soft reset in STA mode results i o kern/178470 wireless [panic][ath] bss vap can and does change o kern/178411 wireless [ral] [panic] FreeBSD kernel crash in rt2860 o kern/178379 wireless [net80211] [ath] WPA rekey on the STA side fails when o kern/178378 wireless [net80211] crypto state isn't reset during a reassocia o kern/178263 wireless [ath] review the use of ic_freq / ic_ieee / ic_flags / o kern/177847 wireless [ath] With TPC enabled, TX power values aren't clamped o kern/177846 wireless [ath] [net80211] net80211 TX power limit isn't correct o conf/177688 wireless WiFi regodmains information is inconsistent between "e o kern/177530 wireless [ath] ath driver isn't 32 bit int clean o kern/177465 wireless [iwn] 20%-100% packet loss with iwn driver o kern/177451 wireless [ieee80211] page fault in ieee80211_tx_mgt_timeout o kern/176238 wireless [ath] [patch] Correct buffer size calculation and simp o kern/176201 wireless [net80211] [patch] 11n station includes unrelated ht p o kern/176104 wireless [iwn] iwn0: iwn_intr: fatal firmware error o kern/175722 wireless [ath]lot of bad seriesx hwrate in kernel messages o kern/175446 wireless [ath] high volumes of PHY errors lead to BB/MAC hangs o kern/175227 wireless [ath] beacon timers aren't necessarily reprogrammed af o kern/175183 wireless [iwn] iwn(4) becomes unresponsive during initial confi o kern/175053 wireless [iwn] iwn firmware error on 9-stable with Ultimate-N 6 o kern/174891 wireless [ieee80211] struct ieee80211_node is freed during acti o kern/174722 wireless [wlan] can't use channel 12 and 13 (14) with my wifi i o kern/174661 wireless [wlan] lost alias on wlan interface o kern/174283 wireless [net80211] panics in ieee80211_ff_age() and ieee80211_ o kern/174276 wireless [ath] if_ath memory modified after free o kern/174273 wireless [net80211] taking down a net80211 node with active fas o kern/173917 wireless [iwn] wpa-supplicant issues on iwn o kern/173898 wireless [iwn] [patch] iwn(4) DOES support 6235 chip. o kern/173883 wireless [ath] ath0: unable to attach - pci issue? o kern/173711 wireless [ath] powerd kills ath on the Asus EeePC 1005HA o kern/173342 wireless PS-Poll isn't working o kern/173336 wireless [ath] Atheros card improper device poweroff handling o o kern/172955 wireless [ath] 11n does not work in adhoc mode o kern/172706 wireless [wpi] wpi0 fails to load firmware when using country o kern/172672 wireless [ubt] Bluetooth device recognised but not working o kern/172661 wireless hostapd(8) securing wireless adapter in HostAP mode is o kern/172338 wireless [ath] [net80211] CCMP IV transmit counters are not cor o kern/171598 wireless [ath] TP-Link TL-WN951N W-LAN PCI Adapter 300 MBit stu o kern/171235 wireless [ath] ath loses connection, system freezes on netif re o kern/170889 wireless [ath] ath driver uses some uninitilized memory o kern/170620 wireless [ath] LOR and deadlock when multiple vaps are used o kern/170573 wireless [iwi] Intel 2200BG iwi NIC hangs with need multicast c o kern/170513 wireless [ath] ath logs: ath_tx_aggr_comp_aggr: AR5416 bug: o kern/170433 wireless [ath] TX hang after a stuck beacon message with active o kern/170411 wireless [ath] Uninitialized variables in if_ath.c o kern/170397 wireless [ath] [patch] Uninitialized variables in ah_eeprom_928 o kern/170302 wireless [ath] 802.11n frames are not being transmitted with mu o kern/170281 wireless [ath] 802.11n locks up on aggregation setup (ampdutx) o kern/170098 wireless [ath] [net80211] VAPs (Virtual access points) with Ath o kern/170066 wireless [ral] ral(4) rt61pci Linksys freezes the machine as so o kern/169432 wireless [ath] BAR TX hang when aggregation session is reset du p kern/169362 wireless [ath] AR5416: radar pulse PHY errors sometimes include o kern/169336 wireless [ath] ANI isn't triggering in a busy/noisy environment o kern/169199 wireless [ath] Cannot set up static ip addresses for wireless w o kern/169084 wireless [ath] suspend/resume doesn't cause a rescan; the assoc o kern/168530 wireless [ath] Broken WEP probably o kern/168393 wireless AR9285: suspend/resume sometimes fails o kern/168170 wireless [net80211] ieee80211_send_bar() doesn't complete corre o kern/167870 wireless [ath] adhoc wifi client does not join an existing IBSS o kern/167834 wireless [ath] kickpcu; 'handled 0 packets' o kern/167828 wireless [iwn] iwn(4) doesn't recover automatically after firmw o kern/167798 wireless ifconfig(8): problem with "ifconfig list scan" command o kern/167491 wireless [ath] TID != hardware queue TID in ath_tx_aggr_comp_ag o kern/167113 wireless [ath] AR5210: "stuck" TX seems to be occuring, without o kern/167080 wireless [ath] channel switch on another VAP break channel setu o kern/166684 wireless [ath] [net80211] mgmtrate/mcastrate isn't updated base p kern/166642 wireless [ieee80211] [patch] in 802.11n mode for FreeBSD AP, ha o kern/166641 wireless [ieee80211] [patch] mbuf/cluster leak in AP mode in 80 p kern/166357 wireless [ath] 802.11n TX stall when the first frame in the BAW o kern/166286 wireless [net80211] [ath] initial switch to HT40 isn't causing p kern/166190 wireless [ath] TX hangs and frames stuck in TX queue o kern/166086 wireless [Patch][ath] Reflect state of rfkill switch in a sysct o kern/165969 wireless [ath] Slower performance in adhoc mode vs Client/AP mo o kern/165966 wireless [ath] ath0: device timeout on SMP machines due to race o kern/165895 wireless [ath] overly busy cabq can tie up all tx buffers o kern/165870 wireless [bwn] bwn driver does not attach on HP Pavilion dv9420 o kern/165866 wireless [ath] TX hangs, requiring a "scan" to properly reset t o kern/165849 wireless [ath] [hang] network ath driver freeze o kern/165595 wireless [ipw] ipw(4): Can't load firmare for ipw2200bg o kern/165543 wireless [ath] ath0 endless scanning of channels without connec o kern/165517 wireless [net80211] bgscan isn't triggered when invalid beacons o kern/165475 wireless [ath] operational mode change doesn't poke the underly o kern/165382 wireless [kernel] taskqueue_unblock doesn't unblock currently q o kern/165306 wireless [ath] race conditions between scanning and beacon time o kern/165220 wireless [ath] "ath_rx_tasklet: sc_inreset_cnt > 0; skipping" m o kern/165214 wireless [ieee80211] Kernel panic in ieee80211_output.c:2505 o kern/165212 wireless [ath] No WiFi on Acer Aspire One 751h (Atheros AR5BHB6 o kern/165149 wireless [ath] [net80211] Ping with data length more than iv_fr o kern/165146 wireless [net80211] Net802.11 Fragment number is assigned 1 (sh o kern/165060 wireless [ath] vap->iv_bss race conditions causing crashes insi o kern/165021 wireless [ath] ath device timeout during scan/attach, if wlan_c o kern/164721 wireless [ath] ath device timeouts o kern/164382 wireless [ath] crash when down/deleting a vap - inside ieee8021 o kern/164365 wireless [iwi] iwi0: UP/DOWN in o bin/164102 wireless hostapd not configured for 802.11n o kern/163759 wireless [ath] ath(4) "stops working" in hostap mode o kern/163724 wireless [mwl] [patch] NULL check before dereference o kern/163719 wireless [ath] ath interface do not receive multicast o kern/163689 wireless [ath] TX timeouts when sending probe/mgmt frames durin o kern/163574 wireless [net80211] overly-frequent HT occupancy changes o kern/163573 wireless [ath] hostap mode TX buffer hang o kern/163559 wireless [ath] kernel panic AH_DEBUG o kern/163318 wireless [ath] ath(4) stops working p kern/163312 wireless [panic] [ath driver] kernel panic: page fault with ath o kern/163237 wireless [ath] AR5416 as HostAP. Delays among clients when a cl o kern/163082 wireless [ath] ar9285 diversity fixes o kern/162648 wireless [ath] AR9227 ADC DC calibration failure o kern/162647 wireless [ath] 11n TX aggregation session / TX hang o kern/161293 wireless [iwn] hang at startup when starting network o kern/161035 wireless [ieee80211] Incorrect number describing 11ng MCS rate o kern/160391 wireless [ieee80211] [patch] Panic in mesh mode o kern/160296 wireless [zyd] [panic] 802.11 usb device reboots system on 'ifc o misc/160176 wireless [mips] [panic] Kernel panic on AR7161 platform with AR o kern/157449 wireless [ath] MAC address conflict causes system to freeze o kern/157243 wireless [ath] investigate beacon TX (AP) / RX (STA) when under o kern/156904 wireless [ath] AR9285 antenna diversity algorithm is buggy and o kern/156884 wireless [ath] ath instablity o kern/156327 wireless [bwn] bwn driver causes 20%-50% packet loss o kern/156322 wireless [wpi] no ahdemo support for if_wpi o kern/156321 wireless [ath] ahdemo doesn't work with if_ath o kern/155498 wireless [ral] ral(4) needs to be resynced with OpenBSD's to ga o kern/155100 wireless [ath] ath driver on busy channel: "stuck beacon" p kern/154598 wireless [ath] Atheros 5424/2424 can't connect to WPA network o kern/154567 wireless [ath] ath(4) lot of bad series(0) o kern/154327 wireless [ath] AR5416 in station mode hangs when transmitting f o kern/154284 wireless [ath] Modern ath wifi cards (such as AR9285) have miss o kern/154153 wireless [ath] AR5213 + MIPS + WPA group key packet corruption o kern/153594 wireless [wlan] netif/devd race o kern/153448 wireless [ath] ath networking device loses association after a o kern/152750 wireless [ath] ath0 lot of bad series hwrate o kern/151198 wireless [ath] ath/5416 fails bgscan with "ath0: ath_chan_set: o kern/149786 wireless [bwn] bwn on Dell Inspiron 1150: connections stall o kern/149516 wireless [ath] ath(4) hostap with fake MAC/BSSID results in sta o kern/149373 wireless [realtek/atheros]: None of my network card working o kern/148322 wireless [ath] Triggering atheros wifi beacon misses in hostap o kern/148317 wireless [ath] FreeBSD 7.x hostap memory leak in net80211 or At o kern/148078 wireless [ath] wireless networking stops functioning o kern/146426 wireless [mwl] 802.11n rates not possible on mwl o kern/146425 wireless [mwl] mwl dropping all packets during and after high u o kern/145826 wireless [panic] [ath] Unable to configure adhoc mode on ath0/w o kern/144987 wireless [wpi] [panic] injecting packets with wlaninject using o kern/144755 wireless [wlan] netif/devd race o bin/144109 wireless hostapd(8) uses the MAC of the wireless interface, but o conf/143079 wireless hostapd(8) startup missing multi wlan functionality p kern/140567 wireless [ath] [patch] ath is not worked on my notebook PC o kern/140245 wireless [ath] [panic] Kernel panic during network activity on o kern/137592 wireless [ath] panic - 7-STABLE (Aug 7, 2009 UTC) crashes on ne o kern/136943 wireless [wpi] [lor] wpi0_com_lock / wpi0 o kern/136836 wireless [ath] atheros card stops functioning after about 12 ho o kern/132722 wireless [ath] Wifi ath0 associates fine with AP, but DHCP or I o bin/131549 wireless ifconfig(8) can't clear 'monitor' mode on the wireless o kern/126475 wireless [ath] [panic] ath pcmcia card inevitably panics under o kern/125721 wireless [ath] Terrible throughput/high ping latency with Ubiqu o kern/125617 wireless [ath] [panic] ath(4) related panic o kern/125501 wireless [ath] atheros cardbus driver hangs o kern/125332 wireless [ath] [panic] crash under any non-tiny networking unde o kern/124767 wireless [iwi] Wireless connection using iwi0 driver (Intel 220 o kern/124753 wireless [ieee80211] net80211 discards power-save queue packets o kern/121061 wireless [ath] [panic] panic while ejecting ath(4)-adapter duri o docs/120456 wireless ath(4) needs to specify requirement on wlan_scan_sta o kern/119513 wireless [ath] [irq] inserting dlink dwl-g630 wireless card res o kern/116747 wireless [ndis] FreeBSD 7.0-CURRENT crash with Dell TrueMobile f kern/105348 wireless [ath] ath device stopps TX 181 problems total. From owner-freebsd-wireless@FreeBSD.ORG Mon Nov 4 15:25:55 2013 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 8A728289 for ; Mon, 4 Nov 2013 15:25:55 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-qe0-x236.google.com (mail-qe0-x236.google.com [IPv6:2607:f8b0:400d:c02::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 4D2E82C9A for ; Mon, 4 Nov 2013 15:25:55 +0000 (UTC) Received: by mail-qe0-f54.google.com with SMTP id 1so4219598qec.13 for ; Mon, 04 Nov 2013 07:25:54 -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:message-id:subject :from:to:cc:content-type; bh=bFBGWxe1yT/aUi09oJorRs+P9iLQKu13ZjKU5kMoFyE=; b=zhOHQmurBlSbXVwIQ7VG1FrRc8JRil6I1t93kzosyoVMNTsMdlN25sqSO1fIFqPYJx 38jU1/avAF3FtqsznEG5L7rXXuzXo8oH1owJAFuKTFKqQjwoEJk2VdD0ZvEDZ91FN6TX N3cyrm2L6icfjZsbJoXEsKIepFRuIqsiLn24oSweifnlfImJ/ni4oLGgYrquW5YvDGE8 8U2p02j8wsNLyo+2Ind6gxmvURS4biirGCorbHukGeo6KoiaN5eLFjHYZWdTCjMA/EUg ZOx07AKa6hFC7RDbY4076ihh6g1E1RzJQ+hSAcAlAffPCfvIW8c9oYLqLHiSUKJDOSup j7nA== MIME-Version: 1.0 X-Received: by 10.224.63.199 with SMTP id c7mr22732964qai.74.1383578754287; Mon, 04 Nov 2013 07:25:54 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.224.207.66 with HTTP; Mon, 4 Nov 2013 07:25:54 -0800 (PST) In-Reply-To: References: Date: Mon, 4 Nov 2013 07:25:54 -0800 X-Google-Sender-Auth: V0WIQ_ogPTPHrvx6s9zAXb_Eyu8 Message-ID: Subject: Re: AR9160 on HEAD - unstable? From: Adrian Chadd To: Sven Hazejager 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: Mon, 04 Nov 2013 15:25:55 -0000 Hi! So, May is ok, october isn't? can you switch back and verify? Those are data dumps of frames that are being freed out of the software staging queue when the wireless node associated has gone away (or is being "flushed.") The "bf_next not NULL!" is a worry. -adrian On 4 November 2013 00:20, Sven Hazejager wrote: > Ever since I upgraded my NanoBSD from May to October HEAD, I seem to be > getting disconnects on my WLAN. It is most visible when I'm on a Skype > video call on my MacBook Air, signal strength fine (MCS 15), but the MBA > just loses the connection and I need to switch its wireless off and on > again. Somehow it feels that these problems have gotten worse over the past > few days (uptime of the box is now 12 days). > > This is what I see on dmesg on the NanoBSD box. What's that FRDS output...? > > ath0: ath_tx_default_comp: bf 0xc293e090: seqno 211: bf_next not NULL! > ath0: ath_tx_default_comp: bf 0xc29438c0: seqno 212: bf_next not NULL! > ath0: ath_tx_default_comp: bf 0xc2942160: seqno 213: bf_next not NULL! > FRDS 02:27:a7:10:7b:00->14:10:9f:f3:fb:64(00:0b:6b:b1:3a:e7) data QoS [TID > 0] WEP [IV 7e 90 00 03 00 00 KID 0] 0M > 8842 0000 1410 9ff3 fb64 000b 6bb1 3ae7 0227 a710 7b00 700d 0000 0000 7e90 > 0020 0300 0000 aaaa 0300 0000 0800 > FRDS 02:27:a7:10:7b:00->14:10:9f:f3:fb:64(00:0b:6b:b1:3a:e7) data QoS [TID > 0] WEP [IV 73 01 00 00 00 00 KID 1] 0M > 8842 0000 1410 9ff3 fb64 000b 6bb1 3ae7 0227 a710 7b00 40c9 0000 0300 7301 > 0060 0000 0000 aaaa 0300 0000 0800 > FRDS 02:27:a7:10:7b:00->14:10:9f:f3:fb:64(00:0b:6b:b1:3a:e7) data QoS [TID > 0] WEP [IV 6e 7a 00 00 00 00 KID 0] 0M > 8842 0000 1410 9ff3 fb64 000b 6bb1 3ae7 0227 a710 7b00 303d 0000 0000 6e7a > 0020 0000 0000 aaaa 0300 0000 0800 > FRDS 02:27:a7:10:7b:00->14:10:9f:f3:fb:64(00:0b:6b:b1:3a:e7) data QoS [TID > 0] WEP [IV 7d 0a 00 00 00 00 KID 0] 0M > 8842 0000 1410 9ff3 fb64 000b 6bb1 3ae7 0227 a710 7b00 c0a7 0000 0000 7d0a > 0020 0000 0000 aaaa 0300 0000 0800 > FRDS 02:27:a7:10:7b:00->14:10:9f:f3:fb:64(00:0b:6b:b1:3a:e7) data QoS [TID > 0] WEP [IV 99 11 00 00 00 00 KID 0] 0M > 8842 0000 1410 9ff3 fb64 000b 6bb1 3ae7 0227 a710 7b00 7019 0000 0000 9911 > 0020 0000 0000 aaaa 0300 0000 0800 > ath0: stuck beacon; resetting (bmiss count 4) > ath0: stuck beacon; resetting (bmiss count 4) > ath0: stuck beacon; resetting (bmiss count 4) > ath0: stuck beacon; resetting (bmiss count 4) > ath0: device timeout > FRDS 00:11:32:1a:e1:54->14:10:9f:f3:fb:64(00:0b:6b:b1:3a:e7) data QoS [TID > 0] WEP [IV 37 00 00 00 00 00 KID 1] 0M > 8842 0000 1410 9ff3 fb64 000b 6bb1 3ae7 0011 321a e154 7024 0000 0000 3700 > 0060 0000 0000 aaaa 0300 0000 0800 > FRDS 02:27:a7:10:7b:00->14:10:9f:f3:fb:64(00:0b:6b:b1:3a:e7) data QoS [TID > 0] WEP [IV 33 02 00 00 00 00 KID 0] 0M > 8842 2c00 1410 9ff3 fb64 000b 6bb1 3ae7 0227 a710 7b00 3023 0000 15fc 3302 > 0020 0000 0000 aaaa 0300 0000 0800 > ath0: stuck beacon; resetting (bmiss count 4) > ath0: stuck beacon; resetting (bmiss count 4) > ath0: stuck beacon; resetting (bmiss count 4) > ath0: ath_tx_default_comp: bf 0xc29538d0: seqno 128: bf_next not NULL! > ath0: ath_tx_default_comp: bf 0xc294d600: seqno 129: bf_next not NULL! > ath0: ath_tx_default_comp: bf 0xc29490f0: seqno 130: bf_next not NULL! > ath0: ath_tx_default_comp: bf 0xc2953270: seqno 131: bf_next not NULL! > ath0: ath_tx_default_comp: bf 0xc29458a0: seqno 132: bf_next not NULL! > ath0: ath_tx_default_comp: bf 0xc294f1a0: seqno 133: bf_next not NULL! > ath0: ath_tx_default_comp: bf 0xc2944250: seqno 134: bf_next not NULL! > ath0: ath_tx_default_comp: bf 0xc2946340: seqno 135: bf_next not NULL! > ath0: ath_tx_default_comp: bf 0xc293b500: seqno 136: bf_next not NULL! > ath0: ath_tx_default_comp: bf 0xc294bd90: seqno 137: bf_next not NULL! > ath0: ath_tx_default_comp: bf 0xc2954d00: seqno 138: bf_next not NULL! > ath0: ath_tx_default_comp: bf 0xc2949ca0: seqno 139: bf_next not NULL! > ath0: ath_tx_default_comp: bf 0xc293f900: seqno 140: bf_next not NULL! > ath0: ath_tx_default_comp: bf 0xc2943ae0: seqno 141: bf_next not NULL! > ath0: ath_tx_default_comp: bf 0xc2945460: seqno 142: bf_next not NULL! > ath0: ath_tx_default_comp: bf 0xc294b620: seqno 143: bf_next not NULL! > ath0: ath_tx_default_comp: bf 0xc2936330: seqno 144: bf_next not NULL! > ath0: ath_tx_default_comp: bf 0xc29425a0: seqno 145: bf_next not NULL! > ath0: ath_tx_default_comp: bf 0xc293d1b0: seqno 146: bf_next not NULL! > ath0: ath_tx_default_comp: bf 0xc2946de0: seqno 147: bf_next not NULL! > ath0: ath_tx_default_comp: bf 0xc294cfa0: seqno 148: bf_next not NULL! > ath0: ath_tx_default_comp: bf 0xc2945f00: seqno 149: bf_next not NULL! > ath0: ath_tx_default_comp: bf 0xc2948870: seqno 150: bf_next not NULL! > ath0: ath_tx_default_comp: bf 0xc294d710: seqno 151: bf_next not NULL! > ath0: ath_tx_default_comp: bf 0xc293da30: seqno 152: bf_next not NULL! > ath0: ath_tx_default_comp: bf 0xc2938420: seqno 153: bf_next not NULL! > ath0: ath_tx_default_comp: bf 0xc2955030: seqno 154: bf_next not NULL! > ath0: ath_tx_default_comp: bf 0xc2937210: seqno 155: bf_next not NULL! > ath0: ath_tx_default_comp: bf 0xc293d5f0: seqno 156: bf_next not NULL! > ath0: ath_tx_default_comp: bf 0xc2943e10: seqno 157: bf_next not NULL! > ath0: ath_tx_default_comp: bf 0xc293f3b0: seqno 158: bf_next not NULL! > ath0: ath_tx_default_comp: bf 0xc294e5f0: seqno 160: bf_next not NULL! > ath0: ath_tx_default_comp: bf 0xc29414a0: seqno 161: bf_next not NULL! > ath0: ath_tx_default_comp: bf 0xc294de80: seqno 162: bf_next not NULL! > ath0: ath_tx_default_comp: bf 0xc2938a80: seqno 163: bf_next not NULL! > FRDS 02:27:a7:10:7b:00->14:10:9f:f3:fb:64(00:0b:6b:b1:3a:e7) data QoS [TID > 0] WEP [IV 32 00 00 > stray irq7 > 00 00 00 KID 1] 0M > 8842 0000 1410 9ff3 fb64 000b 6bb1 3ae7 0227 a710 7b00 500a 0000 0300 3200 > 0060 0000 0000 aaaa 0300 0000 0800 > ath0: ath_tx_default_comp: bf 0xc293aa60: seqno 813: bf_next not NULL! > ath0: ath_tx_default_comp: bf 0xc29449c0: seqno 807: bf_next not NULL! > ath0: ath_tx_default_comp: bf 0xc2954f20: seqno 808: bf_next not NULL! > ath0: ath_tx_default_comp: bf 0xc2957780: seqno 809: bf_next not NULL! > ath0: ath_tx_default_comp: bf 0xc2936550: seqno 810: bf_next not NULL! > ath0: ath_tx_default_comp: bf 0xc293f4c0: seqno 811: bf_next not NULL! > _______________________________________________ > freebsd-wireless@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-wireless > To unsubscribe, send any mail to "freebsd-wireless-unsubscribe@freebsd.org" From owner-freebsd-wireless@FreeBSD.ORG Tue Nov 5 18:23:17 2013 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 8130580; Tue, 5 Nov 2013 18:23:17 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 5773F2C2E; Tue, 5 Nov 2013 18:23:17 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 57349B968; Tue, 5 Nov 2013 13:23:15 -0500 (EST) From: John Baldwin To: freebsd-arch@freebsd.org Subject: Re: service netif restart [iface] runs a wpa_supplicant twice Date: Tue, 5 Nov 2013 11:54:18 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20130906; KDE/4.5.5; amd64; ; ) References: <1382572583.1862.39.camel@eva02.mbsd> <1383419596.3253.42.camel@eva02.mbsd> In-Reply-To: MIME-Version: 1.0 Message-Id: <201311051154.18872.jhb@freebsd.org> Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 05 Nov 2013 13:23:15 -0500 (EST) Cc: clutton , "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: Tue, 05 Nov 2013 18:23:17 -0000 On Sunday, November 03, 2013 12:56:08 pm Adrian Chadd wrote: > On 2 November 2013 12:13, clutton wrote: > > [snip] > > > What was happened? netif tries to setup wlan0 (clone, wpa, dhcp, etc), > > when wlan0 interface occurs, devd runs another copy of netif. > > Well, it sounds like we need to pick an architecture _and_ fix the > behaviour here. > > Which is: > > > * I think wpa-supplicant should always run if it's required in /etc/rc.conf; > * netif should check if devd is configured and if so, just leave the > configuration up to devd > * if it isn't running, then devd should be responsible for > dhclient/add-to-wpa-config > > What we first have to establish is whether add_interface and > remove_interface (or whatever they're called) are correctly working, > for ethernet and wifi driver types. Then, we need to ensure they can > coexist (ie, one wpa_supplicant, but with both ethernet/wifi drivers > loaded and active on their relevant interfaces.) _then_ we can break > out the "stuff devd does" out of netif and have _either_ netif (x)or > devd call this new script to setup/teardown the interface runtime > state. > > How's that sound? Note that devd just runs netif (via /etc/pccard_ether), so it's already just one script, and having netif bail if devd is running would make netif not do anything in the common case. What normally happens during boot is that '/etc/rc.d/netif start' creates wlan0 and runs wpa_supplicant via 'childif_create' making a nested call to ifn_start for wlan0. That is, childif_create autoruns /etc/rc.d/netif explicitly after it creates the device. Probably that is what should be removed. That would let devd always start wpa_supplicant via /etc/pccard_ether. I've just tested this by doing a stop/start on iwn0 (parent of wlan0, so wlan0 gets destroyed and re-created) and it started wpa_supplicant correctly. Index: head/etc/network.subr =================================================================== --- network.subr (revision 257705) +++ network.subr (working copy) @@ -1429,9 +1429,6 @@ childif_create() fi ${IFCONFIG_CMD} $i name $child && cfg=0 fi - if autoif $child; then - ifn_start $child - fi done # Create vlan interfaces I also tested vlans created via vlans_ and they should use the same fix as well. Note that this model is more consistent with how cloned_interfaces works where ifn_start is not explicitly run when each interface is created. Instead, we rely on devd kicking off pccard_ether for those as well. -- John Baldwin From owner-freebsd-wireless@FreeBSD.ORG Tue Nov 5 19:03:49 2013 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id CD660652; Tue, 5 Nov 2013 19:03:49 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-qe0-x22e.google.com (mail-qe0-x22e.google.com [IPv6:2607:f8b0:400d:c02::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 6C43B2EFB; Tue, 5 Nov 2013 19:03:49 +0000 (UTC) Received: by mail-qe0-f46.google.com with SMTP id s14so5318656qeb.33 for ; Tue, 05 Nov 2013 11:03:48 -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:message-id:subject :from:to:cc:content-type; bh=NRYgCyKCjrafZHaWFLMoH708tu1m5BkpkvpvMT8gQAY=; b=YqzfkOJmN+zOJPkhsFvwEzrekVZZzX+p/B+GkT2wZicTVSrZkSn3zIm5+6Cr+8hOdj d8XQXqmTeYO56okM1SQ1CJaIgeqRpkv/tIALGvZNeonDafC1C4iXp9xFxAXxuBReehGe /p4ujE14zVzNKC16/JSXRx5KQGIHez1zltivyE5g4HOL9FDyAa0p3QLU6uwkE+aTGhbx 6ed98xMvHwvjA+7DUOfWQknjg+LVa2v+5x8O2+0FG+0A63xWf5xJYQAyeGJu6dNmpM65 9n5IhQd52DrxNv0iZFaam/oX60iqmqGzpji0OV/MbQBprBhISkr/jZe5y0joQ1E+PdLX m1PA== MIME-Version: 1.0 X-Received: by 10.49.59.115 with SMTP id y19mr31529010qeq.8.1383678228585; Tue, 05 Nov 2013 11:03:48 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.224.207.66 with HTTP; Tue, 5 Nov 2013 11:03:48 -0800 (PST) In-Reply-To: <201311051154.18872.jhb@freebsd.org> References: <1382572583.1862.39.camel@eva02.mbsd> <1383419596.3253.42.camel@eva02.mbsd> <201311051154.18872.jhb@freebsd.org> Date: Tue, 5 Nov 2013 11:03:48 -0800 X-Google-Sender-Auth: VQVObu6YbYwAdTlLt0xOukFlQ24 Message-ID: Subject: Re: service netif restart [iface] runs a wpa_supplicant twice From: Adrian Chadd To: John Baldwin Content-Type: text/plain; charset=ISO-8859-1 Cc: clutton , "freebsd-wireless@freebsd.org" , "freebsd-arch@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: Tue, 05 Nov 2013 19:03:49 -0000 On 5 November 2013 08:54, John Baldwin wrote: > Note that devd just runs netif (via /etc/pccard_ether), so it's already > just one script, and having netif bail if devd is running would make > netif not do anything in the common case. > > What normally happens during boot is that '/etc/rc.d/netif start' creates > wlan0 and runs wpa_supplicant via 'childif_create' making a nested call to > ifn_start for wlan0. That is, childif_create autoruns /etc/rc.d/netif > explicitly after it creates the device. Probably that is what should be > removed. That would let devd always start wpa_supplicant via > /etc/pccard_ether. I've just tested this by doing a stop/start on iwn0 > (parent of wlan0, so wlan0 gets destroyed and re-created) and it started > wpa_supplicant correctly. > > Index: head/etc/network.subr > =================================================================== > --- network.subr (revision 257705) > +++ network.subr (working copy) > @@ -1429,9 +1429,6 @@ childif_create() > fi > ${IFCONFIG_CMD} $i name $child && cfg=0 > fi > - if autoif $child; then > - ifn_start $child > - fi > done > > # Create vlan interfaces > > I also tested vlans created via vlans_ and they should use the same fix as > well. Note that this model is more consistent with how cloned_interfaces > works where ifn_start is not explicitly run when each interface is created. > Instead, we rely on devd kicking off pccard_ether for those as well. Well, if you'd like to do the honours.. ? I'd like this fixed before 10.0-REL. It should make the normal use case for wifi actually work reliably again. -adrian From owner-freebsd-wireless@FreeBSD.ORG Tue Nov 5 19:33:59 2013 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 01C8EAAA for ; Tue, 5 Nov 2013 19:33:59 +0000 (UTC) (envelope-from bschmidt@techwires.net) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 90A942119 for ; Tue, 5 Nov 2013 19:33:58 +0000 (UTC) Received: by mail-wi0-f172.google.com with SMTP id ez12so2660747wid.11 for ; Tue, 05 Nov 2013 11:33:50 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=RG92irbN9hCPPVhzWP35JsMJyAuanIyipef5rTDe6Lc=; b=OvTRcgb2Dzp0iEGMyL6LtqJ2qBdgnq57Oyn991NVGFBwRXvc9EjfO+mst3UAeEuaFC 3qKHgm5eaVgDrItcK7hC49M80+DHY/6g2kszlUf4RDENoltTh9j5W1WcsbpePFo4fyvB aKHcjnrdrhpU2cGJI8nCGsUy4Yw4leMW3pzQvnjAkTqC5AH7Tam5I3lb6b6lk2y8tmgZ Uld7HpjTwN7WmZ6MhXgXUEUC+BvVPnIVOaYrHehyFwgsnX0ADBXm/1td3XYQFSIRcslo oHhEELh+qSyLyXbrkd7EK0ZjV/szlHHQfgRamwqhOs9T4dJJMDMrs2SpccRroOjOfWKd Nv8w== X-Gm-Message-State: ALoCoQmASy3Bmjpcyyi4FE2tcWfw3Yx+jBXN1sYS3H2sKGUPw6SScGCwXLPIrP7EFFf0NAy0vzk6 MIME-Version: 1.0 X-Received: by 10.194.240.197 with SMTP id wc5mr19642081wjc.23.1383680030616; Tue, 05 Nov 2013 11:33:50 -0800 (PST) Received: by 10.227.226.196 with HTTP; Tue, 5 Nov 2013 11:33:50 -0800 (PST) X-Originating-IP: [88.67.223.128] In-Reply-To: <201311051154.18872.jhb@freebsd.org> References: <1382572583.1862.39.camel@eva02.mbsd> <1383419596.3253.42.camel@eva02.mbsd> <201311051154.18872.jhb@freebsd.org> Date: Tue, 5 Nov 2013 20:33:50 +0100 Message-ID: Subject: Re: service netif restart [iface] runs a wpa_supplicant twice From: Bernhard Schmidt To: John Baldwin Content-Type: text/plain; charset=ISO-8859-1 Cc: clutton , "freebsd-wireless@freebsd.org" , freebsd-arch@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: Tue, 05 Nov 2013 19:33:59 -0000 On Tue, Nov 5, 2013 at 5:54 PM, John Baldwin wrote: > On Sunday, November 03, 2013 12:56:08 pm Adrian Chadd wrote: >> On 2 November 2013 12:13, clutton wrote: >> >> [snip] >> >> > What was happened? netif tries to setup wlan0 (clone, wpa, dhcp, etc), >> > when wlan0 interface occurs, devd runs another copy of netif. >> >> Well, it sounds like we need to pick an architecture _and_ fix the >> behaviour here. >> >> Which is: >> >> >> * I think wpa-supplicant should always run if it's required in /etc/rc.conf; >> * netif should check if devd is configured and if so, just leave the >> configuration up to devd >> * if it isn't running, then devd should be responsible for >> dhclient/add-to-wpa-config >> >> What we first have to establish is whether add_interface and >> remove_interface (or whatever they're called) are correctly working, >> for ethernet and wifi driver types. Then, we need to ensure they can >> coexist (ie, one wpa_supplicant, but with both ethernet/wifi drivers >> loaded and active on their relevant interfaces.) _then_ we can break >> out the "stuff devd does" out of netif and have _either_ netif (x)or >> devd call this new script to setup/teardown the interface runtime >> state. >> >> How's that sound? > > Note that devd just runs netif (via /etc/pccard_ether), so it's already > just one script, and having netif bail if devd is running would make > netif not do anything in the common case. > > What normally happens during boot is that '/etc/rc.d/netif start' creates > wlan0 and runs wpa_supplicant via 'childif_create' making a nested call to > ifn_start for wlan0. That is, childif_create autoruns /etc/rc.d/netif > explicitly after it creates the device. Probably that is what should be > removed. That would let devd always start wpa_supplicant via > /etc/pccard_ether. I've just tested this by doing a stop/start on iwn0 > (parent of wlan0, so wlan0 gets destroyed and re-created) and it started > wpa_supplicant correctly. > > Index: head/etc/network.subr > =================================================================== > --- network.subr (revision 257705) > +++ network.subr (working copy) > @@ -1429,9 +1429,6 @@ childif_create() > fi > ${IFCONFIG_CMD} $i name $child && cfg=0 > fi > - if autoif $child; then > - ifn_start $child > - fi > done > > # Create vlan interfaces > > I also tested vlans created via vlans_ and they should use the same fix as > well. Note that this model is more consistent with how cloned_interfaces > works where ifn_start is not explicitly run when each interface is created. > Instead, we rely on devd kicking off pccard_ether for those as well. That looks sane too me. Just one question, I remember that devd is disabled during boot and activated later through a sysctl (to ignore events entirely), is this the case before or after netif is running? I guess it is activated after netif, otherwise we would have seen this issue on booting and not just during netif restart. -- Bernhard From owner-freebsd-wireless@FreeBSD.ORG Tue Nov 5 22:19:31 2013 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id EDA65A58; Tue, 5 Nov 2013 22:19:31 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A7F4A2BA3; Tue, 5 Nov 2013 22:19:31 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 4D992B98F; Tue, 5 Nov 2013 17:19:30 -0500 (EST) From: John Baldwin To: Bernhard Schmidt Subject: Re: service netif restart [iface] runs a wpa_supplicant twice Date: Tue, 5 Nov 2013 17:17:30 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20130906; KDE/4.5.5; amd64; ; ) References: <1382572583.1862.39.camel@eva02.mbsd> <201311051154.18872.jhb@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201311051717.30519.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 05 Nov 2013 17:19:30 -0500 (EST) Cc: clutton , "freebsd-wireless@freebsd.org" , freebsd-arch@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: Tue, 05 Nov 2013 22:19:32 -0000 On Tuesday, November 05, 2013 2:33:50 pm Bernhard Schmidt wrote: > On Tue, Nov 5, 2013 at 5:54 PM, John Baldwin wrote: > > On Sunday, November 03, 2013 12:56:08 pm Adrian Chadd wrote: > >> On 2 November 2013 12:13, clutton wrote: > >> > >> [snip] > >> > >> > What was happened? netif tries to setup wlan0 (clone, wpa, dhcp, etc), > >> > when wlan0 interface occurs, devd runs another copy of netif. > >> > >> Well, it sounds like we need to pick an architecture _and_ fix the > >> behaviour here. > >> > >> Which is: > >> > >> > >> * I think wpa-supplicant should always run if it's required in /etc/rc.conf; > >> * netif should check if devd is configured and if so, just leave the > >> configuration up to devd > >> * if it isn't running, then devd should be responsible for > >> dhclient/add-to-wpa-config > >> > >> What we first have to establish is whether add_interface and > >> remove_interface (or whatever they're called) are correctly working, > >> for ethernet and wifi driver types. Then, we need to ensure they can > >> coexist (ie, one wpa_supplicant, but with both ethernet/wifi drivers > >> loaded and active on their relevant interfaces.) _then_ we can break > >> out the "stuff devd does" out of netif and have _either_ netif (x)or > >> devd call this new script to setup/teardown the interface runtime > >> state. > >> > >> How's that sound? > > > > Note that devd just runs netif (via /etc/pccard_ether), so it's already > > just one script, and having netif bail if devd is running would make > > netif not do anything in the common case. > > > > What normally happens during boot is that '/etc/rc.d/netif start' creates > > wlan0 and runs wpa_supplicant via 'childif_create' making a nested call to > > ifn_start for wlan0. That is, childif_create autoruns /etc/rc.d/netif > > explicitly after it creates the device. Probably that is what should be > > removed. That would let devd always start wpa_supplicant via > > /etc/pccard_ether. I've just tested this by doing a stop/start on iwn0 > > (parent of wlan0, so wlan0 gets destroyed and re-created) and it started > > wpa_supplicant correctly. > > > > Index: head/etc/network.subr > > =================================================================== > > --- network.subr (revision 257705) > > +++ network.subr (working copy) > > @@ -1429,9 +1429,6 @@ childif_create() > > fi > > ${IFCONFIG_CMD} $i name $child && cfg=0 > > fi > > - if autoif $child; then > > - ifn_start $child > > - fi > > done > > > > # Create vlan interfaces > > > > I also tested vlans created via vlans_ and they should use the same fix as > > well. Note that this model is more consistent with how cloned_interfaces > > works where ifn_start is not explicitly run when each interface is created. > > Instead, we rely on devd kicking off pccard_ether for those as well. > > That looks sane too me. > > Just one question, I remember that devd is disabled during boot and > activated later through a sysctl (to ignore events entirely), is this > the case before or after netif is running? I guess it is activated > after netif, otherwise we would have seen this issue on booting and > not just during netif restart. Hmm, devd starts after netif, but it just worked fine for me when I booted up. I also misspoke about cloned_interfaces. We manually add the cloned_interface list to the list of interfaces /etc/rc.d/netif iterates over. What I am puzzled by is that this just worked for me during a test boot. Hmm, it looks like devctl is no longer disabled during boot and then explicitly enabled by devd. devctl is now always enabled during boot, but capped at 1000 entries to avoid leaking memory. In fact, it looks like devd tries to recreate a few interfaces after netif finishes and is generally confused. I tried again with devd_flags set to "-n" to flush the initial set of events on boot. This removed the multiple calls to netif on boot on my laptop, but somehow wpa_supplicant is still being started by devd (and I'm not sure how now). Maybe we should bring back the ifn_start calls, but only do them if devd is not running (i.e. during boot) as Adrian suggested? -- John Baldwin From owner-freebsd-wireless@FreeBSD.ORG Wed Nov 6 01:15:08 2013 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 8989B2EF for ; Wed, 6 Nov 2013 01:15:08 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-qa0-x22e.google.com (mail-qa0-x22e.google.com [IPv6:2607:f8b0:400d:c00::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 4EBA42449 for ; Wed, 6 Nov 2013 01:15:08 +0000 (UTC) Received: by mail-qa0-f46.google.com with SMTP id j7so1613890qaq.5 for ; Tue, 05 Nov 2013 17:15:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=hG48DFlk3WLqGFB+bdhojbN5SwlcfYIifYBh29Si9fo=; b=JDhK33L55jvxzQCzSKLZflRoOtHlD/baUMDN3rLShtArOHel0rKq+WDwHpulRQZUuW EnRufLmITCuiFuINXz+FYPFR8EK/Mg8t84W9BxCr6wM4e2PV1aRpLwJi4XL8KxNSTfrH c3XV/JqHVtcS2uhqtsuvfmVEe/I+CYldwoNuHxKN7dneaFJAiSHQpNH2C9xxxM9GTbvI lQvMbsFf5b6jm1WdmmgT0mEkp5nvKPfeQ3Cqo9NtU6qmaThvLZ8mODZiBEJVI+vvO+51 lxTzyMkaWUmYYucxYSGLsHBdzx7fuGp0+HFW1j2sDm/Zm/PyL0okzUjADc05CYCES0ru Tz+A== MIME-Version: 1.0 X-Received: by 10.224.63.199 with SMTP id c7mr2315307qai.74.1383700507345; Tue, 05 Nov 2013 17:15:07 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.224.207.66 with HTTP; Tue, 5 Nov 2013 17:15:07 -0800 (PST) Date: Tue, 5 Nov 2013 17:15:07 -0800 X-Google-Sender-Auth: KdbOy0ag2eyh96nQMNPSZs0Sydo Message-ID: Subject: [iwn] my first attempt at porting cedric's hardware update patches over From: Adrian Chadd To: "freebsd-wireless@freebsd.org" , Cedric GROSS 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: Wed, 06 Nov 2013 01:15:08 -0000 Hi, So: http://people.freebsd.org/~adrian/iwn/20131105-iwn-update-works-full-5100-5.diff This is my attempt at merging in all of Cedric's work to date, _minus_ the PAN stuff. Ie, it's only the hardware addons. It turns out that it's not that big a change - a large part of the diff is just the config options. The biggest annoyance here is the calibration stuff. If the wrong calibration commands are sent up (ie, not all of them, in the right order!) then the firmware just panics after association. So, all I've done thus far is test it on my Intel 5100. Next is testing it on the 4965. After that, I'll try the 6xxx, 2xxx and 1xxx / 100 series stuff. I'd appreciate some testing of this. It's against -HEAD, so yes, you'll have to run -HEAD. Thanks, -adrian From owner-freebsd-wireless@FreeBSD.ORG Wed Nov 6 07:48:50 2013 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 55091A47; Wed, 6 Nov 2013 07:48:50 +0000 (UTC) (envelope-from hiren.panchasara@gmail.com) Received: from mail-ee0-x231.google.com (mail-ee0-x231.google.com [IPv6:2a00:1450:4013:c00::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id BF0E328BE; Wed, 6 Nov 2013 07:48:49 +0000 (UTC) Received: by mail-ee0-f49.google.com with SMTP id e52so2308302eek.36 for ; Tue, 05 Nov 2013 23:48:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=xZbJXciaLno14ZHih8VuZUwKUtFChg2KPemczavamPw=; b=ZaK+pw3nzQ5YTNpDlz+24wGHL4QXn7ctsBeDf30hDymKR54yy14QJZ4ccWXuY9rRqg N3wrOQ+0KMlwhK3moWPr1y8GScr0zFCzywm/66SlvcwWD50ZW+h6r5kNN43APPTZkZzP af72xPPXHOtJ8SaSwUTEVas8Bdw9U2tjBhQF0zv1rgrzw+X64JurJd/Y8acii+yjmats COLHeYOuQ+b7adZK/UgXnLOZOYszsew0ZKSCz95Mba9bYbZXPj8fJYdjpYNZ3/lQv7Zy 8SCrUl/JUkThL0YUPfcb/PqKtyeOUol4zWnfl4nfYNcxuk82eTTmS6STwqMEUGu2Ijgl s5dA== MIME-Version: 1.0 X-Received: by 10.14.209.197 with SMTP id s45mr1596867eeo.92.1383724128224; Tue, 05 Nov 2013 23:48:48 -0800 (PST) Received: by 10.14.127.195 with HTTP; Tue, 5 Nov 2013 23:48:47 -0800 (PST) In-Reply-To: References: Date: Tue, 5 Nov 2013 23:48:47 -0800 Message-ID: Subject: Re: [iwn] my first attempt at porting cedric's hardware update patches over From: hiren panchasara To: Adrian Chadd Content-Type: text/plain; charset=UTF-8 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: Wed, 06 Nov 2013 07:48:50 -0000 On Tue, Nov 5, 2013 at 5:15 PM, Adrian Chadd wrote: > Hi, > > So: > > http://people.freebsd.org/~adrian/iwn/20131105-iwn-update-works-full-5100-5.diff > I'd appreciate some testing of this. It's against -HEAD, so yes, > you'll have to run -HEAD. Seems to be doing alright on my Centrino Advanced-N 6205. I will report back if things go sideways. Thank you for your work, Hiren From owner-freebsd-wireless@FreeBSD.ORG Wed Nov 6 19:18:24 2013 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 81C4B759; Wed, 6 Nov 2013 19:18:24 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 375482647; Wed, 6 Nov 2013 19:18:24 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 3AF05B96C; Wed, 6 Nov 2013 14:18:23 -0500 (EST) From: John Baldwin To: freebsd-arch@freebsd.org Subject: Re: service netif restart [iface] runs a wpa_supplicant twice Date: Wed, 6 Nov 2013 11:59:14 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20130906; KDE/4.5.5; amd64; ; ) References: <1382572583.1862.39.camel@eva02.mbsd> <201311051717.30519.jhb@freebsd.org> In-Reply-To: <201311051717.30519.jhb@freebsd.org> MIME-Version: 1.0 Message-Id: <201311061159.14824.jhb@freebsd.org> Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 06 Nov 2013 14:18:23 -0500 (EST) Cc: clutton , "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: Wed, 06 Nov 2013 19:18:24 -0000 On Tuesday, November 05, 2013 5:17:30 pm John Baldwin wrote: > On Tuesday, November 05, 2013 2:33:50 pm Bernhard Schmidt wrote: > > On Tue, Nov 5, 2013 at 5:54 PM, John Baldwin wrote: > > > On Sunday, November 03, 2013 12:56:08 pm Adrian Chadd wrote: > > >> On 2 November 2013 12:13, clutton wrote: > > >> > > >> [snip] > > >> > > >> > What was happened? netif tries to setup wlan0 (clone, wpa, dhcp, etc), > > >> > when wlan0 interface occurs, devd runs another copy of netif. > > >> > > >> Well, it sounds like we need to pick an architecture _and_ fix the > > >> behaviour here. > > >> > > >> Which is: > > >> > > >> > > >> * I think wpa-supplicant should always run if it's required in /etc/rc.conf; > > >> * netif should check if devd is configured and if so, just leave the > > >> configuration up to devd > > >> * if it isn't running, then devd should be responsible for > > >> dhclient/add-to-wpa-config > > >> > > >> What we first have to establish is whether add_interface and > > >> remove_interface (or whatever they're called) are correctly working, > > >> for ethernet and wifi driver types. Then, we need to ensure they can > > >> coexist (ie, one wpa_supplicant, but with both ethernet/wifi drivers > > >> loaded and active on their relevant interfaces.) _then_ we can break > > >> out the "stuff devd does" out of netif and have _either_ netif (x)or > > >> devd call this new script to setup/teardown the interface runtime > > >> state. > > >> > > >> How's that sound? > > > > > > Note that devd just runs netif (via /etc/pccard_ether), so it's already > > > just one script, and having netif bail if devd is running would make > > > netif not do anything in the common case. > > > > > > What normally happens during boot is that '/etc/rc.d/netif start' creates > > > wlan0 and runs wpa_supplicant via 'childif_create' making a nested call to > > > ifn_start for wlan0. That is, childif_create autoruns /etc/rc.d/netif > > > explicitly after it creates the device. Probably that is what should be > > > removed. That would let devd always start wpa_supplicant via > > > /etc/pccard_ether. I've just tested this by doing a stop/start on iwn0 > > > (parent of wlan0, so wlan0 gets destroyed and re-created) and it started > > > wpa_supplicant correctly. > > > > > > Index: head/etc/network.subr > > > =================================================================== > > > --- network.subr (revision 257705) > > > +++ network.subr (working copy) > > > @@ -1429,9 +1429,6 @@ childif_create() > > > fi > > > ${IFCONFIG_CMD} $i name $child && cfg=0 > > > fi > > > - if autoif $child; then > > > - ifn_start $child > > > - fi > > > done > > > > > > # Create vlan interfaces > > > > > > I also tested vlans created via vlans_ and they should use the same fix as > > > well. Note that this model is more consistent with how cloned_interfaces > > > works where ifn_start is not explicitly run when each interface is created. > > > Instead, we rely on devd kicking off pccard_ether for those as well. > > > > That looks sane too me. > > > > Just one question, I remember that devd is disabled during boot and > > activated later through a sysctl (to ignore events entirely), is this > > the case before or after netif is running? I guess it is activated > > after netif, otherwise we would have seen this issue on booting and > > not just during netif restart. > > Hmm, devd starts after netif, but it just worked fine for me when I booted up. > I also misspoke about cloned_interfaces. We manually add the cloned_interface > list to the list of interfaces /etc/rc.d/netif iterates over. What I am > puzzled by is that this just worked for me during a test boot. Hmm, it looks like > devctl is no longer disabled during boot and then explicitly enabled by devd. > devctl is now always enabled during boot, but capped at 1000 entries to avoid > leaking memory. In fact, it looks like devd tries to recreate a few interfaces > after netif finishes and is generally confused. I tried again with devd_flags > set to "-n" to flush the initial set of events on boot. This removed the > multiple calls to netif on boot on my laptop, but somehow wpa_supplicant is > still being started by devd (and I'm not sure how now). I've hacked devd some more and can now see what is going on. -n doesn't do what I thought it does. It does not throw away pending events on startup, it just makes devd not fork until it has walked the initial set of events. The kernel changed (a while ago) to queue the first 1000 events until devd starts up. This means that in practice devd gets arrival events for all devices in the system as soon as it starts up and triggers duplicate invocations of netif after netif finishes. However, /etc/pccard_ether ignores attempts to start a device that is already up, so this should be a no-op on bootup (if my change is reverted) as the interfaces should already be configured by the time devd starts. I suspect what happens in multiuser is that devd fires off pccard_ether and sees that the interface isn't up before the original netif has a chance to invoke the nested ifn_start. We could perhaps change it so we only invoke ifn_start if devd isn't running. One other thought: I restart my wireless interfaces by doing 'sh /etc/rc.d/netif restart wlan0', not 'iwn0'. This doesn't teardown/recreate the wlan0 device, so it doesn't suffer from the issue reported by the OP. Here is a change I've tested that seems to do the right thing both at boot time and doing a restart of either iwn0 or wlan0 at runtime. If devd is running it leaves the task of starting an interface up to devd, otherwise (such as during boot), it configures the new child interface synchronously. Note that pgrep is in /bin. Index: network.subr =================================================================== --- network.subr (revision 257747) +++ network.subr (working copy) @@ -1406,10 +1406,14 @@ clone_down() # childif_create() { - local cfg child child_vlans child_wlans create_args debug_flags ifn i + local cfg child child_vlans child_wlans create_args debug_flags devd \ + ifn i cfg=1 ifn=$1 + # Check if devd is running + devd=$(pgrep devd) + # Create wireless interfaces child_wlans=`get_if_var $ifn wlans_IF` @@ -1429,6 +1433,9 @@ childif_create() fi ${IFCONFIG_CMD} $i name $child && cfg=0 fi + if [ -z "$devd" ] && autoif $child; then + ifn_start $child + fi done # Create vlan interfaces @@ -1452,6 +1459,9 @@ childif_create() ${IFCONFIG_CMD} $i name $child && cfg=0 fi fi + if [ -z "$devd" ] && autoif $child; then + ifn_start $child + fi done return ${cfg} -- John Baldwin From owner-freebsd-wireless@FreeBSD.ORG Wed Nov 6 20:46:04 2013 Return-Path: Delivered-To: freebsd-wireless@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 5ABA2CA4; Wed, 6 Nov 2013 20:46:04 +0000 (UTC) (envelope-from gavin@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 2DE8F2CB9; Wed, 6 Nov 2013 20:46:04 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id rA6Kk4kY069718; Wed, 6 Nov 2013 20:46:04 GMT (envelope-from gavin@freefall.freebsd.org) Received: (from gavin@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id rA6Kk4ID069717; Wed, 6 Nov 2013 20:46:04 GMT (envelope-from gavin) Date: Wed, 6 Nov 2013 20:46:04 GMT Message-Id: <201311062046.rA6Kk4ID069717@freefall.freebsd.org> To: gavin@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-wireless@FreeBSD.org From: gavin@FreeBSD.org Subject: Re: misc/183727: [wlan] ENOBUFFS incorrectly returned when tx packet is deferred due to power management 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: Wed, 06 Nov 2013 20:46:04 -0000 Synopsis: [wlan] ENOBUFFS incorrectly returned when tx packet is deferred due to power management Responsible-Changed-From-To: freebsd-bugs->freebsd-wireless Responsible-Changed-By: gavin Responsible-Changed-When: Wed Nov 6 20:45:41 UTC 2013 Responsible-Changed-Why: Over to -wireless http://www.freebsd.org/cgi/query-pr.cgi?pr=183727 From owner-freebsd-wireless@FreeBSD.ORG Wed Nov 6 23:20:39 2013 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id DD02F837 for ; Wed, 6 Nov 2013 23:20:39 +0000 (UTC) (envelope-from vince@unsane.co.uk) Received: from unsane.co.uk (unsane-pt.tunnel.tserv5.lon1.ipv6.he.net [IPv6:2001:470:1f08:110::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D41722715 for ; Wed, 6 Nov 2013 23:20:38 +0000 (UTC) Received: from vincemacbook.unsane.co.uk (vincemacbook.unsane.co.uk [10.10.10.20]) (authenticated bits=0) by unsane.co.uk (8.14.7/8.14.6) with ESMTP id rA6NKXwo011762 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Wed, 6 Nov 2013 23:20:34 GMT (envelope-from vince@unsane.co.uk) Message-ID: <527ACEC1.1050802@unsane.co.uk> Date: Wed, 06 Nov 2013 23:20:33 +0000 From: Vincent Hoffman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: "freebsd-wireless@freebsd.org" Subject: Odd issue with ath and 2 IPs on interface at boot X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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: Wed, 06 Nov 2013 23:20:39 -0000 Hi, I'm trying to bring up a wlan interface with 2 IPs on it so I can NAT other devices on the wireless network. If I try and configure both IPs at boot via rc.conf I get no link and logs as follows Many repeating Nov 5 23:02:34 ostracod wpa_supplicant[676]: wlan0: Failed to initiate AP scan Nov 5 23:02:35 ostracod kernel: ath0: ath_legacy_rx_tasklet: sc_inreset_cnt > 0; skipping Nov 5 23:02:35 ostracod wpa_supplicant[676]: ioctl[SIOCS80211, op=103, val=0, arg_len=128]: Operation now in progress Nov 5 23:02:35 ostracod wpa_supplicant[676]: wlan0: Failed to initiate AP scan with the occasional Nov 5 23:04:51 ostracod kernel: ath0: ath_raw_xmit: sc_inreset_cnt > 0; bailing Nov 5 23:04:51 ostracod kernel: ath0: ath_raw_xmit: sc_inreset_cnt > 0; bailing in rc.conf I have: wlans_ath0="wlan0" ifconfig_wlan0="WPA inet 85.233.185.162/29 -bgscan" ifconfig_wlan0_alias0="inet 10.10.10.1/24" If however I add just one address and then create the alias manually later It works fine. ath device details ath0: mem 0xfebf0000-0xfebfffff irq 16 at device 0.0 on pci4 ath0: AR2425 mac 14.2 RF5424 phy 7.0 ath0: 2GHz radio: 0x0000; 5GHz radio: 0x00a2 ath0@pci0:4:0:0: class=0x020000 card=0x7131144f chip=0x001c168c rev=0x01 hdr=0x00 vendor = 'Atheros Communications Inc.' device = 'AR242x / AR542x Wireless Network Adapter (PCI-Express)' class = network subclass = ethernet OS details: FreeBSD ostracod.unsane.co.uk 10.0-BETA2 FreeBSD 10.0-BETA2 #71 r257498: Fri Nov 1 17:31:01 GMT 2013 toor@ostracod.unsane.co.uk:/scratch/obj/usr/src/sys/OSTRACOD amd64 It seems unlikely this is expected and i'm not even sure its ath based but I dont have any other wireless interfaces to test with. Any suggestions? The system is in use at the moment but I can test from time to time. Vince From owner-freebsd-wireless@FreeBSD.ORG Wed Nov 6 23:22:33 2013 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id DEEAB962 for ; Wed, 6 Nov 2013 23:22:32 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-qa0-x233.google.com (mail-qa0-x233.google.com [IPv6:2607:f8b0:400d:c00::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A1ACE2753 for ; Wed, 6 Nov 2013 23:22:32 +0000 (UTC) Received: by mail-qa0-f51.google.com with SMTP id hu16so360021qab.17 for ; Wed, 06 Nov 2013 15:22:30 -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:message-id:subject :from:to:cc:content-type; bh=hiBi+hgNsJMdT+6zZIK2ALeX7Kev6BymLs13a0+x4Z8=; b=PwSY+J088qdqcxIlgdUVZ8AhyNQ4tyYv+HFZ1hR352JR62Nz/2eH/vZepYZrE5s+kP rFzi7mMb+g7CST8u4m/i/pOvrU34sgj1lvtMpCkJn47KaAmn4wObUjw+LykTxPqmsfwd bmxE8Ho1DB82DJmMOU6w/oDn5Mg1bdtomJPVn6ngdBlRmoIsSFVeMg8MUVF2eS8PXboF qL3ioDPMtVgjybrkY+XQLbBQEP9wdBSnWmPFqsjisrG0jqxuVnknCDbVU+MB9F917xyM 44frzFKanaTPikXkZAnMiBWuk0JA43/+XrvvOZ0JOlNEOGcOprw3i3KZqBqRQrcx7yKe OhbA== MIME-Version: 1.0 X-Received: by 10.224.51.131 with SMTP id d3mr9744171qag.0.1383780150794; Wed, 06 Nov 2013 15:22:30 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.224.207.66 with HTTP; Wed, 6 Nov 2013 15:22:30 -0800 (PST) In-Reply-To: <527ACEC1.1050802@unsane.co.uk> References: <527ACEC1.1050802@unsane.co.uk> Date: Wed, 6 Nov 2013 15:22:30 -0800 X-Google-Sender-Auth: ssjNGFj_Pqnphw0oJmOljz_gcKo Message-ID: Subject: Re: Odd issue with ath and 2 IPs on interface at boot From: Adrian Chadd To: Vincent Hoffman 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: Wed, 06 Nov 2013 23:22:33 -0000 There's bugs with how interfaces are setup and wpa_supplicant is being called. So I think this is just fallout from that. :( -adrian On 6 November 2013 15:20, Vincent Hoffman wrote: > Hi, > I'm trying to bring up a wlan interface with 2 IPs on it so I can > NAT other devices on the wireless network. > If I try and configure both IPs at boot via rc.conf I get no link and > logs as follows > Many repeating > Nov 5 23:02:34 ostracod wpa_supplicant[676]: wlan0: Failed to initiate > AP scan > Nov 5 23:02:35 ostracod kernel: ath0: ath_legacy_rx_tasklet: > sc_inreset_cnt > 0; skipping > Nov 5 23:02:35 ostracod wpa_supplicant[676]: ioctl[SIOCS80211, op=103, > val=0, arg_len=128]: Operation now in progress > Nov 5 23:02:35 ostracod wpa_supplicant[676]: wlan0: Failed to initiate > AP scan > with the occasional > Nov 5 23:04:51 ostracod kernel: ath0: ath_raw_xmit: sc_inreset_cnt > 0; > bailing > Nov 5 23:04:51 ostracod kernel: ath0: ath_raw_xmit: sc_inreset_cnt > 0; > bailing > > in rc.conf I have: > wlans_ath0="wlan0" > ifconfig_wlan0="WPA inet 85.233.185.162/29 -bgscan" > ifconfig_wlan0_alias0="inet 10.10.10.1/24" > > > If however I add just one address and then create the alias manually > later It works fine. > > ath device details > > ath0: mem 0xfebf0000-0xfebfffff irq 16 at device 0.0 > on pci4 > ath0: AR2425 mac 14.2 RF5424 phy 7.0 > ath0: 2GHz radio: 0x0000; 5GHz radio: 0x00a2 > > ath0@pci0:4:0:0: class=0x020000 card=0x7131144f chip=0x001c168c > rev=0x01 hdr=0x00 > vendor = 'Atheros Communications Inc.' > device = 'AR242x / AR542x Wireless Network Adapter (PCI-Express)' > class = network > subclass = ethernet > > OS details: > FreeBSD ostracod.unsane.co.uk 10.0-BETA2 FreeBSD 10.0-BETA2 #71 r257498: > Fri Nov 1 17:31:01 GMT 2013 > toor@ostracod.unsane.co.uk:/scratch/obj/usr/src/sys/OSTRACOD amd64 > > It seems unlikely this is expected and i'm not even sure its ath based > but I dont have any other wireless interfaces to test with. > Any suggestions? > The system is in use at the moment but I can test from time to time. > > Vince > > > _______________________________________________ > freebsd-wireless@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-wireless > To unsubscribe, send any mail to "freebsd-wireless-unsubscribe@freebsd.org" From owner-freebsd-wireless@FreeBSD.ORG Thu Nov 7 10:33:54 2013 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id DEF015D5; Thu, 7 Nov 2013 10:33:53 +0000 (UTC) (envelope-from vince@unsane.co.uk) Received: from unsane.co.uk (unsane-pt.tunnel.tserv5.lon1.ipv6.he.net [IPv6:2001:470:1f08:110::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id CB86A2067; Thu, 7 Nov 2013 10:33:52 +0000 (UTC) Received: from vincemacbook.unsane.co.uk (vincemacbook.unsane.co.uk [10.10.10.20]) (authenticated bits=0) by unsane.co.uk (8.14.7/8.14.6) with ESMTP id rA7AXeGD016216 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 7 Nov 2013 10:33:40 GMT (envelope-from vince@unsane.co.uk) Message-ID: <527B6C83.8090208@unsane.co.uk> Date: Thu, 07 Nov 2013 10:33:39 +0000 From: Vincent Hoffman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Adrian Chadd Subject: Re: Odd issue with ath and 2 IPs on interface at boot References: <527ACEC1.1050802@unsane.co.uk> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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: Thu, 07 Nov 2013 10:33:54 -0000 That makes sense. I just added a couple of lines to rc.local for now. will update/test again in a month or so. The other option I thought might work would be to make 2 nodes from the ath0, wlan0 (station mode) and wlan1 (access point) and have the inside addresses on a separate network, might try that later. Vince On 06/11/2013 23:22, Adrian Chadd wrote: > There's bugs with how interfaces are setup and wpa_supplicant is being > called. So I think this is just fallout from that. > > > :( > > > -adrian > > > On 6 November 2013 15:20, Vincent Hoffman wrote: >> Hi, >> I'm trying to bring up a wlan interface with 2 IPs on it so I can >> NAT other devices on the wireless network. >> If I try and configure both IPs at boot via rc.conf I get no link and >> logs as follows >> Many repeating >> Nov 5 23:02:34 ostracod wpa_supplicant[676]: wlan0: Failed to initiate >> AP scan >> Nov 5 23:02:35 ostracod kernel: ath0: ath_legacy_rx_tasklet: >> sc_inreset_cnt > 0; skipping >> Nov 5 23:02:35 ostracod wpa_supplicant[676]: ioctl[SIOCS80211, op=103, >> val=0, arg_len=128]: Operation now in progress >> Nov 5 23:02:35 ostracod wpa_supplicant[676]: wlan0: Failed to initiate >> AP scan >> with the occasional >> Nov 5 23:04:51 ostracod kernel: ath0: ath_raw_xmit: sc_inreset_cnt > 0; >> bailing >> Nov 5 23:04:51 ostracod kernel: ath0: ath_raw_xmit: sc_inreset_cnt > 0; >> bailing >> >> in rc.conf I have: >> wlans_ath0="wlan0" >> ifconfig_wlan0="WPA inet 85.233.185.162/29 -bgscan" >> ifconfig_wlan0_alias0="inet 10.10.10.1/24" >> >> >> If however I add just one address and then create the alias manually >> later It works fine. >> >> ath device details >> >> ath0: mem 0xfebf0000-0xfebfffff irq 16 at device 0.0 >> on pci4 >> ath0: AR2425 mac 14.2 RF5424 phy 7.0 >> ath0: 2GHz radio: 0x0000; 5GHz radio: 0x00a2 >> >> ath0@pci0:4:0:0: class=0x020000 card=0x7131144f chip=0x001c168c >> rev=0x01 hdr=0x00 >> vendor = 'Atheros Communications Inc.' >> device = 'AR242x / AR542x Wireless Network Adapter (PCI-Express)' >> class = network >> subclass = ethernet >> >> OS details: >> FreeBSD ostracod.unsane.co.uk 10.0-BETA2 FreeBSD 10.0-BETA2 #71 r257498: >> Fri Nov 1 17:31:01 GMT 2013 >> toor@ostracod.unsane.co.uk:/scratch/obj/usr/src/sys/OSTRACOD amd64 >> >> It seems unlikely this is expected and i'm not even sure its ath based >> but I dont have any other wireless interfaces to test with. >> Any suggestions? >> The system is in use at the moment but I can test from time to time. >> >> Vince >> >> >> _______________________________________________ >> freebsd-wireless@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-wireless >> To unsubscribe, send any mail to "freebsd-wireless-unsubscribe@freebsd.org" From owner-freebsd-wireless@FreeBSD.ORG Thu Nov 7 18:14:29 2013 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id A5CBA15C for ; Thu, 7 Nov 2013 18:14:29 +0000 (UTC) (envelope-from sean_bruno@yahoo.com) Received: from nm32-vm1.bullet.mail.bf1.yahoo.com (nm32-vm1.bullet.mail.bf1.yahoo.com [72.30.239.137]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 56C73230A for ; Thu, 7 Nov 2013 18:14:25 +0000 (UTC) Received: from [98.139.215.140] by nm32.bullet.mail.bf1.yahoo.com with NNFMP; 07 Nov 2013 18:08:24 -0000 Received: from [98.139.211.162] by tm11.bullet.mail.bf1.yahoo.com with NNFMP; 07 Nov 2013 18:08:24 -0000 Received: from [127.0.0.1] by smtp219.mail.bf1.yahoo.com with NNFMP; 07 Nov 2013 18:08:24 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1383847704; bh=EWngvPbaA39rXRJFyavg5kg1REzguHhI6e0AtrJQssQ=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:Subject:From:Reply-To:To:Cc:In-Reply-To:References:Content-Type:Date:Message-ID:Mime-Version:X-Mailer; b=4lytQkpS+5z80kJQZnECEH3jKXxzFTEPvyah7yLMdrIL1pScem6l9NJuyLQuWssXcNn9RiyfPPG2BAXVfM8gx/vyCzAloWLv3awDzOrFN5GJ3YZWK+9X4UdB3OZGZleoYOWKKSu6H/UHDNymLVjGv3Wrzp8rbYE03mvkeafFG3Q= X-Yahoo-Newman-Id: 326664.13260.bm@smtp219.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: IYKgRTQVM1nZNc49Au1OWXoMo3Xl9Hh0vrMZnEsU4ol_VtD TleVVor2yILf0BMEJEP6uk.pa2yeS3BqSztdyjg9PI1craRnTXLTvMTq3B9E Iek9UWb9G4AOLinQesN9YmUrd_mAPRPs8ACnKLIssvuxYHKq.fAoG5eQGlVT ZTj_mGRhQcdkaN9SGEBMlPz4Ir_NMzddwBHQ8yaV7C7lyrQY_slucQtgow4y eytKdlE1OMCCl0YHqTgfywpK6N1c3bNHPduGoQbTn7.3Y4.PCzs2Ljm3HNeR M3RPWM1YgrORE6UON9GyQvm6UCJyR6TZX6wRTbsTdVUqpFj344TyOfDRGqNo EPycJg4WiiC_ehloqTL841pejqvRYT7dgfxINbzwZ_YkrX07g7ieL36tzjG4 cB5.5uSDbOU3PLylE2uyjkgBk3fTf0hVzJ6REwsjkLzf4bzJArkSMNe6Ixt7 4ibuW97tHU2RlveQ1zxwpmP4xm9fjfXe.xllNpxLRyT3uOrBFsTBD9H3Olmj FIO8.35_BamCnOs..Csbi7l0zAgCiqTVw1f83nSF56Uec1PeUn0xX9PVVOVi n X-Yahoo-SMTP: u5BKR6OswBC_iZJVfGRoMkTIpc8pEA4- X-Rocket-Received: from [10.73.213.5] (sean_bruno@66.228.162.52 with ) by smtp219.mail.bf1.yahoo.com with SMTP; 07 Nov 2013 10:08:24 -0800 PST Subject: Re: [iwn] my first attempt at porting cedric's hardware update patches over From: Sean Bruno To: Adrian Chadd In-Reply-To: References: Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-d7qSQa3XamAjRGLPI8Dn" Date: Thu, 07 Nov 2013 10:08:21 -0800 Message-ID: <1383847701.1866.2.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Cc: "freebsd-wireless@freebsd.org" X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: sbruno@freebsd.org 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: Thu, 07 Nov 2013 18:14:29 -0000 --=-d7qSQa3XamAjRGLPI8Dn Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Tue, 2013-11-05 at 17:15 -0800, Adrian Chadd wrote: > Hi, >=20 > So: >=20 > http://people.freebsd.org/~adrian/iwn/20131105-iwn-update-works-full-5100= -5.diff >=20 > This is my attempt at merging in all of Cedric's work to date, _minus_ > the PAN stuff. Ie, it's only the hardware addons. It turns out that > it's not that big a change - a large part of the diff is just the > config options. >=20 > The biggest annoyance here is the calibration stuff. If the wrong > calibration commands are sent up (ie, not all of them, in the right > order!) then the firmware just panics after association. >=20 > So, all I've done thus far is test it on my Intel 5100. Next is > testing it on the 4965. After that, I'll try the 6xxx, 2xxx and 1xxx / > 100 series stuff. >=20 > I'd appreciate some testing of this. It's against -HEAD, so yes, > you'll have to run -HEAD. >=20 > Thanks, >=20 >=20 >=20 > -adrian > _______________________________________________ > freebsd-wireless@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-wireless > To unsubscribe, send any mail to "freebsd-wireless-unsubscribe@freebsd.or= g" Initial test looks good. I've enabled bluetooth to make sure that it doesn't break iwn(4) and I see no issues running on wireless. I reverted my hack to disable 11N support and iwn(4) still has serious issues negotiating with my $DAYJOB wireless APs. So, I'm still running with 11N disabled for now. sean --=-d7qSQa3XamAjRGLPI8Dn Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.15 (FreeBSD) iQEcBAABAgAGBQJSe9aqAAoJEBkJRdwI6BaHmFwH/3SR7MwyxzEJ4WC/v+qZ7VPN NFmmq4WVCjxT3U3UV8FEhMfVACa3pJZGLsHOdA6bKuOL5whDbIxwaugtSgX/P+gp xPdkkSe7KShQRRXHTGEzbhsHPPls9kSRZ2iMeFfOdmDqEfPE/cMRre1Y9BGGVw1H pA7+JqRuJG1aSLF/emIsH+ct2xJPWz+R8S3VJ5AEkIxOmnnBOn9E5fwWs0c4dxEM qS15hjqsvXpx0d0AUKYy7nZ64hjrgrA6EAqpWbpxBZUqcxxwkWiPByuy5IdPr9Gw 7U53IQW+kTz9626U0g5u9S9d1hU6JIkrzfS55tDu6lxMlVUo2feGLpDyXR8i0LA= =fCDT -----END PGP SIGNATURE----- --=-d7qSQa3XamAjRGLPI8Dn-- From owner-freebsd-wireless@FreeBSD.ORG Thu Nov 7 18:33:09 2013 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id B5DBD5BD; Thu, 7 Nov 2013 18:33:09 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-qc0-x22f.google.com (mail-qc0-x22f.google.com [IPv6:2607:f8b0:400d:c01::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 65E852430; Thu, 7 Nov 2013 18:33:09 +0000 (UTC) Received: by mail-qc0-f175.google.com with SMTP id e16so777027qcx.34 for ; Thu, 07 Nov 2013 10:33:08 -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:message-id:subject :from:to:cc:content-type; bh=vOJuNYOkapFgaQ2jhQf+nGFSJbENG1XrDR65HeOp8Vo=; b=Nd7GzsjHQhGb5GCJHX1sSzIvpe99i54GIu645SFS388dBgFzMxP9ccE3JCp81jd7UC G4/hOdmA61fVYpTO4bosgDE4a7zMpTiK/tdWzn3lwbwseVUQWV2SlanGKpbxi0OtR0Vw l5ETA+gQRtK0TmeSW2e2K/tbkrSXrTkcuZJwz1H/OB72Q2SA7bBjbEUnIopXTyW8xFVX Vvb+cDu3ITAFuK+YUEwPrR1ZFA8V5+x/W1aPjooj00TVT5YEdrBj+KF0Tbsh+ljij4W2 cNJ4FCs+c9JIBYRn+c2C+eum7dpi0akEclI6QWoAKoGFcSISh9+lQT+nmmqlENxa+9yB 48Fg== MIME-Version: 1.0 X-Received: by 10.224.28.130 with SMTP id m2mr16581657qac.98.1383849188572; Thu, 07 Nov 2013 10:33:08 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.224.207.66 with HTTP; Thu, 7 Nov 2013 10:33:08 -0800 (PST) In-Reply-To: <1383847701.1866.2.camel@localhost> References: <1383847701.1866.2.camel@localhost> Date: Thu, 7 Nov 2013 10:33:08 -0800 X-Google-Sender-Auth: URamG3tLeas0i2Vq5DPnfNJXH1U Message-ID: Subject: Re: [iwn] my first attempt at porting cedric's hardware update patches over From: Adrian Chadd To: Sean Bruno 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: Thu, 07 Nov 2013 18:33:09 -0000 I can't stay associated to Y!Guest with wpa_supplicant (11n). Connecting without wpa_supplicant works out very very well. So, maybe wpa_supplicant is bitching. It has 'locally_generated=1' which I believe says "wpa_supplicant made the decision!" Can you check your wpa_supplicant logs and see if the reason(s) it gives is locally generated? Would you also try connecting to Y!Guest without wpa_supplicant? Thanks! -adrian On 7 November 2013 10:08, Sean Bruno wrote: > On Tue, 2013-11-05 at 17:15 -0800, Adrian Chadd wrote: >> Hi, >> >> So: >> >> http://people.freebsd.org/~adrian/iwn/20131105-iwn-update-works-full-5100-5.diff >> >> This is my attempt at merging in all of Cedric's work to date, _minus_ >> the PAN stuff. Ie, it's only the hardware addons. It turns out that >> it's not that big a change - a large part of the diff is just the >> config options. >> >> The biggest annoyance here is the calibration stuff. If the wrong >> calibration commands are sent up (ie, not all of them, in the right >> order!) then the firmware just panics after association. >> >> So, all I've done thus far is test it on my Intel 5100. Next is >> testing it on the 4965. After that, I'll try the 6xxx, 2xxx and 1xxx / >> 100 series stuff. >> >> I'd appreciate some testing of this. It's against -HEAD, so yes, >> you'll have to run -HEAD. >> >> Thanks, >> >> >> >> -adrian >> _______________________________________________ >> freebsd-wireless@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-wireless >> To unsubscribe, send any mail to "freebsd-wireless-unsubscribe@freebsd.org" > > > Initial test looks good. I've enabled bluetooth to make sure that it > doesn't break iwn(4) and I see no issues running on wireless. > > I reverted my hack to disable 11N support and iwn(4) still has serious > issues negotiating with my $DAYJOB wireless APs. So, I'm still running > with 11N disabled for now. > > sean From owner-freebsd-wireless@FreeBSD.ORG Thu Nov 7 19:47:03 2013 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 447875ED for ; Thu, 7 Nov 2013 19:47:03 +0000 (UTC) (envelope-from lists@eitanadler.com) Received: from mail-qc0-x232.google.com (mail-qc0-x232.google.com [IPv6:2607:f8b0:400d:c01::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 0611D28E0 for ; Thu, 7 Nov 2013 19:47:02 +0000 (UTC) Received: by mail-qc0-f178.google.com with SMTP id x19so869503qcw.9 for ; Thu, 07 Nov 2013 11:47:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eitanadler.com; s=0xdeadbeef; h=mime-version:from:date:message-id:subject:to:content-type; bh=k3bRUWoJvd/6NvYItvafiPrv/u3OpgJRmheBJ6NHOhM=; b=RSokEN2nc0ywU2I5V/yI1Z54DGZnPFbioW/VrxZmq+MJfQZYAvEj+CWWXXOMqEEs+O +GCaaCClb5b37HvMpwo6ADKUvnnCG0HZws8rcL6uujyXtdlmS/EbOwdzq9hexjfiJQjD ka0jiXGbSeziZOGojii1xSuC2kGaUFFJOn+R4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=k3bRUWoJvd/6NvYItvafiPrv/u3OpgJRmheBJ6NHOhM=; b=DCiJczsg680TNf3NgWlzuUO/DXS8b8dunWVrup7CglVliAUl5IHaz6l8NWdN6ap+qX XKv1AcK2LeCQbITt70a0R9rJd0jwLxmNNJAp9wRe/Ca81spvgQ188kRZzZUoNTC01z63 PLH4d7jfvsrUGcuMUh+JTQn67VZlmFx/F89rhYfFQkZ+392BncZV6AIRFiiQpbby+opw 9IP3jPedg2DaLhaFbWOgaCKaOBbbkBqUH1qsd+t1vNF316XGAAYzTnO/R2uvrP39laUI HoCL1G7OL60H09MnOtqMbWpjymk77XPQj5nKabVmzexY8ESxVa3DEMoRDB3xEz27rsRf atrQ== X-Gm-Message-State: ALoCoQll85yNcA91SnO7Y11hA08hy9LrwRDKAaG5i8V4SxG0z6Ti7GxmXL2kdjA/IPvYPOnl23S1 X-Received: by 10.224.136.71 with SMTP id q7mr9801878qat.45.1383853622007; Thu, 07 Nov 2013 11:47:02 -0800 (PST) MIME-Version: 1.0 Received: by 10.96.63.101 with HTTP; Thu, 7 Nov 2013 11:46:31 -0800 (PST) From: Eitan Adler Date: Thu, 7 Nov 2013 14:46:31 -0500 Message-ID: Subject: Intro Centrino 2000 firmware error To: "freebsd-wireless@freebsd.org" Content-Type: text/plain; charset=UTF-8 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: Thu, 07 Nov 2013 19:47:03 -0000 With Adrian's latest patch: I am able to create wlan1 based on iwn0 iwn0@pci0:2:0:0: class=0x028000 card=0x42228086 chip=0x08918086 rev=0xc4 hdr=0x00 vendor = 'Intel Corporation' device = 'Centrino Wireless-N 2200' class = network However attempting to do wpa_supplicant (even for an open network) results in the following: iwn0: iwn_intr: fatal firmware error firmware error log: error type = "UNKNOWN" (0x00002776) program counter = 0x00009348 source line = 0x00000067 error data = 0x0408008000000002 branch link = 0x0000933600009336 interrupt link = 0x0000E1AE00000000 time = 29752 driver status: tx ring 0: qid=0 cur=0 queued=0 tx ring 1: qid=1 cur=0 queued=0 tx ring 2: qid=2 cur=0 queued=0 tx ring 3: qid=3 cur=0 queued=0 tx ring 4: qid=4 cur=9 queued=0 tx ring 5: qid=5 cur=0 queued=0 tx ring 6: qid=6 cur=0 queued=0 tx ring 7: qid=7 cur=0 queued=0 tx ring 8: qid=8 cur=0 queued=0 tx ring 9: qid=9 cur=0 queued=0 tx ring 10: qid=10 cur=0 queued=0 tx ring 11: qid=11 cur=0 queued=0 tx ring 12: qid=12 cur=0 queued=0 tx ring 13: qid=13 cur=0 queued=0 tx ring 14: qid=14 cur=0 queued=0 tx ring 15: qid=15 cur=0 queued=0 tx ring 16: qid=16 cur=0 queued=0 tx ring 17: qid=17 cur=0 queued=0 tx ring 18: qid=18 cur=0 queued=0 tx ring 19: qid=19 cur=0 queued=0 rx ring: cur=9 -- Eitan Adler From owner-freebsd-wireless@FreeBSD.ORG Thu Nov 7 19:54:16 2013 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id BD4668D5 for ; Thu, 7 Nov 2013 19:54:16 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-qc0-x231.google.com (mail-qc0-x231.google.com [IPv6:2607:f8b0:400d:c01::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 7F9432965 for ; Thu, 7 Nov 2013 19:54:16 +0000 (UTC) Received: by mail-qc0-f177.google.com with SMTP id u18so854837qcx.22 for ; Thu, 07 Nov 2013 11:54:15 -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:message-id:subject :from:to:cc:content-type; bh=08TVjhHcJEkiDu4EpJzDWH4M/qVnelqi23FT394qO8s=; b=AxT7BXX/Pd6XbiQqKnXeHRW60cRwB7zCOh66DeMGRoRlw/2YhdNdcbT05TwjQdaEeL Uc6qfcVo4HIBOSEHK5UxOn8yvWjjMqAfJ2kBFbCTJQOKJx1x/2fGYH0I9ZSaI+UbKGYv zCltrMnp7n8Oaz3g+FcxHQlkyM3J3ZlJVpJNpFu7+kxoP8Qxm/X9eXCvrm2vpJ2Lmx1H XTLXiuAoKLCeSx3Y6hz5/BEoNFH45C1SgxweXGcQnPJqUheVUjWOCLiM5lTv6O4K7+M/ 6OtmT4ymqg6oPLsdbATCAPIlTfSXW1Qdu0pCLQ7YeOeNIgd1QRYB2kZM2bW06SnLV7JB JZYA== MIME-Version: 1.0 X-Received: by 10.224.98.200 with SMTP id r8mr17782055qan.26.1383854055711; Thu, 07 Nov 2013 11:54:15 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.224.207.66 with HTTP; Thu, 7 Nov 2013 11:54:15 -0800 (PST) In-Reply-To: References: Date: Thu, 7 Nov 2013 11:54:15 -0800 X-Google-Sender-Auth: bhAzqwVekO5aijz9NAZXidZOmj0 Message-ID: Subject: Re: Intro Centrino 2000 firmware error From: Adrian Chadd To: Eitan Adler 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: Thu, 07 Nov 2013 19:54:16 -0000 Hi! Look at if_iwn_debug.h. turn on STATE, CMD, INTR and RECV. Then, try again. -adrian On 7 November 2013 11:46, Eitan Adler wrote: > With Adrian's latest patch: > > I am able to create wlan1 based on iwn0 > > iwn0@pci0:2:0:0: class=0x028000 card=0x42228086 chip=0x08918086 > rev=0xc4 hdr=0x00 > vendor = 'Intel Corporation' > device = 'Centrino Wireless-N 2200' > class = network > > However attempting to do wpa_supplicant (even for an open network) > results in the following: > > iwn0: iwn_intr: fatal firmware error > firmware error log: > error type = "UNKNOWN" (0x00002776) > program counter = 0x00009348 > source line = 0x00000067 > error data = 0x0408008000000002 > branch link = 0x0000933600009336 > interrupt link = 0x0000E1AE00000000 > time = 29752 > driver status: > tx ring 0: qid=0 cur=0 queued=0 > tx ring 1: qid=1 cur=0 queued=0 > tx ring 2: qid=2 cur=0 queued=0 > tx ring 3: qid=3 cur=0 queued=0 > tx ring 4: qid=4 cur=9 queued=0 > tx ring 5: qid=5 cur=0 queued=0 > tx ring 6: qid=6 cur=0 queued=0 > tx ring 7: qid=7 cur=0 queued=0 > tx ring 8: qid=8 cur=0 queued=0 > tx ring 9: qid=9 cur=0 queued=0 > tx ring 10: qid=10 cur=0 queued=0 > tx ring 11: qid=11 cur=0 queued=0 > tx ring 12: qid=12 cur=0 queued=0 > tx ring 13: qid=13 cur=0 queued=0 > tx ring 14: qid=14 cur=0 queued=0 > tx ring 15: qid=15 cur=0 queued=0 > tx ring 16: qid=16 cur=0 queued=0 > tx ring 17: qid=17 cur=0 queued=0 > tx ring 18: qid=18 cur=0 queued=0 > tx ring 19: qid=19 cur=0 queued=0 > rx ring: cur=9 > > > > -- > Eitan Adler > _______________________________________________ > freebsd-wireless@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-wireless > To unsubscribe, send any mail to "freebsd-wireless-unsubscribe@freebsd.org" From owner-freebsd-wireless@FreeBSD.ORG Thu Nov 7 20:09:54 2013 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id B9427EFF for ; Thu, 7 Nov 2013 20:09:54 +0000 (UTC) (envelope-from lists@eitanadler.com) Received: from mail-qe0-x234.google.com (mail-qe0-x234.google.com [IPv6:2607:f8b0:400d:c02::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 77C0C2A26 for ; Thu, 7 Nov 2013 20:09:54 +0000 (UTC) Received: by mail-qe0-f52.google.com with SMTP id w7so1015587qeb.11 for ; Thu, 07 Nov 2013 12:09:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eitanadler.com; s=0xdeadbeef; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=7sDouA9gGWZ8zYlwSz6wvAsQPmzygnzVIeGeIDc3rn4=; b=Le37oC+QN3Xwvqgt5rrut5AZ95Igs63Z+vkZ4FParladSvDP/Y8S+NjGFzZwpQ6xci mqnuw57MnFSlEbu4p7i01MdNsh8lh0yrh35yQyTYASCemFReeKJZu+LHDTV81ffu4vHL RQU4oa6kherrd0lKSaF6+mLtneP9yrvSuDoBg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=7sDouA9gGWZ8zYlwSz6wvAsQPmzygnzVIeGeIDc3rn4=; b=B6txeDaqJXdvaEYARkOqpM1sYoFGUEgEW7gG9i2NDMNM+/F8XU4WGsF34jETZEKh1b NmdaFcAqolxJB3zgNXRAT60hqlcR/OjH5JU8/wdELZfTlyZpdLZMNRWS5ZMocxuBTtCU ZYES4QNPcNi4qlO/7uJHcaXpUQ3ApJ0zVdEk9K9DZFaNP0db5rPOGrgMpO3VI9EBMZJs sMgf8e3W66vGMKp7VF+D0r8jFYW69R+VIz8I7vDtjmfYirwVcR3lmca21jiRHk5dM9Ye tIfCJveDcaq+2VeMDfi6zw1W2I9ow0y3MrSrOutqE7UHxHmWsuDSWC62tImUaAJvj/Vs EnjQ== X-Gm-Message-State: ALoCoQk+1B0v/0lGRNyr+rlhjQXtl8/hbyLOATtutqI+HbC/NNyc4/saoVWdMFCcVMDP+IRX5mRs X-Received: by 10.224.131.67 with SMTP id w3mr17866621qas.62.1383854993401; Thu, 07 Nov 2013 12:09:53 -0800 (PST) MIME-Version: 1.0 Received: by 10.96.63.101 with HTTP; Thu, 7 Nov 2013 12:09:23 -0800 (PST) In-Reply-To: References: From: Eitan Adler Date: Thu, 7 Nov 2013 15:09:23 -0500 Message-ID: Subject: Re: Intro Centrino 2000 firmware error To: Adrian Chadd Content-Type: text/plain; charset=UTF-8 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: Thu, 07 Nov 2013 20:09:54 -0000 [ top posting? ] On Thu, Nov 7, 2013 at 2:54 PM, Adrian Chadd wrote: > Hi! > > Look at if_iwn_debug.h. turn on STATE, CMD, INTR and RECV. Then, try again. I define IWN_DEBUG. Not sure what you mean by enabling STATE, CMD, etc. -- Eitan Adler From owner-freebsd-wireless@FreeBSD.ORG Thu Nov 7 20:12:45 2013 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 7C93A118 for ; Thu, 7 Nov 2013 20:12:45 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-qe0-x22c.google.com (mail-qe0-x22c.google.com [IPv6:2607:f8b0:400d:c02::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 3E6CE2A74 for ; Thu, 7 Nov 2013 20:12:45 +0000 (UTC) Received: by mail-qe0-f44.google.com with SMTP id 6so1015984qeb.17 for ; Thu, 07 Nov 2013 12:12:44 -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:message-id:subject :from:to:cc:content-type; bh=JxXnPmU5KOaL1S3D7TNpnxxJArXIKl+mRpKzjuD/gh4=; b=oCtNG8/rc7R9E/V8O7nZ14mbs43jBZOmcj6FaCNX+KUyYfA+dqFq2OJEGIr1ZH+R9u ISi1pdMnJHBgD1bcK3qKWLhoKQ+JXH3iqoi0cynhOSsEbl73eAU0788t1FijIBJWRnXS 6KHKtbA1BsNKq0Gk6brmNGC3EBn3Lt+mTlumLYy0FBUmGW0FeP39Rpa+roihdP5VA9Lp +g0Z9xWkFlq35UnqTJd+Gjkfb12ERw5tUiyyabk7o8YQy3gIQRUyVoIs6mnqLdwCNZSC s4d9LiOQe1tyoTl/+9A3YsA4cWqZg4InQSraWzAW7ltXBQCPZyhQNIxLJPZlYQhW7Q5h 6lhg== MIME-Version: 1.0 X-Received: by 10.224.111.197 with SMTP id t5mr17546755qap.49.1383855164384; Thu, 07 Nov 2013 12:12:44 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.224.207.66 with HTTP; Thu, 7 Nov 2013 12:12:44 -0800 (PST) In-Reply-To: References: Date: Thu, 7 Nov 2013 12:12:44 -0800 X-Google-Sender-Auth: SihKdPbh1eNn5BYu33jvh8GUKVw Message-ID: Subject: Re: Intro Centrino 2000 firmware error From: Adrian Chadd To: Eitan Adler 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: Thu, 07 Nov 2013 20:12:45 -0000 On 7 November 2013 12:09, Eitan Adler wrote: > [ top posting? ] > > On Thu, Nov 7, 2013 at 2:54 PM, Adrian Chadd wrote: >> Hi! >> >> Look at if_iwn_debug.h. turn on STATE, CMD, INTR and RECV. Then, try again. > > I define IWN_DEBUG. Not sure what you mean by enabling STATE, CMD, etc. > > Check if_iwn_debug.h for the bit mask value, and then sysctl dev.iwn.0.debug= -adrian From owner-freebsd-wireless@FreeBSD.ORG Thu Nov 7 20:15:10 2013 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 6594215F for ; Thu, 7 Nov 2013 20:15:10 +0000 (UTC) (envelope-from lists@eitanadler.com) Received: from mail-qc0-x22a.google.com (mail-qc0-x22a.google.com [IPv6:2607:f8b0:400d:c01::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 230BE2A91 for ; Thu, 7 Nov 2013 20:15:10 +0000 (UTC) Received: by mail-qc0-f170.google.com with SMTP id n9so901967qcw.29 for ; Thu, 07 Nov 2013 12:15:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eitanadler.com; s=0xdeadbeef; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=qWSn6Nwdi4i2DwwWC2CZdc+T7jte5rr5ni16edCgxfo=; b=Gaw5e0Qk9/uVjmmKTMZlK8GvJQ8iwyinZ5Tm9GscquOxNHia+gL+9qjrsEkroHMC/h IGlbrlfVHvljJmNROXyTBLsR7fCs4wjgDeth1BStOZHH88jmmGJDY4hUlmxzUjM64flE oBM53vE15zIaV1DxYeAagnlVnC2E+rpEiBmb0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=qWSn6Nwdi4i2DwwWC2CZdc+T7jte5rr5ni16edCgxfo=; b=hZ243n4Wj+InH5CcFzL6/448fZ79DjUZYney2YdIxwRxQJjFQ2/G44WMTYkZUJ256b Tc1LJ/SgpgKGrqcGW4aUMMHGnUpFhyPnH3M+o1C/N6YoB2TDH6+mhkREwc8UBzf+cNEh EX41TmhVVUSr2cVbU8wqO7TMeAFOWTyP6RCdb3UBaUN/Fimff9uTSdhka6zRfxtNQx2V xVpEqOmuI2MF8x72x0QRD+gcyLP+19u/PWe1kDxsyxANpL33hxVbYpnGaaVQDBEJa9v7 P4AKcjYgODQZf3BkkktbYhjHQ1/o6qNUsJr3Obi9fIeRCdDElqqGYMQBN4D9dnV5oOIL Fk4Q== X-Gm-Message-State: ALoCoQm5jHsc9lfXo2sppk1JIZkAnIQ8hW7HsJK8zwWo7/BL5mrH4Rr2XV3SiEFnL0+yzQEq8L9h X-Received: by 10.224.8.65 with SMTP id g1mr17741007qag.68.1383855309284; Thu, 07 Nov 2013 12:15:09 -0800 (PST) MIME-Version: 1.0 Received: by 10.96.63.101 with HTTP; Thu, 7 Nov 2013 12:14:39 -0800 (PST) In-Reply-To: References: From: Eitan Adler Date: Thu, 7 Nov 2013 15:14:39 -0500 Message-ID: Subject: Re: Intro Centrino 2000 firmware error To: Adrian Chadd Content-Type: text/plain; charset=UTF-8 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: Thu, 07 Nov 2013 20:15:10 -0000 On Thu, Nov 7, 2013 at 3:12 PM, Adrian Chadd wrote: > On 7 November 2013 12:09, Eitan Adler wrote: >> [ top posting? ] >> >> On Thu, Nov 7, 2013 at 2:54 PM, Adrian Chadd wrote: >>> Hi! >>> >>> Look at if_iwn_debug.h. turn on STATE, CMD, INTR and RECV. Then, try again. >> >> I define IWN_DEBUG. Not sure what you mean by enabling STATE, CMD, etc. >> >> > > Check if_iwn_debug.h for the bit mask value, and then sysctl > dev.iwn.0.debug= I set it to 0xFF FW: "2000 fw v18.168.6.1 build 0 ", build 0x0 using alternative 0 TLV type 16 reconized but not handled TLV type 17 reconized but not handled TLV type 6 reconized but not handled PAN Support found: 1 TLV type 8 reconized but not handled TLV type 9 reconized but not handled TLV type 10 reconized but not handled TLV type 11 reconized but not handled TLV type 12 reconized but not handled TLV type 13 reconized but not handled iwn_notif_intr: qid 0 idx 0 flags 0 type 1(UC_READY) len 36 microcode alive notification version=18.168 subtype=9 alive=1 iwn5000_ict_reset: enabling ICT iwn5000_send_wimax_coex: Configuring WiMAX coexistence iwn_notif_intr: qid 4 idx 0 flags 0 type 90(IWN5000_CMD_WIMAX_COEX) len 4 iwn_notif_intr: qid 0 idx 1 flags 0 type 98(UNKNOWN INTR NOTIF/CMD) len 8 iwn_notif_intr: qid 4 idx 1 flags 0 type 176(IWN_CMD_PHY_CALIB) len 4 iwn_notif_intr: qid 4 idx 2 flags 0 type 101(IWN5000_CMD_CALIB_CONFIG) len 8 iwn_notif_intr: qid 0 idx 2 flags 0 type 102(IWN5000_CMD_CALIB_RESULT) len 12 iwn_notif_intr: qid 0 idx 3 flags 0 type 102(IWN5000_CMD_CALIB_RESULT) len 520 iwn_notif_intr: qid 0 idx 4 flags 0 type 102(IWN5000_CMD_CALIB_RESULT) len 1352 iwn_notif_intr: qid 0 idx 5 flags 0 type 102(IWN5000_CMD_CALIB_RESULT) len 92 iwn_notif_intr: qid 0 idx 6 flags 0 type 103(IWN5000_CMD_CALIB_COMPLETE) len 8 iwn_notif_intr: qid 0 idx 0 flags 0 type 1(UC_READY) len 36 microcode alive notification version=18.168 subtype=1 alive=1 iwn5000_ict_reset: enabling ICT iwn5000_send_wimax_coex: Configuring WiMAX coexistence iwn_notif_intr: qid 4 idx 0 flags 0 type 90(IWN5000_CMD_WIMAX_COEX) len 4 iwn_notif_intr: qid 0 idx 1 flags 0 type 98(UNKNOWN INTR NOTIF/CMD) len 8 iwn_notif_intr: qid 4 idx 1 flags 0 type 176(IWN_CMD_PHY_CALIB) len 4 iwn_notif_intr: qid 4 idx 2 flags 0 type 176(IWN_CMD_PHY_CALIB) len 4 iwn_notif_intr: qid 4 idx 3 flags 0 type 176(IWN_CMD_PHY_CALIB) len 4 iwn_notif_intr: qid 4 idx 4 flags 0 type 176(IWN_CMD_PHY_CALIB) len 4 iwn_notif_intr: qid 4 idx 5 flags 0 type 176(IWN_CMD_PHY_CALIB) len 4 iwn_notif_intr: qid 4 idx 6 flags 0 type 176(IWN_CMD_PHY_CALIB) len 4 iwn_newstate: INIT -> SCAN iwn_scan: chan 1 flags 0x3 rf_gain 0x28 dsp_gain 0x6e active 0x24 passive 0x78 sending scan command nchan=1 iwn_notif_intr: qid 4 idx 7 flags 0 ty firmware error log: error type = "UNKNOWN" (0x00002776) program counter = 0x00009348 source line = 0x00000067 error data = 0x0408008000000002 branch link = 0x0000933600009336 interrupt link = 0x0000E1AE00000000 time = 29988 driver status: tx ring 0: qid=0 cur=0 queued=0 tx ring 1: qid=1 cur=0 queued=0 tx ring 2: qid=2 cur=0 queued=0 tx ring 3: qid=3 cur=0 queued=0 tx ring 4: qid=4 cur=9 queued=0 tx ring 5: qid=5 cur=0 queued=0 tx ring 6: qid=6 cur=0 queued=0 tx ring 7: qid=7 cur=0 queued=0 tx ring 8: qid=8 cur=0 queued=0 tx ring 9: qid=9 cur=0 queued=0 tx ring 10: qid=10 cur=0 queued=0 tx ring 11: qid=11 cur=0 queued=0 tx ring 12: qid=12 cur=0 queued=0 tx ring 13: qid=13 cur=0 queued=0 tx ring 14: qid=14 cur=0 queued=0 tx ring 15: qid=15 cur=0 queued=0 tx ring 16: qid=16 cur=0 queued=0 tx ring 17: qid=17 cur=0 queued=0 tx ring 18: qid=18 cur=0 queued=0 tx ring 19: qid=19 cur=0 queued=0 rx ring: cur=10 -- Eitan Adler From owner-freebsd-wireless@FreeBSD.ORG Thu Nov 7 20:29:21 2013 Return-Path: Delivered-To: freebsd-wireless@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id F3AB79CF; Thu, 7 Nov 2013 20:29:20 +0000 (UTC) (envelope-from gavin@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C933F2BC8; Thu, 7 Nov 2013 20:29:20 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id rA7KTKCC012395; Thu, 7 Nov 2013 20:29:20 GMT (envelope-from gavin@freefall.freebsd.org) Received: (from gavin@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id rA7KTKVW012394; Thu, 7 Nov 2013 20:29:20 GMT (envelope-from gavin) Date: Thu, 7 Nov 2013 20:29:20 GMT Message-Id: <201311072029.rA7KTKVW012394@freefall.freebsd.org> To: gavin@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-wireless@FreeBSD.org From: gavin@FreeBSD.org Subject: Re: kern/183759: [iwn] [wlan] Interface dies, OACTIVE set on wlan0 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: Thu, 07 Nov 2013 20:29:21 -0000 Synopsis: [iwn] [wlan] Interface dies, OACTIVE set on wlan0 Responsible-Changed-From-To: freebsd-bugs->freebsd-wireless Responsible-Changed-By: gavin Responsible-Changed-When: Thu Nov 7 20:29:05 UTC 2013 Responsible-Changed-Why: Over to -wireless http://www.freebsd.org/cgi/query-pr.cgi?pr=183759 From owner-freebsd-wireless@FreeBSD.ORG Thu Nov 7 21:17:59 2013 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id E0B14432 for ; Thu, 7 Nov 2013 21:17:59 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-qc0-x233.google.com (mail-qc0-x233.google.com [IPv6:2607:f8b0:400d:c01::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A19F02EC5 for ; Thu, 7 Nov 2013 21:17:59 +0000 (UTC) Received: by mail-qc0-f179.google.com with SMTP id k18so966424qcv.24 for ; Thu, 07 Nov 2013 13:17:58 -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:message-id:subject :from:to:cc:content-type; bh=Yh+JUAFMqPKaLd7C63900D//3BBq0LLwLUFRDX9wor8=; b=BQMmRKU2WarjkmOGmuI/AtYYrki949jXHC2kYTM7z3XxAxgNHWr+AhTuLgAzzx0wx6 mma9cM/2Uwc7w8sooDEdLG/taViDLRNlXnuBcAvWclhKwivKnhVh6wHDZYYZBmcFq4Kb 0pOPDoIULlKc4R9XiSK3XHzxGfHGk6cKCYhQw+cKmjFpsNoVTtRn7COAmybFMgHBZHd4 sSsvl8vRM2gFMn6DC6+GkpBULW3JS1Y6tP5vsjehySOwoTmX8VTBMGPt4cYct+IwScDW TkpPFrgm7HZLLSsCRwtAOhktKPhu7bqZ3rKYb4XdHrVpY9cHUFFfHSyx5ZHewrLkjxLS yOWw== MIME-Version: 1.0 X-Received: by 10.224.28.130 with SMTP id m2mr17762609qac.98.1383859078685; Thu, 07 Nov 2013 13:17:58 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.224.207.66 with HTTP; Thu, 7 Nov 2013 13:17:58 -0800 (PST) In-Reply-To: References: Date: Thu, 7 Nov 2013 13:17:58 -0800 X-Google-Sender-Auth: olabNHXJ6EItDAr6O0nft6sGV5o Message-ID: Subject: Re: Intro Centrino 2000 firmware error From: Adrian Chadd To: Eitan Adler 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: Thu, 07 Nov 2013 21:17:59 -0000 [snip] You didn't include: IWN_DEBUG_CMD = 0x00001000, /* cmd submission */ Nor: IWN_DEBUG_INTR = 0x00000100, /* ISR */ So, try 0x11ff --adrian From owner-freebsd-wireless@FreeBSD.ORG Thu Nov 7 22:22:17 2013 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id E05B5E99; Thu, 7 Nov 2013 22:22:17 +0000 (UTC) (envelope-from clutton@zoho.com) Received: from sender1.zohomail.com (sender1.zohomail.com [72.5.230.95]) by mx1.freebsd.org (Postfix) with ESMTP id BDC862286; Thu, 7 Nov 2013 22:22:17 +0000 (UTC) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=zapps768; d=zoho.com; h=subject:from:to:cc:in-reply-to:references:content-type:date:message-id:mime-version; b=KXl98ZqPxYsesq9eENVQxu9CLi9nTeQtuA5LadivjIxGwEmmVjek6E9ZDrHOpEbF9W8w2bZPTMLS RvFQ+NxEfJMxmUexLke4To6tUk8VQGwo1Wnu0Sef6Xrh+xR0TALj Received: from [192.168.1.100] (svann.corbina.com.ua [31.43.139.125]) by mx.zohomail.com with SMTPS id 1383862929208753.7064245195025; Thu, 7 Nov 2013 14:22:09 -0800 (PST) Subject: Re: service netif restart [iface] runs a wpa_supplicant twice From: clutton To: freebsd-wireless@freebsd.org, freebsd-arch@freebsd.org In-Reply-To: <201311061159.14824.jhb@freebsd.org> References: <1382572583.1862.39.camel@eva02.mbsd> <201311051717.30519.jhb@freebsd.org> <201311061159.14824.jhb@freebsd.org> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-BVm0CXnSENNJNebfmTOo" Date: Fri, 08 Nov 2013 00:22:03 +0200 Message-ID: <1383862923.70321.87.camel@eva02.mbsd> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port X-Zoho-Virus-Status: 1 X-ZohoMail: Ss SS_10 UW UB UW UB SGR3_1_06113_64 X-ZohoMail-Owner: <1383862923.70321.87.camel@eva02.mbsd>+zmo_0_ X-ZohoMail-Sender: 31.43.139.125 X-ZohoMailClient: External Cc: John Baldwin 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: Thu, 07 Nov 2013 22:22:18 -0000 --=-BVm0CXnSENNJNebfmTOo Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, 2013-11-06 at 11:59 -0500, John Baldwin wrote: > On Tuesday, November 05, 2013 5:17:30 pm John Baldwin wrote: > > On Tuesday, November 05, 2013 2:33:50 pm Bernhard Schmidt wrote: > > > On Tue, Nov 5, 2013 at 5:54 PM, John Baldwin wrote: > > > > On Sunday, November 03, 2013 12:56:08 pm Adrian Chadd wrote: > > > >> On 2 November 2013 12:13, clutton wrote: > > > >> > > > >> [snip] > > > >> > > > >> > What was happened? netif tries to setup wlan0 (clone, wpa, dhcp,= etc), > > > >> > when wlan0 interface occurs, devd runs another copy of netif. > > > >> > > > >> Well, it sounds like we need to pick an architecture _and_ fix the > > > >> behaviour here. > > > >> > > > >> Which is: > > > >> > > > >> > > > >> * I think wpa-supplicant should always run if it's required in /et= c/rc.conf; > > > >> * netif should check if devd is configured and if so, just leave t= he > > > >> configuration up to devd > > > >> * if it isn't running, then devd should be responsible for > > > >> dhclient/add-to-wpa-config > > > >> > > > >> What we first have to establish is whether add_interface and > > > >> remove_interface (or whatever they're called) are correctly workin= g, > > > >> for ethernet and wifi driver types. Then, we need to ensure they c= an > > > >> coexist (ie, one wpa_supplicant, but with both ethernet/wifi drive= rs > > > >> loaded and active on their relevant interfaces.) _then_ we can bre= ak > > > >> out the "stuff devd does" out of netif and have _either_ netif (x)= or > > > >> devd call this new script to setup/teardown the interface runtime > > > >> state. > > > >> > > > >> How's that sound? > > > > > > > > Note that devd just runs netif (via /etc/pccard_ether), so it's alr= eady > > > > just one script, and having netif bail if devd is running would mak= e > > > > netif not do anything in the common case. > > > > > > > > What normally happens during boot is that '/etc/rc.d/netif start' c= reates > > > > wlan0 and runs wpa_supplicant via 'childif_create' making a nested = call to > > > > ifn_start for wlan0. That is, childif_create autoruns /etc/rc.d/ne= tif > > > > explicitly after it creates the device. Probably that is what shou= ld be > > > > removed. That would let devd always start wpa_supplicant via > > > > /etc/pccard_ether. I've just tested this by doing a stop/start on = iwn0 > > > > (parent of wlan0, so wlan0 gets destroyed and re-created) and it st= arted > > > > wpa_supplicant correctly. > > > > > > > > Index: head/etc/network.subr > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > --- network.subr (revision 257705) > > > > +++ network.subr (working copy) > > > > @@ -1429,9 +1429,6 @@ childif_create() > > > > fi > > > > ${IFCONFIG_CMD} $i name $child && cfg=3D0 > > > > fi > > > > - if autoif $child; then > > > > - ifn_start $child > > > > - fi > > > > done > > > > > > > > # Create vlan interfaces > > > > > > > > I also tested vlans created via vlans_ and they should use the = same fix as > > > > well. Note that this model is more consistent with how cloned_inte= rfaces > > > > works where ifn_start is not explicitly run when each interface is = created. > > > > Instead, we rely on devd kicking off pccard_ether for those as well= . > > >=20 > > > That looks sane too me. > > >=20 > > > Just one question, I remember that devd is disabled during boot and > > > activated later through a sysctl (to ignore events entirely), is this > > > the case before or after netif is running? I guess it is activated > > > after netif, otherwise we would have seen this issue on booting and > > > not just during netif restart. > >=20 > > Hmm, devd starts after netif, but it just worked fine for me when I boo= ted up. > > I also misspoke about cloned_interfaces. We manually add the cloned_in= terface > > list to the list of interfaces /etc/rc.d/netif iterates over. What I a= m > > puzzled by is that this just worked for me during a test boot. Hmm, it= looks like > > devctl is no longer disabled during boot and then explicitly enabled by= devd. > > devctl is now always enabled during boot, but capped at 1000 entries to= avoid > > leaking memory. In fact, it looks like devd tries to recreate a few in= terfaces > > after netif finishes and is generally confused. I tried again with dev= d_flags > > set to "-n" to flush the initial set of events on boot. This removed t= he > > multiple calls to netif on boot on my laptop, but somehow wpa_supplican= t is > > still being started by devd (and I'm not sure how now). >=20 > I've hacked devd some more and can now see what is going on. -n doesn't = do what > I thought it does. It does not throw away pending events on startup, it = just > makes devd not fork until it has walked the initial set of events. The k= ernel > changed (a while ago) to queue the first 1000 events until devd starts up= . This > means that in practice devd gets arrival events for all devices in the sy= stem as > soon as it starts up and triggers duplicate invocations of netif after ne= tif > finishes. However, /etc/pccard_ether ignores attempts to start a device = that > is already up, so this should be a no-op on bootup (if my change is rever= ted) > as the interfaces should already be configured by the time devd starts. = I suspect > what happens in multiuser is that devd fires off pccard_ether and sees th= at the > interface isn't up before the original netif has a chance to invoke the n= ested > ifn_start. We could perhaps change it so we only invoke ifn_start if dev= d > isn't running. >=20 > One other thought: I restart my wireless interfaces by doing > 'sh /etc/rc.d/netif restart wlan0', not 'iwn0'. This doesn't teardown/re= create > the wlan0 device, so it doesn't suffer from the issue reported by the OP. >=20 > Here is a change I've tested that seems to do the right thing both at boo= t time > and doing a restart of either iwn0 or wlan0 at runtime. If devd is runni= ng > it leaves the task of starting an interface up to devd, otherwise (such a= s during > boot), it configures the new child interface synchronously. >=20 > Note that pgrep is in /bin. >=20 > Index: network.subr > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- network.subr (revision 257747) > +++ network.subr (working copy) > @@ -1406,10 +1406,14 @@ clone_down() > # > childif_create() > { > - local cfg child child_vlans child_wlans create_args debug_flags ifn i > + local cfg child child_vlans child_wlans create_args debug_flags devd \ > + ifn i > cfg=3D1 > ifn=3D$1 > =20 > + # Check if devd is running > + devd=3D$(pgrep devd) > + > # Create wireless interfaces > child_wlans=3D`get_if_var $ifn wlans_IF` > =20 > @@ -1429,6 +1433,9 @@ childif_create() > fi > ${IFCONFIG_CMD} $i name $child && cfg=3D0 > fi > + if [ -z "$devd" ] && autoif $child; then > + ifn_start $child > + fi > done > =20 > # Create vlan interfaces > @@ -1452,6 +1459,9 @@ childif_create() > ${IFCONFIG_CMD} $i name $child && cfg=3D0 > fi > fi > + if [ -z "$devd" ] && autoif $child; then > + ifn_start $child > + fi > done > =20 > return ${cfg} >=20 Yes, the "service netif restart wlan0" doesn't teardown/recreate the wlan0 device. Anyway, a "service netif restart" does. What about removing this functionality, instead? See the patch below. The pros: 1) creating the wlan interface by hand (by ifconfig) means that the further configuration is going to be in that way, by hand (by ifconfig, route, dhcpclient, etc). 2) already written down configuration (in rc.conf) means working with rc subsystem (netif) 3) I have no idea why somebody would expect from a command "ifconfig wlan0 create wlandev ath0" the same behaviour as from a "service netif start wlan0". 4) Let's remove the unexpected behaviour at all, it's prone error, it's not obviously at first glance, some kind of clever computer which knows better what do you need. I think that we have this functionality occasionally, no one had designed this on purpose, am I wrong? The cons: I have none. You told me. =CE=9E ~ =E2=86=92 diff -u /usr/src/etc/devd.conf /etc/devd.conf =20 --- /usr/src/etc/devd.conf 2013-09-29 17:24:16.759250174 +0300 +++ /etc/devd.conf 2013-11-07 23:43:17.833616197 +0200 @@ -38,7 +38,7 @@ # notify 0 { match "system" "IFNET"; - match "subsystem" "!usbus[0-9]+"; + match "subsystem" "!(usbus|wlan|vlan)[0-9]+"; match "type" "ATTACH"; action "/etc/pccard_ether $subsystem start"; }; --=-BVm0CXnSENNJNebfmTOo Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAABAgAGBQJSfBKLAAoJECNkWbjnbjuixB0QAKRQ5n8KY0kVxCdw+bxNMSeK cbNeAyunZ6dx90sPTmw1eIsdlt0smvXJBWFVhclEhaT/yYKhTziO1GH3OPvZlB3H wkYzy3HzpO8MoP0ue7TpzPuJaTIdG30fSD/XiUq5y3rhc8AioIKFFmS386gaJA8h 4eOxhQQdtHpbfFxSg7kzp2n9KaHlguZqCzZn6VOpPbTCRBjvuV+cIFIgUpPFrIXc +7q5qtzLsRGZ2OXwFPfd3r8gqNXxIvl66BqEPXGXEobtEpdH5wOVV+TUz32AEYr6 XzYvnIYwdF9Dl5/Y/qnCmACWBduKeRvGFH6PRaV2f0d6YoyhP1QXgOsbrwW3mQbp WxPZm8/TSTco3gjm1u7CBac/iB3hr/N+t7OUy5PuxVW6dWI3u6aGO7PY9ovzgDOG iTAe4fCPkunTccPn1MDOMyDRzRpqqgv8JiSGj3jlnJs9BzC+gqcAUbgnkQKNQE1k PtMGmRnYWBuXU0WN8Y5TnvPmif8VQgmKNhBO2y13tXAyjW195kZnna/KUIWNQw84 YB0koK6xQblNcxjipFQt5ldYlPTFv7CXCiOzLH+X+BXUrKxp+fmSNlTBSOKJ5XDf nTCIxVLFBxB7DADtsHH8VOi0s8yCr/3xNSGJ50bAjLSPG1KNVN3LC+/FCvjxG1Dx FR0M5eiP9h6uZncZdAra =Fusc -----END PGP SIGNATURE----- --=-BVm0CXnSENNJNebfmTOo-- From owner-freebsd-wireless@FreeBSD.ORG Thu Nov 7 22:40:40 2013 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id B67E1578 for ; Thu, 7 Nov 2013 22:40:40 +0000 (UTC) (envelope-from lists@eitanadler.com) Received: from mail-qa0-x230.google.com (mail-qa0-x230.google.com [IPv6:2607:f8b0:400d:c00::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 70AD023EF for ; Thu, 7 Nov 2013 22:40:40 +0000 (UTC) Received: by mail-qa0-f48.google.com with SMTP id w8so1046578qac.14 for ; Thu, 07 Nov 2013 14:40:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eitanadler.com; s=0xdeadbeef; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=a3YGEEnBY57oFQa9YB2JCcEp4Ywa/k9R4TG9EE5iOIA=; b=GZcAZucpFd0BJZS2n/YdQxtcGdEdB0zZhfHK3vFa0vNZTYjQt2SFJTlljrIP/Ps8Dw O7mg+yObeFTJ2cAMkwK4UH8FzuqaNIfIBUadhgU+NyRlArgQaVCQ6l1+BfBD0226JGbb 0CZOeGGYY7avwAxdLkF5qZ+waQ7y1AKXz3Zfk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=a3YGEEnBY57oFQa9YB2JCcEp4Ywa/k9R4TG9EE5iOIA=; b=cOKS4skNo+EbwW+m7ZUnyxX+yBRFjKjNavquYxYCu4zZjpqq1GB6zoR8JBvFeeyK8p 4fR9/joMzFFo9zxh0H1PvSV657umIzx8qxJSRa/Pe5cO1ZBScpL+Jhtn8E8Olds6WQBn 0p5VJ6A9xBozboPrrPpiHNloQeeV6Obl2g/MJdQKlQjJAEa30b+uewEvpLH942NWtgI6 MguY1mCQG4S+3fcGvKLE+BwsMyJWK7ZacOzuKVIvYooEqcW915KF6zCtFqAMukQOZDuP i1u4l9R8Jl+WT/qZsxOZj9I3D9YYqLoA8VtBYwJsze7dXiM5st+6b6Aa9WX/UKkXGJdG 0Ysg== X-Gm-Message-State: ALoCoQlLc9FzHHs4vGmOw/oZP/pURT+ytUMVpBCzARI6Xm187eJWFDQoPBsElrLAdQ/pqyMQsRvW X-Received: by 10.224.69.132 with SMTP id z4mr18490030qai.78.1383864039557; Thu, 07 Nov 2013 14:40:39 -0800 (PST) MIME-Version: 1.0 Received: by 10.96.63.101 with HTTP; Thu, 7 Nov 2013 14:40:09 -0800 (PST) In-Reply-To: References: From: Eitan Adler Date: Thu, 7 Nov 2013 17:40:09 -0500 Message-ID: Subject: Re: Intro Centrino 2000 firmware error To: Adrian Chadd Content-Type: text/plain; charset=UTF-8 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: Thu, 07 Nov 2013 22:40:40 -0000 On Thu, Nov 7, 2013 at 4:17 PM, Adrian Chadd wrote: > [snip] > > You didn't include: > > IWN_DEBUG_CMD = 0x00001000, /* cmd submission */ > > Nor: > > IWN_DEBUG_INTR = 0x00000100, /* ISR */ > > So, try 0x11ff ", build 0x0 using alternative 0 TLV type 16 reconized but not handled TLV type 17 reconized but not handled TLV type 6 reconized but not handled PAN Support found: 1 TLV type 8 reconized but not handled TLV type 9 reconized but not handled TLV type 10 reconized but not handled TLV type 11 reconized but not handled TLV type 12 reconized but not handled TLV type 13 reconized but not handled interrupt reg1=0x08000000 reg2=0x00000001 interrupt reg1=0x08000000 reg2=0x00000001 interrupt reg1=0x80000001 reg2=0x40010000 iwn_notif_intr: qid 0 idx 0 flags 0 type 1(UC_READY) len 36 microcode alive notification version=18.168 subtype=9 alive=1 iwn5000_ict_reset: enabling ICT iwn5000_send_wimax_coex: Configuring WiMAX coexistence iwn_cmd: IWN5000_CMD_WIMAX_COEX (0x5a) flags 0 qid 4 idx 0 interrupt reg1=0x80000000 reg2=0x00000000 iwn_notif_intr: qid 4 idx 0 flags 0 type 90(IWN5000_CMD_WIMAX_COEX) len 4 iwn_cmd: IWN_CMD_PHY_CALIB (0xb0) flags 0 qid 4 idx 1 interrupt reg1=0x80000000 reg2=0x00000000 iwn_notif_intr: qid 0 idx 1 flags 0 type 98(UNKNOWN INTR NOTIF/CMD) len 8 iwn_notif_intr: qid 4 idx 1 flags 0 type 176(IWN_CMD_PHY_CALIB) len 4 iwn_cmd: IWN5000_CMD_CALIB_CONFIG (0x65) flags 0 qid 4 idx 2 interrupt reg1=0x80000000 reg2=0x00000000 iwn_notif_intr: qid 4 idx 2 flags 0 type 101(IWN5000_CMD_CALIB_CONFIG) len 8 interrupt reg1=0x80000000 reg2=0x00000000 iwn_notif_intr: qid 0 idx 2 flags 0 type 102(IWN5000_CMD_CALIB_RESULT) len 12 interrupt reg1=0x80000000 reg2=0x00000000 iwn_notif_intr: qid 0 idx 3 flags 0 type 102(IWN5000_CMD_CALIB_RESULT) len 520 interrupt reg1=0x10000000 reg2=0x00000000 interrupt reg1=0x80000000 reg2=0x00000000 iwn_notif_intr: qid 0 idx 4 flags 0 type 102(IWN5000_CMD_CALIB_RESULT) len 1352 interrupt reg1=0x10000000 reg2=0x00000000 interrupt reg1=0x80000000 reg2=0x00000000 iwn_notif_intr: qid 0 idx 5 flags 0 type 102(IWN5000_CMD_CALIB_RESULT) len 92 interrupt reg1=0x80000000 reg2=0x00000000 iwn_notif_intr: qid 0 idx 6 flags 0 type 103(IWN5000_CMD_CALIB_COMPLETE) len 8 interrupt reg1=0x08000000 reg2=0x00000001 interrupt reg1=0x08000000 reg2=0x00000001 interrupt reg1=0x80000001 reg2=0x40010000 iwn_notif_intr: qid 0 idx 0 flags 0 type 1(UC_READY) len 36 microcode alive notification version=18.168 subtype=1 alive=1 iwn5000_ict_reset: enabling ICT iwn5000_send_wimax_coex: Configuring WiMAX coexistence iwn_cmd: IWN5000_CMD_WIMAX_COEX (0x5a) flags 0 qid 4 idx 0 interrupt reg1=0x80000000 reg2=0x00000000 iwn_notif_intr: qid 4 idx 0 flags 0 type 90(IWN5000_CMD_WIMAX_COEX) len 4 iwn_cmd: IWN_CMD_PHY_CALIB (0xb0) flags 0 qid 4 idx 1 interrupt reg1=0x80000000 reg2=0x00000000 iwn_notif_intr: qid 0 idx 1 flags 0 type 98(UNKNOWN INTR NOTIF/CMD) len 8 iwn_notif_intr: qid 4 idx 1 flags 0 type 176(IWN_CMD_PHY_CALIB) len 4 iwn_cmd: IWN_CMD_PHY_CALIB (0xb0) flags 0 qid 4 idx 2 interrupt reg1=0x80000000 reg2=0x00000000 iwn_notif_intr: qid 4 idx 2 flags 0 type 101(IWN5000_CMD_CALIB_CONFIG) len 8 interrupt reg1=0x80000000 reg2=0x00000000 iwn_notif_intr: qid 0 idx 2 flags 0 type 102(IWN5000_CMD_CALIB_RESULT) len 12 interrupt reg1=0x80000000 reg2=0x00000000 iwn_notif_intr: qid 0 idx 3 flags 0 type 102(IWN5000_CMD_CALIB_RESULT) len 520 interrupt reg1=0x10000000 reg2=0x00000000 interrupt reg1=0x80000000 reg2=0x00000000 iwn_notif_intr: qid 0 idx 4 flags 0 type 102(IWN5000_CMD_CALIB_RESULT) len 1352 interrupt reg1=0x10000000 reg2=0x00000000 interrupt reg1=0x80000000 reg2=0x00000000 iwn_notif_intr: qid 0 idx 5 flags 0 type 102(IWN5000_CMD_CALIB_RESULT) len 92 interrupt reg1=0x80000000 reg2=0x00000000 iwn_notif_intr: qid 0 idx 6 flags 0 type 103(IWN5000_CMD_CALIB_COMPLETE) len 8 interrupt reg1=0x08000000 reg2=0x00000001 interrupt reg1=0x08000000 reg2=0x00000001 interrupt reg1=0x80000001 reg2=0x40010000 iwn_notif_intr: qid 0 idx 0 flags 0 type 1(UC_READY) len 36 microcode alive notification version=18.168 subtype=1 alive=1 iwn5000_ict_reset: enabling ICT iwn5000_send_wimax_coex: Configuring WiMAX coexistence iwn_cmd: IWN5000_CMD_WIMAX_COEX (0x5a) flags 0 qid 4 idx 0 interrupt reg1=0x80000000 reg2=0x00000000 iwn_notif_intr: qid 4 idx 0 flags 0 type 90(IWN5000_CMD_WIMAX_COEX) len 4 iwn_cmd: IWN_CMD_PHY_CALIB (0xb0) flags 0 qid 4 idx 1 interrupt reg1=0x80000000 reg2=0x00000000 iwn_notif_intr: qid 0 idx 1 flags 0 type 98(UNKNOWN INTR NOTIF/CMD) len 8 iwn_notif_intr: qid 4 idx 1 flags 0 type 176(IWN_CMD_PHY_CALIB) len 4 iwn_cmd: IWN_CMD_PHY_CALIB (0xb0) flags 0 qid 4 idx 2 interrupt reg1=0x80000000 reg2=0x00000000 iwn_notif_intr: qid 4 idx 2 flags 0 type 176(IWN_CMD_PHY_CALIB) len 4 iwn_cmd: IWN_CMD_PHY_CALIB (0xb0) flags 0 qid 4 idx 3 interrupt reg1=0x80000000 reg2=0x00000000 iwn_notif_intr: qid 4 idx 3 flags 0 type 176(IWN_CMD_PHY_CALIB) len 4 iwn_cmd: IWN_CMD_PHY_CALIB (0xb0) flags 0 qid 4 idx 4 interrupt reg1=0x80000000 reg2=0x00000000 iwn_notif_intr: qid 4 idx 4 flags 0 type 176(IWN_CMD_PHY_CALIB) len 4 iwn_cmd: IWN_CMD_PHY_CALIB (0xb0) flags 0 qid 4 idx 5 interrupt reg1=0x80000000 reg2=0x00000000 iwn_notif_intr: qid 4 idx 5 flags 0 type 176(IWN_CMD_PHY_CALIB) len 4 iwn_cmd: IWN_CMD_PHY_CALIB (0xb0) flags 0 qid 4 idx 6 interrupt reg1=0x80000000 reg2=0x00000000 iwn_notif_intr: qid 4 idx 6 flags 0 type 176(IWN_CMD_PHY_CALIB) len 4 iwn_newstate: INIT -> SCAN iwn_cmd: IWN_CMD_SET_LED (0x48) flags 0 qid 4 idx 7 iwn_scan: chan 1 flags 0x3 rf_gain 0x28 dsp_gain 0x6e active 0x24 passive 0x78 sending scan command nchan=1 iwn_cmd: IWN_CMD_SCAN (0x80) flags 0 qid 4 idx 8 interrupt reg1=0x80000000 reg2=0x00000000 iwn_notif_intr: qid 4 idx 7 flags 0 type 72(IWN_CMD_SET_LED) len 4 interrupt reg1=0x02000000 reg2=0x00000000 iwn0: iwn_intr: fatal firmware error firmware error log: error type = "UNKNOWN" (0x00002776) program counter = 0x00009348 source line = 0x00000067 error data = 0x0408008000000002 branch link = 0x0000933600009336 interrupt link = 0x0000E1AE00000000 time = 30190 driver status: tx ring 0: qid=0 cur=0 queued=0 tx ring 1: qid=1 cur=0 queued=0 tx ring 2: qid=2 cur=0 queued=0 tx ring 3: qid=3 cur=0 queued=0 tx ring 4: qid=4 cur=9 queued=0 tx ring 5: qid=5 cur=0 queued=0 tx ring 6: qid=6 cur=0 queued=0 tx ring 7: qid=7 cur=0 queued=0 tx ring 8: qid=8 cur=0 queued=0 tx ring 9: qid=9 cur=0 queued=0 tx ring 10: qid=10 cur=0 queued=0 tx ring 11: qid=11 cur=0 queued=0 tx ring 12: qid=12 cur=0 queued=0 tx ring 13: qid=13 cur=0 queued=0 tx ring 14: qid=14 cur=0 queued=0 tx ring 15: qid=15 cur=0 queued=0 tx ring 16: qid=16 cur=0 queued=0 tx ring 17: qid=17 cur=0 queued=0 tx ring 18: qid=18 cur=0 queued=0 tx ring 19: qid=19 cur=0 queued=0 rx ring: cur=10 -- Eitan Adler From owner-freebsd-wireless@FreeBSD.ORG Fri Nov 8 05:30:59 2013 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id E19212CE for ; Fri, 8 Nov 2013 05:30:59 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-qc0-x233.google.com (mail-qc0-x233.google.com [IPv6:2607:f8b0:400d:c01::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A7C602E53 for ; Fri, 8 Nov 2013 05:30:59 +0000 (UTC) Received: by mail-qc0-f179.google.com with SMTP id k18so1338909qcv.38 for ; Thu, 07 Nov 2013 21:30:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=ofaydqW5M+mNzuJDKvkTfZuwFGzPxajaF42+BtAW/ko=; b=QE+HXVx8FUfzI1haP2vDMYnw+EgReWdXZhF/XCyRQ1tKVNrQohsvB5mUPG5MOIiI7P GhKGKCkjNrCVsdMBQrWotqS+8VB5OmvAJbDDvThhshOMWxqeiMNdIm2qVp9eT3JCZRBX n1G17SjdGjEMYBW6JwxpdjKLsNUH16zwHgh6Rr9Bqtf150KvBBPsjMZLBbgP5+jFCooB FgUEJwX4SW2b56Q5u21OBW8LQ2jHQfDhr0r+D7bDWDNsSprQ6gkyRFP50fbzI9vXA2Pw s4Eeg5rF8nPpDblxWoNsh3Hm2+UgEJnZnVsKKP2e11VuHWDBk8U8lVEO7bMHrkkcQAl+ AC9g== MIME-Version: 1.0 X-Received: by 10.224.36.201 with SMTP id u9mr20655191qad.76.1383888658860; Thu, 07 Nov 2013 21:30:58 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.224.207.66 with HTTP; Thu, 7 Nov 2013 21:30:58 -0800 (PST) Date: Thu, 7 Nov 2013 21:30:58 -0800 X-Google-Sender-Auth: umU0HRXvxgVvIbulTU9bYuapM2Q Message-ID: Subject: [iwn] round two - 5100 works, but 2xxx doesn't 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: Fri, 08 Nov 2013 05:30:59 -0000 Hiya, Here's the latest patch: http://people.freebsd.org/~adrian/iwn/20131107-iwn-update-works-full-5100-9.diff This includes some change to the TX ring and command queue setup. Unfortunately the 2xxx series NICs don't work. The firmware panics once the first scan message is sent. So, I think something is not being setup correctly. Nov 7 19:50:11 lucy-11i386 kernel: FW: "2030 fw v18.168.6.1 build 0 Nov 7 19:50:11 lucy-11i386 kernel: ", build 0x0 Nov 7 19:50:11 lucy-11i386 kernel: using alternative 0 Nov 7 19:50:11 lucy-11i386 kernel: TLV type 16 reconized but not handled Nov 7 19:50:11 lucy-11i386 kernel: TLV type 17 reconized but not handled Nov 7 19:50:11 lucy-11i386 kernel: TLV type 6 reconized but not handled Nov 7 19:50:11 lucy-11i386 kernel: PAN Support found: 1 Nov 7 19:50:11 lucy-11i386 kernel: TLV type 8 reconized but not handled Nov 7 19:50:11 lucy-11i386 kernel: TLV type 9 reconized but not handled Nov 7 19:50:11 lucy-11i386 kernel: TLV type 10 reconized but not handled Nov 7 19:50:11 lucy-11i386 kernel: TLV type 11 reconized but not handled Nov 7 19:50:11 lucy-11i386 kernel: TLV type 12 reconized but not handled Nov 7 19:50:11 lucy-11i386 kernel: TLV type 13 reconized but not handled Nov 7 19:50:11 lucy-11i386 kernel: iwn_notif_intr: qid 0 idx 0 flags 0 type 1(UC_READY) len 36 Nov 7 19:50:11 lucy-11i386 kernel: microcode alive notification version=18.168 subtype=9 alive=1 Nov 7 19:50:11 lucy-11i386 kernel: iwn5000_ict_reset: enabling ICT Nov 7 19:50:11 lucy-11i386 kernel: iwn5000_send_wimax_coex: Configuring WiMAX coexistence Nov 7 19:50:11 lucy-11i386 kernel: iwn_cmd: IWN5000_CMD_WIMAX_COEX (0x5a) flags 0 qid 9 idx 0 Nov 7 19:50:11 lucy-11i386 kernel: iwn_notif_intr: qid 9 idx 0 flags 0 type 90(IWN5000_CMD_WIMAX_COEX) len 4 Nov 7 19:50:11 lucy-11i386 kernel: sending crystal calibration 0, 0 Nov 7 19:50:11 lucy-11i386 kernel: iwn_cmd: IWN_CMD_PHY_CALIB (0xb0) flags 0 qid 9 idx 1 Nov 7 19:50:11 lucy-11i386 kernel: iwn_notif_intr: qid 0 idx 1 flags 0 type 98(UNKNOWN INTR NOTIF/CMD) len 8 Nov 7 19:50:11 lucy-11i386 kernel: iwn_notif_intr: qid 9 idx 1 flags 0 type 176(IWN_CMD_PHY_CALIB) len 4 Nov 7 19:50:11 lucy-11i386 kernel: iwn5000_query_calibration: sending calibration query Nov 7 19:50:11 lucy-11i386 kernel: iwn_cmd: IWN5000_CMD_CALIB_CONFIG (0x65) flags 0 qid 9 idx 2 Nov 7 19:50:11 lucy-11i386 kernel: iwn_notif_intr: qid 9 idx 2 flags 0 type 101(IWN5000_CMD_CALIB_CONFIG) len 8 Nov 7 19:50:11 lucy-11i386 kernel: iwn_notif_intr: qid 0 idx 2 flags 0 type 102(IWN5000_CMD_CALIB_RESULT) len 12 Nov 7 19:50:11 lucy-11i386 kernel: saving calibration result idx=4, code=16 len=8 Nov 7 19:50:11 lucy-11i386 kernel: iwn_notif_intr: qid 0 idx 3 flags 0 type 102(IWN5000_CMD_CALIB_RESULT) len 520 Nov 7 19:50:11 lucy-11i386 kernel: saving calibration result idx=0, code=8 len=516 Nov 7 19:50:11 lucy-11i386 kernel: iwn_notif_intr: qid 0 idx 4 flags 0 type 102(IWN5000_CMD_CALIB_RESULT) len 1352 Nov 7 19:50:11 lucy-11i386 kernel: saving calibration result idx=1, code=9 len=1348 Nov 7 19:50:12 lucy-11i386 kernel: iwn_notif_intr: qid 0 idx 5 flags 0 type 102(IWN5000_CMD_CALIB_RESULT) len 92 Nov 7 19:50:12 lucy-11i386 kernel: saving calibration result idx=2, code=11 len=88 Nov 7 19:50:12 lucy-11i386 kernel: iwn_notif_intr: qid 0 idx 6 flags 0 type 103(IWN5000_CMD_CALIB_COMPLETE) len 8 Nov 7 19:50:12 lucy-11i386 kernel: iwn_notif_intr: qid 0 idx 0 flags 0 type 1(UC_READY) len 36 Nov 7 19:50:12 lucy-11i386 kernel: microcode alive notification version=18.168 subtype=1 alive=1 Nov 7 19:50:12 lucy-11i386 kernel: iwn5000_ict_reset: enabling ICT Nov 7 19:50:12 lucy-11i386 kernel: iwn5000_send_wimax_coex: Configuring WiMAX coexistence Nov 7 19:50:12 lucy-11i386 kernel: iwn_cmd: IWN5000_CMD_WIMAX_COEX (0x5a) flags 0 qid 9 idx 0 Nov 7 19:50:12 lucy-11i386 kernel: iwn_notif_intr: qid 9 idx 0 flags 0 type 90(IWN5000_CMD_WIMAX_COEX) len 4 Nov 7 19:50:12 lucy-11i386 kernel: sending crystal calibration 0, 0 Nov 7 19:50:12 lucy-11i386 kernel: iwn_cmd: IWN_CMD_PHY_CALIB (0xb0) flags 0 qid 9 idx 1 Nov 7 19:50:12 lucy-11i386 kernel: iwn_notif_intr: qid 0 idx 1 flags 0 type 98(UNKNOWN INTR NOTIF/CMD) len 8 Nov 7 19:50:12 lucy-11i386 kernel: iwn_notif_intr: qid 9 idx 1 flags 0 type 176(IWN_CMD_PHY_CALIB) len 4 Nov 7 19:50:12 lucy-11i386 kernel: send calibration result idx=0 len=516 Nov 7 19:50:12 lucy-11i386 kernel: iwn_cmd: IWN_CMD_PHY_CALIB (0xb0) flags 0 qid 9 idx 2 Nov 7 19:50:12 lucy-11i386 kernel: iwn_notif_intr: qid 9 idx 2 flags 0 type 176(IWN_CMD_PHY_CALIB) len 4 Nov 7 19:50:12 lucy-11i386 kernel: send calibration result idx=1 len=1348 Nov 7 19:50:12 lucy-11i386 kernel: iwn_cmd: IWN_CMD_PHY_CALIB (0xb0) flags 0 qid 9 idx 3 Nov 7 19:50:12 lucy-11i386 kernel: iwn_notif_intr: qid 9 idx 3 flags 0 type 176(IWN_CMD_PHY_CALIB) len 4 Nov 7 19:50:12 lucy-11i386 kernel: send calibration result idx=2 len=88 Nov 7 19:50:12 lucy-11i386 kernel: iwn_cmd: IWN_CMD_PHY_CALIB (0xb0) flags 0 qid 9 idx 4 Nov 7 19:50:12 lucy-11i386 kernel: iwn_notif_intr: qid 9 idx 4 flags 0 type 176(IWN_CMD_PHY_CALIB) len 4 Nov 7 19:50:12 lucy-11i386 kernel: No need of calib 3 Nov 7 19:50:12 lucy-11i386 kernel: send calibration result idx=4 len=8 Nov 7 19:50:12 lucy-11i386 kernel: iwn_cmd: IWN_CMD_PHY_CALIB (0xb0) flags 0 qid 9 idx 5 Nov 7 19:50:12 lucy-11i386 kernel: iwn_notif_intr: qid 9 idx 5 flags 0 type 176(IWN_CMD_PHY_CALIB) len 4 Nov 7 19:50:12 lucy-11i386 kernel: No need of calib 5 Nov 7 19:50:12 lucy-11i386 kernel: No need of calib 6 Nov 7 19:50:12 lucy-11i386 kernel: Need calib idx : 7 but no available data Nov 7 19:50:12 lucy-11i386 kernel: setting radio sensor low offset to 2701, high offset to 2703, voltage to 3353 Nov 7 19:50:12 lucy-11i386 kernel: iwn_cmd: IWN_CMD_PHY_CALIB (0xb0) flags 0 qid 9 idx 6 Nov 7 19:50:12 lucy-11i386 kernel: iwn_notif_intr: qid 9 idx 6 flags 0 type 176(IWN_CMD_PHY_CALIB) len 4 Nov 7 19:50:12 lucy-11i386 kernel: iwn_newstate: INIT -> SCAN Nov 7 19:50:12 lucy-11i386 kernel: iwn_cmd: IWN_CMD_SET_LED (0x48) flags 0 qid 9 idx 7 Nov 7 19:50:12 lucy-11i386 kernel: iwn_scan: chan 1 flags 0x1 rf_gain 0x28 dsp_gain 0x6e active 0x24 passive 0x78 Nov 7 19:50:12 lucy-11i386 kernel: sending scan command nchan=1 Nov 7 19:50:12 lucy-11i386 kernel: iwn_cmd: IWN_CMD_SCAN (0x80) flags 0 qid 9 idx 8 Nov 7 19:50:12 lucy-11i386 kernel: iwn1: iwn_intr: fatal firmware error Nov 7 19:50:12 lucy-11i386 kernel: firmware error log: Nov 7 19:50:12 lucy-11i386 kernel: error type = "UNKNOWN" (0x00002776) Nov 7 19:50:12 lucy-11i386 kernel: program counter = 0x00009E20 Nov 7 19:50:12 lucy-11i386 kernel: source line = 0x00000067 Nov 7 19:50:12 lucy-11i386 kernel: error data = 0x0908008000000002 Nov 7 19:50:12 lucy-11i386 kernel: branch link = 0x00009E0E00009E0E Nov 7 19:50:12 lucy-11i386 kernel: interrupt link = 0x0000EC7A00000000 Nov 7 19:50:12 lucy-11i386 kernel: time = 35209 Nov 7 19:50:12 lucy-11i386 kernel: driver status: Nov 7 19:50:12 lucy-11i386 kernel: tx ring 0: qid=0 cur=0 queued=0 Nov 7 19:50:12 lucy-11i386 kernel: tx ring 1: qid=1 cur=0 queued=0 Nov 7 19:50:12 lucy-11i386 kernel: tx ring 2: qid=2 cur=0 queued=0 Nov 7 19:50:12 lucy-11i386 kernel: tx ring 3: qid=3 cur=0 queued=0 Nov 7 19:50:12 lucy-11i386 kernel: tx ring 4: qid=4 cur=0 queued=0 Nov 7 19:50:12 lucy-11i386 kernel: tx ring 5: qid=5 cur=0 queued=0 Nov 7 19:50:12 lucy-11i386 kernel: tx ring 6: qid=6 cur=0 queued=0 Nov 7 19:50:12 lucy-11i386 kernel: tx ring 7: qid=7 cur=0 queued=0 Nov 7 19:50:12 lucy-11i386 kernel: tx ring 8: qid=8 cur=0 queued=0 Nov 7 19:50:12 lucy-11i386 kernel: tx ring 9: qid=9 cur=9 queued=0 Nov 7 19:50:12 lucy-11i386 kernel: tx ring 10: qid=10 cur=0 queued=0 Nov 7 19:50:12 lucy-11i386 kernel: tx ring 11: qid=11 cur=0 queued=0 Nov 7 19:50:12 lucy-11i386 kernel: tx ring 12: qid=12 cur=0 queued=0 Nov 7 19:50:12 lucy-11i386 kernel: tx ring 13: qid=13 cur=0 queued=0 Nov 7 19:50:12 lucy-11i386 kernel: tx ring 14: qid=14 cur=0 queued=0 Nov 7 19:50:12 lucy-11i386 kernel: tx ring 15: qid=15 cur=0 queued=0 Nov 7 19:50:12 lucy-11i386 kernel: tx ring 16: qid=16 cur=0 queued=0 Nov 7 19:50:12 lucy-11i386 kernel: tx ring 17: qid=17 cur=0 queued=0 Nov 7 19:50:12 lucy-11i386 kernel: tx ring 18: qid=18 cur=0 queued=0 Nov 7 19:50:12 lucy-11i386 kernel: tx ring 19: qid=19 cur=0 queued=0 Nov 7 19:50:12 lucy-11i386 kernel: rx ring: cur=9 From owner-freebsd-wireless@FreeBSD.ORG Fri Nov 8 08:03:05 2013 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id DCCCC210 for ; Fri, 8 Nov 2013 08:03:05 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-qc0-x232.google.com (mail-qc0-x232.google.com [IPv6:2607:f8b0:400d:c01::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A152B2708 for ; Fri, 8 Nov 2013 08:03:05 +0000 (UTC) Received: by mail-qc0-f178.google.com with SMTP id x19so1432878qcw.37 for ; Fri, 08 Nov 2013 00:03:04 -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:message-id:subject :from:to:content-type; bh=qYgK1rtivvDGN3T0Zjw3mp4f/S74eZ56ayti69YMokU=; b=lTcXSjl+0eLWP8OO4qlo4FEv15HO+rL7ElA/zy5UNEk9pdHqUmXRRsGg16F2wMXldp u+SwYWtlXvVpDRCyCg7yDxfFnDX0a802widrrZmREL/C7ntG9UEK5QI4L7/Lm4Ay5y+v FiEhPgCibVtiQ0tmHtBIEwMhVeFKBgV/rcfVBF+x37DHPOyI6/GxLXq6SESnlSH887m4 uUN98q45zE9zSFJEPTh8RK0wyYLQPj8e3Xvx3+Qz/n7jlC8RKziYJgEgqKgFl+Cv2L+7 N4Elkz+bD1TxB5GuXNlRB6baDi5Ug+VyA4Z4kmRFZSeky1sxU0nzHRFo1S3up+wwV1nd H0nQ== MIME-Version: 1.0 X-Received: by 10.224.36.201 with SMTP id u9mr21416784qad.76.1383897784789; Fri, 08 Nov 2013 00:03:04 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.224.207.66 with HTTP; Fri, 8 Nov 2013 00:03:04 -0800 (PST) In-Reply-To: References: Date: Fri, 8 Nov 2013 00:03:04 -0800 X-Google-Sender-Auth: TvTMd2zYmtyfSXQIn7122jjd7WA Message-ID: Subject: Re: [iwn] round two - 5100 works, but 2xxx doesn't 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: Fri, 08 Nov 2013 08:03:05 -0000 .. I compared it to cedric's driver (after I made it compile on -HEAD). Lo and behold, I realised a bunch of stuff in iwn_config() wasn't being run. Damned missing braces. http://people.freebsd.org/~adrian/iwn/20131107-iwn-update-works-full-5100-2230-10.diff This works on the 5100 and the Centrino 2230 NICs. I haven't yet tested the rest. -adrian From owner-freebsd-wireless@FreeBSD.ORG Fri Nov 8 19:37:36 2013 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id AF196435 for ; Fri, 8 Nov 2013 19:37:36 +0000 (UTC) (envelope-from lists@eitanadler.com) Received: from mail-qa0-x236.google.com (mail-qa0-x236.google.com [IPv6:2607:f8b0:400d:c00::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 6FFFB2CD7 for ; Fri, 8 Nov 2013 19:37:36 +0000 (UTC) Received: by mail-qa0-f54.google.com with SMTP id j7so2066168qaq.6 for ; Fri, 08 Nov 2013 11:37:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eitanadler.com; s=0xdeadbeef; h=mime-version:from:date:message-id:subject:to:cc:content-type; bh=+bhdpl8oeimCPn/E/BCG2Hs6g8qCG6ASFN43eaXkRuE=; b=ISPsmUb0m6e1eL1SphUC3w2MXf4qSfAEiV3uTmWBAsJH5jmjB9vwqk2GPAiOofkm01 M8DzXdiYIcT8YYGYoeJvOc3kYNQGagTxCVc86bMJKBcTowkzK+aEuB7BFtNPo2YzyTUJ yaQr2T3ZDwTkwjpYUh0OtjT2JAU460DOwXLZg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc :content-type; bh=+bhdpl8oeimCPn/E/BCG2Hs6g8qCG6ASFN43eaXkRuE=; b=dAhoL4OlvK1//eaUBWGTngWI5aoXxelDkris62RsmPtgZHSiRzg826/sPAp4cPX/6V 1gIyNG9z19xbHkfXvlG+zHW5WQMNHerlwfazlcv+GT5UV8PTu+mUAoBGOtAPk6qXQPBH XG/Kpem89cQSdwg9M7dfpmMNL8X+h9Kj7Ajm10LJSxzP6BS5m82UOWA6BaNuM5vtIbFx j5GEhRSgDsldldIei4XT3O7KuJMAB2RvjoFp09c4PVHkMsbcYJ4qw2NbMsOEZR1IHeOj H0JtHnBuYBPZP1zgiHtNUNZhcFbqoV7yvOfS8xll6JlB2vSJU8EAUzQDCStxp1U/goP1 NbzA== X-Gm-Message-State: ALoCoQmUNaXW60btoNHWUfRdkpGlinAbmCsr+oxjb6uyinNEO+S9Uuiq/m4IQM1y6wz2OPRnRafC X-Received: by 10.49.116.19 with SMTP id js19mr25536558qeb.34.1383939455148; Fri, 08 Nov 2013 11:37:35 -0800 (PST) MIME-Version: 1.0 Received: by 10.96.63.101 with HTTP; Fri, 8 Nov 2013 11:37:05 -0800 (PST) From: Eitan Adler Date: Fri, 8 Nov 2013 14:37:05 -0500 Message-ID: Subject: 2xxx works To: Adrian Chadd Content-Type: text/plain; charset=UTF-8 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: Fri, 08 Nov 2013 19:37:36 -0000 On Fri, Nov 8, 2013 at 3:03 AM, Adrian Chadd wrote: > This works on the 5100 and the Centrino 2230 NICs. I haven't yet > tested the rest. It lives! iwn0@pci0:2:0:0: class=0x028000 card=0x42228086 chip=0x08918086 rev=0xc4 hdr=0x00 vendor = 'Intel Corporation' device = 'Centrino Wireless-N 2200' class = network Thanks Cedric and Adrian -- Eitan Adler From owner-freebsd-wireless@FreeBSD.ORG Fri Nov 8 19:51:20 2013 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 4F8DC510 for ; Fri, 8 Nov 2013 19:51:20 +0000 (UTC) (envelope-from lists@eitanadler.com) Received: from mail-qc0-x234.google.com (mail-qc0-x234.google.com [IPv6:2607:f8b0:400d:c01::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 0F2162D7A for ; Fri, 8 Nov 2013 19:51:19 +0000 (UTC) Received: by mail-qc0-f180.google.com with SMTP id e9so2100173qcy.25 for ; Fri, 08 Nov 2013 11:51:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eitanadler.com; s=0xdeadbeef; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=/h1khCMivGbvgULWbRoC1DACzfu9QW1sB3arp0BhRQ8=; b=YW75kaRZfszGJtlNV8g8rN7MU7W1ZtC5h1zyDCu+rgZgz5yD3UbznqD4pAaK8s7f4X NdNlLc96gDUs9eTcnF6rjpaYaF9vLqLppiAUpen+1l6/fZVLMzHKMHt6XMQ3dqUXcT5J 0ydmamM60xJua0b7cz6bgtGYDV1ROo3mK+7eY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=/h1khCMivGbvgULWbRoC1DACzfu9QW1sB3arp0BhRQ8=; b=HJfifRMg7D7aswkbTVfG1j6ZXO1PtzE8Bwrbb0ZfUORKSR90WIDDYzfdB/PIH754E4 m57eYwwpv/asSAeuDUkkvD9kr9/8zJ/nDVTsHYszsprNkec1DoBwUd8rGzujIQTfggJC ox7ErjXPtHKGMUBcOwsuoPvny+Ts2/54D7eD517raEu5n+NLotbrNwftYVvX5/UCd2xY tjqID8Q+yWnCpnJOjTmXWo4uj5UwIOfEq/VCzdohMjNsUm83cCPLNetZA0LlPr/rE9Ou YLcH0f8Q6EQBXoVS9lFWHRzvk0+05+fTeyecMnvEI+WozAl5Fu/QDm2L/PjY57MaBimu ZD9w== X-Gm-Message-State: ALoCoQkroGKEvXslZlkM8vJ/O/+DLKKspBfKcBu7tNV6S4KTpA4AU9NwCGShWQdAOZJT2Jdy1xLx X-Received: by 10.224.131.67 with SMTP id w3mr27372824qas.62.1383940279171; Fri, 08 Nov 2013 11:51:19 -0800 (PST) MIME-Version: 1.0 Received: by 10.96.63.101 with HTTP; Fri, 8 Nov 2013 11:50:48 -0800 (PST) In-Reply-To: References: From: Eitan Adler Date: Fri, 8 Nov 2013 14:50:48 -0500 Message-ID: Subject: Re: 2xxx works To: Adrian Chadd Content-Type: text/plain; charset=UTF-8 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: Fri, 08 Nov 2013 19:51:20 -0000 On Fri, Nov 8, 2013 at 2:37 PM, Eitan Adler wrote: > On Fri, Nov 8, 2013 at 3:03 AM, Adrian Chadd wrote: > >> This works on the 5100 and the Centrino 2230 NICs. I haven't yet >> tested the rest. > > It lives! I spoke a bit fast: it works for a while but eventually wifi just dies. wpa_supplicant was still on but ping to any address including my gateway failed. -- Eitan Adler From owner-freebsd-wireless@FreeBSD.ORG Sat Nov 9 05:39:21 2013 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 3DE79AB8 for ; Sat, 9 Nov 2013 05:39:21 +0000 (UTC) (envelope-from lists@eitanadler.com) Received: from mail-qc0-x232.google.com (mail-qc0-x232.google.com [IPv6:2607:f8b0:400d:c01::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id F3E1D2892 for ; Sat, 9 Nov 2013 05:39:20 +0000 (UTC) Received: by mail-qc0-f178.google.com with SMTP id x19so2548725qcw.37 for ; Fri, 08 Nov 2013 21:39:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eitanadler.com; s=0xdeadbeef; h=mime-version:from:date:message-id:subject:to:content-type; bh=Ehjh1l5dfg2kof0cUEWKFdNhe612eLMqu755J2+3jAI=; b=dBOmF5J28lJrTgPQeBT0WDehA1rEFkKt6MvogvfMz0xnIYGL/a0blzgvcpQiH8pahB l0x9U18QqjhQuutTdGSRBsHOXv0pnRSJDfcLaEpaEoA/savOdEYs3goV48PPfeMq093y xWaSyXxv+Ux/5zaAqsfqTnYiTPPgyKs9c5LDc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=Ehjh1l5dfg2kof0cUEWKFdNhe612eLMqu755J2+3jAI=; b=TyL3aEmmxtNkzG27vIsGMJyTzyEtPMaMQ5kgmXGmtCzeThvUBO5oVycLlzFHMCCLl8 7/V3Z5/OMGpBQgH0s6lVNsaxyy1Cc29O5G+QiikgE7AKdFxbWWfTvVfb78Y4hscvJ0Ui cbZV05wLCWaBUGrbECsmE/Vh43XODOC+r/t5VEufmMdEPLEqWs/bUz5/Z/Vn4GIbvWa6 WrmU4dqvKvPJoULQuFeUBE7u3Ufo8szMndwXqWfq3bxSEJMCAq2qoayHwJi2dkkBxE5c L8IyyF9R/mzXpVf3WQCjcUTOSlofXOo9tg5iE/9FC6D/n1epfX6bndmRtfktNi9cgRbK tmZA== X-Gm-Message-State: ALoCoQnvINSiTaz7zxrtY+nw4Db8tRoAx4fIQIoec9r1LUV9rmzBDA+B53CI1wxpnv+U4RML+m3u X-Received: by 10.49.26.6 with SMTP id h6mr28115267qeg.75.1383975560191; Fri, 08 Nov 2013 21:39:20 -0800 (PST) MIME-Version: 1.0 Received: by 10.96.63.101 with HTTP; Fri, 8 Nov 2013 21:38:50 -0800 (PST) From: Eitan Adler Date: Sat, 9 Nov 2013 00:38:50 -0500 Message-ID: Subject: iwn transmit debug info To: "freebsd-wireless@freebsd.org" Content-Type: text/plain; charset=UTF-8 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, 09 Nov 2013 05:39:21 -0000 Per Adrian's request: iwn_notif_intr: scanning channel 5 status 1 iwn_notif_intr: scanning channel 8 status 1 iwn_notif_intr: scanning channel 9 status 1 iwn_notif_intr: scanning channel 10 status 1 iwn_notif_intr: scanning channel 12 status 1 iwn_tx_data_raw: qid 3 idx 0 len 6 nsegs 1 iwn5000_tx_done: qid 3 idx 0 retries 1 nkill 0 rate 420a duration 1242 status 201 iwn_tx_data_raw: qid 3 idx 1 len 83 nsegs 1 iwn5000_tx_done: qid 3 idx 1 retries 0 nkill 0 rate 420a duration 1394 status 201 wlan1: link state changed to UP iwn_tx_data: qid 3 idx 2 len 24 nsegs 2 iwn5000_tx_done: qid 3 idx 2 retries 0 nkill 0 rate 6100 duration 158 status 201 iwn_tx_data: qid 3 idx 3 len 241 nsegs 2 iwn5000_tx_done: qid 3 idx 3 retries 0 nkill 0 rate 6100 duration 399 status 201 iwn_tx_data: qid 3 idx 4 len 18 nsegs 2 iwn5000_tx_done: qid 3 idx 4 retries 0 nkill 0 rate 6100 duration 150 status 201 iwn_tx_data: qid 3 idx 5 len 18 nsegs 2 iwn5000_tx_done: qid 3 idx 5 retries 0 nkill 0 rate 6100 duration 150 status 201 iwn_tx_data: qid 3 idx 6 len 18 nsegs 2 iwn5000_tx_done: qid 3 idx 6 retries 0 nkill 0 rate 6100 duration 150 status 201 iwn_tx_data: qid 3 idx 7 len 18 nsegs 2 iwn5000_tx_done: qid 3 idx 7 retries 1 nkill 0 rate 6100 duration 240 status 201 iwn_tx_data: qid 3 idx 8 len 344 nsegs 2 iwn5000_tx_done: qid 3 idx 8 retries 0 nkill 0 rate 6100 duration 514 status 201 iwn_tx_data: qid 3 idx 9 len 18 nsegs 2 iwn5000_tx_done: qid 3 idx 9 retries 0 nkill 0 rate 6100 duration 150 status 201 iwn_tx_data: qid 3 idx 10 len 108 nsegs 2 iwn5000_tx_done: qid 3 idx 10 retries 0 nkill 0 rate 6100 duration 251 status 201 iwn_tx_data: qid 3 idx 11 len 156 nsegs 2 iwn5000_tx_done: qid 3 idx 11 retries 0 nkill 0 rate 6100 duration 305 status 201 iwn_tx_data: qid 3 idx 12 len 92 nsegs 2 iwn5000_tx_done: qid 3 idx 12 retries 0 nkill 0 rate 6100 duration 233 status 201 iwn_tx_data: qid 3 idx 13 len 18 nsegs 2 iwn5000_tx_done: qid 3 idx 13 retries 0 nkill 0 rate 6100 duration 150 status 201 iwn_tx_data: qid 3 idx 14 len 129 nsegs 2 iwn5000_tx_done: qid 3 idx 14 retries 0 nkill 0 rate 6100 duration 276 status 201 iwn_tx_data: qid 3 idx 15 len 107 nsegs 2 iwn5000_tx_done: qid 3 idx 15 retries 0 nkill 0 rate 6100 duration 251 status 201 -- Eitan Adler From owner-freebsd-wireless@FreeBSD.ORG Sat Nov 9 05:51:24 2013 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 0BDEEEE1 for ; Sat, 9 Nov 2013 05:51:24 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-qe0-x231.google.com (mail-qe0-x231.google.com [IPv6:2607:f8b0:400d:c02::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C26BC2B0E for ; Sat, 9 Nov 2013 05:51:23 +0000 (UTC) Received: by mail-qe0-f49.google.com with SMTP id a11so2805170qen.36 for ; Fri, 08 Nov 2013 21:51: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:message-id:subject :from:to:cc:content-type; bh=EqBXjcROSYFHNKxN5d321ttWWY2V2eMQ79jbB68eN2k=; b=iVkPtsLzrnZHN4WHD5P9DCFyo2S2G3167ycokr3Wx5Mvy+rHMMW0HZne+up3bIOZ2L /d5O1XPEyQo4nvdz078bUpUwUALUAR1tE9IK5UA1IF5L0jdRphyx8CIJNyOvKksfMRMj HvSJ3tufwHKeTWYtxXn/CjSRH6RLK4H+pgAN3u7ovl+544jYbH+WeQ+DptxFY3jMI9A6 xgSuxWZoxtS5153NSvJprO38uesPbVN4YVCUo8ItYhM+6qftdTiUZQxXwYPxrW3o/aLR 5c5les81Hrg8kQEl7oigYqFQFLe0nOHTTH2twJeB8kqGZLcHlaDOK71n3FiQizymuOvk /WDw== MIME-Version: 1.0 X-Received: by 10.49.59.70 with SMTP id x6mr28137441qeq.17.1383976282493; Fri, 08 Nov 2013 21:51:22 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.224.207.66 with HTTP; Fri, 8 Nov 2013 21:51:22 -0800 (PST) In-Reply-To: References: Date: Fri, 8 Nov 2013 21:51:22 -0800 X-Google-Sender-Auth: 3Ds9Q3ruVZCWYbUi231HmHajLqM Message-ID: Subject: Re: iwn transmit debug info From: Adrian Chadd To: Eitan Adler 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: Sat, 09 Nov 2013 05:51:24 -0000 Yeah, but those frames are successfully transmitting. Are pings making it through? -adrian On 8 November 2013 21:38, Eitan Adler wrote: > Per Adrian's request: > > iwn_notif_intr: scanning channel 5 status 1 > iwn_notif_intr: scanning channel 8 status 1 > iwn_notif_intr: scanning channel 9 status 1 > iwn_notif_intr: scanning channel 10 status 1 > iwn_notif_intr: scanning channel 12 status 1 > iwn_tx_data_raw: qid 3 idx 0 len 6 nsegs 1 > iwn5000_tx_done: qid 3 idx 0 retries 1 nkill 0 rate 420a duration 1242 > status 201 > iwn_tx_data_raw: qid 3 idx 1 len 83 nsegs 1 > iwn5000_tx_done: qid 3 idx 1 retries 0 nkill 0 rate 420a duration 1394 > status 201 > wlan1: link state changed to UP > iwn_tx_data: qid 3 idx 2 len 24 nsegs 2 > iwn5000_tx_done: qid 3 idx 2 retries 0 nkill 0 rate 6100 duration 158 status 201 > iwn_tx_data: qid 3 idx 3 len 241 nsegs 2 > iwn5000_tx_done: qid 3 idx 3 retries 0 nkill 0 rate 6100 duration 399 status 201 > iwn_tx_data: qid 3 idx 4 len 18 nsegs 2 > iwn5000_tx_done: qid 3 idx 4 retries 0 nkill 0 rate 6100 duration 150 status 201 > iwn_tx_data: qid 3 idx 5 len 18 nsegs 2 > iwn5000_tx_done: qid 3 idx 5 retries 0 nkill 0 rate 6100 duration 150 status 201 > iwn_tx_data: qid 3 idx 6 len 18 nsegs 2 > iwn5000_tx_done: qid 3 idx 6 retries 0 nkill 0 rate 6100 duration 150 status 201 > iwn_tx_data: qid 3 idx 7 len 18 nsegs 2 > iwn5000_tx_done: qid 3 idx 7 retries 1 nkill 0 rate 6100 duration 240 status 201 > iwn_tx_data: qid 3 idx 8 len 344 nsegs 2 > iwn5000_tx_done: qid 3 idx 8 retries 0 nkill 0 rate 6100 duration 514 status 201 > iwn_tx_data: qid 3 idx 9 len 18 nsegs 2 > iwn5000_tx_done: qid 3 idx 9 retries 0 nkill 0 rate 6100 duration 150 status 201 > iwn_tx_data: qid 3 idx 10 len 108 nsegs 2 > iwn5000_tx_done: qid 3 idx 10 retries 0 nkill 0 rate 6100 duration 251 > status 201 > iwn_tx_data: qid 3 idx 11 len 156 nsegs 2 > iwn5000_tx_done: qid 3 idx 11 retries 0 nkill 0 rate 6100 duration 305 > status 201 > iwn_tx_data: qid 3 idx 12 len 92 nsegs 2 > iwn5000_tx_done: qid 3 idx 12 retries 0 nkill 0 rate 6100 duration 233 > status 201 > iwn_tx_data: qid 3 idx 13 len 18 nsegs 2 > iwn5000_tx_done: qid 3 idx 13 retries 0 nkill 0 rate 6100 duration 150 > status 201 > iwn_tx_data: qid 3 idx 14 len 129 nsegs 2 > iwn5000_tx_done: qid 3 idx 14 retries 0 nkill 0 rate 6100 duration 276 > status 201 > iwn_tx_data: qid 3 idx 15 len 107 nsegs 2 > iwn5000_tx_done: qid 3 idx 15 retries 0 nkill 0 rate 6100 duration 251 > status 201 > > > -- > Eitan Adler > _______________________________________________ > freebsd-wireless@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-wireless > To unsubscribe, send any mail to "freebsd-wireless-unsubscribe@freebsd.org" From owner-freebsd-wireless@FreeBSD.ORG Sat Nov 9 07:13:44 2013 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id E954C7E1 for ; Sat, 9 Nov 2013 07:13:44 +0000 (UTC) (envelope-from sven@hazejager.nl) Received: from mail-oa0-f43.google.com (mail-oa0-f43.google.com [209.85.219.43]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id AF87B2E17 for ; Sat, 9 Nov 2013 07:13:44 +0000 (UTC) Received: by mail-oa0-f43.google.com with SMTP id g12so1729621oah.16 for ; Fri, 08 Nov 2013 23:13:38 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=SPYcSsijDK3hV9B5VEM3xtJhT45YTPVR7wZedQV94Cw=; b=jDb34UUDhIuYHiWF4yw0kcSAyqydPQaHTHa4DDgv7XN7VYSQMGmgjvxE1gddevV9w6 qskeU7uJSswAdV6ID5s9Xha+LvOywGn86rRG2HMeRbpD8ZszJycUgqVxLLQvsaeBgQzP zGi7T/kcLDUpc7gveresFWHMIpq0YQrgSQx3NKzpvnoyfk7BtWHm7qX5ooIpQWudIXgT oek+g4iUnwcwaXQ1u5s7s6Ncoy+6s6jbvApkYbioKuzDx8nCMbAyjZGaAMNBY+VnnL0N VSukXedlLxW5ZcUpssHT9NtIvQAiCIPsjQ+8IWIzKPRQfc4TIxvdMOPGoFx1H/Gxp+FU g4UA== X-Gm-Message-State: ALoCoQnBCXJMe51zXpi9qibWy5VzTaxmDlZ1zRne3CiJNKAcq1E/OZIxvO++gtJAE5/HMlTytpg2 MIME-Version: 1.0 X-Received: by 10.182.28.35 with SMTP id y3mr434726obg.55.1383981217969; Fri, 08 Nov 2013 23:13:37 -0800 (PST) Received: by 10.182.18.9 with HTTP; Fri, 8 Nov 2013 23:13:37 -0800 (PST) X-Originating-IP: [83.81.40.148] In-Reply-To: References: Date: Sat, 9 Nov 2013 08:13:37 +0100 Message-ID: Subject: Re: AR9160 on HEAD - unstable? From: Sven Hazejager To: Adrian Chadd Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 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: Sat, 09 Nov 2013 07:13:45 -0000 Well, my original hypothesis was wrong: HEAD r250200 (around 3 May 2013) fully lost its wifi on me this morning. My iPhone was on during the night, which generated a long list of "stuck beacon" messages. The iPhone could not get a connection and neither could any other stations. A warm reboot did not help! I had to physically power down the ALIX box. So I guess I won't be testing on r250200 anymore, as my previous problems were all resolvable by resetting the station, not the AP. Below is the complete /var/log/messages. Any suggestions? Nov 7 21:54:23 algol newsyslog[1056]: logfile first created Nov 7 21:54:23 algol syslogd: kernel boot file is /boot/kernel/kernel Nov 7 21:54:23 algol kernel: Copyright (c) 1992-2013 The FreeBSD Project. Nov 7 21:54:23 algol kernel: Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 Nov 7 21:54:23 algol kernel: The Regents of the University of California. All rights reserved. Nov 7 21:54:23 algol kernel: FreeBSD is a registered trademark of The FreeBSD Foundation. Nov 7 21:54:23 algol kernel: FreeBSD 10.0-CURRENT #0: Thu Nov 7 15:30:54 CET 2013 Nov 7 21:54:23 algol kernel: root@vmbsd10:/usr/obj/nanobsd.alix/usr/src/sys/ALIX i386 Nov 7 21:54:23 algol kernel: FreeBSD clang version 3.3 (trunk 178860) 20130405 Nov 7 21:54:23 algol kernel: CPU: Geode(TM) Integrated Processor by AMD PCS (498.06-MHz 586-class CPU) Nov 7 21:54:23 algol kernel: Origin = "AuthenticAMD" Id = 0x5a2 Family = 0x5 Model = 0xa Stepping = 2 Nov 7 21:54:23 algol kernel: Features=0x88a93d Nov 7 21:54:23 algol kernel: AMD Features=0xc0400000 Nov 7 21:54:23 algol kernel: real memory = 268435456 (256 MB) Nov 7 21:54:23 algol kernel: avail memory = 250781696 (239 MB) Nov 7 21:54:23 algol kernel: pnpbios: Bad PnP BIOS data checksum Nov 7 21:54:23 algol kernel: K6-family MTRR support enabled (2 registers) Nov 7 21:54:23 algol kernel: cryptosoft0: on motherboard Nov 7 21:54:23 algol kernel: pcib0 pcibus 0 on motherboard Nov 7 21:54:23 algol kernel: pci0: on pcib0 Nov 7 21:54:23 algol kernel: Geode LX: PC Engines ALIX.2 v0.99h tinyBIOS V1.4a (C)1997-2007 Nov 7 21:54:23 algol kernel: glxsb0: mem 0xefff4000-0xefff7fff irq 9 at device 1.2 on pci0 Nov 7 21:54:23 algol kernel: vr0: port 0x1000-0x10ff mem 0xe0000000-0xe00000ff irq 10 at device 9.0 on pci0 Nov 7 21:54:23 algol kernel: vr0: Quirks: 0x2 Nov 7 21:54:23 algol kernel: vr0: Revision: 0x96 Nov 7 21:54:23 algol kernel: miibus0: on vr0 Nov 7 21:54:23 algol kernel: ukphy0: PHY 1 on miibus0 Nov 7 21:54:23 algol kernel: ukphy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto, auto-flow Nov 7 21:54:23 algol kernel: vr0: Ethernet address: 00:0d:b9:19:aa:94 Nov 7 21:54:23 algol kernel: vr1: port 0x1400-0x14ff mem 0xe0040000-0xe00400ff irq 15 at device 11.0 on pci0 Nov 7 21:54:23 algol kernel: vr1: Quirks: 0x2 Nov 7 21:54:23 algol kernel: vr1: Revision: 0x96 Nov 7 21:54:23 algol kernel: miibus1: on vr1 Nov 7 21:54:23 algol kernel: ukphy1: PHY 1 on miibus1 Nov 7 21:54:23 algol kernel: ukphy1: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto, auto-flow Nov 7 21:54:23 algol kernel: vr1: Ethernet address: 00:0d:b9:19:aa:95 Nov 7 21:54:23 algol kernel: ath0: mem 0xe0080000-0xe008ffff irq 9 at device 12.0 on pci0 Nov 7 21:54:23 algol kernel: ath0: [HT] enabling HT modes Nov 7 21:54:23 algol kernel: ath0: [HT] 2 RX streams; 2 TX streams Nov 7 21:54:23 algol kernel: ath0: AR9160 mac 64.1 RF5133 phy 11.0 Nov 7 21:54:23 algol kernel: ath0: 2GHz radio: 0x0000; 5GHz radio: 0x00c0 Nov 7 21:54:23 algol kernel: isab0: port 0x6000-0x6007,0x6100-0x61ff,0x6200-0x623f,0x9d00-0x9d7f,0x9c00-0x9c3f at device 15.0 on pci0 Nov 7 21:54:23 algol kernel: isa0: on isab0 Nov 7 21:54:23 algol kernel: atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xff00-0xff0f at device 15.2 on pci0 Nov 7 21:54:23 algol kernel: ata0: at channel 0 on atapci0 Nov 7 21:54:23 algol kernel: ata1: at channel 1 on atapci0 Nov 7 21:54:23 algol kernel: ohci0: mem 0xefffe000-0xefffefff irq 12 at device 15.4 on pci0 Nov 7 21:54:23 algol kernel: usbus0 on ohci0 Nov 7 21:54:23 algol kernel: ehci0: mem 0xefffd000-0xefffdfff irq 12 at device 15.5 on pci0 Nov 7 21:54:23 algol kernel: usbus1: EHCI version 1.0 Nov 7 21:54:23 algol kernel: usbus1 on ehci0 Nov 7 21:54:23 algol kernel: cpu0 on motherboard Nov 7 21:54:23 algol kernel: orm0: at iomem 0xe0000-0xea7ff pnpid ORM0000 on isa0 Nov 7 21:54:23 algol kernel: atrtc0: at port 0x70 irq 8 on isa0 Nov 7 21:54:23 algol kernel: Event timer "RTC" frequency 32768 Hz quality 0 Nov 7 21:54:23 algol kernel: attimer0: at port 0x40 on isa0 Nov 7 21:54:23 algol kernel: Timecounter "i8254" frequency 1193182 Hz quality 0 Nov 7 21:54:23 algol kernel: Event timer "i8254" frequency 1193182 Hz quality 100 Nov 7 21:54:23 algol kernel: uart0: <16550 or compatible> at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 Nov 7 21:54:23 algol kernel: uart0: console (57600,n,8,1) Nov 7 21:54:23 algol kernel: uart1: <16550 or compatible> at port 0x2f8-0x2ff irq 3 on isa0 Nov 7 21:54:23 algol kernel: Timecounters tick every 1.000 msec Nov 7 21:54:23 algol kernel: usbus0: 12Mbps Full Speed USB v1.0 Nov 7 21:54:23 algol kernel: usbus1: 480Mbps High Speed USB v2.0 Nov 7 21:54:23 algol kernel: ugen0.1: at usbus0 Nov 7 21:54:23 algol kernel: uhub0: on usbus0 Nov 7 21:54:23 algol kernel: ugen1.1: at usbus1 Nov 7 21:54:23 algol kernel: uhub1: on usbus1 Nov 7 21:54:23 algol kernel: ada0 at ata0 bus 0 scbus0 target 0 lun 0 Nov 7 21:54:23 algol kernel: ada0: ATA-0 device Nov 7 21:54:23 algol kernel: ada0: 100.000MB/s transfers (UDMA5, PIO 512bytes) Nov 7 21:54:23 algol kernel: ada0: 3831MB (7847280 512 byte sectors: 16H 63S/T 7785C) Nov 7 21:54:23 algol kernel: ada0: Previously was known as ad0 Nov 7 21:54:23 algol kernel: Timecounter "TSC" frequency 498060911 Hz quality 800 Nov 7 21:54:23 algol kernel: Root mount waiting for: usbus1 usbus0 Nov 7 21:54:23 algol kernel: uhub0: 4 ports with 4 removable, self powered Nov 7 21:54:23 algol kernel: Root mount waiting for: usbus1 Nov 7 21:54:23 algol kernel: uhub1: 4 ports with 4 removable, self powered Nov 7 21:54:23 algol kernel: Trying to mount root from ufs:/dev/ada0s2a [ro]... Nov 7 21:54:23 algol kernel: bridge0: Ethernet address: 02:6e:c2:cf:62:00 Nov 7 21:54:23 algol kernel: wlan0: Ethernet address: 00:0b:6b:b1:3a:e7 Nov 7 21:54:25 algol root: /etc/rc: WARNING: failed precmd routine for unbound Nov 7 21:54:25 algol kernel: /etc/rc: WARNING: failed precmd routine for unbound Nov 7 21:54:26 algol ntpd[1183]: ntpd 4.2.4p5-a (1) Nov 7 21:54:28 algol ftp-proxy[1268]: listening on 127.0.0.1 port 8021 Nov 7 21:54:28 algol ntpd_initres[1187]: host name not found: 0.nl.pool.ntp.org Nov 7 21:54:28 algol ntpd_initres[1187]: host name not found: 1.nl.pool.ntp.org Nov 7 21:54:28 algol ntpd_initres[1187]: host name not found: 2.nl.pool.ntp.org Nov 7 21:54:28 algol ntpd_initres[1187]: host name not found: 3.nl.pool.ntp.org Nov 7 21:54:29 algol dhcpd: gigaset.home.lan: temporary name server failure Nov 7 21:54:32 algol dhcpd: sven-iphone.home.lan: temporary name server failure Nov 7 21:54:46 algol su: sven to root on /dev/pts/0 Nov 7 21:55:05 algol unbound: [1301:0] notice: init module 0: validator Nov 7 21:55:05 algol unbound: [1301:0] notice: init module 1: iterator Nov 7 21:55:37 algol ntpd[1184]: time reset -0.953825 s Nov 7 21:59:21 algol su: sven to root on /dev/pts/0 Nov 7 22:02:30 algol su: sven to root on /dev/pts/0 Nov 7 22:31:50 algol dhcpd: uid lease 192.168.2.33 for client 18:af:61:21:ae:28 is duplicate on 192.168.2.0/24 Nov 7 22:31:51 algol dhcpd: uid lease 192.168.2.33 for client 18:af:61:21:ae:28 is duplicate on 192.168.2.0/24 Nov 7 22:44:15 algol kernel: ath0: ath_bar_response: huh? bar_tx=0, bar_wait=0 Nov 7 23:05:06 algol dhcpd: uid lease 192.168.2.33 for client 18:af:61:21:ae:28 is duplicate on 192.168.2.0/24 Nov 7 23:15:07 algol dhcpd: uid lease 192.168.2.33 for client 18:af:61:21:ae:28 is duplicate on 192.168.2.0/24 Nov 8 00:18:16 algol dhcpd: uid lease 192.168.2.33 for client 18:af:61:21:ae:28 is duplicate on 192.168.2.0/24 Nov 8 01:18:32 algol dhcpd: uid lease 192.168.2.33 for client 18:af:61:21:ae:28 is duplicate on 192.168.2.0/24 Nov 8 02:18:43 algol dhcpd: uid lease 192.168.2.33 for client 18:af:61:21:ae:28 is duplicate on 192.168.2.0/24 Nov 8 03:18:56 algol dhcpd: uid lease 192.168.2.33 for client 18:af:61:21:ae:28 is duplicate on 192.168.2.0/24 Nov 8 03:42:20 algol dhcpd: uid lease 192.168.2.33 for client 18:af:61:21:ae:28 is duplicate on 192.168.2.0/24 Nov 8 04:42:31 algol dhcpd: uid lease 192.168.2.33 for client 18:af:61:21:ae:28 is duplicate on 192.168.2.0/24 Nov 8 05:05:56 algol dhcpd: uid lease 192.168.2.33 for client 18:af:61:21:ae:28 is duplicate on 192.168.2.0/24 Nov 8 05:19:19 algol dhcpd: uid lease 192.168.2.33 for client 18:af:61:21:ae:28 is duplicate on 192.168.2.0/24 Nov 8 06:19:32 algol dhcpd: uid lease 192.168.2.33 for client 18:af:61:21:ae:28 is duplicate on 192.168.2.0/24 Nov 8 06:42:56 algol dhcpd: uid lease 192.168.2.33 for client 18:af:61:21:ae:28 is duplicate on 192.168.2.0/24 Nov 8 07:43:05 algol dhcpd: uid lease 192.168.2.33 for client 18:af:61:21:ae:28 is duplicate on 192.168.2.0/24 Nov 8 10:13:12 algol kernel: ath0: stuck beacon; resetting (bmiss count 4) Nov 8 10:13:12 algol kernel: ar5416StopDmaReceive: dma failed to stop in 10ms Nov 8 10:13:12 algol kernel: AR_CR=0x00000024 Nov 8 10:13:12 algol kernel: AR_DIAG_SW=0x42000020 Nov 8 12:28:45 algol kernel: ath0: ath_tx_tid_drain_print: norm: node 0xc3339000: bf=0xc254cd10: addbaw=0, dobaw=0, seqno=106, retry=0 Nov 8 12:28:45 algol kernel: ath0: ath_tx_tid_drain_print: node 0xc3339000: bf=0xc254cd10: txq[1] axq_depth=18, axq_aggr_depth=0 Nov 8 12:28:45 algol kernel: ath0: ath_tx_tid_drain_print: node 0xc3339000: bf=0xc254cd10: tid txq_depth=20 hwq_depth=18, bar_wait=0, isfiltered=0 Nov 8 12:28:45 algol kernel: ath0: ath_tx_tid_drain_print: node 0xc3339000: tid 0: sched=1, paused=0, incomp=0, baw_head=93, baw_tail=93 txa_start=3976, ni_txseqs=4222 Nov 8 12:28:45 algol kernel: FRDS 02:6e:c2:cf:62:00->c4:85:08:56:df:74(00:0b:6b:b1:3a:e7) data QoS [TID 0] WEP [IV 6d 40 00 00 00 00 KID 0] 0M Nov 8 12:28:45 algol kernel: 8842 0000 c485 0856 df74 000b 6bb1 3ae7 026e c2cf 6200 a006 0000 0000 6d40 0020 0000 0000 aaaa 0300 0000 0800 Nov 8 15:58:37 algol kernel: ath0: stuck beacon; resetting (bmiss count 4) Nov 8 15:58:37 algol kernel: ar5416StopDmaReceive: dma failed to stop in 10ms Nov 8 15:58:37 algol kernel: AR_CR=0x00000024 Nov 8 15:58:37 algol kernel: AR_DIAG_SW=0x42000020 Nov 8 15:58:37 algol kernel: stray irq7 Nov 8 16:37:43 algol dhcpd: uid lease 192.168.2.33 for client 18:af:61:21:ae:28 is duplicate on 192.168.2.0/24 Nov 8 16:37:44 algol dhcpd: uid lease 192.168.2.33 for client 18:af:61:21:ae:28 is duplicate on 192.168.2.0/24 Nov 8 17:07:50 algol dhcpd: uid lease 192.168.2.33 for client 18:af:61:21:ae:28 is duplicate on 192.168.2.0/24 Nov 8 18:08:23 algol dhcpd: uid lease 192.168.2.33 for client 18:af:61:21:ae:28 is duplicate on 192.168.2.0/24 Nov 8 18:30:49 algol dhcpd: uid lease 192.168.2.33 for client 18:af:61:21:ae:28 is duplicate on 192.168.2.0/24 Nov 8 18:43:43 algol dhcpd: uid lease 192.168.2.33 for client 18:af:61:21:ae:28 is duplicate on 192.168.2.0/24 Nov 8 18:50:26 algol dhcpd: uid lease 192.168.2.33 for client 18:af:61:21:ae:28 is duplicate on 192.168.2.0/24 Nov 8 19:11:01 algol kernel: ath0: ath_bar_response: huh? bar_tx=0, bar_wait=0 Nov 8 19:21:09 algol dhcpd: uid lease 192.168.2.33 for client 18:af:61:21:ae:28 is duplicate on 192.168.2.0/24 Nov 8 20:27:23 algol dhcpd: uid lease 192.168.2.33 for client 18:af:61:21:ae:28 is duplicate on 192.168.2.0/24 Nov 8 20:27:40 algol last message repeated 4 times Nov 8 21:08:53 algol dhcpd: uid lease 192.168.2.33 for client 18:af:61:21:ae:28 is duplicate on 192.168.2.0/24 Nov 8 21:19:01 algol last message repeated 2 times Nov 8 21:29:01 algol last message repeated 8 times Nov 8 21:38:59 algol last message repeated 19 times Nov 8 21:48:56 algol last message repeated 19 times Nov 8 21:52:19 algol last message repeated 4 times Nov 8 22:22:19 algol dhcpd: uid lease 192.168.2.33 for client 18:af:61:21:ae:28 is duplicate on 192.168.2.0/24 Nov 8 22:35:29 algol dhcpd: uid lease 192.168.2.33 for client 18:af:61:21:ae:28 is duplicate on 192.168.2.0/24 Nov 8 22:42:12 algol dhcpd: uid lease 192.168.2.33 for client 18:af:61:21:ae:28 is duplicate on 192.168.2.0/24 Nov 8 22:48:55 algol last message repeated 2 times Nov 8 23:49:17 algol dhcpd: uid lease 192.168.2.33 for client 18:af:61:21:ae:28 is duplicate on 192.168.2.0/24 Nov 9 00:12:46 algol dhcpd: uid lease 192.168.2.33 for client 18:af:61:21:ae:28 is duplicate on 192.168.2.0/24 Nov 9 00:23:20 algol dhcpd: uid lease 192.168.2.33 for client 18:af:61:21:ae:28 is duplicate on 192.168.2.0/24 Nov 9 00:36:15 algol dhcpd: uid lease 192.168.2.33 for client 18:af:61:21:ae:28 is duplicate on 192.168.2.0/24 Nov 9 00:46:21 algol last message repeated 2 times Nov 9 00:56:25 algol last message repeated 18 times Nov 9 00:56:29 algol last message repeated 2 times Nov 9 00:59:47 algol dhcpd: uid lease 192.168.2.33 for client 18:af:61:21:ae:28 is duplicate on 192.168.2.0/24 Nov 9 01:00:12 algol last message repeated 5 times Nov 9 01:03:07 algol dhcpd: uid lease 192.168.2.33 for client 18:af:61:21:ae:28 is duplicate on 192.168.2.0/24 Nov 9 01:13:11 algol last message repeated 10 times Nov 9 01:23:14 algol last message repeated 26 times Nov 9 01:33:19 algol last message repeated 13 times Nov 9 01:43:23 algol last message repeated 17 times Nov 9 01:53:27 algol last message repeated 15 times Nov 9 02:03:29 algol last message repeated 13 times Nov 9 02:10:16 algol last message repeated 11 times Nov 9 02:21:40 algol last message repeated 18 times Nov 9 02:30:27 algol last message repeated 13 times Nov 9 02:40:49 algol last message repeated 13 times Nov 9 02:50:29 algol last message repeated 11 times Nov 9 03:00:56 algol last message repeated 12 times Nov 9 03:07:32 algol last message repeated 10 times Nov 9 03:58:05 algol dhcpd: uid lease 192.168.2.33 for client 18:af:61:21:ae:28 is duplicate on 192.168.2.0/24 Nov 9 04:08:09 algol last message repeated 3 times Nov 9 04:18:14 algol last message repeated 13 times Nov 9 04:28:19 algol last message repeated 24 times Nov 9 04:38:22 algol last message repeated 20 times Nov 9 04:48:26 algol last message repeated 11 times Nov 9 04:48:34 algol last message repeated 4 times Nov 9 05:19:05 algol dhcpd: uid lease 192.168.2.33 for client 18:af:61:21:ae:28 is duplicate on 192.168.2.0/24 Nov 9 05:32:31 algol dhcpd: uid lease 192.168.2.33 for client 18:af:61:21:ae:28 is duplicate on 192.168.2.0/24 Nov 9 05:39:14 algol dhcpd: uid lease 192.168.2.33 for client 18:af:61:21:ae:28 is duplicate on 192.168.2.0/24 Nov 9 05:52:33 algol last message repeated 29 times Nov 9 06:02:29 algol last message repeated 13 times Nov 9 06:12:28 algol last message repeated 12 times Nov 9 06:19:09 algol last message repeated 6 times Nov 9 06:20:06 algol kernel: ath0: stuck beacon; resetting (bmiss count 4) Nov 9 06:22:29 algol dhcpd: uid lease 192.168.2.33 for client 18:af:61:21:ae:28 is duplicate on 192.168.2.0/24 Nov 9 06:22:33 algol last message repeated 2 times Nov 9 06:25:48 algol dhcpd: uid lease 192.168.2.33 for client 18:af:61:21:ae:28 is duplicate on 192.168.2.0/24 Nov 9 06:25:53 algol last message repeated 2 times Nov 9 06:26:43 algol kernel: ath0: stuck beacon; resetting (bmiss count 4) Nov 9 06:28:06 algol kernel: ath0: stuck beacon; resetting (bmiss count 4) Nov 9 06:29:10 algol dhcpd: uid lease 192.168.2.33 for client 18:af:61:21:ae:28 is duplicate on 192.168.2.0/24 Nov 9 06:29:19 algol last message repeated 3 times Nov 9 06:31:16 algol kernel: ath0: stuck beacon; resetting (bmiss count 4) Nov 9 06:32:32 algol dhcpd: uid lease 192.168.2.33 for client 18:af:61:21:ae:28 is duplicate on 192.168.2.0/24 Nov 9 06:32:36 algol last message repeated 2 times Nov 9 06:34:00 algol kernel: ath0: stuck beacon; resetting (bmiss count 4) Nov 9 06:35:55 algol dhcpd: uid lease 192.168.2.33 for client 18:af:61:21:ae:28 is duplicate on 192.168.2.0/24 Nov 9 06:35:59 algol last message repeated 2 times Nov 9 06:39:09 algol kernel: ath0: stuck beacon; resetting (bmiss count 4) Nov 9 06:39:15 algol dhcpd: uid lease 192.168.2.33 for client 18:af:61:21:ae:28 is duplicate on 192.168.2.0/24 Nov 9 06:39:18 algol dhcpd: uid lease 192.168.2.33 for client 18:af:61:21:ae:28 is duplicate on 192.168.2.0/24 Nov 9 06:42:37 algol dhcpd: uid lease 192.168.2.33 for client 18:af:61:21:ae:28 is duplicate on 192.168.2.0/24 Nov 9 06:42:41 algol last message repeated 2 times Nov 9 06:42:41 algol kernel: ath0: stuck beacon; resetting (bmiss count 4) Nov 9 06:42:46 algol dhcpd: uid lease 192.168.2.33 for client 18:af:61:21:ae:28 is duplicate on 192.168.2.0/24 Nov 9 06:43:02 algol last message repeated 2 times Nov 9 06:45:57 algol dhcpd: uid lease 192.168.2.33 for client 18:af:61:21:ae:28 is duplicate on 192.168.2.0/24 Nov 9 06:46:02 algol last message repeated 4 times Nov 9 06:46:38 algol kernel: ath0: stuck beacon; resetting (bmiss count 4) Nov 9 06:48:54 algol kernel: ath0: stuck beacon; resetting (bmiss count 4) Nov 9 06:49:20 algol dhcpd: uid lease 192.168.2.33 for client 18:af:61:21:ae:28 is duplicate on 192.168.2.0/24 Nov 9 06:49:28 algol last message repeated 3 times Nov 9 06:50:32 algol kernel: ath0: stuck beacon; resetting (bmiss count 4) Nov 9 06:52:39 algol dhcpd: uid lease 192.168.2.33 for client 18:af:61:21:ae:28 is duplicate on 192.168.2.0/24 Nov 9 06:52:43 algol last message repeated 2 times Nov 9 06:56:03 algol dhcpd: uid lease 192.168.2.33 for client 18:af:61:21:ae:28 is duplicate on 192.168.2.0/24 Nov 9 07:03:10 algol last message repeated 11 times Nov 9 07:11:49 algol last message repeated 15 times Nov 9 07:14:04 algol kernel: ath0: stuck beacon; resetting (bmiss count 4) Nov 9 07:14:34 algol kernel: ath0: stuck beacon; resetting (bmiss count 4) Nov 9 07:14:52 algol dhcpd: uid lease 192.168.2.33 for client 18:af:61:21:ae:28 is duplicate on 192.168.2.0/24 Nov 9 07:15:19 algol last message repeated 5 times Nov 9 07:17:28 algol last message repeated 9 times Nov 9 07:23:40 algol last message repeated 35 times Nov 9 07:25:25 algol kernel: ath0: stuck beacon; resetting (bmiss count 4) Nov 9 07:26:58 algol dhcpd: uid lease 192.168.2.33 for client 18:af:61:21:ae:28 is duplicate on 192.168.2.0/24 Nov 9 07:26:59 algol dhcpd: uid lease 192.168.2.33 for client 18:af:61:21:ae:28 is duplicate on 192.168.2.0/24 Nov 9 07:34:28 algol kernel: ath0: stuck beacon; resetting (bmiss count 4) Nov 9 07:47:28 algol kernel: ath0: stuck beacon; resetting (bmiss count 4) Nov 9 07:50:32 algol kernel: ath0: stuck beacon; resetting (bmiss count 4) Nov 9 07:57:36 algol last message repeated 2 times Nov 9 07:58:24 algol dhcpd: uid lease 192.168.2.33 for client 18:af:61:21:ae:28 is duplicate on 192.168.2.0/24 Nov 9 08:00:11 algol su: sven to root on /dev/pts/0 Nov 9 08:00:26 algol kernel: ar5416PerCalibrationN: NF calibration didn't finish; delaying CCA Nov 9 08:00:26 algol dhcpd: uid lease 192.168.2.33 for client 18:af:61:21:ae:28 is duplicate on 192.168.2.0/24 Nov 9 08:00:35 algol last message repeated 3 times Nov 9 08:01:16 algol kernel: ath0: stuck beacon; resetting (bmiss count 4) Nov 9 08:02:51 algol kernel: ath0: stuck beacon; resetting (bmiss count 4) On 4 November 2013 16:25, Adrian Chadd wrote: > So, May is ok, october isn't? > > can you switch back and verify? > > Those are data dumps of frames that are being freed out of the > software staging queue when the wireless node associated has gone away > (or is being "flushed.") The "bf_next not NULL!" is a worry. > From owner-freebsd-wireless@FreeBSD.ORG Sat Nov 9 07:46:24 2013 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 31C8AC96 for ; Sat, 9 Nov 2013 07:46:24 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-qc0-x22b.google.com (mail-qc0-x22b.google.com [IPv6:2607:f8b0:400d:c01::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id EA0AC2F78 for ; Sat, 9 Nov 2013 07:46:23 +0000 (UTC) Received: by mail-qc0-f171.google.com with SMTP id i8so1632479qcq.30 for ; Fri, 08 Nov 2013 23:46:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=EzlbJ6qCIN/kQXMA00M4CZ8zYuSlOWnvz5a8GScGlTk=; b=mG2Gktx5xzjVHglkX2TB/sfpV4hvsnf2DB+9T6v3DbwZTWG2Ajupjnb1hciN+DQQGc tsiVHa94CnTilVFCOeAHv2N0Rs+ibjL2tlYA34YMgsl4svBuP3LWp+7l5QEY5R7nj+c+ DDOs+GuJ91wEkVYVlIMuoumWhumLueMlwzwrH62m9f/XaIAJnf28HFrY4cR0saWMfbQq kUC9XC9bTXMQ53IXPj5jru64M3VLKjtE/JDIEnwT2rjtMngu8L30OulyZLGHhjqnwD2I Hd7ubEPZnbrdrjkXA6en3amzzY6UGsQDjW9Q8iGqSwQP9X24nwld5p3P5EoO6voK6qio c3Lw== MIME-Version: 1.0 X-Received: by 10.49.99.98 with SMTP id ep2mr29104254qeb.9.1383983183081; Fri, 08 Nov 2013 23:46:23 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.224.207.66 with HTTP; Fri, 8 Nov 2013 23:46:23 -0800 (PST) Date: Fri, 8 Nov 2013 23:46:23 -0800 X-Google-Sender-Auth: DeqAaIVMiDlZUsDzJq9W40X5pEA Message-ID: Subject: [iwn] round four - 5100 works, 21xx works, EAPOL fixes, rate selection fixes 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, 09 Nov 2013 07:46:24 -0000 Argh, why am I still hacking on the iwn(4) driver. So, I saw a lot of broken stuff. This patch fixes some. http://people.freebsd.org/~adrian/iwn/20131108-iwn-update-works-full-5100-11.diff You have to update sys/net80211 and sys/dev/iwn to the latest version in HEAD before you apply this diff. What's committed: * AMRR wasn't correctly initializing the initial rate, so it thought it was starting at MCS15 but it was in fact starting at MCS0. This caused hilarity. * AMRR should be selecting a "mostly ok" rate, not MCS15. So, this was also fixed. What's in this patch: * EAPOL frames were going out at the normal data rate, rather than going out at the management rate. Like ath(4), override this. Once I fixed AMRR to set the initial rate from MCS0 to the "best initial rate" it chose MCS15 and this failed. It showed up as the initial association suceeding but the auth exchange failed, logging a "pre-shared key may be incorrect" message. Sigh. So, like ath(4), detect if it's EAPOL and if so override. * If an AMPDU frame TX failed the firmware doesn't send up a compressed-BA notification as it doesn't receive one. iwn_ampdu_tx_done() doesn't do any rate control notification - that is left up to the compressed BA RX function. So, if an entire A-MPDU transmit failed, there'd be no notification of such - and the rate control code never got notified of said failures! Thus it would never back off the rate. So, if the whole frame transmission failed, just notify the rate control code so it correctly backs off the rate selection. With this, things are .. more stable. The whole A-MPDU handling needs a lot of work to make as correct as the ath(4) driver, but that is so not in the scope of what I'm doing here. -adrian From owner-freebsd-wireless@FreeBSD.ORG Sat Nov 9 07:50:00 2013 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 66A39CD9 for ; Sat, 9 Nov 2013 07:50:00 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-qc0-x22b.google.com (mail-qc0-x22b.google.com [IPv6:2607:f8b0:400d:c01::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 1BF602F8F for ; Sat, 9 Nov 2013 07:50:00 +0000 (UTC) Received: by mail-qc0-f171.google.com with SMTP id i8so1603311qcq.2 for ; Fri, 08 Nov 2013 23:49:59 -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:message-id:subject :from:to:cc:content-type; bh=ilAz2fOaUIwoI2DOCMqPT8aSPkrDTr8pz5ca9/LepOo=; b=eUhhjZs6B/T/FauJsTsOSYlle26bRH8UPK+leiykePoYnxftH9BWi8AQfX7qG8AmVS vgiCKWhApwDRL+5p2PVmnL/Okg0SLy1F8fOjIlseDxgNRcyNOJr5xm+5qRgU2aGt6I99 d0qJDowVHhXWs77aTltanlIdAGw4f9hEGD5cKSDgPnhhsI1lixTkl77vUaXL2I3q8O0G BTpyPpw51IwH/gcNL/Gw2uU2SZImN0T8tjcljHtNPDgPPHR+5dvvXHuIgb7yz5gAhJTD rx8W23dswbkYX8BQt84uEIdWdDsrOtYUAj4w/QuviHfTqdY0ikmHbVSajRKQtL7b8j2D MuIg== MIME-Version: 1.0 X-Received: by 10.49.19.101 with SMTP id d5mr28731806qee.78.1383983399360; Fri, 08 Nov 2013 23:49:59 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.224.207.66 with HTTP; Fri, 8 Nov 2013 23:49:59 -0800 (PST) In-Reply-To: References: Date: Fri, 8 Nov 2013 23:49:59 -0800 X-Google-Sender-Auth: 3G4y9Q3FuAnMUHIAcP76NpxxYWA Message-ID: Subject: Re: AR9160 on HEAD - unstable? From: Adrian Chadd To: Sven Hazejager 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: Sat, 09 Nov 2013 07:50:00 -0000 Hi, the stuck beacon stuff is likely just the MAC getting angry at the power save aggressiveness that the iphone/ipad does. But it itself shouldn't lock things up. When you say you did a warm reboot, is that a 'reboot' where you typed reboot? is there a physical reset button on the ALIX you can short? -adrian On 8 November 2013 23:13, Sven Hazejager wrote: > Well, my original hypothesis was wrong: HEAD r250200 (around 3 May 2013) > fully lost its wifi on me this morning. My iPhone was on during the night, > which generated a long list of "stuck beacon" messages. The iPhone could not > get a connection and neither could any other stations. A warm reboot did not > help! I had to physically power down the ALIX box. > > So I guess I won't be testing on r250200 anymore, as my previous problems > were all resolvable by resetting the station, not the AP. Below is the > complete /var/log/messages. Any suggestions? > > Nov 7 21:54:23 algol newsyslog[1056]: logfile first created > Nov 7 21:54:23 algol syslogd: kernel boot file is /boot/kernel/kernel > Nov 7 21:54:23 algol kernel: Copyright (c) 1992-2013 The FreeBSD Project. > Nov 7 21:54:23 algol kernel: Copyright (c) 1979, 1980, 1983, 1986, 1988, > 1989, 1991, 1992, 1993, 1994 > Nov 7 21:54:23 algol kernel: The Regents of the University of California. > All rights reserved. > Nov 7 21:54:23 algol kernel: FreeBSD is a registered trademark of The > FreeBSD Foundation. > Nov 7 21:54:23 algol kernel: FreeBSD 10.0-CURRENT #0: Thu Nov 7 15:30:54 > CET 2013 > Nov 7 21:54:23 algol kernel: > root@vmbsd10:/usr/obj/nanobsd.alix/usr/src/sys/ALIX i386 > Nov 7 21:54:23 algol kernel: FreeBSD clang version 3.3 (trunk 178860) > 20130405 > Nov 7 21:54:23 algol kernel: CPU: Geode(TM) Integrated Processor by AMD PCS > (498.06-MHz 586-class CPU) > Nov 7 21:54:23 algol kernel: Origin = "AuthenticAMD" Id = 0x5a2 Family = > 0x5 Model = 0xa Stepping = 2 > Nov 7 21:54:23 algol kernel: > Features=0x88a93d > Nov 7 21:54:23 algol kernel: AMD Features=0xc0400000 > Nov 7 21:54:23 algol kernel: real memory = 268435456 (256 MB) > Nov 7 21:54:23 algol kernel: avail memory = 250781696 (239 MB) > Nov 7 21:54:23 algol kernel: pnpbios: Bad PnP BIOS data checksum > Nov 7 21:54:23 algol kernel: K6-family MTRR support enabled (2 registers) > Nov 7 21:54:23 algol kernel: cryptosoft0: on motherboard > Nov 7 21:54:23 algol kernel: pcib0 pcibus 0 on motherboard > Nov 7 21:54:23 algol kernel: pci0: on pcib0 > Nov 7 21:54:23 algol kernel: Geode LX: PC Engines ALIX.2 v0.99h tinyBIOS > V1.4a (C)1997-2007 > Nov 7 21:54:23 algol kernel: glxsb0: (AES-128-CBC, RNG)> mem 0xefff4000-0xefff7fff irq 9 at device 1.2 on pci0 > Nov 7 21:54:23 algol kernel: vr0: port > 0x1000-0x10ff mem 0xe0000000-0xe00000ff irq 10 at device 9.0 on pci0 > Nov 7 21:54:23 algol kernel: vr0: Quirks: 0x2 > Nov 7 21:54:23 algol kernel: vr0: Revision: 0x96 > Nov 7 21:54:23 algol kernel: miibus0: on vr0 > Nov 7 21:54:23 algol kernel: ukphy0: > PHY 1 on miibus0 > Nov 7 21:54:23 algol kernel: ukphy0: none, 10baseT, 10baseT-FDX, > 100baseTX, 100baseTX-FDX, auto, auto-flow > Nov 7 21:54:23 algol kernel: vr0: Ethernet address: 00:0d:b9:19:aa:94 > Nov 7 21:54:23 algol kernel: vr1: port > 0x1400-0x14ff mem 0xe0040000-0xe00400ff irq 15 at device 11.0 on pci0 > Nov 7 21:54:23 algol kernel: vr1: Quirks: 0x2 > Nov 7 21:54:23 algol kernel: vr1: Revision: 0x96 > Nov 7 21:54:23 algol kernel: miibus1: on vr1 > Nov 7 21:54:23 algol kernel: ukphy1: > PHY 1 on miibus1 > Nov 7 21:54:23 algol kernel: ukphy1: none, 10baseT, 10baseT-FDX, > 100baseTX, 100baseTX-FDX, auto, auto-flow > Nov 7 21:54:23 algol kernel: vr1: Ethernet address: 00:0d:b9:19:aa:95 > Nov 7 21:54:23 algol kernel: ath0: mem 0xe0080000-0xe008ffff > irq 9 at device 12.0 on pci0 > Nov 7 21:54:23 algol kernel: ath0: [HT] enabling HT modes > Nov 7 21:54:23 algol kernel: ath0: [HT] 2 RX streams; 2 TX streams > Nov 7 21:54:23 algol kernel: ath0: AR9160 mac 64.1 RF5133 phy 11.0 > Nov 7 21:54:23 algol kernel: ath0: 2GHz radio: 0x0000; 5GHz radio: 0x00c0 > Nov 7 21:54:23 algol kernel: isab0: port > 0x6000-0x6007,0x6100-0x61ff,0x6200-0x623f,0x9d00-0x9d7f,0x9c00-0x9c3f at > device 15.0 on pci0 > Nov 7 21:54:23 algol kernel: isa0: on isab0 > Nov 7 21:54:23 algol kernel: atapci0: port > 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xff00-0xff0f at device 15.2 on pci0 > Nov 7 21:54:23 algol kernel: ata0: at channel 0 on atapci0 > Nov 7 21:54:23 algol kernel: ata1: at channel 1 on atapci0 > Nov 7 21:54:23 algol kernel: ohci0: mem > 0xefffe000-0xefffefff irq 12 at device 15.4 on pci0 > Nov 7 21:54:23 algol kernel: usbus0 on ohci0 > Nov 7 21:54:23 algol kernel: ehci0: > mem 0xefffd000-0xefffdfff irq 12 at device 15.5 on pci0 > Nov 7 21:54:23 algol kernel: usbus1: EHCI version 1.0 > Nov 7 21:54:23 algol kernel: usbus1 on ehci0 > Nov 7 21:54:23 algol kernel: cpu0 on motherboard > Nov 7 21:54:23 algol kernel: orm0: at iomem > 0xe0000-0xea7ff pnpid ORM0000 on isa0 > Nov 7 21:54:23 algol kernel: atrtc0: at port 0x70 irq 8 > on isa0 > Nov 7 21:54:23 algol kernel: Event timer "RTC" frequency 32768 Hz quality 0 > Nov 7 21:54:23 algol kernel: attimer0: at port 0x40 on isa0 > Nov 7 21:54:23 algol kernel: Timecounter "i8254" frequency 1193182 Hz > quality 0 > Nov 7 21:54:23 algol kernel: Event timer "i8254" frequency 1193182 Hz > quality 100 > Nov 7 21:54:23 algol kernel: uart0: <16550 or compatible> at port > 0x3f8-0x3ff irq 4 flags 0x10 on isa0 > Nov 7 21:54:23 algol kernel: uart0: console (57600,n,8,1) > Nov 7 21:54:23 algol kernel: uart1: <16550 or compatible> at port > 0x2f8-0x2ff irq 3 on isa0 > Nov 7 21:54:23 algol kernel: Timecounters tick every 1.000 msec > Nov 7 21:54:23 algol kernel: usbus0: 12Mbps Full Speed USB v1.0 > Nov 7 21:54:23 algol kernel: usbus1: 480Mbps High Speed USB v2.0 > Nov 7 21:54:23 algol kernel: ugen0.1: at usbus0 > Nov 7 21:54:23 algol kernel: uhub0: 1.00/1.00, addr 1> on usbus0 > Nov 7 21:54:23 algol kernel: ugen1.1: at usbus1 > Nov 7 21:54:23 algol kernel: uhub1: 2.00/1.00, addr 1> on usbus1 > Nov 7 21:54:23 algol kernel: ada0 at ata0 bus 0 scbus0 target 0 lun 0 > Nov 7 21:54:23 algol kernel: ada0: ATA-0 device > Nov 7 21:54:23 algol kernel: ada0: 100.000MB/s transfers (UDMA5, PIO > 512bytes) > Nov 7 21:54:23 algol kernel: ada0: 3831MB (7847280 512 byte sectors: 16H > 63S/T 7785C) > Nov 7 21:54:23 algol kernel: ada0: Previously was known as ad0 > Nov 7 21:54:23 algol kernel: Timecounter "TSC" frequency 498060911 Hz > quality 800 > Nov 7 21:54:23 algol kernel: Root mount waiting for: usbus1 usbus0 > Nov 7 21:54:23 algol kernel: uhub0: 4 ports with 4 removable, self powered > Nov 7 21:54:23 algol kernel: Root mount waiting for: usbus1 > Nov 7 21:54:23 algol kernel: uhub1: 4 ports with 4 removable, self powered > Nov 7 21:54:23 algol kernel: Trying to mount root from ufs:/dev/ada0s2a > [ro]... > Nov 7 21:54:23 algol kernel: bridge0: Ethernet address: 02:6e:c2:cf:62:00 > Nov 7 21:54:23 algol kernel: wlan0: Ethernet address: 00:0b:6b:b1:3a:e7 > Nov 7 21:54:25 algol root: /etc/rc: WARNING: failed precmd routine for > unbound > Nov 7 21:54:25 algol kernel: /etc/rc: WARNING: failed precmd routine for > unbound > Nov 7 21:54:26 algol ntpd[1183]: ntpd 4.2.4p5-a (1) > Nov 7 21:54:28 algol ftp-proxy[1268]: listening on 127.0.0.1 port 8021 > Nov 7 21:54:28 algol ntpd_initres[1187]: host name not found: > 0.nl.pool.ntp.org > Nov 7 21:54:28 algol ntpd_initres[1187]: host name not found: > 1.nl.pool.ntp.org > Nov 7 21:54:28 algol ntpd_initres[1187]: host name not found: > 2.nl.pool.ntp.org > Nov 7 21:54:28 algol ntpd_initres[1187]: host name not found: > 3.nl.pool.ntp.org > Nov 7 21:54:29 algol dhcpd: gigaset.home.lan: temporary name server failure > Nov 7 21:54:32 algol dhcpd: sven-iphone.home.lan: temporary name server > failure > Nov 7 21:54:46 algol su: sven to root on /dev/pts/0 > Nov 7 21:55:05 algol unbound: [1301:0] notice: init module 0: validator > Nov 7 21:55:05 algol unbound: [1301:0] notice: init module 1: iterator > Nov 7 21:55:37 algol ntpd[1184]: time reset -0.953825 s > Nov 7 21:59:21 algol su: sven to root on /dev/pts/0 > Nov 7 22:02:30 algol su: sven to root on /dev/pts/0 > Nov 7 22:31:50 algol dhcpd: uid lease 192.168.2.33 for client > 18:af:61:21:ae:28 is duplicate on 192.168.2.0/24 > Nov 7 22:31:51 algol dhcpd: uid lease 192.168.2.33 for client > 18:af:61:21:ae:28 is duplicate on 192.168.2.0/24 > Nov 7 22:44:15 algol kernel: ath0: ath_bar_response: huh? bar_tx=0, > bar_wait=0 > Nov 7 23:05:06 algol dhcpd: uid lease 192.168.2.33 for client > 18:af:61:21:ae:28 is duplicate on 192.168.2.0/24 > Nov 7 23:15:07 algol dhcpd: uid lease 192.168.2.33 for client > 18:af:61:21:ae:28 is duplicate on 192.168.2.0/24 > Nov 8 00:18:16 algol dhcpd: uid lease 192.168.2.33 for client > 18:af:61:21:ae:28 is duplicate on 192.168.2.0/24 > Nov 8 01:18:32 algol dhcpd: uid lease 192.168.2.33 for client > 18:af:61:21:ae:28 is duplicate on 192.168.2.0/24 > Nov 8 02:18:43 algol dhcpd: uid lease 192.168.2.33 for client > 18:af:61:21:ae:28 is duplicate on 192.168.2.0/24 > Nov 8 03:18:56 algol dhcpd: uid lease 192.168.2.33 for client > 18:af:61:21:ae:28 is duplicate on 192.168.2.0/24 > Nov 8 03:42:20 algol dhcpd: uid lease 192.168.2.33 for client > 18:af:61:21:ae:28 is duplicate on 192.168.2.0/24 > Nov 8 04:42:31 algol dhcpd: uid lease 192.168.2.33 for client > 18:af:61:21:ae:28 is duplicate on 192.168.2.0/24 > Nov 8 05:05:56 algol dhcpd: uid lease 192.168.2.33 for client > 18:af:61:21:ae:28 is duplicate on 192.168.2.0/24 > Nov 8 05:19:19 algol dhcpd: uid lease 192.168.2.33 for client > 18:af:61:21:ae:28 is duplicate on 192.168.2.0/24 > Nov 8 06:19:32 algol dhcpd: uid lease 192.168.2.33 for client > 18:af:61:21:ae:28 is duplicate on 192.168.2.0/24 > Nov 8 06:42:56 algol dhcpd: uid lease 192.168.2.33 for client > 18:af:61:21:ae:28 is duplicate on 192.168.2.0/24 > Nov 8 07:43:05 algol dhcpd: uid lease 192.168.2.33 for client > 18:af:61:21:ae:28 is duplicate on 192.168.2.0/24 > Nov 8 10:13:12 algol kernel: ath0: stuck beacon; resetting (bmiss count 4) > Nov 8 10:13:12 algol kernel: ar5416StopDmaReceive: dma failed to stop in > 10ms > Nov 8 10:13:12 algol kernel: AR_CR=0x00000024 > Nov 8 10:13:12 algol kernel: AR_DIAG_SW=0x42000020 > Nov 8 12:28:45 algol kernel: ath0: ath_tx_tid_drain_print: norm: node > 0xc3339000: bf=0xc254cd10: addbaw=0, dobaw=0, seqno=106, retry=0 > Nov 8 12:28:45 algol kernel: ath0: ath_tx_tid_drain_print: node 0xc3339000: > bf=0xc254cd10: txq[1] axq_depth=18, axq_aggr_depth=0 > Nov 8 12:28:45 algol kernel: ath0: ath_tx_tid_drain_print: node 0xc3339000: > bf=0xc254cd10: tid txq_depth=20 hwq_depth=18, bar_wait=0, isfiltered=0 > Nov 8 12:28:45 algol kernel: ath0: ath_tx_tid_drain_print: node 0xc3339000: > tid 0: sched=1, paused=0, incomp=0, baw_head=93, baw_tail=93 txa_start=3976, > ni_txseqs=4222 > Nov 8 12:28:45 algol kernel: FRDS > 02:6e:c2:cf:62:00->c4:85:08:56:df:74(00:0b:6b:b1:3a:e7) data QoS [TID 0] WEP > [IV 6d 40 00 00 00 00 KID 0] 0M > Nov 8 12:28:45 algol kernel: 8842 0000 c485 0856 df74 000b 6bb1 3ae7 026e > c2cf 6200 a006 0000 0000 6d40 0020 0000 0000 aaaa 0300 0000 0800 > Nov 8 15:58:37 algol kernel: ath0: stuck beacon; resetting (bmiss count 4) > Nov 8 15:58:37 algol kernel: ar5416StopDmaReceive: dma failed to stop in > 10ms > Nov 8 15:58:37 algol kernel: AR_CR=0x00000024 > Nov 8 15:58:37 algol kernel: AR_DIAG_SW=0x42000020 > Nov 8 15:58:37 algol kernel: stray irq7 > Nov 8 16:37:43 algol dhcpd: uid lease 192.168.2.33 for client > 18:af:61:21:ae:28 is duplicate on 192.168.2.0/24 > Nov 8 16:37:44 algol dhcpd: uid lease 192.168.2.33 for client > 18:af:61:21:ae:28 is duplicate on 192.168.2.0/24 > Nov 8 17:07:50 algol dhcpd: uid lease 192.168.2.33 for client > 18:af:61:21:ae:28 is duplicate on 192.168.2.0/24 > Nov 8 18:08:23 algol dhcpd: uid lease 192.168.2.33 for client > 18:af:61:21:ae:28 is duplicate on 192.168.2.0/24 > Nov 8 18:30:49 algol dhcpd: uid lease 192.168.2.33 for client > 18:af:61:21:ae:28 is duplicate on 192.168.2.0/24 > Nov 8 18:43:43 algol dhcpd: uid lease 192.168.2.33 for client > 18:af:61:21:ae:28 is duplicate on 192.168.2.0/24 > Nov 8 18:50:26 algol dhcpd: uid lease 192.168.2.33 for client > 18:af:61:21:ae:28 is duplicate on 192.168.2.0/24 > Nov 8 19:11:01 algol kernel: ath0: ath_bar_response: huh? bar_tx=0, > bar_wait=0 > Nov 8 19:21:09 algol dhcpd: uid lease 192.168.2.33 for client > 18:af:61:21:ae:28 is duplicate on 192.168.2.0/24 > Nov 8 20:27:23 algol dhcpd: uid lease 192.168.2.33 for client > 18:af:61:21:ae:28 is duplicate on 192.168.2.0/24 > Nov 8 20:27:40 algol last message repeated 4 times > Nov 8 21:08:53 algol dhcpd: uid lease 192.168.2.33 for client > 18:af:61:21:ae:28 is duplicate on 192.168.2.0/24 > Nov 8 21:19:01 algol last message repeated 2 times > Nov 8 21:29:01 algol last message repeated 8 times > Nov 8 21:38:59 algol last message repeated 19 times > Nov 8 21:48:56 algol last message repeated 19 times > Nov 8 21:52:19 algol last message repeated 4 times > Nov 8 22:22:19 algol dhcpd: uid lease 192.168.2.33 for client > 18:af:61:21:ae:28 is duplicate on 192.168.2.0/24 > Nov 8 22:35:29 algol dhcpd: uid lease 192.168.2.33 for client > 18:af:61:21:ae:28 is duplicate on 192.168.2.0/24 > Nov 8 22:42:12 algol dhcpd: uid lease 192.168.2.33 for client > 18:af:61:21:ae:28 is duplicate on 192.168.2.0/24 > Nov 8 22:48:55 algol last message repeated 2 times > Nov 8 23:49:17 algol dhcpd: uid lease 192.168.2.33 for client > 18:af:61:21:ae:28 is duplicate on 192.168.2.0/24 > Nov 9 00:12:46 algol dhcpd: uid lease 192.168.2.33 for client > 18:af:61:21:ae:28 is duplicate on 192.168.2.0/24 > Nov 9 00:23:20 algol dhcpd: uid lease 192.168.2.33 for client > 18:af:61:21:ae:28 is duplicate on 192.168.2.0/24 > Nov 9 00:36:15 algol dhcpd: uid lease 192.168.2.33 for client > 18:af:61:21:ae:28 is duplicate on 192.168.2.0/24 > Nov 9 00:46:21 algol last message repeated 2 times > Nov 9 00:56:25 algol last message repeated 18 times > Nov 9 00:56:29 algol last message repeated 2 times > Nov 9 00:59:47 algol dhcpd: uid lease 192.168.2.33 for client > 18:af:61:21:ae:28 is duplicate on 192.168.2.0/24 > Nov 9 01:00:12 algol last message repeated 5 times > Nov 9 01:03:07 algol dhcpd: uid lease 192.168.2.33 for client > 18:af:61:21:ae:28 is duplicate on 192.168.2.0/24 > Nov 9 01:13:11 algol last message repeated 10 times > Nov 9 01:23:14 algol last message repeated 26 times > Nov 9 01:33:19 algol last message repeated 13 times > Nov 9 01:43:23 algol last message repeated 17 times > Nov 9 01:53:27 algol last message repeated 15 times > Nov 9 02:03:29 algol last message repeated 13 times > Nov 9 02:10:16 algol last message repeated 11 times > Nov 9 02:21:40 algol last message repeated 18 times > Nov 9 02:30:27 algol last message repeated 13 times > Nov 9 02:40:49 algol last message repeated 13 times > Nov 9 02:50:29 algol last message repeated 11 times > Nov 9 03:00:56 algol last message repeated 12 times > Nov 9 03:07:32 algol last message repeated 10 times > Nov 9 03:58:05 algol dhcpd: uid lease 192.168.2.33 for client > 18:af:61:21:ae:28 is duplicate on 192.168.2.0/24 > Nov 9 04:08:09 algol last message repeated 3 times > Nov 9 04:18:14 algol last message repeated 13 times > Nov 9 04:28:19 algol last message repeated 24 times > Nov 9 04:38:22 algol last message repeated 20 times > Nov 9 04:48:26 algol last message repeated 11 times > Nov 9 04:48:34 algol last message repeated 4 times > Nov 9 05:19:05 algol dhcpd: uid lease 192.168.2.33 for client > 18:af:61:21:ae:28 is duplicate on 192.168.2.0/24 > Nov 9 05:32:31 algol dhcpd: uid lease 192.168.2.33 for client > 18:af:61:21:ae:28 is duplicate on 192.168.2.0/24 > Nov 9 05:39:14 algol dhcpd: uid lease 192.168.2.33 for client > 18:af:61:21:ae:28 is duplicate on 192.168.2.0/24 > Nov 9 05:52:33 algol last message repeated 29 times > Nov 9 06:02:29 algol last message repeated 13 times > Nov 9 06:12:28 algol last message repeated 12 times > Nov 9 06:19:09 algol last message repeated 6 times > Nov 9 06:20:06 algol kernel: ath0: stuck beacon; resetting (bmiss count 4) > Nov 9 06:22:29 algol dhcpd: uid lease 192.168.2.33 for client > 18:af:61:21:ae:28 is duplicate on 192.168.2.0/24 > Nov 9 06:22:33 algol last message repeated 2 times > Nov 9 06:25:48 algol dhcpd: uid lease 192.168.2.33 for client > 18:af:61:21:ae:28 is duplicate on 192.168.2.0/24 > Nov 9 06:25:53 algol last message repeated 2 times > Nov 9 06:26:43 algol kernel: ath0: stuck beacon; resetting (bmiss count 4) > Nov 9 06:28:06 algol kernel: ath0: stuck beacon; resetting (bmiss count 4) > Nov 9 06:29:10 algol dhcpd: uid lease 192.168.2.33 for client > 18:af:61:21:ae:28 is duplicate on 192.168.2.0/24 > Nov 9 06:29:19 algol last message repeated 3 times > Nov 9 06:31:16 algol kernel: ath0: stuck beacon; resetting (bmiss count 4) > Nov 9 06:32:32 algol dhcpd: uid lease 192.168.2.33 for client > 18:af:61:21:ae:28 is duplicate on 192.168.2.0/24 > Nov 9 06:32:36 algol last message repeated 2 times > Nov 9 06:34:00 algol kernel: ath0: stuck beacon; resetting (bmiss count 4) > Nov 9 06:35:55 algol dhcpd: uid lease 192.168.2.33 for client > 18:af:61:21:ae:28 is duplicate on 192.168.2.0/24 > Nov 9 06:35:59 algol last message repeated 2 times > Nov 9 06:39:09 algol kernel: ath0: stuck beacon; resetting (bmiss count 4) > Nov 9 06:39:15 algol dhcpd: uid lease 192.168.2.33 for client > 18:af:61:21:ae:28 is duplicate on 192.168.2.0/24 > Nov 9 06:39:18 algol dhcpd: uid lease 192.168.2.33 for client > 18:af:61:21:ae:28 is duplicate on 192.168.2.0/24 > Nov 9 06:42:37 algol dhcpd: uid lease 192.168.2.33 for client > 18:af:61:21:ae:28 is duplicate on 192.168.2.0/24 > Nov 9 06:42:41 algol last message repeated 2 times > Nov 9 06:42:41 algol kernel: ath0: stuck beacon; resetting (bmiss count 4) > Nov 9 06:42:46 algol dhcpd: uid lease 192.168.2.33 for client > 18:af:61:21:ae:28 is duplicate on 192.168.2.0/24 > Nov 9 06:43:02 algol last message repeated 2 times > Nov 9 06:45:57 algol dhcpd: uid lease 192.168.2.33 for client > 18:af:61:21:ae:28 is duplicate on 192.168.2.0/24 > Nov 9 06:46:02 algol last message repeated 4 times > Nov 9 06:46:38 algol kernel: ath0: stuck beacon; resetting (bmiss count 4) > Nov 9 06:48:54 algol kernel: ath0: stuck beacon; resetting (bmiss count 4) > Nov 9 06:49:20 algol dhcpd: uid lease 192.168.2.33 for client > 18:af:61:21:ae:28 is duplicate on 192.168.2.0/24 > Nov 9 06:49:28 algol last message repeated 3 times > Nov 9 06:50:32 algol kernel: ath0: stuck beacon; resetting (bmiss count 4) > Nov 9 06:52:39 algol dhcpd: uid lease 192.168.2.33 for client > 18:af:61:21:ae:28 is duplicate on 192.168.2.0/24 > Nov 9 06:52:43 algol last message repeated 2 times > Nov 9 06:56:03 algol dhcpd: uid lease 192.168.2.33 for client > 18:af:61:21:ae:28 is duplicate on 192.168.2.0/24 > Nov 9 07:03:10 algol last message repeated 11 times > Nov 9 07:11:49 algol last message repeated 15 times > Nov 9 07:14:04 algol kernel: ath0: stuck beacon; resetting (bmiss count 4) > Nov 9 07:14:34 algol kernel: ath0: stuck beacon; resetting (bmiss count 4) > Nov 9 07:14:52 algol dhcpd: uid lease 192.168.2.33 for client > 18:af:61:21:ae:28 is duplicate on 192.168.2.0/24 > Nov 9 07:15:19 algol last message repeated 5 times > Nov 9 07:17:28 algol last message repeated 9 times > Nov 9 07:23:40 algol last message repeated 35 times > Nov 9 07:25:25 algol kernel: ath0: stuck beacon; resetting (bmiss count 4) > Nov 9 07:26:58 algol dhcpd: uid lease 192.168.2.33 for client > 18:af:61:21:ae:28 is duplicate on 192.168.2.0/24 > Nov 9 07:26:59 algol dhcpd: uid lease 192.168.2.33 for client > 18:af:61:21:ae:28 is duplicate on 192.168.2.0/24 > Nov 9 07:34:28 algol kernel: ath0: stuck beacon; resetting (bmiss count 4) > Nov 9 07:47:28 algol kernel: ath0: stuck beacon; resetting (bmiss count 4) > Nov 9 07:50:32 algol kernel: ath0: stuck beacon; resetting (bmiss count 4) > Nov 9 07:57:36 algol last message repeated 2 times > Nov 9 07:58:24 algol dhcpd: uid lease 192.168.2.33 for client > 18:af:61:21:ae:28 is duplicate on 192.168.2.0/24 > Nov 9 08:00:11 algol su: sven to root on /dev/pts/0 > Nov 9 08:00:26 algol kernel: ar5416PerCalibrationN: NF calibration didn't > finish; delaying CCA > Nov 9 08:00:26 algol dhcpd: uid lease 192.168.2.33 for client > 18:af:61:21:ae:28 is duplicate on 192.168.2.0/24 > Nov 9 08:00:35 algol last message repeated 3 times > Nov 9 08:01:16 algol kernel: ath0: stuck beacon; resetting (bmiss count 4) > Nov 9 08:02:51 algol kernel: ath0: stuck beacon; resetting (bmiss count 4) > > > On 4 November 2013 16:25, Adrian Chadd wrote: >> >> So, May is ok, october isn't? >> >> can you switch back and verify? >> >> Those are data dumps of frames that are being freed out of the >> software staging queue when the wireless node associated has gone away >> (or is being "flushed.") The "bf_next not NULL!" is a worry. > > > From owner-freebsd-wireless@FreeBSD.ORG Sat Nov 9 10:01:35 2013 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 79AAF1D7 for ; Sat, 9 Nov 2013 10:01:35 +0000 (UTC) (envelope-from sven@hazejager.nl) Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 40F5724E9 for ; Sat, 9 Nov 2013 10:01:35 +0000 (UTC) Received: by mail-oa0-f44.google.com with SMTP id i7so3553241oag.3 for ; Sat, 09 Nov 2013 02:01:34 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Nov/V88RrVDsSD1iJryrDjM59dPNAM8T0usFeeRUz0A=; b=YfyiMVVzOmXTlIPm8Fi0nwXjKHbHdtGAZA+1b9zIKI8CLFYPpNO4ifMOp2alCp62IO I4xUK+2SrxXBMbgeMTCmTgGzE71mz3DK0CIMA/5gg2E2kff1xD747N+P5HjfQy0fTmji C6xiyg8LXeD4FggvUoPzjaMew04aABNPe3bxLcE7ZXCMM9YR3ISghpQHvB4dXVYhKSqX UD/DsvCgYdn3Y23YQ0oGxoBWIvCuez9Kh8F0qJWQhmS1Qo1mlMZwZiH/xUPoS4sxKofs TfLz5AXaMdXbvMJJE64VhFPXcHb8tquyrUIxzLPkdttB+D5WOP6ZvWxEDzPj+OTkMeL0 YkKw== X-Gm-Message-State: ALoCoQkqJVTcoX8LDhmOKwfEpmHai+myWH4BSTTVEnBEN+DaNgTAxhtu2TqTfnJnnE9R8hNY9XsC MIME-Version: 1.0 X-Received: by 10.60.117.225 with SMTP id kh1mr15291379oeb.15.1383991294273; Sat, 09 Nov 2013 02:01:34 -0800 (PST) Received: by 10.182.18.9 with HTTP; Sat, 9 Nov 2013 02:01:34 -0800 (PST) X-Originating-IP: [212.123.177.47] In-Reply-To: References: Date: Sat, 9 Nov 2013 11:01:34 +0100 Message-ID: Subject: Re: AR9160 on HEAD - unstable? From: Sven Hazejager To: Adrian Chadd Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 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: Sat, 09 Nov 2013 10:01:35 -0000 OK will ignore the stuck beacon stuff :-). Warm reboot is indeed typing "reboot". That did not resolve this morning's matter. Actually, after I unplugged the ALIX for a couple of seconds, it came back up... same problem! Second time, I unplugged it for 30 seconds... problem solved...! Hardware issue with my AR9160? I've never had it this bad before. I did compile in your debug stuff + ath tools: what should I do next time this happens to get more information? On 9 November 2013 08:49, Adrian Chadd wrote: > the stuck beacon stuff is likely just the MAC getting angry at the > power save aggressiveness that the iphone/ipad does. But it itself > shouldn't lock things up. > > When you say you did a warm reboot, is that a 'reboot' where you typed > reboot? is there a physical reset button on the ALIX you can short? > From owner-freebsd-wireless@FreeBSD.ORG Sat Nov 9 10:11:24 2013 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id CB302248 for ; Sat, 9 Nov 2013 10:11:24 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-qa0-x22c.google.com (mail-qa0-x22c.google.com [IPv6:2607:f8b0:400d:c00::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 8B45D253C for ; Sat, 9 Nov 2013 10:11:24 +0000 (UTC) Received: by mail-qa0-f44.google.com with SMTP id f11so401528qae.17 for ; Sat, 09 Nov 2013 02:11:23 -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:message-id:subject :from:to:cc:content-type; bh=VRUjoyd2gSBAgXgMWju47Ulrt1qQ/TMGm9wUeO0KD60=; b=hk3HGjRs0eEHq0MqE08z93clav73cAhxklkajUwOs8kw2Lo5SwaV0zEH9kb3SLGTAZ l2F+0SHR134GTcJXku71oloU4HGMUpJ5lBHAzO+anqB1xJE0jMU2hIdcpRUo+8H4c75W D7gJvkEfzOYmEFpasgHRiW3cgJZm48CAKX2rNqGrat8+LC7idkOoZ4fccfnQZOReqehp 9V6oXeOyZdsT2bFs+c8yzNAKugbHsitp9G0534OYeklVKELow/kuKWaw9Jv1Zww2VbjY 7YQTpnqOsQnF+p9OS9rW4sMAdWN2MMEaLp3cWFf3qxpj9fXd7OodZMnF5BOPMZNN06lo Qrtg== MIME-Version: 1.0 X-Received: by 10.224.36.201 with SMTP id u9mr30977162qad.76.1383991883817; Sat, 09 Nov 2013 02:11:23 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.224.207.66 with HTTP; Sat, 9 Nov 2013 02:11:23 -0800 (PST) In-Reply-To: References: Date: Sat, 9 Nov 2013 02:11:23 -0800 X-Google-Sender-Auth: e0j7ZR68R2X-hK7OGgnsnhIVi3Y Message-ID: Subject: Re: AR9160 on HEAD - unstable? From: Adrian Chadd To: Sven Hazejager 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: Sat, 09 Nov 2013 10:11:24 -0000 Hi! Well, I'd start by checking to see what is being transmitted and received. * is it transmitting beacons? * is it transmitting anything data-like? eg, is it transmitting broadcast/multicast frames? * can it receive frames? You can use athstats to see what's going on. wlandebug -i ath(0,1,2..) +rate is a cheap way to see if its transmitting data frames reliably. -adrian On 9 November 2013 02:01, Sven Hazejager wrote: > OK will ignore the stuck beacon stuff :-). Warm reboot is indeed typing > "reboot". That did not resolve this morning's matter. Actually, after I > unplugged the ALIX for a couple of seconds, it came back up... same problem! > Second time, I unplugged it for 30 seconds... problem solved...! Hardware > issue with my AR9160? I've never had it this bad before. > > I did compile in your debug stuff + ath tools: what should I do next time > this happens to get more information? > > On 9 November 2013 08:49, Adrian Chadd wrote: >> >> the stuck beacon stuff is likely just the MAC getting angry at the >> power save aggressiveness that the iphone/ipad does. But it itself >> shouldn't lock things up. >> >> When you say you did a warm reboot, is that a 'reboot' where you typed >> reboot? is there a physical reset button on the ALIX you can short? > > > From owner-freebsd-wireless@FreeBSD.ORG Sat Nov 9 17:40:34 2013 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id C1923E8C for ; Sat, 9 Nov 2013 17:40:34 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-qc0-x22e.google.com (mail-qc0-x22e.google.com [IPv6:2607:f8b0:400d:c01::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 84F732A6A for ; Sat, 9 Nov 2013 17:40:34 +0000 (UTC) Received: by mail-qc0-f174.google.com with SMTP id s13so277257qcv.5 for ; Sat, 09 Nov 2013 09:40:33 -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:message-id:subject :from:to:content-type; bh=GBrXu2mV0WKpChN0C+DqSUttN1Pngr2/fx6JoVVTz0g=; b=mBBvA9n3T1XkuqYIlnbdac5SjEMQ6Vrl2I5kXpI9QzFJPp3f4e6FBFWV+a8TuTuqf3 MSdcFJZb0zbd+IaPyX775eE+j2j+OHa/AZtqrjTqyrIyU+wPMDz+Avz8uDHOwRcgATc7 lTYC8VpVwyC/ZY0mjqLlcMNPRF9iDVwS6ah7aap7EhyGie3uFdQSoKsZOXVIJj4bVrVw Qv4CCEnV//+27P0sfNyNKI76WUNeLFeN7uZ8LDrDDjzhqrBk9Niu4MSaQt6zA4DMgveW lzYrVlFv4iZnN1fqMIcKT17+IyX9iVBRcJcsBy4Hp+jE7q2dGqaQs22aS8+jdEmS3Jyx eJ3Q== MIME-Version: 1.0 X-Received: by 10.224.64.200 with SMTP id f8mr34438211qai.55.1384018833179; Sat, 09 Nov 2013 09:40:33 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.224.207.66 with HTTP; Sat, 9 Nov 2013 09:40:33 -0800 (PST) In-Reply-To: References: Date: Sat, 9 Nov 2013 09:40:33 -0800 X-Google-Sender-Auth: s7gMTWa2lBxplPa96OXZ_46LfkI Message-ID: Subject: Re: [iwn] round four - 5100 works, 21xx works, EAPOL fixes, rate selection fixes 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, 09 Nov 2013 17:40:34 -0000 followup: * 6205 works * 6230 works * 6200 works * 2230 works * 1030 works * 5100 works What i haven't yet tested: * 4965, mostly because I'm scared to * Whichever NIC Eitan has, as he has it and I don't (2200?) * (and obviously whatever other NICs exist that I don't have) What doesn't work: * Centrino 100 - EEPROM read failure, then kernel hang * 6150, 6235, 6250 - all have a variant on firmware panic or failed calibration upload. So, the 6xxx NICs that don't work should be easy to solve - they should already have (somewhat) worked with -HEAD. The Centrino 100 is a bit more of a special case. If you have any of the above NICs that work or that I haven't yet tested, I'd really appreciate it if you could spin up the latest diff with the latest net80211 code. It should behave quite a bit better. Thanks! -adrian On 8 November 2013 23:46, Adrian Chadd wrote: > Argh, why am I still hacking on the iwn(4) driver. > > So, I saw a lot of broken stuff. This patch fixes some. > > http://people.freebsd.org/~adrian/iwn/20131108-iwn-update-works-full-5100-11.diff > > You have to update sys/net80211 and sys/dev/iwn to the latest version > in HEAD before you apply this diff. > > What's committed: > > * AMRR wasn't correctly initializing the initial rate, so it thought > it was starting at MCS15 but it was in fact starting at MCS0. This > caused hilarity. > > * AMRR should be selecting a "mostly ok" rate, not MCS15. So, this was > also fixed. > > What's in this patch: > > * EAPOL frames were going out at the normal data rate, rather than > going out at the management rate. Like ath(4), override this. Once I > fixed AMRR to set the initial rate from MCS0 to the "best initial > rate" it chose MCS15 and this failed. It showed up as the initial > association suceeding but the auth exchange failed, logging a > "pre-shared key may be incorrect" message. Sigh. So, like ath(4), > detect if it's EAPOL and if so override. > > * If an AMPDU frame TX failed the firmware doesn't send up a > compressed-BA notification as it doesn't receive one. > iwn_ampdu_tx_done() doesn't do any rate control notification - that is > left up to the compressed BA RX function. So, if an entire A-MPDU > transmit failed, there'd be no notification of such - and the rate > control code never got notified of said failures! Thus it would never > back off the rate. So, if the whole frame transmission failed, just > notify the rate control code so it correctly backs off the rate > selection. > > With this, things are .. more stable. The whole A-MPDU handling needs > a lot of work to make as correct as the ath(4) driver, but that is so > not in the scope of what I'm doing here. > > > > -adrian From owner-freebsd-wireless@FreeBSD.ORG Sat Nov 9 19:11:48 2013 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 2FDBBEFC for ; Sat, 9 Nov 2013 19:11:48 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-qa0-x233.google.com (mail-qa0-x233.google.com [IPv6:2607:f8b0:400d:c00::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E47E92E42 for ; Sat, 9 Nov 2013 19:11:47 +0000 (UTC) Received: by mail-qa0-f51.google.com with SMTP id hu16so664091qab.10 for ; Sat, 09 Nov 2013 11:11:47 -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:message-id:subject :from:to:content-type; bh=JG9Khf64uJ5Kz5HQPHYTEQsZsbLxbKRpYqvy+jqq44Y=; b=tEtPohQA1RBVKbylB00GgkfQGoVYNuGqr3Y2PwT6OKTXWXPQn3akCthOejGSKoOkGy LMrgEAtxwNuriwz87DW8sAxhRu0Y0OBVgXgTgHby2kQA0Eybc8eG0OF1MgFhqc1KUQTk b5Z9T3TmKPP6uNvI5MlOHfqiLWUHTINi/ijuPQjmBaZZXX5N6Nlg1pn9X1UXyNrqghNy IXJiv0etDzycUgYaY4kzMzPpcqXe0mH3WprQ9NQw+SFvjvr+TB56nCboMaDw+kPDXd2p n6KTA7cb1ne8eJLSX4owozj4yPUVxWsPnhgf67mLm3sZXo1bE8zBHEAHNBd/AriMe1Fe SRyA== MIME-Version: 1.0 X-Received: by 10.229.106.131 with SMTP id x3mr33129009qco.1.1384024307113; Sat, 09 Nov 2013 11:11:47 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.224.207.66 with HTTP; Sat, 9 Nov 2013 11:11:47 -0800 (PST) In-Reply-To: References: Date: Sat, 9 Nov 2013 11:11:47 -0800 X-Google-Sender-Auth: rE4N6xyeaR4e2p0UWeoeNHgcz8U Message-ID: Subject: Re: [iwn] round four - 5100 works, 21xx works, EAPOL fixes, rate selection fixes 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, 09 Nov 2013 19:11:48 -0000 Hm! On 9 November 2013 09:40, Adrian Chadd wrote: > What doesn't work: > > * Centrino 100 - EEPROM read failure, then kernel hang > * 6150, 6235, 6250 - all have a variant on firmware panic or failed > calibration upload. > > So, the 6xxx NICs that don't work should be easy to solve - they > should already have (somewhat) worked with -HEAD. http://people.freebsd.org/~adrian/iwn/20131109-iwn-works-full-5100-14.diff I got the 6250 to work - Cedric's patch enabled the wrong calibrations for the 6050 NIC series. The whole chip configuration setup needs closer auditing.. -adrian