LinuxQuestions.org
Latest LQ Deal: Latest LQ Deals
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware > Slackware - Installation
User Name
Password
Slackware - Installation This forum is for the discussion of installation issues with Slackware.

Notices


Reply
  Search this Thread
Old 12-08-2019, 03:38 AM   #16
Chalapticus
LQ Newbie
 
Registered: Aug 2019
Posts: 10

Original Poster
Rep: Reputation: Disabled

@abga

I made a new compilation in the meantime, the difference to my working config is setting HIHGMEM to 64G (this effected other automatic changes). Booting with this does *not* work. I attached the config.

Now I'll try the same settings with EFI_RCI2 set to off. We'll see, maybe it's a strange iteraction between HIGHMEM and EFI_RCI2.

@gus3

Actually, for me it was the same: not a new install, but -current kernel update. But then I tested with qemu and the install usbimage, so I ended up posting here.
Attached Files
File Type: log config-5.4.2-custom-2.xz.log (42.5 KB, 3 views)

Last edited by Chalapticus; 12-08-2019 at 03:42 AM. Reason: I did not actually attached the config, so now I did.
 
Old 12-08-2019, 04:17 PM   #17
Chalapticus
LQ Newbie
 
Registered: Aug 2019
Posts: 10

Original Poster
Rep: Reputation: Disabled
Turning the EFI_RCI2 off in my previously posted non-working kernel config made the resulting kernel bootable and working. So it seems that there is really something strange going on between HIGHMEM=4G/64G and EFI_RCI2=n/y, something like EFI_RCI2 can be enabled only if HIHGMEM=4G (but only on x86 and more specifically Atom n270?).

However, I cannot state this flat out as I also played with the MTRR settings, as we discussed some posts before. In order to be sure I should compile two more times: 1) the -current 5.4.2 config modified *only* with EFI_RCI2 unset and 2) *only* modified with HIGHMEM=4G. It would take once again a lot of time and I have seen in the kernel thread that it is surely enough to unset EFI_RCI2.

How to proceed now?

1) Make a kernel bug report? I do not know these Dell EMC Servers, maybe they are 64bit only/Xeon, so even the possibility to set this should be automatically disabled in the kernel configuration tool?

2) Given that based on the kernel config documentation this setting is useful only for `Dell EMC PowerEdge systems' (what might be 64bit only), could it be suggested to the Slackware team that this option would be set to off in future 5.4.x kernels (maybe only for x86)?

3) Just get on with it and compile the kernel anew on every update? I personally would lose something, as my older HW was supported out of the box with -current and the 4.19.* kernel series.

Thanks for suggestions in advance; anybody please chip in.
 
1 members found this post helpful.
Old 12-08-2019, 06:07 PM   #18
abga
Senior Member
 
Registered: Jul 2017
Location: EU
Distribution: Slackware
Posts: 1,393

Rep: Reputation: 782Reputation: 782Reputation: 782Reputation: 782Reputation: 782Reputation: 782Reputation: 782
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 ...

Last edited by abga; 12-08-2019 at 07:30 PM. Reason: typos
 
1 members found this post helpful.
Old 12-09-2019, 05:53 PM   #19
Chalapticus
LQ Newbie
 
Registered: Aug 2019
Posts: 10

Original Poster
Rep: Reputation: Disabled
So I filed a bug report and it seems that the issue was resolved yesterday.

@abga Thanks for your support. Hopefully/probably 5.4.3 will not have the problem (after all this I also think that CONFIG_EFI_RCI2=y is not needed for i386, even if the oops won't be triggered).

Last edited by Chalapticus; 12-09-2019 at 05:55 PM. Reason: grammatical error
 
2 members found this post helpful.
Old 12-09-2019, 06:36 PM   #20
gus3
Member
 
Registered: Jun 2014
Distribution: Slackware (x86 and ARM)
Posts: 229

Rep: Reputation: Disabled
I'm glad someone was able to get a full panic log. The only way I can do that is through netconsole, and that requires re-compiling the kernel.
 
Old 12-09-2019, 08:10 PM   #21
abga
Senior Member
 
Registered: Jul 2017
Location: EU
Distribution: Slackware
Posts: 1,393

Rep: Reputation: 782Reputation: 782Reputation: 782Reputation: 782Reputation: 782Reputation: 782Reputation: 782
@Chalapticus

Thanks for reporting this issue to the kernel devs. It looks like they fixed (added some missing checks) the code and I believe it will be safe to keep CONFIG_EFI_RCI2_TABLE=y after this patch:

https://git.kernel.org/pub/scm/linux...5fac8dd79b5e70
Quote:
added support for a Dell specific UEFI configuration table, but
failed to take into account that mapping the table should not be
attempted unless the table actually exists. If it doesn't exist,
the code usually fails silently unless pr_debug() prints are
enabled. However, on 32-bit PAE x86, the splat below is produced due
to the attempt to map the placeholder value EFI_INVALID_TABLE_ADDR
which we use for non-existing UEFI configuration tables, and which
equals ULONG_MAX.
 
Old 12-11-2019, 01:30 PM   #22
abga
Senior Member
 
Registered: Jul 2017
Location: EU
Distribution: Slackware
Posts: 1,393

Rep: Reputation: 782Reputation: 782Reputation: 782Reputation: 782Reputation: 782Reputation: 782Reputation: 782
Just checked, nothing about:
https://git.kernel.org/pub/scm/linux...5fac8dd79b5e70
In the upcoming 5.4.3
http://lkml.iu.edu/hypermail/linux/k...2.1/05385.html

Meaning, "# CONFIG_EFI_RCI2_TABLE is not set" should (still) be used when compiling 5.4.3 for 32 bit systems.
 
Old 12-13-2019, 03:44 PM   #23
Chalapticus
LQ Newbie
 
Registered: Aug 2019
Posts: 10

Original Poster
Rep: Reputation: Disabled
I am writing this on my Acer Aspire One running the currently updated `kernel-generic-smp-5.4.3_smp-i686-1'

`EFI_RCI2_TABLE y -> n' made the oops go away.

Thanks everybody, marking it as solved.
 
2 members found this post helpful.
Old 12-13-2019, 07:53 PM   #24
abga
Senior Member
 
Registered: Jul 2017
Location: EU
Distribution: Slackware
Posts: 1,393

Rep: Reputation: 782Reputation: 782Reputation: 782Reputation: 782Reputation: 782Reputation: 782Reputation: 782
Can confirm this, just downloaded kernel-huge-smp-5.4.3_smp-i686-1.txz and kernel-modules-smp-5.4.3_smp-i686-1.txz, unpacked them (manually installed) and used them too boot my Atom N270 powered Acer Aspire One (Slackware 14.2 32bit).
Everything looks OK so far.

... an issue still persists, unrelated to this thread. My LAN adapter on this Acer system remains powered after a normal shut down (shutdown -h now). It started to happen with the 5.x kernels - my own 5.3.1 compilation, then the 5.4.1 & 5.4.2 test compilations (the same config as provided by Slackware, just EFI_RCI2_TABLE disabled) and now the Slackware official 5.4.3 kernel.
The default Slackware 14.2 kernel 4.4.202 shuts down the NIC properly.
I first noticed this after the first 5.3.1 boot, by checking the switch LEDs, the link for the Acer was still on. I'm usually checking the switch to make sure all the systems are down after I finish my work and leaving the room. So far, I checked the BIOS, Boot from LAN is disabled, and ethtool reports WoL disabled:
Code:
ethtool eth0 | grep Wake-on
        Supports Wake-on: pumbg
        Wake-on: d
Will maybe start a new thread on this problem if I get some time to test the 5.x kernels on another system and able to confirm it (not running any -current on x86).
 
1 members found this post helpful.
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
x86-4.4.172 Kernel and niVidia 304.137-x86 driver slakdrax Slackware 10 04-08-2019 07:51 PM
[SOLVED] Slackware 14.2 glibc-2.23 vs Slackware Current glibc-2.24 and the Current 4.4.17 Kernel kjhambrick Slackware 10 08-13-2016 02:00 AM
[kernel-headers-3.2.45-x86-3] OR [kernel-headers-3.2.45_smp-x86-3]? Sefid par Slackware 3 07-24-2013 10:59 AM
[SOLVED] VirtualBox 4 Slackware Current (x86) (No Kernel Modules) Gavin Harper Slackware 13 01-06-2011 10:56 AM
X86-64 and X86 SlipAway172 Mandriva 1 03-03-2005 06:45 AM

LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware > Slackware - Installation

All times are GMT -5. The time now is 08:21 AM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration