From nobody Thu Mar 06 13:18:34 2025 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 4Z7qkM0qKMz5pbDg for ; Thu, 06 Mar 2025 13:18:51 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-lf1-f46.google.com (mail-lf1-f46.google.com [209.85.167.46]) (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 4Z7qkL68SBz3gMk; Thu, 06 Mar 2025 13:18:50 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-lf1-f46.google.com with SMTP id 2adb3069b0e04-5439a6179a7so687670e87.1; Thu, 06 Mar 2025 05:18:50 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1741267127; x=1741871927; 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=Oa2NLmd2DvCvXDrWs52cb8FgTQKWOak1Vd9y00zMa/c=; b=QX4cLxst6rgOJ9pt1pt2+Pdq2yge5jaOJt1Y+6mD8GESacPrOqMuMw6YUuc3j2ysjC 3G4Lc3qfzHsWb+sYjzbuYBQCjJSxrQy0ivd6ic1iuIiHIxxAVWfl1tV7eXzZv50gqKHM la4rgDem8hxcK/sPSd/khf+ufEihGIhlXo+deFnAHkrworKQsutwhKcgFdBTPC2tNb0n 2UVnRDiOiYdwYJ2X0ahs3DlVfkiCA2ekbO32z0MBg+vjHomwUBG/Ys+5vUfs30uwbRdw w32nSBToSOR2DKOu2kCseYj6ir3QM6W24W6Me2As32nj7gYfEXMoDBSD6kDucD1Y7sA0 81+w== X-Forwarded-Encrypted: i=1; AJvYcCW7n6bfoA43jdX7hkjCqPx7ufff8a+EhpFqAOB5qMHcZgoqA6QqZpHVGwsbTxR9xHR9Z2xhKHjOmQ==@freebsd.org X-Gm-Message-State: AOJu0YwC6n1Ae3G4HIwvip8shaiwu+zFLYqSmqsptyKKVvB35UsNQEwz dJhn26UicPtbmkNrhVMfNhY2PV/22tfLLKwSmA/REONGKVmY/47gwOIEEBM7R5ZlFrHLrnlc0TW KMqRqYNC9dPzJrIuKp7CSucS48Jhb6A== X-Gm-Gg: ASbGncvDssPEV8ysBr3OSTLSOX3OKi7bA29xmMnNLJVz5AouHDsQL8ZsIzpq5We/Kic A/FbaoMuBMmLwzY7HW49Kx638StVDn104OqoXCOv6r/3DcEPPhHcR8N6qsb4Zi3hE5UyXzUXEG2 BCQo0w7FsWs+gM2Tckx0igAMkRmW4= X-Google-Smtp-Source: AGHT+IEMKJiu7wTt53QR3Sw6WOdHPyyakcNlx2IZLZneFliVNeWdj/Jj96ajHnMBLGRErqCShxQUiDB6lgWSpBSTBH8= X-Received: by 2002:a05:6512:1153:b0:548:ae6e:bf43 with SMTP id 2adb3069b0e04-54984c1687amr1338100e87.24.1741267127349; Thu, 06 Mar 2025 05:18:47 -0800 (PST) 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: <38523r8n-46pr-9r68-8049-47pqqr774711@SerrOFQ.bet> <63xz4b6wrnhr4zwune5sbdflumjk5nlqwkq35cm2yh55sskkm7@nebya5fcoknu> In-Reply-To: From: Adrian Chadd Date: Thu, 6 Mar 2025 05:18:34 -0800 X-Gm-Features: AQ5f1JqwLP6VBXsIxmKJOfsPSSwwSY4kR2MW2eFjRjtWL8y4ro_Im2Knb4YJSO4 Message-ID: Subject: Re: HEADS UP! Do not update on main currently (panic - on boot) To: "Bjoern A. Zeeb" Cc: Baptiste Daroussin , FreeBSD wireless mailing list Content-Type: multipart/alternative; boundary="00000000000095bba4062fac581a" 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:209.85.128.0/17, country:US] X-Rspamd-Queue-Id: 4Z7qkL68SBz3gMk X-Spamd-Bar: ---- --00000000000095bba4062fac581a Content-Type: text/plain; charset="UTF-8" On Thu, 6 Mar 2025 at 01:44, Bjoern A. Zeeb wrote: > On Thu, 6 Mar 2025, Baptiste Daroussin wrote: > > > On Wed 05 Mar 23:39, Bjoern A. Zeeb wrote: > >> Hi, > >> > >> the fix from > https://cgit.FreeBSD.org/src/commit/?id=27bf5c405bf2eb69392e45c06605defc78882612 > >> makes wireless panic for me in my development branch; that said I am > >> working on TKIP currently so I have code in progress. > >> > >> In case you hit the panic (on boot) because you have updated, please > >> disable the HW_CRYPTO tunable from loader and live without HT/VHT for a > >> few hours again. > >> > >> I am looking where the problem comes from now and for a fix then. > >> > >> /bz > >> > > > > Thanks for the heads up! > > > > The weekly snapshots for pkgbase are generated the weekend, if you > haven't been > > able to figure out a fix by then, if would be nice for pkgbase consumers > if you > > could revert the change before the next snapshot building. > > > > Many people took the habbit to run pkgbase from weekly snapshots and > reboot > > every monday on a fresh new current machine. > > I have a very crude workaround I am testing. I still hope to be able to > fix it more properly if net80211 locking allows us. > > The problem isn't so much of reverting. > 11db70b6057e41b259dc2245cd893d5b19179fcc > taked about the possible panic on key delete I could not reproduce > anymore. As I had guessed the mentioned commit was the reason. The > problem was that that commit had logic inverted and we corrected that > yesterday so now net80211 and ath AP mode and others are fine again but > the panic on key delete is back depending on timing. > > The problem is that net80211 already has incosistent locking there and > we have to conditionally unlock for the downcall to driver/firmware > which can sleep. > Both together opens a possible race which is there in theory with or > without LinuxKPI as it is two threads (wpa and net80211) racing. > I am just able to trigger it again (note that some drivers simply omitted > these bits; that's why you don't see ic_cryptocaps set in iwm or iwn) > but that no longer works as firmware needs to be able to handle crypto > for doing A-MPDU offloading. > Ah crap, can you email me the panic and stack traces? It seems fine on rtwn which does HW crypto, but its also very possible that rtwn already has the workarounds. -adrian --00000000000095bba4062fac581a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, 6 Mar 2= 025 at 01:44, Bjoern A. Zeeb <bz@freeb= sd.org> wrote:
On Thu, 6 Mar 2025, Baptiste Daroussin wrote:

> On Wed 05 Mar 23:39, Bjoern A. Zeeb wrote:
>> Hi,
>>
>> the fix from https://cgit.FreeBSD.org/src/commit/?id=3D27bf5c405bf2eb69392e45c06605d= efc78882612
>> makes wireless panic for me in my development branch;=C2=A0 that s= aid I am
>> working on TKIP currently so I have code in progress.
>>
>> In case you hit the panic (on boot) because you have updated, plea= se
>> disable the HW_CRYPTO tunable from loader and live without HT/VHT = for a
>> few hours again.
>>
>> I am looking where the problem comes from now and for a fix then.<= br> >>
>> /bz
>>
>
> Thanks for the heads up!
>
> The weekly snapshots for pkgbase are generated the weekend, if you hav= en't been
> able to figure out a fix by then, if would be nice for pkgbase consume= rs if you
> could revert the change before the next snapshot building.
>
> Many people took the habbit to run pkgbase from weekly snapshots and r= eboot
> every monday on a fresh new current machine.

I have a very crude workaround I am testing.=C2=A0 I still hope to be able = to
fix it more properly if net80211 locking allows us.

The problem isn't so much of reverting.=C2=A0 11db70b6057e41b259dc2245c= d893d5b19179fcc
taked about the possible panic on key delete I could not reproduce
anymore.=C2=A0 As I had guessed the mentioned commit was the reason.=C2=A0 = The
problem was that that commit had logic inverted and we corrected that
yesterday so now net80211 and ath AP mode and others are fine again but
the panic on key delete is back depending on timing.

The problem is that net80211 already has incosistent locking there and
we have to conditionally unlock for the downcall to driver/firmware
which can sleep.
Both together opens a possible race which is there in theory with or
without LinuxKPI as it is two threads (wpa and net80211) racing.
I am just able to trigger it again (note that some drivers simply omitted these bits; that's why you don't see ic_cryptocaps set in iwm or iw= n)
but that no longer works as firmware needs to be able to handle crypto
for doing A-MPDU offloading.

Ah crap, c= an you email me the panic and stack traces?

It see= ms fine on rtwn which does HW crypto, but its also very possible that rtwn<= /div>
already has the workarounds.


<= div>
-adrian

--00000000000095bba4062fac581a--