From owner-freebsd-questions@FreeBSD.ORG Wed Apr 16 13:08:05 2014 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 777AD805; Wed, 16 Apr 2014 13:08:05 +0000 (UTC) Received: from mail.unitedinsong.com.au (mail.unitedinsong.com.au [150.101.178.33]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C8BAA1C8E; Wed, 16 Apr 2014 13:08:04 +0000 (UTC) Received: from laptop2.herveybayaustralia.com.au (laptop2.herveybayaustralia.com.au [192.168.0.100]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mail.unitedinsong.com.au (Postfix) with ESMTPSA id F1D2127322; Wed, 16 Apr 2014 23:07:55 +1000 (EST) Message-ID: <534E80AB.4000007@herveybayaustralia.com.au> Date: Wed, 16 Apr 2014 23:07:55 +1000 From: Da Rock User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130516 Thunderbird/17.0.6 MIME-Version: 1.0 To: Adrian Chadd Subject: Re: FBSD10 Atheros wifi not working References: <534B32FA.30500@herveybayaustralia.com.au> <534BC380.90608@herveybayaustralia.com.au> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Questions X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Apr 2014 13:08:05 -0000 On 04/15/14 12:16, Adrian Chadd wrote: > Wait, you don't have this problem on the install image when running from USB? I thought I had answered this, but it doesn't appear to be showing in the list (but that could just be my dying machine here with a slow email client). Thats the weird part of all this: the install disk could scan for APs and setup the network, but the actual installed system is having a coronary and can't do anything. I've now managed to build a new kernel and install it (with debug), and still no go. I can send the error logs if needed (privately), but I do notice a lot of messages involving more than just the 9285 chipset (5416, 5212) - is this normal? The kernel picks the right product, as the logs show ath0: and 'AR9285E_20 detected'. The errors remain unchanged though. This new kernel also seems to crash quicker (or lock, might be a better term - I need to hold the power button down and reboot for a response). The other gave more time - might be the debug options? This happens despite the sysctls turned off; with them on it turns in seconds rather than around 2-3 minutes. I could speculate further, but I reckon I'd hinder more than help at this point. > > > -a > > > On 14 April 2014 04:16, Da Rock > 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 , 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 >>> 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@freebsd.org mailing list >>>> http://lists.freebsd.org/mailman/listinfo/freebsd-questions >>>> To unsubscribe, send any mail to >>>> "freebsd-questions-unsubscribe@freebsd.org" >>> _______________________________________________ >>> freebsd-questions@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-questions >>> To unsubscribe, send any mail to >>> "freebsd-questions-unsubscribe@freebsd.org" >> >> _______________________________________________ >> freebsd-questions@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-questions >> To unsubscribe, send any mail to "freebsd-questions-unsubscribe@freebsd.org"