Bug 1074918

Summary:	Boot fails after update to Linux kernel 4.14.11
Product:	[openSUSE] openSUSE Tumbleweed	Reporter:	Luis Correia <luismiguel427>
Component:	Kernel	Assignee:	E-mail List <kernel-maintainers>
Status:	RESOLVED DUPLICATE	QA Contact:	E-mail List <qa-bugs>
Severity:	Major
Priority:	P5 - None	CC:	jslaby, luismiguel427, tiwai
Version:	Current	Flags:	jslaby: needinfo? (luismiguel427)
Target Milestone:	---
Hardware:	x86-64
OS:	SUSE Other
Whiteboard:
Found By:	---	Services Priority:
Business Priority:		Blocker:	---
Marketing QA Status:	---	IT Deployment:	---
Bug Depends on:
Bug Blocks:	1075183

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.