Bug 1074918 - Boot fails after update to Linux kernel 4.14.11
Boot fails after update to Linux kernel 4.14.11
Status: RESOLVED DUPLICATE of bug 1074869
Classification: openSUSE
Product: openSUSE Tumbleweed
Classification: openSUSE
Component: Kernel
Current
x86-64 SUSE Other
: P5 - None : Major (vote)
: ---
Assigned To: E-mail List
E-mail List
:
Depends on:
Blocks: 1075183
  Show dependency treegraph
 
Reported: 2018-01-07 19:32 UTC by Luis Correia
Modified: 2018-01-09 17:04 UTC (History)
3 users (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---
jslaby: needinfo? (luismiguel427)


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Luis Correia 2018-01-07 19:32:11 UTC
After updating tumbleweed from kernel 4.14.9 to 4.14.11, the system stops booting. It gets stuck during the boot splash and after a minute or so, the system resets.

Booting with 4.14.9 still works.

Starting 4.14.11 with the "nopti" option works and the system boots normally, so I assume it is due to the KPTI patches.

Hardware specs:

CPU: AMD FX-8320 8 Core
RAM: 16GB/ECC
GPU: Two AMD R9 290X's
M/B: Gigabyte 990FXA-UD7 (UEFI)
PCIe Cards: Creative X-Fi & HP P400 (SAS RAID)

The boot drive is an SSD with BTRFS and the system has several other HDD's connected (EXT4, BTRFS & NTFS), along with a HP LTO tape drive and a second SSD with Windows 10.
Comment 1 Jiri Slaby 2018-01-09 13:11:47 UTC
Similar symptoms are reproted when a 32bit binary is run on AMD processors.

So:
1) could you check 4.14.12 from Kernel:stable?
2) try to boot into text mode and see if you can capture the crash?
Comment 2 Jiri Slaby 2018-01-09 13:42:54 UTC
.

*** This bug has been marked as a duplicate of bug 1074869 ***
Comment 3 Luis Correia 2018-01-09 13:54:12 UTC
Although also related to KPTI, I'm not sure if the bug is the same as bug 1074869. As far as I know, no 32 bit binaries are loaded at startup (it is a fairly recent installation).
I will have access to the system at the end of the day and will provide boot logs / 4.14.12 results.
Comment 4 Jiri Slaby 2018-01-09 13:58:19 UTC
Sure, if it turns out to be a different issue, feel free to reopen this one.
Comment 5 Luis Correia 2018-01-09 17:04:50 UTC
After comparing a successful boot output with a failed one, it seems this bug is indeed a duplicate. The system had TeamViewer installed and it was hanging right before the TV module started. I believe TeamViewer runs in Wine, so it was probably trying to load wine which would crash the system. Removing TeamViewer solved the issue.