You are not logged in.
Pages: 1
since the mitigation for SPECTRE was released...kernel 4.15 I believe....at boot I get an error
stating "LFENCE not serializing-switching to generic retpoline".....now my monitor resolution
is limited to 1024x768 instead of 1990x1080 like it was, and should be, before the upgrade...
tried using xrandr to generate a new mode of 1990x1080 but got error saying it could not read
the gamma of monitor....using xrandr to force gamma didn't work either...it seems to accept the
new values, but reports back that gamma is 0 .....stuck in an endless loop....
my research led me to this article with information on AMD & LFENCE...i have copied some pertinent
sections here...
"lfence is another instruction that doesn't really have anything to do with speculative execution.
In principle, it is used to ensure that the processor has finished all outstanding attempts to load
data from memory before it starts any new load attempts. The exact value of this instruction in
x86 isn't entirely clear (x86 already has strict rules about the order in which it attempts to perform
loads from memory), but with the discovery of Spectre, lfence has taken on a new role: it, too, is
a speculation block."
"AMD has adopted Intel's convention; going forward, lfence will always be a serializing instruction
that blocks speculative execution. For existing processors, AMD says that an MSR
(a "model specific register," a special vendor and model-specific processor register that can be used
to apply low-level configuration) can be used to change non-serializing lfence into serializing lfence.
Only operating systems (and virtualization hypervisors) are able to change MSRs, so operating system
updates will be needed to ensure that this is enabled."
I then found that a patch had been generated on this page https://www.systutorials.com/linux-kernels/
55670/x86-cpu-amd-make-lfence-a-serializing-instruction-linux-4-9-77/
he states this will be done in the release of Linux 4.9.77
my question is: any idea of when this might be coming...or should I just install the patch now ???
Last edited by NM5TF (2018-03-28 02:37:27)
Registered Linux User # 529389
Arch Linux, MX 18.3, Linux
my improved web page http://users.gilanet.com/~tfrost
Offline
Why the interest in linux 4.9.77 ? In the repos we have only 4.14.27 and 4.15.9.
R00KIE
Tm90aGluZyB0byBzZWUgaGVyZSwgbW92ZSBhbG9uZy4K
Offline
I understand that....
my reasoning was....if it will be "fixed" in kernel 4.9.77, then I could wait until then
rather than installing the patch....
I have also tried to downgrade to before kernel 4.15 but get tons of errors stating
if you downgrade pkg xxx.xx it will break pkg yyy.yy
so from your "answer" it would seem that I need to install the patch...or get rid of
this perfectly capable machine and get something newer....
Registered Linux User # 529389
Arch Linux, MX 18.3, Linux
my improved web page http://users.gilanet.com/~tfrost
Offline
my reasoning was....if it will be "fixed" in kernel 4.9.77, then I could wait until then
rather than installing the patch....
4.9.77 is older than 4.14.27 and 4.15.10
https://git.kernel.org/pub/scm/linux/ke … 637f1867ec the commit you are interested in
https://git.kernel.org/pub/scm/linux/ke … 15.10#n831 it is already present
https://git.kernel.org/pub/scm/linux/ke … 15.10#n262 the code generating the message you are interested in
If you boot with spectre_v2=off to disable spectre v2 mitigation does that affect the screen resolution? As I believe you are incorrect in your conclusion that the issues are related.
Offline
Your answer leaves me even more puzzled, what makes you think that using lfence as a serializing instruction as not been added to more recent kernels?
Why would kernel 4.14.27 or 4.15.9 not support your machine? What makes you think the result with that patch you mention will not result in the same error? Or worse, not have all the checks as fallbacks and fail silently?
From what I can see that error message is shown because the cpu in your machine is _missing_ some instruction, a patch for an older kernel is not magically going to make it work.
From arch/x86/kernel/cpu/bugs.c
retpoline_auto:
if (boot_cpu_data.x86_vendor == X86_VENDOR_AMD) {
retpoline_amd:
if (!boot_cpu_has(X86_FEATURE_LFENCE_RDTSC)) {
pr_err("Spectre mitigation: LFENCE not serializing, switching to generic retpoline\n");
goto retpoline_generic;
}
Edit:
The error about LFENCE is a red herring, it almost certainly has nothing to do with your resolution problem, instead you should be looking into changes in the kernel drivers for the gpu.
Last edited by R00KIE (2018-03-17 16:58:16)
R00KIE
Tm90aGluZyB0byBzZWUgaGVyZSwgbW92ZSBhbG9uZy4K
Offline
git checkout linux-4.14.y
git log --grep=e4d0e84e490790798691aaa0f2e598637f1867ec
commit 649c1de819afc90cb6699dc04f5340009dd3783c
Author: Tom Lendacky <thomas.lendacky@amd.com>
Date: Mon Jan 8 16:09:21 2018 -0600
x86/cpu/AMD: Make LFENCE a serializing instruction
commit e4d0e84e490790798691aaa0f2e598637f1867ec upstream.
....
git tag --contains 649c1de819afc90cb6699dc04f5340009dd3783c
v4.14.14
v4.14.15
v4.14.16
v4.14.17
v4.14.18
v4.14.19
v4.14.20
v4.14.21
v4.14.22
v4.14.23
v4.14.24
v4.14.25
v4.14.26
v4.14.27
git checkout linux-4.15.y
git tag --contains e4d0e84e490790798691aaa0f2e598637f1867ec
v4.15
v4.15-rc8
v4.15-rc9
v4.15.1
v4.15.10
v4.15.2
v4.15.3
v4.15.4
v4.15.5
v4.15.6
v4.15.7
v4.15.8
v4.15.9
v4.16-rc1
v4.16-rc2
v4.16-rc3
v4.16-rc4
v4.16-rc5
So the commit has been in 4.14 since v4.14.14 and every release of 4.15
Offline
@ loqs....so the commit has been in place since v4.14.14 & every release of 4.15 yet I am still getting an error....
@ rookie....I agree the resolution problem is not connected to the LFENCE error....am looking into Xorg errors
probably should close or delete this post and open new post about resolution problem...it also is affecting
my Fedora distro....
Registered Linux User # 529389
Arch Linux, MX 18.3, Linux
my improved web page http://users.gilanet.com/~tfrost
Offline
@ loqs....so the commit has been in place since v4.14.14 & every release of 4.15 yet I am still getting an error....
if (cpu_has(c, X86_FEATURE_XMM2)) {
+ /*
+ * A serializing LFENCE has less overhead than MFENCE, so
+ * use it for execution serialization. On families which
+ * don't have that MSR, LFENCE is already serializing.
+ * msr_set_bit() uses the safe accessors, too, even if the MSR
+ * is not present.
+ */
+ msr_set_bit(MSR_F10H_DECFG,
+ MSR_F10H_DECFG_LFENCE_SERIALIZE_BIT);
+
/* MFENCE stops RDTSC speculation */
set_cpu_cap(c, X86_FEATURE_MFENCE_RDTSC);
If cpu has feature X86_FEATURE_XMM2 then set an msr bit and set_cpu_cap X86_FEATURE_MFENCE_RDTSC.
Look at the code producing the error that I linked to and rookie posted it checks for X86_FEATURE_LFENCE_RDTSC not X86_FEATURE_MFENCE_RDTSC.
Offline
@NM5TF
If you have one kernel that works and another that doesn't while keeping everything else the same I'd still say the problem is in the kernel driver and not Xorg.
Your best bet to find which commit broke things for you is to bisect the kernel, however this will require some time and effort, but as the saying goes no pain no gain.
R00KIE
Tm90aGluZyB0byBzZWUgaGVyZSwgbW92ZSBhbG9uZy4K
Offline
marking it solved....
the changes to new version of Xorg are not supported by my legacy nvidia driver it seems
changing to nouveau driver, which supports the older nvidia cards, fixed the resolution
problem....
LFENCE not serializing was a true "red herring" that sent me off down a wrong path
chasing a non-related problem
Registered Linux User # 529389
Arch Linux, MX 18.3, Linux
my improved web page http://users.gilanet.com/~tfrost
Offline
Pages: 1