On 8/4/25 18:41, Bjoern A. Zeeb wrote:
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?
Compared to the last six months. I have been doing CURRENT snapshot
upgrades on a weekly to monthly basis and using fwget(8) to upgrade
iwlwifi just after, and sometimes in between. The issues I detailed
below have been constant during that time.
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.
In all the cases I mentioned, the interface stops passing traffic. It is
still connected to the AP. Restarting wpa_supplicant never fixes the
problem, but "service netif restart wlan0" always fixes it. I'm talking
about broken downloads (no ssh involved) like snapshot archives,
anything over a few MB. I would have to switch to ethernet and redo the
download, which always worked fine. I would also have to issue "service
netif restart wlan0" to get the wireless interface working.
I did watch the output of "dmesg -a" but had no idea what I was looking
at. Sorry I didn't report it at the time.
This all reminds me of a very important symptom I forgot to mention
before. After restarting the wireless interface, touchpad and keyboard
input would get really choppy as kernel utilization, observed with "top
-PCS", would go through the roof for 30-60 seconds. Maybe this happened
most of the time, not every time.
* 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.
Yes, I will try that, but whenever the issue occurs I am actively
browsing. The last time it happened I was researching various items and
had about 50 open tabs with recipe sites, shopping sites and Startpage
searches. I was having to restart the interface more and more frequently
-- I even tried unloading and loading the kernel module - and finally
the system became unresponsive (I did not try to ssh in remotely, but
have tried that before under similar circumstances and the system could
not be reached) and I had to reboot. I assumed it was because of too
much traffic.
That is what prompted me to finally try building
wifi-firmware-iwlwifi-kmod from ports because I noticed it was a newer
version. In three days of moderate use since then I have not had to
manually run "service netif restart wlan0" once; I also haven't had
nearly as many tabs open.
* 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
Do you mean when the system freezes? Are you talking about typing those
commands in a terminal, or are you saying the system, in such state,
might accept those commands as input regardless of the active window (I
can't imagine that's what you mean but just checking).
Thanks for the tip, I will try it. In fact, thanks for all the tips and
for all your work on this project.
Ross
