Hi,
Nope. In theory the full reset is doing just that.. a full chip cold
stop and start. There's only a handful of state that needs a full
reset line pulldown to achieve.
So if that's fixing it then ok, maybe there's some issues i can patch
aronud by doing a full chip reset. I wonder if there are also some
bugs lurking in some of the calibration code that keeps state over
time; or the ANI code that keeps state over time.
-adrian
On 14 December 2014 at 09:23, Thomas Zander <riggs at freebsd.org>
wrote:> On 23 November 2014 at 13:23, Thomas Zander <riggs at freebsd.org>
wrote:
>> On 22 November 2014 at 19:11, Adrian Chadd <adrian at
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.
>
> I made the following observations in the past two weeks regarding this
sysctl:
> - Reboots are not strictly necessary after an ath0 device timeout to
> get wifi to reconnect, as you expected,
> - If a device timeout has happend once, it is a virtual certainty to
> get the next one within 2 hours. This continues until the next reboot.
> So *something* might not get reset fully
>
> Any ideas?
>
> Best regards
> Riggs