* Memory corruptions upon strcpy and similar when being interrupted by scheduler
@ 2022-09-30 11:47 Heber, Stefan
2022-10-14 9:28 ` Zhang, Qiang1
2022-10-24 20:13 ` Jan Kiszka
0 siblings, 2 replies; 24+ messages in thread
From: Heber, Stefan @ 2022-09-30 11:47 UTC (permalink / raw)
To: xenomai
[-- Attachment #1: Type: text/plain, Size: 2677 bytes --]
Dear list,
we, as long time Xenomai users now have a severe problem. We are currently
in the process of migrating our huge application from xenomai 2.6.4 32bit
to 3.2.2 64bit (linux 5.4.105). In general we are almost done, but one
problem remains: Obviously we have memory corruptions resulting from
strcpy functions (transferring large configurations) being interrupted by
high prio tasks.
We now nailed this problem down in two minimal test applications in order
to rule out any programming errors in our own sources. These two
applications are:
a) a simple test that swaps two very large strings forth and back via
strcpy (and alternatively other copy implementations) and then check the
string contents. This simply happens on the main thread.
b) a "sleepproc" app that simply contains a while/nanosleep loop that
wakes up every 500ms just in order to interrupt app a).
When running the test app while sleepproc is running we see sporadically
errors (typically less than 20 runs of test until we see that error).
Without the sleepproc app, test runs without errors. And don't worry
about this magic txr19391 prefix, it is just an issue number ;-)
So, could you please help us and have a look into this problem?
Some remarks:
- The test seems to be highly sensitive concerning timing. So we had to
fine-tune a lot to see the error in this minimal test. Also it seems that
even the CPU may influence performance enough to make the error
disappear. Another weird thing is, that if we let the sleepproc sleep
100ms rather than 500ms the error disappears.
- In the test we can either work with individual mallocs for the needed
3 string buffers or with one large malloc and specific "pool allocations"
from that large pool buffer. We can see the error only, if we use the
pool approach (see the two options in the code switchable by commenting/
discommenting).
- We tested 5 different copy methods: strcpy, memcpy, two types of while
loops, one for-loop. We can only see the error with strcpy, memcpy and
for-loop. (also here: see the options in the code). Maybe that depends on
timing, maybe it depends on the implementation ... we don't know.
CPUs we tested on (all with more or less the same kernel config):
- Intel(R) Core(TM) i5-8400H CPU @ 2.50GHz, 4 cores
- Intel(R) Core(TM) i7-7820EQ CPU @ 3.00GHz, 4 cores
- Intel(R) Core(TM) i7-4700EQ CPU @ 2.40GHz, 4 cores
- Intel(R) Atom(TM) CPU D525 @ 1.80GHz, 2 cores ... here we couldn't tune
it such that the error appears
So, thanks in advance and, btw, thanks a lot for your excellent work
during the last >15 years!
Best regards
Stefan
[-- Attachment #2: Makefile --]
[-- Type: application/octet-stream, Size: 737 bytes --]
OBJST = txr19391test.o
OBJSW = txr19391sleepproc.o
XENO_CONFIG=../../cross-tools-2.25-5.4.105-xenomai-3.2.2/x86_64-tc2linux.core2-linux-gnu/host/usr/bin/xeno-config
ifeq ($(shell $(XENO_CONFIG) --prefix),)
$(error xeno-config not found, searching for $(XENO_CONFIG))
endif
CC=$(shell $(XENO_CONFIG) --cc)
LD=$(shell $(XENO_CONFIG) --ccld)
CFLAGS = $(shell $(XENO_CONFIG) --skin=posix --cflags) -O2
LDFLAGS=$(shell $(XENO_CONFIG) --skin=posix --auto-init-solib --ldflags)
all: txr19391test txr19391sleepproc
txr19391test: $(OBJST)
$(LD) -o $@ $^ $(LDFLAGS)
txr19391sleepproc: $(OBJSW)
$(LD) -o $@ $^ $(LDFLAGS)
%.o: %.c
$(CC) -c $(CFLAGS) $(CPPFLAGS) -o $@ $<
clean:
rm -fr txr19391test txr19391sleepproc $(OBJST) $(OBJSW)
[-- Attachment #3: system-info.txt --]
[-- Type: text/plain, Size: 91647 bytes --]
/usr/xenomai/bin/xeno-config --info
Xenomai version: 3.2.2
Linux tC2 5.4.105-xenomai-3.2.2-msc.c6b.klh #1 SMP PREEMPT Thu Sep 29 15:32:21 CEST 2022 x86_64 GNU/Linux
Kernel parameters: xenomai.smi=enabled mem=0x26de00000 root=/dev/sda3 vga=0x31a vmalloc=247M console=ttyS3,115200 console=tty0 noresume quiet
I-pipe release #4 detected
Cobalt core 3.2.2 detected
Compiler: gcc version 7.5.0 (GCC)
Build args: --prefix=/work/zwick/tc2linux/tc2linux-0.0.0-scratch/build-root/usr/xenomai --srcdir=. --libdir=/work/zwick/tc2linux/tc2linux-0.0.0-scratch/build-root/usr/xenomai/lib --host=x86_64-tc2linux.core2-linux-gnu host_alias=x86_64-tc2linux.core2-linux-gnu CC=/work/zwick/tc2linux/tc2linux-0.0.0-scratch/cross-tools-2.25-5.4.105-xenomai-3.2.2/x86_64-tc2linux.core2-linux-gnu/host/usr/bin/x86_64-tc2linux.core2-linux-gnu-gcc
####
/usr/xenomai/bin/smokey --run
syscall-tests.c:907, monitor_wait64 returned too early!
Expected wakeup at: 1467 sec 240038289 nsec
Back at : 1467 sec 240036889 nsec
syscall-tests.c:1018, socket(AF_RTIPC, SOCK_DGRAM, IPCPROTO_XDDP): Address family not supported by protocol
recvmmsg64: skipped. (no kernel support)
y2038 OK
xddp skipped (no kernel support)
vdso_access OK
tsc OK
timerfd OK
sigdebug "SIGDEBUG_MIGRATE_PRIOINV" skipped (no kernel support)
sigdebug OK
setsched OK
sched_tp skipped (no kernel support)
sched_quota skipped (no kernel support)
rtdm skipped (no kernel support)
posix_select OK
posix_mutex OK
posix_fork OK
cond_wait waited 9998.951 us
####
#
# Automatically generated file; DO NOT EDIT.
# Linux/x86 5.4.105 Kernel Configuration
#
#
# Compiler: gcc (SUSE Linux) 7.5.0
#
CONFIG_CC_IS_GCC=y
CONFIG_GCC_VERSION=70500
CONFIG_CLANG_VERSION=0
CONFIG_CC_CAN_LINK=y
CONFIG_CC_HAS_ASM_GOTO=y
CONFIG_CC_HAS_ASM_INLINE=y
CONFIG_IRQ_WORK=y
CONFIG_BUILDTIME_EXTABLE_SORT=y
CONFIG_THREAD_INFO_IN_TASK=y
#
# General setup
#
CONFIG_INIT_ENV_ARG_LIMIT=32
# CONFIG_COMPILE_TEST is not set
CONFIG_LOCALVERSION="-xenomai-3.2.2-msc.c6b.klh"
CONFIG_LOCALVERSION_AUTO=y
CONFIG_BUILD_SALT=""
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=y
# CONFIG_KERNEL_LZMA is not set
# CONFIG_KERNEL_XZ is not set
# CONFIG_KERNEL_LZO is not set
# CONFIG_KERNEL_LZ4 is not set
CONFIG_DEFAULT_HOSTNAME="tC2"
# CONFIG_SWAP is not set
CONFIG_SYSVIPC=y
CONFIG_SYSVIPC_SYSCTL=y
CONFIG_POSIX_MQUEUE=y
CONFIG_POSIX_MQUEUE_SYSCTL=y
# CONFIG_CROSS_MEMORY_ATTACH is not set
# CONFIG_USELIB is not set
CONFIG_AUDIT=y
CONFIG_HAVE_ARCH_AUDITSYSCALL=y
CONFIG_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_GENERIC_IRQ_MATRIX_ALLOCATOR=y
CONFIG_GENERIC_IRQ_RESERVATION_MODE=y
CONFIG_IRQ_FORCED_THREADING=y
CONFIG_SPARSE_IRQ=y
# CONFIG_GENERIC_IRQ_DEBUGFS is not set
# end of IRQ subsystem
CONFIG_CLOCKSOURCE_WATCHDOG=y
CONFIG_ARCH_CLOCKSOURCE_DATA=y
CONFIG_ARCH_CLOCKSOURCE_INIT=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 is not set
# CONFIG_HIGH_RES_TIMERS is not set
# end of Timers subsystem
# CONFIG_PREEMPT_NONE is not set
# CONFIG_PREEMPT_VOLUNTARY is not set
CONFIG_PREEMPT=y
CONFIG_PREEMPT_COUNT=y
CONFIG_PREEMPTION=y
#
# CPU/Task time and stats accounting
#
CONFIG_TICK_CPU_ACCOUNTING=y
# CONFIG_IRQ_TIME_ACCOUNTING is not set
CONFIG_BSD_PROCESS_ACCT=y
CONFIG_BSD_PROCESS_ACCT_V3=y
# CONFIG_TASKSTATS is not set
# CONFIG_PSI is not set
# end of CPU/Task time and stats accounting
CONFIG_CPU_ISOLATION=y
#
# RCU Subsystem
#
CONFIG_PREEMPT_RCU=y
# CONFIG_RCU_EXPERT is not set
CONFIG_SRCU=y
CONFIG_TREE_SRCU=y
CONFIG_TASKS_RCU=y
CONFIG_RCU_STALL_COMMON=y
CONFIG_RCU_NEED_SEGCBLIST=y
# end of RCU Subsystem
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
# CONFIG_IKHEADERS is not set
CONFIG_LOG_BUF_SHIFT=17
CONFIG_LOG_CPU_MAX_BUF_SHIFT=12
CONFIG_PRINTK_SAFE_LOG_BUF_SHIFT=13
CONFIG_HAVE_UNSTABLE_SCHED_CLOCK=y
#
# Scheduler features
#
# end of Scheduler features
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_NAMESPACES is not set
# CONFIG_CHECKPOINT_RESTORE is not set
# CONFIG_SCHED_AUTOGROUP is not set
CONFIG_SYSFS_DEPRECATED=y
CONFIG_SYSFS_DEPRECATED_V2=y
CONFIG_RELAY=y
CONFIG_BLK_DEV_INITRD=y
CONFIG_INITRAMFS_SOURCE=""
CONFIG_RD_GZIP=y
# CONFIG_RD_BZIP2 is not set
# CONFIG_RD_LZMA is not set
# CONFIG_RD_XZ is not set
# CONFIG_RD_LZO is not set
# CONFIG_RD_LZ4 is not set
# CONFIG_CC_OPTIMIZE_FOR_PERFORMANCE is not set
CONFIG_CC_OPTIMIZE_FOR_SIZE=y
CONFIG_SYSCTL=y
CONFIG_SYSCTL_EXCEPTION_TRACE=y
CONFIG_HAVE_PCSPKR_PLATFORM=y
CONFIG_BPF=y
CONFIG_EXPERT=y
CONFIG_MULTIUSER=y
CONFIG_SGETMASK_SYSCALL=y
CONFIG_SYSFS_SYSCALL=y
CONFIG_SYSCTL_SYSCALL=y
# CONFIG_FHANDLE is not set
CONFIG_POSIX_TIMERS=y
CONFIG_PRINTK=y
CONFIG_PRINTK_NMI=y
CONFIG_RAW_PRINTK=y
CONFIG_BUG=y
CONFIG_ELF_CORE=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_SHMEM=y
CONFIG_AIO=y
CONFIG_IO_URING=y
CONFIG_ADVISE_SYSCALLS=y
CONFIG_MEMBARRIER=y
CONFIG_KALLSYMS=y
# CONFIG_KALLSYMS_ALL is not set
CONFIG_KALLSYMS_ABSOLUTE_PERCPU=y
CONFIG_KALLSYMS_BASE_RELATIVE=y
# CONFIG_BPF_SYSCALL is not set
# CONFIG_USERFAULTFD is not set
CONFIG_ARCH_HAS_MEMBARRIER_SYNC_CORE=y
CONFIG_RSEQ=y
# CONFIG_DEBUG_RSEQ is not set
# CONFIG_EMBEDDED is not set
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
# end of Kernel Performance Events And Counters
# CONFIG_VM_EVENT_COUNTERS is not set
CONFIG_COMPAT_BRK=y
CONFIG_SLAB=y
# CONFIG_SLUB is not set
# CONFIG_SLOB is not set
CONFIG_SLAB_MERGE_DEFAULT=y
# CONFIG_SLAB_FREELIST_RANDOM is not set
# CONFIG_SHUFFLE_PAGE_ALLOCATOR is not set
CONFIG_PROFILING=y
CONFIG_TRACEPOINTS=y
# end of General setup
CONFIG_64BIT=y
CONFIG_FORCE_MAX_ZONEORDER=13
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_GENERIC_ISA_DMA=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_BUG_RELATIVE_POINTERS=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_ARCH_HAS_CPU_RELAX=y
CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
CONFIG_ARCH_HAS_FILTER_PGPROT=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_GENERAL_HUGETLB=y
CONFIG_ZONE_DMA32=y
CONFIG_AUDIT_ARCH=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_CC_HAS_SANE_STACKPROTECTOR=y
#
# Processor type and features
#
CONFIG_ZONE_DMA=y
CONFIG_SMP=y
CONFIG_X86_FEATURE_NAMES=y
CONFIG_X86_MPPARSE=y
# CONFIG_GOLDFISH is not set
# CONFIG_RETPOLINE is not set
# CONFIG_X86_CPU_RESCTRL 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 is not set
CONFIG_X86_SUPPORTS_MEMORY_FAILURE=y
CONFIG_SCHED_OMIT_FRAME_POINTER=y
# CONFIG_HYPERVISOR_GUEST is not set
# CONFIG_MK8 is not set
# CONFIG_MPSC is not set
CONFIG_MCORE2=y
# 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_P6_NOP=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=y
# CONFIG_CPU_SUP_AMD is not set
# CONFIG_CPU_SUP_HYGON is not set
# CONFIG_CPU_SUP_CENTAUR is not set
# CONFIG_CPU_SUP_ZHAOXIN is not set
CONFIG_HPET_TIMER=y
CONFIG_HPET_EMULATE_RTC=y
CONFIG_DMI=y
# CONFIG_CALGARY_IOMMU is not set
CONFIG_NR_CPUS_RANGE_BEGIN=2
CONFIG_NR_CPUS_RANGE_END=512
CONFIG_NR_CPUS_DEFAULT=64
CONFIG_NR_CPUS=4
CONFIG_SCHED_SMT=y
CONFIG_SCHED_MC=y
# CONFIG_SCHED_MC_PRIO is not set
CONFIG_HAVE_IPIPE_SUPPORT=y
CONFIG_IPIPE=y
CONFIG_IPIPE_CORE=y
CONFIG_IPIPE_WANT_PTE_PINNING=y
CONFIG_IPIPE_CORE_APIREV=2
CONFIG_IPIPE_WANT_APIREV_2=y
CONFIG_IPIPE_TARGET_APIREV=2
CONFIG_IPIPE_HAVE_HOSTRT=y
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=y
CONFIG_X86_MCE_THRESHOLD=y
# CONFIG_X86_MCE_INJECT is not set
CONFIG_X86_THERMAL_VECTOR=y
#
# Performance monitoring
#
# CONFIG_PERF_EVENTS_INTEL_UNCORE is not set
# CONFIG_PERF_EVENTS_INTEL_RAPL is not set
# CONFIG_PERF_EVENTS_INTEL_CSTATE is not set
# end of Performance monitoring
# CONFIG_X86_16BIT is not set
CONFIG_X86_VSYSCALL_EMULATION=y
# CONFIG_I8K is not set
CONFIG_MICROCODE=y
CONFIG_MICROCODE_INTEL=y
# CONFIG_MICROCODE_AMD is not set
# CONFIG_MICROCODE_OLD_INTERFACE is not set
CONFIG_X86_MSR=y
CONFIG_X86_CPUID=y
# CONFIG_X86_5LEVEL is not set
CONFIG_X86_DIRECT_GBPAGES=y
# CONFIG_X86_CPA_STATISTICS 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_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=0
CONFIG_MTRR_SANITIZER_SPARE_REG_NR_DEFAULT=1
CONFIG_X86_PAT=y
CONFIG_ARCH_USES_PG_UNCACHED=y
CONFIG_ARCH_RANDOM=y
CONFIG_X86_SMAP=y
CONFIG_X86_INTEL_UMIP=y
# CONFIG_X86_INTEL_MPX is not set
CONFIG_X86_INTEL_MEMORY_PROTECTION_KEYS=y
CONFIG_X86_INTEL_TSX_MODE_OFF=y
# CONFIG_X86_INTEL_TSX_MODE_ON is not set
# CONFIG_X86_INTEL_TSX_MODE_AUTO 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 is not set
CONFIG_HZ_1000=y
CONFIG_HZ=1000
# CONFIG_KEXEC is not set
CONFIG_CRASH_DUMP=y
CONFIG_PHYSICAL_START=0x1000000
CONFIG_RELOCATABLE=y
# CONFIG_RANDOMIZE_BASE is not set
CONFIG_PHYSICAL_ALIGN=0x200000
CONFIG_HOTPLUG_CPU=y
# CONFIG_BOOTPARAM_HOTPLUG_CPU0 is not set
# CONFIG_DEBUG_HOTPLUG_CPU0 is not set
# CONFIG_LEGACY_VSYSCALL_EMULATE is not set
CONFIG_LEGACY_VSYSCALL_XONLY=y
# CONFIG_LEGACY_VSYSCALL_NONE is not set
CONFIG_CMDLINE_BOOL=y
CONFIG_CMDLINE="xenomai.smi=enabled mem=0x26de00000"
# CONFIG_CMDLINE_OVERRIDE is not set
CONFIG_MODIFY_LDT_SYSCALL=y
CONFIG_HAVE_LIVEPATCH=y
# end of Processor type and features
CONFIG_ARCH_HAS_ADD_PAGES=y
CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG=y
CONFIG_ARCH_ENABLE_SPLIT_PMD_PTLOCK=y
#
# Power management and ACPI options
#
# CONFIG_SUSPEND is not set
# CONFIG_PM is not set
CONFIG_ARCH_SUPPORTS_ACPI=y
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_SPCR_TABLE=y
CONFIG_ACPI_LPIT=y
# 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_DOCK is not set
CONFIG_ACPI_PROCESSOR_CSTATE=y
# CONFIG_ACPI_PROCESSOR is not set
CONFIG_ARCH_HAS_ACPI_TABLE_UPGRADE=y
# CONFIG_ACPI_TABLE_UPGRADE is not set
# CONFIG_ACPI_DEBUG is not set
# CONFIG_ACPI_PCI_SLOT is not set
# 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_PMIC_OPREGION is not set
# CONFIG_ACPI_CONFIGFS is not set
# CONFIG_X86_PM_TIMER is not set
# CONFIG_SFI is not set
#
# CPU Frequency scaling
#
# CONFIG_CPU_FREQ is not set
# end of CPU Frequency scaling
#
# CPU Idle
#
# CONFIG_CPU_IDLE is not set
# end of CPU Idle
# end of Power management and ACPI options
#
# Bus options (PCI etc.)
#
CONFIG_PCI_DIRECT=y
CONFIG_PCI_MMCONFIG=y
CONFIG_MMCONF_FAM10H=y
# CONFIG_PCI_CNB20LE_QUIRK is not set
# CONFIG_ISA_BUS is not set
CONFIG_ISA_DMA_API=y
# CONFIG_X86_SYSFB is not set
# end of Bus options (PCI etc.)
#
# Binary Emulations
#
# CONFIG_IA32_EMULATION is not set
# CONFIG_X86_X32 is not set
# end of Binary Emulations
#
# Firmware Drivers
#
CONFIG_EDD=y
# CONFIG_EDD_OFF is not set
CONFIG_FIRMWARE_MEMMAP=y
# CONFIG_DMIID is not set
# CONFIG_DMI_SYSFS is not set
CONFIG_DMI_SCAN_MACHINE_NON_EFI_FALLBACK=y
# CONFIG_ISCSI_IBFT is not set
# CONFIG_FW_CFG_SYSFS is not set
# CONFIG_GOOGLE_FIRMWARE is not set
#
# Tegra firmware driver
#
# end of Tegra firmware driver
# end of Firmware Drivers
CONFIG_HAVE_KVM=y
# CONFIG_VIRTUALIZATION is not set
#
# General architecture-dependent options
#
CONFIG_CRASH_CORE=y
CONFIG_HOTPLUG_SMT=y
CONFIG_OPROFILE=m
# CONFIG_OPROFILE_EVENT_MULTIPLEX is not set
CONFIG_HAVE_OPROFILE=y
CONFIG_OPROFILE_NMI_TIMER=y
CONFIG_KPROBES=y
CONFIG_OPTPROBES=y
CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS=y
CONFIG_ARCH_USE_BUILTIN_BSWAP=y
CONFIG_KRETPROBES=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_FUNCTION_ERROR_INJECTION=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_HAS_SET_DIRECT_MAP=y
CONFIG_HAVE_ARCH_THREAD_STRUCT_WHITELIST=y
CONFIG_ARCH_WANTS_DYNAMIC_TASK_STRUCT=y
CONFIG_HAVE_ASM_MODVERSIONS=y
CONFIG_HAVE_REGS_AND_STACK_ACCESS_API=y
CONFIG_HAVE_RSEQ=y
CONFIG_HAVE_FUNCTION_ARG_ACCESS_API=y
CONFIG_HAVE_CLK=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_ARCH_HAVE_NMI_SAFE_CMPXCHG=y
CONFIG_HAVE_CMPXCHG_LOCAL=y
CONFIG_HAVE_CMPXCHG_DOUBLE=y
CONFIG_HAVE_ARCH_SECCOMP_FILTER=y
CONFIG_SECCOMP_FILTER=y
CONFIG_HAVE_ARCH_STACKLEAK=y
CONFIG_HAVE_STACKPROTECTOR=y
CONFIG_CC_HAS_STACKPROTECTOR_NONE=y
CONFIG_STACKPROTECTOR=y
CONFIG_STACKPROTECTOR_STRONG=y
CONFIG_HAVE_ARCH_WITHIN_STACK_FRAMES=y
CONFIG_HAVE_VIRT_CPU_ACCOUNTING_GEN=y
CONFIG_HAVE_IRQ_TIME_ACCOUNTING=y
CONFIG_HAVE_MOVE_PMD=y
CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE=y
CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE_PUD=y
CONFIG_HAVE_ARCH_HUGE_VMAP=y
CONFIG_ARCH_WANT_HUGE_PMD_SHARE=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_RELIABLE_STACKTRACE=y
CONFIG_64BIT_TIME=y
CONFIG_HAVE_ARCH_VMAP_STACK=y
CONFIG_VMAP_STACK=y
CONFIG_ARCH_HAS_STRICT_KERNEL_RWX=y
CONFIG_STRICT_KERNEL_RWX=y
CONFIG_ARCH_HAS_STRICT_MODULE_RWX=y
CONFIG_STRICT_MODULE_RWX=y
CONFIG_ARCH_HAS_REFCOUNT=y
# CONFIG_REFCOUNT_FULL is not set
CONFIG_HAVE_ARCH_PREL32_RELOCATIONS=y
# CONFIG_LOCK_EVENT_COUNTS is not set
CONFIG_ARCH_HAS_MEM_ENCRYPT=y
#
# GCOV-based kernel profiling
#
# CONFIG_GCOV_KERNEL is not set
CONFIG_ARCH_HAS_GCOV_PROFILE_ALL=y
# end of GCOV-based kernel profiling
CONFIG_PLUGIN_HOSTCC=""
CONFIG_HAVE_GCC_PLUGINS=y
# end of General architecture-dependent options
CONFIG_RT_MUTEXES=y
CONFIG_BASE_SMALL=0
CONFIG_MODULES=y
# CONFIG_MODULE_FORCE_LOAD is not set
CONFIG_MODULE_UNLOAD=y
# CONFIG_MODULE_FORCE_UNLOAD is not set
CONFIG_MODVERSIONS=y
CONFIG_ASM_MODVERSIONS=y
CONFIG_MODULE_SRCVERSION_ALL=y
# CONFIG_MODULE_SIG is not set
# CONFIG_MODULE_COMPRESS is not set
# CONFIG_MODULE_ALLOW_MISSING_NAMESPACE_IMPORTS is not set
# CONFIG_UNUSED_SYMBOLS is not set
# CONFIG_TRIM_UNUSED_KSYMS 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=y
# 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 is not set
# 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=y
# 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 is not set
# CONFIG_SYSV68_PARTITION is not set
# CONFIG_CMDLINE_PARTITION is not set
# end of Partition Types
CONFIG_BLK_MQ_PCI=y
#
# IO Schedulers
#
CONFIG_MQ_IOSCHED_DEADLINE=y
CONFIG_MQ_IOSCHED_KYBER=y
# CONFIG_IOSCHED_BFQ is not set
# end of IO Schedulers
CONFIG_UNINLINE_SPIN_UNLOCK=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_ARCH_HAS_SYNC_CORE_BEFORE_USERMODE=y
CONFIG_ARCH_HAS_SYSCALL_WRAPPER=y
CONFIG_XENOMAI=y
CONFIG_XENO_ARCH_FPU=y
#
# Core features
#
# CONFIG_XENO_OPT_SCHED_CLASSES is not set
CONFIG_XENO_OPT_STATS=y
CONFIG_XENO_OPT_STATS_IRQS=y
# CONFIG_XENO_OPT_SHIRQ is not set
CONFIG_XENO_OPT_RR_QUANTUM=1000
CONFIG_XENO_OPT_AUTOTUNE=y
# CONFIG_XENO_OPT_SCALABLE_SCHED is not set
CONFIG_XENO_OPT_TIMER_LIST=y
# CONFIG_XENO_OPT_TIMER_RBTREE is not set
CONFIG_XENO_OPT_VFILE=y
# end of Core features
#
# Sizes and static limits
#
CONFIG_XENO_OPT_REGISTRY_NRSLOTS=80000
CONFIG_XENO_OPT_SYS_HEAPSZ=32768
CONFIG_XENO_OPT_PRIVATE_HEAPSZ=4096
CONFIG_XENO_OPT_SHARED_HEAPSZ=4096
CONFIG_XENO_OPT_NRTIMERS=256
# end of Sizes and static limits
#
# Latency settings
#
CONFIG_XENO_OPT_TIMING_SCHEDLAT=0
CONFIG_XENO_OPT_TIMING_KSCHEDLAT=0
CONFIG_XENO_OPT_TIMING_IRQLAT=0
# end of Latency settings
CONFIG_XENO_OPT_DEBUG=y
# CONFIG_XENO_OPT_DEBUG_COBALT is not set
# CONFIG_XENO_OPT_DEBUG_MEMORY is not set
# CONFIG_XENO_OPT_DEBUG_CONTEXT is not set
CONFIG_XENO_OPT_DEBUG_LOCKING=y
# CONFIG_XENO_OPT_DEBUG_USER is not set
# CONFIG_XENO_OPT_DEBUG_TRACE_RELAX is not set
CONFIG_XENO_OPT_WATCHDOG=y
CONFIG_XENO_OPT_WATCHDOG_TIMEOUT=60
#
# Drivers
#
CONFIG_XENO_OPT_RTDM_COMPAT_DEVNODE=y
CONFIG_XENO_DRIVERS_AUTOTUNE=y
#
# Serial drivers
#
CONFIG_XENO_DRIVERS_16550A=m
CONFIG_XENO_DRIVERS_16550A_PIO=y
# CONFIG_XENO_DRIVERS_16550A_MMIO is not set
# CONFIG_XENO_DRIVERS_16550A_ANY is not set
# CONFIG_XENO_DRIVERS_16550A_PCI is not set
# end of Serial drivers
#
# Testing drivers
#
CONFIG_XENO_DRIVERS_TIMERBENCH=m
CONFIG_XENO_DRIVERS_SWITCHTEST=m
CONFIG_XENO_DRIVERS_HEAPCHECK=y
# CONFIG_XENO_DRIVERS_RTDMTEST is not set
# end of Testing drivers
#
# CAN drivers
#
# CONFIG_XENO_DRIVERS_CAN is not set
# end of CAN drivers
#
# RTnet
#
# CONFIG_XENO_DRIVERS_NET is not set
# end of RTnet
#
# ANALOGY drivers
#
# CONFIG_XENO_DRIVERS_ANALOGY is not set
# end of ANALOGY drivers
#
# Real-time IPC drivers
#
# CONFIG_XENO_DRIVERS_RTIPC is not set
# end of Real-time IPC drivers
#
# UDD support
#
# CONFIG_XENO_DRIVERS_UDD is not set
# end of UDD support
#
# Real-time GPIO drivers
#
# end of Real-time GPIO drivers
#
# GPIOPWM support
#
# CONFIG_XENO_DRIVERS_GPIOPWM is not set
# end of GPIOPWM support
#
# Real-time SPI master drivers
#
# end of Real-time SPI master drivers
# end of Drivers
CONFIG_XENO_VERSION_MAJOR=3
CONFIG_XENO_VERSION_MINOR=2
CONFIG_XENO_REVISION_LEVEL=2
CONFIG_XENO_VERSION_STRING="3.2.2"
#
# Executable file formats
#
CONFIG_BINFMT_ELF=y
CONFIG_ELFCORE=y
CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS=y
CONFIG_BINFMT_SCRIPT=y
CONFIG_BINFMT_MISC=y
CONFIG_COREDUMP=y
# end of Executable file formats
#
# Memory Management options
#
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_VMEMMAP=y
CONFIG_HAVE_MEMBLOCK_NODE_MAP=y
CONFIG_HAVE_FAST_GUP=y
# CONFIG_MEMORY_HOTPLUG is not set
CONFIG_SPLIT_PTLOCK_CPUS=4
# CONFIG_COMPACTION is not set
CONFIG_PHYS_ADDR_T_64BIT=y
CONFIG_BOUNCE=y
CONFIG_VIRT_TO_BUS=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_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_DEFERRED_STRUCT_PAGE_INIT is not set
# CONFIG_IDLE_PAGE_TRACKING is not set
CONFIG_ARCH_HAS_PTE_DEVMAP=y
CONFIG_ARCH_USES_HIGH_VMA_FLAGS=y
CONFIG_ARCH_HAS_PKEYS=y
# CONFIG_PERCPU_STATS is not set
# CONFIG_GUP_BENCHMARK is not set
CONFIG_ARCH_HAS_PTE_SPECIAL=y
# end of Memory Management options
CONFIG_NET=y
CONFIG_SKB_EXTENSIONS=y
#
# Networking options
#
CONFIG_PACKET=y
# CONFIG_PACKET_DIAG is not set
CONFIG_UNIX=y
CONFIG_UNIX_SCM=y
# CONFIG_UNIX_DIAG is not set
# CONFIG_TLS is not set
CONFIG_XFRM=y
CONFIG_XFRM_ALGO=y
CONFIG_XFRM_USER=m
# CONFIG_XFRM_SUB_POLICY is not set
# CONFIG_XFRM_MIGRATE is not set
# CONFIG_XFRM_STATISTICS is not set
CONFIG_XFRM_IPCOMP=m
CONFIG_NET_KEY=y
# CONFIG_NET_KEY_MIGRATE is not set
CONFIG_INET=y
CONFIG_IP_MULTICAST=y
# 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_IP_MROUTE is not set
# CONFIG_SYN_COOKIES is not set
# CONFIG_NET_IPVTI is not set
# CONFIG_NET_FOU is not set
CONFIG_INET_AH=m
CONFIG_INET_ESP=m
# CONFIG_INET_ESP_OFFLOAD is not set
CONFIG_INET_IPCOMP=m
CONFIG_INET_XFRM_TUNNEL=m
CONFIG_INET_TUNNEL=m
# CONFIG_INET_DIAG is not set
# CONFIG_TCP_CONG_ADVANCED is not set
CONFIG_TCP_CONG_CUBIC=y
CONFIG_DEFAULT_TCP_CONG="cubic"
# CONFIG_TCP_MD5SIG is not set
# CONFIG_IPV6 is not set
# CONFIG_NETWORK_SECMARK is not set
CONFIG_NET_PTP_CLASSIFY=y
# CONFIG_NETWORK_PHY_TIMESTAMPING is not set
# CONFIG_NETFILTER is not set
# CONFIG_BPFILTER 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_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 is not set
# CONFIG_DCB is not set
CONFIG_DNS_RESOLVER=y
# 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_BPF_JIT is not set
CONFIG_NET_FLOW_LIMIT=y
#
# Network testing
#
# CONFIG_NET_PKTGEN is not set
# CONFIG_NET_DROP_MONITOR is not set
# end of Network testing
# end of Networking options
# 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_WIRELESS is not set
# CONFIG_WIMAX is not set
# CONFIG_RFKILL is not set
# CONFIG_NET_9P 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_GRO_CELLS=y
# CONFIG_FAILOVER is not set
CONFIG_HAVE_EBPF_JIT=y
#
# Device Drivers
#
CONFIG_HAVE_EISA=y
# CONFIG_EISA is not set
CONFIG_HAVE_PCI=y
CONFIG_PCI=y
CONFIG_PCI_DOMAINS=y
CONFIG_PCIEPORTBUS=y
CONFIG_PCIEAER=y
# CONFIG_PCIEAER_INJECT is not set
# CONFIG_PCIE_ECRC is not set
# CONFIG_PCIEASPM is not set
# CONFIG_PCIE_DPC is not set
# CONFIG_PCIE_PTM is not set
# CONFIG_PCIE_BW is not set
CONFIG_PCI_MSI=y
CONFIG_PCI_MSI_IRQ_DOMAIN=y
CONFIG_PCI_QUIRKS=y
# CONFIG_PCI_DEBUG is not set
# CONFIG_PCI_STUB is not set
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
#
# PCI controller drivers
#
#
# Cadence PCIe controllers support
#
# end of Cadence PCIe controllers support
# CONFIG_VMD is not set
#
# DesignWare PCI Core Support
#
# CONFIG_PCIE_DW_PLAT_HOST is not set
# CONFIG_PCI_MESON is not set
# end of DesignWare PCI Core Support
# end of PCI controller drivers
#
# PCI Endpoint
#
# CONFIG_PCI_ENDPOINT is not set
# end of PCI Endpoint
#
# PCI switch controller drivers
#
# CONFIG_PCI_SW_SWITCHTEC is not set
# end of PCI switch controller drivers
# CONFIG_PCCARD is not set
# CONFIG_RAPIDIO is not set
#
# Generic Driver Options
#
# CONFIG_UEVENT_HELPER is not set
CONFIG_DEVTMPFS=y
# CONFIG_DEVTMPFS_MOUNT is not set
CONFIG_STANDALONE=y
CONFIG_PREVENT_FIRMWARE_BUILD=y
#
# Firmware loader
#
CONFIG_FW_LOADER=y
CONFIG_FW_LOADER_PAGED_BUF=y
CONFIG_EXTRA_FIRMWARE=""
CONFIG_FW_LOADER_USER_HELPER=y
# CONFIG_FW_LOADER_USER_HELPER_FALLBACK is not set
# CONFIG_FW_LOADER_COMPRESS is not set
# end of Firmware loader
CONFIG_ALLOW_DEV_COREDUMP=y
# CONFIG_DEBUG_DRIVER is not set
# CONFIG_DEBUG_DEVRES is not set
# CONFIG_DEBUG_TEST_DRIVER_REMOVE is not set
# CONFIG_TEST_ASYNC_DRIVER_PROBE is not set
CONFIG_GENERIC_CPU_AUTOPROBE=y
CONFIG_GENERIC_CPU_VULNERABILITIES=y
CONFIG_REGMAP=y
CONFIG_REGMAP_I2C=m
# end of Generic Driver Options
#
# Bus devices
#
# end of Bus devices
CONFIG_CONNECTOR=y
CONFIG_PROC_EVENTS=y
# CONFIG_GNSS 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 is not set
#
# Protocols
#
CONFIG_PNPACPI=y
CONFIG_BLK_DEV=y
# CONFIG_BLK_DEV_NULL_BLK is not set
# CONFIG_BLK_DEV_FD is not set
# CONFIG_BLK_DEV_PCIESSD_MTIP32XX is not set
# CONFIG_BLK_DEV_UMEM is not set
CONFIG_BLK_DEV_LOOP=y
CONFIG_BLK_DEV_LOOP_MIN_COUNT=8
# CONFIG_BLK_DEV_CRYPTOLOOP is not set
# CONFIG_BLK_DEV_DRBD is not set
CONFIG_BLK_DEV_NBD=y
# CONFIG_BLK_DEV_SKD is not set
# CONFIG_BLK_DEV_SX8 is not set
CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_COUNT=16
CONFIG_BLK_DEV_RAM_SIZE=64000
# CONFIG_CDROM_PKTCDVD is not set
# CONFIG_ATA_OVER_ETH is not set
# CONFIG_BLK_DEV_RBD is not set
# CONFIG_BLK_DEV_RSXX is not set
#
# NVME Support
#
# CONFIG_BLK_DEV_NVME is not set
# CONFIG_NVME_FC is not set
# CONFIG_NVME_TARGET is not set
# end of NVME Support
#
# Misc devices
#
# CONFIG_AD525X_DPOT is not set
# CONFIG_DUMMY_IRQ is not set
# CONFIG_IBM_ASM is not set
# CONFIG_PHANTOM 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_SRAM is not set
# CONFIG_PCI_ENDPOINT_TEST is not set
# CONFIG_XILINX_SDFEC is not set
# CONFIG_PVPANIC 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_EEPROM_EE1004 is not set
# end of EEPROM support
# CONFIG_CB710_CORE is not set
#
# Texas Instruments shared transport line discipline
#
# end of Texas Instruments shared transport line discipline
# CONFIG_SENSORS_LIS3_I2C is not set
# 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 & related support
#
#
# 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
#
# end of Intel MIC & related support
# CONFIG_GENWQE is not set
# CONFIG_ECHO is not set
# CONFIG_MISC_ALCOR_PCI is not set
# CONFIG_MISC_RTSX_PCI is not set
# CONFIG_MISC_RTSX_USB is not set
# CONFIG_HABANA_AI is not set
# end of Misc devices
CONFIG_HAVE_IDE=y
# CONFIG_IDE is not set
#
# SCSI device support
#
CONFIG_SCSI_MOD=m
CONFIG_RAID_ATTRS=m
CONFIG_SCSI=m
CONFIG_SCSI_DMA=y
CONFIG_SCSI_PROC_FS=y
#
# SCSI support type (disk, tape, CD-ROM)
#
CONFIG_BLK_DEV_SD=m
# CONFIG_CHR_DEV_ST is not set
# CONFIG_BLK_DEV_SR is not set
CONFIG_CHR_DEV_SG=m
# CONFIG_CHR_DEV_SCH is not set
CONFIG_SCSI_CONSTANTS=y
CONFIG_SCSI_LOGGING=y
# CONFIG_SCSI_SCAN_ASYNC is not set
#
# SCSI Transports
#
CONFIG_SCSI_SPI_ATTRS=m
# CONFIG_SCSI_FC_ATTRS is not set
# CONFIG_SCSI_ISCSI_ATTRS is not set
CONFIG_SCSI_SAS_ATTRS=m
# CONFIG_SCSI_SAS_LIBSAS is not set
# CONFIG_SCSI_SRP_ATTRS is not set
# end of SCSI Transports
CONFIG_SCSI_LOWLEVEL=y
# CONFIG_ISCSI_TCP is not set
# CONFIG_ISCSI_BOOT_SYSFS is not set
# CONFIG_SCSI_CXGB3_ISCSI is not set
# CONFIG_SCSI_CXGB4_ISCSI is not set
# CONFIG_SCSI_BNX2_ISCSI is not set
# CONFIG_BE2ISCSI is not set
# CONFIG_BLK_DEV_3W_XXXX_RAID is not set
# CONFIG_SCSI_HPSA is not set
# CONFIG_SCSI_3W_9XXX is not set
# CONFIG_SCSI_3W_SAS is not set
# CONFIG_SCSI_ACARD is not set
# CONFIG_SCSI_AACRAID is not set
# CONFIG_SCSI_AIC7XXX is not set
# CONFIG_SCSI_AIC79XX is not set
# CONFIG_SCSI_AIC94XX is not set
# CONFIG_SCSI_MVSAS is not set
# CONFIG_SCSI_MVUMI is not set
# CONFIG_SCSI_DPT_I2O is not set
# CONFIG_SCSI_ADVANSYS is not set
# CONFIG_SCSI_ARCMSR is not set
# CONFIG_SCSI_ESAS2R is not set
# CONFIG_MEGARAID_NEWGEN is not set
# CONFIG_MEGARAID_LEGACY is not set
# CONFIG_MEGARAID_SAS is not set
CONFIG_SCSI_MPT3SAS=m
CONFIG_SCSI_MPT2SAS_MAX_SGE=128
CONFIG_SCSI_MPT3SAS_MAX_SGE=128
CONFIG_SCSI_MPT2SAS=m
# CONFIG_SCSI_SMARTPQI is not set
# CONFIG_SCSI_UFSHCD is not set
# CONFIG_SCSI_HPTIOP is not set
# CONFIG_SCSI_BUSLOGIC is not set
# CONFIG_SCSI_MYRB is not set
# CONFIG_SCSI_MYRS is not set
# CONFIG_VMWARE_PVSCSI is not set
# CONFIG_SCSI_SNIC is not set
# CONFIG_SCSI_DMX3191D is not set
# CONFIG_SCSI_FDOMAIN_PCI is not set
# CONFIG_SCSI_GDTH is not set
# CONFIG_SCSI_ISCI is not set
# CONFIG_SCSI_IPS is not set
# CONFIG_SCSI_INITIO is not set
# CONFIG_SCSI_INIA100 is not set
# CONFIG_SCSI_STEX is not set
# CONFIG_SCSI_SYM53C8XX_2 is not set
# CONFIG_SCSI_IPR is not set
# CONFIG_SCSI_QLOGIC_1280 is not set
# CONFIG_SCSI_QLA_ISCSI is not set
# CONFIG_SCSI_DC395x is not set
# CONFIG_SCSI_AM53C974 is not set
# CONFIG_SCSI_WD719X is not set
# CONFIG_SCSI_DEBUG is not set
# CONFIG_SCSI_PMCRAID is not set
# CONFIG_SCSI_PM8001 is not set
# CONFIG_SCSI_DH is not set
# end of SCSI device support
CONFIG_ATA=m
CONFIG_ATA_VERBOSE_ERROR=y
CONFIG_ATA_ACPI=y
CONFIG_SATA_PMP=y
#
# Controllers with non-SFF native interface
#
CONFIG_SATA_AHCI=m
CONFIG_SATA_MOBILE_LPM_POLICY=0
CONFIG_SATA_AHCI_PLATFORM=m
# CONFIG_SATA_INIC162X is not set
# CONFIG_SATA_ACARD_AHCI is not set
# CONFIG_SATA_SIL24 is not set
CONFIG_ATA_SFF=y
#
# SFF controllers with custom DMA interface
#
# CONFIG_PDC_ADMA is not set
# CONFIG_SATA_QSTOR is not set
# CONFIG_SATA_SX4 is not set
CONFIG_ATA_BMDMA=y
#
# SATA SFF controllers with BMDMA
#
CONFIG_ATA_PIIX=m
# CONFIG_SATA_MV is not set
# CONFIG_SATA_NV is not set
# CONFIG_SATA_PROMISE is not set
# CONFIG_SATA_SIL is not set
# CONFIG_SATA_SIS is not set
# CONFIG_SATA_SVW is not set
# CONFIG_SATA_ULI is not set
# CONFIG_SATA_VIA is not set
# CONFIG_SATA_VITESSE is not set
#
# PATA SFF controllers with BMDMA
#
# CONFIG_PATA_ALI is not set
# CONFIG_PATA_AMD is not set
# CONFIG_PATA_ARTOP is not set
# CONFIG_PATA_ATIIXP is not set
# CONFIG_PATA_ATP867X is not set
# CONFIG_PATA_CMD64X is not set
# CONFIG_PATA_CYPRESS is not set
# CONFIG_PATA_EFAR is not set
# CONFIG_PATA_HPT366 is not set
# CONFIG_PATA_HPT37X is not set
# CONFIG_PATA_HPT3X2N is not set
# CONFIG_PATA_HPT3X3 is not set
# CONFIG_PATA_IT8213 is not set
# CONFIG_PATA_IT821X is not set
# CONFIG_PATA_JMICRON is not set
# CONFIG_PATA_MARVELL is not set
# CONFIG_PATA_NETCELL is not set
# CONFIG_PATA_NINJA32 is not set
# CONFIG_PATA_NS87415 is not set
# CONFIG_PATA_OLDPIIX is not set
# CONFIG_PATA_OPTIDMA is not set
# CONFIG_PATA_PDC2027X is not set
# CONFIG_PATA_PDC_OLD is not set
# CONFIG_PATA_RADISYS is not set
# CONFIG_PATA_RDC is not set
# CONFIG_PATA_SCH is not set
# CONFIG_PATA_SERVERWORKS is not set
# CONFIG_PATA_SIL680 is not set
# CONFIG_PATA_SIS is not set
# CONFIG_PATA_TOSHIBA is not set
# CONFIG_PATA_TRIFLEX is not set
# CONFIG_PATA_VIA is not set
# CONFIG_PATA_WINBOND is not set
#
# PIO-only SFF controllers
#
# CONFIG_PATA_CMD640_PCI is not set
# CONFIG_PATA_MPIIX is not set
# CONFIG_PATA_NS87410 is not set
# CONFIG_PATA_OPTI is not set
# CONFIG_PATA_PLATFORM is not set
# CONFIG_PATA_RZ1000 is not set
#
# Generic fallback / legacy drivers
#
# CONFIG_PATA_ACPI is not set
# CONFIG_ATA_GENERIC is not set
# CONFIG_PATA_LEGACY 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
# end of IEEE 1394 (FireWire) support
# CONFIG_MACINTOSH_DRIVERS is not set
CONFIG_NETDEVICES=y
CONFIG_MII=m
CONFIG_NET_CORE=y
# CONFIG_BONDING is not set
# CONFIG_DUMMY is not set
# CONFIG_EQUALIZER is not set
# CONFIG_NET_FC is not set
# CONFIG_NET_TEAM is not set
# CONFIG_MACVLAN is not set
# CONFIG_IPVLAN is not set
# CONFIG_VXLAN is not set
# CONFIG_GENEVE is not set
# CONFIG_GTP is not set
# CONFIG_MACSEC is not set
CONFIG_NETCONSOLE=y
CONFIG_NETPOLL=y
CONFIG_NET_POLL_CONTROLLER=y
CONFIG_TUN=m
# CONFIG_TUN_VNET_CROSS_LE is not set
# CONFIG_VETH is not set
# CONFIG_NLMON is not set
# CONFIG_ARCNET is not set
#
# CAIF transport drivers
#
#
# Distributed Switch Architecture drivers
#
# end of Distributed Switch Architecture drivers
CONFIG_ETHERNET=y
CONFIG_MDIO=m
CONFIG_NET_VENDOR_3COM=y
CONFIG_VORTEX=m
CONFIG_TYPHOON=m
# CONFIG_NET_VENDOR_ADAPTEC is not set
# CONFIG_NET_VENDOR_AGERE 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=y
CONFIG_AMD8111_ETH=m
CONFIG_PCNET32=m
# CONFIG_AMD_XGBE is not set
# CONFIG_NET_VENDOR_AQUANTIA is not set
# CONFIG_NET_VENDOR_ARC is not set
# CONFIG_NET_VENDOR_ATHEROS is not set
# CONFIG_NET_VENDOR_AURORA is not set
CONFIG_NET_VENDOR_BROADCOM=y
CONFIG_B44=m
CONFIG_B44_PCI_AUTOSELECT=y
CONFIG_B44_PCICORE_AUTOSELECT=y
CONFIG_B44_PCI=y
# CONFIG_BCMGENET is not set
CONFIG_BNX2=m
CONFIG_CNIC=m
CONFIG_TIGON3=m
CONFIG_TIGON3_HWMON=y
CONFIG_BNX2X=m
# CONFIG_SYSTEMPORT is not set
# CONFIG_BNXT is not set
# CONFIG_NET_VENDOR_BROCADE is not set
# CONFIG_NET_VENDOR_CADENCE 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_NET_VENDOR_CORTINA 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=y
CONFIG_DL2K=m
CONFIG_SUNDANCE=m
# CONFIG_SUNDANCE_MMIO is not set
# CONFIG_NET_VENDOR_EMULEX is not set
# CONFIG_NET_VENDOR_EZCHIP is not set
# CONFIG_NET_VENDOR_GOOGLE is not set
# CONFIG_NET_VENDOR_HP is not set
# CONFIG_NET_VENDOR_HUAWEI is not set
CONFIG_NET_VENDOR_I825XX=y
CONFIG_NET_VENDOR_INTEL=y
CONFIG_E100=m
CONFIG_E1000=m
CONFIG_E1000E=y
CONFIG_E1000E_HWTS=y
CONFIG_IGB=m
CONFIG_IGB_HWMON=y
CONFIG_IGBVF=m
# CONFIG_IXGB is not set
# CONFIG_IXGBE is not set
# CONFIG_IXGBEVF is not set
# CONFIG_I40E is not set
# CONFIG_I40EVF is not set
# CONFIG_ICE is not set
# CONFIG_FM10K is not set
# CONFIG_IGC 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_MICROCHIP is not set
# CONFIG_NET_VENDOR_MICROSEMI is not set
# CONFIG_NET_VENDOR_MYRI is not set
# CONFIG_FEALNX is not set
CONFIG_NET_VENDOR_NATSEMI=y
CONFIG_NATSEMI=m
CONFIG_NS83820=m
# CONFIG_NET_VENDOR_NETERION is not set
# CONFIG_NET_VENDOR_NETRONOME is not set
# CONFIG_NET_VENDOR_NI is not set
CONFIG_NET_VENDOR_8390=y
CONFIG_NE2K_PCI=m
# CONFIG_NET_VENDOR_NVIDIA is not set
# CONFIG_NET_VENDOR_OKI is not set
# CONFIG_ETHOC is not set
# CONFIG_NET_VENDOR_PACKET_ENGINES is not set
# CONFIG_NET_VENDOR_PENSANDO is not set
# CONFIG_NET_VENDOR_QLOGIC is not set
# CONFIG_NET_VENDOR_QUALCOMM is not set
# CONFIG_NET_VENDOR_RDC is not set
CONFIG_NET_VENDOR_REALTEK=y
CONFIG_8139CP=m
CONFIG_8139TOO=m
# CONFIG_8139TOO_PIO is not set
# CONFIG_8139TOO_TUNE_TWISTER is not set
CONFIG_8139TOO_8129=y
# CONFIG_8139_OLD_RX_RESET is not set
CONFIG_R8169=m
# CONFIG_NET_VENDOR_RENESAS 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_SOLARFLARE is not set
# CONFIG_NET_VENDOR_SILAN is not set
CONFIG_NET_VENDOR_SIS=y
CONFIG_SIS900=m
CONFIG_SIS190=m
# CONFIG_NET_VENDOR_SMSC is not set
# CONFIG_NET_VENDOR_SOCIONEXT is not set
# CONFIG_NET_VENDOR_STMICRO is not set
# CONFIG_NET_VENDOR_SUN is not set
# CONFIG_NET_VENDOR_SYNOPSYS is not set
# CONFIG_NET_VENDOR_TEHUTI is not set
# CONFIG_NET_VENDOR_TI is not set
CONFIG_NET_VENDOR_VIA=y
CONFIG_VIA_RHINE=m
# CONFIG_VIA_RHINE_MMIO is not set
CONFIG_VIA_VELOCITY=m
# CONFIG_NET_VENDOR_WIZNET is not set
# CONFIG_NET_VENDOR_XILINX is not set
# CONFIG_FDDI is not set
# CONFIG_HIPPI is not set
# CONFIG_NET_SB1000 is not set
CONFIG_MDIO_DEVICE=m
CONFIG_MDIO_BUS=m
# CONFIG_MDIO_BCM_UNIMAC is not set
# CONFIG_MDIO_BITBANG is not set
# CONFIG_MDIO_MSCC_MIIM is not set
# CONFIG_MDIO_THUNDER is not set
CONFIG_PHYLIB=m
#
# MII PHY device drivers
#
# CONFIG_ADIN_PHY is not set
CONFIG_AMD_PHY=m
# CONFIG_AQUANTIA_PHY is not set
# CONFIG_AX88796B_PHY is not set
# CONFIG_AT803X_PHY is not set
# CONFIG_BCM7XXX_PHY is not set
# CONFIG_BCM87XX_PHY is not set
CONFIG_BCM_NET_PHYLIB=m
CONFIG_BROADCOM_PHY=m
# CONFIG_CICADA_PHY is not set
# CONFIG_CORTINA_PHY is not set
# CONFIG_DAVICOM_PHY is not set
# CONFIG_DP83822_PHY is not set
# CONFIG_DP83TC811_PHY is not set
# CONFIG_DP83848_PHY is not set
# CONFIG_DP83867_PHY is not set
# CONFIG_FIXED_PHY is not set
# CONFIG_ICPLUS_PHY is not set
# CONFIG_INTEL_XWAY_PHY is not set
# CONFIG_LSI_ET1011C_PHY is not set
CONFIG_LXT_PHY=m
CONFIG_MARVELL_PHY=m
# CONFIG_MARVELL_10G_PHY is not set
# CONFIG_MICREL_PHY is not set
# CONFIG_MICROCHIP_PHY is not set
# CONFIG_MICROCHIP_T1_PHY is not set
# CONFIG_MICROSEMI_PHY is not set
CONFIG_NATIONAL_PHY=m
# CONFIG_NXP_TJA11XX_PHY is not set
# CONFIG_QSEMI_PHY is not set
CONFIG_REALTEK_PHY=m
# CONFIG_RENESAS_PHY is not set
# CONFIG_ROCKCHIP_PHY is not set
# CONFIG_SMSC_PHY is not set
CONFIG_STE10XP=m
# CONFIG_TERANETICS_PHY is not set
# CONFIG_VITESSE_PHY is not set
# CONFIG_XILINX_GMII2RGMII is not set
# CONFIG_PPP is not set
# CONFIG_SLIP is not set
CONFIG_USB_NET_DRIVERS=y
CONFIG_USB_CATC=m
CONFIG_USB_KAWETH=m
CONFIG_USB_PEGASUS=m
CONFIG_USB_RTL8150=m
CONFIG_USB_RTL8152=m
# CONFIG_USB_LAN78XX is not set
CONFIG_USB_USBNET=m
CONFIG_USB_NET_AX8817X=m
CONFIG_USB_NET_AX88179_178A=m
CONFIG_USB_NET_CDCETHER=m
# CONFIG_USB_NET_CDC_EEM is not set
CONFIG_USB_NET_CDC_NCM=m
# CONFIG_USB_NET_HUAWEI_CDC_NCM is not set
# CONFIG_USB_NET_CDC_MBIM is not set
# CONFIG_USB_NET_DM9601 is not set
# CONFIG_USB_NET_SR9700 is not set
# CONFIG_USB_NET_SR9800 is not set
# CONFIG_USB_NET_SMSC75XX is not set
# CONFIG_USB_NET_SMSC95XX is not set
CONFIG_USB_NET_GL620A=m
CONFIG_USB_NET_NET1080=m
# CONFIG_USB_NET_PLUSB is not set
# CONFIG_USB_NET_MCS7830 is not set
# CONFIG_USB_NET_RNDIS_HOST is not set
CONFIG_USB_NET_CDC_SUBSET_ENABLE=m
CONFIG_USB_NET_CDC_SUBSET=m
CONFIG_USB_ALI_M5632=y
CONFIG_USB_AN2720=y
CONFIG_USB_BELKIN=y
CONFIG_USB_ARMLINUX=y
CONFIG_USB_EPSON2888=y
# CONFIG_USB_KC2190 is not set
CONFIG_USB_NET_ZAURUS=m
# CONFIG_USB_NET_CX82310_ETH is not set
# CONFIG_USB_NET_KALMIA is not set
# CONFIG_USB_NET_QMI_WWAN is not set
# CONFIG_USB_NET_INT51X1 is not set
# CONFIG_USB_IPHETH is not set
# CONFIG_USB_SIERRA_NET is not set
# CONFIG_USB_VL600 is not set
# CONFIG_USB_NET_CH9200 is not set
# CONFIG_USB_NET_AQC111 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_NETDEVSIM is not set
# CONFIG_NET_FAILOVER is not set
# CONFIG_ISDN is not set
# CONFIG_NVM is not set
#
# Input device support
#
CONFIG_INPUT=y
CONFIG_INPUT_FF_MEMLESS=m
CONFIG_INPUT_POLLDEV=m
# CONFIG_INPUT_SPARSEKMAP is not set
# CONFIG_INPUT_MATRIXKMAP is not set
#
# Userland interfaces
#
CONFIG_INPUT_MOUSEDEV=y
CONFIG_INPUT_MOUSEDEV_PSAUX=y
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_QT1050 is not set
# 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=m
# 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
# end of Hardware I/O ports
# end of Input device support
#
# 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=y
CONFIG_LEGACY_PTY_COUNT=64
CONFIG_SERIAL_NONSTANDARD=y
# CONFIG_ROCKETPORT is not set
# CONFIG_CYCLADES is not set
# CONFIG_MOXA_INTELLIO is not set
# CONFIG_MOXA_SMARTIO is not set
# CONFIG_SYNCLINK is not set
# CONFIG_SYNCLINKMP is not set
# CONFIG_SYNCLINK_GT is not set
# CONFIG_NOZOMI is not set
# CONFIG_ISI is not set
# CONFIG_N_HDLC is not set
# CONFIG_N_GSM is not set
# CONFIG_TRACE_SINK is not set
# CONFIG_NULL_TTY is not set
CONFIG_LDISC_AUTOLOAD=y
CONFIG_DEVMEM=y
CONFIG_DEVKMEM=y
#
# Serial drivers
#
CONFIG_SERIAL_EARLYCON=y
CONFIG_SERIAL_8250=y
CONFIG_SERIAL_8250_DEPRECATED_OPTIONS=y
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=8
CONFIG_SERIAL_8250_RUNTIME_UARTS=8
CONFIG_SERIAL_8250_EXTENDED=y
# CONFIG_SERIAL_8250_MANY_PORTS is not set
CONFIG_SERIAL_8250_SHARE_IRQ=y
# CONFIG_SERIAL_8250_DETECT_IRQ is not set
CONFIG_SERIAL_8250_RSA=y
CONFIG_SERIAL_8250_DWLIB=y
# CONFIG_SERIAL_8250_DW is not set
# CONFIG_SERIAL_8250_RT288X is not set
CONFIG_SERIAL_8250_LPSS=y
CONFIG_SERIAL_8250_MID=y
#
# 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_FSL_LINFLEXUART is not set
# end of Serial drivers
# CONFIG_SERIAL_DEV_BUS is not set
# CONFIG_TTY_PRINTK is not set
# CONFIG_IPMI_HANDLER is not set
CONFIG_HW_RANDOM=y
# CONFIG_HW_RANDOM_TIMERIOMEM is not set
CONFIG_HW_RANDOM_INTEL=y
# CONFIG_HW_RANDOM_AMD is not set
# CONFIG_HW_RANDOM_VIA is not set
CONFIG_NVRAM=m
# CONFIG_APPLICOM is not set
# CONFIG_MWAVE is not set
# CONFIG_RAW_DRIVER is not set
# CONFIG_HPET is not set
# 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
# end of Character devices
# CONFIG_RANDOM_TRUST_CPU is not set
# CONFIG_RANDOM_TRUST_BOOTLOADER is not set
#
# I2C support
#
CONFIG_I2C=y
CONFIG_ACPI_I2C_OPREGION=y
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_SMBUS=y
CONFIG_I2C_ALGOBIT=m
#
# 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_AMD_MP2 is not set
CONFIG_I2C_I801=y
# CONFIG_I2C_ISCH is not set
# CONFIG_I2C_ISMT is not set
CONFIG_I2C_PIIX4=m
# CONFIG_I2C_NFORCE2 is not set
# CONFIG_I2C_NVIDIA_GPU 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_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
# end of I2C Hardware Bus support
# CONFIG_I2C_STUB 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
# end of I2C support
# CONFIG_I3C is not set
# CONFIG_SPI is not set
# CONFIG_SPMI is not set
# CONFIG_HSI is not set
CONFIG_PPS=y
# CONFIG_PPS_DEBUG is not set
#
# PPS clients support
#
# CONFIG_PPS_CLIENT_KTIMER is not set
# CONFIG_PPS_CLIENT_LDISC is not set
# CONFIG_PPS_CLIENT_GPIO is not set
#
# PPS generators support
#
#
# PTP clock support
#
CONFIG_PTP_1588_CLOCK=y
#
# Enable PHYLIB and NETWORK_PHY_TIMESTAMPING to see the additional clocks.
#
# end of PTP clock support
# CONFIG_PINCTRL is not set
# 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 is not set
CONFIG_HWMON=m
CONFIG_HWMON_VID=m
# 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_AS370 is not set
# CONFIG_SENSORS_ASC7621 is not set
# CONFIG_SENSORS_K8TEMP 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_FTSTEUTATES 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=m
CONFIG_SENSORS_CORETEMP=m
# 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_MAX6621 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=m
CONFIG_SENSORS_LM73=m
CONFIG_SENSORS_LM75=m
CONFIG_SENSORS_LM77=m
CONFIG_SENSORS_LM78=m
CONFIG_SENSORS_LM80=m
CONFIG_SENSORS_LM83=m
CONFIG_SENSORS_LM85=m
CONFIG_SENSORS_LM87=m
CONFIG_SENSORS_LM90=m
CONFIG_SENSORS_LM92=m
CONFIG_SENSORS_LM93=m
CONFIG_SENSORS_LM95234=m
CONFIG_SENSORS_LM95241=m
CONFIG_SENSORS_LM95245=m
CONFIG_SENSORS_PC87360=m
CONFIG_SENSORS_PC87427=m
# 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_NPCM7XX 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_SCH5627 is not set
# CONFIG_SENSORS_SCH5636 is not set
# CONFIG_SENSORS_STTS751 is not set
# CONFIG_SENSORS_SMM665 is not set
# CONFIG_SENSORS_ADC128D818 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_W83773G 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 is not set
# CONFIG_THERMAL is not set
CONFIG_WATCHDOG=y
CONFIG_WATCHDOG_CORE=y
# CONFIG_WATCHDOG_NOWAYOUT is not set
CONFIG_WATCHDOG_HANDLE_BOOT_ENABLED=y
CONFIG_WATCHDOG_OPEN_TIMEOUT=0
# CONFIG_WATCHDOG_SYSFS is not set
#
# Watchdog Pretimeout Governors
#
# CONFIG_WATCHDOG_PRETIMEOUT_GOV is not set
#
# Watchdog Device Drivers
#
# CONFIG_SOFT_WATCHDOG is not set
# CONFIG_WDAT_WDT is not set
# CONFIG_XILINX_WATCHDOG is not set
# CONFIG_ZIIRAVE_WATCHDOG is not set
# CONFIG_CADENCE_WATCHDOG is not set
# CONFIG_DW_WATCHDOG is not set
# CONFIG_MAX63XX_WATCHDOG is not set
# CONFIG_ACQUIRE_WDT is not set
# CONFIG_ADVANTECH_WDT is not set
# CONFIG_ALIM1535_WDT is not set
# CONFIG_ALIM7101_WDT is not set
# CONFIG_EBC_C384_WDT is not set
# CONFIG_F71808E_WDT is not set
# CONFIG_SP5100_TCO is not set
# CONFIG_SBC_FITPC2_WATCHDOG is not set
# CONFIG_EUROTECH_WDT is not set
# CONFIG_IB700_WDT is not set
# CONFIG_IBMASR is not set
# CONFIG_WAFER_WDT is not set
CONFIG_I6300ESB_WDT=m
CONFIG_IE6XX_WDT=m
CONFIG_ITCO_WDT=m
CONFIG_ITCO_VENDOR_SUPPORT=y
# CONFIG_IT8712F_WDT is not set
# CONFIG_IT87_WDT is not set
# CONFIG_HP_WATCHDOG is not set
# CONFIG_SC1200_WDT is not set
# CONFIG_PC87413_WDT is not set
# CONFIG_NV_TCO is not set
# CONFIG_60XX_WDT is not set
# CONFIG_CPU5_WDT is not set
# CONFIG_SMSC_SCH311X_WDT is not set
# CONFIG_SMSC37B787_WDT is not set
# CONFIG_TQMX86_WDT is not set
# CONFIG_VIA_WDT is not set
# CONFIG_W83627HF_WDT is not set
# CONFIG_W83877F_WDT is not set
# CONFIG_W83977F_WDT is not set
# CONFIG_MACHZ_WDT is not set
# CONFIG_SBC_EPX_C3_WATCHDOG is not set
# CONFIG_NI903X_WDT is not set
# CONFIG_NIC7018_WDT is not set
#
# PCI-based Watchdog Cards
#
# CONFIG_PCIPCWATCHDOG is not set
# CONFIG_WDTPCI is not set
#
# USB-based Watchdog Cards
#
# CONFIG_USBPCWATCHDOG is not set
CONFIG_SSB_POSSIBLE=y
CONFIG_SSB=m
CONFIG_SSB_SPROM=y
CONFIG_SSB_PCIHOST_POSSIBLE=y
CONFIG_SSB_PCIHOST=y
CONFIG_SSB_DRIVER_PCICORE_POSSIBLE=y
CONFIG_SSB_DRIVER_PCICORE=y
CONFIG_BCMA_POSSIBLE=y
# CONFIG_BCMA is not set
#
# Multifunction device drivers
#
CONFIG_MFD_CORE=m
# 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_MADERA 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=m
CONFIG_LPC_SCH=m
# 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_RT5033 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_TI_LP873X 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_TQMX86 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
# end of Multifunction device drivers
# 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=y
CONFIG_VGA_ARB_MAX_GPUS=16
# CONFIG_VGA_SWITCHEROO is not set
# CONFIG_DRM is not set
# CONFIG_DRM_DP_CEC is not set
#
# ARM devices
#
# end of ARM devices
#
# ACP (Audio CoProcessor) Configuration
#
# end of ACP (Audio CoProcessor) Configuration
#
# Frame buffer Devices
#
CONFIG_FB_CMDLINE=y
CONFIG_FB_NOTIFY=y
CONFIG_FB=y
CONFIG_FIRMWARE_EDID=y
CONFIG_FB_BOOT_VESA_SUPPORT=y
CONFIG_FB_CFB_FILLRECT=y
CONFIG_FB_CFB_COPYAREA=y
CONFIG_FB_CFB_IMAGEBLIT=y
# CONFIG_FB_FOREIGN_ENDIAN is not set
CONFIG_FB_MODE_HELPERS=y
CONFIG_FB_TILEBLITTING=y
#
# 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_UVESA is not set
CONFIG_FB_VESA=y
# 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_SIMPLE is not set
# CONFIG_FB_SM712 is not set
# end of Frame buffer Devices
#
# Backlight & LCD device support
#
# CONFIG_LCD_CLASS_DEVICE is not set
# CONFIG_BACKLIGHT_CLASS_DEVICE is not set
# end of Backlight & LCD device support
#
# Console display driver support
#
CONFIG_VGA_CONSOLE=y
CONFIG_DUMMY_CONSOLE=y
CONFIG_DUMMY_CONSOLE_COLUMNS=80
CONFIG_DUMMY_CONSOLE_ROWS=25
CONFIG_FRAMEBUFFER_CONSOLE=y
# CONFIG_FRAMEBUFFER_CONSOLE_DETECT_PRIMARY is not set
# CONFIG_FRAMEBUFFER_CONSOLE_ROTATION is not set
# CONFIG_FRAMEBUFFER_CONSOLE_DEFERRED_TAKEOVER is not set
# end of Console display driver support
# CONFIG_LOGO is not set
# end of Graphics support
# CONFIG_SOUND is not set
#
# HID support
#
CONFIG_HID=y
# CONFIG_HID_BATTERY_STRENGTH is not set
# CONFIG_HIDRAW is not set
# 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_COUGAR is not set
# CONFIG_HID_MACALLY is not set
# CONFIG_HID_CMEDIA is not set
# CONFIG_HID_CREATIVE_SB0540 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_VIEWSONIC is not set
# CONFIG_HID_GYRATION is not set
# CONFIG_HID_ICADE is not set
# CONFIG_HID_ITE is not set
# CONFIG_HID_JABRA 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 is not set
# CONFIG_HID_MAGICMOUSE is not set
# CONFIG_HID_MALTRON is not set
# CONFIG_HID_MAYFLASH is not set
# CONFIG_HID_REDRAGON 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_STEAM 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
# end of Special HID drivers
#
# USB HID support
#
CONFIG_USB_HID=y
# CONFIG_HID_PID is not set
CONFIG_USB_HIDDEV=y
# end of USB HID support
#
# I2C HID support
#
# CONFIG_I2C_HID is not set
# end of I2C HID support
#
# Intel ISH HID support
#
# CONFIG_INTEL_ISH_HID is not set
# end of Intel ISH HID support
# end of HID support
CONFIG_USB_OHCI_LITTLE_ENDIAN=y
CONFIG_USB_SUPPORT=y
CONFIG_USB_COMMON=y
# CONFIG_USB_ULPI_BUS is not set
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_WHITELIST is not set
# CONFIG_USB_OTG_BLACKLIST_HUB is not set
CONFIG_USB_AUTOSUSPEND_DELAY=2
# CONFIG_USB_MON is not set
#
# USB Host Controller Drivers
#
# CONFIG_USB_C67X00_HCD is not set
CONFIG_USB_XHCI_HCD=y
# CONFIG_USB_XHCI_DBGCAP is not set
CONFIG_USB_XHCI_PCI=y
# CONFIG_USB_XHCI_PLATFORM is not set
CONFIG_USB_EHCI_HCD=y
# CONFIG_USB_EHCI_ROOT_HUB_TT is not set
CONFIG_USB_EHCI_TT_NEWSCHED=y
CONFIG_USB_EHCI_PCI=y
# CONFIG_USB_EHCI_FSL is not set
CONFIG_USB_EHCI_HCD_PLATFORM=m
# CONFIG_USB_OXU210HP_HCD is not set
# CONFIG_USB_ISP116X_HCD is not set
# CONFIG_USB_FOTG210_HCD is not set
CONFIG_USB_OHCI_HCD=m
CONFIG_USB_OHCI_HCD_PCI=m
# CONFIG_USB_OHCI_HCD_SSB is not set
# CONFIG_USB_OHCI_HCD_PLATFORM is not set
CONFIG_USB_UHCI_HCD=y
# CONFIG_USB_SL811_HCD is not set
# CONFIG_USB_R8A66597_HCD is not set
# CONFIG_USB_HCD_SSB is not set
# CONFIG_USB_HCD_TEST_MODE is not set
#
# USB Device Class drivers
#
# CONFIG_USB_ACM is not set
# CONFIG_USB_PRINTER is not set
# 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=m
# 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_CDNS3 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_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
# CONFIG_USB_CHAOSKEY is not set
#
# USB Physical Layer drivers
#
# CONFIG_NOP_USB_XCEIV is not set
# CONFIG_USB_ISP1301 is not set
# end of USB Physical Layer drivers
# CONFIG_USB_GADGET is not set
# CONFIG_TYPEC is not set
# CONFIG_USB_ROLE_SWITCH 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 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=y
# CONFIG_RTC_DRV_TEST is not set
#
# I2C RTC drivers
#
# CONFIG_RTC_DRV_ABB5ZES3 is not set
# CONFIG_RTC_DRV_ABEOZ9 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_PCF85363 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_RV3028 is not set
# CONFIG_RTC_DRV_RV8803 is not set
# CONFIG_RTC_DRV_SD3078 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_DMADEVICES is not set
#
# DMABUF options
#
# CONFIG_SYNC_FILE is not set
# end of DMABUF options
# CONFIG_AUXDISPLAY is not set
CONFIG_UIO=m
# CONFIG_UIO_CIF is not set
# CONFIG_UIO_PDRV_GENIRQ is not set
# CONFIG_UIO_DMEM_GENIRQ is not set
# CONFIG_UIO_AEC is not set
# CONFIG_UIO_SERCOS3 is not set
# CONFIG_UIO_PCI_GENERIC is not set
# CONFIG_UIO_NETX is not set
# CONFIG_UIO_PRUSS is not set
# CONFIG_UIO_MF624 is not set
# CONFIG_VIRT_DRIVERS is not set
# CONFIG_VIRTIO_MENU is not set
#
# Microsoft Hyper-V guest support
#
# end of Microsoft Hyper-V guest support
# CONFIG_GREYBUS is not set
# CONFIG_STAGING is not set
# CONFIG_X86_PLATFORM_DEVICES is not set
CONFIG_PMC_ATOM=y
# CONFIG_MFD_CROS_EC is not set
# CONFIG_CHROME_PLATFORMS is not set
# CONFIG_MELLANOX_PLATFORM is not set
CONFIG_CLKDEV_LOOKUP=y
CONFIG_HAVE_CLK_PREPARE=y
CONFIG_COMMON_CLK=y
#
# Common Clock Framework
#
# CONFIG_COMMON_CLK_MAX9485 is not set
# CONFIG_COMMON_CLK_SI5341 is not set
# CONFIG_COMMON_CLK_SI5351 is not set
# CONFIG_COMMON_CLK_SI544 is not set
# CONFIG_COMMON_CLK_CDCE706 is not set
# CONFIG_COMMON_CLK_CS2000_CP is not set
# end of Common Clock Framework
# CONFIG_HWSPINLOCK is not set
#
# Clock Source drivers
#
CONFIG_CLKEVT_I8253=y
CONFIG_CLKBLD_I8253=y
# end of Clock Source drivers
# CONFIG_MAILBOX is not set
# CONFIG_IOMMU_SUPPORT is not set
#
# Remoteproc drivers
#
# CONFIG_REMOTEPROC is not set
# end of Remoteproc drivers
#
# Rpmsg drivers
#
# CONFIG_RPMSG_VIRTIO is not set
# end of Rpmsg drivers
# CONFIG_SOUNDWIRE is not set
#
# SOC (System On Chip) specific Drivers
#
#
# Amlogic SoC drivers
#
# end of Amlogic SoC drivers
#
# Aspeed SoC drivers
#
# end of Aspeed SoC drivers
#
# Broadcom SoC drivers
#
# end of Broadcom SoC drivers
#
# NXP/Freescale QorIQ SoC drivers
#
# end of NXP/Freescale QorIQ SoC drivers
#
# i.MX SoC drivers
#
# end of i.MX SoC drivers
#
# Qualcomm SoC drivers
#
# end of Qualcomm SoC drivers
# CONFIG_SOC_TI is not set
#
# Xilinx SoC drivers
#
# CONFIG_XILINX_VCU is not set
# end of Xilinx SoC drivers
# end of SOC (System On Chip) specific Drivers
# 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
#
# IRQ chip support
#
# end of IRQ chip support
# CONFIG_IPACK_BUS is not set
# CONFIG_RESET_CONTROLLER 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
# end of PHY Subsystem
# CONFIG_POWERCAP is not set
# CONFIG_MCB is not set
#
# Performance monitor support
#
# end of Performance monitor support
CONFIG_RAS=y
# CONFIG_THUNDERBOLT is not set
#
# Android
#
# CONFIG_ANDROID is not set
# end of Android
# CONFIG_LIBNVDIMM is not set
# CONFIG_DAX is not set
CONFIG_NVMEM=y
CONFIG_NVMEM_SYSFS=y
#
# HW tracing support
#
# CONFIG_STM is not set
# CONFIG_INTEL_TH is not set
# end of HW tracing support
# CONFIG_FPGA is not set
# CONFIG_UNISYS_VISORBUS is not set
# CONFIG_SIOX is not set
# CONFIG_SLIMBUS is not set
# CONFIG_INTERCONNECT is not set
# CONFIG_COUNTER is not set
# end of Device Drivers
#
# File systems
#
CONFIG_DCACHE_WORD_ACCESS=y
# CONFIG_VALIDATE_FS_PARSER is not set
CONFIG_FS_IOMAP=y
CONFIG_EXT2_FS=y
CONFIG_EXT2_FS_XATTR=y
CONFIG_EXT2_FS_POSIX_ACL=y
CONFIG_EXT2_FS_SECURITY=y
CONFIG_EXT3_FS=y
CONFIG_EXT3_FS_POSIX_ACL=y
CONFIG_EXT3_FS_SECURITY=y
CONFIG_EXT4_FS=y
CONFIG_EXT4_FS_POSIX_ACL=y
CONFIG_EXT4_FS_SECURITY=y
# 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_OCFS2_FS is not set
# CONFIG_BTRFS_FS 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=m
CONFIG_EXPORTFS_BLOCK_OPS=y
CONFIG_FILE_LOCKING=y
CONFIG_MANDATORY_FILE_LOCKING=y
# CONFIG_FS_ENCRYPTION is not set
# CONFIG_FS_VERITY is not set
CONFIG_FSNOTIFY=y
# CONFIG_DNOTIFY is not set
# CONFIG_INOTIFY_USER is not set
# CONFIG_FANOTIFY is not set
# CONFIG_QUOTA is not set
# CONFIG_AUTOFS4_FS is not set
# CONFIG_AUTOFS_FS is not set
# CONFIG_FUSE_FS is not set
# CONFIG_OVERLAY_FS is not set
#
# Caches
#
# CONFIG_FSCACHE is not set
# end of Caches
#
# CD-ROM/DVD Filesystems
#
# CONFIG_ISO9660_FS is not set
# CONFIG_UDF_FS is not set
# end of CD-ROM/DVD Filesystems
#
# DOS/FAT/NT Filesystems
#
CONFIG_FAT_FS=m
CONFIG_MSDOS_FS=m
CONFIG_VFAT_FS=m
CONFIG_FAT_DEFAULT_CODEPAGE=437
CONFIG_FAT_DEFAULT_IOCHARSET="iso8859-1"
# CONFIG_FAT_DEFAULT_UTF8 is not set
# CONFIG_NTFS_FS is not set
# end of DOS/FAT/NT Filesystems
#
# Pseudo filesystems
#
CONFIG_PROC_FS=y
CONFIG_PROC_KCORE=y
CONFIG_PROC_VMCORE=y
# CONFIG_PROC_VMCORE_DEVICE_DUMP is not set
CONFIG_PROC_SYSCTL=y
CONFIG_PROC_PAGE_MONITOR=y
# CONFIG_PROC_CHILDREN is not set
CONFIG_PROC_PID_ARCH_STATUS=y
CONFIG_KERNFS=y
CONFIG_SYSFS=y
CONFIG_TMPFS=y
CONFIG_TMPFS_POSIX_ACL=y
CONFIG_TMPFS_XATTR=y
CONFIG_HUGETLBFS=y
CONFIG_HUGETLB_PAGE=y
CONFIG_MEMFD_CREATE=y
CONFIG_ARCH_HAS_GIGANTIC_PAGE=y
CONFIG_CONFIGFS_FS=m
# end of Pseudo filesystems
# CONFIG_MISC_FILESYSTEMS is not set
CONFIG_NETWORK_FILESYSTEMS=y
CONFIG_NFS_FS=y
CONFIG_NFS_V2=y
CONFIG_NFS_V3=y
CONFIG_NFS_V3_ACL=y
CONFIG_NFS_V4=y
CONFIG_NFS_V4_1=y
CONFIG_NFS_V4_2=y
CONFIG_PNFS_FILE_LAYOUT=y
CONFIG_PNFS_FLEXFILE_LAYOUT=m
CONFIG_NFS_V4_1_IMPLEMENTATION_ID_DOMAIN="kernel.org"
CONFIG_NFS_V4_1_MIGRATION=y
CONFIG_ROOT_NFS=y
# CONFIG_NFS_USE_LEGACY_DNS is not set
CONFIG_NFS_USE_KERNEL_DNS=y
CONFIG_NFSD=m
CONFIG_NFSD_V2_ACL=y
CONFIG_NFSD_V3=y
CONFIG_NFSD_V3_ACL=y
CONFIG_NFSD_V4=y
CONFIG_NFSD_PNFS=y
CONFIG_NFSD_BLOCKLAYOUT=y
CONFIG_NFSD_SCSILAYOUT=y
CONFIG_NFSD_FLEXFILELAYOUT=y
CONFIG_GRACE_PERIOD=y
CONFIG_LOCKD=y
CONFIG_LOCKD_V4=y
CONFIG_NFS_ACL_SUPPORT=y
CONFIG_NFS_COMMON=y
CONFIG_SUNRPC=y
CONFIG_SUNRPC_GSS=y
CONFIG_SUNRPC_BACKCHANNEL=y
# CONFIG_SUNRPC_DEBUG is not set
# CONFIG_CEPH_FS is not set
# CONFIG_CIFS is not set
# CONFIG_CODA_FS is not set
# CONFIG_AFS_FS is not set
CONFIG_NLS=y
CONFIG_NLS_DEFAULT="utf8"
CONFIG_NLS_CODEPAGE_437=m
# CONFIG_NLS_CODEPAGE_737 is not set
# CONFIG_NLS_CODEPAGE_775 is not set
CONFIG_NLS_CODEPAGE_850=m
# 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=m
CONFIG_NLS_ISO8859_1=m
# 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=m
# 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
# CONFIG_DLM is not set
# CONFIG_UNICODE is not set
# end of File systems
#
# Security options
#
CONFIG_KEYS=y
# CONFIG_KEYS_REQUEST_CACHE is not set
# CONFIG_PERSISTENT_KEYRINGS is not set
# CONFIG_BIG_KEYS is not set
# CONFIG_ENCRYPTED_KEYS is not set
# CONFIG_KEY_DH_OPERATIONS is not set
# CONFIG_SECURITY_DMESG_RESTRICT is not set
# CONFIG_SECURITY is not set
# CONFIG_SECURITYFS is not set
CONFIG_PAGE_TABLE_ISOLATION=y
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_LSM="lockdown,yama,loadpin,safesetid,integrity"
#
# Kernel hardening options
#
#
# Memory initialization
#
CONFIG_INIT_STACK_NONE=y
# CONFIG_INIT_ON_ALLOC_DEFAULT_ON is not set
# CONFIG_INIT_ON_FREE_DEFAULT_ON is not set
# end of Memory initialization
# end of Kernel hardening options
# end of Security options
CONFIG_CRYPTO=y
#
# Crypto core or helper
#
CONFIG_CRYPTO_ALGAPI=y
CONFIG_CRYPTO_ALGAPI2=y
CONFIG_CRYPTO_AEAD=m
CONFIG_CRYPTO_AEAD2=y
CONFIG_CRYPTO_BLKCIPHER=y
CONFIG_CRYPTO_BLKCIPHER2=y
CONFIG_CRYPTO_HASH=y
CONFIG_CRYPTO_HASH2=y
CONFIG_CRYPTO_RNG=m
CONFIG_CRYPTO_RNG2=y
CONFIG_CRYPTO_RNG_DEFAULT=m
CONFIG_CRYPTO_AKCIPHER2=y
CONFIG_CRYPTO_KPP2=y
CONFIG_CRYPTO_ACOMP2=y
CONFIG_CRYPTO_MANAGER=m
CONFIG_CRYPTO_MANAGER2=y
# CONFIG_CRYPTO_USER is not set
# CONFIG_CRYPTO_MANAGER_DISABLE_TESTS is not set
# CONFIG_CRYPTO_MANAGER_EXTRA_TESTS is not set
CONFIG_CRYPTO_NULL=m
CONFIG_CRYPTO_NULL2=y
# CONFIG_CRYPTO_PCRYPT is not set
# CONFIG_CRYPTO_CRYPTD is not set
CONFIG_CRYPTO_AUTHENC=m
# CONFIG_CRYPTO_TEST is not set
#
# Public-key cryptography
#
# CONFIG_CRYPTO_RSA is not set
# CONFIG_CRYPTO_DH is not set
# CONFIG_CRYPTO_ECDH is not set
# CONFIG_CRYPTO_ECRDSA 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_AEGIS128 is not set
# CONFIG_CRYPTO_AEGIS128_AESNI_SSE2 is not set
# CONFIG_CRYPTO_SEQIV is not set
CONFIG_CRYPTO_ECHAINIV=m
#
# Block modes
#
CONFIG_CRYPTO_CBC=m
# CONFIG_CRYPTO_CFB 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_OFB is not set
# CONFIG_CRYPTO_PCBC is not set
# CONFIG_CRYPTO_XTS is not set
# CONFIG_CRYPTO_KEYWRAP is not set
# CONFIG_CRYPTO_NHPOLY1305_SSE2 is not set
# CONFIG_CRYPTO_NHPOLY1305_AVX2 is not set
# CONFIG_CRYPTO_ADIANTUM is not set
# CONFIG_CRYPTO_ESSIV is not set
#
# Hash modes
#
# CONFIG_CRYPTO_CMAC is not set
CONFIG_CRYPTO_HMAC=m
# 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_XXHASH 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=m
# 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=m
# CONFIG_CRYPTO_SHA1_SSSE3 is not set
# CONFIG_CRYPTO_SHA256_SSSE3 is not set
# CONFIG_CRYPTO_SHA512_SSSE3 is not set
CONFIG_CRYPTO_LIB_SHA256=m
CONFIG_CRYPTO_SHA256=m
# CONFIG_CRYPTO_SHA512 is not set
# CONFIG_CRYPTO_SHA3 is not set
# CONFIG_CRYPTO_SM3 is not set
# CONFIG_CRYPTO_STREEBOG 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 is not set
# CONFIG_CRYPTO_AES_TI 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_LIB_DES=m
CONFIG_CRYPTO_DES=m
# 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_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_SM4 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=m
# CONFIG_CRYPTO_LZO is not set
# CONFIG_CRYPTO_842 is not set
# CONFIG_CRYPTO_LZ4 is not set
# CONFIG_CRYPTO_LZ4HC is not set
# CONFIG_CRYPTO_ZSTD is not set
#
# Random Number Generation
#
# CONFIG_CRYPTO_ANSI_CPRNG is not set
CONFIG_CRYPTO_DRBG_MENU=m
CONFIG_CRYPTO_DRBG_HMAC=y
# CONFIG_CRYPTO_DRBG_HASH is not set
CONFIG_CRYPTO_DRBG=m
CONFIG_CRYPTO_JITTERENTROPY=m
# 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
# CONFIG_ASYMMETRIC_KEY_TYPE is not set
#
# Certificates for signature checking
#
# CONFIG_SYSTEM_BLACKLIST_KEYRING is not set
# end of Certificates for signature checking
CONFIG_BINARY_PRINTF=y
#
# Library routines
#
# CONFIG_PACKING is not set
CONFIG_BITREVERSE=y
CONFIG_GENERIC_STRNCPY_FROM_USER=y
CONFIG_GENERIC_STRNLEN_USER=y
CONFIG_GENERIC_NET_UTILS=y
CONFIG_GENERIC_FIND_FIRST_BIT=y
# CONFIG_CORDIC is not set
CONFIG_RATIONAL=y
CONFIG_GENERIC_PCI_IOMAP=y
CONFIG_GENERIC_IOMAP=y
CONFIG_ARCH_USE_CMPXCHG_LOCKREF=y
CONFIG_ARCH_HAS_FAST_MULTIPLIER=y
CONFIG_CRC_CCITT=m
CONFIG_CRC16=y
# CONFIG_CRC_T10DIF is not set
CONFIG_CRC_ITU_T=m
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_CRC64 is not set
# CONFIG_CRC4 is not set
# CONFIG_CRC7 is not set
CONFIG_LIBCRC32C=m
# CONFIG_CRC8 is not set
# CONFIG_RANDOM32_SELFTEST is not set
CONFIG_ZLIB_INFLATE=y
CONFIG_ZLIB_DEFLATE=m
# CONFIG_XZ_DEC is not set
CONFIG_DECOMPRESS_GZIP=y
CONFIG_GENERIC_ALLOCATOR=y
CONFIG_ASSOCIATIVE_ARRAY=y
CONFIG_HAS_IOMEM=y
CONFIG_HAS_IOPORT_MAP=y
CONFIG_HAS_DMA=y
CONFIG_NEED_SG_DMA_LENGTH=y
CONFIG_NEED_DMA_MAP_STATE=y
CONFIG_ARCH_DMA_ADDR_T_64BIT=y
CONFIG_SWIOTLB=y
# CONFIG_DMA_API_DEBUG is not set
CONFIG_SGL_ALLOC=y
CONFIG_CHECK_SIGNATURE=y
CONFIG_CPU_RMAP=y
CONFIG_DQL=y
CONFIG_GLOB=y
# CONFIG_GLOB_SELFTEST is not set
CONFIG_NLATTR=y
CONFIG_IRQ_POLL=y
CONFIG_OID_REGISTRY=y
CONFIG_HAVE_GENERIC_VDSO=y
CONFIG_GENERIC_GETTIMEOFDAY=y
CONFIG_FONT_SUPPORT=y
# CONFIG_FONTS is not set
CONFIG_FONT_8x8=y
CONFIG_FONT_8x16=y
CONFIG_SG_POOL=y
CONFIG_ARCH_HAS_PMEM_API=y
CONFIG_ARCH_HAS_UACCESS_FLUSHCACHE=y
CONFIG_ARCH_HAS_UACCESS_MCSAFE=y
CONFIG_ARCH_STACKWALK=y
CONFIG_SBITMAP=y
# CONFIG_STRING_SELFTEST is not set
# end of Library routines
#
# Kernel hacking
#
#
# printk and dmesg options
#
CONFIG_PRINTK_TIME=y
# CONFIG_PRINTK_CALLER is not set
CONFIG_CONSOLE_LOGLEVEL_DEFAULT=7
CONFIG_CONSOLE_LOGLEVEL_QUIET=4
CONFIG_MESSAGE_LOGLEVEL_DEFAULT=4
# CONFIG_BOOT_PRINTK_DELAY is not set
# CONFIG_DYNAMIC_DEBUG is not set
# end of printk and dmesg options
#
# Compile-time checks and compiler options
#
# CONFIG_DEBUG_INFO is not set
CONFIG_ENABLE_MUST_CHECK=y
CONFIG_FRAME_WARN=1024
# CONFIG_STRIP_ASM_SYMS is not set
# CONFIG_READABLE_ASM is not set
CONFIG_DEBUG_FS=y
# CONFIG_HEADERS_INSTALL is not set
CONFIG_OPTIMIZE_INLINING=y
# 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
# end of Compile-time checks and compiler options
CONFIG_MAGIC_SYSRQ=y
CONFIG_MAGIC_SYSRQ_DEFAULT_ENABLE=0x1
CONFIG_MAGIC_SYSRQ_SERIAL=y
CONFIG_IPIPE_DEBUG=y
CONFIG_IPIPE_DEBUG_CONTEXT=y
CONFIG_IPIPE_DEBUG_INTERNAL=y
CONFIG_HAVE_IPIPE_TRACER_SUPPORT=y
CONFIG_IPIPE_TRACE=y
# CONFIG_IPIPE_TRACE_ENABLE is not set
CONFIG_IPIPE_TRACE_MCOUNT=y
CONFIG_IPIPE_TRACE_IRQSOFF=y
CONFIG_IPIPE_TRACE_SHIFT=14
# CONFIG_IPIPE_TRACE_VMALLOC is not set
CONFIG_IPIPE_TRACE_PANIC=y
CONFIG_DEBUG_KERNEL=y
# CONFIG_DEBUG_MISC is not set
#
# Memory Debugging
#
# CONFIG_PAGE_EXTENSION is not set
# CONFIG_DEBUG_PAGEALLOC is not set
# CONFIG_PAGE_OWNER is not set
# CONFIG_PAGE_POISONING is not set
# CONFIG_DEBUG_PAGE_REF is not set
# CONFIG_DEBUG_RODATA_TEST is not set
# CONFIG_DEBUG_OBJECTS is not set
# CONFIG_DEBUG_SLAB 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_ARCH_KASAN=y
CONFIG_CC_HAS_KASAN_GENERIC=y
# CONFIG_KASAN is not set
CONFIG_KASAN_STACK=1
# end of Memory Debugging
CONFIG_ARCH_HAS_KCOV=y
CONFIG_CC_HAS_SANCOV_TRACE_PC=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
# end of Debug Lockups and Hangs
# CONFIG_PANIC_ON_OOPS is not set
CONFIG_PANIC_ON_OOPS_VALUE=0
CONFIG_PANIC_TIMEOUT=0
# CONFIG_SCHED_DEBUG is not set
# CONFIG_SCHEDSTATS is not set
# CONFIG_SCHED_STACK_END_CHECK is not set
# CONFIG_DEBUG_TIMEKEEPING is not set
# CONFIG_DEBUG_PREEMPT is not set
#
# Lock Debugging (spinlocks, mutexes, etc...)
#
CONFIG_LOCK_DEBUGGING_SUPPORT=y
# CONFIG_PROVE_LOCKING is not set
# CONFIG_LOCK_STAT is not set
# 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_RWSEMS is not set
# CONFIG_DEBUG_LOCK_ALLOC 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
# end of Lock Debugging (spinlocks, mutexes, etc...)
CONFIG_STACKTRACE=y
# CONFIG_WARN_ALL_UNSEEDED_RANDOM is not set
# CONFIG_DEBUG_KOBJECT is not set
# CONFIG_DEBUG_BUGVERBOSE is not set
# CONFIG_DEBUG_LIST is not set
# CONFIG_DEBUG_PLIST is not set
# CONFIG_DEBUG_SG is not set
# CONFIG_DEBUG_NOTIFIERS is not set
# CONFIG_DEBUG_CREDENTIALS is not set
#
# RCU Debugging
#
# CONFIG_RCU_PERF_TEST is not set
# CONFIG_RCU_TORTURE_TEST is not set
CONFIG_RCU_CPU_STALL_TIMEOUT=21
# CONFIG_RCU_TRACE is not set
# CONFIG_RCU_EQS_DEBUG is not set
# end of RCU Debugging
# CONFIG_DEBUG_WQ_FORCE_RR_CPU is not set
# CONFIG_DEBUG_BLOCK_EXT_DEVT is not set
# CONFIG_CPU_HOTPLUG_STATE_CONTROL is not set
# CONFIG_NOTIFIER_ERROR_INJECTION is not set
CONFIG_FUNCTION_ERROR_INJECTION=y
# CONFIG_FAULT_INJECTION is not set
# CONFIG_LATENCYTOP is not set
CONFIG_USER_STACKTRACE_SUPPORT=y
CONFIG_NOP_TRACER=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_TRACE_CLOCK=y
CONFIG_RING_BUFFER=y
CONFIG_EVENT_TRACING=y
CONFIG_CONTEXT_SWITCH_TRACER=y
CONFIG_RING_BUFFER_ALLOW_SWAP=y
CONFIG_TRACING=y
CONFIG_GENERIC_TRACER=y
CONFIG_TRACING_SUPPORT=y
CONFIG_FTRACE=y
CONFIG_FUNCTION_TRACER=y
# CONFIG_FUNCTION_GRAPH_TRACER is not set
# CONFIG_PREEMPTIRQ_EVENTS is not set
# CONFIG_IRQSOFF_TRACER is not set
# CONFIG_PREEMPT_TRACER is not set
# CONFIG_SCHED_TRACER is not set
# CONFIG_HWLAT_TRACER is not set
# CONFIG_FTRACE_SYSCALLS is not set
# CONFIG_TRACER_SNAPSHOT is not set
CONFIG_BRANCH_PROFILE_NONE=y
# CONFIG_PROFILE_ANNOTATED_BRANCHES is not set
# CONFIG_PROFILE_ALL_BRANCHES is not set
# CONFIG_STACK_TRACER is not set
# CONFIG_BLK_DEV_IO_TRACE is not set
# CONFIG_KPROBE_EVENTS is not set
# CONFIG_UPROBE_EVENTS is not set
# CONFIG_FUNCTION_PROFILER is not set
# CONFIG_FTRACE_STARTUP_TEST is not set
# CONFIG_MMIOTRACE is not set
# CONFIG_HIST_TRIGGERS is not set
# CONFIG_TRACEPOINT_BENCHMARK is not set
# CONFIG_RING_BUFFER_BENCHMARK is not set
# CONFIG_RING_BUFFER_STARTUP_TEST is not set
# CONFIG_PREEMPTIRQ_DELAY_TEST is not set
# CONFIG_TRACE_EVAL_MAP_FILE is not set
# CONFIG_PROVIDE_OHCI1394_DMA_INIT is not set
# CONFIG_RUNTIME_TESTING_MENU 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_UBSAN is not set
CONFIG_UBSAN_ALIGNMENT=y
CONFIG_ARCH_HAS_DEVMEM_IS_ALLOWED=y
# CONFIG_STRICT_DEVMEM is not set
CONFIG_TRACE_IRQFLAGS_SUPPORT=y
# CONFIG_X86_VERBOSE_BOOTUP is not set
CONFIG_EARLY_PRINTK=y
# CONFIG_EARLY_PRINTK_DBGP is not set
# CONFIG_EARLY_PRINTK_USB_XDBC is not set
# CONFIG_X86_PTDUMP is not set
# CONFIG_DEBUG_WX is not set
CONFIG_DOUBLEFAULT=y
# CONFIG_DEBUG_TLBFLUSH is not set
CONFIG_HAVE_MMIOTRACE_SUPPORT=y
# CONFIG_X86_DECODER_SELFTEST is not set
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_DEBUG_BOOT_PARAMS is not set
# CONFIG_CPA_DEBUG is not set
# 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_UNWINDER_ORC=y
# CONFIG_UNWINDER_FRAME_POINTER is not set
# CONFIG_UNWINDER_GUESS is not set
# end of Kernel hacking
[-- Attachment #4: txr19391sleepproc.c --]
[-- Type: text/plain, Size: 976 bytes --]
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <time.h>
#include <pthread.h>
#include <sched.h>
#include <errno.h>
// --- select a core for sched_setaffinity. should be the same as in txr19391test
#define CORENR 1
#define DO(call, msg) { int en = call; if(en) {errno = en; perror(msg); exit(EXIT_FAILURE);} }
int main(void)
{
// affinity must be same as in txr193931watchdog in order to compete for this core
cpu_set_t cpuset;
CPU_ZERO(&cpuset);
CPU_SET(CORENR,&cpuset);
DO(sched_setaffinity(0, sizeof(cpuset), &cpuset), "sched_setaffinity");
// priority such that txr193931test gets interrupted by this here
struct sched_param param;
param.sched_priority = 5;
DO(pthread_setschedparam(pthread_self(), SCHED_FIFO, ¶m), "pthread_setschedparam");
while (1)
{
struct timespec ts;
ts.tv_sec = 0;
ts.tv_nsec = 500*1000*1000;
nanosleep(&ts, NULL);
}
return 0;
}
[-- Attachment #5: txr19391test.c --]
[-- Type: text/plain, Size: 4266 bytes --]
#include <sched.h>
#include <stdlib.h>
#include <unistd.h>
#include <pthread.h>
#include <time.h>
#include <stdio.h>
#include <string.h>
#include <wchar.h>
#include <errno.h>
#define DO(call, msg) { int en = call; if(en) {errno = en; perror(msg); exit(EXIT_FAILURE);} }
// -----------------------------------------------------------------------------
// --- select a core for sched_setaffinity. should be the same as in txr19391watchdog ---
#define CORENR 1
// -----------------------------------------------------------------------------
// --- select a copy implementation --------------------------------------------
#define CPY(dst, src, dummy) strcpy (dst, src);
//#define CPY(dst, src, size) memcpy (dst, src, size);
//#define CPY(dst, src, dummy) { size_t i=0; do{ dst[i]=src[i]; }while(src[i++]); }
//#define CPY(dst, src, dummy) { char* pd=dst; char* ps=src; do{ *pd = *ps; ++pd; }while(*ps++); }
//#define CPY(dst, src, size) for(size_t i=0; i<size; i++){dst[i]=src[i];}
// -----------------------------------------------------------------------------
// -----------------------------------------------------------------------------
#define len (200*1000*1000)
#define bufsize (len+1)
const size_t poolsize=3*(bufsize+1024); // enough space for block distances
char* pMemoryPool=NULL;
size_t alloc_offset = 0;
// -----------------------------------------------------------------------------
// --- select an allocator implementation --------------------------------------
// --- A) an extremely simple pool, doesn't free anything upon free, only meant to be used here ---
void simple_allocator_init()
{
pMemoryPool=(char*)(malloc(poolsize));
if(!pMemoryPool)
{
printf("could not malloc %zu bytes\n.", poolsize);
exit(EXIT_FAILURE);
}
memset(pMemoryPool, 0, poolsize);
}
char* simple_malloc(size_t size)
{
char* p = &pMemoryPool[alloc_offset];
alloc_offset += (size/16+2)*16; // separate blocks a bit, align to 16B
return p;
}
void simple_free(char* p)
{
(void) p;
}
void simple_allocator_fini()
{
free(pMemoryPool);
}
// --- B) fall back to malloc/free ---
// void simple_allocator_init()
// {
// }
//
// char* simple_malloc(size_t size)
// {
// return (char*)malloc(size);
// }
//
// void simple_free(char* p)
// {
// free(p);
// }
//
// void simple_allocator_fini()
// {
// }
// -----------------------------------------------------------------------------
// -----------------------------------------------------------------------------
int test()
{
int rv=0;
char* pS0 = simple_malloc(bufsize);
char* pS1 = simple_malloc(bufsize);
char* pS2 = simple_malloc(bufsize);
// fill up strings 0 and 1
for(size_t i = 0; i<=len; i++)
{
pS0[i]=(i<len)?'a':0;
pS1[i]=(i<len)?'b':0;
}
// swap strings
CPY(pS2,pS1,bufsize);
CPY(pS1,pS0,bufsize);
CPY(pS0,pS2,bufsize);
// swap strings back
CPY(pS2,pS1,bufsize);
CPY(pS1,pS0,bufsize);
CPY(pS0,pS2,bufsize);
// check for errors
for(size_t i = 0; i<=len; i++)
{
if(pS0[i]!=((i<len)?'a':0))
{
printf("error at position %zu of string S0: expected %d, actual: %d\n", i, (int)'a', (int)pS0[i]);
rv = EXIT_FAILURE;
break;
}
if(pS1[i]!=((i<len)?'b':0))
{
printf("error at position %zu of string S1: expected %d, actual: %d\n", i, (int)'b',(int)pS1[i]);
rv = EXIT_FAILURE;
break;
}
}
simple_free(pS0);
simple_free(pS1);
simple_free(pS2);
if(!rv)
{
printf("ok\n");
}
return rv;
}
int main(void)
{
simple_allocator_init();
// affinity must be same as in txr193931watchdog in order to compete for this core
cpu_set_t Mask;
CPU_ZERO(&Mask);
CPU_SET(CORENR, &Mask);
DO(sched_setaffinity(0, sizeof(Mask), &Mask), "sched_setaffinity");
// priority such that txr193931watchdog interrupts this here
struct sched_param SParam;
SParam.sched_priority = 1;
DO(pthread_setschedparam(pthread_self(), SCHED_FIFO, &SParam), "pthread_setschedparam");
int rv = test();
simple_allocator_fini();
return rv;
}
^ permalink raw reply [flat|nested] 24+ messages in thread
* RE: Memory corruptions upon strcpy and similar when being interrupted by scheduler
2022-09-30 11:47 Memory corruptions upon strcpy and similar when being interrupted by scheduler Heber, Stefan
@ 2022-10-14 9:28 ` Zhang, Qiang1
2022-10-24 20:13 ` Jan Kiszka
1 sibling, 0 replies; 24+ messages in thread
From: Zhang, Qiang1 @ 2022-10-14 9:28 UTC (permalink / raw)
To: Heber, Stefan, xenomai, Kiszka, Jan, rpm; +Cc: Wang, Rick Y, Chen, Hongzhan
-----Original Message-----
From: Heber, Stefan <Stefan.Heber@zwickroell.com>
Sent: Friday, September 30, 2022 7:47 PM
To: xenomai@lists.linux.dev
Subject: Memory corruptions upon strcpy and similar when being interrupted by scheduler
Dear list,
we, as long time Xenomai users now have a severe problem. We are currently
in the process of migrating our huge application from xenomai 2.6.4 32bit
to 3.2.2 64bit (linux 5.4.105). In general we are almost done, but one
problem remains: Obviously we have memory corruptions resulting from
strcpy functions (transferring large configurations) being interrupted by
high prio tasks.
We now nailed this problem down in two minimal test applications in order
to rule out any programming errors in our own sources. These two
applications are:
a) a simple test that swaps two very large strings forth and back via
strcpy (and alternatively other copy implementations) and then check the
string contents. This simply happens on the main thread.
b) a "sleepproc" app that simply contains a while/nanosleep loop that
wakes up every 500ms just in order to interrupt app a).
Hi Heber, Stefan
I tested according to the steps a), b) you described, and I also can reproduce this problem.
(xenomai-v3.2.1, linux-5.4.105, ipipe-core-5.4.105-x86-4.patch)
The test method used is as follows:
after launching txr19391sleepproc, run test.sh
copy methods: memcpy
#!/bin/bash
for host in {1..20000}
do
./txr19391test
done
# ./test.sh
ok
ok
ok
ok
error at position 40473600 of string S1: expected 98, actual: -56
but after I made changes to the code
about txr19391test.c:
I only move simple_allocator_init() after pthread_setschedparam()
use test.sh to test it, this problem cannot reproduce.
But I haven't found the root cause yet, You can test it according to my modification to
see if it can be reproduced.
Maybe Jan and Philippe will have some ideas.
Thanks
Zqiang
When running the test app while sleepproc is running we see sporadically
errors (typically less than 20 runs of test until we see that error).
Without the sleepproc app, test runs without errors. And don't worry
about this magic txr19391 prefix, it is just an issue number ;-)
So, could you please help us and have a look into this problem?
Some remarks:
- The test seems to be highly sensitive concerning timing. So we had to
fine-tune a lot to see the error in this minimal test. Also it seems that
even the CPU may influence performance enough to make the error
disappear. Another weird thing is, that if we let the sleepproc sleep
100ms rather than 500ms the error disappears.
- In the test we can either work with individual mallocs for the needed
3 string buffers or with one large malloc and specific "pool allocations"
from that large pool buffer. We can see the error only, if we use the
pool approach (see the two options in the code switchable by commenting/
discommenting).
- We tested 5 different copy methods: strcpy, memcpy, two types of while
loops, one for-loop. We can only see the error with strcpy, memcpy and
for-loop. (also here: see the options in the code). Maybe that depends on
timing, maybe it depends on the implementation ... we don't know.
CPUs we tested on (all with more or less the same kernel config):
- Intel(R) Core(TM) i5-8400H CPU @ 2.50GHz, 4 cores
- Intel(R) Core(TM) i7-7820EQ CPU @ 3.00GHz, 4 cores
- Intel(R) Core(TM) i7-4700EQ CPU @ 2.40GHz, 4 cores
- Intel(R) Atom(TM) CPU D525 @ 1.80GHz, 2 cores ... here we couldn't tune
it such that the error appears
So, thanks in advance and, btw, thanks a lot for your excellent work
during the last >15 years!
Best regards
Stefan
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Memory corruptions upon strcpy and similar when being interrupted by scheduler
2022-09-30 11:47 Memory corruptions upon strcpy and similar when being interrupted by scheduler Heber, Stefan
2022-10-14 9:28 ` Zhang, Qiang1
@ 2022-10-24 20:13 ` Jan Kiszka
2022-10-25 2:39 ` Zhang, Qiang1
1 sibling, 1 reply; 24+ messages in thread
From: Jan Kiszka @ 2022-10-24 20:13 UTC (permalink / raw)
To: Heber, Stefan, xenomai; +Cc: Zhang, Qiang1, Chen, Hongzhan
On 30.09.22 13:47, Heber, Stefan wrote:
> Dear list,
>
> we, as long time Xenomai users now have a severe problem. We are currently
> in the process of migrating our huge application from xenomai 2.6.4 32bit
> to 3.2.2 64bit (linux 5.4.105). In general we are almost done, but one
> problem remains: Obviously we have memory corruptions resulting from
> strcpy functions (transferring large configurations) being interrupted by
> high prio tasks.
>
> We now nailed this problem down in two minimal test applications in order
> to rule out any programming errors in our own sources. These two
> applications are:
> a) a simple test that swaps two very large strings forth and back via
> strcpy (and alternatively other copy implementations) and then check the
> string contents. This simply happens on the main thread.
> b) a "sleepproc" app that simply contains a while/nanosleep loop that
> wakes up every 500ms just in order to interrupt app a).
>
> When running the test app while sleepproc is running we see sporadically
> errors (typically less than 20 runs of test until we see that error).
> Without the sleepproc app, test runs without errors. And don't worry
> about this magic txr19391 prefix, it is just an issue number ;-)
>
> So, could you please help us and have a look into this problem?
>
> Some remarks:
> - The test seems to be highly sensitive concerning timing. So we had to
> fine-tune a lot to see the error in this minimal test. Also it seems that
> even the CPU may influence performance enough to make the error
> disappear. Another weird thing is, that if we let the sleepproc sleep
> 100ms rather than 500ms the error disappears.
> - In the test we can either work with individual mallocs for the needed
> 3 string buffers or with one large malloc and specific "pool allocations"
> from that large pool buffer. We can see the error only, if we use the
> pool approach (see the two options in the code switchable by commenting/
> discommenting).
> - We tested 5 different copy methods: strcpy, memcpy, two types of while
> loops, one for-loop. We can only see the error with strcpy, memcpy and
> for-loop. (also here: see the options in the code). Maybe that depends on
> timing, maybe it depends on the implementation ... we don't know.
>
> CPUs we tested on (all with more or less the same kernel config):
> - Intel(R) Core(TM) i5-8400H CPU @ 2.50GHz, 4 cores
> - Intel(R) Core(TM) i7-7820EQ CPU @ 3.00GHz, 4 cores
> - Intel(R) Core(TM) i7-4700EQ CPU @ 2.40GHz, 4 cores
> - Intel(R) Atom(TM) CPU D525 @ 1.80GHz, 2 cores ... here we couldn't tune
> it such that the error appears
>
> So, thanks in advance and, btw, thanks a lot for your excellent work
> during the last >15 years!
>
> Best regards
> Stefan
Ok, confirmed under xenomai-images, qemu-amd64, 3.2-head, 5.4-head. But
it does not seem to trigger with 4.19-head (all the rest was the same).
So we may "only" have to look into what makes 5.4 special. Didn't debug
anything yet, though.
Jan
--
Siemens AG, Technology
Competence Center Embedded Linux
^ permalink raw reply [flat|nested] 24+ messages in thread
* RE: Memory corruptions upon strcpy and similar when being interrupted by scheduler
2022-10-24 20:13 ` Jan Kiszka
@ 2022-10-25 2:39 ` Zhang, Qiang1
2022-10-25 6:40 ` Jan Kiszka
0 siblings, 1 reply; 24+ messages in thread
From: Zhang, Qiang1 @ 2022-10-25 2:39 UTC (permalink / raw)
To: Kiszka, Jan, Heber, Stefan; +Cc: Chen, Hongzhan, Wang, Rick Y, xenomai
On 30.09.22 13:47, Heber, Stefan wrote:
> Dear list,
>
> we, as long time Xenomai users now have a severe problem. We are currently
> in the process of migrating our huge application from xenomai 2.6.4 32bit
> to 3.2.2 64bit (linux 5.4.105). In general we are almost done, but one
> problem remains: Obviously we have memory corruptions resulting from
> strcpy functions (transferring large configurations) being interrupted by
> high prio tasks.
>
> We now nailed this problem down in two minimal test applications in order
> to rule out any programming errors in our own sources. These two
> applications are:
> a) a simple test that swaps two very large strings forth and back via
> strcpy (and alternatively other copy implementations) and then check the
> string contents. This simply happens on the main thread.
> b) a "sleepproc" app that simply contains a while/nanosleep loop that
> wakes up every 500ms just in order to interrupt app a).
>
> When running the test app while sleepproc is running we see sporadically
> errors (typically less than 20 runs of test until we see that error).
> Without the sleepproc app, test runs without errors. And don't worry
> about this magic txr19391 prefix, it is just an issue number ;-)
>
> So, could you please help us and have a look into this problem?
>
> Some remarks:
> - The test seems to be highly sensitive concerning timing. So we had to
> fine-tune a lot to see the error in this minimal test. Also it seems that
> even the CPU may influence performance enough to make the error
> disappear. Another weird thing is, that if we let the sleepproc sleep
> 100ms rather than 500ms the error disappears.
> - In the test we can either work with individual mallocs for the needed
> 3 string buffers or with one large malloc and specific "pool allocations"
> from that large pool buffer. We can see the error only, if we use the
> pool approach (see the two options in the code switchable by commenting/
> discommenting).
> - We tested 5 different copy methods: strcpy, memcpy, two types of while
> loops, one for-loop. We can only see the error with strcpy, memcpy and
> for-loop. (also here: see the options in the code). Maybe that depends on
> timing, maybe it depends on the implementation ... we don't know.
>
> CPUs we tested on (all with more or less the same kernel config):
> - Intel(R) Core(TM) i5-8400H CPU @ 2.50GHz, 4 cores
> - Intel(R) Core(TM) i7-7820EQ CPU @ 3.00GHz, 4 cores
> - Intel(R) Core(TM) i7-4700EQ CPU @ 2.40GHz, 4 cores
> - Intel(R) Atom(TM) CPU D525 @ 1.80GHz, 2 cores ... here we couldn't tune
> it such that the error appears
>
> So, thanks in advance and, btw, thanks a lot for your excellent work
> during the last >15 years!
>
> Best regards
> Stefan
>
>Ok, confirmed under xenomai-images, qemu-amd64, 3.2-head, 5.4-head. But
>it does not seem to trigger with 4.19-head (all the rest was the same).
>So we may "only" have to look into what makes 5.4 special. Didn't debug
>anything yet, though.
My test environment (xenomai-v3.2.1 linux-kernelv5.4.105 qemu), can reproduce.
but after I made the modification as below, the problem disappeared,
It seems that the large memory copy uses the FPU.
--- a/kernel/cobalt/arch/x86/ipipe/thread.c
+++ b/kernel/cobalt/arch/x86/ipipe/thread.c
@@ -153,7 +153,7 @@ void xnarch_switch_to(struct xnthread *out, struct xnthread *in)
*/
clts();
#endif /* ! IPIPE_X86_FPU_EAGER */
-#if LINUX_VERSION_CODE >= KERNEL_VERSION(5,2,0)
+#if 0
if (!xnthread_test_state(out, XNROOT | XNUSER) &&
!test_thread_flag(TIF_NEED_FPU_LOAD)) {
/*
@@ -209,7 +209,7 @@ void xnarch_switch_to(struct xnthread *out, struct xnthread *in)
#ifndef IPIPE_X86_FPU_EAGER
stts();
#endif /* ! IPIPE_X86_FPU_EAGER */
-#if LINUX_VERSION_CODE >= KERNEL_VERSION(5,2,0)
+#if 0
/*
* Refresh 'in', we switch the stacks. However, there might be no
* current thread at this point.
@@ -445,7 +445,7 @@ void xnarch_switch_fpu(struct xnthread *from, struct xnthread *to)
return;
copy_kernel_to_fpregs(&to_tcb->kfpu->state);
-#if LINUX_VERSION_CODE >= KERNEL_VERSION(5,2,0)
+#if 0
/* redo the invalidation done by kernel_fpu_begin */
__cpu_invalidate_fpregs_state();
#endif
Thanks
Zqiang
>
>Jan
>
>--
>Siemens AG, Technology
>Competence Center Embedded Linux
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Memory corruptions upon strcpy and similar when being interrupted by scheduler
2022-10-25 2:39 ` Zhang, Qiang1
@ 2022-10-25 6:40 ` Jan Kiszka
2022-10-26 12:50 ` Heber, Stefan
2022-10-28 12:12 ` Heber, Stefan
0 siblings, 2 replies; 24+ messages in thread
From: Jan Kiszka @ 2022-10-25 6:40 UTC (permalink / raw)
To: Zhang, Qiang1, Heber, Stefan; +Cc: Chen, Hongzhan, Wang, Rick Y, xenomai
On 25.10.22 04:39, Zhang, Qiang1 wrote:
> On 30.09.22 13:47, Heber, Stefan wrote:
>> Dear list,
>>
>> we, as long time Xenomai users now have a severe problem. We are currently
>> in the process of migrating our huge application from xenomai 2.6.4 32bit
>> to 3.2.2 64bit (linux 5.4.105). In general we are almost done, but one
>> problem remains: Obviously we have memory corruptions resulting from
>> strcpy functions (transferring large configurations) being interrupted by
>> high prio tasks.
>>
>> We now nailed this problem down in two minimal test applications in order
>> to rule out any programming errors in our own sources. These two
>> applications are:
>> a) a simple test that swaps two very large strings forth and back via
>> strcpy (and alternatively other copy implementations) and then check the
>> string contents. This simply happens on the main thread.
>> b) a "sleepproc" app that simply contains a while/nanosleep loop that
>> wakes up every 500ms just in order to interrupt app a).
>>
>> When running the test app while sleepproc is running we see sporadically
>> errors (typically less than 20 runs of test until we see that error).
>> Without the sleepproc app, test runs without errors. And don't worry
>> about this magic txr19391 prefix, it is just an issue number ;-)
>>
>> So, could you please help us and have a look into this problem?
>>
>> Some remarks:
>> - The test seems to be highly sensitive concerning timing. So we had to
>> fine-tune a lot to see the error in this minimal test. Also it seems that
>> even the CPU may influence performance enough to make the error
>> disappear. Another weird thing is, that if we let the sleepproc sleep
>> 100ms rather than 500ms the error disappears.
>> - In the test we can either work with individual mallocs for the needed
>> 3 string buffers or with one large malloc and specific "pool allocations"
>> from that large pool buffer. We can see the error only, if we use the
>> pool approach (see the two options in the code switchable by commenting/
>> discommenting).
>> - We tested 5 different copy methods: strcpy, memcpy, two types of while
>> loops, one for-loop. We can only see the error with strcpy, memcpy and
>> for-loop. (also here: see the options in the code). Maybe that depends on
>> timing, maybe it depends on the implementation ... we don't know.
>>
>> CPUs we tested on (all with more or less the same kernel config):
>> - Intel(R) Core(TM) i5-8400H CPU @ 2.50GHz, 4 cores
>> - Intel(R) Core(TM) i7-7820EQ CPU @ 3.00GHz, 4 cores
>> - Intel(R) Core(TM) i7-4700EQ CPU @ 2.40GHz, 4 cores
>> - Intel(R) Atom(TM) CPU D525 @ 1.80GHz, 2 cores ... here we couldn't tune
>> it such that the error appears
>>
>> So, thanks in advance and, btw, thanks a lot for your excellent work
>> during the last >15 years!
>>
>> Best regards
>> Stefan
>>
>> Ok, confirmed under xenomai-images, qemu-amd64, 3.2-head, 5.4-head. But
>> it does not seem to trigger with 4.19-head (all the rest was the same).
>> So we may "only" have to look into what makes 5.4 special. Didn't debug
>> anything yet, though.
>
>
> My test environment (xenomai-v3.2.1 linux-kernelv5.4.105 qemu), can reproduce.
> but after I made the modification as below, the problem disappeared,
> It seems that the large memory copy uses the FPU.
>
> --- a/kernel/cobalt/arch/x86/ipipe/thread.c
> +++ b/kernel/cobalt/arch/x86/ipipe/thread.c
> @@ -153,7 +153,7 @@ void xnarch_switch_to(struct xnthread *out, struct xnthread *in)
> */
> clts();
> #endif /* ! IPIPE_X86_FPU_EAGER */
> -#if LINUX_VERSION_CODE >= KERNEL_VERSION(5,2,0)
> +#if 0
> if (!xnthread_test_state(out, XNROOT | XNUSER) &&
> !test_thread_flag(TIF_NEED_FPU_LOAD)) {
> /*
> @@ -209,7 +209,7 @@ void xnarch_switch_to(struct xnthread *out, struct xnthread *in)
> #ifndef IPIPE_X86_FPU_EAGER
> stts();
> #endif /* ! IPIPE_X86_FPU_EAGER */
> -#if LINUX_VERSION_CODE >= KERNEL_VERSION(5,2,0)
> +#if 0
> /*
> * Refresh 'in', we switch the stacks. However, there might be no
> * current thread at this point.
> @@ -445,7 +445,7 @@ void xnarch_switch_fpu(struct xnthread *from, struct xnthread *to)
> return;
>
> copy_kernel_to_fpregs(&to_tcb->kfpu->state);
> -#if LINUX_VERSION_CODE >= KERNEL_VERSION(5,2,0)
> +#if 0
> /* redo the invalidation done by kernel_fpu_begin */
> __cpu_invalidate_fpregs_state();
> #endif
>
> Thanks
> Zqiang
>
Interesting. Yes, SSE instructions are preferred for memcpy on today's
CPUs. And that version-dependent code is obviously not taken by 4.19.
Forms a picture, but we still need to understand why our switchtest is
not catching the issue. And we need to understand the issue itself.
Jan
--
Siemens AG, Technology
Competence Center Embedded Linux
^ permalink raw reply [flat|nested] 24+ messages in thread
* RE: Memory corruptions upon strcpy and similar when being interrupted by scheduler
2022-10-25 6:40 ` Jan Kiszka
@ 2022-10-26 12:50 ` Heber, Stefan
2022-11-02 11:30 ` Zhang, Qiang1
2022-10-28 12:12 ` Heber, Stefan
1 sibling, 1 reply; 24+ messages in thread
From: Heber, Stefan @ 2022-10-26 12:50 UTC (permalink / raw)
To: Jan Kiszka, Zhang, Qiang1; +Cc: Chen, Hongzhan, Wang, Rick Y, xenomai
Dear list,
We tested some of the suggested ways to make the problem disappear.
Here our results:
1. The patch of kernel/cobalt/arch/x86/ipipe/thread.c as suggested by Zqiang makes the problem disappear with our tiny testapp on our system, too.
But with a systemtest from our huge application (>250k LoC, >20 threads) the problem still exists.
2. The problem disappears with linux 5.10.127, xenomai 3.2.2 and dovetail with our tiny testapp on our system, too.
And it also disappears with the above mentioned huge systemtest AND with the complete application.
Tests with 4.19.x are still in progress.
Stefan
-----Original Message-----
From: Jan Kiszka <jan.kiszka@siemens.com>
Sent: Tuesday, October 25, 2022 8:40 AM
To: Zhang, Qiang1 <qiang1.zhang@intel.com>; Heber, Stefan <Stefan.Heber@zwickroell.com>
Cc: Chen, Hongzhan <hongzhan.chen@intel.com>; Wang, Rick Y <rick.y.wang@intel.com>; xenomai@lists.linux.dev
Subject: Re: Memory corruptions upon strcpy and similar when being interrupted by scheduler
On 25.10.22 04:39, Zhang, Qiang1 wrote:
> On 30.09.22 13:47, Heber, Stefan wrote:
>> Dear list,
>>
>> we, as long time Xenomai users now have a severe problem. We are currently
>> in the process of migrating our huge application from xenomai 2.6.4 32bit
>> to 3.2.2 64bit (linux 5.4.105). In general we are almost done, but one
>> problem remains: Obviously we have memory corruptions resulting from
>> strcpy functions (transferring large configurations) being interrupted by
>> high prio tasks.
>>
>> We now nailed this problem down in two minimal test applications in order
>> to rule out any programming errors in our own sources. These two
>> applications are:
>> a) a simple test that swaps two very large strings forth and back via
>> strcpy (and alternatively other copy implementations) and then check the
>> string contents. This simply happens on the main thread.
>> b) a "sleepproc" app that simply contains a while/nanosleep loop that
>> wakes up every 500ms just in order to interrupt app a).
>>
>> When running the test app while sleepproc is running we see sporadically
>> errors (typically less than 20 runs of test until we see that error).
>> Without the sleepproc app, test runs without errors. And don't worry
>> about this magic txr19391 prefix, it is just an issue number ;-)
>>
>> So, could you please help us and have a look into this problem?
>>
>> Some remarks:
>> - The test seems to be highly sensitive concerning timing. So we had to
>> fine-tune a lot to see the error in this minimal test. Also it seems that
>> even the CPU may influence performance enough to make the error
>> disappear. Another weird thing is, that if we let the sleepproc sleep
>> 100ms rather than 500ms the error disappears.
>> - In the test we can either work with individual mallocs for the needed
>> 3 string buffers or with one large malloc and specific "pool allocations"
>> from that large pool buffer. We can see the error only, if we use the
>> pool approach (see the two options in the code switchable by commenting/
>> discommenting).
>> - We tested 5 different copy methods: strcpy, memcpy, two types of while
>> loops, one for-loop. We can only see the error with strcpy, memcpy and
>> for-loop. (also here: see the options in the code). Maybe that depends on
>> timing, maybe it depends on the implementation ... we don't know.
>>
>> CPUs we tested on (all with more or less the same kernel config):
>> - Intel(R) Core(TM) i5-8400H CPU @ 2.50GHz, 4 cores
>> - Intel(R) Core(TM) i7-7820EQ CPU @ 3.00GHz, 4 cores
>> - Intel(R) Core(TM) i7-4700EQ CPU @ 2.40GHz, 4 cores
>> - Intel(R) Atom(TM) CPU D525 @ 1.80GHz, 2 cores ... here we couldn't tune
>> it such that the error appears
>>
>> So, thanks in advance and, btw, thanks a lot for your excellent work
>> during the last >15 years!
>>
>> Best regards
>> Stefan
>>
>> Ok, confirmed under xenomai-images, qemu-amd64, 3.2-head, 5.4-head. But
>> it does not seem to trigger with 4.19-head (all the rest was the same).
>> So we may "only" have to look into what makes 5.4 special. Didn't debug
>> anything yet, though.
>
>
> My test environment (xenomai-v3.2.1 linux-kernelv5.4.105 qemu), can reproduce.
> but after I made the modification as below, the problem disappeared,
> It seems that the large memory copy uses the FPU.
>
> --- a/kernel/cobalt/arch/x86/ipipe/thread.c
> +++ b/kernel/cobalt/arch/x86/ipipe/thread.c
> @@ -153,7 +153,7 @@ void xnarch_switch_to(struct xnthread *out, struct xnthread *in)
> */
> clts();
> #endif /* ! IPIPE_X86_FPU_EAGER */
> -#if LINUX_VERSION_CODE >= KERNEL_VERSION(5,2,0)
> +#if 0
> if (!xnthread_test_state(out, XNROOT | XNUSER) &&
> !test_thread_flag(TIF_NEED_FPU_LOAD)) {
> /*
> @@ -209,7 +209,7 @@ void xnarch_switch_to(struct xnthread *out, struct xnthread *in)
> #ifndef IPIPE_X86_FPU_EAGER
> stts();
> #endif /* ! IPIPE_X86_FPU_EAGER */
> -#if LINUX_VERSION_CODE >= KERNEL_VERSION(5,2,0)
> +#if 0
> /*
> * Refresh 'in', we switch the stacks. However, there might be no
> * current thread at this point.
> @@ -445,7 +445,7 @@ void xnarch_switch_fpu(struct xnthread *from, struct xnthread *to)
> return;
>
> copy_kernel_to_fpregs(&to_tcb->kfpu->state);
> -#if LINUX_VERSION_CODE >= KERNEL_VERSION(5,2,0)
> +#if 0
> /* redo the invalidation done by kernel_fpu_begin */
> __cpu_invalidate_fpregs_state();
> #endif
>
> Thanks
> Zqiang
>
Interesting. Yes, SSE instructions are preferred for memcpy on today's
CPUs. And that version-dependent code is obviously not taken by 4.19.
Forms a picture, but we still need to understand why our switchtest is
not catching the issue. And we need to understand the issue itself.
Jan
--
Siemens AG, Technology
Competence Center Embedded Linux
^ permalink raw reply [flat|nested] 24+ messages in thread
* RE: Memory corruptions upon strcpy and similar when being interrupted by scheduler
2022-10-25 6:40 ` Jan Kiszka
2022-10-26 12:50 ` Heber, Stefan
@ 2022-10-28 12:12 ` Heber, Stefan
1 sibling, 0 replies; 24+ messages in thread
From: Heber, Stefan @ 2022-10-28 12:12 UTC (permalink / raw)
To: Jan Kiszka, Zhang, Qiang1; +Cc: Chen, Hongzhan, Wang, Rick Y, xenomai
Dear list,
Here the results of our tests with linux kernel 4.19.x:
The problem disappears with linux 4.19.252, xenomai 3.2.2 with our tiny testapp on our system, too.
And it also disappears with the systemtest from our huge application (>250k LoC, >20 threads).
Stefan
-----Original Message-----
From: Jan Kiszka <jan.kiszka@siemens.com>
Sent: Tuesday, October 25, 2022 8:40 AM
To: Zhang, Qiang1 <qiang1.zhang@intel.com>; Heber, Stefan <Stefan.Heber@zwickroell.com>
Cc: Chen, Hongzhan <hongzhan.chen@intel.com>; Wang, Rick Y <rick.y.wang@intel.com>; xenomai@lists.linux.dev
Subject: Re: Memory corruptions upon strcpy and similar when being interrupted by scheduler
On 25.10.22 04:39, Zhang, Qiang1 wrote:
> On 30.09.22 13:47, Heber, Stefan wrote:
>> Dear list,
>>
>> we, as long time Xenomai users now have a severe problem. We are currently
>> in the process of migrating our huge application from xenomai 2.6.4 32bit
>> to 3.2.2 64bit (linux 5.4.105). In general we are almost done, but one
>> problem remains: Obviously we have memory corruptions resulting from
>> strcpy functions (transferring large configurations) being interrupted by
>> high prio tasks.
>>
>> We now nailed this problem down in two minimal test applications in order
>> to rule out any programming errors in our own sources. These two
>> applications are:
>> a) a simple test that swaps two very large strings forth and back via
>> strcpy (and alternatively other copy implementations) and then check the
>> string contents. This simply happens on the main thread.
>> b) a "sleepproc" app that simply contains a while/nanosleep loop that
>> wakes up every 500ms just in order to interrupt app a).
>>
>> When running the test app while sleepproc is running we see sporadically
>> errors (typically less than 20 runs of test until we see that error).
>> Without the sleepproc app, test runs without errors. And don't worry
>> about this magic txr19391 prefix, it is just an issue number ;-)
>>
>> So, could you please help us and have a look into this problem?
>>
>> Some remarks:
>> - The test seems to be highly sensitive concerning timing. So we had to
>> fine-tune a lot to see the error in this minimal test. Also it seems that
>> even the CPU may influence performance enough to make the error
>> disappear. Another weird thing is, that if we let the sleepproc sleep
>> 100ms rather than 500ms the error disappears.
>> - In the test we can either work with individual mallocs for the needed
>> 3 string buffers or with one large malloc and specific "pool allocations"
>> from that large pool buffer. We can see the error only, if we use the
>> pool approach (see the two options in the code switchable by commenting/
>> discommenting).
>> - We tested 5 different copy methods: strcpy, memcpy, two types of while
>> loops, one for-loop. We can only see the error with strcpy, memcpy and
>> for-loop. (also here: see the options in the code). Maybe that depends on
>> timing, maybe it depends on the implementation ... we don't know.
>>
>> CPUs we tested on (all with more or less the same kernel config):
>> - Intel(R) Core(TM) i5-8400H CPU @ 2.50GHz, 4 cores
>> - Intel(R) Core(TM) i7-7820EQ CPU @ 3.00GHz, 4 cores
>> - Intel(R) Core(TM) i7-4700EQ CPU @ 2.40GHz, 4 cores
>> - Intel(R) Atom(TM) CPU D525 @ 1.80GHz, 2 cores ... here we couldn't tune
>> it such that the error appears
>>
>> So, thanks in advance and, btw, thanks a lot for your excellent work
>> during the last >15 years!
>>
>> Best regards
>> Stefan
>>
>> Ok, confirmed under xenomai-images, qemu-amd64, 3.2-head, 5.4-head. But
>> it does not seem to trigger with 4.19-head (all the rest was the same).
>> So we may "only" have to look into what makes 5.4 special. Didn't debug
>> anything yet, though.
>
>
> My test environment (xenomai-v3.2.1 linux-kernelv5.4.105 qemu), can reproduce.
> but after I made the modification as below, the problem disappeared,
> It seems that the large memory copy uses the FPU.
>
> --- a/kernel/cobalt/arch/x86/ipipe/thread.c
> +++ b/kernel/cobalt/arch/x86/ipipe/thread.c
> @@ -153,7 +153,7 @@ void xnarch_switch_to(struct xnthread *out, struct xnthread *in)
> */
> clts();
> #endif /* ! IPIPE_X86_FPU_EAGER */
> -#if LINUX_VERSION_CODE >= KERNEL_VERSION(5,2,0)
> +#if 0
> if (!xnthread_test_state(out, XNROOT | XNUSER) &&
> !test_thread_flag(TIF_NEED_FPU_LOAD)) {
> /*
> @@ -209,7 +209,7 @@ void xnarch_switch_to(struct xnthread *out, struct xnthread *in)
> #ifndef IPIPE_X86_FPU_EAGER
> stts();
> #endif /* ! IPIPE_X86_FPU_EAGER */
> -#if LINUX_VERSION_CODE >= KERNEL_VERSION(5,2,0)
> +#if 0
> /*
> * Refresh 'in', we switch the stacks. However, there might be no
> * current thread at this point.
> @@ -445,7 +445,7 @@ void xnarch_switch_fpu(struct xnthread *from, struct xnthread *to)
> return;
>
> copy_kernel_to_fpregs(&to_tcb->kfpu->state);
> -#if LINUX_VERSION_CODE >= KERNEL_VERSION(5,2,0)
> +#if 0
> /* redo the invalidation done by kernel_fpu_begin */
> __cpu_invalidate_fpregs_state();
> #endif
>
> Thanks
> Zqiang
>
Interesting. Yes, SSE instructions are preferred for memcpy on today's
CPUs. And that version-dependent code is obviously not taken by 4.19.
Forms a picture, but we still need to understand why our switchtest is
not catching the issue. And we need to understand the issue itself.
Jan
--
Siemens AG, Technology
Competence Center Embedded Linux
^ permalink raw reply [flat|nested] 24+ messages in thread
* RE: Memory corruptions upon strcpy and similar when being interrupted by scheduler
2022-10-26 12:50 ` Heber, Stefan
@ 2022-11-02 11:30 ` Zhang, Qiang1
2022-11-02 15:34 ` Heber, Stefan
0 siblings, 1 reply; 24+ messages in thread
From: Zhang, Qiang1 @ 2022-11-02 11:30 UTC (permalink / raw)
To: Heber, Stefan, Kiszka, Jan; +Cc: Chen, Hongzhan, Wang, Rick Y, xenomai
[-- Attachment #1: Type: text/plain, Size: 6356 bytes --]
>Dear list,
>
>We tested some of the suggested ways to make the problem disappear.
>Here our results:
>
>1. The patch of kernel/cobalt/arch/x86/ipipe/thread.c as suggested by Zqiang makes the problem disappear with our tiny testapp on our system, too.
>But with a systemtest from our huge application (>250k LoC, >20 threads) the problem still exists.
Hello Stefan
I guess this problem is related to FPU, so I ignore FPU operation on Xenoami, the FPU operation
is fully controlled by linux kernel. The patch base on Xenoami v3.2.
As usual, I apply this patch and use kernel-5.4 run your testapp, this problem disappear.
do you have time to test it out with your huge application?
Thanks
Zqiang
>
>2. The problem disappears with linux 5.10.127, xenomai 3.2.2 and dovetail with our tiny testapp on our system, too.
>And it also disappears with the above mentioned huge systemtest AND with the complete application.
>
>Tests with 4.19.x are still in progress.
>
>Stefan
-----Original Message-----
From: Jan Kiszka <jan.kiszka@siemens.com>
Sent: Tuesday, October 25, 2022 8:40 AM
To: Zhang, Qiang1 <qiang1.zhang@intel.com>; Heber, Stefan <Stefan.Heber@zwickroell.com>
Cc: Chen, Hongzhan <hongzhan.chen@intel.com>; Wang, Rick Y <rick.y.wang@intel.com>; xenomai@lists.linux.dev
Subject: Re: Memory corruptions upon strcpy and similar when being interrupted by scheduler
On 25.10.22 04:39, Zhang, Qiang1 wrote:
> On 30.09.22 13:47, Heber, Stefan wrote:
>> Dear list,
>>
>> we, as long time Xenomai users now have a severe problem. We are currently
>> in the process of migrating our huge application from xenomai 2.6.4 32bit
>> to 3.2.2 64bit (linux 5.4.105). In general we are almost done, but one
>> problem remains: Obviously we have memory corruptions resulting from
>> strcpy functions (transferring large configurations) being interrupted by
>> high prio tasks.
>>
>> We now nailed this problem down in two minimal test applications in order
>> to rule out any programming errors in our own sources. These two
>> applications are:
>> a) a simple test that swaps two very large strings forth and back via
>> strcpy (and alternatively other copy implementations) and then check the
>> string contents. This simply happens on the main thread.
>> b) a "sleepproc" app that simply contains a while/nanosleep loop that
>> wakes up every 500ms just in order to interrupt app a).
>>
>> When running the test app while sleepproc is running we see sporadically
>> errors (typically less than 20 runs of test until we see that error).
>> Without the sleepproc app, test runs without errors. And don't worry
>> about this magic txr19391 prefix, it is just an issue number ;-)
>>
>> So, could you please help us and have a look into this problem?
>>
>> Some remarks:
>> - The test seems to be highly sensitive concerning timing. So we had to
>> fine-tune a lot to see the error in this minimal test. Also it seems that
>> even the CPU may influence performance enough to make the error
>> disappear. Another weird thing is, that if we let the sleepproc sleep
>> 100ms rather than 500ms the error disappears.
>> - In the test we can either work with individual mallocs for the needed
>> 3 string buffers or with one large malloc and specific "pool allocations"
>> from that large pool buffer. We can see the error only, if we use the
>> pool approach (see the two options in the code switchable by commenting/
>> discommenting).
>> - We tested 5 different copy methods: strcpy, memcpy, two types of while
>> loops, one for-loop. We can only see the error with strcpy, memcpy and
>> for-loop. (also here: see the options in the code). Maybe that depends on
>> timing, maybe it depends on the implementation ... we don't know.
>>
>> CPUs we tested on (all with more or less the same kernel config):
>> - Intel(R) Core(TM) i5-8400H CPU @ 2.50GHz, 4 cores
>> - Intel(R) Core(TM) i7-7820EQ CPU @ 3.00GHz, 4 cores
>> - Intel(R) Core(TM) i7-4700EQ CPU @ 2.40GHz, 4 cores
>> - Intel(R) Atom(TM) CPU D525 @ 1.80GHz, 2 cores ... here we couldn't tune
>> it such that the error appears
>>
>> So, thanks in advance and, btw, thanks a lot for your excellent work
>> during the last >15 years!
>>
>> Best regards
>> Stefan
>>
>> Ok, confirmed under xenomai-images, qemu-amd64, 3.2-head, 5.4-head. But
>> it does not seem to trigger with 4.19-head (all the rest was the same).
>> So we may "only" have to look into what makes 5.4 special. Didn't debug
>> anything yet, though.
>
>
> My test environment (xenomai-v3.2.1 linux-kernelv5.4.105 qemu), can reproduce.
> but after I made the modification as below, the problem disappeared,
> It seems that the large memory copy uses the FPU.
>
> --- a/kernel/cobalt/arch/x86/ipipe/thread.c
> +++ b/kernel/cobalt/arch/x86/ipipe/thread.c
> @@ -153,7 +153,7 @@ void xnarch_switch_to(struct xnthread *out, struct xnthread *in)
> */
> clts();
> #endif /* ! IPIPE_X86_FPU_EAGER */
> -#if LINUX_VERSION_CODE >= KERNEL_VERSION(5,2,0)
> +#if 0
> if (!xnthread_test_state(out, XNROOT | XNUSER) &&
> !test_thread_flag(TIF_NEED_FPU_LOAD)) {
> /*
> @@ -209,7 +209,7 @@ void xnarch_switch_to(struct xnthread *out, struct xnthread *in)
> #ifndef IPIPE_X86_FPU_EAGER
> stts();
> #endif /* ! IPIPE_X86_FPU_EAGER */
> -#if LINUX_VERSION_CODE >= KERNEL_VERSION(5,2,0)
> +#if 0
> /*
> * Refresh 'in', we switch the stacks. However, there might be no
> * current thread at this point.
> @@ -445,7 +445,7 @@ void xnarch_switch_fpu(struct xnthread *from, struct xnthread *to)
> return;
>
> copy_kernel_to_fpregs(&to_tcb->kfpu->state);
> -#if LINUX_VERSION_CODE >= KERNEL_VERSION(5,2,0)
> +#if 0
> /* redo the invalidation done by kernel_fpu_begin */
> __cpu_invalidate_fpregs_state();
> #endif
>
> Thanks
> Zqiang
>
Interesting. Yes, SSE instructions are preferred for memcpy on today's
CPUs. And that version-dependent code is obviously not taken by 4.19.
Forms a picture, but we still need to understand why our switchtest is
not catching the issue. And we need to understand the issue itself.
Jan
--
Siemens AG, Technology
Competence Center Embedded Linux
[-- Attachment #2: 0001-IPIPE-ignore-xenomai-FPU-operation.patch --]
[-- Type: application/octet-stream, Size: 3076 bytes --]
From dd637a60bc15dc59d05442a083e5f3c256f20c9e Mon Sep 17 00:00:00 2001
From: Zqiang <qiang1.zhang@intel.com>
Date: Wed, 2 Nov 2022 19:25:54 +0800
Subject: [PATCH] IPIPE: ignore xenomai FPU operation
Signed-off-by: Zqiang <qiang1.zhang@intel.com>
---
kernel/cobalt/arch/x86/ipipe/thread.c | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/kernel/cobalt/arch/x86/ipipe/thread.c b/kernel/cobalt/arch/x86/ipipe/thread.c
index 7e28903a4..9f8e22fa9 100644
--- a/kernel/cobalt/arch/x86/ipipe/thread.c
+++ b/kernel/cobalt/arch/x86/ipipe/thread.c
@@ -154,6 +154,7 @@ void xnarch_switch_to(struct xnthread *out, struct xnthread *in)
clts();
#endif /* ! IPIPE_X86_FPU_EAGER */
#if LINUX_VERSION_CODE >= KERNEL_VERSION(5,2,0)
+#if 0
if (!xnthread_test_state(out, XNROOT | XNUSER) &&
!test_thread_flag(TIF_NEED_FPU_LOAD)) {
/*
@@ -167,6 +168,7 @@ void xnarch_switch_to(struct xnthread *out, struct xnthread *in)
else
prev_fpu->last_cpu = raw_smp_processor_id();
}
+#endif
#endif
next = in_tcb->core.host_task;
@@ -210,6 +212,7 @@ void xnarch_switch_to(struct xnthread *out, struct xnthread *in)
stts();
#endif /* ! IPIPE_X86_FPU_EAGER */
#if LINUX_VERSION_CODE >= KERNEL_VERSION(5,2,0)
+#if 0
/*
* Refresh 'in', we switch the stacks. However, there might be no
* current thread at this point.
@@ -232,6 +235,7 @@ void xnarch_switch_to(struct xnthread *out, struct xnthread *in)
clear_thread_flag(TIF_NEED_FPU_LOAD);
}
#endif
+#endif
}
#ifndef IPIPE_X86_FPU_EAGER
@@ -412,6 +416,7 @@ void xnarch_switch_fpu(struct xnthread *from, struct xnthread *to)
#else /* IPIPE_X86_FPU_EAGER */
void xnarch_leave_root(struct xnthread *root)
{
+#if 0
struct xnarchtcb *const rootcb = xnthread_archtcb(root);
rootcb->root_kfpu = current_task_used_kfpu();
@@ -437,10 +442,12 @@ void xnarch_leave_root(struct xnthread *root)
if (fpregs_active())
fpregs_deactivate(¤t->thread.fpu);
#endif
+#endif
}
void xnarch_switch_fpu(struct xnthread *from, struct xnthread *to)
{
+#if 0
struct xnarchtcb *const to_tcb = xnthread_archtcb(to);
if (!tcb_used_kfpu(to_tcb))
@@ -452,11 +459,13 @@ void xnarch_switch_fpu(struct xnthread *from, struct xnthread *to)
__cpu_invalidate_fpregs_state();
#endif
kernel_fpu_disable();
+#endif
}
#endif /* ! IPIPE_X86_FPU_EAGER */
void xnarch_init_root_tcb(struct xnthread *thread)
{
+#if 0
struct xnarchtcb *tcb = xnthread_archtcb(thread);
#if LINUX_VERSION_CODE < KERNEL_VERSION(4,8,0)
@@ -471,10 +480,12 @@ void xnarch_init_root_tcb(struct xnthread *thread)
tcb->kfpu = kmem_cache_zalloc(xstate_cache, GFP_KERNEL);
#endif /* ! IPIPE_X86_FPU_EAGER */
tcb->root_kfpu = 0;
+#endif
}
void xnarch_init_shadow_tcb(struct xnthread *thread)
{
+#if 0
struct xnarchtcb *tcb = xnthread_archtcb(thread);
struct task_struct *p = tcb->core.host_task;
@@ -503,6 +514,7 @@ void xnarch_init_shadow_tcb(struct xnthread *thread)
fpu__initialize(&p->thread.fpu);
#endif
#endif /* ! IPIPE_X86_FPU_EAGER */
+#endif
}
int mach_x86_thread_init(void)
--
2.25.1
^ permalink raw reply related [flat|nested] 24+ messages in thread
* RE: Memory corruptions upon strcpy and similar when being interrupted by scheduler
2022-11-02 11:30 ` Zhang, Qiang1
@ 2022-11-02 15:34 ` Heber, Stefan
2022-11-02 15:48 ` Jan Kiszka
2022-11-03 1:42 ` Zhang, Qiang1
0 siblings, 2 replies; 24+ messages in thread
From: Heber, Stefan @ 2022-11-02 15:34 UTC (permalink / raw)
To: Zhang, Qiang1, Kiszka, Jan; +Cc: Chen, Hongzhan, Wang, Rick Y, xenomai
Hello Zqiang,
We tested your 0001-IPIPE-ignore-xenomai-FPU-operation.patch on our system (Linux-kernel 5.4, Xenomai v3.2).
This patch makes the problem disappear with our tiny testapp on our system, too.
But with a systemtest from our huge application (>250k LoC, >20 threads) the problem still exists.
Stefan
-----Original Message-----
From: Zhang, Qiang1 <qiang1.zhang@intel.com>
Sent: Wednesday, November 2, 2022 12:30 PM
To: Heber, Stefan <Stefan.Heber@zwickroell.com>; Kiszka, Jan <jan.kiszka@siemens.com>
Cc: Chen, Hongzhan <hongzhan.chen@intel.com>; Wang, Rick Y <rick.y.wang@intel.com>; xenomai@lists.linux.dev
Subject: RE: Memory corruptions upon strcpy and similar when being interrupted by scheduler
>Dear list,
>
>We tested some of the suggested ways to make the problem disappear.
>Here our results:
>
>1. The patch of kernel/cobalt/arch/x86/ipipe/thread.c as suggested by Zqiang makes the problem disappear with our tiny testapp on our system, too.
>But with a systemtest from our huge application (>250k LoC, >20 threads) the problem still exists.
Hello Stefan
I guess this problem is related to FPU, so I ignore FPU operation on Xenoami, the FPU operation
is fully controlled by linux kernel. The patch base on Xenoami v3.2.
As usual, I apply this patch and use kernel-5.4 run your testapp, this problem disappear.
do you have time to test it out with your huge application?
Thanks
Zqiang
>
>2. The problem disappears with linux 5.10.127, xenomai 3.2.2 and dovetail with our tiny testapp on our system, too.
>And it also disappears with the above mentioned huge systemtest AND with the complete application.
>
>Tests with 4.19.x are still in progress.
>
>Stefan
-----Original Message-----
From: Jan Kiszka <jan.kiszka@siemens.com>
Sent: Tuesday, October 25, 2022 8:40 AM
To: Zhang, Qiang1 <qiang1.zhang@intel.com>; Heber, Stefan <Stefan.Heber@zwickroell.com>
Cc: Chen, Hongzhan <hongzhan.chen@intel.com>; Wang, Rick Y <rick.y.wang@intel.com>; xenomai@lists.linux.dev
Subject: Re: Memory corruptions upon strcpy and similar when being interrupted by scheduler
On 25.10.22 04:39, Zhang, Qiang1 wrote:
> On 30.09.22 13:47, Heber, Stefan wrote:
>> Dear list,
>>
>> we, as long time Xenomai users now have a severe problem. We are currently
>> in the process of migrating our huge application from xenomai 2.6.4 32bit
>> to 3.2.2 64bit (linux 5.4.105). In general we are almost done, but one
>> problem remains: Obviously we have memory corruptions resulting from
>> strcpy functions (transferring large configurations) being interrupted by
>> high prio tasks.
>>
>> We now nailed this problem down in two minimal test applications in order
>> to rule out any programming errors in our own sources. These two
>> applications are:
>> a) a simple test that swaps two very large strings forth and back via
>> strcpy (and alternatively other copy implementations) and then check the
>> string contents. This simply happens on the main thread.
>> b) a "sleepproc" app that simply contains a while/nanosleep loop that
>> wakes up every 500ms just in order to interrupt app a).
>>
>> When running the test app while sleepproc is running we see sporadically
>> errors (typically less than 20 runs of test until we see that error).
>> Without the sleepproc app, test runs without errors. And don't worry
>> about this magic txr19391 prefix, it is just an issue number ;-)
>>
>> So, could you please help us and have a look into this problem?
>>
>> Some remarks:
>> - The test seems to be highly sensitive concerning timing. So we had to
>> fine-tune a lot to see the error in this minimal test. Also it seems that
>> even the CPU may influence performance enough to make the error
>> disappear. Another weird thing is, that if we let the sleepproc sleep
>> 100ms rather than 500ms the error disappears.
>> - In the test we can either work with individual mallocs for the needed
>> 3 string buffers or with one large malloc and specific "pool allocations"
>> from that large pool buffer. We can see the error only, if we use the
>> pool approach (see the two options in the code switchable by commenting/
>> discommenting).
>> - We tested 5 different copy methods: strcpy, memcpy, two types of while
>> loops, one for-loop. We can only see the error with strcpy, memcpy and
>> for-loop. (also here: see the options in the code). Maybe that depends on
>> timing, maybe it depends on the implementation ... we don't know.
>>
>> CPUs we tested on (all with more or less the same kernel config):
>> - Intel(R) Core(TM) i5-8400H CPU @ 2.50GHz, 4 cores
>> - Intel(R) Core(TM) i7-7820EQ CPU @ 3.00GHz, 4 cores
>> - Intel(R) Core(TM) i7-4700EQ CPU @ 2.40GHz, 4 cores
>> - Intel(R) Atom(TM) CPU D525 @ 1.80GHz, 2 cores ... here we couldn't tune
>> it such that the error appears
>>
>> So, thanks in advance and, btw, thanks a lot for your excellent work
>> during the last >15 years!
>>
>> Best regards
>> Stefan
>>
>> Ok, confirmed under xenomai-images, qemu-amd64, 3.2-head, 5.4-head. But
>> it does not seem to trigger with 4.19-head (all the rest was the same).
>> So we may "only" have to look into what makes 5.4 special. Didn't debug
>> anything yet, though.
>
>
> My test environment (xenomai-v3.2.1 linux-kernelv5.4.105 qemu), can reproduce.
> but after I made the modification as below, the problem disappeared,
> It seems that the large memory copy uses the FPU.
>
> --- a/kernel/cobalt/arch/x86/ipipe/thread.c
> +++ b/kernel/cobalt/arch/x86/ipipe/thread.c
> @@ -153,7 +153,7 @@ void xnarch_switch_to(struct xnthread *out, struct xnthread *in)
> */
> clts();
> #endif /* ! IPIPE_X86_FPU_EAGER */
> -#if LINUX_VERSION_CODE >= KERNEL_VERSION(5,2,0)
> +#if 0
> if (!xnthread_test_state(out, XNROOT | XNUSER) &&
> !test_thread_flag(TIF_NEED_FPU_LOAD)) {
> /*
> @@ -209,7 +209,7 @@ void xnarch_switch_to(struct xnthread *out, struct xnthread *in)
> #ifndef IPIPE_X86_FPU_EAGER
> stts();
> #endif /* ! IPIPE_X86_FPU_EAGER */
> -#if LINUX_VERSION_CODE >= KERNEL_VERSION(5,2,0)
> +#if 0
> /*
> * Refresh 'in', we switch the stacks. However, there might be no
> * current thread at this point.
> @@ -445,7 +445,7 @@ void xnarch_switch_fpu(struct xnthread *from, struct xnthread *to)
> return;
>
> copy_kernel_to_fpregs(&to_tcb->kfpu->state);
> -#if LINUX_VERSION_CODE >= KERNEL_VERSION(5,2,0)
> +#if 0
> /* redo the invalidation done by kernel_fpu_begin */
> __cpu_invalidate_fpregs_state();
> #endif
>
> Thanks
> Zqiang
>
Interesting. Yes, SSE instructions are preferred for memcpy on today's
CPUs. And that version-dependent code is obviously not taken by 4.19.
Forms a picture, but we still need to understand why our switchtest is
not catching the issue. And we need to understand the issue itself.
Jan
--
Siemens AG, Technology
Competence Center Embedded Linux
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Memory corruptions upon strcpy and similar when being interrupted by scheduler
2022-11-02 15:34 ` Heber, Stefan
@ 2022-11-02 15:48 ` Jan Kiszka
2022-11-07 8:42 ` Jan Kiszka
2022-11-03 1:42 ` Zhang, Qiang1
1 sibling, 1 reply; 24+ messages in thread
From: Jan Kiszka @ 2022-11-02 15:48 UTC (permalink / raw)
To: Heber, Stefan, Zhang, Qiang1; +Cc: Chen, Hongzhan, Wang, Rick Y, xenomai
On 02.11.22 16:34, Heber, Stefan wrote:
> Hello Zqiang,
>
> We tested your 0001-IPIPE-ignore-xenomai-FPU-operation.patch on our system (Linux-kernel 5.4, Xenomai v3.2).
>
> This patch makes the problem disappear with our tiny testapp on our system, too.
> But with a systemtest from our huge application (>250k LoC, >20 threads) the problem still exists.
The patch is surely no solution, but it points to the direction where we
need to dig. Unfortunately, I still didn't find enough contiguous time
to start that.
Jan
>
> Stefan
>
> -----Original Message-----
> From: Zhang, Qiang1 <qiang1.zhang@intel.com>
> Sent: Wednesday, November 2, 2022 12:30 PM
> To: Heber, Stefan <Stefan.Heber@zwickroell.com>; Kiszka, Jan <jan.kiszka@siemens.com>
> Cc: Chen, Hongzhan <hongzhan.chen@intel.com>; Wang, Rick Y <rick.y.wang@intel.com>; xenomai@lists.linux.dev
> Subject: RE: Memory corruptions upon strcpy and similar when being interrupted by scheduler
>
>> Dear list,
>>
>> We tested some of the suggested ways to make the problem disappear.
>> Here our results:
>>
>> 1. The patch of kernel/cobalt/arch/x86/ipipe/thread.c as suggested by Zqiang makes the problem disappear with our tiny testapp on our system, too.
>> But with a systemtest from our huge application (>250k LoC, >20 threads) the problem still exists.
>
> Hello Stefan
>
> I guess this problem is related to FPU, so I ignore FPU operation on Xenoami, the FPU operation
> is fully controlled by linux kernel. The patch base on Xenoami v3.2.
> As usual, I apply this patch and use kernel-5.4 run your testapp, this problem disappear.
> do you have time to test it out with your huge application?
>
> Thanks
> Zqiang
>
>>
>> 2. The problem disappears with linux 5.10.127, xenomai 3.2.2 and dovetail with our tiny testapp on our system, too.
>> And it also disappears with the above mentioned huge systemtest AND with the complete application.
>>
>> Tests with 4.19.x are still in progress.
>>
>> Stefan
>
> -----Original Message-----
> From: Jan Kiszka <jan.kiszka@siemens.com>
> Sent: Tuesday, October 25, 2022 8:40 AM
> To: Zhang, Qiang1 <qiang1.zhang@intel.com>; Heber, Stefan <Stefan.Heber@zwickroell.com>
> Cc: Chen, Hongzhan <hongzhan.chen@intel.com>; Wang, Rick Y <rick.y.wang@intel.com>; xenomai@lists.linux.dev
> Subject: Re: Memory corruptions upon strcpy and similar when being interrupted by scheduler
>
> On 25.10.22 04:39, Zhang, Qiang1 wrote:
>> On 30.09.22 13:47, Heber, Stefan wrote:
>>> Dear list,
>>>
>>> we, as long time Xenomai users now have a severe problem. We are currently
>>> in the process of migrating our huge application from xenomai 2.6.4 32bit
>>> to 3.2.2 64bit (linux 5.4.105). In general we are almost done, but one
>>> problem remains: Obviously we have memory corruptions resulting from
>>> strcpy functions (transferring large configurations) being interrupted by
>>> high prio tasks.
>>>
>>> We now nailed this problem down in two minimal test applications in order
>>> to rule out any programming errors in our own sources. These two
>>> applications are:
>>> a) a simple test that swaps two very large strings forth and back via
>>> strcpy (and alternatively other copy implementations) and then check the
>>> string contents. This simply happens on the main thread.
>>> b) a "sleepproc" app that simply contains a while/nanosleep loop that
>>> wakes up every 500ms just in order to interrupt app a).
>>>
>>> When running the test app while sleepproc is running we see sporadically
>>> errors (typically less than 20 runs of test until we see that error).
>>> Without the sleepproc app, test runs without errors. And don't worry
>>> about this magic txr19391 prefix, it is just an issue number ;-)
>>>
>>> So, could you please help us and have a look into this problem?
>>>
>>> Some remarks:
>>> - The test seems to be highly sensitive concerning timing. So we had to
>>> fine-tune a lot to see the error in this minimal test. Also it seems that
>>> even the CPU may influence performance enough to make the error
>>> disappear. Another weird thing is, that if we let the sleepproc sleep
>>> 100ms rather than 500ms the error disappears.
>>> - In the test we can either work with individual mallocs for the needed
>>> 3 string buffers or with one large malloc and specific "pool allocations"
>>> from that large pool buffer. We can see the error only, if we use the
>>> pool approach (see the two options in the code switchable by commenting/
>>> discommenting).
>>> - We tested 5 different copy methods: strcpy, memcpy, two types of while
>>> loops, one for-loop. We can only see the error with strcpy, memcpy and
>>> for-loop. (also here: see the options in the code). Maybe that depends on
>>> timing, maybe it depends on the implementation ... we don't know.
>>>
>>> CPUs we tested on (all with more or less the same kernel config):
>>> - Intel(R) Core(TM) i5-8400H CPU @ 2.50GHz, 4 cores
>>> - Intel(R) Core(TM) i7-7820EQ CPU @ 3.00GHz, 4 cores
>>> - Intel(R) Core(TM) i7-4700EQ CPU @ 2.40GHz, 4 cores
>>> - Intel(R) Atom(TM) CPU D525 @ 1.80GHz, 2 cores ... here we couldn't tune
>>> it such that the error appears
>>>
>>> So, thanks in advance and, btw, thanks a lot for your excellent work
>>> during the last >15 years!
>>>
>>> Best regards
>>> Stefan
>>>
>>> Ok, confirmed under xenomai-images, qemu-amd64, 3.2-head, 5.4-head. But
>>> it does not seem to trigger with 4.19-head (all the rest was the same).
>>> So we may "only" have to look into what makes 5.4 special. Didn't debug
>>> anything yet, though.
>>
>>
>> My test environment (xenomai-v3.2.1 linux-kernelv5.4.105 qemu), can reproduce.
>> but after I made the modification as below, the problem disappeared,
>> It seems that the large memory copy uses the FPU.
>>
>> --- a/kernel/cobalt/arch/x86/ipipe/thread.c
>> +++ b/kernel/cobalt/arch/x86/ipipe/thread.c
>> @@ -153,7 +153,7 @@ void xnarch_switch_to(struct xnthread *out, struct xnthread *in)
>> */
>> clts();
>> #endif /* ! IPIPE_X86_FPU_EAGER */
>> -#if LINUX_VERSION_CODE >= KERNEL_VERSION(5,2,0)
>> +#if 0
>> if (!xnthread_test_state(out, XNROOT | XNUSER) &&
>> !test_thread_flag(TIF_NEED_FPU_LOAD)) {
>> /*
>> @@ -209,7 +209,7 @@ void xnarch_switch_to(struct xnthread *out, struct xnthread *in)
>> #ifndef IPIPE_X86_FPU_EAGER
>> stts();
>> #endif /* ! IPIPE_X86_FPU_EAGER */
>> -#if LINUX_VERSION_CODE >= KERNEL_VERSION(5,2,0)
>> +#if 0
>> /*
>> * Refresh 'in', we switch the stacks. However, there might be no
>> * current thread at this point.
>> @@ -445,7 +445,7 @@ void xnarch_switch_fpu(struct xnthread *from, struct xnthread *to)
>> return;
>>
>> copy_kernel_to_fpregs(&to_tcb->kfpu->state);
>> -#if LINUX_VERSION_CODE >= KERNEL_VERSION(5,2,0)
>> +#if 0
>> /* redo the invalidation done by kernel_fpu_begin */
>> __cpu_invalidate_fpregs_state();
>> #endif
>>
>> Thanks
>> Zqiang
>>
>
> Interesting. Yes, SSE instructions are preferred for memcpy on today's
> CPUs. And that version-dependent code is obviously not taken by 4.19.
> Forms a picture, but we still need to understand why our switchtest is
> not catching the issue. And we need to understand the issue itself.
>
> Jan
>
> --
> Siemens AG, Technology
> Competence Center Embedded Linux
>
--
Siemens AG, Technology
Competence Center Embedded Linux
^ permalink raw reply [flat|nested] 24+ messages in thread
* RE: Memory corruptions upon strcpy and similar when being interrupted by scheduler
2022-11-02 15:34 ` Heber, Stefan
2022-11-02 15:48 ` Jan Kiszka
@ 2022-11-03 1:42 ` Zhang, Qiang1
2022-11-03 13:42 ` Heber, Stefan
1 sibling, 1 reply; 24+ messages in thread
From: Zhang, Qiang1 @ 2022-11-03 1:42 UTC (permalink / raw)
To: Heber, Stefan, Kiszka, Jan; +Cc: Chen, Hongzhan, Wang, Rick Y, xenomai
>Hello Zqiang,
>
>We tested your 0001-IPIPE-ignore-xenomai-FPU-operation.patch on our system (Linux-kernel 5.4, Xenomai v3.2).
>
>This patch makes the problem disappear with our tiny testapp on our system, too.
>But with a systemtest from our huge application (>250k LoC, >20 threads) the problem still exists.
Hi Stefan
Thanks again for the help with the test. at least that gives us a big direction to look at the problem.
I'm not sure if it's possible, can you share your systemtest from our huge application with us?
Thanks
Zqiang
>
>Stefan
-----Original Message-----
From: Zhang, Qiang1 <qiang1.zhang@intel.com>
Sent: Wednesday, November 2, 2022 12:30 PM
To: Heber, Stefan <Stefan.Heber@zwickroell.com>; Kiszka, Jan <jan.kiszka@siemens.com>
Cc: Chen, Hongzhan <hongzhan.chen@intel.com>; Wang, Rick Y <rick.y.wang@intel.com>; xenomai@lists.linux.dev
Subject: RE: Memory corruptions upon strcpy and similar when being interrupted by scheduler
>Dear list,
>
>We tested some of the suggested ways to make the problem disappear.
>Here our results:
>
>1. The patch of kernel/cobalt/arch/x86/ipipe/thread.c as suggested by Zqiang makes the problem disappear with our tiny testapp on our system, too.
>But with a systemtest from our huge application (>250k LoC, >20 threads) the problem still exists.
Hello Stefan
I guess this problem is related to FPU, so I ignore FPU operation on Xenoami, the FPU operation
is fully controlled by linux kernel. The patch base on Xenoami v3.2.
As usual, I apply this patch and use kernel-5.4 run your testapp, this problem disappear.
do you have time to test it out with your huge application?
Thanks
Zqiang
>
>2. The problem disappears with linux 5.10.127, xenomai 3.2.2 and dovetail with our tiny testapp on our system, too.
>And it also disappears with the above mentioned huge systemtest AND with the complete application.
>
>Tests with 4.19.x are still in progress.
>
>Stefan
-----Original Message-----
From: Jan Kiszka <jan.kiszka@siemens.com>
Sent: Tuesday, October 25, 2022 8:40 AM
To: Zhang, Qiang1 <qiang1.zhang@intel.com>; Heber, Stefan <Stefan.Heber@zwickroell.com>
Cc: Chen, Hongzhan <hongzhan.chen@intel.com>; Wang, Rick Y <rick.y.wang@intel.com>; xenomai@lists.linux.dev
Subject: Re: Memory corruptions upon strcpy and similar when being interrupted by scheduler
On 25.10.22 04:39, Zhang, Qiang1 wrote:
> On 30.09.22 13:47, Heber, Stefan wrote:
>> Dear list,
>>
>> we, as long time Xenomai users now have a severe problem. We are currently
>> in the process of migrating our huge application from xenomai 2.6.4 32bit
>> to 3.2.2 64bit (linux 5.4.105). In general we are almost done, but one
>> problem remains: Obviously we have memory corruptions resulting from
>> strcpy functions (transferring large configurations) being interrupted by
>> high prio tasks.
>>
>> We now nailed this problem down in two minimal test applications in order
>> to rule out any programming errors in our own sources. These two
>> applications are:
>> a) a simple test that swaps two very large strings forth and back via
>> strcpy (and alternatively other copy implementations) and then check the
>> string contents. This simply happens on the main thread.
>> b) a "sleepproc" app that simply contains a while/nanosleep loop that
>> wakes up every 500ms just in order to interrupt app a).
>>
>> When running the test app while sleepproc is running we see sporadically
>> errors (typically less than 20 runs of test until we see that error).
>> Without the sleepproc app, test runs without errors. And don't worry
>> about this magic txr19391 prefix, it is just an issue number ;-)
>>
>> So, could you please help us and have a look into this problem?
>>
>> Some remarks:
>> - The test seems to be highly sensitive concerning timing. So we had to
>> fine-tune a lot to see the error in this minimal test. Also it seems that
>> even the CPU may influence performance enough to make the error
>> disappear. Another weird thing is, that if we let the sleepproc sleep
>> 100ms rather than 500ms the error disappears.
>> - In the test we can either work with individual mallocs for the needed
>> 3 string buffers or with one large malloc and specific "pool allocations"
>> from that large pool buffer. We can see the error only, if we use the
>> pool approach (see the two options in the code switchable by commenting/
>> discommenting).
>> - We tested 5 different copy methods: strcpy, memcpy, two types of while
>> loops, one for-loop. We can only see the error with strcpy, memcpy and
>> for-loop. (also here: see the options in the code). Maybe that depends on
>> timing, maybe it depends on the implementation ... we don't know.
>>
>> CPUs we tested on (all with more or less the same kernel config):
>> - Intel(R) Core(TM) i5-8400H CPU @ 2.50GHz, 4 cores
>> - Intel(R) Core(TM) i7-7820EQ CPU @ 3.00GHz, 4 cores
>> - Intel(R) Core(TM) i7-4700EQ CPU @ 2.40GHz, 4 cores
>> - Intel(R) Atom(TM) CPU D525 @ 1.80GHz, 2 cores ... here we couldn't tune
>> it such that the error appears
>>
>> So, thanks in advance and, btw, thanks a lot for your excellent work
>> during the last >15 years!
>>
>> Best regards
>> Stefan
>>
>> Ok, confirmed under xenomai-images, qemu-amd64, 3.2-head, 5.4-head. But
>> it does not seem to trigger with 4.19-head (all the rest was the same).
>> So we may "only" have to look into what makes 5.4 special. Didn't debug
>> anything yet, though.
>
>
> My test environment (xenomai-v3.2.1 linux-kernelv5.4.105 qemu), can reproduce.
> but after I made the modification as below, the problem disappeared,
> It seems that the large memory copy uses the FPU.
>
> --- a/kernel/cobalt/arch/x86/ipipe/thread.c
> +++ b/kernel/cobalt/arch/x86/ipipe/thread.c
> @@ -153,7 +153,7 @@ void xnarch_switch_to(struct xnthread *out, struct xnthread *in)
> */
> clts();
> #endif /* ! IPIPE_X86_FPU_EAGER */
> -#if LINUX_VERSION_CODE >= KERNEL_VERSION(5,2,0)
> +#if 0
> if (!xnthread_test_state(out, XNROOT | XNUSER) &&
> !test_thread_flag(TIF_NEED_FPU_LOAD)) {
> /*
> @@ -209,7 +209,7 @@ void xnarch_switch_to(struct xnthread *out, struct xnthread *in)
> #ifndef IPIPE_X86_FPU_EAGER
> stts();
> #endif /* ! IPIPE_X86_FPU_EAGER */
> -#if LINUX_VERSION_CODE >= KERNEL_VERSION(5,2,0)
> +#if 0
> /*
> * Refresh 'in', we switch the stacks. However, there might be no
> * current thread at this point.
> @@ -445,7 +445,7 @@ void xnarch_switch_fpu(struct xnthread *from, struct xnthread *to)
> return;
>
> copy_kernel_to_fpregs(&to_tcb->kfpu->state);
> -#if LINUX_VERSION_CODE >= KERNEL_VERSION(5,2,0)
> +#if 0
> /* redo the invalidation done by kernel_fpu_begin */
> __cpu_invalidate_fpregs_state();
> #endif
>
> Thanks
> Zqiang
>
Interesting. Yes, SSE instructions are preferred for memcpy on today's
CPUs. And that version-dependent code is obviously not taken by 4.19.
Forms a picture, but we still need to understand why our switchtest is
not catching the issue. And we need to understand the issue itself.
Jan
--
Siemens AG, Technology
Competence Center Embedded Linux
^ permalink raw reply [flat|nested] 24+ messages in thread
* RE: Memory corruptions upon strcpy and similar when being interrupted by scheduler
2022-11-03 1:42 ` Zhang, Qiang1
@ 2022-11-03 13:42 ` Heber, Stefan
0 siblings, 0 replies; 24+ messages in thread
From: Heber, Stefan @ 2022-11-03 13:42 UTC (permalink / raw)
To: Zhang, Qiang1, Kiszka, Jan; +Cc: Chen, Hongzhan, Wang, Rick Y, xenomai
Hello Zqiang,
The systemtest from our huge application is very complex and needs a lot of binaries and testdata.
Sharing all the needed stuff is not that simple.
If you have further patches you want to test out with our systemtest we can do this for you.
Stefan
-----Original Message-----
From: Zhang, Qiang1 <qiang1.zhang@intel.com>
Sent: Thursday, November 3, 2022 2:42 AM
To: Heber, Stefan <Stefan.Heber@zwickroell.com>; Kiszka, Jan <jan.kiszka@siemens.com>
Cc: Chen, Hongzhan <hongzhan.chen@intel.com>; Wang, Rick Y <rick.y.wang@intel.com>; xenomai@lists.linux.dev
Subject: RE: Memory corruptions upon strcpy and similar when being interrupted by scheduler
>Hello Zqiang,
>
>We tested your 0001-IPIPE-ignore-xenomai-FPU-operation.patch on our system (Linux-kernel 5.4, Xenomai v3.2).
>
>This patch makes the problem disappear with our tiny testapp on our system, too.
>But with a systemtest from our huge application (>250k LoC, >20 threads) the problem still exists.
Hi Stefan
Thanks again for the help with the test. at least that gives us a big direction to look at the problem.
I'm not sure if it's possible, can you share your systemtest from our huge application with us?
Thanks
Zqiang
>
>Stefan
-----Original Message-----
From: Zhang, Qiang1 <qiang1.zhang@intel.com>
Sent: Wednesday, November 2, 2022 12:30 PM
To: Heber, Stefan <Stefan.Heber@zwickroell.com>; Kiszka, Jan <jan.kiszka@siemens.com>
Cc: Chen, Hongzhan <hongzhan.chen@intel.com>; Wang, Rick Y <rick.y.wang@intel.com>; xenomai@lists.linux.dev
Subject: RE: Memory corruptions upon strcpy and similar when being interrupted by scheduler
>Dear list,
>
>We tested some of the suggested ways to make the problem disappear.
>Here our results:
>
>1. The patch of kernel/cobalt/arch/x86/ipipe/thread.c as suggested by Zqiang makes the problem disappear with our tiny testapp on our system, too.
>But with a systemtest from our huge application (>250k LoC, >20 threads) the problem still exists.
Hello Stefan
I guess this problem is related to FPU, so I ignore FPU operation on Xenoami, the FPU operation
is fully controlled by linux kernel. The patch base on Xenoami v3.2.
As usual, I apply this patch and use kernel-5.4 run your testapp, this problem disappear.
do you have time to test it out with your huge application?
Thanks
Zqiang
>
>2. The problem disappears with linux 5.10.127, xenomai 3.2.2 and dovetail with our tiny testapp on our system, too.
>And it also disappears with the above mentioned huge systemtest AND with the complete application.
>
>Tests with 4.19.x are still in progress.
>
>Stefan
-----Original Message-----
From: Jan Kiszka <jan.kiszka@siemens.com>
Sent: Tuesday, October 25, 2022 8:40 AM
To: Zhang, Qiang1 <qiang1.zhang@intel.com>; Heber, Stefan <Stefan.Heber@zwickroell.com>
Cc: Chen, Hongzhan <hongzhan.chen@intel.com>; Wang, Rick Y <rick.y.wang@intel.com>; xenomai@lists.linux.dev
Subject: Re: Memory corruptions upon strcpy and similar when being interrupted by scheduler
On 25.10.22 04:39, Zhang, Qiang1 wrote:
> On 30.09.22 13:47, Heber, Stefan wrote:
>> Dear list,
>>
>> we, as long time Xenomai users now have a severe problem. We are currently
>> in the process of migrating our huge application from xenomai 2.6.4 32bit
>> to 3.2.2 64bit (linux 5.4.105). In general we are almost done, but one
>> problem remains: Obviously we have memory corruptions resulting from
>> strcpy functions (transferring large configurations) being interrupted by
>> high prio tasks.
>>
>> We now nailed this problem down in two minimal test applications in order
>> to rule out any programming errors in our own sources. These two
>> applications are:
>> a) a simple test that swaps two very large strings forth and back via
>> strcpy (and alternatively other copy implementations) and then check the
>> string contents. This simply happens on the main thread.
>> b) a "sleepproc" app that simply contains a while/nanosleep loop that
>> wakes up every 500ms just in order to interrupt app a).
>>
>> When running the test app while sleepproc is running we see sporadically
>> errors (typically less than 20 runs of test until we see that error).
>> Without the sleepproc app, test runs without errors. And don't worry
>> about this magic txr19391 prefix, it is just an issue number ;-)
>>
>> So, could you please help us and have a look into this problem?
>>
>> Some remarks:
>> - The test seems to be highly sensitive concerning timing. So we had to
>> fine-tune a lot to see the error in this minimal test. Also it seems that
>> even the CPU may influence performance enough to make the error
>> disappear. Another weird thing is, that if we let the sleepproc sleep
>> 100ms rather than 500ms the error disappears.
>> - In the test we can either work with individual mallocs for the needed
>> 3 string buffers or with one large malloc and specific "pool allocations"
>> from that large pool buffer. We can see the error only, if we use the
>> pool approach (see the two options in the code switchable by commenting/
>> discommenting).
>> - We tested 5 different copy methods: strcpy, memcpy, two types of while
>> loops, one for-loop. We can only see the error with strcpy, memcpy and
>> for-loop. (also here: see the options in the code). Maybe that depends on
>> timing, maybe it depends on the implementation ... we don't know.
>>
>> CPUs we tested on (all with more or less the same kernel config):
>> - Intel(R) Core(TM) i5-8400H CPU @ 2.50GHz, 4 cores
>> - Intel(R) Core(TM) i7-7820EQ CPU @ 3.00GHz, 4 cores
>> - Intel(R) Core(TM) i7-4700EQ CPU @ 2.40GHz, 4 cores
>> - Intel(R) Atom(TM) CPU D525 @ 1.80GHz, 2 cores ... here we couldn't tune
>> it such that the error appears
>>
>> So, thanks in advance and, btw, thanks a lot for your excellent work
>> during the last >15 years!
>>
>> Best regards
>> Stefan
>>
>> Ok, confirmed under xenomai-images, qemu-amd64, 3.2-head, 5.4-head. But
>> it does not seem to trigger with 4.19-head (all the rest was the same).
>> So we may "only" have to look into what makes 5.4 special. Didn't debug
>> anything yet, though.
>
>
> My test environment (xenomai-v3.2.1 linux-kernelv5.4.105 qemu), can reproduce.
> but after I made the modification as below, the problem disappeared,
> It seems that the large memory copy uses the FPU.
>
> --- a/kernel/cobalt/arch/x86/ipipe/thread.c
> +++ b/kernel/cobalt/arch/x86/ipipe/thread.c
> @@ -153,7 +153,7 @@ void xnarch_switch_to(struct xnthread *out, struct xnthread *in)
> */
> clts();
> #endif /* ! IPIPE_X86_FPU_EAGER */
> -#if LINUX_VERSION_CODE >= KERNEL_VERSION(5,2,0)
> +#if 0
> if (!xnthread_test_state(out, XNROOT | XNUSER) &&
> !test_thread_flag(TIF_NEED_FPU_LOAD)) {
> /*
> @@ -209,7 +209,7 @@ void xnarch_switch_to(struct xnthread *out, struct xnthread *in)
> #ifndef IPIPE_X86_FPU_EAGER
> stts();
> #endif /* ! IPIPE_X86_FPU_EAGER */
> -#if LINUX_VERSION_CODE >= KERNEL_VERSION(5,2,0)
> +#if 0
> /*
> * Refresh 'in', we switch the stacks. However, there might be no
> * current thread at this point.
> @@ -445,7 +445,7 @@ void xnarch_switch_fpu(struct xnthread *from, struct xnthread *to)
> return;
>
> copy_kernel_to_fpregs(&to_tcb->kfpu->state);
> -#if LINUX_VERSION_CODE >= KERNEL_VERSION(5,2,0)
> +#if 0
> /* redo the invalidation done by kernel_fpu_begin */
> __cpu_invalidate_fpregs_state();
> #endif
>
> Thanks
> Zqiang
>
Interesting. Yes, SSE instructions are preferred for memcpy on today's
CPUs. And that version-dependent code is obviously not taken by 4.19.
Forms a picture, but we still need to understand why our switchtest is
not catching the issue. And we need to understand the issue itself.
Jan
--
Siemens AG, Technology
Competence Center Embedded Linux
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Memory corruptions upon strcpy and similar when being interrupted by scheduler
2022-11-02 15:48 ` Jan Kiszka
@ 2022-11-07 8:42 ` Jan Kiszka
2022-11-07 11:39 ` Jan Kiszka
0 siblings, 1 reply; 24+ messages in thread
From: Jan Kiszka @ 2022-11-07 8:42 UTC (permalink / raw)
To: Heber, Stefan, Zhang, Qiang1; +Cc: Chen, Hongzhan, Wang, Rick Y, xenomai
On 02.11.22 16:48, Jan Kiszka wrote:
> On 02.11.22 16:34, Heber, Stefan wrote:
>> Hello Zqiang,
>>
>> We tested your 0001-IPIPE-ignore-xenomai-FPU-operation.patch on our system (Linux-kernel 5.4, Xenomai v3.2).
>>
>> This patch makes the problem disappear with our tiny testapp on our system, too.
>> But with a systemtest from our huge application (>250k LoC, >20 threads) the problem still exists.
>
> The patch is surely no solution, but it points to the direction where we
> need to dig. Unfortunately, I still didn't find enough contiguous time
> to start that.
I'm starting to understand the problem:
Somewhere between 4.19 and 5.4, the kernel moved FPU restoration for
incoming threads from the thread-switching code to
prepare_exit_to_usermode(). However, this path is not taken when
switching in a primary thread, at least when it's coming from secondary.
Need to look for the right way to account for this now.
Jan
--
Siemens AG, Technology
Competence Center Embedded Linux
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Memory corruptions upon strcpy and similar when being interrupted by scheduler
2022-11-07 8:42 ` Jan Kiszka
@ 2022-11-07 11:39 ` Jan Kiszka
2022-11-07 13:18 ` Zhang, Qiang1
0 siblings, 1 reply; 24+ messages in thread
From: Jan Kiszka @ 2022-11-07 11:39 UTC (permalink / raw)
To: Heber, Stefan, Zhang, Qiang1; +Cc: Chen, Hongzhan, Wang, Rick Y, xenomai
On 07.11.22 09:42, Jan Kiszka wrote:
> On 02.11.22 16:48, Jan Kiszka wrote:
>> On 02.11.22 16:34, Heber, Stefan wrote:
>>> Hello Zqiang,
>>>
>>> We tested your 0001-IPIPE-ignore-xenomai-FPU-operation.patch on our system (Linux-kernel 5.4, Xenomai v3.2).
>>>
>>> This patch makes the problem disappear with our tiny testapp on our system, too.
>>> But with a systemtest from our huge application (>250k LoC, >20 threads) the problem still exists.
>>
>> The patch is surely no solution, but it points to the direction where we
>> need to dig. Unfortunately, I still didn't find enough contiguous time
>> to start that.
>
> I'm starting to understand the problem:
>
> Somewhere between 4.19 and 5.4, the kernel moved FPU restoration for
> incoming threads from the thread-switching code to
> prepare_exit_to_usermode(). However, this path is not taken when
> switching in a primary thread, at least when it's coming from secondary.
> Need to look for the right way to account for this now.
>
A first, so far promising fix attempt:
diff --git a/kernel/cobalt/arch/x86/ipipe/thread.c b/kernel/cobalt/arch/x86/ipipe/thread.c
index 7e28903a42..8bd2cd912b 100644
--- a/kernel/cobalt/arch/x86/ipipe/thread.c
+++ b/kernel/cobalt/arch/x86/ipipe/thread.c
@@ -443,15 +443,19 @@ void xnarch_switch_fpu(struct xnthread *from, struct xnthread *to)
{
struct xnarchtcb *const to_tcb = xnthread_archtcb(to);
- if (!tcb_used_kfpu(to_tcb))
- return;
-
- copy_kernel_to_fpregs(&to_tcb->kfpu->state);
+ if (tcb_used_kfpu(to_tcb)) {
+ copy_kernel_to_fpregs(&to_tcb->kfpu->state);
#if LINUX_VERSION_CODE >= KERNEL_VERSION(5,2,0)
- /* redo the invalidation done by kernel_fpu_begin */
- __cpu_invalidate_fpregs_state();
+ /* redo the invalidation done by kernel_fpu_begin */
+ __cpu_invalidate_fpregs_state();
+#endif
+ kernel_fpu_disable();
+ }
+#if LINUX_VERSION_CODE >= KERNEL_VERSION(5,2,0)
+ else if (xnthread_test_state(to, XNROOT | XNUSER) == XNUSER &&
+ test_thread_flag(TIF_NEED_FPU_LOAD))
+ switch_fpu_return();
#endif
- kernel_fpu_disable();
}
#endif /* ! IPIPE_X86_FPU_EAGER */
Jan
--
Siemens AG, Technology
Competence Center Embedded Linux
^ permalink raw reply related [flat|nested] 24+ messages in thread
* RE: Memory corruptions upon strcpy and similar when being interrupted by scheduler
2022-11-07 11:39 ` Jan Kiszka
@ 2022-11-07 13:18 ` Zhang, Qiang1
2022-11-07 13:22 ` Bezdeka, Florian
2022-11-07 15:09 ` Heber, Stefan
0 siblings, 2 replies; 24+ messages in thread
From: Zhang, Qiang1 @ 2022-11-07 13:18 UTC (permalink / raw)
To: Kiszka, Jan, Heber, Stefan; +Cc: Chen, Hongzhan, Wang, Rick Y, xenomai
On 07.11.22 09:42, Jan Kiszka wrote:
> On 02.11.22 16:48, Jan Kiszka wrote:
>> On 02.11.22 16:34, Heber, Stefan wrote:
>>> Hello Zqiang,
>>>
>>> We tested your 0001-IPIPE-ignore-xenomai-FPU-operation.patch on our system (Linux-kernel 5.4, Xenomai v3.2).
>>>
>>> This patch makes the problem disappear with our tiny testapp on our system, too.
>>> But with a systemtest from our huge application (>250k LoC, >20 threads) the problem still exists.
>>
>> The patch is surely no solution, but it points to the direction where we
>> need to dig. Unfortunately, I still didn't find enough contiguous time
>> to start that.
>
> I'm starting to understand the problem:
>
> Somewhere between 4.19 and 5.4, the kernel moved FPU restoration for
> incoming threads from the thread-switching code to
> prepare_exit_to_usermode(). However, this path is not taken when
> switching in a primary thread, at least when it's coming from secondary.
> Need to look for the right way to account for this now.
>
>A first, so far promising fix attempt:
Hi Jan
Thanks for the patch, I have tested it base on Xenomai v3.2 and linux-v5.4
This problem disappear. I expect Stefan's test result.
Thanks
Zqiang
>
>
>diff --git a/kernel/cobalt/arch/x86/ipipe/thread.c b/kernel/cobalt/arch/x86/ipipe/thread.c
>index 7e28903a42..8bd2cd912b 100644
>--- a/kernel/cobalt/arch/x86/ipipe/thread.c
>+++ b/kernel/cobalt/arch/x86/ipipe/thread.c
>@@ -443,15 +443,19 @@ void xnarch_switch_fpu(struct xnthread *from, struct xnthread *to)
> {
> struct xnarchtcb *const to_tcb = xnthread_archtcb(to);
>
>- if (!tcb_used_kfpu(to_tcb))
>- return;
>-
>- copy_kernel_to_fpregs(&to_tcb->kfpu->state);
>+ if (tcb_used_kfpu(to_tcb)) {
>+ copy_kernel_to_fpregs(&to_tcb->kfpu->state);
> #if LINUX_VERSION_CODE >= KERNEL_VERSION(5,2,0)
>- /* redo the invalidation done by kernel_fpu_begin */
>- __cpu_invalidate_fpregs_state();
>+ /* redo the invalidation done by kernel_fpu_begin */
>+ __cpu_invalidate_fpregs_state();
>+#endif
>+ kernel_fpu_disable();
>+ }
>+#if LINUX_VERSION_CODE >= KERNEL_VERSION(5,2,0)
>+ else if (xnthread_test_state(to, XNROOT | XNUSER) == XNUSER &&
>+ test_thread_flag(TIF_NEED_FPU_LOAD))
>+ switch_fpu_return();
>#endif
>- kernel_fpu_disable();
> }
> #endif /* ! IPIPE_X86_FPU_EAGER */
>
>
>Jan
>
>--
>Siemens AG, Technology
>Competence Center Embedded Linux
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Memory corruptions upon strcpy and similar when being interrupted by scheduler
2022-11-07 13:18 ` Zhang, Qiang1
@ 2022-11-07 13:22 ` Bezdeka, Florian
2022-11-07 13:38 ` Jan Kiszka
2022-11-07 15:09 ` Heber, Stefan
1 sibling, 1 reply; 24+ messages in thread
From: Bezdeka, Florian @ 2022-11-07 13:22 UTC (permalink / raw)
To: qiang1.zhang, Kiszka, Jan, Stefan.Heber
Cc: hongzhan.chen, rick.y.wang, xenomai
On Mon, 2022-11-07 at 13:18 +0000, Zhang, Qiang1 wrote:
> On 07.11.22 09:42, Jan Kiszka wrote:
> > On 02.11.22 16:48, Jan Kiszka wrote:
> > > On 02.11.22 16:34, Heber, Stefan wrote:
> > > > Hello Zqiang,
> > > >
> > > > We tested your 0001-IPIPE-ignore-xenomai-FPU-operation.patch on our system (Linux-kernel 5.4, Xenomai v3.2).
> > > >
> > > > This patch makes the problem disappear with our tiny testapp on our system, too.
> > > > But with a systemtest from our huge application (>250k LoC, >20 threads) the problem still exists.
> > >
> > > The patch is surely no solution, but it points to the direction where we
> > > need to dig. Unfortunately, I still didn't find enough contiguous time
> > > to start that.
> >
> > I'm starting to understand the problem:
> >
> > Somewhere between 4.19 and 5.4, the kernel moved FPU restoration for
> > incoming threads from the thread-switching code to
> > prepare_exit_to_usermode(). However, this path is not taken when
> > switching in a primary thread, at least when it's coming from secondary.
> > Need to look for the right way to account for this now.
> >
>
> > A first, so far promising fix attempt:
>
> Hi Jan
>
> Thanks for the patch, I have tested it base on Xenomai v3.2 and linux-v5.4
> This problem disappear. I expect Stefan's test result.
Even if this is the correct solution (LGTM) we should update the test
suite to cover such cases. I fear there is more work to do.
>
> Thanks
> Zqiang
>
> >
> >
> > diff --git a/kernel/cobalt/arch/x86/ipipe/thread.c b/kernel/cobalt/arch/x86/ipipe/thread.c
> > index 7e28903a42..8bd2cd912b 100644
> > --- a/kernel/cobalt/arch/x86/ipipe/thread.c
> > +++ b/kernel/cobalt/arch/x86/ipipe/thread.c
> > @@ -443,15 +443,19 @@ void xnarch_switch_fpu(struct xnthread *from, struct xnthread *to)
> > {
> > struct xnarchtcb *const to_tcb = xnthread_archtcb(to);
> >
> > - if (!tcb_used_kfpu(to_tcb))
> > - return;
> > -
> > - copy_kernel_to_fpregs(&to_tcb->kfpu->state);
> > + if (tcb_used_kfpu(to_tcb)) {
> > + copy_kernel_to_fpregs(&to_tcb->kfpu->state);
> > #if LINUX_VERSION_CODE >= KERNEL_VERSION(5,2,0)
> > - /* redo the invalidation done by kernel_fpu_begin */
> > - __cpu_invalidate_fpregs_state();
> > + /* redo the invalidation done by kernel_fpu_begin */
> > + __cpu_invalidate_fpregs_state();
> > +#endif
> > + kernel_fpu_disable();
> > + }
> > +#if LINUX_VERSION_CODE >= KERNEL_VERSION(5,2,0)
> > + else if (xnthread_test_state(to, XNROOT | XNUSER) == XNUSER &&
> > + test_thread_flag(TIF_NEED_FPU_LOAD))
> > + switch_fpu_return();
> > #endif
> > - kernel_fpu_disable();
> > }
> > #endif /* ! IPIPE_X86_FPU_EAGER */
> >
> >
> > Jan
> >
> > --
> > Siemens AG, Technology
> > Competence Center Embedded Linux
>
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Memory corruptions upon strcpy and similar when being interrupted by scheduler
2022-11-07 13:22 ` Bezdeka, Florian
@ 2022-11-07 13:38 ` Jan Kiszka
0 siblings, 0 replies; 24+ messages in thread
From: Jan Kiszka @ 2022-11-07 13:38 UTC (permalink / raw)
To: Bezdeka, Florian (T CED SES-DE),
qiang1.zhang, Stefan.Heber, Schaffner, Tobias (T CED SES-DE)
Cc: hongzhan.chen, rick.y.wang, xenomai
On 07.11.22 14:22, Bezdeka, Florian (T CED SES-DE) wrote:
> On Mon, 2022-11-07 at 13:18 +0000, Zhang, Qiang1 wrote:
>> On 07.11.22 09:42, Jan Kiszka wrote:
>>> On 02.11.22 16:48, Jan Kiszka wrote:
>>>> On 02.11.22 16:34, Heber, Stefan wrote:
>>>>> Hello Zqiang,
>>>>>
>>>>> We tested your 0001-IPIPE-ignore-xenomai-FPU-operation.patch on our system (Linux-kernel 5.4, Xenomai v3.2).
>>>>>
>>>>> This patch makes the problem disappear with our tiny testapp on our system, too.
>>>>> But with a systemtest from our huge application (>250k LoC, >20 threads) the problem still exists.
>>>>
>>>> The patch is surely no solution, but it points to the direction where we
>>>> need to dig. Unfortunately, I still didn't find enough contiguous time
>>>> to start that.
>>>
>>> I'm starting to understand the problem:
>>>
>>> Somewhere between 4.19 and 5.4, the kernel moved FPU restoration for
>>> incoming threads from the thread-switching code to
>>> prepare_exit_to_usermode(). However, this path is not taken when
>>> switching in a primary thread, at least when it's coming from secondary.
>>> Need to look for the right way to account for this now.
>>>
>>
>>> A first, so far promising fix attempt:
>>
>> Hi Jan
>>
>> Thanks for the patch, I have tested it base on Xenomai v3.2 and linux-v5.4
>> This problem disappear. I expect Stefan's test result.
>
> Even if this is the correct solution (LGTM) we should update the test
> suite to cover such cases. I fear there is more work to do.
>
If we are lucky, "just" resolving
https://gitlab.com/Xenomai/xenomai-hacker-space/-/issues/22 may help
here. I've asked my colleague Tobias to have a look at that.
Jan
>>
>> Thanks
>> Zqiang
>>
>>>
>>>
>>> diff --git a/kernel/cobalt/arch/x86/ipipe/thread.c b/kernel/cobalt/arch/x86/ipipe/thread.c
>>> index 7e28903a42..8bd2cd912b 100644
>>> --- a/kernel/cobalt/arch/x86/ipipe/thread.c
>>> +++ b/kernel/cobalt/arch/x86/ipipe/thread.c
>>> @@ -443,15 +443,19 @@ void xnarch_switch_fpu(struct xnthread *from, struct xnthread *to)
>>> {
>>> struct xnarchtcb *const to_tcb = xnthread_archtcb(to);
>>>
>>> - if (!tcb_used_kfpu(to_tcb))
>>> - return;
>>> -
>>> - copy_kernel_to_fpregs(&to_tcb->kfpu->state);
>>> + if (tcb_used_kfpu(to_tcb)) {
>>> + copy_kernel_to_fpregs(&to_tcb->kfpu->state);
>>> #if LINUX_VERSION_CODE >= KERNEL_VERSION(5,2,0)
>>> - /* redo the invalidation done by kernel_fpu_begin */
>>> - __cpu_invalidate_fpregs_state();
>>> + /* redo the invalidation done by kernel_fpu_begin */
>>> + __cpu_invalidate_fpregs_state();
>>> +#endif
>>> + kernel_fpu_disable();
>>> + }
>>> +#if LINUX_VERSION_CODE >= KERNEL_VERSION(5,2,0)
>>> + else if (xnthread_test_state(to, XNROOT | XNUSER) == XNUSER &&
>>> + test_thread_flag(TIF_NEED_FPU_LOAD))
>>> + switch_fpu_return();
>>> #endif
>>> - kernel_fpu_disable();
>>> }
>>> #endif /* ! IPIPE_X86_FPU_EAGER */
>>>
>>>
>>> Jan
>>>
>>> --
>>> Siemens AG, Technology
>>> Competence Center Embedded Linux
>>
>
--
Siemens AG, Technology
Competence Center Embedded Linux
^ permalink raw reply [flat|nested] 24+ messages in thread
* RE: Memory corruptions upon strcpy and similar when being interrupted by scheduler
2022-11-07 13:18 ` Zhang, Qiang1
2022-11-07 13:22 ` Bezdeka, Florian
@ 2022-11-07 15:09 ` Heber, Stefan
2022-11-07 16:20 ` Jan Kiszka
1 sibling, 1 reply; 24+ messages in thread
From: Heber, Stefan @ 2022-11-07 15:09 UTC (permalink / raw)
To: Zhang, Qiang1, Kiszka, Jan; +Cc: Chen, Hongzhan, Wang, Rick Y, xenomai
Hello Jan and Zqiang,
We tested Jan's patch on our system (Linux-kernel 5.4, Xenomai v3.2).
This patch makes the problem disappear with our tiny testapp on our system, too.
And the problem disappears also with the systemtest from our huge application.
Stefan
-----Original Message-----
From: Zhang, Qiang1 <qiang1.zhang@intel.com>
Sent: Monday, November 7, 2022 2:18 PM
To: Kiszka, Jan <jan.kiszka@siemens.com>; Heber, Stefan <Stefan.Heber@zwickroell.com>
Cc: Chen, Hongzhan <hongzhan.chen@intel.com>; Wang, Rick Y <rick.y.wang@intel.com>; xenomai@lists.linux.dev
Subject: RE: Memory corruptions upon strcpy and similar when being interrupted by scheduler
On 07.11.22 09:42, Jan Kiszka wrote:
> On 02.11.22 16:48, Jan Kiszka wrote:
>> On 02.11.22 16:34, Heber, Stefan wrote:
>>> Hello Zqiang,
>>>
>>> We tested your 0001-IPIPE-ignore-xenomai-FPU-operation.patch on our system (Linux-kernel 5.4, Xenomai v3.2).
>>>
>>> This patch makes the problem disappear with our tiny testapp on our system, too.
>>> But with a systemtest from our huge application (>250k LoC, >20 threads) the problem still exists.
>>
>> The patch is surely no solution, but it points to the direction where we
>> need to dig. Unfortunately, I still didn't find enough contiguous time
>> to start that.
>
> I'm starting to understand the problem:
>
> Somewhere between 4.19 and 5.4, the kernel moved FPU restoration for
> incoming threads from the thread-switching code to
> prepare_exit_to_usermode(). However, this path is not taken when
> switching in a primary thread, at least when it's coming from secondary.
> Need to look for the right way to account for this now.
>
>A first, so far promising fix attempt:
Hi Jan
Thanks for the patch, I have tested it base on Xenomai v3.2 and linux-v5.4
This problem disappear. I expect Stefan's test result.
Thanks
Zqiang
>
>
>diff --git a/kernel/cobalt/arch/x86/ipipe/thread.c b/kernel/cobalt/arch/x86/ipipe/thread.c
>index 7e28903a42..8bd2cd912b 100644
>--- a/kernel/cobalt/arch/x86/ipipe/thread.c
>+++ b/kernel/cobalt/arch/x86/ipipe/thread.c
>@@ -443,15 +443,19 @@ void xnarch_switch_fpu(struct xnthread *from, struct xnthread *to)
> {
> struct xnarchtcb *const to_tcb = xnthread_archtcb(to);
>
>- if (!tcb_used_kfpu(to_tcb))
>- return;
>-
>- copy_kernel_to_fpregs(&to_tcb->kfpu->state);
>+ if (tcb_used_kfpu(to_tcb)) {
>+ copy_kernel_to_fpregs(&to_tcb->kfpu->state);
> #if LINUX_VERSION_CODE >= KERNEL_VERSION(5,2,0)
>- /* redo the invalidation done by kernel_fpu_begin */
>- __cpu_invalidate_fpregs_state();
>+ /* redo the invalidation done by kernel_fpu_begin */
>+ __cpu_invalidate_fpregs_state();
>+#endif
>+ kernel_fpu_disable();
>+ }
>+#if LINUX_VERSION_CODE >= KERNEL_VERSION(5,2,0)
>+ else if (xnthread_test_state(to, XNROOT | XNUSER) == XNUSER &&
>+ test_thread_flag(TIF_NEED_FPU_LOAD))
>+ switch_fpu_return();
>#endif
>- kernel_fpu_disable();
> }
> #endif /* ! IPIPE_X86_FPU_EAGER */
>
>
>Jan
>
>--
>Siemens AG, Technology
>Competence Center Embedded Linux
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Memory corruptions upon strcpy and similar when being interrupted by scheduler
2022-11-07 15:09 ` Heber, Stefan
@ 2022-11-07 16:20 ` Jan Kiszka
0 siblings, 0 replies; 24+ messages in thread
From: Jan Kiszka @ 2022-11-07 16:20 UTC (permalink / raw)
To: Heber, Stefan, Zhang, Qiang1; +Cc: Chen, Hongzhan, Wang, Rick Y, xenomai
On 07.11.22 16:09, Heber, Stefan wrote:
> Hello Jan and Zqiang,
>
> We tested Jan's patch on our system (Linux-kernel 5.4, Xenomai v3.2).
>
> This patch makes the problem disappear with our tiny testapp on our system, too.
> And the problem disappears also with the systemtest from our huge application.
Great to hear! I will meditate over a good commit message - and if that
change actually catches everything.
Jan
>
> Stefan
>
> -----Original Message-----
> From: Zhang, Qiang1 <qiang1.zhang@intel.com>
> Sent: Monday, November 7, 2022 2:18 PM
> To: Kiszka, Jan <jan.kiszka@siemens.com>; Heber, Stefan <Stefan.Heber@zwickroell.com>
> Cc: Chen, Hongzhan <hongzhan.chen@intel.com>; Wang, Rick Y <rick.y.wang@intel.com>; xenomai@lists.linux.dev
> Subject: RE: Memory corruptions upon strcpy and similar when being interrupted by scheduler
>
> On 07.11.22 09:42, Jan Kiszka wrote:
>> On 02.11.22 16:48, Jan Kiszka wrote:
>>> On 02.11.22 16:34, Heber, Stefan wrote:
>>>> Hello Zqiang,
>>>>
>>>> We tested your 0001-IPIPE-ignore-xenomai-FPU-operation.patch on our system (Linux-kernel 5.4, Xenomai v3.2).
>>>>
>>>> This patch makes the problem disappear with our tiny testapp on our system, too.
>>>> But with a systemtest from our huge application (>250k LoC, >20 threads) the problem still exists.
>>>
>>> The patch is surely no solution, but it points to the direction where we
>>> need to dig. Unfortunately, I still didn't find enough contiguous time
>>> to start that.
>>
>> I'm starting to understand the problem:
>>
>> Somewhere between 4.19 and 5.4, the kernel moved FPU restoration for
>> incoming threads from the thread-switching code to
>> prepare_exit_to_usermode(). However, this path is not taken when
>> switching in a primary thread, at least when it's coming from secondary.
>> Need to look for the right way to account for this now.
>>
>
>> A first, so far promising fix attempt:
>
> Hi Jan
>
> Thanks for the patch, I have tested it base on Xenomai v3.2 and linux-v5.4
> This problem disappear. I expect Stefan's test result.
>
> Thanks
> Zqiang
>
>>
>>
>> diff --git a/kernel/cobalt/arch/x86/ipipe/thread.c b/kernel/cobalt/arch/x86/ipipe/thread.c
>> index 7e28903a42..8bd2cd912b 100644
>> --- a/kernel/cobalt/arch/x86/ipipe/thread.c
>> +++ b/kernel/cobalt/arch/x86/ipipe/thread.c
>> @@ -443,15 +443,19 @@ void xnarch_switch_fpu(struct xnthread *from, struct xnthread *to)
>> {
>> struct xnarchtcb *const to_tcb = xnthread_archtcb(to);
>>
>> - if (!tcb_used_kfpu(to_tcb))
>> - return;
>> -
>> - copy_kernel_to_fpregs(&to_tcb->kfpu->state);
>> + if (tcb_used_kfpu(to_tcb)) {
>> + copy_kernel_to_fpregs(&to_tcb->kfpu->state);
>> #if LINUX_VERSION_CODE >= KERNEL_VERSION(5,2,0)
>> - /* redo the invalidation done by kernel_fpu_begin */
>> - __cpu_invalidate_fpregs_state();
>> + /* redo the invalidation done by kernel_fpu_begin */
>> + __cpu_invalidate_fpregs_state();
>> +#endif
>> + kernel_fpu_disable();
>> + }
>> +#if LINUX_VERSION_CODE >= KERNEL_VERSION(5,2,0)
>> + else if (xnthread_test_state(to, XNROOT | XNUSER) == XNUSER &&
>> + test_thread_flag(TIF_NEED_FPU_LOAD))
>> + switch_fpu_return();
>> #endif
>> - kernel_fpu_disable();
>> }
>> #endif /* ! IPIPE_X86_FPU_EAGER */
>>
>>
>> Jan
>>
>> --
>> Siemens AG, Technology
>> Competence Center Embedded Linux
>
--
Siemens AG, Technology
Competence Center Embedded Linux
^ permalink raw reply [flat|nested] 24+ messages in thread
* RE: Memory corruptions upon strcpy and similar when being interrupted by scheduler
2022-10-20 6:10 ` Jan Kiszka
@ 2022-10-20 7:50 ` Chen, Hongzhan
0 siblings, 0 replies; 24+ messages in thread
From: Chen, Hongzhan @ 2022-10-20 7:50 UTC (permalink / raw)
To: Kiszka, Jan, Zhang, Qiang1, Heber, Stefan, rpm; +Cc: Wang, Rick Y, xenomai
>-----Original Message-----
>From: Jan Kiszka <jan.kiszka@siemens.com>
>Sent: Thursday, October 20, 2022 2:10 PM
>To: Chen, Hongzhan <hongzhan.chen@intel.com>; Zhang, Qiang1
><qiang1.zhang@intel.com>; Heber, Stefan <Stefan.Heber@zwickroell.com>;
>rpm@xenomai.org
>Cc: Wang, Rick Y <rick.y.wang@intel.com>; xenomai@lists.linux.dev
>Subject: Re: Memory corruptions upon strcpy and similar when being
>interrupted by scheduler
>
>On 20.10.22 02:41, Chen, Hongzhan wrote:
>>
>>
>>> -----Original Message-----
>>> From: Zhang, Qiang1 <qiang1.zhang@intel.com>
>>> Sent: Monday, October 17, 2022 4:44 PM
>>> To: Heber, Stefan <Stefan.Heber@zwickroell.com>; Kiszka, Jan
>>> <jan.kiszka@siemens.com>; rpm@xenomai.org
>>> Cc: Wang, Rick Y <rick.y.wang@intel.com>; Chen, Hongzhan
>>> <hongzhan.chen@intel.com>; xenomai@lists.linux.dev
>>> Subject: RE: Memory corruptions upon strcpy and similar when being
>>> interrupted by scheduler
>>>
>>> Hi Stefan
>>>
>>> I also use xenomai-v3.2 and linux-v5.10.y-dovetail to test it.
>>> This problem does not trigger whether we use memcpy or strcpy
>>> (not need to change txr19391test code).
>>>
>>> It seems likely that the problem is related to i-pipe.
>>
>> I found it write wrong own stack address into alloced memory when issue
>happen.
>> For example after run txr19391test
>> cat its /proc/pid/maps. Its stack address is from 7ffdad88e000 -
>7ffdad8af000 like following.
>>
>> 7ff784727000-7ff784728000 rw-p 00000000 00:00 0
>> 7ffdad88e000-7ffdad8af000 rw-p 00000000 00:00 0 [stack]
>> 7ffdad96a000-7ffdad96d000 r--p 00000000 00:00 0 [vvar]
>> 7ffdad96d000-7ffdad96e000 r-xp 00000000 00:00 0 [vdso]
>>
>> After print 16 bytes of the corrupted data in txr19391test, we can see
>> data like following:
>>
>> 0x78 0xcb 0x8a 0xad 0xfd 0x7f 0x0 0x0
>> 0xb0 0xcb 0x8a 0xad 0xfd 0x 7f 0x0 0x0
>>
>
>Is the stack pointer of the related thread invalid in that case as well?
We will continue to further debug to check if it is invalid at that time. In addition, we added debug code for be more quicker to find the corruption in xnintr_core_clock_handler which is triggered on other CPU before app running on CPU1 find corruption and then set breakpoint there as you suggested to try to locate the problematic context and find the root cause.
Regards
Hongzhan Chen
>
>Jan
>
>--
>Siemens AG, Technology
>Competence Center Embedded Linux
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Memory corruptions upon strcpy and similar when being interrupted by scheduler
2022-10-20 0:41 ` Chen, Hongzhan
@ 2022-10-20 6:10 ` Jan Kiszka
2022-10-20 7:50 ` Chen, Hongzhan
0 siblings, 1 reply; 24+ messages in thread
From: Jan Kiszka @ 2022-10-20 6:10 UTC (permalink / raw)
To: Chen, Hongzhan, Zhang, Qiang1, Heber, Stefan, rpm; +Cc: Wang, Rick Y, xenomai
On 20.10.22 02:41, Chen, Hongzhan wrote:
>
>
>> -----Original Message-----
>> From: Zhang, Qiang1 <qiang1.zhang@intel.com>
>> Sent: Monday, October 17, 2022 4:44 PM
>> To: Heber, Stefan <Stefan.Heber@zwickroell.com>; Kiszka, Jan
>> <jan.kiszka@siemens.com>; rpm@xenomai.org
>> Cc: Wang, Rick Y <rick.y.wang@intel.com>; Chen, Hongzhan
>> <hongzhan.chen@intel.com>; xenomai@lists.linux.dev
>> Subject: RE: Memory corruptions upon strcpy and similar when being
>> interrupted by scheduler
>>
>> Hi Stefan
>>
>> I also use xenomai-v3.2 and linux-v5.10.y-dovetail to test it.
>> This problem does not trigger whether we use memcpy or strcpy
>> (not need to change txr19391test code).
>>
>> It seems likely that the problem is related to i-pipe.
>
> I found it write wrong own stack address into alloced memory when issue happen.
> For example after run txr19391test
> cat its /proc/pid/maps. Its stack address is from 7ffdad88e000 - 7ffdad8af000 like following.
>
> 7ff784727000-7ff784728000 rw-p 00000000 00:00 0
> 7ffdad88e000-7ffdad8af000 rw-p 00000000 00:00 0 [stack]
> 7ffdad96a000-7ffdad96d000 r--p 00000000 00:00 0 [vvar]
> 7ffdad96d000-7ffdad96e000 r-xp 00000000 00:00 0 [vdso]
>
> After print 16 bytes of the corrupted data in txr19391test, we can see
> data like following:
>
> 0x78 0xcb 0x8a 0xad 0xfd 0x7f 0x0 0x0
> 0xb0 0xcb 0x8a 0xad 0xfd 0x 7f 0x0 0x0
>
Is the stack pointer of the related thread invalid in that case as well?
Jan
--
Siemens AG, Technology
Competence Center Embedded Linux
^ permalink raw reply [flat|nested] 24+ messages in thread
* RE: Memory corruptions upon strcpy and similar when being interrupted by scheduler
2022-10-17 8:43 ` Zhang, Qiang1
@ 2022-10-20 0:41 ` Chen, Hongzhan
2022-10-20 6:10 ` Jan Kiszka
0 siblings, 1 reply; 24+ messages in thread
From: Chen, Hongzhan @ 2022-10-20 0:41 UTC (permalink / raw)
To: Zhang, Qiang1, Heber, Stefan, Kiszka, Jan, rpm; +Cc: Wang, Rick Y, xenomai
>-----Original Message-----
>From: Zhang, Qiang1 <qiang1.zhang@intel.com>
>Sent: Monday, October 17, 2022 4:44 PM
>To: Heber, Stefan <Stefan.Heber@zwickroell.com>; Kiszka, Jan
><jan.kiszka@siemens.com>; rpm@xenomai.org
>Cc: Wang, Rick Y <rick.y.wang@intel.com>; Chen, Hongzhan
><hongzhan.chen@intel.com>; xenomai@lists.linux.dev
>Subject: RE: Memory corruptions upon strcpy and similar when being
>interrupted by scheduler
>
>Hi Stefan
>
>I also use xenomai-v3.2 and linux-v5.10.y-dovetail to test it.
>This problem does not trigger whether we use memcpy or strcpy
>(not need to change txr19391test code).
>
>It seems likely that the problem is related to i-pipe.
I found it write wrong own stack address into alloced memory when issue happen.
For example after run txr19391test
cat its /proc/pid/maps. Its stack address is from 7ffdad88e000 - 7ffdad8af000 like following.
7ff784727000-7ff784728000 rw-p 00000000 00:00 0
7ffdad88e000-7ffdad8af000 rw-p 00000000 00:00 0 [stack]
7ffdad96a000-7ffdad96d000 r--p 00000000 00:00 0 [vvar]
7ffdad96d000-7ffdad96e000 r-xp 00000000 00:00 0 [vdso]
After print 16 bytes of the corrupted data in txr19391test, we can see
data like following:
0x78 0xcb 0x8a 0xad 0xfd 0x7f 0x0 0x0
0xb0 0xcb 0x8a 0xad 0xfd 0x 7f 0x0 0x0
Regards
Hongzhan Chen
>
>Thanks
>Zqiang
>
>
>
>
>-----Original Message-----
>From: Heber, Stefan <Stefan.Heber@zwickroell.com>
>Sent: Friday, October 14, 2022 8:49 PM
>To: Zhang, Qiang1 <qiang1.zhang@intel.com>; xenomai@lists.linux.dev;
>Kiszka, Jan <jan.kiszka@siemens.com>; rpm@xenomai.org
>Cc: Wang, Rick Y <rick.y.wang@intel.com>; Chen, Hongzhan
><hongzhan.chen@intel.com>
>Subject: RE: Memory corruptions upon strcpy and similar when being
>interrupted by scheduler
>
>Hi Zqiang,
>
>We' re glad to hear that someone else can reproduce our problem.
>The problem disappears with your modification (move simple_allocator_init()
>after pthread_setschedparam()) on our system, too.
>
>We don't understand why this modification helps. Maybe we do when
>someone found the root cause.
>
>Thanks
>Stefan
>
>
>-----Ursprüngliche Nachricht-----
>Von: Zhang, Qiang1 <qiang1.zhang@intel.com>
>Gesendet: Freitag, 14. Oktober 2022 11:28
>An: Heber, Stefan <Stefan.Heber@zwickroell.com>; xenomai@lists.linux.dev;
>Kiszka, Jan <jan.kiszka@siemens.com>; rpm@xenomai.org
>Cc: Wang, Rick Y <rick.y.wang@intel.com>; Chen, Hongzhan
><hongzhan.chen@intel.com>
>Betreff: RE: Memory corruptions upon strcpy and similar when being
>interrupted by scheduler
>
>
>-----Original Message-----
>From: Heber, Stefan <Stefan.Heber@zwickroell.com>
>Sent: Friday, September 30, 2022 7:47 PM
>To: xenomai@lists.linux.dev
>Subject: Memory corruptions upon strcpy and similar when being interrupted
>by scheduler
>
>Dear list,
>
>we, as long time Xenomai users now have a severe problem. We are currently
>in the process of migrating our huge application from xenomai 2.6.4 32bit
>to 3.2.2 64bit (linux 5.4.105). In general we are almost done, but one
>problem remains: Obviously we have memory corruptions resulting from
>strcpy functions (transferring large configurations) being interrupted by
>high prio tasks.
>
>We now nailed this problem down in two minimal test applications in order
>to rule out any programming errors in our own sources. These two
>applications are:
>a) a simple test that swaps two very large strings forth and back via
>strcpy (and alternatively other copy implementations) and then check the
>string contents. This simply happens on the main thread.
>b) a "sleepproc" app that simply contains a while/nanosleep loop that
>wakes up every 500ms just in order to interrupt app a).
>
>
>
>
>
>Hi Heber, Stefan
>
>I tested according to the steps a), b) you described, and I also can reproduce
>this problem.
>
>(xenomai-v3.2.1, linux-5.4.105, ipipe-core-5.4.105-x86-4.patch)
>The test method used is as follows:
>after launching txr19391sleepproc, run test.sh
>copy methods: memcpy
>
>#!/bin/bash
>
>for host in {1..20000}
>do
> ./txr19391test
>done
>
># ./test.sh
>ok
>ok
>ok
>ok
>error at position 40473600 of string S1: expected 98, actual: -56
>
>but after I made changes to the code
>
>about txr19391test.c:
>I only move simple_allocator_init() after pthread_setschedparam()
>
>use test.sh to test it, this problem cannot reproduce.
>But I haven't found the root cause yet, You can test it according to my
>modification to
>see if it can be reproduced.
>Maybe Jan and Philippe will have some ideas.
>
>Thanks
>Zqiang
>
>
>
>
>
>When running the test app while sleepproc is running we see sporadically
>errors (typically less than 20 runs of test until we see that error).
>Without the sleepproc app, test runs without errors. And don't worry
>about this magic txr19391 prefix, it is just an issue number ;-)
>
>So, could you please help us and have a look into this problem?
>
>Some remarks:
>- The test seems to be highly sensitive concerning timing. So we had to
>fine-tune a lot to see the error in this minimal test. Also it seems that
>even the CPU may influence performance enough to make the error
>disappear. Another weird thing is, that if we let the sleepproc sleep
>100ms rather than 500ms the error disappears.
>- In the test we can either work with individual mallocs for the needed
>3 string buffers or with one large malloc and specific "pool allocations"
>from that large pool buffer. We can see the error only, if we use the
>pool approach (see the two options in the code switchable by commenting/
>discommenting).
>- We tested 5 different copy methods: strcpy, memcpy, two types of while
>loops, one for-loop. We can only see the error with strcpy, memcpy and
>for-loop. (also here: see the options in the code). Maybe that depends on
>timing, maybe it depends on the implementation ... we don't know.
>
>CPUs we tested on (all with more or less the same kernel config):
>- Intel(R) Core(TM) i5-8400H CPU @ 2.50GHz, 4 cores
>- Intel(R) Core(TM) i7-7820EQ CPU @ 3.00GHz, 4 cores
>- Intel(R) Core(TM) i7-4700EQ CPU @ 2.40GHz, 4 cores
>- Intel(R) Atom(TM) CPU D525 @ 1.80GHz, 2 cores ... here we couldn't tune
> it such that the error appears
>
>So, thanks in advance and, btw, thanks a lot for your excellent work
>during the last >15 years!
>
>Best regards
>Stefan
^ permalink raw reply [flat|nested] 24+ messages in thread
* RE: Memory corruptions upon strcpy and similar when being interrupted by scheduler
2022-10-14 12:49 Heber, Stefan
@ 2022-10-17 8:43 ` Zhang, Qiang1
2022-10-20 0:41 ` Chen, Hongzhan
0 siblings, 1 reply; 24+ messages in thread
From: Zhang, Qiang1 @ 2022-10-17 8:43 UTC (permalink / raw)
To: Heber, Stefan, Kiszka, Jan, rpm; +Cc: Wang, Rick Y, Chen, Hongzhan, xenomai
Hi Stefan
I also use xenomai-v3.2 and linux-v5.10.y-dovetail to test it.
This problem does not trigger whether we use memcpy or strcpy
(not need to change txr19391test code).
It seems likely that the problem is related to i-pipe.
Thanks
Zqiang
-----Original Message-----
From: Heber, Stefan <Stefan.Heber@zwickroell.com>
Sent: Friday, October 14, 2022 8:49 PM
To: Zhang, Qiang1 <qiang1.zhang@intel.com>; xenomai@lists.linux.dev; Kiszka, Jan <jan.kiszka@siemens.com>; rpm@xenomai.org
Cc: Wang, Rick Y <rick.y.wang@intel.com>; Chen, Hongzhan <hongzhan.chen@intel.com>
Subject: RE: Memory corruptions upon strcpy and similar when being interrupted by scheduler
Hi Zqiang,
We' re glad to hear that someone else can reproduce our problem.
The problem disappears with your modification (move simple_allocator_init() after pthread_setschedparam()) on our system, too.
We don't understand why this modification helps. Maybe we do when someone found the root cause.
Thanks
Stefan
-----Ursprüngliche Nachricht-----
Von: Zhang, Qiang1 <qiang1.zhang@intel.com>
Gesendet: Freitag, 14. Oktober 2022 11:28
An: Heber, Stefan <Stefan.Heber@zwickroell.com>; xenomai@lists.linux.dev; Kiszka, Jan <jan.kiszka@siemens.com>; rpm@xenomai.org
Cc: Wang, Rick Y <rick.y.wang@intel.com>; Chen, Hongzhan <hongzhan.chen@intel.com>
Betreff: RE: Memory corruptions upon strcpy and similar when being interrupted by scheduler
-----Original Message-----
From: Heber, Stefan <Stefan.Heber@zwickroell.com>
Sent: Friday, September 30, 2022 7:47 PM
To: xenomai@lists.linux.dev
Subject: Memory corruptions upon strcpy and similar when being interrupted by scheduler
Dear list,
we, as long time Xenomai users now have a severe problem. We are currently
in the process of migrating our huge application from xenomai 2.6.4 32bit
to 3.2.2 64bit (linux 5.4.105). In general we are almost done, but one
problem remains: Obviously we have memory corruptions resulting from
strcpy functions (transferring large configurations) being interrupted by
high prio tasks.
We now nailed this problem down in two minimal test applications in order
to rule out any programming errors in our own sources. These two
applications are:
a) a simple test that swaps two very large strings forth and back via
strcpy (and alternatively other copy implementations) and then check the
string contents. This simply happens on the main thread.
b) a "sleepproc" app that simply contains a while/nanosleep loop that
wakes up every 500ms just in order to interrupt app a).
Hi Heber, Stefan
I tested according to the steps a), b) you described, and I also can reproduce this problem.
(xenomai-v3.2.1, linux-5.4.105, ipipe-core-5.4.105-x86-4.patch)
The test method used is as follows:
after launching txr19391sleepproc, run test.sh
copy methods: memcpy
#!/bin/bash
for host in {1..20000}
do
./txr19391test
done
# ./test.sh
ok
ok
ok
ok
error at position 40473600 of string S1: expected 98, actual: -56
but after I made changes to the code
about txr19391test.c:
I only move simple_allocator_init() after pthread_setschedparam()
use test.sh to test it, this problem cannot reproduce.
But I haven't found the root cause yet, You can test it according to my modification to
see if it can be reproduced.
Maybe Jan and Philippe will have some ideas.
Thanks
Zqiang
When running the test app while sleepproc is running we see sporadically
errors (typically less than 20 runs of test until we see that error).
Without the sleepproc app, test runs without errors. And don't worry
about this magic txr19391 prefix, it is just an issue number ;-)
So, could you please help us and have a look into this problem?
Some remarks:
- The test seems to be highly sensitive concerning timing. So we had to
fine-tune a lot to see the error in this minimal test. Also it seems that
even the CPU may influence performance enough to make the error
disappear. Another weird thing is, that if we let the sleepproc sleep
100ms rather than 500ms the error disappears.
- In the test we can either work with individual mallocs for the needed
3 string buffers or with one large malloc and specific "pool allocations"
from that large pool buffer. We can see the error only, if we use the
pool approach (see the two options in the code switchable by commenting/
discommenting).
- We tested 5 different copy methods: strcpy, memcpy, two types of while
loops, one for-loop. We can only see the error with strcpy, memcpy and
for-loop. (also here: see the options in the code). Maybe that depends on
timing, maybe it depends on the implementation ... we don't know.
CPUs we tested on (all with more or less the same kernel config):
- Intel(R) Core(TM) i5-8400H CPU @ 2.50GHz, 4 cores
- Intel(R) Core(TM) i7-7820EQ CPU @ 3.00GHz, 4 cores
- Intel(R) Core(TM) i7-4700EQ CPU @ 2.40GHz, 4 cores
- Intel(R) Atom(TM) CPU D525 @ 1.80GHz, 2 cores ... here we couldn't tune
it such that the error appears
So, thanks in advance and, btw, thanks a lot for your excellent work
during the last >15 years!
Best regards
Stefan
^ permalink raw reply [flat|nested] 24+ messages in thread
* RE: Memory corruptions upon strcpy and similar when being interrupted by scheduler
@ 2022-10-14 12:49 Heber, Stefan
2022-10-17 8:43 ` Zhang, Qiang1
0 siblings, 1 reply; 24+ messages in thread
From: Heber, Stefan @ 2022-10-14 12:49 UTC (permalink / raw)
To: Zhang, Qiang1, xenomai, Kiszka, Jan, rpm; +Cc: Wang, Rick Y, Chen, Hongzhan
Hi Zqiang,
We' re glad to hear that someone else can reproduce our problem.
The problem disappears with your modification (move simple_allocator_init() after pthread_setschedparam()) on our system, too.
We don't understand why this modification helps. Maybe we do when someone found the root cause.
Thanks
Stefan
-----Ursprüngliche Nachricht-----
Von: Zhang, Qiang1 <qiang1.zhang@intel.com>
Gesendet: Freitag, 14. Oktober 2022 11:28
An: Heber, Stefan <Stefan.Heber@zwickroell.com>; xenomai@lists.linux.dev; Kiszka, Jan <jan.kiszka@siemens.com>; rpm@xenomai.org
Cc: Wang, Rick Y <rick.y.wang@intel.com>; Chen, Hongzhan <hongzhan.chen@intel.com>
Betreff: RE: Memory corruptions upon strcpy and similar when being interrupted by scheduler
-----Original Message-----
From: Heber, Stefan <Stefan.Heber@zwickroell.com>
Sent: Friday, September 30, 2022 7:47 PM
To: xenomai@lists.linux.dev
Subject: Memory corruptions upon strcpy and similar when being interrupted by scheduler
Dear list,
we, as long time Xenomai users now have a severe problem. We are currently
in the process of migrating our huge application from xenomai 2.6.4 32bit
to 3.2.2 64bit (linux 5.4.105). In general we are almost done, but one
problem remains: Obviously we have memory corruptions resulting from
strcpy functions (transferring large configurations) being interrupted by
high prio tasks.
We now nailed this problem down in two minimal test applications in order
to rule out any programming errors in our own sources. These two
applications are:
a) a simple test that swaps two very large strings forth and back via
strcpy (and alternatively other copy implementations) and then check the
string contents. This simply happens on the main thread.
b) a "sleepproc" app that simply contains a while/nanosleep loop that
wakes up every 500ms just in order to interrupt app a).
Hi Heber, Stefan
I tested according to the steps a), b) you described, and I also can reproduce this problem.
(xenomai-v3.2.1, linux-5.4.105, ipipe-core-5.4.105-x86-4.patch)
The test method used is as follows:
after launching txr19391sleepproc, run test.sh
copy methods: memcpy
#!/bin/bash
for host in {1..20000}
do
./txr19391test
done
# ./test.sh
ok
ok
ok
ok
error at position 40473600 of string S1: expected 98, actual: -56
but after I made changes to the code
about txr19391test.c:
I only move simple_allocator_init() after pthread_setschedparam()
use test.sh to test it, this problem cannot reproduce.
But I haven't found the root cause yet, You can test it according to my modification to
see if it can be reproduced.
Maybe Jan and Philippe will have some ideas.
Thanks
Zqiang
When running the test app while sleepproc is running we see sporadically
errors (typically less than 20 runs of test until we see that error).
Without the sleepproc app, test runs without errors. And don't worry
about this magic txr19391 prefix, it is just an issue number ;-)
So, could you please help us and have a look into this problem?
Some remarks:
- The test seems to be highly sensitive concerning timing. So we had to
fine-tune a lot to see the error in this minimal test. Also it seems that
even the CPU may influence performance enough to make the error
disappear. Another weird thing is, that if we let the sleepproc sleep
100ms rather than 500ms the error disappears.
- In the test we can either work with individual mallocs for the needed
3 string buffers or with one large malloc and specific "pool allocations"
from that large pool buffer. We can see the error only, if we use the
pool approach (see the two options in the code switchable by commenting/
discommenting).
- We tested 5 different copy methods: strcpy, memcpy, two types of while
loops, one for-loop. We can only see the error with strcpy, memcpy and
for-loop. (also here: see the options in the code). Maybe that depends on
timing, maybe it depends on the implementation ... we don't know.
CPUs we tested on (all with more or less the same kernel config):
- Intel(R) Core(TM) i5-8400H CPU @ 2.50GHz, 4 cores
- Intel(R) Core(TM) i7-7820EQ CPU @ 3.00GHz, 4 cores
- Intel(R) Core(TM) i7-4700EQ CPU @ 2.40GHz, 4 cores
- Intel(R) Atom(TM) CPU D525 @ 1.80GHz, 2 cores ... here we couldn't tune
it such that the error appears
So, thanks in advance and, btw, thanks a lot for your excellent work
during the last >15 years!
Best regards
Stefan
^ permalink raw reply [flat|nested] 24+ messages in thread
end of thread, other threads:[~2022-11-07 16:20 UTC | newest]
Thread overview: 24+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-09-30 11:47 Memory corruptions upon strcpy and similar when being interrupted by scheduler Heber, Stefan
2022-10-14 9:28 ` Zhang, Qiang1
2022-10-24 20:13 ` Jan Kiszka
2022-10-25 2:39 ` Zhang, Qiang1
2022-10-25 6:40 ` Jan Kiszka
2022-10-26 12:50 ` Heber, Stefan
2022-11-02 11:30 ` Zhang, Qiang1
2022-11-02 15:34 ` Heber, Stefan
2022-11-02 15:48 ` Jan Kiszka
2022-11-07 8:42 ` Jan Kiszka
2022-11-07 11:39 ` Jan Kiszka
2022-11-07 13:18 ` Zhang, Qiang1
2022-11-07 13:22 ` Bezdeka, Florian
2022-11-07 13:38 ` Jan Kiszka
2022-11-07 15:09 ` Heber, Stefan
2022-11-07 16:20 ` Jan Kiszka
2022-11-03 1:42 ` Zhang, Qiang1
2022-11-03 13:42 ` Heber, Stefan
2022-10-28 12:12 ` Heber, Stefan
2022-10-14 12:49 Heber, Stefan
2022-10-17 8:43 ` Zhang, Qiang1
2022-10-20 0:41 ` Chen, Hongzhan
2022-10-20 6:10 ` Jan Kiszka
2022-10-20 7:50 ` Chen, Hongzhan
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.