From owner-freebsd-stable@FreeBSD.ORG Thu Nov 16 02:53:53 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CC82916A403 for ; Thu, 16 Nov 2006 02:53:53 +0000 (UTC) (envelope-from sam@errno.com) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.FreeBSD.org (Postfix) with ESMTP id 70F7F43D46 for ; Thu, 16 Nov 2006 02:53:53 +0000 (GMT) (envelope-from sam@errno.com) Received: from [10.0.0.200] ([10.0.0.200]) (authenticated bits=0) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id kAG2rpVd014912 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 15 Nov 2006 18:53:53 -0800 (PST) (envelope-from sam@errno.com) Message-ID: <455BD2BF.3050802@errno.com> Date: Wed, 15 Nov 2006 18:53:51 -0800 From: Sam Leffler Organization: Errno Consulting User-Agent: Thunderbird 1.5.0.8 (Macintosh/20061025) MIME-Version: 1.0 To: Lamont Granquist References: <45578B48.1090704@errno.com> In-Reply-To: X-Enigmail-Version: 0.94.1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: ath0 issue X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Nov 2006 02:53:53 -0000 Lamont Granquist wrote: > > > On Sun, 12 Nov 2006, Sam Leffler wrote: >> If tx stops in ap mode you need to figure out whether the h/w tx q is >> stalled or something else "above" is blocking outbound traffic. The >> usual things to check are: >> >> 1. are there resources in the driver to send a packet (e.g. buffers on >> the queue); if the tx q is full then the OACTIVE bit will be marked on >> the interface and visible with ifconfig > > during one of the period where tx was blocking i got ifconfigs that > looked like: > > ath0: flags=8843 mtu 1500 > inet 192.168.70.1 netmask 0xffffff00 broadcast 192.168.70.255 > ether 00:09:5b:c8:78:9c > media: IEEE 802.11 Wireless Ethernet autoselect mode 11g > status: associated > ssid lamontnet channel 1 bssid 00:09:5b:c8:78:9c > authmode OPEN privacy OFF txpowmax 30 bmiss 7 protmode CTS burst > dtimperiod 1 bintval 100 > > ath0: flags=8843 mtu 1500 > inet 192.168.70.1 netmask 0xffffff00 broadcast 192.168.70.255 > ether 00:09:5b:c8:78:9c > media: IEEE 802.11 Wireless Ethernet autoselect mode 11g > status: associated > ssid lamontnet channel 1 bssid 00:09:5b:c8:78:9c > authmode OPEN privacy OFF txpowmax 30 bmiss 7 protmode CTS burst > dtimperiod 1 bintval 100 > >> 2. if packets are queued to the h/w and not going out then you need to >> identify whether a higher priority frame is blocking them; this is >> harder but can occur when something like a beacon frame fails to go out >> or if there is cabq traffic q'd up behind the beacon frame that doesn't >> make it out >> 3. if none of the above is blocking traffic then h/w may consider the >> media busy; this can happen if your ap is operating in a busy >> environment and things like protection are being used heavily, or if you >> have an overlapping BSS that is operating in 11b > > i'm not certain how to go about collecting that information, but this is > a very lightly used wireless network with only the freebsd box and the > windows machine participating and the traffic is limited to the ssh > sessions that i setup and the usual windoze and dhcp chatter... > >> Often problems such as this are most easily understood by sniffing >> traffic from another station and looking for traffic patterns coincident >> with the event on the ap. > > i've only got the two wireless points right now, so i can't get a third > machine up to sniff... > >> More useful information can be found in the >> statistics collected by the driver (use athstats). > > here's a before and after of athstats which brackets one of these events: > > warez# ./athstats > 2243 data frames received > 2925 data frames transmit > 50 tx frames with an alternate rate > 947 long on-chip tx retries > 115 tx failed 'cuz too many retries > 2M current transmit rate > 982 tx management frames > 6 tx frames discarded prior to association > 242 tx frames with no ack marked > 2828 tx frames with short preamble > 2439 rx failed 'cuz of bad CRC > 28137 rx failed 'cuz of PHY err > 19620 OFDM timing > 8517 CCK timing > 150622 beacons transmitted > 534 periodic calibrations > 16 rssi of last ack > 19 avg recv rssi > -96 rx noise floor > 1 cabq frames transmitted > 33 switched default/rx antenna > Antenna profile: > [1] tx 1862 rx 6345 > [2] tx 1927 rx 6371 > warez# ./athstats > 2252 data frames received > 2937 data frames transmit > 50 tx frames with an alternate rate > 947 long on-chip tx retries > 115 tx failed 'cuz too many retries > 2M current transmit rate > 982 tx management frames > 6 tx frames discarded prior to association > 242 tx frames with no ack marked > 2840 tx frames with short preamble > 2440 rx failed 'cuz of bad CRC > 28145 rx failed 'cuz of PHY err > 19623 OFDM timing > 8522 CCK timing > 150659 beacons transmitted > 535 periodic calibrations > 22 rssi of last ack > 22 avg recv rssi > -96 rx noise floor > 1 cabq frames transmitted > 33 switched default/rx antenna > Antenna profile: > [1] tx 1874 rx 6371 > [2] tx 1927 rx 6371 > > Snapshots are rarely useful; try running athstats 1 and correlate what you see with pauses. Another possible reason for deferred operation is something else in the system blocking the taskq threads; that's a bit trickier to diagnose. Sam