Re: [Trisquel-devel] success on arm64 Supermicro ARS-110M-NR
On 2024-07-10 06:45, Simon Josefsson wrote: Jing Luo writes: formatted the rootfs as btrfs, with linux-generic-64k-hwe-11.0-edge What is the benefit of the 64k kernels? The package description doesn't really say one would just them over the other ones. Are there performance differences? From what I understand, larger page size means that the memory allocation will be less computationally expensive. But so far I don't know if there is real, visible difference in performance. However, larger page sizes can break compatibility, like Proxmox uses a certain Rust jemalloc that only supports 4K page size (so I've heard). Your Talos II should default to 64K page size, I remember only seeing the 64K option in linux's menuconfig for ppc64el. Also, Raspberry Pi foundation ships 16K page size kernel (non-free) with Raspberry Pi 5. https://en.wikipedia.org/wiki/Page_%28computer_memory%29#TLB_usage Right now, I am using linux-libre 6.9.8 on my machine (thanks Jason for releasing gnu-2.0 versions in gzip format!) because of a known (mostly cosmetic) bug with the mpt3sas driver that also occurs on amd64. I didn't have any issues with the vanilla trisquel kernel before adding the LSI card to the machine. I tried the linux-libre-lts 6.6 packages and they work fine on this machine too. Ah yes! Although from a user's perspective, I usually don't recommend using upstream packages directly, be it linux or linux-libre (freesh), because they tend to be raw and unrefined. Downstreams like Trisquel (or even Debian) have a more refined config/preset and is more suitable for day-to-day uses. An example would be the issue you encountered with gzipped/uncompressed vmlinuz, Trisquel or Debian didn't break when freesh did (no offense to our hero Jason). There are plans to improve the node stack, as Ecne will be adding riscv and more load to arm, but that's is still on it's way. Using community vm/nodes might require to layout some security policies, and some other directives, we'll need to find some time to define those if moving in that direction. I am also happy sponsor build machines here, but I understand the dilemma about riscv. Either you purchase some riscv machine and set it up yourself (I am happy to donate funding for this), but then as far as I understand the requirements, we would need to make sure it runs on only free software and no blobs. I got my Milky-V Pioneer riscv machine working via upstream's kernel image and Debian debootstrap. I have tried installing both Debian and linux-libre kernels, but I just get a blank screen when booting. I have been hoping for months that the Debian people make progress on a kernel for this hardware, but I don't know if there is any known problem or just lack of time. So we don't really know if this machine can ever boot without some non-free blob or not. The alternative is to build in people's VM, and I'm happy to setup a VM on the riscv machine I have, but then there are BOTH trust issues with the hoster and the uncertainty about freedom of the hardware. I don't know of a way to resolve this... I would be unhappy if ecne won't ship with riscv due to this. There are not that many unique packages in trisquel, it would be entirely possible to rebuild all of them on a new hardware eventually to increase trust in the packages. I would be happy if Trisquel becomes the first 100% libre distro that officially supports riscv64. Before that happens...I'm stuck with debian sid. I think if you build u-boot and linux(-libre) from source for a certain board, you should know if that board can boot with only free software. I also have a few SBCs that won't boot with upstream or debian's kernel, so I ported many patches from "vendor kernel" then build the kernel myself. They are buggy, many drivers won't work properly, but at least they are libre, unlike the blob-ridden "vendor kernel". However, I have a RK3588 based ROCK 5B that requires me to insert a blob when compiling u-boot, that was when I realized RK3588 requires non-free software... So the conclusion is, if the board can boot with a "clean" u-boot and linux-libre, then it doesn't require non-free blobs to boot. However, in many cases, HDMI and GPU won't work without blobs, but I gave up on those already (who needs framebuffer support anyway? :) I've heard stories that it's hard to make Milk-V Pioneer boot, but I have confidence to make it work :) I plan to buy the board when I save enough money and US dollar is not so strong. Anyway, for Pioneer, two months ago I looked at upstream linux 6.8 device tree, it seems that the support for this board is very minimal: only serial console, CPU and RAM are supported. Judging from kernel.org mailing lists and Debian's salsa, I don't think anyone is working on it. The manufacturer Milk-V in China (located in my hometown actually) doesn't seem to care about upstream support at all, like most other SBC manufacturers. But in any cas
Re: [Trisquel-devel] success on arm64 Supermicro ARS-110M-NR
Jing Luo writes: > Hi Simon and bill-auger and maybe Luis and Rubén, > > I also have good news! I just installed Trisquel on my new arm64 > server and it looks good. Yay! >> congrats - AFAIK, this is the first powerful non-x86 computer that >> is known to >> run a libre distro; so it is a significant landmark > > Talos II (2019) is also powerful too...? FSF has one I think. Yes, I have them too and I find them sufficiently powerful, and they also have libre BIOS and firmware something these arm machines lack. > Unlike Simon, I used the prebuilt Trisquel ISO: > > https://repo.jing.rocks/trisquel-iso/trisquel-netinst_11.0.1_arm64.iso That is the same image that I used: fe9626483a1b46ce2b99ac24ce047828e57d8f245083cc0bc421511aaf8e5ddd The ISO is inside the tarball I gave the link to. > formatted the rootfs as btrfs, with linux-generic-64k-hwe-11.0-edge What is the benefit of the 64k kernels? The package description doesn't really say one would just them over the other ones. Are there performance differences? Right now, I am using linux-libre 6.9.8 on my machine (thanks Jason for releasing gnu-2.0 versions in gzip format!) because of a known (mostly cosmetic) bug with the mpt3sas driver that also occurs on amd64. I didn't have any issues with the vanilla trisquel kernel before adding the LSI card to the machine. I tried the linux-libre-lts 6.6 packages and they work fine on this machine too. I'll see if I can post some benchmarks on my machine eventually, I want to setup a GitLab runner in a VM on it that I could ask to build the kernel package for me. >> So...if Luiz or Rubén is reading this, I would be happy to host a VM >> for Trisquel to speed up jenkins builds, seeing that Trisquel is >> using a ROCK 3A for the build farm. It should be 20~30 times faster. > > There are plans to improve the node stack, as Ecne will be adding > riscv and more load to arm, but that's is still on it's way. Using > community vm/nodes might require to layout some security policies, and > some other directives, we'll need to find some time to define those if > moving in that direction. I am also happy sponsor build machines here, but I understand the dilemma about riscv. Either you purchase some riscv machine and set it up yourself (I am happy to donate funding for this), but then as far as I understand the requirements, we would need to make sure it runs on only free software and no blobs. I got my Milky-V Pioneer riscv machine working via upstream's kernel image and Debian debootstrap. I have tried installing both Debian and linux-libre kernels, but I just get a blank screen when booting. I have been hoping for months that the Debian people make progress on a kernel for this hardware, but I don't know if there is any known problem or just lack of time. So we don't really know if this machine can ever boot without some non-free blob or not. The alternative is to build in people's VM, and I'm happy to setup a VM on the riscv machine I have, but then there are BOTH trust issues with the hoster and the uncertainty about freedom of the hardware. I don't know of a way to resolve this... I would be unhappy if ecne won't ship with riscv due to this. There are not that many unique packages in trisquel, it would be entirely possible to rebuild all of them on a new hardware eventually to increase trust in the packages. For arm64 I think there are many boards available on the market cheaply that would suffice, but I didn't think performance was a real problem today. /Simon signature.asc Description: PGP signature ___ Trisquel-devel mailing list [email protected] https://listas.trisquel.info/mailman/listinfo/trisquel-devel
Re: [Trisquel-devel] success on arm64 Supermicro ARS-110M-NR
Hello! En 09/07/24 05:14, Jing Luo escribió: Hi Simon and bill-auger and maybe Luis and Rubén, I also have good news! I just installed Trisquel on my new arm64 server and it looks good. I hope I can use this server to help Trisquel's development in some way. Nice! For now you can document your installation process, report and investigate issues found in it. Simon reported some small details with repo selection (mirrors) and language, if you found the same issue, maybe report that. [...] The installation was so smooth that I started to suspect something would go wrong, given my experience with Rockchip-based SBCs. But luckily, things just worked. I used the "expert install" option and formatted the rootfs as btrfs, with linux-generic-64k-hwe-11.0-edge for the kernel, and no desktop environment (don't have a mouse). Yay!, it's great to read that world's arm64 is having more Trisquel in it. Time for some numbers: Building trisquel's linux 5.15 using sbuild took about 17 minutes, with the following command: sbuild -d aramo --no-arch-all --no-run-lintian --no-run-autopkgtest --no-run-piuparts linux_5.15.0-113.123+11.0trisquel30.dsc Impressive timing :) (found a bug in trisquel's debootstrap, will suggest a fix on gitlab later.) [...] So...if Luiz or Rubén is reading this, I would be happy to host a VM for Trisquel to speed up jenkins builds, seeing that Trisquel is using a ROCK 3A for the build farm. It should be 20~30 times faster. There are plans to improve the node stack, as Ecne will be adding riscv and more load to arm, but that's is still on it's way. Using community vm/nodes might require to layout some security policies, and some other directives, we'll need to find some time to define those if moving in that direction. Regards. -- Cuanto más gente resista, más gente va a ser Libre, y más gente va a ser libre para ser Libre. Por tu propio bien, y en solidaridad a todos, elige la libertad. ¡Sé Libre! http://fsfla.org/selibre/ Luis A. Guzmán G. http://ark.switnet.org OpenPGP_0x35AD8DB3BE2C988C.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature ___ Trisquel-devel mailing list [email protected] https://listas.trisquel.info/mailman/listinfo/trisquel-devel
Re: [Trisquel-devel] success on arm64 Supermicro ARS-110M-NR
Hi Simon and bill-auger and maybe Luis and Rubén, I also have good news! I just installed Trisquel on my new arm64 server and it looks good. I hope I can use this server to help Trisquel's development in some way. On 2024-06-16 10:21, bill-auger wrote: congrats - AFAIK, this is the first powerful non-x86 computer that is known to run a libre distro; so it is a significant landmark Talos II (2019) is also powerful too...? FSF has one I think. if you would like to run an experiment, i would be interested to know ho much time it takes to compile linux on that box, or some other heavy build like firefox or blender (Please scroll down to see some test/benchmark results of linux and gcc-14.) Firefox has too many build-deps, so I didn't want to build it. I recently acquired a budget DIY system that is similar to Simon's Supermicro 1U server. The motherboard is Asrock ALTRAD8UD-1L2T. The CPU is an engineering sample of Ampere Altra Max I got from ebay, it has 128 cores and claims that it boosts to 3.0GHz (although it could only reach 2.8GHz `cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq`, so slower than Simon's). 8 sticks of common 16GB DDR4 ECC RDIMM. Unlike Simon, I used the prebuilt Trisquel ISO: https://repo.jing.rocks/trisquel-iso/trisquel-netinst_11.0.1_arm64.iso See, that's the benefit of hosting a mirror for Trisquel :) The installation was so smooth that I started to suspect something would go wrong, given my experience with Rockchip-based SBCs. But luckily, things just worked. I used the "expert install" option and formatted the rootfs as btrfs, with linux-generic-64k-hwe-11.0-edge for the kernel, and no desktop environment (don't have a mouse). Time for some numbers: Building trisquel's linux 5.15 using sbuild took about 17 minutes, with the following command: sbuild -d aramo --no-arch-all --no-run-lintian --no-run-autopkgtest --no-run-piuparts linux_5.15.0-113.123+11.0trisquel30.dsc (found a bug in trisquel's debootstrap, will suggest a fix on gitlab later.) Since the dsc also produces many unimportant deb/udeb packages, runs many debhelper programs, I also attempted to `make` using the source tarball only, to get a better result. allyesconfig failed to build from source (FTBFS), defconfig took 57 seconds. Then, to establish a base line for test/benchmark results, I downloaded linux 6.1.94 from Debian and ran `make` on my Ampere Altra and my AMD EPYC, defconfig and allyesconfig, separately: (command) make distclean && make defconfig && time make -j128 arm64 defconfig: real 1m19.278s, user 97m42.929s, sys 20m5.660s amd64 defconfig: real 0m54.487s, user 24m19.703s, sys 39m33.731s arm64 allyesconfig: real 13m3.830s, user 427m32.619s, sys 56m36.050s amd64 allyesconfig: real 11m58.768s, user 311m59.228s, sys 475m12.674s Next, gcc 14.1, which should be a more accurate comparison because linux has too different configs on different arch: (command) ../configure --enable-languages=c,c++ --enable-threads=posix --enable-default-pie --enable-default-ssp --with-system-zlib --disable-multilib then `time make -j128` as usual: arm64: real 26m5.756s, user 340m30.708s, sys 11m3.072s amd64: real 23m5.812s, user 278m49.675s, sys 26m57.191s `time make -k -j128 check`: arm64: real 16m24.069s, user 1563m3.285s, sys 375m6.749s amd64: real 14m20.548s, user 753m53.327s, sys 672m37.120s So...if Luiz or Rubén is reading this, I would be happy to host a VM for Trisquel to speed up jenkins builds, seeing that Trisquel is using a ROCK 3A for the build farm. It should be 20~30 times faster. I plan to use Proxmox (should be ported to arm64 first) or libvirtd to manage VMs, and upgrade RAM to 512GB around this September. I'm also doing more testings since I got an engineering sample CPU instead of a retail one, to see if it's stable or has any CPU bug. -- Jing Luo About me: https://jing.rocks/about/ GPG Fingerprint: 4E09 8D19 00AA 3F72 1899 2614 09B3 316E 13A1 1EFC signature.asc Description: OpenPGP digital signature ___ Trisquel-devel mailing list [email protected] https://listas.trisquel.info/mailman/listinfo/trisquel-devel
Re: [Trisquel-devel] success on arm64 Supermicro ARS-110M-NR
congrats - AFAIK, this is the first powerful non-x86 computer that is known to run a libre distro; so it is a significant landmark if you would like to run an experiment, i would be interested to know ho much time it takes to compile linux on that box, or some other heavy build like firefox or blender ___ Trisquel-devel mailing list [email protected] https://listas.trisquel.info/mailman/listinfo/trisquel-devel
