On Wed, 11 Oct 2017 00:36:22 +0200
Stefan Sperling <[email protected]> wrote:
 
> AFAICT there was only one commit between 6.1 and 6.2 which
> could affect ath(4) in your situation.
> The diff below backs it out. Does it help?
> 
> Index: ath.c
> ===================================================================
> RCS file: /cvs/src/sys/dev/ic/ath.c,v
> retrieving revision 1.115
> retrieving revision 1.114
> diff -u -p -r1.115 -r1.114
> --- ath.c     31 May 2017 09:17:39 -0000      1.115
> +++ ath.c     11 Apr 2017 14:43:49 -0000      1.114
> @@ -1,4 +1,4 @@
> -/*      $OpenBSD: ath.c,v 1.115 2017/05/31 09:17:39 stsp Exp $  */
> +/*      $OpenBSD: ath.c,v 1.114 2017/04/11 14:43:49 dhill Exp $  */
>  /*   $NetBSD: ath.c,v 1.37 2004/08/18 21:59:39 dyoung Exp $  */
>  
>  /*-
> @@ -1417,6 +1417,7 @@ ath_beacon_config(struct ath_softc *sc)
>           __func__, ni->ni_intval, nexttbtt));
>       if (ic->ic_opmode == IEEE80211_M_STA) {
>               HAL_BEACON_STATE bs;
> +             u_int32_t bmisstime;
>  
>               /* NB: no PCF support right now */
>               bzero(&bs, sizeof(bs));
> @@ -1426,10 +1427,13 @@ ath_beacon_config(struct ath_softc *sc)
>               bs.bs_nextdtim = nexttbtt;
>               /*
>                * Calculate the number of consecutive beacons to miss
> -              * before taking a BMISS interrupt. 
> -              * Note that we clamp the result to at most 7 beacons.
> +              * before taking a BMISS interrupt.  The configuration
> +              * is specified in ms, so we need to convert that to
> +              * TU's and then calculate based on the beacon interval.
> +              * Note that we clamp the result to at most 10 beacons.
>                */
> -             bs.bs_bmissthreshold = ic->ic_bmissthres;
> +             bmisstime = MAX(7, ic->ic_bmisstimeout);
> +             bs.bs_bmissthreshold = howmany(bmisstime, intval);
>               if (bs.bs_bmissthreshold > 7) {
>                       bs.bs_bmissthreshold = 7;
>               } else if (bs.bs_bmissthreshold <= 0) {

I think this may be it.

Could not test the diff on -current due to ic->ic_bmisstimeout not
being available anymore, so I reverted the system to 6.1 and compiled
kernels from -D "2017-05-30" and -D "2017-06-01" checkouts.

The kernel from June-1st exhibited the issue right away:

ar5k_ar5212_nic_wakeup: failed to warm reset the AR5212
ath0: ath_reset: unable to reset hardware; hal status 16392   
ath0: device timeout

Kernel from May-30th - not yet, not after 30 minutes of actively trying
to trigger it, but need to run with it for couple more days to be sure.

--
Andre

Reply via email to