<SiFuh>
This one also didn't cover the dowels with the dragonfly emblem. Hmmmm
zorz has joined #crux-social
<farkuhar>
SiFuh: stenur has been promoting zstd compression on the mailing list (at least in regards to pkgmk/bsdtar), so I thought I'd try out compressing the kernel modules with zstd. But I never successfully got them to load, even after activating the option "support in-kernel decompression". I notice that your modular kernel config sets module compression to "None", which is the setting I restored after the zstd experiment failed.
<SiFuh>
farkuhar: I always use ZSTD compression in my kernels on my systems. I set it to default because if you set it to ZSTD CRUX would always complain that you didn't have ZSTD installed. But I think now ZSTD is CRUX core now
<farkuhar>
The kernel decompresses itself just fine using the zstd algorithm, but it fails to load any *.zstd files under /lib/modules, so only the hardware supported by compiled-in drivers is available on boot. The error message is ENOENT, as if modprobe couldn't find a file of the intended name.
<SiFuh>
You will need an initramfs with it included
<farkuhar>
But wouldn't the option "support in-kernel decompression" make an initramfs unnecessary? It's not decompressing in userspace, if I understand the documentation correctly, so there's no need for zstd to be in $PATH.
<SiFuh>
Not sure if builds it into the kernel with the ability to run the command within itself
<farkuhar>
If your repo server has module compression mode="None" (i.e., # CONFIG_MODULE_COMPRESS_ZSTD is not set), then of course it wouldn't need an initramfs. I'm wondering whether you can get away with no initramfs, using the "in-kernel decompression" feature to load the modules, or whether it requires a rebuild of kmod too.
<SiFuh>
farkuhar: I am compressing the kernel, not the modules.
<farkuhar>
SiFuh: I don't have any problem with the kernel decompressing itself, but if I wanted to save disk space under /lib/modules, it would be nice to know what else is needed to get zstd compression working there too. According to the kmod ./configure script, you need to pass the option --with-zstd, and our kmod Pkgfile doesn't do that.
<farkuhar>
So if our kmod binary does not recognize *.zstd as a valid module filename, that would explain the ENOENT failure in dmesg. The kernel itself would probably be able to perform the decompression (after toggling the appropriate option in make menuconfig), but it never sees the file because of kmod's strict filename globbing.
<SiFuh>
Alright. Building the kernel. Will be done in 5 days or so
<SiFuh>
Hahaha and I have --with-zstd in my kmod so that is all good
<farkuhar>
It looks like our kmod port doesn't build in support for _any_ compression, even though xz zlib and zstd are all in core. Why wouldn't we enable those features by default for everybody?
<farkuhar>
Hahaha you have --with-zstd in your kmod, but not in the package you built for the CRUX-MUSL iso? Why should others have to reconfigure and rebuild a core port, when you could just package it with all the compression modes enabled?
<SiFuh>
And I am not going to do a linux-pam maneuver
<SiFuh>
Oh wait, you want me to try on the MUSL machine. Okay. That kmod shouldn't have with zstd
<farkuhar>
Is there a known issue with enabling zstd in the kmod package on CRUX-MUSL? It wouldn't be a "linux-pam maneuver" to tweak the Pkgfile on a forked distro; you're already assuming responsibility for all the core ports, so why not configure them more sensibly than the official CRUX does?
<zorz>
farkuhar: i think at the end official will be the crux-musl and not the CRUX :-)
<SiFuh>
farkuhar: I did not take responsibility. I just built it. It's up to everyone else now to do as they will.
<farkuhar>
SiFuh: I stupidly rebuilt kmod and updated it without backing up the original package. Now I'm experiencing the segfault that emmett1 already fixed, and I don't remember where to find his musl patch.
<SiFuh>
farkuhar: I just looked at the musl port of kmod and it has with-xz and with-zlib
<SiFuh>
Zstandard is a lossless data compression algorithm developed by Yann Collet at Facebook. Zstd is the corresponding reference implementation in C, released as open-source software on 31 August 2016.
<farkuhar>
Gitlab's JS-heavy frontend has the drawback of not being very navigable in lynx. On the plus side, it does allow the nifty feature of downloading only a subdirectory of someone's repo (in contrast to standard command-line git, which doesn't support subdirectory checkout, as ukky reminded us a few days ago).
<SiFuh>
I moved to gitlab because github was too slow. I'd upload new ports or modify ports and sometimes several hours later before it would let me pull it.
<farkuhar>
SiFuh: thanks for updating the kmod Pkgfile. Now we can all enjoy the smaller footprint of /lib/modules, without having to rebuild a core port ourselves.
<SiFuh>
But you will have to ;-) Because I never updated the ISO
<SiFuh>
I can't find my beer... Hmm. Must have finished it
<SiFuh>
It's only core and a few opt but it is basically the foundations for anyone who wishes to take it and run.
ppetrov^ has left #crux-social [Leaving]
emmett1 has quit [Quit: emmett1]
<farkuhar>
SiFuh: 20M /lib/modules/6.6.30 (Zstd compression) versus 66M /lib/modules/6.6.30.bak (no compression).
<SiFuh>
Not bad
<SiFuh>
So Facebooks compression is what you plan on using now
<SiFuh>
That was suppose to be a question. Hahaha
<farkuhar>
I now have a kmod that handles both compressed and uncompressed kernel modules, but alas the internal soundcard is not fully initialized. At least on Linux we have the alsa-info script, which gives useful troubleshooting output: http://sprunge.us/27UQD3
<SiFuh>
farkuhar: Compressive!
<farkuhar>
The 1.515412 dmesg is suggestive ("0000:00:1f.3: iDisp hw present but no driver", followed immediately by the codec probe error). I've been reconfiguring and recompiling the kernel for several days already, and I thought by now I would have stumbled upon the right driver. Surely the hardware is not too new to be unsupported by the 6.6.30 kernel?
<ukky>
farkuhar: I might be wrong, but it seems like your HW needs this firmware: /lib/firmware/intel/sof/sof-jsl.ri
<ukky>
farkuhar: Check these structures in sound/soc/sof/intel/pci-icl.c : sof_pci_ids and jsl_desc. Your HW is PCI_DEVICE_DATA(INTEL, HDA_JSL_N, &jsl_desc)
<farkuhar>
ukky: thanks. I think I installed the sof-bin firmware in the correct path, but I'll check again.
<farkuhar>
ukky: I downloaded a release of sof-bin that doesn't populate all the directories listed in pci-icl.c, only the directories satisfying the SOF_IPC bitmask: http://dpaste.org/SAKMh Maybe that firmware tarball is meant to be used with a different kernel, or I have to reconfigure the 6.6.30 kernel so that SOF_IPC4 isn't matched.
<ukky>
farkuhar: Could you upload full boot log and `lspci -nnk`?
lavaball has quit [Remote host closed the connection]
DesRoin has quit [Ping timeout: 268 seconds]
DesRoin has joined #crux-social
<ukky>
farkuhar: Check function sof_pci_probe() in sound/soc/sof/sof-pci-dev.c, it decides which directory and file to load firmware from. Maybe you can play with <module>.{fw_path,tplg_path,fw_filename,tplg_filename}