Moved to the actual 5.4.2 on the Acer Aspire One, kernel-huge-smp-5.4.2_smp-i686-1.txz & kernel-modules-smp-5.4.2_smp-i686-1.txz, and experienced the same crash due to efi_rci2.
Recompiled only the kernel with the original config-huge-smp-5.4.2-smp and the only modification:
Code:
CONFIG_EFI_RCI2_TABLE=y
substituted with:
Code:
# CONFIG_EFI_RCI2_TABLE is not set
And the kernel booted properly. I didn't compile the modules and again I had no keyboard, vpn, firewall messed up, etc. (my paranoia(firewall+vpn)&laziness(disable them) is to blame), thus, no "raw" dmesg available, but only the /var/log/messages entries:
https://pastebin.com/iPT6K9wq
@Chalapticus
My approach was to only manually (editing the .config) modify an option for every try/build. Then, as mentioned before, due to the stage in which this crash occurs (pretty much at the beginning of the boot process) I didn't bother recompiling the modules. Rebuilding only the kernel takes around 2 hours natively on the Acer Aspire One (Atom N270) and this was my procedure:
Code:
# enter the kernel source dir & clean the previous crap
cd /test/linux-5.4.2/
make mrproper
# then prepare the kernel with the default config
make defconfig
# remove (store for comparison) the generated .config
rm .config
# copy over the Slackware provided kernel config (stock, unmodified)
cp /test/config-huge-smp-5.4.2-smp /test/linux-5.4.2/.config
# edit the .config and modify the particular option
# build the kernel - ~2 hours on the Atom N270
make -j 2 bzImage
# once done, copy the generated bzImage (and System.map if you need it) into /boot, add a lilo entry for it and update lilo
cp arch/x86/boot/bzImage /boot/TEST-vmlinuz-huge-smp-5.4.2-smp
# restart & choose the test kernel
On your points:
1) I was also considering that those DELL Servers must be 64 bit and as presented in my post #6, there is apparently no differentiation between 32bit & 64bit in the kernel config for the EFI_RCI2_TABLE option:
https://lore.kernel.org/linux-efi/20...el@linaro.org/
If this EFI_RCI2_TABLE should be enabled or not in the Slackware kernel, it is up to the Slackware Team, my suggestion was to disable it, at least for the 32 bit kernel. But then a distribution kernel should contain support for all the available hardware (that's why it compiles that huge amount of modules), unlike my "user" approach to respect all the options that the "make default" target is configuring and only add/remove what I consider appropriate.
Related to the bug report, it'll be useful if you're willing to register @ kernel.org and report it. My POV, after inspecting the rci2-table source code, is that this driver is not doing a proper job reserving the memory it needs for the "RCI2 Table" or memremap is doing it wrong (I believe I found the answer to my previous question, "who's calling memremap?" - it's in the rci2-table.c).
Look at those conditional statements, none of those success/error messages are shown in the kernel boot log, but only the crash:
https://github.com/torvalds/linux/bl...i/rci2-table.c
2) Answered above
3) Well, that won't be the case, I'm sure the Slackware Team will find a solution to not force the users to recompile the kernels on every update ...
