Date: Sun, 23 Nov 2014 13:23:55 +0100 From: Thomas Zander <riggs@freebsd.org> To: Adrian Chadd <adrian@freebsd.org> Cc: Danilo Egea Gondolfo <daniloegea@yahoo.com.br>, FreeBSD Stable Mailing List <freebsd-stable@freebsd.org> Subject: Re: ath(4) device timeout -> reboot necessary Message-ID: <CAFU734yUsBy8FXyS2C9%2BzUXQLHQhhgMFrzTuSC5=D36A-8EbTw@mail.gmail.com> In-Reply-To: <CAJ-Vmo=wUr%2BCTJA7zkANR3LAaDSYOW3eBVNwFK8xt22UBGOCdw@mail.gmail.com> References: <20141122171734.GA4600@marvin2011.fritz.box> <5470C695.3040204@yahoo.com.br> <CAJ-Vmo=wUr%2BCTJA7zkANR3LAaDSYOW3eBVNwFK8xt22UBGOCdw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 22 November 2014 at 19:11, Adrian Chadd <adrian@freebsd.org> wrote: > Try setting > sysctl dev.ath.0.hal.force_full_reset=1 Thanks Adrian. I put this into sysctl.conf and observe the effects over the next weeks. > But the reason the AR9287 is going deaf is still unknown. In station > mode we detect it by seeing missed beacons and doing a hardware reset. > In AP mode we don't have that; we just see it failing to do noise > floor calibration and we never hear any frames. Then I guess I am lucky that at the moment I operate the device only in station mode :) > There are also issues with wpa_supplicant being run more than once at > a time due to issues with the rc script side of things and it's > confusing the wifi drivers. I haven't really looked into it in that > much detail - I was hoping the RC scripts would be fixed, but I'm > going to have to fix the driver to at least not confuse the hardware. True, looking into the rc scripts is certainly a part of the job, but as you said, getting the driver reliable "no matter what" would definitely be appreciated. Let us know if there is anything we can do to help debugging / testing! Best regards Riggs
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAFU734yUsBy8FXyS2C9%2BzUXQLHQhhgMFrzTuSC5=D36A-8EbTw>