Date: Fri, 02 Feb 2007 10:13:15 -0800 From: Sam Leffler <sam@errno.com> To: Kai Lockwood <kailockwood@gmail.com> Cc: freebsd-stable@freebsd.org Subject: Re: ath0: ath_reset: unable to reset hardware; hal status 3 Message-ID: <45C37F3B.8060506@errno.com> In-Reply-To: <200702011743.16748.kailockwood@gmail.com> References: <20070128105053.GA93664@tirith.brixandersen.dk> <45BCEF32.3030101@errno.com> <200702011743.16748.kailockwood@gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Kai Lockwood wrote: > Hello, > > I am having the same type of trouble with a Dynex card. I mearly > receive 'ath0: Device timeout' on the main console screen. "device timeout" and being unable to reset the h/w are totally different issues. > >> I take it you tried ifconfig'ing the interface down and up? > I have. The card does not appear to reset itself. While the card is up, it > just rotates across the chanels. If it's scanning then it resets. If it does not reset you will get a console msg saying it could not reset the chip. > >> The output of athstats at the point where things are wedged might be >> useful. > # /usr/local/bin/athstats > 84874 data frames received > 53228 data frames transmit > 2228 tx frames with an alternate rate > 15357 long on-chip tx retries > 560 tx failed 'cuz too many retries > 98877 mib overflow interrupts > 11M current transmit rate > 860 watchdog timeouts > 85 beacon miss interrupts > 612 tx management frames > 1602 tx frames discarded prior to association > 496 tx frames with no ack marked > 21148 rx failed 'cuz of bad CRC > 361 rx failed 'cuz of PHY err > 96 OFDM restart > 265 CCK restart > 13422 periodic calibrations > 10 rssi of last ack > -95 rx noise floor > 18 phantom beacon misses > 1 rx failed 'cuz frame too large > 1 switched default/rx antenna > Antenna profile: > [1] tx 51420 rx 1829072 > [2] tx 403 rx 116 You have not indicated what h/w you have, what os version you're runing, or how your card is setup. The original poster I believe was operating in ap mode and you do not appear to be. Your athstats output indicates a very noise environment and/or a very long-running system (e.g. 98877 mib overflow interrupts for ~1.8 million packets tx/rx). Further an rssi of 10 indicates very low signal to the ap (it's barely on the fringe of operational use). > # >> Also verify if only tx is wedged (e.g. athstats 1 will show you >> if you're receiving frames). > input output altrate short long xretry crcerr crypt phyerr rssi > rate > 84874 53228 2228 0 15357 560 21148 0 361 0 11M > 0 0 0 0 0 0 0 0 0 0 11M > 0 0 0 0 0 0 0 0 0 0 11M > 0 0 0 0 0 0 0 0 0 0 11M > 0 0 0 0 0 0 0 0 0 0 11M > 0 0 0 0 0 0 0 0 0 0 11M > 0 0 0 0 0 0 0 0 0 0 11M > 0 0 0 0 0 0 0 0 0 0 11M > 0 0 0 0 0 0 0 0 0 0 11M > 0 0 0 0 0 0 0 0 0 0 11M > 0 0 0 0 0 0 0 0 0 0 11M > 0 0 0 0 0 0 0 0 0 0 11M > 0 0 0 0 0 0 0 0 0 0 11M > 0 0 0 0 0 0 0 0 0 0 11M > 0 0 0 0 0 0 0 0 0 0 11M > 0 0 0 0 0 0 0 0 0 0 11M > 0 0 0 0 0 0 0 0 0 0 11M > 0 0 0 0 0 0 0 0 0 0 11M > 0 0 0 0 0 0 0 0 0 0 11M > 0 0 0 0 0 0 0 0 0 0 11M > 0 0 0 0 0 0 0 0 0 0 11M > > The above snippet repeats verbatium regardless of traffic. rssi of 0 makes no sense. I don't trust your stats now. > >> Best suggestion I can make is to use a >> different model card. > > I can't. Is there someway to look into this issue deeper? I do not understand why you "can't" but whatever. FWIW I have a laptop that very recently started exhibiting "device timeouts" while operating in sta mode (using wpa). This means I'll eventually be able to look at that specific issue which in the past I've not been able to recreate. Sam
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?45C37F3B.8060506>