Bug 1074869

(In reply to kolA flash from comment #0)
> CPU: AMD Phenom(tm) II X4 955 Processor

This CPU should have page table isolation disabled as AMD should be safe, if that patch went into stable 4.14 already. Please grep for "pti" or "kaiser" in /proc/cpuinfo to verify neither is there.

Hm actually it seems from looking at source that pti will be there. Try booting with "nopti" kernel parameter, verify that pti is gone, and try wine again.

I recall from LWN comments wine was doing something with ldt that required some handling wrt PTI, maybe a patch is missing from stable...

I can reproduce the problem reported on my a rather old AMD machine (8 year old Toshiba Netbook) with:

lscpu 
Architektur:           x86_64
CPU Operationsmodus:   32-bit, 64-bit
Byte-Reihenfolge:      Little Endian
CPU(s):                2
Liste der Online-CPU(s):0,1
Thread(s) pro Kern:    1
Kern(e) pro Socket:    2
Sockel:                1
NUMA-Knoten:           1
Anbieterkennung:       AuthenticAMD
Prozessorfamilie:      20
Modell:                1
Modellname:            AMD C-50 Processor
Stepping:              0
CPU MHz:               800.000
Maximale Taktfrequenz der CPU:1000,0000
Minimale Taktfrequenz der CPU:800,0000
BogoMIPS:              1994.96
Virtualisierung:       AMD-V
L1d Cache:             32K
L1i Cache:             32K
L2 Cache:              512K
NUMA-Knoten0 CPU(s):   0,1
Markierungen:          fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_good nopl nonstop_tsc cpuid extd_apicid aperfmperf pni monitor ssse3 cx16 popcnt lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch ibs skinit wdt hw_pstate pti vmmcall arat npt lbrv svm_lock nrip_save pausefilter

While my two other (Intel) machines don't show this behaviour, on the AMD machine the kernel crashes when executing _any_ 32-Bit application. I tried different types of 32-bit applications, statically linked against glibc, musl-libc or dietlibc and also dynamically linked against glibc and all of them crash the kernel immediately.

Booting with "nopti" successfully works around this issue.

AK

So apparently this is known problem that will be fixed in 4.14.12. Which will also have the patch to automatically disable PTI on AMD processors. For now please use the "nopti" parameter.

(In reply to Vlastimil Babka from comment #3)
> So apparently this is known problem that will be fixed in 4.14.12. 

For the record (and other people reading this thread), this seems to be the commit you are referring to:

https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/commit/?h=linux-4.14.y&id=151d7039757b71ebd9d170af0944562f51149372

AK

So does 4.14.12 work? Kernel stable has it already:
https://build.opensuse.org/project/monitor?project=Kernel%3Astable

(In reply to Jiri Slaby from comment #5)
> So does 4.14.12 work? Kernel stable has it already:
> https://build.opensuse.org/project/monitor?project=Kernel%3Astable

Unfortunately, no.

I Installed 4.14.12-2.1 from Kernel:stable

Linux 4.14.12-2.g7637ae2-default #1 SMP PREEMPT Sat Jan 6 09:10:30 UTC 2018 (7637ae2) x86_64 x86_64 x86_64 GNU/Linux

I tried executing some 32-Bit applications one after the other (Disclaimer: I have a nice little collection of small 32-Bit applications, most of them statically linked on my custom "Rescue-USB stick even useful for old systems", so I have some choice to test) and at first, the problem seemed to be fixed.

But after a while, the system crashed and in order to reproduce the problem, I rebooted the system and tried the same executable which crashed the system before. To my surprise, this time the system kept running.

Now I tried calling that application in a loop (while true; do ; done) and the system crashed after a few repetitions.

Same goes for other 32-bit applications I tried, after a few repetitions in a loop the system crashes reproducibly. (It also seems the "bigger" the application is and the more output is produced, the lesser loops are needed to crash the system, though not really in a predictable manner.)

In addition, booting the kernel with the "nopti" parameter does no longer have any effect as in 4.14.11.

AK

I see something very same when building virtualbox in obs with kernel 4.14.11 running as the base:

https://build.opensuse.org/package/live_build_log/openSUSE:Factory:Staging:D:DVD/virtualbox/standard/x86_64

In openQQ, about 1% of the runs had a fail in glibc-sanity, which does nothing but run /lib/glibc.so.6 (this special lib allows that)

Created attachment 755068 [details]
running StarCraft-2 in Wine on 4.14.12 with nopti

Test results:

4.14.7 (no errors with this)
- /proc/cpuinfo doesn't have "pti"

4.14.11
- /proc/cpuinfo has "pti"
- Boot with "nopti" option and "wine --version" and even more complex Windows applications like the "Blizzard App" or "StarCraft 2" run fine in Wine.

4.14.12
- /proc/cpuinfo doesn't have "pti"
- Boot with or without "nopti" makes no difference
- "wine --version" runs fine
- More complex Windows applications like the "Blizzard App" or "StarCraft 2" crash Wine. (see attached screenshot)

The double fault on 4.4.12 might be not specific to WINE.  We see lots of 32bit build package breakage now (bsc#1075018).

*** Bug 1074918 has been marked as a duplicate of this bug. ***

*** Bug 1074920 has been marked as a duplicate of this bug. ***

*** Bug 1074921 has been marked as a duplicate of this bug. ***

*** Bug 1075018 has been marked as a duplicate of this bug. ***

*** Bug 1075034 has been marked as a duplicate of this bug. ***

Could anyone test this?
  https://build.opensuse.org/project/monitor?project=home%3Ajirislaby%3Astable-bnc1075183

---
Linux version 4.14.12-2.gf4b3cf0-default (geeko@buildhost) (gcc version 7.2.1 20171020 [gcc-7-branch revision 253932] (SUSE Linux)) #1 SMP PREEMPT Tue Jan 9 13:48:04 UTC 2018 (f4b3cf0)
---

works for me, fixes bug 1074921

(In reply to Jiri Slaby from comment #15)
> Could anyone test this?
>  
> https://build.opensuse.org/project/monitor?project=home%3Ajirislaby%3Astable-
> bnc1075183

Works for me, tested with several 32-bit applications running in a loop for several minutes, no more crashes. However, some additional testing with a "big" application like wine might be a good idea.

Linux 4.14.12-2.gf4b3cf0-default #1 SMP PREEMPT Tue Jan 9 13:48:04 UTC 2018 (f4b3cf0) x86_64 x86_64 x86_64 GNU/Linux

AK

(In reply to Jiri Slaby from comment #15)
> Could anyone test this?
>  
> https://build.opensuse.org/project/monitor?project=home%3Ajirislaby%3Astable-
> bnc1075183

I submitted the fix to Kernel:stable and removed this project. Use the former (after it builds) if you still want to test.

Also I submitted it to factory.

If someone still sees some issues with the fixed kernel, please reopen your respective bug.

(In reply to Jiri Slaby from comment #18)
> Also I submitted it to factory.
KDE still crashes with latest version from factory: 4.14.12-1.4 - Bug 1075034.

Factory has not received the kernel yet -- see:
https://build.opensuse.org/request/show/563126

Or monitor changelog and check whether it mentions these bugs.

*** Bug 1075034 has been marked as a duplicate of this bug. ***

(In reply to Jiri Slaby from comment #18)
> (In reply to Jiri Slaby from comment #15)
> > Could anyone test this?
> >  
> > https://build.opensuse.org/project/monitor?project=home%3Ajirislaby%3Astable-
> > bnc1075183
> 
> I submitted the fix to Kernel:stable and removed this project. Use the
> former (after it builds) if you still want to test.
> 
> Also I submitted it to factory.
> 
> If someone still sees some issues with the fixed kernel, please reopen your
> respective bug.

Just installed 4.14.13-1.1.gbd444a0 from
  https://download.opensuse.org/repositories/Kernel:/stable/standard/
and it looks like everything is back to normal. StarCraft 2 is running fine again on Wine!

(In reply to kolA flash from comment #22)
> Just installed 4.14.13-1.1.gbd444a0 from and it looks like everything is back to normal.
Good, waiting for 4.14.13 in factory.

KDE still crashes with latest kernel 4.14.12-1.8 from factory. When good kernel be available?

the 4.14.13 kernel will be in the next tumbleweed snapshot and I also submitted it for :Update

.

Will this fix also work for GOG games that are installed locally?