Please always reply to the bug report (I'll see it then too)! On woensdag 3 april 2024 22:01:20 CEST you wrote: > Thanks, I am working on that, but it's not trivial > > (1) About firmware > > These are provided by debian and cause the problem > -rw-r--r-- 1 root root 1299660 2023-05-01 21:30 > iwlwifi-QuZ-a0-hr-b0-59.ucode -rw-r--r-- 1 root root 1370356 2023-05-01 > 21:30 iwlwifi-QuZ-a0-hr-b0-72.ucode > > I grabbed new fw from a TI git repo, but the debian kernel does not load any > of them. Is fw signed? Do I need to sign it with my MOK? Use the upstream repo to get the files. The files aren't signed. https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/ The `dmesg` command will tell you which firmware files it's trying to load. Then DL that(/those) file(s) from the repo and put them in /lib/firmware/ Then on next boot the kernel will find them. > -rw-r--r-- 1 root root 1369976 2024-04-03 21:24 > iwlwifi-QuZ-a0-hr-b0-73.ucode -rw-r--r-- 1 root root 1371668 2024-04-03 > 21:24 iwlwifi-QuZ-a0-hr-b0-74.ucode -rw-r--r-- 1 root root 1404184 > 2024-04-03 21:24 iwlwifi-QuZ-a0-hr-b0-77.ucode > > (2) About kernel experiments, unfortunately it is a production server with > samba-ad and ad replication. It uses btrfs and snapshots work great, but it > needs some work (disable email services, make snapshots, stop all clients, > testing, restore snapshots, reenable email, restart clients). > > (3) Instead I will try first to use debian testing on a different NUC, but > this will take some time. > > 2. April 2024 20:28, "Diederik de Haas" <didi.debian@cknow.org> schrieb: > > On Tuesday, 2 April 2024 19:54:41 CEST J. Pfennig wrote: > >> Package: src:linux > >> Version: 6.1.76-1 > >> Severity: important > >> Tags: upstream > > > > I am/was inclined to remove that tag, but the problem is likely caused by > > firmware which is too old for the 'backported' patches that upstream > > applied.> > >> The driver fills the eventlog with millions !!! of messages, see below. > >> It otherwise works. The problem can be reproduced on different NUC > >> systems. > > > > If you downgrade the kernel version, does the issue then go away? > > > >> ** Kernel log: > >> [30911.569896] BTRFS info (device sda4): disk space caching is enabled > >> [30974.905443] net_ratelimit: 67420 callbacks suppressed > >> [30974.905457] iwlwifi 0000:00:14.3: Unhandled alg: 0x33f0707 > >> [30974.905728] iwlwifi 0000:00:14.3: Unhandled alg: 0x33f0707 > >> [30974.906036] iwlwifi 0000:00:14.3: Unhandled alg: 0x33f0707 > > > > https://unix.stackexchange.com/a/721474 looks related and the solution is > > to upgrade the firmware to a newer version. > > That isn't available on Stable, but grabbing ``firmware-iwlwifi`` from > > Testing should be safe. Not sure if that version is new enough though. > > > > https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.gi > > t > > is the upstream repo and you could 'grab' the firmware files which `dmesg` > > reports it can't find. > > > >> -- System Information: > >> Debian Release: 12.5 > >> APT prefers stable-security > >> APT policy: (500, 'stable-security'), (500, 'stable') > >> Architecture: amd64 (x86_64) > >> > >> Versions of packages linux-image-6.1.0-18-amd64 is related to: > >> ii firmware-amd-graphics 20230210-5 > >> pn firmware-atheros <none> > >> pn firmware-bnx2 <none> > >> pn firmware-bnx2x <none> > >> pn firmware-brcm80211 <none> > >> pn firmware-cavium <none> > >> ii firmware-intel-sound 20230210-5 > >> pn firmware-intelwimax <none> > >> pn firmware-ipw2x00 <none> > >> pn firmware-ivtv <none> > >> ii firmware-iwlwifi 20230210-5 > > > > My guess is that those 'backported' patches expect newer firmware then > > that.
Attachment:
signature.asc
Description: This is a digitally signed message part.