From nobody Mon May 27 23:31:08 2024 X-Original-To: wireless@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4VpBjl5vTCz5Kyc8 for ; Mon, 27 May 2024 23:31:23 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-lf1-x129.google.com (mail-lf1-x129.google.com [IPv6:2a00:1450:4864:20::129]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4VpBjl44Wnz485c; Mon, 27 May 2024 23:31:23 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-lf1-x129.google.com with SMTP id 2adb3069b0e04-5238b7d0494so294093e87.3; Mon, 27 May 2024 16:31:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1716852681; x=1717457481; darn=freebsd.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=4QP3078IaFgOtsRPrUyKXbNnc4kHvKdktY6JADq8now=; b=ieEtyvNtSX9RlmewPGkD3AVWrTlbaYOieDhdjhG2Dzh/SqnWioEV4oQ5Qtrotr9eK1 vFZBg+FnwsDy1p4mHmpBHO2MW2HHA28nCSYdLqMF/oHFUgjviWeWXQsCEubFZMR3xcJ/ aaB+syCrYWcOuZy+tlDhiXpEQ9P8rPgEjCaR+S58TvSNM+4MLgdidk9WFlUxGcGRHftK 4xcPqUA8z2fqsXrjnF02oi4pOmMxw0qmwbGCP7grYbIWxOsTW9kXeUV6hPZyk6HibN05 Pns+FQWvBvWBK+KtCZ5xjXZpJWG4n9fM+egYtFTZnQlHZPa8QTvNHy+YnauuL4m0kOPO UwdQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1716852681; x=1717457481; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=4QP3078IaFgOtsRPrUyKXbNnc4kHvKdktY6JADq8now=; b=qRTFoFseZK2RxmdFeWWMPhwasspr7HGbbEvBukJIXBrTmEZLjE645JD77uF+0oJHni RqDwEkiXwAkHy65d/zauQpdyGuvOYniG2S15diUwXsS1FfOc8eYJhG5VIQMIWo+YTvfZ rTzvn0sfBtzJ7bHp3FUvD3+5HXTVGSWv1KwoMRo2uOrjan5p/lct6xaehaaY7beX1CmK v5qhkm4P9z/YJe/GuCHqejtio4G1s0hQOQy/jSvDJ1Eoc9a5ZPkibDmarU9pYeWwNAWt 3Uoy+N4jBoirTywqhRKtaDqYNi72Q/Ir2hUcf0hQ+NE0BrxiRRrXwlIK+CeoyExv5uFr P9/g== X-Gm-Message-State: AOJu0YzGdr9eni4QDMtbqFH0Rw/xZikTM7exkcbM/wrIkJhDXG6P3qpk TfNixdhRdWyioVIxuEvpxdqOCAojpbCuFu/9UtQzSNYF1uhI95iIiGwoXK2vdQjLEJp0yPlJopW ynmOMbs0emKGCeHnLD6MLokDl2lwocA== X-Google-Smtp-Source: AGHT+IFh6DhRC8pAGfqY0TbPCI3UxHabGIKTBKovJ8KHDlWA8kaWb57iI39eCgfYWZwBfQ57sDmtECniZO6RhqANQwA= X-Received: by 2002:a19:6902:0:b0:51b:6366:3459 with SMTP id 2adb3069b0e04-5296746417emr7632160e87.67.1716852680825; Mon, 27 May 2024 16:31:20 -0700 (PDT) List-Id: Discussions List-Archive: https://lists.freebsd.org/archives/freebsd-wireless List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: freebsd-wireless@freebsd.org Sender: owner-freebsd-wireless@FreeBSD.org MIME-Version: 1.0 References: <4rq46736-pnp2-nrp2-r3q9-3r3s3256os84@SerrOFQ.bet> In-Reply-To: <4rq46736-pnp2-nrp2-r3q9-3r3s3256os84@SerrOFQ.bet> From: Adrian Chadd Date: Mon, 27 May 2024 16:31:08 -0700 Message-ID: Subject: Re: wireless porject status report To: "Bjoern A. Zeeb" Cc: FreeBSD wireless mailing list Content-Type: multipart/alternative; boundary="0000000000002c2338061977eac5" X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; TAGGED_FROM(0.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US] X-Rspamd-Queue-Id: 4VpBjl44Wnz485c --0000000000002c2338061977eac5 Content-Type: text/plain; charset="UTF-8" On Mon, 27 May 2024 at 15:59, Bjoern A. Zeeb wrote: Last I got fed up by SCAN problems this afternoon and started > investigating. Have other people (with iwn/iwm/iwlwifi or others) noticed > the fact that once you are associated with a channel in a band (say Channel > 6) you will not get scan results for 11a/5Ghz anymore? Or that > sometimes scanning will "just stop" (way beyond scanvalid interval) and > triggering a manual scan (or from wpa_cli) you either just get the old > cache > or EINPROGRESS? (checking ddb on-off I noticed that the scan got stuck > in ACTIVE or BGSCAN was on suddenly despite IEEE80211_FEXT_SCAN_OFFLOAD > is set given iwlwifi does hw_scan and we never enable background > scanning). > I know this has bugged me in the past a lot on iwm(4) on 8xxx chipsets > and ifconfig down/ifconifg mode auto/ifconfig up fixed it again. > In case more people have observed similar things, please let me know > so we can properly track this. > Oh, wow, this is still a problem? Aiee. I remember fixing a WHOLE lot of races in the non scan offload and the then-new scan full offload paths. I'll see if I can reproduce it on iwn(4) (which supports full scan offload) and see what happens. A lot of this stuff originally used flags in multiple threads without actually using atomics + barriers and it was just super easy to get stuck :( -adrian --0000000000002c2338061977eac5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, 27 May 2024 at 15:59, Bjoern = A. Zeeb <bz@freebsd.org> wrote:=

Last I got fed up by SCAN problems this afternoon and started
investigating.=C2=A0 Have other people (with iwn/iwm/iwlwifi or others) not= iced
the fact that once you are associated with a channel in a band (say Channel=
6) you will not get scan results for 11a/5Ghz anymore?=C2=A0 Or that
sometimes scanning will "just stop" (way beyond scanvalid interva= l) and
triggering a manual scan (or from wpa_cli) you either just get the old cach= e
or EINPROGRESS?=C2=A0 (checking ddb on-off I noticed that the scan got stuc= k
in ACTIVE or BGSCAN was on suddenly despite IEEE80211_FEXT_SCAN_OFFLOAD
is set given iwlwifi does hw_scan and we never enable background
scanning).
I know this has bugged me in the past a lot on iwm(4) on 8xxx chipsets
and ifconfig down/ifconifg mode auto/ifconfig up fixed it again.
In case more people have observed similar things, please let me know
so we can properly track this.

Oh, wow,= this is still a problem? Aiee. I remember fixing a WHOLE lot of races
in the non scan offload and the then-new scan full offload paths.

I'll see if I can reproduce it on iwn(4) (which supports ful= l scan offload) and
see what happens. A lot of this stuff origina= lly used flags in multiple threads without
actually using atomics= =C2=A0+ barriers and it was just super easy to get stuck :(

<= /div>


-adrian

<= /div> --0000000000002c2338061977eac5--