From owner-freebsd-stable@FreeBSD.ORG Fri Dec 29 12:04:25 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9441016A403 for ; Fri, 29 Dec 2006 12:04:25 +0000 (UTC) (envelope-from joao@matik.com.br) Received: from msrv.matik.com.br (msrv.matik.com.br [200.152.83.14]) by mx1.freebsd.org (Postfix) with ESMTP id 0EDF913C461 for ; Fri, 29 Dec 2006 12:04:24 +0000 (UTC) (envelope-from joao@matik.com.br) Received: from ap-h.matik.com.br (ap-h.matik.com.br [200.152.83.36]) by msrv.matik.com.br (8.13.8/8.13.1) with ESMTP id kBT1dpLS054231; Thu, 28 Dec 2006 22:39:52 -0300 (BRT) (envelope-from joao@matik.com.br) From: JoaoBR Organization: Infomatik To: Lamont Granquist , freebsd-stable@freebsd.org Date: Thu, 28 Dec 2006 22:41:24 -0300 User-Agent: KMail/1.9.4 References: <200612282002.11562.joao@matik.com.br> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200612282241.24542.joao@matik.com.br> X-Virus-Scanned: ClamAV version 0.88.4, clamav-milter version 0.88.4 on msrv.matik.com.br X-Virus-Status: Clean Cc: Subject: Re: ath0 timeout problem - again 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: Fri, 29 Dec 2006 12:04:25 -0000 On Thursday 28 December 2006 21:52, you wrote: > check this message: > > http://lists.freebsd.org/pipermail/freebsd-stable/2006-December/031216.ht= ml > > run "/usr/src/tools/tools/net80211/wlandebug/wlandebug -i ath0 power" and > see if one of the hosts on your wlan has powersaving turned on. > > "stops forever" was not one of my symptoms though, so your issue may be > different... > thank's for your answer powersaving is not the issue here because it's off But I saw histories about this and even if powersaving issue "was the issue= in=20 that case(really?)" I think this is wierd in any way because if ONE station= =20 with powersaving on could set the AP in DoS ... man ... if really true this= =20 is kind of lame excuse or kind of driver weakness which both would be=20 inacceptable, and, if it does NOT wake up if in sleep state ... no further= =20 comment, but a driver weakness right? wether powersaving is on or not on the station/client is a local setting t= o=20 this station and must not influence any remote computer in any way, imagin= e,=20 you turn on your powersavings and the complete internet goes down on your=20 request hihihihi :) but then, like my case, on the AP or better ath in ap mode, even IF=20 powersaving is ON it might stop working for any related reason but firstabl= e=20 NOT WHILE TX/RX and secondable if idle it must return soon THIS computer=20 wants to transmit any kind of traffic again last but not least powersaving might shut the power down but must return w= hen=20 necessary - if not - there is a driver problem. Jo=E3o > On Thu, 28 Dec 2006, JoaoBR wrote: > > I need some help here, this is not a single case, I get this on a sever= al > > machines, this is releng_6 , recent, but old problem getting ugly > > > > > > first I get this kind of events in messages, independent if it is client > > mode or hostap or adhoc > > > > Dec 28 16:50:53 ap1-cds kernel: ath0: discard oversize frame (ether type > > 5e4 flags 3 len 1522 > max 1514) > > Dec 28 16:51:01 ap1-cds kernel: ath0: discard oversize frame (ether type > > 5e4 flags 3 len 1522 > max 1514) > > Dec 28 16:58:16 ap1-cds kernel: ath0: device timeout > > ... timeout event repeats > > > > I really do not know what this event means (ether type 5e4), for my > > understandings it is vague in the source, so I am lost here > > > > { > > I get continously: > > > > kernel: ath0: link state changed to DOWN > > kernel: ath0: link state changed to UP > > > > when WL client but it recovers when the AP comes back to normal > > so wl-cli mode is not the issue > > } > > > > > > but when the machine is running hostap the link state up/down events do > > not come up but transmission is interrupted, or better, goes slow and > > stops then - and stops forever until cold reboot, no chance to get this > > card back, not even unload ath and reload the driver (that was a try but > > I use it compiled into the kernel) > > this is not related to any WEP settings or any rate, this problem is > > coming up with either rate-sample or rate_onoe > > > > > > this is not related to the "tx stopped" problem (OACTIVE) and it is not > > related to any [TX|RX]BUF value (whatever it is set to) > > > > this problem is not a single case and not hardware related, here I mean > > MB, CPU, memory but is related in a certain way to the ath drv - same > > machine, but wi0 (prism card) and it does NOT happen this way > > > > > > I am with this problem since 6.0 and would be glad if somebody could > > convince Mr. Sam L. to attend this since it is a serious issue - any > > FreeBSD releng_6 has this problem but releng_5 does not > > > > depending on the amount of traffic I get this any hour ( when 2-3Mbit/s > > or more) or several times a day (when 1-2Mbit/s) > > > > it get worse when I have more then one ath card installed > > > > > > ath stats: > > > > 70777 data frames received > > 71551 data frames transmit > > 420 tx frames with an alternate rate > > 10821 long on-chip tx retries > > 260 tx failed 'cuz too many retries > > 11M current transmit rate > > 10489 tx management frames > > 1 tx frames discarded prior to association > > 786 tx frames with no ack marked > > 80516 tx frames with short preamble > > 54395 rx failed 'cuz of bad CRC > > 146438 rx failed 'cuz of PHY err > > 145013 CCK timing > > 1425 CCK restart > > 5295 beacons transmitted > > 19 periodic calibrations > > 42 rssi of last ack > > 31 avg recv rssi > > -98 rx noise floor > > 572 cabq frames transmitted > > 11 cabq xmit overflowed beacon interval > > 1525 switched default/rx antenna > > Antenna profile: > > [1] tx 41285 rx 4 > > > > > > ifconfig > > > > ath0: flags=3D8943 mtu = 1500 > > ether 00:13:46:8b:f1:86 > > media: IEEE 802.11 Wireless Ethernet DS/11Mbps mode 11b > > status: associated > > ssid omegasul channel 1 (2412) bssid 00:13:46:8b:f1:86 > > authmode OPEN privacy ON deftxkey 1 > > wepkey 1:40-bit > > wepkey 2:40-bit > > wepkey 3:40-bit > > wepkey 4:40-bit powersavemode OFF powersavesleep 100 txpowmax 36 > > txpower 63 rtsthreshold 2346 mcastrate 1 fragthreshold 2346 bmiss > > 7 -pureg protmode CTS -wme burst ssid HIDE -apbridge dtimperiod 1 bintv= al > > 100 > > > > > > > > > > -- > > thank's > > Jo=E3o > > > > > > > > > > > > > > > > A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada > > segura. Service fornecido pelo Datacenter Matik=20 > > https://datacenter.matik.com.br > > _______________________________________________ > > freebsd-stable@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.or= g" =2D-=20 Jo=E3o A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada segura. Service fornecido pelo Datacenter Matik https://datacenter.matik.com.br