On Thu, 6 Mar 2025 at 01:44, Bjoern A. Zeeb <b...@freebsd.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=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
