Re: ath0: ath_reset: unable to reset hardware; hal status 3
Hi Sam, Sorry about the long delay in replying, been busy moving to a new apartment :) On Sun, Jan 28, 2007 at 10:45:06AM -0800, Sam Leffler wrote: I take it you tried ifconfig'ing the interface down and up? Yes, that didn't solve it. The output of athstats at the point where things are wedged might be useful. Also verify if only tx is wedged (e.g. athstats 1 will show you if you're receiving frames). Thanks, I'll check that next time the problem occurs. The fact that the card cannot be reset seems to imply the mac is somehow locked up. I vaguely recall some h/w issues like this on older cards (and you are using a rather old card) but nothing that wasn't handled by doing a reset operation. Best suggestion I can make is to use a different model card. I see. Can you recommend a replacement 802.11a/b/g card model which is supported by ath(4)? Sincerely, Brix -- Henrik Brix Andersen [EMAIL PROTECTED] pgpKxE48W5yJS.pgp Description: PGP signature
Re: ath0: ath_reset: unable to reset hardware; hal status 3
On Thu, Feb 15, 2007 at 02:16:42PM +0100, Henrik Brix Andersen wrote: On Sun, Jan 28, 2007 at 10:45:06AM -0800, Sam Leffler wrote: The output of athstats at the point where things are wedged might be useful. Also verify if only tx is wedged (e.g. athstats 1 will show you if you're receiving frames). Thanks, I'll check that next time the problem occurs. Output of athstats on the AP looks like this with ping(8) running on both AP and STA while things are wedged: input output altrate shortlong xretry crcerr crypt phyerr rssi rate 01 0 0 0 0 0 0 12 39 24M The above output repeats itself with small variations in the phyerr column. The fact that the card cannot be reset seems to imply the mac is somehow locked up. I vaguely recall some h/w issues like this on older cards (and you are using a rather old card) but nothing that wasn't handled by doing a reset operation. Best suggestion I can make is to use a different model card. I see. Can you recommend a replacement 802.11a/b/g card model which is supported by ath(4)? I have been searching for a replacement for my current 5212-based atheros miniPCI card and came across these two products: http://www.netgate.com/product_info.php?cPath=26_34products_id=279 http://www.netgate.com/product_info.php?cPath=26_34products_id=393 Both are based on the Atheros AR5006xs 6th generation chipset (AR5414) but only one of them supports Super AG. Does anybody know if these cards will work the the ath(4)/ath_hal(4) found in FreeBSD? According to the ath_hal(4) man page, the only supported cards are those based on the Atheros AR5210, AR5211 and AR5212 chipsets? Sincerely, Brix -- Henrik Brix Andersen [EMAIL PROTECTED] pgp8zXxAjR9iZ.pgp Description: PGP signature
Re: ath0: ath_reset: unable to reset hardware; hal status 3
Henrik Brix Andersen wrote: I have been searching for a replacement for my current 5212-based atheros miniPCI card and came across these two products: http://www.netgate.com/product_info.php?cPath=26_34products_id=279 http://www.netgate.com/product_info.php?cPath=26_34products_id=393 Both are based on the Atheros AR5006xs 6th generation chipset (AR5414) but only one of them supports Super AG. Does anybody know if these cards will work the the ath(4)/ath_hal(4) found in FreeBSD? According to the ath_hal(4) man page, the only supported cards are those based on the Atheros AR5210, AR5211 and AR5212 chipsets? This week I ordered a ThinkPad R60 with an AR5006 PCI Express card. If you can wait a week or two, I'll have some information on FreeBSD's success with it. -Proto ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ath0: ath_reset: unable to reset hardware; hal status 3
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] tx51420 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 shortlong xretry crcerr crypt phyerr rssi rate 84874532282228 0 15357560 21148 0 3610 11M 00 0 0 0 0 0 0 00 11M 00 0 0 0 0 0 0 00 11M 00 0 0 0 0 0 0 00 11M 00 0 0 0 0 0 0 00 11M 00 0 0 0 0 0 0 00 11M 00 0 0 0 0 0 0 00 11M 00 0 0 0 0 0 0 00 11M 00 0 0 0 0 0 0 00 11M 00 0 0 0 0 0 0 00 11M 00 0 0 0 0 0 0 00 11M 00 0 0 0 0 0 0 00 11M 00 0 0 0 0 0 0 00 11M 00 0 0 0 0 0 0 00 11M 00 0 0 0 0 0 0 00 11M 00 0 0 0 0 0 0 00 11M 00 0 0 0 0 0 0 00 11M 00 0 0 0 0 0 0 00 11M 00 0 0 0 0 0 0 00 11M 00 0 0 0 0 0 0 00 11M 00 0 0 0 0 0 0 00 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 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ath0: ath_reset: unable to reset hardware; hal status 3
Hello, I am having the same type of trouble with a Dynex card. I mearly receive 'ath0: Device timeout' on the main console screen. 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. 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] tx51420 rx 1829072 [2] tx 403 rx 116 # Also verify if only tx is wedged (e.g. athstats 1 will show you if you're receiving frames). input output altrate shortlong xretry crcerr crypt phyerr rssi rate 84874532282228 0 15357560 21148 0 3610 11M 00 0 0 0 0 0 0 00 11M 00 0 0 0 0 0 0 00 11M 00 0 0 0 0 0 0 00 11M 00 0 0 0 0 0 0 00 11M 00 0 0 0 0 0 0 00 11M 00 0 0 0 0 0 0 00 11M 00 0 0 0 0 0 0 00 11M 00 0 0 0 0 0 0 00 11M 00 0 0 0 0 0 0 00 11M 00 0 0 0 0 0 0 00 11M 00 0 0 0 0 0 0 00 11M 00 0 0 0 0 0 0 00 11M 00 0 0 0 0 0 0 00 11M 00 0 0 0 0 0 0 00 11M 00 0 0 0 0 0 0 00 11M 00 0 0 0 0 0 0 00 11M 00 0 0 0 0 0 0 00 11M 00 0 0 0 0 0 0 00 11M 00 0 0 0 0 0 0 00 11M 00 0 0 0 0 0 0 00 11M The above snippet repeats verbatium regardless of traffic. Best suggestion I can make is to use a different model card. I can't. Is there someway to look into this issue deeper? Thanks, Kai Lockwood ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
ath0: ath_reset: unable to reset hardware; hal status 3
Hi all, I have noticed a problem when using ath(4) as an 802.11g access point with hostapd(8) and WPA2-PSK CCMP. The following problem seems to only occur when a Microsoft Windows XP STA connects to the AP in 802.11g mode, my FreeeBSD STAs doesn't seem to trigger this: Jan 28 11:21:07 osgiliath kernel: ath0: stuck beacon; resetting (bmiss count 4) Jan 28 11:21:07 osgiliath kernel: ath0: ath_reset: unable to reset hardware; hal status 3 Jan 28 11:21:25 osgiliath kernel: ath0: device timeout Jan 28 11:21:25 osgiliath kernel: ath0: stuck beacon; resetting (bmiss count 4) Jan 28 11:21:25 osgiliath kernel: ath0: ath_reset: unable to reset hardware; hal status 3 Jan 28 11:21:37 osgiliath kernel: ath0: device timeout Jan 28 11:21:38 osgiliath kernel: ath0: stuck beacon; resetting (bmiss count 4) Jan 28 11:21:38 osgiliath kernel: ath0: ath_reset: unable to reset hardware; hal status 3 Jan 28 11:21:46 osgiliath kernel: ath0: device timeout This is FreeBSD RELENG_6 (nanoBSD) as of yesterday with the new ath_hal(4) running on a Soekris net4801-50: ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) ath0: Atheros 5212 mem 0xa001-0xa001 irq 11 at device 14.0 on pci0 ath0: Ethernet address: 00:05:4e:42:e8:7c ath0: mac 5.6 phy 4.1 5ghz radio 1.7 2ghz radio 2.3 The same problem occured with version 0.9.17.2 of ath_hal(4). I have increased the RX/TX buffers in ath(4) as shown in this snippet from my kernel configuration: device ath device ath_hal device ath_rate_sample options ATH_RXBUF=80 options ATH_TXBUF=200 The only way I can get the AP running again after the above messages to syslog is to reboot it. The problem doesn't seem to occur in 802.11b mode nor in 802.11g mode with only FreeBSD STAs. Any help in debugging this will be appreciated. Regards, Brix -- Henrik Brix Andersen [EMAIL PROTECTED] pgpaSfvVEpUzW.pgp Description: PGP signature
Re: ath0: ath_reset: unable to reset hardware; hal status 3
Henrik Brix Andersen wrote: Hi all, I have noticed a problem when using ath(4) as an 802.11g access point with hostapd(8) and WPA2-PSK CCMP. The following problem seems to only occur when a Microsoft Windows XP STA connects to the AP in 802.11g mode, my FreeeBSD STAs doesn't seem to trigger this: Jan 28 11:21:07 osgiliath kernel: ath0: stuck beacon; resetting (bmiss count 4) Jan 28 11:21:07 osgiliath kernel: ath0: ath_reset: unable to reset hardware; hal status 3 Jan 28 11:21:25 osgiliath kernel: ath0: device timeout Jan 28 11:21:25 osgiliath kernel: ath0: stuck beacon; resetting (bmiss count 4) Jan 28 11:21:25 osgiliath kernel: ath0: ath_reset: unable to reset hardware; hal status 3 Jan 28 11:21:37 osgiliath kernel: ath0: device timeout Jan 28 11:21:38 osgiliath kernel: ath0: stuck beacon; resetting (bmiss count 4) Jan 28 11:21:38 osgiliath kernel: ath0: ath_reset: unable to reset hardware; hal status 3 Jan 28 11:21:46 osgiliath kernel: ath0: device timeout This is FreeBSD RELENG_6 (nanoBSD) as of yesterday with the new ath_hal(4) running on a Soekris net4801-50: ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) ath0: Atheros 5212 mem 0xa001-0xa001 irq 11 at device 14.0 on pci0 ath0: Ethernet address: 00:05:4e:42:e8:7c ath0: mac 5.6 phy 4.1 5ghz radio 1.7 2ghz radio 2.3 The same problem occured with version 0.9.17.2 of ath_hal(4). I have increased the RX/TX buffers in ath(4) as shown in this snippet from my kernel configuration: deviceath deviceath_hal deviceath_rate_sample options ATH_RXBUF=80 options ATH_TXBUF=200 The only way I can get the AP running again after the above messages to syslog is to reboot it. The problem doesn't seem to occur in 802.11b mode nor in 802.11g mode with only FreeBSD STAs. Any help in debugging this will be appreciated. I take it you tried ifconfig'ing the interface down and up? The output of athstats at the point where things are wedged might be useful. Also verify if only tx is wedged (e.g. athstats 1 will show you if you're receiving frames). The fact that the card cannot be reset seems to imply the mac is somehow locked up. I vaguely recall some h/w issues like this on older cards (and you are using a rather old card) but nothing that wasn't handled by doing a reset operation. Best suggestion I can make is to use a different model card. Sam ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
