ath0: ath_reset: unable to reset hardware;

I've the latest FreeBSD on my ASUS N53S laptop

Code:
FreeBSD hadi-pc.my.domain 11.1-RELEASE-p4 FreeBSD 11.1-RELEASE-p4 #0: Tue Nov 14 06:12:40 UTC 2017     root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC  amd64

The problem is sometimes (happens alot) my wlan interface just stop working with no reason, and I've restart the whole system to resolve the problem. Here it is the logs I took when i face this problem:

Code:
dmesg:

ath0: device timeout
ath0: ath_reset: unable to reset hardware; hal status 3
ath0: device timeout
ath0: ath_reset: unable to reset hardware; hal status 3
ath0: device timeout
ath0: ath_reset: unable to reset hardware; hal status 3
ath0: device timeout
ath0: ath_reset: unable to reset hardware; hal status 3


ifconfig:

wlan0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
        ether 00:08:ca:3d:85:db
        hwaddr 00:08:ca:3d:85:db
        inet 192.168.43.5 netmask 0xffffff00 broadcast 192.168.43.255
        nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
        media: IEEE 802.11 Wireless Ethernet MCS mode 11ng
        status: associated
        ssid atari83 channel 11 (2462 MHz 11g ht/20) bssid 50:68:0a:43:f8:f5
        regdomain 96 indoor ecm authmode WPA2/802.11i privacy ON
        deftxkey UNDEF AES-CCM 2:128-bit AES-CCM 3:128-bit txpower 20 bmiss 7
        scanvalid 60 protmode CTS ampdulimit 32k ampdudensity 8 shortgi smps
        -stbctx stbcrx wme burst roaming MANUAL
        groups: wlan

       
pciconf:

hostb0@pci0:0:0:0:      class=0x060000 card=0x11471043 chip=0x01048086 rev=0x09 hdr=0x00
pcib1@pci0:0:1:0:       class=0x060400 card=0x11471043 chip=0x01018086 rev=0x09 hdr=0x01
vgapci1@pci0:0:2:0:     class=0x030000 card=0x17121043 chip=0x01268086 rev=0x09 hdr=0x00
none0@pci0:0:22:0:      class=0x078000 card=0x11471043 chip=0x1c3a8086 rev=0x04 hdr=0x00
ehci0@pci0:0:26:0:      class=0x0c0320 card=0x11471043 chip=0x1c2d8086 rev=0x05 hdr=0x00
hdac0@pci0:0:27:0:      class=0x040300 card=0x10631043 chip=0x1c208086 rev=0x05 hdr=0x00
pcib2@pci0:0:28:0:      class=0x060400 card=0x11471043 chip=0x1c108086 rev=0xb5 hdr=0x01
pcib3@pci0:0:28:1:      class=0x060400 card=0x11471043 chip=0x1c128086 rev=0xb5 hdr=0x01
pcib4@pci0:0:28:3:      class=0x060400 card=0x11471043 chip=0x1c168086 rev=0xb5 hdr=0x01
pcib5@pci0:0:28:5:      class=0x060400 card=0x11471043 chip=0x1c1a8086 rev=0xb5 hdr=0x01
ehci1@pci0:0:29:0:      class=0x0c0320 card=0x11471043 chip=0x1c268086 rev=0x05 hdr=0x00
isab0@pci0:0:31:0:      class=0x060100 card=0x11471043 chip=0x1c498086 rev=0x05 hdr=0x00
ahci0@pci0:0:31:2:      class=0x010601 card=0x11471043 chip=0x1c038086 rev=0x05 hdr=0x00
none1@pci0:0:31:3:      class=0x0c0500 card=0x11471043 chip=0x1c228086 rev=0x05 hdr=0x00
vgapci0@pci0:1:0:0:     class=0x030000 card=0x17121043 chip=0x0df610de rev=0xa1 hdr=0x00
ath0@pci0:3:0:0:        class=0x028000 card=0x2c371a3b chip=0x002b168c rev=0x01 hdr=0x00
xhci0@pci0:4:0:0:       class=0x0c0330 card=0x10391043 chip=0x10001b73 rev=0x04 hdr=0x00
re0@pci0:5:0:0: class=0x020000 card=0x16d51043 chip=0x816810ec rev=0x06 hdr=0x00

let me know if you need more logs. Thanks.
 
I tried ifconfig unplumb and plumb again to attach wlan to ath0 but same result. so I've to restart notebook like 100times during a day :(
 
In my case, the disconnection happens for a reason (which is my machine is on the fringe of the coverage area). But, I think the ath driver for FreeBSD has trouble re-attaching when the connection is lost. Like you, I find myself rebooting in order to get the connection back.

wpa_cli -iwlan0 disconnect works fine,

but

wpa_cli -iwlan0 reattach gives error

It's the same result when using plumb/unplumb, or restarting the network or killing and restarting the wpa_supplicant program, etc. Even if I manually kill off the interface and redo everything from scratch with command line it won't reattach. Seems it needs a hard reset. I don't have this issue with other adapters that I know of. Is your machine in the fringe area of your WiFi?

Also, when my connection drops due to fringe coverage, I do get the error you mentioned ...

ath0: ath_reset: unable to reset hardware
 
Code:
eval "/sbin/ping -Q -p ff -i 15" ${HOST} && sleep 4
only a hint, but if you can .sh code that, to a HOST where you are
allowed to ping, it may keep the ath0 up 8 hours rather than 70 minutes...
[ sorry for not posting the code, is semi proprietary... ]
 
Code:
eval "/sbin/ping -Q -p ff -i 15" ${HOST} && sleep 4
only a hint, but if you can .sh code that, to a HOST where you are
allowed to ping, it may keep the ath0 up 8 hours rather than 70 minutes...
[ sorry for not posting the code, is semi proprietary... ]

Alright, I'll give it a try.
So basically I need to ping an IP on the internet right ? like 4.2.2.2 (as $HOST) ?
 
Alright, I'll give it a try.
So basically I need to ping an IP on the internet right ? like 4.2.2.2 (as $HOST) ?

Are you still having problems?

If you could poll for signal quality, and log all the traffic on your interface, maybe this could give us a hint in what layer the problem could be at... Also, your firewall rules, if any...
 
I have to say I use Atheros exclusively and even run an Wireless Access Point on FreeBSD and I do not see this problem.

Makes me wonder if its not an ACPI power state problem.

Reason I mention it is I see similar problem with cellular modem connectivity and I narrowed it down to the power state.
My Sierra modem has a LP mode it goes into when the laptop goes into S3 mode.
 
I have to say I use Atheros exclusively and even run an Wireless Access Point on FreeBSD and I do not see this problem.

Makes me wonder if its not an ACPI power state problem.

Reason I mention it is I see similar problem with cellular modem connectivity and I narrowed it down to the power state.
My Sierra modem has a LP mode it goes into when the laptop goes into S3 mode.

Phishfry : Could you describe the ACPI power problem? In my case, I can purposely down the Atheros WiFi interface, but then I cannot bring it back up without a hard reset. I've no problem downing RALink, Realtek, and other adapters, and bringing them back up without a hard reset.

poorandunlucky - Yes, that's a very good idea. If the OP could put a second adapter into monitor mode, run net/tcpdump with the "-I" RFCOM option, parse the dumped file with net/wireshark, and post the results, we might have better luck with a diagnosis. He could pull/twist the monitor antenna off so that he picks up just his own adapter RF exchanges.
 
Back
Top