All of lore.kernel.org
 help / color / mirror / Atom feed
* Current mainline git (24e700e291d52bd2) hangs when building e.g. perf
@ 2017-09-05  7:27 Markus Trippelsdorf
  2017-09-05  8:53 ` Peter Zijlstra
  0 siblings, 1 reply; 61+ messages in thread
From: Markus Trippelsdorf @ 2017-09-05  7:27 UTC (permalink / raw)
  To: linux-kernel; +Cc: Thomas Gleixner, Ingo Molnar, Peter Zijlstra

Current mainline git (24e700e291d52bd2) hangs when building software
concurrently (for example perf).
The issue is not 100% reproducible (sometimes building perf succeeds),
so bisecting will not work.
Magic SysRq key doesn't work and there is nothing in the logs.
Enabling CONFIG_PROVE_LOCKING makes the issue go away.

Any ideas on how to debug this further?

-- 
Markus

^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: Current mainline git (24e700e291d52bd2) hangs when building e.g. perf
  2017-09-05  7:27 Current mainline git (24e700e291d52bd2) hangs when building e.g. perf Markus Trippelsdorf
@ 2017-09-05  8:53 ` Peter Zijlstra
  2017-09-05  9:55   ` Markus Trippelsdorf
  0 siblings, 1 reply; 61+ messages in thread
From: Peter Zijlstra @ 2017-09-05  8:53 UTC (permalink / raw)
  To: Markus Trippelsdorf; +Cc: linux-kernel, Thomas Gleixner, Ingo Molnar

On Tue, Sep 05, 2017 at 09:27:38AM +0200, Markus Trippelsdorf wrote:
> Current mainline git (24e700e291d52bd2) hangs when building software
> concurrently (for example perf).
> The issue is not 100% reproducible (sometimes building perf succeeds),
> so bisecting will not work.

Sadly I cannot reproduce, I had:

  while :; do make clean; make; done

running on tools/perf for a while, and now have:

  while :; do make O=defconfig-build clean; make O=defconfig-build -j80; done

running, all smooth sailing, although there's the hope that the moment I
hit send on this email the box comes unstuck.

> Magic SysRq key doesn't work and there is nothing in the logs.
> Enabling CONFIG_PROVE_LOCKING makes the issue go away.

SysRq not working is suspicious.. and I take it the NMI watchdog also
isn't firing?

> Any ideas on how to debug this further?

So you have a (real) serial line on that box?

Could you try something like:

  debug ignore_loglevel sysrq_always_enabled earlyprintk=serial,ttyS0,115200 force_early_printk

with the below patch applied? That always gives me the most reliable
output.

---
 kernel/printk/printk.c | 119 +++++++++++++++++++++++++++++++++++--------------
 1 file changed, 86 insertions(+), 33 deletions(-)

diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
index fc47863f629c..b17099fbc7ce 100644
--- a/kernel/printk/printk.c
+++ b/kernel/printk/printk.c
@@ -365,6 +365,75 @@ __packed __aligned(4)
 #endif
 ;
 
+#ifdef CONFIG_EARLY_PRINTK
+struct console *early_console;
+
+static bool __read_mostly force_early_printk;
+
+static int __init force_early_printk_setup(char *str)
+{
+	force_early_printk = true;
+	return 0;
+}
+early_param("force_early_printk", force_early_printk_setup);
+
+static int early_printk_cpu = -1;
+
+static int early_vprintk(const char *fmt, va_list args)
+{
+	int n, cpu, old;
+	char buf[512];
+
+	cpu = get_cpu();
+	/*
+	 * Test-and-Set inter-cpu spinlock with recursion.
+	 */
+	for (;;) {
+		/*
+		 * c-cas to avoid the exclusive bouncing on spin.
+		 * Depends on the memory barrier implied by cmpxchg
+		 * for ACQUIRE semantics.
+		 */
+		old = READ_ONCE(early_printk_cpu);
+		if (old == -1) {
+			old = cmpxchg(&early_printk_cpu, -1, cpu);
+			if (old == -1)
+				break;
+		}
+		/*
+		 * Allow recursion for interrupts and the like.
+		 */
+		if (old == cpu)
+			break;
+
+		cpu_relax();
+	}
+
+	n = vscnprintf(buf, sizeof(buf), fmt, args);
+	early_console->write(early_console, buf, n);
+
+	/*
+	 * Unlock -- in case @old == @cpu, this is a no-op.
+	 */
+	smp_store_release(&early_printk_cpu, old);
+	put_cpu();
+
+	return n;
+}
+
+asmlinkage __visible void early_printk(const char *fmt, ...)
+{
+	va_list ap;
+
+	if (!early_console)
+		return;
+
+	va_start(ap, fmt);
+	early_vprintk(fmt, ap);
+	va_end(ap);
+}
+#endif
+
 /*
  * The logbuf_lock protects kmsg buffer, indices, counters.  This can be taken
  * within the scheduler's rq lock. It must be released before calling
@@ -1704,6 +1773,16 @@ asmlinkage int vprintk_emit(int facility, int level,
 	int printed_len = 0;
 	bool in_sched = false;
 
+#ifdef CONFIG_KGDB_KDB
+	if (unlikely(kdb_trap_printk && kdb_printf_cpu < 0))
+		return vkdb_printf(KDB_MSGSRC_PRINTK, fmt, args);
+#endif
+
+#ifdef CONFIG_EARLY_PRINTK
+	if (force_early_printk && early_console)
+		return early_vprintk(fmt, args);
+#endif
+
 	if (level == LOGLEVEL_SCHED) {
 		level = LOGLEVEL_DEFAULT;
 		in_sched = true;
@@ -1796,18 +1875,7 @@ EXPORT_SYMBOL(printk_emit);
 
 int vprintk_default(const char *fmt, va_list args)
 {
-	int r;
-
-#ifdef CONFIG_KGDB_KDB
-	/* Allow to pass printk() to kdb but avoid a recursion. */
-	if (unlikely(kdb_trap_printk && kdb_printf_cpu < 0)) {
-		r = vkdb_printf(KDB_MSGSRC_PRINTK, fmt, args);
-		return r;
-	}
-#endif
-	r = vprintk_emit(0, LOGLEVEL_DEFAULT, NULL, 0, fmt, args);
-
-	return r;
+	return vprintk_emit(0, LOGLEVEL_DEFAULT, NULL, 0, fmt, args);
 }
 EXPORT_SYMBOL_GPL(vprintk_default);
 
@@ -1838,7 +1906,12 @@ asmlinkage __visible int printk(const char *fmt, ...)
 	int r;
 
 	va_start(args, fmt);
-	r = vprintk_func(fmt, args);
+#ifdef CONFIG_EARLY_PRINTK
+	if (force_early_printk && early_console)
+		r = vprintk_default(fmt, args);
+	else
+#endif
+		r = vprintk_func(fmt, args);
 	va_end(args);
 
 	return r;
@@ -1875,26 +1948,6 @@ static bool suppress_message_printing(int level) { return false; }
 
 #endif /* CONFIG_PRINTK */
 
-#ifdef CONFIG_EARLY_PRINTK
-struct console *early_console;
-
-asmlinkage __visible void early_printk(const char *fmt, ...)
-{
-	va_list ap;
-	char buf[512];
-	int n;
-
-	if (!early_console)
-		return;
-
-	va_start(ap, fmt);
-	n = vscnprintf(buf, sizeof(buf), fmt, ap);
-	va_end(ap);
-
-	early_console->write(early_console, buf, n);
-}
-#endif
-
 static int __add_preferred_console(char *name, int idx, char *options,
 				   char *brl_options)
 {

^ permalink raw reply related	[flat|nested] 61+ messages in thread

* Re: Current mainline git (24e700e291d52bd2) hangs when building e.g. perf
  2017-09-05  8:53 ` Peter Zijlstra
@ 2017-09-05  9:55   ` Markus Trippelsdorf
  2017-09-06 12:52     ` Thomas Gleixner
  0 siblings, 1 reply; 61+ messages in thread
From: Markus Trippelsdorf @ 2017-09-05  9:55 UTC (permalink / raw)
  To: Peter Zijlstra; +Cc: linux-kernel, Thomas Gleixner, Ingo Molnar

On 2017.09.05 at 10:53 +0200, Peter Zijlstra wrote:
> On Tue, Sep 05, 2017 at 09:27:38AM +0200, Markus Trippelsdorf wrote:
> > Current mainline git (24e700e291d52bd2) hangs when building software
> > concurrently (for example perf).
> > The issue is not 100% reproducible (sometimes building perf succeeds),
> > so bisecting will not work.
> 
> Sadly I cannot reproduce, I had:
> 
>   while :; do make clean; make; done
> 
> running on tools/perf for a while, and now have:
> 
>   while :; do make O=defconfig-build clean; make O=defconfig-build -j80; done
> 
> running, all smooth sailing, although there's the hope that the moment I
> hit send on this email the box comes unstuck.
> 
> > Magic SysRq key doesn't work and there is nothing in the logs.
> > Enabling CONFIG_PROVE_LOCKING makes the issue go away.
> 
> SysRq not working is suspicious.. and I take it the NMI watchdog also
> isn't firing?

Yes.

> > Any ideas on how to debug this further?
> 
> So you have a (real) serial line on that box?

Sadly, no. But hopefully somebody else (with a proper kernel debugging
setup) will reproduce the issue soon.

-- 
Markus

^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: Current mainline git (24e700e291d52bd2) hangs when building e.g. perf
  2017-09-05  9:55   ` Markus Trippelsdorf
@ 2017-09-06 12:52     ` Thomas Gleixner
  2017-09-06 13:15       ` Markus Trippelsdorf
  0 siblings, 1 reply; 61+ messages in thread
From: Thomas Gleixner @ 2017-09-06 12:52 UTC (permalink / raw)
  To: Markus Trippelsdorf; +Cc: Peter Zijlstra, linux-kernel, Ingo Molnar

On Tue, 5 Sep 2017, Markus Trippelsdorf wrote:
> On 2017.09.05 at 10:53 +0200, Peter Zijlstra wrote:
> > > Any ideas on how to debug this further?
> > 
> > So you have a (real) serial line on that box?
> 
> Sadly, no. But hopefully somebody else (with a proper kernel debugging
> setup) will reproduce the issue soon.

Does the machine respond to ping or is it entirely dead?

Thanks,

	tglx

^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: Current mainline git (24e700e291d52bd2) hangs when building e.g. perf
  2017-09-06 12:52     ` Thomas Gleixner
@ 2017-09-06 13:15       ` Markus Trippelsdorf
  2017-09-07  6:28         ` Markus Trippelsdorf
  0 siblings, 1 reply; 61+ messages in thread
From: Markus Trippelsdorf @ 2017-09-06 13:15 UTC (permalink / raw)
  To: Thomas Gleixner; +Cc: Peter Zijlstra, linux-kernel, Ingo Molnar

On 2017.09.06 at 14:52 +0200, Thomas Gleixner wrote:
> On Tue, 5 Sep 2017, Markus Trippelsdorf wrote:
> > On 2017.09.05 at 10:53 +0200, Peter Zijlstra wrote:
> > > > Any ideas on how to debug this further?
> > > 
> > > So you have a (real) serial line on that box?
> > 
> > Sadly, no. But hopefully somebody else (with a proper kernel debugging
> > setup) will reproduce the issue soon.
> 
> Does the machine respond to ping or is it entirely dead?

It is entirely dead and doesn't respond to ping.

-- 
Markus

^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: Current mainline git (24e700e291d52bd2) hangs when building e.g. perf
  2017-09-06 13:15       ` Markus Trippelsdorf
@ 2017-09-07  6:28         ` Markus Trippelsdorf
  2017-09-08  5:35           ` Markus Trippelsdorf
  0 siblings, 1 reply; 61+ messages in thread
From: Markus Trippelsdorf @ 2017-09-07  6:28 UTC (permalink / raw)
  To: Thomas Gleixner; +Cc: Peter Zijlstra, linux-kernel, Ingo Molnar

On 2017.09.06 at 15:15 +0200, Markus Trippelsdorf wrote:
> On 2017.09.06 at 14:52 +0200, Thomas Gleixner wrote:
> > On Tue, 5 Sep 2017, Markus Trippelsdorf wrote:
> > > On 2017.09.05 at 10:53 +0200, Peter Zijlstra wrote:
> > > > > Any ideas on how to debug this further?
> > > > 
> > > > So you have a (real) serial line on that box?
> > > 
> > > Sadly, no. But hopefully somebody else (with a proper kernel debugging
> > > setup) will reproduce the issue soon.
> > 
> > Does the machine respond to ping or is it entirely dead?
> 
> It is entirely dead and doesn't respond to ping.

The bug even kills the host (running 4.13) when running 24e700e2 in qemu
(kvm) and compiling stuff in parallel in the guest.
I see an RCU CPU stall in dmesg (on the host), but unfortunately cannot
save it, because nothing gets written to disk after the stall.
Connecting to qemu via gdb also doesn't work.

-- 
Markus

^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: Current mainline git (24e700e291d52bd2) hangs when building e.g. perf
  2017-09-07  6:28         ` Markus Trippelsdorf
@ 2017-09-08  5:35           ` Markus Trippelsdorf
  2017-09-08  6:26             ` Thomas Gleixner
  0 siblings, 1 reply; 61+ messages in thread
From: Markus Trippelsdorf @ 2017-09-08  5:35 UTC (permalink / raw)
  To: Thomas Gleixner
  Cc: Peter Zijlstra, linux-kernel, Ingo Molnar, Andy Lutomirski

[-- Attachment #1: Type: text/plain, Size: 1148 bytes --]

On 2017.09.07 at 08:28 +0200, Markus Trippelsdorf wrote:
> On 2017.09.06 at 15:15 +0200, Markus Trippelsdorf wrote:
> > On 2017.09.06 at 14:52 +0200, Thomas Gleixner wrote:
> > > On Tue, 5 Sep 2017, Markus Trippelsdorf wrote:
> > > > On 2017.09.05 at 10:53 +0200, Peter Zijlstra wrote:
> > > > > > Any ideas on how to debug this further?
> > > > > 
> > > > > So you have a (real) serial line on that box?
> > > > 
> > > > Sadly, no. But hopefully somebody else (with a proper kernel debugging
> > > > setup) will reproduce the issue soon.
> > > 
> > > Does the machine respond to ping or is it entirely dead?
> > 
> > It is entirely dead and doesn't respond to ping.
> 
> The bug even kills the host (running 4.13) when running 24e700e2 in qemu
> (kvm) and compiling stuff in parallel in the guest.
> I see an RCU CPU stall in dmesg (on the host), but unfortunately cannot
> save it, because nothing gets written to disk after the stall.
> Connecting to qemu via gdb also doesn't work.

My guess would be a bug in a low level function (asm) that only hits AMD
machines. I'm running an old Phenom II X4 processor. My config is
attached.

-- 
Markus

[-- Attachment #2: config --]
[-- Type: text/plain, Size: 84296 bytes --]

#
# Automatically generated file; DO NOT EDIT.
# Linux/x86 4.13.0 Kernel Configuration
#
CONFIG_64BIT=y
CONFIG_X86_64=y
CONFIG_X86=y
CONFIG_INSTRUCTION_DECODER=y
CONFIG_OUTPUT_FORMAT="elf64-x86-64"
CONFIG_ARCH_DEFCONFIG="arch/x86/configs/x86_64_defconfig"
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_MMU=y
CONFIG_ARCH_MMAP_RND_BITS_MIN=28
CONFIG_ARCH_MMAP_RND_BITS_MAX=32
CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MIN=8
CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MAX=16
CONFIG_NEED_DMA_MAP_STATE=y
CONFIG_NEED_SG_DMA_LENGTH=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_BUG_RELATIVE_POINTERS=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_ARCH_HAS_CPU_RELAX=y
CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
CONFIG_HAVE_SETUP_PER_CPU_AREA=y
CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y
CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y
CONFIG_ARCH_HIBERNATION_POSSIBLE=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y
CONFIG_ARCH_WANT_GENERAL_HUGETLB=y
CONFIG_ZONE_DMA32=y
CONFIG_AUDIT_ARCH=y
CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y
CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
CONFIG_X86_64_SMP=y
CONFIG_ARCH_SUPPORTS_UPROBES=y
CONFIG_FIX_EARLYCON_MEM=y
CONFIG_PGTABLE_LEVELS=4
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
CONFIG_IRQ_WORK=y
CONFIG_BUILDTIME_EXTABLE_SORT=y
CONFIG_THREAD_INFO_IN_TASK=y

#
# General setup
#
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_CROSS_COMPILE=""
# CONFIG_COMPILE_TEST is not set
CONFIG_LOCALVERSION=""
CONFIG_LOCALVERSION_AUTO=y
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_BZIP2=y
CONFIG_HAVE_KERNEL_LZMA=y
CONFIG_HAVE_KERNEL_XZ=y
CONFIG_HAVE_KERNEL_LZO=y
CONFIG_HAVE_KERNEL_LZ4=y
# CONFIG_KERNEL_GZIP is not set
# CONFIG_KERNEL_BZIP2 is not set
# CONFIG_KERNEL_LZMA is not set
# CONFIG_KERNEL_XZ is not set
CONFIG_KERNEL_LZO=y
# CONFIG_KERNEL_LZ4 is not set
CONFIG_DEFAULT_HOSTNAME="(none)"
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_SYSVIPC_SYSCTL=y
CONFIG_POSIX_MQUEUE=y
CONFIG_POSIX_MQUEUE_SYSCTL=y
# CONFIG_CROSS_MEMORY_ATTACH is not set
# CONFIG_FHANDLE is not set
# CONFIG_USELIB is not set
# CONFIG_AUDIT is not set
CONFIG_HAVE_ARCH_AUDITSYSCALL=y

#
# IRQ subsystem
#
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_GENERIC_IRQ_SHOW=y
CONFIG_GENERIC_IRQ_EFFECTIVE_AFF_MASK=y
CONFIG_GENERIC_PENDING_IRQ=y
CONFIG_GENERIC_IRQ_MIGRATION=y
CONFIG_IRQ_DOMAIN=y
CONFIG_IRQ_DOMAIN_HIERARCHY=y
CONFIG_GENERIC_MSI_IRQ=y
CONFIG_GENERIC_MSI_IRQ_DOMAIN=y
# CONFIG_IRQ_DOMAIN_DEBUG is not set
CONFIG_IRQ_FORCED_THREADING=y
CONFIG_SPARSE_IRQ=y
# CONFIG_GENERIC_IRQ_DEBUGFS is not set
CONFIG_CLOCKSOURCE_WATCHDOG=y
CONFIG_ARCH_CLOCKSOURCE_DATA=y
CONFIG_CLOCKSOURCE_VALIDATE_LAST_CYCLE=y
CONFIG_GENERIC_TIME_VSYSCALL=y
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y
CONFIG_GENERIC_CLOCKEVENTS_MIN_ADJUST=y
CONFIG_GENERIC_CMOS_UPDATE=y

#
# Timers subsystem
#
CONFIG_TICK_ONESHOT=y
CONFIG_NO_HZ_COMMON=y
# CONFIG_HZ_PERIODIC is not set
CONFIG_NO_HZ_IDLE=y
# CONFIG_NO_HZ_FULL is not set
CONFIG_NO_HZ=y
CONFIG_HIGH_RES_TIMERS=y

#
# CPU/Task time and stats accounting
#
CONFIG_TICK_CPU_ACCOUNTING=y
# CONFIG_VIRT_CPU_ACCOUNTING_GEN is not set
# CONFIG_IRQ_TIME_ACCOUNTING is not set
CONFIG_BSD_PROCESS_ACCT=y
# CONFIG_BSD_PROCESS_ACCT_V3 is not set
CONFIG_TASKSTATS=y
CONFIG_TASK_DELAY_ACCT=y
# CONFIG_TASK_XACCT is not set

#
# RCU Subsystem
#
CONFIG_TREE_RCU=y
# CONFIG_RCU_EXPERT is not set
CONFIG_SRCU=y
CONFIG_TREE_SRCU=y
# CONFIG_TASKS_RCU is not set
CONFIG_RCU_STALL_COMMON=y
CONFIG_RCU_NEED_SEGCBLIST=y
CONFIG_BUILD_BIN2C=y
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
CONFIG_LOG_BUF_SHIFT=18
CONFIG_LOG_CPU_MAX_BUF_SHIFT=12
CONFIG_PRINTK_SAFE_LOG_BUF_SHIFT=13
CONFIG_HAVE_UNSTABLE_SCHED_CLOCK=y
CONFIG_ARCH_SUPPORTS_NUMA_BALANCING=y
CONFIG_ARCH_WANT_BATCHED_UNMAP_TLB_FLUSH=y
CONFIG_ARCH_SUPPORTS_INT128=y
# CONFIG_CGROUPS is not set
# CONFIG_CHECKPOINT_RESTORE is not set
CONFIG_NAMESPACES=y
# CONFIG_UTS_NS is not set
# CONFIG_IPC_NS is not set
CONFIG_USER_NS=y
CONFIG_PID_NS=y
CONFIG_NET_NS=y
# CONFIG_SCHED_AUTOGROUP is not set
# CONFIG_SYSFS_DEPRECATED is not set
# CONFIG_RELAY is not set
# CONFIG_BLK_DEV_INITRD is not set
CONFIG_CC_OPTIMIZE_FOR_PERFORMANCE=y
# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
CONFIG_SYSCTL=y
CONFIG_ANON_INODES=y
CONFIG_SYSCTL_EXCEPTION_TRACE=y
CONFIG_HAVE_PCSPKR_PLATFORM=y
CONFIG_BPF=y
CONFIG_EXPERT=y
CONFIG_MULTIUSER=y
# CONFIG_SGETMASK_SYSCALL is not set
# CONFIG_SYSFS_SYSCALL is not set
CONFIG_SYSCTL_SYSCALL=y
CONFIG_POSIX_TIMERS=y
CONFIG_KALLSYMS=y
# CONFIG_KALLSYMS_ALL is not set
CONFIG_KALLSYMS_ABSOLUTE_PERCPU=y
CONFIG_KALLSYMS_BASE_RELATIVE=y
CONFIG_PRINTK=y
CONFIG_PRINTK_NMI=y
CONFIG_BUG=y
# CONFIG_PCSPKR_PLATFORM is not set
CONFIG_BASE_FULL=y
CONFIG_FUTEX=y
CONFIG_FUTEX_PI=y
CONFIG_EPOLL=y
CONFIG_SIGNALFD=y
CONFIG_TIMERFD=y
CONFIG_EVENTFD=y
# CONFIG_BPF_SYSCALL is not set
CONFIG_SHMEM=y
CONFIG_AIO=y
CONFIG_ADVISE_SYSCALLS=y
# CONFIG_USERFAULTFD is not set
CONFIG_PCI_QUIRKS=y
CONFIG_MEMBARRIER=y
CONFIG_EMBEDDED=y
CONFIG_HAVE_PERF_EVENTS=y
# CONFIG_PC104 is not set

#
# Kernel Performance Events And Counters
#
CONFIG_PERF_EVENTS=y
# CONFIG_DEBUG_PERF_USE_VMALLOC is not set
CONFIG_VM_EVENT_COUNTERS=y
# CONFIG_SLUB_DEBUG is not set
# CONFIG_COMPAT_BRK is not set
# CONFIG_SLAB is not set
CONFIG_SLUB=y
# CONFIG_SLOB is not set
CONFIG_SLAB_MERGE_DEFAULT=y
# CONFIG_SLAB_FREELIST_RANDOM is not set
# CONFIG_SLAB_FREELIST_HARDENED is not set
CONFIG_SLUB_CPU_PARTIAL=y
# CONFIG_SYSTEM_DATA_VERIFICATION is not set
# CONFIG_PROFILING is not set
CONFIG_CRASH_CORE=y
CONFIG_KEXEC_CORE=y
CONFIG_HAVE_OPROFILE=y
CONFIG_OPROFILE_NMI_TIMER=y
CONFIG_JUMP_LABEL=y
# CONFIG_STATIC_KEYS_SELFTEST is not set
# CONFIG_UPROBES is not set
# CONFIG_HAVE_64BIT_ALIGNED_ACCESS is not set
CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS=y
CONFIG_ARCH_USE_BUILTIN_BSWAP=y
CONFIG_USER_RETURN_NOTIFIER=y
CONFIG_HAVE_IOREMAP_PROT=y
CONFIG_HAVE_KPROBES=y
CONFIG_HAVE_KRETPROBES=y
CONFIG_HAVE_OPTPROBES=y
CONFIG_HAVE_KPROBES_ON_FTRACE=y
CONFIG_HAVE_NMI=y
CONFIG_HAVE_ARCH_TRACEHOOK=y
CONFIG_HAVE_DMA_CONTIGUOUS=y
CONFIG_GENERIC_SMP_IDLE_THREAD=y
CONFIG_ARCH_HAS_FORTIFY_SOURCE=y
CONFIG_ARCH_HAS_SET_MEMORY=y
CONFIG_ARCH_WANTS_DYNAMIC_TASK_STRUCT=y
CONFIG_HAVE_REGS_AND_STACK_ACCESS_API=y
CONFIG_HAVE_CLK=y
CONFIG_HAVE_DMA_API_DEBUG=y
CONFIG_HAVE_HW_BREAKPOINT=y
CONFIG_HAVE_MIXED_BREAKPOINTS_REGS=y
CONFIG_HAVE_USER_RETURN_NOTIFIER=y
CONFIG_HAVE_PERF_EVENTS_NMI=y
CONFIG_HAVE_HARDLOCKUP_DETECTOR_PERF=y
CONFIG_HAVE_PERF_REGS=y
CONFIG_HAVE_PERF_USER_STACK_DUMP=y
CONFIG_HAVE_ARCH_JUMP_LABEL=y
CONFIG_HAVE_RCU_TABLE_FREE=y
CONFIG_ARCH_HAVE_NMI_SAFE_CMPXCHG=y
CONFIG_HAVE_ALIGNED_STRUCT_PAGE=y
CONFIG_HAVE_CMPXCHG_LOCAL=y
CONFIG_HAVE_CMPXCHG_DOUBLE=y
CONFIG_HAVE_ARCH_SECCOMP_FILTER=y
CONFIG_SECCOMP_FILTER=y
CONFIG_HAVE_GCC_PLUGINS=y
# CONFIG_GCC_PLUGINS is not set
CONFIG_HAVE_CC_STACKPROTECTOR=y
# CONFIG_CC_STACKPROTECTOR is not set
CONFIG_CC_STACKPROTECTOR_NONE=y
# CONFIG_CC_STACKPROTECTOR_REGULAR is not set
# CONFIG_CC_STACKPROTECTOR_STRONG is not set
CONFIG_THIN_ARCHIVES=y
CONFIG_HAVE_ARCH_WITHIN_STACK_FRAMES=y
CONFIG_HAVE_CONTEXT_TRACKING=y
CONFIG_HAVE_VIRT_CPU_ACCOUNTING_GEN=y
CONFIG_HAVE_IRQ_TIME_ACCOUNTING=y
CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE=y
CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE_PUD=y
CONFIG_HAVE_ARCH_HUGE_VMAP=y
CONFIG_HAVE_ARCH_SOFT_DIRTY=y
CONFIG_HAVE_MOD_ARCH_SPECIFIC=y
CONFIG_MODULES_USE_ELF_RELA=y
CONFIG_HAVE_IRQ_EXIT_ON_IRQ_STACK=y
CONFIG_ARCH_HAS_ELF_RANDOMIZE=y
CONFIG_HAVE_ARCH_MMAP_RND_BITS=y
CONFIG_HAVE_EXIT_THREAD=y
CONFIG_ARCH_MMAP_RND_BITS=28
CONFIG_HAVE_COPY_THREAD_TLS=y
CONFIG_HAVE_STACK_VALIDATION=y
# CONFIG_HAVE_ARCH_HASH is not set
# CONFIG_ISA_BUS_API is not set
# CONFIG_CPU_NO_EFFICIENT_FFS is not set
CONFIG_HAVE_ARCH_VMAP_STACK=y
CONFIG_VMAP_STACK=y
# CONFIG_ARCH_OPTIONAL_KERNEL_RWX is not set
# CONFIG_ARCH_OPTIONAL_KERNEL_RWX_DEFAULT is not set
CONFIG_ARCH_HAS_STRICT_KERNEL_RWX=y
CONFIG_STRICT_KERNEL_RWX=y
CONFIG_ARCH_HAS_STRICT_MODULE_RWX=y
# CONFIG_REFCOUNT_FULL is not set

#
# GCOV-based kernel profiling
#
# CONFIG_GCOV_KERNEL is not set
CONFIG_ARCH_HAS_GCOV_PROFILE_ALL=y
# CONFIG_HAVE_GENERIC_DMA_COHERENT is not set
CONFIG_RT_MUTEXES=y
CONFIG_BASE_SMALL=0
# CONFIG_MODULES is not set
CONFIG_MODULES_TREE_LOOKUP=y
CONFIG_BLOCK=y
CONFIG_BLK_SCSI_REQUEST=y
CONFIG_BLK_DEV_BSG=y
# CONFIG_BLK_DEV_BSGLIB is not set
# CONFIG_BLK_DEV_INTEGRITY is not set
# CONFIG_BLK_DEV_ZONED is not set
# CONFIG_BLK_CMDLINE_PARSER is not set
# CONFIG_BLK_WBT is not set
CONFIG_BLK_DEBUG_FS=y
# CONFIG_BLK_SED_OPAL is not set

#
# Partition Types
#
CONFIG_PARTITION_ADVANCED=y
# CONFIG_ACORN_PARTITION is not set
# CONFIG_AIX_PARTITION is not set
# CONFIG_OSF_PARTITION is not set
# CONFIG_AMIGA_PARTITION is not set
# CONFIG_ATARI_PARTITION is not set
# CONFIG_MAC_PARTITION is not set
CONFIG_MSDOS_PARTITION=y
# CONFIG_BSD_DISKLABEL is not set
# CONFIG_MINIX_SUBPARTITION is not set
# CONFIG_SOLARIS_X86_PARTITION is not set
# CONFIG_UNIXWARE_DISKLABEL is not set
# CONFIG_LDM_PARTITION is not set
# CONFIG_SGI_PARTITION is not set
# CONFIG_ULTRIX_PARTITION is not set
# CONFIG_SUN_PARTITION is not set
# CONFIG_KARMA_PARTITION is not set
CONFIG_EFI_PARTITION=y
# CONFIG_SYSV68_PARTITION is not set
# CONFIG_CMDLINE_PARTITION is not set
CONFIG_BLK_MQ_PCI=y
CONFIG_BLK_MQ_VIRTIO=y

#
# IO Schedulers
#
CONFIG_IOSCHED_NOOP=y
# CONFIG_IOSCHED_DEADLINE is not set
# CONFIG_IOSCHED_CFQ is not set
CONFIG_DEFAULT_NOOP=y
CONFIG_DEFAULT_IOSCHED="noop"
CONFIG_MQ_IOSCHED_DEADLINE=y
# CONFIG_MQ_IOSCHED_KYBER is not set
# CONFIG_IOSCHED_BFQ is not set
CONFIG_PREEMPT_NOTIFIERS=y
CONFIG_INLINE_SPIN_UNLOCK_IRQ=y
CONFIG_INLINE_READ_UNLOCK=y
CONFIG_INLINE_READ_UNLOCK_IRQ=y
CONFIG_INLINE_WRITE_UNLOCK=y
CONFIG_INLINE_WRITE_UNLOCK_IRQ=y
CONFIG_ARCH_SUPPORTS_ATOMIC_RMW=y
CONFIG_MUTEX_SPIN_ON_OWNER=y
CONFIG_RWSEM_SPIN_ON_OWNER=y
CONFIG_LOCK_SPIN_ON_OWNER=y
CONFIG_ARCH_USE_QUEUED_SPINLOCKS=y
CONFIG_QUEUED_SPINLOCKS=y
CONFIG_ARCH_USE_QUEUED_RWLOCKS=y
CONFIG_QUEUED_RWLOCKS=y
# CONFIG_FREEZER is not set

#
# Processor type and features
#
CONFIG_ZONE_DMA=y
CONFIG_SMP=y
CONFIG_X86_FEATURE_NAMES=y
CONFIG_X86_FAST_FEATURE_TESTS=y
# CONFIG_X86_MPPARSE is not set
# CONFIG_GOLDFISH is not set
# CONFIG_X86_EXTENDED_PLATFORM is not set
# CONFIG_X86_INTEL_LPSS is not set
# CONFIG_X86_AMD_PLATFORM_DEVICE is not set
CONFIG_IOSF_MBI=y
# CONFIG_IOSF_MBI_DEBUG is not set
CONFIG_X86_SUPPORTS_MEMORY_FAILURE=y
CONFIG_SCHED_OMIT_FRAME_POINTER=y
# CONFIG_HYPERVISOR_GUEST is not set
CONFIG_NO_BOOTMEM=y
CONFIG_MK8=y
# CONFIG_MPSC is not set
# CONFIG_MCORE2 is not set
# CONFIG_MATOM is not set
# CONFIG_GENERIC_CPU is not set
CONFIG_X86_INTERNODE_CACHE_SHIFT=6
CONFIG_X86_L1_CACHE_SHIFT=6
CONFIG_X86_INTEL_USERCOPY=y
CONFIG_X86_USE_PPRO_CHECKSUM=y
CONFIG_X86_TSC=y
CONFIG_X86_CMPXCHG64=y
CONFIG_X86_CMOV=y
CONFIG_X86_MINIMUM_CPU_FAMILY=64
CONFIG_X86_DEBUGCTLMSR=y
CONFIG_PROCESSOR_SELECT=y
# CONFIG_CPU_SUP_INTEL is not set
CONFIG_CPU_SUP_AMD=y
# CONFIG_CPU_SUP_CENTAUR is not set
CONFIG_HPET_TIMER=y
CONFIG_HPET_EMULATE_RTC=y
CONFIG_DMI=y
# CONFIG_GART_IOMMU is not set
# CONFIG_CALGARY_IOMMU is not set
CONFIG_SWIOTLB=y
CONFIG_IOMMU_HELPER=y
# CONFIG_MAXSMP is not set
CONFIG_NR_CPUS=4
# CONFIG_SCHED_SMT is not set
CONFIG_SCHED_MC=y
# CONFIG_PREEMPT_NONE is not set
CONFIG_PREEMPT_VOLUNTARY=y
# CONFIG_PREEMPT is not set
CONFIG_X86_LOCAL_APIC=y
CONFIG_X86_IO_APIC=y
# CONFIG_X86_REROUTE_FOR_BROKEN_BOOT_IRQS is not set
CONFIG_X86_MCE=y
# CONFIG_X86_MCELOG_LEGACY is not set
# CONFIG_X86_MCE_INTEL is not set
CONFIG_X86_MCE_AMD=y
CONFIG_X86_MCE_THRESHOLD=y
# CONFIG_X86_MCE_INJECT is not set

#
# Performance monitoring
#
# CONFIG_PERF_EVENTS_AMD_POWER is not set
# CONFIG_VM86 is not set
CONFIG_X86_VSYSCALL_EMULATION=y
# CONFIG_I8K is not set
CONFIG_MICROCODE=y
# CONFIG_MICROCODE_INTEL is not set
CONFIG_MICROCODE_AMD=y
CONFIG_MICROCODE_OLD_INTERFACE=y
CONFIG_X86_MSR=y
CONFIG_X86_CPUID=y
# CONFIG_X86_5LEVEL is not set
CONFIG_ARCH_PHYS_ADDR_T_64BIT=y
CONFIG_ARCH_DMA_ADDR_T_64BIT=y
CONFIG_X86_DIRECT_GBPAGES=y
CONFIG_ARCH_HAS_MEM_ENCRYPT=y
# CONFIG_AMD_MEM_ENCRYPT is not set
# CONFIG_NUMA is not set
CONFIG_ARCH_SPARSEMEM_ENABLE=y
CONFIG_ARCH_SPARSEMEM_DEFAULT=y
CONFIG_ARCH_SELECT_MEMORY_MODEL=y
CONFIG_ARCH_PROC_KCORE_TEXT=y
CONFIG_ILLEGAL_POINTER_VALUE=0xdead000000000000
CONFIG_SELECT_MEMORY_MODEL=y
CONFIG_SPARSEMEM_MANUAL=y
CONFIG_SPARSEMEM=y
CONFIG_HAVE_MEMORY_PRESENT=y
CONFIG_SPARSEMEM_EXTREME=y
CONFIG_SPARSEMEM_VMEMMAP_ENABLE=y
CONFIG_SPARSEMEM_ALLOC_MEM_MAP_TOGETHER=y
CONFIG_SPARSEMEM_VMEMMAP=y
CONFIG_HAVE_MEMBLOCK=y
CONFIG_HAVE_MEMBLOCK_NODE_MAP=y
CONFIG_HAVE_GENERIC_GUP=y
CONFIG_ARCH_DISCARD_MEMBLOCK=y
# CONFIG_HAVE_BOOTMEM_INFO_NODE is not set
# CONFIG_MEMORY_HOTPLUG is not set
CONFIG_SPLIT_PTLOCK_CPUS=4
CONFIG_ARCH_ENABLE_SPLIT_PMD_PTLOCK=y
CONFIG_COMPACTION=y
CONFIG_MIGRATION=y
CONFIG_PHYS_ADDR_T_64BIT=y
CONFIG_BOUNCE=y
CONFIG_VIRT_TO_BUS=y
CONFIG_MMU_NOTIFIER=y
# CONFIG_KSM is not set
CONFIG_DEFAULT_MMAP_MIN_ADDR=4096
CONFIG_ARCH_SUPPORTS_MEMORY_FAILURE=y
# CONFIG_MEMORY_FAILURE is not set
# CONFIG_TRANSPARENT_HUGEPAGE is not set
CONFIG_ARCH_WANTS_THP_SWAP=y
# CONFIG_CLEANCACHE is not set
# CONFIG_FRONTSWAP is not set
# CONFIG_CMA is not set
# CONFIG_ZPOOL is not set
# CONFIG_ZBUD is not set
# CONFIG_ZSMALLOC is not set
CONFIG_GENERIC_EARLY_IOREMAP=y
CONFIG_ARCH_SUPPORTS_DEFERRED_STRUCT_PAGE_INIT=y
# CONFIG_IDLE_PAGE_TRACKING is not set
CONFIG_ARCH_HAS_ZONE_DEVICE=y
# CONFIG_PERCPU_STATS is not set
# CONFIG_X86_PMEM_LEGACY is not set
# CONFIG_X86_CHECK_BIOS_CORRUPTION is not set
CONFIG_X86_RESERVE_LOW=64
CONFIG_MTRR=y
CONFIG_MTRR_SANITIZER=y
CONFIG_MTRR_SANITIZER_ENABLE_DEFAULT=1
CONFIG_MTRR_SANITIZER_SPARE_REG_NR_DEFAULT=2
CONFIG_X86_PAT=y
CONFIG_ARCH_USES_PG_UNCACHED=y
# CONFIG_ARCH_RANDOM is not set
# CONFIG_X86_SMAP is not set
# CONFIG_EFI is not set
CONFIG_SECCOMP=y
# CONFIG_HZ_100 is not set
# CONFIG_HZ_250 is not set
CONFIG_HZ_300=y
# CONFIG_HZ_1000 is not set
CONFIG_HZ=300
CONFIG_SCHED_HRTICK=y
CONFIG_KEXEC=y
# CONFIG_CRASH_DUMP is not set
CONFIG_PHYSICAL_START=0x200000
# CONFIG_RELOCATABLE is not set
CONFIG_PHYSICAL_ALIGN=0x1000000
# CONFIG_HOTPLUG_CPU is not set
# CONFIG_LEGACY_VSYSCALL_NATIVE is not set
CONFIG_LEGACY_VSYSCALL_EMULATE=y
# CONFIG_LEGACY_VSYSCALL_NONE is not set
# CONFIG_CMDLINE_BOOL is not set
# CONFIG_MODIFY_LDT_SYSCALL is not set
CONFIG_HAVE_LIVEPATCH=y
CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG=y

#
# Power management and ACPI options
#
# CONFIG_SUSPEND is not set
# CONFIG_HIBERNATION is not set
CONFIG_PM=y
# CONFIG_PM_DEBUG is not set
CONFIG_PM_CLK=y
# CONFIG_WQ_POWER_EFFICIENT_DEFAULT is not set
CONFIG_ACPI=y
CONFIG_ACPI_LEGACY_TABLES_LOOKUP=y
CONFIG_ARCH_MIGHT_HAVE_ACPI_PDC=y
CONFIG_ACPI_SYSTEM_POWER_STATES_SUPPORT=y
# CONFIG_ACPI_DEBUGGER is not set
# CONFIG_ACPI_PROCFS_POWER is not set
CONFIG_ACPI_REV_OVERRIDE_POSSIBLE=y
# CONFIG_ACPI_EC_DEBUGFS is not set
# CONFIG_ACPI_AC is not set
# CONFIG_ACPI_BATTERY is not set
# CONFIG_ACPI_BUTTON is not set
# CONFIG_ACPI_VIDEO is not set
# CONFIG_ACPI_FAN is not set
# CONFIG_ACPI_DOCK is not set
CONFIG_ACPI_CPU_FREQ_PSS=y
CONFIG_ACPI_PROCESSOR_CSTATE=y
CONFIG_ACPI_PROCESSOR_IDLE=y
CONFIG_ACPI_PROCESSOR=y
# CONFIG_ACPI_PROCESSOR_AGGREGATOR is not set
# CONFIG_ACPI_THERMAL is not set
# CONFIG_ACPI_CUSTOM_DSDT is not set
CONFIG_ARCH_HAS_ACPI_TABLE_UPGRADE=y
# CONFIG_ACPI_DEBUG is not set
# CONFIG_ACPI_PCI_SLOT is not set
CONFIG_X86_PM_TIMER=y
# CONFIG_ACPI_CONTAINER is not set
CONFIG_ACPI_HOTPLUG_IOAPIC=y
# CONFIG_ACPI_SBS is not set
# CONFIG_ACPI_HED is not set
# CONFIG_ACPI_CUSTOM_METHOD is not set
# CONFIG_ACPI_REDUCED_HARDWARE_ONLY is not set
# CONFIG_ACPI_NFIT is not set
CONFIG_HAVE_ACPI_APEI=y
CONFIG_HAVE_ACPI_APEI_NMI=y
# CONFIG_ACPI_APEI is not set
# CONFIG_DPTF_POWER is not set
# CONFIG_ACPI_EXTLOG is not set
# CONFIG_PMIC_OPREGION is not set
# CONFIG_ACPI_CONFIGFS is not set
# CONFIG_SFI is not set

#
# CPU Frequency scaling
#
CONFIG_CPU_FREQ=y
CONFIG_CPU_FREQ_GOV_ATTR_SET=y
CONFIG_CPU_FREQ_GOV_COMMON=y
CONFIG_CPU_FREQ_STAT=y
# CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE is not set
# CONFIG_CPU_FREQ_DEFAULT_GOV_POWERSAVE is not set
# CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE is not set
CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND=y
# CONFIG_CPU_FREQ_DEFAULT_GOV_CONSERVATIVE is not set
# CONFIG_CPU_FREQ_DEFAULT_GOV_SCHEDUTIL is not set
CONFIG_CPU_FREQ_GOV_PERFORMANCE=y
# CONFIG_CPU_FREQ_GOV_POWERSAVE is not set
# CONFIG_CPU_FREQ_GOV_USERSPACE is not set
CONFIG_CPU_FREQ_GOV_ONDEMAND=y
# CONFIG_CPU_FREQ_GOV_CONSERVATIVE is not set
# CONFIG_CPU_FREQ_GOV_SCHEDUTIL is not set

#
# CPU frequency scaling drivers
#
# CONFIG_X86_INTEL_PSTATE is not set
# CONFIG_X86_PCC_CPUFREQ is not set
CONFIG_X86_ACPI_CPUFREQ=y
# CONFIG_X86_ACPI_CPUFREQ_CPB is not set
# CONFIG_X86_POWERNOW_K8 is not set
# CONFIG_X86_AMD_FREQ_SENSITIVITY is not set
# CONFIG_X86_SPEEDSTEP_CENTRINO is not set
# CONFIG_X86_P4_CLOCKMOD is not set

#
# shared options
#
# CONFIG_X86_SPEEDSTEP_LIB is not set

#
# CPU Idle
#
CONFIG_CPU_IDLE=y
CONFIG_CPU_IDLE_GOV_LADDER=y
CONFIG_CPU_IDLE_GOV_MENU=y
# CONFIG_ARCH_NEEDS_CPU_IDLE_COUPLED is not set

#
# Bus options (PCI etc.)
#
CONFIG_PCI=y
CONFIG_PCI_DIRECT=y
# CONFIG_PCI_MMCONFIG is not set
CONFIG_PCI_DOMAINS=y
# CONFIG_PCI_CNB20LE_QUIRK is not set
# CONFIG_PCIEPORTBUS is not set
CONFIG_PCI_BUS_ADDR_T_64BIT=y
CONFIG_PCI_MSI=y
CONFIG_PCI_MSI_IRQ_DOMAIN=y
# CONFIG_PCI_DEBUG is not set
# CONFIG_PCI_REALLOC_ENABLE_AUTO is not set
# CONFIG_PCI_STUB is not set
CONFIG_HT_IRQ=y
CONFIG_PCI_LOCKLESS_CONFIG=y
# CONFIG_PCI_IOV is not set
# CONFIG_PCI_PRI is not set
# CONFIG_PCI_PASID is not set
CONFIG_PCI_LABEL=y
# CONFIG_HOTPLUG_PCI is not set

#
# DesignWare PCI Core Support
#
# CONFIG_PCIE_DW_PLAT is not set

#
# PCI host controller drivers
#
# CONFIG_VMD is not set

#
# PCI Endpoint
#
# CONFIG_PCI_ENDPOINT is not set

#
# PCI switch controller drivers
#
# CONFIG_PCI_SW_SWITCHTEC is not set
# CONFIG_ISA_BUS is not set
CONFIG_ISA_DMA_API=y
CONFIG_AMD_NB=y
# CONFIG_PCCARD is not set
# CONFIG_RAPIDIO is not set
# CONFIG_X86_SYSFB is not set

#
# Executable file formats / Emulations
#
CONFIG_BINFMT_ELF=y
CONFIG_ELFCORE=y
CONFIG_BINFMT_SCRIPT=y
# CONFIG_HAVE_AOUT is not set
# CONFIG_BINFMT_MISC is not set
# CONFIG_COREDUMP is not set
# CONFIG_IA32_EMULATION is not set
# CONFIG_X86_X32 is not set
CONFIG_X86_DEV_DMA_OPS=y
CONFIG_NET=y
CONFIG_NET_INGRESS=y

#
# Networking options
#
CONFIG_PACKET=y
# CONFIG_PACKET_DIAG is not set
CONFIG_UNIX=y
# CONFIG_UNIX_DIAG is not set
# CONFIG_TLS is not set
# CONFIG_XFRM_USER is not set
# CONFIG_NET_KEY is not set
CONFIG_INET=y
# CONFIG_IP_MULTICAST is not set
# CONFIG_IP_ADVANCED_ROUTER is not set
CONFIG_IP_PNP=y
CONFIG_IP_PNP_DHCP=y
# CONFIG_IP_PNP_BOOTP is not set
# CONFIG_IP_PNP_RARP is not set
# CONFIG_NET_IPIP is not set
# CONFIG_NET_IPGRE_DEMUX is not set
# CONFIG_NET_IP_TUNNEL is not set
# CONFIG_SYN_COOKIES is not set
# CONFIG_NET_UDP_TUNNEL is not set
# CONFIG_NET_FOU is not set
# CONFIG_INET_AH is not set
# CONFIG_INET_ESP is not set
# CONFIG_INET_IPCOMP is not set
# CONFIG_INET_XFRM_TUNNEL is not set
# CONFIG_INET_TUNNEL is not set
# CONFIG_INET_XFRM_MODE_TRANSPORT is not set
# CONFIG_INET_XFRM_MODE_TUNNEL is not set
# CONFIG_INET_XFRM_MODE_BEET is not set
CONFIG_INET_DIAG=y
CONFIG_INET_TCP_DIAG=y
# CONFIG_INET_UDP_DIAG is not set
# CONFIG_INET_RAW_DIAG is not set
# CONFIG_INET_DIAG_DESTROY is not set
CONFIG_TCP_CONG_ADVANCED=y
# CONFIG_TCP_CONG_BIC is not set
CONFIG_TCP_CONG_CUBIC=y
# CONFIG_TCP_CONG_WESTWOOD is not set
# CONFIG_TCP_CONG_HTCP is not set
# CONFIG_TCP_CONG_HSTCP is not set
# CONFIG_TCP_CONG_HYBLA is not set
# CONFIG_TCP_CONG_VEGAS is not set
# CONFIG_TCP_CONG_NV is not set
# CONFIG_TCP_CONG_SCALABLE is not set
# CONFIG_TCP_CONG_LP is not set
# CONFIG_TCP_CONG_VENO is not set
# CONFIG_TCP_CONG_YEAH is not set
# CONFIG_TCP_CONG_ILLINOIS is not set
# CONFIG_TCP_CONG_DCTCP is not set
# CONFIG_TCP_CONG_CDG is not set
CONFIG_TCP_CONG_BBR=y
# CONFIG_DEFAULT_CUBIC is not set
CONFIG_DEFAULT_BBR=y
# CONFIG_DEFAULT_RENO is not set
CONFIG_DEFAULT_TCP_CONG="bbr"
# CONFIG_TCP_MD5SIG is not set
# CONFIG_IPV6 is not set
# CONFIG_NETWORK_SECMARK is not set
# CONFIG_NET_PTP_CLASSIFY is not set
# CONFIG_NETWORK_PHY_TIMESTAMPING is not set
CONFIG_NETFILTER=y
# CONFIG_NETFILTER_ADVANCED is not set

#
# Core Netfilter Configuration
#
CONFIG_NETFILTER_INGRESS=y
CONFIG_NETFILTER_NETLINK=y
CONFIG_NETFILTER_NETLINK_LOG=y
CONFIG_NF_CONNTRACK=y
CONFIG_NF_LOG_COMMON=y
# CONFIG_NF_LOG_NETDEV is not set
# CONFIG_NF_CONNTRACK_PROCFS is not set
# CONFIG_NF_CONNTRACK_FTP is not set
# CONFIG_NF_CONNTRACK_IRC is not set
# CONFIG_NF_CONNTRACK_NETBIOS_NS is not set
# CONFIG_NF_CONNTRACK_SIP is not set
CONFIG_NF_CT_NETLINK=y
# CONFIG_NETFILTER_NETLINK_GLUE_CT is not set
CONFIG_NF_NAT=y
CONFIG_NF_NAT_NEEDED=y
# CONFIG_NF_NAT_AMANDA is not set
# CONFIG_NF_NAT_FTP is not set
# CONFIG_NF_NAT_IRC is not set
# CONFIG_NF_NAT_SIP is not set
# CONFIG_NF_NAT_TFTP is not set
# CONFIG_NF_NAT_REDIRECT is not set
# CONFIG_NF_TABLES is not set
CONFIG_NETFILTER_XTABLES=y

#
# Xtables combined modules
#
CONFIG_NETFILTER_XT_MARK=y

#
# Xtables targets
#
CONFIG_NETFILTER_XT_TARGET_LOG=y
CONFIG_NETFILTER_XT_NAT=y
# CONFIG_NETFILTER_XT_TARGET_NETMAP is not set
CONFIG_NETFILTER_XT_TARGET_NFLOG=y
# CONFIG_NETFILTER_XT_TARGET_REDIRECT is not set
CONFIG_NETFILTER_XT_TARGET_TCPMSS=y

#
# Xtables matches
#
# CONFIG_NETFILTER_XT_MATCH_ADDRTYPE is not set
CONFIG_NETFILTER_XT_MATCH_CONNTRACK=y
CONFIG_NETFILTER_XT_MATCH_STATE=y
# CONFIG_IP_SET is not set
# CONFIG_IP_VS is not set

#
# IP: Netfilter Configuration
#
CONFIG_NF_DEFRAG_IPV4=y
CONFIG_NF_CONNTRACK_IPV4=y
# CONFIG_NF_SOCKET_IPV4 is not set
# CONFIG_NF_DUP_IPV4 is not set
CONFIG_NF_LOG_ARP=y
CONFIG_NF_LOG_IPV4=y
CONFIG_NF_REJECT_IPV4=y
CONFIG_NF_NAT_IPV4=y
CONFIG_NF_NAT_MASQUERADE_IPV4=y
# CONFIG_NF_NAT_PPTP is not set
# CONFIG_NF_NAT_H323 is not set
CONFIG_IP_NF_IPTABLES=y
CONFIG_IP_NF_FILTER=y
CONFIG_IP_NF_TARGET_REJECT=y
CONFIG_IP_NF_NAT=y
CONFIG_IP_NF_TARGET_MASQUERADE=y
CONFIG_IP_NF_MANGLE=y
# CONFIG_IP_NF_RAW is not set
# CONFIG_IP_DCCP is not set
# CONFIG_IP_SCTP is not set
# CONFIG_RDS is not set
# CONFIG_TIPC is not set
# CONFIG_ATM is not set
# CONFIG_L2TP is not set
# CONFIG_BRIDGE is not set
CONFIG_HAVE_NET_DSA=y
# CONFIG_NET_DSA is not set
# CONFIG_VLAN_8021Q is not set
# CONFIG_DECNET is not set
# CONFIG_LLC2 is not set
# CONFIG_IPX is not set
# CONFIG_ATALK is not set
# CONFIG_X25 is not set
# CONFIG_LAPB is not set
# CONFIG_PHONET is not set
# CONFIG_IEEE802154 is not set
CONFIG_NET_SCHED=y

#
# Queueing/Scheduling
#
# CONFIG_NET_SCH_CBQ is not set
# CONFIG_NET_SCH_HTB is not set
# CONFIG_NET_SCH_HFSC is not set
# CONFIG_NET_SCH_PRIO is not set
# CONFIG_NET_SCH_MULTIQ is not set
# CONFIG_NET_SCH_RED is not set
# CONFIG_NET_SCH_SFB is not set
# CONFIG_NET_SCH_SFQ is not set
# CONFIG_NET_SCH_TEQL is not set
# CONFIG_NET_SCH_TBF is not set
# CONFIG_NET_SCH_GRED is not set
# CONFIG_NET_SCH_DSMARK is not set
# CONFIG_NET_SCH_NETEM is not set
# CONFIG_NET_SCH_DRR is not set
# CONFIG_NET_SCH_MQPRIO is not set
# CONFIG_NET_SCH_CHOKE is not set
# CONFIG_NET_SCH_QFQ is not set
# CONFIG_NET_SCH_CODEL is not set
CONFIG_NET_SCH_FQ_CODEL=y
CONFIG_NET_SCH_FQ=y
# CONFIG_NET_SCH_HHF is not set
# CONFIG_NET_SCH_PIE is not set
# CONFIG_NET_SCH_PLUG is not set
CONFIG_NET_SCH_DEFAULT=y
CONFIG_DEFAULT_FQ=y
# CONFIG_DEFAULT_FQ_CODEL is not set
# CONFIG_DEFAULT_PFIFO_FAST is not set
CONFIG_DEFAULT_NET_SCH="fq"

#
# Classification
#
# CONFIG_NET_CLS_BASIC is not set
# CONFIG_NET_CLS_TCINDEX is not set
# CONFIG_NET_CLS_ROUTE4 is not set
# CONFIG_NET_CLS_FW is not set
# CONFIG_NET_CLS_U32 is not set
# CONFIG_NET_CLS_RSVP is not set
# CONFIG_NET_CLS_RSVP6 is not set
# CONFIG_NET_CLS_FLOW is not set
# CONFIG_NET_CLS_BPF is not set
# CONFIG_NET_CLS_FLOWER is not set
# CONFIG_NET_CLS_MATCHALL is not set
# CONFIG_NET_EMATCH is not set
# CONFIG_NET_CLS_ACT is not set
CONFIG_NET_SCH_FIFO=y
# CONFIG_DCB is not set
# CONFIG_BATMAN_ADV is not set
# CONFIG_OPENVSWITCH is not set
# CONFIG_VSOCKETS is not set
# CONFIG_NETLINK_DIAG is not set
# CONFIG_MPLS is not set
# CONFIG_NET_NSH is not set
# CONFIG_HSR is not set
# CONFIG_NET_SWITCHDEV is not set
# CONFIG_NET_L3_MASTER_DEV is not set
# CONFIG_NET_NCSI is not set
CONFIG_RPS=y
CONFIG_RFS_ACCEL=y
CONFIG_XPS=y
CONFIG_NET_RX_BUSY_POLL=y
CONFIG_BQL=y
CONFIG_NET_FLOW_LIMIT=y

#
# Network testing
#
# CONFIG_NET_PKTGEN is not set
# CONFIG_HAMRADIO is not set
# CONFIG_CAN is not set
# CONFIG_BT is not set
# CONFIG_AF_RXRPC is not set
# CONFIG_AF_KCM is not set
# CONFIG_STREAM_PARSER is not set
# CONFIG_WIRELESS is not set
# CONFIG_WIMAX is not set
# CONFIG_RFKILL is not set
CONFIG_NET_9P=y
CONFIG_NET_9P_VIRTIO=y
# CONFIG_NET_9P_DEBUG is not set
# CONFIG_CAIF is not set
# CONFIG_CEPH_LIB is not set
# CONFIG_NFC is not set
# CONFIG_PSAMPLE is not set
# CONFIG_NET_IFE is not set
# CONFIG_LWTUNNEL is not set
# CONFIG_DST_CACHE is not set
# CONFIG_GRO_CELLS is not set
# CONFIG_NET_DEVLINK is not set
CONFIG_MAY_USE_DEVLINK=y
CONFIG_HAVE_EBPF_JIT=y

#
# Device Drivers
#

#
# Generic Driver Options
#
# CONFIG_UEVENT_HELPER is not set
CONFIG_DEVTMPFS=y
CONFIG_DEVTMPFS_MOUNT=y
CONFIG_STANDALONE=y
# CONFIG_PREVENT_FIRMWARE_BUILD is not set
CONFIG_FW_LOADER=y
CONFIG_FIRMWARE_IN_KERNEL=y
CONFIG_EXTRA_FIRMWARE="amd-ucode/microcode_amd.bin radeon/R600_rlc.bin"
CONFIG_EXTRA_FIRMWARE_DIR="/lib/firmware"
# CONFIG_FW_LOADER_USER_HELPER_FALLBACK is not set
# CONFIG_ALLOW_DEV_COREDUMP is not set
# CONFIG_DEBUG_DRIVER is not set
# CONFIG_DEBUG_DEVRES is not set
# CONFIG_DEBUG_TEST_DRIVER_REMOVE is not set
# CONFIG_SYS_HYPERVISOR is not set
# CONFIG_GENERIC_CPU_DEVICES is not set
CONFIG_GENERIC_CPU_AUTOPROBE=y
CONFIG_REGMAP=y
CONFIG_REGMAP_I2C=y
CONFIG_DMA_SHARED_BUFFER=y
# CONFIG_DMA_FENCE_TRACE is not set

#
# Bus devices
#
# CONFIG_CONNECTOR is not set
# CONFIG_MTD is not set
# CONFIG_OF is not set
CONFIG_ARCH_MIGHT_HAVE_PC_PARPORT=y
# CONFIG_PARPORT is not set
CONFIG_PNP=y
CONFIG_PNP_DEBUG_MESSAGES=y

#
# Protocols
#
CONFIG_PNPACPI=y
CONFIG_BLK_DEV=y
# CONFIG_BLK_DEV_FD is not set
# CONFIG_BLK_DEV_PCIESSD_MTIP32XX is not set
# CONFIG_BLK_CPQ_CISS_DA is not set
# CONFIG_BLK_DEV_DAC960 is not set
# CONFIG_BLK_DEV_UMEM is not set
# CONFIG_BLK_DEV_COW_COMMON is not set
CONFIG_BLK_DEV_LOOP=y
CONFIG_BLK_DEV_LOOP_MIN_COUNT=1
# CONFIG_BLK_DEV_CRYPTOLOOP is not set
# CONFIG_BLK_DEV_DRBD is not set
# CONFIG_BLK_DEV_NBD is not set
# CONFIG_BLK_DEV_SKD is not set
# CONFIG_BLK_DEV_SX8 is not set
# CONFIG_BLK_DEV_RAM is not set
CONFIG_CDROM_PKTCDVD=y
CONFIG_CDROM_PKTCDVD_BUFFERS=8
# CONFIG_CDROM_PKTCDVD_WCACHE is not set
# CONFIG_ATA_OVER_ETH is not set
CONFIG_VIRTIO_BLK=y
# CONFIG_VIRTIO_BLK_SCSI is not set
# CONFIG_BLK_DEV_RBD is not set
# CONFIG_BLK_DEV_RSXX is not set
# CONFIG_BLK_DEV_NVME is not set
# CONFIG_NVME_FC is not set

#
# Misc devices
#
# CONFIG_SENSORS_LIS3LV02D is not set
# CONFIG_AD525X_DPOT is not set
# CONFIG_DUMMY_IRQ is not set
# CONFIG_IBM_ASM is not set
# CONFIG_PHANTOM is not set
# CONFIG_SGI_IOC4 is not set
# CONFIG_TIFM_CORE is not set
# CONFIG_ICS932S401 is not set
# CONFIG_ENCLOSURE_SERVICES is not set
# CONFIG_HP_ILO is not set
# CONFIG_APDS9802ALS is not set
# CONFIG_ISL29003 is not set
# CONFIG_ISL29020 is not set
# CONFIG_SENSORS_TSL2550 is not set
# CONFIG_SENSORS_BH1770 is not set
# CONFIG_SENSORS_APDS990X is not set
# CONFIG_HMC6352 is not set
# CONFIG_DS1682 is not set
# CONFIG_USB_SWITCH_FSA9480 is not set
# CONFIG_SRAM is not set
# CONFIG_PCI_ENDPOINT_TEST is not set
# CONFIG_C2PORT is not set

#
# EEPROM support
#
# CONFIG_EEPROM_AT24 is not set
# CONFIG_EEPROM_LEGACY is not set
# CONFIG_EEPROM_MAX6875 is not set
# CONFIG_EEPROM_93CX6 is not set
# CONFIG_EEPROM_IDT_89HPESX is not set
# CONFIG_CB710_CORE is not set

#
# Texas Instruments shared transport line discipline
#
# CONFIG_SENSORS_LIS3_I2C is not set

#
# Altera FPGA firmware download module
#
# CONFIG_ALTERA_STAPL is not set
# CONFIG_INTEL_MEI is not set
# CONFIG_INTEL_MEI_ME is not set
# CONFIG_INTEL_MEI_TXE is not set
# CONFIG_VMWARE_VMCI is not set

#
# Intel MIC Bus Driver
#
# CONFIG_INTEL_MIC_BUS is not set

#
# SCIF Bus Driver
#
# CONFIG_SCIF_BUS is not set

#
# VOP Bus Driver
#
# CONFIG_VOP_BUS is not set

#
# Intel MIC Host Driver
#

#
# Intel MIC Card Driver
#

#
# SCIF Driver
#

#
# Intel MIC Coprocessor State Management (COSM) Drivers
#

#
# VOP Driver
#
# CONFIG_GENWQE is not set
# CONFIG_ECHO is not set
# CONFIG_CXL_BASE is not set
# CONFIG_CXL_AFU_DRIVER_OPS is not set
# CONFIG_CXL_LIB is not set
CONFIG_HAVE_IDE=y
# CONFIG_IDE is not set

#
# SCSI device support
#
CONFIG_SCSI_MOD=y
# CONFIG_RAID_ATTRS is not set
CONFIG_SCSI=y
CONFIG_SCSI_DMA=y
# CONFIG_SCSI_NETLINK is not set
CONFIG_SCSI_MQ_DEFAULT=y
# CONFIG_SCSI_PROC_FS is not set

#
# SCSI support type (disk, tape, CD-ROM)
#
CONFIG_BLK_DEV_SD=y
# CONFIG_CHR_DEV_ST is not set
# CONFIG_CHR_DEV_OSST is not set
CONFIG_BLK_DEV_SR=y
# CONFIG_BLK_DEV_SR_VENDOR is not set
CONFIG_CHR_DEV_SG=y
# CONFIG_CHR_DEV_SCH is not set
# CONFIG_SCSI_CONSTANTS is not set
# CONFIG_SCSI_LOGGING is not set
# CONFIG_SCSI_SCAN_ASYNC is not set

#
# SCSI Transports
#
# CONFIG_SCSI_SPI_ATTRS is not set
# CONFIG_SCSI_FC_ATTRS is not set
# CONFIG_SCSI_ISCSI_ATTRS is not set
# CONFIG_SCSI_SAS_ATTRS is not set
# CONFIG_SCSI_SAS_LIBSAS is not set
# CONFIG_SCSI_SRP_ATTRS is not set
# CONFIG_SCSI_LOWLEVEL is not set
# CONFIG_SCSI_DH is not set
# CONFIG_SCSI_OSD_INITIATOR is not set
CONFIG_ATA=y
# CONFIG_ATA_NONSTANDARD is not set
CONFIG_ATA_VERBOSE_ERROR=y
# CONFIG_ATA_ACPI is not set
# CONFIG_SATA_PMP is not set

#
# Controllers with non-SFF native interface
#
CONFIG_SATA_AHCI=y
# CONFIG_SATA_AHCI_PLATFORM is not set
# CONFIG_SATA_INIC162X is not set
# CONFIG_SATA_ACARD_AHCI is not set
# CONFIG_SATA_SIL24 is not set
# CONFIG_ATA_SFF is not set
# CONFIG_MD is not set
# CONFIG_TARGET_CORE is not set
# CONFIG_FUSION is not set

#
# IEEE 1394 (FireWire) support
#
# CONFIG_FIREWIRE is not set
# CONFIG_FIREWIRE_NOSY is not set
# CONFIG_MACINTOSH_DRIVERS is not set
CONFIG_NETDEVICES=y
CONFIG_MII=y
CONFIG_NET_CORE=y
# CONFIG_BONDING is not set
CONFIG_DUMMY=y
# CONFIG_EQUALIZER is not set
# CONFIG_NET_FC is not set
# CONFIG_NET_TEAM is not set
# CONFIG_MACVLAN is not set
# CONFIG_VXLAN is not set
# CONFIG_MACSEC is not set
# CONFIG_NETCONSOLE is not set
# CONFIG_NETPOLL is not set
# CONFIG_NET_POLL_CONTROLLER is not set
CONFIG_TUN=y
# CONFIG_TUN_VNET_CROSS_LE is not set
# CONFIG_VETH is not set
CONFIG_VIRTIO_NET=y
# CONFIG_NLMON is not set
# CONFIG_ARCNET is not set

#
# CAIF transport drivers
#

#
# Distributed Switch Architecture drivers
#
CONFIG_ETHERNET=y
# CONFIG_NET_VENDOR_3COM is not set
# CONFIG_NET_VENDOR_ADAPTEC is not set
CONFIG_NET_VENDOR_AGERE=y
# CONFIG_ET131X is not set
# CONFIG_NET_VENDOR_ALACRITECH is not set
# CONFIG_NET_VENDOR_ALTEON is not set
# CONFIG_ALTERA_TSE is not set
# CONFIG_NET_VENDOR_AMAZON is not set
# CONFIG_NET_VENDOR_AMD is not set
# CONFIG_NET_VENDOR_AQUANTIA is not set
# CONFIG_NET_VENDOR_ARC is not set
CONFIG_NET_VENDOR_ATHEROS=y
# CONFIG_ATL2 is not set
# CONFIG_ATL1 is not set
CONFIG_ATL1E=y
# CONFIG_ATL1C is not set
# CONFIG_ALX is not set
# CONFIG_NET_VENDOR_AURORA is not set
# CONFIG_NET_CADENCE is not set
# CONFIG_NET_VENDOR_BROADCOM is not set
# CONFIG_NET_VENDOR_BROCADE is not set
# CONFIG_NET_VENDOR_CAVIUM is not set
# CONFIG_NET_VENDOR_CHELSIO is not set
# CONFIG_NET_VENDOR_CISCO is not set
# CONFIG_CX_ECAT is not set
# CONFIG_DNET is not set
# CONFIG_NET_VENDOR_DEC is not set
# CONFIG_NET_VENDOR_DLINK is not set
# CONFIG_NET_VENDOR_EMULEX is not set
# CONFIG_NET_VENDOR_EZCHIP is not set
# CONFIG_NET_VENDOR_EXAR is not set
# CONFIG_NET_VENDOR_HP is not set
# CONFIG_NET_VENDOR_HUAWEI is not set
# CONFIG_NET_VENDOR_INTEL is not set
# CONFIG_JME is not set
# CONFIG_NET_VENDOR_MARVELL is not set
# CONFIG_NET_VENDOR_MELLANOX is not set
# CONFIG_NET_VENDOR_MICREL is not set
# CONFIG_NET_VENDOR_MYRI is not set
# CONFIG_FEALNX is not set
# CONFIG_NET_VENDOR_NATSEMI is not set
CONFIG_NET_VENDOR_NETRONOME=y
# CONFIG_NFP is not set
# CONFIG_NET_VENDOR_NVIDIA is not set
# CONFIG_NET_VENDOR_OKI is not set
# CONFIG_ETHOC is not set
# CONFIG_NET_PACKET_ENGINE is not set
# CONFIG_NET_VENDOR_QLOGIC is not set
# CONFIG_NET_VENDOR_QUALCOMM is not set
# CONFIG_NET_VENDOR_REALTEK is not set
# CONFIG_NET_VENDOR_RENESAS is not set
# CONFIG_NET_VENDOR_RDC is not set
# CONFIG_NET_VENDOR_ROCKER is not set
# CONFIG_NET_VENDOR_SAMSUNG is not set
# CONFIG_NET_VENDOR_SEEQ is not set
# CONFIG_NET_VENDOR_SILAN is not set
# CONFIG_NET_VENDOR_SIS is not set
# CONFIG_NET_VENDOR_SOLARFLARE is not set
# CONFIG_NET_VENDOR_SMSC is not set
# CONFIG_NET_VENDOR_STMICRO is not set
# CONFIG_NET_VENDOR_SUN is not set
# CONFIG_NET_VENDOR_TEHUTI is not set
# CONFIG_NET_VENDOR_TI is not set
# CONFIG_NET_VENDOR_VIA is not set
# CONFIG_NET_VENDOR_WIZNET is not set
# CONFIG_NET_VENDOR_SYNOPSYS is not set
# CONFIG_FDDI is not set
# CONFIG_HIPPI is not set
# CONFIG_NET_SB1000 is not set
# CONFIG_MDIO_DEVICE is not set
# CONFIG_MDIO_BUS is not set
# CONFIG_PHYLIB is not set
# CONFIG_PPP is not set
# CONFIG_SLIP is not set
# CONFIG_USB_NET_DRIVERS is not set
# CONFIG_WLAN is not set

#
# Enable WiMAX (Networking options) to see the WiMAX drivers
#
# CONFIG_WAN is not set
# CONFIG_VMXNET3 is not set
# CONFIG_FUJITSU_ES is not set
# CONFIG_ISDN is not set
# CONFIG_NVM is not set

#
# Input device support
#
CONFIG_INPUT=y
# CONFIG_INPUT_FF_MEMLESS is not set
# CONFIG_INPUT_POLLDEV is not set
# CONFIG_INPUT_SPARSEKMAP is not set
# CONFIG_INPUT_MATRIXKMAP is not set

#
# Userland interfaces
#
CONFIG_INPUT_MOUSEDEV=y
# CONFIG_INPUT_MOUSEDEV_PSAUX is not set
CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024
CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768
# CONFIG_INPUT_JOYDEV is not set
CONFIG_INPUT_EVDEV=y
# CONFIG_INPUT_EVBUG is not set

#
# Input Device Drivers
#
CONFIG_INPUT_KEYBOARD=y
# CONFIG_KEYBOARD_ADP5588 is not set
# CONFIG_KEYBOARD_ADP5589 is not set
CONFIG_KEYBOARD_ATKBD=y
# CONFIG_KEYBOARD_QT1070 is not set
# CONFIG_KEYBOARD_QT2160 is not set
# CONFIG_KEYBOARD_DLINK_DIR685 is not set
# CONFIG_KEYBOARD_LKKBD is not set
# CONFIG_KEYBOARD_TCA6416 is not set
# CONFIG_KEYBOARD_TCA8418 is not set
# CONFIG_KEYBOARD_LM8333 is not set
# CONFIG_KEYBOARD_MAX7359 is not set
# CONFIG_KEYBOARD_MCS is not set
# CONFIG_KEYBOARD_MPR121 is not set
# CONFIG_KEYBOARD_NEWTON is not set
# CONFIG_KEYBOARD_OPENCORES is not set
# CONFIG_KEYBOARD_SAMSUNG is not set
# CONFIG_KEYBOARD_STOWAWAY is not set
# CONFIG_KEYBOARD_SUNKBD is not set
# CONFIG_KEYBOARD_XTKBD is not set
CONFIG_INPUT_MOUSE=y
# CONFIG_MOUSE_PS2 is not set
# CONFIG_MOUSE_SERIAL is not set
# CONFIG_MOUSE_APPLETOUCH is not set
# CONFIG_MOUSE_BCM5974 is not set
# CONFIG_MOUSE_CYAPA is not set
# CONFIG_MOUSE_ELAN_I2C is not set
# CONFIG_MOUSE_VSXXXAA is not set
# CONFIG_MOUSE_SYNAPTICS_I2C is not set
# CONFIG_MOUSE_SYNAPTICS_USB is not set
# CONFIG_INPUT_JOYSTICK is not set
# CONFIG_INPUT_TABLET is not set
# CONFIG_INPUT_TOUCHSCREEN is not set
# CONFIG_INPUT_MISC is not set
# CONFIG_RMI4_CORE is not set

#
# Hardware I/O ports
#
CONFIG_SERIO=y
CONFIG_ARCH_MIGHT_HAVE_PC_SERIO=y
CONFIG_SERIO_I8042=y
# CONFIG_SERIO_SERPORT is not set
# CONFIG_SERIO_CT82C710 is not set
# CONFIG_SERIO_PCIPS2 is not set
CONFIG_SERIO_LIBPS2=y
# CONFIG_SERIO_RAW is not set
# CONFIG_SERIO_ALTERA_PS2 is not set
# CONFIG_SERIO_PS2MULT is not set
# CONFIG_SERIO_ARC_PS2 is not set
# CONFIG_USERIO is not set
# CONFIG_GAMEPORT is not set

#
# Character devices
#
CONFIG_TTY=y
CONFIG_VT=y
CONFIG_CONSOLE_TRANSLATIONS=y
CONFIG_VT_CONSOLE=y
CONFIG_HW_CONSOLE=y
CONFIG_VT_HW_CONSOLE_BINDING=y
CONFIG_UNIX98_PTYS=y
# CONFIG_LEGACY_PTYS is not set
# CONFIG_SERIAL_NONSTANDARD is not set
# CONFIG_NOZOMI is not set
# CONFIG_N_GSM is not set
# CONFIG_TRACE_SINK is not set
CONFIG_DEVMEM=y
# CONFIG_DEVKMEM is not set

#
# Serial drivers
#
CONFIG_SERIAL_EARLYCON=y
CONFIG_SERIAL_8250=y
# CONFIG_SERIAL_8250_DEPRECATED_OPTIONS is not set
CONFIG_SERIAL_8250_PNP=y
# CONFIG_SERIAL_8250_FINTEK is not set
CONFIG_SERIAL_8250_CONSOLE=y
CONFIG_SERIAL_8250_PCI=y
CONFIG_SERIAL_8250_EXAR=y
CONFIG_SERIAL_8250_NR_UARTS=4
CONFIG_SERIAL_8250_RUNTIME_UARTS=4
# CONFIG_SERIAL_8250_EXTENDED is not set
# CONFIG_SERIAL_8250_FSL is not set
# CONFIG_SERIAL_8250_DW is not set
# CONFIG_SERIAL_8250_RT288X is not set
# CONFIG_SERIAL_8250_LPSS is not set
# CONFIG_SERIAL_8250_MID is not set
# CONFIG_SERIAL_8250_MOXA is not set

#
# Non-8250 serial port support
#
# CONFIG_SERIAL_UARTLITE is not set
CONFIG_SERIAL_CORE=y
CONFIG_SERIAL_CORE_CONSOLE=y
# CONFIG_SERIAL_JSM is not set
# CONFIG_SERIAL_SCCNXP is not set
# CONFIG_SERIAL_SC16IS7XX is not set
# CONFIG_SERIAL_ALTERA_JTAGUART is not set
# CONFIG_SERIAL_ALTERA_UART is not set
# CONFIG_SERIAL_ARC is not set
# CONFIG_SERIAL_RP2 is not set
# CONFIG_SERIAL_FSL_LPUART is not set
# CONFIG_SERIAL_DEV_BUS is not set
# CONFIG_TTY_PRINTK is not set
CONFIG_HVC_DRIVER=y
CONFIG_VIRTIO_CONSOLE=y
# CONFIG_IPMI_HANDLER is not set
# CONFIG_HW_RANDOM is not set
# CONFIG_NVRAM is not set
# CONFIG_R3964 is not set
# CONFIG_APPLICOM is not set
# CONFIG_MWAVE is not set
# CONFIG_RAW_DRIVER is not set
CONFIG_HPET=y
CONFIG_HPET_MMAP=y
CONFIG_HPET_MMAP_DEFAULT=y
# CONFIG_HANGCHECK_TIMER is not set
# CONFIG_TCG_TPM is not set
# CONFIG_TELCLOCK is not set
CONFIG_DEVPORT=y
# CONFIG_XILLYBUS is not set

#
# I2C support
#
CONFIG_I2C=y
# CONFIG_ACPI_I2C_OPREGION is not set
CONFIG_I2C_BOARDINFO=y
CONFIG_I2C_COMPAT=y
CONFIG_I2C_CHARDEV=y
# CONFIG_I2C_MUX is not set
CONFIG_I2C_HELPER_AUTO=y
CONFIG_I2C_ALGOBIT=y

#
# I2C Hardware Bus support
#

#
# PC SMBus host controller drivers
#
# CONFIG_I2C_ALI1535 is not set
# CONFIG_I2C_ALI1563 is not set
# CONFIG_I2C_ALI15X3 is not set
# CONFIG_I2C_AMD756 is not set
# CONFIG_I2C_AMD8111 is not set
# CONFIG_I2C_I801 is not set
# CONFIG_I2C_ISCH is not set
# CONFIG_I2C_ISMT is not set
# CONFIG_I2C_PIIX4 is not set
# CONFIG_I2C_NFORCE2 is not set
# CONFIG_I2C_SIS5595 is not set
# CONFIG_I2C_SIS630 is not set
# CONFIG_I2C_SIS96X is not set
# CONFIG_I2C_VIA is not set
# CONFIG_I2C_VIAPRO is not set

#
# ACPI drivers
#
# CONFIG_I2C_SCMI is not set

#
# I2C system bus drivers (mostly embedded / system-on-chip)
#
# CONFIG_I2C_DESIGNWARE_PLATFORM is not set
# CONFIG_I2C_DESIGNWARE_PCI is not set
# CONFIG_I2C_EMEV2 is not set
# CONFIG_I2C_OCORES is not set
# CONFIG_I2C_PCA_PLATFORM is not set
# CONFIG_I2C_PXA_PCI is not set
# CONFIG_I2C_SIMTEC is not set
# CONFIG_I2C_XILINX is not set

#
# External I2C/SMBus adapter drivers
#
# CONFIG_I2C_DIOLAN_U2C is not set
# CONFIG_I2C_PARPORT_LIGHT is not set
# CONFIG_I2C_ROBOTFUZZ_OSIF is not set
# CONFIG_I2C_TAOS_EVM is not set
# CONFIG_I2C_TINY_USB is not set

#
# Other I2C/SMBus bus drivers
#
# CONFIG_I2C_MLXCPLD is not set
# CONFIG_I2C_SLAVE is not set
# CONFIG_I2C_DEBUG_CORE is not set
# CONFIG_I2C_DEBUG_ALGO is not set
# CONFIG_I2C_DEBUG_BUS is not set
# CONFIG_SPI is not set
# CONFIG_SPMI is not set
# CONFIG_HSI is not set
# CONFIG_PPS is not set

#
# PTP clock support
#
# CONFIG_PTP_1588_CLOCK is not set

#
# Enable PHYLIB and NETWORK_PHY_TIMESTAMPING to see the additional clocks.
#
# CONFIG_GPIOLIB is not set
# CONFIG_W1 is not set
# CONFIG_POWER_AVS is not set
# CONFIG_POWER_RESET is not set
CONFIG_POWER_SUPPLY=y
# CONFIG_POWER_SUPPLY_DEBUG is not set
# CONFIG_PDA_POWER is not set
# CONFIG_TEST_POWER is not set
# CONFIG_BATTERY_DS2780 is not set
# CONFIG_BATTERY_DS2781 is not set
# CONFIG_BATTERY_DS2782 is not set
# CONFIG_BATTERY_SBS is not set
# CONFIG_CHARGER_SBS is not set
# CONFIG_BATTERY_BQ27XXX is not set
# CONFIG_BATTERY_MAX17040 is not set
# CONFIG_BATTERY_MAX17042 is not set
# CONFIG_CHARGER_MAX8903 is not set
# CONFIG_CHARGER_LP8727 is not set
# CONFIG_CHARGER_BQ2415X is not set
# CONFIG_CHARGER_SMB347 is not set
# CONFIG_BATTERY_GAUGE_LTC2941 is not set
CONFIG_HWMON=y
# CONFIG_HWMON_VID is not set
# CONFIG_HWMON_DEBUG_CHIP is not set

#
# Native drivers
#
# CONFIG_SENSORS_ABITUGURU is not set
# CONFIG_SENSORS_ABITUGURU3 is not set
# CONFIG_SENSORS_AD7414 is not set
# CONFIG_SENSORS_AD7418 is not set
# CONFIG_SENSORS_ADM1021 is not set
# CONFIG_SENSORS_ADM1025 is not set
# CONFIG_SENSORS_ADM1026 is not set
# CONFIG_SENSORS_ADM1029 is not set
# CONFIG_SENSORS_ADM1031 is not set
# CONFIG_SENSORS_ADM9240 is not set
# CONFIG_SENSORS_ADT7410 is not set
# CONFIG_SENSORS_ADT7411 is not set
# CONFIG_SENSORS_ADT7462 is not set
# CONFIG_SENSORS_ADT7470 is not set
# CONFIG_SENSORS_ADT7475 is not set
# CONFIG_SENSORS_ASC7621 is not set
# CONFIG_SENSORS_K8TEMP is not set
CONFIG_SENSORS_K10TEMP=y
# CONFIG_SENSORS_FAM15H_POWER is not set
# CONFIG_SENSORS_APPLESMC is not set
# CONFIG_SENSORS_ASB100 is not set
# CONFIG_SENSORS_ASPEED is not set
# CONFIG_SENSORS_ATXP1 is not set
# CONFIG_SENSORS_DS620 is not set
# CONFIG_SENSORS_DS1621 is not set
# CONFIG_SENSORS_DELL_SMM is not set
# CONFIG_SENSORS_I5K_AMB is not set
# CONFIG_SENSORS_F71805F is not set
# CONFIG_SENSORS_F71882FG is not set
# CONFIG_SENSORS_F75375S is not set
# CONFIG_SENSORS_FSCHMD is not set
# CONFIG_SENSORS_GL518SM is not set
# CONFIG_SENSORS_GL520SM is not set
# CONFIG_SENSORS_G760A is not set
# CONFIG_SENSORS_G762 is not set
# CONFIG_SENSORS_HIH6130 is not set
# CONFIG_SENSORS_I5500 is not set
# CONFIG_SENSORS_CORETEMP is not set
# CONFIG_SENSORS_IT87 is not set
# CONFIG_SENSORS_JC42 is not set
# CONFIG_SENSORS_POWR1220 is not set
# CONFIG_SENSORS_LINEAGE is not set
# CONFIG_SENSORS_LTC2945 is not set
# CONFIG_SENSORS_LTC2990 is not set
# CONFIG_SENSORS_LTC4151 is not set
# CONFIG_SENSORS_LTC4215 is not set
# CONFIG_SENSORS_LTC4222 is not set
# CONFIG_SENSORS_LTC4245 is not set
# CONFIG_SENSORS_LTC4260 is not set
# CONFIG_SENSORS_LTC4261 is not set
# CONFIG_SENSORS_MAX16065 is not set
# CONFIG_SENSORS_MAX1619 is not set
# CONFIG_SENSORS_MAX1668 is not set
# CONFIG_SENSORS_MAX197 is not set
# CONFIG_SENSORS_MAX6639 is not set
# CONFIG_SENSORS_MAX6642 is not set
# CONFIG_SENSORS_MAX6650 is not set
# CONFIG_SENSORS_MAX6697 is not set
# CONFIG_SENSORS_MAX31790 is not set
# CONFIG_SENSORS_MCP3021 is not set
# CONFIG_SENSORS_TC654 is not set
# CONFIG_SENSORS_LM63 is not set
# CONFIG_SENSORS_LM73 is not set
# CONFIG_SENSORS_LM75 is not set
# CONFIG_SENSORS_LM77 is not set
# CONFIG_SENSORS_LM78 is not set
# CONFIG_SENSORS_LM80 is not set
# CONFIG_SENSORS_LM83 is not set
# CONFIG_SENSORS_LM85 is not set
# CONFIG_SENSORS_LM87 is not set
# CONFIG_SENSORS_LM90 is not set
# CONFIG_SENSORS_LM92 is not set
# CONFIG_SENSORS_LM93 is not set
# CONFIG_SENSORS_LM95234 is not set
# CONFIG_SENSORS_LM95241 is not set
# CONFIG_SENSORS_LM95245 is not set
# CONFIG_SENSORS_PC87360 is not set
# CONFIG_SENSORS_PC87427 is not set
# CONFIG_SENSORS_NTC_THERMISTOR is not set
# CONFIG_SENSORS_NCT6683 is not set
# CONFIG_SENSORS_NCT6775 is not set
# CONFIG_SENSORS_NCT7802 is not set
# CONFIG_SENSORS_NCT7904 is not set
# CONFIG_SENSORS_PCF8591 is not set
# CONFIG_PMBUS is not set
# CONFIG_SENSORS_SHT21 is not set
# CONFIG_SENSORS_SHT3x is not set
# CONFIG_SENSORS_SHTC1 is not set
# CONFIG_SENSORS_SIS5595 is not set
# CONFIG_SENSORS_DME1737 is not set
# CONFIG_SENSORS_EMC1403 is not set
# CONFIG_SENSORS_EMC2103 is not set
# CONFIG_SENSORS_EMC6W201 is not set
# CONFIG_SENSORS_SMSC47M1 is not set
# CONFIG_SENSORS_SMSC47M192 is not set
# CONFIG_SENSORS_SMSC47B397 is not set
# CONFIG_SENSORS_SCH56XX_COMMON is not set
# CONFIG_SENSORS_STTS751 is not set
# CONFIG_SENSORS_SMM665 is not set
# CONFIG_SENSORS_ADC128D818 is not set
# CONFIG_SENSORS_ADS1015 is not set
# CONFIG_SENSORS_ADS7828 is not set
# CONFIG_SENSORS_AMC6821 is not set
# CONFIG_SENSORS_INA209 is not set
# CONFIG_SENSORS_INA2XX is not set
# CONFIG_SENSORS_INA3221 is not set
# CONFIG_SENSORS_TC74 is not set
# CONFIG_SENSORS_THMC50 is not set
# CONFIG_SENSORS_TMP102 is not set
# CONFIG_SENSORS_TMP103 is not set
# CONFIG_SENSORS_TMP108 is not set
# CONFIG_SENSORS_TMP401 is not set
# CONFIG_SENSORS_TMP421 is not set
# CONFIG_SENSORS_VIA_CPUTEMP is not set
# CONFIG_SENSORS_VIA686A is not set
# CONFIG_SENSORS_VT1211 is not set
# CONFIG_SENSORS_VT8231 is not set
# CONFIG_SENSORS_W83781D is not set
# CONFIG_SENSORS_W83791D is not set
# CONFIG_SENSORS_W83792D is not set
# CONFIG_SENSORS_W83793 is not set
# CONFIG_SENSORS_W83795 is not set
# CONFIG_SENSORS_W83L785TS is not set
# CONFIG_SENSORS_W83L786NG is not set
# CONFIG_SENSORS_W83627HF is not set
# CONFIG_SENSORS_W83627EHF is not set

#
# ACPI drivers
#
# CONFIG_SENSORS_ACPI_POWER is not set
CONFIG_SENSORS_ATK0110=y
CONFIG_THERMAL=y
CONFIG_THERMAL_EMERGENCY_POWEROFF_DELAY_MS=0
CONFIG_THERMAL_HWMON=y
# CONFIG_THERMAL_WRITABLE_TRIPS is not set
CONFIG_THERMAL_DEFAULT_GOV_STEP_WISE=y
# CONFIG_THERMAL_DEFAULT_GOV_FAIR_SHARE is not set
# CONFIG_THERMAL_DEFAULT_GOV_USER_SPACE is not set
# CONFIG_THERMAL_DEFAULT_GOV_POWER_ALLOCATOR is not set
# CONFIG_THERMAL_GOV_FAIR_SHARE is not set
CONFIG_THERMAL_GOV_STEP_WISE=y
# CONFIG_THERMAL_GOV_BANG_BANG is not set
# CONFIG_THERMAL_GOV_USER_SPACE is not set
# CONFIG_THERMAL_GOV_POWER_ALLOCATOR is not set
# CONFIG_THERMAL_EMULATION is not set
# CONFIG_INTEL_SOC_DTS_THERMAL is not set

#
# ACPI INT340X thermal drivers
#
# CONFIG_INT340X_THERMAL is not set
# CONFIG_INTEL_PCH_THERMAL is not set
# CONFIG_WATCHDOG is not set
CONFIG_SSB_POSSIBLE=y

#
# Sonics Silicon Backplane
#
# CONFIG_SSB is not set
CONFIG_BCMA_POSSIBLE=y
# CONFIG_BCMA is not set

#
# Multifunction device drivers
#
# CONFIG_MFD_CORE is not set
# CONFIG_MFD_AS3711 is not set
# CONFIG_PMIC_ADP5520 is not set
# CONFIG_MFD_BCM590XX is not set
# CONFIG_MFD_BD9571MWV is not set
# CONFIG_MFD_AXP20X_I2C is not set
# CONFIG_MFD_CROS_EC is not set
# CONFIG_PMIC_DA903X is not set
# CONFIG_MFD_DA9052_I2C is not set
# CONFIG_MFD_DA9055 is not set
# CONFIG_MFD_DA9062 is not set
# CONFIG_MFD_DA9063 is not set
# CONFIG_MFD_DA9150 is not set
# CONFIG_MFD_DLN2 is not set
# CONFIG_MFD_MC13XXX_I2C is not set
# CONFIG_HTC_PASIC3 is not set
# CONFIG_MFD_INTEL_QUARK_I2C_GPIO is not set
# CONFIG_LPC_ICH is not set
# CONFIG_LPC_SCH is not set
# CONFIG_INTEL_SOC_PMIC_CHTWC is not set
# CONFIG_MFD_INTEL_LPSS_ACPI is not set
# CONFIG_MFD_INTEL_LPSS_PCI is not set
# CONFIG_MFD_JANZ_CMODIO is not set
# CONFIG_MFD_KEMPLD is not set
# CONFIG_MFD_88PM800 is not set
# CONFIG_MFD_88PM805 is not set
# CONFIG_MFD_88PM860X is not set
# CONFIG_MFD_MAX14577 is not set
# CONFIG_MFD_MAX77693 is not set
# CONFIG_MFD_MAX77843 is not set
# CONFIG_MFD_MAX8907 is not set
# CONFIG_MFD_MAX8925 is not set
# CONFIG_MFD_MAX8997 is not set
# CONFIG_MFD_MAX8998 is not set
# CONFIG_MFD_MT6397 is not set
# CONFIG_MFD_MENF21BMC is not set
# CONFIG_MFD_VIPERBOARD is not set
# CONFIG_MFD_RETU is not set
# CONFIG_MFD_PCF50633 is not set
# CONFIG_MFD_RDC321X is not set
# CONFIG_MFD_RTSX_PCI is not set
# CONFIG_MFD_RT5033 is not set
# CONFIG_MFD_RTSX_USB is not set
# CONFIG_MFD_RC5T583 is not set
# CONFIG_MFD_SEC_CORE is not set
# CONFIG_MFD_SI476X_CORE is not set
# CONFIG_MFD_SM501 is not set
# CONFIG_MFD_SKY81452 is not set
# CONFIG_MFD_SMSC is not set
# CONFIG_ABX500_CORE is not set
# CONFIG_MFD_SYSCON is not set
# CONFIG_MFD_TI_AM335X_TSCADC is not set
# CONFIG_MFD_LP3943 is not set
# CONFIG_MFD_LP8788 is not set
# CONFIG_MFD_TI_LMU is not set
# CONFIG_MFD_PALMAS is not set
# CONFIG_TPS6105X is not set
# CONFIG_TPS6507X is not set
# CONFIG_MFD_TPS65086 is not set
# CONFIG_MFD_TPS65090 is not set
# CONFIG_MFD_TPS65217 is not set
# CONFIG_MFD_TPS68470 is not set
# CONFIG_MFD_TI_LP873X is not set
# CONFIG_MFD_TPS65218 is not set
# CONFIG_MFD_TPS6586X is not set
# CONFIG_MFD_TPS65912_I2C is not set
# CONFIG_MFD_TPS80031 is not set
# CONFIG_TWL4030_CORE is not set
# CONFIG_TWL6040_CORE is not set
# CONFIG_MFD_WL1273_CORE is not set
# CONFIG_MFD_LM3533 is not set
# CONFIG_MFD_TMIO is not set
# CONFIG_MFD_VX855 is not set
# CONFIG_MFD_ARIZONA_I2C is not set
# CONFIG_MFD_WM8400 is not set
# CONFIG_MFD_WM831X_I2C is not set
# CONFIG_MFD_WM8350_I2C is not set
# CONFIG_MFD_WM8994 is not set
# CONFIG_REGULATOR is not set
# CONFIG_RC_CORE is not set
# CONFIG_MEDIA_SUPPORT is not set

#
# Graphics support
#
# CONFIG_AGP is not set
# CONFIG_VGA_ARB is not set
# CONFIG_VGA_SWITCHEROO is not set
CONFIG_DRM=y
# CONFIG_DRM_DP_AUX_CHARDEV is not set
# CONFIG_DRM_DEBUG_MM is not set
# CONFIG_DRM_DEBUG_MM_SELFTEST is not set
CONFIG_DRM_KMS_HELPER=y
CONFIG_DRM_KMS_FB_HELPER=y
CONFIG_DRM_FBDEV_EMULATION=y
CONFIG_DRM_FBDEV_OVERALLOC=100
# CONFIG_DRM_LOAD_EDID_FIRMWARE is not set
CONFIG_DRM_TTM=y

#
# I2C encoder or helper chips
#
# CONFIG_DRM_I2C_CH7006 is not set
# CONFIG_DRM_I2C_SIL164 is not set
# CONFIG_DRM_I2C_NXP_TDA998X is not set
CONFIG_DRM_RADEON=y
# CONFIG_DRM_RADEON_USERPTR is not set
# CONFIG_DRM_AMDGPU is not set

#
# ACP (Audio CoProcessor) Configuration
#
# CONFIG_DRM_NOUVEAU is not set
# CONFIG_DRM_I915 is not set
# CONFIG_DRM_VGEM is not set
# CONFIG_DRM_VMWGFX is not set
# CONFIG_DRM_GMA500 is not set
# CONFIG_DRM_UDL is not set
# CONFIG_DRM_AST is not set
# CONFIG_DRM_MGAG200 is not set
# CONFIG_DRM_CIRRUS_QEMU is not set
# CONFIG_DRM_QXL is not set
# CONFIG_DRM_BOCHS is not set
# CONFIG_DRM_VIRTIO_GPU is not set
CONFIG_DRM_PANEL=y

#
# Display Panels
#
CONFIG_DRM_BRIDGE=y
CONFIG_DRM_PANEL_BRIDGE=y

#
# Display Interface Bridges
#
# CONFIG_DRM_ANALOGIX_ANX78XX is not set
# CONFIG_DRM_HISI_HIBMC is not set
# CONFIG_DRM_TINYDRM is not set
# CONFIG_DRM_LEGACY is not set
# CONFIG_DRM_LIB_RANDOM is not set

#
# Frame buffer Devices
#
CONFIG_FB=y
# CONFIG_FIRMWARE_EDID is not set
CONFIG_FB_CMDLINE=y
CONFIG_FB_NOTIFY=y
# CONFIG_FB_DDC is not set
# CONFIG_FB_BOOT_VESA_SUPPORT is not set
CONFIG_FB_CFB_FILLRECT=y
CONFIG_FB_CFB_COPYAREA=y
CONFIG_FB_CFB_IMAGEBLIT=y
# CONFIG_FB_CFB_REV_PIXELS_IN_BYTE is not set
CONFIG_FB_SYS_FILLRECT=y
CONFIG_FB_SYS_COPYAREA=y
CONFIG_FB_SYS_IMAGEBLIT=y
# CONFIG_FB_PROVIDE_GET_FB_UNMAPPED_AREA is not set
# CONFIG_FB_FOREIGN_ENDIAN is not set
CONFIG_FB_SYS_FOPS=y
CONFIG_FB_DEFERRED_IO=y
# CONFIG_FB_SVGALIB is not set
# CONFIG_FB_MACMODES is not set
# CONFIG_FB_BACKLIGHT is not set
CONFIG_FB_MODE_HELPERS=y
# CONFIG_FB_TILEBLITTING is not set

#
# Frame buffer hardware drivers
#
# CONFIG_FB_CIRRUS is not set
# CONFIG_FB_PM2 is not set
# CONFIG_FB_CYBER2000 is not set
# CONFIG_FB_ARC is not set
# CONFIG_FB_ASILIANT is not set
# CONFIG_FB_IMSTT is not set
# CONFIG_FB_VGA16 is not set
# CONFIG_FB_VESA is not set
# CONFIG_FB_N411 is not set
# CONFIG_FB_HGA is not set
# CONFIG_FB_OPENCORES is not set
# CONFIG_FB_S1D13XXX is not set
# CONFIG_FB_NVIDIA is not set
# CONFIG_FB_RIVA is not set
# CONFIG_FB_I740 is not set
# CONFIG_FB_LE80578 is not set
# CONFIG_FB_MATROX is not set
# CONFIG_FB_RADEON is not set
# CONFIG_FB_ATY128 is not set
# CONFIG_FB_ATY is not set
# CONFIG_FB_S3 is not set
# CONFIG_FB_SAVAGE is not set
# CONFIG_FB_SIS is not set
# CONFIG_FB_NEOMAGIC is not set
# CONFIG_FB_KYRO is not set
# CONFIG_FB_3DFX is not set
# CONFIG_FB_VOODOO1 is not set
# CONFIG_FB_VT8623 is not set
# CONFIG_FB_TRIDENT is not set
# CONFIG_FB_ARK is not set
# CONFIG_FB_PM3 is not set
# CONFIG_FB_CARMINE is not set
# CONFIG_FB_SMSCUFX is not set
# CONFIG_FB_UDL is not set
# CONFIG_FB_IBM_GXT4500 is not set
# CONFIG_FB_VIRTUAL is not set
# CONFIG_FB_METRONOME is not set
# CONFIG_FB_MB862XX is not set
# CONFIG_FB_BROADSHEET is not set
# CONFIG_FB_AUO_K190X is not set
# CONFIG_FB_SIMPLE is not set
# CONFIG_FB_SM712 is not set
CONFIG_BACKLIGHT_LCD_SUPPORT=y
# CONFIG_LCD_CLASS_DEVICE is not set
CONFIG_BACKLIGHT_CLASS_DEVICE=y
# CONFIG_BACKLIGHT_GENERIC is not set
# CONFIG_BACKLIGHT_APPLE is not set
# CONFIG_BACKLIGHT_PM8941_WLED is not set
# CONFIG_BACKLIGHT_SAHARA is not set
# CONFIG_BACKLIGHT_ADP8860 is not set
# CONFIG_BACKLIGHT_ADP8870 is not set
# CONFIG_BACKLIGHT_LM3639 is not set
# CONFIG_BACKLIGHT_LV5207LP is not set
# CONFIG_BACKLIGHT_BD6107 is not set
# CONFIG_BACKLIGHT_ARCXCNN is not set
# CONFIG_VGASTATE is not set
CONFIG_HDMI=y

#
# Console display driver support
#
CONFIG_VGA_CONSOLE=y
CONFIG_VGACON_SOFT_SCROLLBACK=y
CONFIG_VGACON_SOFT_SCROLLBACK_SIZE=64
# CONFIG_VGACON_SOFT_SCROLLBACK_PERSISTENT_ENABLE_BY_DEFAULT is not set
CONFIG_DUMMY_CONSOLE=y
CONFIG_DUMMY_CONSOLE_COLUMNS=80
CONFIG_DUMMY_CONSOLE_ROWS=25
CONFIG_FRAMEBUFFER_CONSOLE=y
CONFIG_FRAMEBUFFER_CONSOLE_DETECT_PRIMARY=y
CONFIG_FRAMEBUFFER_CONSOLE_ROTATION=y
# CONFIG_LOGO is not set
CONFIG_SOUND=y
CONFIG_SOUND_OSS_CORE=y
CONFIG_SOUND_OSS_CORE_PRECLAIM=y
CONFIG_SND=y
CONFIG_SND_TIMER=y
CONFIG_SND_PCM=y
CONFIG_SND_HWDEP=y
CONFIG_SND_SEQ_DEVICE=y
CONFIG_SND_RAWMIDI=y
CONFIG_SND_JACK=y
CONFIG_SND_JACK_INPUT_DEV=y
CONFIG_SND_OSSEMUL=y
CONFIG_SND_MIXER_OSS=y
CONFIG_SND_PCM_OSS=y
CONFIG_SND_PCM_OSS_PLUGINS=y
CONFIG_SND_PCM_TIMER=y
CONFIG_SND_HRTIMER=y
CONFIG_SND_DYNAMIC_MINORS=y
CONFIG_SND_MAX_CARDS=4
CONFIG_SND_SUPPORT_OLD_API=y
CONFIG_SND_PROC_FS=y
# CONFIG_SND_VERBOSE_PROCFS is not set
# CONFIG_SND_VERBOSE_PRINTK is not set
# CONFIG_SND_DEBUG is not set
CONFIG_SND_VMASTER=y
CONFIG_SND_DMA_SGBUF=y
CONFIG_SND_SEQUENCER=y
CONFIG_SND_SEQ_DUMMY=y
CONFIG_SND_SEQUENCER_OSS=y
CONFIG_SND_SEQ_HRTIMER_DEFAULT=y
CONFIG_SND_SEQ_MIDI_EVENT=y
CONFIG_SND_SEQ_MIDI=y
# CONFIG_SND_OPL3_LIB_SEQ is not set
# CONFIG_SND_OPL4_LIB_SEQ is not set
# CONFIG_SND_DRIVERS is not set
CONFIG_SND_PCI=y
# CONFIG_SND_AD1889 is not set
# CONFIG_SND_ALS300 is not set
# CONFIG_SND_ALS4000 is not set
# CONFIG_SND_ALI5451 is not set
# CONFIG_SND_ASIHPI is not set
# CONFIG_SND_ATIIXP is not set
# CONFIG_SND_ATIIXP_MODEM is not set
# CONFIG_SND_AU8810 is not set
# CONFIG_SND_AU8820 is not set
# CONFIG_SND_AU8830 is not set
# CONFIG_SND_AW2 is not set
# CONFIG_SND_AZT3328 is not set
# CONFIG_SND_BT87X is not set
# CONFIG_SND_CA0106 is not set
# CONFIG_SND_CMIPCI is not set
# CONFIG_SND_OXYGEN is not set
# CONFIG_SND_CS4281 is not set
# CONFIG_SND_CS46XX is not set
# CONFIG_SND_CTXFI is not set
# CONFIG_SND_DARLA20 is not set
# CONFIG_SND_GINA20 is not set
# CONFIG_SND_LAYLA20 is not set
# CONFIG_SND_DARLA24 is not set
# CONFIG_SND_GINA24 is not set
# CONFIG_SND_LAYLA24 is not set
# CONFIG_SND_MONA is not set
# CONFIG_SND_MIA is not set
# CONFIG_SND_ECHO3G is not set
# CONFIG_SND_INDIGO is not set
# CONFIG_SND_INDIGOIO is not set
# CONFIG_SND_INDIGODJ is not set
# CONFIG_SND_INDIGOIOX is not set
# CONFIG_SND_INDIGODJX is not set
# CONFIG_SND_EMU10K1 is not set
# CONFIG_SND_EMU10K1_SEQ is not set
# CONFIG_SND_EMU10K1X is not set
# CONFIG_SND_ENS1370 is not set
# CONFIG_SND_ENS1371 is not set
# CONFIG_SND_ES1938 is not set
# CONFIG_SND_ES1968 is not set
# CONFIG_SND_FM801 is not set
# CONFIG_SND_HDSP is not set
# CONFIG_SND_HDSPM is not set
# CONFIG_SND_ICE1712 is not set
# CONFIG_SND_ICE1724 is not set
# CONFIG_SND_INTEL8X0 is not set
# CONFIG_SND_INTEL8X0M is not set
# CONFIG_SND_KORG1212 is not set
# CONFIG_SND_LOLA is not set
# CONFIG_SND_LX6464ES is not set
# CONFIG_SND_MAESTRO3 is not set
# CONFIG_SND_MIXART is not set
# CONFIG_SND_NM256 is not set
# CONFIG_SND_PCXHR is not set
# CONFIG_SND_RIPTIDE is not set
# CONFIG_SND_RME32 is not set
# CONFIG_SND_RME96 is not set
# CONFIG_SND_RME9652 is not set
# CONFIG_SND_SE6X is not set
# CONFIG_SND_SONICVIBES is not set
# CONFIG_SND_TRIDENT is not set
# CONFIG_SND_VIA82XX is not set
# CONFIG_SND_VIA82XX_MODEM is not set
# CONFIG_SND_VIRTUOSO is not set
# CONFIG_SND_VX222 is not set
# CONFIG_SND_YMFPCI is not set

#
# HD-Audio
#
CONFIG_SND_HDA=y
CONFIG_SND_HDA_INTEL=y
CONFIG_SND_HDA_HWDEP=y
# CONFIG_SND_HDA_RECONFIG is not set
# CONFIG_SND_HDA_INPUT_BEEP is not set
# CONFIG_SND_HDA_PATCH_LOADER is not set
# CONFIG_SND_HDA_CODEC_REALTEK is not set
# CONFIG_SND_HDA_CODEC_ANALOG is not set
# CONFIG_SND_HDA_CODEC_SIGMATEL is not set
CONFIG_SND_HDA_CODEC_VIA=y
# CONFIG_SND_HDA_CODEC_HDMI is not set
# CONFIG_SND_HDA_CODEC_CIRRUS is not set
# CONFIG_SND_HDA_CODEC_CONEXANT is not set
# CONFIG_SND_HDA_CODEC_CA0110 is not set
# CONFIG_SND_HDA_CODEC_CA0132 is not set
# CONFIG_SND_HDA_CODEC_CMEDIA is not set
# CONFIG_SND_HDA_CODEC_SI3054 is not set
CONFIG_SND_HDA_GENERIC=y
CONFIG_SND_HDA_POWER_SAVE_DEFAULT=60
CONFIG_SND_HDA_CORE=y
CONFIG_SND_HDA_PREALLOC_SIZE=64
CONFIG_SND_USB=y
CONFIG_SND_USB_AUDIO=y
# CONFIG_SND_USB_UA101 is not set
# CONFIG_SND_USB_USX2Y is not set
# CONFIG_SND_USB_CAIAQ is not set
# CONFIG_SND_USB_US122L is not set
# CONFIG_SND_USB_6FIRE is not set
# CONFIG_SND_USB_HIFACE is not set
# CONFIG_SND_BCD2000 is not set
# CONFIG_SND_USB_POD is not set
# CONFIG_SND_USB_PODHD is not set
# CONFIG_SND_USB_TONEPORT is not set
# CONFIG_SND_USB_VARIAX is not set
# CONFIG_SND_SOC is not set
# CONFIG_SND_X86 is not set

#
# HID support
#
CONFIG_HID=y
# CONFIG_HID_BATTERY_STRENGTH is not set
CONFIG_HIDRAW=y
# CONFIG_UHID is not set
CONFIG_HID_GENERIC=y

#
# Special HID drivers
#
# CONFIG_HID_A4TECH is not set
# CONFIG_HID_ACCUTOUCH is not set
# CONFIG_HID_ACRUX is not set
# CONFIG_HID_APPLE is not set
# CONFIG_HID_APPLEIR is not set
# CONFIG_HID_AUREAL is not set
# CONFIG_HID_BELKIN is not set
# CONFIG_HID_BETOP_FF is not set
# CONFIG_HID_CHERRY is not set
# CONFIG_HID_CHICONY is not set
# CONFIG_HID_PRODIKEYS is not set
# CONFIG_HID_CMEDIA is not set
# CONFIG_HID_CYPRESS is not set
# CONFIG_HID_DRAGONRISE is not set
# CONFIG_HID_EMS_FF is not set
# CONFIG_HID_ELECOM is not set
# CONFIG_HID_ELO is not set
# CONFIG_HID_EZKEY is not set
# CONFIG_HID_GEMBIRD is not set
# CONFIG_HID_GFRM is not set
# CONFIG_HID_HOLTEK is not set
# CONFIG_HID_KEYTOUCH is not set
# CONFIG_HID_KYE is not set
# CONFIG_HID_UCLOGIC is not set
# CONFIG_HID_WALTOP is not set
# CONFIG_HID_GYRATION is not set
# CONFIG_HID_ICADE is not set
# CONFIG_HID_ITE is not set
# CONFIG_HID_TWINHAN is not set
# CONFIG_HID_KENSINGTON is not set
# CONFIG_HID_LCPOWER is not set
# CONFIG_HID_LENOVO is not set
CONFIG_HID_LOGITECH=y
CONFIG_HID_LOGITECH_DJ=y
CONFIG_HID_LOGITECH_HIDPP=y
# CONFIG_LOGITECH_FF is not set
# CONFIG_LOGIRUMBLEPAD2_FF is not set
# CONFIG_LOGIG940_FF is not set
# CONFIG_LOGIWHEELS_FF is not set
# CONFIG_HID_MAGICMOUSE is not set
# CONFIG_HID_MAYFLASH is not set
# CONFIG_HID_MICROSOFT is not set
# CONFIG_HID_MONTEREY is not set
# CONFIG_HID_MULTITOUCH is not set
# CONFIG_HID_NTI is not set
# CONFIG_HID_NTRIG is not set
# CONFIG_HID_ORTEK is not set
# CONFIG_HID_PANTHERLORD is not set
# CONFIG_HID_PENMOUNT is not set
# CONFIG_HID_PETALYNX is not set
# CONFIG_HID_PICOLCD is not set
# CONFIG_HID_PLANTRONICS is not set
# CONFIG_HID_PRIMAX is not set
# CONFIG_HID_RETRODE is not set
# CONFIG_HID_ROCCAT is not set
# CONFIG_HID_SAITEK is not set
# CONFIG_HID_SAMSUNG is not set
# CONFIG_HID_SPEEDLINK is not set
# CONFIG_HID_STEELSERIES is not set
# CONFIG_HID_SUNPLUS is not set
# CONFIG_HID_RMI is not set
# CONFIG_HID_GREENASIA is not set
# CONFIG_HID_SMARTJOYPLUS is not set
# CONFIG_HID_TIVO is not set
# CONFIG_HID_TOPSEED is not set
# CONFIG_HID_THRUSTMASTER is not set
# CONFIG_HID_UDRAW_PS3 is not set
# CONFIG_HID_WACOM is not set
# CONFIG_HID_XINMO is not set
# CONFIG_HID_ZEROPLUS is not set
# CONFIG_HID_ZYDACRON is not set
# CONFIG_HID_SENSOR_HUB is not set
# CONFIG_HID_ALPS is not set

#
# USB HID support
#
CONFIG_USB_HID=y
# CONFIG_HID_PID is not set
CONFIG_USB_HIDDEV=y

#
# I2C HID support
#
# CONFIG_I2C_HID is not set

#
# Intel ISH HID support
#
# CONFIG_INTEL_ISH_HID is not set
CONFIG_USB_OHCI_LITTLE_ENDIAN=y
CONFIG_USB_SUPPORT=y
CONFIG_USB_COMMON=y
CONFIG_USB_ARCH_HAS_HCD=y
CONFIG_USB=y
CONFIG_USB_PCI=y
# CONFIG_USB_ANNOUNCE_NEW_DEVICES is not set

#
# Miscellaneous USB options
#
CONFIG_USB_DEFAULT_PERSIST=y
# CONFIG_USB_DYNAMIC_MINORS is not set
# CONFIG_USB_OTG is not set
# CONFIG_USB_OTG_WHITELIST is not set
# CONFIG_USB_OTG_BLACKLIST_HUB is not set
CONFIG_USB_MON=y
# CONFIG_USB_WUSB_CBAF is not set

#
# USB Host Controller Drivers
#
# CONFIG_USB_C67X00_HCD is not set
# CONFIG_USB_XHCI_HCD is not set
CONFIG_USB_EHCI_HCD=y
# CONFIG_USB_EHCI_ROOT_HUB_TT is not set
# CONFIG_USB_EHCI_TT_NEWSCHED is not set
CONFIG_USB_EHCI_PCI=y
# CONFIG_USB_EHCI_HCD_PLATFORM is not set
# CONFIG_USB_OXU210HP_HCD is not set
# CONFIG_USB_ISP116X_HCD is not set
# CONFIG_USB_ISP1362_HCD is not set
# CONFIG_USB_FOTG210_HCD is not set
CONFIG_USB_OHCI_HCD=y
CONFIG_USB_OHCI_HCD_PCI=y
# CONFIG_USB_OHCI_HCD_PLATFORM is not set
# CONFIG_USB_UHCI_HCD is not set
# CONFIG_USB_SL811_HCD is not set
# CONFIG_USB_R8A66597_HCD is not set
# CONFIG_USB_HCD_TEST_MODE is not set

#
# USB Device Class drivers
#
# CONFIG_USB_ACM is not set
CONFIG_USB_PRINTER=y
# CONFIG_USB_WDM is not set
# CONFIG_USB_TMC is not set

#
# NOTE: USB_STORAGE depends on SCSI but BLK_DEV_SD may
#

#
# also be needed; see USB_STORAGE Help for more info
#
CONFIG_USB_STORAGE=y
# CONFIG_USB_STORAGE_DEBUG is not set
# CONFIG_USB_STORAGE_REALTEK is not set
# CONFIG_USB_STORAGE_DATAFAB is not set
# CONFIG_USB_STORAGE_FREECOM is not set
# CONFIG_USB_STORAGE_ISD200 is not set
# CONFIG_USB_STORAGE_USBAT is not set
# CONFIG_USB_STORAGE_SDDR09 is not set
# CONFIG_USB_STORAGE_SDDR55 is not set
# CONFIG_USB_STORAGE_JUMPSHOT is not set
# CONFIG_USB_STORAGE_ALAUDA is not set
# CONFIG_USB_STORAGE_ONETOUCH is not set
# CONFIG_USB_STORAGE_KARMA is not set
# CONFIG_USB_STORAGE_CYPRESS_ATACB is not set
# CONFIG_USB_STORAGE_ENE_UB6250 is not set
# CONFIG_USB_UAS is not set

#
# USB Imaging devices
#
# CONFIG_USB_MDC800 is not set
# CONFIG_USB_MICROTEK is not set
# CONFIG_USBIP_CORE is not set
# CONFIG_USB_MUSB_HDRC is not set
# CONFIG_USB_DWC3 is not set
# CONFIG_USB_DWC2 is not set
# CONFIG_USB_CHIPIDEA is not set
# CONFIG_USB_ISP1760 is not set

#
# USB port drivers
#
# CONFIG_USB_SERIAL is not set

#
# USB Miscellaneous drivers
#
# CONFIG_USB_EMI62 is not set
# CONFIG_USB_EMI26 is not set
# CONFIG_USB_ADUTUX is not set
# CONFIG_USB_SEVSEG is not set
# CONFIG_USB_RIO500 is not set
# CONFIG_USB_LEGOTOWER is not set
# CONFIG_USB_LCD is not set
# CONFIG_USB_CYPRESS_CY7C63 is not set
# CONFIG_USB_CYTHERM is not set
# CONFIG_USB_IDMOUSE is not set
# CONFIG_USB_FTDI_ELAN is not set
# CONFIG_USB_APPLEDISPLAY is not set
# CONFIG_USB_SISUSBVGA is not set
# CONFIG_USB_LD is not set
# CONFIG_USB_TRANCEVIBRATOR is not set
# CONFIG_USB_IOWARRIOR is not set
# CONFIG_USB_TEST is not set
# CONFIG_USB_EHSET_TEST_FIXTURE is not set
# CONFIG_USB_ISIGHTFW is not set
# CONFIG_USB_YUREX is not set
# CONFIG_USB_EZUSB_FX2 is not set
# CONFIG_USB_HUB_USB251XB is not set
# CONFIG_USB_HSIC_USB3503 is not set
# CONFIG_USB_HSIC_USB4604 is not set
# CONFIG_USB_LINK_LAYER_TEST is not set

#
# USB Physical Layer drivers
#
# CONFIG_USB_PHY is not set
# CONFIG_NOP_USB_XCEIV is not set
# CONFIG_USB_ISP1301 is not set
# CONFIG_USB_GADGET is not set

#
# USB Power Delivery and Type-C drivers
#
# CONFIG_TYPEC_UCSI is not set
# CONFIG_USB_ULPI_BUS is not set
# CONFIG_UWB is not set
# CONFIG_MMC is not set
# CONFIG_MEMSTICK is not set
# CONFIG_NEW_LEDS is not set
# CONFIG_ACCESSIBILITY is not set
# CONFIG_INFINIBAND is not set
CONFIG_EDAC_ATOMIC_SCRUB=y
CONFIG_EDAC_SUPPORT=y
CONFIG_EDAC=y
CONFIG_EDAC_LEGACY_SYSFS=y
# CONFIG_EDAC_DEBUG is not set
CONFIG_EDAC_DECODE_MCE=y
CONFIG_EDAC_AMD64=y
# CONFIG_EDAC_AMD64_ERROR_INJECTION is not set
# CONFIG_EDAC_E752X is not set
# CONFIG_EDAC_I82975X is not set
# CONFIG_EDAC_I3000 is not set
# CONFIG_EDAC_I3200 is not set
# CONFIG_EDAC_IE31200 is not set
# CONFIG_EDAC_X38 is not set
# CONFIG_EDAC_I5400 is not set
# CONFIG_EDAC_I5000 is not set
# CONFIG_EDAC_I5100 is not set
# CONFIG_EDAC_I7300 is not set
CONFIG_RTC_LIB=y
CONFIG_RTC_MC146818_LIB=y
CONFIG_RTC_CLASS=y
CONFIG_RTC_HCTOSYS=y
CONFIG_RTC_HCTOSYS_DEVICE="rtc0"
CONFIG_RTC_SYSTOHC=y
CONFIG_RTC_SYSTOHC_DEVICE="rtc0"
# CONFIG_RTC_DEBUG is not set
CONFIG_RTC_NVMEM=y

#
# RTC interfaces
#
CONFIG_RTC_INTF_SYSFS=y
CONFIG_RTC_INTF_PROC=y
CONFIG_RTC_INTF_DEV=y
# CONFIG_RTC_INTF_DEV_UIE_EMUL is not set
# CONFIG_RTC_DRV_TEST is not set

#
# I2C RTC drivers
#
# CONFIG_RTC_DRV_ABB5ZES3 is not set
# CONFIG_RTC_DRV_ABX80X is not set
# CONFIG_RTC_DRV_DS1307 is not set
# CONFIG_RTC_DRV_DS1374 is not set
# CONFIG_RTC_DRV_DS1672 is not set
# CONFIG_RTC_DRV_MAX6900 is not set
# CONFIG_RTC_DRV_RS5C372 is not set
# CONFIG_RTC_DRV_ISL1208 is not set
# CONFIG_RTC_DRV_ISL12022 is not set
# CONFIG_RTC_DRV_X1205 is not set
# CONFIG_RTC_DRV_PCF8523 is not set
# CONFIG_RTC_DRV_PCF85063 is not set
# CONFIG_RTC_DRV_PCF8563 is not set
# CONFIG_RTC_DRV_PCF8583 is not set
# CONFIG_RTC_DRV_M41T80 is not set
# CONFIG_RTC_DRV_BQ32K is not set
# CONFIG_RTC_DRV_S35390A is not set
# CONFIG_RTC_DRV_FM3130 is not set
# CONFIG_RTC_DRV_RX8010 is not set
# CONFIG_RTC_DRV_RX8581 is not set
# CONFIG_RTC_DRV_RX8025 is not set
# CONFIG_RTC_DRV_EM3027 is not set
# CONFIG_RTC_DRV_RV8803 is not set

#
# SPI RTC drivers
#
CONFIG_RTC_I2C_AND_SPI=y

#
# SPI and I2C RTC drivers
#
# CONFIG_RTC_DRV_DS3232 is not set
# CONFIG_RTC_DRV_PCF2127 is not set
# CONFIG_RTC_DRV_RV3029C2 is not set

#
# Platform RTC drivers
#
CONFIG_RTC_DRV_CMOS=y
# CONFIG_RTC_DRV_DS1286 is not set
# CONFIG_RTC_DRV_DS1511 is not set
# CONFIG_RTC_DRV_DS1553 is not set
# CONFIG_RTC_DRV_DS1685_FAMILY is not set
# CONFIG_RTC_DRV_DS1742 is not set
# CONFIG_RTC_DRV_DS2404 is not set
# CONFIG_RTC_DRV_STK17TA8 is not set
# CONFIG_RTC_DRV_M48T86 is not set
# CONFIG_RTC_DRV_M48T35 is not set
# CONFIG_RTC_DRV_M48T59 is not set
# CONFIG_RTC_DRV_MSM6242 is not set
# CONFIG_RTC_DRV_BQ4802 is not set
# CONFIG_RTC_DRV_RP5C01 is not set
# CONFIG_RTC_DRV_V3020 is not set

#
# on-CPU RTC drivers
#
# CONFIG_RTC_DRV_FTRTC010 is not set

#
# HID Sensor RTC drivers
#
# CONFIG_RTC_DRV_HID_SENSOR_TIME is not set
# CONFIG_DMADEVICES is not set

#
# DMABUF options
#
CONFIG_SYNC_FILE=y
# CONFIG_SW_SYNC is not set
# CONFIG_AUXDISPLAY is not set
# CONFIG_UIO is not set
CONFIG_IRQ_BYPASS_MANAGER=y
# CONFIG_VIRT_DRIVERS is not set
CONFIG_VIRTIO=y

#
# Virtio drivers
#
CONFIG_VIRTIO_PCI=y
CONFIG_VIRTIO_PCI_LEGACY=y
# CONFIG_VIRTIO_BALLOON is not set
# CONFIG_VIRTIO_INPUT is not set
# CONFIG_VIRTIO_MMIO is not set

#
# Microsoft Hyper-V guest support
#
# CONFIG_HYPERV_TSCPAGE is not set
# CONFIG_STAGING is not set
# CONFIG_X86_PLATFORM_DEVICES is not set
CONFIG_PMC_ATOM=y
# CONFIG_CHROME_PLATFORMS is not set
CONFIG_CLKDEV_LOOKUP=y
CONFIG_HAVE_CLK_PREPARE=y
CONFIG_COMMON_CLK=y

#
# Common Clock Framework
#
# CONFIG_COMMON_CLK_SI5351 is not set
# CONFIG_COMMON_CLK_CDCE706 is not set
# CONFIG_COMMON_CLK_CS2000_CP is not set
# CONFIG_COMMON_CLK_NXP is not set
# CONFIG_COMMON_CLK_PXA is not set
# CONFIG_COMMON_CLK_PIC32 is not set
# CONFIG_HWSPINLOCK is not set

#
# Clock Source drivers
#
CONFIG_CLKEVT_I8253=y
CONFIG_CLKBLD_I8253=y
# CONFIG_ATMEL_PIT is not set
# CONFIG_SH_TIMER_CMT is not set
# CONFIG_SH_TIMER_MTU2 is not set
# CONFIG_SH_TIMER_TMU is not set
# CONFIG_EM_TIMER_STI is not set
# CONFIG_MAILBOX is not set
# CONFIG_IOMMU_SUPPORT is not set

#
# Remoteproc drivers
#
# CONFIG_REMOTEPROC is not set

#
# Rpmsg drivers
#

#
# SOC (System On Chip) specific Drivers
#

#
# Broadcom SoC drivers
#

#
# i.MX SoC drivers
#
# CONFIG_SUNXI_SRAM is not set
# CONFIG_SOC_TI is not set
# CONFIG_PM_DEVFREQ is not set
# CONFIG_EXTCON is not set
# CONFIG_MEMORY is not set
# CONFIG_IIO is not set
# CONFIG_NTB is not set
# CONFIG_VME_BUS is not set
# CONFIG_PWM is not set
CONFIG_ARM_GIC_MAX_NR=1
# CONFIG_IPACK_BUS is not set
# CONFIG_RESET_CONTROLLER is not set
# CONFIG_FMC is not set

#
# PHY Subsystem
#
# CONFIG_GENERIC_PHY is not set
# CONFIG_BCM_KONA_USB2_PHY is not set
# CONFIG_PHY_PXA_28NM_HSIC is not set
# CONFIG_PHY_PXA_28NM_USB2 is not set
# CONFIG_POWERCAP is not set
# CONFIG_MCB is not set

#
# Performance monitor support
#
CONFIG_RAS=y
# CONFIG_THUNDERBOLT is not set

#
# Android
#
# CONFIG_ANDROID is not set
# CONFIG_LIBNVDIMM is not set
CONFIG_DAX=y
CONFIG_NVMEM=y
# CONFIG_STM is not set
# CONFIG_INTEL_TH is not set
# CONFIG_FPGA is not set

#
# FSI support
#
# CONFIG_FSI is not set

#
# Firmware Drivers
#
# CONFIG_EDD is not set
CONFIG_FIRMWARE_MEMMAP=y
# CONFIG_DELL_RBU is not set
# CONFIG_DCDBAS is not set
# CONFIG_DMIID is not set
# CONFIG_DMI_SYSFS is not set
CONFIG_DMI_SCAN_MACHINE_NON_EFI_FALLBACK=y
# CONFIG_ISCSI_IBFT_FIND is not set
# CONFIG_FW_CFG_SYSFS is not set
# CONFIG_GOOGLE_FIRMWARE is not set
# CONFIG_EFI_DEV_PATH_PARSER is not set

#
# Tegra firmware driver
#

#
# File systems
#
CONFIG_DCACHE_WORD_ACCESS=y
# CONFIG_EXT2_FS is not set
# CONFIG_EXT3_FS is not set
CONFIG_EXT4_FS=y
CONFIG_EXT4_USE_FOR_EXT2=y
# CONFIG_EXT4_FS_POSIX_ACL is not set
# CONFIG_EXT4_FS_SECURITY is not set
# CONFIG_EXT4_ENCRYPTION is not set
# CONFIG_EXT4_DEBUG is not set
CONFIG_JBD2=y
# CONFIG_JBD2_DEBUG is not set
CONFIG_FS_MBCACHE=y
# CONFIG_REISERFS_FS is not set
# CONFIG_JFS_FS is not set
# CONFIG_XFS_FS is not set
# CONFIG_GFS2_FS is not set
CONFIG_BTRFS_FS=y
# CONFIG_BTRFS_FS_POSIX_ACL is not set
# CONFIG_BTRFS_FS_CHECK_INTEGRITY is not set
# CONFIG_BTRFS_FS_RUN_SANITY_TESTS is not set
# CONFIG_BTRFS_DEBUG is not set
# CONFIG_BTRFS_ASSERT is not set
# CONFIG_NILFS2_FS is not set
# CONFIG_F2FS_FS is not set
# CONFIG_FS_DAX is not set
CONFIG_FS_POSIX_ACL=y
# CONFIG_EXPORTFS_BLOCK_OPS is not set
CONFIG_FILE_LOCKING=y
# CONFIG_MANDATORY_FILE_LOCKING is not set
# CONFIG_FS_ENCRYPTION is not set
CONFIG_FSNOTIFY=y
CONFIG_DNOTIFY=y
CONFIG_INOTIFY_USER=y
# CONFIG_FANOTIFY is not set
# CONFIG_QUOTA is not set
# CONFIG_QUOTACTL is not set
# CONFIG_AUTOFS4_FS is not set
CONFIG_FUSE_FS=y
# CONFIG_CUSE is not set
# CONFIG_OVERLAY_FS is not set

#
# Caches
#
# CONFIG_FSCACHE is not set

#
# CD-ROM/DVD Filesystems
#
CONFIG_ISO9660_FS=y
CONFIG_JOLIET=y
# CONFIG_ZISOFS is not set
CONFIG_UDF_FS=y
CONFIG_UDF_NLS=y

#
# DOS/FAT/NT Filesystems
#
CONFIG_FAT_FS=y
CONFIG_MSDOS_FS=y
CONFIG_VFAT_FS=y
CONFIG_FAT_DEFAULT_CODEPAGE=437
CONFIG_FAT_DEFAULT_IOCHARSET="iso8859-1"
# CONFIG_FAT_DEFAULT_UTF8 is not set
# CONFIG_NTFS_FS is not set

#
# Pseudo filesystems
#
CONFIG_PROC_FS=y
CONFIG_PROC_KCORE=y
CONFIG_PROC_SYSCTL=y
CONFIG_PROC_PAGE_MONITOR=y
# CONFIG_PROC_CHILDREN is not set
CONFIG_KERNFS=y
CONFIG_SYSFS=y
CONFIG_TMPFS=y
# CONFIG_TMPFS_POSIX_ACL is not set
# CONFIG_TMPFS_XATTR is not set
# CONFIG_HUGETLBFS is not set
# CONFIG_HUGETLB_PAGE is not set
# CONFIG_CONFIGFS_FS is not set
# CONFIG_MISC_FILESYSTEMS is not set
CONFIG_NETWORK_FILESYSTEMS=y
# CONFIG_NFS_FS is not set
# CONFIG_NFSD is not set
# CONFIG_CEPH_FS is not set
# CONFIG_CIFS is not set
# CONFIG_NCP_FS is not set
# CONFIG_CODA_FS is not set
# CONFIG_AFS_FS is not set
CONFIG_9P_FS=y
# CONFIG_9P_FS_POSIX_ACL is not set
# CONFIG_9P_FS_SECURITY is not set
CONFIG_NLS=y
CONFIG_NLS_DEFAULT="iso8859-1"
CONFIG_NLS_CODEPAGE_437=y
# CONFIG_NLS_CODEPAGE_737 is not set
# CONFIG_NLS_CODEPAGE_775 is not set
# CONFIG_NLS_CODEPAGE_850 is not set
# CONFIG_NLS_CODEPAGE_852 is not set
# CONFIG_NLS_CODEPAGE_855 is not set
# CONFIG_NLS_CODEPAGE_857 is not set
# CONFIG_NLS_CODEPAGE_860 is not set
# CONFIG_NLS_CODEPAGE_861 is not set
# CONFIG_NLS_CODEPAGE_862 is not set
# CONFIG_NLS_CODEPAGE_863 is not set
# CONFIG_NLS_CODEPAGE_864 is not set
# CONFIG_NLS_CODEPAGE_865 is not set
# CONFIG_NLS_CODEPAGE_866 is not set
# CONFIG_NLS_CODEPAGE_869 is not set
# CONFIG_NLS_CODEPAGE_936 is not set
# CONFIG_NLS_CODEPAGE_950 is not set
# CONFIG_NLS_CODEPAGE_932 is not set
# CONFIG_NLS_CODEPAGE_949 is not set
# CONFIG_NLS_CODEPAGE_874 is not set
# CONFIG_NLS_ISO8859_8 is not set
# CONFIG_NLS_CODEPAGE_1250 is not set
# CONFIG_NLS_CODEPAGE_1251 is not set
CONFIG_NLS_ASCII=y
CONFIG_NLS_ISO8859_1=y
# CONFIG_NLS_ISO8859_2 is not set
# CONFIG_NLS_ISO8859_3 is not set
# CONFIG_NLS_ISO8859_4 is not set
# CONFIG_NLS_ISO8859_5 is not set
# CONFIG_NLS_ISO8859_6 is not set
# CONFIG_NLS_ISO8859_7 is not set
# CONFIG_NLS_ISO8859_9 is not set
# CONFIG_NLS_ISO8859_13 is not set
# CONFIG_NLS_ISO8859_14 is not set
CONFIG_NLS_ISO8859_15=y
# CONFIG_NLS_KOI8_R is not set
# CONFIG_NLS_KOI8_U is not set
# CONFIG_NLS_MAC_ROMAN is not set
# CONFIG_NLS_MAC_CELTIC is not set
# CONFIG_NLS_MAC_CENTEURO is not set
# CONFIG_NLS_MAC_CROATIAN is not set
# CONFIG_NLS_MAC_CYRILLIC is not set
# CONFIG_NLS_MAC_GAELIC is not set
# CONFIG_NLS_MAC_GREEK is not set
# CONFIG_NLS_MAC_ICELAND is not set
# CONFIG_NLS_MAC_INUIT is not set
# CONFIG_NLS_MAC_ROMANIAN is not set
# CONFIG_NLS_MAC_TURKISH is not set
CONFIG_NLS_UTF8=y

#
# Kernel hacking
#
CONFIG_TRACE_IRQFLAGS_SUPPORT=y

#
# printk and dmesg options
#
# CONFIG_PRINTK_TIME is not set
CONFIG_CONSOLE_LOGLEVEL_DEFAULT=7
CONFIG_MESSAGE_LOGLEVEL_DEFAULT=4
# CONFIG_BOOT_PRINTK_DELAY is not set
# CONFIG_DYNAMIC_DEBUG is not set

#
# Compile-time checks and compiler options
#
# CONFIG_DEBUG_INFO is not set
# CONFIG_ENABLE_WARN_DEPRECATED is not set
# CONFIG_ENABLE_MUST_CHECK is not set
CONFIG_FRAME_WARN=1024
# CONFIG_STRIP_ASM_SYMS is not set
# CONFIG_READABLE_ASM is not set
# CONFIG_UNUSED_SYMBOLS is not set
# CONFIG_PAGE_OWNER is not set
CONFIG_DEBUG_FS=y
# CONFIG_HEADERS_CHECK is not set
# CONFIG_DEBUG_SECTION_MISMATCH is not set
CONFIG_SECTION_MISMATCH_WARN_ONLY=y
CONFIG_STACK_VALIDATION=y
# CONFIG_DEBUG_FORCE_WEAK_PER_CPU is not set
CONFIG_MAGIC_SYSRQ=y
CONFIG_MAGIC_SYSRQ_DEFAULT_ENABLE=0x1
# CONFIG_MAGIC_SYSRQ_SERIAL is not set
CONFIG_DEBUG_KERNEL=y

#
# Memory Debugging
#
# CONFIG_PAGE_EXTENSION is not set
# CONFIG_DEBUG_PAGEALLOC is not set
# CONFIG_PAGE_POISONING is not set
# CONFIG_DEBUG_RODATA_TEST is not set
# CONFIG_DEBUG_OBJECTS is not set
# CONFIG_SLUB_STATS is not set
CONFIG_HAVE_DEBUG_KMEMLEAK=y
# CONFIG_DEBUG_KMEMLEAK is not set
# CONFIG_DEBUG_STACK_USAGE is not set
# CONFIG_DEBUG_VM is not set
CONFIG_ARCH_HAS_DEBUG_VIRTUAL=y
# CONFIG_DEBUG_VIRTUAL is not set
# CONFIG_DEBUG_MEMORY_INIT is not set
# CONFIG_DEBUG_PER_CPU_MAPS is not set
CONFIG_HAVE_DEBUG_STACKOVERFLOW=y
# CONFIG_DEBUG_STACKOVERFLOW is not set
CONFIG_HAVE_ARCH_KMEMCHECK=y
# CONFIG_KMEMCHECK is not set
CONFIG_HAVE_ARCH_KASAN=y
# CONFIG_KASAN is not set
CONFIG_ARCH_HAS_KCOV=y
# CONFIG_KCOV is not set
# CONFIG_DEBUG_SHIRQ is not set

#
# Debug Lockups and Hangs
#
# CONFIG_SOFTLOCKUP_DETECTOR is not set
CONFIG_HARDLOCKUP_CHECK_TIMESTAMP=y
# CONFIG_HARDLOCKUP_DETECTOR is not set
# CONFIG_DETECT_HUNG_TASK is not set
# CONFIG_WQ_WATCHDOG is not set
# CONFIG_PANIC_ON_OOPS is not set
CONFIG_PANIC_ON_OOPS_VALUE=0
CONFIG_PANIC_TIMEOUT=0
# CONFIG_SCHED_DEBUG is not set
CONFIG_SCHED_INFO=y
# CONFIG_SCHEDSTATS is not set
# CONFIG_SCHED_STACK_END_CHECK is not set
# CONFIG_DEBUG_TIMEKEEPING is not set

#
# Lock Debugging (spinlocks, mutexes, etc...)
#
# CONFIG_DEBUG_RT_MUTEXES is not set
# CONFIG_DEBUG_SPINLOCK is not set
# CONFIG_DEBUG_MUTEXES is not set
# CONFIG_DEBUG_WW_MUTEX_SLOWPATH is not set
# CONFIG_DEBUG_LOCK_ALLOC is not set
# CONFIG_PROVE_LOCKING is not set
# CONFIG_LOCK_STAT is not set
# CONFIG_DEBUG_ATOMIC_SLEEP is not set
# CONFIG_DEBUG_LOCKING_API_SELFTESTS is not set
# CONFIG_LOCK_TORTURE_TEST is not set
# CONFIG_WW_MUTEX_SELFTEST is not set
# CONFIG_STACKTRACE is not set
# CONFIG_WARN_ALL_UNSEEDED_RANDOM is not set
# CONFIG_DEBUG_KOBJECT is not set
CONFIG_DEBUG_BUGVERBOSE=y
# CONFIG_DEBUG_LIST is not set
# CONFIG_DEBUG_PI_LIST is not set
# CONFIG_DEBUG_SG is not set
# CONFIG_DEBUG_NOTIFIERS is not set
# CONFIG_DEBUG_CREDENTIALS is not set

#
# RCU Debugging
#
# CONFIG_PROVE_RCU is not set
# CONFIG_TORTURE_TEST is not set
# CONFIG_RCU_PERF_TEST is not set
# CONFIG_RCU_TORTURE_TEST is not set
CONFIG_RCU_CPU_STALL_TIMEOUT=60
# CONFIG_RCU_TRACE is not set
# CONFIG_RCU_EQS_DEBUG is not set
# CONFIG_DEBUG_WQ_FORCE_RR_CPU is not set
# CONFIG_DEBUG_BLOCK_EXT_DEVT is not set
# CONFIG_NOTIFIER_ERROR_INJECTION is not set
# CONFIG_FAULT_INJECTION is not set
# CONFIG_LATENCYTOP is not set
CONFIG_USER_STACKTRACE_SUPPORT=y
CONFIG_HAVE_FUNCTION_TRACER=y
CONFIG_HAVE_FUNCTION_GRAPH_TRACER=y
CONFIG_HAVE_DYNAMIC_FTRACE=y
CONFIG_HAVE_DYNAMIC_FTRACE_WITH_REGS=y
CONFIG_HAVE_FTRACE_MCOUNT_RECORD=y
CONFIG_HAVE_SYSCALL_TRACEPOINTS=y
CONFIG_HAVE_FENTRY=y
CONFIG_HAVE_C_RECORDMCOUNT=y
CONFIG_TRACING_SUPPORT=y
# CONFIG_FTRACE is not set

#
# Runtime Testing
#
# CONFIG_LKDTM is not set
# CONFIG_TEST_LIST_SORT is not set
# CONFIG_TEST_SORT is not set
# CONFIG_BACKTRACE_SELF_TEST is not set
# CONFIG_RBTREE_TEST is not set
# CONFIG_INTERVAL_TREE_TEST is not set
# CONFIG_ATOMIC64_SELFTEST is not set
# CONFIG_TEST_HEXDUMP is not set
# CONFIG_TEST_STRING_HELPERS is not set
# CONFIG_TEST_KSTRTOX is not set
# CONFIG_TEST_PRINTF is not set
# CONFIG_TEST_BITMAP is not set
# CONFIG_TEST_UUID is not set
# CONFIG_TEST_RHASHTABLE is not set
# CONFIG_TEST_HASH is not set
# CONFIG_PROVIDE_OHCI1394_DMA_INIT is not set
# CONFIG_DMA_API_DEBUG is not set
# CONFIG_TEST_FIRMWARE is not set
# CONFIG_TEST_SYSCTL is not set
# CONFIG_TEST_UDELAY is not set
# CONFIG_MEMTEST is not set
# CONFIG_BUG_ON_DATA_CORRUPTION is not set
# CONFIG_SAMPLES is not set
CONFIG_HAVE_ARCH_KGDB=y
# CONFIG_KGDB is not set
CONFIG_ARCH_HAS_UBSAN_SANITIZE_ALL=y
# CONFIG_ARCH_WANTS_UBSAN_NO_NULL is not set
# CONFIG_UBSAN is not set
CONFIG_ARCH_HAS_DEVMEM_IS_ALLOWED=y
CONFIG_STRICT_DEVMEM=y
CONFIG_IO_STRICT_DEVMEM=y
# CONFIG_X86_VERBOSE_BOOTUP is not set
# CONFIG_EARLY_PRINTK is not set
CONFIG_X86_PTDUMP_CORE=y
# CONFIG_X86_PTDUMP is not set
CONFIG_DEBUG_WX=y
CONFIG_DOUBLEFAULT=y
# CONFIG_DEBUG_TLBFLUSH is not set
# CONFIG_IOMMU_STRESS is not set
CONFIG_HAVE_MMIOTRACE_SUPPORT=y
CONFIG_IO_DELAY_TYPE_0X80=0
CONFIG_IO_DELAY_TYPE_0XED=1
CONFIG_IO_DELAY_TYPE_UDELAY=2
CONFIG_IO_DELAY_TYPE_NONE=3
CONFIG_IO_DELAY_0X80=y
# CONFIG_IO_DELAY_0XED is not set
# CONFIG_IO_DELAY_UDELAY is not set
# CONFIG_IO_DELAY_NONE is not set
CONFIG_DEFAULT_IO_DELAY_TYPE=0
# CONFIG_DEBUG_BOOT_PARAMS is not set
# CONFIG_CPA_DEBUG is not set
CONFIG_OPTIMIZE_INLINING=y
# CONFIG_DEBUG_ENTRY is not set
# CONFIG_DEBUG_NMI_SELFTEST is not set
# CONFIG_X86_DEBUG_FPU is not set
# CONFIG_PUNIT_ATOM_DEBUG is not set
# CONFIG_FRAME_POINTER_UNWINDER is not set
CONFIG_ORC_UNWINDER=y
# CONFIG_GUESS_UNWINDER is not set

#
# Security options
#
# CONFIG_KEYS is not set
# CONFIG_SECURITY_DMESG_RESTRICT is not set
# CONFIG_SECURITY is not set
# CONFIG_SECURITYFS is not set
CONFIG_HAVE_HARDENED_USERCOPY_ALLOCATOR=y
# CONFIG_HARDENED_USERCOPY is not set
# CONFIG_FORTIFY_SOURCE is not set
# CONFIG_STATIC_USERMODEHELPER is not set
CONFIG_DEFAULT_SECURITY_DAC=y
CONFIG_DEFAULT_SECURITY=""
CONFIG_XOR_BLOCKS=y
CONFIG_CRYPTO=y

#
# Crypto core or helper
#
CONFIG_CRYPTO_ALGAPI=y
CONFIG_CRYPTO_ALGAPI2=y
CONFIG_CRYPTO_HASH=y
CONFIG_CRYPTO_HASH2=y
# CONFIG_CRYPTO_RSA is not set
# CONFIG_CRYPTO_DH is not set
# CONFIG_CRYPTO_ECDH is not set
# CONFIG_CRYPTO_MANAGER is not set
# CONFIG_CRYPTO_MANAGER2 is not set
# CONFIG_CRYPTO_USER is not set
# CONFIG_CRYPTO_GF128MUL is not set
# CONFIG_CRYPTO_NULL is not set
# CONFIG_CRYPTO_PCRYPT is not set
# CONFIG_CRYPTO_CRYPTD is not set
# CONFIG_CRYPTO_MCRYPTD is not set
# CONFIG_CRYPTO_AUTHENC is not set

#
# Authenticated Encryption with Associated Data
#
# CONFIG_CRYPTO_CCM is not set
# CONFIG_CRYPTO_GCM is not set
# CONFIG_CRYPTO_CHACHA20POLY1305 is not set
# CONFIG_CRYPTO_SEQIV is not set
# CONFIG_CRYPTO_ECHAINIV is not set

#
# Block modes
#
# CONFIG_CRYPTO_CBC is not set
# CONFIG_CRYPTO_CTR is not set
# CONFIG_CRYPTO_CTS is not set
# CONFIG_CRYPTO_ECB is not set
# CONFIG_CRYPTO_LRW is not set
# CONFIG_CRYPTO_PCBC is not set
# CONFIG_CRYPTO_XTS is not set
# CONFIG_CRYPTO_KEYWRAP is not set

#
# Hash modes
#
# CONFIG_CRYPTO_CMAC is not set
# CONFIG_CRYPTO_HMAC is not set
# CONFIG_CRYPTO_XCBC is not set
# CONFIG_CRYPTO_VMAC is not set

#
# Digest
#
CONFIG_CRYPTO_CRC32C=y
# CONFIG_CRYPTO_CRC32C_INTEL is not set
# CONFIG_CRYPTO_CRC32 is not set
# CONFIG_CRYPTO_CRC32_PCLMUL is not set
# CONFIG_CRYPTO_CRCT10DIF is not set
# CONFIG_CRYPTO_GHASH is not set
# CONFIG_CRYPTO_POLY1305 is not set
# CONFIG_CRYPTO_POLY1305_X86_64 is not set
# CONFIG_CRYPTO_MD4 is not set
# CONFIG_CRYPTO_MD5 is not set
# CONFIG_CRYPTO_MICHAEL_MIC is not set
# CONFIG_CRYPTO_RMD128 is not set
# CONFIG_CRYPTO_RMD160 is not set
# CONFIG_CRYPTO_RMD256 is not set
# CONFIG_CRYPTO_RMD320 is not set
# CONFIG_CRYPTO_SHA1 is not set
# CONFIG_CRYPTO_SHA1_SSSE3 is not set
# CONFIG_CRYPTO_SHA256_SSSE3 is not set
# CONFIG_CRYPTO_SHA512_SSSE3 is not set
# CONFIG_CRYPTO_SHA1_MB is not set
# CONFIG_CRYPTO_SHA256_MB is not set
# CONFIG_CRYPTO_SHA512_MB is not set
# CONFIG_CRYPTO_SHA256 is not set
# CONFIG_CRYPTO_SHA512 is not set
# CONFIG_CRYPTO_SHA3 is not set
# CONFIG_CRYPTO_TGR192 is not set
# CONFIG_CRYPTO_WP512 is not set
# CONFIG_CRYPTO_GHASH_CLMUL_NI_INTEL is not set

#
# Ciphers
#
CONFIG_CRYPTO_AES=y
# CONFIG_CRYPTO_AES_TI is not set
# CONFIG_CRYPTO_AES_X86_64 is not set
# CONFIG_CRYPTO_AES_NI_INTEL is not set
# CONFIG_CRYPTO_ANUBIS is not set
# CONFIG_CRYPTO_ARC4 is not set
# CONFIG_CRYPTO_BLOWFISH is not set
# CONFIG_CRYPTO_BLOWFISH_X86_64 is not set
# CONFIG_CRYPTO_CAMELLIA is not set
# CONFIG_CRYPTO_CAMELLIA_X86_64 is not set
# CONFIG_CRYPTO_CAMELLIA_AESNI_AVX_X86_64 is not set
# CONFIG_CRYPTO_CAMELLIA_AESNI_AVX2_X86_64 is not set
# CONFIG_CRYPTO_CAST5 is not set
# CONFIG_CRYPTO_CAST5_AVX_X86_64 is not set
# CONFIG_CRYPTO_CAST6 is not set
# CONFIG_CRYPTO_CAST6_AVX_X86_64 is not set
# CONFIG_CRYPTO_DES is not set
# CONFIG_CRYPTO_DES3_EDE_X86_64 is not set
# CONFIG_CRYPTO_FCRYPT is not set
# CONFIG_CRYPTO_KHAZAD is not set
# CONFIG_CRYPTO_SALSA20 is not set
# CONFIG_CRYPTO_SALSA20_X86_64 is not set
# CONFIG_CRYPTO_CHACHA20 is not set
# CONFIG_CRYPTO_CHACHA20_X86_64 is not set
# CONFIG_CRYPTO_SEED is not set
# CONFIG_CRYPTO_SERPENT is not set
# CONFIG_CRYPTO_SERPENT_SSE2_X86_64 is not set
# CONFIG_CRYPTO_SERPENT_AVX_X86_64 is not set
# CONFIG_CRYPTO_SERPENT_AVX2_X86_64 is not set
# CONFIG_CRYPTO_TEA is not set
# CONFIG_CRYPTO_TWOFISH is not set
# CONFIG_CRYPTO_TWOFISH_X86_64 is not set
# CONFIG_CRYPTO_TWOFISH_X86_64_3WAY is not set
# CONFIG_CRYPTO_TWOFISH_AVX_X86_64 is not set

#
# Compression
#
# CONFIG_CRYPTO_DEFLATE is not set
# CONFIG_CRYPTO_LZO is not set
# CONFIG_CRYPTO_842 is not set
# CONFIG_CRYPTO_LZ4 is not set
# CONFIG_CRYPTO_LZ4HC is not set

#
# Random Number Generation
#
# CONFIG_CRYPTO_ANSI_CPRNG is not set
# CONFIG_CRYPTO_DRBG_MENU is not set
# CONFIG_CRYPTO_JITTERENTROPY is not set
# CONFIG_CRYPTO_USER_API_HASH is not set
# CONFIG_CRYPTO_USER_API_SKCIPHER is not set
# CONFIG_CRYPTO_USER_API_RNG is not set
# CONFIG_CRYPTO_USER_API_AEAD is not set
# CONFIG_CRYPTO_HW is not set

#
# Certificates for signature checking
#
CONFIG_HAVE_KVM=y
CONFIG_HAVE_KVM_IRQCHIP=y
CONFIG_HAVE_KVM_IRQFD=y
CONFIG_HAVE_KVM_IRQ_ROUTING=y
CONFIG_HAVE_KVM_EVENTFD=y
CONFIG_KVM_MMIO=y
CONFIG_KVM_ASYNC_PF=y
CONFIG_HAVE_KVM_MSI=y
CONFIG_HAVE_KVM_CPU_RELAX_INTERCEPT=y
CONFIG_KVM_VFIO=y
CONFIG_KVM_GENERIC_DIRTYLOG_READ_PROTECT=y
CONFIG_HAVE_KVM_IRQ_BYPASS=y
CONFIG_VIRTUALIZATION=y
CONFIG_KVM=y
CONFIG_KVM_AMD=y
CONFIG_VHOST_NET=y
CONFIG_VHOST=y
# CONFIG_VHOST_CROSS_ENDIAN_LEGACY is not set
# CONFIG_BINARY_PRINTF is not set

#
# Library routines
#
CONFIG_RAID6_PQ=y
CONFIG_BITREVERSE=y
# CONFIG_HAVE_ARCH_BITREVERSE is not set
CONFIG_RATIONAL=y
CONFIG_GENERIC_STRNCPY_FROM_USER=y
CONFIG_GENERIC_STRNLEN_USER=y
CONFIG_GENERIC_NET_UTILS=y
CONFIG_GENERIC_FIND_FIRST_BIT=y
CONFIG_GENERIC_PCI_IOMAP=y
CONFIG_GENERIC_IOMAP=y
CONFIG_GENERIC_IO=y
CONFIG_ARCH_USE_CMPXCHG_LOCKREF=y
CONFIG_ARCH_HAS_FAST_MULTIPLIER=y
# CONFIG_CRC_CCITT is not set
CONFIG_CRC16=y
# CONFIG_CRC_T10DIF is not set
CONFIG_CRC_ITU_T=y
CONFIG_CRC32=y
# CONFIG_CRC32_SELFTEST is not set
CONFIG_CRC32_SLICEBY8=y
# CONFIG_CRC32_SLICEBY4 is not set
# CONFIG_CRC32_SARWATE is not set
# CONFIG_CRC32_BIT is not set
# CONFIG_CRC4 is not set
# CONFIG_CRC7 is not set
# CONFIG_LIBCRC32C is not set
# CONFIG_CRC8 is not set
# CONFIG_AUDIT_ARCH_COMPAT_GENERIC is not set
# CONFIG_RANDOM32_SELFTEST is not set
CONFIG_ZLIB_INFLATE=y
CONFIG_ZLIB_DEFLATE=y
CONFIG_LZO_COMPRESS=y
CONFIG_LZO_DECOMPRESS=y
# CONFIG_XZ_DEC is not set
# CONFIG_XZ_DEC_BCJ is not set
CONFIG_GENERIC_ALLOCATOR=y
CONFIG_INTERVAL_TREE=y
CONFIG_HAS_IOMEM=y
CONFIG_HAS_IOPORT_MAP=y
CONFIG_HAS_DMA=y
# CONFIG_DMA_NOOP_OPS is not set
# CONFIG_DMA_VIRT_OPS is not set
CONFIG_CPU_RMAP=y
CONFIG_DQL=y
CONFIG_GLOB=y
# CONFIG_GLOB_SELFTEST is not set
CONFIG_NLATTR=y
# CONFIG_CORDIC is not set
# CONFIG_DDR is not set
# CONFIG_IRQ_POLL is not set
CONFIG_FONT_SUPPORT=y
# CONFIG_FONTS is not set
CONFIG_FONT_8x8=y
CONFIG_FONT_8x16=y
# CONFIG_SG_SPLIT is not set
CONFIG_SG_POOL=y
CONFIG_ARCH_HAS_SG_CHAIN=y
CONFIG_ARCH_HAS_PMEM_API=y
CONFIG_ARCH_HAS_UACCESS_FLUSHCACHE=y
CONFIG_ARCH_HAS_MMIO_FLUSH=y
CONFIG_SBITMAP=y

^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: Current mainline git (24e700e291d52bd2) hangs when building e.g. perf
  2017-09-08  5:35           ` Markus Trippelsdorf
@ 2017-09-08  6:26             ` Thomas Gleixner
  2017-09-08  8:05               ` Borislav Petkov
  0 siblings, 1 reply; 61+ messages in thread
From: Thomas Gleixner @ 2017-09-08  6:26 UTC (permalink / raw)
  To: Markus Trippelsdorf
  Cc: Peter Zijlstra, LKML, Ingo Molnar, Andy Lutomirski, Borislav Petkov

On Fri, 8 Sep 2017, Markus Trippelsdorf wrote:

CC+ Borislav. He might have access to such a beast

> On 2017.09.07 at 08:28 +0200, Markus Trippelsdorf wrote:
> > On 2017.09.06 at 15:15 +0200, Markus Trippelsdorf wrote:
> > > On 2017.09.06 at 14:52 +0200, Thomas Gleixner wrote:
> > > > On Tue, 5 Sep 2017, Markus Trippelsdorf wrote:
> > > > > On 2017.09.05 at 10:53 +0200, Peter Zijlstra wrote:
> > > > > > > Any ideas on how to debug this further?
> > > > > > 
> > > > > > So you have a (real) serial line on that box?
> > > > > 
> > > > > Sadly, no. But hopefully somebody else (with a proper kernel debugging
> > > > > setup) will reproduce the issue soon.
> > > > 
> > > > Does the machine respond to ping or is it entirely dead?
> > > 
> > > It is entirely dead and doesn't respond to ping.
> > 
> > The bug even kills the host (running 4.13) when running 24e700e2 in qemu
> > (kvm) and compiling stuff in parallel in the guest.
> > I see an RCU CPU stall in dmesg (on the host), but unfortunately cannot
> > save it, because nothing gets written to disk after the stall.
> > Connecting to qemu via gdb also doesn't work.
> 
> My guess would be a bug in a low level function (asm) that only hits AMD
> machines. I'm running an old Phenom II X4 processor. My config is
> attached.
> 
> -- 
> Markus
> 

^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: Current mainline git (24e700e291d52bd2) hangs when building e.g. perf
  2017-09-08  6:26             ` Thomas Gleixner
@ 2017-09-08  8:05               ` Borislav Petkov
  2017-09-08  9:16                 ` Borislav Petkov
  0 siblings, 1 reply; 61+ messages in thread
From: Borislav Petkov @ 2017-09-08  8:05 UTC (permalink / raw)
  To: Thomas Gleixner
  Cc: Markus Trippelsdorf, Peter Zijlstra, LKML, Ingo Molnar, Andy Lutomirski

On Fri, Sep 08, 2017 at 08:26:44AM +0200, Thomas Gleixner wrote:
> On Fri, 8 Sep 2017, Markus Trippelsdorf wrote:
> 
> CC+ Borislav. He might have access to such a beast

Can I have /proc/cpuinfo and dmesg pls, in order to see whether I have
something similar?

Private mail's fine too.

Thx.

-- 
Regards/Gruss,
    Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.

^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: Current mainline git (24e700e291d52bd2) hangs when building e.g. perf
  2017-09-08  8:05               ` Borislav Petkov
@ 2017-09-08  9:16                 ` Borislav Petkov
  2017-09-08  9:48                   ` Markus Trippelsdorf
  2017-09-08 14:51                   ` Borislav Petkov
  0 siblings, 2 replies; 61+ messages in thread
From: Borislav Petkov @ 2017-09-08  9:16 UTC (permalink / raw)
  To: Markus Trippelsdorf
  Cc: Thomas Gleixner, Peter Zijlstra, LKML, Ingo Molnar, Andy Lutomirski

On Fri, Sep 08, 2017 at 10:05:36AM +0200, Borislav Petkov wrote:
> On Fri, Sep 08, 2017 at 08:26:44AM +0200, Thomas Gleixner wrote:
> > On Fri, 8 Sep 2017, Markus Trippelsdorf wrote:
> > 
> > CC+ Borislav. He might have access to such a beast
> 
> Can I have /proc/cpuinfo and dmesg pls, in order to see whether I have
> something similar?
> 
> Private mail's fine too.

So I don't have exactly your model - mine is model 2, stepping 3 but I see
something strange too, in dmesg:

+blkid[981]: segfault at 8 ip 00007f8267a4a3fd sp 00007ffc77045de0 error 4 in ld-linux-x86-64.so.2[7f8267a3a000+22000]
+blkid[984]: segfault at 8 ip 00007fe6035583fd sp 00007ffe9456e5b0 error 4 in ld-linux-x86-64.so.2[7fe603548000+22000]
+blkid[987]: segfault at 8 ip 00007fc695f123fd sp 00007fff1838f5f0 error 4 in ld-linux-x86-64.so.2[7fc695f02000+22000]
+blkid[990]: segfault at 8 ip 00007fd2a8d7c3fd sp 00007ffe4f663870 error 4 in ld-linux-x86-64.so.2[7fd2a8d6c000+22000]
+blkid[993]: segfault at 8 ip 00007fdb865fb3fd sp 00007ffc2ff85050 error 4 in ld-linux-x86-64.so.2[7fdb865eb000+22000]
+blkid[996]: segfault at 8 ip 00007fc28b90a3fd sp 00007ffc7233e0e0 error 4 in ld-linux-x86-64.so.2[7fc28b8fa000+22000]
+blkid[999]: segfault at 8 ip 00007fb95934c3fd sp 00007ffed513d660 error 4 in ld-linux-x86-64.so.2[7fb95933c000+22000]
+blkid[1002]: segfault at 8 ip 00007fb5facc83fd sp 00007ffece190fe0 error 4 in ld-linux-x86-64.so.2[7fb5facb8000+22000]
+blkid[1005]: segfault at 8 ip 00007f113cc693fd sp 00007ffcf6bbd3f0 error 4 in ld-linux-x86-64.so.2[7f113cc59000+22000]
+blkid[1008]: segfault at 8 ip 00007f1ad0a593fd sp 00007ffeee162df0 error 4 in ld-linux-x86-64.so.2[7f1ad0a49000+22000]
+blkid[1011]: segfault at 8 ip 00007fdd003183fd sp 00007ffde1f69e60 error 4 in ld-linux-x86-64.so.2[7fdd00308000+22000]
+blkid[1014]: segfault at 8 ip 00007ffb3240c3fd sp 00007ffc75a88180 error 4 in ld-linux-x86-64.so.2[7ffb323fc000+22000]
+blkid[1017]: segfault at 8 ip 00007f88b6d683fd sp 00007ffef5dbe830 error 4 in ld-linux-x86-64.so.2[7f88b6d58000+22000]
+blkid[1020]: segfault at 8 ip 00007fec7760c3fd sp 00007ffc9dd05890 error 4 in ld-linux-x86-64.so.2[7fec775fc000+22000]
+blkid[1026]: segfault at 8 ip 00007f5a31ecc3fd sp 00007fffaf3604b0 error 4 in ld-linux-x86-64.so.2[7f5a31ebc000+22000]
+logsave[1027]: segfault at 8 ip 00007f237d2033fd sp 00007fff53933e60 error 4 in ld-linux-x86-64.so.2[7f237d1f3000+22000]

and then

git pull
...

Fast-forward
error: merge died of signal 7

Lemme try 4.13.

-- 
Regards/Gruss,
    Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.

^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: Current mainline git (24e700e291d52bd2) hangs when building e.g. perf
  2017-09-08  9:16                 ` Borislav Petkov
@ 2017-09-08  9:48                   ` Markus Trippelsdorf
  2017-09-08 10:35                     ` Ingo Molnar
  2017-09-08 14:51                   ` Borislav Petkov
  1 sibling, 1 reply; 61+ messages in thread
From: Markus Trippelsdorf @ 2017-09-08  9:48 UTC (permalink / raw)
  To: Borislav Petkov
  Cc: Thomas Gleixner, Peter Zijlstra, LKML, Ingo Molnar,
	Andy Lutomirski, Tom Lendacky

On 2017.09.08 at 11:16 +0200, Borislav Petkov wrote:
> On Fri, Sep 08, 2017 at 10:05:36AM +0200, Borislav Petkov wrote:
> > On Fri, Sep 08, 2017 at 08:26:44AM +0200, Thomas Gleixner wrote:
> > > On Fri, 8 Sep 2017, Markus Trippelsdorf wrote:
> > > 
> > > CC+ Borislav. He might have access to such a beast
> > 
> > Can I have /proc/cpuinfo and dmesg pls, in order to see whether I have
> > something similar?
> > 
> > Private mail's fine too.
> 
> So I don't have exactly your model - mine is model 2, stepping 3 but I see
> something strange too, in dmesg:

I'm pretty sure the bug is in the merged 'x86-mm-for-linus' branch:
Either Andy's "PCID optimized TLB flushing" (would be my guess) or
'encrypted memory' support by Tom Lendacky.

(Bisecting is hard, because sometimes I can compile stuff for over 15
minutes without hitting the bug. At other times the machine locks up
hard when starting X11 already.)

-- 
Markus

^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: Current mainline git (24e700e291d52bd2) hangs when building e.g. perf
  2017-09-08  9:48                   ` Markus Trippelsdorf
@ 2017-09-08 10:35                     ` Ingo Molnar
  2017-09-08 10:39                       ` Markus Trippelsdorf
  0 siblings, 1 reply; 61+ messages in thread
From: Ingo Molnar @ 2017-09-08 10:35 UTC (permalink / raw)
  To: Markus Trippelsdorf
  Cc: Borislav Petkov, Thomas Gleixner, Peter Zijlstra, LKML,
	Ingo Molnar, Andy Lutomirski, Tom Lendacky


* Markus Trippelsdorf <markus@trippelsdorf.de> wrote:

> On 2017.09.08 at 11:16 +0200, Borislav Petkov wrote:
> > On Fri, Sep 08, 2017 at 10:05:36AM +0200, Borislav Petkov wrote:
> > > On Fri, Sep 08, 2017 at 08:26:44AM +0200, Thomas Gleixner wrote:
> > > > On Fri, 8 Sep 2017, Markus Trippelsdorf wrote:
> > > > 
> > > > CC+ Borislav. He might have access to such a beast
> > > 
> > > Can I have /proc/cpuinfo and dmesg pls, in order to see whether I have
> > > something similar?
> > > 
> > > Private mail's fine too.
> > 
> > So I don't have exactly your model - mine is model 2, stepping 3 but I see
> > something strange too, in dmesg:
> 
> I'm pretty sure the bug is in the merged 'x86-mm-for-linus' branch:
> Either Andy's "PCID optimized TLB flushing" (would be my guess) or
> 'encrypted memory' support by Tom Lendacky.
> 
> (Bisecting is hard, because sometimes I can compile stuff for over 15
> minutes without hitting the bug. At other times the machine locks up
> hard when starting X11 already.)

Do you have the 72c0098d92ce fix?

Thanks,

	Ingo

^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: Current mainline git (24e700e291d52bd2) hangs when building e.g. perf
  2017-09-08 10:35                     ` Ingo Molnar
@ 2017-09-08 10:39                       ` Markus Trippelsdorf
  2017-09-08 11:30                         ` Markus Trippelsdorf
  0 siblings, 1 reply; 61+ messages in thread
From: Markus Trippelsdorf @ 2017-09-08 10:39 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Borislav Petkov, Thomas Gleixner, Peter Zijlstra, LKML,
	Ingo Molnar, Andy Lutomirski, Tom Lendacky

On 2017.09.08 at 12:35 +0200, Ingo Molnar wrote:
> 
> * Markus Trippelsdorf <markus@trippelsdorf.de> wrote:
> 
> > On 2017.09.08 at 11:16 +0200, Borislav Petkov wrote:
> > > On Fri, Sep 08, 2017 at 10:05:36AM +0200, Borislav Petkov wrote:
> > > > On Fri, Sep 08, 2017 at 08:26:44AM +0200, Thomas Gleixner wrote:
> > > > > On Fri, 8 Sep 2017, Markus Trippelsdorf wrote:
> > > > > 
> > > > > CC+ Borislav. He might have access to such a beast
> > > > 
> > > > Can I have /proc/cpuinfo and dmesg pls, in order to see whether I have
> > > > something similar?
> > > > 
> > > > Private mail's fine too.
> > > 
> > > So I don't have exactly your model - mine is model 2, stepping 3 but I see
> > > something strange too, in dmesg:
> > 
> > I'm pretty sure the bug is in the merged 'x86-mm-for-linus' branch:
> > Either Andy's "PCID optimized TLB flushing" (would be my guess) or
> > 'encrypted memory' support by Tom Lendacky.
> > 
> > (Bisecting is hard, because sometimes I can compile stuff for over 15
> > minutes without hitting the bug. At other times the machine locks up
> > hard when starting X11 already.)
> 
> Do you have the 72c0098d92ce fix?

Yes. The bug still happens on the current git tree (which has the fix
already):
 % git describe
v4.13-9217-g5969d1bb3082

-- 
Markus

^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: Current mainline git (24e700e291d52bd2) hangs when building e.g. perf
  2017-09-08 10:39                       ` Markus Trippelsdorf
@ 2017-09-08 11:30                         ` Markus Trippelsdorf
  2017-09-08 16:12                           ` Andy Lutomirski
  0 siblings, 1 reply; 61+ messages in thread
From: Markus Trippelsdorf @ 2017-09-08 11:30 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Borislav Petkov, Thomas Gleixner, Peter Zijlstra, LKML,
	Ingo Molnar, Andy Lutomirski, Tom Lendacky

On 2017.09.08 at 12:39 +0200, Markus Trippelsdorf wrote:
> On 2017.09.08 at 12:35 +0200, Ingo Molnar wrote:
> > 
> > * Markus Trippelsdorf <markus@trippelsdorf.de> wrote:
> > 
> > > On 2017.09.08 at 11:16 +0200, Borislav Petkov wrote:
> > > > On Fri, Sep 08, 2017 at 10:05:36AM +0200, Borislav Petkov wrote:
> > > > > On Fri, Sep 08, 2017 at 08:26:44AM +0200, Thomas Gleixner wrote:
> > > > > > On Fri, 8 Sep 2017, Markus Trippelsdorf wrote:
> > > > > > 
> > > > > > CC+ Borislav. He might have access to such a beast
> > > > > 
> > > > > Can I have /proc/cpuinfo and dmesg pls, in order to see whether I have
> > > > > something similar?
> > > > > 
> > > > > Private mail's fine too.
> > > > 
> > > > So I don't have exactly your model - mine is model 2, stepping 3 but I see
> > > > something strange too, in dmesg:
> > > 
> > > I'm pretty sure the bug is in the merged 'x86-mm-for-linus' branch:
> > > Either Andy's "PCID optimized TLB flushing" (would be my guess) or
> > > 'encrypted memory' support by Tom Lendacky.
> > > 
> > > (Bisecting is hard, because sometimes I can compile stuff for over 15
> > > minutes without hitting the bug. At other times the machine locks up
> > > hard when starting X11 already.)
> > 
> > Do you have the 72c0098d92ce fix?
> 
> Yes. The bug still happens on the current git tree (which has the fix
> already):

The bug is definitely caused by Andy Lutomirski's PCID optimized TLB
flushing" patches. Tom is off the hook.

-- 
Markus

^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: Current mainline git (24e700e291d52bd2) hangs when building e.g. perf
  2017-09-08  9:16                 ` Borislav Petkov
  2017-09-08  9:48                   ` Markus Trippelsdorf
@ 2017-09-08 14:51                   ` Borislav Petkov
  1 sibling, 0 replies; 61+ messages in thread
From: Borislav Petkov @ 2017-09-08 14:51 UTC (permalink / raw)
  To: Markus Trippelsdorf
  Cc: Thomas Gleixner, Peter Zijlstra, LKML, Ingo Molnar, Andy Lutomirski

On Fri, Sep 08, 2017 at 11:16:14AM +0200, Borislav Petkov wrote:
...
> +blkid[1020]: segfault at 8 ip 00007fec7760c3fd sp 00007ffc9dd05890 error 4 in ld-linux-x86-64.so.2[7fec775fc000+22000]
> +blkid[1026]: segfault at 8 ip 00007f5a31ecc3fd sp 00007fffaf3604b0 error 4 in ld-linux-x86-64.so.2[7f5a31ebc000+22000]
> +logsave[1027]: segfault at 8 ip 00007f237d2033fd sp 00007fff53933e60 error 4 in ld-linux-x86-64.so.2[7f237d1f3000+22000]

Yap, definitely no segfaults with 4.13

-- 
Regards/Gruss,
    Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.

^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: Current mainline git (24e700e291d52bd2) hangs when building e.g. perf
  2017-09-08 11:30                         ` Markus Trippelsdorf
@ 2017-09-08 16:12                           ` Andy Lutomirski
  2017-09-08 17:16                             ` Markus Trippelsdorf
  0 siblings, 1 reply; 61+ messages in thread
From: Andy Lutomirski @ 2017-09-08 16:12 UTC (permalink / raw)
  To: Markus Trippelsdorf
  Cc: Ingo Molnar, Borislav Petkov, Thomas Gleixner, Peter Zijlstra,
	LKML, Ingo Molnar, Andy Lutomirski, Tom Lendacky

On Fri, Sep 8, 2017 at 4:30 AM, Markus Trippelsdorf
<markus@trippelsdorf.de> wrote:
> On 2017.09.08 at 12:39 +0200, Markus Trippelsdorf wrote:
>> On 2017.09.08 at 12:35 +0200, Ingo Molnar wrote:
>> >
>> > * Markus Trippelsdorf <markus@trippelsdorf.de> wrote:
>> >
>> > > On 2017.09.08 at 11:16 +0200, Borislav Petkov wrote:
>> > > > On Fri, Sep 08, 2017 at 10:05:36AM +0200, Borislav Petkov wrote:
>> > > > > On Fri, Sep 08, 2017 at 08:26:44AM +0200, Thomas Gleixner wrote:
>> > > > > > On Fri, 8 Sep 2017, Markus Trippelsdorf wrote:
>> > > > > >
>> > > > > > CC+ Borislav. He might have access to such a beast
>> > > > >
>> > > > > Can I have /proc/cpuinfo and dmesg pls, in order to see whether I have
>> > > > > something similar?
>> > > > >
>> > > > > Private mail's fine too.
>> > > >
>> > > > So I don't have exactly your model - mine is model 2, stepping 3 but I see
>> > > > something strange too, in dmesg:
>> > >
>> > > I'm pretty sure the bug is in the merged 'x86-mm-for-linus' branch:
>> > > Either Andy's "PCID optimized TLB flushing" (would be my guess) or
>> > > 'encrypted memory' support by Tom Lendacky.
>> > >
>> > > (Bisecting is hard, because sometimes I can compile stuff for over 15
>> > > minutes without hitting the bug. At other times the machine locks up
>> > > hard when starting X11 already.)
>> >
>> > Do you have the 72c0098d92ce fix?
>>
>> Yes. The bug still happens on the current git tree (which has the fix
>> already):
>
> The bug is definitely caused by Andy Lutomirski's PCID optimized TLB
> flushing" patches. Tom is off the hook.

I'm pretty sure it can't be PCID per se, since these CPUs are way too
old and are very unlikely to have PCID.

It could plausibly be the lazy TLB flushing changes.

^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: Current mainline git (24e700e291d52bd2) hangs when building e.g. perf
  2017-09-08 16:12                           ` Andy Lutomirski
@ 2017-09-08 17:16                             ` Markus Trippelsdorf
  2017-09-08 21:47                               ` Andy Lutomirski
  0 siblings, 1 reply; 61+ messages in thread
From: Markus Trippelsdorf @ 2017-09-08 17:16 UTC (permalink / raw)
  To: Andy Lutomirski
  Cc: Ingo Molnar, Borislav Petkov, Thomas Gleixner, Peter Zijlstra,
	LKML, Ingo Molnar, Tom Lendacky

On 2017.09.08 at 09:12 -0700, Andy Lutomirski wrote:
> On Fri, Sep 8, 2017 at 4:30 AM, Markus Trippelsdorf
> <markus@trippelsdorf.de> wrote:
> > On 2017.09.08 at 12:39 +0200, Markus Trippelsdorf wrote:
> >> On 2017.09.08 at 12:35 +0200, Ingo Molnar wrote:
> >> >
> >> > * Markus Trippelsdorf <markus@trippelsdorf.de> wrote:
> >> >
> >> > > On 2017.09.08 at 11:16 +0200, Borislav Petkov wrote:
> >> > > > On Fri, Sep 08, 2017 at 10:05:36AM +0200, Borislav Petkov wrote:
> >> > > > > On Fri, Sep 08, 2017 at 08:26:44AM +0200, Thomas Gleixner wrote:
> >> > > > > > On Fri, 8 Sep 2017, Markus Trippelsdorf wrote:
> >> > > > > >
> >> > > > > > CC+ Borislav. He might have access to such a beast
> >> > > > >
> >> > > > > Can I have /proc/cpuinfo and dmesg pls, in order to see whether I have
> >> > > > > something similar?
> >> > > > >
> >> > > > > Private mail's fine too.
> >> > > >
> >> > > > So I don't have exactly your model - mine is model 2, stepping 3 but I see
> >> > > > something strange too, in dmesg:
> >> > >
> >> > > I'm pretty sure the bug is in the merged 'x86-mm-for-linus' branch:
> >> > > Either Andy's "PCID optimized TLB flushing" (would be my guess) or
> >> > > 'encrypted memory' support by Tom Lendacky.
> >> > >
> >> > > (Bisecting is hard, because sometimes I can compile stuff for over 15
> >> > > minutes without hitting the bug. At other times the machine locks up
> >> > > hard when starting X11 already.)
> >> >
> >> > Do you have the 72c0098d92ce fix?
> >>
> >> Yes. The bug still happens on the current git tree (which has the fix
> >> already):
> >
> > The bug is definitely caused by Andy Lutomirski's PCID optimized TLB
> > flushing" patches. Tom is off the hook.
> 
> I'm pretty sure it can't be PCID per se, since these CPUs are way too
> old and are very unlikely to have PCID.

Yes, the CPU doesn't support PCID (,but it does support PGE).

> It could plausibly be the lazy TLB flushing changes.

Yes, I've narrowed it down to:

commit 94b1b03b519b81c494900cb112aa00ed205cc2d9
Author: Andy Lutomirski <luto@kernel.org>
Date:   Thu Jun 29 08:53:17 2017 -0700

    x86/mm: Rework lazy TLB mode and TLB freshness tracking


Theoretically you guys should be able to reproduce the issue by using
the "nopcid" boot option. 

-- 
Markus

^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: Current mainline git (24e700e291d52bd2) hangs when building e.g. perf
  2017-09-08 17:16                             ` Markus Trippelsdorf
@ 2017-09-08 21:47                               ` Andy Lutomirski
  2017-09-08 21:56                                 ` Borislav Petkov
  2017-09-09  8:13                                 ` Markus Trippelsdorf
  0 siblings, 2 replies; 61+ messages in thread
From: Andy Lutomirski @ 2017-09-08 21:47 UTC (permalink / raw)
  To: Markus Trippelsdorf
  Cc: Andy Lutomirski, Ingo Molnar, Borislav Petkov, Thomas Gleixner,
	Peter Zijlstra, LKML, Ingo Molnar, Tom Lendacky

On Fri, Sep 8, 2017 at 10:16 AM, Markus Trippelsdorf
<markus@trippelsdorf.de> wrote:
> On 2017.09.08 at 09:12 -0700, Andy Lutomirski wrote:
>> On Fri, Sep 8, 2017 at 4:30 AM, Markus Trippelsdorf
>> <markus@trippelsdorf.de> wrote:
>> > On 2017.09.08 at 12:39 +0200, Markus Trippelsdorf wrote:
>> >> On 2017.09.08 at 12:35 +0200, Ingo Molnar wrote:
>> >> >
>> >> > * Markus Trippelsdorf <markus@trippelsdorf.de> wrote:
>> >> >
>> >> > > On 2017.09.08 at 11:16 +0200, Borislav Petkov wrote:
>> >> > > > On Fri, Sep 08, 2017 at 10:05:36AM +0200, Borislav Petkov wrote:
>> >> > > > > On Fri, Sep 08, 2017 at 08:26:44AM +0200, Thomas Gleixner wrote:
>> >> > > > > > On Fri, 8 Sep 2017, Markus Trippelsdorf wrote:
>> >> > > > > >
>> >> > > > > > CC+ Borislav. He might have access to such a beast
>> >> > > > >
>> >> > > > > Can I have /proc/cpuinfo and dmesg pls, in order to see whether I have
>> >> > > > > something similar?
>> >> > > > >
>> >> > > > > Private mail's fine too.
>> >> > > >
>> >> > > > So I don't have exactly your model - mine is model 2, stepping 3 but I see
>> >> > > > something strange too, in dmesg:
>> >> > >
>> >> > > I'm pretty sure the bug is in the merged 'x86-mm-for-linus' branch:
>> >> > > Either Andy's "PCID optimized TLB flushing" (would be my guess) or
>> >> > > 'encrypted memory' support by Tom Lendacky.
>> >> > >
>> >> > > (Bisecting is hard, because sometimes I can compile stuff for over 15
>> >> > > minutes without hitting the bug. At other times the machine locks up
>> >> > > hard when starting X11 already.)
>> >> >
>> >> > Do you have the 72c0098d92ce fix?
>> >>
>> >> Yes. The bug still happens on the current git tree (which has the fix
>> >> already):
>> >
>> > The bug is definitely caused by Andy Lutomirski's PCID optimized TLB
>> > flushing" patches. Tom is off the hook.
>>
>> I'm pretty sure it can't be PCID per se, since these CPUs are way too
>> old and are very unlikely to have PCID.
>
> Yes, the CPU doesn't support PCID (,but it does support PGE).
>
>> It could plausibly be the lazy TLB flushing changes.
>
> Yes, I've narrowed it down to:
>
> commit 94b1b03b519b81c494900cb112aa00ed205cc2d9
> Author: Andy Lutomirski <luto@kernel.org>
> Date:   Thu Jun 29 08:53:17 2017 -0700
>
>     x86/mm: Rework lazy TLB mode and TLB freshness tracking
>
>
> Theoretically you guys should be able to reproduce the issue by using
> the "nopcid" boot option.
>

Any chance you could test with CONFIG_DEBUG_VM=y?  There are lots of
potentially useful assertions in that code.

Can you also post your /proc/cpuinfo?  And can you re-confirm that a
problematic guest kernel is causing problems in the *host*?

^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: Current mainline git (24e700e291d52bd2) hangs when building e.g. perf
  2017-09-08 21:47                               ` Andy Lutomirski
@ 2017-09-08 21:56                                 ` Borislav Petkov
  2017-09-08 23:07                                   ` Andy Lutomirski
  2017-09-09  6:39                                   ` Markus Trippelsdorf
  2017-09-09  8:13                                 ` Markus Trippelsdorf
  1 sibling, 2 replies; 61+ messages in thread
From: Borislav Petkov @ 2017-09-08 21:56 UTC (permalink / raw)
  To: Markus Trippelsdorf
  Cc: Andy Lutomirski, Ingo Molnar, Thomas Gleixner, Peter Zijlstra,
	LKML, Ingo Molnar, Tom Lendacky

On Fri, Sep 08, 2017 at 02:47:00PM -0700, Andy Lutomirski wrote:
> Any chance you could test with CONFIG_DEBUG_VM=y?  There are lots of
> potentially useful assertions in that code.
> 
> Can you also post your /proc/cpuinfo?  And can you re-confirm that a
> problematic guest kernel is causing problems in the *host*?

Also, have you seen any MCEs during early boot, after the freezes?

You probably wouldn't have because we don't log them on F10h due to
broken BIOSen. So add "mce=bootlog" to your grub and warm-reset your box
after one of those freezes and send me dmesg. It should have an MCE in
there, if it happens what I think it happens.

Thx.

-- 
Regards/Gruss,
    Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.

^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: Current mainline git (24e700e291d52bd2) hangs when building e.g. perf
  2017-09-08 21:56                                 ` Borislav Petkov
@ 2017-09-08 23:07                                   ` Andy Lutomirski
  2017-09-08 23:23                                     ` Linus Torvalds
  2017-09-09  6:39                                   ` Markus Trippelsdorf
  1 sibling, 1 reply; 61+ messages in thread
From: Andy Lutomirski @ 2017-09-08 23:07 UTC (permalink / raw)
  To: Borislav Petkov, Linus Torvalds
  Cc: Markus Trippelsdorf, Andy Lutomirski, Ingo Molnar,
	Thomas Gleixner, Peter Zijlstra, LKML, Ingo Molnar, Tom Lendacky

[Linus, I added you to get your opinion on whether the last bit here
is a problem.]

On Fri, Sep 8, 2017 at 2:56 PM, Borislav Petkov <bp@alien8.de> wrote:
> On Fri, Sep 08, 2017 at 02:47:00PM -0700, Andy Lutomirski wrote:
>> Any chance you could test with CONFIG_DEBUG_VM=y?  There are lots of
>> potentially useful assertions in that code.
>>
>> Can you also post your /proc/cpuinfo?  And can you re-confirm that a
>> problematic guest kernel is causing problems in the *host*?
>
> Also, have you seen any MCEs during early boot, after the freezes?
>
> You probably wouldn't have because we don't log them on F10h due to
> broken BIOSen. So add "mce=bootlog" to your grub and warm-reset your box
> after one of those freezes and send me dmesg. It should have an MCE in
> there, if it happens what I think it happens.
>

Here's my theory as to what's happening.

Before my patch, flush_tlb_mm_range() guaranteed that the range would
be flushed on all CPUs prior to returning.  With the patch, it only
promises that it will be flushed on all CPUs prior to anyone trying to
access it on the CPU in question.  This has two consequences:

1. A kernel thread that accidentally reads or writes a user address
could hit a stale TLB entry.  This seems harmless in the sense that
this can only happen if we already have a bug.

2. The CPU itself could see the TLB entry and do nefarious
architecturally invisible things with it.

I bet that #2 dramatically increases the chance that we hit erratum 383.

I can imagine a case where we have a problem even in the absence of an
erratum.  Specifically, suppose we have some page mapped.  CPU A
writes to it using combining (it's mapped WC or an explicit streaming
write is done).  CPU B removes the TLB entry and does
flush_tlb_mm_range().  CPU B would expect that all writes to the page
are done, but CPU A's write is still sitting in the streaming buffers.

I *think* this is impossible because CPU A's mm_cpumask manipulations
are atomic and should therefore force out the streaming write buffers,
but maybe there's some other scenario where this matters.

--Andy

^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: Current mainline git (24e700e291d52bd2) hangs when building e.g. perf
  2017-09-08 23:07                                   ` Andy Lutomirski
@ 2017-09-08 23:23                                     ` Linus Torvalds
  2017-09-09  0:00                                       ` Andy Lutomirski
  0 siblings, 1 reply; 61+ messages in thread
From: Linus Torvalds @ 2017-09-08 23:23 UTC (permalink / raw)
  To: Andy Lutomirski
  Cc: Borislav Petkov, Markus Trippelsdorf, Ingo Molnar,
	Thomas Gleixner, Peter Zijlstra, LKML, Ingo Molnar, Tom Lendacky

On Fri, Sep 8, 2017 at 4:07 PM, Andy Lutomirski <luto@kernel.org> wrote:
>
> I *think* this is impossible because CPU A's mm_cpumask manipulations
> are atomic and should therefore force out the streaming write buffers,
> but maybe there's some other scenario where this matters.

I don't think atomic memops do that.

They enforce globally visible ordering, but since they happen in the
cache and is not actually visible to outside, that doesn't actually
affect any streaming write buffers.

Then, if somebody else requests a cacheline that we have exclusive
ownership to, the write buffers just need to flush before we give up
that cacheline.

So a locked memory op is *not* serializing, it only enforces memory
ordering. Big difference.

Only fully serializing instructions will serialize with the write
buffers, and they are expensive as hell (partly exactly _due_ to these
kinds of issues).

So this change to delay invalidation does sound fairly scary..

              Linus

^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: Current mainline git (24e700e291d52bd2) hangs when building e.g. perf
  2017-09-08 23:23                                     ` Linus Torvalds
@ 2017-09-09  0:00                                       ` Andy Lutomirski
  2017-09-09  1:05                                         ` Linus Torvalds
  0 siblings, 1 reply; 61+ messages in thread
From: Andy Lutomirski @ 2017-09-09  0:00 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: Andy Lutomirski, Borislav Petkov, Markus Trippelsdorf,
	Ingo Molnar, Thomas Gleixner, Peter Zijlstra, LKML, Ingo Molnar,
	Tom Lendacky

On Fri, Sep 8, 2017 at 4:23 PM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> On Fri, Sep 8, 2017 at 4:07 PM, Andy Lutomirski <luto@kernel.org> wrote:
>>
>> I *think* this is impossible because CPU A's mm_cpumask manipulations
>> are atomic and should therefore force out the streaming write buffers,
>> but maybe there's some other scenario where this matters.
>
> I don't think atomic memops do that.
>
> They enforce globally visible ordering, but since they happen in the
> cache and is not actually visible to outside, that doesn't actually
> affect any streaming write buffers.
>
> Then, if somebody else requests a cacheline that we have exclusive
> ownership to, the write buffers just need to flush before we give up
> that cacheline.
>
> So a locked memory op is *not* serializing, it only enforces memory
> ordering. Big difference.
>
> Only fully serializing instructions will serialize with the write
> buffers, and they are expensive as hell (partly exactly _due_ to these
> kinds of issues).

I'm not convinced.  The SDM says (Vol 3, 11.3, under WC):

If the WC buffer is partially filled, the writes may be delayed until
the next occurrence of a serializing event; such as, an SFENCE or
MFENCE instruction, CPUID execution, a read or write to uncached
memory, an interrupt occurrence, or a LOCK instruction execution.

Thanks, Intel, for definiing "serializing event" differently here than
anywhere else in the whole manual.

Anyhow, I can think of two cases where this is relevant.

1. The kernel wants to reclaim a page of normal memory, so it unmaps
it and flushes.  Another CPU has an entry for that page in its WC
buffer.  I don't think we care whether the flush causes the WC write
to really hit RAM because it's unobservable -- we just need to make
sure it is ordered, as seen by software, before the flush operation
completes.  From the quote above, I think we're okay here.

2. The kernel is unmapping some IO memory (e.g. a GPU command buffer).
It wants a guarantee that, when flush_tlb_mm_range returns, all CPUs
are really done writing to it.  Here I'm less convinced.  The SDM
quote certainly suggests to me that we have a promise that the WC
write has *started* before flush_tlb_mm_range returns, but I'm not
sure I believe that it's guaranteed to have retired.  That being said,
I'm not sure that this is observable either -- anything the kernel
does that depends on the writes being done presumably has to involve
further IO to the same device, and I suspect that WC write; lock write
to memory; observe that write on another CPU; IO on other CPU really
does guarantee that everything hits the bus in order.

FWIW, I'm not sure that we ever had a guarantee that IO writes were
all fully done before flush_tlb_mm_range would return.  Can't they
still be hanging out in the PCI bridge or whatever until someone
*reads* that device?

>
> So this change to delay invalidation does sound fairly scary..

With PCID, we're fundamentally delaying invalidation.  I think the
worry is more that we're not guaranteeing that every CPU that could
have accessed the page being flushed has executed a real serializing
instruction.

If we want to force invalidation/serialization, I can see two
reasonable solutions:

1. Revert this behavior change: continue sending IPIs to lazy CPUs.
The problem is that this will totally wipe out the performance gain,
and that gain seemed to be substantial in some microbenchmarks at
least.

2. Get rid of lazy mode.  With PCID at least, switching to init_mm isn't so bad.

I'd prefer to leave it as is except on the buggy AMD CPUs, though,
since the current code is nice and fast.

^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: Current mainline git (24e700e291d52bd2) hangs when building e.g. perf
  2017-09-09  0:00                                       ` Andy Lutomirski
@ 2017-09-09  1:05                                         ` Linus Torvalds
  2017-09-09  1:39                                           ` Andy Lutomirski
  0 siblings, 1 reply; 61+ messages in thread
From: Linus Torvalds @ 2017-09-09  1:05 UTC (permalink / raw)
  To: Andy Lutomirski
  Cc: Borislav Petkov, Markus Trippelsdorf, Ingo Molnar,
	Thomas Gleixner, Peter Zijlstra, LKML, Ingo Molnar, Tom Lendacky

On Fri, Sep 8, 2017 at 5:00 PM, Andy Lutomirski <luto@kernel.org> wrote:
>
> I'm not convinced.  The SDM says (Vol 3, 11.3, under WC):
>
> If the WC buffer is partially filled, the writes may be delayed until
> the next occurrence of a serializing event; such as, an SFENCE or
> MFENCE instruction, CPUID execution, a read or write to uncached
> memory, an interrupt occurrence, or a LOCK instruction execution.
>
> Thanks, Intel, for definiing "serializing event" differently here than
> anywhere else in the whole manual.

Yeah, it's really badly defined. Ok, maybe a locked instruction does
actually wait for it.. It should be invisible to anything, regardless.

> 1. The kernel wants to reclaim a page of normal memory, so it unmaps
> it and flushes.  Another CPU has an entry for that page in its WC
> buffer.  I don't think we care whether the flush causes the WC write
> to really hit RAM because it's unobservable -- we just need to make
> sure it is ordered, as seen by software, before the flush operation
> completes.  From the quote above, I think we're okay here.

Agreed.

> 2. The kernel is unmapping some IO memory (e.g. a GPU command buffer).
> It wants a guarantee that, when flush_tlb_mm_range returns, all CPUs
> are really done writing to it.  Here I'm less convinced.  The SDM
> quote certainly suggests to me that we have a promise that the WC
> write has *started* before flush_tlb_mm_range returns, but I'm not
> sure I believe that it's guaranteed to have retired.

If others have writable TLB entries, what keeps them from just
continuing to write for a long time afterwards?

> I'd prefer to leave it as is except on the buggy AMD CPUs, though,
> since the current code is nice and fast.

So is there a patch to detect the 383 erratum and serialize for those?
I may have missed that part.

              Linus

^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: Current mainline git (24e700e291d52bd2) hangs when building e.g. perf
  2017-09-09  1:05                                         ` Linus Torvalds
@ 2017-09-09  1:39                                           ` Andy Lutomirski
  2017-09-09 17:49                                             ` Andy Lutomirski
  0 siblings, 1 reply; 61+ messages in thread
From: Andy Lutomirski @ 2017-09-09  1:39 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: Andy Lutomirski, Borislav Petkov, Markus Trippelsdorf,
	Ingo Molnar, Thomas Gleixner, Peter Zijlstra, LKML, Ingo Molnar,
	Tom Lendacky



> On Sep 8, 2017, at 6:05 PM, Linus Torvalds <torvalds@linux-foundation.org> wrote:
> 
>> On Fri, Sep 8, 2017 at 5:00 PM, Andy Lutomirski <luto@kernel.org> wrote:
>> 
>> I'm not convinced.  The SDM says (Vol 3, 11.3, under WC):
>> 
>> If the WC buffer is partially filled, the writes may be delayed until
>> the next occurrence of a serializing event; such as, an SFENCE or
>> MFENCE instruction, CPUID execution, a read or write to uncached
>> memory, an interrupt occurrence, or a LOCK instruction execution.
>> 
>> Thanks, Intel, for definiing "serializing event" differently here than
>> anywhere else in the whole manual.
> 
> Yeah, it's really badly defined. Ok, maybe a locked instruction does
> actually wait for it.. It should be invisible to anything, regardless.
> 
>> 1. The kernel wants to reclaim a page of normal memory, so it unmaps
>> it and flushes.  Another CPU has an entry for that page in its WC
>> buffer.  I don't think we care whether the flush causes the WC write
>> to really hit RAM because it's unobservable -- we just need to make
>> sure it is ordered, as seen by software, before the flush operation
>> completes.  From the quote above, I think we're okay here.
> 
> Agreed.
> 
>> 2. The kernel is unmapping some IO memory (e.g. a GPU command buffer).
>> It wants a guarantee that, when flush_tlb_mm_range returns, all CPUs
>> are really done writing to it.  Here I'm less convinced.  The SDM
>> quote certainly suggests to me that we have a promise that the WC
>> write has *started* before flush_tlb_mm_range returns, but I'm not
>> sure I believe that it's guaranteed to have retired.
> 
> If others have writable TLB entries, what keeps them from just
> continuing to write for a long time afterwards?

Whoever unmaps the resource by kicking out their drm fd?  I admit I'm just trying to think of the worst case.

> 
>> I'd prefer to leave it as is except on the buggy AMD CPUs, though,
>> since the current code is nice and fast.
> 
> So is there a patch to detect the 383 erratum and serialize for those?
> I may have missed that part.
> 

The patch is in my head.  It's imaginarily attached to this email.


>              Linus

^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: Current mainline git (24e700e291d52bd2) hangs when building e.g. perf
  2017-09-08 21:56                                 ` Borislav Petkov
  2017-09-08 23:07                                   ` Andy Lutomirski
@ 2017-09-09  6:39                                   ` Markus Trippelsdorf
  2017-09-09 10:18                                     ` Borislav Petkov
  1 sibling, 1 reply; 61+ messages in thread
From: Markus Trippelsdorf @ 2017-09-09  6:39 UTC (permalink / raw)
  To: Borislav Petkov
  Cc: Andy Lutomirski, Ingo Molnar, Thomas Gleixner, Peter Zijlstra,
	LKML, Ingo Molnar, Tom Lendacky

On 2017.09.08 at 23:56 +0200, Borislav Petkov wrote:
> On Fri, Sep 08, 2017 at 02:47:00PM -0700, Andy Lutomirski wrote:
> > Any chance you could test with CONFIG_DEBUG_VM=y?  There are lots of
> > potentially useful assertions in that code.
> > 
> > Can you also post your /proc/cpuinfo?  And can you re-confirm that a
> > problematic guest kernel is causing problems in the *host*?
> 
> Also, have you seen any MCEs during early boot, after the freezes?
> 
> You probably wouldn't have because we don't log them on F10h due to
> broken BIOSen. So add "mce=bootlog" to your grub and warm-reset your box
> after one of those freezes and send me dmesg. It should have an MCE in
> there, if it happens what I think it happens.

Unfortunately the machine hangs in the BIOS after the first warm-reset.
Probably when it encounters an MCE it doesn't expect. I have to
warm-reset a second time to get to the boot-loader. So it is impossible
for me to see any possible MCE.

-- 
Markus

^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: Current mainline git (24e700e291d52bd2) hangs when building e.g. perf
  2017-09-08 21:47                               ` Andy Lutomirski
  2017-09-08 21:56                                 ` Borislav Petkov
@ 2017-09-09  8:13                                 ` Markus Trippelsdorf
  1 sibling, 0 replies; 61+ messages in thread
From: Markus Trippelsdorf @ 2017-09-09  8:13 UTC (permalink / raw)
  To: Andy Lutomirski
  Cc: Ingo Molnar, Borislav Petkov, Thomas Gleixner, Peter Zijlstra,
	LKML, Ingo Molnar, Tom Lendacky

On 2017.09.08 at 14:47 -0700, Andy Lutomirski wrote:
> On Fri, Sep 8, 2017 at 10:16 AM, Markus Trippelsdorf
> <markus@trippelsdorf.de> wrote:
> > On 2017.09.08 at 09:12 -0700, Andy Lutomirski wrote:
> >> On Fri, Sep 8, 2017 at 4:30 AM, Markus Trippelsdorf
> >> <markus@trippelsdorf.de> wrote:
> >> > On 2017.09.08 at 12:39 +0200, Markus Trippelsdorf wrote:
> >> >> On 2017.09.08 at 12:35 +0200, Ingo Molnar wrote:
> >> >> >
> >> >> > * Markus Trippelsdorf <markus@trippelsdorf.de> wrote:
> >> >> >
> >> >> > > On 2017.09.08 at 11:16 +0200, Borislav Petkov wrote:
> >> >> > > > On Fri, Sep 08, 2017 at 10:05:36AM +0200, Borislav Petkov wrote:
> >> >> > > > > On Fri, Sep 08, 2017 at 08:26:44AM +0200, Thomas Gleixner wrote:
> >> >> > > > > > On Fri, 8 Sep 2017, Markus Trippelsdorf wrote:
> >> >> > > > > >
> >> >> > > > > > CC+ Borislav. He might have access to such a beast
> >> >> > > > >
> >> >> > > > > Can I have /proc/cpuinfo and dmesg pls, in order to see whether I have
> >> >> > > > > something similar?
> >> >> > > > >
> >> >> > > > > Private mail's fine too.
> >> >> > > >
> >> >> > > > So I don't have exactly your model - mine is model 2, stepping 3 but I see
> >> >> > > > something strange too, in dmesg:
> >> >> > >
> >> >> > > I'm pretty sure the bug is in the merged 'x86-mm-for-linus' branch:
> >> >> > > Either Andy's "PCID optimized TLB flushing" (would be my guess) or
> >> >> > > 'encrypted memory' support by Tom Lendacky.
> >> >> > >
> >> >> > > (Bisecting is hard, because sometimes I can compile stuff for over 15
> >> >> > > minutes without hitting the bug. At other times the machine locks up
> >> >> > > hard when starting X11 already.)
> >> >> >
> >> >> > Do you have the 72c0098d92ce fix?
> >> >>
> >> >> Yes. The bug still happens on the current git tree (which has the fix
> >> >> already):
> >> >
> >> > The bug is definitely caused by Andy Lutomirski's PCID optimized TLB
> >> > flushing" patches. Tom is off the hook.
> >>
> >> I'm pretty sure it can't be PCID per se, since these CPUs are way too
> >> old and are very unlikely to have PCID.
> >
> > Yes, the CPU doesn't support PCID (,but it does support PGE).
> >
> >> It could plausibly be the lazy TLB flushing changes.
> >
> > Yes, I've narrowed it down to:
> >
> > commit 94b1b03b519b81c494900cb112aa00ed205cc2d9
> > Author: Andy Lutomirski <luto@kernel.org>
> > Date:   Thu Jun 29 08:53:17 2017 -0700
> >
> >     x86/mm: Rework lazy TLB mode and TLB freshness tracking
> >
> >
> > Theoretically you guys should be able to reproduce the issue by using
> > the "nopcid" boot option.
> >
> 
> Any chance you could test with CONFIG_DEBUG_VM=y?  There are lots of
> potentially useful assertions in that code.

CONFIG_DEBUG_VM=y doesn't change anything. I still get the hard hang
without anything in the logs.

> Can you also post your /proc/cpuinfo?  And can you re-confirm that a
> problematic guest kernel is causing problems in the *host*?

processor       : 0
vendor_id       : AuthenticAMD
cpu family      : 16
model           : 4
model name      : AMD Phenom(tm) II X4 955 Processor
stepping        : 2
microcode       : 0x10000db
cpu MHz         : 3210.960
cache size      : 512 KB
physical id     : 0
siblings        : 4
core id         : 0
cpu cores       : 4
apicid          : 0
initial apicid  : 0
fpu             : yes
fpu_exception   : yes
cpuid level     : 5
wp              : yes
flags           : 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 3dnowext 3dnow constant_tsc rep_good nopl nonstop_tsc cpuid extd_apicid pni monitor cx16 popcnt lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs skinit wdt hw_pstate vmmcall npt lbrv svm_lock nrip_save
bugs            : tlb_mmatch apic_c1e fxsave_leak sysret_ss_attrs null_seg amd_e400
bogomips        : 6424.50
TLB size        : 1024 4K pages
clflush size    : 64
cache_alignment : 64
address sizes   : 48 bits physical, 48 bits virtual
power management: ts ttp tm stc 100mhzsteps hwpstate

Unfortunately I cannot reproduce the qemu (kvm) problem anymore. (Perhaps
I have not tried long enough). 
Anyway, kvm has code that should handle erratum_383.

-- 
Markus

^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: Current mainline git (24e700e291d52bd2) hangs when building e.g. perf
  2017-09-09  6:39                                   ` Markus Trippelsdorf
@ 2017-09-09 10:18                                     ` Borislav Petkov
  2017-09-09 11:07                                       ` Markus Trippelsdorf
  0 siblings, 1 reply; 61+ messages in thread
From: Borislav Petkov @ 2017-09-09 10:18 UTC (permalink / raw)
  To: Markus Trippelsdorf
  Cc: Andy Lutomirski, Ingo Molnar, Thomas Gleixner, Peter Zijlstra,
	LKML, Ingo Molnar, Tom Lendacky

On Sat, Sep 09, 2017 at 08:39:08AM +0200, Markus Trippelsdorf wrote:
> Unfortunately the machine hangs in the BIOS after the first warm-reset.
> Probably when it encounters an MCE it doesn't expect. I have to
> warm-reset a second time to get to the boot-loader. So it is impossible
> for me to see any possible MCE.

Ok, let's try to disable the syncflood before the test. As root:

# V=$(setpci -s 18.3 0x44.l)
# echo $V
# V=$(printf "0x%x" $((0x$V & ~(1 << 21))))
# setpci -s 18.3 0x44.l=$V
# echo $V

I've added the echo $V so that you can paste them as a reply so that I
can see their values.

And then run the triggering sequence again, better not on an X terminal
but in the text console to see any MCEs when it freezes. I remember you
saying that you don't have serial connected to it so catching the MCE
would need more staring :)

Thx.

-- 
Regards/Gruss,
    Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.

^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: Current mainline git (24e700e291d52bd2) hangs when building e.g. perf
  2017-09-09 10:18                                     ` Borislav Petkov
@ 2017-09-09 11:07                                       ` Markus Trippelsdorf
  2017-09-09 13:07                                         ` Borislav Petkov
  0 siblings, 1 reply; 61+ messages in thread
From: Markus Trippelsdorf @ 2017-09-09 11:07 UTC (permalink / raw)
  To: Borislav Petkov
  Cc: Andy Lutomirski, Ingo Molnar, Thomas Gleixner, Peter Zijlstra,
	LKML, Ingo Molnar, Tom Lendacky

On 2017.09.09 at 12:18 +0200, Borislav Petkov wrote:
> On Sat, Sep 09, 2017 at 08:39:08AM +0200, Markus Trippelsdorf wrote:
> > Unfortunately the machine hangs in the BIOS after the first warm-reset.
> > Probably when it encounters an MCE it doesn't expect. I have to
> > warm-reset a second time to get to the boot-loader. So it is impossible
> > for me to see any possible MCE.
> 
> Ok, let's try to disable the syncflood before the test. As root:
> 
> # V=$(setpci -s 18.3 0x44.l)
> # echo $V

4a70005c

> # V=$(printf "0x%x" $((0x$V & ~(1 << 21))))
> # setpci -s 18.3 0x44.l=$V
> # echo $V

0x4a50005c

> I've added the echo $V so that you can paste them as a reply so that I
> can see their values.
> 
> And then run the triggering sequence again, better not on an X terminal
> but in the text console to see any MCEs when it freezes. I remember you
> saying that you don't have serial connected to it so catching the MCE
> would need more staring :)

It doesn't work. Compiling in a text console just freezes the machine
before any MCE gets printed.

-- 
Markus

^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: Current mainline git (24e700e291d52bd2) hangs when building e.g. perf
  2017-09-09 11:07                                       ` Markus Trippelsdorf
@ 2017-09-09 13:07                                         ` Borislav Petkov
  2017-09-09 13:37                                           ` Markus Trippelsdorf
  0 siblings, 1 reply; 61+ messages in thread
From: Borislav Petkov @ 2017-09-09 13:07 UTC (permalink / raw)
  To: Markus Trippelsdorf
  Cc: Andy Lutomirski, Ingo Molnar, Thomas Gleixner, Peter Zijlstra,
	LKML, Ingo Molnar, Tom Lendacky

On Sat, Sep 09, 2017 at 01:07:49PM +0200, Markus Trippelsdorf wrote:
> It doesn't work. Compiling in a text console just freezes the machine
> before any MCE gets printed.

Ok, let's turn off all syncflood bits. Hunk below. Do a

$ dmesg | grep syncflood

to check it worked. It says

[    1.557017] quirk_syncflood: 0x44: 0xa900044
[    1.561431] quirk_syncflood: 0x44: wrote 0xa800040
[    1.566361] quirk_syncflood: 0x180: 0x700022
[    1.570775] quirk_syncflood: 0x180: wrote 0x20

here.

Also, make sure you boot with "pci=check_enable_amd_mmconf" on the
kernel cmdline because someone broke extended PCI cfg space again on
those machines. At least on my test box here... But that's something
I'll deal with later. :-\

Thanks.

---
diff --git a/arch/x86/kernel/quirks.c b/arch/x86/kernel/quirks.c
index eaa591cfd98b..c6a4430d2222 100644
--- a/arch/x86/kernel/quirks.c
+++ b/arch/x86/kernel/quirks.c
@@ -626,6 +626,32 @@ static void amd_disable_seq_and_redirect_scrub(struct pci_dev *dev)
 DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_16H_NB_F3,
 			amd_disable_seq_and_redirect_scrub);
 
+static void quirk_syncflood(struct pci_dev *misc)
+{
+	u32 val;
+
+	pci_read_config_dword(misc, 0x44, &val);
+	pr_info("%s: 0x44: 0x%x\n", __func__, val);
+
+	val &= ~(BIT(30) | BIT(21) | BIT(20) | BIT(2));
+
+	pci_write_config_dword(misc, 0x44, val);
+	pci_read_config_dword(misc, 0x44, &val);
+	pr_info("%s: 0x44: wrote 0x%x\n", __func__, val);
+
+	pci_read_config_dword(misc, 0x180, &val);
+	pr_info("%s: 0x180: 0x%x\n", __func__, val);
+
+	val &= ~(BIT(22) | BIT(21) | BIT(20) | BIT(9) | BIT(8) | BIT(7) | BIT(6) | BIT(1));
+
+	pci_write_config_dword(misc, 0x180, val);
+	pci_read_config_dword(misc, 0x180, &val);
+	pr_info("%s: 0x180: wrote 0x%x\n", __func__, val);
+}
+
+DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_10H_NB_MISC,
+			quirk_syncflood);
+
 #if defined(CONFIG_X86_64) && defined(CONFIG_X86_MCE)
 #include <linux/jump_label.h>
 #include <asm/string_64.h>




-- 
Regards/Gruss,
    Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.

^ permalink raw reply related	[flat|nested] 61+ messages in thread

* Re: Current mainline git (24e700e291d52bd2) hangs when building e.g. perf
  2017-09-09 13:07                                         ` Borislav Petkov
@ 2017-09-09 13:37                                           ` Markus Trippelsdorf
  2017-09-09 13:39                                             ` Markus Trippelsdorf
  0 siblings, 1 reply; 61+ messages in thread
From: Markus Trippelsdorf @ 2017-09-09 13:37 UTC (permalink / raw)
  To: Borislav Petkov
  Cc: Andy Lutomirski, Ingo Molnar, Thomas Gleixner, Peter Zijlstra,
	LKML, Ingo Molnar, Tom Lendacky

On 2017.09.09 at 15:07 +0200, Borislav Petkov wrote:
> On Sat, Sep 09, 2017 at 01:07:49PM +0200, Markus Trippelsdorf wrote:
> > It doesn't work. Compiling in a text console just freezes the machine
> > before any MCE gets printed.
> 
> Ok, let's turn off all syncflood bits. Hunk below. Do a
> 
> $ dmesg | grep syncflood
> 
> to check it worked. It says
> 
> [    1.557017] quirk_syncflood: 0x44: 0xa900044
> [    1.561431] quirk_syncflood: 0x44: wrote 0xa800040
> [    1.566361] quirk_syncflood: 0x180: 0x700022
> [    1.570775] quirk_syncflood: 0x180: wrote 0x20
> 
> here.
> 
> Also, make sure you boot with "pci=check_enable_amd_mmconf" on the
> kernel cmdline because someone broke extended PCI cfg space again on
> those machines. At least on my test box here... But that's something
> I'll deal with later. :-\

Thanks. This one worked:

mce: [Hardware Error]: CPU: 0 Machine Check Exception: 4 Bank 4: fa000010000b0c0f
mce: [Hardware Error]: TSC b75d6ef4ad MISC c00a00001000000
mce: [Hardware Error]: PROCESSOR 2:100f42 TIME 1504963036 SOCKET 0 APIC 0 microcode 1000db

(I had to copy the above by hand, so it may not be 100% accurate).

-- 
Markus

^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: Current mainline git (24e700e291d52bd2) hangs when building e.g. perf
  2017-09-09 13:37                                           ` Markus Trippelsdorf
@ 2017-09-09 13:39                                             ` Markus Trippelsdorf
  2017-09-09 14:07                                               ` Borislav Petkov
  0 siblings, 1 reply; 61+ messages in thread
From: Markus Trippelsdorf @ 2017-09-09 13:39 UTC (permalink / raw)
  To: Borislav Petkov
  Cc: Andy Lutomirski, Ingo Molnar, Thomas Gleixner, Peter Zijlstra,
	LKML, Ingo Molnar, Tom Lendacky

On 2017.09.09 at 15:37 +0200, Markus Trippelsdorf wrote:
> On 2017.09.09 at 15:07 +0200, Borislav Petkov wrote:
> > On Sat, Sep 09, 2017 at 01:07:49PM +0200, Markus Trippelsdorf wrote:
> > > It doesn't work. Compiling in a text console just freezes the machine
> > > before any MCE gets printed.
> > 
> > Ok, let's turn off all syncflood bits. Hunk below. Do a
> > 
> > $ dmesg | grep syncflood
> > 
> > to check it worked. It says
> > 
> > [    1.557017] quirk_syncflood: 0x44: 0xa900044
> > [    1.561431] quirk_syncflood: 0x44: wrote 0xa800040
> > [    1.566361] quirk_syncflood: 0x180: 0x700022
> > [    1.570775] quirk_syncflood: 0x180: wrote 0x20
> > 
> > here.
> > 
> > Also, make sure you boot with "pci=check_enable_amd_mmconf" on the
> > kernel cmdline because someone broke extended PCI cfg space again on
> > those machines. At least on my test box here... But that's something
> > I'll deal with later. :-\
> 
> Thanks. This one worked:
> 
> mce: [Hardware Error]: CPU: 0 Machine Check Exception: 4 Bank 4: fa000010000b0c0f
> mce: [Hardware Error]: TSC b75d6ef4ad MISC c00a00001000000
> mce: [Hardware Error]: PROCESSOR 2:100f42 TIME 1504963036 SOCKET 0 APIC 0 microcode 1000db

Decoded:

CPU: 0 Machine Check Exception: 4 Bank 4: fa000010000b0c0f
Hardware event. This is not a software error.
CPU 0 0 data cache TSC b75d6ef4ad 
TIME 1504963036 Sat Sep  9 15:17:16 2017
STATUS 0 MCGSTATUS 0
CPUID Vendor AMD Family 16 Model 4
SOCKET 0 APIC 0 microcode 1000db


-- 
Markus

^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: Current mainline git (24e700e291d52bd2) hangs when building e.g. perf
  2017-09-09 13:39                                             ` Markus Trippelsdorf
@ 2017-09-09 14:07                                               ` Borislav Petkov
  2017-09-09 14:20                                                 ` Markus Trippelsdorf
  0 siblings, 1 reply; 61+ messages in thread
From: Borislav Petkov @ 2017-09-09 14:07 UTC (permalink / raw)
  To: Markus Trippelsdorf
  Cc: Andy Lutomirski, Ingo Molnar, Thomas Gleixner, Peter Zijlstra,
	LKML, Ingo Molnar, Tom Lendacky

On Sat, Sep 09, 2017 at 03:39:54PM +0200, Markus Trippelsdorf wrote:
> > mce: [Hardware Error]: CPU: 0 Machine Check Exception: 4 Bank 4: fa000010000b0c0f
> > mce: [Hardware Error]: TSC b75d6ef4ad MISC c00a00001000000
> > mce: [Hardware Error]: PROCESSOR 2:100f42 TIME 1504963036 SOCKET 0 APIC 0 microcode 1000db
> 
> Decoded:
> 
> CPU: 0 Machine Check Exception: 4 Bank 4: fa000010000b0c0f
> Hardware event. This is not a software error.
> CPU 0 0 data cache TSC b75d6ef4ad 
> TIME 1504963036 Sat Sep  9 15:17:16 2017
> STATUS 0 MCGSTATUS 0
> CPUID Vendor AMD Family 16 Model 4
> SOCKET 0 APIC 0 microcode 1000db

Yeah, this is not really decoding it - I need to address that case of
uncorrectable MCE not being decoded too.

In any case, it is not E383:

MC4_STATUS[Val|Over|UC|EN|MiscV|PCC|UECC|EEC: GART cache table walk encountered an invalid PTE (0x05)|ET: TLB(tt:GEN;ll:LG)]: 0xfa0020000005001b

And those should actually be masked out:

"BIOS is recommended to mask GART table walk errors by setting the bit
in MSRC001_0048 corresponding to F3x40[GartTblWkEn]."

And we disable those but for some reason, it doesn't stick :-)

Do

# modprobe msr
# rdmsr -a 0x00000410
# rdmsr -a 0xc0010048

as root.

Thanks.

-- 
Regards/Gruss,
    Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.

^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: Current mainline git (24e700e291d52bd2) hangs when building e.g. perf
  2017-09-09 14:07                                               ` Borislav Petkov
@ 2017-09-09 14:20                                                 ` Markus Trippelsdorf
  2017-09-09 14:33                                                   ` Borislav Petkov
  0 siblings, 1 reply; 61+ messages in thread
From: Markus Trippelsdorf @ 2017-09-09 14:20 UTC (permalink / raw)
  To: Borislav Petkov
  Cc: Andy Lutomirski, Ingo Molnar, Thomas Gleixner, Peter Zijlstra,
	LKML, Ingo Molnar, Tom Lendacky

On 2017.09.09 at 16:07 +0200, Borislav Petkov wrote:
> On Sat, Sep 09, 2017 at 03:39:54PM +0200, Markus Trippelsdorf wrote:
> > > mce: [Hardware Error]: CPU: 0 Machine Check Exception: 4 Bank 4: fa000010000b0c0f
> > > mce: [Hardware Error]: TSC b75d6ef4ad MISC c00a00001000000
> > > mce: [Hardware Error]: PROCESSOR 2:100f42 TIME 1504963036 SOCKET 0 APIC 0 microcode 1000db
> > 
> > Decoded:
> > 
> > CPU: 0 Machine Check Exception: 4 Bank 4: fa000010000b0c0f
> > Hardware event. This is not a software error.
> > CPU 0 0 data cache TSC b75d6ef4ad 
> > TIME 1504963036 Sat Sep  9 15:17:16 2017
> > STATUS 0 MCGSTATUS 0
> > CPUID Vendor AMD Family 16 Model 4
> > SOCKET 0 APIC 0 microcode 1000db
> 
> Yeah, this is not really decoding it - I need to address that case of
> uncorrectable MCE not being decoded too.
> 
> In any case, it is not E383:
> 
> MC4_STATUS[Val|Over|UC|EN|MiscV|PCC|UECC|EEC: GART cache table walk encountered an invalid PTE (0x05)|ET: TLB(tt:GEN;ll:LG)]: 0xfa0020000005001b
> 
> And those should actually be masked out:
> 
> "BIOS is recommended to mask GART table walk errors by setting the bit
> in MSRC001_0048 corresponding to F3x40[GartTblWkEn]."
> 
> And we disable those but for some reason, it doesn't stick :-)
> 
> Do
> 
> # rdmsr -a 0x00000410

3fffffff                                    
0                                           
0                                           
0 

> # rdmsr -a 0xc0010048

780400                                      
780400                                      
780400                                      
780400 

-- 
Markus

^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: Current mainline git (24e700e291d52bd2) hangs when building e.g. perf
  2017-09-09 14:20                                                 ` Markus Trippelsdorf
@ 2017-09-09 14:33                                                   ` Borislav Petkov
  2017-09-09 14:43                                                     ` Markus Trippelsdorf
  0 siblings, 1 reply; 61+ messages in thread
From: Borislav Petkov @ 2017-09-09 14:33 UTC (permalink / raw)
  To: Markus Trippelsdorf
  Cc: Andy Lutomirski, Ingo Molnar, Thomas Gleixner, Peter Zijlstra,
	LKML, Ingo Molnar, Tom Lendacky

On Sat, Sep 09, 2017 at 04:20:14PM +0200, Markus Trippelsdorf wrote:
> > # rdmsr -a 0x00000410
> 
> 3fffffff
> 0
> 0
> 0

WTF?! Those should be equal on every CPU. Yikes, we need to pay
attention to those... Grrr.

# wrmsr -a 0x00000410 0x3ffffbff

should fix your issue.

-- 
Regards/Gruss,
    Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.

^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: Current mainline git (24e700e291d52bd2) hangs when building e.g. perf
  2017-09-09 14:33                                                   ` Borislav Petkov
@ 2017-09-09 14:43                                                     ` Markus Trippelsdorf
  2017-09-09 16:32                                                       ` Markus Trippelsdorf
  0 siblings, 1 reply; 61+ messages in thread
From: Markus Trippelsdorf @ 2017-09-09 14:43 UTC (permalink / raw)
  To: Borislav Petkov
  Cc: Andy Lutomirski, Ingo Molnar, Thomas Gleixner, Peter Zijlstra,
	LKML, Ingo Molnar, Tom Lendacky

On 2017.09.09 at 16:33 +0200, Borislav Petkov wrote:
> On Sat, Sep 09, 2017 at 04:20:14PM +0200, Markus Trippelsdorf wrote:
> > > # rdmsr -a 0x00000410
> > 
> > 3fffffff
> > 0
> > 0
> > 0
> 
> WTF?! Those should be equal on every CPU. Yikes, we need to pay
> attention to those... Grrr.
> 
> # wrmsr -a 0x00000410 0x3ffffbff
> 
> should fix your issue.

No, it doesn't work:

x4 ~ # rdmsr -a 0x00000410
3fffffff                                    
0                                           
0                                           
0                                           
x4 ~ # wrmsr -a 0x00000410 0x3ffffbff
x4 ~ # rdmsr -a 0x00000410
3ffffbff                                    
0                                           
0                                           
0 

-- 
Markus

^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: Current mainline git (24e700e291d52bd2) hangs when building e.g. perf
  2017-09-09 14:43                                                     ` Markus Trippelsdorf
@ 2017-09-09 16:32                                                       ` Markus Trippelsdorf
  2017-09-09 17:05                                                         ` Borislav Petkov
  0 siblings, 1 reply; 61+ messages in thread
From: Markus Trippelsdorf @ 2017-09-09 16:32 UTC (permalink / raw)
  To: Borislav Petkov
  Cc: Andy Lutomirski, Ingo Molnar, Thomas Gleixner, Peter Zijlstra,
	LKML, Ingo Molnar, Tom Lendacky

On 2017.09.09 at 16:43 +0200, Markus Trippelsdorf wrote:
> On 2017.09.09 at 16:33 +0200, Borislav Petkov wrote:
> > On Sat, Sep 09, 2017 at 04:20:14PM +0200, Markus Trippelsdorf wrote:
> > > > # rdmsr -a 0x00000410
> > > 
> > > 3fffffff
> > > 0
> > > 0
> > > 0
> > 
> > WTF?! Those should be equal on every CPU. Yikes, we need to pay
> > attention to those... Grrr.
> > 
> > # wrmsr -a 0x00000410 0x3ffffbff
> > 
> > should fix your issue.
> 
> No, it doesn't work:
> 
> x4 ~ # rdmsr -a 0x00000410
> 3fffffff                                    
> 0                                           
> 0                                           
> 0                                           
> x4 ~ # wrmsr -a 0x00000410 0x3ffffbff
> x4 ~ # rdmsr -a 0x00000410
> 3ffffbff                                    
> 0                                           
> 0                                           
> 0 

Also tried the following patch. It does not help.

diff --git a/arch/x86/kernel/cpu/mcheck/mce.c b/arch/x86/kernel/cpu/mcheck/mce.c
index 3b413065c613..9ee1edb0929f 100644
--- a/arch/x86/kernel/cpu/mcheck/mce.c
+++ b/arch/x86/kernel/cpu/mcheck/mce.c
@@ -1580,7 +1580,7 @@ static int __mcheck_cpu_apply_quirks(struct cpuinfo_x86 *c)
 
 	/* This should be disabled by the BIOS, but isn't always */
 	if (c->x86_vendor == X86_VENDOR_AMD) {
-		if (c->x86 == 15 && cfg->banks > 4) {
+		if ((c->x86 == 15 || c->x86 == 16) && cfg->banks > 4) {
 			/*
 			 * disable GART TBL walk error reporting, which
 			 * trips off incorrectly with the IOMMU & 3ware

-- 
Markus

^ permalink raw reply related	[flat|nested] 61+ messages in thread

* Re: Current mainline git (24e700e291d52bd2) hangs when building e.g. perf
  2017-09-09 16:32                                                       ` Markus Trippelsdorf
@ 2017-09-09 17:05                                                         ` Borislav Petkov
  2017-09-09 17:23                                                           ` Markus Trippelsdorf
  0 siblings, 1 reply; 61+ messages in thread
From: Borislav Petkov @ 2017-09-09 17:05 UTC (permalink / raw)
  To: Markus Trippelsdorf
  Cc: Andy Lutomirski, Ingo Molnar, Thomas Gleixner, Peter Zijlstra,
	LKML, Ingo Molnar, Tom Lendacky

On Sat, Sep 09, 2017 at 06:32:25PM +0200, Markus Trippelsdorf wrote:
> Also tried the following patch. It does not help.

Ok, another theory. This one still needs to be fixed properly but that
for later.

For some reason (insufficient coffee maybe), I have mistyped your
MCi_STATUS value earlier. Your mail says it is "fa000010000b0c0f". Do
you still have a screen photo to verify it?

Because if so, the correct error type is:

MC4_STATUS[Val|Over|UC|EN|MiscV|PCC|EEC: Protocol error (link, L3, probe filter) (0x0b)|ET: BUS(pp:OBS;t:NOTIMOUT;r4:GEN;ii:GEN;ll:LG)]: 0xfa000010000b0c0f

And for that I'd need the MC4_ADDR value too.

So can you please apply the patch below ontop of the syncflood quirk
patch and retrigger, make a photo of the MCE and send it to me?

Thanks.

---
commit e84e5ad290c7c26af69a721148f404766529509b
Author: Borislav Petkov <bp@suse.de>
Date:   Sat Sep 9 00:55:50 2017 +0200

    x86/MCE/AMD: Collect error info even if valid bits are not set
    
    The MCA banks log error info into MCA_ADDR, MCA_MISC0, and MCA_SYND even
    if the corresponding valid bits are not set:
    
    "Error handlers should save the values in MCA_ADDR, MCA_MISC0,
    and MCA_SYND even if MCA_STATUS[AddrV], MCA_STATUS[MiscV], and
    MCA_STATUS[SyndV] are zero."
    
    Do so by setting those bits so that code down the MCE processing path
    doesn't need to be changed.
    
    Signed-off-by: Borislav Petkov <bp@suse.de>

diff --git a/arch/x86/kernel/cpu/mcheck/mce.c b/arch/x86/kernel/cpu/mcheck/mce.c
index 3b413065c613..c63c7ef326c7 100644
--- a/arch/x86/kernel/cpu/mcheck/mce.c
+++ b/arch/x86/kernel/cpu/mcheck/mce.c
@@ -436,6 +436,20 @@ static inline void mce_gather_info(struct mce *m, struct pt_regs *regs)
 		if (mca_cfg.rip_msr)
 			m->ip = mce_rdmsrl(mca_cfg.rip_msr);
 	}
+
+	/*
+	 * Error handlers should save the values in MCA_ADDR, MCA_MISC0, and
+	 * MCA_SYND even if MCA_STATUS[AddrV], MCA_STATUS[MiscV], and
+	 * MCA_STATUS[SyndV] are zero.
+	 */
+	if (m->cpuvendor == X86_VENDOR_AMD) {
+		u64 status = MCI_STATUS_ADDRV | MCI_STATUS_MISCV;
+
+		if (mce_flags.smca)
+			status |= MCI_STATUS_SYNDV;
+
+		m->status |= status;
+	}
 }
 
 int mce_available(struct cpuinfo_x86 *c)

-- 
Regards/Gruss,
    Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.

^ permalink raw reply related	[flat|nested] 61+ messages in thread

* Re: Current mainline git (24e700e291d52bd2) hangs when building e.g. perf
  2017-09-09 17:05                                                         ` Borislav Petkov
@ 2017-09-09 17:23                                                           ` Markus Trippelsdorf
  2017-09-09 17:36                                                             ` Borislav Petkov
  0 siblings, 1 reply; 61+ messages in thread
From: Markus Trippelsdorf @ 2017-09-09 17:23 UTC (permalink / raw)
  To: Borislav Petkov
  Cc: Andy Lutomirski, Ingo Molnar, Thomas Gleixner, Peter Zijlstra,
	LKML, Ingo Molnar, Tom Lendacky

On 2017.09.09 at 19:05 +0200, Borislav Petkov wrote:
> On Sat, Sep 09, 2017 at 06:32:25PM +0200, Markus Trippelsdorf wrote:
> > Also tried the following patch. It does not help.
> 
> Ok, another theory. This one still needs to be fixed properly but that
> for later.
> 
> For some reason (insufficient coffee maybe), I have mistyped your
> MCi_STATUS value earlier. Your mail says it is "fa000010000b0c0f". Do
> you still have a screen photo to verify it?

I double checked and the value is correct.

> Because if so, the correct error type is:
> 
> MC4_STATUS[Val|Over|UC|EN|MiscV|PCC|EEC: Protocol error (link, L3, probe filter) (0x0b)|ET: BUS(pp:OBS;t:NOTIMOUT;r4:GEN;ii:GEN;ll:LG)]: 0xfa000010000b0c0f
> 
> And for that I'd need the MC4_ADDR value too.
> 
> So can you please apply the patch below ontop of the syncflood quirk
> patch and retrigger, make a photo of the MCE and send it to me?

Hmm, the output is exactly the same as before your patch.

-- 
Markus

^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: Current mainline git (24e700e291d52bd2) hangs when building e.g. perf
  2017-09-09 17:23                                                           ` Markus Trippelsdorf
@ 2017-09-09 17:36                                                             ` Borislav Petkov
  2017-09-09 18:14                                                               ` Markus Trippelsdorf
  0 siblings, 1 reply; 61+ messages in thread
From: Borislav Petkov @ 2017-09-09 17:36 UTC (permalink / raw)
  To: Markus Trippelsdorf
  Cc: Andy Lutomirski, Ingo Molnar, Thomas Gleixner, Peter Zijlstra,
	LKML, Ingo Molnar, Tom Lendacky

On Sat, Sep 09, 2017 at 07:23:52PM +0200, Markus Trippelsdorf wrote:
> Hmm, the output is exactly the same as before your patch.

Bah, that patch doesn't account for the fact that we're rereading the
status field again in do_machine_check().

Ok, let's force MCi_ADDR out. Ontop:

---
diff --git a/arch/x86/kernel/cpu/mcheck/mce.c b/arch/x86/kernel/cpu/mcheck/mce.c
index c63c7ef326c7..e5580da2c491 100644
--- a/arch/x86/kernel/cpu/mcheck/mce.c
+++ b/arch/x86/kernel/cpu/mcheck/mce.c
@@ -240,8 +240,7 @@ static void __print_mce(struct mce *m)
 	}
 
 	pr_emerg(HW_ERR "TSC %llx ", m->tsc);
-	if (m->addr)
-		pr_cont("ADDR %llx ", m->addr);
+	pr_cont("ADDR %llx ", m->addr);
 	if (m->misc)
 		pr_cont("MISC %llx ", m->misc);
 
@@ -636,8 +635,9 @@ static void mce_read_aux(struct mce *m, int i)
 	if (m->status & MCI_STATUS_MISCV)
 		m->misc = mce_rdmsrl(msr_ops.misc(i));
 
+	m->addr = mce_rdmsrl(msr_ops.addr(i));
+
 	if (m->status & MCI_STATUS_ADDRV) {
-		m->addr = mce_rdmsrl(msr_ops.addr(i));
 
 		/*
 		 * Mask the reported address by the reported granularity.

---
Thanks.

-- 
Regards/Gruss,
    Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.

^ permalink raw reply related	[flat|nested] 61+ messages in thread

* Re: Current mainline git (24e700e291d52bd2) hangs when building e.g. perf
  2017-09-09  1:39                                           ` Andy Lutomirski
@ 2017-09-09 17:49                                             ` Andy Lutomirski
  2017-09-09 18:02                                               ` Linus Torvalds
  0 siblings, 1 reply; 61+ messages in thread
From: Andy Lutomirski @ 2017-09-09 17:49 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: Andy Lutomirski, Borislav Petkov, Markus Trippelsdorf,
	Ingo Molnar, Thomas Gleixner, Peter Zijlstra, LKML, Ingo Molnar,
	Tom Lendacky

On Fri, Sep 8, 2017 at 6:39 PM, Andy Lutomirski <luto@amacapital.net> wrote:
>
>
>> On Sep 8, 2017, at 6:05 PM, Linus Torvalds <torvalds@linux-foundation.org> wrote:
>>
>>> On Fri, Sep 8, 2017 at 5:00 PM, Andy Lutomirski <luto@kernel.org> wrote:
>>>
>>> I'm not convinced.  The SDM says (Vol 3, 11.3, under WC):
>>>
>>> If the WC buffer is partially filled, the writes may be delayed until
>>> the next occurrence of a serializing event; such as, an SFENCE or
>>> MFENCE instruction, CPUID execution, a read or write to uncached
>>> memory, an interrupt occurrence, or a LOCK instruction execution.
>>>
>>> Thanks, Intel, for definiing "serializing event" differently here than
>>> anywhere else in the whole manual.
>>
>> Yeah, it's really badly defined. Ok, maybe a locked instruction does
>> actually wait for it.. It should be invisible to anything, regardless.
>>
>>> 1. The kernel wants to reclaim a page of normal memory, so it unmaps
>>> it and flushes.  Another CPU has an entry for that page in its WC
>>> buffer.  I don't think we care whether the flush causes the WC write
>>> to really hit RAM because it's unobservable -- we just need to make
>>> sure it is ordered, as seen by software, before the flush operation
>>> completes.  From the quote above, I think we're okay here.
>>
>> Agreed.
>>
>>> 2. The kernel is unmapping some IO memory (e.g. a GPU command buffer).
>>> It wants a guarantee that, when flush_tlb_mm_range returns, all CPUs
>>> are really done writing to it.  Here I'm less convinced.  The SDM
>>> quote certainly suggests to me that we have a promise that the WC
>>> write has *started* before flush_tlb_mm_range returns, but I'm not
>>> sure I believe that it's guaranteed to have retired.
>>
>> If others have writable TLB entries, what keeps them from just
>> continuing to write for a long time afterwards?
>
> Whoever unmaps the resource by kicking out their drm fd?  I admit I'm just trying to think of the worst case.
>
>>
>>> I'd prefer to leave it as is except on the buggy AMD CPUs, though,
>>> since the current code is nice and fast.
>>
>> So is there a patch to detect the 383 erratum and serialize for those?
>> I may have missed that part.
>>
>
> The patch is in my head.  It's imaginarily attached to this email.

After contemplating the info from Boris and Markus, I think I need to
add a #3 to the list of reasons my patch could be problematic:

3. If a CPU frees a page table (or PUD or PMD or whatever), that CPU
will flush before the memory goes back to the system.  If that flush
is deferred on a different CPU that has the pointer to the freed table
cached in its TLB, then that CPU can speculatively load complete
garbage into its TLB.

I don't think this should be observable, but I can easily imagine it
triggering errata or weird ill-advised machine checks.

Anyway, if I need change the behavior back, I can do it in one of two
ways.  I can just switch to init_mm instead of going lazy, which is
expensive, but not *that* expensive on CPUs with PCID.  Or I can do it
the way we used to do it and send the flush IPI to lazy CPUs.  The
latter will only have a performance impact when a flush happens, but
the performance hit is much higher when there's a flush.

--Andy

^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: Current mainline git (24e700e291d52bd2) hangs when building e.g. perf
  2017-09-09 17:49                                             ` Andy Lutomirski
@ 2017-09-09 18:02                                               ` Linus Torvalds
  0 siblings, 0 replies; 61+ messages in thread
From: Linus Torvalds @ 2017-09-09 18:02 UTC (permalink / raw)
  To: Andy Lutomirski
  Cc: Borislav Petkov, Markus Trippelsdorf, Ingo Molnar,
	Thomas Gleixner, Peter Zijlstra, LKML, Ingo Molnar, Tom Lendacky

On Sat, Sep 9, 2017 at 10:49 AM, Andy Lutomirski <luto@kernel.org> wrote:
>
> Anyway, if I need change the behavior back, I can do it in one of two
> ways.  I can just switch to init_mm instead of going lazy, which is
> expensive, but not *that* expensive on CPUs with PCID.  Or I can do it
> the way we used to do it and send the flush IPI to lazy CPUs.  The
> latter will only have a performance impact when a flush happens, but
> the performance hit is much higher when there's a flush.

Why not both?

Let's at least entertain the idea. In particular, we don't send IPI's
to *all* CPU's. We only send them to the set of CPU's that could have
that MM cached.

And that set _may_ be very limited. In the best case, it's just the
current CPU, and no IPI is needed at all.

Which means that maybe we can use that set of CPU's as guidance to how
we should treat lazy.

We can *also* take PCID support into account.

So what I would suggest is something like

 - if we have PCID support, _and_ the set of CPU's is more than just
us, just switch to init_mm. The switch is cheaper than the IPI's.

 - otherwise do what we used to do, with the IPI.

The exact heuristics could be tuned later, but considering Markus's
report, and considering that not so many people have really even
heavily tested the new code yet (so _one_ report now means that there
are probably a shitload of machines that would show it later), I
really think we need to steer back towards our old behavior. But at
the same time, I think we can take advantage of newer CPU's that _do_
have PCID.

Hmm?

                  Linus

^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: Current mainline git (24e700e291d52bd2) hangs when building e.g. perf
  2017-09-09 17:36                                                             ` Borislav Petkov
@ 2017-09-09 18:14                                                               ` Markus Trippelsdorf
  2017-09-09 18:26                                                                 ` Borislav Petkov
  2017-09-09 18:26                                                                 ` Linus Torvalds
  0 siblings, 2 replies; 61+ messages in thread
From: Markus Trippelsdorf @ 2017-09-09 18:14 UTC (permalink / raw)
  To: Borislav Petkov
  Cc: Andy Lutomirski, Ingo Molnar, Thomas Gleixner, Peter Zijlstra,
	LKML, Ingo Molnar, Tom Lendacky

On 2017.09.09 at 19:36 +0200, Borislav Petkov wrote:
> On Sat, Sep 09, 2017 at 07:23:52PM +0200, Markus Trippelsdorf wrote:
> > Hmm, the output is exactly the same as before your patch.
> 
> Bah, that patch doesn't account for the fact that we're rereading the
> status field again in do_machine_check().
> 
> Ok, let's force MCi_ADDR out. Ontop:

Thanks, will try it later.

I think the issue gets fixed by:
 
 # wrmsr -a 0xc0010015 0x1000018

Setting bit 3 of the Hardware Configuration Register to 1.

Quote for the docs:
»TlbCacheDis: cacheable memory disable. Read-write. 0=Enables performance optimization that
assumes PML4, PDP, PDE, and PTE entries are in cacheable WB-DRAM; memory type checks may
be bypassed, and addresses outside of WB-DRAM may result in undefined behavior or NB protocol
errors. 1=Disables performance optimization and allows PML4, PDP, PDE and PTE entries to be in
any memory type. Operating systems that maintain page tables in memory types other than WB-
DRAM must set TlbCacheDis to insure proper operation.«


I've been successfully compiling for over 15 minutes now. 

-- 
Markus

^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: Current mainline git (24e700e291d52bd2) hangs when building e.g. perf
  2017-09-09 18:14                                                               ` Markus Trippelsdorf
@ 2017-09-09 18:26                                                                 ` Borislav Petkov
  2017-09-09 18:46                                                                   ` Markus Trippelsdorf
  2017-09-09 18:26                                                                 ` Linus Torvalds
  1 sibling, 1 reply; 61+ messages in thread
From: Borislav Petkov @ 2017-09-09 18:26 UTC (permalink / raw)
  To: Markus Trippelsdorf
  Cc: Andy Lutomirski, Ingo Molnar, Thomas Gleixner, Peter Zijlstra,
	LKML, Ingo Molnar, Tom Lendacky

On Sat, Sep 09, 2017 at 08:14:45PM +0200, Markus Trippelsdorf wrote:
>  # wrmsr -a 0xc0010015 0x1000018

I know but I'd still like to see the exact error signature.

So please clear that bit 3 and try to catch that MCE together with the
ADDR.

Thanks.


-- 
Regards/Gruss,
    Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.

^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: Current mainline git (24e700e291d52bd2) hangs when building e.g. perf
  2017-09-09 18:14                                                               ` Markus Trippelsdorf
  2017-09-09 18:26                                                                 ` Borislav Petkov
@ 2017-09-09 18:26                                                                 ` Linus Torvalds
  2017-09-09 18:29                                                                   ` Borislav Petkov
  2017-09-12  7:14                                                                   ` Markus Trippelsdorf
  1 sibling, 2 replies; 61+ messages in thread
From: Linus Torvalds @ 2017-09-09 18:26 UTC (permalink / raw)
  To: Markus Trippelsdorf
  Cc: Borislav Petkov, Andy Lutomirski, Ingo Molnar, Thomas Gleixner,
	Peter Zijlstra, LKML, Ingo Molnar, Tom Lendacky

On Sat, Sep 9, 2017 at 11:14 AM, Markus Trippelsdorf
<markus@trippelsdorf.de> wrote:
>
> I think the issue gets fixed by:
>
>  # wrmsr -a 0xc0010015 0x1000018
>
> Setting bit 3 of the Hardware Configuration Register to 1.
>
> Quote for the docs:
> »TlbCacheDis: cacheable memory disable. Read-write. 0=Enables performance optimization that
> assumes PML4, PDP, PDE, and PTE entries are in cacheable WB-DRAM

Uhhuh.

The page directories should *definitely* always be in cacheable
memory, so it should be ok for that bit to be 0, and it's possible
that setting it to 1 will seriously screw up performance.

But the fact that that fixes it for you does indicate that it's not
just a stale TLB entry or something, it really is some CPU using page
tables after they have been free'd and been re-allocated to something
else (and *then* they may point to garbage).

So I do think it's a sign that we definitely need that IPI for you.

                Linus

^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: Current mainline git (24e700e291d52bd2) hangs when building e.g. perf
  2017-09-09 18:26                                                                 ` Linus Torvalds
@ 2017-09-09 18:29                                                                   ` Borislav Petkov
  2017-09-09 18:47                                                                     ` Linus Torvalds
  2017-09-12  7:14                                                                   ` Markus Trippelsdorf
  1 sibling, 1 reply; 61+ messages in thread
From: Borislav Petkov @ 2017-09-09 18:29 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: Markus Trippelsdorf, Andy Lutomirski, Ingo Molnar,
	Thomas Gleixner, Peter Zijlstra, LKML, Ingo Molnar, Tom Lendacky

On Sat, Sep 09, 2017 at 11:26:27AM -0700, Linus Torvalds wrote:
> But the fact that that fixes it for you does indicate that it's not
> just a stale TLB entry or something, it really is some CPU using page
> tables after they have been free'd and been re-allocated to something
> else (and *then* they may point to garbage).

Cool, I was trying to think of a good use case how we'd hit that. I
guess you just gave one. :)

Thx.

-- 
Regards/Gruss,
    Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.

^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: Current mainline git (24e700e291d52bd2) hangs when building e.g. perf
  2017-09-09 18:26                                                                 ` Borislav Petkov
@ 2017-09-09 18:46                                                                   ` Markus Trippelsdorf
  2017-09-09 19:11                                                                     ` Borislav Petkov
  0 siblings, 1 reply; 61+ messages in thread
From: Markus Trippelsdorf @ 2017-09-09 18:46 UTC (permalink / raw)
  To: Borislav Petkov
  Cc: Andy Lutomirski, Ingo Molnar, Thomas Gleixner, Peter Zijlstra,
	LKML, Ingo Molnar, Tom Lendacky

On 2017.09.09 at 20:26 +0200, Borislav Petkov wrote:
> On Sat, Sep 09, 2017 at 08:14:45PM +0200, Markus Trippelsdorf wrote:
> >  # wrmsr -a 0xc0010015 0x1000018
> 
> I know but I'd still like to see the exact error signature.
> 
> So please clear that bit 3 and try to catch that MCE together with the
> ADDR.

OK. ADDR is 12. The rest is the same (modulo time).

-- 
Markus

^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: Current mainline git (24e700e291d52bd2) hangs when building e.g. perf
  2017-09-09 18:29                                                                   ` Borislav Petkov
@ 2017-09-09 18:47                                                                     ` Linus Torvalds
  2017-09-09 19:09                                                                       ` Borislav Petkov
  0 siblings, 1 reply; 61+ messages in thread
From: Linus Torvalds @ 2017-09-09 18:47 UTC (permalink / raw)
  To: Borislav Petkov
  Cc: Markus Trippelsdorf, Andy Lutomirski, Ingo Molnar,
	Thomas Gleixner, Peter Zijlstra, LKML, Ingo Molnar, Tom Lendacky

On Sat, Sep 9, 2017 at 11:29 AM, Borislav Petkov <bp@alien8.de> wrote:
> On Sat, Sep 09, 2017 at 11:26:27AM -0700, Linus Torvalds wrote:
>> But the fact that that fixes it for you does indicate that it's not
>> just a stale TLB entry or something, it really is some CPU using page
>> tables after they have been free'd and been re-allocated to something
>> else (and *then* they may point to garbage).
>
> Cool, I was trying to think of a good use case how we'd hit that. I
> guess you just gave one. :)

The thing is, even with the delayed TLB flushing, I don't think it
should be *so* delayed that we should be seeing a TLB fill from
garbage page tables.

But the part in Andy's patch that worries me the most is that

+               cpumask_clear_cpu(cpu, mm_cpumask(mm));

in enter_lazy_tlb(). It means that we won't be notified by peopel
invalidating the page tables, and while we then do re-validate the TLB
when we switch back from lazy mode, I still worry. I'm not entirely
convinced by that tlb_gen logic.

I can't actually see anything *wrong* in the tlb_gen logic, but it worries me.

            Linus

^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: Current mainline git (24e700e291d52bd2) hangs when building e.g. perf
  2017-09-09 18:47                                                                     ` Linus Torvalds
@ 2017-09-09 19:09                                                                       ` Borislav Petkov
  2017-09-09 19:21                                                                         ` Linus Torvalds
  2017-09-09 19:28                                                                         ` Andy Lutomirski
  0 siblings, 2 replies; 61+ messages in thread
From: Borislav Petkov @ 2017-09-09 19:09 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: Markus Trippelsdorf, Andy Lutomirski, Ingo Molnar,
	Thomas Gleixner, Peter Zijlstra, LKML, Ingo Molnar, Tom Lendacky

On Sat, Sep 09, 2017 at 11:47:33AM -0700, Linus Torvalds wrote:
> The thing is, even with the delayed TLB flushing, I don't think it
> should be *so* delayed that we should be seeing a TLB fill from
> garbage page tables.

Yeah, but we can't know what kind of speculative accesses happen between
the removal from the mask and the actual flushing.

> But the part in Andy's patch that worries me the most is that
> 
> +               cpumask_clear_cpu(cpu, mm_cpumask(mm));
> 
> in enter_lazy_tlb(). It means that we won't be notified by peopel
> invalidating the page tables, and while we then do re-validate the TLB
> when we switch back from lazy mode, I still worry. I'm not entirely
> convinced by that tlb_gen logic.
> 
> I can't actually see anything *wrong* in the tlb_gen logic, but it worries me.

Yeah, sounds like we're uncovering a situation of possibly stale
mappings which we haven't had before. Or at least widening that window.

And I still need to analyze what that MCE on Markus' machine is saying
exactly. The TlbCacheDis thing is an optimization which does away with
memory type checks. But we probably will have to disable it on those
boxes as we can't guarantee pagetable elements are all in WB mem...

Or we can guarantee them in WB but the lazy flushing delays the actual
clearing of the TLB entries so much so that they end up pointing to
garbage, as you say, which is not in WB mem and thus causes the protocol
error.

Hmm. All still wet.

-- 
Regards/Gruss,
    Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.

^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: Current mainline git (24e700e291d52bd2) hangs when building e.g. perf
  2017-09-09 18:46                                                                   ` Markus Trippelsdorf
@ 2017-09-09 19:11                                                                     ` Borislav Petkov
  2017-09-09 19:19                                                                       ` Borislav Petkov
  0 siblings, 1 reply; 61+ messages in thread
From: Borislav Petkov @ 2017-09-09 19:11 UTC (permalink / raw)
  To: Markus Trippelsdorf
  Cc: Andy Lutomirski, Ingo Molnar, Thomas Gleixner, Peter Zijlstra,
	LKML, Ingo Molnar, Tom Lendacky

On Sat, Sep 09, 2017 at 08:46:38PM +0200, Markus Trippelsdorf wrote:
> OK. ADDR is 12. The rest is the same (modulo time).

I'm assuming that's 12 hex... yeah, "ADDR %llx ".

Dammit, that should have "0x" prepended. Grrr, I'll fix all that next
week.

-- 
Regards/Gruss,
    Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.

^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: Current mainline git (24e700e291d52bd2) hangs when building e.g. perf
  2017-09-09 19:11                                                                     ` Borislav Petkov
@ 2017-09-09 19:19                                                                       ` Borislav Petkov
  0 siblings, 0 replies; 61+ messages in thread
From: Borislav Petkov @ 2017-09-09 19:19 UTC (permalink / raw)
  To: Markus Trippelsdorf, Linus Torvalds
  Cc: Andy Lutomirski, Ingo Molnar, Thomas Gleixner, Peter Zijlstra,
	LKML, Ingo Molnar, Tom Lendacky

On Sat, Sep 09, 2017 at 09:11:33PM +0200, Borislav Petkov wrote:
> On Sat, Sep 09, 2017 at 08:46:38PM +0200, Markus Trippelsdorf wrote:
> > OK. ADDR is 12. The rest is the same (modulo time).
> 
> I'm assuming that's 12 hex... yeah, "ADDR %llx ".
> 
> Dammit, that should have "0x" prepended. Grrr, I'll fix all that next
> week.

Ok, that 0x12 looks like it fits the TlbCacheDis thing (bits [5:1]):

"0_1001b

Link: A specific coherent-only packet from a CPU was issued to an
IO link. This may be caused by software which addresses page table
structures in a memory type other than cacheable WB-DRAM without
properly configuring MSRC001_0015[TlbCacheDis]. This may occur, for
example, when page table structure addresses are above top of memory. In
such cases, the NB will generate an MCE if it sees a mismatch between
the memory operation generated by the core and the link type. See
2.9.3.1.2 [Determining The Access Destination for CPU Accesses]."

-- 
Regards/Gruss,
    Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.

^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: Current mainline git (24e700e291d52bd2) hangs when building e.g. perf
  2017-09-09 19:09                                                                       ` Borislav Petkov
@ 2017-09-09 19:21                                                                         ` Linus Torvalds
  2017-09-09 19:28                                                                         ` Andy Lutomirski
  1 sibling, 0 replies; 61+ messages in thread
From: Linus Torvalds @ 2017-09-09 19:21 UTC (permalink / raw)
  To: Borislav Petkov
  Cc: Markus Trippelsdorf, Andy Lutomirski, Ingo Molnar,
	Thomas Gleixner, Peter Zijlstra, LKML, Ingo Molnar, Tom Lendacky

On Sat, Sep 9, 2017 at 12:09 PM, Borislav Petkov <bp@alien8.de> wrote:
>
> Yeah, but we can't know what kind of speculative accesses happen between
> the removal from the mask and the actual flushing.

Indeed. The speculative kernel thread accesses while lazy could easily
trigger this.

And I guess those are pretty fundamental. So..

            Linus

^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: Current mainline git (24e700e291d52bd2) hangs when building e.g. perf
  2017-09-09 19:09                                                                       ` Borislav Petkov
  2017-09-09 19:21                                                                         ` Linus Torvalds
@ 2017-09-09 19:28                                                                         ` Andy Lutomirski
  2017-09-09 19:37                                                                           ` Borislav Petkov
  2017-09-11  1:12                                                                           ` Rik van Riel
  1 sibling, 2 replies; 61+ messages in thread
From: Andy Lutomirski @ 2017-09-09 19:28 UTC (permalink / raw)
  To: Borislav Petkov
  Cc: Linus Torvalds, Markus Trippelsdorf, Andy Lutomirski,
	Ingo Molnar, Thomas Gleixner, Peter Zijlstra, LKML, Ingo Molnar,
	Tom Lendacky, Rik van Riel

On Sat, Sep 9, 2017 at 12:09 PM, Borislav Petkov <bp@alien8.de> wrote:
> On Sat, Sep 09, 2017 at 11:47:33AM -0700, Linus Torvalds wrote:
>> The thing is, even with the delayed TLB flushing, I don't think it
>> should be *so* delayed that we should be seeing a TLB fill from
>> garbage page tables.
>
> Yeah, but we can't know what kind of speculative accesses happen between
> the removal from the mask and the actual flushing.
>
>> But the part in Andy's patch that worries me the most is that
>>
>> +               cpumask_clear_cpu(cpu, mm_cpumask(mm));
>>
>> in enter_lazy_tlb(). It means that we won't be notified by peopel
>> invalidating the page tables, and while we then do re-validate the TLB
>> when we switch back from lazy mode, I still worry. I'm not entirely
>> convinced by that tlb_gen logic.
>>
>> I can't actually see anything *wrong* in the tlb_gen logic, but it worries me.
>
> Yeah, sounds like we're uncovering a situation of possibly stale
> mappings which we haven't had before. Or at least widening that window.
>
> And I still need to analyze what that MCE on Markus' machine is saying
> exactly. The TlbCacheDis thing is an optimization which does away with
> memory type checks. But we probably will have to disable it on those
> boxes as we can't guarantee pagetable elements are all in WB mem...
>
> Or we can guarantee them in WB but the lazy flushing delays the actual
> clearing of the TLB entries so much so that they end up pointing to
> garbage, as you say, which is not in WB mem and thus causes the protocol
> error.
>
> Hmm. All still wet.
>

I think it's my theory #3.  The CPU has a "paging-structure cache"
(Intel lingo) that points to a freed page.  The CPU speculatively
follows it and gets complete garbage, triggering this MCE and who
knows what else.

I propose the following fix.  If PCID is on, then, in
enter_lazy_tlb(), we switch to init_mm with the no-flush flag set.
(And we give init_mm its own dedicated ASID to keep it simple and fast
-- no need to use the LRU ASID mapping to assign one dynamically.)  We
clear the bit in mm_cpumask.  That is, we more or less just skip the
whole lazy TLB optimization and rely on PCID CPUs having reasonably
fast CR3 writes.  No extra IPIs.  I suppose I need to benchmark this.
It will certainly slow down workloads that rapidly toggle between a
user thread and a kernel thread because it forces serialization on
each mm switch, but maybe that's not so bad.

If PCID is off, then we leave the old CR3 value when we go lazy, and
we also leave the flag in mm_cpumask set.  When a flush is requested,
we send out the IPI and switch to init_mm (and flush because we have
no choice).  IOW, the no-PCID behavior goes back to what it used to
be.

For the PCID case, I'm relying on this language in the SDM (vol 3, 4.10):

When a logical processor creates entries in the TLBs (Section 4.10.2)
and paging-structure caches (Section
4.10.3), it associates those entries with the current PCID. When using
entries in the TLBs and paging-structure
caches to translate a linear address, a logical processor uses only
those entries associated with the current PCID
(see Section 4.10.2.4 for an exception).

This is also just common sense -- a CPU that makes any assumptions
about a paging-structure cache for an inactive ASID is just nuts,
especially if it assumes that the result of following it is at all
sane.  IOW, we really should be able to switch to ASID 1 and back to 0
without any flushes without worrying that the old page tables for ASID
1 might get freed afterwards.  Obviously we need to flush if we switch
back to PCID 1, but the code already does this.


Also, sorry Rik, this means your old increased laziness optimization
is dead in the water.  It will have exactly the same speculative load
problem.

^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: Current mainline git (24e700e291d52bd2) hangs when building e.g. perf
  2017-09-09 19:28                                                                         ` Andy Lutomirski
@ 2017-09-09 19:37                                                                           ` Borislav Petkov
  2017-09-10  4:42                                                                             ` Andy Lutomirski
  2017-09-11  1:12                                                                           ` Rik van Riel
  1 sibling, 1 reply; 61+ messages in thread
From: Borislav Petkov @ 2017-09-09 19:37 UTC (permalink / raw)
  To: Andy Lutomirski
  Cc: Linus Torvalds, Markus Trippelsdorf, Ingo Molnar,
	Thomas Gleixner, Peter Zijlstra, LKML, Ingo Molnar, Tom Lendacky,
	Rik van Riel

On Sat, Sep 09, 2017 at 12:28:30PM -0700, Andy Lutomirski wrote:
> I propose the following fix.  If PCID is on, then, in
> enter_lazy_tlb(), we switch to init_mm with the no-flush flag set.
> (And we give init_mm its own dedicated ASID to keep it simple and fast
> -- no need to use the LRU ASID mapping to assign one dynamically.)  We
> clear the bit in mm_cpumask.  That is, we more or less just skip the
> whole lazy TLB optimization and rely on PCID CPUs having reasonably
> fast CR3 writes.  No extra IPIs.  I suppose I need to benchmark this.
> It will certainly slow down workloads that rapidly toggle between a
> user thread and a kernel thread because it forces serialization on
> each mm switch, but maybe that's not so bad.

Sounds ok so far.

> If PCID is off, then we leave the old CR3 value when we go lazy, and
> we also leave the flag in mm_cpumask set.  When a flush is requested,
> we send out the IPI and switch to init_mm (and flush because we have
> no choice).  IOW, the no-PCID behavior goes back to what it used to
> be.

Ok, question: why can't we load the new CR3 value too, immediately? Or
are we saying, we might get to return to the same CR3 we had before we
were lazy so we won't need to do an unnecessary CR3 write with the same
value. A microoptimization, if you will.

Yes?

-- 
Regards/Gruss,
    Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.

^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: Current mainline git (24e700e291d52bd2) hangs when building e.g. perf
  2017-09-09 19:37                                                                           ` Borislav Petkov
@ 2017-09-10  4:42                                                                             ` Andy Lutomirski
  2017-09-10 20:22                                                                               ` Peter Zijlstra
  2017-09-17 17:04                                                                               ` Ingo Molnar
  0 siblings, 2 replies; 61+ messages in thread
From: Andy Lutomirski @ 2017-09-10  4:42 UTC (permalink / raw)
  To: Borislav Petkov, Peter Zijlstra
  Cc: Andy Lutomirski, Linus Torvalds, Markus Trippelsdorf,
	Ingo Molnar, Thomas Gleixner, LKML, Ingo Molnar, Tom Lendacky,
	Rik van Riel

On Sat, Sep 9, 2017 at 12:37 PM, Borislav Petkov <bp@alien8.de> wrote:
> On Sat, Sep 09, 2017 at 12:28:30PM -0700, Andy Lutomirski wrote:
>> I propose the following fix.  If PCID is on, then, in
>> enter_lazy_tlb(), we switch to init_mm with the no-flush flag set.
>> (And we give init_mm its own dedicated ASID to keep it simple and fast
>> -- no need to use the LRU ASID mapping to assign one dynamically.)  We
>> clear the bit in mm_cpumask.  That is, we more or less just skip the
>> whole lazy TLB optimization and rely on PCID CPUs having reasonably
>> fast CR3 writes.  No extra IPIs.  I suppose I need to benchmark this.
>> It will certainly slow down workloads that rapidly toggle between a
>> user thread and a kernel thread because it forces serialization on
>> each mm switch, but maybe that's not so bad.
>
> Sounds ok so far.
>
>> If PCID is off, then we leave the old CR3 value when we go lazy, and
>> we also leave the flag in mm_cpumask set.  When a flush is requested,
>> we send out the IPI and switch to init_mm (and flush because we have
>> no choice).  IOW, the no-PCID behavior goes back to what it used to
>> be.
>
> Ok, question: why can't we load the new CR3 value too, immediately? Or
> are we saying, we might get to return to the same CR3 we had before we
> were lazy so we won't need to do an unnecessary CR3 write with the same
> value. A microoptimization, if you will.

It is indeed a microoptimization, but it's a microoptimization that
we've had in the kernel for a long, long time.

But it may be an ill-advised microoptimization, or at least a poorly
implemented one historically.  The microoptimization mostly affects
workloads that have a process on an otherwise idle CPU that frequently
sleeps for very short times.  With the optimization, we avoid two TLB
flushes and two serializing instructions every time we sleep.
Historically, we got a bunch of useless IPIs, too, depending on the
workload.

The problem is that the implementation, which lives in
kernel/sched/core.c for the most part, involves some extra reference
counting, and there are NUMA workloads with many cores all running the
same mm that pay a *huge* cost in refcounting, since all the CPUs are
hammering the same refcount.  And this refcount is (I think) basically
pointless on x86 and maybe on most architectures.

PeterZ and Ingo, would you be okay with adding a define so arches can
opt out of the task_struct::active_mm field entirely?  That is, with
the option set, task_struct wouldn't have an active_mm field, the core
wouldn't call mmgrab and mmdrop, and the arch would be responsible for
that bookkeeping instead?  x86, and presumably all arches without
cross-core invalidation, would probably prefer to just shoot down the
old mm entirely in __mmput() rather than trying to figure out when do
finish freeing old mms.  After all, exit_mmap() is going to send an
IPI regardless, so I see no reason to have the scheduler core pin an
old dead mm just because some random kernel thread's active_mm field
points to it.

IOW, if I'm going to reintroduce something like what the old lazy mode
did on x86, I'd rather do it right.

--Andy

^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: Current mainline git (24e700e291d52bd2) hangs when building e.g. perf
  2017-09-10  4:42                                                                             ` Andy Lutomirski
@ 2017-09-10 20:22                                                                               ` Peter Zijlstra
  2017-09-10 20:25                                                                                 ` Andy Lutomirski
  2017-09-17 17:04                                                                               ` Ingo Molnar
  1 sibling, 1 reply; 61+ messages in thread
From: Peter Zijlstra @ 2017-09-10 20:22 UTC (permalink / raw)
  To: Andy Lutomirski
  Cc: Borislav Petkov, Linus Torvalds, Markus Trippelsdorf,
	Ingo Molnar, Thomas Gleixner, LKML, Ingo Molnar, Tom Lendacky,
	Rik van Riel

On Sat, Sep 09, 2017 at 09:42:12PM -0700, Andy Lutomirski wrote:
> PeterZ and Ingo, would you be okay with adding a define so arches can
> opt out of the task_struct::active_mm field entirely?  That is, with
> the option set, task_struct wouldn't have an active_mm field, the core
> wouldn't call mmgrab and mmdrop, and the arch would be responsible for
> that bookkeeping instead?  x86, and presumably all arches without
> cross-core invalidation, would probably prefer to just shoot down the
> old mm entirely in __mmput() rather than trying to figure out when do
> finish freeing old mms.  After all, exit_mmap() is going to send an
> IPI regardless, so I see no reason to have the scheduler core pin an
> old dead mm just because some random kernel thread's active_mm field
> points to it.

I'm only quickly skimming this thread, but I don't see anything too
worrysome being proposed.

If you're in LA next week we can talk about it in more detail if you
want.

^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: Current mainline git (24e700e291d52bd2) hangs when building e.g. perf
  2017-09-10 20:22                                                                               ` Peter Zijlstra
@ 2017-09-10 20:25                                                                                 ` Andy Lutomirski
  0 siblings, 0 replies; 61+ messages in thread
From: Andy Lutomirski @ 2017-09-10 20:25 UTC (permalink / raw)
  To: Peter Zijlstra
  Cc: Andy Lutomirski, Borislav Petkov, Linus Torvalds,
	Markus Trippelsdorf, Ingo Molnar, Thomas Gleixner, LKML,
	Ingo Molnar, Tom Lendacky, Rik van Riel



> On Sep 10, 2017, at 1:22 PM, Peter Zijlstra <peterz@infradead.org> wrote:
> 
>> On Sat, Sep 09, 2017 at 09:42:12PM -0700, Andy Lutomirski wrote:
>> PeterZ and Ingo, would you be okay with adding a define so arches can
>> opt out of the task_struct::active_mm field entirely?  That is, with
>> the option set, task_struct wouldn't have an active_mm field, the core
>> wouldn't call mmgrab and mmdrop, and the arch would be responsible for
>> that bookkeeping instead?  x86, and presumably all arches without
>> cross-core invalidation, would probably prefer to just shoot down the
>> old mm entirely in __mmput() rather than trying to figure out when do
>> finish freeing old mms.  After all, exit_mmap() is going to send an
>> IPI regardless, so I see no reason to have the scheduler core pin an
>> old dead mm just because some random kernel thread's active_mm field
>> points to it.
> 
> I'm only quickly skimming this thread, but I don't see anything too
> worrysome being proposed.
> 
> If you're in LA next week we can talk about it in more detail if you
> want.

I'll be there.

^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: Current mainline git (24e700e291d52bd2) hangs when building e.g. perf
  2017-09-09 19:28                                                                         ` Andy Lutomirski
  2017-09-09 19:37                                                                           ` Borislav Petkov
@ 2017-09-11  1:12                                                                           ` Rik van Riel
  2017-09-11  1:46                                                                             ` Andy Lutomirski
  1 sibling, 1 reply; 61+ messages in thread
From: Rik van Riel @ 2017-09-11  1:12 UTC (permalink / raw)
  To: Andy Lutomirski, Borislav Petkov
  Cc: Linus Torvalds, Markus Trippelsdorf, Ingo Molnar,
	Thomas Gleixner, Peter Zijlstra, LKML, Ingo Molnar, Tom Lendacky

On Sat, 2017-09-09 at 12:28 -0700, Andy Lutomirski wrote:
> -
> I propose the following fix.  If PCID is on, then, in
> enter_lazy_tlb(), we switch to init_mm with the no-flush flag set.
> (And we give init_mm its own dedicated ASID to keep it simple and
> fast
> -- no need to use the LRU ASID mapping to assign one
> dynamically.)  We
> clear the bit in mm_cpumask.  That is, we more or less just skip the
> whole lazy TLB optimization and rely on PCID CPUs having reasonably
> fast CR3 writes.  No extra IPIs.

Avoiding the IPIs is probably what matters the most, especially
on systems with deep C states, and virtual machines where the
host may be running something else, causing the IPI service time
to go through the roof for idle VCPUs.

> Also, sorry Rik, this means your old increased laziness optimization
> is dead in the water.  It will have exactly the same speculative load
> problem.

Doesn't a memory barrier solve that speculative load
problem?

The memory barrier could be added only to the path
that potentially skips reloading the TLB, under the
assumption that a memory barrier is cheaper than a
TLB reload (even with ASID).

^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: Current mainline git (24e700e291d52bd2) hangs when building e.g. perf
  2017-09-11  1:12                                                                           ` Rik van Riel
@ 2017-09-11  1:46                                                                             ` Andy Lutomirski
  2017-09-11 15:08                                                                               ` Rik van Riel
  0 siblings, 1 reply; 61+ messages in thread
From: Andy Lutomirski @ 2017-09-11  1:46 UTC (permalink / raw)
  To: Rik van Riel
  Cc: Andy Lutomirski, Borislav Petkov, Linus Torvalds,
	Markus Trippelsdorf, Ingo Molnar, Thomas Gleixner,
	Peter Zijlstra, LKML, Ingo Molnar, Tom Lendacky

On Sun, Sep 10, 2017 at 6:12 PM, Rik van Riel <riel@redhat.com> wrote:
> On Sat, 2017-09-09 at 12:28 -0700, Andy Lutomirski wrote:
>> -
>> I propose the following fix.  If PCID is on, then, in
>> enter_lazy_tlb(), we switch to init_mm with the no-flush flag set.
>> (And we give init_mm its own dedicated ASID to keep it simple and
>> fast
>> -- no need to use the LRU ASID mapping to assign one
>> dynamically.)  We
>> clear the bit in mm_cpumask.  That is, we more or less just skip the
>> whole lazy TLB optimization and rely on PCID CPUs having reasonably
>> fast CR3 writes.  No extra IPIs.
>
> Avoiding the IPIs is probably what matters the most, especially
> on systems with deep C states, and virtual machines where the
> host may be running something else, causing the IPI service time
> to go through the roof for idle VCPUs.
>
>> Also, sorry Rik, this means your old increased laziness optimization
>> is dead in the water.  It will have exactly the same speculative load
>> problem.
>
> Doesn't a memory barrier solve that speculative load
> problem?
>
> The memory barrier could be added only to the path
> that potentially skips reloading the TLB, under the
> assumption that a memory barrier is cheaper than a
> TLB reload (even with ASID).

No, nothing stops the problematic speculative load.  Here's the issue.
One CPU removes a reference to a page table from a higher-level page
table, flushes, and then frees the page table.  Then it re-allocates
it and writes something unrelated there.  Another CPU that has CR3
pointing to the page hierarchy in question could have a reference to
the freed table in its paging structure cache.  Even if it's
guaranteed to not try to access the addresses in question (because
they're user addresses and the other CPU is in kernel mode, etc), but
there is never a guarantee that the CPU doesn't randomly try to fill
its TLB for the affected addresses.  This results in invalid PTEs in
the TLB, possible accesses using bogus memory types, and maybe even
reads from IO space.

It looks like we actually need to propagate flushes everywhere that
could have references to the flushed range, even if the software won't
access that range.

^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: Current mainline git (24e700e291d52bd2) hangs when building e.g. perf
  2017-09-11  1:46                                                                             ` Andy Lutomirski
@ 2017-09-11 15:08                                                                               ` Rik van Riel
  0 siblings, 0 replies; 61+ messages in thread
From: Rik van Riel @ 2017-09-11 15:08 UTC (permalink / raw)
  To: Andy Lutomirski
  Cc: Borislav Petkov, Linus Torvalds, Markus Trippelsdorf,
	Ingo Molnar, Thomas Gleixner, Peter Zijlstra, LKML, Ingo Molnar,
	Tom Lendacky

On Sun, 2017-09-10 at 18:46 -0700, Andy Lutomirski wrote:
> 
> No, nothing stops the problematic speculative load.  Here's the
> issue.
> One CPU removes a reference to a page table from a higher-level page
> table, flushes, and then frees the page table.  Then it re-allocates
> it and writes something unrelated there.  Another CPU that has CR3
> pointing to the page hierarchy in question could have a reference to
> the freed table in its paging structure cache.  Even if it's
> guaranteed to not try to access the addresses in question (because
> they're user addresses and the other CPU is in kernel mode, etc), but
> there is never a guarantee that the CPU doesn't randomly try to fill
> its TLB for the affected addresses.  This results in invalid PTEs in
> the TLB, possible accesses using bogus memory types, and maybe even
> reads from IO space.

Good point, I had forgotten all about memory accesses
that do not originate with software behavior.

^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: Current mainline git (24e700e291d52bd2) hangs when building e.g. perf
  2017-09-09 18:26                                                                 ` Linus Torvalds
  2017-09-09 18:29                                                                   ` Borislav Petkov
@ 2017-09-12  7:14                                                                   ` Markus Trippelsdorf
  1 sibling, 0 replies; 61+ messages in thread
From: Markus Trippelsdorf @ 2017-09-12  7:14 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: Borislav Petkov, Andy Lutomirski, Ingo Molnar, Thomas Gleixner,
	Peter Zijlstra, LKML, Ingo Molnar, Tom Lendacky

On 2017.09.09 at 11:26 -0700, Linus Torvalds wrote:
> On Sat, Sep 9, 2017 at 11:14 AM, Markus Trippelsdorf
> <markus@trippelsdorf.de> wrote:
> >
> > I think the issue gets fixed by:
> >
> >  # wrmsr -a 0xc0010015 0x1000018
> >
> > Setting bit 3 of the Hardware Configuration Register to 1.
> >
> > Quote from the docs:
> > »TlbCacheDis: cacheable memory disable. Read-write. 0=Enables performance optimization that
> > assumes PML4, PDP, PDE, and PTE entries are in cacheable WB-DRAM
> 
> Uhhuh.
> 
> The page directories should *definitely* always be in cacheable
> memory, so it should be ok for that bit to be 0, and it's possible
> that setting it to 1 will seriously screw up performance.

Well, I don't see any dramatic performance decrease on my box.
For instance compile times are roughly the same (a bit quicker in fact).
And in day to day usage I notice absolutely no difference.

-- 
Markus

^ permalink raw reply	[flat|nested] 61+ messages in thread

* Re: Current mainline git (24e700e291d52bd2) hangs when building e.g. perf
  2017-09-10  4:42                                                                             ` Andy Lutomirski
  2017-09-10 20:22                                                                               ` Peter Zijlstra
@ 2017-09-17 17:04                                                                               ` Ingo Molnar
  1 sibling, 0 replies; 61+ messages in thread
From: Ingo Molnar @ 2017-09-17 17:04 UTC (permalink / raw)
  To: Andy Lutomirski
  Cc: Borislav Petkov, Peter Zijlstra, Linus Torvalds,
	Markus Trippelsdorf, Thomas Gleixner, LKML, Ingo Molnar,
	Tom Lendacky, Rik van Riel


* Andy Lutomirski <luto@kernel.org> wrote:

> PeterZ and Ingo, would you be okay with adding a define so arches can
> opt out of the task_struct::active_mm field entirely?  That is, with
> the option set, task_struct wouldn't have an active_mm field, the core
> wouldn't call mmgrab and mmdrop, and the arch would be responsible for
> that bookkeeping instead?  x86, and presumably all arches without
> cross-core invalidation, would probably prefer to just shoot down the
> old mm entirely in __mmput() rather than trying to figure out when do
> finish freeing old mms.  After all, exit_mmap() is going to send an
> IPI regardless, so I see no reason to have the scheduler core pin an
> old dead mm just because some random kernel thread's active_mm field
> points to it.
> 
> IOW, if I'm going to reintroduce something like what the old lazy mode
> did on x86, I'd rather do it right.

How realistic would it be to get rid of ::active_mm on all architectures
at once?

Thanks,

	Ingo

^ permalink raw reply	[flat|nested] 61+ messages in thread

end of thread, other threads:[~2017-09-17 17:04 UTC | newest]

Thread overview: 61+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-09-05  7:27 Current mainline git (24e700e291d52bd2) hangs when building e.g. perf Markus Trippelsdorf
2017-09-05  8:53 ` Peter Zijlstra
2017-09-05  9:55   ` Markus Trippelsdorf
2017-09-06 12:52     ` Thomas Gleixner
2017-09-06 13:15       ` Markus Trippelsdorf
2017-09-07  6:28         ` Markus Trippelsdorf
2017-09-08  5:35           ` Markus Trippelsdorf
2017-09-08  6:26             ` Thomas Gleixner
2017-09-08  8:05               ` Borislav Petkov
2017-09-08  9:16                 ` Borislav Petkov
2017-09-08  9:48                   ` Markus Trippelsdorf
2017-09-08 10:35                     ` Ingo Molnar
2017-09-08 10:39                       ` Markus Trippelsdorf
2017-09-08 11:30                         ` Markus Trippelsdorf
2017-09-08 16:12                           ` Andy Lutomirski
2017-09-08 17:16                             ` Markus Trippelsdorf
2017-09-08 21:47                               ` Andy Lutomirski
2017-09-08 21:56                                 ` Borislav Petkov
2017-09-08 23:07                                   ` Andy Lutomirski
2017-09-08 23:23                                     ` Linus Torvalds
2017-09-09  0:00                                       ` Andy Lutomirski
2017-09-09  1:05                                         ` Linus Torvalds
2017-09-09  1:39                                           ` Andy Lutomirski
2017-09-09 17:49                                             ` Andy Lutomirski
2017-09-09 18:02                                               ` Linus Torvalds
2017-09-09  6:39                                   ` Markus Trippelsdorf
2017-09-09 10:18                                     ` Borislav Petkov
2017-09-09 11:07                                       ` Markus Trippelsdorf
2017-09-09 13:07                                         ` Borislav Petkov
2017-09-09 13:37                                           ` Markus Trippelsdorf
2017-09-09 13:39                                             ` Markus Trippelsdorf
2017-09-09 14:07                                               ` Borislav Petkov
2017-09-09 14:20                                                 ` Markus Trippelsdorf
2017-09-09 14:33                                                   ` Borislav Petkov
2017-09-09 14:43                                                     ` Markus Trippelsdorf
2017-09-09 16:32                                                       ` Markus Trippelsdorf
2017-09-09 17:05                                                         ` Borislav Petkov
2017-09-09 17:23                                                           ` Markus Trippelsdorf
2017-09-09 17:36                                                             ` Borislav Petkov
2017-09-09 18:14                                                               ` Markus Trippelsdorf
2017-09-09 18:26                                                                 ` Borislav Petkov
2017-09-09 18:46                                                                   ` Markus Trippelsdorf
2017-09-09 19:11                                                                     ` Borislav Petkov
2017-09-09 19:19                                                                       ` Borislav Petkov
2017-09-09 18:26                                                                 ` Linus Torvalds
2017-09-09 18:29                                                                   ` Borislav Petkov
2017-09-09 18:47                                                                     ` Linus Torvalds
2017-09-09 19:09                                                                       ` Borislav Petkov
2017-09-09 19:21                                                                         ` Linus Torvalds
2017-09-09 19:28                                                                         ` Andy Lutomirski
2017-09-09 19:37                                                                           ` Borislav Petkov
2017-09-10  4:42                                                                             ` Andy Lutomirski
2017-09-10 20:22                                                                               ` Peter Zijlstra
2017-09-10 20:25                                                                                 ` Andy Lutomirski
2017-09-17 17:04                                                                               ` Ingo Molnar
2017-09-11  1:12                                                                           ` Rik van Riel
2017-09-11  1:46                                                                             ` Andy Lutomirski
2017-09-11 15:08                                                                               ` Rik van Riel
2017-09-12  7:14                                                                   ` Markus Trippelsdorf
2017-09-09  8:13                                 ` Markus Trippelsdorf
2017-09-08 14:51                   ` Borislav Petkov

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.