Do firmware files in /lib/firmware have to be compressed with xz or are they also admissible as "firmwarename.fw" type
I am having a hauppauge card for sat and digital dvbt. Unfortunately after the latest update to the kernel Linux linux.fritz.box 6.9.1-1-default #1 SMP PREEMPT_DYNAMIC I am not able to sync channels anymore with kaffeine, the cards are seen correctly when I launch kaffeine but now channels or sync. The output when started from the CLI is: ntropy@linux:~> kaffeine 24-05-24 08:20:41.168 [Warning ] QCommandLineParser: already having an option named "h" 24-05-24 08:20:41.168 [Warning ] QCommandLineParser: already having an option named "help-all" 24-05-24 08:20:41.168 [Warning ] QCommandLineParser: already having an option named "v" vlc: unknown option or missing mandatory argument `--dumpdvb' Try `vlc --help' for more information. 24-05-24 08:20:41.207 [Warning ] kaffeine.mediawidget: libVLC: failed to use extra args: --no-video-title-show --dumpdvb 24-05-24 08:20:41.210 [Info ] kaffeine.mediawidget: Using libVLC without arguments 24-05-24 08:20:41.450 [Info ] kaffeine.dvb: Using built-in dvb device manager 24-05-24 08:21:00.693 [Info ] kaffeine.dev: Found dvb device P14f188800070f038: Montage Technology M88RS6000 24-05-24 08:21:00.703 [Info ] kaffeine.dev: Found dvb device P14f188800070f038: Silicon Labs Si2168 24-05-24 08:21:00.757 [Warning ] kf.service.services: KServiceTypeTrader: serviceType "ThumbCreator" not found 24-05-24 08:21:00.757 [Warning ] kf.service.services: KServiceTypeTrader: serviceType "ThumbCreator" not found 24-05-24 08:21:01.051 [Warning ] kf.service.services: KServiceTypeTrader: serviceType "ThumbCreator" not found 24-05-24 08:21:01.051 [Warning ] kf.service.services: KServiceTypeTrader: serviceType "ThumbCreator" not found 24-05-24 08:21:31.151 [Critical] kaffeine.dev: FE_SET_TONE: Risorsa temporaneamente non disponibile 24-05-24 08:21:58.551 [Critical] kaffeine.dev: FE_SET_TONE: Risorsa temporaneamente non disponibile [00007fbaf80014e0] mjpeg demux error: cannot peek [00007fbb00007710] mjpeg demux error: cannot peek In the journal some points to the firmware issue: mag 24 08:21:00 linux.fritz.box kernel: si2168 13-0064: firmware download failed -22 mag 24 08:21:00 linux.fritz.box kernel: si2168 13-0064: downloading firmware from file 'dvb-demod-si2168-b40-01.fw' mag 24 08:21:00 linux.fritz.box kernel: m88ds3103 13-0069: firmware did not run mag 24 08:20:41 linux.fritz.box kernel: m88ds3103 13-0069: downloading firmware from file 'dvb-demod-m88rs6000.fw' mag 24 08:20:41 linux.fritz.box kernel: m88ds3103 13-0069: found a 'Montage Technology M88RS6000' in cold state Have there been any changes with the kernel for what is firmware? Anybody knows? Thank you.
On Fri, May 24, 2024 at 9:28 AM Stakanov <stakanov@disroot.org> wrote:
In the journal some points to the firmware issue: mag 24 08:21:00 linux.fritz.box kernel: si2168 13-0064: firmware download failed -22
It is out of context and so meaningless.
mag 24 08:21:00 linux.fritz.box kernel: si2168 13-0064: downloading firmware from file 'dvb-demod-si2168-b40-01.fw'
There is no error after this message so we can assume the download was successful.
mag 24 08:21:00 linux.fritz.box kernel: m88ds3103 13-0069: firmware did not run mag 24 08:20:41 linux.fritz.box kernel: m88ds3103 13-0069: downloading firmware from file 'dvb-demod-m88rs6000.fw'
Again no error message.
mag 24 08:20:41 linux.fritz.box kernel: m88ds3103 13-0069: found a 'Montage Technology M88RS6000' in cold state
Have there been any changes with the kernel for what is firmware? Anybody knows?
I do not know what "change" you are talking about, but kernel first tries the literal file name as requested by driver and if it's missing then (if configured) tries compressed variants with appended .xz and .zstd.
In data venerdì 24 maggio 2024 10:18:17 CEST, Andrei Borzenkov ha scritto:
I do not know what "change" you are talking about, but kernel first tries the literal file name as requested by driver and if it's missing then (if configured) tries compressed variants with appended .xz and .zstd.
Well, I am searching for a solution for the problem I described and that appeared with the kernel change. Before: it worked. (With previous kernels). Now, after new install, does not work. Same instructions from Linux TV org. So what changes in the latest kernel could there be to cause this, if you know, then you are helpful. If you you don't know, you cannot help me. If you do not know but answer like "It is out of context and so meaningless." you may have just a size problem and are not helpful at all. Warm regards.
Am Freitag, 24. Mai 2024, 20:11:54 CEST schrieb Stakanov:
Well, I am searching for a solution for the problem I described and that appeared with the kernel change. Before: it worked. (With previous kernels). Now, after new install, does not work. Same instructions from Linux TV org.
So what changes in the latest kernel could there be to cause this, if you know, then you are helpful.
If you you don't know, you cannot help me.
If you do not know but answer like "It is out of context and so meaningless." you may have just a size problem and are not helpful at all.
Warm regards.
Open an bugreport... That is often the best practise. Stephan
In data sabato 25 maggio 2024 08:35:48 CEST, Stephan Hemeier ha scritto:
Am Freitag, 24. Mai 2024, 20:11:54 CEST schrieb Stakanov:
Well, I am searching for a solution for the problem I described and that appeared with the kernel change. Before: it worked. (With previous kernels). Now, after new install, does not work. Same instructions from Linux TV org.
So what changes in the latest kernel could there be to cause this, if you know, then you are helpful.
If you you don't know, you cannot help me.
If you do not know but answer like "It is out of context and so meaningless." you may have just a size problem and are not helpful at all.
Warm regards.
Open an bugreport...
That is often the best practise.
Stephan
Of course, but as good practice, before you open one, you ask on the pertinent mailing list if somebody sees already a problem, can avoid to open one by pointing to a straightforward solution which one may have overlooked, and answer straightforward questions. All this by respecting an acceptable communication level without void or patronizing or even straightforwardly aggressive behavior. So the pertinent and useful part here was, that the format of firmware is by itself not stringent but should (conditional is obligatory) be accepted as given in /lib/firmware. (All this would not have been necessary if I wouldn't have lost the former firmware files (which unfortunately "wouldn't, shouldn't" is not the case any more. Hence since I did not recall their former format, I had to ask). Hence, thank you, yes, I came to your solution too, so I will open a bug now, and thank you for your kind suggestion. Have a good weekend.
participants (3)
-
Andrei Borzenkov -
Stakanov -
Stephan Hemeier