From owner-freebsd-mobile@FreeBSD.ORG Sun Feb 15 17:40:35 2009 Return-Path: Delivered-To: freebsd-mobile@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4B7FF106566C for ; Sun, 15 Feb 2009 17:40:35 +0000 (UTC) (envelope-from webmaster@kibab.com) Received: from mx0.deglitch.com (backbone.deglitch.com [IPv6:2001:16d8:fffb:4::abba]) by mx1.freebsd.org (Postfix) with ESMTP id E5FA58FC16 for ; Sun, 15 Feb 2009 17:40:34 +0000 (UTC) (envelope-from webmaster@kibab.com) Received: from kibab-nb.kibab.com (ppp85-140-151-28.pppoe.mtu-net.ru [85.140.151.28]) by mx0.deglitch.com (Postfix) with ESMTPA id BD0828FC1D for ; Sun, 15 Feb 2009 20:40:32 +0300 (MSK) Date: Sun, 15 Feb 2009 20:40:25 +0300 From: Ilya Bakulin To: freebsd-mobile@freebsd.org Message-Id: <20090215204025.51c16438.webmaster@kibab.com> In-Reply-To: <4995EDCC.1090207@twilley.org> References: <1233145383.00067348.1233133205@10.7.7.3> <1233231789.00067817.1233220802@10.7.7.3> <1233761002.00070820.1233750002@10.7.7.3> <1233761005.00070824.1233750602@10.7.7.3> <1234419790.00074006.1234407602@10.7.7.3> <4993CF8B.2030103@mavhome.dp.ua> <4993D01F.5070507@mavhome.dp.ua> <4995EDCC.1090207@twilley.org> Organization: Deglitch Networks X-Mailer: Sylpheed 2.6.0 (GTK+ 2.14.7; i386-portbld-freebsd7.1) Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="PGP-SHA1"; boundary="Signature=_Sun__15_Feb_2009_20_40_25_+0300_sKWxLnBtPbIUDZs=" Subject: Re: Tethering with HTC Touch Pro -- how? X-BeenThere: freebsd-mobile@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile computing with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Feb 2009 17:40:35 -0000 --Signature=_Sun__15_Feb_2009_20_40_25_+0300_sKWxLnBtPbIUDZs= Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, 13 Feb 2009 14:01:48 -0800 Jack Twilley wrote: > Your script was great. I was able to get a connection, and DHCP=20 > configured the interface. I was able to ping hosts on the Internet and=20 > resolve names, but I couldn't ssh to my colo box nor was I able to=20 > browse the web or chat via IM. Still some work to be done but I can't=20 > blame FreeBSD. :-) You may try to use built-in Internet sharing on PDA. Alternatively, look at ICSControl application (freeware), you may find it h= ere: http://forum.xda-developers.com/showthread.php?t=3D377047 Using this utility you may turn on NAT in device. After that you should acc= ess Internet without problems. Tested it myself, works great. --=20 Ilya Bakulin xmpp://kibab612@jabber.ru --Signature=_Sun__15_Feb_2009_20_40_25_+0300_sKWxLnBtPbIUDZs= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAkmYU5IACgkQo9vlj1oadwiGAwCeN+sQ1bzARrC0CnJbrtdRkaHH 1lUAn16sf2ULGVvdWwuVjkMThmo47IV5 =9LjW -----END PGP SIGNATURE----- --Signature=_Sun__15_Feb_2009_20_40_25_+0300_sKWxLnBtPbIUDZs=-- From owner-freebsd-mobile@FreeBSD.ORG Tue Feb 17 19:28:05 2009 Return-Path: Delivered-To: freebsd-mobile@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 36F2C106566C; Tue, 17 Feb 2009 19:28:05 +0000 (UTC) (envelope-from bengta@P142.sics.se) Received: from sink.sics.se (sink.sics.se [193.10.64.88]) by mx1.freebsd.org (Postfix) with ESMTP id F0B598FC15; Tue, 17 Feb 2009 19:28:03 +0000 (UTC) (envelope-from bengta@P142.sics.se) Received: from P142.sics.se (P142.sics.se [193.10.66.253]) by sink.sics.se (8.14.3/8.14.3) with ESMTP id n1HJRstx028684 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 17 Feb 2009 20:27:55 +0100 (CET) (envelope-from bengta@P142.sics.se) Received: from P142.sics.se (localhost [127.0.0.1]) by P142.sics.se (8.14.3/8.14.3) with ESMTP id n1HJTwsu001678; Tue, 17 Feb 2009 20:29:58 +0100 (CET) (envelope-from bengta@P142.sics.se) Received: (from bengta@localhost) by P142.sics.se (8.14.3/8.14.3/Submit) id n1HJTvrU001677; Tue, 17 Feb 2009 20:29:57 +0100 (CET) (envelope-from bengta@P142.sics.se) To: Sam Leffler From: Bengt Ahlgren In-Reply-To: <4991DB1F.7060809@freebsd.org> (Sam Leffler's message of "Tue\, 10 Feb 2009 11\:53\:03 -0800") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (berkeley-unix) References: <20090210154047.N38905@sola.nimnet.asn.au> <4991ABA0.4050300@freebsd.org> <4991DB1F.7060809@freebsd.org> Date: Tue, 17 Feb 2009 20:29:57 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: freebsd-mobile@freebsd.org Subject: Re: Problems with ath at kern.hz=100 X-BeenThere: freebsd-mobile@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile computing with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2009 19:28:05 -0000 Sam Leffler writes: [...] > You've removed all the context of the original problem; I can't recall > what you were trying to fix. The ps q drops might be caused by a bug > that was fixed (I think in RELENG_7). I don't see what version of > code you're running so can't tell. Sorry, a summary of the problem: The system frequently comes into a state where outgoing packets are held somewhere. The condition persists for seconds to minutes. It goes away by itself, but some of the packets are usually lost. This occurs on ath, FreeBSD 7.1-REL, no SMP, with kern.hz=100 (but not with hz=1000). Original mail with description can be found here: http://lists.freebsd.org/pipermail/freebsd-mobile/2009-February/011343.html I have done some more investigation, inserting debug prints in ath_start (if_ath.c 1.177.2.2.2.1), one just after IFQ_DRV_DEQUEUE (line 1576), another just before the call to ieee80211_pwrsave (line 1614). Packets are dequeued, but ieee80211_pwrsave is called and nothing happens. Below is the output from "athdebug xmit" with these extra two DPRINTF:s during the queue-up. Then after a while packets are sent again. Bengt ath_start: dequeue packet 0x0 ath_start: dequeue packet 0x0 ath_start: dequeue packet 0x0 ath_start: dequeue packet 0xc37d3000 ath_start: power save, packet=0xc37d3000 ath_start: dequeue packet 0x0 ath_start: dequeue packet 0xc37d4800 ath_start: power save, packet=0xc37d4800 ath_start: dequeue packet 0x0 ath_start: dequeue packet 0xc37d4600 ath_start: power save, packet=0xc37d4600 ath_start: dequeue packet 0x0 ath_start: dequeue packet 0xc37d6c00 ath_start: power save, packet=0xc37d6c00 ath_start: dequeue packet 0x0 ath_start: dequeue packet 0xc37db000 ath_start: power save, packet=0xc37db000 ath_start: dequeue packet 0x0 ath_start: dequeue packet 0xc37d9e00 ath_start: power save, packet=0xc37d9e00 ath_start: dequeue packet 0x0 ath_start: dequeue packet 0xc37d5800 ath_start: power save, packet=0xc37d5800 ath_start: dequeue packet 0x0 ath_start: dequeue packet 0xc37da800 ath_start: power save, packet=0xc37da800 ath_start: dequeue packet 0x0 ath_start: dequeue packet 0xc37da100 ath_start: power save, packet=0xc37da100 ath_start: dequeue packet 0x0 ath_start: dequeue packet 0xc37dab00 ath_start: power save, packet=0xc37dab00 ath_start: dequeue packet 0x0 ath_start: dequeue packet 0xc38ef900 ath_start: power save, packet=0xc38ef900 ath_start: dequeue packet 0x0 ath_start: dequeue packet 0xc37d4d00 ath_start: power save, packet=0xc37d4d00 ath_start: dequeue packet 0x0 ath_start: dequeue packet 0xc37d9b00 ath_start: power save, packet=0xc37d9b00 ath_start: dequeue packet 0x0 ath_start: dequeue packet 0xc37d9500 ath_start: power save, packet=0xc37d9500 ath_start: dequeue packet 0x0 ath_tx_dmasetup: m 0xc37d3500 len 42 NODS 00:05:4e:4e:1f:c7->ff:ff:ff:ff:ff:ff(ff:ff:ff:ff:ff:ff) probe_req 1M 4000 0000 ffff ffff ffff 0005 4e4e 1fc7 ffff ffff ffff 9001 0000 0108 8284 8b96 0c12 1824 3204 3048 606c ath_tx_handoff: 0: 00000000 014cd5b0 6122002e 0100802a 00040000 0000001b ath_tx_handoff: TXDP[1] = 0x1d3df500 (0xdecdc500) depth 1 ath_starath_start: dequeue packet 0x0 t: dequeue packet 0x0 ath_tx_dmasetup: m 0xc37d9400 len 46 NODS 00:05:4e:4e:1f:c7->ff:ff:ff:ff:ff:ff(ff:ff:ff:ff:ff:ff) probe_req 1M 4000 0000 ffff ffff ffff 0005 4e4e 1fc7 ffff ffff ffff a001 0004 5349 4353 0108 8284 8b96 0c12 1824 3204 3048 606c ath_tx_handoff: 0: 00000000 014d34b0 61220032 0100802e 00040000 0000001b ath_tx_handoff: link[1](0xdecdc500)=0x1d3df8c0 (0xdecdc8c0) depth 2 ath_start: dequeue packet 0x0 ath_start: dequeue packet 0x0 ath_start: dequeue packet 0x0 ath_start: dequeue packet 0xc37d9600 ath_start: power save, packet=0xc37d9600 ath_start: dequeue packet 0x0 ath_start: dequeue packet 0xc37d7d00 ath_start: power save, packet=0xc37d7d00 ath_start: dequeue packet 0x0 ath_start: dequeue packet 0xc37d9100 ath_start: power save, packet=0xc37d9100 ath_start: dequeue packet 0x0 ath_start: dequeue packet 0xc38a1500 ath_start: power save, packet=0xc38a1500 ath_start: dequeue packet 0x0 ath_start: dequeue packet 0xc37d6800 ath_start: power save, packet=0xc37d6800 ath_start: dequeue packet 0x0 ath_start: dequeue packet 0xc37d8800 ath_start: power save, packet=0xc37d8800 ath_start: dequeue packet 0x0 ath_start: dequeue packet 0xc37d5a00 ath_start: power save, packet=0xc37d5a00 ath_start: dequeue packet 0x0 ath_start: dequeue packet 0xc37d4400 ath_start: power save, packet=0xc37d4400 ath_start: dequeue packet 0x0 ath_start: dequeue packet 0xc37da400 ath_start: power save, packet=0xc37da400 ath_start: dequeue packet 0x0 ath_start: dequeue packet 0xc37d5d00 ath_start: power save, packet=0xc37d5d00 ath_start: dequeue packet 0x0 ath_start: dequeue packet 0xc37d7000 ath_start: power save, packet=0xc37d7000 ath_start: dequeue packet 0x0 ath_start: dequeue packet 0xc37db400 ath_start: power save, packet=0xc37db400 ath_start: dequeue packet 0x0 ath_start: dequeue packet 0xc37d6400 ath_start: power save, packet=0xc37d6400 ath_start: dequeue packet 0x0 ath_start: dequeue packet 0xc37d6700 ath_start: power save, packet=0xc37d6700 ath_start: dequeue packet 0x0 ath_start: dequeue packet 0xc37d5700 ath_start: power save, packet=0xc37d5700 ath_start: dequeue packet 0x0 ath_start: dequeue packet 0xc37d8100 ath_start: power save, packet=0xc37d8100 ath_start: dequeue packet 0x0 ath_start: dequeue packet 0xc37d8d00 ath_start: power save, packet=0xc37d8d00 ath_start: dequeue packet 0x0 ath_start: dequeue packet 0xc37d4a00 ath_start: power save, packet=0xc37d4a00 ath_start: dequeue packet 0x0 ath_start: dequeue packet 0xc37d8a00 ath_start: power save, packet=0xc37d8a00 ath_start: dequeue packet 0x0 ath_start: dequeue packet 0xc37d9400 ath_start: power save, packet=0xc37d9400 ath_start: dequeue packet 0x0 ath_start: dequeue packet 0xc37d8400 ath_start: power save, packet=0xc37d8400 ath_start: dequeue packet 0x0 ath_start: dequeue packet 0xc37d3400 ath_start: power save, packet=0xc37d3400 ath_start: dequeue packet 0x0 ath_start: dequeue packet 0xc37d4500 ath_start: power save, packet=0xc37d4500 ath_start: dequeue packet 0x0 ath_start: dequeue packet 0xc37d7400 ath_start: power save, packet=0xc37d7400 ath_start: dequeue packet 0x0 ath_start: dequeue packet 0xc37d8000 ath_start: power save, packet=0xc37d8000 ath_start: dequeue packet 0x0 ath_start: dequeue packet 0xc38f0700 ath_start: power save, packet=0xc38f0700 ath_start: dequeue packet 0x0 ath_tx_dmasetup: m 0xc37d8900 len 24 TODS 00:05:4e:4e:1f:c7->00:13:1a:47:7a:33(00:13:1a:47:7a:33) data 48M 4801 2c00 0013 1a47 7a33 0005 4e4e 1fc7 0013 1a47 7a33 b001 ath_tx_handoff: 0: 00000000 014d29e8 4122001c 00008018 03328000 00006d08 ath_tx_handoff: TXDP[1] = 0x1d3d4600 (0xdecd1600) depth 1 ath_start:ath_start: dequeue packet 0x0 dequeue packet 0x0 ath_start: dequeue packet 0xc37d3000 ath_tx_dmasetup: m 0xc37d3000 len 116 TODS 00:05:4e:4e:1f:c7->00:e0:18:88:02:e6(00:13:1a:47:7a:33) data 48M 0801 2c00 0013 1a47 7a33 0005 4e4e 1fc7 00e0 1888 02e6 c001 aaaa 0300 0000 0800 4500 0054 06e2 0000 4001 6cf4 c10a 42fd c10a 41c1 0800 ecc4 4a06 0000 499b 0c67 000a 8025 0809 0a0b 0c0d 0e0f 1011 1213 1415 1617 1819 1a1b 1c1d 1e1f 2021 2223 2425 2627 2829 2a2b 2c2d 2e2f 3031 3233 3435 3637 ath_tx_handoff: 0: 00000000 014cd064 41220078 00008074 03328000 00006d08 ath_tx_handoff: link[1](0xdecd1600)=0x1d3d44c0 (0xdecd14c0) depth 2 ath_start: dequeue packet 0xc37d4800 ath_tx_dmasetup: m 0xc37d4800 len 116 TODS 00:05:4e:4e:1f:c7->00:e0:18:88:02:e6(00:13:1a:47:7a:33) data 48M 0801 2c00 0013 1a47 7a33 0005 4e4e 1fc7 00e0 1888 02e6 d001 aaaa 0300 0000 0800 4500 0054 06e3 0000 4001 6cf3 c10a 42fd c10a 41c1 0800 ca0e 4a06 0001 499b 0c68 000a a2d9 0809 0a0b 0c0d 0e0f 1011 1213 1415 1617 1819 1a1b 1c1d 1e1f 2021 2223 2425 2627 2829 2a2b 2c2d 2e2f 3031 3233 3435 3637 ath_tx_handoff: 0: 00000000 014ce864 41220078 00008074 03328000 00006d08 ath_tx_handoff: link[1](0xdecd14c0)=0x1d3d4b00 (0xdecd1b00) depth 3 ath_start: dequeue packet 0xc37d4600 ath_tx_dmasetup: m 0xc37d4600 len 116 TODS 00:05:4e:4e:1f:c7->00:e0:18:88:02:e6(00:13:1a:47:7a:33) data 48M 0801 2c00 0013 1a47 7a33 0005 4e4e 1fc7 00e0 1888 02e6 e001 aaaa 0300 0000 0800 4500 0054 06e4 0000 4001 6cf2 c10a 42fd c10a 41c1 0800 a2ec 4a06 0002 499b 0c69 000a c9f9 0809 0a0b 0c0d 0e0f 1011 1213 1415 1617 1819 1a1b 1c1d 1e1f 2021 2223 2425 2627 2829 2a2b 2c2d 2e2f 3031 3233 3435 3637 ath_tx_handoff: 0: 00000000 014ce664 41220078 00008074 03328000 00006d08 ath_tx_handoff: link[1](0xdecd1b00)=0x1d3d4c40 (0xdecd1c40) depth 4 ath_start: dequeue packet 0xc37d6c00 ath_tx_dmasetup: m 0xc37d6c00 len 116 TODS 00:05:4e:4e:1f:c7->00:e0:18:88:02:e6(00:13:1a:47:7a:33) data 48M 0801 2c00 0013 1a47 7a33 0005 4e4e 1fc7 00e0 1888 02e6 f001 aaaa 0300 0000 0800 4500 0054 06e5 0000 4001 6cf1 c10a 42fd c10a 41c1 0800 7bca 4a06 0003 499b 0c6a 000a f119 0809 0a0b 0c0d 0e0f 1011 1213 1415 1617 1819 1a1b 1c1d 1e1f 2021 2223 2425 2627 2829 2a2b 2c2d 2e2f 3031 3233 3435 3637 ath_tx_handoff: 0: 00000000 014d0c64 41220078 00008074 03328000 00006d08 ath_tx_handoff: link[1](0xdecd1c40)=0x1d3d4740 (0xdecd1740) depth 5 ath_start: dequeue packet 0xc37db000 ath_tx_dmasetup: m 0xc37db000 len 116 TODS 00:05:4e:4e:1f:c7->00:e0:18:88:02:e6(00:13:1a:47:7a:33) data 54M 0801 2c00 0013 1a47 7a33 0005 4e4e 1fc7 00e0 1888 02e6 0002 aaaa 0300 0000 0800 4500 0054 06e6 0000 4001 6cf0 c10a 42fd c10a 41c1 0800 54a8 4a06 0004 499b 0c6b 000b 1839 0809 0a0b 0c0d 0e0f 1011 1213 1415 1617 1819 1a1b 1c1d 1e1f 2021 2223 2425 2627 2829 2a2b 2c2d 2e2f 3031 3233 3435 3637 ath_tx_handoff: 0: 00000000 014d5064 61220078 00008074 03328000 00006d0c ath_tx_handoff: link[1](0xdecd1740)=0x1d3d4d80 (0xdecd1d80) depth 6 ath_start: dequeue packet 0xc37d9e00 ath_tx_dmasetup: m 0xc37d9e00 len 116 TODS 00:05:4e:4e:1f:c7->00:e0:18:88:02:e6(00:13:1a:47:7a:33) data 48M 0801 2c00 0013 1a47 7a33 0005 4e4e 1fc7 00e0 1888 02e6 1002 aaaa 0300 0000 0800 4500 0054 06e7 0000 4001 6cef c10a 42fd c10a 41c1 0800 2d83 4a06 0005 499b 0c6c 000b 3f5c 0809 0a0b 0c0d 0e0f 1011 1213 1415 1617 1819 1a1b 1c1d 1e1f 2021 2223 2425 2627 2829 2a2b 2c2d 2e2f 3031 3233 3435 3637 ath_tx_handoff: 0: 00000000 014d3e64 41220078 00008074 03328000 00006d08 ath_tx_handoff: link[1](0xdecd1d80)=0x1d3d5000 (0xdecd2000) depth 7 ath_start: dequeue packet 0xc37d5800 ath_tx_dmasetup: m 0xc37d5800 len 116 TODS 00:05:4e:4e:1f:c7->00:e0:18:88:02:e6(00:13:1a:47:7a:33) data 48M 0801 2c00 0013 1a47 7a33 0005 4e4e 1fc7 00e0 1888 02e6 2002 aaaa 0300 0000 0800 4500 0054 06e8 0000 4001 6cee c10a 42fd c10a 41c1 0800 0665 4a06 0006 499b 0c6d 000b 6678 0809 0a0b 0c0d 0e0f 1011 1213 1415 1617 1819 1a1b 1c1d 1e1f 2021 2223 2425 2627 2829 2a2b 2c2d 2e2f 3031 3233 3435 3637 ath_tx_handoff: 0: 00000000 014cf864 41220078 00008074 03328000 00006d08 ath_tx_handoff: link[1](0xdecd2000)=0x1d3d5280 (0xdecd2280) depth 8 ath_start: dequeue packet 0xc37da800 ath_tx_dmasetup: m 0xc37da800 len 116 TODS 00:05:4e:4e:1f:c7->00:e0:18:88:02:e6(00:13:1a:47:7a:33) data 48M 0801 2c00 0013 1a47 7a33 0005 4e4e 1fc7 00e0 1888 02e6 3002 aaaa 0300 0000 0800 4500 0054 06e9 0000 4001 6ced c10a 42fd c10a 41c1 0800 df42 4a06 0007 499b 0c6e 000b 8d98 0809 0a0b 0c0d 0e0f 1011 1213 1415 1617 1819 1a1b 1c1d 1e1f 2021 2223 2425 2627 2829 2a2b 2c2d 2e2f 3031 3233 3435 3637 ath_tx_handoff: 0: 00000000 014d4864 41220078 00008074 03328000 00006d08 ath_tx_handoff: link[1](0xdecd2280)=0x1d3d53c0 (0xdecd23c0) depth 9 ath_start: dequeue packet 0xc37da100 ath_tx_dmasetup: m 0xc37da100 len 116 TODS 00:05:4e:4e:1f:c7->00:e0:18:88:02:e6(00:13:1a:47:7a:33) data 48M 0801 2c00 0013 1a47 7a33 0005 4e4e 1fc7 00e0 1888 02e6 4002 aaaa 0300 0000 0800 4500 0054 06ea 0000 4001 6cec c10a 42fd c10a 41c1 0800 b821 4a06 0008 499b 0c6f 000b b4b7 0809 0a0b 0c0d 0e0f 1011 1213 1415 1617 1819 1a1b 1c1d 1e1f 2021 2223 2425 2627 2829 2a2b 2c2d 2e2f 3031 3233 3435 3637 ath_tx_handoff: 0: 00000000 014d4164 41220078 00008074 03328000 00006d08 ath_tx_handoff: link[1](0xdecd23c0)=0x1d3d4ec0 (0xdecd1ec0) depth 10 ath_start: dequeue packet 0xc37dab00 ath_tx_dmasetup: m 0xc37dab00 len 116 TODS 00:05:4e:4e:1f:c7->00:e0:18:88:02:e6(00:13:1a:47:7a:33) data 48M 0801 2c00 0013 1a47 7a33 0005 4e4e 1fc7 00e0 1888 02e6 5002 aaaa 0300 0000 0800 4500 0054 06eb 0000 4001 6ceb c10a 42fd c10a 41c1 0800 90f8 4a06 0009 499b 0c70 000b dbde 0809 0a0b 0c0d 0e0f 1011 1213 1415 1617 1819 1a1b 1c1d 1e1f 2021 2223 2425 2627 2829 2a2b 2c2d 2e2f 3031 3233 3435 3637 ath_tx_handoff: 0: 00000000 014d4b64 61220078 00008074 03328000 00006d08 ath_tx_handoff: link[1](0xdecd1ec0)=0x1d3d5500 (0xdecd2500) depth 11 ath_start: dequeue packet 0xc38ef900 ath_tx_dmasetup: m 0xc38ef900 len 116 TODS 00:05:4e:4e:1f:c7->00:e0:18:88:02:e6(00:13:1a:47:7a:33) data 48M 0801 2c00 0013 1a47 7a33 0005 4e4e 1fc7 00e0 1888 02e6 6002 aaaa 0300 0000 0800 4500 0054 06ec 0000 4001 6cea c10a 42fd c10a 41c1 0800 69c4 4a06 000a 499b 0c71 000c 0310 0809 0a0b 0c0d 0e0f 1011 1213 1415 1617 1819 1a1b 1c1d 1e1f 2021 2223 2425 2627 2829 2a2b 2c2d 2e2f 3031 3233 3435 3637 ath_tx_handoff: 0: 00000000 01fe2964 41220078 00008074 03328000 00006d08 ath_tx_handoff: link[1](0xdecd2500)=0x1d3d5640 (0xdecd2640) depth 12 ath_start: dequeue packet 0xc37d4d00 ath_tx_dmasetup: m 0xc37d4d00 len 116 TODS 00:05:4e:4e:1f:c7->00:e0:18:88:02:e6(00:13:1a:47:7a:33) data 48M 0801 2c00 0013 1a47 7a33 0005 4e4e 1fc7 00e0 1888 02e6 7002 aaaa 0300 0000 0800 4500 0054 06ed 0000 4001 6ce9 c10a 42fd c10a 41c1 0800 42be 4a06 000b 499b 0c72 000c 2a14 0809 0a0b 0c0d 0e0f 1011 1213 1415 1617 1819 1a1b 1c1d 1e1f 2021 2223 2425 2627 2829 2a2b 2c2d 2e2f 3031 3233 3435 3637 ath_tx_handoff: 0: 00000000 014ced64 41220078 00008074 03328000 00006d08 ath_tx_handoff: link[1](0xdecd2640)=0x1d3d5140 (0xdecd2140) depth 13 ath_start: dequeue packet 0xc37d9b00 ath_tx_dmasetup: m 0xc37d9b00 len 116 TODS 00:05:4e:4e:1f:c7->00:e0:18:88:02:e6(00:13:1a:47:7a:33) data 48M 0801 2c00 0013 1a47 7a33 0005 4e4e 1fc7 00e0 1888 02e6 8002 aaaa 0300 0000 0800 4500 0054 06ee 0000 4001 6ce8 c10a 42fd c10a 41c1 0800 1b98 4a06 000c 499b 0c73 000c 5138 0809 0a0b 0c0d 0e0f 1011 1213 1415 1617 1819 1a1b 1c1d 1e1f 2021 2223 2425 2627 2829 2a2b 2c2d 2e2f 3031 3233 3435 3637 ath_tx_handoff: 0: 00000000 014d3b64 41220078 00008074 03328000 00006d08 ath_tx_handoff: link[1](0xdecd2140)=0x1d3d5780 (0xdecd2780) depth 14 ath_start: dequeue packet 0xc37d9500 ath_tx_dmasetup: m 0xc37d9500 len 116 TODS 00:05:4e:4e:1f:c7->00:e0:18:88:02:e6(00:13:1a:47:7a:33) data 48M 0801 2c00 0013 1a47 7a33 0005 4e4e 1fc7 00e0 1888 02e6 9002 aaaa 0300 0000 0800 4500 0054 06ef 0000 4001 6ce7 c10a 42fd c10a 41c1 0800 f476 4a06 000d 499b 0c74 000c 7857 0809 0a0b 0c0d 0e0f 1011 1213 1415 1617 1819 1a1b 1c1d 1e1f 2021 2223 2425 2627 2829 2a2b 2c2d 2e2f 3031 3233 3435 3637 ath_tx_handoff: 0: 00000000 014d3564 41220078 00008074 03328000 00006d08 ath_tx_handoff: link[1](0xdecd2780)=0x1d3d5a00 (0xdecd2a00) depth 15 ath_start: dequeue packet 0xc37d9600 ath_tx_dmasetup: m 0xc37d9600 len 116 TODS 00:05:4e:4e:1f:c7->00:e0:18:88:02:e6(00:13:1a:47:7a:33) data 48M 0801 2c00 0013 1a47 7a33 0005 4e4e 1fc7 00e0 1888 02e6 a002 aaaa 0300 0000 0800 4500 0054 06f0 0000 4001 6ce6 c10a 42fd c10a 41c1 0800 cd56 4a06 000e 499b 0c75 000c 9f75 0809 0a0b 0c0d 0e0f 1011 1213 1415 1617 1819 1a1b 1c1d 1e1f 2021 2223 2425 2627 2829 2a2b 2c2d 2e2f 3031 3233 3435 3637 ath_tx_handoff: 0: 00000000 014d3664 61220078 00008074 03328000 00006d08 ath_tx_handoff: link[1](0xdecd2a00)=0x1d3d5c80 (0xdecd2c80) depth 16 ath_start: dequeue packet 0xc37d7d00 ath_tx_dmasetup: m 0xc37d7d00 len 116 TODS 00:05:4e:4e:1f:c7->00:e0:18:88:02:e6(00:13:1a:47:7a:33) data 54M 0801 2c00 0013 1a47 7a33 0005 4e4e 1fc7 00e0 1888 02e6 b002 aaaa 0300 0000 0800 4500 0054 06f1 0000 4001 6ce5 c10a 42fd c10a 41c1 0800 a634 4a06 000f 499b 0c76 000c c695 0809 0a0b 0c0d 0e0f 1011 1213 1415 1617 1819 1a1b 1c1d 1e1f 2021 2223 2425 2627 2829 2a2b 2c2d 2e2f 3031 3233 3435 3637 ath_tx_handoff: 0: 00000000 014d1d64 41220078 00008074 03328000 00006d0c ath_tx_handoff: link[1](0xdecd2c80)=0x1d3d5dc0 (0xdecd2dc0) depth 17 ath_start: dequeue packet 0xc37d9100 ath_tx_dmasetup: m 0xc37d9100 len 116 TODS 00:05:4e:4e:1f:c7->00:e0:18:88:02:e6(00:13:1a:47:7a:33) data 48M 0801 2c00 0013 1a47 7a33 0005 4e4e 1fc7 00e0 1888 02e6 c002 aaaa 0300 0000 0800 4500 0054 06f2 0000 4001 6ce4 c10a 42fd c10a 41c1 0800 7f13 4a06 0010 499b 0c77 000c edb4 0809 0a0b 0c0d 0e0f 1011 1213 1415 1617 1819 1a1b 1c1d 1e1f 2021 2223 2425 2627 2829 2a2b 2c2d 2e2f 3031 3233 3435 3637 ath_tx_handoff: 0: 00000000 014d3164 41220078 00008074 03328000 00006d08 ath_tx_handoff: link[1](0xdecd2dc0)=0x1d3d58c0 (0xdecd28c0) depth 18 ath_start: dequeue packet 0xc38a1500 ath_tx_dmasetup: m 0xc38a1500 len 116 TODS 00:05:4e:4e:1f:c7->00:e0:18:88:02:e6(00:13:1a:47:7a:33) data 48M 0801 2c00 0013 1a47 7a33 0005 4e4e 1fc7 00e0 1888 02e6 d002 aaaa 0300 0000 0800 4500 0054 06f3 0000 4001 6ce3 c10a 42fd c10a 41c1 0800 57f1 4a06 0011 499b 0c78 000d 14d4 0809 0a0b 0c0d 0e0f 1011 1213 1415 1617 1819 1a1b 1c1d 1e1f 2021 2223 2425 2627 2829 2a2b 2c2d 2e2f 3031 3233 3435 3637 ath_tx_handoff: 0: 00000000 01f58564 41220078 00008074 03328000 00006d08 ath_tx_handoff: link[1](0xdecd28c0)=0x1d3d5f00 (0xdecd2f00) depth 19 ath_start: dequeue packet 0xc37d6800 ath_tx_dmasetup: m 0xc37d6800 len 116 TODS 00:05:4e:4e:1f:c7->00:e0:18:88:02:e6(00:13:1a:47:7a:33) data 48M 0801 2c00 0013 1a47 7a33 0005 4e4e 1fc7 00e0 1888 02e6 e002 aaaa 0300 0000 0800 4500 0054 06f4 0000 4001 6ce2 c10a 42fd c10a 41c1 0800 30d2 4a06 0012 499b 0c79 000d 3bf1 0809 0a0b 0c0d 0e0f 1011 1213 1415 1617 1819 1a1b 1c1d 1e1f 2021 2223 2425 2627 2829 2a2b 2c2d 2e2f 3031 3233 3435 3637 ath_tx_handoff: 0: 00000000 014d0864 41220078 00008074 03328000 00006d08 ath_tx_handoff: link[1](0xdecd2f00)=0x1d3d6040 (0xdecd3040) depth 20 ath_start: dequeue packet 0xc37d8800 ath_tx_dmasetup: m 0xc37d8800 len 116 TODS 00:05:4e:4e:1f:c7->00:e0:18:88:02:e6(00:13:1a:47:7a:33) data 48M 0801 2c00 0013 1a47 7a33 0005 4e4e 1fc7 00e0 1888 02e6 f002 aaaa 0300 0000 0800 4500 0054 06f5 0000 4001 6ce1 c10a 42fd c10a 41c1 0800 09a4 4a06 0013 499b 0c7a 000d 631d 0809 0a0b 0c0d 0e0f 1011 1213 1415 1617 1819 1a1b 1c1d 1e1f 2021 2223 2425 2627 2829 2a2b 2c2d 2e2f 3031 3233 3435 3637 ath_tx_handoff: 0: 00000000 014d2864 61220078 00008074 03328000 00006d08 ath_tx_handoff: link[1](0xdecd3040)=0x1d3d5b40 (0xdecd2b40) depth 21 ath_start: dequeue packet 0xc37d5a00 ath_tx_dmasetup: m 0xc37d5a00 len 116 TODS 00:05:4e:4e:1f:c7->00:e0:18:88:02:e6(00:13:1a:47:7a:33) data 48M 0801 2c00 0013 1a47 7a33 0005 4e4e 1fc7 00e0 1888 02e6 0003 aaaa 0300 0000 0800 4500 0054 06f6 0000 4001 6ce0 c10a 42fd c10a 41c1 0800 e279 4a06 0014 499b 0c7b 000d 8a45 0809 0a0b 0c0d 0e0f 1011 1213 1415 1617 1819 1a1b 1c1d 1e1f 2021 2223 2425 2627 2829 2a2b 2c2d 2e2f 3031 3233 3435 3637 ath_tx_handoff: 0: 00000000 014cfa64 41220078 00008074 03328000 00006d08 ath_tx_handoff: link[1](0xdecd2b40)=0x1d3d6180 (0xdecd3180) depth 22 ath_start: dequeue packet 0xc37d4400 ath_tx_dmasetup: m 0xc37d4400 len 116 TODS 00:05:4e:4e:1f:c7->00:e0:18:88:02:e6(00:13:1a:47:7a:33) data 48M 0801 2c00 0013 1a47 7a33 0005 4e4e 1fc7 00e0 1888 02e6 1003 aaaa 0300 0000 0800 4500 0054 06f7 0000 4001 6cdf c10a 42fd c10a 41c1 0800 bb6d 4a06 0015 499b 0c7c 000d b14f 0809 0a0b 0c0d 0e0f 1011 1213 1415 1617 1819 1a1b 1c1d 1e1f 2021 2223 2425 2627 2829 2a2b 2c2d 2e2f 3031 3233 3435 3637 ath_tx_handoff: 0: 00000000 014ce464 41220078 00008074 03328000 00006d08 ath_tx_handoff: link[1](0xdecd3180)=0x1d3d6400 (0xdecd3400) depth 23 ath_start: dequeue packet 0xc37da400 ath_tx_dmasetup: m 0xc37da400 len 116 TODS 00:05:4e:4e:1f:c7->00:e0:18:88:02:e6(00:13:1a:47:7a:33) data 48M 0801 2c00 0013 1a47 7a33 0005 4e4e 1fc7 00e0 1888 02e6 2003 aaaa 0300 0000 0800 4500 0054 06f8 0000 4001 6cde c10a 42fd c10a 41c1 0800 9448 4a06 0016 499b 0c7d 000d d872 0809 0a0b 0c0d 0e0f 1011 1213 1415 1617 1819 1a1b 1c1d 1e1f 2021 2223 2425 2627 2829 2a2b 2c2d 2e2f 3031 3233 3435 3637 ath_tx_handoff: 0: 00000000 014d4464 41220078 00008074 03328000 00006d08 ath_tx_handoff: link[1](0xdecd3400)=0x1d3d6680 (0xdecd3680) depth 24 ath_start: dequeue packet 0xc37d5d00 ath_tx_dmasetup: m 0xc37d5d00 len 116 TODS 00:05:4e:4e:1f:c7->00:e0:18:88:02:e6(00:13:1a:47:7a:33) data 48M 0801 2c00 0013 1a47 7a33 0005 4e4e 1fc7 00e0 1888 02e6 3003 aaaa 0300 0000 0800 4500 0054 06f9 0000 4001 6cdd c10a 42fd c10a 41c1 0800 6d1e 4a06 0017 499b 0c7e 000d ff9a 0809 0a0b 0c0d 0e0f 1011 1213 1415 1617 1819 1a1b 1c1d 1e1f 2021 2223 2425 2627 2829 2a2b 2c2d 2e2f 3031 3233 3435 3637 ath_tx_handoff: 0: 00000000 014cfd64 41220078 00008074 03328000 00006d08 ath_tx_handoff: link[1](0xdecd3680)=0x1d3d67c0 (0xdecd37c0) depth 25 ath_start: dequeue packet 0xc37d7000 ath_tx_dmasetup: m 0xc37d7000 len 116 TODS 00:05:4e:4e:1f:c7->00:e0:18:88:02:e6(00:13:1a:47:7a:33) data 48M 0801 2c00 0013 1a47 7a33 0005 4e4e 1fc7 00e0 1888 02e6 4003 aaaa 0300 0000 0800 4500 0054 06fa 0000 4001 6cdc c10a 42fd c10a 41c1 0800 4606 4a06 0018 499b 0c7f 000e 26b0 0809 0a0b 0c0d 0e0f 1011 1213 1415 1617 1819 1a1b 1c1d 1e1f 2021 2223 2425 2627 2829 2a2b 2c2d 2e2f 3031 3233 3435 3637 ath_tx_handoff: 0: 00000000 014d1064 61220078 00008074 03328000 00006d08 ath_tx_handoff: link[1](0xdecd37c0)=0x1d3d62c0 (0xdecd32c0) depth 26 ath_start: dequeue packet 0xc37db400 ath_tx_dmasetup: m 0xc37db400 len 116 TODS 00:05:4e:4e:1f:c7->00:e0:18:88:02:e6(00:13:1a:47:7a:33) data 48M 0801 2c00 0013 1a47 7a33 0005 4e4e 1fc7 00e0 1888 02e6 5003 aaaa 0300 0000 0800 4500 0054 06fb 0000 4001 6cdb c10a 42fd c10a 41c1 0800 1ee3 4a06 0019 499b 0c80 000e 4dd1 0809 0a0b 0c0d 0e0f 1011 1213 1415 1617 1819 1a1b 1c1d 1e1f 2021 2223 2425 2627 2829 2a2b 2c2d 2e2f 3031 3233 3435 3637 ath_tx_handoff: 0: 00000000 014d5464 41220078 00008074 03328000 00006d08 ath_tx_handoff: link[1](0xdecd32c0)=0x1d3d6900 (0xdecd3900) depth 27 ath_start: dequeue packet 0xc37d6400 ath_tx_dmasetup: m 0xc37d6400 len 116 TODS 00:05:4e:4e:1f:c7->00:e0:18:88:02:e6(00:13:1a:47:7a:33) data 54M 0801 2c00 0013 1a47 7a33 0005 4e4e 1fc7 00e0 1888 02e6 6003 aaaa 0300 0000 0800 4500 0054 06fc 0000 4001 6cda c10a 42fd c10a 41c1 0800 f7c2 4a06 001a 499b 0c81 000e 74ef 0809 0a0b 0c0d 0e0f 1011 1213 1415 1617 1819 1a1b 1c1d 1e1f 2021 2223 2425 2627 2829 2a2b 2c2d 2e2f 3031 3233 3435 3637 ath_tx_handoff: 0: 00000000 014d0464 41220078 00008074 03328000 00006d0c ath_tx_handoff: link[1](0xdecd3900)=0x1d3d6a40 (0xdecd3a40) depth 28 ath_start: dequeue packet 0xc37d6700 ath_tx_dmasetup: m 0xc37d6700 len 116 TODS 00:05:4e:4e:1f:c7->00:e0:18:88:02:e6(00:13:1a:47:7a:33) data 48M 0801 2c00 0013 1a47 7a33 0005 4e4e 1fc7 00e0 1888 02e6 7003 aaaa 0300 0000 0800 4500 0054 06fd 0000 4001 6cd9 c10a 42fd c10a 41c1 0800 d0a1 4a06 001b 499b 0c82 000e 9c0e 0809 0a0b 0c0d 0e0f 1011 1213 1415 1617 1819 1a1b 1c1d 1e1f 2021 2223 2425 2627 2829 2a2b 2c2d 2e2f 3031 3233 3435 3637 ath_tx_handoff: 0: 00000000 014d0764 41220078 00008074 03328000 00006d08 ath_tx_handoff: link[1](0xdecd3a40)=0x1d3d6540 (0xdecd3540) depth 29 ath_start: dequeue packet 0xc37d5700 ath_tx_dmasetup: m 0xc37d5700 len 116 TODS 00:05:4e:4e:1f:c7->00:e0:18:88:02:e6(00:13:1a:47:7a:33) data 48M 0801 2c00 0013 1a47 7a33 0005 4e4e 1fc7 00e0 1888 02e6 8003 aaaa 0300 0000 0800 4500 0054 06fe 0000 4001 6cd8 c10a 42fd c10a 41c1 0800 a980 4a06 001c 499b 0c83 000e c32d 0809 0a0b 0c0d 0e0f 1011 1213 1415 1617 1819 1a1b 1c1d 1e1f 2021 2223 2425 2627 2829 2a2b 2c2d 2e2f 3031 3233 3435 3637 ath_tx_handoff: 0: 00000000 014cf764 41220078 00008074 03328000 00006d08 ath_tx_handoff: link[1](0xdecd3540)=0x1d3d6b80 (0xdecd3b80) depth 30 ath_start: dequeue packet 0xc37d8100 ath_tx_dmasetup: m 0xc37d8100 len 116 TODS 00:05:4e:4e:1f:c7->00:e0:18:88:02:e6(00:13:1a:47:7a:33) data 48M 0801 2c00 0013 1a47 7a33 0005 4e4e 1fc7 00e0 1888 02e6 9003 aaaa 0300 0000 0800 4500 0054 06ff 0000 4001 6cd7 c10a 42fd c10a 41c1 0800 825a 4a06 001d 499b 0c84 000e ea51 0809 0a0b 0c0d 0e0f 1011 1213 1415 1617 1819 1a1b 1c1d 1e1f 2021 2223 2425 2627 2829 2a2b 2c2d 2e2f 3031 3233 3435 3637 ath_tx_handoff: 0: 00000000 014d2164 61220078 00008074 03328000 00006d08 ath_tx_handoff: link[1](0xdecd3b80)=0x1d3d6e00 (0xdecd3e00) depth 31 ath_start: dequeue packet 0xc37d8d00 ath_tx_dmasetup: m 0xc37d8d00 len 116 TODS 00:05:4e:4e:1f:c7->00:e0:18:88:02:e6(00:13:1a:47:7a:33) data 48M 0801 2c00 0013 1a47 7a33 0005 4e4e 1fc7 00e0 1888 02e6 a003 aaaa 0300 0000 0800 4500 0054 0700 0000 4001 6cd6 c10a 42fd c10a 41c1 0800 5b20 4a06 001e 499b 0c85 000f 1189 0809 0a0b 0c0d 0e0f 1011 1213 1415 1617 1819 1a1b 1c1d 1e1f 2021 2223 2425 2627 2829 2a2b 2c2d 2e2f 3031 3233 3435 3637 ath_tx_handoff: 0: 00000000 014d2d64 41220078 00008074 03328000 00006d08 ath_tx_handoff: link[1](0xdecd3e00)=0x1d3d6f40 (0xdecd3f40) depth 32 ath_start: dequeue packet 0xc37d4a00 ath_tx_dmasetup: m 0xc37d4a00 len 116 TODS 00:05:4e:4e:1f:c7->00:e0:18:88:02:e6(00:13:1a:47:7a:33) data 48M 0801 2c00 0013 1a47 7a33 0005 4e4e 1fc7 00e0 1888 02e6 b003 aaaa 0300 0000 0800 4500 0054 0701 0000 4001 6cd5 c10a 42fd c10a 41c1 0800 341e 4a06 001f 499b 0c86 000f 3889 0809 0a0b 0c0d 0e0f 1011 1213 1415 1617 1819 1a1b 1c1d 1e1f 2021 2223 2425 2627 2829 2a2b 2c2d 2e2f 3031 3233 3435 3637 ath_tx_handoff: 0: 00000000 014cea64 41220078 00008074 03328000 00006d08 ath_tx_handoff: link[1](0xdecd3f40)=0x1d3d6cc0 (0xdecd3cc0) depth 33 ath_start: dequeue packet 0xc37d8a00 ath_tx_dmasetup: m 0xc37d8a00 len 116 TODS 00:05:4e:4e:1f:c7->00:e0:18:88:02:e6(00:13:1a:47:7a:33) data 48M 0801 2c00 0013 1a47 7a33 0005 4e4e 1fc7 00e0 1888 02e6 c003 aaaa 0300 0000 0800 4500 0054 0702 0000 4001 6cd4 c10a 42fd c10a 41c1 0800 4f44 4a06 0020 499b 0c88 0000 1d6f 0809 0a0b 0c0d 0e0f 1011 1213 1415 1617 1819 1a1b 1c1d 1e1f 2021 2223 2425 2627 2829 2a2b 2c2d 2e2f 3031 3233 3435 3637 ath_tx_handoff: 0: 00000000 014d2a64 41220078 00008074 03328000 00006d08 ath_tx_handoff: link[1](0xdecd3cc0)=0x1d3d7080 (0xdecd4080) depth 34 ath_start: dequeue packet 0xc37d9400 ath_tx_dmasetup: m 0xc37d9400 len 116 TODS 00:05:4e:4e:1f:c7->00:e0:18:88:02:e6(00:13:1a:47:7a:33) data 48M 0801 2c00 0013 1a47 7a33 0005 4e4e 1fc7 00e0 1888 02e6 d003 aaaa 0300 0000 0800 4500 0054 0703 0000 4001 6cd3 c10a 42fd c10a 41c1 0800 2827 4a06 0021 499b 0c89 0000 448a 0809 0a0b 0c0d 0e0f 1011 1213 1415 1617 1819 1a1b 1c1d 1e1f 2021 2223 2425 2627 2829 2a2b 2c2d 2e2f 3031 3233 3435 3637 ath_tx_handoff: 0: 00000000 014d3464 41220078 00008074 03328000 00006d08 ath_tx_handoff: link[1](0xdecd4080)=0x1d3d7300 (0xdecd4300) depth 35 ath_start: dequeue packet 0xc37d8400 ath_tx_dmasetup: m 0xc37d8400 len 116 TODS 00:05:4e:4e:1f:c7->00:e0:18:88:02:e6(00:13:1a:47:7a:33) data 48M 0801 2c00 0013 1a47 7a33 0005 4e4e 1fc7 00e0 1888 02e6 e003 aaaa 0300 0000 0800 4500 0054 0704 0000 4001 6cd2 c10a 42fd c10a 41c1 0800 0105 4a06 0022 499b 0c8a 0000 6baa 0809 0a0b 0c0d 0e0f 1011 1213 1415 1617 1819 1a1b 1c1d 1e1f 2021 2223 2425 2627 2829 2a2b 2c2d 2e2f 3031 3233 3435 3637 ath_tx_handoff: 0: 00000000 014d2464 61220078 00008074 03328000 00006d08 ath_tx_handoff: link[1](0xdecd4300)=0x1d3d7440 (0xdecd4440) depth 36 ath_start: dequeue packet 0xc37d3400 ath_tx_dmasetup: m 0xc37d3400 len 116 TODS 00:05:4e:4e:1f:c7->00:e0:18:88:02:e6(00:13:1a:47:7a:33) data 48M 0801 2c00 0013 1a47 7a33 0005 4e4e 1fc7 00e0 1888 02e6 f003 aaaa 0300 0000 0800 4500 0054 0705 0000 4001 6cd1 c10a 42fd c10a 41c1 0800 d9e3 4a06 0023 499b 0c8b 0000 92c9 0809 0a0b 0c0d 0e0f 1011 1213 1415 1617 1819 1a1b 1c1d 1e1f 2021 2223 2425 2627 2829 2a2b 2c2d 2e2f 3031 3233 3435 3637 ath_tx_handoff: 0: 00000000 014cd464 41220078 00008074 03328000 00006d08 ath_tx_handoff: link[1](0xdecd4440)=0x1d3d71c0 (0xdecd41c0) depth 37 ath_start: dequeue packet 0xc37d4500 ath_tx_dmasetup: m 0xc37d4500 len 116 TODS 00:05:4e:4e:1f:c7->00:e0:18:88:02:e6(00:13:1a:47:7a:33) data 48M 0801 2c00 0013 1a47 7a33 0005 4e4e 1fc7 00e0 1888 02e6 0004 aaaa 0300 0000 0800 4500 0054 0706 0000 4001 6cd0 c10a 42fd c10a 41c1 0800 b2bd 4a06 0024 499b 0c8c 0000 b9ed 0809 0a0b 0c0d 0e0f 1011 1213 1415 1617 1819 1a1b 1c1d 1e1f 2021 2223 2425 2627 2829 2a2b 2c2d 2e2f 3031 3233 3435 3637 ath_tx_handoff: 0: 00000000 014ce564 41220078 00008074 03328000 00006d08 ath_tx_handoff: link[1](0xdecd41c0)=0x1d3d7580 (0xdecd4580) depth 38 ath_start: dequeue packet 0xc37d7400 ath_tx_dmasetup: m 0xc37d7400 len 116 TODS 00:05:4e:4e:1f:c7->00:e0:18:88:02:e6(00:13:1a:47:7a:33) data 54M 0801 2c00 0013 1a47 7a33 0005 4e4e 1fc7 00e0 1888 02e6 1004 aaaa 0300 0000 0800 4500 0054 0707 0000 4001 6ccf c10a 42fd c10a 41c1 0800 8ba0 4a06 0025 499b 0c8d 0000 e108 0809 0a0b 0c0d 0e0f 1011 1213 1415 1617 1819 1a1b 1c1d 1e1f 2021 2223 2425 2627 2829 2a2b 2c2d 2e2f 3031 3233 3435 3637 ath_tx_handoff: 0: 00000000 014d1464 41220078 00008074 03328000 00006d0c ath_tx_handoff: link[1](0xdecd4580)=0x1d3d76c0 (0xdecd46c0) depth 39 ath_start: dequeue packet 0xc37d8000 ath_tx_dmasetup: m 0xc37d8000 len 116 TODS 00:05:4e:4e:1f:c7->00:e0:18:88:02:e6(00:13:1a:47:7a:33) data 48M 0801 2c00 0013 1a47 7a33 0005 4e4e 1fc7 00e0 1888 02e6 2004 aaaa 0300 0000 0800 4500 0054 0708 0000 4001 6cce c10a 42fd c10a 41c1 0800 6480 4a06 0026 499b 0c8e 0001 0826 0809 0a0b 0c0d 0e0f 1011 1213 1415 1617 1819 1a1b 1c1d 1e1f 2021 2223 2425 2627 2829 2a2b 2c2d 2e2f 3031 3233 3435 3637 ath_tx_handoff: 0: 00000000 014d2064 41220078 00008074 03328000 00006d08 ath_tx_handoff: link[1](0xdecd46c0)=0x1d3d7940 (0xdecd4940) depth 40 ath_start: dequeue packet 0xc38f0700 ath_tx_dmasetup: m 0xc38f0700 len 116 TODS 00:05:4e:4e:1f:c7->00:e0:18:88:02:e6(00:13:1a:47:7a:33) data 48M 0801 2c00 0013 1a47 7a33 0005 4e4e 1fc7 00e0 1888 02e6 3004 aaaa 0300 0000 0800 4500 0054 0709 0000 4001 6ccd c10a 42fd c10a 41c1 0800 3d50 4a06 0027 499b 0c8f 0001 2f54 0809 0a0b 0c0d 0e0f 1011 1213 1415 1617 1819 1a1b 1c1d 1e1f 2021 2223 2425 2627 2829 2a2b 2c2d 2e2f 3031 3233 3435 3637 ath_tx_handoff: 0: 00000000 01fe3764 61220078 00008074 03328000 00006d08 ath_tx_handoff: link[1](0xdecd4940)=0x1d3d7a80 (0xdecd4a80) depth 41 ath_start: dequeue packet 0x0 ath_start: dequeue packet 0x0 ath_start: dequeue packet 0x0 ath_start: dequeue packet 0x0 From owner-freebsd-mobile@FreeBSD.ORG Tue Feb 17 20:30:52 2009 Return-Path: Delivered-To: freebsd-mobile@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8979F1065679 for ; Tue, 17 Feb 2009 20:30:52 +0000 (UTC) (envelope-from sam@freebsd.org) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.freebsd.org (Postfix) with ESMTP id 5CD038FC28 for ; Tue, 17 Feb 2009 20:30:52 +0000 (UTC) (envelope-from sam@freebsd.org) Received: from trouble.errno.com (trouble.errno.com [10.0.0.248]) (authenticated bits=0) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id n1HKUpIq078105 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 17 Feb 2009 12:30:51 -0800 (PST) (envelope-from sam@freebsd.org) Message-ID: <499B1E7B.2030908@freebsd.org> Date: Tue, 17 Feb 2009 12:30:51 -0800 From: Sam Leffler Organization: FreeBSD Project User-Agent: Thunderbird 2.0.0.18 (X11/20081209) MIME-Version: 1.0 To: Bengt Ahlgren References: <20090210154047.N38905@sola.nimnet.asn.au> <4991ABA0.4050300@freebsd.org> <4991DB1F.7060809@freebsd.org> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-DCC-sonic.net-Metrics: ebb.errno.com; whitelist Cc: freebsd-mobile@freebsd.org Subject: Re: Problems with ath at kern.hz=100 X-BeenThere: freebsd-mobile@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile computing with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2009 20:30:53 -0000 Bengt Ahlgren wrote: > Sam Leffler writes: > > [...] > > >> You've removed all the context of the original problem; I can't recall >> what you were trying to fix. The ps q drops might be caused by a bug >> that was fixed (I think in RELENG_7). I don't see what version of >> code you're running so can't tell. >> > > Sorry, a summary of the problem: > > The system frequently comes into a state where outgoing packets are > held somewhere. The condition persists for seconds to minutes. It > goes away by itself, but some of the packets are usually lost. This > occurs on ath, FreeBSD 7.1-REL, no SMP, with kern.hz=100 (but not with > hz=1000). Original mail with description can be found here: > > http://lists.freebsd.org/pipermail/freebsd-mobile/2009-February/011343.html > > I have done some more investigation, inserting debug prints in > ath_start (if_ath.c 1.177.2.2.2.1), one just after IFQ_DRV_DEQUEUE > (line 1576), another just before the call to ieee80211_pwrsave (line > 1614). > > Packets are dequeued, but ieee80211_pwrsave is called and nothing > happens. Below is the output from "athdebug xmit" with these extra > two DPRINTF:s during the queue-up. Then after a while packets are > sent again. > > Bengt > > <...debug output removed...> Did you try RELENG_7? ap mode power save was fixed post 7.1 release. Sam From owner-freebsd-mobile@FreeBSD.ORG Tue Feb 17 22:48:41 2009 Return-Path: Delivered-To: freebsd-mobile@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B076F1065676 for ; Tue, 17 Feb 2009 22:48:41 +0000 (UTC) (envelope-from kalin@el.net) Received: from mail.el.net (mail.el.net [74.1.12.120]) by mx1.freebsd.org (Postfix) with ESMTP id 4BAE78FC1C for ; Tue, 17 Feb 2009 22:48:41 +0000 (UTC) (envelope-from kalin@el.net) Received: (qmail 86360 invoked by uid 1008); 17 Feb 2009 23:24:18 -0000 Received: from unknown (HELO kalins-macbook-pro.local) (kalin@el.net@74.1.12.115) by mail.el.net with ESMTPA; 17 Feb 2009 23:24:18 -0000 Message-ID: <499B3888.2000701@el.net> Date: Tue, 17 Feb 2009 17:22:00 -0500 From: kalin m User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: freebsd-net@freebsd.org, freebsd-mobile@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: sms gprs gsm edge X-BeenThere: freebsd-mobile@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile computing with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2009 22:48:42 -0000 hi all... just looking for a few pointers for setting up a sms gateway. if somebody would like to share some knowledge on successfully implemented hardware (gprs/gsm/edge modems/drivers) and software like kannel, smstools, etc... for example i just talked to a salesperson at a company called moxa (http://www.moxa.com/product/oncell_g3100.htm) and was looking at their g3100 model gprs modem. according to their own specifications they have freebsd drivers. anybody has had any experience with those?! any information will be appreciated.. thank you.... From owner-freebsd-mobile@FreeBSD.ORG Tue Feb 17 23:40:46 2009 Return-Path: Delivered-To: freebsd-mobile@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0E1E91065672; Tue, 17 Feb 2009 23:40:46 +0000 (UTC) (envelope-from 000.fbsd@quip.cz) Received: from elsa.codelab.cz (elsa.codelab.cz [91.103.162.4]) by mx1.freebsd.org (Postfix) with ESMTP id C23D88FC15; Tue, 17 Feb 2009 23:40:45 +0000 (UTC) (envelope-from 000.fbsd@quip.cz) Received: from localhost (localhost.codelab.cz [127.0.0.1]) by elsa.codelab.cz (Postfix) with ESMTP id 00D2019E027; Wed, 18 Feb 2009 00:20:48 +0100 (CET) Received: from [192.168.1.2] (r5bb235.net.upc.cz [86.49.61.235]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by elsa.codelab.cz (Postfix) with ESMTPSA id B494519E023; Wed, 18 Feb 2009 00:20:45 +0100 (CET) Message-ID: <499B464C.5020409@quip.cz> Date: Wed, 18 Feb 2009 00:20:44 +0100 From: Miroslav Lachman <000.fbsd@quip.cz> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: cz, cs, en, en-us MIME-Version: 1.0 To: kalin m References: <499B3888.2000701@el.net> In-Reply-To: <499B3888.2000701@el.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, freebsd-mobile@freebsd.org Subject: Re: sms gprs gsm edge X-BeenThere: freebsd-mobile@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile computing with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2009 23:40:46 -0000 kalin m wrote: > > hi all... > > just looking for a few pointers for setting up a sms gateway. > if somebody would like to share some knowledge on successfully > implemented hardware (gprs/gsm/edge modems/drivers) and software like > kannel, smstools, etc... > > for example i just talked to a salesperson at a company called moxa > (http://www.moxa.com/product/oncell_g3100.htm) and was looking at their > g3100 model gprs modem. according to their own specifications they have > freebsd drivers. anybody has had any experience with those?! > > any information will be appreciated.. > thank you.... I used Siemens MC35i GSM modem over COM1 with smstools few years ago (with FreeBSD 4.x). No special drivers needed. It was used to send and receive SMS with our custom PHP web application. I don't know what is your definition of "sms gateway". Miroslav Lachman From owner-freebsd-mobile@FreeBSD.ORG Tue Feb 17 23:45:12 2009 Return-Path: Delivered-To: freebsd-mobile@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4C7B81065687; Tue, 17 Feb 2009 23:45:12 +0000 (UTC) (envelope-from peo@intersonic.se) Received: from neonpark.inter-sonic.com (neonpark.inter-sonic.com [212.247.8.98]) by mx1.freebsd.org (Postfix) with ESMTP id 100178FC28; Tue, 17 Feb 2009 23:45:12 +0000 (UTC) (envelope-from peo@intersonic.se) X-Virus-Scanned: amavisd-new at BSDLabs AB Message-ID: <499B4878.7060103@intersonic.se> Date: Wed, 18 Feb 2009 00:30:00 +0100 From: Per olof Ljungmark Organization: Intersonic AB User-Agent: Thunderbird 2.0.0.19 (X11/20090208) MIME-Version: 1.0 To: kalin m References: <499B3888.2000701@el.net> In-Reply-To: <499B3888.2000701@el.net> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, freebsd-mobile@freebsd.org Subject: Re: sms gprs gsm edge X-BeenThere: freebsd-mobile@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile computing with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2009 23:45:13 -0000 kalin m wrote: > > hi all... > > just looking for a few pointers for setting up a sms gateway. > if somebody would like to share some knowledge on successfully > implemented hardware (gprs/gsm/edge modems/drivers) and software like > kannel, smstools, etc... > > for example i just talked to a salesperson at a company called moxa > (http://www.moxa.com/product/oncell_g3100.htm) and was looking at their > g3100 model gprs modem. according to their own specifications they have > freebsd drivers. anybody has had any experience with those?! > Hi, I know that a collegue here used a Siemens TC65 GSM Modem together with smstools and sms_client from ports to set up a sms paging system that works well. If you'd like I could ask him to send you more detailed info on how it was implemented. I also believe that the engine in this modem is available in various packages, the TC65 is a standalone unit needing only the sim card and antenna to work. It is connected over a usb to serial adapter and required no special drivers. -- per From owner-freebsd-mobile@FreeBSD.ORG Wed Feb 18 09:52:20 2009 Return-Path: Delivered-To: freebsd-mobile@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 36A0C1065670; Wed, 18 Feb 2009 09:52:20 +0000 (UTC) (envelope-from bengta@P142.sics.se) Received: from sink.sics.se (sink.sics.se [193.10.64.88]) by mx1.freebsd.org (Postfix) with ESMTP id B9F898FC28; Wed, 18 Feb 2009 09:52:19 +0000 (UTC) (envelope-from bengta@P142.sics.se) Received: from P142.sics.se (P142.sics.se [193.10.66.253]) by sink.sics.se (8.14.3/8.14.3) with ESMTP id n1I9qAR4060292 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 18 Feb 2009 10:52:10 +0100 (CET) (envelope-from bengta@P142.sics.se) Received: from P142.sics.se (localhost [127.0.0.1]) by P142.sics.se (8.14.3/8.14.3) with ESMTP id n1I9sFVN001118; Wed, 18 Feb 2009 10:54:15 +0100 (CET) (envelope-from bengta@P142.sics.se) Received: (from bengta@localhost) by P142.sics.se (8.14.3/8.14.3/Submit) id n1I9sEdk001117; Wed, 18 Feb 2009 10:54:14 +0100 (CET) (envelope-from bengta@P142.sics.se) To: Sam Leffler From: Bengt Ahlgren In-Reply-To: <499B1E7B.2030908@freebsd.org> (Sam Leffler's message of "Tue\, 17 Feb 2009 12\:30\:51 -0800") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (berkeley-unix) References: <20090210154047.N38905@sola.nimnet.asn.au> <4991ABA0.4050300@freebsd.org> <4991DB1F.7060809@freebsd.org> <499B1E7B.2030908@freebsd.org> Date: Wed, 18 Feb 2009 10:54:14 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: freebsd-mobile@freebsd.org Subject: Re: Problems with ath at kern.hz=100 X-BeenThere: freebsd-mobile@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile computing with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2009 09:52:20 -0000 Sam Leffler writes: > Bengt Ahlgren wrote: >> Sam Leffler writes: >> >> [...] >> >> >>> You've removed all the context of the original problem; I can't recall >>> what you were trying to fix. The ps q drops might be caused by a bug >>> that was fixed (I think in RELENG_7). I don't see what version of >>> code you're running so can't tell. >>> >> >> Sorry, a summary of the problem: >> >> The system frequently comes into a state where outgoing packets are >> held somewhere. The condition persists for seconds to minutes. It >> goes away by itself, but some of the packets are usually lost. This >> occurs on ath, FreeBSD 7.1-REL, no SMP, with kern.hz=100 (but not with >> hz=1000). Original mail with description can be found here: >> >> http://lists.freebsd.org/pipermail/freebsd-mobile/2009-February/011343.html >> >> I have done some more investigation, inserting debug prints in >> ath_start (if_ath.c 1.177.2.2.2.1), one just after IFQ_DRV_DEQUEUE >> (line 1576), another just before the call to ieee80211_pwrsave (line >> 1614). >> >> Packets are dequeued, but ieee80211_pwrsave is called and nothing >> happens. Below is the output from "athdebug xmit" with these extra >> two DPRINTF:s during the queue-up. Then after a while packets are >> sent again. >> >> Bengt >> >> > <...debug output removed...> > > Did you try RELENG_7? ap mode power save was fixed post 7.1 release. I can do that, but I am not using ap mode. Will it still be useful? Bengt From owner-freebsd-mobile@FreeBSD.ORG Wed Feb 18 13:23:16 2009 Return-Path: Delivered-To: freebsd-mobile@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1143E106566B; Wed, 18 Feb 2009 13:23:16 +0000 (UTC) (envelope-from bengta@P142.sics.se) Received: from sink.sics.se (sink.sics.se [193.10.64.88]) by mx1.freebsd.org (Postfix) with ESMTP id 939FE8FC16; Wed, 18 Feb 2009 13:23:15 +0000 (UTC) (envelope-from bengta@P142.sics.se) Received: from P142.sics.se (P142.sics.se [193.10.66.253]) by sink.sics.se (8.14.3/8.14.3) with ESMTP id n1IDN6Jq062503 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 18 Feb 2009 14:23:06 +0100 (CET) (envelope-from bengta@P142.sics.se) Received: from P142.sics.se (localhost [127.0.0.1]) by P142.sics.se (8.14.3/8.14.3) with ESMTP id n1IDPBqr003093; Wed, 18 Feb 2009 14:25:11 +0100 (CET) (envelope-from bengta@P142.sics.se) Received: (from bengta@localhost) by P142.sics.se (8.14.3/8.14.3/Submit) id n1IDPBne003092; Wed, 18 Feb 2009 14:25:11 +0100 (CET) (envelope-from bengta@P142.sics.se) To: Sam Leffler From: Bengt Ahlgren In-Reply-To: (Bengt Ahlgren's message of "Wed\, 18 Feb 2009 10\:54\:14 +0100") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (berkeley-unix) References: <20090210154047.N38905@sola.nimnet.asn.au> <4991ABA0.4050300@freebsd.org> <4991DB1F.7060809@freebsd.org> <499B1E7B.2030908@freebsd.org> Date: Wed, 18 Feb 2009 14:25:11 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: freebsd-mobile@freebsd.org Subject: Re: Problems with ath at kern.hz=100 X-BeenThere: freebsd-mobile@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile computing with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2009 13:23:16 -0000 Bengt Ahlgren writes: > Sam Leffler writes: > >> Bengt Ahlgren wrote: >>> Sam Leffler writes: >>> >>> [...] >>> >>> >>>> You've removed all the context of the original problem; I can't recall >>>> what you were trying to fix. The ps q drops might be caused by a bug >>>> that was fixed (I think in RELENG_7). I don't see what version of >>>> code you're running so can't tell. >>>> >>> >>> Sorry, a summary of the problem: >>> >>> The system frequently comes into a state where outgoing packets are >>> held somewhere. The condition persists for seconds to minutes. It >>> goes away by itself, but some of the packets are usually lost. This >>> occurs on ath, FreeBSD 7.1-REL, no SMP, with kern.hz=100 (but not with >>> hz=1000). Original mail with description can be found here: >>> >>> http://lists.freebsd.org/pipermail/freebsd-mobile/2009-February/011343.html >>> >>> I have done some more investigation, inserting debug prints in >>> ath_start (if_ath.c 1.177.2.2.2.1), one just after IFQ_DRV_DEQUEUE >>> (line 1576), another just before the call to ieee80211_pwrsave (line >>> 1614). >>> >>> Packets are dequeued, but ieee80211_pwrsave is called and nothing >>> happens. Below is the output from "athdebug xmit" with these extra >>> two DPRINTF:s during the queue-up. Then after a while packets are >>> sent again. >>> >>> Bengt >>> >>> >> <...debug output removed...> >> >> Did you try RELENG_7? ap mode power save was fixed post 7.1 release. > > I can do that, but I am not using ap mode. Will it still be useful? Hmm, I see no difference in ath between 7.1-REL and RELENG_7 (besides CVS ID strings)??? Are you meaning HEAD? If so, can I just drop in src/sys/dev/ath from HEAD in 7.1R? Bengt From owner-freebsd-mobile@FreeBSD.ORG Wed Feb 18 16:21:13 2009 Return-Path: Delivered-To: freebsd-mobile@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2A6841065673 for ; Wed, 18 Feb 2009 16:21:13 +0000 (UTC) (envelope-from sam@freebsd.org) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.freebsd.org (Postfix) with ESMTP id D1B388FC15 for ; Wed, 18 Feb 2009 16:21:12 +0000 (UTC) (envelope-from sam@freebsd.org) Received: from trouble.errno.com (trouble.errno.com [10.0.0.248]) (authenticated bits=0) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id n1IGLC6p085053 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 18 Feb 2009 08:21:12 -0800 (PST) (envelope-from sam@freebsd.org) Message-ID: <499C3578.9080007@freebsd.org> Date: Wed, 18 Feb 2009 08:21:12 -0800 From: Sam Leffler Organization: FreeBSD Project User-Agent: Thunderbird 2.0.0.18 (X11/20081209) MIME-Version: 1.0 To: Bengt Ahlgren References: <20090210154047.N38905@sola.nimnet.asn.au> <4991ABA0.4050300@freebsd.org> <4991DB1F.7060809@freebsd.org> <499B1E7B.2030908@freebsd.org> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-DCC-Rhyolite-Metrics: ebb.errno.com; whitelist Cc: freebsd-mobile@freebsd.org Subject: Re: Problems with ath at kern.hz=100 X-BeenThere: freebsd-mobile@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile computing with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2009 16:21:13 -0000 Bengt Ahlgren wrote: > Bengt Ahlgren writes: > > >> Sam Leffler writes: >> >> >>> Bengt Ahlgren wrote: >>> >>>> Sam Leffler writes: >>>> >>>> [...] >>>> >>>> >>>> >>>>> You've removed all the context of the original problem; I can't recall >>>>> what you were trying to fix. The ps q drops might be caused by a bug >>>>> that was fixed (I think in RELENG_7). I don't see what version of >>>>> code you're running so can't tell. >>>>> >>>>> >>>> Sorry, a summary of the problem: >>>> >>>> The system frequently comes into a state where outgoing packets are >>>> held somewhere. The condition persists for seconds to minutes. It >>>> goes away by itself, but some of the packets are usually lost. This >>>> occurs on ath, FreeBSD 7.1-REL, no SMP, with kern.hz=100 (but not with >>>> hz=1000). Original mail with description can be found here: >>>> >>>> http://lists.freebsd.org/pipermail/freebsd-mobile/2009-February/011343.html >>>> >>>> I have done some more investigation, inserting debug prints in >>>> ath_start (if_ath.c 1.177.2.2.2.1), one just after IFQ_DRV_DEQUEUE >>>> (line 1576), another just before the call to ieee80211_pwrsave (line >>>> 1614). >>>> >>>> Packets are dequeued, but ieee80211_pwrsave is called and nothing >>>> happens. Below is the output from "athdebug xmit" with these extra >>>> two DPRINTF:s during the queue-up. Then after a while packets are >>>> sent again. >>>> >>>> Bengt >>>> >>>> >>>> >>> <...debug output removed...> >>> >>> Did you try RELENG_7? ap mode power save was fixed post 7.1 release. >>> >> I can do that, but I am not using ap mode. Will it still be useful? >> > > No changes were made related to sta mode. > Hmm, I see no difference in ath between 7.1-REL and RELENG_7 (besides > CVS ID strings)??? Are you meaning HEAD? If so, can I just drop in > src/sys/dev/ath from HEAD in 7.1R? > Code in HEAD is totally different. Sam From owner-freebsd-mobile@FreeBSD.ORG Wed Feb 18 18:18:06 2009 Return-Path: Delivered-To: freebsd-mobile@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BBA1510656D9; Wed, 18 Feb 2009 18:18:06 +0000 (UTC) (envelope-from bengta@P142.sics.se) Received: from sink.sics.se (sink.sics.se [193.10.64.88]) by mx1.freebsd.org (Postfix) with ESMTP id 0BACC8FC1E; Wed, 18 Feb 2009 18:18:05 +0000 (UTC) (envelope-from bengta@P142.sics.se) Received: from P142.sics.se (P142.sics.se [193.10.66.253]) by sink.sics.se (8.14.3/8.14.3) with ESMTP id n1IIHuee063908 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 18 Feb 2009 19:17:56 +0100 (CET) (envelope-from bengta@P142.sics.se) Received: from P142.sics.se (localhost [127.0.0.1]) by P142.sics.se (8.14.3/8.14.3) with ESMTP id n1IIK23K001500; Wed, 18 Feb 2009 19:20:02 +0100 (CET) (envelope-from bengta@P142.sics.se) Received: (from bengta@localhost) by P142.sics.se (8.14.3/8.14.3/Submit) id n1IIK1JS001499; Wed, 18 Feb 2009 19:20:01 +0100 (CET) (envelope-from bengta@P142.sics.se) To: Sam Leffler From: Bengt Ahlgren In-Reply-To: (Bengt Ahlgren's message of "Wed\, 18 Feb 2009 14\:25\:11 +0100") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (berkeley-unix) References: <20090210154047.N38905@sola.nimnet.asn.au> <4991ABA0.4050300@freebsd.org> <4991DB1F.7060809@freebsd.org> <499B1E7B.2030908@freebsd.org> Date: Wed, 18 Feb 2009 19:20:01 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: freebsd-mobile@freebsd.org Subject: Re: Problems with ath at kern.hz=100 X-BeenThere: freebsd-mobile@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile computing with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2009 18:18:07 -0000 Bengt Ahlgren writes: > Bengt Ahlgren writes: > >> Sam Leffler writes: >> >>> Bengt Ahlgren wrote: >>>> Sam Leffler writes: >>>> >>>> [...] >>>> >>>> >>>>> You've removed all the context of the original problem; I can't recall >>>>> what you were trying to fix. The ps q drops might be caused by a bug >>>>> that was fixed (I think in RELENG_7). I don't see what version of >>>>> code you're running so can't tell. >>>>> >>>> >>>> Sorry, a summary of the problem: >>>> >>>> The system frequently comes into a state where outgoing packets are >>>> held somewhere. The condition persists for seconds to minutes. It >>>> goes away by itself, but some of the packets are usually lost. This >>>> occurs on ath, FreeBSD 7.1-REL, no SMP, with kern.hz=100 (but not with >>>> hz=1000). Original mail with description can be found here: >>>> >>>> http://lists.freebsd.org/pipermail/freebsd-mobile/2009-February/011343.html >>>> >>>> I have done some more investigation, inserting debug prints in >>>> ath_start (if_ath.c 1.177.2.2.2.1), one just after IFQ_DRV_DEQUEUE >>>> (line 1576), another just before the call to ieee80211_pwrsave (line >>>> 1614). >>>> >>>> Packets are dequeued, but ieee80211_pwrsave is called and nothing >>>> happens. Below is the output from "athdebug xmit" with these extra >>>> two DPRINTF:s during the queue-up. Then after a while packets are >>>> sent again. >>>> >>>> Bengt >>>> >>>> >>> <...debug output removed...> >>> >>> Did you try RELENG_7? ap mode power save was fixed post 7.1 release. >> >> I can do that, but I am not using ap mode. Will it still be useful? > > Hmm, I see no difference in ath between 7.1-REL and RELENG_7 (besides > CVS ID strings)??? Are you meaning HEAD? If so, can I just drop in > src/sys/dev/ath from HEAD in 7.1R? You are meaning sys/net80211, right? I dropped the RELENG_7 version of that into my 7.1-REL tree: # ident /boot/kernel/kernel | grep ieee80211_power $FreeBSD: src/sys/net80211/ieee80211_power.c,v 1.2.2.1 2009/01/26 20:24:04 dwhite Exp $ but there is no difference. ifconfig shows that powersavemode is off, and it can't be turned on either. Perhaps normal? # ifconfig -v ath0 ath0: flags=8843 metric 0 mtu 1500 ether 00:05:4e:4e:1f:c7 inet 193.10.66.253 netmask 0xfffffc00 broadcast 193.10.67.255 media: IEEE 802.11 Wireless Ethernet autoselect (OFDM/36Mbps) status: associated ssid SICS channel 1 (2412 Mhz 11g) bssid 00:13:1a:47:7a:33 authmode OPEN privacy OFF deftxkey UNDEF powersavemode OFF powersavesleep 100 txpower 31.5 txpowmax 17.0 rtsthreshold 2346 fragthreshold 2346 bmiss 7 scanvalid 60 bgscan bgscanintvl 300 bgscanidle 250 roam:rssi11a 7 roam:rate11a 12 roam:rssi11b 7 roam:rate11b 1 roam:rssi11g 7 roam:rate11g 5 -pureg protmode CTS -ht -htcompat -ampdu ampdulimit 8k ampdudensity - -amsdu -shortgi htprotmode RTSCTS -puren -wme burst -ff -dturbo roaming AUTO bintval 100 # ifconfig ath0 powersave ifconfig: SIOCS80211: Invalid argument OK, now what? I turned on "wlandebug power+state" which revealed this during packet queueup. There is one second between each frame (ping packets): ath0: [00:13:1a:47:7a:33] sta power save mode on ath0: [00:13:1a:47:7a:33] save frame with age 40, 1 now queued ath0: [00:13:1a:47:7a:33] save frame with age 0, 2 now queued ath0: [00:13:1a:47:7a:33] save frame with age 0, 3 now queued ath0: [00:13:1a:47:7a:33] save frame with age 0, 4 now queued ath0: [00:13:1a:47:7a:33] save frame with age 0, 5 now queued ath0: [00:13:1a:47:7a:33] save frame with age 0, 6 now queued ath0: [00:13:1a:47:7a:33] save frame with age 0, 7 now queued ath0: [00:13:1a:47:7a:33] save frame with age 0, 8 now queued ath0: [00:13:1a:47:7a:33] save frame with age 0, 9 now queued ath0: [00:13:1a:47:7a:33] save frame with age 0, 10 now queued ath0: [00:13:1a:47:7a:33] save frame with age 0, 11 now queued ath0: [00:13:1a:47:7a:33] save frame with age 0, 12 now queued ath0: [00:13:1a:47:7a:33] save frame with age 0, 13 now queued ath0: [00:13:1a:47:7a:33] save frame with age 0, 14 now queued ath0: [00:13:1a:47:7a:33] save frame with age 0, 15 now queued ath0: [00:13:1a:47:7a:33] save frame with age 0, 16 now queued ath0: [00:13:1a:47:7a:33] save frame with age 0, 17 now queued ath0: [00:13:1a:47:7a:33] save frame with age 0, 18 now queued ath0: [00:13:1a:47:7a:33] save frame with age 0, 19 now queued ath0: [00:13:1a:47:7a:33] save frame with age 0, 20 now queued ath0: [00:13:1a:47:7a:33] save frame with age 0, 21 now queued ath0: [00:13:1a:47:7a:33] save frame with age 0, 22 now queued ath0: [00:13:1a:47:7a:33] save frame with age 0, 23 now queued ath0: [00:13:1a:47:7a:33] save frame with age 0, 24 now queued ath0: [00:13:1a:47:7a:33] save frame with age 0, 25 now queued ath0: [00:13:1a:47:7a:33] save frame with age 0, 26 now queued ath0: [00:13:1a:47:7a:33] save frame with age 0, 27 now queued ath0: [00:13:1a:47:7a:33] save frame with age 0, 28 now queued ath0: [00:13:1a:47:7a:33] save frame with age 0, 29 now queued ath0: [00:13:1a:47:7a:33] save frame with age 0, 30 now queued ath0: [00:13:1a:47:7a:33] save frame with age 0, 31 now queued ath0: [00:13:1a:47:7a:33] save frame with age 0, 32 now queued ath0: [00:13:1a:47:7a:33] sta power save mode off ath0: [00:13:1a:47:7a:33] flush ps queue, 32 packets queued After reading some code, trying with "wlanstats scan", both at hz=100 and 1000, I discovered that while it is scanning, it uses the power save logic to hold packets. But something goes wrong when hz is too low. Below is the printout of the log for a full scan with "wlanstats scan+power+state". It takes several minutes because it halts after several "scan_next: stopped". So, the scanning is the culprit. I bet that there is a race condition in the scanning logic! One thing to note is that callout_reset is called with ticks=0 in several places. That will be interpreted as 1, that is, the callout won't be called immediately, but at the next clock tick. Bengt ath0: ieee80211_bg_scan: active scan, ticks 84796 duration 15 ath0: [00:13:1a:47:7a:33] sta power save mode on ath0: scan_next: chan 1g -> 1g [active, dwell min 2 max 15] ath0: ieee80211_add_scan: chan 1g min dwell met (84799 > 84799) ath0: scan_next: chan 1g -> 6g [active, dwell min 2 max 12] ath0: ieee80211_add_scan: chan 6g min dwell met (84802 > 84802) ath0: scan_next: chan 6g -> 11g [active, dwell min 2 max 9] ath0: ieee80211_add_scan: chan 11g min dwell met (84807 > 84805) ath0: scan_next: chan 11g -> 7g [active, dwell min 2 max 4] ath0: scan_next: stopped, [ticks 84812, dwell min 2 scanend 84812] ath0: ieee80211_bg_scan: active scan, ticks 87315 duration 15 ath0: scan_next: chan 1g -> 13g [passive, dwell min 2 max 14] ath0: scan_next: stopped, [ticks 87330, dwell min 2 scanend 87330] ath0: ieee80211_bg_scan: active scan, ticks 87335 duration 15 ath0: scan_next: chan 1g -> 52a [passive, dwell min 2 max 14] ath0: scan_next: stopped, [ticks 87350, dwell min 2 scanend 87350] ath0: ieee80211_bg_scan: active scan, ticks 87356 duration 15 ath0: scan_next: chan 1g -> 56a [passive, dwell min 2 max 14] ath0: scan_next: stopped, [ticks 87371, dwell min 2 scanend 87371] ath0: ieee80211_bg_scan: active scan, ticks 87377 duration 15 ath0: scan_next: chan 1g -> 60a [passive, dwell min 2 max 14] ath0: scan_next: stopped, [ticks 87392, dwell min 2 scanend 87392] ath0: ieee80211_bg_scan: active scan, ticks 87397 duration 15 ath0: scan_next: chan 1g -> 64a [passive, dwell min 2 max 14] ath0: scan_next: stopped, [ticks 87412, dwell min 2 scanend 87412] ath0: ieee80211_bg_scan: active scan, ticks 87478 duration 15 ath0: scan_next: chan 1g -> 36a [passive, dwell min 2 max 14] ath0: scan_next: stopped, [ticks 87493, dwell min 2 scanend 87493] ath0: ieee80211_bg_scan: active scan, ticks 87499 duration 15 ath0: scan_next: chan 1g -> 40a [passive, dwell min 2 max 14] ath0: scan_next: stopped, [ticks 87514, dwell min 2 scanend 87514] ath0: ieee80211_bg_scan: active scan, ticks 87519 duration 15 ath0: scan_next: chan 1g -> 44a [passive, dwell min 2 max 14] ath0: scan_next: stopped, [ticks 87534, dwell min 2 scanend 87534] ath0: ieee80211_bg_scan: active scan, ticks 87540 duration 15 ath0: scan_next: chan 1g -> 48a [passive, dwell min 2 max 14] ath0: scan_next: stopped, [ticks 87555, dwell min 2 scanend 87555] ath0: ieee80211_bg_scan: active scan, ticks 87560 duration 15 ath0: scan_next: chan 1g -> 34a [passive, dwell min 2 max 14] ath0: scan_next: stopped, [ticks 87575, dwell min 2 scanend 87575] ath0: ieee80211_bg_scan: active scan, ticks 87581 duration 15 ath0: scan_next: chan 1g -> 38a [passive, dwell min 2 max 14] ath0: scan_next: stopped, [ticks 87596, dwell min 2 scanend 87596] ath0: ieee80211_bg_scan: active scan, ticks 87601 duration 15 ath0: scan_next: chan 1g -> 42a [passive, dwell min 2 max 14] ath0: scan_next: stopped, [ticks 87616, dwell min 2 scanend 87616] ath0: ieee80211_bg_scan: active scan, ticks 87622 duration 15 ath0: scan_next: chan 1g -> 46a [passive, dwell min 2 max 14] ath0: scan_next: stopped, [ticks 87637, dwell min 2 scanend 87637] ath0: ieee80211_bg_scan: active scan, ticks 87642 duration 15 ath0: scan_next: chan 1g -> 2g [active, dwell min 2 max 14] ath0: scan_next: stopped, [ticks 87657, dwell min 2 scanend 87657] ath0: ieee80211_bg_scan: active scan, ticks 90151 duration 15 ath0: scan_next: chan 1g -> 3g [active, dwell min 2 max 14] ath0: scan_next: stopped, [ticks 90166, dwell min 2 scanend 90166] ath0: ieee80211_bg_scan: active scan, ticks 92660 duration 15 ath0: scan_next: chan 1g -> 4g [active, dwell min 2 max 14] ath0: scan_next: stopped, [ticks 92675, dwell min 2 scanend 92675] ath0: beacon miss ath0: ieee80211_bg_scan: active scan, ticks 95271 duration 15 ath0: scan_next: chan 1g -> 5g [active, dwell min 2 max 14] ath0: scan_next: stopped, [ticks 95286, dwell min 2 scanend 95286] ath0: beacon miss ath0: ieee80211_bg_scan: active scan, ticks 99715 duration 15 ath0: scan_next: chan 1g -> 8g [active, dwell min 2 max 14] ath0: scan_next: stopped, [ticks 99730, dwell min 2 scanend 99730] ath0: ieee80211_bg_scan: active scan, ticks 102224 duration 15 ath0: scan_next: chan 1g -> 9g [active, dwell min 2 max 14] ath0: scan_next: stopped, [ticks 102239, dwell min 2 scanend 102239] ath0: ieee80211_bg_scan: active scan, ticks 104732 duration 15 ath0: scan_next: chan 1g -> 10g [active, dwell min 2 max 14] ath0: scan_next: stopped, [ticks 104747, dwell min 2 scanend 104747] ath0: ieee80211_bg_scan: active scan, ticks 107241 duration 15 ath0: scan_next: chan 1g -> 12g [passive, dwell min 2 max 14] ath0: scan_next: stopped, [ticks 107256, dwell min 2 scanend 107256] ath0: ieee80211_bg_scan: active scan, ticks 107263 duration 15 ath0: scan_next: chan 1g -> 14b [passive, dwell min 2 max 14] ath0: scan_next: stopped, [ticks 107278, dwell min 2 scanend 107278] ath0: ieee80211_bg_scan: active scan, ticks 107282 duration 15 ath0: scan_next: chan 1g -> 149a [passive, dwell min 2 max 14] ath0: scan_next: stopped, [ticks 107297, dwell min 2 scanend 107297] ath0: ieee80211_bg_scan: active scan, ticks 107303 duration 15 ath0: scan_next: chan 1g -> 153a [passive, dwell min 2 max 14] ath0: scan_next: stopped, [ticks 107318, dwell min 2 scanend 107318] ath0: ieee80211_bg_scan: active scan, ticks 107323 duration 15 ath0: scan_next: chan 1g -> 157a [passive, dwell min 2 max 14] ath0: scan_next: stopped, [ticks 107338, dwell min 2 scanend 107338] ath0: ieee80211_bg_scan: active scan, ticks 107344 duration 15 ath0: scan_next: chan 1g -> 161a [passive, dwell min 2 max 14] ath0: scan_next: stopped, [ticks 107359, dwell min 2 scanend 107359] ath0: ieee80211_bg_scan: active scan, ticks 107366 duration 15 ath0: scan_next: chan 1g -> 165a [passive, dwell min 2 max 14] ath0: scan_next: stopped, [ticks 107381, dwell min 2 scanend 107381] ath0: ieee80211_bg_scan: active scan, ticks 107385 duration 15 ath0: scan_next: chan 1g -> 100a [passive, dwell min 2 max 14] ath0: scan_next: stopped, [ticks 107400, dwell min 2 scanend 107400] ath0: ieee80211_bg_scan: active scan, ticks 107405 duration 15 ath0: scan_next: chan 1g -> 104a [passive, dwell min 2 max 14] ath0: scan_next: stopped, [ticks 107420, dwell min 2 scanend 107420] ath0: ieee80211_bg_scan: active scan, ticks 107426 duration 15 ath0: scan_next: chan 1g -> 108a [passive, dwell min 2 max 14] ath0: scan_next: stopped, [ticks 107441, dwell min 2 scanend 107441] ath0: ieee80211_bg_scan: active scan, ticks 107446 duration 15 ath0: scan_next: chan 1g -> 112a [passive, dwell min 2 max 14] ath0: scan_next: stopped, [ticks 107461, dwell min 2 scanend 107461] ath0: ieee80211_bg_scan: active scan, ticks 107467 duration 15 ath0: scan_next: chan 1g -> 116a [passive, dwell min 2 max 14] ath0: scan_next: stopped, [ticks 107482, dwell min 2 scanend 107482] ath0: ieee80211_bg_scan: active scan, ticks 107487 duration 15 ath0: scan_next: chan 1g -> 120a [passive, dwell min 2 max 14] ath0: scan_next: stopped, [ticks 107502, dwell min 2 scanend 107502] ath0: ieee80211_bg_scan: active scan, ticks 107507 duration 15 ath0: scan_next: chan 1g -> 124a [passive, dwell min 2 max 14] ath0: scan_next: stopped, [ticks 107522, dwell min 2 scanend 107522] ath0: ieee80211_bg_scan: active scan, ticks 107528 duration 15 ath0: scan_next: chan 1g -> 128a [passive, dwell min 2 max 14] ath0: scan_next: stopped, [ticks 107543, dwell min 2 scanend 107543] ath0: ieee80211_bg_scan: active scan, ticks 107548 duration 15 ath0: scan_next: chan 1g -> 132a [passive, dwell min 2 max 14] ath0: scan_next: stopped, [ticks 107563, dwell min 2 scanend 107563] ath0: ieee80211_bg_scan: active scan, ticks 107569 duration 15 ath0: scan_next: chan 1g -> 136a [passive, dwell min 2 max 14] ath0: scan_next: stopped, [ticks 107584, dwell min 2 scanend 107584] ath0: ieee80211_bg_scan: active scan, ticks 107589 duration 15 ath0: scan_next: chan 1g -> 140a [passive, dwell min 2 max 14] ath0: scan_next: done, [ticks 107604, dwell min 2 scanend 107604] ath0: [00:13:1a:47:7a:33] sta power save mode off ath0: notify scan done From owner-freebsd-mobile@FreeBSD.ORG Wed Feb 18 18:27:39 2009 Return-Path: Delivered-To: freebsd-mobile@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F34C1106566B for ; Wed, 18 Feb 2009 18:27:38 +0000 (UTC) (envelope-from sam@freebsd.org) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.freebsd.org (Postfix) with ESMTP id 827008FC1D for ; Wed, 18 Feb 2009 18:27:38 +0000 (UTC) (envelope-from sam@freebsd.org) Received: from trouble.errno.com (trouble.errno.com [10.0.0.248]) (authenticated bits=0) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id n1IIRb3a085822 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 18 Feb 2009 10:27:38 -0800 (PST) (envelope-from sam@freebsd.org) Message-ID: <499C5319.10306@freebsd.org> Date: Wed, 18 Feb 2009 10:27:37 -0800 From: Sam Leffler Organization: FreeBSD Project User-Agent: Thunderbird 2.0.0.18 (X11/20081209) MIME-Version: 1.0 To: Bengt Ahlgren References: <20090210154047.N38905@sola.nimnet.asn.au> <4991ABA0.4050300@freebsd.org> <4991DB1F.7060809@freebsd.org> <499B1E7B.2030908@freebsd.org> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-DCC-Rhyolite-Metrics: ebb.errno.com; whitelist Cc: freebsd-mobile@freebsd.org Subject: Re: Problems with ath at kern.hz=100 X-BeenThere: freebsd-mobile@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile computing with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2009 18:27:39 -0000 Bengt Ahlgren wrote: > Bengt Ahlgren writes: > > >> Bengt Ahlgren writes: >> >> >>> Sam Leffler writes: >>> >>> >>>> Bengt Ahlgren wrote: >>>> >>>>> Sam Leffler writes: >>>>> >>>>> [...] >>>>> >>>>> >>>>> >>>>>> You've removed all the context of the original problem; I can't recall >>>>>> what you were trying to fix. The ps q drops might be caused by a bug >>>>>> that was fixed (I think in RELENG_7). I don't see what version of >>>>>> code you're running so can't tell. >>>>>> >>>>>> >>>>> Sorry, a summary of the problem: >>>>> >>>>> The system frequently comes into a state where outgoing packets are >>>>> held somewhere. The condition persists for seconds to minutes. It >>>>> goes away by itself, but some of the packets are usually lost. This >>>>> occurs on ath, FreeBSD 7.1-REL, no SMP, with kern.hz=100 (but not with >>>>> hz=1000). Original mail with description can be found here: >>>>> >>>>> http://lists.freebsd.org/pipermail/freebsd-mobile/2009-February/011343.html >>>>> >>>>> I have done some more investigation, inserting debug prints in >>>>> ath_start (if_ath.c 1.177.2.2.2.1), one just after IFQ_DRV_DEQUEUE >>>>> (line 1576), another just before the call to ieee80211_pwrsave (line >>>>> 1614). >>>>> >>>>> Packets are dequeued, but ieee80211_pwrsave is called and nothing >>>>> happens. Below is the output from "athdebug xmit" with these extra >>>>> two DPRINTF:s during the queue-up. Then after a while packets are >>>>> sent again. >>>>> >>>>> Bengt >>>>> >>>>> >>>>> >>>> <...debug output removed...> >>>> >>>> Did you try RELENG_7? ap mode power save was fixed post 7.1 release. >>>> >>> I can do that, but I am not using ap mode. Will it still be useful? >>> >> Hmm, I see no difference in ath between 7.1-REL and RELENG_7 (besides >> CVS ID strings)??? Are you meaning HEAD? If so, can I just drop in >> src/sys/dev/ath from HEAD in 7.1R? >> > > You are meaning sys/net80211, right? I dropped the RELENG_7 version > of that into my 7.1-REL tree: > > # ident /boot/kernel/kernel | grep ieee80211_power > $FreeBSD: src/sys/net80211/ieee80211_power.c,v 1.2.2.1 2009/01/26 20:24:04 dwhite Exp $ > > but there is no difference. ifconfig shows that powersavemode is off, > and it can't be turned on either. Perhaps normal? > Yes, there is no sta mode power save support for ath (or any other driver that depends on net80211 for doing it). > # ifconfig -v ath0 > ath0: flags=8843 metric 0 mtu 1500 > ether 00:05:4e:4e:1f:c7 > inet 193.10.66.253 netmask 0xfffffc00 broadcast 193.10.67.255 > media: IEEE 802.11 Wireless Ethernet autoselect (OFDM/36Mbps) > status: associated > ssid SICS channel 1 (2412 Mhz 11g) bssid 00:13:1a:47:7a:33 > authmode OPEN privacy OFF deftxkey UNDEF powersavemode OFF > powersavesleep 100 txpower 31.5 txpowmax 17.0 rtsthreshold 2346 > fragthreshold 2346 bmiss 7 scanvalid 60 bgscan bgscanintvl 300 > bgscanidle 250 roam:rssi11a 7 roam:rate11a 12 roam:rssi11b 7 > roam:rate11b 1 roam:rssi11g 7 roam:rate11g 5 -pureg protmode CTS -ht > -htcompat -ampdu ampdulimit 8k ampdudensity - -amsdu -shortgi > htprotmode RTSCTS -puren -wme burst -ff -dturbo roaming AUTO > bintval 100 > > # ifconfig ath0 powersave > ifconfig: SIOCS80211: Invalid argument > > OK, now what? I turned on "wlandebug power+state" which revealed this > during packet queueup. There is one second between each frame (ping > packets): > > ath0: [00:13:1a:47:7a:33] sta power save mode on > ath0: [00:13:1a:47:7a:33] save frame with age 40, 1 now queued > ath0: [00:13:1a:47:7a:33] save frame with age 0, 2 now queued > ath0: [00:13:1a:47:7a:33] save frame with age 0, 3 now queued > ath0: [00:13:1a:47:7a:33] save frame with age 0, 4 now queued > ath0: [00:13:1a:47:7a:33] save frame with age 0, 5 now queued > ath0: [00:13:1a:47:7a:33] save frame with age 0, 6 now queued > ath0: [00:13:1a:47:7a:33] save frame with age 0, 7 now queued > ath0: [00:13:1a:47:7a:33] save frame with age 0, 8 now queued > ath0: [00:13:1a:47:7a:33] save frame with age 0, 9 now queued > ath0: [00:13:1a:47:7a:33] save frame with age 0, 10 now queued > ath0: [00:13:1a:47:7a:33] save frame with age 0, 11 now queued > ath0: [00:13:1a:47:7a:33] save frame with age 0, 12 now queued > ath0: [00:13:1a:47:7a:33] save frame with age 0, 13 now queued > ath0: [00:13:1a:47:7a:33] save frame with age 0, 14 now queued > ath0: [00:13:1a:47:7a:33] save frame with age 0, 15 now queued > ath0: [00:13:1a:47:7a:33] save frame with age 0, 16 now queued > ath0: [00:13:1a:47:7a:33] save frame with age 0, 17 now queued > ath0: [00:13:1a:47:7a:33] save frame with age 0, 18 now queued > ath0: [00:13:1a:47:7a:33] save frame with age 0, 19 now queued > ath0: [00:13:1a:47:7a:33] save frame with age 0, 20 now queued > ath0: [00:13:1a:47:7a:33] save frame with age 0, 21 now queued > ath0: [00:13:1a:47:7a:33] save frame with age 0, 22 now queued > ath0: [00:13:1a:47:7a:33] save frame with age 0, 23 now queued > ath0: [00:13:1a:47:7a:33] save frame with age 0, 24 now queued > ath0: [00:13:1a:47:7a:33] save frame with age 0, 25 now queued > ath0: [00:13:1a:47:7a:33] save frame with age 0, 26 now queued > ath0: [00:13:1a:47:7a:33] save frame with age 0, 27 now queued > ath0: [00:13:1a:47:7a:33] save frame with age 0, 28 now queued > ath0: [00:13:1a:47:7a:33] save frame with age 0, 29 now queued > ath0: [00:13:1a:47:7a:33] save frame with age 0, 30 now queued > ath0: [00:13:1a:47:7a:33] save frame with age 0, 31 now queued > ath0: [00:13:1a:47:7a:33] save frame with age 0, 32 now queued > ath0: [00:13:1a:47:7a:33] sta power save mode off > ath0: [00:13:1a:47:7a:33] flush ps queue, 32 packets queued > > After reading some code, trying with "wlanstats scan", both at hz=100 > and 1000, I discovered that while it is scanning, it uses the power > save logic to hold packets. But something goes wrong when hz is too > low. > The ap is told the sta is in power save while off channel but scanning should return to the bss channel often to collect frames the ap might have buffered for it. Also any bg scan should be canceled if there are outbound frames; it appears from the above this is not happening. > Below is the printout of the log for a full scan with "wlanstats > scan+power+state". It takes several minutes because it halts after > several "scan_next: stopped". So, the scanning is the culprit. I bet > that there is a race condition in the scanning logic! > > One thing to note is that callout_reset is called with ticks=0 in > several places. That will be interpreted as 1, that is, the callout > won't be called immediately, but at the next clock tick. > > Bengt > > ath0: ieee80211_bg_scan: active scan, ticks 84796 duration 15 > ath0: [00:13:1a:47:7a:33] sta power save mode on > ath0: scan_next: chan 1g -> 1g [active, dwell min 2 max 15] > ath0: ieee80211_add_scan: chan 1g min dwell met (84799 > 84799) > ath0: scan_next: chan 1g -> 6g [active, dwell min 2 max 12] > ath0: ieee80211_add_scan: chan 6g min dwell met (84802 > 84802) > ath0: scan_next: chan 6g -> 11g [active, dwell min 2 max 9] > ath0: ieee80211_add_scan: chan 11g min dwell met (84807 > 84805) > ath0: scan_next: chan 11g -> 7g [active, dwell min 2 max 4] > ath0: scan_next: stopped, [ticks 84812, dwell min 2 scanend 84812] > ath0: ieee80211_bg_scan: active scan, ticks 87315 duration 15 > ath0: scan_next: chan 1g -> 13g [passive, dwell min 2 max 14] > ath0: scan_next: stopped, [ticks 87330, dwell min 2 scanend 87330] > ath0: ieee80211_bg_scan: active scan, ticks 87335 duration 15 > ath0: scan_next: chan 1g -> 52a [passive, dwell min 2 max 14] > ath0: scan_next: stopped, [ticks 87350, dwell min 2 scanend 87350] > ath0: ieee80211_bg_scan: active scan, ticks 87356 duration 15 > ath0: scan_next: chan 1g -> 56a [passive, dwell min 2 max 14] > ath0: scan_next: stopped, [ticks 87371, dwell min 2 scanend 87371] > ath0: ieee80211_bg_scan: active scan, ticks 87377 duration 15 > ath0: scan_next: chan 1g -> 60a [passive, dwell min 2 max 14] > ath0: scan_next: stopped, [ticks 87392, dwell min 2 scanend 87392] > ath0: ieee80211_bg_scan: active scan, ticks 87397 duration 15 > ath0: scan_next: chan 1g -> 64a [passive, dwell min 2 max 14] > ath0: scan_next: stopped, [ticks 87412, dwell min 2 scanend 87412] > ath0: ieee80211_bg_scan: active scan, ticks 87478 duration 15 > ath0: scan_next: chan 1g -> 36a [passive, dwell min 2 max 14] > ath0: scan_next: stopped, [ticks 87493, dwell min 2 scanend 87493] > ath0: ieee80211_bg_scan: active scan, ticks 87499 duration 15 > ath0: scan_next: chan 1g -> 40a [passive, dwell min 2 max 14] > ath0: scan_next: stopped, [ticks 87514, dwell min 2 scanend 87514] > ath0: ieee80211_bg_scan: active scan, ticks 87519 duration 15 > ath0: scan_next: chan 1g -> 44a [passive, dwell min 2 max 14] > ath0: scan_next: stopped, [ticks 87534, dwell min 2 scanend 87534] > ath0: ieee80211_bg_scan: active scan, ticks 87540 duration 15 > ath0: scan_next: chan 1g -> 48a [passive, dwell min 2 max 14] > ath0: scan_next: stopped, [ticks 87555, dwell min 2 scanend 87555] > ath0: ieee80211_bg_scan: active scan, ticks 87560 duration 15 > ath0: scan_next: chan 1g -> 34a [passive, dwell min 2 max 14] > ath0: scan_next: stopped, [ticks 87575, dwell min 2 scanend 87575] > ath0: ieee80211_bg_scan: active scan, ticks 87581 duration 15 > ath0: scan_next: chan 1g -> 38a [passive, dwell min 2 max 14] > ath0: scan_next: stopped, [ticks 87596, dwell min 2 scanend 87596] > ath0: ieee80211_bg_scan: active scan, ticks 87601 duration 15 > ath0: scan_next: chan 1g -> 42a [passive, dwell min 2 max 14] > ath0: scan_next: stopped, [ticks 87616, dwell min 2 scanend 87616] > ath0: ieee80211_bg_scan: active scan, ticks 87622 duration 15 > ath0: scan_next: chan 1g -> 46a [passive, dwell min 2 max 14] > ath0: scan_next: stopped, [ticks 87637, dwell min 2 scanend 87637] > ath0: ieee80211_bg_scan: active scan, ticks 87642 duration 15 > ath0: scan_next: chan 1g -> 2g [active, dwell min 2 max 14] > ath0: scan_next: stopped, [ticks 87657, dwell min 2 scanend 87657] > ath0: ieee80211_bg_scan: active scan, ticks 90151 duration 15 > ath0: scan_next: chan 1g -> 3g [active, dwell min 2 max 14] > ath0: scan_next: stopped, [ticks 90166, dwell min 2 scanend 90166] > ath0: ieee80211_bg_scan: active scan, ticks 92660 duration 15 > ath0: scan_next: chan 1g -> 4g [active, dwell min 2 max 14] > ath0: scan_next: stopped, [ticks 92675, dwell min 2 scanend 92675] > ath0: beacon miss > ath0: ieee80211_bg_scan: active scan, ticks 95271 duration 15 > ath0: scan_next: chan 1g -> 5g [active, dwell min 2 max 14] > ath0: scan_next: stopped, [ticks 95286, dwell min 2 scanend 95286] > ath0: beacon miss > ath0: ieee80211_bg_scan: active scan, ticks 99715 duration 15 > ath0: scan_next: chan 1g -> 8g [active, dwell min 2 max 14] > ath0: scan_next: stopped, [ticks 99730, dwell min 2 scanend 99730] > ath0: ieee80211_bg_scan: active scan, ticks 102224 duration 15 > ath0: scan_next: chan 1g -> 9g [active, dwell min 2 max 14] > ath0: scan_next: stopped, [ticks 102239, dwell min 2 scanend 102239] > ath0: ieee80211_bg_scan: active scan, ticks 104732 duration 15 > ath0: scan_next: chan 1g -> 10g [active, dwell min 2 max 14] > ath0: scan_next: stopped, [ticks 104747, dwell min 2 scanend 104747] > ath0: ieee80211_bg_scan: active scan, ticks 107241 duration 15 > ath0: scan_next: chan 1g -> 12g [passive, dwell min 2 max 14] > ath0: scan_next: stopped, [ticks 107256, dwell min 2 scanend 107256] > ath0: ieee80211_bg_scan: active scan, ticks 107263 duration 15 > ath0: scan_next: chan 1g -> 14b [passive, dwell min 2 max 14] > ath0: scan_next: stopped, [ticks 107278, dwell min 2 scanend 107278] > ath0: ieee80211_bg_scan: active scan, ticks 107282 duration 15 > ath0: scan_next: chan 1g -> 149a [passive, dwell min 2 max 14] > ath0: scan_next: stopped, [ticks 107297, dwell min 2 scanend 107297] > ath0: ieee80211_bg_scan: active scan, ticks 107303 duration 15 > ath0: scan_next: chan 1g -> 153a [passive, dwell min 2 max 14] > ath0: scan_next: stopped, [ticks 107318, dwell min 2 scanend 107318] > ath0: ieee80211_bg_scan: active scan, ticks 107323 duration 15 > ath0: scan_next: chan 1g -> 157a [passive, dwell min 2 max 14] > ath0: scan_next: stopped, [ticks 107338, dwell min 2 scanend 107338] > ath0: ieee80211_bg_scan: active scan, ticks 107344 duration 15 > ath0: scan_next: chan 1g -> 161a [passive, dwell min 2 max 14] > ath0: scan_next: stopped, [ticks 107359, dwell min 2 scanend 107359] > ath0: ieee80211_bg_scan: active scan, ticks 107366 duration 15 > ath0: scan_next: chan 1g -> 165a [passive, dwell min 2 max 14] > ath0: scan_next: stopped, [ticks 107381, dwell min 2 scanend 107381] > ath0: ieee80211_bg_scan: active scan, ticks 107385 duration 15 > ath0: scan_next: chan 1g -> 100a [passive, dwell min 2 max 14] > ath0: scan_next: stopped, [ticks 107400, dwell min 2 scanend 107400] > ath0: ieee80211_bg_scan: active scan, ticks 107405 duration 15 > ath0: scan_next: chan 1g -> 104a [passive, dwell min 2 max 14] > ath0: scan_next: stopped, [ticks 107420, dwell min 2 scanend 107420] > ath0: ieee80211_bg_scan: active scan, ticks 107426 duration 15 > ath0: scan_next: chan 1g -> 108a [passive, dwell min 2 max 14] > ath0: scan_next: stopped, [ticks 107441, dwell min 2 scanend 107441] > ath0: ieee80211_bg_scan: active scan, ticks 107446 duration 15 > ath0: scan_next: chan 1g -> 112a [passive, dwell min 2 max 14] > ath0: scan_next: stopped, [ticks 107461, dwell min 2 scanend 107461] > ath0: ieee80211_bg_scan: active scan, ticks 107467 duration 15 > ath0: scan_next: chan 1g -> 116a [passive, dwell min 2 max 14] > ath0: scan_next: stopped, [ticks 107482, dwell min 2 scanend 107482] > ath0: ieee80211_bg_scan: active scan, ticks 107487 duration 15 > ath0: scan_next: chan 1g -> 120a [passive, dwell min 2 max 14] > ath0: scan_next: stopped, [ticks 107502, dwell min 2 scanend 107502] > ath0: ieee80211_bg_scan: active scan, ticks 107507 duration 15 > ath0: scan_next: chan 1g -> 124a [passive, dwell min 2 max 14] > ath0: scan_next: stopped, [ticks 107522, dwell min 2 scanend 107522] > ath0: ieee80211_bg_scan: active scan, ticks 107528 duration 15 > ath0: scan_next: chan 1g -> 128a [passive, dwell min 2 max 14] > ath0: scan_next: stopped, [ticks 107543, dwell min 2 scanend 107543] > ath0: ieee80211_bg_scan: active scan, ticks 107548 duration 15 > ath0: scan_next: chan 1g -> 132a [passive, dwell min 2 max 14] > ath0: scan_next: stopped, [ticks 107563, dwell min 2 scanend 107563] > ath0: ieee80211_bg_scan: active scan, ticks 107569 duration 15 > ath0: scan_next: chan 1g -> 136a [passive, dwell min 2 max 14] > ath0: scan_next: stopped, [ticks 107584, dwell min 2 scanend 107584] > ath0: ieee80211_bg_scan: active scan, ticks 107589 duration 15 > ath0: scan_next: chan 1g -> 140a [passive, dwell min 2 max 14] > ath0: scan_next: done, [ticks 107604, dwell min 2 scanend 107604] > ath0: [00:13:1a:47:7a:33] sta power save mode off > ath0: notify scan done > > The above looks wrong; the bg scan should leave the bss channel briefly then return to check for frames. Instead it appears it's never returning. Also any outbound packets should cause the bg scan to be canceled (look for ieee80211_cancel_scan in ath_start). Sam From owner-freebsd-mobile@FreeBSD.ORG Thu Feb 19 15:22:54 2009 Return-Path: Delivered-To: freebsd-mobile@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 697A41065670; Thu, 19 Feb 2009 15:22:54 +0000 (UTC) (envelope-from bengta@P142.sics.se) Received: from sink.sics.se (sink.sics.se [193.10.64.88]) by mx1.freebsd.org (Postfix) with ESMTP id 8337B8FC15; Thu, 19 Feb 2009 15:22:53 +0000 (UTC) (envelope-from bengta@P142.sics.se) Received: from P142.sics.se (P142.sics.se [193.10.66.253]) by sink.sics.se (8.14.3/8.14.3) with ESMTP id n1JFMfvL068428 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 19 Feb 2009 16:22:42 +0100 (CET) (envelope-from bengta@P142.sics.se) Received: from P142.sics.se (localhost [127.0.0.1]) by P142.sics.se (8.14.3/8.14.3) with ESMTP id n1JFOoQp002385; Thu, 19 Feb 2009 16:24:50 +0100 (CET) (envelope-from bengta@P142.sics.se) Received: (from bengta@localhost) by P142.sics.se (8.14.3/8.14.3/Submit) id n1JFOnTE002384; Thu, 19 Feb 2009 16:24:49 +0100 (CET) (envelope-from bengta@P142.sics.se) To: Sam Leffler From: Bengt Ahlgren In-Reply-To: <499C5319.10306@freebsd.org> (Sam Leffler's message of "Wed\, 18 Feb 2009 10\:27\:37 -0800") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (berkeley-unix) References: <20090210154047.N38905@sola.nimnet.asn.au> <4991ABA0.4050300@freebsd.org> <4991DB1F.7060809@freebsd.org> <499B1E7B.2030908@freebsd.org> <499C5319.10306@freebsd.org> Date: Thu, 19 Feb 2009 16:24:49 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: freebsd-mobile@freebsd.org Subject: Re: Problems with ath at kern.hz=100 X-BeenThere: freebsd-mobile@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile computing with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2009 15:22:54 -0000 Sam Leffler writes: > Bengt Ahlgren wrote: >> Bengt Ahlgren writes: >> >> >>> Bengt Ahlgren writes: >>> >>> >>>> Sam Leffler writes: >>>> >>>> >>>>> Bengt Ahlgren wrote: >>>>> >>>>>> Sam Leffler writes: >>>>>> >>>>>> [...] >>>>>> >>>>>> >>>>>>> You've removed all the context of the original problem; I can't recall >>>>>>> what you were trying to fix. The ps q drops might be caused by a bug >>>>>>> that was fixed (I think in RELENG_7). I don't see what version of >>>>>>> code you're running so can't tell. >>>>>>> >>>>>> Sorry, a summary of the problem: >>>>>> >>>>>> The system frequently comes into a state where outgoing packets are >>>>>> held somewhere. The condition persists for seconds to minutes. It >>>>>> goes away by itself, but some of the packets are usually lost. This >>>>>> occurs on ath, FreeBSD 7.1-REL, no SMP, with kern.hz=100 (but not with >>>>>> hz=1000). Original mail with description can be found here: >>>>>> >>>>>> http://lists.freebsd.org/pipermail/freebsd-mobile/2009-February/011343.html >>>>>> >>>>>> I have done some more investigation, inserting debug prints in >>>>>> ath_start (if_ath.c 1.177.2.2.2.1), one just after IFQ_DRV_DEQUEUE >>>>>> (line 1576), another just before the call to ieee80211_pwrsave (line >>>>>> 1614). >>>>>> >>>>>> Packets are dequeued, but ieee80211_pwrsave is called and nothing >>>>>> happens. Below is the output from "athdebug xmit" with these extra >>>>>> two DPRINTF:s during the queue-up. Then after a while packets are >>>>>> sent again. >>>>>> >>>>>> Bengt >>>>>> >>>>>> >>>>> <...debug output removed...> >>>>> >>>>> Did you try RELENG_7? ap mode power save was fixed post 7.1 release. >>>>> >>>> I can do that, but I am not using ap mode. Will it still be useful? >>>> >>> Hmm, I see no difference in ath between 7.1-REL and RELENG_7 (besides >>> CVS ID strings)??? Are you meaning HEAD? If so, can I just drop in >>> src/sys/dev/ath from HEAD in 7.1R? >>> >> >> You are meaning sys/net80211, right? I dropped the RELENG_7 version >> of that into my 7.1-REL tree: >> >> # ident /boot/kernel/kernel | grep ieee80211_power >> $FreeBSD: src/sys/net80211/ieee80211_power.c,v 1.2.2.1 2009/01/26 20:24:04 dwhite Exp $ >> >> but there is no difference. ifconfig shows that powersavemode is off, >> and it can't be turned on either. Perhaps normal? >> > > Yes, there is no sta mode power save support for ath (or any other > driver that depends on net80211 for doing it). > >> # ifconfig -v ath0 >> ath0: flags=8843 metric 0 mtu 1500 >> ether 00:05:4e:4e:1f:c7 >> inet 193.10.66.253 netmask 0xfffffc00 broadcast 193.10.67.255 >> media: IEEE 802.11 Wireless Ethernet autoselect (OFDM/36Mbps) >> status: associated >> ssid SICS channel 1 (2412 Mhz 11g) bssid 00:13:1a:47:7a:33 >> authmode OPEN privacy OFF deftxkey UNDEF powersavemode OFF >> powersavesleep 100 txpower 31.5 txpowmax 17.0 rtsthreshold 2346 >> fragthreshold 2346 bmiss 7 scanvalid 60 bgscan bgscanintvl 300 >> bgscanidle 250 roam:rssi11a 7 roam:rate11a 12 roam:rssi11b 7 >> roam:rate11b 1 roam:rssi11g 7 roam:rate11g 5 -pureg protmode CTS -ht >> -htcompat -ampdu ampdulimit 8k ampdudensity - -amsdu -shortgi >> htprotmode RTSCTS -puren -wme burst -ff -dturbo roaming AUTO >> bintval 100 >> >> # ifconfig ath0 powersave >> ifconfig: SIOCS80211: Invalid argument >> >> OK, now what? I turned on "wlandebug power+state" which revealed this >> during packet queueup. There is one second between each frame (ping >> packets): >> >> ath0: [00:13:1a:47:7a:33] sta power save mode on >> ath0: [00:13:1a:47:7a:33] save frame with age 40, 1 now queued >> ath0: [00:13:1a:47:7a:33] save frame with age 0, 2 now queued >> ath0: [00:13:1a:47:7a:33] save frame with age 0, 3 now queued >> ath0: [00:13:1a:47:7a:33] save frame with age 0, 4 now queued >> ath0: [00:13:1a:47:7a:33] save frame with age 0, 5 now queued >> ath0: [00:13:1a:47:7a:33] save frame with age 0, 6 now queued >> ath0: [00:13:1a:47:7a:33] save frame with age 0, 7 now queued >> ath0: [00:13:1a:47:7a:33] save frame with age 0, 8 now queued >> ath0: [00:13:1a:47:7a:33] save frame with age 0, 9 now queued >> ath0: [00:13:1a:47:7a:33] save frame with age 0, 10 now queued >> ath0: [00:13:1a:47:7a:33] save frame with age 0, 11 now queued >> ath0: [00:13:1a:47:7a:33] save frame with age 0, 12 now queued >> ath0: [00:13:1a:47:7a:33] save frame with age 0, 13 now queued >> ath0: [00:13:1a:47:7a:33] save frame with age 0, 14 now queued >> ath0: [00:13:1a:47:7a:33] save frame with age 0, 15 now queued >> ath0: [00:13:1a:47:7a:33] save frame with age 0, 16 now queued >> ath0: [00:13:1a:47:7a:33] save frame with age 0, 17 now queued >> ath0: [00:13:1a:47:7a:33] save frame with age 0, 18 now queued >> ath0: [00:13:1a:47:7a:33] save frame with age 0, 19 now queued >> ath0: [00:13:1a:47:7a:33] save frame with age 0, 20 now queued >> ath0: [00:13:1a:47:7a:33] save frame with age 0, 21 now queued >> ath0: [00:13:1a:47:7a:33] save frame with age 0, 22 now queued >> ath0: [00:13:1a:47:7a:33] save frame with age 0, 23 now queued >> ath0: [00:13:1a:47:7a:33] save frame with age 0, 24 now queued >> ath0: [00:13:1a:47:7a:33] save frame with age 0, 25 now queued >> ath0: [00:13:1a:47:7a:33] save frame with age 0, 26 now queued >> ath0: [00:13:1a:47:7a:33] save frame with age 0, 27 now queued >> ath0: [00:13:1a:47:7a:33] save frame with age 0, 28 now queued >> ath0: [00:13:1a:47:7a:33] save frame with age 0, 29 now queued >> ath0: [00:13:1a:47:7a:33] save frame with age 0, 30 now queued >> ath0: [00:13:1a:47:7a:33] save frame with age 0, 31 now queued >> ath0: [00:13:1a:47:7a:33] save frame with age 0, 32 now queued >> ath0: [00:13:1a:47:7a:33] sta power save mode off >> ath0: [00:13:1a:47:7a:33] flush ps queue, 32 packets queued >> >> After reading some code, trying with "wlanstats scan", both at hz=100 >> and 1000, I discovered that while it is scanning, it uses the power >> save logic to hold packets. But something goes wrong when hz is too >> low. >> > > The ap is told the sta is in power save while off channel but scanning > should return to the bss channel often to collect frames the ap might > have buffered for it. Also any bg scan should be canceled if there are > outbound frames; it appears from the above this is not happening. > >> Below is the printout of the log for a full scan with "wlanstats >> scan+power+state". It takes several minutes because it halts after >> several "scan_next: stopped". So, the scanning is the culprit. I bet >> that there is a race condition in the scanning logic! >> >> One thing to note is that callout_reset is called with ticks=0 in >> several places. That will be interpreted as 1, that is, the callout >> won't be called immediately, but at the next clock tick. >> >> Bengt >> >> ath0: ieee80211_bg_scan: active scan, ticks 84796 duration 15 >> ath0: [00:13:1a:47:7a:33] sta power save mode on >> ath0: scan_next: chan 1g -> 1g [active, dwell min 2 max 15] >> ath0: ieee80211_add_scan: chan 1g min dwell met (84799 > 84799) >> ath0: scan_next: chan 1g -> 6g [active, dwell min 2 max 12] >> ath0: ieee80211_add_scan: chan 6g min dwell met (84802 > 84802) >> ath0: scan_next: chan 6g -> 11g [active, dwell min 2 max 9] >> ath0: ieee80211_add_scan: chan 11g min dwell met (84807 > 84805) >> ath0: scan_next: chan 11g -> 7g [active, dwell min 2 max 4] >> ath0: scan_next: stopped, [ticks 84812, dwell min 2 scanend 84812] >> ath0: ieee80211_bg_scan: active scan, ticks 87315 duration 15 >> ath0: scan_next: chan 1g -> 13g [passive, dwell min 2 max 14] >> ath0: scan_next: stopped, [ticks 87330, dwell min 2 scanend 87330] >> ath0: ieee80211_bg_scan: active scan, ticks 87335 duration 15 >> ath0: scan_next: chan 1g -> 52a [passive, dwell min 2 max 14] >> ath0: scan_next: stopped, [ticks 87350, dwell min 2 scanend 87350] >> ath0: ieee80211_bg_scan: active scan, ticks 87356 duration 15 >> ath0: scan_next: chan 1g -> 56a [passive, dwell min 2 max 14] >> ath0: scan_next: stopped, [ticks 87371, dwell min 2 scanend 87371] >> ath0: ieee80211_bg_scan: active scan, ticks 87377 duration 15 >> ath0: scan_next: chan 1g -> 60a [passive, dwell min 2 max 14] >> ath0: scan_next: stopped, [ticks 87392, dwell min 2 scanend 87392] >> ath0: ieee80211_bg_scan: active scan, ticks 87397 duration 15 >> ath0: scan_next: chan 1g -> 64a [passive, dwell min 2 max 14] >> ath0: scan_next: stopped, [ticks 87412, dwell min 2 scanend 87412] >> ath0: ieee80211_bg_scan: active scan, ticks 87478 duration 15 >> ath0: scan_next: chan 1g -> 36a [passive, dwell min 2 max 14] >> ath0: scan_next: stopped, [ticks 87493, dwell min 2 scanend 87493] >> ath0: ieee80211_bg_scan: active scan, ticks 87499 duration 15 >> ath0: scan_next: chan 1g -> 40a [passive, dwell min 2 max 14] >> ath0: scan_next: stopped, [ticks 87514, dwell min 2 scanend 87514] >> ath0: ieee80211_bg_scan: active scan, ticks 87519 duration 15 >> ath0: scan_next: chan 1g -> 44a [passive, dwell min 2 max 14] >> ath0: scan_next: stopped, [ticks 87534, dwell min 2 scanend 87534] >> ath0: ieee80211_bg_scan: active scan, ticks 87540 duration 15 >> ath0: scan_next: chan 1g -> 48a [passive, dwell min 2 max 14] >> ath0: scan_next: stopped, [ticks 87555, dwell min 2 scanend 87555] >> ath0: ieee80211_bg_scan: active scan, ticks 87560 duration 15 >> ath0: scan_next: chan 1g -> 34a [passive, dwell min 2 max 14] >> ath0: scan_next: stopped, [ticks 87575, dwell min 2 scanend 87575] >> ath0: ieee80211_bg_scan: active scan, ticks 87581 duration 15 >> ath0: scan_next: chan 1g -> 38a [passive, dwell min 2 max 14] >> ath0: scan_next: stopped, [ticks 87596, dwell min 2 scanend 87596] >> ath0: ieee80211_bg_scan: active scan, ticks 87601 duration 15 >> ath0: scan_next: chan 1g -> 42a [passive, dwell min 2 max 14] >> ath0: scan_next: stopped, [ticks 87616, dwell min 2 scanend 87616] >> ath0: ieee80211_bg_scan: active scan, ticks 87622 duration 15 >> ath0: scan_next: chan 1g -> 46a [passive, dwell min 2 max 14] >> ath0: scan_next: stopped, [ticks 87637, dwell min 2 scanend 87637] >> ath0: ieee80211_bg_scan: active scan, ticks 87642 duration 15 >> ath0: scan_next: chan 1g -> 2g [active, dwell min 2 max 14] >> ath0: scan_next: stopped, [ticks 87657, dwell min 2 scanend 87657] >> ath0: ieee80211_bg_scan: active scan, ticks 90151 duration 15 >> ath0: scan_next: chan 1g -> 3g [active, dwell min 2 max 14] >> ath0: scan_next: stopped, [ticks 90166, dwell min 2 scanend 90166] >> ath0: ieee80211_bg_scan: active scan, ticks 92660 duration 15 >> ath0: scan_next: chan 1g -> 4g [active, dwell min 2 max 14] >> ath0: scan_next: stopped, [ticks 92675, dwell min 2 scanend 92675] >> ath0: beacon miss >> ath0: ieee80211_bg_scan: active scan, ticks 95271 duration 15 >> ath0: scan_next: chan 1g -> 5g [active, dwell min 2 max 14] >> ath0: scan_next: stopped, [ticks 95286, dwell min 2 scanend 95286] >> ath0: beacon miss >> ath0: ieee80211_bg_scan: active scan, ticks 99715 duration 15 >> ath0: scan_next: chan 1g -> 8g [active, dwell min 2 max 14] >> ath0: scan_next: stopped, [ticks 99730, dwell min 2 scanend 99730] >> ath0: ieee80211_bg_scan: active scan, ticks 102224 duration 15 >> ath0: scan_next: chan 1g -> 9g [active, dwell min 2 max 14] >> ath0: scan_next: stopped, [ticks 102239, dwell min 2 scanend 102239] >> ath0: ieee80211_bg_scan: active scan, ticks 104732 duration 15 >> ath0: scan_next: chan 1g -> 10g [active, dwell min 2 max 14] >> ath0: scan_next: stopped, [ticks 104747, dwell min 2 scanend 104747] >> ath0: ieee80211_bg_scan: active scan, ticks 107241 duration 15 >> ath0: scan_next: chan 1g -> 12g [passive, dwell min 2 max 14] >> ath0: scan_next: stopped, [ticks 107256, dwell min 2 scanend 107256] >> ath0: ieee80211_bg_scan: active scan, ticks 107263 duration 15 >> ath0: scan_next: chan 1g -> 14b [passive, dwell min 2 max 14] >> ath0: scan_next: stopped, [ticks 107278, dwell min 2 scanend 107278] >> ath0: ieee80211_bg_scan: active scan, ticks 107282 duration 15 >> ath0: scan_next: chan 1g -> 149a [passive, dwell min 2 max 14] >> ath0: scan_next: stopped, [ticks 107297, dwell min 2 scanend 107297] >> ath0: ieee80211_bg_scan: active scan, ticks 107303 duration 15 >> ath0: scan_next: chan 1g -> 153a [passive, dwell min 2 max 14] >> ath0: scan_next: stopped, [ticks 107318, dwell min 2 scanend 107318] >> ath0: ieee80211_bg_scan: active scan, ticks 107323 duration 15 >> ath0: scan_next: chan 1g -> 157a [passive, dwell min 2 max 14] >> ath0: scan_next: stopped, [ticks 107338, dwell min 2 scanend 107338] >> ath0: ieee80211_bg_scan: active scan, ticks 107344 duration 15 >> ath0: scan_next: chan 1g -> 161a [passive, dwell min 2 max 14] >> ath0: scan_next: stopped, [ticks 107359, dwell min 2 scanend 107359] >> ath0: ieee80211_bg_scan: active scan, ticks 107366 duration 15 >> ath0: scan_next: chan 1g -> 165a [passive, dwell min 2 max 14] >> ath0: scan_next: stopped, [ticks 107381, dwell min 2 scanend 107381] >> ath0: ieee80211_bg_scan: active scan, ticks 107385 duration 15 >> ath0: scan_next: chan 1g -> 100a [passive, dwell min 2 max 14] >> ath0: scan_next: stopped, [ticks 107400, dwell min 2 scanend 107400] >> ath0: ieee80211_bg_scan: active scan, ticks 107405 duration 15 >> ath0: scan_next: chan 1g -> 104a [passive, dwell min 2 max 14] >> ath0: scan_next: stopped, [ticks 107420, dwell min 2 scanend 107420] >> ath0: ieee80211_bg_scan: active scan, ticks 107426 duration 15 >> ath0: scan_next: chan 1g -> 108a [passive, dwell min 2 max 14] >> ath0: scan_next: stopped, [ticks 107441, dwell min 2 scanend 107441] >> ath0: ieee80211_bg_scan: active scan, ticks 107446 duration 15 >> ath0: scan_next: chan 1g -> 112a [passive, dwell min 2 max 14] >> ath0: scan_next: stopped, [ticks 107461, dwell min 2 scanend 107461] >> ath0: ieee80211_bg_scan: active scan, ticks 107467 duration 15 >> ath0: scan_next: chan 1g -> 116a [passive, dwell min 2 max 14] >> ath0: scan_next: stopped, [ticks 107482, dwell min 2 scanend 107482] >> ath0: ieee80211_bg_scan: active scan, ticks 107487 duration 15 >> ath0: scan_next: chan 1g -> 120a [passive, dwell min 2 max 14] >> ath0: scan_next: stopped, [ticks 107502, dwell min 2 scanend 107502] >> ath0: ieee80211_bg_scan: active scan, ticks 107507 duration 15 >> ath0: scan_next: chan 1g -> 124a [passive, dwell min 2 max 14] >> ath0: scan_next: stopped, [ticks 107522, dwell min 2 scanend 107522] >> ath0: ieee80211_bg_scan: active scan, ticks 107528 duration 15 >> ath0: scan_next: chan 1g -> 128a [passive, dwell min 2 max 14] >> ath0: scan_next: stopped, [ticks 107543, dwell min 2 scanend 107543] >> ath0: ieee80211_bg_scan: active scan, ticks 107548 duration 15 >> ath0: scan_next: chan 1g -> 132a [passive, dwell min 2 max 14] >> ath0: scan_next: stopped, [ticks 107563, dwell min 2 scanend 107563] >> ath0: ieee80211_bg_scan: active scan, ticks 107569 duration 15 >> ath0: scan_next: chan 1g -> 136a [passive, dwell min 2 max 14] >> ath0: scan_next: stopped, [ticks 107584, dwell min 2 scanend 107584] >> ath0: ieee80211_bg_scan: active scan, ticks 107589 duration 15 >> ath0: scan_next: chan 1g -> 140a [passive, dwell min 2 max 14] >> ath0: scan_next: done, [ticks 107604, dwell min 2 scanend 107604] >> ath0: [00:13:1a:47:7a:33] sta power save mode off >> ath0: notify scan done >> >> > The above looks wrong; the bg scan should leave the bss channel > briefly then return to check for frames. Instead it appears it's never > returning. Also any outbound packets should cause the bg scan to be > canceled (look for ieee80211_cancel_scan in ath_start). I think I am getting a bit closer to the real problem. Check out this sequence (run with hz=1000 NB!): ath0: scan_next: stopped, [ticks 14980883, dwell min 20 scanend 14980873] ath_start: dequeue packet 0xc38ef000 ath_start: power save, packet=0xc38ef000 ath0: [00:13:1a:47:7a:33] save frame with age 40, 1 now queued ath_start: dequeue packet 0x0 ath0: ieee80211_bg_scan: active scan, ticks 14981030 duration 150 ath0: scan_next: chan 1g -> 13g [passive, dwell min 20 max 149] ath0: scan_next: stopped, [ticks 14981190, dwell min 20 scanend 14981180] ath0: ieee80211_bg_scan: active scan, ticks 14981236 duration 150 ath0: scan_next: chan 1g -> 52a [passive, dwell min 20 max 149] ath0: scan_next: stopped, [ticks 14981396, dwell min 20 scanend 14981386] ath0: ieee80211_bg_scan: active scan, ticks 14981441 duration 150 ath0: scan_next: chan 1g -> 56a [passive, dwell min 20 max 149] ath0: scan_next: stopped, [ticks 14981601, dwell min 20 scanend 14981591] ath0: ieee80211_bg_scan: active scan, ticks 14981645 duration 150 ath0: scan_next: chan 1g -> 60a [passive, dwell min 20 max 149] ath0: scan_next: stopped, [ticks 14981805, dwell min 20 scanend 14981795] ath0: ieee80211_bg_scan: active scan, ticks 14981850 duration 150 ath0: scan_next: chan 1g -> 64a [passive, dwell min 20 max 149] ath0: scan_next: stopped, [ticks 14982010, dwell min 20 scanend 14982000] ath0: ieee80211_bg_scan: active scan, ticks 14982059 duration 150 ath0: scan_next: chan 1g -> 36a [passive, dwell min 20 max 149] ath0: scan_next: stopped, [ticks 14982219, dwell min 20 scanend 14982209] ath0: ieee80211_bg_scan: active scan, ticks 14982259 duration 150 ath0: scan_next: chan 1g -> 40a [passive, dwell min 20 max 149] ath0: scan_next: stopped, [ticks 14982419, dwell min 20 scanend 14982409] ath0: ieee80211_bg_scan: active scan, ticks 14982467 duration 150 ath0: scan_next: chan 1g -> 44a [passive, dwell min 20 max 149] ath0: scan_next: stopped, [ticks 14982627, dwell min 20 scanend 14982617] ath0: ieee80211_bg_scan: active scan, ticks 14982669 duration 150 ath0: scan_next: chan 1g -> 48a [passive, dwell min 20 max 149] ath0: scan_next: stopped, [ticks 14982829, dwell min 20 scanend 14982819] ath0: ieee80211_bg_scan: active scan, ticks 14982874 duration 150 ath0: scan_next: chan 1g -> 34a [passive, dwell min 20 max 149] ath0: scan_next: stopped, [ticks 14983034, dwell min 20 scanend 14983024] ath0: ieee80211_bg_scan: active scan, ticks 14983079 duration 150 ath0: scan_next: chan 1g -> 38a [passive, dwell min 20 max 149] ath0: scan_next: stopped, [ticks 14983239, dwell min 20 scanend 14983229] ath0: ieee80211_bg_scan: active scan, ticks 14983283 duration 150 ath0: scan_next: chan 1g -> 42a [passive, dwell min 20 max 149] ath0: scan_next: stopped, [ticks 14983443, dwell min 20 scanend 14983433] ath0: ieee80211_bg_scan: active scan, ticks 14983488 duration 150 ath0: scan_next: chan 1g -> 46a [passive, dwell min 20 max 149] ath_start: dequeue packet 0xc37d4d00 ath0: ieee80211_cancel_scan: cancel active scan ath_start: power save, packet=0xc37d4d00 ath0: [00:13:1a:47:7a:33] save frame with age 0, 2 now queued ath_start: dequeue packet 0x0 ath0: scan_next: done, [ticks 14983598, dwell min 20 scanend 14983638] ath0: [00:13:1a:47:7a:33] sta power save mode off Now, when the first packet arrives (top of the log), IEEE80211_F_SCAN is NOT set. scan_next just cleared the flag (line 816 in ieee80211_scan.c), but because it is not done scanning, power save is still on. So, ath_start does not call ieee80211_cancel_scan, but rather just queues the packet. When the next packet arrives (bottom of the log), it happens to be in the middle of a scan period, so IEEE80211_F_SCAN is set, and ath_start calls ieee80211_cancel_scan, terminating the scan (well after a little while at least). Question: after scan_next is run, reporting "stopped", what makes ieee80211_bg_scan to be called the next time? In the time between these two events, IEEE80211_F_SCAN is not set, but power save is "on", making all packets queue up. This window apparently gets larger the lower hz you run on. IMO, it would be better that ieee80211_cancel_scan immediately terminated scanning and did callout_drain on scan_next. But that does not close the window when IEEE80211_F_SCAN is not set. So either the scanning logic needs to change, or the test in ath_start. Bengt From owner-freebsd-mobile@FreeBSD.ORG Fri Feb 20 23:22:15 2009 Return-Path: Delivered-To: mobile@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3CDD8106566B for ; Fri, 20 Feb 2009 23:22:15 +0000 (UTC) (envelope-from cid=153-uid=294_-mid=16945-lid=13181-eid=10007-did=6645-bid=153-dsid=1-dtypeid=1-resendctr=0--@ymdirect1.com) Received: from smtp.ymdirect1.com (smtp.ymdirect1.com [204.92.150.16]) by mx1.freebsd.org (Postfix) with ESMTP id E11F68FC17 for ; Fri, 20 Feb 2009 23:22:14 +0000 (UTC) (envelope-from cid=153-uid=294_-mid=16945-lid=13181-eid=10007-did=6645-bid=153-dsid=1-dtypeid=1-resendctr=0--@ymdirect1.com) DKIM-Signature: v=1; a=rsa-sha1; d=ymdirect1.com; s=1024; c=relaxed/simple; q=dns/txt; i=@ymdirect1.com; t=1235171284; h=From:Subject:Date:To:MIME-Version:Content-Type; bh=TW0jDpkrhHEDve/1GAZ88DEqE64=; b=caW51juCACAQRM6E2S/VpLEriMBnQ8xSf+m5Y7Iw302PcCOInY09f5W4TcXMFUiV nWQPggKGXdz1jV1a4Vu313kB0jqysCfaC79tLj8MSB0PtbJ6Bjo6yyJvMNYsprJ7 EHvRDyE0Tb5ai65AWnRYrbzAMBVj2GY8ygKPpDvY8aM=; DomainKey-Signature: q=dns; a=rsa-sha1; c=nofws; s=1024; d=ymdirect1.com; h=Content-Transfer-Encoding:Message-ID:Content-Type:MIME-Version:X-Mailer:Date:To:From:Reply-To:Subject:X-Campid:X-Pviq:Sender:X-Eid; b=Y72cn6bHQj6KNr7z/eUw3AnnT68jm91w8wiNUJ94fGNOfMRKDx0KkZtWFlnUlF2Z fHlrDFZbtw0o31SBxDLS3/ytt6q9KjagC0jDJXVN8m9sOQAceddPodf4laF/q+Tn dkmZLniO9R7bCbf0JxfTqVpkWtDVihiMLVWaPg+QPF0= Message-ID: <9A.DB.22976.4D73F994@ec5> MIME-Version: 1.0 X-Mailer: MIME::Lite 3.01 (F2.73; B3.01; Q3.01) Date: Fri, 20 Feb 2009 23:08:04 UT To: mobile@freebsd.org From: "ALLEN SCHOLLES" X-Campid: cid=10007-uid=294-mid=16945-pid=-- X-Pviq: 000094-000479-YME-10007-16945 Sender: "ALLEN SCHOLLES" X-Eid: mobile@freebsd.org Content-Type: text/plain Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Fresh Cut BG, SBLC, MTN, Bonds and CDs For Lease X-BeenThere: freebsd-mobile@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ascholles@yahoo.com List-Id: Mobile computing with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2009 23:22:15 -0000 Hello, We are direct providers of Fresh Cut BG, SBLC, MTN, Bonds and CDs, which we have specifically for lease. We do not have any broker chain in this offer or get involved in Chauffeur driven offers. We deliver with time and precision as set forth in the agreement. You are at liberty to engage our leased facilities into trade programs as well as in signature project(s) such as Aviation, Agriculture, Automobile, Petroleum, Telecommunication, construction of Dams, Bridges and any other turnkey project(s) etc. Our terms and Conditions are reasonable. For further details and procedure. Please contact Allen. Email:- allenscholles@ymail.com Tel:- 44-208-099-9129 Why Do 8 of 10 Companies Use Leasing To Acquire Equipment? ? PROTECTS AND PRESERVES BANK AND CREDIT LINES CONSERVING WORKING CAPITAL AND MAXIMIZING ? CASH FLOW ? OVERCOMES BUDGET LIMITATIONS WHILE SIMPLIFYING CURRENT BUDGETING AND ACCOUNTING ? MAY ALLOW OFF-BALANCE SHEET TREATMENT AND TAX ADVANTAGES ? CONVENIENT AND QUICK APPROVAL PROCESS ? FLEXIBLE PAYMENT PROGRAMS TO MATCH YOUR NEEDS ? OFFERS A MANAGEABLE AND ECONOMICAL WAY OF KEEPING UP WITH RAPIDLY CHANGING TECHNOLOGIES ? ACTS AS A HEDGE AGAINST INFLATION - FIXED PAYMENTS FOR THE TERM OF THE LEASE ? PAYS FOR ITSELF OUT OF EARNINGS OR SAVINGS GENERATED BY THE EQUIPMENT LEASED LEASING ALLOWS YOUR COMPANY TO RETAIN CASH AND MAKE IT AVAILABLE FOR REINVESTMENT, OPERATIONS OR EXPANSION. | po box 23 | Bakers Mills | New York | 12811 | USA Click Here to Unsubscribe: http://ct.ymdirect1.com/rd/cts?d=10007-16945-13181-7900-294-589169-0-0-0-1-6645-153&list_id=13181&email=mobile@freebsd.org&message_id=16945 Privacy Policy: http://ct.ymdirect1.com/rd/cts?d=10007-16945-13181-7900-294-589170-0-0-0-1-6645-153 Powered by Yesmail Direct.