On Mon, 4 Aug 2025, S. Ross Gohlke wrote:

I am running the latest CURRENT snapshot with the latest wifi-firmware-iwiwifi-kmod built from ports, and so far it seems to be experiencing fewer glitches.

Compared to when?


Despite the fact that FLAVOR options are absent in the Makefile, the various firmwares are indeed implemented as flavors.

They are not absent the Makefile includes a parent Makefile.inc which
translates the FWSUBS= list into FLAVORS..  The magic all happens there
as all the wifi-firmware-*-kmod ports need it.

Unlike other kmods, this one does not require that /usr/src be populated.

Yes because on main and stable/14 firmware files can be loaded as such
and no longer need to .kos;  for stable/13 we are still building .ko
files.


* Large downloads bring down the interface; with my current installation I was able to download libreoffice distfiles, about 400MB, without incident

"bring down the interface" meaning what;  no download will do an
ifconfig wlan0 down

Do you get firmware crashes or do your downloads break or ssh
connections drop or ..?

I am asking because I have a dev branch where I get packets which passed
the FCS up but later I am getting checksum errors on the upper layers; I
do notice because I played around with checksum offloading and so the
stack no longer catches them...  I've not had a chance to see what's
wrong and where the invalid data comes from;  it happens too
occasionsally.


* Interface stops working periodically (every one to 30 minutes), perhaps due to having too many misbehaving websites simultaneously loaded in Firefox; so far I have not had to manually restart netif service

Funny;  can you let a ping run in the background somewhere to your
router (the default gateway) or if you do IPv6 try something like:
        ping6 -n -i 42 ff02::2%wlan0
I am curious if your AP disconnects you for inactivity.

* Occasionally over the last few months, frequently restarting netif service freezes the system; I have not used the current installation long enough to say if this is resolved

I had 7 of them over the weekend; one was WiFi with my own dev code; the
others were drm, usb, ...
Given you are runing CURRENT ddb should be enabled; if you have a dump
device set in rc.conf you could blindly try to type the following when
it happens (write it down somewhere maybe so you have it at hand if you
cannot get to emails otherwise):
        dump
[wait 15 seconds]
        reset

You can repeat that a few times;  sometimes it doesn't work right away
for me;  chances are if it works that you get a crashdump and you can
figure out if what caused the panic.

/bz

--
Bjoern A. Zeeb                                                     r15:7

Reply via email to