Summary: | sys-kernel/gentoo-sources-4.9.78 - /bin/sh: line 1: 23989 Segmentation fault ./tools/objtool/objtool check "fs/ext4/extents_status.o" make[2]: *** [scripts/Makefile.build:294: fs/ext4/extents_status.o] Error 139 | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Corbin <corbinbird> |
Component: | Current packages | Assignee: | Gentoo Kernel Bug Wranglers and Kernel Maintainers <kernel> |
Status: | RESOLVED OBSOLETE | ||
Severity: | normal | ||
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | AMD64 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
logs_and_info_sorted.zip
kernel 4.9.79 logs and info |
Description
Corbin
2018-01-26 02:05:52 UTC
Created attachment 517556 [details]
kernel 4.9.79 logs and info
If you use ld-gold switch back to ld-bfd But i'm sure the kind of work objtool "seems to try doing" will hit many users with reptoline or other tweak in the code itself that make objtool miserably failing. If you seek infos, you can read https://forums.gentoo.org/viewtopic-t-1075862.html which is for now, only a thread that tells you to use ld-fdb and that objtool is, well, not that stable. But i hope the thread will be update with good infos you could use for yourself, when they'll be out. I'm just an end-user but I can confirm this. Starting from 4.14.14 until 4.15.1 (today) I got a big heap of objtool errors until it eventually segfaults. Everything worked fine so far (until and incl. 4.14.13). (AMD FX machine, possibly also others, didn't try them yet) I can provide additional info if needed. I did not yet try to switch things in the kernel config. (In reply to callmewhatyoulike from comment #3) > I'm just an end-user but I can confirm this. Starting from 4.14.14 until > 4.15.1 (today) I got a big heap of objtool errors until it eventually > segfaults. Everything worked fine so far (until and incl. 4.14.13). (AMD FX > machine, possibly also others, didn't try them yet) > I can provide additional info if needed. I did not yet try to switch things > in the kernel config. Follow this link : https://forums.gentoo.org/viewtopic-t-1075862.html Its a workaround until the patches are ?correct? / ?complete?. Have you upgraded to gcc 7.3, yet? If so, do you experience this with gcc 7.3.X ? (In reply to Mike Pagano from comment #5) > Have you upgraded to gcc 7.3, yet? If so, do you experience this with gcc > 7.3.X ? Unfortunately yes. Using sys-devel/gcc-7.3.0-r3, kernel(s) 4.9.x && 4.14.x In kernels 4.9.x, killing 'metadata' got rid of the errors. [ ] Compile-time stack metadata validation In kernels 4.14.x 'retpolines' requires the use of 'metadata'. [*] Avoid speculative indirect branches in kernel -*- Compile-time stack metadata validation The only way to get the kernel to compile with 4.14.x && retpolines is to set the CPU to 'Generic x86_64'. If I remove 'retpolines && metadata', then set the CPU to AMD Piledriver, it compiles. It's been three years, is this still an issue? If so, just give me the new details to see if I can reproduce I found out leaving 'retpoline' and the updated firmware out fixed the problem. AMD Fam15h can't use the 'Indirect Branch Prediction Barrier' contained in the updated firmware. Results in a kernel hard lock every time, 5 to 15 min delay. Something in the chipset / SATA / PATA Controller is reliant on indirect branch prediction. I have changed CPU's and the kernel version since then. |