FBSD10 Atheros wifi not working

[Andrew Merenbach]

Hi,

I went through this with the same messages on FreeBSD 10 the other day on my work tower, a Dell XPS 8700 (I think 8700).

I silenced the messages by and got wifi working by filling in /etc/wpa_supplicant.conf and modifying /etc/rc.conf to have some stuff from <http://www.freebsd.org/doc/handbook/network-wireless.html> :

wlans_ath0="wlan0"
ifconfig_wlan0="WPA DHCP"

With that said, I have intermittent disconnects and I'm not convinced I have everything configured properly. :-/

Please feel free to let me know if I may provide more info, or if corrections can be made to my solution. ;)

Best,
Andrew

Sent from my iPhone

> On Apr 14, 2014, at 4:16, Da Rock <freebsd-questions at herveybayaustralia.com.au> wrote:
> 
> Finally got the email client working again on the walking dead system :)
> 
>> On 04/14/14 13:57, Adrian Chadd wrote:
>> Hi!
> I was hoping you were tuned in. If you can get this thing sorted again I'll owe you one!
>> 
>> You never said exactly what hardware it is Can you include a dmesg of
>> the relevant bits during boot?
> Sorry, that was a bit remiss wasn't it? I had the info to put in too... its the AR9285 atheros chipset.
> 
> dmesg is a bit harder being on a different system. I'll try and get the info in order though, at the time I was reading off the scrolling output from vt1. The error(s) are repetitive though, so I'll just offer one cycle. It doesn't seem to necessarily follow any real order though, from my observation.
> 
> ath0: ath_reset_grablock: didn't finish after 10 iterations
> ath0: ath_reset_grablock: warning, recursive reset path!
> ath0: ath_reset: concurrent reset! danger!
> ath0: ath_reset: unable to reset hardware; hal status 14
> ath0: ath_chanset: unable to reset channel <channel>, hal status 14
> ...
> ath0: ath_reset: unable to reset hardware; hal status 14
>> 
>> Anything like the above kinda indicates there's some bigger issue going on.
> I can't imagine its a hardware issue as it seems to work with other systems (like the install memdisk). I thought with the hal debug sysctl being available it would offer more info, but it seems it may not even be in the kernel although there is a sysctl. I tried compiling a new kernel with the debug options, but the backup battery is not working properly so it depends on ntpd to set the correct time, and the make requires the correct time set; so I'll have to address that before I can continue that course.
> 
> Argh! The joys of Murphy and his damned laws!
>> 
>> 
>> -a
>> 
>> 
>> 
>> On 13 April 2014 17:59, Da Rock
>> <freebsd-questions at herveybayaustralia.com.au> wrote:
>>> The subject line may not be very descriptive, but I'm not sure exactly where
>>> to point as to the problem. All other similar issues are a few years old
>>> now, and on 8,9, some 7's.
>>> 
>>> Long story short I'm just installing 10 (finally) on my laptop, and I need
>>> to get it back up and running asap as I am swamped in work. I didn't think
>>> it would be an issue as 9 had a decent working ath driver and I thought it
>>> could only get better. I'm now emailing using yet another system with the
>>> same device on 9, but a dying hdd which obviously also needs a reinstall on
>>> new hdd. Wired is no good as we aren't equipped.
>>> 
>>> So in bsdinstall, all works well and it sets up wifi easily. Reboot into the
>>> new system an it has a coronary with messages from ath_reset_grablock,
>>> ath_reset, ath_raw_xmit, ath_chan_set, ath_legacy_rx_tasklet:
>>> 
>>> ath_reset: concurrent reset! danger!
>>> 
>>> ath_reset_grablock: didn't finish after 10 iterations
>>> ath_reset_grablock: warning, recursive reset path!
>>> 
>>> ath_chan_set: concurrent reset! danger!
>>> 
>>> ath_raw_xmit: sc_inreset_cnt > 0; bailing
>>> 
>>> ath_legacy_rx_tasklet: sc_inreset_cnt > 0; bailing
>>> 
>>> Scanning doesn't work; ath0 says it is associated, but wlan0 says no
>>> channel.
>>> 
>>> I've set dev.ath.0.hal.debug=1, but there is no ath.0.debug either under dev
>>> or hw. I tried compiling the tools but it failed for lack of gcc.
>>> 
>>> TIA guys, but I am really under the pump here as I thought this would be a
>>> quick up and go now with the pkgng system as well in play. Now I'm up the
>>> proverbial creek without a paddle.
>>> 
>>> Cheers
>>> _______________________________________________
>>> freebsd-questions at freebsd.org mailing list
>>> http://lists.freebsd.org/mailman/listinfo/freebsd-questions
>>> To unsubscribe, send any mail to "freebsd-questions-unsubscribe at freebsd.org"
>> _______________________________________________
>> freebsd-questions at freebsd.org mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-questions
>> To unsubscribe, send any mail to "freebsd-questions-unsubscribe at freebsd.org"
> 
> _______________________________________________
> freebsd-questions at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-questions
> To unsubscribe, send any mail to "freebsd-questions-unsubscribe at freebsd.org"
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3955 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-questions/attachments/20140414/6d1b254a/attachment.bin>