Date: Mon, 27 May 2024 22:59:08 +0000 (UTC) From: "Bjoern A. Zeeb" <bz@FreeBSD.org> To: FreeBSD wireless mailing list <wireless@freebsd.org> Subject: wireless porject status report Message-ID: <4rq46736-pnp2-nrp2-r3q9-3r3s3256os84@SerrOFQ.bet>
next in thread | raw e-mail | index | archive | help
Hi, as indicated last week I somehow worked my way backwards. The fix for pre-22000 chipsets (PR 275255) went in as 5a4d24610fc6143ac1d570fe2b5160e8ae893c2c . Thanks Bakul for testing! I have not had any further feedback on that so I'll MFC it the next days to stable/14 and stable/13. Some other (older) Reviews went in or were updated. In case you see more warnings now like lkpi_iv_newstate: error 95 during state transition 2 (AUTH) -> 2 (AUTH) this is just another side effect/closing race of the long-standing 13+ years net80211 problem which we worked around in LinuxKPI beginning of the years and which LinuxKPI does log and assert. We hope we'll work on that during the year as well and fix all that and it'll go away. If you have a moment, D43967 (updated comments) and D45358 (LinuxKPI PM bits needed to get D3 code) would welcome any review currently. The wifi-firmware-*kmod ports changes went in and cause some disruption (INDEX and non-default options). Thank to jrm@ for helping (and also the ongoing follow-up cleanup). If more ports committers are interested in WiFi please let us know. I would appreciate more "ports" help. Likewise the fwget(8) change went in and should now support all recent drivers (even for bits where no public hardware/firmware exists yet but the iwlwifi driver already supports, so that in future releases adding the firmware will be the only thing needed). On the vendor import side nothing has happened and likely at the end of this week (given stabilisation week was just announced) I'll put the updates in as-are and we'll deal with it otherwise. On the busdma problems on arm64, jhb pointed out that some of the *alloc*/free routines in LinuxKPI are not implemented to the expectations of Linux. I've started to work down his suggestions. As a start I had made changes to the skbuff allocator and kern_malloc.c and the last days extended those well into LinuxKPI *alloc*. I also found my reproducer of the old problem in a driver again (as more things started to work) and worked around that in iwlwifi for now. while this is not directly related to wireless but the general "fixes" hopefully will give LinuxKPI consumers more stability. I also kept working a bit on my 11n branch; hopefully more news to talk about there also soon. 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. Lots of health, Bjoern -- Bjoern A. Zeeb r15:7
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4rq46736-pnp2-nrp2-r3q9-3r3s3256os84>