Hi, upstream updated their patch set to add support for silvermont low power atom processors: https://github.com/graysky2/kernel_gcc_patch/blob/master/enable_additional_cpu_optimizations_for_gcc_v4.9%2B_kernel_v3.15%2B.patch Would be nice if you could integrate this update. Thanks! Reproducible: Always
I compile the kernel 3.19.3 using LZ4 as compressor and gcc-4.9.2, I get this error when booting. early consolein decompress_kernel KASLR using RDTSC Decompressing Linux... Decoding halted $ gcc-config -l [1] x86_64-pc-linux-gnu-4.8.4 [2] x86_64-pc-linux-gnu-4.9.2 * $ eix -Ic lz4 [I] app-arch/lz4 (0_p120@11/02/15): Extremely Fast Compression algorithm I always use lza as a compressor in previous kernel versions and never had problems, I only presents the problem with 3.19.3.
Why do you think this patch is related to your problem? Which march setting are you using? Make sure you select the right value in Processor type and features | ` Processor family Are you using distcc or something? Remember, this patch was only *updated* to add a new option for silvermont processors (nothing else was changed; the patch isn't new). If it was working for you in previous kernels your problem should be caused by something else. If you think this patch is causing the problem, exclude it: 1) Create "/etc/portage/env/genpatches.conf" with content UNIPATCH_EXCLUDE="5000_enable-additional-cpu-optimizations-for-gcc 5010_enable-additional-cpu-optimizations-for-gcc" (this will exclude both patches, the one for <=GCC4.8 and >=GCC 4.9) 2) echo "sys-kernel/gentoo-sources genpatches.conf" >> /etc/portage/package.env ...to enable the previous env file for the gentoo-sources package. 3) Re-emerge gentoo-sources (emerge -a1 gentoo-sources). Check build logs to make sure that both gcc patches were excluded. 4) Recompile your kernel and re-check.
Hi, Thomas processor FX8350 make.conf MAKEOPTS="-j9" ACCEPT_KEYWORDS="~amd64" CFLAGS="-march=bdver2 -mtune=bdver2 -O2 -pipe" .config Processor type and features ---> Processor family (Generic-x86-64) ---> (X) Generic-x86-64 I've tried the steps you happened to me and the problem persists, so this patch is not the problem. I watched the corrections that have been added in 3.18.3: https://www.kernel.org/pub/linux/kernel/v3.x/ChangeLog-3.19.3 And these two seem to me the most suspicious to me: x86/asm/entry/32: Fix user_mode() misuses commit 394838c96013ba414a24ffe7a2a593a9154daadf upstream. x86/vdso: Fix the build on GCC5 commit e893286918d2cde3a94850d8f7101cd1039e0c62 upstream.
I just recompile the kernel 3.19.3 using LZO and works perfect, it seems I have to report that a patch does not get along with LZ4. $ uname -a Linux pc-user 3.19.3-gentoo #3 SMP PREEMPT Sat Mar 28 10:42:23 ART 2015 x86_64 AMD FX(tm)-8350 Eight-Core Processor AuthenticAMD GNU/Linux Thank you very much Thomas.
Hi Néstor, OK, you should fill a new bug for your issue. But don't expect much help from Gentoo kernel team. From my experience they will only guide you through how to do a bisect but you have to do that work. And if you found the bad commit, you have to contact the original author/committer. See https://wiki.gentoo.org/wiki/Kernel_git-bisect You said the last step was decompressing, there was a change in "lib/lz4/lz4_decompress.c" in 3.19.3: commit 5a2581b963c7a27e60b39edad05ffb125b51651a Author: JeHyeon Yeon <tom.yeon@windriver.com> Date: Mon Mar 16 01:03:19 2015 +0000 LZ4 : fix the data abort issue But when 3.19.2 was working for you, a bisect will show you the bad commit very soon.
4.0 release. Closing and thanks.