Summary: | genkernel generated (supplied) Linux kernel configuration settings for x86 targets i686 even if CHOST specifies i486 | ||
---|---|---|---|
Product: | Gentoo Hosted Projects | Reporter: | Kevin Brace <kevinbrace> |
Component: | genkernel | Assignee: | Gentoo Genkernel Maintainers <genkernel> |
Status: | RESOLVED WONTFIX | ||
Severity: | normal | CC: | sam |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | x86 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Kevin Brace
2021-09-10 02:09:02 UTC
(In reply to Kevin Brace from comment #0) > As a result of this, I am now forced to recompile the Linux kernel, and I > expect this to take another 2 weeks or so. I would consider e.g. borrowing Debian or some other distro's binary kernel to get booted initially. (Or of course, cross-compiling, but I understand that it's kind of against the "point" of some projects like this. I'm going to do it soon too!) I'll leave others to comment on the genkernel-specific issue, but you are free to compile your own kernel if you wish too. I am currently compiling Linux 5.10.61 off of minimal LiveCD environment. I am simultaneously compiling LLVM 12.0.1 along with the Linux kernel, so the compiling is taking time. I expect it to take another week and half. After running the computer (233 MHz Intel Pentium MMX with 768 MB of RAM) 1 week or so straight, LLVM is about 1/3 done. Linux kernel is probably about 40% done. I can now interrupt and restart Linux kernel build since I am doing it manually (i.e., did not go through "genkernel all" this time around), but I sure hope the power will not go off (we are already in the wildfire season) since portage is compiling LLVM simultaneously, and if the power goes off, I will need to restart LLVM compilation. (In reply to Sam James from comment #1) > (In reply to Kevin Brace from comment #0) > > As a result of this, I am now forced to recompile the Linux kernel, and I > > expect this to take another 2 weeks or so. > > I would consider e.g. borrowing Debian or some other distro's binary kernel > to get booted initially. > > (Or of course, cross-compiling, but I understand that it's kind of against > the "point" of some projects like this. I'm going to do it soon too!) > > I'll leave others to comment on the genkernel-specific issue, but you are > free to compile your own kernel if you wish too. I can confirm that the boot time crash I experienced was due to CMOV instructions being generated by GCC. The default Linux kernel compilation settings supplied by genkernel activates generation of CMOV instructions (i.e., assumes Pentium Pro to be the target environment). I recompiled the Linux kernel with i486SX (a 486 without an FPU) as the target environment, and the computer (Intel Pentium with MMX 233 MHz) can now properly boot Gentoo Linux. That being said, please fix this bug (shortcoming) or give proper warnings to the user. Kernel option CONFIG_X86_CMOV depends on selected processor. Our default x86 config has set CONFIG_M686 which will enable CMOV support. There is no way to just unset CONFIG_X86_CMOV. If we want to disable CONFIG_X86_CMOV support, we have to select a different processor which will disable CONFIG_X86_CMOV depending on what you selected. But how should we do that? We can only know `uname -m` value (which is not available when cross-compiling) and we have the CHOST value. But if CHOST says i486-*, what should we select? There is 486SX and 486DX -- if we disable FPU when you have a working one, you wouldn't be happy. Maybe CONFIG_M586 would be the better choice? Still bad when you have crippled 486SX, not? And keep in mind, we can't even be sure that i686 is a strong indicator for CMOV support -- what about VIA processors? tl;dr I don't see a way to solve that. Better keep status quo and expect that users of such old processors know what they are doing and will check kernel config and select proper processor on their own. I am closing this bug as WONTFIX. If you have better idea and come up with an implementation taking care of all mentioned problems, feel free to share. We are still reading closed bugs. |