Re: [patch for 2.6.32? 1/3] hrtimers: remove the "timer_stats_active" check when setting the start info

Re: [patch for 2.6.32? 1/3] hrtimers: remove the "timer_stats_active" check when setting the start info

[Thomas Gleixner]

On Tue, 17 Nov 2009, akpm@linux-foundation.org wrote:

Back to LKML with some more cc's.

> From: Feng Tang <feng.tang@intel.com>
> 
> Recent hrtimer code will set the start info to a hrtimer only when that
> flag is set, then the start info of all hrtimers will always be
> uninitialised before a "echo 1 > /proc/timer_stats", thus the
> /proc/timer_lists will have something like:
> 
> active timers:
>  #0: <c27d46b0>, tick_sched_timer, S:01, <(null)>, /-1
>  # expires at 91062000000-91062000000 nsecs [in 156071 to 156071 nsecs]
>  #1: <efb81b6c>, hrtimer_wakeup, S:01, <(null)>, /-1
>  # expires at 91062300331-91062350331 nsecs [in 456402 to 506402 nsecs]
>  #2: <efac9b6c>, hrtimer_wakeup, S:01, <(null)>, /-1
>  # expires at 91068699811-91068749811 nsecs [in 6855882 to 6905882 nsecs]
>  #3: <efacdb6c>, hrtimer_wakeup, S:01, <(null)>, /-1
>  # expires at 91068755511-91068805511 nsecs [in 6911582 to 6961582 nsecs]
>  #4: <efa95b6c>, hrtimer_wakeup, S:01, <(null)>, /-1
>  # expires at 91068806066-91068856066 nsecs [in 6962137 to 7012137 nsecs]
>  .....
> 
> This patch fixes it.

This patch does more than that and it does not mention it in the
change log. The change log is also missing the context which
introduced this regression.

Just to get the context straight:

commit 507e1231 (timer stats: Optimize by adding quick check to avoid
function calls) commit 507e1231 added the timer_stats_active check in
timer_stats_hrtimer_set_start_info() to reduce the overhead when timer
stats are inactive.

As an unintentional side effect it introduced the above regression in
/proc/timer_list.

>  static inline void timer_stats_hrtimer_set_start_info(struct hrtimer *timer)
>  {
> -	if (likely(!timer_stats_active))
> -		return;

This is fine. It reverts the hrtimer part of commit 507e1231 and fixes
the /proc/timer_list regression for the price of the same overhead
which we had before that commit.

That's the immediate fix which needs to go to Linus and stable.

>  	__timer_stats_hrtimer_set_start_info(timer, __builtin_return_address(0));
>  }
>  
> diff -puN kernel/hrtimer.c~hrtimers-remove-the-timer_stats_active-check-when-setting-the-start-info kernel/hrtimer.c
> --- a/kernel/hrtimer.c~hrtimers-remove-the-timer_stats_active-check-when-setting-the-start-info
> +++ a/kernel/hrtimer.c
> @@ -750,7 +750,7 @@ static inline void hrtimer_init_timer_hr
>  #ifdef CONFIG_TIMER_STATS
>  void __timer_stats_hrtimer_set_start_info(struct hrtimer *timer, void *addr)
>  {
> -	if (timer->start_site)
> +	if (timer->start_site == addr && timer->start_pid == current->pid)

This part is unrelated to the above regression and is wrong for the
following reasons:

  1) it runs the memcpy when the start_site changes even when the pid
     is the same, which is extremly bad for tick->sched_timer as this
     timer is re(armed) frequently from different places when NOHZ=y.

  2) it runs the memcpy when the pid changes which is even worse for
     tick->sched_timer as this timer is re(armed) frequently from
     hrtimer_interrupt which hits random pids and would therefor
     report completely wrong pid/comm info.

This needs more thought and is definitely neither -rc7 nor stable
material.

Thanks,

	tglx

[tip:timers/urgent] hrtimer: Fix /proc/timer_list regression

[tip-bot for Feng Tang]

Commit-ID:  887a29f59b93cf54e21814869a4ab6e80b6fa623
Gitweb:     http://git.kernel.org/tip/887a29f59b93cf54e21814869a4ab6e80b6fa623
Author:     Feng Tang <feng.tang@intel.com>
AuthorDate: Thu, 3 Sep 2009 16:32:53 +0800
Committer:  Thomas Gleixner <tglx@linutronix.de>
CommitDate: Wed, 18 Nov 2009 21:20:37 +0100

hrtimer: Fix /proc/timer_list regression

commit 507e1231 (timer stats: Optimize by adding quick check to avoid
function calls) introduced a regression in /proc/timer_list.

/proc/timer_list shows now
 #0: <c27d46b0>, tick_sched_timer, S:01, <(null)>, /-1
instead of
 #0: <c27d46b0>, tick_sched_timer, S:01, hrtimer_start, swapper/0

Revert the hrtimer quick check for now. The optimization needs more
thought, but this is neither 2.6.32-rc7 nor stable material.

[ tglx: Removed unrelated changes from the original patch and massaged
  	the changelog ]

Signed-off-by: Feng Tang <feng.tang@intel.com>
LKML-Reference: <alpine.LFD.2.00.0911181933540.24119@localhost.localdomain>
Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
Cc: stable@kernel.org
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
---
 include/linux/hrtimer.h |    2 --
 1 files changed, 0 insertions(+), 2 deletions(-)

diff --git a/include/linux/hrtimer.h b/include/linux/hrtimer.h
index ff037f0..0a656d6 100644
--- a/include/linux/hrtimer.h
+++ b/include/linux/hrtimer.h
@@ -457,8 +457,6 @@ extern void __timer_stats_hrtimer_set_start_info(struct hrtimer *timer,
 
 static inline void timer_stats_hrtimer_set_start_info(struct hrtimer *timer)
 {
-	if (likely(!timer_stats_active))
-		return;
 	__timer_stats_hrtimer_set_start_info(timer, __builtin_return_address(0));
 }
 

Re: [tip:timers/urgent] hrtimer: Fix /proc/timer_list regression

[Ingo Molnar]

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


* tip-bot for Feng Tang <feng.tang@intel.com> wrote:

> Commit-ID:  887a29f59b93cf54e21814869a4ab6e80b6fa623
> Gitweb:     http://git.kernel.org/tip/887a29f59b93cf54e21814869a4ab6e80b6fa623
> Author:     Feng Tang <feng.tang@intel.com>
> AuthorDate: Thu, 3 Sep 2009 16:32:53 +0800
> Committer:  Thomas Gleixner <tglx@linutronix.de>
> CommitDate: Wed, 18 Nov 2009 21:20:37 +0100
> 
> hrtimer: Fix /proc/timer_list regression
> 
> commit 507e1231 (timer stats: Optimize by adding quick check to avoid
> function calls) introduced a regression in /proc/timer_list.
> 
> /proc/timer_list shows now
>  #0: <c27d46b0>, tick_sched_timer, S:01, <(null)>, /-1
> instead of
>  #0: <c27d46b0>, tick_sched_timer, S:01, hrtimer_start, swapper/0
> 
> Revert the hrtimer quick check for now. The optimization needs more
> thought, but this is neither 2.6.32-rc7 nor stable material.
> 
> [ tglx: Removed unrelated changes from the original patch and massaged
>   	the changelog ]
> 
> Signed-off-by: Feng Tang <feng.tang@intel.com>
> LKML-Reference: <alpine.LFD.2.00.0911181933540.24119@localhost.localdomain>
> Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
> Cc: stable@kernel.org
> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>

-tip testing found that this commit is causing boot crashes:

[...]
calling  init_mmio_trace+0x0/0xf @ 1
initcall init_mmio_trace+0x0/0xf returned 0 after 699 usecs
calling  init_graph_trace+0x0/0x29 @ 1
Testing tracer function_graph: 
------------[ cut here ]------------
------------[ cut here ]------------
WARNING: at kernel/trace/trace_functions_graph.c:131 ftrace_return_to_handler+0x119/0x130()
Hardware name: System Product Name
Bad frame pointer: expected be04be80, received be04becc
  from func timer_stats_update_stats return to 8106c6fc
Modules linked in:
Pid: 534, comm: kstop/0 Not tainted 2.6.32-rc7-00032-g887a29f-dirty #2762
Call Trace:
 [<8104681f>] warn_slowpath_common+0x5f/0x90
 [<810c1f79>] ? ftrace_return_to_handler+0x119/0x130
 [<81046899>] warn_slowpath_fmt+0x29/0x30
 [<810c1f79>] ftrace_return_to_handler+0x119/0x130
 [<81077214>] ? timer_stats_update_stats+0x14/0x200
 [<8106c6fc>] ? __run_hrtimer+0x14c/0x190
 [<8106bdb0>] ? enqueue_hrtimer+0x80/0xd0
 [<8106c657>] ? __run_hrtimer+0xa7/0x190
 [<81004842>] return_to_handler+0xc/0x3a
 [<81098700>] ? stop_cpu+0x0/0x110
 [<81004836>] return_to_handler+0x0/0x3a
 [<8106c6fc>] __run_hrtimer+0x14c/0x190
 [<81004836>] return_to_handler+0x0/0x3a
 [<8106c9e0>] hrtimer_interrupt+0x140/0x240
 [<81098700>] ? stop_cpu+0x0/0x110
 [<810987b1>] ? stop_cpu+0xb1/0x110
 [<8106392f>] worker_thread+0x15f/0x2c0
 [<810638f3>] ? worker_thread+0x123/0x2c0
 [<81068960>] ? autoremove_wake_function+0x0/0x40
 [<810637d0>] ? worker_thread+0x0/0x2c0
 [<810686ec>] kthread+0x6c/0x70
 [<81068680>] ? kthread+0x0/0x70



i've bisected back to it:

| 887a29f59b93cf54e21814869a4ab6e80b6fa623 is the first bad commit
| commit 887a29f59b93cf54e21814869a4ab6e80b6fa623
| Author: Feng Tang <feng.tang@intel.com>
| Date:   Thu Sep 3 16:32:53 2009 +0800
|
|    hrtimer: Fix /proc/timer_list regression

Config attached.

I've removed it from timers/urgent for now.

	Ingo

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

#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.32-rc7
# Thu Nov 19 06:44:44 2009
#
# CONFIG_64BIT is not set
CONFIG_X86_32=y
# CONFIG_X86_64 is not set
CONFIG_X86=y
CONFIG_OUTPUT_FORMAT="elf32-i386"
CONFIG_ARCH_DEFCONFIG="arch/x86/configs/i386_defconfig"
CONFIG_GENERIC_TIME=y
CONFIG_GENERIC_CMOS_UPDATE=y
CONFIG_CLOCKSOURCE_WATCHDOG=y
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_HAVE_LATENCYTOP_SUPPORT=y
CONFIG_MMU=y
CONFIG_ZONE_DMA=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_IOMAP=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
# CONFIG_RWSEM_GENERIC_SPINLOCK is not set
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_ARCH_HAS_CPU_IDLE_WAIT=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
# CONFIG_GENERIC_TIME_VSYSCALL is not set
CONFIG_ARCH_HAS_CPU_RELAX=y
CONFIG_ARCH_HAS_DEFAULT_IDLE=y
CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
CONFIG_HAVE_SETUP_PER_CPU_AREA=y
CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y
CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y
# CONFIG_HAVE_CPUMASK_OF_CPU_MAP is not set
CONFIG_ARCH_HIBERNATION_POSSIBLE=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
# CONFIG_ZONE_DMA32 is not set
CONFIG_ARCH_POPULATES_NODE_MAP=y
# CONFIG_AUDIT_ARCH is not set
CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y
CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
CONFIG_GENERIC_HARDIRQS=y
CONFIG_GENERIC_HARDIRQS_NO__DO_IRQ=y
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_GENERIC_PENDING_IRQ=y
CONFIG_USE_GENERIC_SMP_HELPERS=y
CONFIG_X86_32_SMP=y
CONFIG_X86_HT=y
CONFIG_X86_TRAMPOLINE=y
CONFIG_KTIME_SCALAR=y
# CONFIG_BOOTPARAM_SUPPORT_NOT_WANTED is not set
# CONFIG_BOOTPARAM_SUPPORT is not set
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
CONFIG_CONSTRUCTORS=y

#
# General setup
#
CONFIG_EXPERIMENTAL=y
CONFIG_BROKEN_BOOT_ALLOWED4=y
CONFIG_BROKEN_BOOT_ALLOWED3=y
CONFIG_BROKEN_BOOT_ALLOWED2=y
CONFIG_BROKEN_BOOT_DISALLOWED=y
# CONFIG_BROKEN_BOOT_EUROPE is not set
# CONFIG_BROKEN_BOOT_TITAN is not set
CONFIG_LOCK_KERNEL=y
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_LOCALVERSION=""
CONFIG_LOCALVERSION_AUTO=y
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_BZIP2=y
CONFIG_HAVE_KERNEL_LZMA=y
# CONFIG_KERNEL_GZIP is not set
# CONFIG_KERNEL_BZIP2 is not set
CONFIG_KERNEL_LZMA=y
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_SYSVIPC_SYSCTL=y
CONFIG_POSIX_MQUEUE=y
CONFIG_POSIX_MQUEUE_SYSCTL=y
CONFIG_BSD_PROCESS_ACCT=y
# CONFIG_BSD_PROCESS_ACCT_V3 is not set
CONFIG_TASKSTATS=y
CONFIG_TASK_DELAY_ACCT=y
CONFIG_TASK_XACCT=y
# CONFIG_TASK_IO_ACCOUNTING is not set
CONFIG_AUDIT=y
CONFIG_AUDITSYSCALL=y
CONFIG_AUDIT_TREE=y

#
# RCU Subsystem
#
CONFIG_TREE_RCU=y
# CONFIG_TREE_PREEMPT_RCU is not set
# CONFIG_TINY_RCU is not set
CONFIG_RCU_TRACE=y
CONFIG_RCU_FANOUT=32
# CONFIG_RCU_FANOUT_EXACT is not set
CONFIG_TREE_RCU_TRACE=y
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
CONFIG_LOG_BUF_SHIFT=20
CONFIG_HAVE_UNSTABLE_SCHED_CLOCK=y
CONFIG_GROUP_SCHED=y
# CONFIG_FAIR_GROUP_SCHED is not set
CONFIG_RT_GROUP_SCHED=y
# CONFIG_USER_SCHED is not set
CONFIG_CGROUP_SCHED=y
CONFIG_CGROUPS=y
CONFIG_CGROUP_DEBUG=y
CONFIG_CGROUP_NS=y
CONFIG_CGROUP_FREEZER=y
CONFIG_CGROUP_DEVICE=y
CONFIG_CPUSETS=y
CONFIG_PROC_PID_CPUSET=y
CONFIG_CGROUP_CPUACCT=y
CONFIG_RESOURCE_COUNTERS=y
CONFIG_CGROUP_MEM_RES_CTLR=y
CONFIG_CGROUP_MEM_RES_CTLR_SWAP=y
CONFIG_MM_OWNER=y
CONFIG_SYSFS_DEPRECATED=y
CONFIG_SYSFS_DEPRECATED_V2=y
CONFIG_RELAY=y
CONFIG_NAMESPACES=y
CONFIG_UTS_NS=y
CONFIG_IPC_NS=y
CONFIG_USER_NS=y
CONFIG_PID_NS=y
CONFIG_NET_NS=y
# CONFIG_BLK_DEV_INITRD is not set
# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
CONFIG_SYSCTL=y
CONFIG_ANON_INODES=y
CONFIG_EMBEDDED=y
CONFIG_UID16=y
# CONFIG_SYSCTL_SYSCALL is not set
CONFIG_KALLSYMS=y
CONFIG_KALLSYMS_ALL=y
CONFIG_KALLSYMS_EXTRA_PASS=y
CONFIG_HOTPLUG=y
CONFIG_PRINTK=y
CONFIG_BUG=y
CONFIG_ELF_CORE=y
CONFIG_PCSPKR_PLATFORM=y
CONFIG_BASE_FULL=y
CONFIG_FUTEX=y
CONFIG_EPOLL=y
# CONFIG_SIGNALFD is not set
# CONFIG_TIMERFD is not set
CONFIG_EVENTFD=y
CONFIG_SHMEM=y
CONFIG_AIO=y
CONFIG_HAVE_PERF_EVENTS=y

#
# Kernel Performance Events And Counters
#
CONFIG_PERF_EVENTS=y
CONFIG_EVENT_PROFILE=y
CONFIG_PERF_COUNTERS=y
# CONFIG_DEBUG_PERF_USE_VMALLOC is not set
CONFIG_VM_EVENT_COUNTERS=y
CONFIG_PCI_QUIRKS=y
CONFIG_SLUB_DEBUG=y
CONFIG_COMPAT_BRK=y
# CONFIG_SLAB is not set
CONFIG_SLUB=y
# CONFIG_SLOB is not set
# CONFIG_PROFILING is not set
CONFIG_TRACEPOINTS=y
CONFIG_HAVE_OPROFILE=y
CONFIG_KPROBES=y
CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS=y
CONFIG_KRETPROBES=y
CONFIG_HAVE_IOREMAP_PROT=y
CONFIG_HAVE_KPROBES=y
CONFIG_HAVE_KRETPROBES=y
CONFIG_HAVE_ARCH_TRACEHOOK=y
CONFIG_HAVE_DMA_ATTRS=y
CONFIG_HAVE_DMA_API_DEBUG=y
CONFIG_HAVE_USER_RETURN_NOTIFIER=y
CONFIG_HAVE_HW_BREAKPOINT=y

#
# GCOV-based kernel profiling
#
CONFIG_SLOW_WORK=y
CONFIG_HAVE_GENERIC_DMA_COHERENT=y
CONFIG_SLABINFO=y
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=y
CONFIG_MODVERSIONS=y
CONFIG_MODULE_SRCVERSION_ALL=y
CONFIG_STOP_MACHINE=y
CONFIG_BLOCK=y
CONFIG_LBDAF=y
# CONFIG_BLK_DEV_BSG is not set
# CONFIG_BLK_DEV_INTEGRITY is not set

#
# IO Schedulers
#
CONFIG_IOSCHED_NOOP=y
CONFIG_IOSCHED_AS=y
CONFIG_IOSCHED_DEADLINE=m
CONFIG_IOSCHED_CFQ=m
# CONFIG_DEFAULT_AS is not set
# CONFIG_DEFAULT_DEADLINE is not set
# CONFIG_DEFAULT_CFQ is not set
CONFIG_DEFAULT_NOOP=y
CONFIG_DEFAULT_IOSCHED="noop"
# CONFIG_INLINE_SPIN_TRYLOCK is not set
# CONFIG_INLINE_SPIN_TRYLOCK_BH is not set
# CONFIG_INLINE_SPIN_LOCK is not set
# CONFIG_INLINE_SPIN_LOCK_BH is not set
# CONFIG_INLINE_SPIN_LOCK_IRQ is not set
# CONFIG_INLINE_SPIN_LOCK_IRQSAVE is not set
# CONFIG_INLINE_SPIN_UNLOCK is not set
# CONFIG_INLINE_SPIN_UNLOCK_BH is not set
# CONFIG_INLINE_SPIN_UNLOCK_IRQ is not set
# CONFIG_INLINE_SPIN_UNLOCK_IRQRESTORE is not set
# CONFIG_INLINE_READ_TRYLOCK is not set
# CONFIG_INLINE_READ_LOCK is not set
# CONFIG_INLINE_READ_LOCK_BH is not set
# CONFIG_INLINE_READ_LOCK_IRQ is not set
# CONFIG_INLINE_READ_LOCK_IRQSAVE is not set
# CONFIG_INLINE_READ_UNLOCK is not set
# CONFIG_INLINE_READ_UNLOCK_BH is not set
# CONFIG_INLINE_READ_UNLOCK_IRQ is not set
# CONFIG_INLINE_READ_UNLOCK_IRQRESTORE is not set
# CONFIG_INLINE_WRITE_TRYLOCK is not set
# CONFIG_INLINE_WRITE_LOCK is not set
# CONFIG_INLINE_WRITE_LOCK_BH is not set
# CONFIG_INLINE_WRITE_LOCK_IRQ is not set
# CONFIG_INLINE_WRITE_LOCK_IRQSAVE is not set
# CONFIG_INLINE_WRITE_UNLOCK is not set
# CONFIG_INLINE_WRITE_UNLOCK_BH is not set
# CONFIG_INLINE_WRITE_UNLOCK_IRQ is not set
# CONFIG_INLINE_WRITE_UNLOCK_IRQRESTORE is not set
CONFIG_FREEZER=y

#
# Processor type and features
#
CONFIG_TICK_ONESHOT=y
# CONFIG_NO_HZ is not set
CONFIG_HIGH_RES_TIMERS=y
CONFIG_GENERIC_CLOCKEVENTS_BUILD=y
CONFIG_SMP_SUPPORT=y
CONFIG_X86_MPPARSE=y
# CONFIG_X86_BIGSMP is not set
# CONFIG_X86_EXTENDED_PLATFORM is not set
CONFIG_SCHED_OMIT_FRAME_POINTER=y
CONFIG_PARAVIRT_GUEST=y
# CONFIG_VMI is not set
CONFIG_KVM_CLOCK=y
# CONFIG_KVM_GUEST is not set
CONFIG_LGUEST_GUEST=y
CONFIG_PARAVIRT=y
# CONFIG_PARAVIRT_SPINLOCKS is not set
CONFIG_PARAVIRT_CLOCK=y
# CONFIG_PARAVIRT_DEBUG is not set
CONFIG_MEMTEST=y
# CONFIG_M386 is not set
# CONFIG_M486 is not set
# CONFIG_M586 is not set
# CONFIG_M586TSC is not set
# CONFIG_M586MMX is not set
# CONFIG_M686 is not set
# CONFIG_MPENTIUMII is not set
# CONFIG_MPENTIUMIII is not set
# CONFIG_MPENTIUMM is not set
# CONFIG_MPENTIUM4 is not set
# CONFIG_MK6 is not set
# CONFIG_MK7 is not set
# CONFIG_MK8 is not set
# CONFIG_MCRUSOE is not set
# CONFIG_MEFFICEON is not set
# CONFIG_MWINCHIPC6 is not set
# CONFIG_MWINCHIP3D is not set
CONFIG_MGEODEGX1=y
# CONFIG_MGEODE_LX is not set
# CONFIG_MCYRIXIII is not set
# CONFIG_MVIAC3_2 is not set
# CONFIG_MVIAC7 is not set
# CONFIG_MPSC is not set
# CONFIG_MCORE2 is not set
# CONFIG_MATOM is not set
# CONFIG_GENERIC_CPU is not set
# CONFIG_X86_GENERIC is not set
CONFIG_X86_CPU=y
CONFIG_X86_INTERNODE_CACHE_SHIFT=4
CONFIG_X86_CMPXCHG=y
CONFIG_X86_L1_CACHE_SHIFT=4
CONFIG_X86_XADD=y
# CONFIG_X86_PPRO_FENCE is not set
CONFIG_X86_WP_WORKS_OK=y
CONFIG_X86_INVLPG=y
CONFIG_X86_BSWAP=y
CONFIG_X86_POPAD_OK=y
CONFIG_X86_ALIGNMENT_16=y
CONFIG_X86_TSC=y
CONFIG_X86_CMPXCHG64=y
CONFIG_X86_MINIMUM_CPU_FAMILY=5
CONFIG_X86_DEBUGCTLMSR=y
# CONFIG_PROCESSOR_SELECT is not set
CONFIG_CPU_SUP_INTEL=y
CONFIG_CPU_SUP_CYRIX_32=y
CONFIG_CPU_SUP_AMD=y
CONFIG_CPU_SUP_CENTAUR=y
CONFIG_CPU_SUP_TRANSMETA_32=y
CONFIG_CPU_SUP_UMC_32=y
# CONFIG_X86_DS is not set
CONFIG_HPET_TIMER=y
CONFIG_HPET_EMULATE_RTC=y
CONFIG_DMI=y
# CONFIG_IOMMU_HELPER is not set
# CONFIG_IOMMU_API is not set
CONFIG_NR_CPUS=8
CONFIG_SCHED_SMT=y
CONFIG_SCHED_MC=y
# CONFIG_PREEMPT_NONE is not set
# CONFIG_PREEMPT_VOLUNTARY is not set
CONFIG_PREEMPT=y
CONFIG_X86_LOCAL_APIC=y
CONFIG_X86_IO_APIC=y
CONFIG_X86_REROUTE_FOR_BROKEN_BOOT_IRQS=y
CONFIG_X86_MCE=y
CONFIG_X86_MCE_INTEL=y
CONFIG_X86_MCE_AMD=y
# CONFIG_X86_ANCIENT_MCE is not set
CONFIG_X86_MCE_THRESHOLD=y
CONFIG_X86_MCE_INJECT=m
CONFIG_X86_THERMAL_VECTOR=y
CONFIG_VM86=y
# CONFIG_I8K is not set
CONFIG_X86_REBOOTFIXUPS=y
CONFIG_MICROCODE=y
CONFIG_MICROCODE_INTEL=y
# CONFIG_MICROCODE_AMD is not set
CONFIG_MICROCODE_OLD_INTERFACE=y
CONFIG_X86_MSR=m
CONFIG_X86_CPUID=y
CONFIG_X86_CPU_DEBUG=m
# CONFIG_UP_WANTED_1 is not set
CONFIG_SMP=y
# CONFIG_NOHIGHMEM is not set
CONFIG_HIGHMEM4G=y
# CONFIG_HIGHMEM64G is not set
# CONFIG_VMSPLIT_3G is not set
# CONFIG_VMSPLIT_3G_OPT is not set
CONFIG_VMSPLIT_2G=y
# CONFIG_VMSPLIT_2G_OPT is not set
# CONFIG_VMSPLIT_1G is not set
CONFIG_PAGE_OFFSET=0x80000000
CONFIG_HIGHMEM=y
# CONFIG_ARCH_PHYS_ADDR_T_64BIT is not set
CONFIG_NEED_NODE_MEMMAP_SIZE=y
CONFIG_ARCH_FLATMEM_ENABLE=y
CONFIG_ARCH_SPARSEMEM_ENABLE=y
CONFIG_ARCH_SELECT_MEMORY_MODEL=y
# CONFIG_ARCH_MEMORY_PROBE is not set
CONFIG_ILLEGAL_POINTER_VALUE=0
CONFIG_SELECT_MEMORY_MODEL=y
# CONFIG_FLATMEM_MANUAL is not set
# CONFIG_DISCONTIGMEM_MANUAL is not set
CONFIG_SPARSEMEM_MANUAL=y
CONFIG_SPARSEMEM=y
CONFIG_HAVE_MEMORY_PRESENT=y
CONFIG_SPARSEMEM_STATIC=y
CONFIG_MEMORY_HOTPLUG=y
CONFIG_MEMORY_HOTPLUG_SPARSE=y
CONFIG_MEMORY_HOTREMOVE=y
CONFIG_SPLIT_PTLOCK_CPUS=4
CONFIG_MIGRATION=y
# CONFIG_PHYS_ADDR_T_64BIT is not set
CONFIG_ZONE_DMA_FLAG=1
CONFIG_BOUNCE=y
CONFIG_VIRT_TO_BUS=y
CONFIG_HAVE_MLOCK=y
CONFIG_HAVE_MLOCKED_PAGE_BIT=y
CONFIG_KSM=y
CONFIG_DEFAULT_MMAP_MIN_ADDR=4096
CONFIG_HIGHPTE=y
CONFIG_X86_CHECK_BIOS_CORRUPTION=y
# CONFIG_X86_BOOTPARAM_MEMORY_CORRUPTION_CHECK is not set
CONFIG_X86_RESERVE_LOW_64K=y
# CONFIG_MATH_EMULATION is not set
CONFIG_MTRR=y
CONFIG_MTRR_SANITIZER=y
CONFIG_MTRR_SANITIZER_ENABLE_DEFAULT=0
CONFIG_MTRR_SANITIZER_SPARE_REG_NR_DEFAULT=1
# CONFIG_X86_PAT is not set
CONFIG_EFI=y
CONFIG_SECCOMP=y
CONFIG_CC_STACKPROTECTOR=y
# CONFIG_HZ_100 is not set
CONFIG_HZ_250=y
# CONFIG_HZ_300 is not set
# CONFIG_HZ_1000 is not set
CONFIG_HZ=250
CONFIG_SCHED_HRTICK=y
CONFIG_KEXEC=y
CONFIG_CRASH_DUMP=y
CONFIG_PHYSICAL_START=0x1000000
CONFIG_RELOCATABLE=y
CONFIG_X86_NEED_RELOCS=y
CONFIG_PHYSICAL_ALIGN=0x1000000
CONFIG_HOTPLUG_CPU=y
CONFIG_COMPAT_VDSO=y
CONFIG_CMDLINE_BOOL=y
CONFIG_CMDLINE=""
CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG=y
CONFIG_ARCH_ENABLE_MEMORY_HOTREMOVE=y

#
# Power management and ACPI options
#
CONFIG_PM=y
# CONFIG_PM_DEBUG is not set
CONFIG_PM_SLEEP_SMP=y
CONFIG_PM_SLEEP=y
CONFIG_SUSPEND=y
CONFIG_SUSPEND_FREEZER=y
# CONFIG_HIBERNATION is not set
# CONFIG_PM_RUNTIME is not set
CONFIG_ACPI=y
CONFIG_ACPI_SLEEP=y
CONFIG_ACPI_PROCFS=y
CONFIG_ACPI_PROCFS_POWER=y
CONFIG_ACPI_POWER_METER=m
# CONFIG_ACPI_SYSFS_POWER is not set
CONFIG_ACPI_PROC_EVENT=y
# CONFIG_ACPI_AC is not set
# CONFIG_ACPI_BATTERY is not set
# CONFIG_ACPI_BUTTON is not set
# CONFIG_ACPI_VIDEO is not set
CONFIG_ACPI_FAN=m
CONFIG_ACPI_DOCK=y
CONFIG_ACPI_PROCESSOR=y
CONFIG_ACPI_HOTPLUG_CPU=y
CONFIG_ACPI_PROCESSOR_AGGREGATOR=y
# CONFIG_ACPI_THERMAL is not set
# CONFIG_ACPI_CUSTOM_DSDT is not set
CONFIG_ACPI_BLACKLIST_YEAR=0
CONFIG_ACPI_DEBUG=y
# CONFIG_ACPI_DEBUG_FUNC_TRACE is not set
CONFIG_ACPI_PCI_SLOT=y
CONFIG_X86_PM_TIMER=y
CONFIG_ACPI_CONTAINER=y
# CONFIG_ACPI_HOTPLUG_MEMORY is not set
CONFIG_ACPI_SBS=m
CONFIG_SFI=y

#
# CPU Frequency scaling
#
CONFIG_CPU_FREQ=y
CONFIG_CPU_FREQ_TABLE=y
CONFIG_CPU_FREQ_DEBUG=y
# CONFIG_CPU_FREQ_STAT is not set
# CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE is not set
# CONFIG_CPU_FREQ_DEFAULT_GOV_POWERSAVE is not set
CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE=y
# CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND is not set
# CONFIG_CPU_FREQ_DEFAULT_GOV_CONSERVATIVE is not set
# CONFIG_CPU_FREQ_GOV_PERFORMANCE is not set
CONFIG_CPU_FREQ_GOV_POWERSAVE=m
CONFIG_CPU_FREQ_GOV_USERSPACE=y
# CONFIG_CPU_FREQ_GOV_ONDEMAND is not set
# CONFIG_CPU_FREQ_GOV_CONSERVATIVE is not set

#
# CPUFreq processor drivers
#
# CONFIG_X86_ACPI_CPUFREQ is not set
CONFIG_X86_POWERNOW_K6=m
CONFIG_X86_POWERNOW_K7=m
CONFIG_X86_POWERNOW_K7_ACPI=y
# CONFIG_X86_POWERNOW_K8 is not set
CONFIG_X86_GX_SUSPMOD=y
CONFIG_X86_SPEEDSTEP_CENTRINO=y
CONFIG_X86_SPEEDSTEP_CENTRINO_TABLE=y
CONFIG_X86_SPEEDSTEP_ICH=m
# CONFIG_X86_SPEEDSTEP_SMI is not set
CONFIG_X86_P4_CLOCKMOD=y
# CONFIG_X86_CPUFREQ_NFORCE2 is not set
# CONFIG_X86_LONGRUN is not set
# CONFIG_X86_LONGHAUL is not set
# CONFIG_X86_E_POWERSAVER is not set

#
# shared options
#
CONFIG_X86_SPEEDSTEP_LIB=y
CONFIG_X86_SPEEDSTEP_RELAXED_CAP_CHECK=y
CONFIG_CPU_IDLE=y
CONFIG_CPU_IDLE_GOV_LADDER=y

#
# Bus options (PCI etc.)
#
CONFIG_PCI=y
# CONFIG_PCI_GOBIOS is not set
# CONFIG_PCI_GOMMCONFIG is not set
CONFIG_PCI_GODIRECT=y
# CONFIG_PCI_GOOLPC is not set
# CONFIG_PCI_GOANY is not set
CONFIG_PCI_BIOS=y
CONFIG_PCI_DIRECT=y
CONFIG_PCI_DOMAINS=y
CONFIG_PCIEPORTBUS=y
CONFIG_PCIEAER=y
CONFIG_PCIE_ECRC=y
CONFIG_PCIEAER_INJECT=m
CONFIG_PCIEASPM=y
CONFIG_PCIEASPM_DEBUG=y
CONFIG_ARCH_SUPPORTS_MSI=y
# CONFIG_PCI_MSI is not set
CONFIG_PCI_LEGACY=y
# CONFIG_PCI_DEBUG is not set
CONFIG_PCI_STUB=y
# CONFIG_HT_IRQ is not set
CONFIG_PCI_IOV=y
CONFIG_ISA_DMA_API=y
# CONFIG_ISA is not set
# CONFIG_MCA is not set
CONFIG_SCx200=m
# CONFIG_SCx200HR_TIMER is not set
CONFIG_OLPC=y
CONFIG_K8_NB=y
CONFIG_PCCARD=y
# CONFIG_PCMCIA_DEBUG is not set
CONFIG_PCMCIA=m
CONFIG_PCMCIA_LOAD_CIS=y
# CONFIG_PCMCIA_IOCTL is not set
CONFIG_CARDBUS=y

#
# PC-card bridges
#
# CONFIG_YENTA is not set
# CONFIG_PD6729 is not set
CONFIG_I82092=m
CONFIG_PCCARD_NONSTATIC=m
# CONFIG_HOTPLUG_PCI is not set

#
# Executable file formats / Emulations
#
CONFIG_BINFMT_ELF=y
CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS=y
CONFIG_HAVE_AOUT=y
CONFIG_BINFMT_AOUT=y
CONFIG_BINFMT_MISC=y
CONFIG_HAVE_ATOMIC_IOMAP=y
CONFIG_NET=y

#
# Networking options
#
CONFIG_PACKET=y
# CONFIG_PACKET_MMAP is not set
CONFIG_UNIX=y
CONFIG_XFRM=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=y
# CONFIG_NET_KEY is not set
CONFIG_INET=y
CONFIG_IP_MULTICAST=y
CONFIG_IP_ADVANCED_ROUTER=y
CONFIG_ASK_IP_FIB_HASH=y
# CONFIG_IP_FIB_TRIE is not set
CONFIG_IP_FIB_HASH=y
# CONFIG_IP_MULTIPLE_TABLES is not set
CONFIG_IP_ROUTE_MULTIPATH=y
CONFIG_IP_ROUTE_VERBOSE=y
# CONFIG_IP_PNP is not set
CONFIG_NET_IPIP=m
CONFIG_NET_IPGRE=m
# CONFIG_NET_IPGRE_BROADCAST is not set
CONFIG_IP_MROUTE=y
CONFIG_IP_PIMSM_V1=y
CONFIG_IP_PIMSM_V2=y
CONFIG_ARPD=y
# CONFIG_SYN_COOKIES is not set
CONFIG_INET_AH=m
CONFIG_INET_ESP=m
CONFIG_INET_IPCOMP=y
CONFIG_INET_XFRM_TUNNEL=y
CONFIG_INET_TUNNEL=y
# CONFIG_INET_XFRM_MODE_TRANSPORT is not set
# CONFIG_INET_XFRM_MODE_TUNNEL is not set
CONFIG_INET_XFRM_MODE_BEET=m
CONFIG_INET_LRO=y
CONFIG_INET_DIAG=y
CONFIG_INET_TCP_DIAG=y
# CONFIG_TCP_CONG_ADVANCED is not set
CONFIG_TCP_CONG_CUBIC=y
CONFIG_DEFAULT_TCP_CONG="cubic"
CONFIG_TCP_MD5SIG=y
CONFIG_IPV6=m
# CONFIG_IPV6_PRIVACY is not set
# CONFIG_IPV6_ROUTER_PREF is not set
CONFIG_IPV6_OPTIMISTIC_DAD=y
CONFIG_INET6_AH=m
CONFIG_INET6_ESP=m
# CONFIG_INET6_IPCOMP is not set
# CONFIG_IPV6_MIP6 is not set
# CONFIG_INET6_XFRM_TUNNEL is not set
# CONFIG_INET6_TUNNEL is not set
# CONFIG_INET6_XFRM_MODE_TRANSPORT is not set
# CONFIG_INET6_XFRM_MODE_TUNNEL is not set
# CONFIG_INET6_XFRM_MODE_BEET is not set
CONFIG_INET6_XFRM_MODE_ROUTEOPTIMIZATION=m
# CONFIG_IPV6_SIT is not set
# CONFIG_IPV6_TUNNEL is not set
CONFIG_IPV6_MULTIPLE_TABLES=y
CONFIG_IPV6_SUBTREES=y
CONFIG_IPV6_MROUTE=y
# CONFIG_IPV6_PIMSM_V2 is not set
CONFIG_NETLABEL=y
CONFIG_NETWORK_SECMARK=y
CONFIG_NETFILTER=y
# CONFIG_NETFILTER_DEBUG is not set
# CONFIG_NETFILTER_ADVANCED is not set

#
# Core Netfilter Configuration
#
CONFIG_NETFILTER_NETLINK=m
CONFIG_NETFILTER_NETLINK_LOG=m
CONFIG_NF_CONNTRACK=m
CONFIG_NF_CONNTRACK_SECMARK=y
# CONFIG_NF_CONNTRACK_FTP is not set
CONFIG_NF_CONNTRACK_IRC=m
CONFIG_NF_CONNTRACK_SIP=m
# CONFIG_NF_CT_NETLINK is not set
CONFIG_NETFILTER_XTABLES=y
CONFIG_NETFILTER_XT_TARGET_CONNSECMARK=m
CONFIG_NETFILTER_XT_TARGET_MARK=m
# CONFIG_NETFILTER_XT_TARGET_NFLOG is not set
# CONFIG_NETFILTER_XT_TARGET_SECMARK is not set
CONFIG_NETFILTER_XT_TARGET_TCPMSS=m
# CONFIG_NETFILTER_XT_MATCH_CONNTRACK is not set
# CONFIG_NETFILTER_XT_MATCH_MARK is not set
# CONFIG_NETFILTER_XT_MATCH_POLICY is not set
CONFIG_NETFILTER_XT_MATCH_STATE=m
CONFIG_IP_VS=y
CONFIG_IP_VS_DEBUG=y
CONFIG_IP_VS_TAB_BITS=12

#
# IPVS transport protocol load balancing support
#
# CONFIG_IP_VS_PROTO_TCP is not set
CONFIG_IP_VS_PROTO_UDP=y
CONFIG_IP_VS_PROTO_AH_ESP=y
# CONFIG_IP_VS_PROTO_ESP is not set
CONFIG_IP_VS_PROTO_AH=y

#
# IPVS scheduler
#
CONFIG_IP_VS_RR=m
# CONFIG_IP_VS_WRR is not set
# CONFIG_IP_VS_LC is not set
CONFIG_IP_VS_WLC=m
CONFIG_IP_VS_LBLC=y
CONFIG_IP_VS_LBLCR=y
CONFIG_IP_VS_DH=y
CONFIG_IP_VS_SH=m
CONFIG_IP_VS_SED=m
# CONFIG_IP_VS_NQ is not set

#
# IPVS application helper
#

#
# IP: Netfilter Configuration
#
CONFIG_NF_DEFRAG_IPV4=m
CONFIG_NF_CONNTRACK_IPV4=m
CONFIG_NF_CONNTRACK_PROC_COMPAT=y
CONFIG_IP_NF_IPTABLES=y
CONFIG_IP_NF_FILTER=m
# CONFIG_IP_NF_TARGET_REJECT is not set
# CONFIG_IP_NF_TARGET_LOG is not set
# CONFIG_IP_NF_TARGET_ULOG is not set
CONFIG_NF_NAT=m
CONFIG_NF_NAT_NEEDED=y
CONFIG_IP_NF_TARGET_MASQUERADE=m
# CONFIG_NF_NAT_FTP is not set
CONFIG_NF_NAT_IRC=m
# CONFIG_NF_NAT_TFTP is not set
# CONFIG_NF_NAT_AMANDA is not set
# CONFIG_NF_NAT_PPTP is not set
# CONFIG_NF_NAT_H323 is not set
CONFIG_NF_NAT_SIP=m
# CONFIG_IP_NF_MANGLE is not set

#
# IPv6: Netfilter Configuration
#
# CONFIG_NF_CONNTRACK_IPV6 is not set
CONFIG_IP6_NF_IPTABLES=m
# CONFIG_IP6_NF_MATCH_IPV6HEADER is not set
# CONFIG_IP6_NF_TARGET_LOG is not set
# CONFIG_IP6_NF_FILTER is not set
# CONFIG_IP6_NF_MANGLE is not set
CONFIG_IP_DCCP=m
CONFIG_INET_DCCP_DIAG=m

#
# DCCP CCIDs Configuration (EXPERIMENTAL)
#
CONFIG_IP_DCCP_CCID2_DEBUG=y
CONFIG_IP_DCCP_CCID3=y
CONFIG_IP_DCCP_CCID3_DEBUG=y
CONFIG_IP_DCCP_CCID3_RTO=100
CONFIG_IP_DCCP_TFRC_LIB=y
CONFIG_IP_DCCP_TFRC_DEBUG=y

#
# DCCP Kernel Hacking
#
CONFIG_IP_DCCP_DEBUG=y
CONFIG_NET_DCCPPROBE=m
CONFIG_IP_SCTP=m
CONFIG_SCTP_DBG_MSG=y
CONFIG_SCTP_DBG_OBJCNT=y
# CONFIG_SCTP_HMAC_NONE is not set
CONFIG_SCTP_HMAC_SHA1=y
# CONFIG_SCTP_HMAC_MD5 is not set
CONFIG_RDS=m
# CONFIG_RDS_TCP is not set
CONFIG_RDS_DEBUG=y
CONFIG_TIPC=y
CONFIG_TIPC_ADVANCED=y
CONFIG_TIPC_ZONES=3
CONFIG_TIPC_CLUSTERS=1
CONFIG_TIPC_NODES=255
CONFIG_TIPC_SLAVE_NODES=0
CONFIG_TIPC_PORTS=8191
CONFIG_TIPC_LOG=0
# CONFIG_TIPC_DEBUG is not set
# CONFIG_ATM is not set
CONFIG_STP=m
CONFIG_GARP=m
CONFIG_BRIDGE=m
CONFIG_NET_DSA=y
# CONFIG_NET_DSA_TAG_DSA is not set
# CONFIG_NET_DSA_TAG_EDSA is not set
# CONFIG_NET_DSA_TAG_TRAILER is not set
# CONFIG_NET_DSA_MV88E6XXX is not set
# CONFIG_NET_DSA_MV88E6060 is not set
# CONFIG_NET_DSA_MV88E6XXX_NEED_PPU is not set
# CONFIG_NET_DSA_MV88E6131 is not set
# CONFIG_NET_DSA_MV88E6123_61_65 is not set
CONFIG_VLAN_8021Q=m
CONFIG_VLAN_8021Q_GVRP=y
CONFIG_DECNET=m
# CONFIG_DECNET_ROUTER is not set
CONFIG_LLC=y
CONFIG_LLC2=y
# CONFIG_IPX is not set
# CONFIG_ATALK is not set
CONFIG_X25=y
# CONFIG_LAPB is not set
CONFIG_ECONET=y
CONFIG_ECONET_AUNUDP=y
CONFIG_ECONET_NATIVE=y
# CONFIG_WAN_ROUTER is not set
# CONFIG_PHONET is not set
CONFIG_IEEE802154=y
# CONFIG_NET_SCHED is not set
CONFIG_DCB=y

#
# Network testing
#
CONFIG_NET_PKTGEN=m
CONFIG_NET_TCPPROBE=y
# CONFIG_NET_DROP_MONITOR is not set
# CONFIG_HAMRADIO is not set
CONFIG_CAN=y
# CONFIG_CAN_RAW is not set
# CONFIG_CAN_BCM is not set

#
# CAN Device Drivers
#
# CONFIG_CAN_VCAN is not set
CONFIG_CAN_DEV=m
# CONFIG_CAN_CALC_BITTIMING is not set
CONFIG_CAN_SJA1000=m
CONFIG_CAN_SJA1000_PLATFORM=m
CONFIG_CAN_EMS_PCI=m
CONFIG_CAN_KVASER_PCI=m

#
# CAN USB interfaces
#
# CONFIG_CAN_EMS_USB is not set
CONFIG_CAN_DEBUG_DEVICES=y
# CONFIG_IRDA is not set
CONFIG_BT=m
CONFIG_BT_L2CAP=m
CONFIG_BT_SCO=m
CONFIG_BT_RFCOMM=m
# CONFIG_BT_RFCOMM_TTY is not set
CONFIG_BT_BNEP=m
# CONFIG_BT_BNEP_MC_FILTER is not set
CONFIG_BT_BNEP_PROTO_FILTER=y
# CONFIG_BT_CMTP is not set
# CONFIG_BT_HIDP is not set

#
# Bluetooth device drivers
#
# CONFIG_BT_HCIBTUSB is not set
CONFIG_BT_HCIUART=m
CONFIG_BT_HCIUART_H4=y
CONFIG_BT_HCIUART_BCSP=y
CONFIG_BT_HCIUART_LL=y
# CONFIG_BT_HCIBCM203X is not set
CONFIG_BT_HCIBPA10X=m
CONFIG_BT_HCIBFUSB=m
# CONFIG_BT_HCIDTL1 is not set
CONFIG_BT_HCIBT3C=m
CONFIG_BT_HCIBLUECARD=m
CONFIG_BT_HCIBTUART=m
CONFIG_BT_HCIVHCI=m
# CONFIG_BT_MRVL is not set
CONFIG_AF_RXRPC=y
# CONFIG_AF_RXRPC_DEBUG is not set
CONFIG_RXKAD=y
CONFIG_FIB_RULES=y
CONFIG_WIRELESS=y
# CONFIG_CFG80211 is not set
CONFIG_CFG80211_DEFAULT_PS_VALUE=0
CONFIG_WIRELESS_OLD_REGULATORY=y
CONFIG_WIRELESS_EXT=y
CONFIG_WIRELESS_EXT_SYSFS=y
CONFIG_LIB80211=m
CONFIG_LIB80211_DEBUG=y

#
# CFG80211 needs to be enabled for MAC80211
#
CONFIG_WIMAX=m
CONFIG_WIMAX_DEBUG_LEVEL=8
CONFIG_RFKILL=m
CONFIG_RFKILL_LEDS=y
CONFIG_RFKILL_INPUT=y

#
# Device Drivers
#

#
# Generic Driver Options
#
CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug"
# CONFIG_DEVTMPFS is not set
CONFIG_STANDALONE=y
CONFIG_PREVENT_FIRMWARE_BUILD=y
CONFIG_FW_LOADER=y
CONFIG_FIRMWARE_IN_KERNEL=y
CONFIG_EXTRA_FIRMWARE=""
CONFIG_DEBUG_DRIVER=y
CONFIG_DEBUG_DEVRES=y
# CONFIG_SYS_HYPERVISOR is not set
# CONFIG_CONNECTOR is not set
# CONFIG_PARPORT is not set
CONFIG_PNP=y
CONFIG_PNP_DEBUG_MESSAGES=y

#
# Protocols
#
CONFIG_PNPACPI=y
CONFIG_BLK_DEV=y
# CONFIG_BLK_DEV_FD is not set
CONFIG_BLK_CPQ_DA=y
CONFIG_BLK_CPQ_CISS_DA=m
CONFIG_CISS_SCSI_TAPE=y
CONFIG_BLK_DEV_DAC960=m
# CONFIG_BLK_DEV_UMEM is not set
# CONFIG_BLK_DEV_COW_COMMON is not set
# CONFIG_BLK_DEV_LOOP is not set
CONFIG_BLK_DEV_NBD=y
CONFIG_BLK_DEV_SX8=y
CONFIG_BLK_DEV_UB=y
CONFIG_BLK_DEV_RAM=m
CONFIG_BLK_DEV_RAM_COUNT=16
CONFIG_BLK_DEV_RAM_SIZE=4096
# CONFIG_BLK_DEV_XIP is not set
CONFIG_CDROM_PKTCDVD=y
CONFIG_CDROM_PKTCDVD_BUFFERS=8
CONFIG_CDROM_PKTCDVD_WCACHE=y
# CONFIG_ATA_OVER_ETH is not set
# CONFIG_VIRTIO_BLK is not set
CONFIG_BLK_DEV_HD=y
# CONFIG_MISC_DEVICES is not set
CONFIG_TIFM_CORE=m
CONFIG_DELL_LAPTOP=m
CONFIG_HAVE_IDE=y

#
# SCSI device support
#
CONFIG_RAID_ATTRS=m
CONFIG_SCSI=y
CONFIG_SCSI_DMA=y
CONFIG_SCSI_TGT=y
CONFIG_SCSI_NETLINK=y
CONFIG_SCSI_PROC_FS=y

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

#
# SCSI Transports
#
CONFIG_SCSI_SPI_ATTRS=y
CONFIG_SCSI_FC_ATTRS=y
# CONFIG_SCSI_FC_TGT_ATTRS is not set
CONFIG_SCSI_ISCSI_ATTRS=y
CONFIG_SCSI_SAS_ATTRS=m
CONFIG_SCSI_SAS_LIBSAS=m
CONFIG_SCSI_SAS_ATA=y
# CONFIG_SCSI_SAS_HOST_SMP is not set
CONFIG_SCSI_SAS_LIBSAS_DEBUG=y
CONFIG_SCSI_LOWLEVEL=y
CONFIG_ISCSI_TCP=y
CONFIG_SCSI_CXGB3_ISCSI=y
CONFIG_SCSI_BNX2_ISCSI=m
CONFIG_BE2ISCSI=m
# CONFIG_BLK_DEV_3W_XXXX_RAID is not set
CONFIG_SCSI_3W_9XXX=y
CONFIG_SCSI_ACARD=m
# CONFIG_SCSI_AACRAID is not set
CONFIG_SCSI_AIC7XXX=y
CONFIG_AIC7XXX_CMDS_PER_DEVICE=32
CONFIG_AIC7XXX_RESET_DELAY_MS=5000
# CONFIG_AIC7XXX_DEBUG_ENABLE is not set
CONFIG_AIC7XXX_DEBUG_MASK=0
CONFIG_AIC7XXX_REG_PRETTY_PRINT=y
CONFIG_SCSI_AIC7XXX_OLD=m
# CONFIG_SCSI_AIC79XX is not set
# CONFIG_SCSI_AIC94XX is not set
CONFIG_SCSI_MVSAS=m
CONFIG_SCSI_MVSAS_DEBUG=y
CONFIG_SCSI_DPT_I2O=y
CONFIG_SCSI_ADVANSYS=y
# CONFIG_SCSI_ARCMSR is not set
CONFIG_MEGARAID_NEWGEN=y
CONFIG_MEGARAID_MM=y
CONFIG_MEGARAID_MAILBOX=y
# CONFIG_MEGARAID_LEGACY is not set
CONFIG_MEGARAID_SAS=m
# CONFIG_SCSI_MPT2SAS is not set
CONFIG_SCSI_HPTIOP=m
# CONFIG_SCSI_BUSLOGIC is not set
CONFIG_LIBFC=y
CONFIG_LIBFCOE=m
# CONFIG_FCOE is not set
# CONFIG_FCOE_FNIC is not set
CONFIG_SCSI_DMX3191D=y
CONFIG_SCSI_EATA=y
# CONFIG_SCSI_EATA_TAGGED_QUEUE is not set
# CONFIG_SCSI_EATA_LINKED_COMMANDS is not set
CONFIG_SCSI_EATA_MAX_TAGS=16
CONFIG_SCSI_FUTURE_DOMAIN=m
CONFIG_SCSI_GDTH=m
CONFIG_SCSI_IPS=y
# CONFIG_SCSI_INITIO is not set
CONFIG_SCSI_INIA100=y
# CONFIG_SCSI_STEX is not set
# CONFIG_SCSI_SYM53C8XX_2 is not set
CONFIG_SCSI_IPR=m
# CONFIG_SCSI_IPR_TRACE is not set
CONFIG_SCSI_IPR_DUMP=y
CONFIG_SCSI_QLOGIC_1280=y
# CONFIG_SCSI_QLA_FC is not set
CONFIG_SCSI_QLA_ISCSI=y
# CONFIG_SCSI_LPFC is not set
CONFIG_SCSI_DC395x=y
CONFIG_SCSI_DC390T=m
CONFIG_SCSI_NSP32=m
CONFIG_SCSI_PMCRAID=y
CONFIG_SCSI_SRP=y
CONFIG_SCSI_BFA_FC=m
CONFIG_SCSI_LOWLEVEL_PCMCIA=y
CONFIG_PCMCIA_AHA152X=m
CONFIG_PCMCIA_FDOMAIN=m
CONFIG_PCMCIA_NINJA_SCSI=m
# CONFIG_PCMCIA_QLOGIC is not set
CONFIG_PCMCIA_SYM53C500=m
CONFIG_SCSI_DH=m
# CONFIG_SCSI_DH_RDAC is not set
CONFIG_SCSI_DH_HP_SW=m
CONFIG_SCSI_DH_EMC=m
CONFIG_SCSI_DH_ALUA=m
CONFIG_SCSI_OSD_INITIATOR=y
# CONFIG_SCSI_OSD_ULD is not set
CONFIG_SCSI_OSD_DPRINT_SENSE=1
CONFIG_SCSI_OSD_DEBUG=y
CONFIG_ATA=y
# CONFIG_ATA_NONSTANDARD is not set
CONFIG_ATA_VERBOSE_ERROR=y
CONFIG_ATA_ACPI=y
# CONFIG_SATA_PMP is not set
CONFIG_SATA_AHCI=y
# CONFIG_SATA_SIL24 is not set
CONFIG_ATA_SFF=y
CONFIG_SATA_SVW=m
CONFIG_ATA_PIIX=y
# CONFIG_SATA_MV is not set
CONFIG_SATA_NV=y
CONFIG_PDC_ADMA=y
CONFIG_SATA_QSTOR=y
CONFIG_SATA_PROMISE=m
# CONFIG_SATA_SX4 is not set
# CONFIG_SATA_SIL is not set
CONFIG_SATA_SIS=m
CONFIG_SATA_ULI=m
CONFIG_SATA_VIA=y
# CONFIG_SATA_VITESSE is not set
CONFIG_SATA_INIC162X=m
# CONFIG_PATA_ACPI is not set
CONFIG_PATA_ALI=m
CONFIG_PATA_AMD=y
# CONFIG_PATA_ARTOP is not set
CONFIG_PATA_ATP867X=y
CONFIG_PATA_ATIIXP=m
CONFIG_PATA_CMD640_PCI=m
CONFIG_PATA_CMD64X=y
# CONFIG_PATA_CS5520 is not set
CONFIG_PATA_CS5530=m
CONFIG_PATA_CS5535=y
CONFIG_PATA_CS5536=m
# CONFIG_PATA_CYPRESS is not set
CONFIG_PATA_EFAR=y
CONFIG_ATA_GENERIC=m
CONFIG_PATA_HPT366=y
CONFIG_PATA_HPT37X=y
CONFIG_PATA_HPT3X2N=m
# CONFIG_PATA_HPT3X3 is not set
CONFIG_PATA_IT821X=m
# CONFIG_PATA_IT8213 is not set
# CONFIG_PATA_JMICRON is not set
CONFIG_PATA_TRIFLEX=y
CONFIG_PATA_MARVELL=y
# CONFIG_PATA_MPIIX is not set
CONFIG_PATA_OLDPIIX=y
CONFIG_PATA_NETCELL=y
# CONFIG_PATA_NINJA32 is not set
CONFIG_PATA_NS87410=y
CONFIG_PATA_NS87415=m
CONFIG_PATA_OPTI=y
CONFIG_PATA_OPTIDMA=m
CONFIG_PATA_PCMCIA=m
# CONFIG_PATA_PDC_OLD is not set
CONFIG_PATA_RADISYS=y
CONFIG_PATA_RDC=m
# CONFIG_PATA_RZ1000 is not set
# CONFIG_PATA_SC1200 is not set
# CONFIG_PATA_SERVERWORKS is not set
CONFIG_PATA_PDC2027X=y
CONFIG_PATA_SIL680=m
CONFIG_PATA_SIS=m
# CONFIG_PATA_VIA is not set
CONFIG_PATA_WINBOND=m
CONFIG_PATA_PLATFORM=m
# CONFIG_PATA_SCH is not set
CONFIG_MD=y
CONFIG_BLK_DEV_MD=m
CONFIG_MD_LINEAR=m
CONFIG_MD_RAID0=m
CONFIG_MD_RAID1=m
# CONFIG_MD_RAID10 is not set
CONFIG_MD_RAID456=m
CONFIG_MULTICORE_RAID456=y
CONFIG_MD_RAID6_PQ=m
CONFIG_ASYNC_RAID6_TEST=m
CONFIG_MD_MULTIPATH=m
CONFIG_MD_FAULTY=m
# CONFIG_BLK_DEV_DM is not set
# CONFIG_FUSION is not set

#
# IEEE 1394 (FireWire) support
#

#
# You can enable one or both FireWire driver stacks.
#

#
# See the help texts for more information.
#
# CONFIG_FIREWIRE is not set
# CONFIG_IEEE1394 is not set
# CONFIG_I2O is not set
CONFIG_MACINTOSH_DRIVERS=y
CONFIG_MAC_EMUMOUSEBTN=y
CONFIG_NETDEVICES=y
# CONFIG_DUMMY is not set
CONFIG_BONDING=m
CONFIG_MACVLAN=m
CONFIG_EQUALIZER=y
CONFIG_TUN=y
# CONFIG_VETH is not set
CONFIG_NET_SB1000=y
CONFIG_ARCNET=m
CONFIG_ARCNET_1201=m
CONFIG_ARCNET_1051=m
CONFIG_ARCNET_RAW=m
CONFIG_ARCNET_CAP=m
CONFIG_ARCNET_COM90xx=m
CONFIG_ARCNET_COM90xxIO=m
# CONFIG_ARCNET_RIM_I is not set
# CONFIG_ARCNET_COM20020 is not set
CONFIG_PHYLIB=y

#
# MII PHY device drivers
#
CONFIG_MARVELL_PHY=m
CONFIG_DAVICOM_PHY=m
CONFIG_QSEMI_PHY=m
# CONFIG_LXT_PHY is not set
CONFIG_CICADA_PHY=y
# CONFIG_VITESSE_PHY is not set
CONFIG_SMSC_PHY=y
CONFIG_BROADCOM_PHY=y
CONFIG_ICPLUS_PHY=y
CONFIG_REALTEK_PHY=y
CONFIG_NATIONAL_PHY=y
CONFIG_STE10XP=y
CONFIG_LSI_ET1011C_PHY=m
CONFIG_FIXED_PHY=y
# CONFIG_MDIO_BITBANG is not set
CONFIG_NET_ETHERNET=y
CONFIG_MII=y
CONFIG_HAPPYMEAL=m
CONFIG_SUNGEM=m
CONFIG_CASSINI=m
# CONFIG_NET_VENDOR_3COM is not set
CONFIG_VORTEX=y
CONFIG_ETHOC=m
CONFIG_DNET=m
CONFIG_NET_TULIP=y
# CONFIG_DE2104X is not set
CONFIG_TULIP=m
CONFIG_TULIP_MWI=y
CONFIG_TULIP_MMIO=y
CONFIG_TULIP_NAPI=y
# CONFIG_TULIP_NAPI_HW_MITIGATION is not set
CONFIG_DE4X5=y
# CONFIG_WINBOND_840 is not set
CONFIG_DM9102=y
CONFIG_ULI526X=y
CONFIG_PCMCIA_XIRCOM=m
CONFIG_HP100=y
# CONFIG_IBM_NEW_EMAC_ZMII is not set
# CONFIG_IBM_NEW_EMAC_RGMII is not set
# CONFIG_IBM_NEW_EMAC_TAH is not set
# CONFIG_IBM_NEW_EMAC_EMAC4 is not set
# CONFIG_IBM_NEW_EMAC_NO_FLOW_CTRL is not set
# CONFIG_IBM_NEW_EMAC_MAL_CLR_ICINTSTAT is not set
# CONFIG_IBM_NEW_EMAC_MAL_COMMON_ERR is not set
CONFIG_NET_PCI=y
# CONFIG_PCNET32 is not set
CONFIG_AMD8111_ETH=y
CONFIG_ADAPTEC_STARFIRE=y
CONFIG_B44=y
CONFIG_B44_PCI_AUTOSELECT=y
CONFIG_B44_PCICORE_AUTOSELECT=y
CONFIG_B44_PCI=y
CONFIG_FORCEDETH=y
# CONFIG_FORCEDETH_NAPI is not set
CONFIG_E100=y
# CONFIG_FEALNX is not set
CONFIG_NATSEMI=m
CONFIG_NE2K_PCI=y
CONFIG_8139CP=y
CONFIG_8139TOO=y
CONFIG_8139TOO_PIO=y
CONFIG_8139TOO_TUNE_TWISTER=y
CONFIG_8139TOO_8129=y
# CONFIG_8139_OLD_RX_RESET is not set
CONFIG_R6040=y
CONFIG_SIS900=m
CONFIG_EPIC100=y
CONFIG_SMSC9420=y
# CONFIG_SUNDANCE is not set
CONFIG_TLAN=m
CONFIG_KS8842=y
# CONFIG_KS8851_MLL is not set
CONFIG_VIA_RHINE=y
CONFIG_VIA_RHINE_MMIO=y
CONFIG_SC92031=m
# CONFIG_ATL2 is not set
CONFIG_NETDEV_1000=y
# CONFIG_ACENIC is not set
CONFIG_DL2K=m
CONFIG_E1000=y
CONFIG_E1000E=y
# CONFIG_IP1000 is not set
CONFIG_IGB=y
CONFIG_IGBVF=y
CONFIG_NS83820=y
CONFIG_HAMACHI=y
CONFIG_YELLOWFIN=m
CONFIG_R8169=y
CONFIG_R8169_VLAN=y
CONFIG_SIS190=y
CONFIG_SKGE=m
# CONFIG_SKGE_DEBUG is not set
CONFIG_SKY2=y
CONFIG_SKY2_DEBUG=y
CONFIG_VIA_VELOCITY=y
CONFIG_TIGON3=y
CONFIG_BNX2=m
CONFIG_CNIC=m
CONFIG_QLA3XXX=m
# CONFIG_ATL1 is not set
# CONFIG_ATL1E is not set
CONFIG_ATL1C=m
# CONFIG_JME is not set
CONFIG_NETDEV_10000=y
CONFIG_MDIO=y
CONFIG_CHELSIO_T1=y
CONFIG_CHELSIO_T1_1G=y
CONFIG_CHELSIO_T3_DEPENDS=y
CONFIG_CHELSIO_T3=y
# CONFIG_ENIC is not set
# CONFIG_IXGBE is not set
CONFIG_IXGB=m
CONFIG_S2IO=y
# CONFIG_MYRI10GE is not set
CONFIG_NIU=m
CONFIG_MLX4_EN=y
CONFIG_MLX4_CORE=y
CONFIG_MLX4_DEBUG=y
CONFIG_TEHUTI=y
CONFIG_BNX2X=y
CONFIG_QLGE=y
# CONFIG_SFC is not set
CONFIG_BE2NET=y
CONFIG_TR=y
CONFIG_IBMOL=y
# CONFIG_IBMLS is not set
CONFIG_3C359=y
# CONFIG_TMS380TR is not set
CONFIG_WLAN=y
# CONFIG_WLAN_PRE80211 is not set
# CONFIG_WLAN_80211 is not set

#
# WiMAX Wireless Broadband devices
#

#
# Enable MMC support to see WiMAX SDIO drivers
#

#
# USB Network Adapters
#
# CONFIG_USB_CATC is not set
# CONFIG_USB_KAWETH is not set
CONFIG_USB_PEGASUS=m
CONFIG_USB_RTL8150=y
# CONFIG_USB_USBNET is not set
CONFIG_USB_HSO=m
# CONFIG_NET_PCMCIA is not set
CONFIG_WAN=y
CONFIG_LANMEDIA=m
CONFIG_HDLC=y
CONFIG_HDLC_RAW=y
CONFIG_HDLC_RAW_ETH=y
# CONFIG_HDLC_CISCO is not set
CONFIG_HDLC_FR=m
CONFIG_HDLC_PPP=m

#
# X.25/LAPB support is disabled
#
CONFIG_PCI200SYN=y
# CONFIG_WANXL is not set
CONFIG_PC300TOO=m
CONFIG_FARSYNC=y
CONFIG_DSCC4=m
CONFIG_DSCC4_PCISYNC=y
# CONFIG_DSCC4_PCI_RST is not set
CONFIG_DLCI=m
CONFIG_DLCI_MAX=8
CONFIG_SBNI=m
# CONFIG_SBNI_MULTILINE is not set
CONFIG_IEEE802154_DRIVERS=y
CONFIG_IEEE802154_FAKEHARD=m
CONFIG_FDDI=y
CONFIG_DEFXX=m
# CONFIG_DEFXX_MMIO is not set
CONFIG_SKFP=y
CONFIG_HIPPI=y
CONFIG_ROADRUNNER=y
CONFIG_ROADRUNNER_LARGE_RINGS=y
CONFIG_PPP=m
CONFIG_PPP_MULTILINK=y
CONFIG_PPP_FILTER=y
CONFIG_PPP_ASYNC=m
CONFIG_PPP_SYNC_TTY=m
# CONFIG_PPP_DEFLATE is not set
# CONFIG_PPP_BSDCOMP is not set
CONFIG_PPP_MPPE=m
CONFIG_PPPOE=m
# CONFIG_PPPOL2TP is not set
CONFIG_SLIP=y
# CONFIG_SLIP_COMPRESSED is not set
CONFIG_SLHC=m
CONFIG_SLIP_SMART=y
# CONFIG_SLIP_MODE_SLIP6 is not set
# CONFIG_NET_FC is not set
CONFIG_NETCONSOLE=y
CONFIG_NETCONSOLE_DYNAMIC=y
CONFIG_NETPOLL=y
CONFIG_NETPOLL_TRAP=y
CONFIG_NET_POLL_CONTROLLER=y
# CONFIG_VIRTIO_NET is not set
CONFIG_VMXNET3=m
CONFIG_ISDN=y
# CONFIG_ISDN_I4L is not set
CONFIG_ISDN_CAPI=m
CONFIG_ISDN_DRV_AVMB1_VERBOSE_REASON=y
CONFIG_CAPI_TRACE=y
CONFIG_ISDN_CAPI_MIDDLEWARE=y
CONFIG_ISDN_CAPI_CAPI20=m
# CONFIG_ISDN_CAPI_CAPIFS_BOOL is not set

#
# CAPI hardware drivers
#
CONFIG_CAPI_AVM=y
# CONFIG_ISDN_DRV_AVMB1_B1PCI is not set
CONFIG_ISDN_DRV_AVMB1_B1PCMCIA=m
CONFIG_ISDN_DRV_AVMB1_AVM_CS=m
CONFIG_ISDN_DRV_AVMB1_T1PCI=m
CONFIG_ISDN_DRV_AVMB1_C4=m
CONFIG_CAPI_EICON=y
CONFIG_ISDN_DIVAS=m
# CONFIG_ISDN_DIVAS_BRIPCI is not set
CONFIG_ISDN_DIVAS_PRIPCI=y
CONFIG_ISDN_DIVAS_DIVACAPI=m
# CONFIG_ISDN_DIVAS_USERIDI is not set
CONFIG_ISDN_DIVAS_MAINT=m
CONFIG_PHONE=y
CONFIG_PHONE_IXJ=m
CONFIG_PHONE_IXJ_PCMCIA=m

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

#
# 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=y
# CONFIG_INPUT_EVDEV is not set
# CONFIG_INPUT_EVBUG is not set

#
# Input Device Drivers
#
CONFIG_INPUT_KEYBOARD=y
CONFIG_KEYBOARD_ADP5588=y
CONFIG_KEYBOARD_ATKBD=y
CONFIG_QT2160=m
# CONFIG_KEYBOARD_LKKBD is not set
CONFIG_KEYBOARD_LM8323=m
CONFIG_KEYBOARD_MAX7359=m
# CONFIG_KEYBOARD_NEWTON is not set
CONFIG_KEYBOARD_OPENCORES=m
# CONFIG_KEYBOARD_STOWAWAY is not set
CONFIG_KEYBOARD_SUNKBD=m
# CONFIG_KEYBOARD_TWL4030 is not set
CONFIG_KEYBOARD_XTKBD=m
# CONFIG_INPUT_MOUSE is not set
CONFIG_INPUT_JOYSTICK=y
CONFIG_JOYSTICK_ANALOG=m
# CONFIG_JOYSTICK_A3D is not set
# CONFIG_JOYSTICK_ADI is not set
CONFIG_JOYSTICK_COBRA=m
# CONFIG_JOYSTICK_GF2K is not set
CONFIG_JOYSTICK_GRIP=y
CONFIG_JOYSTICK_GRIP_MP=y
CONFIG_JOYSTICK_GUILLEMOT=y
# CONFIG_JOYSTICK_INTERACT is not set
CONFIG_JOYSTICK_SIDEWINDER=m
CONFIG_JOYSTICK_TMDC=y
CONFIG_JOYSTICK_IFORCE=m
# CONFIG_JOYSTICK_IFORCE_USB is not set
CONFIG_JOYSTICK_IFORCE_232=y
CONFIG_JOYSTICK_WARRIOR=y
CONFIG_JOYSTICK_MAGELLAN=m
CONFIG_JOYSTICK_SPACEORB=y
CONFIG_JOYSTICK_SPACEBALL=y
CONFIG_JOYSTICK_STINGER=m
# CONFIG_JOYSTICK_TWIDJOY is not set
CONFIG_JOYSTICK_ZHENHUA=m
# CONFIG_JOYSTICK_JOYDUMP is not set
# CONFIG_JOYSTICK_XPAD is not set
CONFIG_INPUT_TABLET=y
# CONFIG_TABLET_USB_ACECAD is not set
CONFIG_TABLET_USB_AIPTEK=m
CONFIG_TABLET_USB_GTCO=m
# CONFIG_TABLET_USB_KBTAB is not set
CONFIG_TABLET_USB_WACOM=m
CONFIG_INPUT_TOUCHSCREEN=y
# CONFIG_TOUCHSCREEN_AD7879_I2C is not set
# CONFIG_TOUCHSCREEN_AD7879 is not set
CONFIG_TOUCHSCREEN_DA9034=m
CONFIG_TOUCHSCREEN_EETI=y
CONFIG_TOUCHSCREEN_FUJITSU=y
CONFIG_TOUCHSCREEN_GUNZE=y
CONFIG_TOUCHSCREEN_ELO=m
# CONFIG_TOUCHSCREEN_WACOM_W8001 is not set
# CONFIG_TOUCHSCREEN_MCS5000 is not set
# CONFIG_TOUCHSCREEN_MTOUCH is not set
CONFIG_TOUCHSCREEN_INEXIO=y
CONFIG_TOUCHSCREEN_MK712=y
# CONFIG_TOUCHSCREEN_PENMOUNT is not set
CONFIG_TOUCHSCREEN_TOUCHRIGHT=y
CONFIG_TOUCHSCREEN_TOUCHWIN=m
CONFIG_TOUCHSCREEN_USB_COMPOSITE=y
CONFIG_TOUCHSCREEN_USB_EGALAX=y
CONFIG_TOUCHSCREEN_USB_PANJIT=y
# CONFIG_TOUCHSCREEN_USB_3M is not set
# CONFIG_TOUCHSCREEN_USB_ITM is not set
CONFIG_TOUCHSCREEN_USB_ETURBO=y
CONFIG_TOUCHSCREEN_USB_GUNZE=y
CONFIG_TOUCHSCREEN_USB_DMC_TSC10=y
CONFIG_TOUCHSCREEN_USB_IRTOUCH=y
CONFIG_TOUCHSCREEN_USB_IDEALTEK=y
CONFIG_TOUCHSCREEN_USB_GENERAL_TOUCH=y
# CONFIG_TOUCHSCREEN_USB_GOTOP is not set
# CONFIG_TOUCHSCREEN_USB_JASTEC is not set
CONFIG_TOUCHSCREEN_USB_E2I=y
CONFIG_TOUCHSCREEN_TOUCHIT213=y
CONFIG_TOUCHSCREEN_TSC2007=y
CONFIG_INPUT_MISC=y
# CONFIG_INPUT_PCSPKR is not set
# CONFIG_INPUT_APANEL is not set
# CONFIG_INPUT_WISTRON_BTNS is not set
CONFIG_INPUT_ATLAS_BTNS=m
CONFIG_INPUT_ATI_REMOTE=y
CONFIG_INPUT_ATI_REMOTE2=y
CONFIG_INPUT_KEYSPAN_REMOTE=m
# CONFIG_INPUT_POWERMATE is not set
CONFIG_INPUT_YEALINK=m
CONFIG_INPUT_CM109=y
CONFIG_INPUT_TWL4030_PWRBUTTON=y
CONFIG_INPUT_UINPUT=y
# CONFIG_INPUT_WINBOND_CIR is not set
CONFIG_INPUT_PCF50633_PMU=m
# CONFIG_INPUT_WM831X_ON is not set

#
# Hardware I/O ports
#
CONFIG_SERIO=y
CONFIG_SERIO_I8042=y
CONFIG_SERIO_SERPORT=y
CONFIG_SERIO_CT82C710=y
# CONFIG_SERIO_PCIPS2 is not set
CONFIG_SERIO_LIBPS2=y
CONFIG_SERIO_RAW=y
CONFIG_GAMEPORT=y
CONFIG_GAMEPORT_NS558=m
CONFIG_GAMEPORT_L4=y
# CONFIG_GAMEPORT_EMU10K1 is not set
# CONFIG_GAMEPORT_FM801 is not set

#
# Character devices
#
CONFIG_VT=y
CONFIG_CONSOLE_TRANSLATIONS=y
CONFIG_VT_CONSOLE=y
CONFIG_HW_CONSOLE=y
CONFIG_VT_HW_CONSOLE_BINDING=y
CONFIG_DEVKMEM=y
CONFIG_SERIAL_NONSTANDARD=y
CONFIG_COMPUTONE=y
# CONFIG_ROCKETPORT is not set
CONFIG_CYCLADES=m
CONFIG_CYZ_INTR=y
CONFIG_DIGIEPCA=m
CONFIG_MOXA_INTELLIO=y
CONFIG_MOXA_SMARTIO=m
CONFIG_ISI=y
CONFIG_SYNCLINK=m
CONFIG_SYNCLINKMP=y
CONFIG_SYNCLINK_GT=m
# CONFIG_N_HDLC is not set
CONFIG_RISCOM8=m
# CONFIG_SPECIALIX is not set
CONFIG_STALDRV=y
CONFIG_STALLION=y
# CONFIG_ISTALLION is not set
# CONFIG_NOZOMI is not set

#
# Serial drivers
#
CONFIG_SERIAL_8250=y
CONFIG_SERIAL_8250_CONSOLE=y
CONFIG_FIX_EARLYCON_MEM=y
CONFIG_SERIAL_8250_PCI=y
CONFIG_SERIAL_8250_PNP=y
CONFIG_SERIAL_8250_CS=m
CONFIG_SERIAL_8250_NR_UARTS=4
CONFIG_SERIAL_8250_RUNTIME_UARTS=4
# CONFIG_SERIAL_8250_EXTENDED is not set

#
# Non-8250 serial port support
#
CONFIG_SERIAL_CORE=y
CONFIG_SERIAL_CORE_CONSOLE=y
CONFIG_SERIAL_JSM=y
CONFIG_UNIX98_PTYS=y
CONFIG_DEVPTS_MULTIPLE_INSTANCES=y
# CONFIG_LEGACY_PTYS is not set
CONFIG_HVC_DRIVER=y
CONFIG_VIRTIO_CONSOLE=y
CONFIG_IPMI_HANDLER=m
# CONFIG_IPMI_PANIC_EVENT is not set
CONFIG_IPMI_DEVICE_INTERFACE=m
CONFIG_IPMI_SI=m
CONFIG_IPMI_WATCHDOG=m
CONFIG_IPMI_POWEROFF=m
CONFIG_HW_RANDOM=m
CONFIG_HW_RANDOM_TIMERIOMEM=m
CONFIG_HW_RANDOM_INTEL=m
# CONFIG_HW_RANDOM_AMD is not set
CONFIG_HW_RANDOM_GEODE=m
CONFIG_HW_RANDOM_VIA=m
CONFIG_HW_RANDOM_VIRTIO=m
CONFIG_NVRAM=m
CONFIG_RTC=m
CONFIG_GEN_RTC=m
CONFIG_GEN_RTC_X=y
CONFIG_R3964=y
CONFIG_APPLICOM=y
CONFIG_SONYPI=m

#
# PCMCIA character devices
#
CONFIG_SYNCLINK_CS=m
CONFIG_CARDMAN_4000=m
CONFIG_CARDMAN_4040=m
CONFIG_IPWIRELESS=m
CONFIG_MWAVE=y
# CONFIG_SCx200_GPIO is not set
CONFIG_PC8736x_GPIO=y
CONFIG_NSC_GPIO=y
CONFIG_CS5535_GPIO=y
# CONFIG_RAW_DRIVER is not set
CONFIG_HPET=y
# CONFIG_HPET_MMAP is not set
CONFIG_HANGCHECK_TIMER=m
CONFIG_TCG_TPM=y
CONFIG_TCG_TIS=y
CONFIG_TCG_NSC=m
CONFIG_TCG_ATMEL=m
# CONFIG_TCG_INFINEON is not set
# CONFIG_TELCLOCK is not set
CONFIG_DEVPORT=y
CONFIG_I2C=y
CONFIG_I2C_BOARDINFO=y
CONFIG_I2C_COMPAT=y
# CONFIG_I2C_CHARDEV is not set
CONFIG_I2C_HELPER_AUTO=y
CONFIG_I2C_ALGOBIT=y
CONFIG_I2C_ALGOPCA=y

#
# I2C Hardware Bus support
#

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

#
# ACPI drivers
#
# CONFIG_I2C_SCMI is not set

#
# I2C system bus drivers (mostly embedded / system-on-chip)
#
# CONFIG_I2C_OCORES is not set
CONFIG_I2C_SIMTEC=m

#
# External I2C/SMBus adapter drivers
#
CONFIG_I2C_PARPORT_LIGHT=m
CONFIG_I2C_TAOS_EVM=y
CONFIG_I2C_TINY_USB=m

#
# Graphics adapter I2C/DDC channel drivers
#
# CONFIG_I2C_VOODOO3 is not set

#
# Other I2C/SMBus bus drivers
#
CONFIG_I2C_PCA_PLATFORM=y
# CONFIG_I2C_STUB is not set
# CONFIG_SCx200_ACB is not set

#
# Miscellaneous I2C Chip support
#
# CONFIG_DS1682 is not set
CONFIG_SENSORS_TSL2550=y
CONFIG_I2C_DEBUG_CORE=y
# CONFIG_I2C_DEBUG_ALGO is not set
# CONFIG_I2C_DEBUG_BUS is not set
CONFIG_I2C_DEBUG_CHIP=y
# CONFIG_SPI is not set

#
# PPS support
#
CONFIG_PPS=m
CONFIG_PPS_DEBUG=y
CONFIG_ARCH_WANT_OPTIONAL_GPIOLIB=y
# CONFIG_GPIOLIB is not set
CONFIG_W1=m

#
# 1-wire Bus Masters
#
# CONFIG_W1_MASTER_MATROX is not set
CONFIG_W1_MASTER_DS2490=m
CONFIG_W1_MASTER_DS2482=m

#
# 1-wire Slaves
#
# CONFIG_W1_SLAVE_THERM is not set
CONFIG_W1_SLAVE_SMEM=m
# CONFIG_W1_SLAVE_DS2431 is not set
CONFIG_W1_SLAVE_DS2433=m
CONFIG_W1_SLAVE_DS2433_CRC=y
# CONFIG_W1_SLAVE_DS2760 is not set
# CONFIG_W1_SLAVE_BQ27000 is not set
CONFIG_POWER_SUPPLY=m
CONFIG_POWER_SUPPLY_DEBUG=y
CONFIG_PDA_POWER=m
# CONFIG_WM831X_POWER is not set
# CONFIG_BATTERY_DS2760 is not set
CONFIG_BATTERY_DS2782=m
CONFIG_BATTERY_OLPC=m
CONFIG_BATTERY_BQ27x00=m
# CONFIG_BATTERY_DA9030 is not set
CONFIG_BATTERY_MAX17040=m
CONFIG_CHARGER_PCF50633=m
CONFIG_HWMON=m
CONFIG_HWMON_VID=m
CONFIG_HWMON_DEBUG_CHIP=y

#
# Native drivers
#
# CONFIG_SENSORS_ABITUGURU is not set
# CONFIG_SENSORS_ABITUGURU3 is not set
CONFIG_SENSORS_AD7414=m
CONFIG_SENSORS_AD7418=m
CONFIG_SENSORS_ADM1021=m
CONFIG_SENSORS_ADM1025=m
# CONFIG_SENSORS_ADM1026 is not set
CONFIG_SENSORS_ADM1029=m
CONFIG_SENSORS_ADM1031=m
CONFIG_SENSORS_ADM9240=m
CONFIG_SENSORS_ADT7462=m
# CONFIG_SENSORS_ADT7470 is not set
CONFIG_SENSORS_ADT7473=m
CONFIG_SENSORS_ADT7475=m
CONFIG_SENSORS_K8TEMP=m
CONFIG_SENSORS_ASB100=m
CONFIG_SENSORS_ATXP1=m
# CONFIG_SENSORS_DS1621 is not set
# CONFIG_SENSORS_I5K_AMB is not set
CONFIG_SENSORS_F71805F=m
# CONFIG_SENSORS_F71882FG is not set
CONFIG_SENSORS_F75375S=m
# CONFIG_SENSORS_FSCHMD is not set
# CONFIG_SENSORS_G760A is not set
CONFIG_SENSORS_GL518SM=m
CONFIG_SENSORS_GL520SM=m
CONFIG_SENSORS_CORETEMP=m
# CONFIG_SENSORS_IBMAEM is not set
# CONFIG_SENSORS_IBMPEX is not set
# CONFIG_SENSORS_IT87 is not set
CONFIG_SENSORS_LM63=m
CONFIG_SENSORS_LM75=m
# CONFIG_SENSORS_LM77 is not set
CONFIG_SENSORS_LM78=m
CONFIG_SENSORS_LM80=m
CONFIG_SENSORS_LM83=m
CONFIG_SENSORS_LM85=m
CONFIG_SENSORS_LM87=m
CONFIG_SENSORS_LTC4215=m
CONFIG_SENSORS_LTC4245=m
CONFIG_SENSORS_LM95241=m
# CONFIG_SENSORS_MAX1619 is not set
CONFIG_SENSORS_MAX6650=m
CONFIG_SENSORS_PC87360=m
CONFIG_SENSORS_PC87427=m
# CONFIG_SENSORS_PCF8591 is not set
# CONFIG_SENSORS_SIS5595 is not set
# CONFIG_SENSORS_DME1737 is not set
# CONFIG_SENSORS_SMSC47M1 is not set
# CONFIG_SENSORS_SMSC47M192 is not set
# CONFIG_SENSORS_SMSC47B397 is not set
CONFIG_SENSORS_ADS7828=m
CONFIG_SENSORS_THMC50=m
CONFIG_SENSORS_TMP401=m
# CONFIG_SENSORS_TMP421 is not set
CONFIG_SENSORS_VIA686A=m
# CONFIG_SENSORS_VT1211 is not set
CONFIG_SENSORS_VT8231=m
# CONFIG_SENSORS_W83781D is not set
CONFIG_SENSORS_W83791D=m
# CONFIG_SENSORS_W83792D is not set
CONFIG_SENSORS_W83793=m
CONFIG_SENSORS_W83L785TS=m
CONFIG_SENSORS_W83L786NG=m
# CONFIG_SENSORS_W83627HF is not set
CONFIG_SENSORS_W83627EHF=m
CONFIG_SENSORS_WM831X=m
CONFIG_SENSORS_HDAPS=m
# CONFIG_SENSORS_APPLESMC is not set

#
# ACPI drivers
#
CONFIG_SENSORS_ATK0110=m
CONFIG_SENSORS_LIS3LV02D=m
CONFIG_THERMAL=y
CONFIG_WATCHDOG=y
CONFIG_WATCHDOG_NOWAYOUT=y

#
# Watchdog Device Drivers
#
CONFIG_SOFT_WATCHDOG=y
CONFIG_WM831X_WATCHDOG=y
# CONFIG_TWL4030_WATCHDOG is not set
CONFIG_ACQUIRE_WDT=y
CONFIG_ADVANTECH_WDT=y
CONFIG_ALIM1535_WDT=y
CONFIG_ALIM7101_WDT=m
CONFIG_SC520_WDT=m
CONFIG_IB700_WDT=m
# CONFIG_IBMASR is not set
CONFIG_WAFER_WDT=y
# CONFIG_I6300ESB_WDT is not set
CONFIG_ITCO_WDT=y
CONFIG_ITCO_VENDOR_SUPPORT=y
CONFIG_IT8712F_WDT=m
# CONFIG_IT87_WDT is not set
CONFIG_HP_WATCHDOG=y
CONFIG_SC1200_WDT=y
# CONFIG_SCx200_WDT is not set
CONFIG_PC87413_WDT=y
CONFIG_60XX_WDT=y
# CONFIG_SBC8360_WDT is not set
CONFIG_SBC7240_WDT=y
CONFIG_CPU5_WDT=y
CONFIG_SMSC_SCH311X_WDT=m
# CONFIG_SMSC37B787_WDT is not set
# CONFIG_W83627HF_WDT is not set
CONFIG_W83877F_WDT=m
CONFIG_W83977F_WDT=m
# CONFIG_MACHZ_WDT is not set
CONFIG_SBC_EPX_C3_WATCHDOG=y

#
# PCI-based Watchdog Cards
#
# CONFIG_PCIPCWATCHDOG is not set
CONFIG_WDTPCI=y

#
# USB-based Watchdog Cards
#
CONFIG_USBPCWATCHDOG=m
CONFIG_SSB_POSSIBLE=y

#
# Sonics Silicon Backplane
#
CONFIG_SSB=y
CONFIG_SSB_SPROM=y
CONFIG_SSB_PCIHOST_POSSIBLE=y
CONFIG_SSB_PCIHOST=y
# CONFIG_SSB_B43_PCI_BRIDGE is not set
CONFIG_SSB_SILENT=y
CONFIG_SSB_DRIVER_PCICORE_POSSIBLE=y
CONFIG_SSB_DRIVER_PCICORE=y

#
# Multifunction device drivers
#
CONFIG_MFD_CORE=y
CONFIG_MFD_SM501=y
# CONFIG_HTC_PASIC3 is not set
CONFIG_TWL4030_CORE=y
# CONFIG_MFD_TMIO is not set
CONFIG_PMIC_DA903X=y
CONFIG_MFD_WM8400=m
CONFIG_MFD_WM831X=y
CONFIG_MFD_PCF50633=m
CONFIG_PCF50633_ADC=m
CONFIG_PCF50633_GPIO=m
# CONFIG_AB3100_CORE is not set
CONFIG_REGULATOR=y
CONFIG_REGULATOR_DEBUG=y
# CONFIG_REGULATOR_FIXED_VOLTAGE is not set
CONFIG_REGULATOR_VIRTUAL_CONSUMER=y
# CONFIG_REGULATOR_USERSPACE_CONSUMER is not set
CONFIG_REGULATOR_BQ24022=y
CONFIG_REGULATOR_MAX1586=m
CONFIG_REGULATOR_TWL4030=y
# CONFIG_REGULATOR_WM831X is not set
# CONFIG_REGULATOR_WM8400 is not set
CONFIG_REGULATOR_DA903X=m
CONFIG_REGULATOR_PCF50633=m
# CONFIG_REGULATOR_LP3971 is not set
CONFIG_REGULATOR_TPS65023=y
# CONFIG_REGULATOR_TPS6507X is not set
CONFIG_MEDIA_SUPPORT=m

#
# Multimedia core support
#
# CONFIG_VIDEO_DEV is not set
CONFIG_DVB_CORE=m
CONFIG_VIDEO_MEDIA=m

#
# Multimedia drivers
#
CONFIG_VIDEO_SAA7146=m
CONFIG_MEDIA_ATTACH=y
CONFIG_MEDIA_TUNER=m
# CONFIG_MEDIA_TUNER_CUSTOMISE is not set
CONFIG_MEDIA_TUNER_SIMPLE=m
CONFIG_MEDIA_TUNER_TDA8290=m
CONFIG_MEDIA_TUNER_TDA9887=m
CONFIG_MEDIA_TUNER_TEA5761=m
CONFIG_MEDIA_TUNER_TEA5767=m
CONFIG_MEDIA_TUNER_MT20XX=m
CONFIG_MEDIA_TUNER_XC2028=m
CONFIG_MEDIA_TUNER_XC5000=m
CONFIG_MEDIA_TUNER_MC44S803=m
CONFIG_DVB_MAX_ADAPTERS=8
# CONFIG_DVB_DYNAMIC_MINORS is not set
CONFIG_DVB_CAPTURE_DRIVERS=y

#
# Supported SAA7146 based PCI Adapters
#
CONFIG_TTPCI_EEPROM=m
CONFIG_DVB_BUDGET_CORE=m
CONFIG_DVB_BUDGET=m
# CONFIG_DVB_BUDGET_CI is not set

#
# Supported USB Adapters
#
CONFIG_DVB_TTUSB_BUDGET=m
CONFIG_DVB_TTUSB_DEC=m
CONFIG_SMS_SIANO_MDTV=m

#
# Siano module components
#
# CONFIG_SMS_USB_DRV is not set

#
# Supported FlexCopII (B2C2) Adapters
#
CONFIG_DVB_B2C2_FLEXCOP=m
CONFIG_DVB_B2C2_FLEXCOP_PCI=m
# CONFIG_DVB_B2C2_FLEXCOP_USB is not set
CONFIG_DVB_B2C2_FLEXCOP_DEBUG=y

#
# Supported BT878 Adapters
#

#
# Supported Pluto2 Adapters
#
CONFIG_DVB_PLUTO2=m

#
# Supported SDMC DM1105 Adapters
#
# CONFIG_DVB_DM1105 is not set

#
# Supported Earthsoft PT1 Adapters
#
# CONFIG_DVB_PT1 is not set

#
# Supported DVB Frontends
#
CONFIG_DVB_FE_CUSTOMISE=y

#
# Customise DVB Frontends
#

#
# Multistandard (satellite) frontends
#
CONFIG_DVB_STB0899=m
CONFIG_DVB_STB6100=m
CONFIG_DVB_STV090x=m
CONFIG_DVB_STV6110x=m

#
# DVB-S (satellite) frontends
#
# CONFIG_DVB_CX24110 is not set
# CONFIG_DVB_CX24123 is not set
# CONFIG_DVB_MT312 is not set
# CONFIG_DVB_ZL10036 is not set
CONFIG_DVB_ZL10039=m
# CONFIG_DVB_S5H1420 is not set
CONFIG_DVB_STV0288=m
CONFIG_DVB_STB6000=m
# CONFIG_DVB_STV0299 is not set
# CONFIG_DVB_STV6110 is not set
CONFIG_DVB_STV0900=m
# CONFIG_DVB_TDA8083 is not set
CONFIG_DVB_TDA10086=m
CONFIG_DVB_TDA8261=m
CONFIG_DVB_VES1X93=m
CONFIG_DVB_TUNER_ITD1000=m
CONFIG_DVB_TUNER_CX24113=m
CONFIG_DVB_TDA826X=m
CONFIG_DVB_TUA6100=m
# CONFIG_DVB_CX24116 is not set
CONFIG_DVB_SI21XX=m

#
# DVB-T (terrestrial) frontends
#
CONFIG_DVB_SP8870=m
CONFIG_DVB_SP887X=m
CONFIG_DVB_CX22700=m
# CONFIG_DVB_CX22702 is not set
CONFIG_DVB_DRX397XD=m
# CONFIG_DVB_L64781 is not set
CONFIG_DVB_TDA1004X=m
# CONFIG_DVB_NXT6000 is not set
CONFIG_DVB_MT352=m
# CONFIG_DVB_ZL10353 is not set
CONFIG_DVB_DIB3000MB=m
# CONFIG_DVB_DIB3000MC is not set
# CONFIG_DVB_DIB7000M is not set
CONFIG_DVB_DIB7000P=m
CONFIG_DVB_TDA10048=m
CONFIG_DVB_AF9013=m

#
# DVB-C (cable) frontends
#
CONFIG_DVB_VES1820=m
CONFIG_DVB_TDA10021=m
# CONFIG_DVB_TDA10023 is not set
CONFIG_DVB_STV0297=m

#
# ATSC (North American/Korean Terrestrial/Cable DTV) frontends
#
CONFIG_DVB_NXT200X=m
CONFIG_DVB_OR51211=m
# CONFIG_DVB_OR51132 is not set
CONFIG_DVB_BCM3510=m
# CONFIG_DVB_LGDT330X is not set
# CONFIG_DVB_LGDT3304 is not set
# CONFIG_DVB_LGDT3305 is not set
CONFIG_DVB_S5H1409=m
# CONFIG_DVB_S5H1411 is not set

#
# ISDB-T (terrestrial) frontends
#
CONFIG_DVB_S921=m
CONFIG_DVB_DIB8000=m

#
# Digital terrestrial only tuners/PLL
#
CONFIG_DVB_PLL=m
# CONFIG_DVB_TUNER_DIB0070 is not set

#
# SEC control devices for DVB-S
#
CONFIG_DVB_LNBP21=m
# CONFIG_DVB_ISL6405 is not set
CONFIG_DVB_ISL6421=m
# CONFIG_DVB_ISL6423 is not set
CONFIG_DVB_LGS8GL5=m
CONFIG_DVB_LGS8GXX=m

#
# Tools to develop new frontends
#
CONFIG_DVB_DUMMY_FE=m
CONFIG_DAB=y
CONFIG_USB_DABUSB=m

#
# Graphics support
#
CONFIG_AGP=y
CONFIG_AGP_ALI=m
CONFIG_AGP_ATI=m
CONFIG_AGP_AMD=m
CONFIG_AGP_AMD64=m
CONFIG_AGP_INTEL=m
# CONFIG_AGP_NVIDIA is not set
CONFIG_AGP_SIS=m
CONFIG_AGP_SWORKS=y
CONFIG_AGP_VIA=y
# CONFIG_AGP_EFFICEON is not set
CONFIG_VGA_ARB=y
CONFIG_DRM=y
# CONFIG_DRM_TDFX is not set
CONFIG_DRM_R128=y
# CONFIG_DRM_RADEON is not set
# CONFIG_DRM_I810 is not set
# CONFIG_DRM_I830 is not set
# CONFIG_DRM_I915 is not set
CONFIG_DRM_MGA=y
CONFIG_DRM_SIS=y
CONFIG_DRM_VIA=m
CONFIG_DRM_SAVAGE=y
# CONFIG_VGASTATE is not set
CONFIG_VIDEO_OUTPUT_CONTROL=m
# CONFIG_FB is not set
CONFIG_BACKLIGHT_LCD_SUPPORT=y
CONFIG_LCD_CLASS_DEVICE=y
# CONFIG_LCD_ILI9320 is not set
CONFIG_LCD_PLATFORM=y
CONFIG_BACKLIGHT_CLASS_DEVICE=m
# CONFIG_BACKLIGHT_GENERIC is not set
CONFIG_BACKLIGHT_PROGEAR=m
# CONFIG_BACKLIGHT_DA903X is not set
CONFIG_BACKLIGHT_MBP_NVIDIA=m
CONFIG_BACKLIGHT_SAHARA=m
CONFIG_BACKLIGHT_WM831X=m

#
# Display device support
#
CONFIG_DISPLAY_SUPPORT=m

#
# Display hardware drivers
#

#
# Console display driver support
#
CONFIG_VGA_CONSOLE=y
CONFIG_VGACON_SOFT_SCROLLBACK=y
CONFIG_VGACON_SOFT_SCROLLBACK_SIZE=64
CONFIG_DUMMY_CONSOLE=y
CONFIG_FONT_8x16=y
# CONFIG_SOUND is not set
CONFIG_HID_SUPPORT=y
CONFIG_HID=y
CONFIG_HIDRAW=y

#
# USB Input Devices
#
# CONFIG_USB_HID is not set
CONFIG_HID_PID=y

#
# USB HID Boot Protocol drivers
#
CONFIG_USB_KBD=m
CONFIG_USB_MOUSE=y

#
# Special HID drivers
#
CONFIG_USB_SUPPORT=y
CONFIG_USB_ARCH_HAS_HCD=y
CONFIG_USB_ARCH_HAS_OHCI=y
CONFIG_USB_ARCH_HAS_EHCI=y
CONFIG_USB=y
CONFIG_USB_DEBUG=y
CONFIG_USB_ANNOUNCE_NEW_DEVICES=y

#
# Miscellaneous USB options
#
# CONFIG_USB_DEVICEFS is not set
CONFIG_USB_DEVICE_CLASS=y
CONFIG_USB_DYNAMIC_MINORS=y
CONFIG_USB_SUSPEND=y
# CONFIG_USB_OTG is not set
CONFIG_USB_OTG_WHITELIST=y
CONFIG_USB_OTG_BLACKLIST_HUB=y
CONFIG_USB_MON=m
# CONFIG_USB_WUSB is not set
CONFIG_USB_WUSB_CBAF=y
CONFIG_USB_WUSB_CBAF_DEBUG=y

#
# USB Host Controller Drivers
#
CONFIG_USB_C67X00_HCD=y
CONFIG_USB_XHCI_HCD=y
# CONFIG_USB_XHCI_HCD_DEBUGGING is not set
CONFIG_USB_EHCI_HCD=y
CONFIG_USB_EHCI_ROOT_HUB_TT=y
CONFIG_USB_EHCI_TT_NEWSCHED=y
CONFIG_USB_OXU210HP_HCD=m
CONFIG_USB_ISP116X_HCD=y
CONFIG_USB_ISP1760_HCD=m
# CONFIG_USB_ISP1362_HCD is not set
CONFIG_USB_OHCI_HCD=y
CONFIG_USB_OHCI_HCD_SSB=y
# CONFIG_USB_OHCI_BIG_ENDIAN_DESC is not set
# CONFIG_USB_OHCI_BIG_ENDIAN_MMIO is not set
CONFIG_USB_OHCI_LITTLE_ENDIAN=y
CONFIG_USB_UHCI_HCD=y
CONFIG_USB_U132_HCD=m
CONFIG_USB_SL811_HCD=m
# CONFIG_USB_SL811_CS is not set
# CONFIG_USB_R8A66597_HCD is not set
# CONFIG_USB_HWA_HCD is not set

#
# USB Device Class drivers
#
CONFIG_USB_ACM=m
# 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 is not set
CONFIG_USB_LIBUSUAL=y

#
# USB Imaging devices
#
CONFIG_USB_MDC800=m
CONFIG_USB_MICROTEK=m

#
# USB port drivers
#
CONFIG_USB_SERIAL=y
# CONFIG_USB_SERIAL_CONSOLE is not set
CONFIG_USB_EZUSB=y
# CONFIG_USB_SERIAL_GENERIC is not set
CONFIG_USB_SERIAL_AIRCABLE=y
# CONFIG_USB_SERIAL_ARK3116 is not set
# CONFIG_USB_SERIAL_BELKIN is not set
CONFIG_USB_SERIAL_CH341=m
# CONFIG_USB_SERIAL_WHITEHEAT is not set
CONFIG_USB_SERIAL_DIGI_ACCELEPORT=y
# CONFIG_USB_SERIAL_CP210X is not set
CONFIG_USB_SERIAL_CYPRESS_M8=m
# CONFIG_USB_SERIAL_EMPEG is not set
CONFIG_USB_SERIAL_FTDI_SIO=y
CONFIG_USB_SERIAL_FUNSOFT=m
# CONFIG_USB_SERIAL_VISOR is not set
CONFIG_USB_SERIAL_IPAQ=m
CONFIG_USB_SERIAL_IR=y
# CONFIG_USB_SERIAL_EDGEPORT is not set
CONFIG_USB_SERIAL_EDGEPORT_TI=m
CONFIG_USB_SERIAL_GARMIN=m
CONFIG_USB_SERIAL_IPW=m
CONFIG_USB_SERIAL_IUU=y
# CONFIG_USB_SERIAL_KEYSPAN_PDA is not set
CONFIG_USB_SERIAL_KEYSPAN=m
CONFIG_USB_SERIAL_KEYSPAN_MPR=y
CONFIG_USB_SERIAL_KEYSPAN_USA28=y
CONFIG_USB_SERIAL_KEYSPAN_USA28X=y
CONFIG_USB_SERIAL_KEYSPAN_USA28XA=y
# CONFIG_USB_SERIAL_KEYSPAN_USA28XB is not set
CONFIG_USB_SERIAL_KEYSPAN_USA19=y
CONFIG_USB_SERIAL_KEYSPAN_USA18X=y
CONFIG_USB_SERIAL_KEYSPAN_USA19W=y
# CONFIG_USB_SERIAL_KEYSPAN_USA19QW is not set
# CONFIG_USB_SERIAL_KEYSPAN_USA19QI is not set
CONFIG_USB_SERIAL_KEYSPAN_USA49W=y
CONFIG_USB_SERIAL_KEYSPAN_USA49WLC=y
CONFIG_USB_SERIAL_KLSI=y
CONFIG_USB_SERIAL_KOBIL_SCT=y
CONFIG_USB_SERIAL_MCT_U232=y
# CONFIG_USB_SERIAL_MOS7720 is not set
CONFIG_USB_SERIAL_MOS7840=y
CONFIG_USB_SERIAL_MOTOROLA=y
CONFIG_USB_SERIAL_NAVMAN=m
# CONFIG_USB_SERIAL_PL2303 is not set
CONFIG_USB_SERIAL_OTI6858=m
CONFIG_USB_SERIAL_QUALCOMM=y
CONFIG_USB_SERIAL_SPCP8X5=y
CONFIG_USB_SERIAL_HP4X=y
CONFIG_USB_SERIAL_SAFE=m
CONFIG_USB_SERIAL_SAFE_PADDED=y
CONFIG_USB_SERIAL_SIEMENS_MPI=y
CONFIG_USB_SERIAL_SIERRAWIRELESS=m
CONFIG_USB_SERIAL_SYMBOL=y
# CONFIG_USB_SERIAL_TI is not set
# CONFIG_USB_SERIAL_CYBERJACK is not set
# CONFIG_USB_SERIAL_XIRCOM is not set
CONFIG_USB_SERIAL_OPTION=y
CONFIG_USB_SERIAL_OMNINET=y
CONFIG_USB_SERIAL_OPTICON=m
CONFIG_USB_SERIAL_DEBUG=y

#
# USB Miscellaneous drivers
#
CONFIG_USB_EMI62=y
CONFIG_USB_EMI26=y
CONFIG_USB_ADUTUX=y
CONFIG_USB_SEVSEG=y
# CONFIG_USB_RIO500 is not set
CONFIG_USB_LEGOTOWER=m
CONFIG_USB_LCD=y
CONFIG_USB_BERRY_CHARGE=y
CONFIG_USB_LED=y
# CONFIG_USB_CYPRESS_CY7C63 is not set
# CONFIG_USB_CYTHERM is not set
CONFIG_USB_IDMOUSE=y
CONFIG_USB_FTDI_ELAN=y
# CONFIG_USB_APPLEDISPLAY is not set
CONFIG_USB_SISUSBVGA=m
CONFIG_USB_SISUSBVGA_CON=y
CONFIG_USB_LD=y
CONFIG_USB_TRANCEVIBRATOR=m
# CONFIG_USB_IOWARRIOR is not set
CONFIG_USB_TEST=y
# CONFIG_USB_ISIGHTFW is not set
CONFIG_USB_VST=m

#
# OTG and related infrastructure
#
CONFIG_USB_OTG_UTILS=y
CONFIG_TWL4030_USB=y
CONFIG_NOP_USB_XCEIV=m
CONFIG_UWB=y
CONFIG_UWB_HWA=y
# CONFIG_UWB_WHCI is not set
CONFIG_UWB_WLP=m
CONFIG_UWB_I1480U=y
CONFIG_UWB_I1480U_WLP=m
# CONFIG_MMC is not set
CONFIG_MEMSTICK=m
CONFIG_MEMSTICK_DEBUG=y

#
# MemoryStick drivers
#
# CONFIG_MEMSTICK_UNSAFE_RESUME is not set
# CONFIG_MSPRO_BLOCK is not set

#
# MemoryStick Host Controller Drivers
#
CONFIG_MEMSTICK_TIFM_MS=m
# CONFIG_MEMSTICK_JMICRON_38X is not set
CONFIG_NEW_LEDS=y
CONFIG_LEDS_CLASS=y

#
# LED drivers
#
CONFIG_LEDS_ALIX2=y
CONFIG_LEDS_PCA9532=y
# CONFIG_LEDS_LP3944 is not set
CONFIG_LEDS_CLEVO_MAIL=m
CONFIG_LEDS_PCA955X=m
# CONFIG_LEDS_WM831X_STATUS is not set
CONFIG_LEDS_DA903X=m
CONFIG_LEDS_BD2802=m

#
# LED Triggers
#
CONFIG_LEDS_TRIGGERS=y
# CONFIG_LEDS_TRIGGER_TIMER is not set
CONFIG_LEDS_TRIGGER_HEARTBEAT=y
CONFIG_LEDS_TRIGGER_BACKLIGHT=m
CONFIG_LEDS_TRIGGER_DEFAULT_ON=y

#
# iptables trigger is under Netfilter config (LED target)
#
CONFIG_ACCESSIBILITY=y
CONFIG_A11Y_BRAILLE_CONSOLE=y
# CONFIG_INFINIBAND is not set
CONFIG_EDAC=y

#
# Reporting subsystems
#
CONFIG_EDAC_DEBUG=y
# CONFIG_EDAC_DEBUG_VERBOSE is not set
# CONFIG_EDAC_DECODE_MCE is not set
CONFIG_EDAC_MM_EDAC=m
CONFIG_EDAC_AMD76X=m
# CONFIG_EDAC_E7XXX is not set
CONFIG_EDAC_E752X=m
CONFIG_EDAC_I82875P=m
CONFIG_EDAC_I82975X=m
CONFIG_EDAC_I3000=m
# CONFIG_EDAC_I3200 is not set
CONFIG_EDAC_X38=m
CONFIG_EDAC_I5400=m
CONFIG_EDAC_I82860=m
# CONFIG_EDAC_R82600 is not set
CONFIG_EDAC_I5000=m
CONFIG_EDAC_I5100=m
# CONFIG_RTC_CLASS is not set
CONFIG_DMADEVICES=y

#
# DMA Devices
#
CONFIG_ASYNC_TX_DISABLE_CHANNEL_SWITCH=y
CONFIG_INTEL_IOATDMA=m
CONFIG_DMA_ENGINE=y

#
# DMA Clients
#
CONFIG_NET_DMA=y
CONFIG_ASYNC_TX_DMA=y
# CONFIG_DMATEST is not set
CONFIG_DCA=m
# CONFIG_AUXDISPLAY is not set
CONFIG_UIO=y
CONFIG_UIO_CIF=m
CONFIG_UIO_PDRV=y
# CONFIG_UIO_PDRV_GENIRQ is not set
# CONFIG_UIO_SMX is not set
CONFIG_UIO_AEC=m
CONFIG_UIO_SERCOS3=m
CONFIG_UIO_PCI_GENERIC=m

#
# TI VLYNQ
#
CONFIG_X86_PLATFORM_DEVICES=y
# CONFIG_ACER_WMI is not set
# CONFIG_ASUS_LAPTOP is not set
# CONFIG_DELL_WMI is not set
CONFIG_FUJITSU_LAPTOP=m
# CONFIG_FUJITSU_LAPTOP_DEBUG is not set
CONFIG_TC1100_WMI=y
CONFIG_HP_WMI=m
# CONFIG_MSI_LAPTOP is not set
# CONFIG_PANASONIC_LAPTOP is not set
CONFIG_COMPAL_LAPTOP=m
CONFIG_SONY_LAPTOP=m
# CONFIG_SONYPI_COMPAT is not set
CONFIG_THINKPAD_ACPI=m
CONFIG_THINKPAD_ACPI_DEBUGFACILITIES=y
# CONFIG_THINKPAD_ACPI_DEBUG is not set
CONFIG_THINKPAD_ACPI_UNSAFE_LEDS=y
# CONFIG_THINKPAD_ACPI_VIDEO is not set
CONFIG_THINKPAD_ACPI_HOTKEY_POLL=y
CONFIG_ACPI_WMI=y
CONFIG_ACPI_ASUS=m
CONFIG_TOPSTAR_LAPTOP=y
# CONFIG_ACPI_TOSHIBA is not set

#
# Firmware Drivers
#
# CONFIG_EDD is not set
CONFIG_FIRMWARE_MEMMAP=y
# CONFIG_EFI_VARS is not set
CONFIG_DELL_RBU=y
CONFIG_DCDBAS=y
# CONFIG_DMIID is not set
CONFIG_ISCSI_IBFT_FIND=y
CONFIG_ISCSI_IBFT=y

#
# File systems
#
CONFIG_EXT2_FS=m
# CONFIG_EXT2_FS_XATTR is not set
# CONFIG_EXT2_FS_XIP is not set
CONFIG_EXT3_FS=y
# CONFIG_EXT3_DEFAULTS_TO_ORDERED is not set
CONFIG_EXT3_FS_XATTR=y
CONFIG_EXT3_FS_POSIX_ACL=y
CONFIG_EXT3_FS_SECURITY=y
CONFIG_EXT4_FS=m
# CONFIG_EXT4_FS_XATTR is not set
CONFIG_EXT4_DEBUG=y
CONFIG_JBD=y
CONFIG_JBD_DEBUG=y
CONFIG_JBD2=m
CONFIG_JBD2_DEBUG=y
CONFIG_FS_MBCACHE=y
CONFIG_REISERFS_FS=m
# CONFIG_REISERFS_CHECK is not set
CONFIG_REISERFS_PROC_INFO=y
CONFIG_REISERFS_FS_XATTR=y
CONFIG_REISERFS_FS_POSIX_ACL=y
CONFIG_REISERFS_FS_SECURITY=y
# CONFIG_JFS_FS is not set
CONFIG_FS_POSIX_ACL=y
CONFIG_XFS_FS=y
CONFIG_XFS_QUOTA=y
CONFIG_XFS_POSIX_ACL=y
CONFIG_XFS_RT=y
# CONFIG_XFS_DEBUG is not set
# CONFIG_GFS2_FS is not set
# CONFIG_OCFS2_FS is not set
# CONFIG_BTRFS_FS is not set
CONFIG_NILFS2_FS=y
CONFIG_FILE_LOCKING=y
CONFIG_FSNOTIFY=y
CONFIG_DNOTIFY=y
CONFIG_INOTIFY=y
CONFIG_INOTIFY_USER=y
# CONFIG_QUOTA is not set
CONFIG_QUOTACTL=y
# CONFIG_AUTOFS_FS is not set
CONFIG_AUTOFS4_FS=m
CONFIG_FUSE_FS=m
CONFIG_CUSE=m

#
# Caches
#
# CONFIG_FSCACHE is not set

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

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

#
# Pseudo filesystems
#
CONFIG_PROC_FS=y
CONFIG_PROC_KCORE=y
CONFIG_PROC_VMCORE=y
CONFIG_PROC_SYSCTL=y
CONFIG_PROC_PAGE_MONITOR=y
CONFIG_SYSFS=y
CONFIG_TMPFS=y
# CONFIG_TMPFS_POSIX_ACL is not set
CONFIG_HUGETLBFS=y
CONFIG_HUGETLB_PAGE=y
CONFIG_CONFIGFS_FS=y
# CONFIG_MISC_FILESYSTEMS is not set
CONFIG_NETWORK_FILESYSTEMS=y
CONFIG_NFS_FS=y
# CONFIG_NFS_V3 is not set
CONFIG_NFS_V4=y
CONFIG_NFS_V4_1=y
CONFIG_NFSD=y
CONFIG_NFSD_V2_ACL=y
CONFIG_NFSD_V3=y
CONFIG_NFSD_V3_ACL=y
CONFIG_NFSD_V4=y
CONFIG_LOCKD=y
CONFIG_LOCKD_V4=y
CONFIG_EXPORTFS=y
CONFIG_NFS_ACL_SUPPORT=y
CONFIG_NFS_COMMON=y
CONFIG_SUNRPC=y
CONFIG_SUNRPC_GSS=y
CONFIG_RPCSEC_GSS_KRB5=y
CONFIG_RPCSEC_GSS_SPKM3=y
CONFIG_SMB_FS=m
CONFIG_SMB_NLS_DEFAULT=y
CONFIG_SMB_NLS_REMOTE="cp437"
CONFIG_CIFS=m
CONFIG_CIFS_STATS=y
CONFIG_CIFS_STATS2=y
CONFIG_CIFS_WEAK_PW_HASH=y
# CONFIG_CIFS_UPCALL is not set
CONFIG_CIFS_XATTR=y
CONFIG_CIFS_POSIX=y
CONFIG_CIFS_DEBUG2=y
CONFIG_CIFS_DFS_UPCALL=y
CONFIG_CIFS_EXPERIMENTAL=y
# CONFIG_NCP_FS is not set
# CONFIG_CODA_FS is not set
# CONFIG_AFS_FS is not set

#
# Partition Types
#
CONFIG_PARTITION_ADVANCED=y
CONFIG_ACORN_PARTITION=y
CONFIG_ACORN_PARTITION_CUMANA=y
CONFIG_ACORN_PARTITION_EESOX=y
# CONFIG_ACORN_PARTITION_ICS is not set
# CONFIG_ACORN_PARTITION_ADFS is not set
CONFIG_ACORN_PARTITION_POWERTEC=y
CONFIG_ACORN_PARTITION_RISCIX=y
# CONFIG_OSF_PARTITION is not set
CONFIG_AMIGA_PARTITION=y
# CONFIG_ATARI_PARTITION is not set
CONFIG_MAC_PARTITION=y
CONFIG_MSDOS_PARTITION=y
CONFIG_BSD_DISKLABEL=y
CONFIG_MINIX_SUBPARTITION=y
CONFIG_SOLARIS_X86_PARTITION=y
CONFIG_UNIXWARE_DISKLABEL=y
CONFIG_LDM_PARTITION=y
CONFIG_LDM_DEBUG=y
CONFIG_SGI_PARTITION=y
# CONFIG_ULTRIX_PARTITION is not set
# CONFIG_SUN_PARTITION is not set
CONFIG_KARMA_PARTITION=y
CONFIG_EFI_PARTITION=y
# CONFIG_SYSV68_PARTITION is not set
CONFIG_NLS=y
CONFIG_NLS_DEFAULT="iso8859-1"
# CONFIG_NLS_CODEPAGE_437 is not set
CONFIG_NLS_CODEPAGE_737=y
# CONFIG_NLS_CODEPAGE_775 is not set
CONFIG_NLS_CODEPAGE_850=m
CONFIG_NLS_CODEPAGE_852=m
CONFIG_NLS_CODEPAGE_855=m
CONFIG_NLS_CODEPAGE_857=y
CONFIG_NLS_CODEPAGE_860=y
CONFIG_NLS_CODEPAGE_861=m
CONFIG_NLS_CODEPAGE_862=m
CONFIG_NLS_CODEPAGE_863=m
# CONFIG_NLS_CODEPAGE_864 is not set
CONFIG_NLS_CODEPAGE_865=y
# CONFIG_NLS_CODEPAGE_866 is not set
CONFIG_NLS_CODEPAGE_869=y
# CONFIG_NLS_CODEPAGE_936 is not set
CONFIG_NLS_CODEPAGE_950=y
CONFIG_NLS_CODEPAGE_932=m
CONFIG_NLS_CODEPAGE_949=y
# CONFIG_NLS_CODEPAGE_874 is not set
CONFIG_NLS_ISO8859_8=m
CONFIG_NLS_CODEPAGE_1250=y
CONFIG_NLS_CODEPAGE_1251=m
# CONFIG_NLS_ASCII is not set
# CONFIG_NLS_ISO8859_1 is not set
CONFIG_NLS_ISO8859_2=m
CONFIG_NLS_ISO8859_3=y
# CONFIG_NLS_ISO8859_4 is not set
CONFIG_NLS_ISO8859_5=y
# CONFIG_NLS_ISO8859_6 is not set
# CONFIG_NLS_ISO8859_7 is not set
CONFIG_NLS_ISO8859_9=y
CONFIG_NLS_ISO8859_13=y
CONFIG_NLS_ISO8859_14=y
# CONFIG_NLS_ISO8859_15 is not set
CONFIG_NLS_KOI8_R=m
CONFIG_NLS_KOI8_U=y
CONFIG_NLS_UTF8=m
# CONFIG_DLM is not set

#
# Kernel hacking
#
CONFIG_TRACE_IRQFLAGS_SUPPORT=y
# CONFIG_PRINTK_TIME is not set
CONFIG_ALLOW_WARNINGS=y
# CONFIG_ENABLE_WARN_DEPRECATED is not set
# CONFIG_ENABLE_MUST_CHECK is not set
CONFIG_FRAME_WARN=1024
CONFIG_MAGIC_SYSRQ=y
CONFIG_STRIP_ASM_SYMS=y
# CONFIG_UNUSED_SYMBOLS is not set
CONFIG_DEBUG_FS=y
CONFIG_HEADERS_CHECK=y
CONFIG_DEBUG_SECTION_MISMATCH=y
CONFIG_DEBUG_KERNEL=y
CONFIG_DEBUG_SHIRQ=y
CONFIG_DETECT_SOFTLOCKUP=y
# CONFIG_BOOTPARAM_SOFTLOCKUP_PANIC is not set
CONFIG_BOOTPARAM_SOFTLOCKUP_PANIC_VALUE=0
CONFIG_DETECT_HUNG_TASK=y
CONFIG_BOOTPARAM_HUNG_TASK_PANIC=y
CONFIG_BOOTPARAM_HUNG_TASK_PANIC_VALUE=1
CONFIG_SCHED_DEBUG=y
CONFIG_SCHEDSTATS=y
CONFIG_TIMER_STATS=y
CONFIG_DEBUG_OBJECTS=y
CONFIG_DEBUG_OBJECTS_SELFTEST=y
CONFIG_DEBUG_OBJECTS_FREE=y
CONFIG_DEBUG_OBJECTS_TIMERS=y
CONFIG_DEBUG_OBJECTS_ENABLE_DEFAULT=1
CONFIG_SLUB_DEBUG_ON=y
CONFIG_SLUB_STATS=y
CONFIG_DEBUG_PREEMPT=y
CONFIG_DEBUG_RT_MUTEXES=y
CONFIG_DEBUG_PI_LIST=y
# CONFIG_RT_MUTEX_TESTER is not set
CONFIG_DEBUG_SPINLOCK=y
CONFIG_DEBUG_MUTEXES=y
CONFIG_DEBUG_LOCK_ALLOC=y
CONFIG_PROVE_LOCKING=y
CONFIG_LOCKDEP=y
CONFIG_LOCK_STAT=y
CONFIG_DEBUG_LOCKDEP=y
CONFIG_TRACE_IRQFLAGS=y
CONFIG_DEBUG_SPINLOCK_SLEEP=y
# CONFIG_DEBUG_LOCKING_API_SELFTESTS is not set
CONFIG_STACKTRACE=y
CONFIG_DEBUG_HIGHMEM=y
CONFIG_DEBUG_BUGVERBOSE=y
CONFIG_DEBUG_VM=y
# CONFIG_DEBUG_VIRTUAL is not set
# CONFIG_DEBUG_WRITECOUNT is not set
CONFIG_DEBUG_MEMORY_INIT=y
CONFIG_DEBUG_LIST=y
# CONFIG_DEBUG_SG is not set
CONFIG_DEBUG_NOTIFIERS=y
# CONFIG_DEBUG_CREDENTIALS is not set
CONFIG_ARCH_WANT_FRAME_POINTERS=y
CONFIG_FRAME_POINTER=y
CONFIG_BOOT_PRINTK_DELAY=y
CONFIG_RCU_TORTURE_TEST=y
CONFIG_RCU_TORTURE_TEST_RUNNABLE=y
CONFIG_RCU_CPU_STALL_DETECTOR=y
CONFIG_BACKTRACE_SELF_TEST=m
# CONFIG_DEBUG_FORCE_WEAK_PER_CPU is not set
CONFIG_LKDTM=m
# CONFIG_FAULT_INJECTION is not set
CONFIG_LATENCYTOP=y
# CONFIG_DEBUG_PAGEALLOC is not set
CONFIG_USER_STACKTRACE_SUPPORT=y
CONFIG_NOP_TRACER=y
CONFIG_HAVE_FTRACE_NMI_ENTER=y
CONFIG_HAVE_FUNCTION_TRACER=y
CONFIG_HAVE_FUNCTION_GRAPH_TRACER=y
CONFIG_HAVE_FUNCTION_GRAPH_FP_TEST=y
CONFIG_HAVE_FUNCTION_TRACE_MCOUNT_TEST=y
CONFIG_HAVE_DYNAMIC_FTRACE=y
CONFIG_HAVE_FTRACE_MCOUNT_RECORD=y
CONFIG_HAVE_SYSCALL_TRACEPOINTS=y
CONFIG_TRACER_MAX_TRACE=y
CONFIG_RING_BUFFER=y
CONFIG_FTRACE_NMI_ENTER=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=y
CONFIG_IRQSOFF_TRACER=y
# CONFIG_PREEMPT_TRACER is not set
CONFIG_SYSPROF_TRACER=y
CONFIG_SCHED_TRACER=y
CONFIG_FTRACE_SYSCALLS=y
# CONFIG_BOOT_TRACER is not set
CONFIG_BRANCH_PROFILE_NONE=y
# CONFIG_PROFILE_ANNOTATED_BRANCHES is not set
# CONFIG_PROFILE_ALL_BRANCHES is not set
CONFIG_POWER_TRACER=y
CONFIG_KSYM_TRACER=y
CONFIG_PROFILE_KSYM_TRACER=y
CONFIG_STACK_TRACER=y
CONFIG_KMEMTRACE=y
CONFIG_WORKQUEUE_TRACER=y
CONFIG_BLK_DEV_IO_TRACE=y
CONFIG_KPROBE_EVENT=y
CONFIG_DYNAMIC_FTRACE=y
CONFIG_FUNCTION_PROFILER=y
CONFIG_FTRACE_MCOUNT_RECORD=y
CONFIG_FTRACE_SELFTEST=y
CONFIG_FTRACE_STARTUP_TEST=y
# CONFIG_EVENT_TRACE_TEST_SYSCALLS is not set
CONFIG_MMIOTRACE=y
CONFIG_MMIOTRACE_TEST=m
CONFIG_PROVIDE_OHCI1394_DMA_INIT=y
CONFIG_BUILD_DOCSRC=y
CONFIG_DYNAMIC_DEBUG=y
CONFIG_DMA_API_DEBUG=y
CONFIG_SAMPLES=y
CONFIG_SAMPLE_TRACEPOINTS=m
CONFIG_SAMPLE_TRACE_EVENTS=m
CONFIG_SAMPLE_KOBJECT=m
CONFIG_SAMPLE_KPROBES=m
CONFIG_SAMPLE_KRETPROBES=m
CONFIG_SAMPLE_HW_BREAKPOINT=m
CONFIG_HAVE_ARCH_KGDB=y
# CONFIG_KGDB is not set
CONFIG_HAVE_ARCH_KMEMCHECK=y
CONFIG_STRICT_DEVMEM=y
CONFIG_X86_VERBOSE_BOOTUP=y
CONFIG_EARLY_PRINTK=y
CONFIG_EARLY_PRINTK_DBGP=y
CONFIG_DEBUG_STACKOVERFLOW=y
# CONFIG_DEBUG_STACK_USAGE is not set
CONFIG_DEBUG_PER_CPU_MAPS=y
# CONFIG_X86_PTDUMP is not set
# CONFIG_DEBUG_RODATA is not set
CONFIG_DEBUG_NX_TEST=m
# CONFIG_4KSTACKS is not set
CONFIG_DOUBLEFAULT=y
CONFIG_IOMMU_STRESS=y
CONFIG_HAVE_MMIOTRACE_SUPPORT=y
CONFIG_IO_DELAY_TYPE_0X80=0
CONFIG_IO_DELAY_TYPE_0XED=1
CONFIG_IO_DELAY_TYPE_UDELAY=2
CONFIG_IO_DELAY_TYPE_NONE=3
CONFIG_IO_DELAY_0X80=y
# CONFIG_IO_DELAY_0XED is not set
# CONFIG_IO_DELAY_UDELAY is not set
# CONFIG_IO_DELAY_NONE is not set
CONFIG_DEFAULT_IO_DELAY_TYPE=0
CONFIG_DEBUG_BOOT_PARAMS=y
CONFIG_CPA_DEBUG=y
CONFIG_OPTIMIZE_INLINING=y

#
# Security options
#
CONFIG_KEYS=y
CONFIG_KEYS_DEBUG_PROC_KEYS=y
CONFIG_SECURITY=y
CONFIG_SECURITYFS=y
CONFIG_SECURITY_NETWORK=y
CONFIG_SECURITY_NETWORK_XFRM=y
CONFIG_SECURITY_PATH=y
# CONFIG_SECURITY_FILE_CAPABILITIES is not set
CONFIG_LSM_MMAP_MIN_ADDR=65536
CONFIG_SECURITY_SELINUX=y
CONFIG_SECURITY_SELINUX_BOOTPARAM=y
CONFIG_SECURITY_SELINUX_BOOTPARAM_VALUE=1
CONFIG_SECURITY_SELINUX_DISABLE=y
CONFIG_SECURITY_SELINUX_DEVELOP=y
CONFIG_SECURITY_SELINUX_AVC_STATS=y
CONFIG_SECURITY_SELINUX_CHECKREQPROT_VALUE=1
CONFIG_SECURITY_TOMOYO=y
# CONFIG_IMA is not set
CONFIG_XOR_BLOCKS=m
CONFIG_ASYNC_CORE=m
CONFIG_ASYNC_MEMCPY=m
CONFIG_ASYNC_XOR=m
CONFIG_ASYNC_PQ=m
CONFIG_ASYNC_RAID6_RECOV=m
CONFIG_CRYPTO=y

#
# Crypto core or helper
#
CONFIG_CRYPTO_FIPS=y
CONFIG_CRYPTO_ALGAPI=y
CONFIG_CRYPTO_ALGAPI2=y
CONFIG_CRYPTO_AEAD=y
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_PCOMP=y
CONFIG_CRYPTO_MANAGER=y
CONFIG_CRYPTO_MANAGER2=y
CONFIG_CRYPTO_GF128MUL=y
CONFIG_CRYPTO_NULL=m
CONFIG_CRYPTO_WORKQUEUE=y
# CONFIG_CRYPTO_CRYPTD is not set
CONFIG_CRYPTO_AUTHENC=y
CONFIG_CRYPTO_TEST=m

#
# Authenticated Encryption with Associated Data
#
CONFIG_CRYPTO_CCM=m
# CONFIG_CRYPTO_GCM is not set
CONFIG_CRYPTO_SEQIV=m

#
# Block modes
#
CONFIG_CRYPTO_CBC=y
CONFIG_CRYPTO_CTR=m
CONFIG_CRYPTO_CTS=y
CONFIG_CRYPTO_ECB=m
# CONFIG_CRYPTO_LRW is not set
CONFIG_CRYPTO_PCBC=y
CONFIG_CRYPTO_XTS=y

#
# Hash modes
#
CONFIG_CRYPTO_HMAC=y
CONFIG_CRYPTO_XCBC=m
CONFIG_CRYPTO_VMAC=m

#
# Digest
#
CONFIG_CRYPTO_CRC32C=y
# CONFIG_CRYPTO_CRC32C_INTEL is not set
# CONFIG_CRYPTO_GHASH is not set
CONFIG_CRYPTO_MD4=m
CONFIG_CRYPTO_MD5=y
# CONFIG_CRYPTO_MICHAEL_MIC is not set
# CONFIG_CRYPTO_RMD128 is not set
CONFIG_CRYPTO_RMD160=m
CONFIG_CRYPTO_RMD256=m
# CONFIG_CRYPTO_RMD320 is not set
CONFIG_CRYPTO_SHA1=y
CONFIG_CRYPTO_SHA256=y
CONFIG_CRYPTO_SHA512=m
CONFIG_CRYPTO_TGR192=m
CONFIG_CRYPTO_WP512=m

#
# Ciphers
#
CONFIG_CRYPTO_AES=m
CONFIG_CRYPTO_AES_586=m
CONFIG_CRYPTO_ANUBIS=m
CONFIG_CRYPTO_ARC4=m
CONFIG_CRYPTO_BLOWFISH=y
CONFIG_CRYPTO_CAMELLIA=m
CONFIG_CRYPTO_CAST5=y
CONFIG_CRYPTO_CAST6=y
CONFIG_CRYPTO_DES=y
CONFIG_CRYPTO_FCRYPT=y
CONFIG_CRYPTO_KHAZAD=y
# CONFIG_CRYPTO_SALSA20 is not set
# CONFIG_CRYPTO_SALSA20_586 is not set
CONFIG_CRYPTO_SEED=m
CONFIG_CRYPTO_SERPENT=y
CONFIG_CRYPTO_TEA=y
CONFIG_CRYPTO_TWOFISH=m
CONFIG_CRYPTO_TWOFISH_COMMON=m
# CONFIG_CRYPTO_TWOFISH_586 is not set

#
# Compression
#
CONFIG_CRYPTO_DEFLATE=y
CONFIG_CRYPTO_ZLIB=m
CONFIG_CRYPTO_LZO=m

#
# Random Number Generation
#
CONFIG_CRYPTO_ANSI_CPRNG=m
CONFIG_CRYPTO_HW=y
CONFIG_CRYPTO_DEV_PADLOCK=y
CONFIG_CRYPTO_DEV_PADLOCK_AES=m
CONFIG_CRYPTO_DEV_PADLOCK_SHA=y
# CONFIG_CRYPTO_DEV_GEODE is not set
CONFIG_CRYPTO_DEV_HIFN_795X=y
# CONFIG_CRYPTO_DEV_HIFN_795X_RNG is not set
CONFIG_HAVE_KVM=y
# CONFIG_VIRTUALIZATION is not set
CONFIG_VIRTIO=y
CONFIG_VIRTIO_RING=y
CONFIG_BINARY_PRINTF=y

#
# Library routines
#
CONFIG_BITREVERSE=y
CONFIG_GENERIC_FIND_FIRST_BIT=y
CONFIG_GENERIC_FIND_NEXT_BIT=y
CONFIG_GENERIC_FIND_LAST_BIT=y
CONFIG_CRC_CCITT=y
CONFIG_CRC16=m
CONFIG_CRC_T10DIF=y
CONFIG_CRC_ITU_T=y
CONFIG_CRC32=y
CONFIG_CRC7=m
CONFIG_LIBCRC32C=y
CONFIG_AUDIT_GENERIC=y
CONFIG_ZLIB_INFLATE=y
CONFIG_ZLIB_DEFLATE=y
CONFIG_LZO_COMPRESS=m
CONFIG_LZO_DECOMPRESS=m
CONFIG_HAS_IOMEM=y
CONFIG_HAS_IOPORT=y
CONFIG_HAS_DMA=y
CONFIG_CHECK_SIGNATURE=y
CONFIG_CPUMASK_OFFSTACK=y
CONFIG_NLATTR=y
CONFIG_FORCE_SUCCESSFUL_BUILD=y
CONFIG_FORCE_MINIMAL_CONFIG=y
CONFIG_FORCE_MINIMAL_CONFIG_PHYS=y
CONFIG_X86_32_ALWAYS_ON=y

Re: [tip:timers/urgent] hrtimer: Fix /proc/timer_list regression

[Thomas Gleixner]

On Thu, 19 Nov 2009, Ingo Molnar wrote:
> i've bisected back to it:
> 
> | 887a29f59b93cf54e21814869a4ab6e80b6fa623 is the first bad commit
> | commit 887a29f59b93cf54e21814869a4ab6e80b6fa623
> | Author: Feng Tang <feng.tang@intel.com>
> | Date:   Thu Sep 3 16:32:53 2009 +0800
> |
> |    hrtimer: Fix /proc/timer_list regression
> 
> Config attached.
> 
> I've removed it from timers/urgent for now.

Come on, this is a patently wrong conclusion.

We call timer_stats_update_stats() which returns on top of the
function due to:

	if (likely(!timer_stats_active))
		return;

timer_stats_active is 0 during boot and you can only activate it by
writing to /proc/timer_stats which you certainly did not at this
point.

Can you please explain how a call to a function which returns right
away can cause that problem ? 

That patch unearthed some other bug and your revert is just papering
over that fact.

Thanks,

	tglx

BUG: function graph tracer function frame assumptions

[Thomas Gleixner]

B1;2005;0cOn Thu, 19 Nov 2009, Thomas Gleixner wrote:
> On Thu, 19 Nov 2009, Ingo Molnar wrote:
> > i've bisected back to it:
> > 
> > | 887a29f59b93cf54e21814869a4ab6e80b6fa623 is the first bad commit
> > | commit 887a29f59b93cf54e21814869a4ab6e80b6fa623
> > | Author: Feng Tang <feng.tang@intel.com>
> > | Date:   Thu Sep 3 16:32:53 2009 +0800
> > |
> > |    hrtimer: Fix /proc/timer_list regression
> > 
> > Config attached.
> > 
> > I've removed it from timers/urgent for now.
> 
> Come on, this is a patently wrong conclusion.
> 
> We call timer_stats_update_stats() which returns on top of the
> function due to:
> 
> 	if (likely(!timer_stats_active))
> 		return;
> 
> timer_stats_active is 0 during boot and you can only activate it by
> writing to /proc/timer_stats which you certainly did not at this
> point.
> 
> Can you please explain how a call to a function which returns right
> away can cause that problem ? 
> 
> That patch unearthed some other bug and your revert is just papering
> over that fact.

Looked deeper into that and found the root cause.

The function graph tracer expects that the first code sequence in a
function is:

function_start:
	 push	%ebp
	 mov	%esp, %ebp
	 ....
	 call   mcount

and on the return side:

       	 pop	%ebp
	 ret

which is the case for most functions except, but not for all

timer_stats_update_stats() and a few others have:

function_start:
	push   %edi
	lea    0x8(%esp),%edi
	and    $0xfffffff0,%esp
	pushl  -0x4(%edi)
	push   %ebp
	mov    %esp,%ebp
	...
	call   mcount

and the return does:

	pop    %ebp
	lea    -0x8(%edi),%esp
	pop    %edi
	ret

mcount calls prepare_ftrace_return() with the following calling sequence:

        pushl	%eax
        pushl	%ecx
        pushl	%edx
        movl	0xc(%esp), %edx
        lea	0x4(%ebp), %eax

Here is where the shit hits the fan.

For the usual function frames this is correct:

ebp points to the stack location where ebp was pushed and ebp + 4
points to the return address.

For the timer_stats_update_stats case points to the stack location
where ebp was pushed _BUT_ ebp + 4 is pointing to a stack entry
_BELOW_ the return address.

        movl	(%ebp), %ecx
        subl	$MCOUNT_INSN_SIZE, %edx
        call	prepare_ftrace_return
        popl	%edx
        popl	%ecx
        popl	%eax
        ret

prepare_ftrace_return does:

void prepare_ftrace_return(unsigned long *parent, unsigned long self_addr,
			   unsigned long frame_pointer)
{
	unsigned long old;
	int faulted;
	unsigned long return_hooker = (unsigned long)
				&return_to_handler;

	asm volatile(
		"1: " _ASM_MOV " (%[parent]), %[old]\n"
		"2: " _ASM_MOV " %[return_hooker], (%[parent])\n"
		"   movl $0, %[faulted]\n"
		"3:\n"

So here we modify the "return" address on the stack where parent is
supposed to point to. That works for the standard function frames, but
not for the ones which look like timer_stats_update_stats().

In the timer_stats_update_stats() case we do not call the
return_to_handler when the function returns, because we did not modify
the return address. So the next return in the calling function will
trip over the sanity checking and panic.

I'm not yet sure whether this is a compiler problem (using gcc 4.4.1)
or just the stupid assumption that function frames always start with

	push	%ebp
	mov	%esp, %ebp

Thanks,

	tglx

Re: BUG: GCC-4.4.x changes the function frame on some functions

[Thomas Gleixner]

On Thu, 19 Nov 2009, Thomas Gleixner wrote:

Can the GCC folks please shed some light on this:

standard function start:

	 push	%ebp
	 mov	%esp, %ebp
	 ....
	 call   mcount

modified function start on a handful of functions only seen with gcc
4.4.x on x86 32 bit:

	push   %edi
	lea    0x8(%esp),%edi
	and    $0xfffffff0,%esp
	pushl  -0x4(%edi)
	push   %ebp
	mov    %esp,%ebp
	...
	call   mcount

This modification leads to a hard to solve problem in the kernel
function graph tracer which assumes that the stack looks like:

       return address
       saved  ebp

With the modified function start sequence this is not longer true and
the manipulation of the return address on the stack fails silently.

Neither gcc 4.3 nor gcc 3.4 are generating such function frames, so it
looks like a gcc 4.4.x feature.

There is no real obvious reason why the edi magic needs to be done
_before_ 

	push   %ebp
	mov    %esp,%ebp

Thanks,

	tglx

Re: BUG: GCC-4.4.x changes the function frame on some functions

[Andrew Haley]

Thomas Gleixner wrote:
> On Thu, 19 Nov 2009, Thomas Gleixner wrote:
> 
> Can the GCC folks please shed some light on this:
> 
> standard function start:
> 
> 	 push	%ebp
> 	 mov	%esp, %ebp
> 	 ....
> 	 call   mcount
> 
> modified function start on a handful of functions only seen with gcc
> 4.4.x on x86 32 bit:
> 
> 	push   %edi
> 	lea    0x8(%esp),%edi
> 	and    $0xfffffff0,%esp
> 	pushl  -0x4(%edi)
> 	push   %ebp
> 	mov    %esp,%ebp
> 	...
> 	call   mcount
> 
> This modification leads to a hard to solve problem in the kernel
> function graph tracer which assumes that the stack looks like:
> 
>        return address
>        saved  ebp
> 
> With the modified function start sequence this is not longer true and
> the manipulation of the return address on the stack fails silently.
> 
> Neither gcc 4.3 nor gcc 3.4 are generating such function frames, so it
> looks like a gcc 4.4.x feature.
> 
> There is no real obvious reason why the edi magic needs to be done
> _before_ 
> 
> 	push   %ebp
> 	mov    %esp,%ebp

Sure there is: unless you do the adjustment first %ebp won't be 16-aligned.

We're aligning the stack properly, as per the ABI requirements.  Can't
you just fix the tracer?

Andrew.

Re: BUG: GCC-4.4.x changes the function frame on some functions

[H. Peter Anvin]

On 11/19/2009 07:44 AM, Andrew Haley wrote:
> 
> We're aligning the stack properly, as per the ABI requirements.  Can't
> you just fix the tracer?
> 

"Per the ABI requirements?"  We're talking 32 bits, here.

	-hpa

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.

Re: BUG: GCC-4.4.x changes the function frame on some functions

[Richard Guenther]

On Thu, Nov 19, 2009 at 4:54 PM, H. Peter Anvin <hpa@zytor.com> wrote:
> On 11/19/2009 07:44 AM, Andrew Haley wrote:
>>
>> We're aligning the stack properly, as per the ABI requirements.  Can't
>> you just fix the tracer?
>>
>
> "Per the ABI requirements?"  We're talking 32 bits, here.

Hm, even with

void bar (int *);
void foo (void)
{
  int x;
  bar (&x);
}

gcc -S -O2 -m32 -mincoming-stack-boundary=2 t.c

we re-align the stack.  That looks indeed bogus.

HJ, you invented all this code, what's the reason for the above?

Richard.

Re: BUG: GCC-4.4.x changes the function frame on some functions

[Steven Rostedt]

On Thu, 2009-11-19 at 15:44 +0000, Andrew Haley wrote:
> Thomas Gleixner wrote:

> We're aligning the stack properly, as per the ABI requirements.  Can't
> you just fix the tracer?

And how do we do that? The hooks that are in place have no idea of what
happened before they were called?

-- Steve

Re: BUG: GCC-4.4.x changes the function frame on some functions

[H. Peter Anvin]

On 11/19/2009 08:02 AM, Steven Rostedt wrote:
> On Thu, 2009-11-19 at 15:44 +0000, Andrew Haley wrote:
>> Thomas Gleixner wrote:
> 
>> We're aligning the stack properly, as per the ABI requirements.  Can't
>> you just fix the tracer?
> 
> And how do we do that? The hooks that are in place have no idea of what
> happened before they were called?
> 

Furthermore, it is nonsense -- ABI stack alignment on *32 bits* is 4
bytes, not 16.

	-hpa

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.

Re: BUG: GCC-4.4.x changes the function frame on some functions

[Frederic Weisbecker]

On Thu, Nov 19, 2009 at 11:02:32AM -0500, Steven Rostedt wrote:
> On Thu, 2009-11-19 at 15:44 +0000, Andrew Haley wrote:
> > Thomas Gleixner wrote:
> 
> > We're aligning the stack properly, as per the ABI requirements.  Can't
> > you just fix the tracer?
> 
> And how do we do that? The hooks that are in place have no idea of what
> happened before they were called?
> 
> -- Steve


Yep, this is really something we can't fix from the tracer....

Re: BUG: GCC-4.4.x changes the function frame on some functions

[Thomas Gleixner]

On Thu, 19 Nov 2009, Andrew Haley wrote:
> Thomas Gleixner wrote:
> > There is no real obvious reason why the edi magic needs to be done
> > _before_ 
> > 
> > 	push   %ebp
> > 	mov    %esp,%ebp
> 
> Sure there is: unless you do the adjustment first %ebp won't be 16-aligned.

And why is this not done in 99% of the functions in the kernel, just
in this one and some random others ?
 
> We're aligning the stack properly, as per the ABI requirements.  Can't
> you just fix the tracer?

Where is that ABI requirement that

 	push   %ebp

needs to happen on an aligned stack ? 

And why is this something GCC did not care about until GCC4.4 ?

Thanks,

	tglx

Re: BUG: GCC-4.4.x changes the function frame on some functions

[Andrew Haley]

Thomas Gleixner wrote:
> On Thu, 19 Nov 2009, Andrew Haley wrote:
>> Thomas Gleixner wrote:
>>> There is no real obvious reason why the edi magic needs to be done
>>> _before_ 
>>>
>>> 	push   %ebp
>>> 	mov    %esp,%ebp
>> Sure there is: unless you do the adjustment first %ebp won't be 16-aligned.
> 
> And why is this not done in 99% of the functions in the kernel, just
> in this one and some random others ?

If I could see the function I might be able to tell you.  It's either a
performance enhancement, something to do with SSE, or it's a bug.

Andrew.

Re: BUG: GCC-4.4.x changes the function frame on some functions

[Thomas Gleixner]

On Thu, 19 Nov 2009, Andrew Haley wrote:

> Thomas Gleixner wrote:
> > On Thu, 19 Nov 2009, Andrew Haley wrote:
> >> Thomas Gleixner wrote:
> >>> There is no real obvious reason why the edi magic needs to be done
> >>> _before_ 
> >>>
> >>> 	push   %ebp
> >>> 	mov    %esp,%ebp
> >> Sure there is: unless you do the adjustment first %ebp won't be 16-aligned.
> > 
> > And why is this not done in 99% of the functions in the kernel, just
> > in this one and some random others ?
> 
> If I could see the function I might be able to tell you.  It's either a
> performance enhancement, something to do with SSE, or it's a bug.

kernel/time/timer_stats.c timer_stats_update_stats()

Here is the disassembly:

8107ad50 <timer_stats_update_stats>:
8107ad50:	57                   	push   %edi
8107ad51:	8d 7c 24 08          	lea    0x8(%esp),%edi
8107ad55:	83 e4 f0             	and    $0xfffffff0,%esp
8107ad58:	ff 77 fc             	pushl  -0x4(%edi)
8107ad5b:	55                   	push   %ebp
8107ad5c:	89 e5                	mov    %esp,%ebp
8107ad5e:	57                   	push   %edi
8107ad5f:	56                   	push   %esi
8107ad60:	53                   	push   %ebx
8107ad61:	83 ec 6c             	sub    $0x6c,%esp
8107ad64:	e8 47 92 f8 ff       	call   81003fb0 <mcount>
8107ad69:	8b 77 04             	mov    0x4(%edi),%esi
8107ad6c:	89 75 a4             	mov    %esi,-0x5c(%ebp)
8107ad6f:	65 8b 35 14 00 00 00 	mov    %gs:0x14,%esi
8107ad76:	89 75 e4             	mov    %esi,-0x1c(%ebp)
8107ad79:	31 f6                	xor    %esi,%esi
8107ad7b:	8b 35 60 5a cd 81    	mov    0x81cd5a60,%esi
8107ad81:	8b 1f                	mov    (%edi),%ebx
8107ad83:	85 f6                	test   %esi,%esi
8107ad85:	8b 7f 08             	mov    0x8(%edi),%edi
8107ad88:	75 18                	jne    8107ada2 <timer_stats_update_stats+0x52>
8107ad8a:	8b 45 e4             	mov    -0x1c(%ebp),%eax
8107ad8d:	65 33 05 14 00 00 00 	xor    %gs:0x14,%eax
8107ad94:	75 53                	jne    8107ade9 <timer_stats_update_stats+0x99>
8107ad96:	83 c4 6c             	add    $0x6c,%esp
8107ad99:	5b                   	pop    %ebx
8107ad9a:	5e                   	pop    %esi
8107ad9b:	5f                   	pop    %edi
8107ad9c:	5d                   	pop    %ebp
8107ad9d:	8d 67 f8             	lea    -0x8(%edi),%esp
8107ada0:	5f                   	pop    %edi
8107ada1:	c3                   	ret    
8107ada2:	be 00 7a d6 81       	mov    $0x81d67a00,%esi
8107ada7:	89 45 ac             	mov    %eax,-0x54(%ebp)
8107adaa:	89 75 a0             	mov    %esi,-0x60(%ebp)
8107adad:	89 5d b4             	mov    %ebx,-0x4c(%ebp)
8107adb0:	64 8b 35 78 6a d6 81 	mov    %fs:0x81d66a78,%esi
8107adb7:	8b 34 b5 20 50 cd 81 	mov    -0x7e32afe0(,%esi,4),%esi
8107adbe:	89 4d b0             	mov    %ecx,-0x50(%ebp)
8107adc1:	01 75 a0             	add    %esi,-0x60(%ebp)
8107adc4:	89 55 b8             	mov    %edx,-0x48(%ebp)
8107adc7:	8b 45 a0             	mov    -0x60(%ebp),%eax
8107adca:	89 7d c0             	mov    %edi,-0x40(%ebp)
8107adcd:	e8 de f7 76 00       	call   817ea5b0 <_spin_lock_irqsave>
8107add2:	83 3d 60 5a cd 81 00 	cmpl   $0x0,0x81cd5a60
8107add9:	89 c3                	mov    %eax,%ebx
8107addb:	75 11                	jne    8107adee <timer_stats_update_stats+0x9e>
8107addd:	89 da                	mov    %ebx,%edx
8107addf:	8b 45 a0             	mov    -0x60(%ebp),%eax
8107ade2:	e8 79 fc 76 00       	call   817eaa60 <_spin_unlock_irqrestore>
8107ade7:	eb a1                	jmp    8107ad8a <timer_stats_update_stats+0x3a>
8107ade9:	e8 52 e4 fc ff       	call   81049240 <__stack_chk_fail>
8107adee:	8d 45 a8             	lea    -0x58(%ebp),%eax
8107adf1:	8b 55 a4             	mov    -0x5c(%ebp),%edx
8107adf4:	e8 f7 fd ff ff       	call   8107abf0 <tstat_lookup>
8107adf9:	85 c0                	test   %eax,%eax
8107adfb:	74 05                	je     8107ae02 <timer_stats_update_stats+0xb2>
8107adfd:	ff 40 14             	incl   0x14(%eax)
8107ae00:	eb db                	jmp    8107addd <timer_stats_update_stats+0x8d>
8107ae02:	f0 ff 05 00 67 fd 81 	lock incl 0x81fd6700
8107ae09:	eb d2                	jmp    8107addd <timer_stats_update_stats+0x8d>
8107ae0b:	90                   	nop
8107ae0c:	90                   	nop
8107ae0d:	90                   	nop
8107ae0e:	90                   	nop
8107ae0f:	90                   	nop


There is a dozen more of those.

Thanks,

	tglx

Re: BUG: GCC-4.4.x changes the function frame on some functions

[Steven Rostedt]

On Thu, 2009-11-19 at 15:44 +0000, Andrew Haley wrote:

> We're aligning the stack properly, as per the ABI requirements.  Can't
> you just fix the tracer?

Unfortunately, this is the only fix we have:

diff --git a/kernel/trace/Kconfig b/kernel/trace/Kconfig
index b416512..cd39064 100644
--- a/kernel/trace/Kconfig
+++ b/kernel/trace/Kconfig
@@ -143,7 +143,6 @@ config FUNCTION_GRAPH_TRACER
 	bool "Kernel Function Graph Tracer"
 	depends on HAVE_FUNCTION_GRAPH_TRACER
 	depends on FUNCTION_TRACER
-	depends on !X86_32 || !CC_OPTIMIZE_FOR_SIZE
 	default y
 	help
 	  Enable the kernel to trace a function at both its return
diff --git a/kernel/trace/trace_functions_graph.c b/kernel/trace/trace_functions_graph.c
index 45e6c01..50c2251 100644
--- a/kernel/trace/trace_functions_graph.c
+++ b/kernel/trace/trace_functions_graph.c
@@ -1070,6 +1070,11 @@ static __init int init_graph_trace(void)
 {
 	max_bytes_for_cpu = snprintf(NULL, 0, "%d", nr_cpu_ids - 1);
 
+#if defined(CONFIG_X86_32 && __GNUC__ >= 4 && __GNUC_MINOR__ >= 4)
+	pr_info("WARNING: GCC 4.4.X breaks the function graph tracer on i686.\n"
+		"         The function graph tracer will be disabled.\n");
+	return -1;
+#endif
 	return register_tracer(&graph_trace);
 }
 
-- Steve

Re: BUG: GCC-4.4.x changes the function frame on some functions

[H. Peter Anvin]

On 11/19/2009 07:37 AM, Thomas Gleixner wrote:
> 
> modified function start on a handful of functions only seen with gcc
> 4.4.x on x86 32 bit:
> 
> 	push   %edi
> 	lea    0x8(%esp),%edi
> 	and    $0xfffffff0,%esp
> 	pushl  -0x4(%edi)
> 	push   %ebp
> 	mov    %esp,%ebp
> 	...
> 	call   mcount
> 

The real questions is why we're aligning the stack in the kernel.  It is
probably not what we want -- we don't use SSE for anything but a handful
of special cases in the kernel, and we don't want the overhead.

	-hpa

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.

Re: BUG: GCC-4.4.x changes the function frame on some functions

[Richard Guenther]

On Thu, Nov 19, 2009 at 4:45 PM, H. Peter Anvin <hpa@zytor.com> wrote:
> On 11/19/2009 07:37 AM, Thomas Gleixner wrote:
>>
>> modified function start on a handful of functions only seen with gcc
>> 4.4.x on x86 32 bit:
>>
>>       push   %edi
>>       lea    0x8(%esp),%edi
>>       and    $0xfffffff0,%esp
>>       pushl  -0x4(%edi)
>>       push   %ebp
>>       mov    %esp,%ebp
>>       ...
>>       call   mcount
>>
>
> The real questions is why we're aligning the stack in the kernel.  It is
> probably not what we want -- we don't use SSE for anything but a handful
> of special cases in the kernel, and we don't want the overhead.

It's likely because you have long long vars on the stack which is
faster when they are aligned.  -mno-stackrealign may do what you
want (or may not, I have not checked).  I assume you already
use -mpreferred-stack-boundary=2.

Richard.

Re: BUG: GCC-4.4.x changes the function frame on some functions

[Richard Guenther]

On Thu, Nov 19, 2009 at 4:49 PM, Richard Guenther
<richard.guenther@gmail.com> wrote:
> On Thu, Nov 19, 2009 at 4:45 PM, H. Peter Anvin <hpa@zytor.com> wrote:
>> On 11/19/2009 07:37 AM, Thomas Gleixner wrote:
>>>
>>> modified function start on a handful of functions only seen with gcc
>>> 4.4.x on x86 32 bit:
>>>
>>>       push   %edi
>>>       lea    0x8(%esp),%edi
>>>       and    $0xfffffff0,%esp
>>>       pushl  -0x4(%edi)
>>>       push   %ebp
>>>       mov    %esp,%ebp
>>>       ...
>>>       call   mcount
>>>
>>
>> The real questions is why we're aligning the stack in the kernel.  It is
>> probably not what we want -- we don't use SSE for anything but a handful
>> of special cases in the kernel, and we don't want the overhead.
>
> It's likely because you have long long vars on the stack which is
> faster when they are aligned.  -mno-stackrealign may do what you
> want (or may not, I have not checked).  I assume you already
> use -mpreferred-stack-boundary=2.

Just checking it seems you must be using -mincoming-stack-boundary=2
instead but keep the preferred stack boundary at 4.

Richard.

Re: BUG: GCC-4.4.x changes the function frame on some functions

[Andi Kleen]

Richard Guenther <richard.guenther@gmail.com> writes:
>
> It's likely because you have long long vars on the stack which is
> faster when they are aligned.

It's not faster for 32bit.

-Andi

-- 
ak@linux.intel.com -- Speaking for myself only.

Re: BUG: GCC-4.4.x changes the function frame on some functions

[Linus Torvalds]

On Thu, 19 Nov 2009, Thomas Gleixner wrote:
> 
> standard function start:
> 
> 	 push	%ebp
> 	 mov	%esp, %ebp
> 	 ....
> 	 call   mcount
> 
> modified function start on a handful of functions only seen with gcc
> 4.4.x on x86 32 bit:
> 
> 	push   %edi
> 	lea    0x8(%esp),%edi
> 	and    $0xfffffff0,%esp
> 	pushl  -0x4(%edi)
> 	push   %ebp
> 	mov    %esp,%ebp
> 	...
> 	call   mcount

That's some crazy sh*t anyway, since we don't _want_ the stack to be 
16-byte aligned in the kernel. We do

        KBUILD_CFLAGS += $(call cc-option,-mpreferred-stack-boundary=2)

why is that not working?

So this looks like a gcc bug, plain and simple.

> This modification leads to a hard to solve problem in the kernel
> function graph tracer which assumes that the stack looks like:
> 
>        return address
>        saved  ebp

Umm. But it still does, doesn't it? That

	pushl  -0x4(%edi)
	push   %ebp

should do it - the "-0x4(%edi)" thing seems to be trying to reload the 
return address. No? 

Maybe I misread the code - but regardless, it does look like a gcc code 
generation bug if only because we really don't want a 16-byte aligned 
stack anyway, and have asked for it to not be done.

So I agree that gcc shouldn't do that crazy prologue (and certainly _not_ 
before calling mcount anyway), but I'm not sure I agree with that detail 
of your analysis or explanation.

				Linus

Re: BUG: GCC-4.4.x changes the function frame on some functions

[Thomas Gleixner]

On Thu, 19 Nov 2009, Linus Torvalds wrote:
> Umm. But it still does, doesn't it? That
> 
> 	pushl  -0x4(%edi)
> 	push   %ebp
> 
> should do it - the "-0x4(%edi)" thing seems to be trying to reload the 
> return address. No? 
> 
> Maybe I misread the code - but regardless, it does look like a gcc code 
> generation bug if only because we really don't want a 16-byte aligned 
> stack anyway, and have asked for it to not be done.
> 
> So I agree that gcc shouldn't do that crazy prologue (and certainly _not_ 
> before calling mcount anyway), but I'm not sure I agree with that detail 
> of your analysis or explanation.

Yes, it does store the return address before the pushed ebp, but this
is a copy of the real stack entry which is before the pushed edi.

The function graph tracer needs to redirect the return into the tracer
and it therefor saves the real return address and modifies the stack
so the return ends up in the tracer code which then goes back to the
real return address.

But in this prologue/aligment case we modify the copy and not the real
return address on the stack, so we return without calling into the
tracer which is causing the headache because the state of the tracer
becomes confused.

Thanks,

	tglx

Re: BUG: GCC-4.4.x changes the function frame on some functions

[Steven Rostedt]

On Thu, 2009-11-19 at 09:39 -0800, Linus Torvalds wrote:

> > This modification leads to a hard to solve problem in the kernel
> > function graph tracer which assumes that the stack looks like:
> > 
> >        return address
> >        saved  ebp
> 
> Umm. But it still does, doesn't it? That
> 
> 	pushl  -0x4(%edi)
> 	push   %ebp
> 
> should do it - the "-0x4(%edi)" thing seems to be trying to reload the 
> return address. No? 

Yes that is what it is doing. The problem we have is that it is putting
into the frame pointer a "copy" of the return address, and not the
actual pointer. Which is fine for the function tracer, but breaks the
function graph tracer (which is a much more powerful tracer).

Technically, this is all that mcount must have. And yes, we are making
an assumption that the return address in the frame pointer is the one
that will be used to leave the function. But the reason for making this
copy just seems to be all messed up.

I don't know if the ABI says anything about the return address in the
frame pointer must be the actual return address. But it would be nice if
the gcc folks would let us guarantee that it is.

-- Steve

Re: BUG: GCC-4.4.x changes the function frame on some functions

[Richard Guenther]

On Thu, Nov 19, 2009 at 6:59 PM, Steven Rostedt <rostedt@goodmis.org> wrote:
> On Thu, 2009-11-19 at 09:39 -0800, Linus Torvalds wrote:
>
>> > This modification leads to a hard to solve problem in the kernel
>> > function graph tracer which assumes that the stack looks like:
>> >
>> >        return address
>> >        saved  ebp
>>
>> Umm. But it still does, doesn't it? That
>>
>>       pushl  -0x4(%edi)
>>       push   %ebp
>>
>> should do it - the "-0x4(%edi)" thing seems to be trying to reload the
>> return address. No?
>
> Yes that is what it is doing. The problem we have is that it is putting
> into the frame pointer a "copy" of the return address, and not the
> actual pointer. Which is fine for the function tracer, but breaks the
> function graph tracer (which is a much more powerful tracer).
>
> Technically, this is all that mcount must have. And yes, we are making
> an assumption that the return address in the frame pointer is the one
> that will be used to leave the function. But the reason for making this
> copy just seems to be all messed up.
>
> I don't know if the ABI says anything about the return address in the
> frame pointer must be the actual return address. But it would be nice if
> the gcc folks would let us guarantee that it is.

Note that I only can reproduce the issue with
-mincoming-stack-boundary=2, not with -mpreferred-stack-boundary=2.
And
you didn't provide us with a testcase either ... so please open
a bugzilla and attach preprocessed source of a file that
shows the problem, note the function it happens in and provide
the command-line options you used for building.

Otherwise it's going to be all speculation on our side.

Thanks,
Richard.

Re: BUG: GCC-4.4.x changes the function frame on some functions

[Andrew Haley]

Richard Guenther wrote:

> And
> you didn't provide us with a testcase either ... so please open
> a bugzilla and attach preprocessed source of a file that
> shows the problem, note the function it happens in and provide
> the command-line options you used for building.

I've got all that off-list.  I found the cause, and replied in another
email.  It's not a bug.

Andrew.

Re: BUG: GCC-4.4.x changes the function frame on some functions

[Linus Torvalds]

On Thu, 19 Nov 2009, Andrew Haley wrote:
> 
> I've got all that off-list.  I found the cause, and replied in another
> email.  It's not a bug.

Oh Gods, are we back to gcc people saying "sure, we do stupid things, but 
it's allowed, so we don't consider it a bug because it doesn't matter that 
real people care about real life, we only care about some paper, and real 
life doesn't matter, if it's 'undefined' we can make our idiotic choices 
regardless of what people need, and regardless of whether it actually 
generates better code or not".

		Linus

Re: BUG: GCC-4.4.x changes the function frame on some functions

[Linus Torvalds]

On Thu, 19 Nov 2009, Linus Torvalds wrote:
> 
> Oh Gods, are we back to gcc people saying "sure, we do stupid things, but 
> it's allowed, so we don't consider it a bug because it doesn't matter that 
> real people care about real life, we only care about some paper, and real 
> life doesn't matter, if it's 'undefined' we can make our idiotic choices 
> regardless of what people need, and regardless of whether it actually 
> generates better code or not".

Put another way: the stack alignment itself may not be a bug, but gcc 
generating God-awful code for the mcount handling that results in problems 
in real life sure as hell is *stupid* enough to be called a bug.

I bet other people than just the kernel use the mcount hook for subtler 
things than just doing profiles. And even if they don't, the quoted code 
generation is just crazy _crap_.

		Linus

Re: BUG: GCC-4.4.x changes the function frame on some functions

[Linus Torvalds]

On Thu, 19 Nov 2009, Linus Torvalds wrote:
> 
> I bet other people than just the kernel use the mcount hook for subtler 
> things than just doing profiles. And even if they don't, the quoted code 
> generation is just crazy _crap_.

For the kernel, if the only case is that timer_stat.c thing that Thomas 
pointed at, I guess we can at least work around it with something like the 
appended. The kernel code is certainly ugly too, no question about that. 

It's just that we'd like to be able to depend on mcount code generation 
not being insane even in the presense of ugly code..

The alternative would be to have some warning when this happens, so that 
we can at least see it. "mcount won't work reliably"

		Linus

---
 kernel/time/timer_stats.c |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/kernel/time/timer_stats.c b/kernel/time/timer_stats.c
index ee5681f..488c7b8 100644
--- a/kernel/time/timer_stats.c
+++ b/kernel/time/timer_stats.c
@@ -76,7 +76,7 @@ struct entry {
 	 */
 	char			comm[TASK_COMM_LEN + 1];
 
-} ____cacheline_aligned_in_smp;
+};
 
 /*
  * Spinlock protecting the tables - not taken during lookup:
@@ -114,7 +114,7 @@ static ktime_t time_start, time_stop;
 #define MAX_ENTRIES		(1UL << MAX_ENTRIES_BITS)
 
 static unsigned long nr_entries;
-static struct entry entries[MAX_ENTRIES];
+static struct entry entries[MAX_ENTRIES] ____cacheline_aligned_in_smp;
 
 static atomic_t overflow_count;
 

Re: BUG: GCC-4.4.x changes the function frame on some functions

[Thomas Gleixner]

On Thu, 19 Nov 2009, Linus Torvalds wrote:
> > I bet other people than just the kernel use the mcount hook for subtler 
> > things than just doing profiles. And even if they don't, the quoted code 
> > generation is just crazy _crap_.
> 
> For the kernel, if the only case is that timer_stat.c thing that Thomas 
> pointed at, I guess we can at least work around it with something like the 
> appended. The kernel code is certainly ugly too, no question about that. 
> 
> It's just that we'd like to be able to depend on mcount code generation 
> not being insane even in the presense of ugly code..
> 
> The alternative would be to have some warning when this happens, so that 
> we can at least see it. "mcount won't work reliably"

There are at least 20 other random functions which have the same
problem. Have not looked at the details yet.

Just compiled with -mincoming-stack-boundary=4 and the problem goes
away as gcc now thinks that the incoming stack is already 16 byte
aligned. But that might break code which actually uses SSE

Thanks,

	tglx

Re: BUG: GCC-4.4.x changes the function frame on some functions

[Jakub Jelinek]

On Thu, Nov 19, 2009 at 08:01:57PM +0100, Thomas Gleixner wrote:
> Just compiled with -mincoming-stack-boundary=4 and the problem goes
> away as gcc now thinks that the incoming stack is already 16 byte
> aligned. But that might break code which actually uses SSE

Please don't do this, lying to the compiler is just going to result in
wrong-code sooner or later, with the above switch gcc will assume the
incoming stack is 16-byte aligned (which is not true in the ix86 kernel)
and could very well e.g. optimize away code that looks at
alignment of stack variables etc.

	Jakub

Re: BUG: GCC-4.4.x changes the function frame on some functions

[Thomas Gleixner]

On Mon, 23 Nov 2009, Jakub Jelinek wrote:

> On Thu, Nov 19, 2009 at 08:01:57PM +0100, Thomas Gleixner wrote:
> > Just compiled with -mincoming-stack-boundary=4 and the problem goes
> > away as gcc now thinks that the incoming stack is already 16 byte
> > aligned. But that might break code which actually uses SSE
> 
> Please don't do this, lying to the compiler is just going to result in
> wrong-code sooner or later, with the above switch gcc will assume the
> incoming stack is 16-byte aligned (which is not true in the ix86 kernel)
> and could very well e.g. optimize away code that looks at
> alignment of stack variables etc.

Right. I gave up the idea pretty fast. But in the current situation we
are forced to lie to the compiler in some way. Forcing -mtune=generic
when the function graph tracer is enabled seems to be a halfways sane
work around.

Thanks,

	tglx

Re: BUG: GCC-4.4.x changes the function frame on some functions

[David Daney]

Linus Torvalds wrote:
> 
> On Thu, 19 Nov 2009, Linus Torvalds wrote:
>> I bet other people than just the kernel use the mcount hook for subtler 
>> things than just doing profiles. And even if they don't, the quoted code 
>> generation is just crazy _crap_.
> 
> For the kernel, if the only case is that timer_stat.c thing that Thomas 
> pointed at, I guess we can at least work around it with something like the 
> appended. The kernel code is certainly ugly too, no question about that. 
> 
> It's just that we'd like to be able to depend on mcount code generation 
> not being insane even in the presense of ugly code..
> 
> The alternative would be to have some warning when this happens, so that 
> we can at least see it. "mcount won't work reliably"
> 

For the MIPS port of GCC and Linux I recently added the 
-mmcount-ra-address switch.  It causes the location of the return 
address (on the stack) to be passed to mcount in a scratch register.

Perhaps something similar could be done for x86.  It would make this 
patching of the return location more reliable at the expense of more 
code at the mcount invocation site.

For the MIPS case the code size doesn't increase, as it is done in the 
delay slot of the call instruction, which would otherwise be a nop.

David Daney

Re: BUG: GCC-4.4.x changes the function frame on some functions

[Steven Rostedt]

On Thu, 2009-11-19 at 11:10 -0800, David Daney wrote:
> Linus Torvalds wrote:

> For the MIPS port of GCC and Linux I recently added the 
> -mmcount-ra-address switch.  It causes the location of the return 
> address (on the stack) to be passed to mcount in a scratch register.

Hehe, scratch register on i686 ;-)

i686 has no extra regs. It just has:

%eax, %ebx, %ecx, %edx - as the general purpose regs
%esp - stack
%ebp - frame pointer
%edi, %esi - counter regs

That's just 8 regs, and half of those are special.

> 
> Perhaps something similar could be done for x86.  It would make this 
> patching of the return location more reliable at the expense of more 
> code at the mcount invocation site.

I rather not put any more code in the call site.

> 
> For the MIPS case the code size doesn't increase, as it is done in the 
> delay slot of the call instruction, which would otherwise be a nop.

I showed in a previous post what the best would be for x86. That is just
calling mcount at the very beginning of the function. The return address
is automatically pushed onto the stack.

Perhaps we could create another profiler? Instead of calling mcount,
call a new function: __fentry__ or something. Have it activated with
another switch. This could make the performance of the function tracer
even better without all these exceptions.

	<function>:
		call __fentry__
		[...]

	
-- Steve

Re: BUG: GCC-4.4.x changes the function frame on some functions

[Frederic Weisbecker]

On Thu, Nov 19, 2009 at 02:28:06PM -0500, Steven Rostedt wrote:
> On Thu, 2009-11-19 at 11:10 -0800, David Daney wrote:
> > Linus Torvalds wrote:
> 
> > For the MIPS port of GCC and Linux I recently added the 
> > -mmcount-ra-address switch.  It causes the location of the return 
> > address (on the stack) to be passed to mcount in a scratch register.
> 
> Hehe, scratch register on i686 ;-)
> 
> i686 has no extra regs. It just has:
> 
> %eax, %ebx, %ecx, %edx - as the general purpose regs
> %esp - stack
> %ebp - frame pointer
> %edi, %esi - counter regs
> 
> That's just 8 regs, and half of those are special.
> 
> > 
> > Perhaps something similar could be done for x86.  It would make this 
> > patching of the return location more reliable at the expense of more 
> > code at the mcount invocation site.
> 
> I rather not put any more code in the call site.
> 
> > 
> > For the MIPS case the code size doesn't increase, as it is done in the 
> > delay slot of the call instruction, which would otherwise be a nop.
> 
> I showed in a previous post what the best would be for x86. That is just
> calling mcount at the very beginning of the function. The return address
> is automatically pushed onto the stack.
> Perhaps we could create another profiler? Instead of calling mcount,
> call a new function: __fentry__ or something. Have it activated with
> another switch. This could make the performance of the function tracer
> even better without all these exceptions.
> 
> 	<function>:
> 		call __fentry__
> 		[...]
> 
> 	
> -- Steve


I would really like this. So that we can forget about other possible
further suprises due to sophisticated function prologues beeing before
the mcount call.

And I guess that would fix it in every archs.

That said, Linus had a good point about the fact there might other uses
of mcount even more tricky than what does the function graph tracer,
outside the kernel, and those may depend on the strict ABI assumption
that 4(ebp) is always the _real_ return address, and that through all
the previous stack call. This is even a concern that extrapolates the
single mcount case.

So I wonder that actually the real problem is the lack of something that
could provide this guarantee. We may need a -real-ra-before-fp (yeah
I suck in naming).

Re: BUG: GCC-4.4.x changes the function frame on some functions

[Kai Tietz]

2009/11/19 Frederic Weisbecker <fweisbec@gmail.com>:
> I would really like this. So that we can forget about other possible
> further suprises due to sophisticated function prologues beeing before
> the mcount call.
>
> And I guess that would fix it in every archs.

My 5 cent for this, too.

> That said, Linus had a good point about the fact there might other uses
> of mcount even more tricky than what does the function graph tracer,
> outside the kernel, and those may depend on the strict ABI assumption
> that 4(ebp) is always the _real_ return address, and that through all
> the previous stack call. This is even a concern that extrapolates the
> single mcount case.
>
> So I wonder that actually the real problem is the lack of something that
> could provide this guarantee. We may need a -real-ra-before-fp (yeah
> I suck in naming).

There are, especially in windows world. We noticed that for example
the Sun's JDK (which is compiled by VC) can be used in gcc compiled
code only by -fno-omit-frame-pointer, as otherwise it fails badly
reasoned by wrong ebp accesses.

Kai

-- 
|  (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| (")_(") him gain world domination

Re: BUG: GCC-4.4.x changes the function frame on some functions

[Frederic Weisbecker]

On Thu, Nov 19, 2009 at 08:54:56PM +0100, Kai Tietz wrote:
> 2009/11/19 Frederic Weisbecker <fweisbec@gmail.com>:
> > I would really like this. So that we can forget about other possible
> > further suprises due to sophisticated function prologues beeing before
> > the mcount call.
> >
> > And I guess that would fix it in every archs.
> 
> My 5 cent for this, too.
> 
> > That said, Linus had a good point about the fact there might other uses
> > of mcount even more tricky than what does the function graph tracer,
> > outside the kernel, and those may depend on the strict ABI assumption
> > that 4(ebp) is always the _real_ return address, and that through all
> > the previous stack call. This is even a concern that extrapolates the
> > single mcount case.
> >
> > So I wonder that actually the real problem is the lack of something that
> > could provide this guarantee. We may need a -real-ra-before-fp (yeah
> > I suck in naming).
> 
> There are, especially in windows world. We noticed that for example
> the Sun's JDK (which is compiled by VC) can be used in gcc compiled
> code only by -fno-omit-frame-pointer, as otherwise it fails badly
> reasoned by wrong ebp accesses.


Yeah but what we need is not only to ensure ebp is used as the frame
pointer but also that ebp + 4 is really the address that will be used
to return to the caller, and not a copy of the return value.

Re: BUG: GCC-4.4.x changes the function frame on some functions

[Steven Rostedt]

On Thu, 2009-11-19 at 20:46 +0100, Frederic Weisbecker wrote:
> On Thu, Nov 19, 2009 at 02:28:06PM -0500, Steven Rostedt wrote:

> > 	<function>:
> > 		call __fentry__
> > 		[...]
> > 
> > 	
> > -- Steve
> 
> 
> I would really like this. So that we can forget about other possible
> further suprises due to sophisticated function prologues beeing before
> the mcount call.
> 
> And I guess that would fix it in every archs.

Well, other archs use a register to store the return address. But it
would also be easy to do (pseudo arch assembly):

	<function>:
		mov lr, (%sp)
		add 8, %sp
		blr __fentry__
		sub 8, %sp
		mov (%sp), lr


That way the lr would have the current function, and the parent would
still be at 8(%sp)

		
> 
> That said, Linus had a good point about the fact there might other uses
> of mcount even more tricky than what does the function graph tracer,
> outside the kernel, and those may depend on the strict ABI assumption
> that 4(ebp) is always the _real_ return address, and that through all
> the previous stack call. This is even a concern that extrapolates the
> single mcount case.

As I am proposing a new call. This means that mcount stay as is for
legacy reasons. Yes I know there exists the -finstrument-functions but
that adds way too much bloat to the code. One single call to the
profiler is all I want.


> 
> So I wonder that actually the real problem is the lack of something that
> could provide this guarantee. We may need a -real-ra-before-fp (yeah
> I suck in naming).

Don't worry, so do the C compiler folks, I mean, come on "mcount"?

-- Steve

Re: BUG: GCC-4.4.x changes the function frame on some functions

[Steven Rostedt]

On Thu, 2009-11-19 at 15:05 -0500, Steven Rostedt wrote:

> Well, other archs use a register to store the return address. But it
> would also be easy to do (pseudo arch assembly):
> 
> 	<function>:
> 		mov lr, (%sp)
> 		add 8, %sp
> 		blr __fentry__

Should be bl __fentry__ for "branch and link".

> 		sub 8, %sp
> 		mov (%sp), lr
> 
> 
> That way the lr would have the current function, and the parent would
> still be at 8(%sp)

Actually, if we add a new profiler and can make our own specification, I
would say that the add and sub lines be the responsibility of
__fentry__. Then we would have:

	<function>:
		mov lr, (%sp)
		bl __fentry__
		mov (%sp), lr

If sp points to the current content, then replace (%sp) above with 
-8(%sp).  Then the implementation of a nop __fentry__ would simply be:

	__fentry__:
		blr

For anything more elaborate, __fentry__ would be responsible for all
adjustments.

-- Steve

Re: BUG: GCC-4.4.x changes the function frame on some functions

[Frederic Weisbecker]

On Thu, Nov 19, 2009 at 03:17:16PM -0500, Steven Rostedt wrote:
> On Thu, 2009-11-19 at 15:05 -0500, Steven Rostedt wrote:
> 
> > Well, other archs use a register to store the return address. But it
> > would also be easy to do (pseudo arch assembly):
> > 
> > 	<function>:
> > 		mov lr, (%sp)
> > 		add 8, %sp
> > 		blr __fentry__
> 
> Should be bl __fentry__ for "branch and link".
> 
> > 		sub 8, %sp
> > 		mov (%sp), lr
> > 
> > 
> > That way the lr would have the current function, and the parent would
> > still be at 8(%sp)
> 
> Actually, if we add a new profiler and can make our own specification, I
> would say that the add and sub lines be the responsibility of
> __fentry__. Then we would have:
> 
> 	<function>:
> 		mov lr, (%sp)
> 		bl __fentry__
> 		mov (%sp), lr
> 
> If sp points to the current content, then replace (%sp) above with 
> -8(%sp).  Then the implementation of a nop __fentry__ would simply be:
> 
> 	__fentry__:
> 		blr


Good point!

 
> For anything more elaborate, __fentry__ would be responsible for all
> adjustments.


Yep. The more we control it from __fentry__, the less we fall
down into unexpected surprises.

Re: BUG: GCC-4.4.x changes the function frame on some functions

[Frederic Weisbecker]

On Thu, Nov 19, 2009 at 03:05:41PM -0500, Steven Rostedt wrote:
> On Thu, 2009-11-19 at 20:46 +0100, Frederic Weisbecker wrote:
> > On Thu, Nov 19, 2009 at 02:28:06PM -0500, Steven Rostedt wrote:
> 
> > > 	<function>:
> > > 		call __fentry__
> > > 		[...]
> > > 
> > > 	
> > > -- Steve
> > 
> > 
> > I would really like this. So that we can forget about other possible
> > further suprises due to sophisticated function prologues beeing before
> > the mcount call.
> > 
> > And I guess that would fix it in every archs.
> 
> Well, other archs use a register to store the return address. But it
> would also be easy to do (pseudo arch assembly):
> 
> 	<function>:
> 		mov lr, (%sp)
> 		add 8, %sp
> 		blr __fentry__
> 		sub 8, %sp
> 		mov (%sp), lr
> 
> 
> That way the lr would have the current function, and the parent would
> still be at 8(%sp)
> 


Yeah right, we need at least such very tiny prologue for
archs that store return addresses in a reg.

	
> > 
> > That said, Linus had a good point about the fact there might other uses
> > of mcount even more tricky than what does the function graph tracer,
> > outside the kernel, and those may depend on the strict ABI assumption
> > that 4(ebp) is always the _real_ return address, and that through all
> > the previous stack call. This is even a concern that extrapolates the
> > single mcount case.
> 
> As I am proposing a new call. This means that mcount stay as is for
> legacy reasons. Yes I know there exists the -finstrument-functions but
> that adds way too much bloat to the code. One single call to the
> profiler is all I want.


Sure, the purpose is not to change the existing -mcount thing.
What I meant is that we could have -mcount and -real-ra-before-fp
at the same time to guarantee fp + 4 is really what we want while
using -mcount.

The __fentry__ idea is more neat, but the guarantee of a real pointer
to the return address is still something that lacks.


> > 
> > So I wonder that actually the real problem is the lack of something that
> > could provide this guarantee. We may need a -real-ra-before-fp (yeah
> > I suck in naming).
> 
> Don't worry, so do the C compiler folks, I mean, come on "mcount"?


I guess it has been first created for the single purpose of counting
specific functions but then it has been used for wider, unpredicted uses :)

Re: BUG: GCC-4.4.x changes the function frame on some functions

[Linus Torvalds]

On Thu, 19 Nov 2009, Frederic Weisbecker wrote:
>
> > That way the lr would have the current function, and the parent would
> > still be at 8(%sp)
> 
> Yeah right, we need at least such very tiny prologue for
> archs that store return addresses in a reg.

Well, it will be architecture-dependent.

For example, alpha can store the return value in _any_ register if I 
recall correctly, so you can do the "call to __fentry__" by just picking 
another register than the default one as the return address.

And powerpc has two special registers: link and ctr, but iirc you can only 
load 'link' with a branch instruction. Which means that you could do 
something like 

	mflr 0
	bl __fentry__

in the caller (I forget if R0 is actually a call-trashed register or not), 
and then __fentry__ could do something like

	mflr 12		# save _new_ link
	mtlr 0		# restore original link
	mtctr 12	# move __fentry__ link to ctr
	.. do whatever ..
	bctr		# return to __fentry__ caller

to return with 'link' restored (but ctr and r0/r12 trashed - I don't 
recall the ppc calling conventions any more, but I think that is ok).

Saving to stack seems unnecessary and pointless.

            Linus

Re: BUG: GCC-4.4.x changes the function frame on some functions

[Steven Rostedt]

On Thu, 2009-11-19 at 12:36 -0800, Linus Torvalds wrote:
> 
> On Thu, 19 Nov 2009, Frederic Weisbecker wrote:
> >
> > > That way the lr would have the current function, and the parent would
> > > still be at 8(%sp)
> > 
> > Yeah right, we need at least such very tiny prologue for
> > archs that store return addresses in a reg.
> 
> Well, it will be architecture-dependent.

Totally agree, as mcount today is architecture dependent.

> 
> For example, alpha can store the return value in _any_ register if I 
> recall correctly, so you can do the "call to __fentry__" by just picking 
> another register than the default one as the return address.
> 
> And powerpc has two special registers: link and ctr, but iirc you can only 
> load 'link' with a branch instruction. Which means that you could do 
> something like 
> 
> 	mflr 0
> 	bl __fentry__
> 
> in the caller (I forget if R0 is actually a call-trashed register or not), 
> and then __fentry__ could do something like
> 
> 	mflr 12		# save _new_ link
> 	mtlr 0		# restore original link
> 	mtctr 12	# move __fentry__ link to ctr
> 	.. do whatever ..
> 	bctr		# return to __fentry__ caller
> 
> to return with 'link' restored (but ctr and r0/r12 trashed - I don't 
> recall the ppc calling conventions any more, but I think that is ok).
> 
> Saving to stack seems unnecessary and pointless.

I was just using an example. But as you pointed out, each arch can find
its best way to handle it. Having the profiler called at the beginning
of the function is what I feel is the best.

We also get access to the function's parameters :-)


-- Steve

Re: BUG: GCC-4.4.x changes the function frame on some functions

[H. Peter Anvin]

On 11/19/2009 11:28 AM, Steven Rostedt wrote:
> 
> Hehe, scratch register on i686 ;-)
> 
> i686 has no extra regs. It just has:
> 
> %eax, %ebx, %ecx, %edx - as the general purpose regs
> %esp - stack
> %ebp - frame pointer
> %edi, %esi - counter regs
> 
> That's just 8 regs, and half of those are special.
> 

For a modern ABI it is better described as:

	%eax, %edx, %ecx	- argument/return/scratch registers
	%ebx, %esi, %edi	- saved registers
	%esp			- stack pointer
	%ebp			- frame pointer (saved)

> Perhaps we could create another profiler? Instead of calling mcount,
> call a new function: __fentry__ or something. Have it activated with
> another switch. This could make the performance of the function tracer
> even better without all these exceptions.
> 
> 	<function>:
> 		call __fentry__
> 		[...]
> 

Calling the profiler immediately at the entry point is clearly the more
sane option.  It means the ABI is well-defined, stable, and independent
of what the actual function contents are.  It means that ABI isn't the
normal C ABI (the __fentry__ function would have to preserve all
registers), but that's fine...

	-hpa

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.

Re: BUG: GCC-4.4.x changes the function frame on some functions

[Linus Torvalds]

On Thu, 19 Nov 2009, H. Peter Anvin wrote:
> 
> Calling the profiler immediately at the entry point is clearly the more
> sane option.  It means the ABI is well-defined, stable, and independent
> of what the actual function contents are.  It means that ABI isn't the
> normal C ABI (the __fentry__ function would have to preserve all
> registers), but that's fine...

As far as I know, that's true of _mcount already: it's not a normal ABI 
and is rather a highly architecture-specific special case to begin with. 
At least ARM has some (several?) special mcount calling conventions, 
afaik.

(And then ARM people use __attribute__((naked)) and insert the code by 
inline asm, or something. That seems to be "standard" in the embedded 
world, where they often do even stranger things than we do in the 
kernel. At least our low-level system call and interrupt handlers are 
written as assembly language - the embedded world seems to commonly 
write them as C functions with magic attributes and inline asm).

		Linus

Re: BUG: GCC-4.4.x changes the function frame on some functions

[Jeff Law]

On 11/19/09 13:06, Linus Torvalds wrote:
>
> On Thu, 19 Nov 2009, H. Peter Anvin wrote:
>    
>> Calling the profiler immediately at the entry point is clearly the more
>> sane option.  It means the ABI is well-defined, stable, and independent
>> of what the actual function contents are.  It means that ABI isn't the
>> normal C ABI (the __fentry__ function would have to preserve all
>> registers), but that's fine...
>>      
> As far as I know, that's true of _mcount already: it's not a normal ABI
> and is rather a highly architecture-specific special case to begin with.
> At least ARM has some (several?) special mcount calling conventions,
> afaik.
>    
Correct.  _mcount's ABI typically has been defined by the implementation 
of the vendor's C library mcount.

GCC has options to emit the profiling code prior to or after the 
prologue controllable through the usual variety of target macros & 
hooks.  I can't imagine anyone would object to a clean, tested patch to 
change how x86-linux's profiling code was implemented.

jeff

Re: BUG: GCC-4.4.x changes the function frame on some functions

[Steven Rostedt]

On Thu, 2009-11-19 at 11:50 -0800, H. Peter Anvin wrote:

> > Perhaps we could create another profiler? Instead of calling mcount,
> > call a new function: __fentry__ or something. Have it activated with
> > another switch. This could make the performance of the function tracer
> > even better without all these exceptions.
> > 
> > 	<function>:
> > 		call __fentry__
> > 		[...]
> > 
> 
> Calling the profiler immediately at the entry point is clearly the more
> sane option.  It means the ABI is well-defined, stable, and independent
> of what the actual function contents are.  It means that ABI isn't the
> normal C ABI (the __fentry__ function would have to preserve all
> registers), but that's fine...

mcount already has that requirement (saving all/most regs). Anyway, you
are right, we don't care. The tracer should carry the blunt of the load,
not the individual callers.

-- Steve

Re: BUG: GCC-4.4.x changes the function frame on some functions

[Jeff Law]

On 11/19/09 12:50, H. Peter Anvin wrote:
>
> Calling the profiler immediately at the entry point is clearly the more
> sane option.  It means the ABI is well-defined, stable, and independent
> of what the actual function contents are.  It means that ABI isn't the
> normal C ABI (the __fentry__ function would have to preserve all
> registers), but that's fine...
>    
Note there are targets (even some old x86 variants) that required the 
profiling calls to occur after the prologue.  Unfortunately, nobody 
documented *why* that  was the case.   Sigh.

Jeff

Re: BUG: GCC-4.4.x changes the function frame on some functions

[Thomas Gleixner]

On Thu, 19 Nov 2009, Richard Guenther wrote:
> Note that I only can reproduce the issue with
> -mincoming-stack-boundary=2, not with -mpreferred-stack-boundary=2.
> And
> you didn't provide us with a testcase either ... so please open
> a bugzilla and attach preprocessed source of a file that
> shows the problem, note the function it happens in and provide
> the command-line options you used for building.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42109

Thanks,

	tglx

Re: BUG: GCC-4.4.x changes the function frame on some functions

[Linus Torvalds]

On Thu, 19 Nov 2009, Richard Guenther wrote:
> 
> Note that I only can reproduce the issue with
> -mincoming-stack-boundary=2, not with -mpreferred-stack-boundary=2.

Since you can reproduce it with -mincoming-stack-boundary=2, I woul 
suggest just fixing mcount handling that way regardless of anything else. 
The current code generated by gcc is just insane - even for the case where 
you _want_ 16-byte stack alignment.

Instead crazy code like

>       push   %edi
>       lea    0x8(%esp),%edi
>       and    $0xfffffff0,%esp
>       pushl  -0x4(%edi)
>       push   %ebp
>       mov    %esp,%ebp
>       ...
>       call   mcount

the sane thing to do would be to just do it as

	push   %ebp
	mov    %esp,%ebp
	call   mcount
	and    $0xfffffff0,%esp

since

 - no sane 'mcount' implementation can ever care about 16-byte stack 
   alignment anyway, so aliging the stack before mcount is crazy.

 - mcount is special anyway, and is the only thing that cares about that 
   whole ebp/return address thing is mcount, and _all_ your games with 
   %edi are about that mcount thing.

IOW, once you as a compiler person understand that the 'mcount' call is 
special, you should have realized that all the work you did for it was 
totally pointless and stupid to begin with. 

You must already have that special mcount logic (the whole code to save a 
register early and push the fake mcount stack frame), so instead of _that_ 
special logic, change it to a different mcount special logic that 
associates the 'mcount' call with theframe pointer pushing. 

That will not only make the Linux kernel tracer happy, it will make all 
your _other_ users happier too, since you can generate smaller and more 
efficient code.

Admittedly, anybody who compiles with -pg probably doesn't care deeply 
about smaller and more efficient code, since the mcount call overhead 
tends to make the thing moot anyway, but it really looks like a win-win 
situation to just fix the mcount call sequence regardless.

> And you didn't provide us with a testcase either ... so please open a 
> bugzilla and attach preprocessed source of a file that shows the 
> problem, note the function it happens in and provide the command-line 
> options you used for building.
> 
> Otherwise it's going to be all speculation on our side.

See above - all you need to do is to just fix mcount calling.

Now, there is a separate bug that shows that you seem to over-align the 
stack when not asked for, and yes, since we noticed that I hope that 
Thomas and friends will fix that, but I think your mcount logic could (and 
should) be fixed as an independent sillyness.

			Linus

Re: BUG: GCC-4.4.x changes the function frame on some functions

[Ingo Molnar]

* Linus Torvalds <torvalds@linux-foundation.org> wrote:

> Admittedly, anybody who compiles with -pg probably doesn't care deeply 
> about smaller and more efficient code, since the mcount call overhead 
> tends to make the thing moot anyway, but it really looks like a 
> win-win situation to just fix the mcount call sequence regardless.

Just a sidenote: due to dyn-ftrace, which patches out all mcounts during 
bootup to be NOPs (and opt-in patches them in again if someone runs the 
function tracer), the cost is not as large as one would have it with say 
-pg based user-space profiling.

It's not completely zero-cost as the pure NOPs balloon the i$ footprint 
a bit and GCC generates different code too in some cases. But it's 
certainly good enough that it's generally pretty hard to prove overhead 
via micro or macro benchmarks that the patched out mcounts call sites 
are there.

	Ingo

Re: BUG: GCC-4.4.x changes the function frame on some functions

[Steven Rostedt]

On Thu, 2009-11-19 at 19:47 +0100, Ingo Molnar wrote:
> * Linus Torvalds <torvalds@linux-foundation.org> wrote:
> 
> > Admittedly, anybody who compiles with -pg probably doesn't care deeply 
> > about smaller and more efficient code, since the mcount call overhead 
> > tends to make the thing moot anyway, but it really looks like a 
> > win-win situation to just fix the mcount call sequence regardless.
> 
> Just a sidenote: due to dyn-ftrace, which patches out all mcounts during 
> bootup to be NOPs (and opt-in patches them in again if someone runs the 
> function tracer), the cost is not as large as one would have it with say 
> -pg based user-space profiling.
> 
> It's not completely zero-cost as the pure NOPs balloon the i$ footprint 
> a bit and GCC generates different code too in some cases. But it's 
> certainly good enough that it's generally pretty hard to prove overhead 
> via micro or macro benchmarks that the patched out mcounts call sites 
> are there.

And frame pointers do add a little overhead as well. Too bad the mcount
ABI wasn't something like this:


	<function>:
		call	mcount
		[...]

This way, the function address for mcount would have been (%esp) and the
parent address would be 4(%esp). Mcount would work without frame
pointers and this whole mess would also become moot.

-- Steve

Re: BUG: GCC-4.4.x changes the function frame on some functions

[Ingo Molnar]

* Steven Rostedt <rostedt@goodmis.org> wrote:

> On Thu, 2009-11-19 at 19:47 +0100, Ingo Molnar wrote:
> > * Linus Torvalds <torvalds@linux-foundation.org> wrote:
> > 
> > > Admittedly, anybody who compiles with -pg probably doesn't care deeply 
> > > about smaller and more efficient code, since the mcount call overhead 
> > > tends to make the thing moot anyway, but it really looks like a 
> > > win-win situation to just fix the mcount call sequence regardless.
> > 
> > Just a sidenote: due to dyn-ftrace, which patches out all mcounts during 
> > bootup to be NOPs (and opt-in patches them in again if someone runs the 
> > function tracer), the cost is not as large as one would have it with say 
> > -pg based user-space profiling.
> > 
> > It's not completely zero-cost as the pure NOPs balloon the i$ footprint 
> > a bit and GCC generates different code too in some cases. But it's 
> > certainly good enough that it's generally pretty hard to prove overhead 
> > via micro or macro benchmarks that the patched out mcounts call sites 
> > are there.
> 
> And frame pointers do add a little overhead as well. Too bad the mcount
> ABI wasn't something like this:
> 
> 
> 	<function>:
> 		call	mcount
> 		[...]
> 
> This way, the function address for mcount would have been (%esp) and 
> the parent address would be 4(%esp). Mcount would work without frame 
> pointers and this whole mess would also become moot.

In that case we could also fix up static callsites to this address as 
well (to jump +5 bytes into the function) and avoid the NOP as well in 
most cases. (That would in essence merge any slow-path function epilogue 
with the mcount cal instruction in terms of I$ footprint - i.e. it would 
be an even lower overhead feature.)

If only the kernel had its own compiler.

	Ingo

[PATCH] gcc mcount-nofp was Re: BUG: GCC-4.4.x changes the function frame on some functions

[Andi Kleen]

Steven Rostedt <rostedt@goodmis.org> writes:
>
> And frame pointers do add a little overhead as well. Too bad the mcount
> ABI wasn't something like this:
>
>
> 	<function>:
> 		call	mcount
> 		[...]
>
> This way, the function address for mcount would have been (%esp) and the
> parent address would be 4(%esp). Mcount would work without frame
> pointers and this whole mess would also become moot.

I did a patch to do this in x86 gcc some time ago. The motivation
was indeed the frame pointer overhead on Atom with tracing.

Unfortunately it also requires glibc changes (I did those too). For
compatibility and catching mistakes the new function was called
__mcount_nofp.

I haven't tried it with current gcc and last time I missed the 
gcc feature merge window with this.

But perhaps you find it useful. Of course it would need more
kernel changes to probe for the new option and handle it.

Here's the old patch. I haven't retested it with a current
gcc version, but I think it still applies at least.

If there's interest I can polish it up and submit formally.

-Andi


Index: gcc/doc/tm.texi
===================================================================
--- gcc/doc/tm.texi	(revision 149140)
+++ gcc/doc/tm.texi	(working copy)
@@ -1884,6 +1884,12 @@
 of words in each data entry.
 @end defmac
 
+@defmac TARGET_FUNCTION_PROFILE
+Define if the target has a custom function_profiler function.
+The target should not set this macro, it is implicitely set from 
+the PROFILE_BEFORE_PROLOGUE macro.
+@end defmac
+
 @node Registers
 @section Register Usage
 @cindex register usage
Index: gcc/doc/invoke.texi
===================================================================
--- gcc/doc/invoke.texi	(revision 149140)
+++ gcc/doc/invoke.texi	(working copy)
@@ -593,7 +593,7 @@
 -momit-leaf-frame-pointer  -mno-red-zone -mno-tls-direct-seg-refs @gol
 -mcmodel=@var{code-model} -mabi=@var{name} @gol
 -m32  -m64 -mlarge-data-threshold=@var{num} @gol
--mfused-madd -mno-fused-madd -msse2avx}
+-mfused-madd -mno-fused-madd -msse2avx -mmcount-nofp}
 
 @emph{IA-64 Options}
 @gccoptlist{-mbig-endian  -mlittle-endian  -mgnu-as  -mgnu-ld  -mno-pic @gol
@@ -11749,6 +11749,11 @@
 @opindex msse2avx
 Specify that the assembler should encode SSE instructions with VEX
 prefix.  The option @option{-mavx} turns this on by default.
+
+@item -mmcount-nofp
+Don't force the frame counter with @option{-pg} function profiling.
+Instead call a new @code{__mcount_nofp} function before a stack 
+frame is set up.
 @end table
 
 These @samp{-m} switches are supported in addition to the above
Index: gcc/target.h
===================================================================
--- gcc/target.h	(revision 149140)
+++ gcc/target.h	(working copy)
@@ -1132,6 +1132,9 @@
    */
   bool arm_eabi_unwinder;
 
+  /* True when the function profiler code is outputted before the prologue. */
+  bool profile_before_prologue;
+
   /* Leave the boolean fields at the end.  */
 };
 
Index: gcc/final.c
===================================================================
--- gcc/final.c	(revision 149140)
+++ gcc/final.c	(working copy)
@@ -1520,10 +1520,8 @@
 
   /* The Sun386i and perhaps other machines don't work right
      if the profiling code comes after the prologue.  */
-#ifdef PROFILE_BEFORE_PROLOGUE
-  if (crtl->profile)
+  if (targetm.profile_before_prologue && crtl->profile)
     profile_function (file);
-#endif /* PROFILE_BEFORE_PROLOGUE */
 
 #if defined (DWARF2_UNWIND_INFO) && defined (HAVE_prologue)
   if (dwarf2out_do_frame ())
@@ -1565,10 +1563,8 @@
 static void
 profile_after_prologue (FILE *file ATTRIBUTE_UNUSED)
 {
-#ifndef PROFILE_BEFORE_PROLOGUE
-  if (crtl->profile)
+  if (!targetm.profile_before_prologue && crtl->profile)
     profile_function (file);
-#endif /* not PROFILE_BEFORE_PROLOGUE */
 }
 
 static void
Index: gcc/gcc.c
===================================================================
--- gcc/gcc.c	(revision 149140)
+++ gcc/gcc.c	(working copy)
@@ -797,6 +797,12 @@
 # define SYSROOT_HEADERS_SUFFIX_SPEC ""
 #endif
 
+/* Target can override this to allow -pg/-fomit-frame-pointer together */
+#ifndef TARGET_PG_OPTION_SPEC
+#define TARGET_PG_OPTION_SPEC \
+"%{pg:%{fomit-frame-pointer:%e-pg and -fomit-frame-pointer are incompatible}}"
+#endif
+
 static const char *asm_debug;
 static const char *cpp_spec = CPP_SPEC;
 static const char *cc1_spec = CC1_SPEC;
@@ -866,8 +872,8 @@
 
 /* NB: This is shared amongst all front-ends, except for Ada.  */
 static const char *cc1_options =
-"%{pg:%{fomit-frame-pointer:%e-pg and -fomit-frame-pointer are incompatible}}\
- %1 %{!Q:-quiet} -dumpbase %B %{d*} %{m*} %{a*}\
+ TARGET_PG_OPTION_SPEC
+" %1 %{!Q:-quiet} -dumpbase %B %{d*} %{m*} %{a*}\
  %{fcompare-debug-second:%:compare-debug-auxbase-opt(%b)} \
  %{!fcompare-debug-second:%{c|S:%{o*:-auxbase-strip %*}%{!o*:-auxbase %b}}}%{!c:%{!S:-auxbase %b}} \
  %{g*} %{O*} %{W*&pedantic*} %{w} %{std*&ansi&trigraphs}\
Index: gcc/target-def.h
===================================================================
--- gcc/target-def.h	(revision 149140)
+++ gcc/target-def.h	(working copy)
@@ -841,6 +841,12 @@
     TARGET_OPTION_CAN_INLINE_P,			\
   }
 
+#ifdef PROFILE_BEFORE_PROLOGUE
+#define TARGET_FUNCTION_PROFILE true
+#else
+#define TARGET_FUNCTION_PROFILE false
+#endif
+
 /* The whole shebang.  */
 #define TARGET_INITIALIZER			\
 {						\
@@ -960,7 +966,8 @@
   TARGET_HANDLE_PRAGMA_REDEFINE_EXTNAME,	\
   TARGET_HANDLE_PRAGMA_EXTERN_PREFIX,		\
   TARGET_RELAXED_ORDERING,			\
-  TARGET_ARM_EABI_UNWINDER			\
+  TARGET_ARM_EABI_UNWINDER,			\
+  TARGET_FUNCTION_PROFILE			\
 }
 
 #define TARGET_HANDLE_C_OPTION default_handle_c_option
Index: gcc/config/i386/i386.h
===================================================================
--- gcc/config/i386/i386.h	(revision 149140)
+++ gcc/config/i386/i386.h	(working copy)
@@ -2528,6 +2528,9 @@
 #undef TARG_COND_NOT_TAKEN_BRANCH_COST
 #define TARG_COND_NOT_TAKEN_BRANCH_COST ix86_cost->cond_not_taken_branch_cost
 
+/* Allow -pg with -fomit-frame-pointer */
+#define TARGET_PG_OPTION_SPEC ""
+
 /*
 Local variables:
 version-control: t
Index: gcc/config/i386/i386.opt
===================================================================
--- gcc/config/i386/i386.opt	(revision 149140)
+++ gcc/config/i386/i386.opt	(working copy)
@@ -358,3 +358,7 @@
 msse2avx
 Target Report Var(ix86_sse2avx)
 Encode SSE instructions with VEX prefix
+
+mmcount-nofp
+Target Report Var(ix86_mcount_nofp)
+Support function profiling without frame pointer
Index: gcc/config/i386/i386.c
===================================================================
--- gcc/config/i386/i386.c	(revision 149140)
+++ gcc/config/i386/i386.c	(working copy)
@@ -3413,6 +3413,9 @@
     target_flags |= MASK_CLD & ~target_flags_explicit;
 #endif
 
+  if (flag_omit_frame_pointer && profile_flag && ix86_mcount_nofp)
+    targetm.profile_before_prologue = true;
+
   /* Save the initial options in case the user does function specific options */
   if (main_args_p)
     target_option_default_node = target_option_current_node
@@ -7442,7 +7445,7 @@
 	  || ix86_current_function_calls_tls_descriptor))
     return true;
 
-  if (crtl->profile)
+  if (crtl->profile && targetm.profile_before_prologue && !ix86_mcount_nofp)
     return true;
 
   return false;
@@ -27364,6 +27367,11 @@
 void
 x86_function_profiler (FILE *file, int labelno ATTRIBUTE_UNUSED)
 {
+  const char *name = MCOUNT_NAME;
+
+  if (targetm.profile_before_prologue && ix86_mcount_nofp)
+    name = "__mcount_nofp";
+
   if (TARGET_64BIT)
     {
 #ifndef NO_PROFILE_COUNTERS
@@ -27371,9 +27379,9 @@
 #endif
 
       if (DEFAULT_ABI == SYSV_ABI && flag_pic)
-	fprintf (file, "\tcall\t*%s@GOTPCREL(%%rip)\n", MCOUNT_NAME);
+	fprintf (file, "\tcall\t*%s@GOTPCREL(%%rip)\n", name);
       else
-	fprintf (file, "\tcall\t%s\n", MCOUNT_NAME);
+	fprintf (file, "\tcall\t%s\n", name);
     }
   else if (flag_pic)
     {
@@ -27381,7 +27389,7 @@
       fprintf (file, "\tleal\t%sP%d@GOTOFF(%%ebx),%%%s\n",
 	       LPREFIX, labelno, PROFILE_COUNT_REGISTER);
 #endif
-      fprintf (file, "\tcall\t*%s@GOT(%%ebx)\n", MCOUNT_NAME);
+      fprintf (file, "\tcall\t*%s@GOT(%%ebx)\n", name);
     }
   else
     {
@@ -27389,7 +27397,7 @@
       fprintf (file, "\tmovl\t$%sP%d,%%%s\n", LPREFIX, labelno,
 	       PROFILE_COUNT_REGISTER);
 #endif
-      fprintf (file, "\tcall\t%s\n", MCOUNT_NAME);
+      fprintf (file, "\tcall\t%s\n", name);
     }
 }
 

-- 
ak@linux.intel.com -- Speaking for myself only.

Re: [PATCH] gcc mcount-nofp was Re: BUG: GCC-4.4.x changes the function frame on some functions

[Steven Rostedt]

On Fri, 2009-11-20 at 10:57 +0100, Andi Kleen wrote:
> Steven Rostedt <rostedt@goodmis.org> writes:
> >
> > And frame pointers do add a little overhead as well. Too bad the mcount
> > ABI wasn't something like this:
> >
> >
> > 	<function>:
> > 		call	mcount
> > 		[...]
> >
> > This way, the function address for mcount would have been (%esp) and the
> > parent address would be 4(%esp). Mcount would work without frame
> > pointers and this whole mess would also become moot.
> 
> I did a patch to do this in x86 gcc some time ago. The motivation
> was indeed the frame pointer overhead on Atom with tracing.
> 

Yes, I remember you talking about this but I don't remember how far it
went.



> Unfortunately it also requires glibc changes (I did those too). For
> compatibility and catching mistakes the new function was called
> __mcount_nofp.

Actually, could you change the name? I really hate the "mcount" name, it
is legacy and with a new feature, it should be abandoned. Something like
"__fentry__" would be nicer.

> 
> I haven't tried it with current gcc and last time I missed the 
> gcc feature merge window with this.
> 
> But perhaps you find it useful. Of course it would need more
> kernel changes to probe for the new option and handle it.
> 
> Here's the old patch. I haven't retested it with a current
> gcc version, but I think it still applies at least.
> 
> If there's interest I can polish it up and submit formally.

I would definitely be interested, and I would also be willing to test
it.

Thanks!

-- Steve

Re: [PATCH] gcc mcount-nofp was Re: BUG: GCC-4.4.x changes the function frame on some functions

[H. Peter Anvin]

On 11/20/2009 04:34 AM, Steven Rostedt wrote:
>>
>> If there's interest I can polish it up and submit formally.
> 
> I would definitely be interested, and I would also be willing to test
> it.
> 

I don't think there is any question that interception at the
architectural entry point would be the right thing to do.  As such, it
would be great to get this patch productized.

	-hpa

Re: BUG: GCC-4.4.x changes the function frame on some functions

[Thomas Gleixner]

On Thu, 19 Nov 2009, Linus Torvalds wrote:
> On Thu, 19 Nov 2009, Richard Guenther wrote:
> > 
> > Note that I only can reproduce the issue with
> > -mincoming-stack-boundary=2, not with -mpreferred-stack-boundary=2.
> 
> Since you can reproduce it with -mincoming-stack-boundary=2, I woul 
> suggest just fixing mcount handling that way regardless of anything else. 
> The current code generated by gcc is just insane - even for the case where 
> you _want_ 16-byte stack alignment.
> 
> Instead crazy code like
> 
> >       push   %edi
> >       lea    0x8(%esp),%edi
> >       and    $0xfffffff0,%esp
> >       pushl  -0x4(%edi)
> >       push   %ebp
> >       mov    %esp,%ebp
> >       ...
> >       call   mcount
> 
> the sane thing to do would be to just do it as
> 
> 	push   %ebp
> 	mov    %esp,%ebp
> 	call   mcount
> 	and    $0xfffffff0,%esp

which is what the 64bit compile does except that the mcount call
happens a bit later which is fine.

ffffffff8107cd34 <timer_stats_update_stats>:
ffffffff8107cd34:       55                      push   %rbp
ffffffff8107cd35:       48 89 e5                mov    %rsp,%rbp
ffffffff8107cd38:       48 83 e4 c0             and    $0xffffffffffffffc0,%rsp

Thanks,

	tglx

Re: BUG: GCC-4.4.x changes the function frame on some functions

[Andrew Haley]

Thomas Gleixner wrote:
> On Thu, 19 Nov 2009, Thomas Gleixner wrote:
> 
> Can the GCC folks please shed some light on this:
> 
> standard function start:
> 
> 	 push	%ebp
> 	 mov	%esp, %ebp
> 	 ....
> 	 call   mcount
> 
> modified function start on a handful of functions only seen with gcc
> 4.4.x on x86 32 bit:
> 
> 	push   %edi
> 	lea    0x8(%esp),%edi
> 	and    $0xfffffff0,%esp
> 	pushl  -0x4(%edi)
> 	push   %ebp
> 	mov    %esp,%ebp
> 	...
> 	call   mcount
> 
> This modification leads to a hard to solve problem in the kernel
> function graph tracer which assumes that the stack looks like:
> 
>        return address
>        saved  ebp
> 
> With the modified function start sequence this is not longer true and
> the manipulation of the return address on the stack fails silently.
> 
> Neither gcc 4.3 nor gcc 3.4 are generating such function frames, so it
> looks like a gcc 4.4.x feature.
> 
> There is no real obvious reason why the edi magic needs to be done
> _before_ 
> 
> 	push   %ebp
> 	mov    %esp,%ebp

OK, I found it.  There is a struct defined as

struct entry {
 ...
} __attribute__((__aligned__((1 << (4)))));

and then in timer_stats_update_stats you have a local variable of type
struct entry:

void timer_stats_update_stats()
{
 spinlock_t *lock;
 struct entry *entry, input;

So, gcc has to 16-align the stack pointer to satisfy the alignment
for struct entry.

Andrew.

Re: BUG: GCC-4.4.x changes the function frame on some functions

[Steven Rostedt]

On Thu, 2009-11-19 at 18:20 +0000, Andrew Haley wrote:

> OK, I found it.  There is a struct defined as
> 
> struct entry {
>  ...
> } __attribute__((__aligned__((1 << (4)))));
> 
> and then in timer_stats_update_stats you have a local variable of type
> struct entry:
> 
> void timer_stats_update_stats()
> {
>  spinlock_t *lock;
>  struct entry *entry, input;
> 
> So, gcc has to 16-align the stack pointer to satisfy the alignment
> for struct entry.

It has to align the entire stack? Why not just the variable within the
stack?

-- Steve

Re: BUG: GCC-4.4.x changes the function frame on some functions

[Andrew Pinski]

On Thu, Nov 19, 2009 at 10:33 AM, Steven Rostedt <rostedt@goodmis.org> wrote:
> It has to align the entire stack? Why not just the variable within the
> stack?

I had proposed a patch which just aligns the variable but that patch
was never really commented on and HJL's patches to realign the whole
stack went in afterwards.

Thanks,
Andrew Pinski

Re: BUG: GCC-4.4.x changes the function frame on some functions

[Andrew Haley]

Steven Rostedt wrote:
> On Thu, 2009-11-19 at 18:20 +0000, Andrew Haley wrote:
> 
>> OK, I found it.  There is a struct defined as
>>
>> struct entry {
>>  ...
>> } __attribute__((__aligned__((1 << (4)))));
>>
>> and then in timer_stats_update_stats you have a local variable of type
>> struct entry:
>>
>> void timer_stats_update_stats()
>> {
>>  spinlock_t *lock;
>>  struct entry *entry, input;
>>
>> So, gcc has to 16-align the stack pointer to satisfy the alignment
>> for struct entry.
> 
> It has to align the entire stack? Why not just the variable within the
> stack?

How?. gcc has to know, at compile time, the offset from sp of each variable.
So, it of course makes sure that offset is 16-aligned, but it also has to
16-align the stack pointer.

Andrew.

Re: BUG: GCC-4.4.x changes the function frame on some functions

[H. Peter Anvin]

On 11/19/2009 10:33 AM, Steven Rostedt wrote:
> 
> It has to align the entire stack? Why not just the variable within the
> stack?
> 

Because if the stack pointer isn't aligned, it won't know where it can
stuff the variable.  It has to pad *somewhere*, and since you may have
more than one such variable, the most efficient way -- and by far least
complex -- is for the compiler to align the stack when it sets up the
stack frame.

	-hpa

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.

Re: BUG: GCC-4.4.x changes the function frame on some functions

[Thomas Gleixner]

On Thu, 19 Nov 2009, Andrew Haley wrote:
> OK, I found it.  There is a struct defined as
> 
> struct entry {
>  ...
> } __attribute__((__aligned__((1 << (4)))));
> 
> and then in timer_stats_update_stats you have a local variable of type
> struct entry:
> 
> void timer_stats_update_stats()
> {
>  spinlock_t *lock;
>  struct entry *entry, input;
> 
> So, gcc has to 16-align the stack pointer to satisfy the alignment
> for struct entry.

This does not explain why GCC < 4.4.x actually puts

     push %ebp
     mov  %esp, %ebp

first and why GCC 4.4.x decides to create an extra copy of the return
address instead of just keeping the mcount stack magic right at the
function entry.

Thanks,

	tglx

[PATCH][GIT PULL][v2.6.32] tracing/x86: Add check to detect GCC messing with mcount prologue

[Steven Rostedt]

Ingo,

Not sure if this is too much for this late in the -rc game, but it finds
the gcc bug at build time, and we don't need to disable function graph
tracer for all i386 builds.

This is built on my last urgent repo pull request.

Please pull the latest tip/tracing/urgent-2 tree, which can be found at:

  git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-2.6-trace.git
tip/tracing/urgent-2


Steven Rostedt (1):
      tracing/x86: Add check to detect GCC messing with mcount prologue

----
 kernel/trace/Kconfig    |    1 -
 scripts/Makefile.build  |   25 +++++++++++++++-
 scripts/recordmcount.pl |   74 +++++++++++++++++++++++++++++++++++++++++++++--
 3 files changed, 95 insertions(+), 5 deletions(-)
---------------------------
commit c7715fb611c69ac4b7f722a891de08b206fb7686
Author: Steven Rostedt <srostedt@redhat.com>
Date:   Thu Nov 19 23:41:02 2009 -0500

    tracing/x86: Add check to detect GCC messing with mcount prologue
    
    Latest versions of GCC create a funny prologue for some functions.
    Instead of the typical:
    
    		push   %ebp
    		mov    %esp,%ebp
    		and    $0xffffffe0,%esp
    		[...]
    		call   mcount
    
    GCC may try to align the stack before setting up the frame pointer
    register:
    
    		push   %edi
    		lea    0x8(%esp),%edi
    		and    $0xffffffe0,%esp
    		pushl  -0x4(%edi)
    		push   %ebp
    		mov    %esp,%ebp
    		[...]
    		call   mcount
    
    This crazy code places a copy of the return address into the
    frame pointer. The function graph tracer uses this pointer to
    save and replace the return address of the calling function to jump
    to the function graph tracer's return handler, which will put back
    the return address. But instead instead of the typical return:
    
    		mov    %ebp,%esp
    		pop    %ebp
    		ret
    
    The return of the function performs:
    
    		lea    -0x8(%edi),%esp
    		pop    %edi
    		ret
    
    The function graph tracer return handler will not be called at the exit
    of the function, but the parent function will call it. Because we missed
    the return of the child function, the handler will replace the parent's
    return address with that of the child. Obviously this will cause a crash
    (Note, there is code to detect this case and safely panic the kernel).
    
    The kicker is that this happens to just a handful of functions.
    And only with certain gcc options.
    
    Compiling with: 	-march=pentium-mmx
    will cause the problem to appear. But if you were to change
    pentium-mmx to i686 or add -mtune=generic, then the problem goes away.
    
    I first saw this problem when compiling with optimize for size.
    But it seems that various other options may cause this issue to arise.
    
    Instead of completely disabling the function graph tracer for i386 builds
    this patch adds a check to recordmcount.pl to make sure that all
    functions that contain a call to mcount start with "push %ebp".
    If not, it will fail the compile and print out the nasty warning:
    
      CC      kernel/time/timer_stats.o
    
    ********************************************************
      Your version of GCC breaks the function graph tracer
      Please disable CONFIG_FUNCTION_GRAPH_TRACER
      Failed function was "timer_stats_update_stats"
    ********************************************************
    
    The script recordmcount.pl is given a new parameter "do_check". If
    this is negative, the script will only perform this check without
    creating the mcount caller section. This will be executed for x86_32
    when CONFIG_FUNCTION_GRAPH_TRACER is enabled and CONFIG_DYNAMIC_FTRACE
    is not.
    
    If the arch is x86_32 and $do_check is greater than 1, it will perform
    the check while processing the mcount callers. If $do_check is 0, then
    no check will be performed. This is for non x86_32 archs and when
    compiling without CONFIG_FUNCTION_GRAPH_TRACER enabled, even on x86_32.
    
    Reported-by: Thomas Gleixner <tglx@linutronix.de>
    LKML-Reference: <alpine.LFD.2.00.0911191423190.24119@localhost.localdomain>
    Signed-off-by: Steven Rostedt <rostedt@goodmis.org>

diff --git a/kernel/trace/Kconfig b/kernel/trace/Kconfig
index b416512..cd39064 100644
--- a/kernel/trace/Kconfig
+++ b/kernel/trace/Kconfig
@@ -143,7 +143,6 @@ config FUNCTION_GRAPH_TRACER
 	bool "Kernel Function Graph Tracer"
 	depends on HAVE_FUNCTION_GRAPH_TRACER
 	depends on FUNCTION_TRACER
-	depends on !X86_32 || !CC_OPTIMIZE_FOR_SIZE
 	default y
 	help
 	  Enable the kernel to trace a function at both its return
diff --git a/scripts/Makefile.build b/scripts/Makefile.build
index 341b589..3b897f2 100644
--- a/scripts/Makefile.build
+++ b/scripts/Makefile.build
@@ -206,10 +206,33 @@ cmd_modversions =							\
 endif
 
 ifdef CONFIG_FTRACE_MCOUNT_RECORD
+
+ ifdef CONFIG_FUNCTION_GRAPH_TRACER
+  ifdef CONFIG_X86_32
+   rm_do_check = 1
+  else
+   rm_do_check = 0
+  endif
+ else
+  rm_do_check = 0
+ endif
+
 cmd_record_mcount = set -e ; perl $(srctree)/scripts/recordmcount.pl "$(ARCH)" \
 	"$(if $(CONFIG_64BIT),64,32)" \
 	"$(OBJDUMP)" "$(OBJCOPY)" "$(CC)" "$(LD)" "$(NM)" "$(RM)" "$(MV)" \
-	"$(if $(part-of-module),1,0)" "$(@)";
+	"$(if $(part-of-module),1,0)" "$(rm_do_check)" "$(@)";
+
+else
+
+ ifdef CONFIG_X86_32
+ ifdef CONFIG_FUNCTION_GRAPH_TRACER
+   cmd_record_mcount = set -e ; perl $(srctree)/scripts/recordmcount.pl "$(ARCH)" \
+	"$(if $(CONFIG_64BIT),64,32)" \
+	"$(OBJDUMP)" "$(OBJCOPY)" "$(CC)" "$(LD)" "$(NM)" "$(RM)" "$(MV)" \
+	"$(if $(part-of-module),1,0)" "-1" "$(@)";
+ endif
+ endif
+
 endif
 
 define rule_cc_o_c
diff --git a/scripts/recordmcount.pl b/scripts/recordmcount.pl
index 090d300..164a9d5 100755
--- a/scripts/recordmcount.pl
+++ b/scripts/recordmcount.pl
@@ -99,14 +99,14 @@ $P =~ s@.*/@@g;
 
 my $V = '0.1';
 
-if ($#ARGV < 7) {
-	print "usage: $P arch bits objdump objcopy cc ld nm rm mv is_module inputfile\n";
+if ($#ARGV < 11) {
+	print "usage: $P arch bits objdump objcopy cc ld nm rm mv is_module do_check inputfile\n";
 	print "version: $V\n";
 	exit(1);
 }
 
 my ($arch, $bits, $objdump, $objcopy, $cc,
-    $ld, $nm, $rm, $mv, $is_module, $inputfile) = @ARGV;
+    $ld, $nm, $rm, $mv, $is_module, $do_check, $inputfile) = @ARGV;
 
 # This file refers to mcount and shouldn't be ftraced, so lets' ignore it
 if ($inputfile eq "kernel/trace/ftrace.o") {
@@ -129,6 +129,60 @@ $nm = "nm" if ((length $nm) == 0);
 $rm = "rm" if ((length $rm) == 0);
 $mv = "mv" if ((length $mv) == 0);
 
+# gcc can do stupid things with the stack pointer on x86_32.
+# It may pass a copy of the return address to mcount, which will
+# break the function graph tracer. If this happens then we need
+# to flag it and break the build.
+#
+# For x86_32, the parameter do_check will be negative if we only
+# want to perform the check, and positive if we should od the check.
+# If function graph tracing is not enabled, do_check will be zero.
+#
+
+my $check_next_line = 0;
+my $line_failed = 0;
+my $last_function;
+
+sub test_x86_32_prologue
+{
+    if ($check_next_line) {
+	if (!/push\s*\%ebp/) {
+	    $line_failed = 1;
+	}
+    }
+
+    if ($line_failed && /mcount/) {
+	print STDERR "\n********************************************************\n";
+	print STDERR "  Your version of GCC breaks the function graph tracer\n";
+	print STDERR "  Please disable CONFIG_FUNCTION_GRAPH_TRACER\n";
+	print STDERR "  Failed function was \"$last_function\"\n";
+	print STDERR "********************************************************\n\n";
+	exit -1;
+    }
+    $check_next_line = 0;
+
+    # check the first line after a function starts for
+    #  push %ebp
+    if (/^[0-9a-fA-F]+\s+<([a-zA-Z_].*)>:$/) {
+	$last_function = $1;
+	$check_next_line = 1;
+	$line_failed = 0;
+    }
+}
+
+if ($do_check < 0) {
+    # Only perform the check and quit
+    open(IN, "$objdump -dr $inputfile|") || die "error running $objdump";
+
+    while (<IN>) {
+	test_x86_32_prologue;
+    }
+    close (IN);
+    exit 0;
+}
+
+my $check = 0;
+
 #print STDERR "running: $P '$arch' '$objdump' '$objcopy' '$cc' '$ld' " .
 #    "'$nm' '$rm' '$mv' '$inputfile'\n";
 
@@ -153,6 +207,12 @@ if ($arch eq "x86") {
     }
 }
 
+if ($arch eq "i386") {
+    if ($do_check) {
+	$check = 1;
+    }
+}
+
 #
 # We base the defaults off of i386, the other archs may
 # feel free to change them in the below if statements.
@@ -381,6 +441,14 @@ my $text;
 my $read_headers = 1;
 
 while (<IN>) {
+
+    # x86_32 may need to test the start of every function to see
+    # if GCC did not mess up the mcount prologue. All functions must
+    # start with push %ebp, otherwise it is broken.
+    if ($check) {
+	test_x86_32_prologue;
+    }
+
     # is it a section?
     if (/$section_regex/) {
 	$read_headers = 0;

Re: [PATCH][GIT PULL][v2.6.32] tracing/x86: Add check to detect GCC messing with mcount prologue

[Steven Rostedt]

This touches the Makefile scripts. I forgot to CC kbuild and Sam.

-- Steve

On Fri, 2009-11-20 at 00:23 -0500, Steven Rostedt wrote:
> Ingo,
> 
> Not sure if this is too much for this late in the -rc game, but it finds
> the gcc bug at build time, and we don't need to disable function graph
> tracer for all i386 builds.
> 
> This is built on my last urgent repo pull request.
> 
> Please pull the latest tip/tracing/urgent-2 tree, which can be found at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-2.6-trace.git
> tip/tracing/urgent-2
> 
> 
> Steven Rostedt (1):
>       tracing/x86: Add check to detect GCC messing with mcount prologue
> 
> ----
>  kernel/trace/Kconfig    |    1 -
>  scripts/Makefile.build  |   25 +++++++++++++++-
>  scripts/recordmcount.pl |   74 +++++++++++++++++++++++++++++++++++++++++++++--
>  3 files changed, 95 insertions(+), 5 deletions(-)
> ---------------------------
> commit c7715fb611c69ac4b7f722a891de08b206fb7686
> Author: Steven Rostedt <srostedt@redhat.com>
> Date:   Thu Nov 19 23:41:02 2009 -0500
> 
>     tracing/x86: Add check to detect GCC messing with mcount prologue
>     
>     Latest versions of GCC create a funny prologue for some functions.
>     Instead of the typical:
>     
>     		push   %ebp
>     		mov    %esp,%ebp
>     		and    $0xffffffe0,%esp
>     		[...]
>     		call   mcount
>     
>     GCC may try to align the stack before setting up the frame pointer
>     register:
>     
>     		push   %edi
>     		lea    0x8(%esp),%edi
>     		and    $0xffffffe0,%esp
>     		pushl  -0x4(%edi)
>     		push   %ebp
>     		mov    %esp,%ebp
>     		[...]
>     		call   mcount
>     
>     This crazy code places a copy of the return address into the
>     frame pointer. The function graph tracer uses this pointer to
>     save and replace the return address of the calling function to jump
>     to the function graph tracer's return handler, which will put back
>     the return address. But instead instead of the typical return:
>     
>     		mov    %ebp,%esp
>     		pop    %ebp
>     		ret
>     
>     The return of the function performs:
>     
>     		lea    -0x8(%edi),%esp
>     		pop    %edi
>     		ret
>     
>     The function graph tracer return handler will not be called at the exit
>     of the function, but the parent function will call it. Because we missed
>     the return of the child function, the handler will replace the parent's
>     return address with that of the child. Obviously this will cause a crash
>     (Note, there is code to detect this case and safely panic the kernel).
>     
>     The kicker is that this happens to just a handful of functions.
>     And only with certain gcc options.
>     
>     Compiling with: 	-march=pentium-mmx
>     will cause the problem to appear. But if you were to change
>     pentium-mmx to i686 or add -mtune=generic, then the problem goes away.
>     
>     I first saw this problem when compiling with optimize for size.
>     But it seems that various other options may cause this issue to arise.
>     
>     Instead of completely disabling the function graph tracer for i386 builds
>     this patch adds a check to recordmcount.pl to make sure that all
>     functions that contain a call to mcount start with "push %ebp".
>     If not, it will fail the compile and print out the nasty warning:
>     
>       CC      kernel/time/timer_stats.o
>     
>     ********************************************************
>       Your version of GCC breaks the function graph tracer
>       Please disable CONFIG_FUNCTION_GRAPH_TRACER
>       Failed function was "timer_stats_update_stats"
>     ********************************************************
>     
>     The script recordmcount.pl is given a new parameter "do_check". If
>     this is negative, the script will only perform this check without
>     creating the mcount caller section. This will be executed for x86_32
>     when CONFIG_FUNCTION_GRAPH_TRACER is enabled and CONFIG_DYNAMIC_FTRACE
>     is not.
>     
>     If the arch is x86_32 and $do_check is greater than 1, it will perform
>     the check while processing the mcount callers. If $do_check is 0, then
>     no check will be performed. This is for non x86_32 archs and when
>     compiling without CONFIG_FUNCTION_GRAPH_TRACER enabled, even on x86_32.
>     
>     Reported-by: Thomas Gleixner <tglx@linutronix.de>
>     LKML-Reference: <alpine.LFD.2.00.0911191423190.24119@localhost.localdomain>
>     Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
> 
> diff --git a/kernel/trace/Kconfig b/kernel/trace/Kconfig
> index b416512..cd39064 100644
> --- a/kernel/trace/Kconfig
> +++ b/kernel/trace/Kconfig
> @@ -143,7 +143,6 @@ config FUNCTION_GRAPH_TRACER
>  	bool "Kernel Function Graph Tracer"
>  	depends on HAVE_FUNCTION_GRAPH_TRACER
>  	depends on FUNCTION_TRACER
> -	depends on !X86_32 || !CC_OPTIMIZE_FOR_SIZE
>  	default y
>  	help
>  	  Enable the kernel to trace a function at both its return
> diff --git a/scripts/Makefile.build b/scripts/Makefile.build
> index 341b589..3b897f2 100644
> --- a/scripts/Makefile.build
> +++ b/scripts/Makefile.build
> @@ -206,10 +206,33 @@ cmd_modversions =							\
>  endif
>  
>  ifdef CONFIG_FTRACE_MCOUNT_RECORD
> +
> + ifdef CONFIG_FUNCTION_GRAPH_TRACER
> +  ifdef CONFIG_X86_32
> +   rm_do_check = 1
> +  else
> +   rm_do_check = 0
> +  endif
> + else
> +  rm_do_check = 0
> + endif
> +
>  cmd_record_mcount = set -e ; perl $(srctree)/scripts/recordmcount.pl "$(ARCH)" \
>  	"$(if $(CONFIG_64BIT),64,32)" \
>  	"$(OBJDUMP)" "$(OBJCOPY)" "$(CC)" "$(LD)" "$(NM)" "$(RM)" "$(MV)" \
> -	"$(if $(part-of-module),1,0)" "$(@)";
> +	"$(if $(part-of-module),1,0)" "$(rm_do_check)" "$(@)";
> +
> +else
> +
> + ifdef CONFIG_X86_32
> + ifdef CONFIG_FUNCTION_GRAPH_TRACER
> +   cmd_record_mcount = set -e ; perl $(srctree)/scripts/recordmcount.pl "$(ARCH)" \
> +	"$(if $(CONFIG_64BIT),64,32)" \
> +	"$(OBJDUMP)" "$(OBJCOPY)" "$(CC)" "$(LD)" "$(NM)" "$(RM)" "$(MV)" \
> +	"$(if $(part-of-module),1,0)" "-1" "$(@)";
> + endif
> + endif
> +
>  endif
>  
>  define rule_cc_o_c
> diff --git a/scripts/recordmcount.pl b/scripts/recordmcount.pl
> index 090d300..164a9d5 100755
> --- a/scripts/recordmcount.pl
> +++ b/scripts/recordmcount.pl
> @@ -99,14 +99,14 @@ $P =~ s@.*/@@g;
>  
>  my $V = '0.1';
>  
> -if ($#ARGV < 7) {
> -	print "usage: $P arch bits objdump objcopy cc ld nm rm mv is_module inputfile\n";
> +if ($#ARGV < 11) {
> +	print "usage: $P arch bits objdump objcopy cc ld nm rm mv is_module do_check inputfile\n";
>  	print "version: $V\n";
>  	exit(1);
>  }
>  
>  my ($arch, $bits, $objdump, $objcopy, $cc,
> -    $ld, $nm, $rm, $mv, $is_module, $inputfile) = @ARGV;
> +    $ld, $nm, $rm, $mv, $is_module, $do_check, $inputfile) = @ARGV;
>  
>  # This file refers to mcount and shouldn't be ftraced, so lets' ignore it
>  if ($inputfile eq "kernel/trace/ftrace.o") {
> @@ -129,6 +129,60 @@ $nm = "nm" if ((length $nm) == 0);
>  $rm = "rm" if ((length $rm) == 0);
>  $mv = "mv" if ((length $mv) == 0);
>  
> +# gcc can do stupid things with the stack pointer on x86_32.
> +# It may pass a copy of the return address to mcount, which will
> +# break the function graph tracer. If this happens then we need
> +# to flag it and break the build.
> +#
> +# For x86_32, the parameter do_check will be negative if we only
> +# want to perform the check, and positive if we should od the check.
> +# If function graph tracing is not enabled, do_check will be zero.
> +#
> +
> +my $check_next_line = 0;
> +my $line_failed = 0;
> +my $last_function;
> +
> +sub test_x86_32_prologue
> +{
> +    if ($check_next_line) {
> +	if (!/push\s*\%ebp/) {
> +	    $line_failed = 1;
> +	}
> +    }
> +
> +    if ($line_failed && /mcount/) {
> +	print STDERR "\n********************************************************\n";
> +	print STDERR "  Your version of GCC breaks the function graph tracer\n";
> +	print STDERR "  Please disable CONFIG_FUNCTION_GRAPH_TRACER\n";
> +	print STDERR "  Failed function was \"$last_function\"\n";
> +	print STDERR "********************************************************\n\n";
> +	exit -1;
> +    }
> +    $check_next_line = 0;
> +
> +    # check the first line after a function starts for
> +    #  push %ebp
> +    if (/^[0-9a-fA-F]+\s+<([a-zA-Z_].*)>:$/) {
> +	$last_function = $1;
> +	$check_next_line = 1;
> +	$line_failed = 0;
> +    }
> +}
> +
> +if ($do_check < 0) {
> +    # Only perform the check and quit
> +    open(IN, "$objdump -dr $inputfile|") || die "error running $objdump";
> +
> +    while (<IN>) {
> +	test_x86_32_prologue;
> +    }
> +    close (IN);
> +    exit 0;
> +}
> +
> +my $check = 0;
> +
>  #print STDERR "running: $P '$arch' '$objdump' '$objcopy' '$cc' '$ld' " .
>  #    "'$nm' '$rm' '$mv' '$inputfile'\n";
>  
> @@ -153,6 +207,12 @@ if ($arch eq "x86") {
>      }
>  }
>  
> +if ($arch eq "i386") {
> +    if ($do_check) {
> +	$check = 1;
> +    }
> +}
> +
>  #
>  # We base the defaults off of i386, the other archs may
>  # feel free to change them in the below if statements.
> @@ -381,6 +441,14 @@ my $text;
>  my $read_headers = 1;
>  
>  while (<IN>) {
> +
> +    # x86_32 may need to test the start of every function to see
> +    # if GCC did not mess up the mcount prologue. All functions must
> +    # start with push %ebp, otherwise it is broken.
> +    if ($check) {
> +	test_x86_32_prologue;
> +    }
> +
>      # is it a section?
>      if (/$section_regex/) {
>  	$read_headers = 0;
> 

Re: [PATCH][GIT PULL][v2.6.32] tracing/x86: Add check to detect GCC messing with mcount prologue

[Steven Rostedt]

Ingo, Thomas and Linus,

I know Thomas did a patch to force the -mtune=generic, but just in case
gcc decides to do something crazy again, this patch will catch it.

Should we try to get this in now?

-- Steve

On Fri, 2009-11-20 at 00:23 -0500, Steven Rostedt wrote:
> commit c7715fb611c69ac4b7f722a891de08b206fb7686
> Author: Steven Rostedt <srostedt@redhat.com>
> Date:   Thu Nov 19 23:41:02 2009 -0500
> 
>     tracing/x86: Add check to detect GCC messing with mcount prologue
>     
>     Latest versions of GCC create a funny prologue for some functions.
>     Instead of the typical:
>     
>     		push   %ebp
>     		mov    %esp,%ebp
>     		and    $0xffffffe0,%esp
>     		[...]
>     		call   mcount
>     
>     GCC may try to align the stack before setting up the frame pointer
>     register:
>     
>     		push   %edi
>     		lea    0x8(%esp),%edi
>     		and    $0xffffffe0,%esp
>     		pushl  -0x4(%edi)
>     		push   %ebp
>     		mov    %esp,%ebp
>     		[...]
>     		call   mcount
>     
>     This crazy code places a copy of the return address into the
>     frame pointer. The function graph tracer uses this pointer to
>     save and replace the return address of the calling function to jump
>     to the function graph tracer's return handler, which will put back
>     the return address. But instead instead of the typical return:
>     
>     		mov    %ebp,%esp
>     		pop    %ebp
>     		ret
>     
>     The return of the function performs:
>     
>     		lea    -0x8(%edi),%esp
>     		pop    %edi
>     		ret
>     
>     The function graph tracer return handler will not be called at the exit
>     of the function, but the parent function will call it. Because we missed
>     the return of the child function, the handler will replace the parent's
>     return address with that of the child. Obviously this will cause a crash
>     (Note, there is code to detect this case and safely panic the kernel).
>     
>     The kicker is that this happens to just a handful of functions.
>     And only with certain gcc options.
>     
>     Compiling with: 	-march=pentium-mmx
>     will cause the problem to appear. But if you were to change
>     pentium-mmx to i686 or add -mtune=generic, then the problem goes away.
>     
>     I first saw this problem when compiling with optimize for size.
>     But it seems that various other options may cause this issue to arise.
>     
>     Instead of completely disabling the function graph tracer for i386 builds
>     this patch adds a check to recordmcount.pl to make sure that all
>     functions that contain a call to mcount start with "push %ebp".
>     If not, it will fail the compile and print out the nasty warning:
>     
>       CC      kernel/time/timer_stats.o
>     
>     ********************************************************
>       Your version of GCC breaks the function graph tracer
>       Please disable CONFIG_FUNCTION_GRAPH_TRACER
>       Failed function was "timer_stats_update_stats"
>     ********************************************************
>     
>     The script recordmcount.pl is given a new parameter "do_check". If
>     this is negative, the script will only perform this check without
>     creating the mcount caller section. This will be executed for x86_32
>     when CONFIG_FUNCTION_GRAPH_TRACER is enabled and CONFIG_DYNAMIC_FTRACE
>     is not.
>     
>     If the arch is x86_32 and $do_check is greater than 1, it will perform
>     the check while processing the mcount callers. If $do_check is 0, then
>     no check will be performed. This is for non x86_32 archs and when
>     compiling without CONFIG_FUNCTION_GRAPH_TRACER enabled, even on x86_32.
>     
>     Reported-by: Thomas Gleixner <tglx@linutronix.de>
>     LKML-Reference: <alpine.LFD.2.00.0911191423190.24119@localhost.localdomain>
>     Signed-off-by: Steven Rostedt <rostedt@goodmis.org>

Re: [PATCH][GIT PULL][v2.6.32] tracing/x86: Add check to detect GCC messing with mcount prologue

[H. Peter Anvin]

On 11/20/2009 09:00 AM, Steven Rostedt wrote:
> Ingo, Thomas and Linus,
> 
> I know Thomas did a patch to force the -mtune=generic, but just in case
> gcc decides to do something crazy again, this patch will catch it.
> 
> Should we try to get this in now?
> 

Sounds like a very good idea to me.
	
	-hpa

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.

Re: [PATCH][GIT PULL][v2.6.32] tracing/x86: Add check to detect GCC messing with mcount prologue

[Andrew Haley]

Steven Rostedt wrote:
> Ingo, Thomas and Linus,
> 
> I know Thomas did a patch to force the -mtune=generic, but just in case
> gcc decides to do something crazy again, this patch will catch it.
> 
> Should we try to get this in now?

I'm sure this makes sense, but a gcc test case would be even better.
If this can be detected in the gcc test suite it'll be found and
fixed long before y'all in kernel land get to see it.  That's the
only way to guarantee this never bothers you again.

H.J., who wrote the code in question, is hopefully looking at why
this odd code is being generated.  Once he's done I can put a
suitable test case in the gcc test suite.

Andrew.

Re: [PATCH][GIT PULL][v2.6.32] tracing/x86: Add check to detect GCC messing with mcount prologue

[Steven Rostedt]

On Fri, 2009-11-20 at 19:35 +0000, Andrew Haley wrote:
> Steven Rostedt wrote:
> > Ingo, Thomas and Linus,
> > 
> > I know Thomas did a patch to force the -mtune=generic, but just in case
> > gcc decides to do something crazy again, this patch will catch it.
> > 
> > Should we try to get this in now?
> 
> I'm sure this makes sense, but a gcc test case would be even better.
> If this can be detected in the gcc test suite it'll be found and
> fixed long before y'all in kernel land get to see it.  That's the
> only way to guarantee this never bothers you again.
> 
> H.J., who wrote the code in question, is hopefully looking at why
> this odd code is being generated.  Once he's done I can put a
> suitable test case in the gcc test suite.

Yes a gcc test suite will help new instances of gcc. But we need to
worry about the instances of gcc that people have on their desktops now.
This test case will catch the discrepancy between gcc and the function
graph tracer. I'm not 100% convince that just adding -mtune=generic will
help in all cases. If we miss another instance, then the function graph
tracer may crash someone's kernel.

-- Steve

Re: [PATCH][GIT PULL][v2.6.32] tracing/x86: Add check to detect GCC messing with mcount prologue

[H. Peter Anvin]

On 11/20/2009 11:46 AM, Steven Rostedt wrote:
> 
> Yes a gcc test suite will help new instances of gcc. But we need to
> worry about the instances of gcc that people have on their desktops now.
> This test case will catch the discrepancy between gcc and the function
> graph tracer. I'm not 100% convince that just adding -mtune=generic will
> help in all cases. If we miss another instance, then the function graph
> tracer may crash someone's kernel.
> 

Furthermore, for future gcc instances what we really want is the early
interception support anyway.

	-hpa

Re: [PATCH][GIT PULL][v2.6.32] tracing/x86: Add check to detect GCC messing with mcount prologue

[H.J. Lu]

On Fri, Nov 20, 2009 at 11:35 AM, Andrew Haley <aph@redhat.com> wrote:
> Steven Rostedt wrote:
>> Ingo, Thomas and Linus,
>>
>> I know Thomas did a patch to force the -mtune=generic, but just in case
>> gcc decides to do something crazy again, this patch will catch it.
>>
>> Should we try to get this in now?
>
> I'm sure this makes sense, but a gcc test case would be even better.
> If this can be detected in the gcc test suite it'll be found and
> fixed long before y'all in kernel land get to see it.  That's the
> only way to guarantee this never bothers you again.
>
> H.J., who wrote the code in question, is hopefully looking at why
> this odd code is being generated.  Once he's done I can put a
> suitable test case in the gcc test suite.
>

See:

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42109#c7


-- 
H.J.

Re: [PATCH][GIT PULL][v2.6.32] tracing/x86: Add check to detect GCC messing with mcount prologue

[Andrew Haley]

H.J. Lu wrote:
> On Fri, Nov 20, 2009 at 11:35 AM, Andrew Haley <aph@redhat.com> wrote:
>> Steven Rostedt wrote:
>>> Ingo, Thomas and Linus,
>>>
>>> I know Thomas did a patch to force the -mtune=generic, but just in case
>>> gcc decides to do something crazy again, this patch will catch it.
>>>
>>> Should we try to get this in now?
>> I'm sure this makes sense, but a gcc test case would be even better.
>> If this can be detected in the gcc test suite it'll be found and
>> fixed long before y'all in kernel land get to see it.  That's the
>> only way to guarantee this never bothers you again.
>>
>> H.J., who wrote the code in question, is hopefully looking at why
>> this odd code is being generated.  Once he's done I can put a
>> suitable test case in the gcc test suite.
>>
> 
> See:
> 
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42109#c7

I saw that, but does it mean you're going to investigate?  There is
no obvious reason why -mtune=generic should affect code generation
in this way, but it does.

Andrew.

Re: [PATCH][GIT PULL][v2.6.32] tracing/x86: Add check to detect GCC messing with mcount prologue

[H.J. Lu]

On Sun, Nov 22, 2009 at 9:20 AM, Andrew Haley <aph@redhat.com> wrote:
> H.J. Lu wrote:
>> On Fri, Nov 20, 2009 at 11:35 AM, Andrew Haley <aph@redhat.com> wrote:
>>> Steven Rostedt wrote:
>>>> Ingo, Thomas and Linus,
>>>>
>>>> I know Thomas did a patch to force the -mtune=generic, but just in case
>>>> gcc decides to do something crazy again, this patch will catch it.
>>>>
>>>> Should we try to get this in now?
>>> I'm sure this makes sense, but a gcc test case would be even better.
>>> If this can be detected in the gcc test suite it'll be found and
>>> fixed long before y'all in kernel land get to see it.  That's the
>>> only way to guarantee this never bothers you again.
>>>
>>> H.J., who wrote the code in question, is hopefully looking at why
>>> this odd code is being generated.  Once he's done I can put a
>>> suitable test case in the gcc test suite.
>>>
>>
>> See:
>>
>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42109#c7
>
> I saw that, but does it mean you're going to investigate?  There is
> no obvious reason why -mtune=generic should affect code generation
> in this way, but it does.
>

Why not, there is

static const unsigned int x86_accumulate_outgoing_args
  = m_AMD_MULTIPLE | m_ATOM | m_PENT4 | m_NOCONA | m_PPRO | m_CORE2
    | m_GENERIC;

-mtune=generic turns on -maccumulate-outgoing-args.


-- 
H.J.

Re: [PATCH][GIT PULL][v2.6.32] tracing/x86: Add check to detect GCC messing with mcount prologue

[Andrew Haley]

H.J. Lu wrote:
> On Sun, Nov 22, 2009 at 9:20 AM, Andrew Haley <aph@redhat.com> wrote:
>> H.J. Lu wrote:
>>> On Fri, Nov 20, 2009 at 11:35 AM, Andrew Haley <aph@redhat.com> wrote:
>>>> Steven Rostedt wrote:
>>>>> Ingo, Thomas and Linus,
>>>>>
>>>>> I know Thomas did a patch to force the -mtune=generic, but just in case
>>>>> gcc decides to do something crazy again, this patch will catch it.
>>>>>
>>>>> Should we try to get this in now?
>>>> I'm sure this makes sense, but a gcc test case would be even better.
>>>> If this can be detected in the gcc test suite it'll be found and
>>>> fixed long before y'all in kernel land get to see it.  That's the
>>>> only way to guarantee this never bothers you again.
>>>>
>>>> H.J., who wrote the code in question, is hopefully looking at why
>>>> this odd code is being generated.  Once he's done I can put a
>>>> suitable test case in the gcc test suite.
>>>>
>>> See:
>>>
>>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42109#c7
>> I saw that, but does it mean you're going to investigate?  There is
>> no obvious reason why -mtune=generic should affect code generation
>> in this way, but it does.
> 
> Why not, there is
> 
> static const unsigned int x86_accumulate_outgoing_args
>   = m_AMD_MULTIPLE | m_ATOM | m_PENT4 | m_NOCONA | m_PPRO | m_CORE2
>     | m_GENERIC;
> 
> -mtune=generic turns on -maccumulate-outgoing-args.

Alright, so let's at least try to give the kernel people the information
that they need.

What you're saying is, to avoid this:

  000005f0 <timer_stats_update_stats>:
 5f0:   57                      push   %edi
 5f1:   8d 7c 24 08             lea    0x8(%esp),%edi
 5f5:   83 e4 f0                and    $0xfffffff0,%esp
 5f8:   ff 77 fc                pushl  -0x4(%edi)
 5fb:   55                      push   %ebp
 5fc:   89 e5                   mov    %esp,%ebp

you should compile your code with -maccumulate-outgoing-args, and there's
no need to use -mtune=generic.  Is that right?

Andrew.

Re: [PATCH][GIT PULL][v2.6.32] tracing/x86: Add check to detect GCC messing with mcount prologue

[Thomas Gleixner]

On Tue, 24 Nov 2009, Andrew Haley wrote:
> H.J. Lu wrote:
> > On Sun, Nov 22, 2009 at 9:20 AM, Andrew Haley <aph@redhat.com> wrote:
> >> H.J. Lu wrote:
> >>> On Fri, Nov 20, 2009 at 11:35 AM, Andrew Haley <aph@redhat.com> wrote:
> >>>> Steven Rostedt wrote:
> >>>>> Ingo, Thomas and Linus,
> >>>>>
> >>>>> I know Thomas did a patch to force the -mtune=generic, but just in case
> >>>>> gcc decides to do something crazy again, this patch will catch it.
> >>>>>
> >>>>> Should we try to get this in now?
> >>>> I'm sure this makes sense, but a gcc test case would be even better.
> >>>> If this can be detected in the gcc test suite it'll be found and
> >>>> fixed long before y'all in kernel land get to see it.  That's the
> >>>> only way to guarantee this never bothers you again.
> >>>>
> >>>> H.J., who wrote the code in question, is hopefully looking at why
> >>>> this odd code is being generated.  Once he's done I can put a
> >>>> suitable test case in the gcc test suite.
> >>>>
> >>> See:
> >>>
> >>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42109#c7
> >> I saw that, but does it mean you're going to investigate?  There is
> >> no obvious reason why -mtune=generic should affect code generation
> >> in this way, but it does.
> > 
> > Why not, there is
> > 
> > static const unsigned int x86_accumulate_outgoing_args
> >   = m_AMD_MULTIPLE | m_ATOM | m_PENT4 | m_NOCONA | m_PPRO | m_CORE2
> >     | m_GENERIC;
> > 
> > -mtune=generic turns on -maccumulate-outgoing-args.
> 
> Alright, so let's at least try to give the kernel people the information
> that they need.
> 
> What you're saying is, to avoid this:
> 
>   000005f0 <timer_stats_update_stats>:
>  5f0:   57                      push   %edi
>  5f1:   8d 7c 24 08             lea    0x8(%esp),%edi
>  5f5:   83 e4 f0                and    $0xfffffff0,%esp
>  5f8:   ff 77 fc                pushl  -0x4(%edi)
>  5fb:   55                      push   %ebp
>  5fc:   89 e5                   mov    %esp,%ebp
> 
> you should compile your code with -maccumulate-outgoing-args, and there's
> no need to use -mtune=generic.  Is that right?

Seems to work. What other side effects has that ?

Thanks,

	tglx

Re: [PATCH][GIT PULL][v2.6.32] tracing/x86: Add check to detect GCC messing with mcount prologue

[Jakub Jelinek]

On Tue, Nov 24, 2009 at 03:55:49PM +0100, Thomas Gleixner wrote:
> > you should compile your code with -maccumulate-outgoing-args, and there's
> > no need to use -mtune=generic.  Is that right?
> 
> Seems to work. What other side effects has that ?

Faster code, significant increase in code size though.  Note that on many
architectures it is the only supported model.

	Jakub

Re: [PATCH][GIT PULL][v2.6.32] tracing/x86: Add check to detect GCC messing with mcount prologue

[Andrew Haley]

Jakub Jelinek wrote:
> On Tue, Nov 24, 2009 at 03:55:49PM +0100, Thomas Gleixner wrote:
>>> you should compile your code with -maccumulate-outgoing-args, and there's
>>> no need to use -mtune=generic.  Is that right?
>> Seems to work. What other side effects has that ?
> 
> Faster code, significant increase in code size though.

Does it affect code size when we don't have to realign the stack pointer?

Andrew.

Re: [PATCH][GIT PULL][v2.6.32] tracing/x86: Add check to detect GCC messing with mcount prologue

[Jakub Jelinek]

On Tue, Nov 24, 2009 at 03:32:20PM +0000, Andrew Haley wrote:
> Jakub Jelinek wrote:
> > On Tue, Nov 24, 2009 at 03:55:49PM +0100, Thomas Gleixner wrote:
> >>> you should compile your code with -maccumulate-outgoing-args, and there's
> >>> no need to use -mtune=generic.  Is that right?
> >> Seems to work. What other side effects has that ?
> > 
> > Faster code, significant increase in code size though.
> 
> Does it affect code size when we don't have to realign the stack pointer?

Yes, a lot.  The difference is that -maccumulate-outgoing-args allocates
space for arguments of the callee with most arguments in the prologue, using
subtraction from sp, then to pass arguments uses movl XXX, 4(%esp) etc.
and the stack pointer doesn't usually change within the function (except for
alloca/VLAs).
With -mno-accumulate-outgoing-args args are pushed using push instructions
and stack pointer is constantly changing.

	Jakub

Re: [PATCH][GIT PULL][v2.6.32] tracing/x86: Add check to detect GCC messing with mcount prologue

[Andrew Haley]

Jakub Jelinek wrote:
> On Tue, Nov 24, 2009 at 03:32:20PM +0000, Andrew Haley wrote:
>> Jakub Jelinek wrote:
>>> On Tue, Nov 24, 2009 at 03:55:49PM +0100, Thomas Gleixner wrote:
>>>>> you should compile your code with -maccumulate-outgoing-args, and there's
>>>>> no need to use -mtune=generic.  Is that right?
>>>> Seems to work. What other side effects has that ?
>>> Faster code, significant increase in code size though.
>> Does it affect code size when we don't have to realign the stack pointer?
> 
> Yes, a lot.  The difference is that -maccumulate-outgoing-args allocates
> space for arguments of the callee with most arguments in the prologue, using
> subtraction from sp, then to pass arguments uses movl XXX, 4(%esp) etc.
> and the stack pointer doesn't usually change within the function (except for
> alloca/VLAs).
> With -mno-accumulate-outgoing-args args are pushed using push instructions
> and stack pointer is constantly changing.

Alright.  So, it is possible in theory for gcc to generate code that
only uses -maccumulate-outgoing-args when it needs to realign SP.
And, therefore, we could have a nice option for the kernel: one with
(mostly) good code density and never generates the bizarre code
sequence in the prologue.

Andrew.

Re: [PATCH][GIT PULL][v2.6.32] tracing/x86: Add check to detect GCC messing with mcount prologue

[H. Peter Anvin]

On 11/24/2009 07:46 AM, Andrew Haley wrote:
>>
>> Yes, a lot.  The difference is that -maccumulate-outgoing-args allocates
>> space for arguments of the callee with most arguments in the prologue, using
>> subtraction from sp, then to pass arguments uses movl XXX, 4(%esp) etc.
>> and the stack pointer doesn't usually change within the function (except for
>> alloca/VLAs).
>> With -mno-accumulate-outgoing-args args are pushed using push instructions
>> and stack pointer is constantly changing.
> 
> Alright.  So, it is possible in theory for gcc to generate code that
> only uses -maccumulate-outgoing-args when it needs to realign SP.
> And, therefore, we could have a nice option for the kernel: one with
> (mostly) good code density and never generates the bizarre code
> sequence in the prologue.
> 

If we're changing gcc anyway, then let's add the option of intercepting
the function at the point where the machine state is well-defined by
ABI, which is before the function stack frame is set up.

-maccumulate-outgoing-args sounds like it would be painful on x86 (not
using its cheap push/pop instructions), but I guess since it's only when
tracing it's less of an issue.

	-hpa

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.

Re: [PATCH][GIT PULL][v2.6.32] tracing/x86: Add check to detect GCC messing with mcount prologue

[Andrew Haley]

H. Peter Anvin wrote:
> On 11/24/2009 07:46 AM, Andrew Haley wrote:
>>> Yes, a lot.  The difference is that -maccumulate-outgoing-args allocates
>>> space for arguments of the callee with most arguments in the prologue, using
>>> subtraction from sp, then to pass arguments uses movl XXX, 4(%esp) etc.
>>> and the stack pointer doesn't usually change within the function (except for
>>> alloca/VLAs).
>>> With -mno-accumulate-outgoing-args args are pushed using push instructions
>>> and stack pointer is constantly changing.
>> Alright.  So, it is possible in theory for gcc to generate code that
>> only uses -maccumulate-outgoing-args when it needs to realign SP.
>> And, therefore, we could have a nice option for the kernel: one with
>> (mostly) good code density and never generates the bizarre code
>> sequence in the prologue.
> 
> If we're changing gcc anyway, then let's add the option of intercepting
> the function at the point where the machine state is well-defined by
> ABI, which is before the function stack frame is set up.

Hmm.  On the x86 I suppose we could just inject a naked call instruction,
but not all aeches allow us to call anything before we've saved the return
address.  Or are you talking x86 only?

Andrew.

Re: [PATCH][GIT PULL][v2.6.32] tracing/x86: Add check to detect GCC messing with mcount prologue

[Steven Rostedt]

On Tue, 2009-11-24 at 17:12 +0000, Andrew Haley wrote:
> H. Peter Anvin wrote:

> > If we're changing gcc anyway, then let's add the option of intercepting
> > the function at the point where the machine state is well-defined by
> > ABI, which is before the function stack frame is set up.
> 
> Hmm.  On the x86 I suppose we could just inject a naked call instruction,
> but not all aeches allow us to call anything before we've saved the return
> address.  Or are you talking x86 only?

Earlier in the GCC BUG thread we talked about this. Adding a __fentry__
call at the beginning of the function. This could be done for other
archs as well, but yes, the return address must be stored. For x86 it is
the easiest because it automatically stores the return address on the
stack (Andi already has a working patch I believe).

For other archs, Linus showed some examples:

http://lkml.org/lkml/2009/11/19/349

-- Steve

Re: [PATCH][GIT PULL][v2.6.32] tracing/x86: Add check to detect GCC messing with mcount prologue

[H. Peter Anvin]

On 11/24/2009 09:30 AM, Steven Rostedt wrote:
> 
> For other archs, Linus showed some examples:
> 
> http://lkml.org/lkml/2009/11/19/349
> 

Yes; the key here is that the ABI-defined entry state is readily
mappable onto the state on entry to the __fentry__ function.

	-hpa

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.

Re: [PATCH][GIT PULL][v2.6.32] tracing/x86: Add check to detect GCC messing with mcount prologue

[H. Peter Anvin]

On 11/24/2009 09:12 AM, Andrew Haley wrote:
>>
>> If we're changing gcc anyway, then let's add the option of intercepting
>> the function at the point where the machine state is well-defined by
>> ABI, which is before the function stack frame is set up.
> 
> Hmm.  On the x86 I suppose we could just inject a naked call instruction,
> but not all aeches allow us to call anything before we've saved the return
> address.  Or are you talking x86 only?
> 

For x86, we should use a naked call.

For architectures where that is not possible, we should use a minimal
sequence such that the ABI state at the invocation point is 100% derivable.

On MIPS, for example, we could use a sequence such as:

	mov at, ra
	jal __fentry__

It would be up to __fentry__ to save the value in at and to restore it
back into ra before resuming, meaning that __fentry__ has a nonstandard
calling convention.

	-hpa

Re: [PATCH][GIT PULL][v2.6.32] tracing/x86: Add check to detect GCC messing with mcount prologue

[Thomas Gleixner]

On Tue, 24 Nov 2009, Jakub Jelinek wrote:

> On Tue, Nov 24, 2009 at 03:55:49PM +0100, Thomas Gleixner wrote:
> > > you should compile your code with -maccumulate-outgoing-args, and there's
> > > no need to use -mtune=generic.  Is that right?
> > 
> > Seems to work. What other side effects has that ?
> 
> Faster code, significant increase in code size though.  Note that on many
> architectures it is the only supported model.

Just checked on the affected -marchs. The increase in code size is
about 3% which is not that bad and definitely acceptable for the
tracing case. Will zap the -mtune=generic patch and use
-maccumulate-outgoing-args instead.

Thanks,

	tglx

Re: [PATCH][GIT PULL][v2.6.32] tracing/x86: Add check to detect GCC messing with mcount prologue

[Ingo Molnar]

* Thomas Gleixner <tglx@linutronix.de> wrote:

> On Tue, 24 Nov 2009, Jakub Jelinek wrote:
> 
> > On Tue, Nov 24, 2009 at 03:55:49PM +0100, Thomas Gleixner wrote:
> > > > you should compile your code with -maccumulate-outgoing-args, and there's
> > > > no need to use -mtune=generic.  Is that right?
> > > 
> > > Seems to work. What other side effects has that ?
> > 
> > Faster code, significant increase in code size though.  Note that on many
> > architectures it is the only supported model.
> 
> Just checked on the affected -marchs. The increase in code size is 
> about 3% which is not that bad and definitely acceptable for the 
> tracing case. Will zap the -mtune=generic patch and use 
> -maccumulate-outgoing-args instead.

hm, 3% sounds quite large :( dyn-ftrace is enabled in distro configs, so 
3% is a big deal IMO.

	Ingo

Re: [PATCH][GIT PULL][v2.6.32] tracing/x86: Add check to detect GCC messing with mcount prologue

[Thomas Gleixner]

On Wed, 25 Nov 2009, Ingo Molnar wrote:
> * Thomas Gleixner <tglx@linutronix.de> wrote:
> 
> > On Tue, 24 Nov 2009, Jakub Jelinek wrote:
> > 
> > > On Tue, Nov 24, 2009 at 03:55:49PM +0100, Thomas Gleixner wrote:
> > > > > you should compile your code with -maccumulate-outgoing-args, and there's
> > > > > no need to use -mtune=generic.  Is that right?
> > > > 
> > > > Seems to work. What other side effects has that ?
> > > 
> > > Faster code, significant increase in code size though.  Note that on many
> > > architectures it is the only supported model.
> > 
> > Just checked on the affected -marchs. The increase in code size is 
> > about 3% which is not that bad and definitely acceptable for the 
> > tracing case. Will zap the -mtune=generic patch and use 
> > -maccumulate-outgoing-args instead.
> 
> hm, 3% sounds quite large :( dyn-ftrace is enabled in distro configs, so 
> 3% is a big deal IMO.

Distro-configs have -mtune=generic anyway. So it's not changing
anything for them.

I'm talking about the -march flags which result in that weird code
(pentium-mmx ....).

Thanks,

	tglx

Re: [PATCH][GIT PULL][v2.6.32] tracing/x86: Add check to detect GCC messing with mcount prologue

[Ingo Molnar]

* Thomas Gleixner <tglx@linutronix.de> wrote:

> On Wed, 25 Nov 2009, Ingo Molnar wrote:
> > * Thomas Gleixner <tglx@linutronix.de> wrote:
> > 
> > > On Tue, 24 Nov 2009, Jakub Jelinek wrote:
> > > 
> > > > On Tue, Nov 24, 2009 at 03:55:49PM +0100, Thomas Gleixner wrote:
> > > > > > you should compile your code with -maccumulate-outgoing-args, and there's
> > > > > > no need to use -mtune=generic.  Is that right?
> > > > > 
> > > > > Seems to work. What other side effects has that ?
> > > > 
> > > > Faster code, significant increase in code size though.  Note that on many
> > > > architectures it is the only supported model.
> > > 
> > > Just checked on the affected -marchs. The increase in code size is 
> > > about 3% which is not that bad and definitely acceptable for the 
> > > tracing case. Will zap the -mtune=generic patch and use 
> > > -maccumulate-outgoing-args instead.
> > 
> > hm, 3% sounds quite large :( dyn-ftrace is enabled in distro configs, so 
> > 3% is a big deal IMO.
> 
> Distro-configs have -mtune=generic anyway. So it's not changing
> anything for them.
> 
> I'm talking about the -march flags which result in that weird code
> (pentium-mmx ....).

ok!

	Ingo

Re: [PATCH][GIT PULL][v2.6.32] tracing/x86: Add check to detect GCC messing with mcount prologue

[Jakub Jelinek]

On Wed, Nov 25, 2009 at 04:44:52PM +0100, Ingo Molnar wrote:
> 
> * Thomas Gleixner <tglx@linutronix.de> wrote:
> 
> > On Tue, 24 Nov 2009, Jakub Jelinek wrote:
> > 
> > > On Tue, Nov 24, 2009 at 03:55:49PM +0100, Thomas Gleixner wrote:
> > > > > you should compile your code with -maccumulate-outgoing-args, and there's
> > > > > no need to use -mtune=generic.  Is that right?
> > > > 
> > > > Seems to work. What other side effects has that ?
> > > 
> > > Faster code, significant increase in code size though.  Note that on many
> > > architectures it is the only supported model.
> > 
> > Just checked on the affected -marchs. The increase in code size is 
> > about 3% which is not that bad and definitely acceptable for the 
> > tracing case. Will zap the -mtune=generic patch and use 
> > -maccumulate-outgoing-args instead.
> 
> hm, 3% sounds quite large :( dyn-ftrace is enabled in distro configs, so 
> 3% is a big deal IMO.

If you compile kernels 90%+ people out there run with -p on i?86/x86_64,
then certainly coming up with a new gcc switch and new profiling ABI is
desirable.  -p on i?86/x86_64 e.g. forces -fno-omit-frame-pointer, which
makes code on these register starved arches significantly worse.
Making GCC output profiling call before prologue instead of after prologue
is a 4 liner in generic code and a few lines in target specific code.
The important thing is that we shouldn't have 100 different profiling ABIs,
so it is desirable to agree on something that will be generally useful not
just for the kernel, but perhaps for other purposes.

	Jakub

Re: [PATCH][GIT PULL][v2.6.32] tracing/x86: Add check to detect GCC messing with mcount prologue

[H. Peter Anvin]

On 11/25/2009 08:44 AM, Jakub Jelinek wrote:
> 
> If you compile kernels 90%+ people out there run with -p on i?86/x86_64,
> then certainly coming up with a new gcc switch and new profiling ABI is
> desirable.  -p on i?86/x86_64 e.g. forces -fno-omit-frame-pointer, which
> makes code on these register starved arches significantly worse.
> Making GCC output profiling call before prologue instead of after prologue
> is a 4 liner in generic code and a few lines in target specific code.
> The important thing is that we shouldn't have 100 different profiling ABIs,
> so it is desirable to agree on something that will be generally useful not
> just for the kernel, but perhaps for other purposes.
> 

There is really just one that makes sense, which is providing the
ABI-defined entry state, which means intercepting at the point of entry.

Anything else is/was a mistake.

	-hpa

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.

Re: [PATCH][GIT PULL][v2.6.32] tracing/x86: Add check to detect GCC messing with mcount prologue

[Andrew Haley]

H. Peter Anvin wrote:
> On 11/25/2009 08:44 AM, Jakub Jelinek wrote:
>> If you compile kernels 90%+ people out there run with -p on i?86/x86_64,
>> then certainly coming up with a new gcc switch and new profiling ABI is
>> desirable.  -p on i?86/x86_64 e.g. forces -fno-omit-frame-pointer, which
>> makes code on these register starved arches significantly worse.
>> Making GCC output profiling call before prologue instead of after prologue
>> is a 4 liner in generic code and a few lines in target specific code.
>> The important thing is that we shouldn't have 100 different profiling ABIs,
>> so it is desirable to agree on something that will be generally useful not
>> just for the kernel, but perhaps for other purposes.
> 
> There is really just one that makes sense, which is providing the
> ABI-defined entry state, which means intercepting at the point of entry.
> 
> Anything else is/was a mistake.

Indeed.  The problem, though, is that the "naked call" approach, while attractive,
requires the back end to be modified and so requires the help of the gcc maintainers
for every Linux target.  Not that this is a terrible idea, but such co-ordination
is going to take time.

Andrew.

Re: [PATCH][GIT PULL][v2.6.32] tracing/x86: Add check to detect GCC messing with mcount prologue

[Ingo Molnar]

* Steven Rostedt <rostedt@goodmis.org> wrote:

> Ingo, Thomas and Linus,
> 
> I know Thomas did a patch to force the -mtune=generic, but just in 
> case gcc decides to do something crazy again, this patch will catch 
> it.
> 
> Should we try to get this in now?

Very nice example of defensive coding - i like this. I've queued it up 
for .33 (unless anyone objects) as i think it's too late for .32.

	Ingo

[tip:timers/urgent] hrtimer: Fix /proc/timer_list regression

[tip-bot for Feng Tang]

Commit-ID:  8629ea2eaba8ca0de2e38ce1b4a825e16255976e
Gitweb:     http://git.kernel.org/tip/8629ea2eaba8ca0de2e38ce1b4a825e16255976e
Author:     Feng Tang <feng.tang@intel.com>
AuthorDate: Thu, 3 Sep 2009 16:32:53 +0800
Committer:  Thomas Gleixner <tglx@linutronix.de>
CommitDate: Fri, 20 Nov 2009 11:25:48 +0100

hrtimer: Fix /proc/timer_list regression

commit 507e1231 (timer stats: Optimize by adding quick check to avoid
function calls) introduced a regression in /proc/timer_list.

/proc/timer_list shows now
 #0: <c27d46b0>, tick_sched_timer, S:01, <(null)>, /-1
instead of
 #0: <c27d46b0>, tick_sched_timer, S:01, hrtimer_start, swapper/0

Revert the hrtimer quick check for now. The optimization needs more
thought, but this is neither 2.6.32-rc7 nor stable material.

[ tglx: - Removed unrelated changes from the original patch
  	- Prevent unneccesary call to timer_stats_update_stats
	- massaged the changelog ]

Signed-off-by: Feng Tang <feng.tang@intel.com>
LKML-Reference: <alpine.LFD.2.00.0911181933540.24119@localhost.localdomain>
Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
Cc: stable@kernel.org
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
---
 include/linux/hrtimer.h |    4 +---
 1 files changed, 1 insertions(+), 3 deletions(-)

diff --git a/include/linux/hrtimer.h b/include/linux/hrtimer.h
index ff037f0..9bace4b 100644
--- a/include/linux/hrtimer.h
+++ b/include/linux/hrtimer.h
@@ -446,7 +446,7 @@ extern void timer_stats_update_stats(void *timer, pid_t pid, void *startf,
 
 static inline void timer_stats_account_hrtimer(struct hrtimer *timer)
 {
-	if (likely(!timer->start_site))
+	if (likely(!timer_stats_active))
 		return;
 	timer_stats_update_stats(timer, timer->start_pid, timer->start_site,
 				 timer->function, timer->start_comm, 0);
@@ -457,8 +457,6 @@ extern void __timer_stats_hrtimer_set_start_info(struct hrtimer *timer,
 
 static inline void timer_stats_hrtimer_set_start_info(struct hrtimer *timer)
 {
-	if (likely(!timer_stats_active))
-		return;
 	__timer_stats_hrtimer_set_start_info(timer, __builtin_return_address(0));
 }
 

Re: [tip:timers/urgent] hrtimer: Fix /proc/timer_list regression

[Heiko Carstens]

On Fri, Nov 20, 2009 at 10:30:39AM +0000, tip-bot for Feng Tang wrote:
> Commit-ID:  8629ea2eaba8ca0de2e38ce1b4a825e16255976e
> Gitweb:     http://git.kernel.org/tip/8629ea2eaba8ca0de2e38ce1b4a825e16255976e
> Author:     Feng Tang <feng.tang@intel.com>
> AuthorDate: Thu, 3 Sep 2009 16:32:53 +0800
> Committer:  Thomas Gleixner <tglx@linutronix.de>
> CommitDate: Fri, 20 Nov 2009 11:25:48 +0100
> 
> hrtimer: Fix /proc/timer_list regression
> 
> commit 507e1231 (timer stats: Optimize by adding quick check to avoid
> function calls) introduced a regression in /proc/timer_list.
> 
> /proc/timer_list shows now
>  #0: <c27d46b0>, tick_sched_timer, S:01, <(null)>, /-1
> instead of
>  #0: <c27d46b0>, tick_sched_timer, S:01, hrtimer_start, swapper/0

For a 'real' fix I see three possible ways if timer_stats are disabled:

Print something like:

#0: <c27d46b0>, tick_sched_timer, S:01, unknown, unknown/-1

That way the format would be still the same and it should be quite obvious
that timer_stats are disabled and should be enabled.

Alternatively leave start_site, taskname and pid away if the correspending
timer has a NULL start_site. That would be the same like for the !TIMER_STATS
case:

#0: <c27d46b0>, tick_sched_timer, S:01

or (worst choice) revert the whole optimization and live with extra cpu cost.

Re: BUG: GCC-4.4.x changes the function frame on some functions

[H. Peter Anvin]

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

On i386, if we call __fentry__ immediately on entry the return address will be in 4(%esp), so I fail to see how you could not reliably have the return address.  Other arches would have different constraints, of course.

"Frederic Weisbecker" <fweisbec@gmail.com> wrote:

>On Thu, Nov 19, 2009 at 03:05:41PM -0500, Steven Rostedt wrote:
>> On Thu, 2009-11-19 at 20:46 +0100, Frederic Weisbecker wrote:
>> > On Thu, Nov 19, 2009 at 02:28:06PM -0500, Steven Rostedt wrote:
>> 
>> > > 	<function>:
>> > > 		call __fentry__
>> > > 		[...]
>> > > 
>> > > 	
>> > > -- Steve
>> > 
>> > 
>> > I would really like this. So that we can forget about other possible
>> > further suprises due to sophisticated function prologues beeing before
>> > the mcount call.
>> > 
>> > And I guess that would fix it in every archs.
>> 
>> Well, other archs use a register to store the return address. But it
>> would also be easy to do (pseudo arch assembly):
>> 
>> 	<function>:
>> 		mov lr, (%sp)
>> 		add 8, %sp
>> 		blr __fentry__
>> 		sub 8, %sp
>> 		mov (%sp), lr
>> 
>> 
>> That way the lr would have the current function, and the parent would
>> still be at 8(%sp)
>> 
>
>
>Yeah right, we need at least such very tiny prologue for
>archs that store return addresses in a reg.
>
>	
>> > 
>> > That said, Linus had a good point about the fact there might other uses
>> > of mcount even more tricky than what does the function graph tracer,
>> > outside the kernel, and those may depend on the strict ABI assumption
>> > that 4(ebp) is always the _real_ return address, and that through all
>> > the previous stack call. This is even a concern that extrapolates the
>> > single mcount case.
>> 
>> As I am proposing a new call. This means that mcount stay as is for
>> legacy reasons. Yes I know there exists the -finstrument-functions but
>> that adds way too much bloat to the code. One single call to the
>> profiler is all I want.
>
>
>Sure, the purpose is not to change the existing -mcount thing.
>What I meant is that we could have -mcount and -real-ra-before-fp
>at the same time to guarantee fp + 4 is really what we want while
>using -mcount.
>
>The __fentry__ idea is more neat, but the guarantee of a real pointer
>to the return address is still something that lacks.
>
>
>> > 
>> > So I wonder that actually the real problem is the lack of something that
>> > could provide this guarantee. We may need a -real-ra-before-fp (yeah
>> > I suck in naming).
>> 
>> Don't worry, so do the C compiler folks, I mean, come on "mcount"?
>
>
>I guess it has been first created for the single purpose of counting
>specific functions but then it has been used for wider, unpredicted uses :)
>

--
Sent from my mobile phone. Please excuse any lack of formatting.

Re: BUG: GCC-4.4.x changes the function frame on some functions

[H. Peter Anvin]

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

Hence a new unconstrained option...

"Jeff Law" <law@redhat.com> wrote:

>On 11/19/09 12:50, H. Peter Anvin wrote:
>>
>> Calling the profiler immediately at the entry point is clearly the more
>> sane option.  It means the ABI is well-defined, stable, and independent
>> of what the actual function contents are.  It means that ABI isn't the
>> normal C ABI (the __fentry__ function would have to preserve all
>> registers), but that's fine...
>>    
>Note there are targets (even some old x86 variants) that required the 
>profiling calls to occur after the prologue.  Unfortunately, nobody 
>documented *why* that  was the case.   Sigh.
>
>Jeff

--
Sent from my mobile phone. Please excuse any lack of formatting.

Re: BUG: GCC-4.4.x changes the function frame on some functions

[Jeff Law]

On 11/19/09 14:14, H. Peter Anvin wrote:
> Hence a new unconstrained option...
>    
Not arguing against it, just noting there are targets where after the 
prologue mcount is mandated.   There's certainly hooks in GCC to do it 
both ways and if there's no clear need to use after-prologue on 
x86-linux, then before-prologue seems reasonable to me.

It's also the case that aligning stacks on the x86 and the poor code 
generated when used with profiling is an interaction I doubt anyone has 
looked at until now.  The result is definitely ugly and inefficient -- 
and there's something to be said for cleaning that up and at least 
marginally reducing the overhead of profiling.

Having said all that, I don't expect to personally be looking at the 
problem, given the list of other codegen issues that need to be looked 
at (reload in particular), profiling/stack interactions would be around 
87 millionth on my list.

jeff

Re: BUG: GCC-4.4.x changes the function frame on some functions

[Steven Rostedt]

On Thu, 2009-11-19 at 14:25 -0700, Jeff Law wrote:

> Having said all that, I don't expect to personally be looking at the 
> problem, given the list of other codegen issues that need to be looked 
> at (reload in particular), profiling/stack interactions would be around 
> 87 millionth on my list.

Is there someone else that can look at it?

Or at the very least, could you point us to where that code is, and one
of us tracing folks could take a crack at switching hats to be a
compiler writer (with the obvious prerequisite of drinking a lot of beer
first, or is there a better drug to cope with the pain of writing gcc?).

-- Steve
 

Re: BUG: GCC-4.4.x changes the function frame on some functions

[Jeff Law]

On 11/19/09 15:43, Steven Rostedt wrote:
> On Thu, 2009-11-19 at 14:25 -0700, Jeff Law wrote:
>
>    
>> Having said all that, I don't expect to personally be looking at the
>> problem, given the list of other codegen issues that need to be looked
>> at (reload in particular), profiling/stack interactions would be around
>> 87 millionth on my list.
>>      
> Is there someone else that can look at it?
>
>    
Unsure at the moment...  Like everyone else, GCC developers are busy and 
this probably isn't going to be a high priority item for anyone.


> Or at the very least, could you point us to where that code is, and one
> of us tracing folks could take a crack at switching hats to be a
> compiler writer (with the obvious prerequisite of drinking a lot of beer
> first, or is there a better drug to cope with the pain of writing gcc?).
>    
It _might_ be as easy as defining PROFILE_BEFORE_PROLOGUE in
gcc-<someversion>gcc/config/i386/linux.h & rebuilding GCC.

Based on comments elsewhere, the sun386i support may have used 
PROFILE_BEFORE_PROLOGUE in the past and thus the x86 backend may not 
need further adjustment.  That is obviously the ideal case.

If that appears to work for your needs, I'll volunteer to test it more 
thoroughly and assuming those tests look good shepherd it into the 
source tree.

Jeff

Re: BUG: GCC-4.4.x changes the function frame on some functions

[Thomas Gleixner]

On Thu, 19 Nov 2009, Jeff Law wrote:
> On 11/19/09 15:43, Steven Rostedt wrote:
> > On Thu, 2009-11-19 at 14:25 -0700, Jeff Law wrote:
> > 
> >    
> > > Having said all that, I don't expect to personally be looking at the
> > > problem, given the list of other codegen issues that need to be looked
> > > at (reload in particular), profiling/stack interactions would be around
> > > 87 millionth on my list.
> > >      
> > Is there someone else that can look at it?
> > 
> >    
> Unsure at the moment...  Like everyone else, GCC developers are busy and this
> probably isn't going to be a high priority item for anyone.
> 
> 
> > Or at the very least, could you point us to where that code is, and one
> > of us tracing folks could take a crack at switching hats to be a
> > compiler writer (with the obvious prerequisite of drinking a lot of beer
> > first, or is there a better drug to cope with the pain of writing gcc?).
> >    
> It _might_ be as easy as defining PROFILE_BEFORE_PROLOGUE in
> gcc-<someversion>gcc/config/i386/linux.h & rebuilding GCC.
> 
> Based on comments elsewhere, the sun386i support may have used
> PROFILE_BEFORE_PROLOGUE in the past and thus the x86 backend may not need
> further adjustment.  That is obviously the ideal case.
> 
> If that appears to work for your needs, I'll volunteer to test it more
> thoroughly and assuming those tests look good shepherd it into the source
> tree.

We definitely want to see that ASAP.

While testing various kernel configs we found out that the problem
comes and goes. Finally I started to compare the gcc command line
options and after some fiddling it turned out that the following
minimal deltas change the code generator behaviour:

Bad:  -march=pentium-mmx                -Wa,-mtune=generic32
Good: -march=i686        -mtune=generic -Wa,-mtune=generic32
Good: -march=pentium-mmx -mtune-generic -Wa,-mtune=generic32

I'm not supposed to understand the logic behind that, right ?

Thanks,

	tglx

Re: BUG: GCC-4.4.x changes the function frame on some functions

[Linus Torvalds]

On Fri, 20 Nov 2009, Thomas Gleixner wrote:
> 
> While testing various kernel configs we found out that the problem
> comes and goes. Finally I started to compare the gcc command line
> options and after some fiddling it turned out that the following
> minimal deltas change the code generator behaviour:
> 
> Bad:  -march=pentium-mmx                -Wa,-mtune=generic32
> Good: -march=i686        -mtune=generic -Wa,-mtune=generic32
> Good: -march=pentium-mmx -mtune-generic -Wa,-mtune=generic32
> 
> I'm not supposed to understand the logic behind that, right ?

Are you sure it's just the compiler flags?

There's another configuration portion: the size of the alignment itself. 
That's dependent on L1_CACHE_SHIFT, which in turn is taken from the kernel 
config CONFIG_X86_L1_CACHE_SHIFT.

Maybe that value matters too - for example maybe gcc will not try to align 
the stack if it's big?

[ Btw, looking at that, why are X86_L1_CACHE_BYTES and X86_L1_CACHE_SHIFT 
  totally unrelated numbers? Very confusing. ]

The compiler flags we use are tied to some of the same choices that choose 
the cache shift, so the correlation you found while debugging this would 
still hold.

			Linus

Re: BUG: GCC-4.4.x changes the function frame on some functions

[Thomas Gleixner]

On Thu, 19 Nov 2009, Linus Torvalds wrote:
> On Fri, 20 Nov 2009, Thomas Gleixner wrote:
> > 
> > While testing various kernel configs we found out that the problem
> > comes and goes. Finally I started to compare the gcc command line
> > options and after some fiddling it turned out that the following
> > minimal deltas change the code generator behaviour:
> > 
> > Bad:  -march=pentium-mmx                -Wa,-mtune=generic32
> > Good: -march=i686        -mtune=generic -Wa,-mtune=generic32
> > Good: -march=pentium-mmx -mtune-generic -Wa,-mtune=generic32
> > 
> > I'm not supposed to understand the logic behind that, right ?
> 
> Are you sure it's just the compiler flags?

I first captured the command line with V=1 and created a script of
it. Then I changed the -march -mtune options in that script and
compiled just that single file manually w/o changing .config or
invoking the kernel make magic.

The good ones produce:

650:   55                      push   %ebp
651:   89 e5                   mov    %esp,%ebp
653:   83 e4 f0                and    $0xfffffff0,%esp

The bad one:

000005f0 <timer_stats_update_stats>:
 5f0:   57                      push   %edi
 5f1:   8d 7c 24 08             lea    0x8(%esp),%edi
 5f5:   83 e4 f0                and    $0xfffffff0,%esp
 5f8:   ff 77 fc                pushl  -0x4(%edi)
 5fb:   55                      push   %ebp
 5fc:   89 e5                   mov    %esp,%ebp
 
> There's another configuration portion: the size of the alignment itself. 
> That's dependent on L1_CACHE_SHIFT, which in turn is taken from the kernel 
> config CONFIG_X86_L1_CACHE_SHIFT.
> 
> Maybe that value matters too - for example maybe gcc will not try to align 
> the stack if it's big?

That does not change any of the compiler options, but yes it could
have some effect via the various include magics, but all I have seen
so far is linkage.h which should not affect the compiler. And the
manual compile did not change any of this.
 
> [ Btw, looking at that, why are X86_L1_CACHE_BYTES and X86_L1_CACHE_SHIFT 
>   totally unrelated numbers? Very confusing. ]

Agreed.

> The compiler flags we use are tied to some of the same choices that choose 
> the cache shift, so the correlation you found while debugging this would 
> still hold.

Digging further tomorrow when my brain is more awake.

Thanks,

	tglx

Re: BUG: GCC-4.4.x changes the function frame on some functions

[Thomas Gleixner]

On Fri, 20 Nov 2009, Thomas Gleixner wrote:

> On Thu, 19 Nov 2009, Linus Torvalds wrote:
> > On Fri, 20 Nov 2009, Thomas Gleixner wrote:
> > > 
> > > While testing various kernel configs we found out that the problem
> > > comes and goes. Finally I started to compare the gcc command line
> > > options and after some fiddling it turned out that the following
> > > minimal deltas change the code generator behaviour:
> > > 
> > > Bad:  -march=pentium-mmx                -Wa,-mtune=generic32
> > > Good: -march=i686        -mtune=generic -Wa,-mtune=generic32
> > > Good: -march=pentium-mmx -mtune-generic -Wa,-mtune=generic32

Found some more:

Bad:  -march=k6                   -Wa,-mtune=generic32
Bad:  -march=geode                -Wa,-mtune=generic32
Bad:  -march=c3                   -Wa,-mtune=generic32

That seems every thing which has MMX support but no SSE and is somehow
compatible to the pentium-mmx.

Looks like the code generator optimization for those was done after
consuming the secret gcc-shrooms.

Thanks,

	tglx

Re: BUG: GCC-4.4.x changes the function frame on some functions

[H. Peter Anvin]

On 11/19/2009 04:59 PM, Linus Torvalds wrote:
> 
> [ Btw, looking at that, why are X86_L1_CACHE_BYTES and X86_L1_CACHE_SHIFT 
>   totally unrelated numbers? Very confusing. ]
> 

Yes, there is another thread to clean up that particular mess; it is
already in -tip:

http://git.kernel.org/tip/350f8f5631922c7848ec4b530c111cb8c2ff7caa

	-hpa

Re: BUG: GCC-4.4.x changes the function frame on some functions

[Ingo Molnar]

* Linus Torvalds <torvalds@linux-foundation.org> wrote:

> [ Btw, looking at that, why are X86_L1_CACHE_BYTES and X86_L1_CACHE_SHIFT 
>   totally unrelated numbers? Very confusing. ]

incidentally (or maybe not so incidentally) that got fixed yesterday in 
-tip - at around the time i triggered that crash:

  350f8f5: x86: Eliminate redundant/contradicting cache line size config options

See the full commit below. The config that triggered the crash for me 
has:

  CONFIG_X86_L1_CACHE_SHIFT=4

so it's 16 bytes - and it's consistent now, which is a new angle. So i 
think this explains why it stayed dormant for such a long time - it was 
hidden by the cacheline-size config value inconsistencies.

	Ingo

----------------->
>From 350f8f5631922c7848ec4b530c111cb8c2ff7caa Mon Sep 17 00:00:00 2001
From: Jan Beulich <JBeulich@novell.com>
Date: Fri, 13 Nov 2009 11:54:40 +0000
Subject: [PATCH] x86: Eliminate redundant/contradicting cache line size config options

Rather than having X86_L1_CACHE_BYTES and X86_L1_CACHE_SHIFT
(with inconsistent defaults), just having the latter suffices as
the former can be easily calculated from it.

To be consistent, also change X86_INTERNODE_CACHE_BYTES to
X86_INTERNODE_CACHE_SHIFT, and set it to 7 (128 bytes) for NUMA
to account for last level cache line size (which here matters
more than L1 cache line size).

Finally, make sure the default value for X86_L1_CACHE_SHIFT,
when X86_GENERIC is selected, is being seen before that for the
individual CPU model options (other than on x86-64, where
GENERIC_CPU is part of the choice construct, X86_GENERIC is a
separate option on ix86).

Signed-off-by: Jan Beulich <jbeulich@novell.com>
Acked-by: Ravikiran Thirumalai <kiran@scalex86.org>
Acked-by: Nick Piggin <npiggin@suse.de>
LKML-Reference: <4AFD5710020000780001F8F0@vpn.id2.novell.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
---
 arch/x86/Kconfig.cpu                   |   14 +++++---------
 arch/x86/boot/compressed/vmlinux.lds.S |    3 ++-
 arch/x86/include/asm/cache.h           |    7 ++++---
 arch/x86/kernel/vmlinux.lds.S          |   10 +++++-----
 arch/x86/mm/tlb.c                      |    3 ++-
 5 files changed, 18 insertions(+), 19 deletions(-)

diff --git a/arch/x86/Kconfig.cpu b/arch/x86/Kconfig.cpu
index f2824fb..621f2bd 100644
--- a/arch/x86/Kconfig.cpu
+++ b/arch/x86/Kconfig.cpu
@@ -301,15 +301,11 @@ config X86_CPU
 
 #
 # Define implied options from the CPU selection here
-config X86_L1_CACHE_BYTES
+config X86_INTERNODE_CACHE_SHIFT
 	int
-	default "128" if MPSC
-	default "64" if GENERIC_CPU || MK8 || MCORE2 || MATOM || X86_32
-
-config X86_INTERNODE_CACHE_BYTES
-	int
-	default "4096" if X86_VSMP
-	default X86_L1_CACHE_BYTES if !X86_VSMP
+	default "12" if X86_VSMP
+	default "7" if NUMA
+	default X86_L1_CACHE_SHIFT
 
 config X86_CMPXCHG
 	def_bool X86_64 || (X86_32 && !M386)
@@ -317,9 +313,9 @@ config X86_CMPXCHG
 config X86_L1_CACHE_SHIFT
 	int
 	default "7" if MPENTIUM4 || MPSC
+	default "6" if MK7 || MK8 || MPENTIUMM || MCORE2 || MATOM || MVIAC7 || X86_GENERIC || GENERIC_CPU
 	default "4" if X86_ELAN || M486 || M386 || MGEODEGX1
 	default "5" if MWINCHIP3D || MWINCHIPC6 || MCRUSOE || MEFFICEON || MCYRIXIII || MK6 || MPENTIUMIII || MPENTIUMII || M686 || M586MMX || M586TSC || M586 || MVIAC3_2 || MGEODE_LX
-	default "6" if MK7 || MK8 || MPENTIUMM || MCORE2 || MATOM || MVIAC7 || X86_GENERIC || GENERIC_CPU
 
 config X86_XADD
 	def_bool y
diff --git a/arch/x86/boot/compressed/vmlinux.lds.S b/arch/x86/boot/compressed/vmlinux.lds.S
index f4193bb..a6f1a59 100644
--- a/arch/x86/boot/compressed/vmlinux.lds.S
+++ b/arch/x86/boot/compressed/vmlinux.lds.S
@@ -4,6 +4,7 @@ OUTPUT_FORMAT(CONFIG_OUTPUT_FORMAT, CONFIG_OUTPUT_FORMAT, CONFIG_OUTPUT_FORMAT)
 
 #undef i386
 
+#include <asm/cache.h>
 #include <asm/page_types.h>
 
 #ifdef CONFIG_X86_64
@@ -46,7 +47,7 @@ SECTIONS
 		*(.data.*)
 		_edata = . ;
 	}
-	. = ALIGN(CONFIG_X86_L1_CACHE_BYTES);
+	. = ALIGN(L1_CACHE_BYTES);
 	.bss : {
 		_bss = . ;
 		*(.bss)
diff --git a/arch/x86/include/asm/cache.h b/arch/x86/include/asm/cache.h
index 549860d..2f9047c 100644
--- a/arch/x86/include/asm/cache.h
+++ b/arch/x86/include/asm/cache.h
@@ -9,12 +9,13 @@
 
 #define __read_mostly __attribute__((__section__(".data.read_mostly")))
 
+#define INTERNODE_CACHE_SHIFT CONFIG_X86_INTERNODE_CACHE_SHIFT
+#define INTERNODE_CACHE_BYTES (1 << INTERNODE_CACHE_SHIFT)
+
 #ifdef CONFIG_X86_VSMP
-/* vSMP Internode cacheline shift */
-#define INTERNODE_CACHE_SHIFT (12)
 #ifdef CONFIG_SMP
 #define __cacheline_aligned_in_smp					\
-	__attribute__((__aligned__(1 << (INTERNODE_CACHE_SHIFT))))	\
+	__attribute__((__aligned__(INTERNODE_CACHE_BYTES)))		\
 	__page_aligned_data
 #endif
 #endif
diff --git a/arch/x86/kernel/vmlinux.lds.S b/arch/x86/kernel/vmlinux.lds.S
index fd2dabe..eeb4f5f 100644
--- a/arch/x86/kernel/vmlinux.lds.S
+++ b/arch/x86/kernel/vmlinux.lds.S
@@ -135,13 +135,13 @@ SECTIONS
 
 		PAGE_ALIGNED_DATA(PAGE_SIZE)
 
-		CACHELINE_ALIGNED_DATA(CONFIG_X86_L1_CACHE_BYTES)
+		CACHELINE_ALIGNED_DATA(L1_CACHE_BYTES)
 
 		DATA_DATA
 		CONSTRUCTORS
 
 		/* rarely changed data like cpu maps */
-		READ_MOSTLY_DATA(CONFIG_X86_INTERNODE_CACHE_BYTES)
+		READ_MOSTLY_DATA(INTERNODE_CACHE_BYTES)
 
 		/* End of data section */
 		_edata = .;
@@ -165,12 +165,12 @@ SECTIONS
 		*(.vsyscall_0)
 	} :user
 
-	. = ALIGN(CONFIG_X86_L1_CACHE_BYTES);
+	. = ALIGN(L1_CACHE_BYTES);
 	.vsyscall_fn : AT(VLOAD(.vsyscall_fn)) {
 		*(.vsyscall_fn)
 	}
 
-	. = ALIGN(CONFIG_X86_L1_CACHE_BYTES);
+	. = ALIGN(L1_CACHE_BYTES);
 	.vsyscall_gtod_data : AT(VLOAD(.vsyscall_gtod_data)) {
 		*(.vsyscall_gtod_data)
 	}
@@ -194,7 +194,7 @@ SECTIONS
 	}
 	vgetcpu_mode = VVIRT(.vgetcpu_mode);
 
-	. = ALIGN(CONFIG_X86_L1_CACHE_BYTES);
+	. = ALIGN(L1_CACHE_BYTES);
 	.jiffies : AT(VLOAD(.jiffies)) {
 		*(.jiffies)
 	}
diff --git a/arch/x86/mm/tlb.c b/arch/x86/mm/tlb.c
index 36fe08e..65b58e4 100644
--- a/arch/x86/mm/tlb.c
+++ b/arch/x86/mm/tlb.c
@@ -8,6 +8,7 @@
 
 #include <asm/tlbflush.h>
 #include <asm/mmu_context.h>
+#include <asm/cache.h>
 #include <asm/apic.h>
 #include <asm/uv/uv.h>
 
@@ -43,7 +44,7 @@ union smp_flush_state {
 		spinlock_t tlbstate_lock;
 		DECLARE_BITMAP(flush_cpumask, NR_CPUS);
 	};
-	char pad[CONFIG_X86_INTERNODE_CACHE_BYTES];
+	char pad[INTERNODE_CACHE_BYTES];
 } ____cacheline_internodealigned_in_smp;
 
 /* State is put into the per CPU data section, but padded

Re: BUG: GCC-4.4.x changes the function frame on some functions

[Andrew Haley]

Thomas Gleixner wrote:

> While testing various kernel configs we found out that the problem
> comes and goes. Finally I started to compare the gcc command line
> options and after some fiddling it turned out that the following
> minimal deltas change the code generator behaviour:
> 
> Bad:  -march=pentium-mmx                -Wa,-mtune=generic32
> Good: -march=i686        -mtune=generic -Wa,-mtune=generic32
> Good: -march=pentium-mmx -mtune-generic -Wa,-mtune=generic32
> 
> I'm not supposed to understand the logic behind that, right ?

I don't either.  I'm seeing:

timer_stats_update_stats:                                       timer_stats_update_stats:
        pushl   %edi                                          <
        leal    8(%esp), %edi                                 <
        andl    $-16, %esp                                    <
        pushl   -4(%edi)                                      <
        pushl   %ebp                                                    pushl   %ebp
        movl    %esp, %ebp                                              movl    %esp, %ebp
        pushl   %edi                                          |         andl    $-16, %esp
        pushl   %esi                                          |         subl    $112, %esp
        pushl   %ebx                                          |         movl    %ebx, 100(%esp)
        subl    $108, %esp                                    |         movl    %esi, 104(%esp)
                                                              >         movl    %edi, 108(%esp)
        call    mcount                                                  call    mcount

where the only difference is -mtune=generic.  I'm investigating.

Andrew.

Re: BUG: GCC-4.4.x changes the function frame on some functions

[Andrew Haley]

Andrew Haley wrote:
> Thomas Gleixner wrote:
> 
>> While testing various kernel configs we found out that the problem
>> comes and goes. Finally I started to compare the gcc command line
>> options and after some fiddling it turned out that the following
>> minimal deltas change the code generator behaviour:
>>
>> Bad:  -march=pentium-mmx                -Wa,-mtune=generic32
>> Good: -march=i686        -mtune=generic -Wa,-mtune=generic32
>> Good: -march=pentium-mmx -mtune-generic -Wa,-mtune=generic32
>>
>> I'm not supposed to understand the logic behind that, right ?
> 
> I don't either.  I'm seeing:
> 
> timer_stats_update_stats:                                       timer_stats_update_stats:
>         pushl   %edi                                          <
>         leal    8(%esp), %edi                                 <
>         andl    $-16, %esp                                    <
>         pushl   -4(%edi)                                      <
>         pushl   %ebp                                                    pushl   %ebp
>         movl    %esp, %ebp                                              movl    %esp, %ebp
>         pushl   %edi                                          |         andl    $-16, %esp
>         pushl   %esi                                          |         subl    $112, %esp
>         pushl   %ebx                                          |         movl    %ebx, 100(%esp)
>         subl    $108, %esp                                    |         movl    %esi, 104(%esp)
>                                                               >         movl    %edi, 108(%esp)
>         call    mcount                                                  call    mcount
> 
> where the only difference is -mtune=generic.  I'm investigating.

Forget that, I see from the gcc-bugs list that hj has tracked it down to
the use of DRAP, and for some reason the mtune options affect that.  He's
the best person to fix this.

Andrew.